Exit Selection Policies

Once traffic destined for the Internet reaches one of your border routers, the router must decide what to do with it. If it has more than one Internet connection, it must choose between them. If there are other border routers, it must decide if it should forward the exit traffic to them instead of using one of its own Internet connections. Your exit policy determines how your border routers will select the best exit for each packet.

Note that this a very different problem from how your hosts or interior routers select which border should initially be chosen for exit traffic. If your border routers use different exit policies, then border router choice might influence the exit eventually selected. See the section called Border Router Selection for details.

At first blush, you may wonder if there's any need at all for careful exit selection. After all, any connection to any ISP should be able to deliver any packet to any destination, right?

Yes, but even though any exit will usually work, some exits will often work better than others. In the face of equipment failures, careful exit selection can make the difference between staying connected and losing connectivity.

The simplest exit policies usually favor one default interface per border router. Simplicity certainly is a virtue, but it should be weighed against the benefits that a more complex policy can bring. As we'll see in following sections, more complex policies can:



As with Exit selection policies differ not just in the benefits they bring (as described above), but also in the resources they demand. Some require high-power routers, yet some do run just fine on low-end access routers (e.g. the venerable Cisco 25xx series). Some require coaxing your ISP(s) into configuring BGP on their border router just the way you want it while others require no cooperation from your ISP(s) at all. And of course, some are simple and some are complicated. See Table 7-1 for a concise comparison of the exit policies that'll be covered in detail in following sections. But note that these policies are not all mutually exclusive. That is, it's common for them to be used together in complex networks. Also, many networks start with simpler policies and build gradually to more complex policies. Hence it's probably best not to skip over policies that might be useful in some parts of your network or in a transitional role as your network grows.

Table 7-1. Exit Policy Overview

Policy Name Common Technique Relative Complexity (1=simplest) Relative Reliability (1=least reliable) Performance (Path selection quality w/multiple ISPs; 1=poorest selections) Router Hardware Requirements ISP Coordination Required (1=none) Destination Dependent Uses BGP
Use interface x Static route interface x 1 1 1 1 1 no no
Use interface y if interface x is down Low admin. distance static route to interface x, high admin. distance ("floating") static route to backup interface y 2 2 1 1 1 no no
Use closest interface with ISP border router connectivity Redistribute ISP's BGP default route into IGP 4 4 1 2 5 no yes
Use closest interface with ISP backbone router connectivity Redistribute ISP's BGP backbone route into IGP 6 5 1 2 6 no yes
Use interface best able to reach destination with ISP backbone router connectivity Receive customer routes from ISPs via BGP 8 10 8 4 8 yes yes
Receive full routes from ISPs via BGP 10 10 10 10 10 yes yes

Following sections will first examine common scenarios with a single ISP and multiple ISPs. These scenarios will illustrate the consequences of simple exit policies and the potential benefits of more complex policies.

Next, several exit policies and exit selection techniques are discussed in order of increasing complexity and functionality. These policies are separated into those that choose an exit independant of the destination address and those that consider the destination address in the decision process.

These policies may take some or all of these factors into account when chosing an exit:

Each step up this ladder entails more complexity, but also brings better performance and better reliability over a broader range of failures.

Copyright © 1999-2000 by Robert A. Van Valzah