To understand BGP, you first need to understand how it is different than the other protocols discussed so far in this book, including an understanding of autonomous systems.

One way to categorize routing protocols is by whether they are interior or exterior:

Figure 8-1 illustrates the concept of IGPs and EGPs.

Figure 8-1. IGPs Operate Within an Autonomous System, and EGPs Operate Between Autonomous Systems

BGP is an Interdomain Routing Protocol (IDRP), which is also known as an EGP. All of the routing protocols you have seen so far in this book are IGPs.

BGP version 4 (BGP-4) is the latest version of BGP. It is defined in Requests for Comments (RFC) 4271, A Border Gateway Protocol (BGP-4). As noted in this RFC, the classic definition of an AS is “a set of routers under a single technical administration, using an Interior Gateway Protocol (IGP) and common metrics to determine how to route packets within the AS, and using an inter-AS routing protocol to determine how to route packets to other [autonomous systems].”

Autonomous systems might use more than one IGP, with potentially several sets of metrics. The important characteristic of an AS from the BGP point of view is that the AS appears to other autonomous systems to have a single coherent interior routing plan, and it presents a consistent picture of which destinations can be reached through it. All parts of the AS must be connected to each other.

The Internet Assigned Numbers Authority (IANA) is the umbrella organization responsible for allocating AS numbers. Regional Internet Registries (RIRs) are nonprofit corporations established for the purpose of administration and registration of IP address space and autonomous system numbers. There are five RIRs, as follows:

This AS designator is a 16-bit number, with a range of 1 to 65535. RFC 1930, Guidelines for Creation, Selection, and Registration of an Autonomous System (AS), provides guidelines for the use of AS numbers. A range of AS numbers, 64512 to 65535, is reserved for private use, much like the private IP addresses. All of the examples and exercises in this book use private AS numbers, to avoid publishing AS numbers belonging to an organization.

You need to use the IANA-assigned AS number, rather than a private AS number, only if your organization plans to use an EGP, such as BGP, to connect to a public network such as the Internet.

BGP is used between autonomous systems, as illustrated in Figure 8-2.

Figure 8-2. BGP-4 Is Used Between Autonomous Systems on the Internet

BGP is a successor to Exterior Gateway Protocol (EGP). (Note the dual use of the EGP acronym.) The EGP protocol was developed to isolate networks from each other at the early stages of the Internet.

There is a distinction between an ordinary autonomous system and one that has been configured with BGP to implement a transit policy. The latter is called an ISP or a service provider.

Many RFCs relate to BGP-4, including those listed in Table 8-1.

BGP-4 has many enhancements over earlier protocols. It is used extensively on the Internet today to connect ISPs and to interconnect enterprises to ISPs.

BGP-4 and its extensions are the only acceptable version of BGP available for use on the public Internet. BGP-4 carries a network mask for each advertised network and supports both variable-length subnet mask (VLSM) and classless interdomain routing (CIDR). BGP-4 predecessors did not support these capabilities, which are currently mandatory on the Internet. When CIDR is used on a core router for a major ISP, the IP routing table, which is composed mostly of BGP routes, has more than 190,000 CIDR blocks; not using CIDR at the Internet level would cause the IP routing table to have more than 2,000,000 entries. Using CIDR, and, therefore, BGP-4, prevents the Internet routing table from becoming too large for interconnecting millions of users.

Table 8-2 compares some of BGP’s key characteristics to the other scalable routing protocols discussed in this book.

As shown in Table 8-2, OSPF, IS-IS, and EIGRP are interior protocols, whereas BGP is an exterior protocol.

Chapter 2, “Routing Principles,” discusses the characteristics of distance vector and link-state routing protocols. OSPF and IS-IS are link-state protocols, whereas EIGRP is an advanced distance vector protocol. BGP is also a distance vector protocol, with many enhancements; it is also called a path vector protocol.

Most link-state routing protocols, including OSPF and IS-IS, require a hierarchical design, especially to support proper address summarization. OSPF and IS-IS let you separate a large internetwork into smaller internetworks called areas. EIGRP and BGP do not require a hierarchical topology.

BGP works differently than IGPs. Internal routing protocols look at the path cost to get somewhere, usually the quickest path from one point in a corporate network to another based upon certain metrics. RIP uses hop count and looks to cross the fewest Layer 3 devices to reach the destination network. OSPF uses cost, which on Cisco routers is based on bandwidth, as its metric. The IS-IS metric is typically based on bandwidth (but it defaults to 10 on all interfaces on Cisco routers). EIGRP uses a composite metric, with bandwidth and accumulated delay considered by default.

In contrast, BGP does not look at speed for the best path. Rather, BGP is a policy-based routing protocol that allows an AS to control traffic flow using multiple BGP attributes. Routers running BGP exchange network reachability information, called path vectors or attributes, including a list of the full path of BGP AS numbers that a router should take to reach a destination network. BGP allows a provider to fully use all of its bandwidth by manipulating these path attributes.

The Internet is a collection of autonomous systems that are interconnected to allow communication among them. BGP provides the routing between these autonomous systems.

Enterprises that want to connect to the Internet do so through one or more ISPs. If your organization has only one connection to one ISP, then you probably do not need to use BGP; instead you would use a default route. If you have multiple connections to one or to multiple ISPs, however, then BGP might be appropriate because it allows manipulation of path attributes, facilitating selection of the optimal path.

When BGP is running between routers in different autonomous systems, it is called External BGP (EBGP). When BGP is running between routers in the same autonomous system, it is called Internal BGP (IBGP).

Understanding how BGP works is important to avoid creating problems for your AS as a result of running BGP. For example, enterprise AS 65500 in Figure 8-3 is learning routes from both ISP-A and ISP-B via EBGP and is also running IBGP on all of its routers. Autonomous system 65500 learns about routes and chooses the best way to each one based on the configuration of the routers in the AS and the BGP routes passed from the ISPs. If one of the connections to the ISPs goes down, traffic will be sent through the other ISP.

Figure 8-3. Using BGP to Connect to the Internet

One of the routes that AS 65500 learns from ISP-A is the route to 172.18.0.0/16. If that route is passed through AS 65500 using IBGP and is mistakenly announced to ISP-B, then ISP-B might decide that the best way to get to 172.18.0.0/16 is through AS 65500, instead of through the Internet. AS 65500 would then be considered a transit AS (an ISP); this would be a very undesirable situation. AS 65500 wants to have a redundant Internet connection, but does not want to act as a transit AS between ISP-A and ISP-B. Careful BGP configuration is required to avoid this situation.

Multihoming is when an AS has more than one connection to the Internet. Two typical reasons for multihoming are as follows:

The benefits of BGP are apparent when an AS has multiple EBGP connections to either a single ISP or multiple ISPs. Having multiple connections enables an organization to have redundant connections to the Internet so that if a single path becomes unavailable, connectivity can still be maintained.

An organization can be multihomed to either a single ISP or to multiple ISPs. A drawback to having all of your connections to a single ISP is that connectivity issues in that single ISP can cause your AS to lose connectivity to the Internet. By having connections to multiple ISPs, an organization gains the following benefits:

A multihomed AS will run EBGP with its external neighbors and might also run IBGP internally.

If an organization has determined that it will perform multihoming with BGP, three common ways to do this are as follows:

The sections that follow describe these options in greater detail.

Multihoming with Default Routes from All Providers

The first multihoming option is to receive only a default route from each ISP. This configuration requires the least resources within the AS because a default route is used to reach any external destinations. The AS sends all of its routes to the ISPs, which process and pass the routes on to other autonomous systems.

If a router in the AS learns about multiple default routes, the local IGP installs the best default route into the routing table. From the perspective of this router, it takes the default route with the least-cost IGP metric. This IGP default route will route packets that are destined to the external networks to an edge router of this AS, which is running EBGP with the ISPs. The edge router will use the BGP default route to reach all external networks.

The route that inbound packets take to reach the AS is decided outside of the AS (within the ISPs and other autonomous systems).

Regional ISPs that have multiple connections to national or international ISPs commonly implement this option. The regional ISPs do not use BGP for path manipulation; however, they require the capability of adding new customers and the networks of the customers. If the regional ISP does not use BGP, then each time that the regional ISP adds a new set of networks, the customers must wait until the national ISPs add these networks to their BGP process and place static routes pointing at the regional ISP. By running EBGP with the national or international ISPs, the regional ISP needs to add only the new networks of the customers to its BGP process. These new networks automatically propagate across the Internet with minimal delay.

A customer that chooses to receive default routes from all providers must understand the following limitations of this option:

• Path manipulation cannot be performed because only a single route is being received from each ISP.

• Bandwidth manipulation is extremely difficult and can be accomplished only by manipulating the IGP metric of the default route.

• Diverting some of the traffic from one exit point to another is challenging because all destinations are using the same default route for path selection.

Figure 8-4 illustrates an example. AS 65000 and AS 65250 send default routes into AS 65500. The ISP that a specific router within AS 65500 uses to reach any external address is decided by the IGP metric that is used to reach the default route within the autonomous system. For example, if AS 65500 uses RIP, Router C selects the route with the lowest hop count to the default route when sending packets to network 172.16.0.0.

Figure 8-4. Default Routes from All ISPs

Multihoming with Default Routes and Partial Table from All Providers

In the second design option for multihoming, all ISPs pass default routes plus select specific routes to the AS.

An enterprise that is running EBGP with an ISP and that wants a partial routing table generally receives the networks that the ISP and its other customers own. The enterprise can also receive the routes from any other AS.

Major ISPs are assigned between 2000 and 10,000 CIDR blocks of IP addresses from the IANA, which they reassign to their customers. If the ISP passes this information to a customer that wants only a partial BGP routing table, the customer can redistribute these routes into its IGP. The internal routers of the customer (these routers are not running BGP) can then receive these routes via redistribution. They can take the nearest exit point based on the best metric of specific networks instead of taking the nearest exit point based on the default route.

Acquiring a partial BGP table from each provider is beneficial because path selection will be more predictable than when using a default route.

Figure 8-5 illustrates an example. ISPs in AS 65000 and AS 64900 send default routes and the routes that each ISP owns to AS 64500. The enterprise (AS 64500) asked both providers to also send routes to networks in AS 64520 because of the amount of traffic between AS 64520 and AS 64500.

Figure 8-5. Default Routes and Partial Table from All ISPs

By running IBGP between the internal routers within AS 64500, AS 64500 can choose the optimal path to reach the customer networks (AS 64520 in this case). The routes to AS 64100 and to other autonomous systems (not shown in the figure) that are not specifically advertised to AS 64500 by ISP A and ISP B are decided by the IGP metric that is used to reach the default route within the AS.

Multihoming with Full Routes from All Providers

In the third multihoming option, all ISPs pass all routes to the AS, and IBGP is run on at least all the routers in the transit path in this AS. This option allows the internal routers of the AS to take the path through the best ISP for each route.

This configuration requires a lot of resources within the AS because it must process all the external routes.

The AS sends all its routes to the ISPs, which process the routes and pass them to other autonomous systems.

Figure 8-6 illustrates an example. AS 65000 and AS 64900 send all routes into AS 64500. The ISP that a specific router within AS 64500 uses to reach the external networks is determined by the BGP protocol. The routers in AS 64500 can be configured to influence the path to certain networks. For example, Router A and Router B can influence the outbound traffic from AS 64500.

Figure 8-6. Full Routes from All ISPs

Internal routing protocols announce a list of networks and the metrics to get to each network. In contrast, BGP routers exchange network reachability information, called path vectors, made up of path attributes, as illustrated in Figure 8-7. The path vector information includes a list of the full path of BGP AS numbers (hop-by-hop) necessary to reach a destination network. Other attributes include the IP address to get to the next AS (the next-hop attribute) and how the networks at the end of the path were introduced into BGP (the origin code attribute); the later “BGP Attributes” section describes all the BGP attributes in detail.

Figure 8-7. BGP Uses Path Vector Routing

This AS path information is used to construct a graph of loop-free autonomous systems and is used to identify routing policies so that restrictions on routing behavior can be enforced based on the AS path.

BGP is designed to scale to huge internetworks, such as the Internet.

BGP allows routing-policy decisions to be applied to the path of BGP AS numbers so that routing behavior can be enforced at the AS level and to determine how data will flow through the AS. These policies can be implemented for all networks owned by an AS, for a certain CIDR block of network numbers (prefixes), or for individual networks or subnetworks. The policies are based on the attributes carried in the routing information and configured on the routers.

