A route is only as good as its next hop
Every path in the BGP table names a next hop, and the router must be able to reach that address through its routing table. If it cannot, the path is not valid and is not used. Inside an AS the next hop is usually the loopback of another router, reached over the IGP, so BGP convergence depends on the IGP.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
That raises a question: when the IGP changes the route to a next hop, how does BGP find out? Two mechanisms answer it.
The BGP scanner: a periodic check
The original method is a scanner. A background process wakes up periodically (every 60 seconds by default) and walks the whole BGP table, checking each next hop against the routing table. It is simple but slow: a change just after a scan waits almost a full minute. During that time the router may keep forwarding to a next hop that no longer exists, or fail to use a better one. Traffic is black-holed or looped until the next scan.
Next-hop tracking: react to the event
Next-hop tracking removes the wait. The router registers the next-hop addresses it uses with the routing table. When one of those routes changes, BGP is told at once and schedules a next-hop scan after a short delay, 5 seconds by default. The delay lets a burst of IGP changes settle so BGP recalculates once instead of repeatedly.
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.
After the walk, paths whose next hop is now unreachable lose the valid flag, the best-path algorithm picks another path, and the RIB is updated. The failed path stays in the table for a while but is not chosen.
Viewing and tuning it
Next-hop tracking is on by default, so a normal configuration does not mention it. It appears in the full running configuration.
show running-config all | include nexthop triggerPrivileged EXEC mode. Shows the defaults: bgp nexthop trigger enable and bgp nexthop trigger delay 5. These lines are hidden from a normal show running-config because they are default values.
router bgp 64500
address-family ipv4 unicast
bgp nexthop trigger delay 2R1. Shortens the wait before the scan from 5 to 2 seconds. A smaller value reacts faster but recalculates more often if the IGP is unstable. The value is in seconds.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
When a default route hides a lost next hop
If the router has a default route, it can resolve almost any next hop through it, and a next hop that really is gone still looks reachable. Traffic then follows the default route instead of the BGP path you expected. Cisco IOS XE lets you restrict which routes may be used to resolve next hops, with bgp nexthop route-map. Without it, make sure the IGP carries a specific route to each BGP next hop, usually a /32 loopback.
Technical reference: Cisco IOS XE BGP configuration guide, BGP next-hop tracking. Commands shown are the defaults on current IOS XE.
Check your understanding
With default settings, about how long after the IGP removes a next-hop route does BGP begin to recalculate?
A BGP neighbour stops sending keepalives but the IGP route to its loopback is unchanged. Does next-hop tracking react?
Where do you normally see bgp nexthop trigger delay 5?