Border Gateway Protocol. Learning tricks and avoiding pitfalls.

[Hacker]

The content of the article

• Autonomous system with unrelated parts
• AS path prepend and control over incoming traffic
• Community strings
• Standard restrictions and workarounds
• We look at ourselves from the outside
• Conclusion

For example settings, we will use the free implementation of the FreeRangeRouting protocol stack, which runs on Unix-like systems and is used in specialized networked Linux distributions such as Cumulus Linux and VyOS.

Autonomous system with unrelated parts
It is believed that all parts of an autonomous system are directly related to each other. However, in some cases it is necessary to deviate from this rule. With a staged migration to another datacenter, this is inevitable. Points of presence in different datacenters with the same AS number is an undesirable but acceptable situation.

It would seem that it is enough to split the network into parts - for example, 192.0.2.0/24 into 192.0.2.0/25 and 192.0.2.128/25 - configure a new router at an additional point of presence and start advertising 192.0.2.128/25 from there. But not everything is so simple: with the default parameters, everyone on the Internet will see both parts of the AS, but your own routers will lose communication with each other.

Why is this happening? Suppose you use an autonomous system number 64,500 Let between its parts is the provider with the number 64501. Then AS path will look like 64500 64501 64500.

AS path in BGP is not only a path selection criterion, but also a loop prevention mechanism. If we recall the assumption in the protocol that all parts of the AS are connected directly, our path looks exactly like a loop.

BGP implementations consider it to be a loopback and discard any route where the same AS number occurs more than once in the path. But they also often provide an option to opt out of default known safe behaviors. This case is one of them. The option is usually named allowas-in. It takes as a parameter the maximum number of duplicate AS numbers allowed. Let's configure it so that two identical ASs in the path are not considered a loop:

router bgp 64496
 neighbor 192.0.2.1 remote-as 64500
 !
 address-family ipv4 unicast
  neighbor 192.0.2.1 allowas-in 2
 exit-address-family

Of course, with these settings, your router can start to pass real loopback routes too. Fortunately, in practice they are not found on the big Internet: transit providers do not include such options and do the right thing. In the internal network, nothing prevents you from assigning each independent part a separate AS number from the private range (64512-65534).

AS path prepend and control over incoming traffic
The mechanisms for controlling outgoing traffic in BGP are many and varied. Inbound traffic is a completely different story. On the public internet, you have no direct control over it. Autonomous systems are autonomous in that they cannot dictate routing policies to each other.

Any autonomous system, however, has control over the length of the AS path in outgoing announcements, and this can be used as an indirect control mechanism.

As we have already seen, the same AS number cannot appear twice in different places along the path (that is, when there is a third between the instances of the same number), otherwise such a path is considered to be a loopback. However, several copies of the same number in a row are not considered a loop. The path 64500 64500 64555 64501does not seem to raise any objections from BGP implementations. In this case, two identical ASs are not counted as one, so this path will be longer than 64500 64555 64501.

Artificially lengthening a path is called AS path prepend and is often used to influence path selection by other networks. If you have two providers and you advertise to one with a path 64500, and the second with a 64500 64500path, the route through the first will look more attractive for other networks. At least in theory.

This is how you can make the path three AS numbers longer in FRR than it is:

!
route-map Transit-Out permit 10
 set as-path prepend 64496 64496 64496
!
router bgp 64496
 neighbor 192.0.2.1 remote-as 64500
 !
 address-family ipv4 unicast
  neighbor 192.0.2.1 route-map Transit-Out out
 exit-address-family

Now, in show ip bgpthe output, we will see a path from three copies of our AS instead of the usual empty path for local announcements:

## show ip bgp neighbors 192.0.2.1 advertised-routes
   Network          Next Hop            Metric LocPrf Weight Path
*> 203.0.113.0/24   0.0.0.0                  0         32768 64496 64496 64496 i

In practice, you have no guarantees that all incoming traffic will go through the first provider. It may well turn out that for the second provider, the artificially lengthened path is still shorter than the alternative ones that came to him from the first through a chain of other providers. In addition, all administrators have every right to configure the "wrong" route from your point of view as preferred.

So it makes more sense to use the so-called. community strings if your transit provider supports them.

Community strings
Unlike all other protocols, BGP has a mechanism that allows you to influence the routing policy of a neighbor if the neighbor agrees to it.

Community strings are arbitrary values of the form AS:NUMBER(like 64500: 111) that can be assigned to output announcements and used as a criterion in the input policy. In general, the meaning of specific values is determined by the settings, although there are several default values, for example no-advertise, which tell the router not to propagate the announcement to others.

