Product Description

Border Gateway Protocol (BGP) is the routing protocol used to exchange routing information across the Internet. It m akes it possible for ISPs to connect to each other and for end-users to connect to more than one ISP. BGP is the onl y protocol that is designed to deal with a network of the Internet's size, and the only protocol that can deal well with having multiple connections to unrelated routing doma ins. This book is a guide to all aspects of BGP: the protocol, its configuration and operation in an Internet environment, and how to troubleshooting it. The book also describes how to secure BGP, and how BGP can be used as a tool in combating Distributed Denial of Service (DDoS) attacks. Although the examples throughout this book are for Cisco routers, the techniques discussed can be applied to any BGP-capable router. The topics include: Requesting an AS number and IP addresses; route filtering by remote ISPs and how to avoid this; configuring the initial BGP setup; balancing the available incoming or out going traffic over the available connections; securing and troubleshooting BGP; BGP in larger networks: interaction with internal routing protocols, scalability issues; and BGP in Internet Service Provider networks. The book is filled with numerous configuration examples with more complex case studies at the end of the book to strengthen your understanding. BGP is for anyone interested in creating reliable connectivity to the Internet.

Product Details

• Amazon Sales Rank: #168627 in Books
• Published on: 2002-09-11
• Original language: English
• Number of items: 1
• Binding: Paperback
• 304 pages

Emmett Dulaney, UnixReview,com. Dec 2002
At 272 pages, this fits comfortably on any bookshelf. I doubt it will spend much time there, as this will be a book you will want to leaf through often.

About the Author
Iljitsch van Beijnum has been working with BGP in ISP and end-user networks since 1996. He has configured the protocol on single-router networks; networks with several hundred Ciscos ranging from the slowest to the fastest available; and multivendor environments with BGP running on Cisco and Juniper routers, Extreme switches, and FreeBSD hosts running GNU Zebra

Excerpted from BGP by Iljitsch Van Beijnum. Copyright © 2002. Reprinted by permission. All rights reserved.
Chapter 6 - Traffic Engineering

Being multihomed means you have two (or more) routes to any destination connected to the Internet. In other words, you need a way to decide which route is better. When left to its own devices, a BGP router will try to send traffic over the route with the shortest AS path. Depending on the connectivity of your upstream ISPs and traffic patterns, this will suit the available bandwidth of the respective connections to varying degrees. Even though bandwidth is getting cheaper all the time, it's usually advantageous to try to balance the traffic so that it takes advantage of all the available bandwidth in a multihomed setup. Thus, if BGP decides that most of the outgoing traffic should go through the smallest pipe, you will have to tell it that this isn't what you want by tweaking one or more BGP attributes. Ideally, more traffic will then flow over the under-used connection. At the same time, you'll want the traffic to take the best route to a destination, if possible, whatever !
"best" may be. This type of activity is called traffic engineering.

Engineering outgoing traffic is the easy part, because you have control over what your own routers do. It's harder to get incoming traffic balanced properly over the available connections. At the end of the chapter, there is a discussion of queuing, traffic shaping, and traffic policing techniques that can be used to maximize network performance under low-bandwidth conditions.

The examples in this chapter all assume a network with Autonomous System number 60055 multihomed to two ISPs: ISP A (AS 40077) and ISP B (AS 50066). The way ISP A and ISP B interconnect with other ASes differs from example to example, however.
Unlike in Chapter 5, the connections to both ISP A and ISP B terminate at the same router, so the settings for both ISPs can be shown side by side.
TIP: The examples in this chapter show only the commands necessary to perform the function being discussed. You also need to configure filters and other features discussed in Chapter 5 to arrive at a working configuration.

