BGP Next Hop Self

ziyad.barqawi · January 16, 2021, 9:40am

ok let me show you what i have done :

first here is the same topology:

11886×499 64 KB
and you are correct as you mentioned “iBGP doesn’t change the next hop IP address when it advertises a route it learns via eBGP” and here is the output confirming this:

21916×820 83.5 KB

and here i can learn that the vise verse is different : eBGP change the next hop ip address when it advertises a route it learns via iBGP which means R02 advertises 1.1.1.1 to R03 and it changed the next hop ip to its ip address which is 192.168.23.1.
lets now configure neighbor 192.168.12.1 next-hop-self under R02 and see what will happen:

31882×818 72 KB

all looks good after configuring neighbor 192.168.12.1 next-hop-self under R02 , R02 has changed the next hop to its ip before advertising 3.3.3.3 to R01 and R01 was able to install 3.3.3.3 in its routing table as its knowing how to reach to 3.3.3.3 by using the next hop 192.168.12.2.

lets try to ping 3.3.3.3 from R01 , and during this i will run debug ip icmp in both R01 and R03 and lets see the outputs:

41870×710 61.6 KB

ping is dropped because in the echo msg R03 dropped the packet beacuse it dosent have route for 192.168.12.1.

so i tried also to ping 1.1.1.1 from R03 and same result i got , R01 dropped echo msg :

51708×253 16.2 KB
i tried to ping again but i changed the source ip in R01 and it works:

61866×334 25.9 KB
i have advertised 192.168.12.0/30 and 192.168.23.0/30 in R02 and then i was able to ping all ips:

71916×1012 104 KB

and now am ok with all pings:

and in the last i would like to thank you for your time

lagapidis · January 17, 2021, 11:06am

Hello Ziad

That was an excellent and detailed description of your configuration and the steps you took to resolve it. Thanks for sharing that with us!

Laz

ziyad.barqawi · January 17, 2021, 2:52pm

Its my pleasure and am happy to hear that , Thanks Mr.Laz for your time and always support

Networkteam · February 10, 2021, 5:38pm

@lagapidis can you please confirm that if 3rd statement is correct?
Learned from iBGP → Advertise to iBGP → “Next-hop-self all” required

As IBGP learned routes will not be advertised to another IBGP neighbor ?

Also when advertising eBGP routes to RR is next-hop self required or not ?

lagapidis · February 13, 2021, 11:03am

Hello Tejas

The next-hop-self all command and keyword are used in order for the next hop of both eBGP and iBGP learned routes is updated by the route reflector. This command will not affect the way in which plain iBGP neighbors operate. You can see more info about this at the following Cisco command reference:

I hope this has been helpful!

Laz

narad · July 20, 2021, 8:39pm

why routes shows the valid(*) in your lab ??..It should show you as RIB failure .correct Me…!!

What are the possibilities of RIB failure ?

lagapidis · September 4, 2021, 5:12am

Hello Narad

In the lab, if you don’t use the next-hop-self feature, then R1 will still receive the information about the 3.3.3.0/24 prefix, so the route is considered valid. However, it is not placed in the routing table because the next-hop IP for that route is not in its local routing table. Remember, a BGP route will only be installed in the routing table if its next hop IP attribute is in the routing table.

I hope this has been helpful!

Laz

ruben.trazanet · January 15, 2022, 11:37pm

Hi Laz,

I hope all of you are doing well
QQ: Is there any incompatibility between Route reflector and Next-hop-self attributes? I am trying to configure RR1 as route reflector for RC2 & RC3 (Clients). The loop back addresses are advertised by RR1, however they are not installed into the routing table because a reachability issue. The next hop attribute doesn’t change in RC3 or RC2 despite I have configured next-hop-self for both neighbours in RR1

