Hi Guys - simple question… why does Cisco recommend that eBGP neighbors are directly connected? Is there a design reason for this? Thanks - Gareth.
Hello Gareth
The main issue here has to do with control. If you have two AS’es and you configure one BGP router from each to become eBGP peers, then what happens on the network between them is important. If they are directly connected, then that means that you control the network fully from AS to AS down to the physical level. If they are several hops away, it may be that the “in between” network is not under your jurisdiction, and you are running over a third party network. Or even if it is your network, the sharing of your thousands of BGP prefixes depend directly on the stability of that network. In either case, you are adding unknowns, variables, multiple points of failure that can impact your BGP routing.
Remember that if you are configuring AS’es and interconnecting them using eBGP, it is highly likely that your network is supporting hundreds or even thousands of users using mission critical services for their businesses. Having your eBGP routers directly connected goes a long way in ensuring high availability and robustness of your network.
A similar question was asked above, and the following answer to that question may shed some additional light on the subject.
I hope this has been helpful!
Laz
Very helpful Laz - thanks. This makes sense.
Is there anything to ensure that there aren’t a multitude of layer 2 devices between BGP neighbors as they too could introduce unknown variables into the high availability equation?
Hello Gareth
It is inevitable that you will have some L2 devices between your eBGP neighbors, depending on your network layout and design. The important thing here is not necessarily to limit them, but to implement them such that there is sufficient redundancy. Within the core of your L2 infrastructure it is useful to use features such as etherchannel, vPCs, and VSS (as well as STP, and switch stacking to a lesser extent, and closer to your access network) to ensure L2 redundancy and robustness. If this is done to a sufficient degree, then BGP neighbors can form safely and securely over your L2 infrastructure.
I hope this has been helpful!
Laz
1 Like
Hi,
After completing the lab, I entered the command no neighbor x.x.x.x ebgp-multihop 2 on both routers,
what would be the result of that?
Hello Juan
When you tried it in your topology, what happened?
I can tell you what I believe should happen. For both lab setups in the lesson, if you removed the multihop command, BGP would no longer be able to communicate between the two BGP peers. It would take a while for the BGP peering to be disabled since BGP is slow to converge (it should take several minutes at least). This is because BGP packets will start to be exchanged with a TTL of one, thus they won’t be able to reach the BGP peer which is more than one hop away.
Let us know your results!
I hope this has been helpful!
Laz
Hii Rene,
Please clarify my doubts in your second example.
we connected 2 links b/w 2 routers and used loopback interfaces for neighbor relationship.
In this example. neighbor will also established without using ebgp-multihop 2 comand. just by disabling connection check command. am i right? please correct me if i am wrong.
in this example. if we enable disable connection check then router will know that both loopbacks are not in same subnet so it wont establish neighbour. so to resolve this we are using ebgp-multihop 2 command.
Hiii Rene.
in sewcond example command ebgp-multihop 2 we are using hop count as 2 because loopback ip will consider as 1 hop and interface is one hop . so total 2 am i right.
Hello Chandrasekhar
By default, before creating an eBGP peering, the protocol will check to see if the neighbor IP is on a subnet directly connected to the router. Default eBGP operation checks the eBGP neighbor statement against its list of directly connected neighbors. In the second example shown in the lesson, since the loopback on the neighboring router does not fall into the common segment, the eBGP neighbor relationship doesn’t attempt to form.
Now if you choose to use the disable-connected-check parameter, you are telling the router to skip this check. This will allow two directly connected routers to use their loopbacks for the peering. The reason I stress “directly connected” is because there is a second parameter that determines peering, and that is the TTL.
By default, eBGP peering will only take place between peers that are a single hop apart. This is checked using a decremented TTL in the BGP messages for every hop that is encountered. So even if you disable the connected check, if your routers are two hops away from each other, they still won’t form a peering. In order to allow this to happen, the ebgp-multihop parameter is used to adjust the maximum allowed TTL.
So to summarize, disable-connected-check will disable the check of the neighbor IP address to see that it is in one of the directly connected subnets of the router. This allows directly connected routers to use their loopbacks for the peering. This command will not work if the routers are more than a single hop from each other.
Conversely, ebgp-multihop will allow you to create BGP peers between routers that are two or more hops from each other.
For the particular example in the lesson, because the routers are directly connected, both solutions will successfully provide what is needed, but just using different mechanisms.
By default, the hop count used for the check is 1. This means that only directly connected (in the same subnet) neighbors will be allowed to peer. Setting two hops will allow the two loopbacks to peer. You can find out more about this at the following post:
I hope this has been helpful!
Laz
Hi Rene,
How would you configure/establish an eBGP connection over a typial VPN with the Internet as the underlying WAN transport? Do you have to enable BGP Multihop? If yes, we don’t know exactly how many hops the packet will have to traverse over the Internet to get to the other VPN endpoint.
In addition to this, I will be using a Cisco router as the VPN endpoint on both sides with GRE Tunnels and IPsec encryption running ontop of the GRE Tunnels.
Would greatly appreciate your help.
Regards
Akhas
Hello Akhas
If you are using a VPN to connect two routers across the Internet, and you are configuring BGP on the routers that are running the tunneling, then you don’t need to use multihop at all. Imagine you have the following topology (found this image online just to make it faster to respond):
There is a VPN tunnel configured between GW-A and GW-B. Imagine you are running BGP between those two routers. From the point of view of the VPN routers, there is really only one hop from GW-A to GW-B. Remember that the tunnel created between these two routers uses tunnel interfaces that have IP addresses on the same subnet. This by definition means that they are one hop away.
Remember that the tunnel acts as a single hop for the encapsulated IP packet, even though the underlying transport network is actually routed over multiple routers. Take a look at the following lesson to get a better idea of how the GRE tunnels and those interfaces interact.
I hope this has been helpful!
Laz
Hi Laz,
Awesome! That makes sense.
Many thanks for your quick response.
Akhas
1 Like
Hello,
One basic question on IP Routing. Just curious to know
TTL value is decreased after the transit router finds the destination IP and outgoing interface? or even before the destination IP address of the IP packet
Also just to confirm, once the L2 header is rewrittern, router will modify the TTL value of the orginal IPv4 header without touching src/dst ip and puts on the wire…correct?
If the destination IP is for the local router, it will not even look at the TTL value. correct?
Thanks,
Bala
Hello Bala
The TTL is always decremented upon egress of the packet from the router. So the router has already decided how to forward it, and just before it exits the interface, the TTL is decremented.
Yes that is correct. TTL is modified without modifying source and destination IPs in the IP header.
If the destination IP is the local device, it won’t look at the TTL. Not because it is the destination, but because TTL is always decremented just before egress. If the destination is the router itself, there is no egress. Remember, that a packet that is received with a TTL of 0 is still processed, but never forwarded.
Take a look at RFC1812 which talks more about how the TTL works.
I hope this has been helpful!
Laz
Thanks Laz. Will go over the RFC. One more clarification.Once at egress, after decrement, if the TTL value is zero, router will not forward correct.So on what scenario, a packet is received with TTL of 0
Thanks,
Bala
Hello Bala
If a packet is received with a TTL of 0, the device will process that packet. If it is an end device that receives it, it will process it normally. If it is a router that receives the packet, then it will make it’s forwarding decision by examining the routing table, will check the TTL, and if it is 0 it will drop it. If it is not, it will decrement and send it out.
So once at egress, if the TTL is 1 for example, and it is decremented to 0, it will send the packet out.
The order of operations for a router is:
- Receive the packet
- Determine the egress port based on destination IP and routing table
- Examine TTL field
a) if 0 drop packet.
b) If not 0, decrement TTL and send out egress port
I hope this has been helpful!
Laz
Thanks Laz for detailed answer. In EBGP multi hop lesson, When R1 tries to form eBGP with R3, when the packet comes to R2 egress interface, TTL has to be reduced to 0 and send out to R3 correct?But R2 is sending TTL exceeded message. Can you please make me understand here on what I am missing?
Thanks,
Bala
Hello Bala
The specific process that is followed in the scenario you describe from the lesson is the following:
- R1 prepares to send the packet to R3, and sets the TTL to 1.
- R1 will make its forwarding decision (chooses the egress port) using the destination IP address of R3 and its routing table.
- Before egress, the TTL is checked to see if it must be dropped or not. TTL is not equal to 0, so it is not dropped.
- The packet is sent
- R2 receives the packet. As per RFC1812 a router will not discard a packet it receives with a TTL of 1 or 0, but it will process it normally.
- R2 will make its forwarding decision based on the destination IP and routing table.
- Just before egress, the TTL is checked to see if it must be dropped or not. TTL is 1. At this point, if the local device is the destination, it receives it successfully. If not (which is the case now) it is dropped.
- R2 sends TTL exceeded message.
Note that the wireshark capture of the packet on R1 in the lesson is taken before the decrement of the TTL on R1. Rene states that R2 will decrement the TTL but according to the RFC, this is not quite correct. I will tell Rene to take a look and confirm that this is the case, and if so, the lesson will be updated.
I hope this has been helpful!
Laz
Thanks for the detailed explanation
1 Like
Hi Rene,
Can you please show the output/example that loadbalancing is working on this scenario.