Knowing Which Route Is Best
Traditionally, there have been three figures that describe the quality of a connection: bandwidth, delay, and packet loss. A connection with high bandwidth, low delay, and low packet loss is obviously better than one with low bandwidth, high delay, and high packet loss. But which is better: a 45-Mbps satellite connection with a 300-millisecond delay,[1] or a 1544-Kbps terrestrial connection with a 3-ms delay? There is of course no easy answer: it depends. A protocol such as Telnet uses very little bandwidth, but when the user presses a key, he has to wait for the packet containing the input character to travel over the network and for the packet containing the response to travel back again before it shows up on his screen. So any delay of more than a few dozen milliseconds is immediately noticeable. With FTP, the time individual packets take to traverse the line is of little importance. What counts is the total time the file transfer takes, which depends mostly on the bandwidth of the connection. Both low-bandwidth, delay-sensitive applications such as Telnet and bandwidth-hungry, delay-tolerant ones such as FTP suffer from packet loss, because both typically use TCP. TCP uses complex algorithms to optimize performance (especially data throughput) for every possible combination of delay, bandwidth, and packet loss. TCP assumes packet loss indicates congestion in the network, so it slows down when packets are lost. (The TCP congestion management algorithms are discussed at the end of this chapter.)

Finding High- and Low-Quality Routes
There are no hard and fast rules about which quality makes a certain route better than another: application requirements are different, and the interaction between the bandwidth, delay, and packet loss parameters complicate matters further. But that doesn't mean there is nothing you can do. It may be hard to determine which of two good routes is best, but it isn't hard to determine that a route is bad. Some experimentation with the traceroute program can bring interesting information to the surface you can use to base your route selection policy on.

Doing some traceroutes to destinations that are reachable over a certain path will often reveal some or all of the following information, which you may want to use to select the preferred route to certain destinations:

Congestion
Congestion lowers the available bandwidth and increases delay and packet loss, so it's important to avoid routes over congested paths. Congestion shows up in a traceroute in two ways: there is usually packet loss, and the round-trip times are often inconsistent: most of the time high, but sometimes low.

Distance
Two routes can have different paths. Some networks interconnect only at relatively few locations, so they may have to transport traffic over long distances to get it to its destination. Others have better interconnection, so the traffic doesn't have to take a detour. There may be reasons not to prefer the more direct route, such as lower bandwidth or congestion, but generally a shorter geographic path is better. Every 100 kilometers or 60 miles of fiber adds about a millisecond to the round-trip time, because light travels at a speed of approximately 207,000 km or 129,000 miles per second in fiber. A trans-Atlantic or transcontinental detour can easily add up to more than 100-ms extra delay.

The distance of a path isn't directly visible in traceroute (apart from the higher delay), but many networks are helpful enough to give their router descriptive names, so it's possible to deduce the geographic path to some extent. Also, this information may be available in BGP itself in the form of communities that indicate where a route was learned.

Customer Reviews

A definative BGP reference !
You can tell the author has "walked the walk". I actually got far more out of this book than I did with Halabis' Internet Routing Architectures (1st ed).
Far more real-world, this book covers not just the raw BGP protocol (both I and Ebgp), but also covers topics such as DoS prevention, BGP Filters, RIR/LIR requirements, how to obtain PI/PA space/table space/hardware requirements etc etc.
In a Cisco world, this book coupled with Parkhursts' Config Handbook could possibly be all the reference you would need to get by.
A definate "must have" for any engineer needing to support/deploy this protocol.

Truly excellent
BGP is the core of internet routing and is truly an ivory tower. Without operating an actual autonomous subsystem, you are unlikely to encounter it or gain any BGP experience.

So far I haven't yet managed any of the 15.000 current AS's out there but after reading this book, I feel that I would be able to.

Skilled BGP admins are a rare breed, so go read this book!

The definitive guide to BGP
I feel this book not only give's a good grounding in BGP but also is the first book I have read that has really been able to explain to me the LIR requirements and how you go about obtain PI/PA. With the aid of this book I have been able to design and configure BGP and no longer resort to contracting out these tasks. I would recommend to any one taking their first step's into configuring BGP.