BGP Next Hop Address Tracking

Hello Curtis

Debug commands are structured in supersets and subsets. This means that you can either choose to debug a wider range of messages, or a more specific range of messages depending on how you implement the command.

The debug ip bgp events command will indeed give you the BGP scanner messages because this command includes all the syslog messages included under the subcategory “events”. However, if you use the debug ip bgp command, you debug for a wider range of syslog messages. Notice the following:

R3#debug ip bgp ?
  A.B.C.D            BGP neighbor address
  addpath            BGP additional path events
  all                All address families
  bmp                BGP BMP
  dampening          BGP dampening
  diversepath        BGP diverse path events
  events             BGP events
  groups             BGP Config (peer-groups, templates) and Update groups
  igp-metric ignore  BGP igp-metric ignore events
  import             BGP path import across topologies, VRFs or AFs
  in                 BGP Inbound information
  internal           BGP internal
  ipv4               Address family
  ipv6               Address family
  keepalives         BGP keepalives
  l2vpn              Address family
  mpls               BGP MPLS label distribution
  nsap               Address family
  out                BGP Outbound information
  range              BGP dynamic range
  rib-filter         Next hop route watch filter events
  route-server       BGP route server
  rtfilter           Address family
  topology           Routing topology instance
  trace              BGP debug message trace setup
  updates            BGP updates
  vpnv4              Address family
  vpnv6              Address family
  <cr>

By simply issuing the debug ip bgp command, debug messages will appear for all of the shown categories, including events.

In a production network, it is advisable to use the more specific debug commands, in order to alleviate any unnecessary strain on CPU and memory resources of a router or switch, so using the debug ip bgp events command would be preferable. However, because there are no such conditions in a lab, the debug ip bgp command will also do.

I hope this has been helpful! Stay healthy and safe!

Laz

Hello Tanmoy

I apologize, I wasn’t clear. The scan time will be reduced from whatever it was at that particular moment, to 5 seconds. For example, let’s say the scan time was counting down and it was at 47. At that particular time, a next hop IP that happens to be in the BGP table, was removed from the routing table. The scan time will automatically go down to 5 seconds. In other words, the next BGP next hop scan will occur in 5 seconds from that moment.

Yes, that is correct. The next hop address tracking simply speeds up the detection of failed next hops. Once the detection is done, regular BGP and IGP mechanisms find the new next hop.

Yes that is correct.

I hope this has been helpful! Stay healthy and safe!

Laz

Hi Laz,

That’s great. Thanks for you reply…

Stay healthy and safe!

Tanmoy

1 Like

Hi Rene,
Very good explanation on BGP NHT and PIC. Wanted to see if its possible for you to add more topics in BGP convergence such as ORF,maximum prefixes,Fast external failover,BFD,Graceful restart

When I read about NHT I understand it speeds up the convergence as default is 60 seconds. However, when we use dampening then the next hop scanner is delayed. Let us assume a routes keeps on flapping then the next hop tracking will get delayed a lot. So this wouldn’t defeat the purpose of NHT or its like with NHT getting delayed with route getting suppressed as well?

Hello Ravi

Thanks for your suggestions. I’ll let @ReneMolenaar know so he can add them to his to do list…

The purpose of next hop address tracking is to speed up convergence in a very specific scenario. It speeds up the next hop scan process that BGP employs.

The BGP table has a list of prefixes with a next hop IP for each. BGP will scan the routing table every 60 seconds to verify that those next hop IPs are indeed still in the routing table. When the NHT is enabled, if a next hop IP is removed from the routing table for whatever reason, the scan does not wait for the 60 seconds to expire, but is schedules to take place 5 seconds from the time the route has been removed.

Dampening is employed in order to protect a routing topology from the havoc that a flapping route can cause. If NHT is configured, and there is no dampening, and there is a flapping route, then the whole topology can get flooded by BGP updates. This can cause the whole network to fail.

Yes, if dampening causes the delay to continually increase, then we are defeating the purpose of NHT. But this is necessary in the event of flapping, because if dampening wasn’t employed, the whole network would fail.

In such a case, we may employ NHT to improve convergence, only to make things worse. So this is a failsafe that will avoid the destructive results of a flapping route and NHT.

If routes don’t flap, then NHT will function very well and will drastically improve convergence in the event of a topology change.

I hope this has been helpful!

Laz

Hello
What is the maximum penalty that a flapping route can get?
Regards
Sai

Hi Rene / Laz,

When performing this Lab, I am confused with the topic 1.2. Dampening
So if i understand Dampening will only come in effect after the penalty crosses 950.

And I believe at that point Next Hop Tracking is rescheduled till the penalty reaches 100. Lets say that time is 30 secs.

My question is, if the route keep on flapping and the penalty keeps on increasing does the timer reset again? if yes, when will it reset? Will it wait for 30 secs and then check the penalty and reschedule it.

Thanks in advance for your response.

Hi Rene,

can you give me some explanation about BGP Path Hunting and CLUSER LIST LENGTH in BGP

Hello Justin

Actually, if the penalty is greater than 950, the next hop tracking will never scan again until the penalty decreases below 100. However, there is a maximum suppress time of 60, which means that the maximum amount of time that scanning can be delayed is 60 seconds.

So if a route is flapping frequently enough so that the penalty remains greater than 100 for a long time, the longest that this can take place for is 60 seconds. Once the 60 seconds are up, the scan will take place again, only once, the timer will be reset, and the penalties will kick in again.

In actuality, the formula used to calculate these values is quite complicated. You can also think about it this way. On average, it turns out that on average, the penalty value decreases to approximately 92% of its previous value every second. Every time there is another change in the first hop, 500 is added to the penalty value. If it remains above 100 for more than 60 seconds, a scan takes place, and the timer is reset.

