Exit Selection Scenario with Multiple ISPs

All of the issues discussed above in exit selection with a single ISP are present in the case of multiple ISPs. But there's also a new wrinkle: your policy can now make your exit selection based on which ISP is best able to reach the destination. However, that involves some extra complexity so let's look at a simpler alternative an its limitations first.

The simplest exit policies for multiple ISPs are the same as described above for the single ISP with multiple exit points:

  1. take the closest default exit interface, or

  2. take the best default exit as determined by your IGP.



Let's look at a network with two unequal ISPs and follow the path of traffic toward the smaller ISP with default routes from both ISPs. See Figure 7-7. ISPA is the smaller ISP and hence your line to them is only a fractional T1. ISPB is the larger ISP and hence you have a full T1 to them. Your IGP is very likely to choose the default route toward ISPB since it can see that this route is arriving over a faster interface.

Figure 7-7. Poor Path Chosen by Destination Independent Exit Policy

This "best default" exit policy sends traffic for ISPA's customers on a path that is much longer (and probably slower) than needed. In practice, although the first hop may indeed be faster, the second and subsequent hops often consume any advantage gained by taking the faster exit. (The borders between ISPs tend to be where congestion is worst, especially at public interchange points. Hence paths traversing more ASes are more likely to be slower and unreliable.) Your IGP suffers from a "horizon effect." Its only concern is picking the fastest way to get exit traffic out of your AS. It can't "see" beyond the first hop outside your AS.

The same long path would've resulted if you'd been receiving backgone routes via BGP from both ISPs. In this case, the long path would be chosen even when a direct path was available because the exit choice would be made independent of the destination address.

The way to include the destination address in your exit policy is to ask ISPA to advertise its customer routes to you instead of advertising the backbone routes described above. (Customer routes are those networks that an ISP can reach without using transit services from another ISP.) Armed with this information, your border routers can implement a policy like this: "take exit best able to reach the destination address." This policy is illustrated in Figure 7-8.

Figure 7-8. Best Path Chosen by Destination Dependent Exit Policy

A very common configuration for ASes with connections to two different ISPs is to request customer routes from one ISP and backbone routes from the other. You typically want to hand your default traffic to the ISP with more customer routes (since they're more likely to be able to deliver it without having to hand off to another ISP). Hence you request customer routes from the smaller ISP.

In addition to being more complex to configure, destination-dependent policies have another potential disadvantage: they require that border routers have more resources. In particular, all participating border routers must have

  1. Enough memory to hold the routes needed to make good exit choices, and

  2. Enough idle CPU time to maintain its BGP routing table and scan it when making exit choices.

In the extreme case with several connections to several different ISPs, you may want to take "full" BGP routes from your ISPs. Your border routers then need to store the entire Internet routing table. (Definately not a task for an entry-level or "access" router.)

Maybe this xref should go later in this chapter

See the section called Full Routes in Chapter 3.

In the above scenarios, we've seen how some destination independent policies are better than others. We've also seen how desitnation-dependent policies lead to the best exit choices of all. However, each of these adds complexity over the simple "closest default exit" policy. The sections that follow delve into each of these exit policies and the techniques used to implement them.

Copyright © 1999-2000 by Robert A. Van Valzah