We have previously dealt with traffic engineering in general and AS path pre-setting in particular. The traffic engineering distributes the traffic load on the available lines in order to use these lines most efficiently. For example, if you have two 1 Gbps connections and 1.4 Gbps traffic, you want 50% of the traffic on one connection and 50% on the other, under otherwise identical conditions. Maybe 65% / 35% (910/490 Mbps) would still be fine, but what if BGP decides to send 75% of the traffic over one connection and 25% over the other? That would be 1050 Mbit / s (well, of course only 1000 Mbit / s) over one connection and 350 Mbit / s over the other. Now you're only using 1.35 Gbps of the 2 Gbps you're paying for, and 75% of your traffic is overloaded. Not much. By prefixing BGP-AS paths that contain the link that attracts too much traffic, BGP will consider the previously overloaded link to be less attractive and send more traffic over alternative paths that contain the unused link.
In most cases, a single prepend is very effective in changing traffic flows. However, any additional prefix quickly becomes less effective than the previous one, and part of the traffic doesn't move no matter how long the path becomes. Later in this post, we'll look at some issues with AS paths that are too long. However, let's first try to understand the effectiveness of different sets of AS path prefixes.
Over time, the connections between the networks that make up the Internet became increasingly dense. Currently, the average AS path length at well connected points in the network is about 4.5 AS hops and half a hop less if the prepending is ignored. Since there are now so many direct connections between Transit-AS, this means that the number of AS-Hops over different paths is very often the same. A random sample of information collected by the RouteViews project shows that for two transit networks that share their BGP information with RouteViews, in most cases more than 75% of the AS paths are the same length.
As a result, if we place ourselves in front of one of these transit networks, at least 75% of the targets now see a longer path via the preceding path and thus a shorter path via the non-preceding path. This in turn results in a large amount of traffic moving from the preceding path to the unspecified path. So it's not uncommon for a prefix to be too effective.
Please note that this only applies to traffic-related incoming traffic. If a network announces only one prefix for the rest of the world, that prefix can either precede a particular BGP neighbor or not. When a network announces additional prefixes, it cannot prepend some of them and others. Since all networks receive a large number of announcements, it is easy to prefix them selectively in order to achieve a finely tuned traffic technology for outgoing traffic.
Let's take a look at the good, bad, and ugly AS path presets.
The good thing: it works when it is presented
Let's look at the following simplified example so that everyone understands how prepositioning works. A network with eight autonomous systems is shown in the following figure. ASes 10 and 20 are transit providers that provide connectivity to ASes 1, 200, 300 and 400. AS 10 also offers transit services to AS 100 and AS 20 to AS 500.
AS 1 on the left announces the prefix 192.0.2.0/24, which is passed on by AS 10 and 20 to its customers on the left. Every time an AS announces the prefix to the next AS, it adds its own AS number to the left of the existing AS path.
As a result, ASes 200, 300 and 400 now have two options to achieve 192.0.2.0/24: 10 1 to AS 10 or 20 1 to AS 20. In this example, the BGP tie-breaker rules prefer ASes 200 and 300 the path through AS 10 and AS 400 the path through AS 20. (This is indicated by the> sign in front of the preferred paths.) The AS 100 and 500 use the only available path through AS 10 or AS 20.
The result is that traffic from ASes 100, 200 and 300 as well as traffic from AS 10 arrive at AS 1 via the connection to AS 10. Traffic from ASes 400, 500 and 20 arrives via AS 20. The traffic distribution is 4: 3 (57%: 43%). (For the sake of simplicity, we assume that each AS generates the same amount of traffic towards AS 1.)
Assume that the connection to AS 20 has more capacity or is cheaper to use than the connection to AS 10. AS 1 wants to receive more traffic via AS 20 and less via AS 10. To achieve this, AS 1 adds an additional copy of the AS number (prefixed) on the left AS path announcing the prefix 192.0.2.0/24 towards AS 10. This is shown in the next figure. The solid lines indicate preferred paths, the paths with dotted lines are not used because another path is preferred.
ASes 100, 200, 300 and 400 now see the AS path 10 1 1 where they previously saw the AS path 10 1. In the case of ASes 200, 300 and 400, this means that path 201 is now shorter, so that ASes 200 and 300 now switch to using path 20 1. (AS 400 has already used this path.) The result is that only ASes 10 and 100 that have no other options now send their data traffic via the AS 10 AS 1 connection. All other AS send their data traffic via the AS 20 – AS 1 connection. As a result, the traffic distribution ratio is 2: 5 (29%: 61%). So this was a very effective prefix since 28% of the traffic was moved from the 10-1 connection to the 20-1 connection.
The bad thing: when the imagination stops working
However, what if the effect of prefixing is not sufficient and AS 1 wants to move more traffic from the 10-1 connection to the 20-1 connection? The next figure shows another prefix:
But: there is no change. Even if we make AS 10 a customer of AS 20, so that AS 10 has a two-hop path to AS 1 through AS 20 (20 1), AS 10 still prefers the direct path, although the AS path is three Jumps include: 1 1 1. The reason for this is that most networks, and certainly the larger ones, consider the business relationship they have with external AS before considering the AS path.
When research on BGP began, it became clear that there may be situations where BGP does not converge to a stable state. However, a groundbreaking research paper by Lixin Gao and Jennifer Rexford showed that BGP will indeed reach a stable state as long as network operators adhere to a series of guidelines that are limited to the following:
Prefer routes learned by customers over routes learned by colleagues
Prefer routes learned by colleagues over routes learned by transit providers
In practice, this is implemented by routes that have been learned by customers having a high local preference (e.g. 200), routes that have been learned by colleagues, a medium local preference (e.g. 150) and routes, that have been learned by transit providers receive the lowest local preference (e.g. 100). . In this way, the BGP path selection algorithm delivers results that meet the Gao / Rexford guidelines.
The guidelines make economic sense because sending traffic to a customer makes money, sending to a peer is free, and sending to a transit provider costs money.
However, the result is that no matter how often you prepend a path to your service provider, you will still receive traffic coming from that service provider's network, as well as traffic from customers who have no other transit providers. And also from remote AS that have set up their traffic technology so that your long path is overridden by an even longer path or, more likely, by a local default.
If this is a problem, check whether you can set up an active / standby configuration with your transit provider using communities.
The ugly: Problems arise when presenting
An unresolved problem with BGP security is networks that announce prefixes without authorization. If this happens accidentally, it is called a route leak. This is often caused by the fact that networks do not implement filters that belong to a specific business relationship. For example, if network A is the same as networks B and C and then passes the prefixes from B to C. This is expected when BA pays to receive (and send) traffic from the rest of the world (A is the transit of B) provider) or when BA pays to promote B's prefixes to the rest of the world ( A is the transit provider of B). However, if A is neither B's transit provider nor C's transit provider, it shouldn't offer a transit service anyway.
Such a route leak is always a bad situation because traffic can flow over an unexpected and probably untrustworthy path and this path usually does not have the capacity to handle all of the additional traffic. However, traffic only flows on the leaked paths if they are shorter than the shortest regular path. If AS paths are nice and short, route leaks are less likely to be a problem. The potential impact of a route leak increases with each prefix. Fortunately, route leaks rarely occur on most networks. Therefore, avoiding AS path requirements would probably be an overreaction, even in situations where this could be very useful. However, it's best to side with the minimal AS path to limit susceptibility to route leaks.
Last but not least, there is AS path filtering. Some networks filter AS paths that are too long. In a way, this is similar to prefix length filtering, with IPv4 prefixes longer than / 24 and IPv6 prefixes longer than / 48 being filtered out by many networks. However, there is no such convention for maximum AS path lengths. A network operator mentioned filtering out prefixes with AS paths that are 20 hops longer. As the number of hops increases when a prefix changes from one AS to the next, it is important to apply a healthy safety margin. Since more than 99.9% of the AS paths are 10 hops or less (without prepends), 10 prepends and a safety distance of 10 hop should fall just below the 20 hop limit, which apparently filters at least one network.
However, due to the rapidly decreasing effect of additional prefixes, it may be best to avoid using more than three prepends anyway.