Trace the route, one place at a time
A BGP route can be lost at six places between the router that owns it and the router where you expect it. Work along that path from the source. The mistake to avoid is staring at the receiver, because the route may never have left the sender.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Stage 1: the route is never originated
If the prefix is not in the sender BGP table, nothing downstream can find it. The usual cause is the network statement rule: the prefix and mask must exactly match a route in the routing table. A /23 in the routing table and a network for the /24 inside it originates nothing. The originating routes lesson covers this and the other ways a route enters BGP.
R1#show ip bgp 198.51.100.0/24 % Network not in table
show ip route 198.51.100.0 255.255.255.0 next. If the routing table does not have the exact prefix, create it (for example a static route to Null0) or correct the statement.Summaries have the same shape of fault. An aggregate-address exists only while at least one more-specific route is in the BGP table. If all contributors were only in the routing table, the aggregate never appears.
Stage 2: advertised, or filtered on the way out
A route is in the table but the neighbour never hears about it. Check what is actually sent, then look at outbound policy: a prefix list, a route map, an AS-path filter, a no-export community. Each of these can drop it, and each needs a soft reset after a change.
show ip bgp neighbors 192.0.2.1 advertised-routes
show ip bgp 198.51.100.0/24
show ip bgp neighbors 192.0.2.1 | include policy|filter|route-mapR1. The first command lists what is sent after outbound policy. In the second, the line Advertised to update-groups shows who receives the prefix. The third lists the policies attached to the neighbour.
Stage 3: iBGP split horizon
A router does not pass a route it learned from an iBGP peer to another iBGP peer. This stops loops inside the AS, because iBGP does not add to the AS path, but it means every iBGP router must hear the route directly from the router that learned it, or from a route reflector.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Stage 4: the next hop is unreachable
The route arrives but there is no asterisk. The router received it, the next hop in it is not reachable, and so the path is not valid. Across an iBGP session the next hop is not changed, so a path from an eBGP neighbour usually carries a next hop on an external link that the internal routers do not know about.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
R2#show ip bgp 203.0.113.0 BGP routing table entry for 203.0.113.0/24, version 1 Paths: (1 available, no best path) Not advertised to any peer 64501 192.0.2.1 (inaccessible) from 10.255.0.1 (10.255.0.1) Origin IGP, metric 0, localpref 100, valid, internal
(inaccessible) and no best path are the signs. The route exists, but R2 has no route to 192.0.2.1. Add neighbor 10.255.0.2 next-hop-self on R1, or advertise the external link in the IGP.Stage 5 and 6: chosen as best, but not installed
If the path is valid and best but the routing table shows something else, look for an RIB failure, marked r in the BGP table. BGP offered the route and the routing table refused it, because another source has a route to the same prefix with a lower administrative distance. An OSPF route (distance 110) beats an iBGP route (distance 200), so the iBGP copy of a prefix that OSPF also carries is rejected. An eBGP route (distance 20) beats OSPF.
R2#show ip bgp Network Next Hop Metric LocPrf Weight Path r>i 198.51.101.0 10.255.0.1 0 100 0 i
show ip bgp rib-failure to list the routes and the reason. Remove or lower the competing route, or change the distance of the BGP route, if you want BGP to win.On small screens, swipe sideways or focus the diagram and use the arrow keys.
Technical reference: Cisco, BGP best path selection algorithm. Output above is illustrative.
Check your understanding
R1 hears a route from ISP A over eBGP and passes it to R2 over iBGP. R2 does not send it to R3, another iBGP peer. Why?
show ip bgp lists a path without an asterisk and with (inaccessible) after the next hop. What should you check?
A route is marked r> in the BGP table. What happened?