Asymmetric Paths

Since the entrance and exit selection questions are answered separately, packets leaving your network for an Internet destination may take a different path than those returning from that destination. Round-trip paths that that traverse one set of routers and links on the way there and a different set on the way back are called "asymmetric paths." This is really nothing to worry about (assuming that it doesn't lead to congested interfaces), but it concerns a lot of people when they first see it. In fact, it's usually a sign that BGP is making better decisions than would be possible if packets were forced to take the same path into and out of your AS.

It May be Hard to Notice Asymmetric Paths You've probably been using asymmetric paths for a long time without noticing. The most commonly used tool for path testing (traceroute) only shows the paths your packets take toward the destination. Need xref to description of how traceroute works. If you want to see the return path, you have to run the trace from the destination address toward your source address. This may be difficult unless you have access to a router or Unix shell account at the destination.

Asymmetric paths happen when traffic crosses routers operating with different policies. For example, you think it's best to deliver to me over this connection while I think it's best to respond to you using a different connection.

Does Your AS Have Asymmetric Paths Internally? It's natural to wonder why you may have never seen asymmetric paths within your AS. The answer is simple and interesting. In setting up your own network, you probably configured all your routers to use the same policy. This happened automatically if they shared an IGP. (You weren't making extensive use of static routes, were you?)

Asymmetric paths are more common that you might first think. One reason is that in any interchange between your AS and another, there are four policies at work. See Figure 7-1.

Let's follow how these policies influence the round-trip path a packet takes from your AS to a directly-connected destination AS when two paths are available.

1. The first policy that comes into play is the entrance policy of the destination AS. (I bet you thought your exit policy would be first. But the destination AS might not even be reachable if it weren't advertising routes via its entrance policy! See the section called Influencing Entrance Selection below for details.) The destination AS uses its entrance policy to express its preference over where it'd like to receive your traffic. It may have no role in choosing the path or it may have a pivotal role. But it has the first opportunity to participate in selecting the path.

2. Next, your exit policy will actually decide which of your exits to take. It may or may not be influenced by the entrance policy of the destination AS. (See the section called Exit Selection Policies below for details.)

3. On the return trip, your entrance policy may come into play. It may attempt to influence which of your entrances the return packet would use.

4. But ultimately, the exit policy of the destination AS will choose which of your entrances will receive the return packet.

If the source and destination ASes weren't directly connected, then there'd be n * 2 policies involved (where n is the number of ASes traversed by the path). With all these policies involved, it's easy to see how asymmetric paths are common.

For a concrete example, let's take a look at the network of a large, multi-site company like GM. Suppose they have Internet connections at headquarters near Detroit and at proving grounds near Indianapolis. Further suppose that they have a private network connecting these sites. See Figure 7-2.

If GM hosts their own web servers at HQ in Detroit, their outbound connection there may be used heavily by these web servers. If there were excess capacity on the proving grounds exit and on the private network between HQ and the proving grounds, it might make sense for GM's exit policy to send all HQ outbound traffic (other than from the web servers) toward the proving ground exit.

An observant surfer at HQ and a buddy at Ford might compare notes and notice that packets going to Ford's web server leave via the proving grounds exit but return through the HQ entrance. These packets are taking the "best" path in each case. In fact, they're balancing the load on the interfaces well. It's this balancing that leads directly to asymmetric paths in this case.