Foundation Topics

Introduction to BGP

This section presents the basics of BGP and when it is appropriate, introduces some terminology, and explains the ways you might use BGP to connect to the Internet. Complexities within BGP are then layered over this description in succeeding chapters.

The Context for BGP

BGP is a modern routing protocol designed to scale to the largest networks and create stable routes between organizations. BGP supports variable-length subnet mask (VLSM), classless interdomain routing (CIDR), and summarization.

BGP is an extremely complex protocol used throughout the Internet and within multinational organizations. Its main purpose is to connect very large networks or autonomous systems. Large organizations use BGP as the glue between divisions; for example, a conglomerate might use it between lines-of-business or the military might use BGP to communicate between the Army, the Navy, and the Air Force. BGP is also used on the Internet to connect organizations to one another.

BGP is the only routing protocol in use today that supports interdomain routing. The equipment and networks controlled by an organization are called an autonomous system (AS). Autonomous means independent, and when you use BGP you cannot force another organization to route traffic nor can they force routing decisions on you.

BGP Route Stability

Another key point about BGP is that BGP wants the network to be quiet. Whereas IGPs want the latest information and are constantly adjusting routes based on new information, BGP is designed to prefer routes that are stable and not constantly re-advertised. Also, BGP configurations normally require complex policy decisions. Thus, given this complexity coupled with the extreme size of the BGP routing table (often hundreds of thousands of routes), it is not surprising that constantly adjusting routes could overwhelm BGP.

BGP Operation Basics

BGP associates networks with autonomous systems. Other Internet routers then send traffic to your network toward your AS. When that traffic arrives at your edge BGP routers, it is typically the job of an IGP (such as EIGRP or OSPF) to find the best internal path.

BGP is a path-vector routing protocol. Routes are tracked in terms of the AS they pass through, and routers avoid loops by rejecting routes that have already passed through their AS. The idea of path-vector loop detection is illustrated in Figure 14-1.

Figure 14-1. BGP Loop Detection Using AS-Path

[View full size image]

BGP neighbors are called peers; peers are not discovered promiscuously but must be predefined.

There are four BGP message types used in peer relationship building and maintenance:

• Open

• Keepalive

• Update

• Notification

When a BGP process starts, it creates and maintains connections between peers on TCP 179, using BGP Open messages. These sessions are maintained by periodic keepalive messages, and peer information is kept in a separate neighbor table. If a peer is reset, it sends a notification message to indicate that it is closing the relationship.

When neighborship is first established, BGP routers exchange their complete routing tables using update messages. Subsequently, routing updates are only sent when something changes. For example, an update might be sent to reflect a new network that has become available or to remove a route that has been withdrawn.

BGP Record Keeping

Routing with BGP involves three tables:

• Neighbor table

• BGP table

• IP Routing table

BGP routes are maintained in a separate BGP table and the best BGP routes are passed on to the IP routing table.

BGP does not have a "metric" in the same manner as the other protocols that have been discussed. Instead, BGP has a ten-step process for selecting routes that looks at a variety of properties. The complexity of the path selection process, explored in Chapter 16, is one of BGP's great strengths. In addition, BGP supports tools (such as route maps and distribute lists) that allow administrators to manipulate traffic flow based on BGP attributes.

BGP and Hierarchy

Other routing protocols are designed to work in highly summarized, hierarchically organized networks. Organizations are not organized hierarchically (for instance, there is no hierarchical relationship between the UN, General Electric, and the Australia Zoo), so BGP has to work with whatever topology it is given. However, BGP still benefits from summarization for the same reasons as other protocols: smaller and fewer routing updates, less memory and processor utilization in making routing decisions, and less processor utilization maintaining the routing table. Thus an optimized BGP network will be highly summarized, although not necessarily hierarchical. Remember that BGP, by nature, provides a summary of key routes identifying paths between autonomous systems; because the collection of autonomous systems is loosely organized, it follows that BGP networks reflect that (lack of) organization.

BGP can be implemented in between networks and within a network. Remember, as shown in Figure 14-1, that BGP detects loops by seeing its AS in the path. The local AS is added to the path when it is advertised externally. When BGP is used internally, there is no way to use AS-path to detect loops and thus there are some special rules to prevent self-inflicted wounds. Because internal routing with BGP is a special case, we differentiate between the expected use of BGP, external BGP (eBGP), and internal BGP (iBGP). External BGP is used between autonomous systems and iBGP is used within an AS.

When to Use BGP

Because of its complexity and specialization for exterior functions, BGP is best in some specific cases:

• BGP is the only routing protocol that can connect your organization to multiple autonomous systems. For instance, sometimes multiple Internet links are used for redundancy and route optimization purposes.

• BGP should be considered if you need to implement a routing policy that is only possible with BGP, for instance, to control the link to your ISP.

• Finally, BGP is a must if your organization acts as a transit AS and connects other AS together. An ISP is an example of a transit AS.

On the contrary, BGP is probably not needed unless the preceding circumstances applies. If your routing requirements can be met in a simpler way, for instance with a default route, then do not encumber yourself with the monetary, financial, and intellectual overhead of BGP. And above all, do not use BGP if your router has insufficient processor or memory resources or if you are not absolutely sure of the potential effects of your BGP configuration.

Connecting to the Internet with BGP

As an exterior routing protocol, BGP is used to connect to the Internet and to route traffic within the Internet. You must ensure that the amount of traffic and routes does not overwhelm your network.

The following sections deal with two important design considerations: the need for redundant links into the Internet, called multihoming, and the need to decide how much routing information to receive from the Internet.

Redundant Connections to the Internet—Multihoming