Some policies cannot be supported by the hop-by-hop routing paradigm and, thus, require techniques such as source routing to enforce. For example, BGP does not allow one AS to send traffic to a neighboring AS, intending that the traffic take a different route from that taken by traffic originating in that neighboring AS. In other words, you cannot influence how a neighboring AS will route your traffic, but you can influence how your traffic gets to a neighboring AS. However, BGP can support any policy conforming to the hop-by-hop routing paradigm.

Because the current Internet uses only the hop-by-hop routing paradigm, and because BGP can support any policy that conforms to that paradigm, BGP is highly applicable as an inter-AS routing protocol for the current Internet.

For example, in Figure 8-8, the following paths are possible for AS 64512 to reach networks in AS 64700, through AS 64520:

Figure 8-8. BGP Supports Routing Policies

Autonomous system 64512 does not see all these possibilities. Autonomous system 64520 advertises to AS 64512 only its best path, 64520 64600 64700, the same way that IGPs announce only their best least-cost routes. This path is the only path through AS 64520 that AS 64512 sees. All packets that are destined for 64700 via 64520 take this path, because it is the AS-by-AS (hop-by-hop) path that AS 64520 uses to reach the networks in AS 64700. Autonomous system 64520 does not announce the other paths, such as 64520 64540 64600 64700, because it does not choose any of those paths as the best path, based on the BGP routing policy in AS 64520.

AS 64512 does not learn of the second-best path, or any other paths from 64520, unless the best path through AS 64520 becomes unavailable.

Even if AS 64512 were aware of another path through AS 64520 and wanted to use it, AS 64520 would not route packets along that other path, because AS 64520 selected 64520 64600 64700 as its best path, and all AS 64520 routers will use that path as a matter of BGP policy. BGP does not let one AS send traffic to a neighboring AS, intending that the traffic take a different route from that taken by traffic originating in the neighboring AS.

To reach the networks in AS 64700, AS 64512 can choose to use the path through AS 64520 or it can choose to go through the path that AS 64530 is advertising. Autonomous system 64512 selects the best path to take based on its own BGP routing policies.

BGP use in an AS is most appropriate when the effects of BGP are well-understood and at least one of the following conditions exists:

If an enterprise has a policy that requires it to differentiate between its traffic and traffic from its ISP, the enterprise must connect to its ISP using BGP. If, instead, an enterprise is connected to its ISP with a static route, traffic from that enterprise is indistinguishable from traffic from the ISP for policy decision-making purposes.

BGP was designed to allow ISPs to communicate and exchange packets. These ISPs have multiple connections to one another and have agreements to exchange updates. BGP is the protocol that is used to implement these agreements between two or more autonomous systems. If BGP is not properly controlled and filtered, it has the potential to allow an outside AS to affect the traffic flow to your AS. For example, if you are a customer connected to ISP-A and ISP-B (for redundancy), you want to implement a routing policy to ensure that ISP-A does not send traffic to ISP-B via your AS. You want to be able to receive traffic destined for your AS through each ISP, but you do not want to waste valuable resources and bandwidth within your AS to route traffic for your ISPs. This chapter focuses on how BGP operates and how to configure it properly so that you can prevent this from happening.

BGP is not always the appropriate solution to interconnect autonomous systems. For example, if there is only one exit path from the AS, a default or static route is appropriate; using BGP will not accomplish anything except to use router CPU resources and memory. If the routing policy that will be implemented in an AS is consistent with the policy implemented in the ISP AS, it is not necessary or even desirable to configure BGP in that AS. The only time BGP will be required is when the local policy differs from the ISP policy.

Do not use BGP if one or more of the following conditions exist:

In these cases, use static or default routes instead, as discussed in Chapter 2.

What type of protocol is BGP? Chapter 2 covers the characteristics of distance vector and link-state routing protocols. BGP is sometimes categorized as an advanced distance vector protocol, but it is actually a path vector protocol. BGP has many differences from standard distance vector protocols, such as RIP.

BGP uses the Transmission Control Protocol (TCP) as its transport protocol, which provides connection-oriented reliable delivery. In this way, BGP assumes that its communication is reliable and, therefore, BGP does not have to implement any retransmission or error-recovery mechanisms, like EIGRP does. BGP information is carried inside TCP segments using protocol 179; these segments are carried inside IP packets. Figure 8-9 illustrates this concept.

Figure 8-9. BGP Is Carried Inside TCP Segments, Which Are Inside IP Packets

After the TCP connection is made, full BGP routing tables (described in the later “BGP Tables” section) are exchanged. However, because the connection is reliable, BGP routers need to send only changes (incremental updates) after that. Periodic routing updates are not required on a reliable link, so triggered updates are used. BGP sends keepalive messages, similar to the hello messages sent by OSPF, IS-IS, and EIGRP.

OSPF and EIGRP have their own internal functions to ensure that update packets are explicitly acknowledged. These protocols use a one-for-one window so that if either OSPF or EIGRP has multiple packets to send, the next packet cannot be sent until an acknowledgment from the first update packet is received. This process can be very inefficient and cause latency issues if thousands of update packets must be exchanged over relatively slow serial links; however, OSPF and EIGRP rarely have thousands of update packets to send. For example, EIGRP can hold more than 100 networks in one EIGRP update packet, so 100 EIGRP update packets can hold up to 10,000 networks. Most organizations do not have 10,000 subnets.

BGP, on the other hand, has more than 190,000 networks (and growing) on the Internet to advertise, and it uses TCP to handle the acknowledgment function. TCP uses a dynamic window, which allows for up to 65,576 bytes to be outstanding before it stops and waits for an acknowledgment. For example, if 1000-byte packets are being sent and the maximum window size is being used, BGP would have to stop and wait for an acknowledgment only when 65 packets had not been acknowledged.

TCP is designed to use a sliding window, where the receiver acknowledges at the halfway point of the sending window. This method allows any TCP application, such as BGP, to continue streaming packets without having to stop and wait, as OSPF or EIGRP would require.

No single router can handle communications with the tens of thousands of the routers that run BGP and are connected to the Internet, representing more than 22,000 autonomous systems. A BGP router forms a direct neighbor relationship with a limited number of other BGP routers. Through these BGP neighbors, a BGP router learns of the paths through the Internet to reach any advertised network.

Any router that runs BGP is called a BGP speaker.

A BGP speaker has a limited number of BGP neighbors with which it peers and forms a TCP-based relationship, as illustrated in Figure 8-10. BGP peers can be either internal or external to the AS.

Figure 8-10. Routers That Have Formed a BGP Connection Are BGP Neighbors or Peers

External BGP Neighbors

Recall that when BGP is running between routers in different autonomous systems, it is called EBGP. Routers running EBGP are usually directly connected to each other, as shown in Figure 8-11.

Figure 8-11. EBGP Neighbors Belong to Different Autonomous Systems

An EBGP neighbor is a router outside this AS; an IGP is not run between the EBGP neighbors. For two routers to exchange BGP routing updates, the TCP reliable transport layer on each side must successfully pass the TCP three-way handshake before the BGP session can be established. Therefore, the IP address used in the neighbor command must be reachable without using an IGP. This can be accomplished by pointing at an address that can be reached through a directly connected network or by using static routes to that IP address. Generally, the neighbor address used is the address of the directly connected network.

Internal BGP Neighbors

Recall that when BGP is running between routers within the same AS, it is called IBGP. IBGP is run within an AS to exchange BGP information so that all internal BGP speakers have the same BGP routing information about outside autonomous systems and so this information can be passed to other autonomous systems.

Routers running IBGP do not have to be directly connected to each other, as long as they can reach each other so that TCP handshaking can be performed to set up the BGP neighbor relationships. The IBGP neighbor can be reached by a directly connected network, static routes, or an internal routing protocol. Because multiple paths generally exist within an AS to reach other routers, a loopback address is usually used in the BGP neighbor command to establish the IBGP sessions.

For example, in Figure 8-12, Routers A, D, and C learn the paths to the external autonomous systems from their respective EBGP neighbors (Routers Z, Y, and X). If the link between Routers D and Y goes down, Router D must learn new routes to the external autonomous systems. Other BGP routers within AS 65500 that were using Router D to get to external networks must also be informed that the path through Router D is unavailable. Those BGP routers within AS 65500 need to have the alternative paths through Routers A and C in their BGP topology database. You must set up IBGP sessions between all routers in the transit path in AS 65500 so that each router in the transit path within the AS learns about paths to the external networks via IBGP.

Figure 8-12. IBGP Neighbors Are in the Same AS

This section explains why IBGP route propagation requires all routers in the transit path in an AS to run IBGP.

IBGP in a Transit AS

BGP was originally intended to run along the borders of an AS, with the routers in the middle of the AS ignorant of the details of BGP—hence the name “Border Gateway Protocol.” A transit AS, such as the one shown in Figure 8-13, is an AS that routes traffic from one external AS to another external AS. As mentioned earlier, transit autonomous systems are typically ISPs. All routers in a transit AS must have complete knowledge of external routes. Theoretically, one way to achieve this goal is to redistribute BGP routes into an IGP at the edge routers; however, this approach has problems.

Figure 8-13. BGP in a Transit AS

Because the current Internet routing table is very large, redistributing all the BGP routes into an IGP is not a scalable way for the interior routers within an AS to learn about the external networks. Another method that you can use is to run IBGP on all routers within the AS.

BGP Partial-Mesh and Full-Mesh Examples

The top network in Figure 8-14 shows IBGP update behavior in a partially meshed neighbor environment. Router B receives a BGP update from Router A. Router B has two IBGP neighbors, Routers C and D, but does not have an IBGP neighbor relationship with Router E. Routers C and D learn about any networks that were added or withdrawn behind Router B. Even if Routers C and D have IBGP neighbor sessions with Router E, they assume that the AS is fully meshed for IBGP and do not replicate the update and send it to Router E. Sending the IBGP update to Router E is Router B’s responsibility, because it is the router with firsthand knowledge of the networks in and beyond AS 65101. Router E does not learn of any networks through Router B and does not use Router B to reach any networks in AS 65101 or other autonomous systems behind AS 65101.

Figure 8-14. Partial-Mesh Versus Full-Mesh IBGP

In the lower portion of Figure 8-14, IBGP is fully meshed. When Router B receives an update from Router A, it updates all three of its IBGP peers, Router C, Router D, and Router E. OSPF, the IGP, is used to route the TCP segment containing the BGP update from Router A to Router E, because these two routers are not directly connected. The update is sent once to each neighbor and not duplicated by any other IBGP neighbor, which reduces unnecessary traffic. In fully meshed IBGP, each router assumes that every other internal router has a neighbor statement that points to each IBGP neighbor.

Routing Issues if BGP Not on in All Routers in a Transit Path

Figure 8-15 illustrates how routing might not work if all routers in a transit path are not running BGP.

Figure 8-15. Routing Might Not Work if BGP Not Run on All Routers in a Transit Path

In this example, Routers A, B, E, and F are the only ones running BGP. Router B has an EBGP neighbor statement for Router A and an IBGP neighbor statement for Router E. Router E has an EBGP neighbor statement for Router F and an IBGP neighbor statement for Router B. Routers C and D are not running BGP. Routers B, C, D and E are running OSPF as their IGP.

Network 10.0.0.0 is owned by AS 65101 and is advertised by Router A to Router B via an EBGP session. Router B advertises it to Router E via an IBGP session. Routers C and D never learn about this network because it is not redistributed into the local routing protocol (OSPF in this example), and Routers C and D are not running BGP. If Router E advertises this network to Router F in AS 65103, and Router F starts forwarding packets to network 10.0.0.0 through AS 65102, where would Router E send the packets?

Router E would send the packets to its BGP peer, Router B. To get to Router B, however, the packets must go through Router C or D, but those routers do not have an entry in their routing tables for network 10.0.0.0. Thus, when Router E forwards packets with a destination address in network 10.0.0.0 to either Routers C or D, those routers discard the packets.

Even if Routers C and D have a default route going to the exit points of the AS (Routers B and E), there is a good chance that when Router E sends a packet for network 10.0.0.0 to Routers C or D, those routers may send it back to Router E, which will forward it again to Routers C or D, causing a routing loop. To solve this problem, BGP must be implemented on Routers C and D.

