BGP Next Hop Address Tracking

Hello Zaman

Remember that a BGP neighbourship can be formed between two BGP routers even if they are not directly connected. The only prerequisite is that there is adequate routing between them (using IGPs) so that they can exchange BGP information. So, even in that case, if the routing table of a BGP router changes and the route to the other BGP router becomes unavailable, the change in the routing table will take place which will indeed trigger the BGP next hop tracking mechanism.

I hope this has been helpful!

Laz

hi to everybody
i dont understand the topology .How did you connect them, use the switch ?

Hello Bahri

I assume it is this topology that you are talking about:
image
Essentially, the three routers are connected not as a point to point connection (obviously, since there are more than two interconnected devices), but as a multiple access network. This multiple access network can be interconnected by switches or any number of layer two devices. So in between the three routers there can indeed be a switch or any number of switches interconnecting these routers within a single subnet/network segment.

The switch was left out of the topology for simplicity’s sake…

I hope this has been helpful!

Laz

hi
I have same question as Zaman, please help answer the question.

Thank you

Hello Hoan

It seems that Zaman’s question above was responded to. If you have any more specific question, please share it with us.

Laz

Hi Rene,

I have Problems with that.
2 Inside Routers form iBGP over EIGRP(announcing Loopback). EIGRP is running between the Routers on their HSRP addresses:
Router 1 10.10.10.1
HSRP VIP 10.10.10.2
Router 2 10.10.10.3
–> forming EIGRP 10.10.10.1<->10.10.10.3 and Advertising Loopbacks for BGP
All good so far.
Every Router is connected to ISP(same AS but does not matter here) which give a default route only to each inside Router.
That means both inside Routers have default to ISP, but when 1 inside Router chrashes, BGP is not deleted between inside Routers. EIGRP is removed and route to Loopback of other router also, but then they try to reach iBGP neighbor via ISP of Course.

Hi Alexander,

If you use private IP addresses on your network then in this case, traffic could match your default route and is forwarded to the ISP. They’ll drop it though since they don’t route private IP addresses.

If you want to prevent this, you could configure some null0 routes for your private ranges. When the router doesn’t have a more specific entry, it will drop the traffic instead of using the default route.

Rene

So I have to define a static route for bgp-used loopbacks with administrative distance worse than eigrp and point it to Null0?

Hello Alexander

Yes, I believe your description would would indeed provide the desired result.

Laz

1 Like

Hello,

I don’t understand why R1 chooses R3 as next-hop in the first place. R2 has a lower router ID (2.2.2.2) and all BGP attributes are the same.

Also I saw that R3 has not been configured to neighbor with R2. Is this intended or perhaps there is no need for full IBGP adjacency for this lesson?

Many thanks,
Stefanita

Hi Stefanita,

For this example, the iBGP adjacency between R2 and R3 isn’t required but to follow best practices, it should be there :slight_smile: It seems I added it for R2 but not for R3. It’s fixed now.

About the path selection, when everything is equal then it’s the oldest path that is selected. That could be R2 or R3, depending on which neighbor adjacency comes up first.

Rene

1 Like

My bad. Indeed oldest path is selected before router ID. :slight_smile: Many thanks Rene!

1 Like

Hi Rene ,
My question is that Next hop tracking is enable by default on every IOS ?
my second question is that is this work similarly like BFD ?

Kindly clarify my above questions …

Many Thanks!

Hello Tanmoy

According to this Cisco documentation, the next hop tracking is enabled by default for all versions of IOS. In addition it says:

BGP next-hop address tracking is enabled by default for IPv4 and VPNv4 address families. It is also enabled by default for the VPNv6 address family as of Cisco IOS Release 12.2(33)SB6.

Concerning BFD, there is a difference between functionality and what is actually being detected.

Next Hop Address Tracking will cause a BGP peer to preemptively remove a route from the BGP table if the next hop of that route is no longer in the routing table. Once the next hop IP is removed from the routing table, a next hop scan is initiated after 5 seconds, by default. This can be changed to 0 so that the scan occurs immediately.

BFD works differently. It creates BFD peerings between routers. BFD will send hello packets at sub-second intervals to make sure the neighbors are “alive”. If a BGP neighbor is no longer available, the BGP protocol immediately considers the neighbor down, and subsequently all routes learned from that neighbor must be reconverged,.

What’s the difference? The first is triggered by a change in the routing table, which itself is a process that may take several seconds, or tens of seconds depending on the actual failure and the underlying IGP being used. The second is triggered by a failure in BGP neighborship and “realization” of the changes are much more immediate.

So the two processes actually detect something different. You can have a neighbor fail without having the next hop fail, or vice versa.

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

Laz

Hi Laz ,
Thanks for you response
So , here is the summary that I understand so far
Next Hop Tracking : Tracking of the next hop to reach the destination prefix , if next hop down the scan time will start after 5 seconds to find the optimal or available next hop & will install routing table accordingly.
BFD : It will detects the failure of neighbor by using BFD ECHO & reply message.

Please correct me if I wrong.

Hello Tanmoy

For next hop tracking, this is the process that is followed:

  1. Every 60 seconds, BGP scans the next hop addresses of all routes in the BGP table. If successful, everything remains the same. If it fails, any routes in the BGP table with a failed next hop will be removed, and BGP reconvergence begins.
  2. If the next hop of a particular BGP entry is removed from the routing table (for whatever reason such as failure, manual removal etc) then the scan time timer is reduced to 5 seconds, and when this expires, the scan takes place. Simultaneously, if an IGP is configured, it will begin reconvergence depending on how it has been configured.
  3. If the scan finds that the next hop address is no longer available, the route is removed from the BGP table
  4. BGP will begin the reconvergence process based on how it is configured.

Note here that the scan does not find the optimal next hop. The scan simply detects failed next hop addresses. It is the IGP and BGP that reconverge to find the best alternative route.

Yes, this is correct.

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

Laz

Hi, I believe there may be an error with the following, as the “#debug ip bgp events” command is what allows me to view the BGP 60 second Scanner within my labs:

R1#debug ip bgp
*BGP debugging is on for address family: IPv4 Unicast *
You will see the following messages:

R1#
*Apr 9 09:56:53.743: BGP: topo global:IPv4 Unicast:base Scanning routing tables
*Apr 9 09:56:53.744: BGP: topo global:IPv4 Multicast:base Scanning routing tables
*Apr 9 09:56:53.746: BGP: topo global:L2VPN E-VPN:base Scanning routing tables
*Apr 9 09:56:53.747: BGP: topo global:MVPNv4 Unicast:base Scanning routing tables

*Apr 9 09:57:53.754: BGP: topo global:IPv4 Unicast:base Scanning routing tables
*Apr 9 09:57:53.757: BGP: topo global:IPv4 Multicast:base Scanning routing tables
*Apr 9 09:57:53.758: BGP: topo global:L2VPN E-VPN:base Scanning routing tables
*Apr 9 09:57:53.759: BGP: topo global:MVPNv4 Unicast:base Scanning routing tables

Thanks Laz for the response here.
2.If the next hop of a particular BGP entry is removed from the routing table (for whatever reason such as failure, manual removal etc) then the scan time timer is reduced to 5 – that means 60-5 seconds ? = 55 seconds ?
so its IGP and BGP responsibility to find the next hop or best alternative route.
if I configure max-paths with particular neighbor , then both primary & back up path will be installed in routing table … in that case convergence will works fast ?/

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