The BGP next hop processing distinguishes iBGP from eBGP. A route advertised from an eBGP to another eBGP peer, the next hop address will be the address of the exit point of that AS. A route advertised from an eBGP to iBGP, the next-hop address remains unchanged when sent to another iBGP peer. It will not insert its own address as the next-hop address of the advertised route. The problem here is, what if that iBGP peer doesn’t know how to reach that eBGP address?
Let’s take this scenario.
Colletidae, a blellum lady living in the outskirt of Edinburgh, told her neighbor Apidae that Dasypoda is having an illegal affair with somebody else. Colletidae told Apidae that she can spread that in town. And, because Colletidae wants so much attention, she told her to tell everybody that she is the one who told her about it. Colletidae knows that everybody will believe Apidae as she is known to be an honest quine. Apidae cannot believe it and she told Andrena, sister of Andrenidae, about this.
“Don’t be such a wee clipe!”, said Andrena. “Are you the one spreading that rumor?”
“No, it’s not me. It’s Colletidae who told me about that.” Apidae replied.
When Andrena told her sister about this rumor,
“Who told you that?” Andrenidae asked
“Colletidae knows everything about Dasypoda’s affair,” Andrena whispered.
“Who is Colletidae?” Andrenidae asked.
Andrenidae, who is one of Dasypoda’s best friend, knows that it was her sister who told her about the affair rumor. What she didn’t know is that it was Apidae who told her sister about this and that Apidae knows where Colletidae lives.
This is true with partial mesh topology in iBGP. There is no route back to Colletidae.
With the use of next-hop-self command, it would force the iBGP speakers to advertise the route with the next hop address of its own.
Let’s do a simple lab about this scenario.
Let’s see what will happen after Dasypoda advertised its loopback address.
Enter configuration commands, one per line. End with CNTL/Z. Dasypoda(config)#router bgp 600 Dasypoda(config-router)#network 126.96.36.199 mask 255.255.255.0 Dasypoda(config-router)#end
After Dasypoda advertised its loopback address, Colletidae learned it and install it in its routing table:
As you can see, the next hop address is Dasypoda’s IP, 10.0.60.6. Let’s see what happened when it is learned by Apidae.
Since it is still an eBGP peer, there should be no issue as the next hop address is changed to Colletidae’s IP, 10.0.30.3. However, what will happen when Apidae advertised to an iBGP peer?
We can see that Andrena learned the 188.8.131.52 network via 2 ways: 10.0.30.3 and 10.0.20.4. We will talk about the second route, 10.0.20.4 as we go to the AS Path. This is another BGP attribute that needs to be discussed on separate page. For now, let’s focus on 10.0.30.3 as this was shared via iBGP peer.
The 10.0.30.3 is Colletidae’s IP. So Apidae clearly doesn’t change the next hop address. This is the iBGP next hop processing rule. This is a problem if we have a partial mesh topology and once Andrena doesn’t know how to route traffic back to 10.0.30.3.
Now, let us apply the next-hop-self command so Apidae will be forced to insert its own IP address as the next hop address for 184.108.40.206 network:
Apidae(config)#router bgp 65500 Apidae(config-router)#neighb 10.0.10.2 next-hop-self Apidae(config-router)#end Andrena(config)#router bgp 65500 Andrena(config-router)#neigh 10.0.10.1 next-hop-self Andrena(config-router)#end Andrena#
Let us examine Andrena’s routing table:
It is now showing Apidae’s IP, 10.0.10.1, after issuing the next-hop-self command on this two iBGP speakers.