Key Point: Routers in Transit Path Must Run BGP

All routers in the path between IBGP neighbors within an AS, known as the transit path, must also be running BGP. These IBGP sessions must be fully meshed.

In the past, best practice dictated redistributing BGP into the IGP running in an autonomous system, so that IBGP was not needed in every router in the transit path. In this case, synchronization was needed to make sure that packets did not get lost, so synchronization was on by default. As the Internet grew, the number of routes in the BGP table became too much for the IGPs to handle, so the best practice was changed to not redistributing BGP into the IGP, but instead using IBGP on all routers in the transit path. In this case, synchronization is not needed; thus, it is now off by default.

If synchronization is enabled and your autonomous system is passing traffic from one autonomous system to another, BGP should not advertise a route before all routers in your autonomous system have learned about the route via IGP. In other words, BGP and the IGP must be synchronized before networks learned from an IBGP neighbor can be used.

If synchronization is enabled, a router learning a route via IBGP waits until the IGP has propagated the route within the autonomous system and then advertises it to external peers. This is done so that all routers in the autonomous system are synchronized and can route traffic that the autonomous system advertises to other autonomous systems it can route. The BGP synchronization rule also ensures consistency of information throughout the autonomous system and avoids black holes (for example, advertising a destination to an external neighbor when not all the routers within the autonomous system can reach the destination) within the autonomous system.

Having synchronization disabled allows the routers to carry fewer routes in IGP and allows BGP to converge more quickly because it can advertise the routes as soon as it learns them.

Enable synchronization if there are routers in the BGP transit path in the autonomous system that are not running BGP (and therefore the routers do not have full-mesh IBGP within the autonomous system).

Figure 8-16 illustrates an example. Routers A, B, C, and D are all running IBGP and an IGP with each other (full-mesh IBGP). There are no matching IGP routes for the BGP routes (Routers A and B are not redistributing the BGP routes into the IGP). Routers A, B, C, and D have IGP routes to the internal networks of autonomous system 65500 but do not have IGP routes to external networks, such as 172.16.0.0.

Figure 8-16. BGP Synchronization Example

Router B advertises the route to 172.16.0.0 to the other routers in AS 65500 using IBGP.

If synchronization is on in AS 65500 in Figure 8-16, the following happens:

If synchronization is off (the default) in AS 65500 in Figure 8-16, the following happens:

In modern autonomous systems, because the size of the Internet routing table is large, redistributing from BGP into an IGP is not scalable; therefore, most modern autonomous systems run full-mesh IBGP and do not require synchronization. Some advanced BGP configuration methods, such as route reflectors and confederations, reduce the IBGP full-mesh requirements (route reflectors are discussed in Appendix E, “BGP Supplement”).

As shown in Figure 8-17, a router running BGP keeps its own table for storing BGP information received from and sent to other routers.

Figure 8-17. Router Running BGP Keeps a BGP Table, Separate from the IP Routing Table

The router can be configured to share information between the BGP table and the IP routing table.

BGP also keeps a neighbor table containing a list of neighbors with which it has a BGP connection.

For BGP to establish an adjacency, you must configure it explicitly for each neighbor. BGP forms a TCP relationship with each of the configured neighbors and keeps track of the state of these relationships by periodically sending a BGP/TCP keepalive message.

After establishing an adjacency, the neighbors exchange the BGP routes that are in their IP routing table. Each router collects these routes from each neighbor with which it successfully established an adjacency and places them in its BGP forwarding database. All routes that have been learned from each neighbor are placed in the BGP forwarding database. The best routes for each network are selected from the BGP forwarding database using the BGP route selection process (discussed in the section “The Route Selection Decision Process,” later in this chapter) and then are offered to the IP routing table.

Each router compares the offered BGP routes to any other possible paths to those networks in its IP routing table, and the best route, based on administrative distance, is installed in the IP routing table. EBGP routes (BGP routes learned from an external AS) have an administrative distance of 20. IBGP routes (BGP routes learned from within the AS) have an administrative distance of 200.

BGP defines the following message types:

After a TCP connection is established, the first message sent by each side is an open message. If the open message is acceptable, a keepalive message confirming the open message is sent back by the side that received the open message.

When the open is confirmed, the BGP connection is established, and update, keepalive, and notification messages can be exchanged.

BGP peers initially exchange their full BGP routing tables. From then on, incremental updates are sent as the routing table changes. Keepalive packets are sent to ensure that the connection is alive between the BGP peers, and notification packets are sent in response to errors or special conditions.

An open message includes the following information:

BGP does not use any transport protocol-based keepalive mechanism to determine whether peers can be reached. Instead, keepalive messages are exchanged between peers often enough to keep the hold timer from expiring. If the negotiated hold time interval is 0, periodic keepalive messages are not sent. A keepalive message consists of only a message header.

An update message has information on one path only; multiple paths require multiple messages. All the attributes in the message refer to that path, and the networks are those that can be reached through that path. An update message might include the following fields:

A BGP router sends a notification message when it detects an error condition. The BGP router closes the BGP connection immediately after sending the notification message. Notification messages include an error code, an error subcode, and data related to the error.

BGP routers send BGP update messages about destination networks to other BGP routers. As described in the previous section, update messages can contain network layer reachability information, which is a list of one or more networks (IP address prefixes), and path attributes, which are a set of BGP metrics describing the path to these networks (routes). The following are some terms defining how these attributes are implemented:

These characteristics are described in the following sections.

The AS-Path Attribute

The AS-path attribute is a well-known mandatory attribute. Whenever a route update passes through an AS, the AS number is prepended to that update (in other words, it is put at the beginning of the list) when it is advertised to the next EBGP neighbor.

Key Point: AS-Path Attribute

The AS-path attribute is the list of AS numbers that a route has traversed to reach a destination, with the number of the AS that originated the route at the end of the list.

In Figure 8-18, Router A advertises network 192.168.1.0 in AS 64520. When that route traverses AS 65500, Router C prepends its own AS number to it. When the route to 192.168.1.0 reaches Router B, it has two AS numbers attached to it. From Router B’s perspective, the path to reach 192.168.1.0 is (65500, 64520).

Figure 8-18. Router C Prepends Its Own Autonomous System Number as It Passes Routes from Router A to Router B

The same applies for 192.168.2.0 and 192.168.3.0. Router A’s path to 192.168.2.0 is (65500 65000)—it traverses AS 65500 and then AS 65000. Router C has to traverse path (65000) to reach 192.168.2.0 and path (64520) to reach 192.168.1.0.

BGP routers use the AS-path attribute to ensure a loop-free environment. If a BGP router receives a route in which its own AS is part of the AS-path attribute, it does not accept the route.

Autonomous system numbers are prepended only by routers advertising routes to EBGP neighbors. Routers advertising routes to IBGP neighbors do not change the AS-path attribute.

The Next-Hop Attribute

The BGP next-hop attribute is a well-known mandatory attribute that indicates the next-hop IP address that is to be used to reach a destination. BGP, like IGPs, is a hop-by-hop routing protocol. However, unlike IGPs, BGP routes AS-by-AS, not router-by-router, and the default next-hop is the next AS. The next-hop address for a network from another AS is an IP address of the entry point of the next AS along the path to that destination network.

Key Point: EBGP Next Hop

For EBGP, the next hop is the IP address of the neighbor that sent the update.

In Figure 8-19, Router A advertises 172.16.0.0 to Router B, with a next hop of 10.10.10.3, and Router B advertises 172.20.0.0 to Router A, with a next hop of 10.10.10.1. Therefore, Router A uses 10.10.10.1 as the next-hop attribute to get to 172.20.0.0, and Router B uses 10.10.10.3 as the next-hop attribute to get to 172.16.0.0.

Figure 8-19. BGP Next-Hop Attribute

Key Point: IBGP Next Hop

For IBGP, the protocol states that the next hop advertised by EBGP should be carried into IBGP.

Because of this rule, Router B in Figure 8-19 advertises 172.16.0.0 to its IBGP peer Router C, with a next hop of 10.10.10.3 (Router A’s address). Therefore, Router C knows that the next hop to reach 172.16.0.0 is 10.10.10.3, not 172.20.10.1, as you might expect.

It is very important, therefore, that Router C knows how to reach the 10.10.10.0 subnet, either via an IGP or a static route; otherwise, it will drop packets destined for 172.16.0.0, because it will not be able to get to the next-hop address for that network.

The IBGP neighboring router performs a recursive lookup to find out how to reach the BGP next-hop address by using its IGP entries in the routing table. For example, Router C in Figure 8-19 learns in a BGP update about network 172.16.0.0/16 from the route source 172.20.10.1, Router B, with a next hop of 10.10.10.3, Router A. Router C installs the route to 172.16.0.0/16 in the routing table with a next hop of 10.10.10.3. Assuming that Router B announces network 10.10.10.0/24 using its IGP to Router C, Router C installs that route in its routing table with a next hop of 172.20.10.1. An IGP uses the source IP address of a routing update (route source) as the next-hop address, whereas BGP uses a separate field for each network to record the next-hop address. If Router C has a packet to send to 172.16.100.1, it looks up the network in the routing table and finds a BGP route with a next hop of 10.10.10.3. Because it is a BGP entry, Router C completes a recursive lookup in the routing table for a path to network 10.10.10.3; there is an IGP route to network 10.10.10.0 in the routing table with a next hop of 172.20.10.1. Router C then forwards the packet destined for 172.16.100.1 to 172.20.10.1.

When running BGP over a multiaccess network such as Ethernet, a BGP router uses the appropriate address as the next-hop address (by changing the next-hop attribute) to avoid inserting additional hops into the path. This feature is sometimes called a third-party next hop.

For example, in Figure 8-20, assume that Routers B and C in AS 65000 are running an IGP, so that Router B can reach network 172.30.0.0 via 10.10.10.2. Router B is also running EBGP with Router A. When Router B sends a BGP update to Router A about 172.30.0.0, it uses 10.10.10.2 as the next hop, not its own IP address (10.10.10.1). This is because the network among the three routers is a multiaccess network, and it makes more sense for Router A to use Router C as a next hop to reach 172.30.0.0, rather than making an extra hop via Router B.

Figure 8-20. Multiaccess Network: Router A Has 10.10.10.2 as the Next-Hop Attribute to Reach 172.30.0.0

The third-party next-hop address issue also makes sense when you review it from an ISP perspective. A large ISP at a public peering point has multiple routers peering with different neighboring routers; it is not possible for one router to peer with every neighboring router at the major public peering points. For example, in Figure 8-20, Router B might peer with AS 64520, and Router C might peer with AS 64600; however, each router must inform the other IBGP neighbor of reachable networks from other autonomous systems. From the perspective of Router A, it must transit AS 65000 to get to networks in and behind AS 64600. Router A has a neighbor relationship with only Router B in AS 65000; however, Router B does not handle traffic going to AS 64600. Router B gets to AS 64600 through Router C, 10.10.10.2, and Router B must advertise the networks for AS 64600 to Router A, 10.10.10.3. Router B notices that Routers A and C are on the same subnet, so Router B tells Router A to install the AS 64600 networks with a next hop of 10.10.10.2, not 10.10.10.1.

However, if the common medium between routers is a nonbroadcast multiaccess (NBMA) medium, complications might occur.

For example, in Figure 8-21, Routers A, B, and C are connected by Frame Relay. Router B can reach network 172.30.0.0 via 10.10.10.2. When Router B sends a BGP update to Router A about 172.30.0.0, it uses 10.10.10.2 as the next hop, not its own IP address (10.10.10.1). A problem arises if Routers A and C do not know how to communicate directly—in other words, if Routers A and C do not have a Frame Relay map entry to reach each other, Router A does not know how to reach the next-hop address on Router C.

Figure 8-21. NBMA Network: Router A Has 10.10.10.2 as the Next-Hop Attribute to Reach 172.30.0.0, but It Might Be Unreachable

This behavior can be overridden in Router B by configuring it to advertise itself as the next-hop address for routes sent to Router A; this configuration is described in the later section “Changing the Next-Hop Attribute”.

The Local Preference Attribute

Local preference is a well-known discretionary attribute that indicates to routers in the AS which path is preferred to exit the AS.

Key Point: Higher Local Preference Is Preferred

A path with a higher local preference is preferred.

