BGP Next-Hop Trigger clarification

Hello,  I'm running through the Next-Hop Trigger lab and have a clarification question:

Advertise from R8 into BGP.
Configure R3 to respond to BGP prefixes' next-hop changes within 30 seconds

R3# bgp nexthop trigger delay 30

R3 is iBGP with R5.
R3 is Route-Reflector to R8
R5 is Route-Reflector to R8

So I'm going through the verification and trying to see the benefit of this feature.  The lab has you remove NHRP between R3/R5 so they lose their EIGRP peer, so the next-hop change should trigger.

Prior to this, on R3 I see:

R3#sh ip bgp (metric 3584) from (

      Origin IGP, metric 0, localpref 100, valid, internal

      Originator:, Cluster list:

      rx pathid: 0, tx pathid: 0

  Refresh Epoch 2

  Local, (Received from a RR-client) (metric 3584) from (

      Origin IGP, metric 0, localpref 100, valid, internal, best

      rx pathid: 0, tx pathid: 0x0


So, after removing the NHRP binding and issuing #clear ip nhrp & #clear crypto sa from R3, it's IGP peer to R5 goes down.
I believe I should expect to see the prefix learned from go away within 30 seconds as this next-hop is no longer available.


However, what I see is that prefix (from staying in the BGP table until the 180 second holdtime timer expires for BGP and the iBGP session is removed.


Is this intended?  Am I missing something?  If this is intentional and the prefix to the dead next-hop isn't removed until scan-time is ran, what's the point of this feature?


Thanks for any clarification.


Sign In or Register to comment.