Border Router Selection

Border Router Selection vs. Exit Selection

Why read this section on border router selection if you've read the section on exit selection above? Because they're often two different problems.

Exit selection is the process BGP uses to decide which exit from your AS will be used. Border router selection is the process your interior routers and hosts use to pick a border router. Border router selection happens first as a host or interior router must choose a border router. Then the chosen border router decides if the packet should exit through one of its connections or if it should instead be forwarded to another border router for delivery.

Border Router Selection with IBGP

The border router selection problem can be neatly solved if all interior routers and hosts on the perimeter network run IBGP with the border routers. See Figure 7-21.

IBGP will copy the BGP routing tables from each border router into the interior router and host. Hence the interior router and host would always pick the best border router for each destination because of what they learned via IBGP.

However, the burden of running BGP adds a lot of complexity to most hosts. (You'd probably have to add software packages like GNU Zebra or GateD to allow a host to run BGP.) And the extra memory and CPU power required by BGP in interior routers may make them substantially more expensive than they'd be if they didn't run BGP. Hence most network designs will run BGP only on the border routers and therefore be faced with the border router selection problem. Following sections discuss network policies for selecting border routers without using BGP.

Border Router Selection with a Static Route

The simplest way for a host or interior router to choose a border router is to use a static default route. But simplicity has its price. Consider how a static default route might lead a host to choose the "wrong" [1] border router. For example, consider Figure 7-22.

In this case the host had a default static route pointing at Border RouterB and wanted to deliver traffic to a customer of ISPA. ISPA was sending customer routes so that your AS was aware that the destination was a customer of ISPA. In this case, Border RouterB would have learned ISPA's customer routes via IBGP from Border RouterA. So Border RouterB would receive the traffic and immediately redirect or forward it to Border RouterA via the perimeter network. The traffic would've traversed the perimeter network twice, wasting bandwidth.

That's part of the price you pay for the simplicity of a static default route. But there's an even higher price to pay. Suppose that Border RouterB fails as shown in Figure 7-23.

The interior router would likely share an IGP with the border routers. As shown above in the section called Exit Selection and Static Default Routes, your IGP should be configured to select a functioning border router with at least one good Internet connection. Your IGP would detect the failure of Border RouterB so your interior router would use Border RouterA as its default route.

But what about the host shown in Figure 7-23? It has a static default route pointing at the now dead Border RouterB. Hence it has lost all Internet connectivity. This is another example of how static routes and reliable networks often don't mix. But the next sections shows how Cisco routers provide a way that hosts can retain the simplicity of a static default route and yet maintain reliable Internet connectivity.

Border Router Selection with HSRP

HSRP is designed so that two or more routers can dynamically share a single IP address. Hosts that have static default routes pointing at this address will see a reliable exit path from your AS without having to listen to BGP or your IGP.

HSRP isn't a routing protocol at all. It's simply a way for routers on the same multi-access network to present a "non-stop" IP address. See the section called HSRP (Hot Standby Router Protocol) in Chapter 8 for HSRP configuration.

HSRP has the benefit that it keeps host configuration simple—a commonly used static default is all that's required. It also reacts to failures in a matter of seconds.

Here are some examples of HSRP in action. Consider the site shown in Figure 7-24.

The site has a T3 for its primary Internet connection and a T1 on a different border router for a backup. The perimeter network interface of Border RouterA is configured to have address 10.0.0.253. The perimeter network interface of Border RouterB is configured to have address 10.0.0.254. Since Border RouterA has the primary Internet connection, HSRP on it is configured so that it normally also holds the shared virtual interface address (10.0.0.1) on its perimeter network interface. HSRP on Border RouterB is configured to monitor the health of Border RouterA. Internet traffic from the host follows the static default route toward 10.0.0.1 to Border RouterA and exits on the T3 when both border routers are operating.

But suppose Border RouterA fails as shown in Figure 7-25.

Within seconds of Border RouterA's failure, Border RouterB's perimeter network interface takes over the shared virtual interface address (10.0.0.1). The static default route in the host now points to Border RouterB with no work on the host's part. Its Internet traffic now exits on the T1 via Border RouterB.

Now suppose that the T3 fails but Border RouterA continues to operate. See Figure 7-26. We want Border RouterB to take over the shared virtual address even though Border RouterA is still functioning. This case is handled by configuring Border RouterA to "give up" the address whenever it looses carrier detect on the T3.

This behavior is implemented with a priority system. Border RouterA is configured to lower its priority whenever carrier detect is lost on the T3. Border RouterB seizes control of the shared virtual interface address whenever it notices that its priority is now the highest in the group of routers sharing the address. (Yes, more than two routers can share a single virtual interface address.)

Find limit if any.

At this point, HSRP may sound pretty good (and it is), but there are a couple of things you should keep in mind.

• HSRP won't help you if an interface fails to pass data but carrier detect doesn't drop. This type of failure can happen if line between you and the central office is good but the DAX at the CO fails.

  BGP will eventually notice this kind of failure and reroute your traffic—it just won't happen with the speed of HSRP.

• HSRP won't help your hosts pick the "optimal" border router. For example, back in Figure 7-22, HSRP between the border routers wouldn't help the host choose Border RouterA for traffic to ISPA's customers. It would, however, allow the host to remain connected to the Internet should either border router fail.

• Note that HSRP is available on all Cisco routers, but can have only a single IP address on the lower-end routers (e.g. 1600, 2500, 2600, and 3600 series routers as of this writing). Check Cisco's HSRP docs for details.

  Need citation here

  This is generally not a problem since any of the routers participating in an HSRP group can serve as a gateway to other networks.
  
  

• HSRP can appear to interfere with outbound load sharing if you're not taking at least customer routes from one of your ISPs. See the section called Border Router Selection and Load Sharing below.

• Finally, remember that HSRP alone isn't sufficient for reliable Internet connectivity. You'll still need to have BGP configured correctly at your border routers and at all your ISPs to retain connectivity in the face of line and/or router failure.

Border Router Selection with Hosts Listening to IGP

HSRP is usually the best way for hosts to select a border router because it recovers quickly from failures and keeps host configuration simple. If you can't use HSRP, the next best choice for selecting a border router is to have hosts that listen to an IGP. It's most common for hosts to be able to listen to RIP, but the slow (several minute) convergence time of RIP makes it a poor IGP for those interested in reliability.

OSPF makes a much better IGP, but is substantially more complicated than RIP. To run OSPF on your hosts (or if your hosts don't already support RIP), you'll need to install a package like GNU Zebra or GateD. Remember that such packages may significantly complicates a host's configuration. They may also give it additional work to do that may distract it from it's primary function or impose additional hardware (e.g. memory) requirements.

Border Router Selection and Load Sharing

HSRP does a lot for reliability, but it can work against outbound load sharing in some cases. (Unfortunately, these cases often occur at sites with 2 T1s and more than 1 T1s worth of output bandwidth.) Consider the network of Figure 7-27.

Since both ISPs are sending only default routes, each border router will use its Internet connection for all exit traffic it receives. If each host generates about the same amount of outbound traffic, reasonably good outbound load sharing is achieved. (This might be especially desirable if both hosts together generated more traffic than would fit on either Internet connection individually.)

Although the outbound load sharing might be good with this configuration, your outbound traffic might be reaching its destination through some pretty circuitous paths. See the section called Exit Selection Scenario with Multiple ISPs for a complete explanation. As a quick reminder, think about what happens to traffic from HostB that destined for a customer of ISPA. It would have to be carried by at least ISPB (and perhaps several other ASes) before reaching ISPA.

If either Internet connection fails, BGP will lose the default route it had heard through that connection. Exit traffic sent to either router will eventually exit on the remaining (working) Internet connection. (This achieves the same effect that HSRP did above in Figure 7-26, although probably not quite as quickly.)

But what if one of the border routers fails? Any hosts using the failed border router as the destination for a static default route would loose Internet connectivity. HSRP dealt handily with this problem above in Figure 7-25. What would happen if we configured HSRP on both border routers and configured both hosts to use the HSRP virtual interface address for their static default route?

We would have better reliability since either Internet connection or either border router could fail without loss of Internet connectivity. But even in the absence of failure, all exit traffic from the AS would go out one Internet connection while the outbound side of the other sat largely idle. This could lead to congestion if the total exit traffic from HostA and HostB exceeded the capacity of either Internet connection. See Figure 7-28. In short, adding just HSRP to the network of Figure 7-27 achieved reliability at the expense of load sharing.

There are two changes that could be made to achieve both reliability and good outbound load sharing:

• The border routers running HSRP could receive at least customer routes from one ISP. But this might require more memory be added to your border routers.

• More than one HSRP virtual interface address could be used.

  Higher-end Cisco routers can be configured with two virtual interface addresses on the same physical interface. One of these addresses could be configured to favor Border RouterA in the normal case while the other were configured to favor Border RouterB in the normal case. Both would be configured to use the remaining working connection in the event of failure. HostA and HostB would then be configured with static default routes toward different HSRP virtual interface addresses.

  But recall that lower-end Cisco routers support only one HSRP virtual interface address per physical interface. Alternatives here would be upgrading to higher-end routers or using lower-end routers with 2 interfaces to split the perimeter network.

  Need reference back to Arch section here. Perhaps with a figure like BRSel95?