Introduction to BGP and Communicating with Other Autonomous Systems BGP is an extremely complex protocol used throughout the Internet and within multinational organizations. Its main purpose is to connect very large networks or autonomous systems. Large companies can use BGP as the glue between countries in which they operate ; for example, a government might use BGP among the divisions of its administration, and the military might use it among the Army, the Navy, and the Air Force. The goal of an exterior routing protocol such as BGP is not to find a specific network, but to provide you with information that allows you to find the autonomous system wherein the network lies. The interior routing protocol, such as EIGRP, RIP, OSPF, and IS-IS, will find the specific network that you seek. This section presents the basics of BGP, introduces the terminology used in BGP, and explains the role of BGP as a routing protocol in the IP community. It is important to understand when to use BGP and when to use other solutions, such as static and default routes. Within this introductory section, the main characteristics of BGP are explained, laying the foundation for the more complex explanation in the rest of the chapter. Characteristics of BGP The main characteristics of BGP can be distilled into a few short points. These characteristics demonstrate why this protocol is best suited to exterior routing. The interaction of these components and their relative importance to the operation or design of a BGP network is discussed in the rest of the chapter. The key features of BGP include: -
It is a path vector routing protocol. -
BGP supports variable-length subnet mask (VLSM), classless interdomain routing (CIDR), and summarization. -
Full routing updates are sent at the start of the session; triggered updates are sent subsequently. -
It creates and maintains connections between peers, using TCP port 179. -
The connection is maintained by periodic keepalives . -
The failure to see a keepalive, an update, or receipt of a notification is the means by which destination networks and paths to those destinations are tracked. Any change in the network results in a triggered update. -
The metrics used in BGP are intricate and are the source of its complexity and its strength. The metric, referred to as attributes , allows great granularity in path selection. -
The use of hierarchical addressing and the capability to manipulate traffic flow results in a network that is designed to grow. -
It has its own routing table, although it is capable of both sharing and inquiring about the interior IP routing table. -
It is possible to manipulate the traffic flow by using attributes. Despite the complexity offered in path selection using policy-based routing, the traffic is still forwarded using the hop-by-hop paradigm. This means that no router can send traffic on a route that the next -hop router would not choose for itself. One of the most distinctive characteristics of BGP is its routing updates. When you look at the BGP updates, you can see why BGP is excellent for communicating between autonomous systems. BGP works as an exterior routing protocol because the routing updates are extremely concise . BGP is not interested in communicating a full knowledge of every subnet within the organization, but only in conveying enough information to find another autonomous system. The BGP routing update takes summarization to the extreme by communicating only a list of autonomous system numbers , aggregated prefix addresses, and some policy-based routing information. However, the small amount of information that the BGP update carries is extremely important. BGP ensures the reliability of the transport carrying the updates and that the databases are synchronized. BGP can be implemented in several ways, including between autonomous systems or across an autonomous system. When you use BGP to connect autonomous systems, it acts as an Exterior Gateway Protocol (EGP) and is referred to as External BGP, or eBGP. The routing protocol can also carry this external information between eBGP speakers that are resident in the same autonomous system. This is called Interior BGP (iBGP). Figure 15-1 illustrates how BGP can be used to connect autonomous systems. Figure 15-1. Using BGP to Connect Autonomous Systems  Many terms are used in BGP. You need to understand the naming of the parts in order to comprehend the working of the protocol as a whole. BGP Terminology BGP is a very different routing protocol from the interior routing protocols that you have studied so far. This protocol is designed to connect autonomous systems, not connect subnets within an autonomous system. BGP, therefore, comes with its own terms and concepts. As with other routing protocols, understanding the jargon of the technology is halfway to understanding the protocol itself. Table 15-2 provides definitions for keywords and terms introduced in this chapter. A complete listing, including all of the chapter terms and additional terms, can be found in the Glossary toward the end of this book. Table 15-2. BGP Terms | Term | Definition | | aggregation | The BGP term for summarization. | | attribute | Similar to a metric, these are variables that describe characteristics of the path to the destination. Once defined, the characteristics can be used to make decisions as to which path should be taken, based on the characteristic or attribute of the paths available. | | autonomous system | Definition for the organizational boundary. Routers share the same routing protocol within the organization. The autonomous system defines all the routers within an administrative domain, where each router has full knowledge of the subnets within the domain. If you are connecting directly to the Internet using BGP, the autonomous system number must be unique and obtained from the Internet addressing committees . | | Exterior Gateway Protocol (EGP) | The generic term for a protocol that runs between autonomous systems. There is also a specific EGP protocol with this name , which was the precursor to BGP. | | External BGP (eBGP) | eBGP sends routing information between different autonomous system. | | Interior Gateway Protocol (IGP) | This is a routing protocol that runs within an autonomous system. In the past, the term gateway was used to define a router. | | Internal BGP (iBGP) | This is when BGP is used within an autonomous system. The routers are not required to be physical neighbors and often sit on edges of the autonomous system. iBGP is used between eBGP speakers in the same autonomous system. | | Originator-ID | This is a BGP attribute. It is an optional nontransitive attribute that is created by the route reflector. The attribute contains the router ID of the router that originated the route in the update. The purpose of this attribute is to prevent a routing loop. If the originating router receives its own update, it ignores it. | | policy-based routing | This allows the administrator to program the routing protocol by defining how traffic is routed. This is a form of static routing enforced by access lists called route maps . Policy-based routing (PBR) is protocol independent and uses route maps by creating a separate process to force routing decisions in a sophisticated way by matching and changing attributes and other criteria. | | prefix list | The prefix list is used as an alternative to distribute lists to control how BGP learns or advertises updates. Prefix lists are faster, more flexible, and less processor- intensive than distribute lists. | | route reflector | This is the router that is configured to forward routes from other identified iBGP clients . This removes the necessity for a fully meshed iBGP network, preserving network resources. A fully meshed network has a great deal of overhead and does not scale. | | route reflector client | A client is a router that has a TCP session with its iBGP peer that is acting as a route reflector. It forwards routes to the route reflector, which propagates these on to other routers. The client does not have peer connections with other clients. | | route reflector cluster | A cluster is a group consisting of a route reflector and clients. There can be more than one route reflector in a cluster. | | synchronization rule | This rule states that a router cannot forward a route to an eBGP peer unless the route is in its local IP routing table. This requires that the IGP and BGP routing table are synchronized. This is to prevent BGP from advertising routes that the autonomous system cannot direct to the destination. If BGP is fully meshed, it does not have to rely on the IGP routing tables and you can disable synchronization. Use the router(config-router)# no synchronization command to turn off synchronization. | | transit autonomous system | An autonomous system that is used to carry BGP traffic across to another autonomous system. None of the traffic is destined for any router within the transit autonomous system; it is simply being routed through it. | When to Use BGP BGP is particularly complex when determining the path that should be taken or when used in conjunction with route maps to implement policy-based routing. Its complexity is its very strength. BGP is not a protocol for all occasions; its brevity and path determination make it a specialized routing protocol. There are specific situations where using BGP is important, including the following: -
Your organization is connecting to multiple ISPs or autonomous systems and is actively using those links. Many organizations use multiple links for redundancy purposes, justifying the additional cost by using all the links and reducing bottlenecks and congestion. In this case, policy-based routing decisions might need to be made on a link-by-link basis. -
The routing policy of the ISP and your company differ . The cost of the link depends on usage in addition to other factors that might need to be programmed into the BGP configuration to make the best use of the connection by manipulating the traffic. -
The traffic in your organization needs to be distinguished from that of the ISP. The two organizations cannot logically appear as one autonomous system. -
Your organization is an ISP and, therefore, conforms to criteria in the preceding bullets. The nature of your business requires the traffic from other autonomous systems to travel across your autonomous system, treating it as a transit domain. When Not to Use BGP A simple network is a network that is easier to manage and maintain, which is the main reason to avoid BGP configuration in the network. Therefore, if your network has the following characteristics, use other methods , such as static and default routing, to achieve connectivity to the ISP or to another autonomous system network: -
The ISP and your organization have the same routing policy. -
Although your company has multiple links to the ISP, these links are redundant and there are no plans to activate more than one link to the Internet. -
There are limited network resources, such as memory and CPU, on the routers. -
The bandwidth between the autonomous systems is low, and the additional routing overhead would detract from routing data. How BGP works and an explanation of some of its characteristics are given in the following section. Overview of the BGP Operation BGP is connection-oriented. When a neighbor is seen, a TCP peering session is established and maintained. BGP probes are sent out periodically to sustain the link and maintain the session. These probes, otherwise known as keepalives , are simply the 19-byte header used in the BGP updates. Having established the session, the routing tables are exchanged and synchronized. The routers then send incremental updates only when changes occur. The update refers to a single path and the networks that can be reached via that path. Having corrected the routing table, the BGP process propagates the change to all neighbors, with a few exceptions, based on an algorithm to ensure a loop-free network. The operation of BGP is very straightforward. Indeed, all the complexity of the protocol is delivered in only a few different message types. Four different message types are used in BGP: -
Open messages Used to establish connections with peers. -
Keepalives Sent periodically between peers to maintain connections and verify paths held by the router sending the keepalive. These packets are sent unreliably. If the periodic timer is set to a value of 0, this equates to infinity, and no keepalives are sent. -
Update messages Contain paths to destination networks and the path attributes. Updates include routes that are no longer available or are withdrawn. There is one path per update, requiring many updates for many paths. The information contained in the update includes the path attributes such as origin, autonomous system path, neighbor, and interautonomous system metric. -
Notification Used to inform the receiving router of errors that cause the connection to be closed. The establishment of a BGP peer is shown in Figure 15-2. Figure 15-2. Establishing a BGP Peer  The following sections discuss in greater detail how BGP summarizes routes, manipulates the path selection process using policy-based routing, and selects a route. CIDR and Route Aggregation BGP needs to communicate some information between the autonomous systems, but perhaps not all of the information is needed. If the network is designed to support summarization, the amount of network resources required could be reduced, because fewer memory, bandwidth, and CPU resources would be consumed when updating the routing tables. In fact, by summarizing the IANA classful addresses, the Internet becomes a quicker and more reliable environment. CIDR is one of the main solutions implemented in recent years . This is a method of consolidating addresses into a few summary addresses. Instead of an address having a mask to identify the network portion of the address, it has a prefix mask, which is simply a number that indicates the number of bits that have been allocated to the network. Summarization reduces the number of prefix bits and thus incorporates other networks that share those prefix bits into one address. Prefix masks are now used with subnets as well as IANA classful addresses. If an autonomous system has been allocated eight consecutive Class C addresses, it can be advertised as one network, which is an example of summarization at its best. BGP will propagate the prefix and the prefix mask together, allowing not only for the design of a truly hierarchical network, but also for the streamlining of the network resources. A router can pass on the aggregated routes, although it is capable of aggregating routes itself. Therefore, a router can send aggregated routes, routes that have not been summarized, or a mixture of both. The process of how BGP aggregates routes in compliance with CIDR is shown in Figure 15-3. In the figure, the update sends 1 network, instead of 16 networks, to the router in autonomous system 200. Figure 15-3. BGP and CIDR  BGP and Policy-Based Routing Policy-based routing is a separate administrative function from BGP, and they do not rely upon each other to work. Policy-based routing gives the administrator the ability to define how traffic will be routed at the autonomous system level. Policy-based routing is a form of static routing enforced by access lists, including route maps, distribute lists, prefix lists, and filter lists, because they impact the inbound or outbound routing table updates. This is a level of control above the dynamic routing protocol. Given that many variables, or attributes, in BGP can influence dynamic routing, the administrator is provided with a very high level of control. This dimension distinguishes BGP from other routing protocols. You will learn more about BGP attributes later in this section. One of the most sophisticated forms of policy-based routing is implemented with route maps, which are the topic of Chapter 18, "Controlling Network Traffic with Route Maps and Policy-Based Routing." BGP's capability to choose the routing path via conditional programming was used for policy routing in other situations before it became an option in the Cisco IOS software. BGP was deployed in some situations to use the policy routing-based options; for example, BGP was used by the two early deployments of tag routing as the only means of programming policy-based routing. This is a powerful tool and can be used in many situations, such as forcing traffic entering your routing domain to pass through a firewall or load balancing among multiple connections to the Internet. Refer to Figure 15-4 for an example of how policy-based routing could be implemented. Figure 15-4. Example of Policy-Based Routing Using BGP  In Router A in Figure 15-4, the traffic from 192.17.50.6 is from the graphic design department. It is high-volume, sensitive traffic. Therefore, you should send it on a path dedicated to such traffic, so this traffic should be directed to Router C. Policy-based routing is discussed in the following sections. You will be introduced to the rules that govern policy-based routing, the disadvantages that you should be aware of before implementing this technology, and the concept of attributes and how attributes are used in policy-based routing to select a path across a nonbroadcast cloud. Rules of Policy-Based Routing BGP can implement any of the following rules associated with the hop-by-hop paradigm. This paradigm is the capability to influence which router will be the next-hop router, potentially dictating it at every router and thus influencing the entire path of the traffic, hop by hop. The following rules associated with policy-based routing seem repetitive, but, in fact, each point raises a subtly different nuance: -
Traffic can be directed on either the source address or both the source and destination addresses. These are only some of the criteria that can be used. -
Policy-based routing affects only the next hop in the path to the destination. -
Policy-based routing does not affect the destination of the packet. It affects the path used to get to the destination. -
Policy-based routing does not allow traffic sent into another autonomous system to take a different path from the one that would have been chosen by that autonomous system. -
It is possible to influence only how traffic will get to a neighboring autonomous system, not how it will be routed within that autonomous system. -
As policy-based routing examines the source address, it is configured on the inbound interface. NOTE Some things should be considered before arbitrarily deciding to implement policy-based routing. Understand that any additional configuration requires additional CPU, particularly when every packet characteristic must be examined. It is also wise to have a backup path in place in case the defined next-hop router goes down. If there is no alternative defined, policy-based routing will default to dynamic routing decisions. Of course, whenever extra configuration is required, there is the possibility of misconfiguration or of disrupting other traffic. Refer to Chapter 18 for more information about the disadvantages of policy-based routing.
BGP Attributes The key to BGP is the capability to divert traffic into different directions based on criteria determined by the network architects . BGP is concerned with providing the capability to manipulate the traffic flow through the network. This is the key difference between the routing protocols you have seen in previous chapters and BGP. BGP directs the traffic flow by using attributes. This is different from policy-based routing, which is a sophisticated method of forcing traffic down a particular path in spite of the dynamic routing decisions. The use of attributes refers to the use of variables in the selection of the best path for the dynamic routing protocol BGP. BGP uses attributes to select the best path. In essence, attributes are the metric for BGP. However, they are more than a list of variables by which a route is selected. They also carry information on which decisions are based, hence the name attributes . The variables describe characteristics or attributes of the path to the destination. These characteristics can be used to distinguish the paths, which is policy-based routing. So, policy-based routing uses the attributes in BGP to make sophisticated decisions in path selection. The reason for choosing different paths is determined by the nature of the traffic. Policy-based routing allows you to select reliable and slow links for packets that need to be propagated. Some of the information carried in the update messages is more important than others. Indeed, some of this information is crucial to the successful operation of BGP, so it must be carried through the network to every router running BGP. The path selection is based on the attributes and their values. Because the BGP information in the updates varies in significance to the BGP network, it has been categorized by importance. The attributes are divided into two types, well-known and optional. The well-known attributes are those attributes whose implementation is mandatory, whereas the optional ones are just thatoptional. Both of these are subdivided into two further categories, allowing considerable granularity (see Table 15-3). Table 15-3. The Four Categories of Attributes | Category | Description | | Well-known : | | | Mandatory (required by all routers) | These attributes are required and are therefore recognized by all BGP implementations . | | Discretionary (required by all routers and recognized by all routers) | It is not required that these attributes be present in the update messages, but if they are present, all routers running BGP will recognize and act on the information contained. | | Optional : | | | Transitive | The router might not recognize these attributes, but if this is the case, it marks the update as partial and sends the update, complete with attributes, to the next router. The attributes traverse the router unchanged, if they are not recognized. | | Nontransitive | Nontransitive attributes are dropped if they fall onto a router that does not understand or recognize the attribute. These attributes will not be propagated to the BGP peers. Unrecognized nontransitive optional attributes must be quietly ignored and not passed along to other BGP peers. New transitive optional attributes might be attached to the path by the originator or by any other autonomous system in the path (see RFC 1771). | The attributes are appropriately carried in the updates that inform the routers of the routes. Although there are other attributes, the following list includes the ones supported by Cisco. The attributes and a description of their characteristics are listed in Table 15-4 for quick reference and comparison. Table 15-4. The BGP Attributes | Attribute Name | Category | Code | Preference | Description | | Origin | Well-known, mandatory | 1 | Lowest origin code Where: IGP < EGP < Incomplete | This path attribute identifies the source of the routing update. The possible sources of routing information are as follows : -
The path originates from within the autonomous system. It was created with the iBGP network command. The route will be marked in the BGP routing table with an "i." -
If the source is an exterior routing protocol, it will be identified with an "e" in the routing table. -
The route could have been redistributed into BGP, so there is incomplete information. The route is marked by a question mark (?). | | AS_Path | Well-known, mandatory | 2 | Shortest path | This attribute includes a list of all the autonomous systems that the routes have passed through. | | Next Hop | Well-known, mandatory | 3 | Shortest path or IGP metric | The next hop attribute states the next hop on the path for the router to take. In eBGP, this is the source address of the router that sent the update from the other autonomous system. In iBGP, for routes originated outside the autonomous system, the address is still the source address of the router that sent the update. The protocol states that the next hop advertised by eBGP should be carried into iBGP. Therefore, it is important for the IGP to be aware of this network so that any router within the autonomous system can reach the next hop. | | Multiple Exit Discriminator (MED) | Optional, nontransitive | 4 | Lowest value | This attribute informs routers outside the autonomous system which path to take into the autonomous system. The MED is known as the external metric of a route. Therefore, the MED is passed between the autonomous systems, but it will not be propagated into a third autonomous system. | | Local preference | Well-known, discretionary | 5 | Highest value | This attribute is used to tell routers within the autonomous system how to exit the autonomous system in the case of multiple paths. It is the opposite of the MED attribute. This value is passed solely between iBGP peers. | | Atomic aggregate | Well-known, discretionary | 6 | Information not used in path selection | The originator of the aggregate route is stated. It is useful because it shows that some information has been lost because of the aggregation of routes. It states to the receiving router in another autonomous system that the originator of the route aggregated the routes. | | Aggregator | Optional, transitive | 7 | Information not used in path selection | This attribute states the BGP router ID and autonomous system number of the router that was responsible for aggregating the route. This attribute will include a list of all the autonomous systems that the aggregated routes have passed through. | | Community | Optional, transitive | 8 | Information not used in path selection | This is the capability to tag certain routes that have something in common. They are thereby made members of the same club or community. This is often used in conjunction with another attribute that will affect route selection for the community. For example, the use of the local preference and community attributes would allow the network administrators and other privileged employees to use the high-speed link to the Internet, while others share a fractional T1. Communities have no geographical or logical limits. BGP can filter on incoming or outgoing routes for filtering, redistribution, or path selection. | | Originator ID | Optional, nontransitive | 9 | Information not used in path selection | The route reflector (described in Chapter 16, "Implementing and Tuning BGP for Use in Large Networks") appends this attribute. It carries the router ID of the originating router in the local autonomous system. It is used to prevent loops . | | Cluster ID | Optional, nontransitive | 10 | Information not used in path selection | The cluster identifies the routers involved in the route reflection. The cluster list shows the reflection path that has been taken. This is used to prevent looping errors. | | Weight | Cisco-defined | | Highest value | This is proprietary to Cisco and is used in route selection. It is local to the router, and because it is not propagated to other routers, there is no problem with compatibility. When there are multiple paths, it selects a path to a destination with different next hops to the same destination. Note that the weight attribute has no code. Because it is a local attribute and is not propagated to other routers, no code is needed. | The Next-Hop Attribute and a Broadcast Multiaccess Network It is worth mentioning a potential problem with one of the attributes, namely the next-hop attribute. In eBGP, the next hop is the IP address of a router from outside the autonomous system advertising into the autonomous system. The IP address is that specified in the neighbor command. However, on a multiaccess network, if a route came from one router, it would be unwise for another router to readvertise the route with its own address as the source address. This might lead to packets being sent to several routers on the multiaccess network before finding the true originator, which is obviously inefficient. The rule, therefore, is that the address of the router that originally sent the update onto the multiaccess network should remain as the source address. Figure 15-5 shows the next-hop router in a multiaccess network. Figure 15-5. The Next-Hop Router in a Multiaccess Network  As shown in Figure 15-5, the source address is not changed, so the next-hop address is always the source (in this case, Router A). When this rule is applied to nonbroadcast multiaccess (NBMA), problems arise because although Router B might correctly point to Router A, Router B cannot see Router A in this NBMA cloud. Extra configuration is needed, as described in the next section. The Next-Hop Attribute and a Nonbroadcast Multiaccess Network As a multiaccess network, an NBMA network plays by the same rules of maintaining the source address of the router that originated the route on the network. However, there is a potential problem because the other routers are not going to be communicating directly with the source router if the NBMA cloud has a hub-and-spoke configuration (see Figure 15-6). If this is the case, the problem can be solved with a command that forces the router to advertise itself as the source. The commands for configuring BGP are dealt with later in the chapter in the section "Defining the Networks to Be Advertised." Figure 15-6. The Next-Hop Router in an NBMA Network  Route Selection Process As you have seen, BGP has many options by which to select one route over another using attributes. Now that you understand how attributes work in BGP, this section outlines the overall process of route selection. The following process illustrates the logic of the selection process: -
If the router has a valid route to the destination, use that route. -
If there is more than one valid route to the destination, take the route with the highest weight (Cisco proprietary). -
If the weights are the same, select the route with the highest local preference. -
If the routes have the same local preference, prefer the route that originated on that router. -
If there are no routes that originated on the router, examine the AS_Path and select the shortest path (through the fewest autonomous systems). -
If the AS_Path is the same, examine and choose the lowest origin code, where an internal path has a lower value than an external path, which in turn is lower than an incomplete path. -
If the origin codes are the same and the routes originate from a common autonomous system, select the path with the lowest MED. -
If the MED values are the same, choose an external BGP route over an internal BGP route. -
If there is no external route, choose the path with the lowest IGP metric or cost to the next-hop router for iBGP. -
Is one of the routes older? If so, choose the most recent route. -
If all else fails, choose the router with the lowest BGP router ID. NOTE The preceding is a simplification of the selection process. For more detailed information on how the routing decisions are made, refer to RFC 1771, "A Border Gateway Protocol 4 (BGP)." This document, together with its companion document, RFC 1772, "Application of the Border Gateway Protocol in the Internet," defines an interautonomous system routing protocol for the Internet.
Basic Configuration Commands to Connect to Another Autonomous System To connect to another autonomous system, it is necessary to configure required commands. You can also configure optional commands based on the needs of your network environment. The next sections discuss both required and optional commands. Configuring Required BGP Commands To connect to another autonomous system, you need to configure the following items: Starting the Routing Process The command to configure the routing process is the same command as that for the interior routing protocols. The syntax is as follows: Router(config)# router bgp autonomous-system-number Identifying Neighbors and Defining Peer Groups A peer group is a group of neighbors that share the same update policy. This is the mechanism by which routers are grouped to simplify configuration. A peer group also eases the overhead on the network, because the iBGP routers do not need to be fully meshed. When the network is fully meshed, the maintenance of all the neighbor relationships can place strain on your network. All the members of the peer group will inherit the characteristic configured with the following command. The use of peer-group -name allows the identification of the router as a member of a peer group: Router(config-router)# neighbor peer-group-name peer-group Once the peer group has been defined, it is possible to define neighbors for all the members of the peer group. Router(config-router)# neighbor ip-address peer-group-name remote-as autonomous-system - number In iBGP, the remote autonomous system numbers that are defined for the BGP peers and for this BGP routing process are the same; in eBGP, these numbers differ. Figure 15-7 is the topology map for Example 15-1. This figure shows the basic configuration commands required to make eBGP operate between autonomous systems. Figure 15-7. Topology for Example 15-1  In Example 15-1, Router A in AS100 connects to routers in AS100, AS200, AS300, AS400, and AS500. Example 15-1. Basic Configuration of eBGP on Router A Router A Router(config)# interface Serial0.1 Router(config-int)# ip address 10.255.255.201 255.255.255.252 ! Router(config)# interface Serial0.2 Router(config-int)# ip address 10.255.255.205 255.255.255.252 ! Router(config)# interface Serial0.3 Router(config-int)# ip address 10.255.255.209 255.255.255.252 ! Router(config)# interface Serial0.4 Router(config-int)# ip address 10.255.255.213 255.255.255.252 ! Router(config)# router bgp 100 Router(config-router)# neighbor 10.255.255.202 remote-as 200 Router(config-router)# neighbor 10.255.255.206 remote-as 300 Router(config-router)# neighbor 10.255.255.210 remote-as 400 Router(config-router)# neighbor 10.255.255.214 remote-as 500 Configuring Optional BGP Commands The following sections describe optional commands in the basic configuration of BGP. These commands are related to the following tasks : Defining the Networks to Be Advertised To define the network that is to be advertised for this autonomous system, use the following command (each network requires a separate command): Router(config-router)# network network-number mask network-mask The network command determines the networks that are originated by this router. This is a different use of the network command than you are accustomed to configuring with EIGRP, OSPF, and RIP. This command is not identifying the interfaces upon which to run BGP; instead, it is stating the networks that are to be advertised by BGP. The network command must include all the networks in the autonomous system to be advertised, not just those that are directly connected to the router. The mask portion is used because BGP can handle subnetting and supernetting. The mask used is a network mask. Forcing the Next-Hop Address On a multiaccess network, the rule is that the source address of a packet is that of the router that originated the packet onto the network. This can cause problems on an NBMA network that appears to be a multiaccess network, but that in reality might not have full connectivity to all the routers on the network. If the source address is the address of the initiating router, the other routers might not have a path to this next hop, and packets will be dropped. (This issue was described earlier in this chapter in the section "The Next-Hop Attribute and a Broadcast Multiaccess Network.") To overcome this problem, the next-hop address can be configured to be that of the transmitting router. The syntax of the command is as follows: Router(config-router)# neighbor { ip-address peer-group } next-hop-self Aggregating Routes To summarize or aggregate routes within the BGP domain, use the following command from config-router mode: Router(config-router)# aggregate-address ip-address mask [ summary-only ] [ as-set ] If the parameter summary-only is used, then the specific routes are suppressed, and the summary route is the only one propagated. If the parameter as-set is used, then all the autonomous systems that have been traversed will be recorded in the update message. The as-path attributes of the prefixes that make up the aggregate are placed in the as-set attribute of the update. Because it might be necessary to redistribute BGP into the IGP, care must be taken to avoid routing loops and not to overwhelm the routing tables. The administrative distance of BGP helps prevent this problem (see Figure 15-8). Figure 15-8. Administrative Distance and BGP  Example 15-2 is a BGP configuration using the aggregate-address command with the summarization parameter. In this example, any routes with a longer prefix than /16 are summarized, if possible, into the routes specified. In this way, the route 10.20.35.8/29 is not seen in BGP updates because it is summarized into the address 10.20.0.0/16. Any route that does not summarize into those specified in the example is listed individually. Summarization reduces the overhead on the network and simplifies system administration. Example 15-2. The aggregate-address Command with the Summarization Parameter Router A Router(config)# interface Serial0 Router(config-int)# ip address 10.255.255.201 255.255.255.224 ! Router(config)# router bgp 100 ! Router(config-router)# network 10.10.0.0 255.255.0.0 ! aggregate-address 10.20.0.0 255.255.0.0 summary-only aggregate-address 10.30.0.0 255.255.0.0 summary-only aggregate-address 10.40.0.0 255.255.0.0 summary-only aggregate-address 10.50.0.0 255.255.0.0 summary-only ! Router(config-router)# neighbor 10.255.255.202 remote-as 200 Router(config-router)# neighbor 10.255.255.202 next-hop-self ! Router(config-router)# neighbor 10.255.255.206 remote-as 300 Router(config-router)# neighbor 10.255.255.206 next-hop-self ! Router(config-router)# neighbor 10.255.255.210 remote-as 400 Router(config-router)# neighbor 10.255.255.210 next-hop-self ! Router(config-router)# neighbor 10.255.255.214 remote-as 500 Router(config-router)# neighbor 10.255.255.214 next-hop-self In Figure 15-8, because iBGP has an administrative distance of 200, it is effectively the last choice. Router C will always choose the direct path to 10.0.0.0 through Router A because it has an administrative distance of 20. The route through D and B to find network 10.0.0.0 will have an administrative distance of 110 (OSPF) or 200 (iBGP), depending on the configuration. Managing and Verifying the BGP Configuration After configuration changes in BGP, it is necessary to reset the TCP session between neighbors. This can be forced with the following command: Router(config-router)# clear ip bgp { * address }[ soft [ in out ]] This command disconnects the session between the neighbors and reestablishes it using the new configuration that has been entered. The soft option does not tear down the sessions, but it resends the updates. The in and out options allow the configuration of inbound or outbound soft updates. The default is for both. NOTE The clear ip bgp command is an executive command executed at the privileged level. It is not a configuration command.
The show commands for BGP are comprehensive and give clear information about the BGP sessions and routing options. These informative commands and their functions are as follows: -
show ip bgp Displays the BGP routing table. -
show ip bgp paths Displays the topology table. -
show ip bgp summary Displays information about the TCP sessions. -
show ip bgp neighbors Displays information about the TCP connections to neighbors. When the connection is established, the neighbors can exchange updates. -
show processes cpu Displays active processes and is useful to identify any process that is using excessive resources. Another command that helps to troubleshoot any implementation and should be considered in the BGP configuration is the debug command. An entire book in the IOS documentation set is devoted to this command. For BGP, debug is a very useful command. It is shown here with all the possible options: Router# debug ip bgp [ dampening events keepalives updates ] This command displays live information of events as they occur. The options available display dampening information, events, keepalives to maintain the TCP session with the peer, and routing updates as they are sent or received. Route dampening is a mechanism to minimize the instability caused by route flapping. By counting the number of times the identified route fails and applying a penalty to the route for each flap, BGP categorizes the route as well-behaved or ill-behaved. Depending on its reputation, BGP suppresses the route by not advertising it in routing updates. The route can redeem itself by remaining up. Once there is some confidence that the route is stable, BGP reinstates and advertises it once more. Given its complexity and role in internetworking, BGP is seldom used by private organizations. To handle the rush to connect to expanding Internet resources, service providers emerged to set up and manage the connection. This is advantageous for everyone. For a small fee, the organization or individual has a complex connection created and maintained. The burden on the Internet is also eased, because its limited space is taken by large corporations and organizations rather than millions of individual users. Because ISPs handle BGP, information on troubleshooting BGP is not covered in as much detail as has been done in previous chapters for other technologies. Alternative Methods of Connecting to Another Autonomous System If BGP is unnecessary in your network, consider the other possibilities for connecting to another autonomous system. If you do not have BGP running in your organization, you most likely are connecting to an ISP. This section is primarily concerned with connecting your company to the Internet through an ISP. The different methods include the following: -
A default route into the autonomous system and a static route from the autonomous system into the organization. -
A routing protocol into the autonomous system, making the autonomous system part of your autonomous system. The autonomous system will be using redistribution within its domain, and it is advisable for the organization to use some form of security, such as an access list or a firewall. Typically, your ISP gives you a written sheet explaining the required configuration, or it requests access to your autonomous system boundary router (ASBR) so that it can configure the router itself. Either way, it is useful to be cognizant about the procedure. There are too many variations in configuring an internal routing protocol to detail in this chapter. Refer to Chapter 1, "IP Routing Principles," for coverage of static and default routes; Chapter 3, "Designing IP Networks," for connecting to the outside world with NAT; and Chapter 17, "Implementing Redistribution and Controlling Routing Updates," for redistribution. The use of default and static routes is an alternative to BGP that has been implemented for years in connecting remote satellite networks, particularly those connected by a dialup link. The solution is simple : The smaller network defines a default route that it propagates throughout the domain. The default route points to the network that connects to the ISP. The larger autonomous systemin this case, the ISPconfigures static routes to its customer. The ISP's routing table summarizes the static routes to the IANA classful address and propagates the summarized routes throughout the ISP's network, eventually advertising them into the Internet. Thus, the smaller organization is connected into the global internetwork. Figure 15-9 illustrates the use of default and static routes and shows how they are propagated. Figure 15-9. Default and Static Route Configuration into the Internet  The command syntax to configure a static route is as follows: Router(config)# ip route prefix mask { interface ip-address } [ distance ] It is possible to specify either the outgoing interface or the IP address of the next logical hop. If you specify the outgoing interface, the routing table considers the route to be directly connected. The default administrative distance of a directly connected link is 0. This is only appropriate for point-to-point links where there is no choice in the destination address. If the next hop IP address is configured, the route is given the administrative distance of 1. In either case, the administrative distance ensures that this path is chosen above all others. If this static route is a redundant link into the ISP configured as a backup resource, it might be necessary to change the administrative distance. To propagate the static routes throughout the domain, it is necessary to redistribute them in to the appropriate routing protocol. |