RR1#show run | s bgp
router bgp 65100
 bgp log-neighbor-changes
 neighbor 12.12.12.2 remote-as 65100
 neighbor 12.12.12.2 route-reflector-client
 neighbor 12.12.12.2 next-hop-self
 neighbor 13.13.13.3 remote-as 65100
 neighbor 13.13.13.3 route-reflector-client
 neighbor 13.13.13.3 next-hop-self
 neighbor 14.14.14.4 remote-as 65100
 neighbor 17.17.17.7 remote-as 65100
RR1#show ip bgp
BGP table version is 15, local router ID is 17.17.17.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
*>i2.2.2.2/32       12.12.12.2               0    100      0 i
*>i3.3.3.3/32       13.13.13.3               0    100      0 i



RC3(config)#do show run | s bgp
router bgp 65100
 bgp log-neighbor-changes
 network 3.3.3.3 mask 255.255.255.255
 neighbor 13.13.13.1 remote-as 65100
RC3(config)#
RC3(config)#
RC3(config)#do show ip bgp
BGP table version is 5, local router ID is 3.3.3.3
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
* i2.2.2.2/32       12.12.12.2               0    100      0 i
*> 3.3.3.3/32       0.0.0.0                  0         32768 i

RC2#show run | s bgp
router bgp 65100
 bgp log-neighbor-changes
 network 2.2.2.2 mask 255.255.255.255
 neighbor 12.12.12.1 remote-as 65100
RC2#
RC2#show ip bgp
BGP table version is 2, local router ID is 2.2.2.2
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
*> 2.2.2.2/32       0.0.0.0                  0         32768 i
* i3.3.3.3/32       13.13.13.3               0    100      0 i

Any suggestions?

Regards

trazanetsl

lagapidis · January 18, 2022, 6:12am

Hello Ruben

It seems that this is normal behavior. This Cisco BGP documentation states the following:

Do not use the neighbor next-hop-self command to modify the next hop attribute for an RR. Using the neighbor next-hop-self command on the RR will modify next hop attributes only for non-reflected routes and not the intended routes that are being reflected from the RR clients. To modify the next hop attribute when reflecting a route, use an outbound route map.

However, in this Cisco command reference of the neighbor next-hop-self command, you can override this behavior using the optional all keyword in the command, so that the reflected routes will also have the next hop modified.

I hope this has been helpful!

Laz

ruben.trazanet · January 18, 2022, 8:27am

Hi Laz,

Thank you for the explanation. I will test it in my lab. I am preparing CCIE enterprise Lab exam.
QQ: Is the course published in Networklesson for preparing the above mentioned exam updated? Have you any recommendations I should be aware of or sites that might help during the preparation?

BTW.

Thank you

Ruben

lagapidis · January 20, 2022, 6:37am

Hello Ruben

The content on the site is designed to help you prepare for the specific CCIE exam, and yes, it has been updated to match as much as possible the content and topics of the current lab exam. It’s always a good idea to supplement this studying with additional resources if you have time. One of the most important things is to gain experience in labbing. Do as many labs as possible, on as many topics as possible. Obviously do the labs on Networklessons, but also take advantage of those that are provided by the official Cisco CCIE training content, as well as sites such as INE.

I hope this has been helpful!

Laz

ruben.trazanet · January 25, 2022, 10:13am

Hi Lazaros,

Thanks for your response and suggestions. I will carry on doing the strategy you mentioned …labs labs labs. I already had a look at INE.

Thanks again for your help.

Regards

Ruben

hemanttolwani1989 · June 12, 2023, 9:37am

What is the difference between Next Hop Self and Update Source in BGP ?

lagapidis · June 13, 2023, 10:43am

Hello Hemant

The next-hop-self feature causes a BGP router to advertise itself as the next hop for routes advertised to a particular neighbor. This causes the BGP table of the neighboring router to use the IP of the advertising router (and not that of the originating router) as the next hop IP. Keep in mind, as stated in the lesson, this is commonly used by iBGP routers when advertising a route they learned from an eBGP neighbor.

