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 188.8.131.52 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
November 19, 2008 at 4:35 p.m. UTC
thanks, this is very useful to troubleshooting
November 19, 2008 at 5:05 p.m. UTC
Very nice writeup Stretch!
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.
November 20, 2008 at 4:45 p.m. UTC
January 13, 2009 at 8:02 p.m. UTC
Thanks.. Very good info
December 10, 2012 at 6:40 a.m. UTC
thanks to Jeroen Roos.
i was not known to this command.
December 3, 2013 at 3:14 p.m. UTC
Forgot to add higher administrative distance
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.
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.
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).