Local preference is an attribute that is configured on a router and exchanged only among routers within the same AS. The default value for local preference on a Cisco router is 100.

Key Point: Local Preference Is Only for Internal Neighbors

The term local refers to inside the AS. The local preference attribute is sent only to internal BGP neighbors; it is not passed to EBGP peers.

For example, in Figure 8-22, AS 64520 receives updates about network 172.16.0.0 from two directions. Router A and Router B are IBGP neighbors. Assume that the local preference on Router A for network 172.16.0.0 is set to 200 and that the local preference on Router B for network 172.16.0.0 is set to 150. Because the local preference information is exchanged within AS 64520, all traffic in AS 64520 addressed to network 172.16.0.0 is sent to Router A as an exit point from AS 64520.

Figure 8-22. Local Preference Attribute: Router A Is the Preferred Router to Get to 172.16.0.0

The MED Attribute

The MED attribute, also called the metric, is an optional nontransitive attribute. The MED was known as the inter-AS attribute in BGP-3.

Note

The MED attribute is called the metric in the Cisco IOS; in the output of the show ip bgp command for example, the MED is displayed in the metric column.

Key Point: MED

The MED indicates to external neighbors the preferred path into an AS. This is a dynamic way for an AS to try to influence another AS as to which way it should choose to reach a certain route if there are multiple entry points into the AS.

A lower metric value is preferred.

Unlike local preference, the MED is exchanged between autonomous systems. The MED is sent to EBGP peers; those routers propagate the MED within their AS, and the routers within the AS use the MED, but do not pass it on to the next AS. When the same update is passed on to another AS, the metric will be set back to the default of 0.

Key Point: MED and Local Preference

MED influences inbound traffic to an AS, whereas local preference influences outbound traffic from an AS.

By default, a router compares the MED attribute only for paths from neighbors in the same AS.

By using the MED attribute, BGP is the only protocol that can affect how routes are sent into an AS.

For example, in Figure 8-23, Router B has set the MED attribute to 150, and Router C has set the MED attribute to 200. When Router A receives updates from Routers B and C, it picks Router B as the best next hop to get to AS 65500, because 150 is less than 200.

Figure 8-23. MED Attribute: Router B Is the Best Next Hop to Get to AS 65500

Note

By default, the MED comparison is done only if the neighboring autonomous system is the same for all routes considered. For the router to compare metrics from neighbors coming from different autonomous systems, the bgp always-compare-med router configuration command must be configured on the router.

The Weight Attribute (Cisco Only)

The weight attribute is a Cisco-defined attribute used for the path-selection process. The weight is configured locally to a router and is not propagated to any other routers.

Key Point: Weight Attribute

The weight attribute provides local routing policy only and is not propagated to any BGP neighbors.

Routes with a higher weight are preferred when multiple routes to the same destination exist.

The weight can have a value from 0 to 65535. Paths that the router originates have a weight of 32768 by default, and other paths have a weight of 0 by default.

The weight attribute applies when using one router with multiple exit points out of an AS, as compared to the local preference attribute, which is used when two or more routers provide multiple exit points.

In Figure 8-24, Routers B and C learn about network 172.20.0.0 from AS 65250 and propagate the update to Router A. Router A has two ways to reach 172.20.0.0 and must decide which way to go. In the example, Router A is configured to set the weight of updates coming from Router B to 200 and the weight of those coming from Router C to 150. Because the weight for Router B is higher than the weight for Router C, Router A uses Router B as a next hop to reach 172.20.0.0.

Figure 8-24. Weight Attribute: Router A Uses Router B as the Next Hop to Reach 172.20.0.0

After BGP receives updates about different destinations from different autonomous systems, it decides which path to choose to reach each specific destination. Multiple paths might exist to reach a given network; these are kept in the BGP table. As paths for the network are evaluated, those determined not to be the best path are eliminated from the selection criteria but kept in the BGP table in case the best path becomes inaccessible.

BGP is not designed to perform load balancing; paths are chosen because of policy, not based on bandwidth. The BGP selection process eliminates any multiple paths until a single best path is left.

The best path is submitted to the routing table manager process and is evaluated against any other routing protocols that can also reach that network. The route from the routing protocol with the lowest administrative distance is installed in the routing table.

The decision process is based on the attributes discussed earlier in the “BGP Attributes” section. When faced with multiple routes to the same destination, BGP chooses the best route for routing traffic toward the destination. A path is not considered if it is internal, synchronization is on, and the route is not synchronized (in other words, the route is not in the IGP routing table), or if the path’s next-hop address cannot be reached. Thus, to choose the best route, BGP considers only synchronized routes with no AS loops and a valid next-hop address. The following process summarizes how BGP chooses the best route on a Cisco router:

Only the best path is entered in the routing table and propagated to the router’s BGP neighbors.

For example, suppose that there are seven paths to reach network 10.0.0.0. All paths have no AS loops and valid next-hop addresses, so all seven paths proceed to Step 1, which examines the weight of the paths. All seven paths have a weight of 0, so they all proceed to Step 2, which examines the paths’ local preference. Four of the paths have a local preference of 200, and the other three have a local preference of 100, 100, and 150. The four with a local preference of 200 continue the evaluation process to the next step. The other three remain in the BGP forwarding table but are currently disqualified as the best path.

BGP continues the evaluation process until only a single best path remains. The single best path that remains is offered to the IP routing table as the best BGP path.

Figure 8-25. BGP Maximum Paths Example

R1#show ip route bgp
B    10.0.0.0/8 [20/0] via 192.168.1.18, 00:00:41
                [20/0] via 192.168.1.50, 00:00:41

R1#show ip bgp
BGP table version is 3, local router ID is 192.168.1.49
Status codes: s suppressed, d damped, h history, * valid, > best, i ->internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.0         192.168.1.18             0             0 65301 i
*                   192.168.1.50             0             0 65301 i

In BGP, many neighbors are often configured with the same update policies (for example, they have the same filtering applied). On a Cisco Systems router, neighbors with the same update policies can be grouped into peer groups to simplify configuration and, more importantly, to make updating more efficient and improve performance. When you have many peers, this approach is highly recommended.

Instead of separately defining the same policies for each neighbor, a peer group can be defined with these policies assigned to the peer group. Individual neighbors are then made members of the peer group. The policies of the peer group are similar to a template; the template is then applied to the individual members of the peer group.

Members of the peer group inherit all the peer group’s configuration options. The router can also be configured to override these options for some members of the peer group if these options do not affect outbound updates. In other words, only options that affect the inbound updates can be overridden.

Peer groups are more efficient than defining the same policies for each neighbor, because updates are generated only once per peer group rather than repetitiously for each neighboring router; the generated update is replicated for each neighbor that is part of the peer group.

Thus, peer groups save processing time in generating the updates for all IBGP neighbors and make the router configuration easier to read and manage.

The neighbor peer-group-name peer-group router configuration command is used to create a BGP peer group. The peer-group-name is the name of the BGP peer group to be created. The peer-group-name is local to the router on which it is configured; it is not passed to any other router. You can use another syntax form of the neighbor peer-group command, the neighbor ip-address peer-group peer-group-name router configuration command, to assign neighbors as part of the group after the group has been created. Table 8-3 provides details of this command. Using this command allows you to type the peer group name instead of typing the IP addresses of individual neighbors in other commands, for example, to link a policy to the group of neighboring routers. (Note that you must enter the neighbor peer-group-name peer-group command before the router will accept this second command.)

A neighboring router can be part of only one peer group.

The clear ip bgp peer-group peer-group-name EXEC command is used to reset the BGP connections for all members of a BGP peer group. The peer-group-name is the name of the BGP peer group for which connections are to be cleared.

Use the router bgp autonomous-system global configuration command to enter BGP configuration mode, and identify the local AS in which this router belongs. In the command, autonomous-system identifies the local AS. The BGP process needs to be informed of its AS so that when BGP neighbors are configured it can determine whether they are IBGP or EBGP neighbors.

The router bgp command alone does not activate BGP on a router. You must enter at least one subcommand under the router bgp command to activate the BGP process on the router.

Only one instance of BGP can be configured on a router at a time. For example, if you configure your router in AS 65000 and then try to configure the router bgp 65100 command, the router informs you that you are currently configured for AS 65000.

Use the neighbor {ip-address | peer-group-name} remote-as autonomous-system router configuration command to activate a BGP session for external and internal neighbors and to identify a peer router with which the local router will establish a session, as described in Table 8-4.

The IP address used in the neighbor remote-as command is the destination address for all BGP packets going to this neighboring router. For a BGP relationship to be established, this address must be reachable, because BGP attempts to establish a TCP session and exchange BGP updates with the device at this IP address.

The value placed in the autonomous-system field of the neighbor remote-as command determines whether the communication with the neighbor is an EBGP or IBGP session. If the autonomous-system field configured in the router bgp command is identical to the field in the neighbor remote-as command, BGP initiates an internal session, and the IP address specified does not have to be directly connected. If the field values are different, BGP initiates an external session, and the IP address specified must be directly connected, by default.

The network shown in Figure 8-26 uses the BGP neighbor commands; the configurations of Routers A, B, and C are shown in Examples 8-2, 8-3, and 8-4. Router A in AS 65101 has two neighbor statements. In the first statement, neighbor 10.2.2.2 (Router B) is in the same AS as Router A (65101); this neighbor statement defines Router B as an IBGP neighbor. Autonomous system 65101 runs EIGRP between all internal routers. Router A has an EIGRP path to reach IP address 10.2.2.2; as an IBGP neighbor, Router B can be multiple routers away from Router A.

Figure 8-26. BGP Network with IBGP and EBGP Neighbor Relationships

router bgp 65101
  neighbor 10.2.2.2 remote-as 65101
  neighbor 192.168.1.1 remote-as 65102

router bgp 65101
  neighbor 10.1.1.2 remote-as 65101

router bgp 65102
  neighbor 192.168.1.2 remote-as 65101

Router A in Figure 8-26 knows that Router C is an external neighbor because the neighbor statement for Router C uses AS 65102, which is different from the AS number of Router A, AS 65101. Router A can reach AS 65102 via 192.168.1.1, which is directly connected to Router A.

To disable (administratively shut down) an existing BGP neighbor or peer group, use the neighbor {ip-address | peer-group-name} shutdown router configuration command. To enable a previously existing neighbor or peer group that had been disabled using the neighbor shutdown command, use the no neighbor {ip-address | peer-group-name} shutdown router configuration command. If you want to implement major policy changes to a neighboring router and you change multiple parameters, you must administratively shut down the neighboring router, implement the changes, and then bring the neighboring router back up.

The BGP neighbor statement tells the BGP process the destination IP address of each update packet. The router must decide which IP address to use as the source IP address in the BGP routing update.

When a router creates a packet, whether it is a routing update, a ping, or any other type of IP packet, the router does a lookup in the routing table for the destination address; the routing table lists the appropriate interface to get to the destination address. The address of this outbound interface is used as that packet’s source address by default.

For BGP packets, this source IP address must match the address in the corresponding neighbor statement on the other router. (In other words, the other router must have a BGP relationship with the packet’s source IP address.) Otherwise, the routers will not be able to establish the BGP session, and the packet will be ignored. BGP does not accept unsolicited updates; it must be aware of every neighboring router and have a neighbor statement for it.

For example, in Figure 8-27, assume that Router D uses the neighbor 10.3.3.1 remote-as 65102 command to establish a relationship with Router A. If Router A is sending the BGP packets to Router D via Router B, the source IP address of the packets will be 10.1.1.1. When Router D receives a BGP packet via Router B, it does not recognize the sender of the BGP packet, because 10.1.1.1 is not configured as a neighbor of Router D. Therefore, the IBGP session between Router A and Router D cannot be established.

Figure 8-27. BGP Source Address Must Match the Address in the neighbor Command

A solution to this problem is to establish the IBGP session using a loopback interface when there are multiple paths between the IBGP neighbors.

If the IP address of a loopback interface is used in the neighbor command, some extra configuration must be done on the neighbor router. You must tell BGP to use a loopback interface address rather than a physical interface address as the source address for all BGP packets, including those that initiate the BGP neighbor TCP connection. Use the neighbor {ip-address | peer-group-name} update-source loopback interface-number router configuration command to cause the router to use the address of the specified loopback interface as the source address for BGP connections to this neighbor.

