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
I have CSR's in an ESXi environment.