

Multihoming Your Internet Service With BGP
By Chris Lewis
and
Thanh Nguyen
For many organizations, Internet access has become a vital business tool. To implement a measure of fault tolerance, these organizations seek to maintain multiple connections to the Internet. But most find they don't have the same control over load balancing and fault tolerance that they have in their own intranets.
Traditional routing protocols, like Routing Information Protocol (RIP) and Open Shortest PathFirst (OSPF) weren't designed to provide load balancing between purchased network connections. These protocols provide for fault-tolerant connections, but fall short when it comes time to dynamically determine the best w
ay to make use of the bandwidth at hand. One solution to this problem is the Border Gateway Protocol (BGP). It was designed as a method for maintaining routing information between autonom
ous systems (ASes), usually Internet service providers (ISPs), but it can be used to make better use of multihoming as well.
Enter BGP
The Internet is made up of many routing domains, each of which has its own network numbers administered by a different group, typically an ISP. The routing processes on the routers within a domain are identified as belonging to that domain by the AS number with which they are configured. When it comes time to exchange route information among domains, the route information that's transferred is subject to a predefined policy.
Within an AS, routing processes on a router, such as Interior Gateway Routing Protocol (IGRP) and OSPF, are designed to freely exchange information with others running the same routing process. The idea is that all routers configured for the same AS are und
er a common administration and are supplying information that can be trusted. When it comes time to share route information with another AS, however, the same level of trust does not exist. In practice, a separate routing process that can more finely control the exchange of information between two or more ASes is used.
IGRP and OSPF are termed IGPs because they facilitate the exchange of route information within an AS, whereas Exterior Gateway Protocols (EGPs) such as BGP and Interdomain Routing Protocol (IDRP) share only prespecified information among selected routers. With the Internet, the EGP of choice is BGP version 4 as defined in RFC 1771-4.
How BGP Works
While an IGP route update message consists of the destination network, route metric and associated next-hop router, BGP update messages consist of network number, or AS path pairs. The AS path contains a string of ASes through which the specified network can be reached. The BGP process will advertise routes that it has discovered via BG
P updates from routers in different ASes, internal routes redistributed from an IGP (or static routes) into BGP, and network numbers you specifically configure it to advertise. Note that static
route redistribution is preferred to IGP route redistribution since static routes do not vary as often as routes advertised by an IGP.
BGP is often implemented as Internal BGP (IBGP) and External BGP (EBGP) (see "Internal and External BGP" on page 121). Functionally, there is no difference between IBGP and EBGP; IBGP is just used to exchange route information among multiple routers in the same AS.
When two BGP peer routers first establish a session, the initial data exchange contains the entire routing table. Incremental updates are sent out as the routing tables change. BGP uses a predefined set of criteria when selecting routes to enter in the routing table. A simplified description of the path selection criteria used in BGP routers can be summarized as follows:
· Select the path with the highest admin
istrative weight.
· If weights are equal, prefer the route with the highest local preference;
· If the local preferences are the same, prefer the route originated by this router;
· If none of the routes originated from this router, prefer the route that passes through the fewest ASes;
· Beyond this, there are some BGP attributes that are examined as final tiebreakers, ultimately ending with preference being given to the route originating from the router with the lowest IP address.
|