Troubleshooting iBGP

Load isis.ibgp.tshoot.cfg

#IOS-XE
config replace flash:isis.ibgp.tshoot.cfg

#IOS-XR
configure
load bootflash:isis.ibgp.tshoot.cfg
commit replace
y

An iBGP session is configured between R1 and XR2. R1 is advertising a prefix (100.100.100.100/32). LDP autoconfig has been added so that traffic can be tunneled between R1 and XR2.

Explain why the iBGP session is not established, and find a way to fix it.

Answer

#R3, R4
ip prefix-list L2_TO_L1 permit 20.20.20.20/32
!
route-map L2_TO_L1
 match ip add prefix L2_TO_L1
!
router isis
 redistribute isis ip level-2 into level-1 route-map L2_TO_L1

#XR1
route-policy L2_TO_L1
 if destination in ( 1.1.1.1/32 ) then pass endif
end-policy
!
router isis 1
 add ipv4 uni
  propagate level 2 into level 1 route-policy L2_TO_L1

Explanation

Before making any changes, let’s examine the issue. First let’s look at the BGP neighbor on R1. Counter-intuitively, R1 states that it does have a route to 20.20.20.20/32. However, this is very deceptive, because IOS-XE and IOS-XR cannot use the 0/0 route to establish a session with a peer.

If we simply debug ip bgp, we can see the issue. This seems to contradict the show output saying that “the RIB does have a route.”

IOS-XR gives us better output from the show bgp neighbor command:

One easy way to fix this is to leak L2 routes into L1. On R3 and R4, let’s leak 20.20.20.20/32 into L1. This should give R1 an explicit route to XR2.

#R3, R4
ip prefix-list L2_TO_L1 permit 20.20.20.20/32
!
route-map L2_TO_L1
 match ip add prefix L2_TO_L1
!
router isis
 redistribute isis ip level-2 into level-1 route-map L2_TO_L1

The BGP peer now comes up. Only one side needed the explict route to initiate the TCP connection.

However, a second problem now exists. On IOS-XR, a nexthop cannot be resolved through the 0/0 route.

To demonstrate that this is not the case for IOS-XE, let’s inject a route on XR2, remove the L2 to L1 leaking on R3/R4, and only leak 1.1.1.1/32 on XR1.

#R3, R4
router isis
 no redistribute isis ip level-2 into level-1 route-map L2_TO_L1

#XR2
int lo200
 ip add 200.200.200.200/32
!
router bgp 100
 add ipv4 uni
  network 200.200.200.200/32

#XR1
route-policy L2_TO_L1
 if destination in ( 1.1.1.1/32 ) then pass endif
end-policy
!
router isis 1
 add ipv4 uni
  propagate level 2 into level 1 route-policy L2_TO_L1

Now XR2 can validate the nexthop for R1’s prefix:

Even though R1 is missing the /32 route for XR2, 200.200.200.200/32 has a valid nexthop.

Right now, there is no reachability because R2 does not have 20.20.20.20/32 in its RIB, and doesn’t allocate a label for it, and then advertise this to R1. So the end-to-end LSP from R1 to XR2 is broken.

We can sort of get around this in a convuluted way by using static routing and static MPLS labels. On R2, make sure to find R3’s local label to use as the static output label.

#R1
mpls label range 100 199 static 1000 1999
mpls static binding ipv4 20.20.20.20 255.255.255.255 1000
mpls static binding ipv4 20.20.20.20 255.255.255.255 output 10.1.2.2 2000
!
ip route 20.20.20.20 255.255.255.255 10.1.2.2

#R2
mpls label range 200 299 static 2000 2999
mpls static binding ipv4 20.20.20.20 255.255.255.255 2000
mpls static binding ipv4 20.20.20.20 255.255.255.255 output 20.2.3.3 30
!
ip route 20.20.20.20 255.255.255.255 20.2.3.3

Unfortunately, a static route is needed in order to make the MPLS entry valid. So we still had to provide some sort of routing for 20.20.20.20/32 on R1 to get this to work. It would obviously just be easier to leak 20.20.20.20/32 from L2 into L1 on R3/R4.