So you want to load share better on your inbound ‘net links. If you look around the ‘web, it won’t take long to find a site that explains how to configure AS Path Prepending. So the next time you have downtime, you configure it up, turn everything back on, and… Well, it moved some traffic, but not as much as you’d like. So you wait ’til the next scheduled maintenance window and configure a couple of extra prepends into the mix. Now you fire it all back up and… not much happens. Why not? There are a couple of reasons prepending isn’t always that effective—but it primarily has to do with the way the Internet itself tends to be built. Let’s use the figure below as an example network.
You’re sitting at AS65000, and you’re trying to get the traffic to be relatively balanced across the 65001->65000 and the 65004->65000 links. Say you’ve prepended towards AS65001, as that’s the provider sending you more traffic. Assume, for a moment, that AS65003 accepts routes from both AS65001 and AS65004 on an equal basis. When you prepend, you’re causing the route towards your destinations to appear to be longer from AS65003’s perspective. This path will be affected by the first prepend.
But now consider the second prepend—will it have any impact on the traffic flow? AS65003 only has two paths to the destination, one through AS65001 and one through AS65004. It can only choose one of these two paths. If the single prepend worked, a second prepend isn’t going to make any difference. This alerts us to the first problem with prepending: it’s only as effective when it’s within the realistic parameters of the AS Path. Adding 256 prepends in this network isn’t going to have any impact more than the first prepend.
If the effectiveness of prepending is related to the overall path length through the network (edge to edge), then we should ask—what is the average path length of the global Internet? As it turns out, there are folks who measure this sort of thing on a regular basis, and have for quite a long time (in terms of Internet time scales)—CAIDA, RIPE, and Potaroo, for instance, all have pretty extensive measurements taken from the Internet Default Free Zone (DFZ) over time. Here is a chart of the average AS Path length in the DFZ since 1998:
As it turns out, the average AS Path length hasn’t changed much in the last eight years—even though the number of routes and the number of connected autonomous systems has dramatically increased over that same time period. The lesson here is the first AS path prepend is probably going to have the most impact, the second will have a lesser impact, and after that—you’re probably just typing for the fun of it.
There are two other reasons prepending can fail.
First, consider the connection between AS65001 and AS65004. We know this is some sort of peering relationship; it could be settlement free, it could have some sort of settlement on it, or—well, who knows? But one thing you can know is that AS65001 is always going to prefer your route from you over your route learned through AS65004. AS65001 is going to configure this preference using LOCAL_PREF, which comes way before your puny little AS Path Prepend. Bottom line? You’re never going to draw traffic across the 65004->65001 link using prepend.
Second, consider AS65002 sitting up in the corner. Once again, note that AS65001 is always going to prefer routes to its customer learned from its customers. So to add one more to the point above, you’re never going to get the traffic from AS65002 to travel through AS65004 instead of AS65001.
All this to say: if a majority of your traffic is being sourced from one of your two provider’s customers, prepend is going to be useless in redirecting that traffic through another provider.
Now that we know why prepend doesn’t always work, what can we do about it? We’ll save the answer ’til next week’s Design Board.