A post was merged into an existing topic: BGP Next Hop Self
Hello, everyone.
With eBGP Multi-Hop, a default route cannot be used to reach the next-hop, right? The routers will refuse to establish the BGP neighborship.
I’ve done some research about this and also asked on Cisco forums and figured out the following information:
- This is not officially part of the standard, it’s just a security feature implemented by Cisco.
- The logic goes that they don’t want you to use a default route to open the TCP connection because it’s an indication of bad design and opens up the potential for recursive routing problems.
This recursive routing part, imagine that two routers R1 - R3 are peering over a default route.
Imagine that R1 is peering with R3 (192.168.23.3) and is using a default route to establish the peering.
If the peering really was established and we configured R3 to advertise 192.168.23.0/24 (or any other route that would include R3) into BGP, the routing table would look like this on R1:
S - 0.0.0.0 - via R2
B - 192.168.23.0/24 - via 192.168.23.3 (R3)
Now, we would be literally using what we have learned from the BGP session to establish the session itself, it gets confusing.
Now imagine that R3 advertises another network, like 3.3.3.3/32 and now the routing table on R1 looks like this:
S - 0.0.0.0 - via R2
B - 192.168.23.0/24 - via 192.168.23.3 (R3)
B - 3.3.3.3/32 - via 192.168.23.3
BGP requires a two-step process when validating which route to use
- You must find the right BGP route
- You must validate the next hop for that route via a static route or an IGP
At this point, if a packet for 3.3.3.3 arrives, it matches this route:
B - 3.3.3.3/32 - via 192.168.23.3
BGP then needs to find out where 192.168.23.3 is, that is matched by this route
B - 192.168.23.0/24 - via 192.168.23.3 (R3)
BGP still needs to find out where 192.168.23.3 is and it will be forever matched by the 192.168.23.0/24 BGP route and we’ll have a recursive routing error/loop, right?
Do I understand this right?
Funny thing is, this only forces the active connection to use a non-default route but allows the passive side to use it.
Since a common, innocuous enough use case for peering over a default route is the case of a CE with a static default route upstream but where the CE has a public IP, so whatever eBGP peer it’s connecting to, more likely than not, has a specific route pointing at the CE.
David
Hello David
Your description is excellent, and elegantly describes the types of difficulties that can arise if the default route were allowed to be used to create BGP peerings.
Let’s say it another way. Even if Cisco allowed the default route for the session, the recursive loop you described would not necessarily persist, because the BGP next-hop validation would fail. A recursive resolution of B - 192.168.23.0/24 - via 192.168.23.3 would be detected by the router and rejected as inaccessible, preventing installation into the forwarding table in the first place. But Cisco (and other vendors that implement this behavior) simply avoids the entire situation by requiring explicit reachability to the neighbor.
Even if a TCP session for peering were established because the passive side — but not the active side — is using a default route, route installation will still fail for the reasons already described. BGP’s next-hop validation will reject routes whose next-hop creates recursion.
So the RFC-based BGP behavior would reject routes learned over such a peering, but Cisco takes one step further, and ensures that such a peering would not be established in the first place.
I hope this has been helpful!
Laz