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:
- Announce the EBGP next hop through an IGP using a static route or
redistribution.
- 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.