To most modern organizations, losing Internet connectivity is akin to losing dial tone on phones. The Internet carries an enormous amount of traffic and use of the Internet continues to expand for individuals, finance, business, and commerce. It is therefore incumbent on network administrators to address the organization's needs for constant connectivity.

Smart administrators evaluate their Internet connections and try to address the most likely sources of failure. Redundant connections are a common way of addressing requirements for constant Internet service.

Redundant Internet connectivity is referred to as multihoming. The idea of multihoming is that failures at one link or ISP can cause a failover to a second link and ISP. When both links are functioning, this arrangement also increases capacity and improves performance. BGP load sharing between multiple links to distinct autonomous systems is possible via policy configurations.

Multihoming might involve more than one connection to the same ISP or connections to separate ISPs. Connecting to more than one ISP creates some issues you should carefully consider:

• You need to verify that your IP addresses are advertised correctly by your provider. One way to do this is to visit a "looking glass" site, which is an Internet site where you can see how your network is advertised through BGP.

• If routes that you advertise, or external routes you depend on, are advertised in different forms (for instance, a /24 instead of two /25 routes), remember that the more specific route will always be preferred regardless of BGP attributes.

• If you are connected to two different providers, your AS could become a transit AS between the ISPs. This is generally undesirable, even for most ISPs, because this results in supporting traffic from multiple remote autonomous systems through your AS, where both the source and destination of the traffic is outside of your AS.

Generally, the ISP is capable of dealing with these issues and will preconfigure their network to protect you. Of course, mistakes do happen and you should not trust that the provider has correctly configured their side. It is also important that you include both ISPs in your plan to multihome so that they can make necessary adjustments.

Receiving Routing Information from the Internet

When connecting to the Internet, some planning is necessary to decide what updates are to be sent to and received from the outside world.

There are three main approaches to connecting to the Internet:

• Accept only default routes from all providers

• Accept some routes plus a default route from all providers

• Accept full routing updates from all providers

Table 14-2 summarizes the different approaches to obtaining routing information from the Internet.

The easiest way to connect to the Internet is to take default routes from all providers. This provides your company with a backup path if one provider fails. Because you are only receiving one route, the processor and memory utilization is quite low. The tradeoff, however, is that sometimes traffic will take an indirect path because your router does not have all the information necessary to choose a shorter route—in fact, traffic will generally route to whichever edge router is closest. As an example of when this trade-off is appropriate, imagine that your company only connects to the Internet for e-mail and business research. In this case, some inefficient routing is not important and a complex BGP setup might be difficult to support anyway.

Skipping the second case, for a moment, consider the opposite approach. Taking all routes from all providers guarantees best-case routing, but the tradeoff is high memory and CPU utilization. As of this writing, the Internet BGP routing table has 197,866 routes and continues to grow steadily. The table consumes about 200 MB of memory. Synchronization of the table and receiving updates consumes processor cycles and network capacity. If your company is a service provider then it is important to have best-paths to all endpoints. Service providers would also have routers capable of supporting such large tables, high speed connections, and experienced engineers.

As is often the case in life, the middle road is attractive and fits many situations. Cherry-picking a limited set of routes to receive, plus a default, allows you to have as large or as small a table as you need. Traffic going to specific destinations known by the router will always take the best path, but even the traffic to unusual destinations will take the default path and be okay. As an example, imagine that your company has a handful of major customers and suppliers. For these customers, it is important to optimize routing, but other traffic can take the default routes.

Choosing between these options is an important decision, but not a permanent decision. In general, conservatively taking only the portion of the BGP table that is required is a good starting point. As your needs grow, you can work with your service provider to receive a larger and larger portion.

Synchronization

The BGP synchronization requirement states that before iBGP can propagate a route, the route must be known from another source. That is to say, the route must be learned from an IGP. This synchronization is to ensure that a router really knows how to get to the locations it advertises.

If you have a transit autonomous system with only the edge routers running iBGP, you are relying on the IGP to carry the traffic between the iBGP routers. It is therefore important for the IGP to have the information in its routing table to fulfill this task. The synchronization rule is beneficial for the following reasons:

• It prevents traffic from being forwarded to unreachable destinations.

• It reduces unnecessary traffic.

• It ensures consistency within the autonomous system.

The synchronization rule is on by default and is turned off on some occasions. (Just remember that the synchronization requirement exists for a reason!) It might be useful to turn off synchronization for the following reasons:

• All the routers in the AS are running BGP.

• All the BGP routers inside the AS are meshed.

• When the AS is not a transit autonomous system.

To turn off synchronization, use the following command:

Router(config-router)# no synchronization

Turning off synchronization allows routers to advertise routes into BGP before the IGP has a copy of the route in its routing table.

BGP States

BGP cycles through five states as it runs:

• Idle— Searching for neighbors

• Connect— TCP three-way handshake complete with neighbor

• Open Sent— BGP Open message has been sent

• Open Confirm— Response received

• Established— BGP neighborship is established

BGP starts each neighbor in idle, and evolves through Connect, Open Sent, and Open Confirm quickly (these are all displayed as "active") and ends in Established. The Established state indicates that both routers agree that all peering requirements are met. The easiest way to check this is to use the show ip bgp neighbors command. Look at the third line in Example 14-1.

Example 14-1. Show IP BGP Neighbors

Router# show ip bgp neighbors
BGP neighbor is 10.1.1.1, remote AS 100, external link
  BGP version 4, remote router ID 172.31.2.3
  BGP state = Established, up for 00:19:10
!output omitted

Remember: Established is good, anything else is bad.

If a neighbor does not progress from "idle," look for a next-hop address that cannot be reached.

If the neighbor stays "active," the neighbor is not responding as expected, so look for things that affect this reply. For instance, the peering address or AS may be incorrect, the neighbor may be misconfigured, or authentication may be misconfigured.