The update-source option in the neighbor command overrides the default source IP address for BGP packets. This peering arrangement also adds resiliency to the IBGP sessions, because the routers are not tied into a physical interface, which might go down for any number of reasons. For example, if a BGP router is using a neighbor address that is assigned to a specific physical interface on another router, and that interface goes down, the router pointing at that address loses its BGP session with that other BGP neighbor. If, instead, the router peers with the loopback interface of the other router, the BGP session is not lost, because the loopback interface is always available as long as the router itself does not fail.

To peer with the loopback interface of an IBGP neighbor, configure each router with a neighbor command using the loopback address of the other neighbor. Both routers must have a route to the loopback address of the other neighbor in their routing table; check to ensure that both routers are announcing their loopback addresses into their local routing protocol. The neighbor update-source command is necessary for both routers.

For example, in Figure 8-28, Router B has Router A as an EBGP neighbor and Router C as an IBGP neighbor. The configurations for Routers B and C are shown in Examples 8-5 and 8-6. The only reachable address that Router B can use to establish a BGP neighbor relationship with Router A is the directly connected address 172.16.1.1. However, Router B has multiple paths to reach Router C, an IBGP neighbor. All networks, including the IP network for Router C’s loopback interface, can be reached from Router B because these two routers exchange EIGRP updates. (Router B and Router A do not exchange EIGRP updates.) The neighbor relationship between Routers B and C is not tied to a physical interface, because each router peers with the loopback interface on the other router and uses its loopback address as the BGP source IP address. If Router B instead peered with 10.1.1.2 on Router C and that interface went down, the BGP neighbor relationship would be lost.

Figure 8-28. BGP Sample Network Using Loopback Addresses

router bgp 65101
  neighbor 172.16.1.1 remote-as 65100
  neighbor 192.168.3.3 remote-as 65101
  neighbor 192.168.3.3 update-source loopback0
!
router eigrp 1
  network 10.0.0.0
  network 192.168.2.0

router bgp 65101
  neighbor 192.168.1.1 remote-as 65102
  neighbor 192.168.2.2 remote-as 65101
  neighbor 192.168.2.2 update-source loopback0
!
router eigrp 1
  network 10.0.0.0
  network 192.168.3.0

If Router B points at loopback address 192.168.3.3 on Router C and Router C points at loopback address 192.168.2.2 on Router B, but neither uses the neighbor update-source command, a BGP session is not established between these routers. Without this command, Router B will send a BGP open packet to Router C with a source IP address of either 10.1.1.1 or 10.2.2.1. Router C will examine the source IP address and attempt to match it against its list of known neighbors; because Router C will not find a match, it will not respond to the open message from Router B.

When peering with an external neighbor, the only address that an EBGP router can reach without further configuration is the interface that is directly connected to that EBGP router. Because IGP routing information is not exchanged with external peers, the router must point to a directly connected address for external neighbors. A loopback interface is never directly connected. Therefore, if you want to peer with a loopback interface instead, you have to add a static route to the loopback pointing to the physical address of the directly connected network (the next-hop address). You must also enable multihop EBGP, with the neighbor {ip-address | peer-group-name} ebgp-multihop [ttl] router configuration command.

This command allows the router to accept and attempt BGP connections to external peers residing on networks that are not directly connected. This command increases the default of one hop for EBGP peers by changing the default Time to Live (TTL) value of 1 and therefore allowing routes to the EBGP loopback address. By default, the TTL is set to 255 with this command. This command is of value when redundant paths exist between EBGP neighbors.

For example, in Figure 8-29, Router A in AS 65102 has two paths to Router B in AS 65101. If Router A uses a single neighbor statement that points to 192.168.1.18 on Router B and that link goes down, the BGP session between these autonomous systems is lost, and no packets pass from one AS to the next, even though another link exists. This problem can be solved if Router A uses two neighbor statements pointing to 192.168.1.18 and 192.168.1.34 on Router B. However, every BGP update that Router A receives will be sent to Router B twice because of the two neighbor statements.

Figure 8-29. EBGP Multihop Is Required if Loopback Is Used Between External Neighbors

The configurations of Routers A and B are shown in Examples 8-7 and 8-8. As these configurations show, each router instead points to the loopback address of the other router and uses its loopback address as the source IP address for its BGP updates. Because an IGP is not used between autonomous systems, neither router can reach the loopback of the other router without assistance. Each router needs to use two static routes to define the paths available to reach the loopback address of the other router. The neighbor ebgp-multihop command must also be configured to change the default setting of BGP and inform the BGP process that this neighbor IP address is more than one hop away. In these examples, the commands used on Routers A and B inform BGP that the neighbor address is two hops away.

router bgp 65102
  neighbor 172.16.1.1 remote-as 65101
  neighbor 172.16.1.1 update-source loopback0
  neighbor 172.16.1.1 ebgp-multihop 2
ip route 172.16.1.1 255.255.255.255 192.168.1.18
ip route 172.16.1.1 255.255.255.255 192.168.1.34

router bgp 65101
  neighbor 172.17.1.1 remote-as 65102
  neighbor 172.17.1.1 update-source loopback0
  neighbor 172.17.1.1 ebgp-multihop 2
ip route 172.17.1.1 255.255.255.255 192.168.1.17
ip route 172.17.1.1 255.255.255.255 192.168.1.33

As discussed in the section “The Next-Hop Attribute” earlier in this chapter, it is sometimes necessary (for example, in an NBMA environment) to override a router’s default behavior and force it to advertise itself as the next-hop address for routes sent to a neighbor.

An internal protocol, such as RIP, EIGRP, or OSPF, always uses the source IP address of a routing update as the next-hop address for each network from that update that is placed in the routing table. The neighbor {ip-address | peer-group-name} next-hop-self router configuration command is used to force BGP to use the source IP address of the update as the next hop for each network it advertises to the neighbor, rather than letting the protocol choose the next-hop address to use. This command is described in Table 8-5.

For example, in Figure 8-30, Router B views all routes learned from AS 65100 as having a next hop of 172.16.1.1, which is the entrance to AS 65100 for Router B. When Router B announces those networks to its IBGP neighbors in AS 65101, the BGP default setting is to announce that the next hop to reach each of those networks is the entrance to AS 65100 (172.16.1.1), because BGP is an AS-by-AS routing protocol. With the default settings, a BGP router needs to reach the 172.16.1.1 next hop to reach networks in or behind AS 65100. Therefore, the network that represents 172.16.1.1 will have to be advertised in the internal routing protocol.

Figure 8-30. neighbor next-hop-self Command Allows Router B to Advertise Itself as the Next Hop

In this example, however, the configuration for Router B is as shown in Example 8-9. Router B uses the neighbor next-hop-self command to change the default BGP next-hop settings. After this command is given, Router B advertises a next hop of 192.168.2.2 (the IP address of its loopback interface) to its IBGP neighbor, because that is the source IP address of the routing update to its IBGP neighbor (set with the neighbor update-source command).

router bgp 65101
  neighbor 172.16.1.1 remote-as 65100
  neighbor 192.168.3.3 remote-as 65101
  neighbor 192.168.3.3 update-source loopback0
  neighbor 192.168.3.3 next-hop-self
!
router eigrp 1
  network 10.0.0.0
  network 192.168.2.0

When Router C announces networks that are in or behind AS 65101 to its EBGP neighbors, such as Router D in AS 65102, Router C, by default, uses its outbound interface address 192.168.1.2 as the next-hop address. This address is the default next-hop address for Router D to use to reach any networks in or behind AS 65101.

Use the network network-number [mask network-mask] [route-map map-tag] router configuration command to permit BGP to advertise a network if it is present in the IP routing table, as described in Table 8-6.

The network command allows classless prefixes; the router can advertise individual subnets, networks, or supernets. Note that the prefix must exactly match (address and mask) an entry in the IP routing table. A static route to null 0 might be used to create a supernet entry in the IP routing table.

Before Cisco IOS Software Release 12.0, there was a limit of 200 network commands per BGP router; this limit has now been removed. The router’s resources, such as the configured NVRAM or RAM, determine the maximum number of network commands that you can now use.

The sole purpose of the network command is to notify BGP which networks to advertise. If the mask is not specified, this command announces only the classful network number; at least one subnet of the specified major network must be present in the IP routing table to allow BGP to start announcing the classful network as a BGP route. However, if you specify the network-mask, an exact match to the network (both address and mask) must exist in the routing table for the network to be advertised.

Before BGP announces a route, it checks to see whether it can reach it. For example, if you configure network 192.168.1.1 mask 255.255.255.0 by mistake, BGP looks for 192.168.1.1/24 in the routing table. It might find 192.168.1.0/24 or 192.168.1.1/32, but it will never find 192.168.1.1/24. Because the routing table does not contain a specific match to the network, BGP does not announce the 192.168.1.1/24 network to any neighbors.

In another example, if you configure network 192.168.0.0 mask 255.255.0.0 to advertise a CIDR block, BGP looks for 192.168.0.0/16 in the routing table. It might find 192.168.1.0/24 or 192.168.1.1/32; however, if it never finds 192.168.0.0/16, BGP does not announce the 192.168.0.0/16 network to any neighbors. In this case, you can configure the static route ip route 192.168.0.0 255.255.0.0 null0 toward the null interface so that BGP can find an exact match in the routing table. After finding an exact match in the routing table, BGP announces the 192.168.0.0/16 network to any neighbors.

You can configure BGP neighbor authentication on a router so that the router authenticates the source of each routing update packet that it receives. This is accomplished by the exchange of an authenticating key (sometimes referred to as a password) that is known to both the sending and the receiving router. BGP supports Message Digest 5 (MD5) neighbor authentication. MD5 sends a “message digest” (also called a “hash”) which is created using the key and a message. The message digest is then sent instead of the key. The key itself is not sent, preventing it from being read by someone eavesdropping on the line while it is being transmitted.

To enable MD5 authentication on a TCP connection between two BGP peers, use the neighbor {ip-address | peer-group-name} password string router configuration command. Table 8-7 describes the neighbor password command parameters.

When MD5 authentication is configured between two BGP peers, each segment sent on the TCP connection between the peers is verified. MD5 authentication must be configured with the same password on both BGP peers; otherwise, the connection between them will not be made. Configuring MD5 authentication causes the Cisco IOS Software to generate and check the MD5 digest of every segment sent on the TCP connection.

If a router has a password configured for a neighbor, but the neighbor router does not have a password configured, a message such as the following will appear on the console when the routers attempt to send BGP messages between themselves:

%TCP-6-BADAUTH: No MD5 digest from 10.1.0.2(179) to 10.1.0.1(20236)

Similarly, if the two routers have different passwords configured, a message such as the following will appear on the screen:

%TCP-6-BADAUTH: Invalid MD5 digest from 10.1.0.1(12293) to 10.1.0.2(179)

If you configure or change the password or key used for MD5 authentication between two BGP peers, the local router will not tear down the existing session after you configure the password. The local router will attempt to maintain the peering session using the new password until the BGP holddown timer expires. The default time period is 180 seconds. If the password is not entered or changed on the remote router before the holddown timer expires, the session will time out.

Examples 8-10 and 8-11 show the configurations for the routers in Figure 8-31. MD5 authentication is configured for the BGP peering session between Routers A and B. The same password must be configured on the remote peer before the holddown timer expires.

Figure 8-31. BGP Neighbor Authentication

router bgp 65000
  neighbor 10.64.0.2 remote-as 65500
  neighbor 10.64.0.2 password v61ne0qke1336

router bgp 65500
  neighbor 10.64.0.1 remote-as 65000
  neighbor 10.64.0.1 password v61ne0qke1336

Recall that the BGP synchronization rule states that that a BGP router should not use, or advertise to an external neighbor, a route learned by IBGP, unless that route is local or is learned from the IGP.

BGP synchronization is disabled by default in Cisco IOS Software Release 12.2(8)T and later; it was on by default in earlier Cisco IOS Software releases. With the default of synchronization disabled, BGP can use and advertise to an external BGP neighbor routes learned from an IBGP neighbor that are not present in the local routing table.

Use the synchronization router configuration command to enable BGP synchronization so that a router will not advertise routes in BGP until it learns them in an IGP. The no synchronization router configuration command disables synchronization if it was enabled.

