IBGP-Learned Route Not Getting Installed in IP Routing Table-Cause: IBGP Next Hop Not Reachable

IBGP-Learned Route Not Getting Installed in IP Routing Table ‚ Cause: IBGP Next Hop Not Reachable

The cause of this problem is most common in IBGP-learned routes where BGP next-hop address should have been learned through an Interior Gateway Protocol (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 15-20 shows the flowchart to follow to resolve this problem.

Figure 15-20. Problem-Resolution Flowchart

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

Figure 15-21. Next hop of BGP Routes Advertised to IBGP Neighbors Is Not Changed and Might Result in Route Installation Failure

Debugs and Verification

Example 15-45 shows that 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.

Example 15-45 shows the relevant configuration of R8, R1, and R2.

Example 15-45 Configuration Needed in R1, R2, and R8 to Form Neighbor Relationship and Originate and Propagate 100.100.100.0/24

 R8#  router bgp 110   no synchronization   network 100.100.100.0 mask 255.255.255.0   neighbor 206.56.89.2 remote-as 109   ip route 100.100.100.0 255.255.255.0 Null0  _____________________________________________________________________________________ R1#  router bgp 109   no synchronization   neighbor 131.108.10.2 remote-as 109   neighbor 131.108.10.2 update-source Loopback0   neighbor 206.56.89.1 remote-as 110  _____________________________________________________________________________________ R2#  router bgp 109   no synchronization   neighbor 131.108.10.1 remote-as 109  neighbor 131.108.10.1 update-source Loopback0 

The configuration in Example 15-45 shows that R8 has one EBGP neighbor, R1, which has R8 and R2 as EBGP and IBGP neighbors, respectively. R2 has R1 as an IBGP neighbor.

R8 is advertising 100.100.100.0/24 to R1, and R1 will propagate that to R2 as an IBGP advertisement.

Example 15-46 shows that R1 receives this route, installs it in its routing table, and propagates it to R2 131.108.10.2.

Example 15-46 R1 Receives the Route and Propagates It to R2

 R1#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table)  Advertised to non peer-group peers:   131.108.10.2  110     206.56.89.1 from 206.56.89.1 (100.100.100.8)       Origin IGP, metric 0, localpref 100, valid, external, best R1#  show ip route 100.100.100.0  Routing entry for 100.100.100.0/24   Known via "bgp 109", distance 20, metric 0   Tag 110, type external   Last update from 206.56.89.1 00:04:50 ago   Routing Descriptor Blocks:   * 206.56.89.1, from 206.56.89.1, 00:04:50 ago       Route metric is 0, traffic share count is 1       AS Hops 1 

The highlighted output shows that R1 is advertising 100.100.100.0/24 to 131.108.10.2, which is R2.

In Figure 15-21, R2 is an IBGP peer of R1, which advertises 100.100.100.0 /24 to R2. Then R2 receives this BGP route with a Next-hop of 206.56.89.1 but fails to install 100.100.100.0/24 in its routing table, as demonstrated in Example 15-47.

Example 15-47 R2 Fails to Install the 100.100.100.0 /24 Route in Its Routing Table

 R2#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 0 Paths: (1 available, no best path)   Not advertised to any peer   110  206.56.89.1 (inaccessible)  from 131.108.10.1 (131.108.10.1)       Origin IGP, metric 0, localpref 100, valid, internal R2#  show ip route 100.100.100.0  % Network not in table 

Notice that 206.56.89.1 is inaccessible because R2 does not have a route to reach it in its IP routing table, as confirmed by Example 15-48.

Example 15-48 R2's IP Routing Table Confirms an Inaccessible Route

 R2#  show ip route 206.56.89.1  % Network not in table 

This might be because R1 is not advertising 206.56.89.1 to R2 through its IGP (OSPF) or R2 is not installing 206.56.89.1 for any other reason.

Solution

BGP requires the next hop of any BGP route to resolve to a physical interface. 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.

Announce the EBGP Next Hop Through an IGP Using a Static Route or Redistribution

This solution simply requires that the subnet 206.56.89.0/30 be advertised by R1 in its IGP ‚ OSPF, in this example.

Example 15-49 shows the necessary configuration in R1 to accomplish this and shows R2 receiving this route through an IGP.

Example 15-49 Configuring R1 to Advertise EBGP Next Hop Through OSPF

 R1#  router ospf 1  network 206.56.89.0 0.0.0.7 area 0 

The output in Example 15-50 shows that R2 receives this route through OSPF.

Example 15-50 R2's IP Route Table Confirms Receipt of the EBGP Next-Hop Route Advertisement Through OSPF

 R2#  show ip route 206.56.89.0 255.255.255.252  Routing entry for 206.56.89.0/30   Known via "ospf 1", distance 110, metric 74, type intra area   Redistributing via ospf 1   Last update from 131.108.1.1 on Ethernet0, 00:03:17 ago   Routing Descriptor Blocks:   *  131.108.1.1  , from 1.1.1.1, 00:03:17 ago, via  Ethernet0  Route metric is 74, traffic share count is 1 

Note that 131.108.1.1 resolves to interface Ethernet0.

Change the Next Hop to an Internal Peering Address

This solution suggests that R1 change the BGP next hop to its loopback address when advertising IBGP routes to R2.

Example 15-51 shows that the configuration in R1 requires the BGP next hop to be changed to its own loopback address.

Example 15-51 Configuring R1 So That the BGP Next Hop Is Its Own Loopback Address

 R1#  router bgp 109   neighbor 131.108.10.2 remote-as 109   neighbor 131.108.10.2 update-source Loopback0    neighbor 131.108.10.2 next-hop-self   neighbor 206.56.89.1 remote-as 110 

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

Example 15-52 shows this change reflected in R2.

Example 15-52 R2's BGP Route Table Confirms That R1's Loopback Address Is the Next Hop of All BGP Updates Sent to R2

 R2#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table)   Not advertised to any peer   110  131.108.10.1  from 131.108.10.1 (131.108.10.1)       Origin IGP, metric 0, localpref 100, valid, internal, best R2#  show ip route 100.100.100.0  Routing entry for 100.100.100.0/24   Known via "bgp 109", distance 200, metric 0   Tag 110, type internal   Last update from 131.108.10.1 00:00:25 ago   Routing Descriptor Blocks:  * 131.108.10.1  , from 131.108.10.1, 00:00:25 ago       Route metric is 0, traffic share count is 1       AS Hops 1 

The exterior Next-Hop changed to the loopback of R1, 131.108.10.1.

This solution is more widely used and is the preferred method of announcing the next hop to IBGP peer. In the simple example of Figure 15-21, 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.