A prefix is in the BGP table but not in the routing table. What could cause that?
Show the answer
Say this first
The usual causes: the next hop is unreachable (the route has no *); a route from another source with a
better administrative distance is already there (RIB-failure, r, for example OSPF 110 beating iBGP 200);
the path is valid but another path is best; it is suppressed by an aggregate (s) or dampened (d); or on an
ancient config, synchronization is on. show ip bgp <prefix> and show ip bgp rib-failure say which.
Go deeper
Working through it
show ip bgp 198.51.100.0: look at each path forinaccessibleafter the next hop, and forbest,suppressedordampened.- Next hop:
show ip route 192.0.2.1. If the IGP has no route to it, fix with next-hop-self on the edge router. - RIB-failure:
Output R1# show ip bgp rib-failure Network Next Hop RIB-failure RIB-NH Matches 172.16.5.0/24 10.255.0.3 Higher admin distance n/ashow ip route 172.16.5.0shows who won, here OSPF. - Not best: compare the paths with the best path order. The best one may point elsewhere.
A detail interviewers like
IOS still advertises RIB-failure routes to its BGP peers by default. bgp suppress-inactive stops that, so
the router only advertises what it actually forwards with.
They will ask next
Is a RIB-failure always a problem?
Often not. If OSPF and BGP describe the same internal prefix, OSPF winning is normal. It matters when BGP policy expects one path but packets follow the IGP route somewhere else.
What if the prefix is not in the BGP table at all?
Then look earlier: did the peer send it (
received-routeswith soft reconfiguration, or a looking glass on the peer), did inbound policy drop it, or was it dropped as a loop because your own AS was in the path?
Traps
- Thinking
rmeans rejected. The route is valid and best in BGP, it just lost in the routing table.