BGP Next-Hop Trigger clarification

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

Advertise 8.8.8.0/24 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 8.8.8.8

    155.1.58.8 (metric 3584) from 155.1.0.5 (150.1.5.5)

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

      Originator: 150.1.8.8, Cluster list: 150.1.5.5

      rx pathid: 0, tx pathid: 0

  Refresh Epoch 2

  Local, (Received from a RR-client)

    155.1.58.8 (metric 3584) from 155.1.58.8 (150.1.8.8)

      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 155.1.0.5 go away within 30 seconds as this next-hop is no longer available.

 

However, what I see is that prefix (from 155.1.0.5) 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.

Comments

Sign In or Register to comment.