About Next-Hop Tracking Operations of BGP in IOS

CscTsWebDocs · ‎07-24-2014

Introduction

BGP Next-Hop Tracking (hereon referred to as NHT) is a function that allows faster convergence by performing scans dynamically when the route used to reach the next-hop is updated.

This document introduces the NHT operation. Command outputs will also be introduced.

* This document describes operations in the IOS. Please be aware that operations and parameters may differ between IOS-XR and IOS-XE.

Configuration

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

(Setting details of each device are described at the end of the document)

+--10.1.1.0/24(cost 10)--+ +--10.23.1.0/24--[R3](AS65003)-- 172.20.1.0/24

[R1] (AS65000) [R2]

+--10.1.2.0/24(cost100)--+ +--10.24.1.0/24--[R4](AS65004)-- 192.168.1.0/24

R1-R2: iBGP and OSPF as IGP (Advertise 10.x.x.x network)

R2-R3: eBGP (eBGP multihop)

R2-R4: eBGP (disable-connected-check)

* For simplification, all BGP sessions are established among loopback addresses

Set static to the routes for eBGP session mutually; re-distribute static route into OSPF at R2

For R2, advertise two loopback addresses additionally via BGP (10.22.22.22/32, 10.222.222.222/32)

(* 15.1(4)M3 is used for all the output examples below)

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

Basic Operation of Next-Hop Tracking

This is a function enabled by default for IOS currently supported. To disable, configure the no bgp nexthop trigger enable command.

By default, the scan will be performed five seconds after the route is updated. This value can be adjusted by the bgp nexthop trigger delay <SEC> command. If there is no route which can reach to the next-hop address when performing the scan, all the BGP routes that use the next-hop address will be deleted.

The address targeted for tracking is the next-hop address of the BGP route. You can check this address in the Next Hop column using the show ip bgp command. If many prefixes exist, you can check the summarized address using the show ip bgp nexthops command.

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

R1#show ip bgp

BGP table version is 21, local router ID is 1.1.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>i10.22.22.22/32 2.2.2.2 0 100 0 i

*>i10.222.222.222/32

2.2.2.2 0 100 0 i

*>i172.20.1.0/24 3.3.3.3 0 100 0 65003 i

*>i192.168.1.0 4.4.4.4 0 100 0 65004 i

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

R1#show ip bgp nexthops

# Paths Nexthop Address

2 2.2.2.2

1 3.3.3.3

1 4.4.4.4

R1#

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

When a link down occurs between R2-R4, the route to 4.4.4.4. will be lost, which triggers the scan of next-hop address. The following debug is an example of output during scan. You can see that the scan is scheduled after the route is deleted, and is performed 5 seconds later. This next-hop scan deletes the route whose next-hop is 4.4.4.4.

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

* debug ip routing and debug ip bgp event nexthop are enabled.

R1#

06:37:13.483: RT: del 4.4.4.4 via 10.1.1.2, ospf metric [110/20] <-- Deleting OSPF route due to link down

06:37:13.483: RT: delete subnet route to 4.4.4.4/32

06:37:13.483: EvD: accum. penalty decayed to 0 after 749 second(s)

06:37:13.483: EvD: charge penalty 500, new accum. penalty 500, flap count 24 <-- Adding penalty (to be explained later) and scheduling the scan

06:37:13.483: BGP(0): IPv4 Unicast::base nexthop modified, reuse in 00:00:19, 19000 , scheduling nexthop scan in 5 secs

R1#

06:37:18.487: BGP: BGP Event nhop timer <-- Performing Next-hop scan and deleting routes that go through 4.4.4.4

06:37:18.487: BGP: tbl IPv4 Unicast:base Nexthop walk

06:37:18.491: RT: del 192.168.1.0 via 4.4.4.4, bgp metric [200/0]

06:37:18.491: RT: delete network route to 192.168.1.0/24

R1#

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

Dampening Penalties and Half-Lives

NHT also provides a dampening function. For each address updated, 500 is added to the penalty. When the next-hop scan is to be performed is determined by the penalty value after addition.

950 or less: Scheduled as configured, in seconds (default is five seconds)
More than 950: Scheduled for when the penalty value decreases to 100 or less by the calculation formula described below

The penalty value will be added per update event, but if the next-hop scan has already been scheduled, it will not be rescheduled.

Penalty values are not simply subtracted from, but are decreased by half every eight seconds (i.e. they have a half-life of eight seconds). The precise calculation formula is complex, but the value decreases to approximately 92% every second. For example, if 500 is added and there is no other event, the penalty value will decrease to 100 or less after 19 seconds. Unlike ip dampening, this parameter (added penalty value, half-life value) cannot be modified. Also, when NHT is used, this dampening operation cannot be stopped.

Since the target of the penalty value addition is a general update operation, which includes any addition, deletion, and update of routes, the penalty value will be added every time such an event occurs. Note that addition occurs per address regardless of the number of routes that use the next-hop. In this configuration example, next-hop 2.2.2.2 is used by two prefix, but this does not mean that the penalty value will be doubled.

Output example when E0/0 of R1 is down and three routes, 2.2.2.2/32, 3.3.3.3/32, and 4.4.4.4/32, are updated

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