The update source feature is used to specify which IP address/interface will be used for the establishment and subsequent communication between BGP peers. This is particularly useful when configuring a loopback address as the source for the exchange of BGP messages with its peers, as shown in the second topology described in the eBGP multihop topology in the following lesson:

I hope this has been helpful!

Laz

davidilles · June 27, 2023, 1:04pm

Hello!

Are there any situations where leaving the default BGP setting / not issuing the next-hop-self command might be useful?

lagapidis · June 30, 2023, 5:14am

Hello David

The default behavior of BGP concerning the next hop IP address is typically the behavior that you want to have in most BGP topologies. The next-hop-self feature should only be used as an exception to the rule under very specific circumstances.

When a BGP speaker receives an update from an eBGP peer (a peer in a different AS), by default, it changes the NEXT_HOP attribute to the IP address of the neighboring router used to establish the BGP session. This is because routers in different ASes are typically directly connected, and the expectation is that the next hop to an external network is the IP address of the neighboring router.

On the other hand, when the BGP speaker receives an update from an iBGP peer (a peer in the same AS), it does not change the NEXT_HOP attribute. This is because the iBGP speakers within the same AS are often not directly connected and may be multiple hops away. Preserving the NEXT_HOP attribute ensures that the packet will be forwarded along the best path to the original eBGP entry point into the AS, and not to an intermediate iBGP peer.

If the NEXT_HOP attribute was updated by iBGP peers in the same way as eBGP, it could cause a routing loop within the AS. For example, suppose Router A receives an update from an eBGP peer and sets the next hop to its own IP. It then sends this update to Router B, an iBGP peer, which sets the next hop to its own IP. Router A would then receive the update from Router B and, seeing a path to itself, potentially set the next hop to Router B, creating a routing loop.

So in most cases, you wouldn’t use the next-hop-self feature. The “next-hop-self” feature is used in BGP configurations to handle scenarios where the next-hop address isn’t reachable for certain routers in the network. This is often the case in iBGP topologies where not all routers are fully meshed, or in networks where not all routers are running BGP.

I hope this has been helpful!

Laz

sainikhhel66 · September 18, 2023, 1:42pm

Hi rene,
i have a doubt regarding the next hop self feature. let’s say there are four routers in single AS (iBGP) and one router in another AS (eBGP peering). the next hop self-command to the second router from the first router updates the exact next hop in the ibgp(since it is dorectly connected). the next hop-self command to the 3rd and the 4th router works fine with the respective next hop command. My question is for the second router the next hop gets updated which makes sense as it is directly connected. however, how does the exact next hop get updated for the 3rd and 4th router, even though they are not connected and how does the 1st router know the exact next hop to send the advertisements to the 3rd and 4th router?
can i please have a detailed explanation on this.

Thanks!

lagapidis · September 21, 2023, 7:05am

Hello Sai

So based on your description, we’re looking at a topology similar to this:

Under normal circumstances, without any additional configuration, R5 would send an eBGP update to R4 with the 6.6.6.6/32 network, and would send a next hop IP address of 192.168.46.6, which is the IP address of R5. When R4 shares that network with the rest of its iBGP peers in AS 12345, it will advertise it with a next hop of 192.168.46.6. This will be advertised to R1, R2, and R3 directly. Now in order to understand the dynamics of these advertisements, you must remember two things:

iBGP peerings in an AS are full mesh. That means that R4 will directly send a BGP update to R3, R2 and R1. The update is not relayed from router to router.
Secondly, remember that within an AS, iBGP will not advertise a route it learned from one iBGP peer to any other iBGP peers. This is the BGP split horizon rule.

This means that R1, R2, and R3 will receive the BGP update about the 6.6.6.6/32 network, and will all have a next hop IP of 192.168.46.6. The result is that none of these routers know how to get to this next hop IP, so routing fails. To solve this, R4 can be configured with the next hop self feature, so that when it advertises the route to the other iBGP peers, it will use its own IP address of 192.168.24.4 as the next hop. Does that make sense?

I hope this has been helpful!

Laz