Building a Network Using Internal BGP Though BGP is an exterior routing protocol, it comes in two flavors: internal BGP (iBGP) and external BGP (eBGP). The difference depends on the function of the routing protocol. The router will determine whether the peer BGP router is going to be an eBGP peer or an iBGP peer by checking the autonomous system number in the open message that was sent. eBGP complies with the common perception of an external routing protocol; it sends routing information between different autonomous systems. Therefore, the border router between different autonomous systems is the eBGP router. iBGP is used within an autonomous system. It conveys information to all BGP routers within the domain and ensures that they have a consistent understanding of the networks available. iBGP is used by an ISP or a large organization when it is necessary to convey external BGP information about other autonomous systems across a transit autonomous system ; that is, iBGP is used between eBGP speakers in the same autonomous system. In Figure 16-1, eBGP is used between AS 50 and AS 100, but in order to connect to AS 200, the BGP routing information must traverse AS 100. Once the routing protocol has traveled through AS 100, it returns to its more natural form of eBGP to connect to AS 200. Figure 16-1. iBGP and eBGP  Understanding iBGP Network Requirements To design and implement BGP correctly, there are a few characteristics about iBGP that are important to understand. The first of these rules, discussed in the next section, states that iBGP routers do not need to be directly connected, whereas eBGP routers must be physically connected (unless they are running multihop eBGP). You then learn about how synchronization and fully meshed networks factor into BGP network design. Physical versus Logical Connections Unlike Internal Gateway Protocols (IGPs), such as RIP, OSPF, and IPv6, that carry information about the autonomous system, the iBGP routers are not required to be physical neighbors on the same medium. In fact, they often sit at the edges of the autonomous system. Another routing protocol, an IGP such as OSPF, routes the BGP packets between the iBGP routers. In Figure 16-1, you see the iBGP routers are not directly connected, but that they have a TCP connection using TCP port number 179. This means that the internal protocol has topology independence. Through a logical, not a physical, connection, TCP routes the BGP packets across the autonomous system by routers with routing tables maintained by OSPF. For BGP to communicate the routing information, it redistributes its routing information into the IGP. The integration of these different routing protocols can be challenging. Now that you understand the topological requirements of iBGP, you can follow the criteria by which iBGP sends updates over this topology. An iBGP router propagates a route to a BGP neighbor under the following conditions: These criteria are important to understand as they necessitate some design restrictions. Essentially , if the route was learned via an update from a BGP peer within the same autonomous system, a BGP router can propagate this route only to an eBGP peer. Because iBGP does not forward updates it learned from an iBGP peer, iBGP peers need to be connected to one another (fully meshed) to have a complete knowledge of the network. However, a fully meshed network makes it difficult to scale iBGP because every router in the autonomous system has to build a BGP session with every other router in the autonomous system. Synchronization A simple rule states that before iBGP can propagate a route into another autonomous system by handing it over to eBGP, the route must be known throughout the autonomous system. That is to say, the IGP or internal routing protocol must be synchronized with BGP. This synchronization is to ensure that if traffic is sent into the autonomous system, the interior routing protocol can direct it to its destination. The synchronization rule is on by default and should be turned off only if all routers in the autonomous system are running BGP. For example, if you have a transit autonomous system with only the edge routers running iBGP, you are relying on the IGP to carry the traffic between the iBGP routers. It is therefore important for the IGP to have the information in its routing table to fulfill this task. This example is illustrated in Figure 16-2. Figure 16-2. Synchronization Rule and BGP  As you can see, AS 400 and AS 800 are using AS 200 as a transit autonomous system. In accordance with the synchronization rule, the router sending updates into AS 800 will not propagate 56.0.0.0 advertised by AS 400 unless the IGP, in this case OSPF, has full knowledge of how to get to 56.0.0.0. Otherwise , AS 800 might send traffic to 56.0.0.0, which would get lost in AS 200, because with an incomplete IP routing table, it would not be able to direct the traffic to the appropriate destination. The synchronization rule is beneficial for the following reasons: -
It prevents traffic from being forwarded to unreachable destinations. -
It reduces unnecessary traffic. -
It ensures consistency within the autonomous system. On some occasions, it is useful to turn off synchronization. As with any default, it is unwise to turn off this option without a detailed understanding of the network. The occasions when it might be useful to turn off synchronization are as follows : -
If all the routers in the autonomous system are running BGP. -
If all the routers inside the autonomous system are meshed. -
When the autonomous system is not a transit autonomous system. To turn off synchronization, you can use the following command in config-router mode: Router(config-router)# no synchronization This allows routers to advertise routes into BGP before the IGP has a copy of the route in its routing table. A Fully Meshed Network The BGP split horizon rule states that though the routers do not need to be directly connected, they do need to be fully meshed. This configuration is required to ensure full connectivity. To avoid routing loops , the protocol must follow the split horizon rule that no updates learned from internal peers can be sent to other internal peers. This means that the prefixes it receives are not redistributed to other iBGP systems. The prefixes are only propagated to a BGP system in another autonomous system, otherwise known as a peer eBGP system . Network Resources Required in Fully Meshed Networks BGP maintains up-to-date and accurate routing information by sending incremental updates across a TCP connection. The TCP connection is an excellent way of ensuring the accuracy of the information, but it is costly in network resources. The greater the number of connections, the greater the number of required resources. A simple equation demonstrates the problem, one that is also seen in the consideration of designing fully meshed Frame Relay networks. The equation for determining the number of sessions required is as follows: n ( n 1) / 2 In plain English, it is the number of routers minus 1, multiplied by the number of routers, and then divided by 2. Thus, 10 routers would mean 10 (10 1) / 2 = 10 * 9 / 2 = 45 sessions. This equation works well in environments that require a few connections, such as a company with multiple connections into the Internet. However, if the network is an ISP that is using BGP throughout its network, some careful design should be put in place. Administrative Overhead in Fully Meshed Networks There is also administrative overhead in maintaining a fully meshed network of peers. For example, each time a peer is added, the number of iBGP peering configuration statements grows as well. To be fair to TCP, it is not simply the maintenance of the connection that eats up resources, but the amount of updates that traverse those links. If every router is connected to every other router, a great deal of the information that is being sent is duplicated . Figure 16-3 illustrates the redundancy. Figure 16-3. iBGP and a Fully Meshed Network  Designing and Configuring a Scalable iBGP Network The problem of scalability presented by a fully meshed iBGP network can be solved by design. Configuration solutions allow you to overcome the rule that all iBGP peers must be fully meshed. These new commands allow you to develop a hub-and-spoke network to streamline the TCP connections. This is a good thing, but it does require some additional design and configuration. The solution is the implementation of route reflectors and the network design that they support. The following section covers the use of route reflectors that reflect the updates from one connected client to other clients connected to the route reflector. The other topics discussed the next sections include route refresh, which resets the TCP connections and thus affects the change in configuration, and the use of peer groups. To streamline not only the configuration, but also the BGP traffic necessary to maintain full and accurate tables, peer groups are formed to allow one update to be sent to an identified group . Route Reflectors A route reflector is a router configured to forward routing updates to neighbors or peers within the same autonomous system. These iBGP peers need to be identified as clients in the configuration. When a client sends an update to the route reflector, it is forwarded or reflected to the other clients. Essentially, the route reflector defies the split horizon rule that states that the iBGP router will not propagate a route that was learned from a peer within the same autonomous system (an iBGP peer). A client is a router that receives updates from a route reflector that a route reflector has forwarded from another client. It requires no configuration and has no idea that it is anything other than a peer. The route reflector and the client require a full peer relationship because the route reflector forwards updates from other clients, but peering between the clients is not needed. In all probability, a route reflector is connected to peers for which it is not forwarding routes. From the route reflector's view, these neighbors or peers are nonclients . Nonclients must be fully meshed with the route reflector and each other. When a router has been configured as a route reflector, it forwards paths learned from iBGP peers only to route reflector clients and to iBGP/eBGP neighbors. This means that a logical hub-and-spoke design can be implemented within an autonomous system between iBGP peers, thus reducing the number of peering sessions required. Both a route reflector and its clients form a unit that shares information. This unit is called a cluster . The autonomous system can be divided into clusters, and the router reflectors identified and configured. There must be at least one route reflector per cluster. If a route reflector connects to other route reflectors, the route reflectors should be fully meshed. This is to ensure that the iBGP routing tables are complete. When the route reflector forwards an update, the Originator- ID attribute is set. This is the BGP router ID of the router that originated the path . If this router receives back the update, it will see its own ID and will ignore the packet. This prevents the possibility of routing loops. If there are multiple route reflectors in the cluster to provide redundancy, the originating router is identified by the Cluster-ID attribute. This serves the same purpose as the Originator-ID in preventing routing loops. The route reflector concept means that there is more overhead on the route reflector, and if it is configured incorrectly, it can cause serious routing loops. The design to avoid a fully meshed iBGP network can become quite complicated, but multiple route reflectors afford redundancy, which is always reassuring. Multiple levels of route reflectors can even be configured, creating a hierarchical design. Nonroute reflector routers are not affected by the change in design and routing update propagation. Indeed, they are blissfully unaware of any changes because they still receive the updates that they need. The updates are also unchanged because no changes are made to the attribute values. This makes migration to a network design incorporating route reflectors very straightforward. An important design suggestion is for the iBGP route reflectors to be fully meshed to ensure the correct propagation of updates. As mentioned earlier, it is possible to create a hierarchical design where route reflectors are clients of other route reflectors. This is a complex design and requires great care, because as soon as the route reflector is configured and split horizon disabled, there is no protection against a routing loop. A fully meshed route reflector design is therefore advised, as illustrated in Figure 16-4. Figure 16-4. Design of iBGP Network Using Route Reflectors  The benefits of route reflectors include the following: -
The capability to scale the network -
A strong hierarchical design -
A reduction of traffic on the network -
A reduction in the memory and CPU needed to maintain TCP sessions on the client iBGP peers -
Faster convergence and a simpler network because two routing protocols are implemented: -
- iBGP for external routing information traversing the autonomous system -
- IGP for routes internal to the autonomous system The solution provided by route reflectors is used in large iBGP environments such as ISP networks, where a fully meshed iBGP network could result in a large number of TCP sessions. Figure 16-5 illustrates the relationship between route reflectors, clients, and other clusters. Figure 16-5. Clusters and Route Reflector Meshing  The next sections examine how route reflectors operate, how the clients of route reflectors operate , and introduces the concept of a cluster in BGP. How Route Reflectors Operate The previous section summarized of some of the characteristics of route reflectors. These characteristics determine how route reflectors operate. A route reflector is simply a mirror that reflects updates from clients to other clients without requiring a fully meshed network. The following list shows what happens when a route reflector receives an update: -
The client forwards an update to its peer, in this case, the route reflector. -
An update from a client is received by the route reflector, and the update is forwarded to other clients as well as nonclients (both iBGP and eBGP peers). The originator ID is excluded from the update. -
If multiple paths are received by the route reflector, the best path is chosen by the route reflector. -
The only router that does have the update forwarded to it is the originator of the route. -
A nonclient forwards an update to its peer, which happens to be a route reflector. -
The route reflector receives an update from a nonclient, and the update is forwarded only to clients. -
An eBGP peer sends an update to the route reflector. -
The route reflector reflects the update to both clients and nonclients. Configuring Route Reflectors The command for configuring a route reflector is very straightforward. It is explained in the following syntax: Router(config-router)# neighbor ip-address route-reflector-client To remove a router as a client, issue the following command: Router(config-router)# no neighbor ip-address route-reflector-client Remember that if all clients are removed, the route reflector loses its status and becomes a standard iBGP router. If this happens, the iBGP routers need to be fully meshed. Table 16-2 breaks down the syntax of the command to configure a route reflector and identify the clients. Table 16-2. Explanation of the Route Reflector Configuration Command | Syntax | Description | | neighbor | Identifies that the rest of the command is directed at a BGP peer. | | ip-address | The IP address of the neighboring router being identified as a client. | | route-reflector-client | Points to the client of the route reflector. Note that the client is not configured and is unaware of its change of status. It does nothing but continues to send updates to the route reflector, which forwards them unchanged to other clients. | Example 16-1 illustrates the concepts explained in this section. For simplicity, the connection to the eBGP router in AS 400 has not been included in the example. Use this example in conjunction with the network displayed in Figure 16-6. Figure 16-6. Network Topology Configured in Example 16-1  Example 16-1. Configuration of a Route Reflector NewYork# NewYork(config)# router bgp 100 ! Create a connection to Router A, a client NewYork(config-router)# neighbor 167.55.22.2 remote-as 100 ! make Router A as seen in Figure 16-6 a route reflector client New York(config-router)# neighbor 167.55.22.2 route-reflector-client ! connection to Router B NewYork(config-router)# neighbor 167.55.11.1 remote-as 100 NewYork(config-router)# neighbor 167.55.11.1 route-reflector-client ! connection to San Francisco New York(config-router)# neighbor 167.55.77.7 remote-as 100 ! connection to Chicago NewYork(config-router)# neighbor 167.55.44.4 remote-as 100 NewYork(config-router)# neighbor 33.33.33.33 remote-as 300 RouterB# RouterB(config)# router bgp 100 ! connection to New York RouterB(config-router)# neighbor 167.55.33.3 remote-as 100 Chicago# Chicago(config)# router bgp 100 ! connection to Router E Chicago(config-router)# neighbor 167.55.66.6 remote-as 100 Chicago(config-router)# neighbor 167.55.66.6 route-reflector-client ! connection to Router F Chicago(config-router)# neighbor 167.55.55.5 remote-as 100 Chicago(config-router)# neighbor 167.55.55.5 route-reflector-client ! connection to San Francisco Chicago(config-router)# neighbor 167.55.77.7 remote-as 100 ! connection to New York Chicago(config-router)# neighbor 167.55.33.3 remote-as 100 Route Refresh After any BGP configuration, it is necessary to reset the TCP session so that the changes can take effect. This is because the BGP process stores only prefixes that apply to the stated policy. If the policy changes, which means after any configuration, the peer session is torn down and rebuilt with the new characteristics. It is now possible to issue a soft process reboot, which still destroys and rebuilds the peering sessions, but without a hard reboot of the BGP process. The command to reboot all sessions is as follows: Router# clear ip bgp * The command to tell the peer to resend a full BGP update to a particular neighbor follows: Router# clear ip bgp neighbor-address in The command to tell the process to send a full BGP update to the peer follows: Router# clear ip bgp neighbor-address out The clear ip bgp command is described in detail in Chapter 15. It is also possible to configure the BGP process to store the prefixes before the policy application. This obviously requires greater memory, but it allows new configurations to be implemented without tearing down peering sessions. The configuration is applied on a per-neighbor basis and only needs to be applied to the inbound updates. The syntax is as follows: Router(config-router)# neighbor neighbor-address soft-configuration inbound After a configuration change has been made, issue the following command from the executive level: Router# clear ip bgp neighbor-address soft [ in out ] Peer Groups Without peer groups, every iBGP peerbeing fully meshedreceives the same update. This means every iBGP router performs the same calculations, wasting CPU and restricting the ability of iBGP to scale. Once peer groups are configured, every router within the peer group has the same outbound policy, while allowing different inbound policies to be configured on each system. This means that one update can be generated for the group, resulting in the following benefits: -
The administrative overhead is reduced, because the configuration is simpler, reducing the possibility of errors. -
Less CPU is required, speeding up the network responsiveness. When a network converges quickly, it becomes more stable and reliable. To define a peer group, use the following: Router(config-router)# neighbor peer-group-name peer-group Example 16-2 shows how the peer group IBGP-peergp is created and applied to iBGP neighbors. Example 16-2. Configuration of a Peer Group to iBGP Neighbors Router(config)# router bgp 100 Router(config-router)# neighbor IBGP-peergp peer-group Router(config-router)# neighbor IBGP-peergp remote-as 100 Router(config-router)# neighbor IBGP-peergp route-map setpolicy out Router(config-router)# neighbor 6.6.6.6 peer-group IBGP-peergp Router(config-router)# neighbor 6.7.7.7 peer-group IBGP-peergp Router(config-router)# neighbor 6.8.8.8 peer-group IBGP-peergp Verifying the iBGP Configuration It is also important to verify that a configuration is working. Example 16-3 demonstrates the command that verifies the configuration of router 167.55.44.3 and its neighbors and that inbound soft reconfiguration was configured and works. Example 16-3. Example of the show ip bgp neighbors Command New York# show ip bgp neighbors 167.55.44.4 BGP neighbor is 167.55.44.4, remote AS 100, Internal link Index 1, Offset 0, Mask 0x2 Inbound soft reconfiguration allowed BGP version 4, remote router ID 167.55.44.4 BGP state = Established, table version = 27, up for 00:06:12 Last read 00:00:12, hold time is 180, keepalive interval is 60 seconds Minimum time between advertisement runs is 30 seconds Received 19 messages, 0 notifications, 0 in queue Sent 17 messages, 0 notifications, 0 in queue Inbound path policy configured Route map for incoming advertisements is testing Connections established 2; dropped 1 Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Local host: 167.55.44.3, Local port: 11002 Foreign host: 167.55.44.4, Foreign port: 179 Enqueued packets for retransmit: 0, input: 0, saved: 0 Event Timers (current time is 0x530C294): Timer Starts Wakeups Next Retrans 12 0 0x0 TimeWait 0 0 0x0 AckHold 12 10 0x0 SendWnd 0 0 0x0 KeepAlive 0 0 0x0 GiveUp 0 0 0x0 PmtuAger 0 0 0x0 iss: 133981889 snduna: 133982166 sndnxt: 133982166 sndwnd: 16108 irs: 3317025518 rcvnxt: 3317025810 rcvwnd: 16093 delrcvwnd: 291 SRTT: 441 ms, RTTO: 2784 ms, RTV: 951 ms, KRTT: 0 ms minRTT: 0 ms, maxRTT: 300 ms, ACK hold: 300 ms Flags: higher precedence, nagle Datagrams (max data segment is 1460 bytes): Rcvd: 15 (out of order: 0), with data: 12, total data bytes: 291 Sent: 23 (retransmit: 0), with data: 11, total data bytes: 276 Table 16-3 describes the fields shown in Example 16-3. Table 16-3. Explanation of the show ip bgp neighbors Command | Field | Descriptions | | BGP neighbor | IP address and autonomous system of the BGP neighbor. If the autonomous system numbers are the same, then iBGP is running between the neighbors; otherwise, eBGP is in use. | | BGP version | BGP version being used to communicate with the remote router. The neighbor's router ID (an IP address) is also specified. | | BGP state | State of this BGP connection. (Refer to Chapter 15 for an explanation of the states.) | | table version | Indication that the neighbor has been updated with this version of the primary BGP routing table. | | up for | Amount of time that the underlying TCP connection has been in existence. | | Last read | Time that the BGP process last read a message from this neighbor. | | Hold time | Maximum amount of time that can elapse between messages from the peer or neighbor. | | keepalive interval | Time period between sending keepalive packets, which maintain the TCP connection. | | Received | Number of total BGP messages received from this peer, including keepalives . | | Sent | Total number of BGP messages that have been sent to this peer, including keepalives. | | notifications | Number of error messages that the router has sent to this peer. | | Connections established | Number of times that the router has established a TCP connection for BGP between the two peers. | | Dropped | Number of times that a valid TCP connection has failed or been taken down. | | Connection state | State of BGP peer. | | unread input bytes | Number of bytes of packets still to be processed . | | Local host, Local port | Peering address of local router, plus its TCP port. | | Foreign host, Foreign port | Neighbor's peering address and its TCP port. | | Event Timers | Table that displays the number of starts and wakeups for each timer. | | Iss | Initial send sequence number. | | Snduna | Last send sequence number that the local host sent but for which an acknowledgment is outstanding. | | Sndnxt | Sequence number that the local host will send next. | | Sndwnd | TCP window size of the remote host. | | Irs | Initial receive sequence number. | | Rcvnxt | Last receive sequence number that the local host has acknowledged . | | Rcvwnd | Local host's TCP window size. | | delrcvwnd | Delayed receive window. Data that the local host has read from the connection but that has not yet been subtracted from the receive window that the host has advertised to the remote host. The value in this field gradually increases until it is larger than a full- sized packet, at which point it is applied to the rcvwnd field. | | SRTT | A calculated smooth round-trip time. | | RTTO | Round-trip time. | | RTV | Variance of the round-trip time. | | KRTT | New round-trip time (using the Karn algorithm). This field separately tracks the round-trip time of packets that have been retransmitted. | | MinRTT | Smallest recorded round-trip time (hard-wire value used for calculation). | | MaxRTT | Largest recorded round-trip time. | | ACK hold | Time that the local host will delay an acknowledgment to piggyback data on it. | | Flags | IP precedence of the BGP packets. | | Datagrams | Header for the next two fields and the size of the Maximum Transmission Unit (MTU) | | Rcvd | Number of update packets received from neighbor with data. | | With Data Total Data Bytes | Total bytes of data. | | Sent | Number of update packets sent. | | With Data | Number of update packets with data sent. | | Total data bytes | Total data bytes. | NOTE When implementing clusters and route reflectors, select the route reflector carefully in accordance with the physical topology of the network. Keep the design simple, placing one route reflector in a cluster. When the logical cluster design is in place, configure one cluster at a time and one route reflector at a time. After the route reflector in the cluster is configured, remove the BGP configuration that has the BGP sessions between the clients.
Controlling BGP Traffic BGP updates can be controlled. It is often advantageous to limit the way that the BGP routing updates are propagated, for the same reasons that any routing protocol is best limited to only those updates that are required. This not only streamlines the traffic flow on the network, but also simplifies the network and thus its maintenance. Designing how the routing information should be forwarded through the network forms a basic level of security and can reduce the possibility of routing loops. There are three main ways to apply policy-based routing in BGP: -
Making decisions based on the autonomous system path, the community, or the prefix -
Rejecting or accepting selected routes -
Setting attributes to influence the path selection Rejecting or accepting selected routes requires some form of filtering through access lists. Filtering is used not only in policy-based routing, but also essentially as traffic control. There are three main flavors of filtering on a Cisco router: -
Autonomous system path access list Used for filtering autonomous systems. An access list is used in BGP to filter updates sent from a peer based on the autonomous system path. In addition, other technologies use access lists for standard filtering. -
Prefix list Used for filtering prefixes, particularly in redistribution. From Cisco IOS software version 11.2, ISPs were given prefix lists, which are a more efficient form of filtering. Prefix lists filter based on the prefix of the address. This option was made a part of IOS software version 12.0. -
Distribute lists Used to filter routing updates. Although they are often used in redistribution, they are not specific to redistribution; they can be applied to inbound and outbound updates to or from any peer. Both prefix lists and distribute lists filter on network numbers, not autonomous system paths, for which autonomous system path access lists are used. -
Route maps Used to define routing policy. A route map is a sophisticated access list that defines criteria upon which a router acts when a match is found for the stated criteria. It is used in BGP for setting the attributes that determine the basis for selecting the best path to a destination. Prefix lists are dealt with in more depth in the following sections. Route maps are dealt with in detail in Chapter 18, "Controlling Network Traffic with Route Maps and Policy-Based Routing," and distribute lists are explained in Chapter 17, "Implementing Redistribution and Controlling Routing Updates." Autonomous system path access lists are outside the scope of this book. How Prefix Lists Work Prefix lists were introduced in BGP because they are an efficient form of filtering. Because they search on the prefix of the address as defined by the administrator, the lookup is very fast. This is particularly important in the potentially huge routing tables that can be generated in BGP networks. Another great advantage to prefix lists is the capability to edit them, particularly if they become large. Although it is possible to dynamically edit access lists, it is a little complicated. You must either port the access list to an application that allows editing or use named access lists. Prefix lists are easier to create and use. This is true not only with the editing features, but also with the improved interface, which affords greater flexibility. Before applying a prefix list to a process or an interface, you must first define the criteria for the prefix list. Each line in the prefix list is associated with a sequence number, similar to the number identifying a line of code in a computer program. If you choose not to enter the sequence number manually with the prefix-list command, the sequence numbers are automatically generated in increments of five. The sequence numbers that have not been used, for example, between 1 and 4, allow for additional lines to be added in subsequent edits of the prefix list. You can edit the prefix list by referencing the line or sequence number. This ability is not available in access lists, which require you to rewrite the entire list, unless you have the forethought to copy and paste the configuration file into a word processor. Prefix lists work by matching the prefixes in the list to the prefixes of routes that are under scrutiny. The manner in which this is done is similar to that of access lists. When there is a match, the route is used or discarded. More specifically , whether a prefix is permitted or denied is based upon the following rules: -
If a route is permitted, the route is used. -
If a route is denied, the route is not used. -
At the bottom of every prefix list is an implicit deny any . Thus, if a given prefix does not match any entries of a prefix list, it is denied. -
When multiple entries of a prefix list match a given prefix, the entry with the smallest sequence number (the first match in the list) is used. -
The router begins the search at the top of the prefix list, with the sequence number 1. When a match is made, the search stops. Processing time will be reduced if the most common matches or denies are placed near the top of the list. This will prevent having to process criteria that are seldom met every time a route is examined. -
Sequence numbers are automatically generated by default. To configure the sequence numbers manually, use the seq seq-value argument of the ip prefix-list command. -
A sequence number does not need to be specified when removing a configuration entry. How to Configure a BGP Prefix List Configuring a prefix list is straightforward if attention is given to the processing rules. The following command creates an entry in a prefix list and assigns a sequence number to the entry: Router(config-router)# ip prefix-list prefix-list-name [ seq seq-value ] { deny permit } network/len [ ge ge-value ] [ le le-value ] Table 16-4 explains the parameters shown in the preceding syntax. Table 16-4. Explanation of the ip prefix-list Command | Parameter | Description | | prefix-list-name | Name of the prefix list | | [ seq seq-value ] | The sequence number to be assigned to the criteria being defined | | { deny permit } | Whether the action is to deny or permit the route based on the outcome of the criteria | | network/len | The length of the prefix length to be matched | [ ge ge-value ] [ le le-value ] | The optional keywords ge and le can be used to specify the range of the prefix length to be matched. An exact match is assumed when neither ge nor le is specified | To configure a router to use a prefix list as a filter in distributing routes, use the following command: Router(config-router)# neighbor { ip address peer-group } prefix-list prefix-list-name { in out } An example of a simple prefix list follows: Router(config)# ip prefix-list tryout permit 44.0.0.0/8 Router(config)# ip prefix-list tryout permit 130.0.0.0/8 The prefix list "tryout" will allow the networks 44.0.0.0 and the supernet 130.0.0.0 to be further processed by BGP. Sometimes it is necessary to create a criteria range as opposed to an absolute. For example, you could change "all 2-year-old children are allowed into the playground" to "children between the ages of 2 and 4 are allowed into the playground." This grants greater flexibility to the searches. The way to do this in a prefix list is to use the ge and le parameters. These optional keywords allow a range of the prefix length to be specified, as opposed to the network/len , which is the absolute. Therefore, 10.2.3.0/24 is an example of the network/len, which states the prefix to be matched and the length of the prefix. The equations are confusing until you sit and work them out. The following are some key points: Simply put, the ge-value is the barrier for the lower limit, in that the number must be greater than the value stated in for the ge-value . Likewise, the le-value is the barrier for the upper limit, in that the number must be less than that stated in the le-value . So, children entering the playground must be older than 2 ( ge-value of 2) and younger than 4 ( le-value of 4). Therefore, the formula requires the following condition: len < ge-value < or = le-value < or = 32 For example, to permit all prefixes between /8 and /24, you would use the following: Router(config)# ip prefix-list tryone permit 0.0.0.0/0 ge 8 le 24 NOTE An exact match is assumed when neither ge nor le is specified. The range is assumed to be from ge-value to 32 if only the ge attribute is specified, and from len to le-value if only the le attribute is specified.
Verifying the Prefix List Configuration As always, it is important to check the configuration, especially if it involves the filtering of routes or routing updates. Table 16-5 lists the various show commands available for prefix lists. To display information about a prefix list or prefix list entries, use the show ip prefix-list exec command: Router# show ip prefix-list [ detailsummary ] name [ network/len ] [ seq seq-num ] [ longer ] [ first-match ] Table 16-5. Displaying Prefix List Command Options | Command | Description | | show ip prefix-list [ detail summary ] | Displays information about all prefix lists, including the hit count, which is the number of times that a match has been found for the criteria in the prefix list. This is very important in troubleshooting for capacity planning and security. | | show ip prefix-list [ detail summary ] name | Displays a table showing the entries in a prefix list identified by name. | | show ip prefix-list name [ network/len ] | Displays the filtering associated with the node based on the absolute of the defined prefix. | | show ip prefix-list name [ seq seq-num ] | Displays the prefix list entry with a given sequence number. | | show ip prefix-list name [ network/len ] longer | Displays all entries of a prefix list that are more specific than the given network and length. | | show ip prefix-list name [ network/len ] first-match | Displays the entry of a prefix list that matches the given prefix (network and length of prefix). | The show commands always include the sequence numbers in their output. Example 16-4 shows the output of the show ip prefix-list command with details about the prefix list "tryout." Example 16-4. A Sample Output of the show ip prefix-list Command Router# show ip prefix-list detail tryout Ip prefix-list tryout: Description: tryout-list count: 1, range entries: 0, sequences: 5 - 10, refcount: 3 seq 5 permit 44.0.0.0/8 (hit count: 0, refcount: 1) seq 10 permit 130.0.0.0/8 (hit count: 0, refcount: 1) As you have seen, filtering routes is crucial in the design of BGP in order to maintain manageable routing tables and to conserve network resources. Up to this point, the discussion has centered on the use of BGP within and between autonomous systems. When connecting to the Internet, you need to consider slightly different design issues, as discussed in the next section. Connecting to the Internet with BGP As an exterior routing protocol, BGP is used to connect to the Internet and to route traffic within the Internet. You need to be aware of some design considerations when connecting to such an enormous resource. Just like driving a car during rush hour , you need different skills depending on whether you are joining a freeway or driving through a small town. When connecting to the Internet, your network is joining a major freeway that connects large cities, so you must ensure that the amount of traffic and information does not overwhelm your network. The following sections deal with two important design considerations: the need for redundant links into the Internet, called multihoming, and the need to decide how much information to receive from the Internet. Redundant Connections to the InternetMultihoming An enormous amount of traffic leaves an organization in search of Internet resources. This traffic includes not only e-mail and other means of communication, but also requests for information from the Internet. Use of the Internet continues to expand as both an individual tool and a major mechanism of finance and commerce. It becomes increasingly necessary for the network administrator to provide constant access to the Internet with load balancing and redundancy with multihoming. To have more than one connection to the Internet is to be multihomed . The reason for duplicating the connection is clear: The need for Internet access nowadays is too great for the responsibility to fall onto one link. Multiple links not only provide redundancy, but also allow for load balancing and thus present an improvement in performance. Multihoming might be several connections to the same ISP, or it might include another layer of redundancy by making the second connection to another ISP. The following are some concerns about connecting to more than one ISP: -
Each provider might not be propagating the same routes into or from the Internet. If the providers are sending subsets of the required routes, there could be a major problem with connectivity if the link to one of the providers fails. -
If you are connected to two different providers, your autonomous system could become a transit autonomous system between the ISPs. This could happen if a router in the autonomous system of one provider sees a path to a destination via the other provider's autonomous system, and your autonomous system gives the best route to the autonomous system of the other provider. Configuration at the ISP level is the solution to these concerns and is dealt with when setting up the service. Therefore, it is important that you raise the need for multihoming during negotiations with the ISP so that the ISP is aware of the need for additional configuration. Receiving Routing Information from the Internet When connecting to something as vast as the Internet, some planning and forethought is necessary. In particular, it is essential to decide what updates are to be sent to the outside world and how routers within the autonomous system are to know about the outside world and all that it offers. There are three main approaches to the selection of routes from the Internet: -
Accept only default routes from all providers -
Accept partial routes in addition to default routes from all providers -
Accept full routing updates from all providers The decision process is clear: It is a balance of network resources against information. The greater the amount of resources, the more routes can be accepted from the providers. Table 16-6 summarizes the different approaches to obtaining routing information from the Internet. Table 16-6. Receiving Routing Updates from Multiple ISPs | Routes Accepted from the Internet | Memory | CPU | IGP Chooses Best Metric to Default Network? | BGP Selects Best Path to External Network? | Can Exit Path Be Tuned via BGP Attributes? | AS Sends All Its Routes to ISPs? | ISP Chooses Entry Path to AS? | | Default routes only from all ISPs | Low | Low | Yes | Go to nearest gateway that is advertising the route | No | Yes | Yes | | Select routes and default routes from ISPs | Medium | Medium | Yes | Yes; normally the AS_Path is the attribute that selects the exit path to the Internet | Yes | Yes | Yes | | Full routing tables from ISPs | High | High | Yes | Yes; normally the AS_Path is the attribute that selects the exit path to the Internet | Yes | Yes | Yes | Figure 16-7 illustrates the various options available in exchanging routing information with the Internet. Figure 16-7. Exchanging Routing Information with the Internet  NOTE The second solution, accepting partial routes from the ISP, requires the updates sent into the autonomous system to be filtered, either by your autonomous system or by the ISP. If the responsibility falls to your organization, you will need to study the use of route maps and regular expressions. This is a complex subject, which is explained in detail on the Cisco web site. As of press time for this book, the best information on this subject could be found at http://www.cisco.com/warp/public/459/27.html. Or, go to Cisco.com and search for "sample configurations for BGP."
Determining the BGP Path by Tuning the Attributes Now that you understand the network requirements for designing and configuring a BGP network, as well as methods for controlling BGP traffic through the network, you will learn how to configure BGP to take a path to a destination based on different criteria. The attributes discussed in this section are local preference and weight, with the latter being a Cisco-proprietary solution. Using the Local Preference and Weight Attributes The weight attribute selects the exit path out of the router when there are multiple paths to the same destination. The higher the weight value, the better the path. This command is a local command, and the attribute is not propagated to other routers. It is also proprietary to Cisco. To configure the weight attribute, use the following command: Router(config-router)# neighbor { ip-address peer-group-name } weight weight Table 16-7 explains the meaning of the preceding syntax. Table 16-7. An Explanation of the Command to Configure the Weight Attribute | Syntax | Description | | neighbor | This indicates that the rest of the command is directed at a BGP peer. | | ip-address | This is the IP address of the neighboring router. | | peer-group-name | This identifies the BGP peer group, if there is one. | | weight weight | This is proprietary to Cisco and is used in route selection. It is local to the router, and because it is not propagated to other routers, there is no problem with compatibility. When there are multiple paths, it selects a path to a destination with different next hops to the same destination. This identifies the weight attribute, and a value is placed immediately afterward. The default is 32,768, although the range extends from 0 to 65,535, and higher is preferred over lower. | Figure 16-8 illustrates the use of the weight attribute, and Example 16-5 shows how the path through San Francisco is chosen. As you can see, the weight has been set on Chicago, making it prefer the path through San Francisco no matter which network it is trying to reach. The best path to 130.16.0.0 is through New York. (Refer to Example 16-7 later in the chapter to see that the show ip bgp command on Chicago shows that the weight attribute forces San Francisco to be used as the next hop for all paths.) Figure 16-8. The Weight Attribute and Selecting a Path  Example 16-5. A Sample Configuration to Illustrate How to Tune the Weight Attribute ! Chicago(config)# router bgp 100 ! Chicago(config-router)# bgp log-neighbor-changes Chicago(config-router)# neighbor 167.55.191.3 remote-as 100 Chicago(config-router)# neighbor 167.55.199.2 remote-as 100 Chicago(config-router)# neighbor 167.55.199.2 weight 200 !The route from Chicago to San Francisco will have a weight of 200, making this the path that is chosen Chicago# The local preference is equally easy to configure. You can set it on either a default or a per-prefix basis. The command to set the local preference on per-prefix basis follows: Router(config-route-map)# set local-preference local-preference The syntax for the default command is as follows: Router(config-router)# bgp default local-preference value Table 16-8 explains the various parts of the default configuration command. The command to set the local preference on per-prefix basis was provided for reference only because it is outside the scope of this book. Table 16-8. Configuring the Local Preference Attribute | Syntax | Description | | bgp default local-preference | This attribute is used to tell routers within the autonomous system how to exit the autonomous system in the case of multiple paths. It is the opposite of the MED attribute. | | value | Local preference has a range from 0 to 4,294,967,295 (just over 4 billion). The higher value is preferred in selecting routes. The default is 100. | Example 16-6 is based on Figure 16-9. The local preference, set in the San Francisco router to 200, is propagated in the updates to all its peers. Likewise, the local preference of 100 set in the New York router is propagated to its peers. When Chicago has to decide on a path to the network 130.16.0.0, the highest local preference attribute dictates the San Francisco router as the exit point from the autonomous system. Figure 16-9. Using Local Preference to Select a Path  The configurations in Examples 16-5 and 16-6 are extremely simple. Although they work well, you also need to understand route maps. Route maps allow the setting of attributes with conditions and other criteria. Although they are more complex, they are also more efficient. Route maps offer more flexibility with their greater level of sophistication. Route maps are explained in detail in Chapter 18. Example 16-6. A Sample Configuration to Illustrate How to Tune the Local Preference Attribute SanFrancisco(config)# router bgp 100 ! SanFrancisco(config-router)# bgp default local-preference 200 SanFrancisco(config-router)# aggregate-address 167.55.0.0 255.255.0.0 summary-only SanFrancisco(config-router)# neighbor 100.2.4.4 remote-as 400 SanFrancisco(config-router)# neighbor 100.2.4.4 default-originate ! SanFrancisco(config-router)# neighbor 167.55.195.3 remote-as 100 SanFrancisco(config-router)# neighbor 167.55.199.1 remote-as 100 ! NewYork(config)# router bgp 100 ! NewYork(config-router)# bgp default local-preference 100 NewYork(config-router)# network 167.55.0.0 NewYork(config-router)# aggregate-address 167.55.0.0 255.255.0.0 summary-only NewYork(config-router)# neighbor 100.2.3.2 remote-as 300 NewYork(config-router)# neighbor 167.55.191.1 remote-as 100 NewYork(config-router)# neighbor 167.55.195.2 remote-as 100 ! Verifying the Configuration of Attributes It is always important to be able to check your work, particularly when that work defines an entire organization's method of connecting to the Internet. The show ip bgp command shows all the values of all the attributes and their status. Therefore, this is a good command to verify any configurations that change attributes to tune the system and effectively manage the traffic flow to and from the autonomous system. Examples 16-7 through 16-9 show sample output from the show ip bgp command. Example 16-7 shows how BGP is running before the configuration in Example 16-5 or Example 16-6 has been run on the Chicago or San Francisco router. The next hop is to 100.2.3.2, which is in autonomous system 300 because the traffic would be routed via New York. Note in Example 16-7 that the local preference on Chicago has been set by the BGP process to be 100 by default. Example 16-7. The show ip bgp Command Example for Chicago Before Attributes Are Set Chicago# show ip bgp BGP table version is 22, local router ID is 192.168.0.231 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure Origin codes: i - IGP, e - EGP, ? incomplete Network Next Hop Metric LocPrf Weight Path *>i4.0.0.0 100.2.4.4 0 100 0 400 I *>i5.0.0.0 100.2.3.2 0 100 0 300 I *>i100.2.3.0/29 100.2.3.2 0 100 0 300 I *>i100.2.4.0/29 100.2.4.4 0 100 0 400 I *>i130.16.0.0 100.2.3.2 0 100 0 300 I r>i167.55.0.0 167.55.191.3 281600 100 0 I Chicago# Example 16-8 occurs after the configuration for Chicago; the weight is set to 200 for the neighbor 167.55.199.5, which is San Francisco. This forces the longest path to be taken to 130.16.0.0 via San Francisco. Example 16-8. The show ip bgp Command Example Showing the Use of the Weight Attribute Chicago# show ip bgp BGP table version is 8, local router ID is 192.168.0.231 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i4.0.0.0 100.2.4.4 0 100 200 400 i *>i5.0.0.0 100.2.3.2 0 100 0 300 i *>i100.2.3.0/29 100.2.3.2 0 100 0 300 i *>i100.2.4.0/29 100.2.4.4 0 100 200 400 i *>i130.16.0.0 100.2.4.4 100 200 400 500 300 i * i 100.2.3.2 0 100 0 300 i r>i167.55.0.0 167.55.191.3 281600 100 0 i Chicago# Example 16-9 occurs after the San Francisco and New York routers are configured; it is possible to see a change in the neighbor table. The local preference shows that BGP packets destined to 130.16.0.0 still take the high road, against common sense, because the local preference instructs BGP that San Francisco has the best path. This attribute is propagated to other BGP neighbors. You can see that there is only one path shown in this table to 130.16.0.0. Because both New York and San Francisco agree that the path through New York is inferior, it is not sent. Note that the local preference to 167.55.191.3, known to its friends as New York, has a local preference of 100. Example 16-9. The show ip bgp Command Example Showing the Use of the Local Preference Attribute Chicago# show ip bgp BGP table version is 24, local router ID is 192.168.0.231 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure Origin codes: i - IGP, e - EGP, ? incomplete Network Next Hop Metric LocPrf Weight Path *>i4.0.0.0 100.2.4.4 0 200 0 400 i *>i5.0.0.0 100.2.4.4 200 0 400 500 300 i r>i100.2.3.0/29 100.2.4.4 200 0 400 500 300 i *>i100.2.4.0/29 100.2.4.4 0 200 0 400 i *>i130.16.0.0 100.2.4.4 200 0 400 500 300 i r>i167.55.0.0 167.55.191.3 281600 100 0 i Chicago# Table 16-9 describes significant fields shown in Examples 16-7 through 16-9. Table 16-9. Explanation of Output from the show ip bgp Command | Field | Description | | BGP table version | Internal version number of the table. This number is incremented whenever the table changes. | | Local router ID | The highest IP address of the router. | | Status codes | Status of the table entry. The status is displayed at the beginning of each line in the table. It can be one of the following values: s The table entry is suppressed. * The table entry is valid. > The table entry is the best entry to use for that network. i The table entry was learned via an iBGP session. D The table entry was dampened. | | Origin | The origin of the entry. The origin code is placed at the end of each line in the table. It can be one of the following values: i Entry originated from IGP and was advertised with a network router configuration command. e Entry originated from an EGP. ? Origin of the path is not clear. Usually, this is a router that is redistributed into BGP from an IGP. | | Network | A destination IP address of a network. | | Next hop | IP address of the next logical device in the path to the destination. The forwarded packets are sent to this address. An entry of 0.0.0.0 indicates that the router has some non-BGP routes to this network. | | Metric | If shown, this is the value of the metric between autonomous systems. This field is frequently not used. | | LocPrf | Local preference values as set on the routers with interfaces to other autonomous systems. It defines how preferable that router is as a transit point out of the autonomous system. The default value is 100. | | Weight | Weight of the route, determining which path the router will choose. It is proprietary to Cisco and is an attribute local to the router. | | Path | Autonomous system paths to the destination network. There can be one entry in this field for each autonomous system in the path. | Redistribution Between IGP and BGP Up until now, the discussion has been about BGP, its operation, and the configuration options available. However, for most networks, BGP is the means by which information about the Internet is brought into the internal organizational routing domain. Disseminating this information throughout the autonomous system is the subject of the next section. If the organization is not an ISP, there is a fair chance that the network is running an IGP within the autonomous system. The IP routing table generated by this protocol or protocols is distinct from the BGP routing table, although as you have seen, they communicate freely . The use of synchronization is a case in point. However, populating one routing table with routes from the other routing table needs to be manually configured. Routes can be injected from the IGP into BGP, or from the BGP into the IGP, as discussed in the next sections. Advertising Routes from IGP into BGP First, consider the advertising routes into BGP. There are three ways of populating the BGP table with IGP routes: -
Using the network command This is used to advertise routes that are in the IP routing table. -
Redistributing static routes Although any static route can be redistributed into BGP, static routes are often used to create a supernet. The static route is a summary of classful addresses, such as Class C addresses with a prefix mask of 16 bits instead of 24 bits. This requires statically routing to null 0. This fools the system by creating a route that has no exit point from the router because the route does not exist but is redistributed into BGP. The command places the route into the routing table without fear of it being used and creating a black hole. The problem is that if the route in the IGP routing table disappears, BGP still advertises the route, causing traffic to journey into the autonomous system, only to die. Therefore, Cisco suggests that you use the aggregate-address command for BGP instead. -
Redistributing dynamically learned routes from the IGP This configuration is not advised because there is a great reliance on the IGP table. It is imperative that external routes carried in iBGP are filtered out; otherwise, routing loops are generated when BGP routes are fed into IGP, only to be advertised back into BGP further down the network. Advertising Routes from BGP into an IGP Redistributing the routes from the Internet into a small network is unwise. The proposition is alarming because of the vastness of the Internet and the enormity of the routing tables. Even with a large amount of aggregation and filtering, there is still a lot of information to carry over. Because ISPs tend to run eBGP and iBGP extensively, ISPs often run them exclusively for exterior routes, using an IGP only for internal routes. This requires no redistribution, which is easier for the routers and means the following: The synchronization function is not necessary in this type of network because iBGP is running in a fully meshed environment. With either a fully meshed network or carefully designed route reflectors, the synchronization rule can be turned off. If iBGP is multihomed, redistribution from BGP into the IGP is needed. The IGP needs to carry the external routes across the autonomous system to the other BGP router. Also, any device wanting to connect to the Internet needs to have either a default route or specific routes to direct traffic forward. Filtering must be configured; otherwise, the internal routing tables will become overwhelmed. This is illustrated in Figure 16-10. Figure 16-10. Redistributing BGP Routes into a Non-ISP Organization  | 