WB1 7.58 BGP Next-Hop Trigger

7.58 BGP Next-Hop Trigger

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

-------------------------------------

Many times BGP NEXT_HOP attribute is used for recursive lookup through the
IGP table to resolve the actual next-hop interface and router. Until IOS 12.3(14)T
BGP was accounting for IGP information changes only during periodic BGP
scans with the interval defined by the command bgp scan-time <seconds>.
With the default value of 60 seconds, it was impossible to react to IGP topology
changes between the runs of the BGP scanner process.

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.

-------------------------------------

R3:
router bgp 200
 bgp nexthop trigger delay 30

-------------------------------------

Advertise a new network 10.10.10.0/24 into BGP on SW4. Next, configure R5 so
that the Frame-Relay mapping for R3 is removed. This we lead to R3 and R5
losing EIGRP adjacency in 3 minutes. Prior to this, enable the following
debugging in R3: debug ip bgp event nexthop

R5:
interface Serial 0/0
 no frame-relay map ip 155.1.0.3 503 broadcast
SW4:
interface Loobpack1
 ip address 10.10.10.10 255.255.255.0
!
router bgp 200
 network 10.10.10.0 mask 255.255.255.0

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