* debug ip routing and debug ip bgp event nexthop are enabled.

R1#

07:22:06.831: is_up: Ethernet0/0 0 state: 6 sub state: 1 line: 1

R1#

07:22:09.347: RT: updating ospf 2.2.2.2/32 (0x0):

via 10.1.2.2 Et1/0

07:22:09.347: RT: closer admin distance for 2.2.2.2, flushing 1 routes

07:22:09.347: RT: add 2.2.2.2/32 via 10.1.2.2, ospf metric [110/101]

07:22:09.347: RT: updating ospf 10.1.1.0/24 (0x0):

via 10.1.2.2 Et1/0

07:22:09.347: RT: add 10.1.1.0/24 via 10.1.2.2, ospf metric [110/110]

07:22:09.347: RT: updating ospf 4.4.4.4/32 (0x0):

via 10.1.2.2 Et1/0

07:22:09.347: RT: closer admin distance for 4.4.4.4, flushing 1 routes

07:22:09.347: RT: add 4.4.4.4/32 via 10.1.2.2, ospf metric [110/120]

07:22:09.347: RT: updating ospf 3.3.3.3/32 (0x0):

via 10.1.2.2 Et1/0

07:22:09.347: RT: closer admin distance for 3.3.3.3, flushing 1 routes

07:22:09.347: RT: add 3.3.3.3/32 via 10.1.2.2, ospf metric [110/120]

07:22:09.351: EvD: accum. penalty decayed to 0 after 83 second(s)

07:22:09.351: EvD: charge penalty 500, new accum. penalty 500, flap count 44

07:22:09.351: BGP(0): IPv4 Unicast::base nexthop modified, reuse in 00:00:19, 19000 , scheduling nexthop scan in 5 secs

07:22:09.351: EvD: accum. penalty decayed to 500 after 0 second(s)

07:22:09.351: EvD: charge penalty 500, new accum. penalty 1000, flap count 45

07:22:09.351: BGP(0): IPv4 Unicast::base nexthop modified, reuse in 00:00:27, 27000 , timer already running

* Although the penalty value has already exceeded 950 after the second addition, the next-hop scan is not rescheduled because it has already been scheduled.

07:22:09.351: EvD: accum. penalty decayed to 1000 after 0 second(s)

07:22:09.351: EvD: charge penalty 500, new accum. penalty 1500, flap count 46

07:22:09.351: BGP(0): IPv4 Unicast::base nexthop modified, reuse in 00:00:32, 32000 , timer already running

* Since the three target addresses have been updated simultaneously, the penalty value has ultimately increased to 1500.

R1#

07:22:14.367: BGP: BGP Event nhop timer

07:22:14.367: BGP: tbl IPv4 Unicast:base Nexthop walk

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

This dampening does not have much effect if IGP has converged at the time of the next-hop scan immediately after a route change event occurred. However, it may need to be investigated when a flap frequently occurs on the routes that next-hop uses.

The following is an example of intentionally causing successive flaps to 2.2.2.2/32.

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

09:01:28.423: RT: del 2.2.2.2 via 10.1.1.2, ospf metric [110/11]

09:01:28.423: RT: delete subnet route to 2.2.2.2/32

09:01:28.423: EvD: accum. penalty decayed to 0 after 3119 second(s)

09:01:28.423: EvD: charge penalty 500, new accum. penalty 500, flap count 8

09:01:28.423: BGP(0): IPv4 Unicast::base nexthop modified, reuse in 00:00:19, 19000 , scheduling nexthop scan in 5 secs

* For the first deletion of routes, the scan is scheduled in five seconds according to the default setting.

09:01:33.431: BGP: BGP Event nhop timer

09:01:33.431: BGP: tbl IPv4 Unicast:base Nexthop walk

09:01:33.435: RT: del 10.22.22.22 via 2.2.2.2, bgp metric [200/0]

09:01:33.435: RT: delete subnet route to 10.22.22.22/32

09:01:33.435: RT: del 10.222.222.222 via 2.2.2.2, bgp metric [200/0]

09:01:33.435: RT: delete subnet route to 10.222.222.222/32

* Since there is no valid route for 2.2.2.2 at the time of the next-hop scan, BGP routes that use 2.2.2.2 for the next-hop are deleted.

09:01:35.851: RT: updating ospf 2.2.2.2/32 (0x0):

via 10.1.1.2 Et0/0

09:01:35.851: RT: add 2.2.2.2/32 via 10.1.1.2, ospf metric [110/11]

09:01:35.855: EvD: accum. penalty decayed to 272 after 7 second(s) <--Indicates that seven seconds have passed since the previous event and the penalty value has decreased to 272

09:01:35.855: EvD: charge penalty 500, new accum. penalty 772, flap count 9

09:01:35.855: BGP(0): IPv4 Unicast::base nexthop modified, reuse in 00:00:24, 24000 , scheduling nexthop scan in 5 secs

* Penalty addition and next-hop scheduling are performed even when a route is added as shown above

* At this point, even after adding 500 the value is 772, which does not exceed 950; therefore, the scan is scheduled for five seconds later

