> For the complete documentation index, see [llms.txt](https://ccie-sp.gitbook.io/ccie-spv5.1-labs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ccie-sp.gitbook.io/ccie-spv5.1-labs/labs/isis/troubleshooting-ibgp.md).
# 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.
