Content

| 5.9 |  | Troubleshooting BGP |
| 5.9.4 |  | The BGP next hop is not reachable |

A common problem in BGP occurs when the next hop is not reachable. The cause of this problem, IBGP-learned route is not getting installed into the IP routing table, is most common in IBGP-learned routes where BGP next-hop address should have been learned through an IGP. Failure to reach the next hop is an IGP problem, and BGP is merely a victim. With BGP, when IP prefixes are advertised to an IBGP neighbor, the NEXT-HOP attribute of the prefix does not change. The IBGP receiver must have an IP route to reach this next hop.

Figure shows the NEXT-HOP of BGP routes advertised to IBGP neighbors are not changed and might result in route installation failure.

Debugs and Verification
R8 is advertising the 100.100.100.0/24 route to its EBGP peer R1, which will advertise this route to R2. However, on R2, the problem of the next hop appears. Figure shows the configuration of BGP on RT8, RT1, and RT2.

R8 is advertising 100.100.100.0/24 to R1, and R1 will propagate that to R2 as an IBGP advertisement. R1 receives this route, installs it in its routing table, and propagates it to R2 at 131.108.10.2.

In Figure , R2 is an IBGP peer of R1. R2 receives this BGP route, 100.100.100.0/24 with a NEXT-HOP of 206.56.89.1, but fails to install it in its IP routing table.

Solution
Remember that for EBGP sessions, the next hop is the IP address of the neighbor that announced the route. For IBGP sessions, routes that originated inside the AS, the next-hop is the IP address of the neighbor that announced the route.

For routes injected into the AS via EBGP, the next hop learned from EBGP is carried unaltered into IBGP. The next hop is the IP address of the EBGP neighbor from which the route was learned.

BGP requires the next hop of any BGP route to resolve to a physical interface (exit-interface in the IP routing table). This might or might not require multiple recursive lookups in the IP routing table. Two common solutions exist for addressing this problem:

1. Announce the EBGP next hop through an IGP using a static route or redistribution.
2. Change the next hop to an internal peering address, using the next-hop-self command.

Change the configuration of R1 so that the subnet 206.56.89.0/30 is included in its OSPF advertisements of R1 to R2, which would include the address of the next-hop IP address of R8. Figure shows that R2 receives this route through OSPF.

Another solution is to change the BGP next hop address on R1 to its loopback address when advertising IBGP routes to R2. Figure shows the configuration on R1 that modifies the BGP next hop to be changed to its own loopback address.

The command neighbor 131.108.10.2 next-hop-self changes the next-hop to its own loopback 0 (131.108.10.1). The neighbor 131.108.10.2 update-source loopback 0 command makes R1 loopback 0 the source of all BGP packets sent to R2.

The command show ip bgp in Figure shows this change reflected in R2. The exterior next-hop changed to the loopback of R1, 131.108.10.1.

The second solution is more widely used and is the preferred method of announcing the next hop to IBGP peers. The solution of changing the next hop to an internal peering address allows one less IP subnet to go in the IP routing table. In addition, it helps in troubleshooting because network operators recall their internal loopback addresses quicker than external IP subnets, such as that used in the EBGP connection.