notes: Troubleshooting BGP Route Not Installing in Routing Table

If the BGP process fails to create an IP routing table entry, all traffic destined for missing IP subnets in the routing table will be dropped. This is a generic behavior of hop-by-hop IP packet forwarding done by routers

 1. IBGP-Learned Route Not Getting Installed in IP Routing Table—Cause: IBGP Routes Are Not Synchronized

IBGP will not install or propagate a route to other BGP speakers unless IBGP-learned routes are synchronized. Synchronization means that for an IBGP-learned route, there must exist an identical route in the IP routing table provided by an IGP (OSPF, IS-IS, and so on).

debugs and verification:

show ip bgp a.b.c.d

Solution:

- Synchronize all BGP routes.

 R1# router ospf 1

 redistribute static subnets

 network 131.108.1.0 0.0.0.255 area 0

R1# router bgp 109

 network 100.100.100.0 mask 255.255.255.0

 neighbor 131.108.10.2 remote-as 109

 neighbor 131.108.10.2 update-source Loopback0

ip route 100.100.100.0 255.255.255.0 Null0

- Turning off synchronization

   This method is widely used in almost all BGP networks

no synchronization

2.  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.

Debugs and Verification:

show ip route a.b.c.d.

sho ip bgp a.b.c.d  - next hop is inaccessible

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:

a.  Announce the EBGP next hop through an IGP using a static route or redistribution.

b.  Change the next hop to an internal peering address.

This solution is more widely used and is the preferred method of announcing the next hop to IBGP peer.

3.  Problem: EBGP-Learned Route Not Getting Installed in IP Routing Table

3a.  EBGP-Learned Route Not Getting Installed in IP Routing Table—Cause: BGP Routes Are Dampened.

Dampening is the way to minimize instability in a local BGP network caused by unstable BGP routes from EBGP neighbors. RFC 2439, "BGP Route Flap Damping," describes in detail how dampening works. In short, dampening is the way to assign a penalty for a flapping BGP route. A withdrawal of a prefix is considered a flap. A penalty of 1000 is assigned for each flap; if the flap penalty reaches the suppress limit because of continued flaps (default 2000), the BGP path is suppressed and is taken out of the routing table. This penalty is decayed exponentially based on the half-life time (default 15 minutes). When the penalty reaches the reuse value (default 750), the path is unsuppressed and is installed in the routing table and advertised to other BGP neighbors. Any dampened path can be suppressed only until the max suppress time (default 60 minutes). Dampening is applied only to EBGP neighbors, not to IBGP neighbors.

router bgp 1009
bgp dampening half-life-time reuse suppress maximum-suppress-time

half-life-time— Range is 1 to 45 minutes. Current default is 15 minutes.

reuse— Range is 1 to 20,000. Default is 750.

suppress— Range is 1 to 20,000. Default is 2000.

max-suppress-time— Maximum duration that a route can be suppressed. Range is 1 to 255. Default is four times half-life-time.

debug and verifications:

R1#debug ip bgp dampening 1

R1#debug ip bgp updates 1

access-list 1 permit 100.100.100.0 0.0.0.0

Solution:

1.  Wait for the penalty to go below the reuse limit (750).

2.  Remove dampening altogether from the BGP configuration.

3.  Clear the flap statistics.

 clear ip bgp dampening a.b.c.d

3b.  EBGP-Learned Route Not Getting Installed in IP Routing Table—Cause: BGP Next Hop Not Reachable in Case of Multihop EBGP

In a multihop EBGP session, EBGP speakers are not directly connected. Peering between loopback addresses of adjacent routers also is considered multihop.

This problem of an EBGP multihop route not getting installed in an IP routing table is identical to the IBGP next hop issue; however, most of the commonly seen problems occur when the router fails to resolve the next-hop address to an interface.

In this problem, the multihop EBGP next hop is reachable through a BGP route whose next hop is again the original multihop BGP next hop. For example, to reach prefix A, the next hop is prefix B; to reach prefix B, the next hop is again B. This is considered a recursion problem in which a router cannot resolve to an interface to reach the next hop B.

show ip route a.b.c.d

show ip bgp a.b.c.d

Solution:

The solution to this problem based on this cause is to simply have a more specific route for the next-hop address. In the case of EBGP, this is commonly done by having a static route for the multihop EBGP peering address.

This instance is observed in the case of multihop EBGP sessions when the next-hop address is not directly connected and the IP routing table must have an explicit route to the next-hop address.

 4.  EBGP-Learned Route Not Getting Installed in the Routing Table—Cause: Multiexit Discriminator (MED) Value Is Infinite

In Cisco IOS Software, if a multiexit discriminator (MED) is set to infinite 4294967295, the router will not install this route in the routing table.

The infinite metric sometimes is used in route servers, which provide a mirror view of the Internet BGP table. Setting the metric to infinity prohibits such routes from going in the IP routing table, so no IP traffic will use those routes. This case is discussed here just to show a corner case of a BGP path not getting installed in the routing table. Such a configuration is not seen in real BGP networks.