Probable reasons BGP isn't installing a route

By stretch | Wednesday, November 19, 2008 at 1:01 a.m. UTC

Although perhaps only one route to a destination exists, there are a number of reasons BGP might not select it as a "best" route (consequently omitting it from the routing table). Below are some of the most common causes.

Synchronization is enabled and the route is not known by an IGP

If synchronization is enabled, BGP requires each route to be known by an IGP before placing it in the routing table. This is considered legacy behavior and isn't typically enforced on modern networks. Synchronization is easily disabled:

Router(config-router)# no synchronization

In fact, synchronization is disabled by default beginning with IOS release 12.2(8)T.

NEXT_HOP is inaccessible

If the router doesn't know how to reach a route's next hop, a recursive lookup will fail, and the route can't be added to BGP. For example, if a BGP router receives a route for 10.0.0.0/8 with a NEXT_HOP attribute of 192.168.0.1, but doesn't have an entry in its routing table for a subnet containing 192.168.0.1, the received route for 10.0.0.0/8 is useless and won't be installed in the routing table.

AS_PATH includes the local AS

If a route advertised by an external (eBGP) neighbor includes the local AS in its AS_PATH attribute, the route will be rejected. This is a loop prevention mechanism used by BGP, and it is a fundamental concept of the protocol. However, there may be instances when you want to bend this rule and allow such routes anyway. This can be accomplished by appending the allowas-in keyword to a neighbor statement:

Router(config-router)# neighbor 1.2.3.4 allowas-in

As this configuration results in somewhat abnormal BGP behavior, exercise caution to avoid creating routing loops.

Attempting to readvertise iBGP-learned routes to iBGP neighbors

BGP won't advertise a route learned from an internal (iBGP) neighbor to other internal neighbors. To achieve full convergence within an autonomous system, it is recommended to configure mesh adjacencies, or to employ route reflectors or confederations.

Rejection by inbound policy

Routes may be being unintentionally blocked by an inbound route-map applied to the BGP neighbor. This can be inspected by comparing the output of two variations of the show ip bgp neighbor command:

Router# show ip bgp nei 172.16.0.2 received-routes
BGP table version is 6, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
          r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*  192.168.2.0      172.16.0.2             100             0 65200 ?
*  192.168.3.0      172.16.0.2             100             0 65200 ?

Total number of prefixes 2

The first command displays all routes being advertised by the specified neighbor. Note that inbound soft-reconfiguration must be enabled for the neighbor in order for this command to produce any useful output.

Router# show ip bgp nei 172.16.0.2 routes
BGP table version is 6, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
          r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*  192.168.3.0      172.16.0.2             100             0 65200 ?

Total number of prefixes 1

This second command lists all routes from the neighbor which have been entered into the routing table. The above output reveals that only one of the advertised routes (192.168.3.0/24) is being allowed through the inbound routing policy for this neighbor. When this happens, double-check the route-map applied inbound.

About the Author

Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

Posted in Routing

Comments


carloslnx (guest)
November 19, 2008 at 4:35 p.m. UTC

thanks, this is very useful to troubleshooting


Kevin G. (guest)
November 19, 2008 at 5:05 p.m. UTC

Very nice writeup Stretch!


Jeroen Roos (guest)
November 19, 2008 at 7:30 p.m. UTC

A very useful command for this is "show ip bgp rib-failure", which shows an explanation on why a route which is in the local BGP table (so it is not rejected by a filter) is not installed in the routing table. You can recognize those routes by an 'r' in front of it in the show ip bgp output.


Matt (guest)
November 20, 2008 at 4:45 p.m. UTC

Thanks!


Marcus (guest)
January 13, 2009 at 8:02 p.m. UTC

Thanks.. Very good info


Jeroen Roos (guest)
December 10, 2012 at 6:40 a.m. UTC

thanks to Jeroen Roos.
i was not known to this command.


'Mide (guest)
December 3, 2013 at 3:14 p.m. UTC

Forgot to add higher administrative distance


Cuong Tran (guest)
November 3, 2015 at 4:26 a.m. UTC

Another reason is dedicated for loopback interface configured in OSPF. Then BGP router does not advertise the interface to its BGP neighbors. To solve this, you should explicitly configure loopback interface as point-to-point. In detail, it should be like this (for Cisco Router):

conf t int loopback0 ip ospf network point-to-point

Then the world is peaceful again.


Mel (guest)
September 19, 2016 at 4:44 p.m. UTC

Another reason why EBGP to EBGP wont pass on the routes is if the route-map applied to the neighbour has a blanket deny or does not exist.


Mark Paquette (guest)
September 23, 2016 at 5:17 p.m. UTC

I'm actually troubleshooting something now where (m)BGP has the exact same routes as (u)BGP but seems to be ignoring recursive lookups via iBGP (there's a summary route for the distant next-hop) - so it's attempting to use the unicast-only link rather than the multicast-only link. It doesn't manifest itself when the next-hop is directly-connected (as with typical eBGP).

Comments have closed for this article due to its age.