Chapter 7. Policies for Reliability

Table of Contents
Policy and Load Balancing
The Questions of Policy
Asymmetric Paths
Influencing Entrance Selection and Controlling Exit Selection
Exit Selection Policies
Exit Selection Scenario with a Single ISP
Exit Selection Scenario with Multiple ISPs
Destination Independent Exit Policies
Destination Dependent Exit Policies
Influencing Entrance Selection
Originating Routes
Border Router Selection
Choosing an IGP
Choosing an IOS Version
Policy Transition Paths

This chapter discusses the major policies that your network will use to implement reliable Internet connectivity. Often, policies can be changed without spending money. This is in contrast to the preceding chapter where architectures often cannot be changed without spending money. Also, policy changes can usually be implemented promptly by you our your ISP simply by reconfiguring equipment. Architectural changes often cannot be made till new equipment has arrived or new lines have been installed.

Tense doesn't agree in this paragraph.

Readers won't be shown the router configurations needed to implement policies here, but they will know the costs and benefits of each policy and they'll know how to make the best choice for their network. Links are provided into Chapter 8 where you'll find detailed router configuration information.

Three key policy questions figure most prominently in maintiaining reliable Internet connectivity:

Each of these questions is covered in following sections. But before we examine alternative answers to such questions, I'll define some terms and discuss load balancing--a topic that generates a lot of policy discussion.

Policy and Load Balancing

Mention congestion avoiadance. Contrast with load balancing

Policies are established and chaged to meet goals. Common goals include reliable operation in the face of failure and using the lowest-cost provider. But for many BGP users, load balancing is the first goal that comes to mind. Hence before discussing policy, this section will address the goal of load balancing and its relationship to policy.

BGP is really all about choosing the best path for a packet to take. If your network is designed so that taking the best path also results in equally loaded interfaces, then you'll think that BGP is load balancing for you. But it's important to keep in mind that BGP's first goal is finding the best long-term path. You can influence the path chosen by setting policies that reward load sharing between interfaces to some degree. It's best to think of the primary problem as choosing the best exit from and entrance to your AS. Load balancing will come as a pleasant side effect of making the best entrance and exit choices in a well-designed network.

In general, you'll have more control over which exits packets take from your AS and less control over which entrance they use. But especially on the entrance choices, effort expended setting policies beyond a certain point will produce relatively little improvement in load sharing. When this point is reached, you're better off just buying another T1, upgrading to a T3, or redesigning your network architecture instead of trying to achieve better balancing through policy adjustments.

Setting Load Balancing Expectations

Let's start by setting some expectations about what can and what cannot be achieved with BGP load balancing.

IP traffic is bursty. A line into or out of your AS can be nearly idle one second and at or near full capacity the next. It's not unusual to measure the utilization of your lines over a month and conclude that you're only using 15% of your capacity, yet you may still have agonizingly slow Internet connectivity because one line is already at 100% capacity at the times when you need it most.

A router generally won't buffer more than a second or two's worth of data. Packets that don't fit in the buffer get dropped. For example, if you try to send 10 megabits over a 1 megabit per second line evenly distributed over a period of 5 seconds, the router feeding that line will probably deliver about 5 megabits in real time, deliver 1 megabit from a buffer (about 1 second's worth), and drop about 4 megabits of it.

TCP throughput falls substantially with packet loss rates of only a few percent.

Need citation here LBL Sally Floyd.

TCP is used underneath HTTP, SMTP, FTP, and many other Internet protocols. Hence even modest loss rates slow down these protocols dramatically.

Said simply, your long-term line usage doesn't matter—it's second-to-second usage that counts. BGP can give you some control over long-term line usage but doesn't help on the second-to-second usage. It will not help you dynamically avoid a congested interface like the one in the example above. BGP makes routing decisions based on things that change slowly (like connectivity between networks) and not in reaction to fleeting phenomena like network congestion.

That said, using BGP in your AS may help mitigate some congestion problems simply because it can bring more total bandwidth to bear on the problem of connecting your AS to the Internet. But it's really the architecture of the network that produces the benefits—not BGP itself. Design your network and your policies with load balancing in mind and you won't be disappointed with what BGP delivers or how much "tweaking" is required.

A final reminder before we get into the heart of the matter: I'll assume load balancing is only interesting if it's fault tolerant. What happens if you have two lines and one fails? If you had statically configured load sharing, half your traffic might continue while the other half was dropped. Dynamic load balancing implies that you want to balance the offered load across all lines that're available to handle it. Simply put, I'm assuming that reliability comes before load balancing.

Copyright © 1999-2000 by Robert A. Van Valzah