BGP Next-Hop Trigger clarification
Hello, I'm running through the Next-Hop Trigger lab and have a clarification question:
Advertise 184.108.40.206/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 220.127.116.11
18.104.22.168 (metric 3584) from 22.214.171.124 (126.96.36.199)
Origin IGP, metric 0, localpref 100, valid, internal
Originator: 188.8.131.52, Cluster list: 184.108.40.206
rx pathid: 0, tx pathid: 0
Refresh Epoch 2
Local, (Received from a RR-client)
220.127.116.11 (metric 3584) from 18.104.22.168 (22.214.171.124)
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 126.96.36.199 go away within 30 seconds as this next-hop is no longer available.
However, what I see is that prefix (from 188.8.131.52) 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.