BGP can potentially handle huge volumes of routing information. When a BGP policy configuration change occurs (such as when access lists, timers, or attributes are changed), the router cannot go through the huge table of BGP information and recalculate which entry is no longer valid in the local table. Nor can the router determine which route or routes, already advertised, should be withdrawn from a neighbor. There is an obvious risk that the first configuration change will immediately be followed by a second, which would cause the whole process to start all over again. To avoid such a problem, the Cisco IOS Software applies changes on only those updates received or transmitted after the BGP policy configuration change has been performed. The new policy, enforced by the new filters, is applied only on routes received or sent after the change.

If the network administrator wants the policy change to be applied on all routes, he or she must trigger an update to force the router to let all routes pass through the new filter. If the filter is applied to outgoing information, the router has to resend the BGP table through the new filter. If the filter is applied to incoming information, the router needs its neighbor to resend its BGP table so that it passes through the new filter.

There are three ways to trigger an update:

The sections that follow discuss all three methods of triggering an update in greater detail.

Received route refresh capability from peer.

This section provides some configuration examples using the commands discussed.

Basic BGP Example

Figure 8-32 shows a sample BGP network. Example 8-12 provides the configuration of Router A in Figure 8-32, and Example 8-13 provides the configuration of Router B.

Figure 8-32. Sample BGP Network

Example 8-12. Configuration of Router A in Figure 8-32

router bgp 64520
  neighbor 10.1.1.1 remote-as 65000
  network 172.16.0.0

Example 8-13. Configuration of Router B in Figure 8-32

router bgp 65000
  neighbor 10.1.1.2 remote-as 64520
  network 172.17.0.0

In this example, Routers A and B define each other as BGP neighbors, and start an EBGP session. Router A advertises the network 172.16.0.0/16, and Router B advertises the network 172.17.0.0/16.

Peer Group Example

In Figure 8-33, AS 65100 has four routers running IBGP. All of these IBGP neighbors are peering with each others’ loopback 0 interface (shown in the figure) and are using the IP address of their loopback 0 interface as the source IP address for all BGP packets. Each router is using one of its own IP addresses as the next-hop address for each network advertised through BGP. These are outbound policies.

Figure 8-33. Peer Groups Simplify Configuration

Example 8-14 shows the configuration of Router C when it is not using a peer group.

Example 8-14. Configuration of Router C in Figure 8-33 Without Using a Peer Group

router bgp 65100
  neighbor 192.168.24.1 remote-as 65100
  neighbor 192.168.24.1 update-source loopback 0
  neighbor 192.168.24.1 next-hop-self
  neighbor 192.168.24.1 distribute-list 20 out
  neighbor 192.168.25.1 remote-as 65100
  neighbor 192.168.25.1 update-source loopback 0
  neighbor 192.168.25.1 next-hop-self
  neighbor 192.168.25.1 distribute-list 20 out
  neighbor 192.168.26.1 remote-as 65100
  neighbor 192.168.26.1 update-source loopback 0
  neighbor 192.168.26.1 next-hop-self
  neighbor 192.168.26.1 distribute-list 20 out

Router C has an outbound distribution list associated with each IBGP neighbor. This outbound filter performs the same function as the distribute-list command you use for internal routing protocols; however, when used for BGP, it is linked to a specific neighbor. For example, the ISP behind Router C might be announcing private address space to Router C, and Router C does not want to pass these networks to other routers running BGP in AS 65100.

To accomplish this, access-list 20 might look like the following:

• access-list 20 deny 10.0.0.0 0.255.255.255

• access-list 20 deny 172.16.0.0 0.31.255.255

• access-list 20 deny 192.168.0.0 0.0.255.255

• access-list 20 permit any

As shown in Example 8-14, all IBGP neighbors have the outbound distribution list linked to them individually. If Router C receives a change from AS 65101, it must generate an individual update for each IBGP neighbor and run each update against distribute-list 20. If Router C has a large number of IBGP neighbors, the processing power needed to inform the IBGP neighbors of the changes in AS 65101 could be extensive.

Example 8-15 shows the configuration of Router C when it is using a peer group called internal. The neighbor remote-as, neighbor update-source, neighbor next-hop-self, and neighbor distribute-list 20 out commands are all linked to peer group internal, which in turn is linked to each of the IBGP neighbors. If Router C receives a change from AS 65101, it creates a single update and processes it through distribute-list 20 once. The update is replicated for each neighbor that is part of the internal peer group. This action saves processing time in generating the updates for all IBGP neighbors. Thus, the use of peer groups can improve efficiency when processing updates for BGP neighbors that have a common outbound BGP policy.

Example 8-15. Configuration of Router C in Figure 8-33 Using a Peer Group

router bgp 65100
  neighbor internal peer-group
  neighbor internal remote-as 65100
  neighbor internal update-source loopback 0
  neighbor internal next-hop-self
  neighbor internal distribute-list 20 out
  neighbor 192.168.24.1 peer-group internal
  neighbor 192.168.25.1 peer-group internal
  neighbor 192.168.26.1 peer-group internal

Adding a new neighbor with the same policies as the other IBGP neighbors to Router C when it is using a peer group requires adding only a single neighbor statement to link the new neighbor to the peer group. Adding that same neighbor to Router C if it does not use a peer group requires four neighbor statements.

Using a peer group also makes the configuration easier to read and change. If you need to add a new policy, such as a route map, to all IBGP neighbors on Router C, and you are using a peer group, you need only to link the route map to the peer group. If Router C does not use a peer group, you need to add the new policy to each neighbor.

IBGP and EBGP Example

Figure 8-34 shows another BGP example.

Figure 8-34. IBGP and EBGP Example

Example 8-16 shows the configuration for Router B in Figure 8-34 (note that line numbers have been added to this example to simplify the discussion). The first two commands under the router bgp 65000 command establish that Router B has the following two BGP neighbors:

• Router A in AS 64520

• Router C in AS 65000

Example 8-16. Configuration of Router B in Figure 8-34

1.    router bgp 65000
2.    neighbor 10.1.1.2 remote-as 64520
3.    neighbor 192.168.2.2 remote-as 65000
4.    neighbor 192.168.2.2 update-source loopback 0
5.    neighbor 192.168.2.2 next-hop-self
6.    network 172.16.10.0 mask 255.255.255.0
7.    network 192.168.1.0
8.    network 192.168.3.0
9.    no synchronization

From the perspective of Router B, Router A is an EBGP neighbor, and Router C is an IBGP neighbor.

The neighbor statement on Router B for Router A is pointing to the directly connected IP address to reach Router A. However, the neighbor statement on Router B for Router C points to Router C’s loopback interface. Router B has multiple paths to reach Router C. If Router B pointed to the 192.168.3.2 IP address of Router C and that interface went down, Router B would be unable to reestablish the BGP session until the link came back up. By pointing to the loopback interface of Router C, the link stays established as long as any path to Router C is available. (Router C should also point to Router B’s loopback address in its configuration.)

Line 4 in the configuration forces Router B to use its loopback 0 address, 192.168.2.1, as the source IP address when sending an update to Router C, 192.168.2.2.

In line 5, Router B changes the next-hop address for networks that can be reached through it. The default next-hop for networks from AS 64520 is 10.1.1.2. With the neighbor next-hop-self command, Router B sets the next-hop address to the source IP address of the routing update, which is Router B’s loopback 0 address, as set by the neighbor update-source command.

Lines 6, 7, and 8 tell BGP which networks to advertise. Line 6 contains a subnet of a Class B address using the mask option. Lines 7 and 8 contain two network statements for the two Class C networks that connect Routers B and C. The default mask for these networks is 255.255.255.0, so it is not needed in the commands.

In line 9, synchronization is disabled (this command is not needed if the router is running Cisco IOS Software Release 12.2(8)T or later, because then synchronization is off by default). If Router A is advertising 172.20.0.0 in BGP, Router B receives that route and advertises it to Router C. Because synchronization is off, Router C can use this route. If Router C had EBGP neighbors of its own and Router B wanted to use Router C as the path to those networks, synchronization on Router B would also need to be off. In this network, synchronization can be off because all the routers within the transit path in AS are running IBGP.

Use the show ip bgp command to display the BGP topology database (the BGP table).

Example 8-17 is a sample output for the show ip bgp command. The status codes are shown at the beginning of each line of output, and the origin codes are shown at the end of each line. In this output, most of the rows have an asterisk (*) in the first column. This means that the next-hop address (in the fifth column) is valid. The next-hop address is not always the router that is directly connected to this router. Other options for the first column are as follows:

RouterA#show ip bgp
BGP table version is 14, local router ID is 172.31.11.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-
  failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.0.0/24      0.0.0.0                  0         32768 i
* i                 10.1.0.2                 0    100      0 i
*> 10.1.1.0/24      0.0.0.0                  0         32768 i
*>i10.1.2.0/24      10.1.0.2                 0    100      0 i
*> 10.97.97.0/24    172.31.1.3                             0 64998 64997 i
*                   172.31.11.4                            0 64999 64997 i
* i                 172.31.11.4              0    100      0 64999 64997 i
*> 10.254.0.0/24    172.31.1.3               0             0 64998 i
*                   172.31.11.4                            0 64999 64998 i
* i                 172.31.1.3               0    100      0 64998 i
r> 172.31.1.0/24    172.31.1.3               0             0 64998 i
r                   172.31.11.4                            0 64999 64998 i
r i                 172.31.1.3               0    100      0 64998 i
*> 172.31.2.0/24    172.31.1.3               0             0 64998 i
<output omitted>

A greater-than sign (>) in the second column indicates the best path for a route selected by BGP; this route is offered to the IP routing table.

The third column is either blank or has an i in it. If it is blank, BGP learned that route from an external peer. If it has an i, an IBGP neighbor advertised this route to this router.

The fourth column lists the networks that the router learned.

The fifth column lists all the next-hop addresses for each route. This next-hop address column might contain 0.0.0.0, which signifies that this router originated the route.

The next three columns list three BGP path attributes associated with the path: metric (MED), local preference, and weight.

The column with the “Path” header may contain a sequence of autonomous systems in the path. From left to right, the first AS listed is the adjacent AS from which this network was learned. The last number (the rightmost AS number) is this network’s originating AS. The AS numbers between these two represent the exact path that a packet takes back to the originating AS. If the path column is blank, the route is from the current AS.

The last column signifies how this route was entered into BGP on the original router (the origin attribute). If the last column has an i in it, the original router probably used a network command to introduce this network into BGP. The character e signifies that the original router learned this network from EGP, which is the historic predecessor to BGP. A question mark (?) signifies that the original BGP process cannot absolutely verify this network’s availability, because it is redistributed from an IGP into the BGP process.

Use the show ip bgp rib-failure command to display BGP routes that were not installed in the RIB, and the reason that they were not installed. In Example 8-18 the displayed routes were not installed because a route or routes with a better administrative distance already existed in the RIB.

RouterA#show ip bgp rib-failure
Network            Next Hop                      RIB-failure   RIB-NH Matches
172.31.1.0/24      172.31.1.3          Higher admin distance              n/a
172.31.11.0/24     172.31.11.4         Higher admin distance              n/a

The show ip bgp summary command is one way to verify the BGP neighbor relationship. Example 8-19 presents sample output from this command. Here are some of the highlights:

RouterA#show ip bgp summary
BGP router identifier 10.1.1.1, local AS number 65001
BGP table version is 124, main routing table version 124
9 network entries using 1053 bytes of memory
22 path entries using 1144 bytes of memory
12/5 BGP path/bestpath attribute entries using 1488 bytes of memory
6 BGP AS-PATH entries using 144 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 3829 total bytes of memory
BGP activity 58/49 prefixes, 72/50 paths, scan interval 60 secs

Neighbor     V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

10.1.0.2     4 65001      11      11      124    0    0 00:02:28        8
172.31.1.3   4 64998      21      18      124    0    0 00:01:13        6
172.31.11.4  4 64999      11      10      124    0    0 00:01:11        6

Example 8-20 shows partial output from the debug ip bgp updates command on Router A after the clear ip bgp command is issued to clear BGP sessions with its IBGP neighbor 10.1.0.2.

RouterA#debug ip bgp updates
Mobile router debugging is on for address family: IPv4 Unicast
RouterA#clear ip bgp 10.1.0.2
<output omitted>
*May 24 11:06:41.309: %BGP-5-ADJCHANGE: neighbor 10.1.0.2 Up
*May 24 11:06:41.309: BGP(0): 10.1.0.2 send UPDATE (format) 10.1.1.0/24, next 10.1.0.1,
   metric 0, path Local