09:01:40.863: BGP: BGP Event nhop timer

09:01:40.863: BGP: tbl IPv4 Unicast:base Nexthop walk

09:01:40.863: RT: updating bgp 10.22.22.22/32 (0x0):

via 2.2.2.2

09:01:40.863: RT: add 10.22.22.22/32 via 2.2.2.2, bgp metric [200/0]

09:01:40.863: RT: updating bgp 10.222.222.222/32 (0x0):

via 2.2.2.2

09:01:40.863: RT: add 10.222.222.222/32 via 2.2.2.2, bgp metric [200/0]

* Since there is a valid route for 2.2.2.2 at the time of the next-hop scan, BGP routes that use 2.2.2.2 for the next-hop are added.

09:01:40.939: RT: del 2.2.2.2 via 10.1.1.2, ospf metric [110/11]

09:01:40.939: RT: delete subnet route to 2.2.2.2/32

09:01:40.943: EvD: accum. penalty decayed to 500 after 5 second(s)

09:01:40.943: EvD: charge penalty 500, new accum. penalty 1000, flap count 10

09:01:40.943: BGP(0): IPv4 Unicast::base nexthop modified, reuse in 00:00:27, 27000 , scheduling nexthop scan in 27 secs

* The route is deleted again, then the penalty value after addition now exceeds 950. So instead of five seconds later,

* the next-hop scan is scheduled for 27 seconds later, when the penalty 1000 will be decreased to 100

R1#

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

All Devices Settings

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

!

hostname R1

!

interface Loopback0

ip address 1.1.1.1 255.255.255.255

!

interface Ethernet0/0

ip address 10.1.1.1 255.255.255.0

ip ospf cost 10

!

interface Ethernet1/0

ip address 10.1.2.1 255.255.255.0

ip ospf cost 100

!

router ospf 65000

network 1.1.1.1 0.0.0.0 area 0

network 10.1.0.0 0.0.255.255 area 0

!

router bgp 65000

bgp log-neighbor-changes

neighbor 2.2.2.2 remote-as 65000

neighbor 2.2.2.2 update-source Loopback0

!

end

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

!

hostname R2

!

interface Loopback0

ip address 2.2.2.2 255.255.255.255

!

interface Loopback22

ip address 10.22.22.22 255.255.255.255

!

interface Loopback222

ip address 10.222.222.222 255.255.255.255

!

interface Ethernet0/0

ip address 10.1.1.2 255.255.255.0

ip ospf cost 10

!

interface Ethernet1/0

ip address 10.1.2.2 255.255.255.0

ip ospf cost 100

!

interface Serial2/0

ip address 10.23.1.2 255.255.255.0

!

interface Serial3/0

ip address 10.24.1.2 255.255.255.0

!

router ospf 65000

redistribute static metric-type 1 subnets

network 2.2.2.2 0.0.0.0 area 0

network 10.1.0.0 0.0.255.255 area 0

!

router bgp 65000

bgp log-neighbor-changes

no bgp nexthop trigger enable

network 10.22.22.22 mask 255.255.255.255

network 10.222.222.222 mask 255.255.255.255

neighbor 1.1.1.1 remote-as 65000

neighbor 1.1.1.1 update-source Loopback0

neighbor 3.3.3.3 remote-as 65003

neighbor 3.3.3.3 ebgp-multihop 255

neighbor 3.3.3.3 update-source Loopback0

neighbor 4.4.4.4 remote-as 65004

neighbor 4.4.4.4 disable-connected-check

neighbor 4.4.4.4 update-source Loopback0

!

ip route 3.3.3.3 255.255.255.255 Serial2/0 10.23.1.3

ip route 4.4.4.4 255.255.255.255 Serial3/0 10.24.1.4

!

end

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

!

hostname R3

!

interface Loopback0

ip address 3.3.3.3 255.255.255.255

!

interface Ethernet0/0

ip address 172.20.1.3 255.255.255.0

!

interface Serial2/0

ip address 10.23.1.3 255.255.255.0

!

router bgp 65003

bgp log-neighbor-changes

network 172.20.1.0 mask 255.255.255.0

neighbor 2.2.2.2 remote-as 65000

neighbor 2.2.2.2 ebgp-multihop 255

neighbor 2.2.2.2 update-source Loopback0

!

ip route 2.2.2.2 255.255.255.255 Serial2/0 10.23.1.2

!

end

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

!

hostname R4

!

interface Loopback0

ip address 4.4.4.4 255.255.255.255

!

interface Ethernet0/0

ip address 192.168.1.4 255.255.255.0

!

interface Serial3/0

ip address 10.24.1.4 255.255.255.0

!

router bgp 65004

bgp log-neighbor-changes

network 192.168.1.0

neighbor 2.2.2.2 remote-as 65000

neighbor 2.2.2.2 disable-connected-check

neighbor 2.2.2.2 update-source Loopback0

!

ip route 2.2.2.2 255.255.255.255 Serial3/0 10.24.1.2

!

end

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

Related Information

Original Document: https://supportforums.cisco.com/ja/document/110226
Author: Tsuyoshi Niitani
Posted on August 15, 2012