Transit providers often provide customers with this option. In the BGP Services / Features section of the Cogent User Guide (page 20), you can see a whole set of options for setting local preferenceand controlling who Cogent announces your route to (to anyone, everyone, specific regions of the world). Other providers also usually have similar documents - for example, for the RETN.

Let's say you want to give your neighbors the opportunity to display local preferenceon your side for their announcements. Let your autonomous system be 64500, and the client has 64496.

First, let's look at how from the client side to send a string to the provider. Let's send an announcement to the conditional provider with community 64500:50. Here's how to do it in FRR:

route-map Transit-Out permit 10
 set community 64500:50
!
router bgp 64496
 neighbor 192.0.2.1 remote-as 64500
 !
 address-family ipv4 unicast
  neighbor 192.0.2.1 route-map Transit-Out out
 exit-address-family

Now let's look at how to use it to define policies on the provider side. Let's set local preferencefor announcements with such a line to 50 (less than the default value):

bgp community-list expanded Customer-Policy permit 64500:50
!
route-map Customer-Import permit 10
 match community Customer-Policy
 set local-preference 50
!

router bgp 64500
 neighbor 192.0.2.10 remote-as 64496
 !
 address-family ipv4 unicast
  neighbor 192.0.2.10 route-map Customer-Import in
 exit-address-family
!

You can make sure that everything works on the provider side with the same command show ip bgp:

## show ip bgp
   Network          Next Hop            Metric LocPrf Weight Path
*> 203.0.113.0/24   192.0.2.10               0     50      0 64496 i

Standard restrictions and workarounds
There are many ways to make mistakes in dynamic routing, so protocol implementations include standard constraints to prevent common problems. At the same time, the line between error and unusual but meaningful tuning can be thin.

As an example, consider the option ebgp-multihop. By default, BGP will refuse to establish a connection with a neighbor if it is not on the same link-layer segment (that is, there are intermediate routers between the neighbors). This is usually a perfectly logical policy: it is obviously impossible to route traffic through someone who is not on the same network with you.

However, BGP is a fairly abstract protocol compared to all others and allows you to set your own gateway for routes. Because of this, BGP is often used as a method for automatically transferring lists of networks, and what to do with these networks, everyone decides for himself.

The Team Cymru company in this way provides everyone with up-to- date lists of networks that have not yet been allocated to any company and therefore should not appear on the Internet - if traffic comes to you from them, this is a clear sign of IP spoofing.

Since their route server is located somewhere far away on the Internet and it is not supposed to route traffic through it, the restriction on finding neighbors on the same network does not apply to it. In this case ebgp-multihop, the option that sets the maximum allowed number of intermediate routers will help us :

router bgp 64496
 neighbor 192.0.2.1 remote-as 64500
 neighbor 192.0.2.1 ebgp-multihop 255

We look at ourselves from the outside
Many have probably seen looking glass tools. ISPs often provide an interface from which to ping and traceroute to a specified address from their network. Usually nothing else is needed, but to debug routing policies it can be useful to see the AS path. Fortunately, transit providers usually offer this option as well. For example: Level3, Telia, Hurricane Electric.

Hurricane Electric still provides access to its looking glass via telnet. This was once the standard way, implementations like Cisco IOS and Quagga or FRR provide enough flexibility in command privilege control to make this configuration secure and only view data. Let's look through whom the traffic from their network will go to the Qrator network (AS197068), behind which the "Hacker's" site is located. Let's cut off hacker.com (178.248.232.27) and execute the command:

$ telnet route-server.he.net
...
route-server> show ip bgp 178.248.232.27 bestpath
BGP routing table entry for 178.248.232.0/23
Paths: (23 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
    3491 197068 197068 197068
    216.218.252.151 from 216.218.252.151 (216.218.252.151)
      Origin IGP, metric 1, localpref 100, valid, internal, best
      Last update: Mon Sep 23 04:07:39 2020

You can find out who owns the autonomous system number through whois: it whois AS3491will tell us that at the time of this writing, this provider is PCCW Global. Routing on the Internet changes quite often, so don't be surprised if you repeat it and see a different result.

Conclusion
Managing an autonomous system can be tricky, but if you read the documentation carefully, every admin can do it.
If you don't work for a company with your AS, but you want to experiment with routing in a similar real-world environment, you can join DN42 - a virtual network that simulates the Internet with BGP, DNS, whois and other attributes.