Semestre 1 CCNP, Módulo 9
Module 9: BGP
Overview
Routing protocols can be classified in many ways. It depends on where they are used in relationship to the enterprise. Protocols that run inside an enterprise are called interior gateway protocols (IGPs). Examples of IGPs include RIP versions 1 and 2, IGRP, EIGRP, and OSPF. Protocols that run outside an enterprise, or between autonomous systems (ASs), are called exterior gateway protocols (EGPs). Typically, EGPs are used to exchange routing information between Internet Service Providers (ISPs), or in some cases between a customer's AS and the provider's network. Border Gateway Protocol, version 4 (BGP4), is the most common EGP and is considered the Internet standard.
This module provides an overview of the different types of autonomous systems and then focuses on basic BGP operation, including BGP neighbor negotiation. The module also looks at how to use the Cisco IOS to configure BGP and verify its operation. Finally, it examines BGP peering and the BGP routing process.
9.1.1 Overview of autonomous systems
An internetwork is a group of smaller, independent networks. Each of these smaller networks may be owned and operated by a different organization. These organizations can include a company, a university, a government agency, or some other group. The Internet is one example of a single, although immense, internetwork.
The operators of these individual networks desire independence or self-administration over their own systems. Because the routing and security policies of one organization may conflict with the policies of another, internetworks are divided into domains, or autonomous systems (AS). Each AS typically represents an independent organization and applies its own unique routing and security policies. EGPs facilitate the sharing of routing information between autonomous systems.
An AS is a group of routers that share similar routing policies and operate within a single administrative domain. An AS can be a collection of routers running a single IGP, or it can be a collection of routers running different protocols all belonging to one organization. In either case, the outside world views the entire Autonomous System as a single entity.
Each AS has an identifying number that is assigned by an Internet registry or a service provider. This number is between one (1) and 65,535. AS numbers within the range of 64,512 through 65,535 are reserved for private use. This is similar to RFC 1918 IP addresses. Because of the finite number of available AS numbers, an organization must present justification of its need before it will be assigned an AS number.
Today, the Internet Assigned Numbers Authority (IANA) is enforcing a policy whereby organizations that connect to a single provider and share the provider's routing policies use an AS number from the private pool, 64,512 to 65,535. These private AS numbers appear only within the provider's network and are replaced by the provider's registered number upon exiting the network. Therefore, to the outside world, several individual networks are advertised as part of one service provider's network. In principal, this process is similar to NAT. See Module 2, IP Addressing.
During the early days of the Internet, an Exterior Gateway Protocol, EGP version 3, was used to interconnect autonomous systems. EGP3 should not be confused with EGPs in general. Currently, BGP4 is the accepted standard for Internet routing and has essentially replaced the more limited EGP3.
The following sections detail the different types of autonomous systems such as single homed, multihomed nontransit, and multihomed transit. In addition to defining these three types of systems, the following sections will examine the role BGP has in connecting each type of AS to an ISP.
9.1.2 Single-homed autonomous systems
If an AS has only one exit point to outside networks, it is considered a single-homed system. Single-homed autonomous systems are often referred to as stub networks or stubs. Stubs can rely on a default route to handle all traffic destined for non-local networks. For the network shown in Figure , configure the routers in the customer AS to use a default route to an upstream service provider.
The following are three methods to advertise a customer's networks from the provider's perspective:
* Use a static configuration – The provider lists the customer's networks as static entries in its own router and advertises these routes upstream to the Internet core. This approach works well if the customer's networks can be summarized using a CIDR prefix, as discussed in Module 2. However, if the AS contains numerous discontiguous networks, route aggregation may not be a viable option.
* Use an IGP – Both the provider and the customer use an IGP to share information regarding the customer's networks. This provides the benefits associated with dynamic routing.
* Use an EGP – The third method by which the ISP can learn and advertise the customer's routes is to use an EGP such as BGP. In a single-homed autonomous system the customer's routing policies are an extension of the policies of the provider. For this reason the Internet number registries are unlikely to assign an AS number. Instead, the provider can give the customer an AS number from the private pool of AS numbers, 64,512 to 65,535. The provider will strip off these numbers when advertising the customer's routes towards the core of the Internet.
Notice that only the final solution requires the customers to enable BGP on their router.
9.1.3 Multihomed nontransit autonomous systems
An AS is a multihomed system if it has more than one exit point to outside networks. An AS connected to the Internet can be multihomed to a single provider or multiple providers. A nontransit AS does not allow transit traffic to pass through it. Transit traffic is any traffic that has a source and destination outside the AS. Figure illustrates a multihomed and nontransit AS, shown as AS 24, which is connected to two providers, ISP1 and ISP2.
A nontransit AS would advertise only its own routes to both providers to which it connects. It would not advertise routes that it learned from one provider to another. This makes certain that ISP1 will not use AS 24 to reach destinations that belong to ISP2, and ISP2 would not use AS 24 to reach destinations that belong to ISP1. Of course, ISP1 or ISP2 can force traffic to be directed to AS 24 by way of default or static routing. As a precaution against this, the router at the border of AS 24 could filter incoming traffic to prevent transit traffic from passing through its border router.
Multihomed nontransit autonomous systems do not really need to run BGP4 with their providers. It is usually recommended and often required by ISPs. As it will be seen later in this module, BGP4 offers numerous advantages, including increased control of route propagation and filtering.
9.1.4 Multihomed transit autonomous systems
A multihomed transit system has more than one connection to the outside world and can be used for transit traffic by other autonomous systems. The multihomed AS views transit traffic as any traffic originating from outside sources bound for outside destinations.
A transit AS can route transit traffic by running BGP internally so that multiple border routers in the same AS can share BGP information. Additional routers may be used to forward BGP information from one border router to another. BGP can be run inside an AS to facilitate this exchange.
When BGP is running inside an AS, it is referred to as Internal BGP (IBGP). When BGP runs between autonomous systems, it is called External BGP (EBGP). If the role of a BGP router is to route IBGP traffic, it is called a transit router. Routers that sit on the boundary of an AS and that use EBGP to exchange information with the ISP are called border or edge routers.
9.1.5 When not to use BGP
In many cases, the routing policy that is implemented in an AS is consistent with the policy for the ISP. In these cases, it is not necessary or even desirable, to use BGP to exchange routing information with the ISP. Instead, connectivity can be achieved through a combination of static routes and default routes.
Do not use BGP within the AS in the following situations:
* There is only a single connection to the Internet or other AS.
* Internet routing policy and route selection are not of concern to the AS.
* The BGP routers have insufficient RAM or processor power to handle constant updates.
* There is limited understanding of route filtering and the BGP path selection process.
* Low bandwidth link between autonomous systems
In Figure , router A is advertising a default network into the AS through a local IGP, such as RIP. A static route affords connectivity through router B to the AS for the ISP. The ISP is running BGP and is recognized by other BGP routers in the Internet.
NOTE:
In general, when there are different policy requirements than the ISP, it is necessary to use BGP to connect to an ISP.
9.2.1 BGP routing updates
BGP has been most recently defined in RFC 1772. The function of BGP is to exchange routing information between autonomous systems and guarantee the selection of a loop free path. BGP4 is the first version of BGP that supports CIDR and route aggregation. Common IGPs such as RIP, OSPF, and EIGRP use technical metrics. BGP does not use technical metrics. Instead, BGP makes routing decisions based on network policies, or rules.
This section offers a brief overview of how BGP works and is followed by a more detailed examination of the various types of BGP packets and relationship states.
BGP updates are carried using TCP on port 179. In contrast, RIP updates use UDP port 520, while OSPF does not use a Layer 4 protocol. Because BGP requires TCP, IP connectivity must exist between BGP peers. TCP connections must also be negotiated between them before updates can be exchanged. Therefore, BGP inherits those reliable, connection-oriented properties from TCP.
To guarantee loop free path selection, BGP constructs a graph of autonomous systems based on the information exchanged between BGP neighbors. BGP views the whole internetwork as a graph, or tree, of autonomous systems. The connection between any two systems forms a path. The collection of path information is expressed as a sequence of AS numbers called the AS Path. This sequence forms a route to reach a specific destination.
9.2.2 BGP neighbors
When two routers establish a TCP enabled BGP connection, they are called neighbors or peers. Each router running BGP is called a BGP speaker. Peer routers exchange multiple messages to open and confirm the connection parameters, such as the version of BGP to be used. If there are any disagreements between the peers, notification errors are sent and the connection fails.
When BGP neighbors first establish a connection, they exchange all candidate BGP routes. After this initial exchange, incremental updates are sent as network information changes. As discussed in earlier modules, incremental updates are more efficient than complete table updates. This is especially true with BGP routers, which may contain the complete Internet routing table.
Peers advertise destinations that are reachable through them by using update messages. These messages contain route prefix, AS path, path attributes such as the degree of preference for a particular route, and other properties.
The information for network reachability can change, such as when a route becomes unreachable or a better path becomes available. BGP informs its neighbors of this by withdrawing the invalid routes and injecting the new routing information. Withdrawn routes are part of the update message. BGP routers keep a table version number that tracks the version of the BGP routing table received from each peer. If the table changes, BGP increments the table version number. A rapidly incrementing table version is usually an indication of instabilities in the network, or a misconfiguration.
If there are no routing changes to transmit to a peer, a BGP speaker will periodically send keepalive messages to maintain the connection. These 19-byte keepalive packets are sent every 60 seconds by default. These packets present a negligible drain on bandwidth and the CPU time on a router.
9.2.3 BGP message types
Different message types play an essential role in BGP operation. Each message type includes the BGP message header.
The message header contains only three fields. They are a 16-byte Marker field, a 2-byte Length field, and a 1-byte Type field. The Marker field is used either to authenticate incoming BGP messages or to detect loss of synchronization between two BGP peers.
The Length field indicates the total BGP message length, including the header. The smallest BGP message is 19 bytes, 16 + 2 + 1, and the largest possible message is 4096 bytes.
The Type field can have four values, 1 to 4. Each of these values corresponds to one of the four BGP message types, described as follows:
* Open Message – This message is used to establish connections with peers and includes fields for the BGP version number, the AS number, hold time, and Router ID.
* Keepalive Message – This message type is sent periodically between peers to maintain connections and verify paths held by the router sending the keepalive. If the periodic timer is set to a value of zero (0), no keepalives are sent. The recommended keepalive interval is one third of the hold time interval. The keepalive message is a 19-byte BGP message header with no data following it.
* Notification Message – This message type is used to inform the receiving router of errors. This message includes a field for error codes that can be used to troubleshoot BGP connections.
* Update Message – The update messages contain all the information BGP uses to construct a loop free picture of the internetwork. There are three basic components of an update message. They are network-layer reachability information (NLRI), path attributes, and withdrawn routes. These three elements are described briefly in the following sections.
9.2.4 BGP neighbor negotiation
The BGP neighbor negotiation process proceeds through various states, or stages, which can be described in terms of a finite-state machine (FSM).
The BGP FSM
Recall that in Module 6, EIGRP, an FSM was defined. An FSM is a set of possible states something can go through, what events causes those states, and what events will result from those states. Figure presents the BGP FSM, which includes the states and some of the message events that cause them.
The six states of the BGP FSM are described as follows:
* Idle – Idle is the first state of a BGP connection. BGP is waiting for a start event. It is normally initiated by an administrator or a network event. At the start event, BGP initializes its resources and resets a connect retry timer. Then it starts listening for a TCP notice that BGP can transition back to Idle from any other state in case of errors.
* Connect – In the Connect state, BGP is waiting for the TCP connection to be completed. If the TCP connection is successful, the state transitions to OpenSent. If the TCP connection fails, the state transitions to the Active state, and the router tries to connect again. If the connect retry timer expires, the state remains in the Connect state, the timer is reset, and a TCP connection is initiated. In case of any other event, initiated by the system or the administrator, the state returns to Idle.
* Active – In the Active state, BGP is trying to acquire a peer by initiating a TCP connection. If it is successful, it transitions to OpenSent. If the connect retry timer expires, BGP restarts the connect timer and returns to the Connect state. While active, BGP is still listening for a connection that may be initiated from another peer. The state may go back to Idle in case of other events, such as a stop event initiated by the system or the operator.
In general, a neighbor state that is switching between "Connect" and "Active" is an indication that something is wrong and that there are problems with the TCP connection. It could be because of many TCP retransmissions, or the incapability of a neighbor to reach the IP address of its peer.
* OpenSent – In the OpenSent state, BGP is waiting for an open message from its peer. The open message is checked for correctness. In case of errors, such as an incompatible version number or an unacceptable AS, the system sends an error notification message and goes back to idle. If there are no errors, BGP starts sending keepalive messages and resets the keepalive timer. At this stage, the hold time is negotiated and the smaller value is taken. If the negotiated hold time is zero (0), the hold timer and the keepalive timer are not restarted.
At the OpenSent state, BGP recognizes whether the peer belongs to the same AS or to a different AS. BGP does this by comparing its AS number to the AS number of its peer. A same AS is an IBGP peer and a different AS is an EBGP peer.
When a TCP disconnect is detected, the state falls back to Active. For any other errors, such as an expiration of the hold timer, BGP sends a notification message with the corresponding error code. Then it returns to the Idle state.
* OpenConfirm – While in OpenConfirm state, BGP is waiting for a keepalive or notification message. If a keepalive message is received, the state goes to the Established state, and the neighbor negotiation is complete. If the system receives an update or keepalive message, it restarts the hold time, assuming that the negotiated hold time is not zero. If a notification message is received, the state falls back to Idle. The system sends periodic keepalive messages at the rate set by the keepalive timer. In the case of any TCP disconnect or in response to any stop event, initiated by the system or the administrator, the state returns to Idle. In response to any other event, the system sends a notification message with an FSM error code and returns to the Idle state.
* Established – Established is the final state in the neighbor negotiation. BGP starts exchanging update packets with its peers. If it is non-zero, the hold timer is restarted at the receipt of an update or keepalive message.
Each update message is checked for errors, such as missing or duplicate attributes. If errors are found, a notification is sent to the peer. Any notification received while in the Established state will cause the BGP process to drop the receiving peer back to Idle. If the hold timer expires, a disconnect notification is received from TCP or if a stop event is received, the system will return to Idle.
9.2.5 Network-layer reachability information (NLRI)
Rather than advertise reachable destinations as a network and a subnet mask, BGP advertises them using network-layer reachability information (NLRI), which consists of prefixes and prefix lengths. The prefix represents the reachable destination, and the prefix length represents the number of bits set in the subnet mask. For example, 10.1.1.0 255.255.255.0 has a prefix of 10.1.1.0 and a prefix length of 24.
NOTE:
There are 24 bits set in the subnet mask. Therefore it would be advertised by BGP as 10.1.1.0/24.
The NLRI consists of multiple instances of the 2-tuple
Withdrawn Routes
Withdrawn routes provide a list of routing updates that are no longer reachable and that need to be withdrawn or removed from the BGP routing table. Withdrawn routes have the same format as NLRI.
An update message that has no NLRI or path attribute information is used to advertise only routes to be withdrawn from service.
9.2.6 Path attributes
Much of the work in configuring BGP focuses on path attributes. Each route has its own set of defined attributes that can include path information, route preference, next hop, and aggregation information. Administrators use these values to enforce routing policy. Based on attribute values, BGP can be configured to filter routing information, prefer certain paths, or otherwise customize its behavior. Many of these attributes and policy configurations are explored later in this module, in the section "The BGP Routing Process".
Every update message has a variable length sequence of path attributes in the form
Because path attributes will be used extensively when configuring routing policy, note that not all vendor implementations of BGP recognize the same attributes. The following are the four different attribute types:
* Well-known mandatory – An attribute that must exist in the BGP update packet. It must be recognized by all BGP implementations. If a well-known attribute is missing, a notification error will be generated. This ensures that all BGP implementations agree on a standard set of attributes. An example of a well-known mandatory attribute is the AS_Path attribute.
* Well-known discretionary – An attribute that is recognized by all BGP implementations, but may or may not be sent in the BGP update message. An example of a well-known discretionary attribute is the LOCAL_PREF attribute.
* Optional transitive – An attribute that may or may not be recognized by all BGP implementations, therefore, it is optional. Because the attribute is transitive, BGP should accept and advertise the attribute even if it is not recognized.
* Optional nontransitive – An attribute that may or may not be recognized by all BGP implementations. Whether or not the receiving BGP router recognizes the attribute, it is nontransitive and is not passed along to other BGP peers.
Each individual attribute is identified by its type and attribute code. Figure lists the attribute codes that are currently defined.
Several of these attributes are discussed later in this module. Attributes 11, 12, and 13 are not implemented by Cisco because they do not add functionality and will not be covered.
9.3.1 Basic BGP configuration
BGP configuration commands appear on the surface to mirror the syntax of familiar IGP commands. Examples of familiar IGP commands are RIP and OSPF. Although the syntax is similar, the function of these commands is significantly different.
To begin configuring a BGP process, issue the following familiar command:
Router(config)#router bgpAS-number
Notice that the Cisco IOS permits only one BGP process to run at a time. Therefore, a router cannot belong to more than one BGP AS.
The network command is used with IGPs, such as RIP, to determine the interfaces on which to send and receive updates. The command also indicates which directly connected networks to advertise. However, when configuring BGP, the network command does not affect what interfaces BGP runs on. Therefore, configuring just a network statement will not establish a BGP neighbor relationship. This is a major difference between BGP and IGPs. The network statement follows this syntax:
Router(config-router)#network network-number [masknetwork-mask]
In BGP, the network command tells the BGP process what locally learned networks to advertise. The networks can be connected routes, static routes, or routes learned by way of a dynamic routing protocol, such as RIP. These networks must also exist in the routing table of the local router or they will not be sent out in updates. The mask keyword can be used with the network command to specify individual subnets. Routes learned by the BGP process are propagated by default but are often filtered by a routing policy.
For a BGP router to establish a neighbor relationship with another BGP router, issue the following configuration command:
Router(config-router)#neighborip-address remote-as AS-number
This command serves to identify a peer router with which the local router will establish a session. The ip-address argument is the IP address of the neighbor interface. The AS-number argument determines whether the neighbor router is an EBGP or an IBGP neighbor.
9.3.2 EBGP and IBGP
When configuring BGP, remember that BGP supports the following two types of sessions, each with slightly different configuration requirements:
* EBGP session – Occurs between routers in two different autonomous systems. These routers are usually adjacent to one another, sharing the same medium and a subnet. See RTA in Figure .
* IBGP session – Occurs between routers in the same AS, and is used to coordinate and synchronize routing policy within the AS. Neighbors may be located anywhere in the AS, even several hops away from one another. An IBGP session typically occurs between routers in the same AS in an ISP.
If the AS-number configured in the router bgp command is identical to the AS-number configured in the neighbor statement, BGP will initiate an internal session. If the field values are different, BGP will build an external session.
9.3.3 EBGP and IBGP configuration example
The example in Figure , RTB speaks EBGP to RTA, which is a different AS, and speaks IBGP to RTC, which resides in the same AS. To start the EBGP process with RTA, use the following commands:
RTB(config)#router bgp 200
Notice that the remote-as value of 100, from the neighbor command, is different from the AS number of 200, specified by the router bgp command. Because the two AS numbers are different, BGP will start an EBGP connection with RTA. Communication will occur between autonomous systems.
The commands to configure IBGP are essentially the same as those to configure EBGP, except for the possible addition of the update-source interface keyword.
RTB(config)#router bgp 200
RTB(config-router)#neighbor 172.16.1.2 remote-as 200
RTB(config-router)#neighbor 172.16.1.2 update-source loopback 0
The remote-as value, 200, is the same as the AS number for the BGP on RTB. Therefore, BGP recognizes that this connection will occur within AS 200. It attempts to establish an IBGP session. In reality, AS 200 is not a remote AS at all as it is the local AS with both routers residing there. For simplicity, the keyword remote-as is used when configuring both EBGP and IBGP sessions.
Also notice the second neighbor command. This is used to assign an optional parameter to be used when communicating with that neighbor. It is typical to use multiple neighbor commands for the same BGP neighbor, each specifying a particular BGP option.
In this example, the option specified is update-source loopback 0. If multiple pathways to the neighbor exist, then the router can use any IP interface to speak BGP with that neighbor. The update-source loopback 0 command is used to instruct the router to use interface loopback zero (0) for TCP connections. This command is typically used in all IBGP configurations. Without this command, BGP routers can use only the closest IP interface to the peer. The capability to use any operational interface provides BGP with robustness in case the link to the closet interface fails. Because EBGP sessions are typically point-to-point, there is no need to use this command with EBGP.
Returning to the example configuration, assume that the following route appears on the table for RTB:
O 192.168.1.0/24 [110/74] via 10.2.2.1, 00:31:34, Serial2
RTB learned this route by way of an Interior Gateway Protocol, by using OSPF. AS 200 uses OSPF internally to exchange route information. RTB can advertise this network by way of BGP. Redistributing OSPF into BGP will work. However, using the following BGP network command will do the same thing:
RTB(config-router)#network 172.16.1.0 mask 255.255.255.252
RTB(config-router)#network 10.1.1.0 mask 255.255.255.252
RTB(config-router)#network 192.168.1.0
The first two network commands listed include the mask keyword, so only a particular subnet is specified. The third network command results in the OSPF route being advertised by BGP without redistribution. Remember that the BGP network command works differently than the IGP network command.
9.3.4 EBGP multihop
These example configurations have shown how to configure EBGP and IBGP. However, what is the difference between the configuration types? Figure presents some of the important characteristics between these BGP session types.
RTZ and RTY have established an EBGP session. EBGP peers are normally directly connected, but there are certain exceptions to this requirement. In contrast, IBGP peers merely require TCP/IP connectivity within the same AS. As long as RTY can communicate with RTW using TCP, both routers can establish an IBGP session. If needed, an IGP such as OSPF can provide IBGP peers with routes to each other.
In a typical configuration, an IBGP router maintains IBGP sessions with all other IBGP routers in the AS, forming a logical full mesh. This is necessary because IBGP routers do not advertise routes learned by way of IBGP to other IBGP peers, to prevent routing loops. In other words, if the IBGP routers are to exchange BGP routes with each other, configure a full mesh. An alternative to this approach is configuring a route reflector. Information on route reflectors can be obtained from the Cisco web site.
As noted, EBGP neighbors must be directly connected to establish an EBGP session. However, look again at RTW and RTU in Figure . These routers can maintain an EBGP session even though a non-BGP router, RTV, separates them. In this situation, EBGP is running across a non-BGP router using a configurable option called EBGP multihop. EBGP multihop is a Cisco IOS option that allows RTW and RTU to be logically connected in an EBGP session. This is despite the fact that RTV does not support BGP. The EBGP multihop option is configured on each peer with the following command:
Router(config-router)#neighborip-address ebgp-multihop [hops]
This command enables the specification of how many hops, up to 255, separate the EBGP peers. The following commands could be applied to the routers in the example:
RTW(config)#router bgp 200
RTW(config-router)#neighbor 1.1.1.2 remote-as 300
RTW(config-router)#neighbor 1.1.1.2 ebgp-multihop 2
RTU(config)#router bgp 300
RTU(config-router)#neighbor 2.2.2.1 remote-as 200
RTU(config-router)#neighbor 2.2.2.1 ebgp-multihop 2
In general, EBGP multihop is designed to allow the development of economical AS edge router solutions. A single router with sufficient RAM and CPU power to support BGP is used to handle the BGP routing needs. This router does not have to be an expensive modular, chassis based system. EBGP multihop allows inexpensive edge routers to provide sufficient WAN interfaces for the autonomous systems connectivity needs.
9.3.5 Clearing the BGP table
When configuring BGP, changes made to an existing configuration may not appear immediately. In order to force BGP to clear its table and reset BGP sessions, use the clear ip bgp * command as follows:
Router#clear ip bgp *
The asterisk (*) is a wildcard that matches all table entries. Therefore, all BGP routes are lost while the neighbor relationships are reset. This is expedient and very useful in a lab situation, but caution should be exercised when issuing this command on a production router. On an Internet backbone router, it may be more appropriate to use this command with a specific IP address, as shown in the following:
Router#clear ip bgp 10.0.0.0
By specifying a particular network to clear, it prevents all BGP information from being temporarily lost.
9.3.6 Peering
Any two routers that have formed a TCP connection in order to exchange BGP routing information are called peers or neighbors.
Figure demonstrates the different types of BGP peering sessions that will be encountered. An IBGP peering session is formed within AS 3, between the loopback address of RTA and a physical address of RTF. An EBGP session is also formed between AS 3 and AS 1 by using the two directly connected IP addresses of RTA and RTC. Another EBGP session is formed between RTF in AS 3 and RTD in AS 2, using IP addresses that are not on the same segment, multihop.
It is important to remember that the BGP peers will never become established unless there is IP connectivity between the two peers. In this example, OSPF is used to establish the required internal connectivity between RTD and RTE.
NOTE:
Click on the topology in Figure to view command outputs.
In the configuration from RTF, the ebgp-multihop 2 command is seen being used as part of the neighbor configuration. This is an indication that the exterior BGP peer is not directly connected and can be reached at a maximum of two hops away. Remember that EBGP multihop is applicable only with EBGP, and not with IBGP.
The example also shows how the peer connection will look after the neighbors are in an established state. RTF sees neighbor 172.16.2.254 as an internal neighbor that belongs to AS3. The neighbor connection is running BGP Version 4 with a table version of two (2). The table version changes every time the BGP table is updated.
The other RTF neighbor, 192.68.12.1, is also in an Established state. This is an external neighbor that belongs to AS2. Notice that the display indicates that this neighbor is two hops away and is configured using the ebgp-multihop command.
9.3.7 BGP continuity inside an AS
BGP does not advertise routes learned by way of IBGP peers to other IBGP peers. If BGP did, BGP routing inside the AS would present a dangerous potential for routing loops. For IBGP routers to learn about all BGP routes inside the AS, they must connect to every other IBGP router in a full IBGP mesh. This full mesh needs to be only logical, not physical. In other words, as long as the IBGP peers can connect to each other using TCP/IP, a logical full mesh can be created even if the routers are not directly connected.
Figure illustrates one of the common mistakes that administrators make when setting BGP routing within an AS. This ISP network has three POPs (San Jose, San Francisco, and Los Angeles). Each POP has multiple non-BGP routers and a BGP border router running EBGP with other autonomous systems. The administrator has set up an IBGP connection between the San Jose border router and the San Francisco border router. Another IBGP connection has been set up between the San Francisco border router and the Los Angeles border router. In this configuration, EBGP routes learned by way of San Jose are given to San Francisco. EBGP routes learned by way of San Francisco are given to San Jose and Los Angeles. Lastly EBGP routes learned by way of Los Angeles are given to San Francisco.
However, routing in this scenario is not complete. EBGP routes learned by way of San Jose will not be given to Los Angeles, and EBGP routes learned by way of Los Angeles will not be given to San Jose. This is because the San Francisco router will not advertise IBGP routes between San Jose and Los Angeles. What is needed is an additional IBGP connection between San Jose and Los Angeles. This connection is shown as a dotted line.
9.4.1 Verifying BGP operation
Verify BGP operation by using the key show commands.
If the router has not installed the BGP routes expected, use the show ip bgp command to verify that BGP has learned these routes.
Notice that the output of this command includes the BGP table version number, which increments each time the local router receives changed route information. The AS_Path, among other key attributes, is also included in this table. Routes that are considered the best are denoted by the > character and are installed in the router IP routing table.
An expected BGP route may not appear in the BGP table. If this happens, use the show ip bgp neighbors command to verify that the router has established a BGP connection with its neighbors. The most important information output of this command is the BGP state that exists between the neighbors. Anything other than "Established" indicates that the peers are not fully communicating.
The show ip bgp neighbors command supports a number of optional parameters and syntax.
9.5.1 An overview of the BGP routing process
This section describes the process that BGP uses to make routing decisions. Routes are exchanged between BGP peers by way of update messages. BGP routers receive the update messages, perform some policies or filters on the updates, and then pass the routes on to other BGP peers.
The Cisco implementation of BGP keeps track of all BGP updates in a BGP table separate from the IP routing table. In case multiple routes to the same destination exist, BGP does not flood its peers with all those routes. Instead, BGP picks only the best route and sends it to the peers. In addition to passing along routes from peers, a BGP router may originate routing updates to advertise networks that belong to its own AS. Valid local routes originated in the system and the best routes learned from BGP peers are then installed in the IP routing table. The IP routing table is used for the final routing decision.
The following sections detail the BGP routing process, implementing BGP routing policy, controlling BGP routing with attributes, and handling the BGP decision process.
9.5.2 The BGP routing process model
To model the BGP process, imagine each BGP speaker having different pools of routes and different policy engines applied to the routes. The model, shown in Figure , would involve the following components:
* Routes received from peers – BGP receives routes from external or internal peers. Depending on what is configured in the input policy engines, some or all of these routes will make it into the router BGP table.
* Input policy engine – This engine handles route filtering and manipulation of attributes. Filtering is done based on parameters such as the IP prefix, the AS path, and attribute information.
The input policy engine is used to manipulate the path attributes and influences the decision process made by BGP. This affects what routes it will actually use to reach a certain destination. For example, if choosing to filter a certain network coming from a peer, it is an indication to BGP that it should not reach that network by way of that peer. A certain route can be given a better local preference than some other path to the same destination. This is an indication that BGP should prefer this route instead of the other available routes.
* The decision process – BGP goes through a decision process to decide the route or routes it wants to use to reach a certain destination. The decision process is based on the routes that made it into the router after the input policy engine was applied. This is performed on the routes in the BGP routing table. The decision process looks at all the available routes for the same destination, compares the different attributes associated with each route, and chooses one best route. The decision process is discussed later in this module, in the section "The BGP Decision Process".
* Routes used by the router – The best routes, as identified by the decision process, are candidates to be advertised to other peers. These routes are also presented to the routing engine to be placed in the IP routing table. Not all routes presented to the routing engine will be placed in the routing table. This is because multiple protocols may present the same prefix for installation, and the router must choose among them based on administrative distance. In addition to routes passed on from other peers, the router, if configured to do so, originates updates about the networks inside its own AS. This is how an AS injects its routes into the outside world.
* Output policy engine – This is the same engine as the input policy engine, applied on the output side. Routes used by the router, the best routes, in addition to routes that the router generates locally are given to this engine for processing. The engine might apply filters and might change some of the attributes, such as AS_Path or metric, before sending the update.
The output policy engine also differentiates between internal and external peers. For example, routes learned from internal peers cannot be passed on to internal peers.
* Routes advertised to peers – The routes advertised to peers are routes that made it through the output engine and are advertised to the BGP peers, internal or external.
9.5.3 Implementing BGP routing policy
Input and output policies generally are defined using route maps. Route maps are used with BGP to control and modify routing information. Route maps are used to define how the routes are redistributed between routing domains.
Recall from Module 8, Route Optimization, that the route-map command is entered using the following syntax:
Router(config)#route-map map-tag [permit | deny] [sequence-number]
Notice that map-tag is a name that identifies the route map. The sequence-number indicates the position that an instance of the route map is to have in relation to other instances of the same route map. Instances are ordered sequentially, starting with the number ten by default.
For example, the route-map command might be used as follows, to define a route map named MYMAP:
route-map MYMAP permit 10
! First set of conditions goes here.
route-map MYMAP permit 20
! Second set of conditions goes here.
When BGP applies MYMAP to routing updates, it applies the lowest instance first. In this case, instance ten (10). If the first set of conditions is not met, the second instance is applied, and so on, until either a set of conditions has been met or there are no more sets of conditions to apply. If the update does not match in any instance, the update is not redistributed or controlled.
The condition portion of a route map is set by using the match and set commands. The match command specifies what criteria must be matched. The set command specifies an action that is to be taken if the routing update meets the conditions defined by the match command.
Figure shows the commands needed to create a simple route map. Access list 1 is used in the configuration as a way to specify routes.
Recall that there are two types of access lists, standard and extended. The main difference is that a standard access list is applied to the source IP address, whereas an extended access list is normally applied to the source and destination of a packet. However, when used to filter routes within BGP, the first address or wildcard bit set given in an extended access list applies to the prefix. The second address or wildcard bit set applies to the subnet mask of the advertised route.
Access list 1 identifies all routes of the form 1.1.1.x. A routing update of the form 1.1.1.x will match the access list and will be propagated with a metric set to five (5). This is because of the permit keyword in the access list.
A route map can be applied on the incoming, using the keyword in, or the outgoing, using the keyword out, BGP updates. Figure shows the commands needed to apply the route map MYMAP on the outgoing updates toward BGP neighbor 172.16.20.2.
9.6.1 Controlling BGP routing with attributes
Traffic inside and outside an AS always flows according to the road map laid out by routes. If the routes are altered, the traffic behavior will be affected. The following are among the questions that organizations and service providers ask about controlling routes:
* How can the private networks be prevented from being advertised?
* How can routing updates that come from a particular neighbor be filtered?
* How can it be specified to use this link or this provider rather than another one?
Through the use of attributes, BGP provides the answer to all these questions and more.
A BGP speaker can receive updates from multiple autonomous systems that describe different paths to the same destination. It must then choose the single best path for reaching that destination. Once chosen, BGP propagates the best path to its neighbors. The decision is based on the value of attributes, such as Next Hop or Local Preference, that the update contains and other configurable BGP factors. The following sections provide an overview of these key attributes that BGP uses in the decision making process:
* Next Hop
* AS_Path
* Atomic Aggregate
* Aggregator
* Local Preference
* Weight
* Multiple Exit Discriminator (MED)
* Origin
9.6.2 The Next Hop attribute
The next hop attribute is a well-known mandatory attribute, type code 3. In terms of an IGP, such as RIP, the "next hop" to reach a route is the IP address of the router that has announced the route.
The next hop concept with BGP is more complex and takes one of the following three forms:
* For EBGP sessions, the next hop is the IP address of the neighbor that announced the route.
* For IBGP sessions, where routes originated inside the AS, the next hop is the IP address of the neighbor that announced the route. For routes injected into the AS by way of EBGP, the next hop learned from EBGP is carried unaltered into IBGP. The next hop is the IP address of the EBGP neighbor from which the route was learned.
* When the route is advertised on a multiaccess medium, such as Ethernet or Frame Relay, the next hop is usually the IP address of the interface of the router. This will be the interface connected to the media that originated the route.
Figure illustrates the BGP Next Hop attribute. RTC is running an EBGP session with router RTZ and an IBGP session with router RTA. RTC is learning route 128.213.1.0/24 from RTZ. In turn, RTC router is injecting the local route 128.212.1.0/24 into BGP.
RTA learns route 128.212.1.0/24 by way of 2.2.2.2, the IP address of the IBGP peer announcing the route. Therefore, according to the definition, 2.2.2.2 is the next hop for RTA to reach 128.212.1.0/24. Similarly, RTC sees 128.213.1.0/24 coming from RTZ by way of Next Hop 1.1.1.1. When it passes this route update to RTA by way of IBGP, RTC includes the next hop information, unaltered. Therefore, RTA receives the BGP update about 128.213.1.0/24 with Next Hop 1.1.1.1. This is an example of the EBGP next hop being carried into IBGP.
As can be seen, the next hop is not necessarily reachable by way of a direct connection. The next hop for RTA for 128.213.1.0/24 is 1.1.1.1, but reaching it requires a pathway through 3.3.3.3.Therefore, the next hop behavior mandates a recursive IP routing table lookup for a router to know where to send the packet. To reach the Next Hop 1.1.1.1, RTA will consult its IGP routing table to see if and how 1.1.1.1 is reachable. This recursive search continues until the router associates destination 1.1.1.1 with an outgoing interface. The same recursive behavior is performed to reach Next Hop 2.2.2.2. If a hop is not reachable by way of an IGP, BGP considers the route as being inaccessible.
9.6.3 Next Hop behavior on multiaccess media
Recall that a network link is considered multiaccess if more than two hosts can potentially connect to it. Routers on a multiaccess link share the same IP subnet and can physically access all other connected routers in one hop. Ethernet, Frame Relay, and ATM are examples of multiaccess media.
BGP speakers should always advertise the actual source of the route if the source is on the same multiaccess link as the speaker. In other words, RTC advertises a route learned from RTB, and RTC and RTB share a common multiaccess media. Then when RTC advertises the route, it should indicate RTB as being the source of the route. If not, routers on the same medium would have to make an unnecessary hop by way of RTC to get to a router that is sitting in the same segment.
In Figure , RTA, RTB, and RTC share a common multiaccess medium. RTA and RTC are running EBGP, while RTC and RTB are running OSPF. RTC has learned network 11.11.11.0/24 from RTB by way of OSPF and is advertising it to RTA by way of EBGP. Since RTA and RTB are running different routing protocols, it would seem logical that RTA would consider RTC (10.10.10.2) as its next hop to reach 11.11.11.0/24. However, this would not happen. The correct behavior is for RTA to consider RTB, 10.10.10.3, as the next hop because RTB shares the same medium with RTC.
When the media is broadcast, such as Ethernet and FDDI, physical connectivity is assumed and the next hop behavior is not an issue. However, when the media is nonbroadcast, such as Frame Relay and ATM, special care should be taken as described in the following section.
9.6.4 Next Hop behavior on NBMA networks
On an NBMA network, the many-to-many direct interaction between routers is not guaranteed unless virtual circuits are configured from each router to all other routers. The primary reason that most organizations implement a hub-and-spoke topology is because of cost considerations. In a hub-and-spoke topology, multiple remote sites have virtual circuits connected to one or more routers at a central site. Figure illustrates an example of next hop behavior in a nonbroadcast multiaccess environment.
The only difference between the environments illustrated is that the medium in Figure is a Frame Relay cloud that is NBMA. RTC is the hub router and RTA and RTB are the spokes. Notice that the virtual circuits are laid out between RTC and RTA, and between RTC and RTB, but not between RTA and RTB. This is a partially meshed topology.
RTA gets a BGP routing update about 11.11.11.0/24 from RTC and would try to use RTB, 10.10.10.3, as the next hop. This is the same behavior as on multiaccess media. Routing will fail because no virtual circuit exists between RTA and RTB.
Cisco IOS supports a special case parameter that remedies this situation. The next-hop-self keyword forces the router, in this case, RTC, to advertise 11.11.11.0/24 with itself as the next hop, 10.10.10.2. RTA then directs its traffic to RTC to reach destination 11.11.11.0/24. The syntax for this option is as follows:
Router(config-router)#neighbor ip-address next-hop-self
For RTC, issue the following command:
RTC(config-router)#neighbor 10.10.10.1 next-hop-self
9.6.5 The AS_Path attribute
An AS_Path attribute is a well-known mandatory attribute, type code 2. It is the sequence of AS numbers that a route has traversed to reach a destination. The AS that originates the route adds its own AS number when sending the route to its external BGP peers. Thereafter, each AS that receives the route and passes it on to other BGP peers will prepend its own AS number to the list. Prepending is the act of adding the AS number to the beginning of the list. The final list has all the AS numbers that a route has traversed with the AS number of the AS that originated the route at the end of the list. This type of AS_Path list is called an AS_Sequence because all the AS numbers are ordered sequentially.
BGP uses the AS_Path attribute as part of the routing updates, update packet, to ensure a loop free topology on the Internet. Each route that gets passed between BGP peers will carry a list of all AS numbers that the route has already been through. If the route is advertised to the AS that originated it, that AS will see itself as part of the AS_Path attribute list and will not accept the route. BGP speakers prepend their AS numbers when advertising routing updates to other autonomous systems, external peers. When the route is passed to a BGP speaker within the same AS, the AS_Path information is left intact.
Figure illustrates the AS_Path attribute at each instance of the route 172.16.10.0/24, originating in AS1 and passed to AS2, AS3, AS4, and back to AS1. Notice how each AS that passes the route to other external peers adds its own AS number to the beginning of the list. When the route gets back to AS1, the BGP border router will realize that this route has already been through its AS. The AS number one (1) appears in the list, and will not accept the route.
AS_Path information is one of the attributes that BGP looks at to determine the best route to reach a destination. In comparing two or more different routes, given that all other attributes are identical, a shorter path is always preferred. In case of a tie in AS_Path length, other attributes are used to make the decision.
9.6.6 AS_Path and private AS numbers
In an effort to conserve AS numbers, customers whose routing policies are an extension of the policies of their provider generally are not assigned a legal AS number. Therefore, if a customer is single-homed or multihomed to the same provider, the provider generally requests that the customer use an AS number taken from the private pool, 64,512 to 65,535. As such, all BGP updates that the provider receives from its customer contain private AS numbers.
Private AS numbers cannot be advertised to the Internet because they are not unique. For this reason, Cisco has implemented a feature to strip private AS numbers out of the AS_Path list before the routes get propagated to the Internet.
In Figure , AS1 is providing Internet connectivity to its customer AS 65001. Because the customer connects to only this provider and has no plans to connect to an additional provider in the near future, the customer has been allocated a private AS number. Should the customer need connectivity to another provider, a legal AS number must be assigned.
Prefixes originating from AS65001 have an AS_Path of 65001. Notice the prefix 172.16.220.0/24 as it leaves AS65001. For AS1 to propagate the prefix to the Internet, it would have to strip the private AS number. When the prefix reaches the Internet, it would look like it has originated from the provider's AS. Notice how prefix 172.16.220.0/24 has reached the network access point (NAP) with AS_Path 1.
BGP will strip private AS numbers only when propagating updates to the external peers. This means that the AS stripping would be configured on RTB as part of its neighbor connection to RTC.
Privately numbered autonomous systems should be used only when connected to a single provider. If the AS_Path contains a mixture of private and legal AS numbers, BGP will view this as an illegal design. BGP will not strip the private AS numbers from the list, and the update will be treated as usual. Only AS_Path lists that contain private AS numbers in the range 64,512 to 65,535 are stripped.
The example that follows demonstrates how BGP can be configured to prevent the leakage of private AS numbers into the Internet.
RTB(config)#router bgp 1
RTB(config-router)#neighbor 172.16.20.2 remote-as 65001
RTB(config-router)#neighbor 192.168.6.3 remote-as 7
RTB(config-router)#neighbor 192.168.6.3 remove-private-as
Notice how RTB is using the remove-private-as keyword in its neighbor connection to AS7.
9.6.7 The Atomic Aggregate attribute
The Atomic Aggregate attribute is a well-known discretionary attribute, type code 6. The Atomic Aggregate attribute is set to either True or False. If True, this attribute alerts BGP routers that multiple destinations have been grouped into a single update. In other words, the BGP router that sent the update had a more specific route to the destination but did not send it. Because this can lead to routing problems, the Atomic Aggregate attribute warns receiving routers that the information they are receiving is not necessarily the most complete route information available.
BGP can be manually configured to summarize routes by using the aggregate-address command.
Using the aggregate-address command with no arguments will create an aggregate entry, a supernet route, in the BGP routing table. This happens as long as the router knows at least one specific BGP route that belongs to that supernet. Therefore, if the router knows just one route, it can claim to know hundreds of others. This feature should be used with caution. The aggregate route will be advertised as coming from the AS on the router and has the Atomic Aggregate attribute set to True. This shows that information might be missing. By default, the Atomic Aggregate attribute is set to True unless the as-set keyword is specified.
Using the as-set keyword creates an aggregate entry. However, the path advertised for this route will be an AS_Set consisting of all elements contained in all paths that are being summarized. Do not use this form of aggregate-address when aggregating many paths. This route must be continually withdrawn and updated as autonomous system path reachability information for the summarized route changes.
If the router is to propagate the supernet route only, and not to propagate any more specific routes, use the summary-only keyword. When configured using this keyword, the router will send the supernet route and suppress the more specific routes known to BGP.
The following example shows the commands needed to configure a simple supernet advertisement, which will be sent with the Atomic Aggregate attribute set to True.
RTA(config)#router bgp 300
RTA(config-router)#neighbor 3.3.3.3 remote-as 200
RTA(config-router)#neighbor 2.2.2.2 remote-as 100
RTA(config-router)#network 160.10.0.0
RTA(config-router)#aggregate-address 160.0.0.0 255.0.0.0
If RTA is to suppress more specific routes and to update other BGP routers only about the supernet 160.0.0.0 /8, issue this command:
RTA(config-router)#aggregate-address 160.0.0.0 255.0.0.0 summary-only
9.6.8 The Aggregator attribute
Aggregator is a well-known discretionary attribute, type code 7. When configuring address aggregation, the router can also be configured to include its router ID and local AS number along with the supernet route. This attribute enables ISP administrators to determine which BGP router is responsible for a particular instance of aggregation. Tracing a supernet to its original "aggregator" may be necessary for troubleshooting purposes.
9.6.9 The Local Preference attribute
Local Preference is a well-known discretionary attribute, type code 5. The Local Preference attribute is a degree of preference given to a route for comparison with other routes for the same destination. Higher Local Preference values are preferred. Local Preference, as indicated by the name, is local to the AS and is exchanged between IBGP peers only. Local Preference is not advertised to EBGP peers.
Routers within a multihomed AS may learn that they can reach the same destination network by way of neighbors in two or more different autonomous systems. In effect, there could be two or more exit points from the local AS to any given destination. Use the Local Preference attribute to force the BGP routers to prefer one exit point instead of another when routing to a particular destination network. Because this attribute is communicated within all BGP routers inside the AS, all BGP routers will have a common view on how to exit the AS.
NOTE:
Although routers always prefer the lowest route metric and administrative distance for a given destination, BGP routers prefer higher Local Preference values over lower ones.
Consider the environment illustrated in Figure . Suppose that company ANET has purchased Internet connections from two service providers, XNET and YNET. ANET is connected to YNET by way of a primary T3 link and to XNET by way of a backup T1 link.
It is important for ANET to decide what path its outbound traffic is going to take. Of course, the network administrators for ANET prefer to use the T3 link by way of YNET in normal operation as it is a high speed link. This is where Local Preference starts. LA can give the routes coming from YNET a Local Preference of 300, and San Jose can give the routes coming from XNET a lower value, such as 200. Because both San Jose and LA are exchanging routing updates by way of IBGP, they both agree that the exit point of the AS is going to be by way of YNET. This happens because of the higher local preference.
In Figure , ANET learns route 128.213.0.0/16 by way of XNET and YNET. San Jose and LA will agree on using YNET as the exit point for destination 128.213.0.0/16 because of the higher Local Preference value of 300. The Local Preference manipulation discussed in this case affects the traffic going out of the AS and not traffic coming into the AS. Inbound traffic can still come by way of the T1 link.
9.6.10 Manipulating Local Preference
In Figure , AS 256 receives route updates for network 170.10.0.0 from AS 100 and AS 300. The following are two ways to set the Local Preference attribute on the routers in AS 256:
* Use the bgp default local-preference command
* Use a route map to set local preference
Using the bgp default local-preference command, set the Local Preference attribute on RTC and RTD as follows:
RTC(config)#router bgp 256
RTC(config-router)#neighbor 1.1.1.1 remote-as 100
RTC(config-router)#neighbor 128.213.11.2 remote-as 256
RTC(config-router)#bgp default local-preference 150
RTD(config)#router bgp 256
RTD(config-router)#neighbor 3.3.3.4 remote-as 300
RTD(config-router)#neighbor 128.213.11.1 remote-as 256
RTD(config-router)#bgp default local-preference 200
The configuration from RTC causes it to set the Local Preference of all updates from AS 100 to 150. The configuration from RTD causes it to set the Local Preference for all updates from AS 300 to 200. Because Local Preference is exchanged within the AS, both RTC and RTD determine that updates regarding network 170.10.0.0 have a higher Local Preference when they come from AS 300 than when they come from AS 100. As a result, all traffic in AS 256 destined for network 170.10.0.0 is sent RTD.
As an alternate configuration, use a route map. Route maps provide more flexibility than the bgp default local-preference configuration command. When the bgp default local-preference command is used on RTD, the Local Preference attribute of all updates received by RTD will be set to 200. This includes updates from AS 34. The example configuration in Figure uses a route map to set the Local Preference attribute on RTD specifically for updates regarding AS 300.
Notice that the configuration shown in the Figure uses the ip as-path access-list command, which matches the regular expression ^300$. Essentially, this statement matches any routes that include AS 300 in their AS_Path attribute.
With the configuration, the Local Preference attribute of any update coming from AS 300 is set to 200 by instance ten (10) of the route map, SETLOCALIN. Instance 20 of the route map accepts all other routes.
9.6.11 The Weight attribute
The Weight attribute is similar to the Local Preference attribute in that it gives higher preference to the route that has a higher weight. The difference is that the weight parameter is local to the router and is not exchanged between routers. The weight parameter influences routes coming from different providers to the same router, one router with multiple connections to two or more providers. The weight parameter has a higher precedence than any other attribute. It is the most important attribute when determining route preference. The Weight attribute is a Cisco proprietary attribute.
The following paths with highest weight value are most desirable:
* Weight configured on routers, on a per-neighbor basis
* Weight attribute not sent to any BGP neighbors
9.6.12 The Multiple Exit Discriminator attribute
The Multiple-exit-discriminator (MED) attribute is an optional nontransitive attribute, type code 4. MED informs external neighbors about the preferred path into an AS that has multiple entry points. A lower MED is preferred over a higher MED.
Unlike Local Preference, the MED attribute is exchanged between autonomous systems, but a MED attribute that comes into an AS does not leave the AS. When an update enters the AS with a certain MED value, that value is used for decision making within the AS. When BGP forwards the routing update to another AS, the MED is reset to zero. This is true unless the outgoing MED is set to a specific value.
When the route is originated by the AS itself, the MED value typically follows the internal IGP metric of the route. This becomes useful when a customer has multiple connections to the same provider. The IGP metric reflects how close or how far a network is to a certain exit point. A network that is closer to exit point A than to exit point B will have a lower IGP metric in the border router connected to A. When the IGP metric translates to MED, traffic coming into the AS can enter from the link closer to the destination. This is because a lower MED is preferred for the same destination. This can be used by both providers and customers to balance the traffic over multiple links between two autonomous systems.
Unless otherwise specified, the router compares MED attributes for paths from external neighbors that are in the same AS. MEDs from different autonomous systems are not comparable because the MED associated with a route usually gives some indication of the AS internal topology. Comparing MEDs from different autonomous systems would be like comparing apples and oranges. Still, if there is a reason to do so, the Cisco IOS offers the bgp always-compare-med router command.
The MED can be used by an AS to influence the outbound decision of another Autonomous System.
XNET is receiving routing updates about 128.213.0.0/16 from three different sources. They are, San Jose as metric 120, Los Angeles as metric 200, and New York as metric 50. San Francisco will compare the two metric values coming from ANET and will prefer the San Jose router because it is advertising a lower metric, 120. When the bgp always-compare-med command is used on the San Francisco router, it will then compare metrics. It compares metric 120 with metric 50 coming from New York and will prefer New York to reach 128.213.0.0/16. Notice that San Francisco could have influenced its decision by using Local Preference inside XNET to override the metrics coming from outside autonomous systems. Nevertheless, MED is still useful in case XNET prefers to base its BGP decisions on outside factors to simplify router configuration on its end. Customers who connect to the same provider in multiple locations could exchange metrics with their providers to influence the outbound traffic for each router. This leads to better load balancing.
9.6.13 MED configuration example
In Figure , AS 100 receives updates regarding network 180.10.0.0 from RTB, RTC, and RTD. RTC and RTD are in AS 300, and RTB is in AS 400.
Use a route map to configure the MED attribute on a router as follows:
RTB(config)#route-map setmedout permit 10
RTB(config-route-map)#set metric 50
RTB(config)#router bgp 400
RTB(config-router)#neighbor 4.4.4.4 route-map setmedout out
By default, BGP compares only the MED attributes of routes coming from neighbors in the same external AS, such as AS 300 in the example. This means that RTA will compare the MED attribute coming from RTC (120) only to the MED attribute coming from RTD (200). Even though the update coming from RTB has the lowest MED value, RTA will choose RTC as the best path for reaching network 180.10.0.0. To force RTA to include updates for network 180.10.0.0 from RTB in the comparison, use the bgp always-compare-med router configuration command.
RTA will choose RTB as the best next hop for reaching network 180.10.0.0, assuming that all other attributes are the same. The MED attribute can also be set when configuring the redistribution of routes into BGP. For example, on RTB the static route can be injected into BGP with a MED of 50. The preceding configuration causes RTB to send out updates for 180.10.0.0 with a MED attribute of 50.
9.6.14 The Origin attribute
The Origin attribute is a well-known mandatory attribute, type code 1, that indicates the origin of the routing update. BGP allows the following three types of origins:
* IGP – The prefix is internal to the originating AS.
* EGP – The prefix was learned by way of some EGP, such as BGP.
* Incomplete – The prefix was learned by some other means, probably redistribution.
BGP considers the Origin attribute in its decision making process to establish a preference ranking among multiple routes. Specifically, BGP prefers the path with the lowest origin type, where IGP is lower than EGP, and EGP is lower than Incomplete.
9.7.1 The BGP decision process
BGP bases its decision process on the attribute values. When faced with multiple routes to the same destination, BGP chooses the best route for routing traffic toward the destination. The following process summarizes how BGP chooses the best route:
1. If the next hop is inaccessible, the route is ignored. This is why it is important to have an IGP route to the next hop.
2. The BGP router will prefer the path with the largest weight. Weight is a Cisco proprietary parameter.
3. If the weights are the same, the BGP router will prefer the route with the largest local preference.
4. If the routes have the same local preference, the BGP router will prefer the route that was locally originated by this router.
5. If the local preference is the same, the BGP router will prefer the route with the shortest AS_Path.
6. If the AS_Path length is the same, the BGP router will prefer the route with the lowest origin type. This is when IGP is lower than EGP and EGP is lower than Incomplete.
7. If the origin type is the same, the BGP router will prefer the route with the lowest MED.
8. If the routes have the same MED, the BGP router will prefer the route in the following manner. External (EBGP) is better than confederation external, which is better than IBGP. BGP confederations are not covered in this course. For more information, consult Cisco's web site, at http://www.cisco.com/ univercd/home/home.htm.
9. If all the preceding scenarios are identical, the BGP router will prefer the route that can be reached by way of the closest IGP neighbor. That means taking the shortest internal path inside the AS to reach the destination by following the shortest path to the BGP Next Hop.
10. If the internal path is the same, the BGP router ID will be a tiebreaker. The BGP router will prefer the route coming from the BGP router with the lowest router ID. The router ID is usually the highest IP address on the router or the loopback address.
9.8.1 BGP route filtering
Route filtering empowers a BGP speaker to choose what routes to exchange with any of its BGP peers. Route filtering is the cornerstone of policy routing. For example, an AS can identify inbound traffic that it is willing to accept by filtering its outbound advertisements. Conversely, an AS can control what routes its outbound traffic uses by specifying the routes to accept from EBGP neighbors.
Policies that are even more precise can be defined by way of route filters. For example, BGP routes passing through a filter can have their attributes manipulated to affect the best path decision process.
Both the inbound and outbound filtering concepts can be applied between peers and between routing protocols running on a single router. At the peer level, inbound filtering indicates that the BGP speaker is filtering routing updates coming from other peers. The outbound filtering limits the routing updates advertised from this BGP speaker towards other peers.
At the protocol level, inbound filtering limits the routing updates being redistributed into a protocol. Outbound filtering limits the routing updates being injected from this protocol. With respect to BGP, for example, inbound filtering limits the updates being redistributed from other protocols into BGP. Outbound filtering limits the updates being redistributed from BGP into an IGP.
The following sections examine the use of filters to implement routing policy and the use of distribute lists and prefix lists to filter routing updates.
9.8.2 Using filters to implement routing policy
Two distinct steps are involved in manipulating a route or a set of routes as follows:
1. Identify the network number and subnet mask of the route to which the policies are to be applied. For BGP, this information is called the network-layer reachability information (NLRI). Recall that the NLRI consists of a prefix and prefix-length pair. Throughout this section, the NLRI is referred to simply as the prefix.
2. Implement the policies, which can be filtering prefixes out altogether or manipulating the attributes of a prefix to influence the routing decision.
The identification process typically relies on a route map. Prefixes can be selected by their destination network number, the AS from which the prefix originated, the AS_Path, or another specific attribute value. Prefixes are identified using the match statement from the route map. After a route map matches a given prefix, the actions specified by the route map will be executed, and processing will be considered complete. In other words, when a prefix matches, it will not be passed through any remaining clauses in the route map.
What actions can the route map take after it has identified a match? The simplest actions are either to permit the route to pass through or to filter it out by denying it. Actions that are more complex adjust the attributes of a prefix to influence the routing process in some way.
Notice that the route map can match a prefix based on several criteria, such as network number or AS_Path information. Also, notice that once a route matches there are no further comparisons. The order in which the matches are configured in the route map is important. If a route map clause that permits all routes is put at the beginning of the list, it overrides all the other policies configured.
9.8.3 Using distribute-list to filter BGP routes
To restrict the routing information that the router learns or advertises, filter routing updates. Apply route filters to or from a particular neighbor by using the distribute-list command. See Module 8, Route Optimization, for more details about the syntax of this command. RTD in AS2 is originating network 192.68.10.0/24 and sending it to RTF. RTF will pass the update to RTA by way of IBGP, which in turn will propagate it to AS1. By doing so, AS3 could become a transit AS advertising that it is a path to reach network 192.68.10.0/24.
To prevent this situation from happening, configure RTA. Click on RTA in Figure to view the configuration.
The distribute-list keyword, used as part of a BGP neighbor statement, prevents RTA from advertising prefix 192.68.10.0/24 to RTC. The access list is used to identify the prefixes to be filtered and the distribute-list and out keywords apply the filter to outgoing updates.
Notice that access-list 1 concludes with a permit 0.0.0.0 255.255.255.255 statement that is the same as a permit any statement. Remember that, when using access lists for filtering, anything that does not match a permit statement will be denied. Without the permit 0.0.0.0 255.255.255.255 clause, all updates to RTC would be suppressed.
Configuring BGP neighbor statements to include the distribute-list keyword is effective for filtering specific routes, but controlling supernets can be more complicated.
Configuring a distribute list relies on creating an access list. If using a standard access list, there is only limited functionality. RTA connects to multiple subnets in the 172.16.0.0/16 address space. The purpose is to advertise an aggregate address of 172.16.0.0/16, but not the individual subnets themselves. A standard access list would not work because it permits more than is desired. It filters based on the network address only. The following example shows that this access list would permit not only the 172.16.0.0/16 summary, but also all the components of that summary:
access-list 1 permit 172.16.0.0 0.0.255.255
To restrict the update to the 172.16.0.0/16 summary, use an extended access list. It is usually thought of extended access lists as matching both source and destination addresses. In the case of a BGP route filter, an extended access list matches the network address first and then the subnet mask of the prefix. Both network and mask are paired with their own wildcard bitmask, using the following syntax:
router(config)#access-listnumber permit|deny network network-wildcard mask mask-wildcard
To permit the aggregate address in the example, configure an extended access list to match the network address and also the 16-bit mask of the prefix. Using this configuration, RTA would not send a subnet route, such as 172.16.0.0 /17 or 172.16.10.0 /24, in an update to AS1.
RTA(config)#router bgp 3
RTA(config-router)#neighbor 172.16.1.1 remote-as 3
RTA(config-router)#neighbor 172.16.20.1 remote-as 1
RTA(config-router)#neighbor 172.16.20.1 distribute-list 101 out
RTA(config-router)#EXIT
RTA(config)#access-list 101 permit ip 172.16.0.0 0.0.255.255 255.255.0.0 0.0.0.0
If using an extended access list to accomplish this type of filtering seems confusing, that is not unusual. Improved user friendliness was one of the factors that motivated Cisco to include the ip prefix-list command in IOS 12.0. This command is described in the next section.
9.8.4 The ip prefix-list command
Use prefix lists as an alternative to access lists with many BGP route filtering commands. The advantages of using prefix lists rather than access lists include the following:
* Significant performance improvement in loading and route lookup of large lists.
* Support for incremental updates. Filtering by way of extended access lists does not support incremental updates.
* A more user friendly command-line interface.
* Greater flexibility.
Define a prefix list before applying it as a route filter. The Cisco IOS allows a very flexible configuration procedure, where each statement can be assigned its own sequence numbers.
To define a prefix list, use the ip prefix-list command, which has the syntax shown in Figure . Figure describes the parameters that are used with this command.
9.8.5 Example ip prefix-list configuration
Figure presents the commands used to create a simple prefix list and apply it during BGP configuration. The commands define a prefix list called ELMO, which is applied to outgoing External BGP (EBGP) updates to 192.168.1.1 using a neighbor statement.
The real power of the ip prefix-list command is in its optional parameters. The keywords ge and le can be used to specify the range of the prefix length to be matched for prefixes that are more specific than the network/len value. The prefix length range is assumed to be from ge-value to 32 if only the ge attribute is specified. The prefix length range is assumed to be from len to le-value if only the le attribute is specified.
Notice that a specified ge-value and le-value must satisfy the following condition:
len < ge-value <= le-value <= 32
For example, to accept a mask length of up to 24 bits in routes with the prefix 192.0.0.0/8, and to deny more specific routes, use the following commands:
RTA(config)#ip prefix-list GROVER permit 192.0.0.0/8 le 24
RTA(config)#ip prefix-list GROVER deny 192.0.0.0/8 ge 25
These commands test to see if a given prefix begins with 192 in the first octet. After that, they are concerned with only how specific the route is by checking the length of the mask. Therefore, both 192.168.32.0/19 and 192.168.1.0/24 match the permit statement, but 192.168.1.32/27 does not because its mask length is greater than the ge value, 25. Any routes with a mask equal to the ge value will also be denied.
The le and ge keywords can be used together in the same statement, as the following shows:
RTA(config)#ip prefix-list OSCAR permit 10.0.0.0/8 ge 16 le 24
This command permits all prefixes in the 10.0.0.0/8 address space that have a mask length from 16 to 24 bits.
Each prefix list entry is assigned a sequence number, either by default or manually by an administrator. By numbering the prefix list statements, new entries can be inserted at any point in the list. This is important because routers test for prefix list matches from lowest sequence number to highest. When a match occurs, the router does not continue through the rest of the prefix list. For efficiency, put the most common matches near the top of the list. The show ip prefix-list command always includes the sequence numbers in its output, as shown in Figure .
Sequence numbers are automatically generated in increments of five. The first sequence value generated in a prefix list would be five (5), then ten (10), then 15, and so on. If manually specifying a value for an entry and then not specifying values for subsequent entries, the assigned sequence values are incremented in units of five. For example, the first entry in the prefix list has a sequence value specified of three. Then no more sequence values are specified for the other entries, the automatically generated numbers will be 8, 13, 18, and so on. Manually specify prefix list sequence numbers as shown in the following:
RTA(config)#ip prefix-list ELMO seq 12 deny 192.168.1.0/24
Sequence values for prefix list entries can be manually specified in any increments that are wanted. However, if unwisely specifying the sequence values in increments of one (1), additional entries cannot be inserted into the prefix list.
To display information about prefix tables, prefix table entries, the policy associated with a node, or specific information about an entry, use the show ip prefix-list command.
Finally, when using prefix lists, keep the following rules in mind:
* An empty prefix list permits all prefixes.
* An implicit deny is assumed if a given prefix does not match any entries of a prefix list.
* When multiple entries of a prefix list match a given prefix, the sequence number of a prefix list entry identifies the entry with the lowest sequence number. In this case, the entry with the smallest sequence number is considered to be the "real" match.
9.9.1 Issues with redundancy, symmetry, and load balancing
Redundancy, symmetry, and load balancing are crucial needs facing anyone in the process of implementing a high throughput connection to the Internet. ISPs and their large customers require adequate control over how traffic enters and exits their respective autonomous systems.
Redundancy is achieved by providing multiple alternate paths for the traffic. This occurs by having multiple connections to one or more autonomous systems. Symmetry exists if traffic leaves the AS from a certain exit point and returns through the same point. Load balancing, as has been seen, results in the division of traffic optimally over multiple links. Together, these three requirements can be difficult to meet in a BGP environment because any provider between the source and destination of a packet can affect its path.
The general design problem of how best to implement redundancy, symmetry, and load balancing is common to every network. The specific solution, however, depends on the needs and unique configuration of an individual network. The following sections examine the general design issues of redundancy, symmetry, load balancing, as well as configuration models for successful implementation.
9.9.2 Redundancy, symmetry, and load balancing
Although corporations and ISPs prefer uninterrupted connectivity, disruptions still occur for a variety of reasons. Connectivity is not the responsibility of one entity. A connection to the Internet may involve a router, a CSU/DSU, premise wiring, the provider's physical layer, switching equipment, and numerous administrators. Each of these elements has influence over different parts of the connection. At any time, end-to-end connectivity can be jeopardized by human error, software errors, physical errors, or adverse unforeseen conditions, such as bad weather or power outages.
For these reasons, redundancy is generally desirable, but finding the optimal balance between redundancy and symmetry is crucial. Redundancy and symmetry can be conflicting design goals. The more redundant links a network has, the more unpredictable the entrance and exit points for a packet become. A customer may have multiple connections, for example, one to a point of presence (POP) in San Francisco and another to a POP in New York. Therefore, traffic leaving San Francisco might come back through New York. Adding a third connection to a POP in Dallas makes connectivity even more reliable, but it also makes traffic symmetry more challenging. These are the trade-offs that network administrators must consider when implementing routing policies.
Companies might also feel geographic pressure to implement redundancy. Many contemporary companies are national, international, or multinational in nature, and their AS is a logical entity that spans different physical locations. A corporation with an AS that spans several geographical points can take service from a single provider, or from different providers in different regions. In Figure , the San Francisco office of AS1 connects to the San Francisco POP of ISP1, and the New York office connects to the New York POP of ISP2. In this environment, traffic can take a shorter path to reach a destination by traveling by way of the geographically adjacent POP.
Because redundancy refers to the existence of alternate routes to and from a network, additional routing information needs to be kept in the routing tables. To avoid this extra routing overhead, default routing becomes an alternate practical tool that can be used to provide backup routes in case primary connections fail. The next section discusses the different aspects of default routing and how it can be applied to achieve simple routing scenarios.
9.9.3 Default routing in BGP networks
It has been seen that default routes minimize the size of a routing table. They can also provide networks with redundancy in the event of failures and connectivity interruptions. BGP, like almost all IGPs, can distribute a default route. To provide redundancy, default information could be received from multiple BGP sources. In a BGP system, the Local Preference attribute can be manipulated on the various default routes. This is so that one default route is identified as a primary, the highest Local Preference, and others are kept as backups. If the primary fails, a backup route with the next highest preference can take its place.
In Figure , RTA is connected to RTB and is learning about two default routes, one by way of 1.1.1.1 and a second by way of 2.2.2.2. By using the Local Preference attribute, 1.1.1.1 can be given preference and make it the primary default route. RTA will use 2.2.2.2 as a default only after 1.1.1.1 fails.
In Figure , the same behavior can be achieved as long as IBGP is running inside the AS. The Local Preference attribute, which is exchanged between IBGP peers, will determine the primary and backup links.
It is important to control default information in BGP because improper configuration can cause serious Internet routing problems. For example, a misconfigured BGP speaker could end up flooding a default route to all of its neighbors and quickly find itself consumed with default routed traffic from surrounding autonomous systems. To protect against misadvertisements, the Cisco IOS provides a way to target default information at a specific neighbor by using the default-originate option with the neighbor command:
RTC(config)#router bgp 3
RTC(config-router)#neighbor 172.16.20.1 remote-as 1
RTC(config-router)#neighbor 172.16.20.1 default-originate
If RTC is configured as shown in this configuration, it will send default information only to the specified neighbor. If a BGP router is to be configured to advertise a default to all of its peers, use the network command shown as follows:
NOTE:
Both neighbors, 172.16.20.1 and 172.17.1.1, will receive a default route from RTC, if it has one to send.
RTC(config)#router bgp 3
RTC(config-router)#neighbor 172.16.20.1 remote-as 1
RTC(config-router)#neighbor 172.17.1.1 remote-as 2
RTC(config-router)#network 0.0.0.0
Many network administrators choose to filter dynamically learned default routes to avoid situations in which traffic ends up where it is not supposed to be. Without dynamically learned default routes, a router must be statically configured with default information. Statically configured default routes typically provide more control over routing within an AS.
9.9.4 Symmetry
Symmetry is achieved when traffic leaving the AS from one exit point comes back through the same point. Symmetry always exists if an AS maintains a single connection to outside networks. However, the need for redundancy often results in multihoming an AS. If an AS has many different links to the outside world, traffic tends to flow asymmetrically. An asymmetrical traffic flow can result in increased delay and other routing problems. In general, customers and providers would like to see their traffic come back by way of the same point or close to the same point that it left the AS.
To promote symmetry, choose a primary path and configure routing policies that force traffic to flow along this path. A default route with a low administrative distance or a high Local Preference might serve to control the flow of outbound traffic, but inbound traffic can be more complex to manipulate. Through appropriate planning and use of BGP attributes and route filters, an AS can control which paths the outside world finds most desirable.
9.9.5 Load balancing
Load balancing is the capability to divide data traffic over multiple connections. A BGP speaker may learn two identical EBGP paths for a prefix from a neighboring AS. If this happens, it will choose the path with the lowest route ID as the best path. This best path is installed in the IP routing table. If BGP multipath support is enabled and the EBGP paths are learned from the same neighboring AS, the best path may not be chosen. Instead, multiple paths are installed in the IP routing table.
To enable BGP load balancing over equal cost paths, use the maximum-paths command, which has the following syntax:
Router(config-router)#maximum-paths number
BGP supports a maximum of six paths per destination, but only if they are sourced from the same AS. By default, BGP will install only one path to the IP routing table.
Figure illustrates how inbound and outbound traffic behaves. The path for outbound traffic to reach NetA depends on where NetA is learned. Because NetA is received from both San Francisco and New York, outbound traffic toward NetA can go by way of San Francisco or New York.
On the other hand, the path for inbound traffic to reach the local networks, NetB and NetC, depends on how these networks are advertised. If NetC is advertised over the New York link only, then incoming traffic toward NetC will take the New York link. Similarly, if NetB is advertised over the San Francisco link only, traffic toward NetB will take the San Francisco link.
9.9.6 Multihomed connections
Although running BGP when the AS is multihomed to the same ISP is not necessary, it is generally recommended. In the scenario illustrated in Figure , the customer wants to configure only default routes toward the provider. The customer does not want any part of the Internet routing table. While it may seem that a static configuration could work, BGP can offer a more powerful solution.
The customer wants to use one link as the primary traffic conduit and the other as a backup in case the primary link goes down. For outbound traffic, the customer could configure two static default routes with different administrative distances. This would create a primary route and a floating static route to be used as a backup. The default with the lower distance will be the primary.
However, the customer might want to learn the default route, or a few aggregate routes, dynamically from the provider using BGP. In this case, the ISP or the customer could filter the advertisements so that only minimum necessary routes are sent. The Local Preference attribute could then be used to prefer one default route to the other.
Assume that in the example shown in Figure , the default route to New York is preferred over the default to San Francisco. In normal operations, the customer will use the New York link as the primary link and the San Francisco link as a backup.
For outbound traffic, load balancing is not an option. This is because all traffic is sent over the primary path, and the secondary is kept as the backup. The absence of load balancing is offset by the fact that the customer's router requires less memory and processing power.
As for inbound traffic, the customer must carefully control updates to the provider. The customer can advertise its networks to the provider by way of BGP. This way the provider will have two paths to reach destinations within the customer's network. The customer can influence the routing decisions made by ISP by manipulating the metrics advertised to the ISP. The provider will direct its traffic toward the customer based on the metric value. In Figure , the customer is advertising routes with a metric of 50 toward New York and a metric of 100 toward San Francisco. Therefore, traffic toward the customer will take the New York route. Figure shows the commands needed to configure the customer's boundary router.
Notice in this configuration that default routing is handled by two static routes pointing toward the ISP routers. The default route by way of the New York link is set with a lower administrative distance and therefore will be preferred. The SETMETRIC1 and SETMETRIC2 route maps will influence the ISP to send incoming traffic by way of the primary path, New York. Meanwhile, the BLOCK route map prevents any BGP updates from AS 1 from entering AS 3.
What if this customer were multihomed to two different providers? The customer could control inbound traffic the same way, by manipulating advertised metrics using a route map. As for outbound traffic, the customer either can configure static default routes to the two providers or can dynamically learn a default route from both providers. For static default routes, the administrative distance can be used to prefer one default route over the other, while one dynamically learned route can be preferred using the Local Preference attribute.
One good method of pointing defaults to both providers is to accept the same network from both providers and then statically configure a default route towards that network. The customer can manipulate the local preference of this prefix as it is learned from both providers to choose one link over the other. If one default goes away because of a link failure toward one provider, the other default will take its place.
In Figure , the customer is pointing its default routes toward the prefix 192.213.0.0/16, which it is receiving from both providers. The customer's routers apply a route map to incoming updates. The route map sets the Local Preference attribute so that the New York link is preferred. Therefore, the New York link will be the primary link, and the San Francisco link will be the backup.
9.10.1 BGP redistribution overview
When dealing with BGP, route stability is an important issue. There is a close relationship between Internet route stability and the method used to inject routes into BGP. Information can be injected into BGP dynamically or statically. Dynamically injected routes come and go from the BGP routing table, depending on the status of the networks that they identify. Statically injected routes are constantly maintained by the BGP routing tables, regardless of the status of the networks that they identify. Therefore, while a dynamic advertisement will end if the network being advertised no longer exists, a static advertisement will not. Each method has pros and cons, as will be seen in this section.
Dynamically injected information can be further divided into purely dynamic redistribution, in which all the IGP routes are redistributed into BGP using the redistribute command. Dynamically injected information can be further divided into semi-dynamic redistribution, in which only certain IGP routes are to be injected into BGP using the BGP network command. The distinction reflects both the level of user intervention and the level of control in defining the routes to be advertised.
Information is injected dynamically into BGP by enabling all the IGP routes of RIP, OSPF, EIGRP, and so on, to be redistributed into BGP. Dynamic redistribution offers ease of configuration. All internal IGP routes dynamically flow into BGP, regardless of the protocols being used.
The semi-dynamic method of injecting information into BGP is to specify a subset of IGP networks. This is to be advertised by individually listing them for injection into BGP by using the network command. This method is more selective than a completely dynamic method. Controlling which of the IGP-learned routes are advertised by BGP is possible. Unfortunately, a network command is necessary for each route prefix, so when dealing with a large number of prefixes, maintaining semi-dynamic configurations is impractical. In fact, the Cisco IOS limits it to 200 network statements. Ultimately, a semi-dynamic configuration provides greater administrative control but dramatically increases administrative overhead.
BGP assumes that prefixes specified by the network command exist in an IGP domain. This is verified by checking for them in the routing table. If an IGP has not learned about a local route, BGP will not advertise it. Of course, the no synchronization command can be used to disable this verification. However, in doing so, there is a risk that will allow a router to advertise networks that it cannot reach.
9.10.2 Injection of unwanted or faulty information
Injecting routes into BGP by way of the network command may not always be practical or even possible. Injecting routes by way of redistribution can result in polluting other autonomous systems with unwelcome, incorrect, or otherwise undesirable information. Redistributing the entire IGP table into BGP could result in private addresses, or illegal addresses being advertised outside the AS. In some cases, routes with inappropriate prefix lengths could make it upstream to the provider where they are not needed. For example, host routes are generally greeted with disdain by annoyed systems administrators.
Mutual redistribution between IGP and BGP can also result in the propagation of flawed routing information. In this case, a BGP route that was injected from the outside could be sent back into BGP by way of the IGP. This happens as if the route originated within the AS. Figure illustrates the danger of mutual redistribution between protocols.
In Figure , AS100 is the source of NetA and is sending this information by way of BGP to AS200. The border router RTC injects that information into the IGP, and RTB learns about it. RTB is configured to redistribute the IGP information into BGP. NetA will end up being advertised by way of BGP back to the Internet as if it had originated from AS200. This is very misleading to ASs connected to the Internet because NetA now has two sources rather than one source, AS100 and AS200.
To remedy these situations, special filtering should be put on the border routers to specify what particular networks should be injected from the IGP into BGP. For protocols that differentiate between internal and external routes, such as OSPF, configure the IGP to ensure that it will redistribute only internal routes into BGP. In the Cisco implementation, external OSPF routes are automatically blocked from being redistributed into BGP. There is the option of overriding this behavior. Certain protocols may not distinguish between internal and external routes, such as RIP or IGRP. For these types of protocols, special route tagging should be performed to differentiate between external routes and internal routes.
9.10.3 Injecting information statically into BGP
Today, injecting information statically into BGP has proven to be the most effective means to ensure route stability. Of course, this method also has drawbacks. To statically inject information into BGP, the IGP routes, or aggregates, that need to be advertised to other peers are manually defined as static routes. This ensures that these routes will never disappear from the IP routing table and hence will always be advertised. Administrators are often uncomfortable advertising routes to networks that might be down or unreachable. Whether it is appropriate to inject this information statically depends on the particular situation.
For example, if the route is advertised to the Internet from a single point, then advertising a route that is actually down is essentially debatable. Hosts trying to access that destination will fail, regardless of whether the route is advertised. On the other hand, if a route is advertised to the Internet from multiple points, then advertising the route statically at all times might end up creating a black hole for traffic. If problems inside the AS do not allow the border router to reach the network that it is advertising, traffic to that destination will be dropped. This happens even though it could have been reached from some other entry point.
9.10.4 BGP redistribution configuration example
As with IGP routes, all known static routes can be injected into BGP using the redistribute command. A subset of static routes can be injected using the BGP network command. Again, the network command provides greater control, while increasing the administrative burden.
Figure demonstrates how routing information can be injected dynamically into BGP.
Issue the following commands to configure RTB in the Figure to redistribute OSPF learned routes into BGP dynamically:
RTB(config)#router bgp 200
RTB(config-router)#neighbor 10.1.1.2 remote-as 100
RTB(config-router)#neighbor 10.1.1.2 route-map BLOCK-BAD-ADDRESSES out
RTB(config-router)#redistribute ospf 1 match internal metric 50
RTB(config-router)#redistribute static
For insurance, configure a route map that matches any private addresses that are not to be advertised outside the AS. The route map, appropriately called BLOCK-BAD-ADDRESSES, is applied to outbound BGP updates. Also, BGP has been configured to redistribute only internal OSPF routes and assign them a metric of 50. The redistribute static command will dynamically populate BGP with any static routes that RTB happens to be configured with.
Alternatively, configure RTB to inject internal routes semi dynamically, by using the BGP network command as follows:
RTB(config)#router bgp 200
RTB(config-router)#neighbor 10.1.1.2 remote-as 100
RTB(config-router)#neighbor 10.1.1.2 route-map BLOCK-BAD-ADDRESSES out
RTB(config-router)#network 192.168.1.0
RTB(config-router)#network 192.168.2.0
If RTB is configured accordingly, it will not inject all the internal routes into BGP. Only the two networks specified, 192.168.1.0 and 192.168.2.0, will be injected, although all of them could have been configured the same way. In a sense, the BGP network command redistributes the specified IGP route into BGP, allowing for precise control.
9.11.1 Configuring BGP
9.11.2 Configuring IBGP and EBGP sessions
9.11.3 Using the AS_PATH attribute
9.11.4 Using the LOCAL_PREF and MED attributes
9.12.1 BGP challenge lab
Summary
BGP defines the basis of routing architectures in the Internet. The segregation of networks into autonomous systems has logically defined the administrative and political borders between organizations. Interior Gateway Protocols can now run independently of each other, but still interconnect by way of BGP to provide global routing.
In this module, the details of the practical implementation for BGP as part of the overall design problem in building reliable Internet connectivity was covered. This module examined specific attributes of BGP and how the attributes are applied individually and together address this design problem. The terminology, attributes, and details of this module are specific to BGP. However, the general concepts and problems raised are pertinent to routing architecture design, regardless of what specific protocols are being utilized.
by sdominguez.com
* prepara tu examen ccna.
* prepara tu examen ccnp.
* prepara tu certificacion ccnp.
* prepara tu certificacion ccna.
* prepara tu examenes ccna.
* prepara tu examenes ccnp.
* prepara tu certificaciones ccnp.
* prepara tu certificacion ccna.
No hay comentarios:
Publicar un comentario