LAB: BGP Next Hop Trigger

- Configure R3 to respond to BGP prefixes next-hop changes within 30 seconds of IGP prefix change.

Since IOS 12.3(14)T the next-hop tracking behavior has been changed from periodic to event-driven. This behavior is enabled by default using the command bgp nexthop trigger enable. BGP process registers the NEXT_HOP attribute values with the RIB table watch process. As soon as any change that affects an existing NEXT_HOP occurs, the watch process notifies the BGP router process. If the change results in prefix withdrawn, the BGP process immediately removes the prefix. All other notification are delayed and batched until the timeinterval specified by the command bgp nexthop trigger delay <seconds> expires. After this, a full BGP table walk occurs, performing bestpath computations for all prefixes. The delay value should be tuned according to the IGP convergence speed to avoid unnecessary full table walks. That is, it is desirable to have IGP fully converged after an initial change (or sequence of change) until the full BGP walk has started.

configuration:

R3:
router bgp 200
bgp nexthop trigger delay 30

Observe the debugging output on R3. Notice that the BGP process responds to IGP changes and schedules a BGP table walk in 30 seconds.

03:21:28.615: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 155.1.0.5
(Serial1/0.1) is down: holding time expired
03:21:28.631: EvD: accum. penalty decayed to 0 after 232 second(s)
03:21:28.636: BGP(IPv4 Unicast): Nexthop modified, reuse in 00:00:19,
19000 , scheduling nexthop scan in 30 secs
03:21:28.636: EvD: accum. penalty decayed to 500 after 0 second(s)
03:21:28.636: BGP(IPv4 Unicast): Nexthop modified, reuse in 00:00:27,
27000 , timer already running
03:21:58.637: BGP: NHOP scanner event timer
03:21:58.637: BGP: Nexthop walk for IPv4 Unicast