*May 24 11:06:41.309: BGP(0): 10.1.0.2 send UPDATE (prepend, chgflags: 0x0) 10.1.0.0/24,
   next 10.1.0.1, metric 0, path Local
*May 24 11:06:41.309: BGP(0): 10.1.0.2 NEXT_HOP part 1 net 10.97.97.0/24, next 172.31.11.4
*May 24 11:06:41.309: BGP(0): 10.1.0.2 send UPDATE (format) 10.97.97.0/24, next
   172.31.11.4, metric 0, path 64999 64997
*May 24 11:06:41.309: BGP(0): 10.1.0.2 NEXT_HOP part 1 net 172.31.22.0/24, next 172.31.11.4
*May 24 11:06:41.309: BGP(0): 10.1.0.2 send UPDATE (format) 172.31.22.0/24, next
   172.31.11.4, metric 0, path 64999
<output omitted>
*May 24 11:06:41.349: BGP(0): 10.1.0.2 rcvd UPDATE w/ attr: nexthop 10.1.0.2, origin i,
   localpref 100, metric 0
*May 24 11:06:41.349: BGP(0): 10.1.0.2 rcvd 10.1.2.0/24
*May 24 11:06:41.349: BGP(0): 10.1.0.2 rcvd 10.1.0.0/24

After the neighbor adjacency is reestablished, Router A creates and sends updates to 10.1.0.2. The first update highlighted in the example, 10.1.1.0/24, next 10.1.0.1, is an update about network 10.1.1.0/24, with a next hop of 10.1.0.1, which is Router A’s address. The second update highlighted in the example, 10.97.97.0/24, next 172.31.11.4, is an update about network 10.97.97.0/24, with a next hop of 172.31.11.4, which is the address of one of Router A’s EBGP neighbors. The EBGP next-hop address is being carried into IBGP.

Router A later receives updates from 10.1.0.2. The update highlighted in the example contains a path to two networks, 10.1.2.0/24 and 10.1.0.0/24.

After the TCP handshake is complete, the BGP application tries to set up a session with the neighbor. BGP is a state machine that takes a router through the following states with its neighbors:

After you enter the neighbor command, BGP starts in the idle state, and the BGP process checks that it has a route to the IP address listed. BGP should be in the idle state for only a few seconds. If BGP does not find a route to the neighboring IP address, it stays in the idle state. If it finds a route, it goes to the connect state when the TCP handshaking synchronize acknowledge (SYN ACK) packet returns (when the TCP three-way handshake is complete). After the TCP connection is set up, the BGP process creates a BGP open message and sends it to the neighbor. After BGP dispatches this open message, the BGP peering session changes to the open sent state. If there is no response for 5 seconds, the state changes to the active state. If a response does come back in a timely manner, BGP goes to the open confirm state and starts scanning (evaluating) the routing table for the paths to send to the neighbor. When these paths have been found, BGP then goes to the established state and begins routing between the neighbors.

The BGP state is shown in the last column of the show ip bgp summary command output.

%BGP-3-NOTIFICATION: sent to neighbor 172.31.1.3 2/2 (peer in wrong AS) 2 bytes FDE6
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0104 FDE6 00B4 AC1F 0203 1002 0601 0400
  0100 0102 0280 0002 0202 00

%BGP-3-NOTIFICATION: received from neighbor 172.31.1.1 2/2 (peer in wrong AS) 2 bytes
  FDE6

RouterA#show ip bgp neighbors
BGP neighbor is 172.31.1.3,  remote AS 64998, external link
  BGP version 4, remote router ID 172.31.2.3
  BGP state = Established, up for 00:19:10
  Last read 00:00:10, last write 00:00:10, hold time is 180, keepalive interval is 60 seconds
  Neighbor capabilities:
    Route refresh: advertised and received(old & new)
    Address family IPv4 Unicast: advertised and received
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
                         Sent       Rcvd
    Opens:                  7          7
    Notifications:          0          0
    Updates:               13         38
<output omitted>

Unlike local routing protocols, BGP was never designed to choose the quickest path. Rather, it was designed to manipulate traffic flow to maximize or minimize bandwidth use. Figure 8-35 demonstrates a common situation that can result when using BGP without any policy manipulation.

Figure 8-35. BGP Network Without Policy Manipulation

Using default settings for path selection in BGP might cause uneven use of bandwidth. In Figure 8-35, Router A in AS 65001 is using 60 percent of its outbound bandwidth to Router X in 65004, but Router B is using only 20 percent of its outbound bandwidth. If this utilization is acceptable to the administrator, no manipulation is needed. But if the load averages 60 percent and has temporary bursts above 100 percent of the bandwidth, this situation will cause lost packets, higher latency, and higher CPU usage because of the number of packets being routed. When another link to the same location is available and is not heavily used, it makes sense to divert some of the traffic to the other path. To change outbound path selection from AS 65001, the local preference attribute must be manipulated.

Recall that a higher local preference is preferred. To determine which path to manipulate, the administrator performs a traffic analysis on Internet-bound traffic by examining the most heavily visited addresses, web pages, or domain names. This information can usually be found by examining network management records or firewall accounting information.

Assume that in Figure 8-35, 35 percent of all traffic from AS 65001 has been going to www.cisco.com. The administrator can obtain the Cisco address or AS number by performing a reverse Domain Name System (DNS) lookup or by going to ARIN (at www.arin.net) and looking up the AS number of Cisco Systems or the address space assigned to the company. After this information has been determined, the administrator can use route maps to change the local preference to manipulate path selection for the Cisco network.

Using a route map, Router B can announce, to all routers within AS 65001, all networks associated with the Cisco Systems AS with a higher local preference than Router A announces for those networks. Because routers running BGP prefer routes with the highest local preference, other BGP routers in AS 65001 send all traffic destined for the Cisco Systems AS to exit AS 65001 via Router B. The outbound load for Router B increases from its previous load of 20 percent to account for the extra traffic from AS 65001 destined for the Cisco networks. The outbound load for Router A, which was originally 60 percent, should decrease. This change will make the outbound load on both links more balanced. The administrator should monitor the outbound loads and adjust the configuration accordingly as traffic patterns change over time.

Just as there was a loading issue outbound from AS 65001, there can be a similar problem inbound. For example, if the inbound load to Router B has a much higher utilization than the inbound load to Router A, the BGP MED attribute can be used to manipulate how traffic enters AS 65001. Router A in AS 65001 can announce a lower MED for network 192.168.25.0/24 to AS 65004 than Router B announces. This MED recommends to the next AS how to enter AS 65001. However, MED is not considered until later in the BGP path-selection process than local preference. Therefore, if AS 65004 prefers to leave its AS via Router Y (to Router B in AS 65001), Router Y should be configured to announce a higher local preference to the BGP routers in AS 65004 for network 192.168.25.0/24 than Router X announces. The local preference that Routers X and Y advertise to other BGP routers in AS 65004 is evaluated before the MED coming from Routers A and B. MED is considered a recommendation, because the receiving AS can override it by manipulating another variable that is considered before the MED is evaluated.

As another example using Figure 8-35, assume that 55 percent of all traffic is going to the 192.168.25.0/24 subnet (on Router A). The inbound utilization to Router A is averaging only 10 percent, but the inbound utilization to Router B is averaging 75 percent. The problem is that if the inbound load for Router B spikes to more than 100 percent and causes the link to flap, all the sessions crossing that link could be lost. For example, if these sessions were purchases being made on AS 65001 web servers, revenue would be lost, which is something administrators want to avoid. If AS 65001 were set to prefer to have all traffic that is going to 192.168.25.0/24 enter through Router A, the load inbound on Router A should increase, and the load inbound on Router B should decrease.

If load averages less than 50 percent for an outbound or inbound case, path manipulation might not be needed. However, as soon as a link starts to reach its capacity for an extended period of time, either more bandwidth is needed or path manipulation should be considered. The administrator should monitor the inbound loads and adjust the configuration accordingly as traffic patterns change over time.

Local preference is used only within an AS between IBGP speakers to determine the best path to leave the AS to reach an outside network. The local preference is set to 100 by default; higher values are preferred.

Changing Local Preference for All Routes

The bgp default local-preference value router configuration command changes the default local preference to the value specified; all BGP routes that are advertised include this local preference value. The value can be set to a number between 0 and 4294967295.

Manipulating the default local preference can have an immediate and dramatic effect on traffic flow leaving an AS. Before making any changes to manipulate paths, the network administrator should perform a thorough traffic analysis to understand the effects of the change. For example, the configurations for Routers A and B in Figure 8-36 are shown in Examples 8-22 and 8-23, respectively. In this network, the administrator changed the default local preference for all routes on Router B to 500 and on Router A to 200. All BGP routers in AS 65001 send all traffic destined for the Internet to Router B, causing its outbound utilization to be much higher and the utilization out Router A to be reduced to a minimal amount. This change is probably not what the network administrator intended. Instead, the network administrator should use route maps to set only certain networks to have a higher local preference through Router B to decrease some of the original outbound load that was being sent out Router A.

Figure 8-36. Setting a Default Local Preference for All Routes

Example 8-22. Configuration for Router A in Figure 8-36

router bgp 65001
  bgp default local-preference 200

Example 8-23. Configuration for Router B in Figure 8-36

router bgp 65001
  bgp default local-preference 500

Local Preference Example

Figure 8-37 illustrates a sample network running BGP that will be used to demonstrate how local preference can be manipulated. This network initially has no commands configured to change the local preference.

Figure 8-37. Network for Local Preference Example

Example 8-24 illustrates the BGP forwarding table on Router C in Figure 8-37, showing only the networks of interest to this example:

• 172.16.0.0 in AS 65003

• 172.24.0.0 in AS 65005

• 172.30.0.0 in AS 65004

Example 8-24. BGP Table for Router C in Figure 8-37 Without Path Manipulation

RouterC#show ip bgp
BGP table version is 7, local router ID is 192.168.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,  r RIB-
  failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network             Next Hop      Metric LocPrf  Weight Path
* i172.16.0.0       172.20.50.1             100       0 65005 65004 65003 i
*>i                 192.168.28.1            100       0 65002 65003 i
*>i172.24.0.0       172.20.50.1             100       0 65005 i
* i                 192.168.28.1            100       0 65002 65003 65004 65005 i
*>i172.30.0.0       172.20.50.1             100       0 65005 65004 i
* i                 192.168.28.1            100       0 65002 65003 65004i

The best path is indicated with a > in the second column of the output.

Each network has two paths that are loop-free and synchronization-disabled and that have a valid next-hop address (that can be reached from Router C). All routes have a weight of 0 and a default local preference of 100, so Steps 1 and 2 in the BGP path-selection process do not select the best route.

This router does not originate any of the routes (Step 3), so the process moves to Step 4, and BGP uses the shortest AS-path to select the best routes as follows:

• For network 172.16.0.0, the shortest AS-path of two autonomous systems (65002 65003) is through the next hop of 192.168.28.1.

• For network 172.24.0.0, the shortest AS-path of one AS (65005) is through the next hop of 172.20.50.1.

• For network 172.30.0.0, the shortest AS-path of two autonomous systems (65005 65004) is through the next hop of 172.20.50.1.

Neither Routers A nor B are using the neighbor next-hop-self command in this example.

A traffic analysis reveals the following:

• The link going through Router B to 172.20.50.1 is heavily used, and the link through Router A to 192.168.28.1 is hardly used at all.

• The three largest-volume destination networks on the Internet from AS 65001 are 172.30.0.0, 172.24.0.0, and 172.16.0.0.

• Thirty percent of all Internet traffic is going to network 172.24.0.0 (via Router B), 20 percent is going to network 172.30.0.0 (via Router B), and 10 percent is going to network 172.16.0.0 (via Router A); the other 40 percent is going to other destinations. Thus, considering only these three largest-volume destinations, only 10 percent of the traffic is using the link out Router A to 192.168.28.1, and 50 percent of the traffic is using the link out Router B to 172.20.50.1.

The network administrator has decided to divert traffic to network 172.30.0.0 and send it out Router A to the next hop of 192.168.28.1, so that the loading between Routers A and B is more balanced.

