In my continued quest through BGP i ran into a couple of things which i wanted to share my thoughts about.
All of them has to do with a non-direct peering between BGP peers.
Originally the BGP protocol was designed to be run between directly connected routers. Then came along these busy times where we might want to have two connections, for redundancy and load-balacing purposes. We also want to have a single peering only. These days we might even have non-BGP speakers in our core, such as with MPLS.
Now, per default a peering will have an IP TTL of 1. Also, remember that even though you are communicating with a directly connected router’s loopback interface, you can STILL do this with just a TTL of 1. Just try and perform a traceroute to the neighbor router’s loopback interface. You will see just one hop (TTL of 1).
With BGP however, there’s one additional check in the BGP process itself. And thats the directly-connected check.
If the neighbor address you specify is not on a directly connected network, it simply wont ever start the BGP peering with this neighbor. There are 2 ways to overcome this (well, 3, but more on this later).
One way is to use the “ebgp-multihop “command. Now for me, this was a misunderstood command. I have always been under the impression that this command specified how many hops away this router would accept a connection from. This is not the case.
Through Wiresharking most of my sunday afternoon, to my girlfriends disapproving eyes, i discovered two things.
One is that this command sets the TTL to whatever you set the hop to. The second is that this will make the local BGP process able to start the peering with a router thats not directly connected.
What this means is that since you set your TTL to something higher than the default of 1, you can reach routers further away. Second, accept incomming connections from a non-directly peer.
The next way of accomplishing the same thing, well almost, is to use the “disable-connected-check” command on your neighbor statement. The behavior here is different though. It does not modify the TTL of packets sent out from the local router. It does however disable the check thats performed on incomming connections, that they must be directly connected. As such it will start the BGP process on this neighbor specifically. So the end result is that you can use this command only on directly connected peers, but you can use loopbacks on the neighbors to perform the peering! Nothing else (afaik).
I mentioned a third way. The third way is really a security feature introduced in later IOS versions. To understand this in detail its important to know what happens when the BGP process receives an incomming peering request (open packets). Imagine an attacker sending open requests to your local BGP router.
Its easy for an attacker to fake the TTL in the ip packet so they can be routed, say over the internet. Even if your local router would process it, its reply would set the TTL to 1 and most likely be dropped before reaching the attackers BGP process, it STILL uses up cpu time to perform the local check. So this will in turn perform a (D)DOS attack on your router.
The command we are looking for is called “ttl-security hops “. When this command is in place, your router will send out IP packets with a TTL of 255. However, it will only accept IP packets (for BGP) with a TTL of (255-hops) and higher. So if you specify the hops to be 10, it will accept all IP packets (for BGP) with a TTL of 245 and more. This is a simple security meassure to reduce the possibility of a DDOS attack from attackers more hops away than what you have specified in the hops parameter. This works by utilitizing existing behavior. Each router along the path reduce the TTL by one when it routes the packet. This means that using this command reduces the attack diameter. The more hops you allow, the higher the risk (in very simple terms) you run.
I hope this has been enlightening. It was for me at least 🙂