I hope this has been helpful!

Laz

Hello Ravi

BGP Path Hunting is just another name for BGP’s method of operation. When a path is withdrawn by a remote router or AS, BGP on the local router will “hunt” for another path in its attempt at reconverging. BGPs path hunting behaviour has been a topic of study for many, and it involves various phenomena including situations in which in a particular topology, only a single flap of a prefix can cause the dropping of traffic for extended periods of time. Others have found topologies that would cause a complete withdrawal of a prefix if a single link were to go down. All of these are associated with next hop tracking and dampening of flapping routes.

BGP mechanisms and topologies can get so complex and interesting, that they are been studied as if a living organism. By doing a search in your favourite search engine, you will find several academic papers on BGP path hunting, and the problems that they depict as well as their proposed solutions.

As for cluster list length in BGP, take a look at the following lesson which includes this concept:


I hope this has been helpful!

Laz

1 Like

If the default hold down timer is 180sec, In that case lets say i have enabled the NHT and if my next hop will be unreachable then my route will be removed immediately instead of waiting for 180sec…Right ?

Hello Narad

The BGP hold timer is used for neighbor adjacency states, and not for the validity of particular routes in the BGP table. This hold timer, which indeed is initially set to 180 seconds, is involved in maintaining BGP peerings. Every time a keepalive or update message is received, the hold timer is reset. If the hold timer is exhausted without any messages, then the BGP neighbor peering is torn down. More info on this process can be found in the following lesson:

The concept of a hold-down timer is something used by IGPs. BGP does not use such a timer for the validity of BGP routes. Instead, it performs a scan every 60 seconds. It scans all of the next-hop IPs found in its BGP table to see if they are reachable. Specifically, it checks to see if the local routing table has a route that serves those next hop IPs.

Now under normal circumstances, this scan will take place every 60 seconds. So if the route to a particular next hop of a BGP route is removed from the local routing table, it may take up to 60 seconds for the BGP process to realize it.

Next hop address tracking, as stated in the lesson, is event-based. This means that if there is a change in the routing table, BGP is instructed to schedule a next-hop scan in 5 seconds. The process is then further described in the lesson.

I hope this has been helpful!

Laz

I think there is a mistake in the conclusion:
Next hop tracking increases BGP convergence time by checking changes to next hops in the routing table.

I think it decreases convergence time

I also have a query:
To make next-hop unreachable you were performing shut/no-shut on loopback 0 interface on R3. The same loopback interface is used as update-source on R3 for BGP neighborship. We also see the route still in the BGP table and the reason mentioned in the article is:
We still see 3.3.3.3 as a next hop in the BGP table. That’s because the BGP hold-down timer hasn’t expired yet.

Query:
Do we not have any inbuilt mechanism in BGP where it immediately tells the neighbour to bring down the neighborship as soon as its own update-source goes down?

I think this can be done with BFD but I am curious whether BGP has anything in built to deal with such case.

Hello Muhammad

Yes, you are correct. I will let @ReneMolenaar know to make the correction.

One thing you can do is adjust the timers such that BGP will converge faster. The keepalive timer by default is 60 seconds, while the hold-down timer is 3x that, at 180 seconds. You can change these values using the timers keyword on the neighbor command. Note the following:

  • The timers can be applied to an accuracy of one second, so sub-second convergence is not possible.
  • When the timer values are different on two BGP peers, the lowest timer is used.

If you want to get faster convergence, you can use BFD of course, and you can find out more about BFD for BGP here:

However, you should keep in mind that BGP was not designed to be a routing protocol with quick convergence. It is actually designed to be slower in its convergence. As a result, trying to get it to converge quickly is likely to cause unwanted effects such as route flapping. This is why if you configure the hold time at a value of less than 20 seconds, the following warning will appear on the Cisco IOS CLI:

% Warning: A hold time of less than 20 seconds increases the chances of peer flapping

If you want to ensure correct routing in the event that a BGP route fails, it is preferable to use features such as additional paths and multipath load sharing which deliver redundancy, rather than sub-second reconvergence of BGP.

I hope this has been helpful!

Laz

HI,

There is any chance to change the BGP scanner times? if possible how we can change

Hello Balakrishna

Yes, it is possible to change the scanning interval of BGP routers for next-hop address tracking. This can be done using the bgp scan-time command. This is applied under the BGP router configuration. The range of values can be between 5 and 60 seconds. You can find out more information about this particular command at the following Cisco Command Reference:

https://www.cisco.com/c/en/us/td/docs/ios/iproute_bgp/command/reference/irg_book/irg_bgp1.html#wp1116049

For Cisco IOS 15.X versions, the minimum scan time has been increased from 5 to 15 seconds.

I hope this has been helpful!

Laz

“The penalty decreases by half every 8 seconds. If the current penalty is 2000 then 8 seconds later, it will be 1000. Another 8 seconds later, it will be 500. These parameters cannot be configured.”

Is this a typo? because you have a whole lesson dedicated to changing bgp dampening parameters.

Hello Dartagnan

The dampening that is described in this lesson is specific to the next hop tracking feature. The dampening here deals with a flapping next hop IP address. That is, the IGP being used continuously installs and uninstalls the next hop IP in the routing table. When that happens, the frequency with which the next hop scanning occurs is dampened. The parameters of this dampening are hardwired and cannot be changed.

BGP route dampening however, is another feature. This involves the installation and uninstallation of a BGP route. Every time this happens, a BGP update is sent, and this update has to be processed and responded to by BGP peers. This can cause disruption and instability in a BGP topology. BGP route dampening is involved in maintaining network stability when there is such an instability in the topology.

The difference between the two is somewhat nuanced, but each feature deals with a different aspect of BGP. Does that make sense?

I hope this has been helpful!

Laz