router bgp 65001
  neighbor 192.168.2.2 remote-as 65001
  neighbor 192.168.3.3 remote-as 65001
  neighbor 192.168.2.2 remote-as 65001 update-source loopback0
  neighbor 192.168.3.3 remote-as 65001 update-source loopback0
  neighbor 192.168.28.1 remote-as 65002
  neighbor 192.168.28.1 route-map local_pref in
!
route-map local_pref permit 10
  match ip address 65
  set local-preference 400
!
route-map local_pref permit 20
!
access-list 65 permit 172.30.0.0 0.0.255.255

RouterC#show ip bgp
BGP table version is 7, local router ID is 192.168.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,  r RIB-
  failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop       Metric LocPrf Weight Path
* i172.16.0.0       172.20.50.1             100       0 65005 65004 65003 i
*>i                 192.168.28.1            100       0 65002 65003 i
*>i172.24.0.0       172.20.50.1             100       0 65005 i
* i                 192.168.28.1            100       0 65002 65003 65004 65005 i
* i172.30.0.0       172.20.50.1             100       0 65005 65004 i
*>i                 192.168.28.1            400       0 65002 65003 65004i              

Recall that MED is used to decide how to enter an AS when multiple paths exist between two autonomous systems and one AS is trying to influence the incoming path from the other AS. Because MED is evaluated late in the BGP path-selection process (Step 6), it usually has no influence on the process. For example, an AS receiving a MED for a route can change its local preference on how to leave the AS to override what the other AS is advertising with its MED value.

When comparing MED values for the same destination network in the BGP path-selection process, the lowest MED value is preferred.

Changing the MED for All Routes

The default MED value for each network an AS owns and advertises to an EBGP neighbor is set to 0. To change this value, use the default-metric number router configuration command. The number parameter is the MED value.

Manipulating the default MED value can have an immediate and dramatic effect on traffic flow entering your AS. Before making any changes to manipulate the path, you should perform a thorough traffic analysis to ensure that you understand the effects of the change.

For example, the configurations of Routers A and B in Figure 8-38 are shown in Examples 8-27 and 8-28, respectively. The network administrator in AS 65001 tries to manipulate how AS 65004 chooses its path to reach routes in AS 65001. By changing the default metric under the BGP process on Router A to 1001, Router A advertises a MED of 1001 for all routes to Router X. Router X then informs all the other routers in AS 65004 of the MED through Router X to reach networks originating in AS 65001. A similar event happens on Router B, but Router B advertises a MED of 99 for all routes to Router Y. All routers in AS 65004 see a MED of 1001 through the next hop of Router A and a MED of 99 through the next hop of Router B to reach networks in AS 65001. (The neighbor next-hop self command is not used on either Router X or Router Y.) If AS 65004 has no overriding policy, all routers in AS 65004 choose to exit their AS through Router Y to reach the networks in AS 65001; this traffic goes through Router B. This selection causes Router A’s inbound bandwidth utilization to decrease to almost nothing except for BGP routing updates, and it causes the inbound utilization on Router B to increase and account for all returning packets from AS 65004 to AS 65001.

Figure 8-38. Changing the Default MED for All Routes

Example 8-27. BGP Configuration for Router A in Figure 8-38

router bgp 65001
  default-metric 1001

Example 8-28. BGP Configuration for Router B in Figure 8-38

router bgp 65001
  default-metric 99

This situation is probably not what the network administrator intended. Instead, to load-share the inbound traffic to AS 65001, the AS 65001 network administrator should configure some networks to have a lower MED through Router B and other networks to have a lower MED through Router A. Route maps should be used to set the appropriate MED values for various networks.

Changing the MED Using Route Maps

The network shown in Figure 8-39 is used as an example to demonstrate how to manipulate inbound traffic using route maps to change the BGP MED attribute. The intention of these route maps is to designate Router A as the preferred entry point to reach networks 192.168.25.0/24 and 192.168.26.0/24 and Router B as the preferred entry point to reach network 192.168.24.0/24. The other networks should still be reachable through each router in case of a link or router failure.

Figure 8-39. Network for MED Examples

The MED is set outbound when advertising to an EBGP neighbor. In the configuration for Router A shown in Example 8-29, a route map named med_65004 is linked to neighbor 192.168.28.1 (Router X) as an outbound route map. When Router A sends an update to neighbor 192.168.28.1, it processes the outbound update through route map med_65004 and changes any values specified in a set command as long as the corresponding match command conditions in that section of the route map are met.

Example 8-29. BGP Configuration for Router A in Figure 8-39 with a Route Map

router bgp 65001
  neighbor 192.168.2.2 remote-as 65001
  neighbor 192.168.3.3 remote-as 65001
  neighbor 192.168.2.2 update-source loopback0
  neighbor 192.168.3.3 update-source loopback0
  neighbor 192.168.28.1 remote-as 65004
  neighbor 192.168.28.1 route-map med_65004 out
!
route-map med_65004 permit 10
  match ip address 66
  set metric 100
route-map med_65004 permit 100
  set metric 200
!
access-list 66 permit 192.168.25.0.0 0.0.0.255
access-list 66 permit 192.168.26.0.0 0.0.0.255

The first line of the route map called med_65004 is a permit statement with a sequence number of 10; this defines the first route-map statement. The match condition for this statement checks all networks to see which are permitted by access list 66. The first line of access list 66 permits any networks that start with the first three octets of 192.168.25.0, and the second line of access list 66 permits networks that start with the first three octets of 192.168.26.0.

Any networks that are permitted by either of these lines will have the MED set to 100 by the route map. No other networks are permitted by this access list (there is an implicit deny all at the end of all access lists), so their MED is not changed. These other networks must proceed to the next route-map statement in the med_65004 route map.

The route map’s second statement is a permit statement with a sequence number of 100. The route map does not have any match statements, just a set metric 200 statement. This statement is a permit any statement for route maps. Because the network administrator does not specify a match condition for this portion of the route map, all networks being processed through this section of the route map (sequence number 100) are permitted, and they are set to a MED of 200. If the network administrator did not set the MED to 200, by default it would have been set to a MED of 0. Because 0 is less than 100, the routes with a MED of 0 would have been the preferred paths to the networks in AS 65001.

Similarly, the configuration for Router B is shown in Example 8-30. A route map named med_65004 is linked to neighbor 172.20.50.1 as an outbound route map. Before Router B sends an update to neighbor 172.20.50.1, it processes the outbound update through route map med_65004, and changes any values specified in a set command as long as the preceding match command conditions in that section of the route map are met.

Example 8-30. BGP Configuration for Router B in Figure 8-39 with a Route Map

router bgp 65001
  neighbor 192.168.1.1 remote-as 65001
  neighbor 192.168.3.3 remote-as 65001
  neighbor 192.168.1.1 update-source loopback0
  neighbor 192.168.3.3 update-source loopback0
  neighbor 172.20.50.1 remote-as 65004
  neighbor 172.20.50.1 route-map med_65004 out
!
route-map med_65004 permit 10
  match ip address 66
  set metric 100
route-map med_65004 permit 100
  set metric 200
!
access-list 66 permit 192.168.24.0.0 0.0.0.255

The first line of the route map called med_65004 is a permit statement with a sequence number of 10; this defines the first route-map statement. The match condition for this statement checks all networks to see which are permitted by access list 66. Access list 66 on Router B permits any networks that start with the first three octets of 192.168.24.0. Any networks that are permitted by this line have the MED set to 100 by the route map. No other networks are permitted by this access list, so their MED is unchanged. These other networks must proceed to the next route-map statement in the med_65004 route map.

The second statement of the route map is a permit statement with a sequence number of 100, but it does not have any match statements, just a set metric 200 statement. This statement is a permit any statement for route maps. Because the network administrator does not specify a match condition for this portion of the route map, all networks being processed through this section of the route map are permitted, but they are set to a MED of 200. If the network administrator did not set the MED to 200, by default it would have been set to a MED of 0. Because 0 is less than 100, the routes with a MED of 0 would have been the preferred paths to the networks in AS 65001.

Example 8-31 shows the BGP forwarding table on Router Z in AS 65004 indicating the networks learned from AS 65001. (Other networks that do not affect this example have been omitted.) Note that in this command output, the MED is shown in the column labeled Metric.

Example 8-31. BGP Table for Router Z in Figure 8-39 with a Route Map

RouterZ#show ip bgp
BGP table version is 7, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,  r RIB-
   failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop       Metric LocPrf Weight Path
*>i192.168.24.0     172.20.50.2      100    100       0 65001 i
* i                 192.168.28.2     200    100       0 65001 i
* i192.168.25.0     172.20.50.2      200    100       0 65001 i
*>i                 192.168.28.2     100    100       0 65001 i
* i192.168.26.0     172.20.50.2      200    100       0 65001 i
*>i                 192.168.28.2     100    100       0 65001 i

Router Z has multiple paths to reach each network. These paths all have valid next-hop addresses and synchronization disabled and are loop free. All networks have a weight of 0 and a local preference of 100, so Steps 1 and 2 in the route-selection decision process do not determine the best path. None of the routes were originated by this router or any router in AS 65004; all networks came from AS 65001, so Step 3 does not apply. All networks have an AS-path of one AS (65001) and were introduced into BGP with network statements (i is the origin code), so Steps 4 and 5 are equal. The route selection decision process therefore gets to Step 6, which states that BGP chooses the lowest MED if all preceding steps are equal or do not apply.

For network 192.168.24.0, the next hop of 172.20.50.2 has a lower MED than the next hop of 192.168.28.2. Therefore, for network 192.168.24.0, the path through 172.20.50.2 is the preferred path. For networks 192.168.25.0 and 192.168.26.0, the next hop of 192.168.28.2 has a lower MED (100) than the next hop of 172.20.50.2 (with a MED of 200). Therefore, 192.168.28.2 is the preferred path for those two networks.

Recall that the weight attribute influences only the local router. Routes with a higher weight are preferred.

The neighbor {ip-address | peer-group-name} weight weight router configuration command is used to assign a weight to updates from a neighbor connection, as described in Table 8-8.

Figure 8-40 depicts a typical enterprise BGP implementation. The enterprise is multihomed to two ISPs, to increase the reliability and performance of its connection to the Internet. The ISPs might pass only default routes or might also pass other specific routes, or even all routes, to the enterprise. The enterprise routers connected to the ISPs run EBGP with the ISP routers and IBGP between themselves; thus all routers in the transit path within the enterprise AS run IBGP. These routers pass default routes to the other routers in the enterprise, rather than redistributing BGP into the interior routing protocol.

Figure 8-40. BGP in an Enterprise

BGP attributes can be manipulated, using the methods discussed in this section, by any of the routers running BGP, to affect the path of the traffic to and from the autonomous systems.

The objectives of this exercise are to configure EBGP on your edge routers which are multihomed to the backbone, to simulate multihomed ISP connections.

Figure 8-41 illustrates the topology used and what you will accomplish in this exercise.

Figure 8-41. Multihomed BGP Configuration Exercise Topology

In this exercise, you use the commands in Table 8-9, listed in logical order. Refer to this list if you need configuration command assistance during the exercise.

In this task, you remove some of the configuration from the previous exercises, and create two multipoint subinterfaces on your edge routers in preparation for configuring BGP in the next task. Follow these steps:

In this task, you configure basic BGP on the edge routers. Follow these steps:

You have successfully completed this exercise when you achieve the following results:

The objective of this exercise is to configure a full-mesh IBGP network.

Figure 8-42 illustrates the topology used in this exercise.

Figure 8-42. Full-Mesh IBGP Configuration Exercise Topology

In this exercise, you use the commands in Table 8-10, listed in logical order. Refer to this list if you need configuration command assistance during the exercise.

In this task, you configure and verify full-mesh IBGP in your pod. Follow these steps:

You have successfully completed this exercise if you have configured full-mesh IBGP within your pod and your routing tables contain BGP routes to the networks advertised by the core.

The objective of this exercise is to use route maps to change BGP MED and local preference values, affecting path selection.

Figure 8-44 illustrates the topology used in this exercise.

Figure 8-44. BGP Path Manipulation Configuration Exercise Topology

In this exercise, you use the commands in Table 8-11, listed in logical order. Refer to this list if you need configuration command assistance during the exercise.

In this task, you change the MED and local preference to manipulate the BGP path-selection process, as shown in Figure 8-45.

Figure 8-45. BGP Paths That Will Be Manipulated

You have successfully completed this exercise when you achieve the following results: