Basic BGP Configuration

This section presents the essential steps for configuring a BGP process and the most commonly used techniques for controlling BGP. For the great majority of BGP implementations , the information presented in this section is all that you need.

Case Study: Peering BGP Routers

A BGP session between routers is configured in two steps:

Step 1. Establish the BGP process and specify the local AS number with the router bgp command.

Step 2. Specify a neighbor and the neighbor's AS number with the neighbor remote-as command.

Figure 3-1 shows two routers in different autonomous systems. The structure of the BGP configuration for these routers differs from EGP configuration. Recall from Chapter 1, "Exterior Gateway Protocol," that the router egp command specifies the remote AS, and the autonomous-system command specifies the local AS. In contrast, router bgp specifies the local AS. Each neighbor's AS is specified with the neighbor remote-as command. This difference is significant. Whereas only core EGP routers can peer with more than one remote AS (with the router egp 0 command), any BGP process can peer with any number of remote autonomous systems. The EGP requirement for stub autonomous systems connected through a core AS is eliminated; autonomous systems can be meshed fully under BGP.

Figure 3-1. An EBGP Session Is Established Between Taos and Vail

Example 3-1 shows the EBGP configurations for the Taos and Vail routers in Figure 3-1.

Example 3-1 EBGP Configurations for Routers in Figure 3-1

  Taos   router bgp 200   neighbor 192.168.1.226 remote-as 100  _______________________________________________________________________  Vail   router bgp 100   neighbor 192.168.1.225 remote-as 200  

Example 3-2 shows the information Vail has recorded about Taos. Much of the information in this screen is particularly useful for troubleshooting. Appendix A, "The show ip bgp neighbors Display," provides a complete description of all the fields displayed by the show ip bgp neighbors command.

Example 3-2 show ip bgp neighbors Command Output Contains Details About the Peer Connection with a Neighbor

 Vail#  show ip bgp neighbors   BGP neighbor is 192.168.1.225,  remote AS 200, external link  Index 1, Offset 0, Mask 0x2  BGP version 4, remote router ID 192.168.1.225   BGP state = Established, table version = 1, up for 19:32:02   Last read 00:00:03, hold time is 180, keepalive interval is 60 seconds  Minimum time between advertisement runs is 30 seconds   Received 1175 messages, 0 notifications, 0 in queue   Sent 1175 messages, 0 notifications, 0 in queue   Prefix advertised 0, suppressed 0, withdrawn 0   Connections established 1; dropped 0   Last reset never   0 accepted prefixes consume 0 bytes   0 history paths consume 0 bytes  Connection state is ESTAB, I/O status: 1, unread input bytes: 0   Local host: 192.168.1.226, Local port: 11025   Foreign host: 192.168.1.225, Foreign port: 179  Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 bytes) Event Timers (current time is 0x45FDF2C): Timer          Starts    Wakeups            Next Retrans          1176          0             0x0 TimeWait            0          0             0x0 AckHold          1175        885             0x0 SendWnd             0          0             0x0 KeepAlive           0          0             0x0 GiveUp              0          0             0x0 PmtuAger            0          0             0x0 DeadWait            0          0             0x0 iss: 4072889888  snduna: 4072912224  sndnxt: 4072912224     sndwnd:  16004 irs: 4121607729  rcvnxt: 4121630065  rcvwnd:      16004  delrcvwnd:    380 SRTT: 300 ms, RTTO: 607 ms, RTV: 3 ms, KRTT: 0 ms minRTT: 4 ms, maxRTT: 340 ms, ACK hold: 200 ms Flags: higher precedence, nagle Datagrams (max data segment is 1460 bytes): Rcvd: 2220 (out of order: 0), with data: 1175, total data bytes: 22335 Sent: 2077 (retransmit: 0), with data: 1175, total data bytes: 22335 Vail# 

The first line of output in Example 3-2 shows the address of Taos (192.168.1.225), its AS number (200), and the type of BGP connection to the router (external). The third line displays the BGP version used between Vail and Taos, and Taos' router ID. The fourth line begins by showing the state of the BGP finite state machine. The table version is incremented whenever the BGP routing table changes; in Example 3-2, no changes have taken place since the connection to Taos was established, so the table version is still 1. Uptime shows the time since the present peer connection was established. In Example 3-2, Taos has been peered continuously for 19 hours, 32 minutes, and 2 seconds.

Also of interest are the details of the underlying TCP connection. Example 3-2 highlights these lines. The lines show that the TCP connection state is Established, that Vail is originating BGP messages from TCP port 11025, and that the destination port at Taos is 179. The source port can be especially important when you are capturing packets on a link carrying more than one BGP session.

In Figure 3-2, another router is added to AS 100. Because they are in the same AS, Vail and Aspen are internal neighbors.

Figure 3-2. IBGP Is Spoken Between Vail and Aspen

Example 3-3 shows the configuration for Vail.

Example 3-3 Configuration for Vail Router in Figure 3-2

  router bgp 100   neighbor 192.168.1.222 remote-as 100   neighbor 192.168.1.225 remote-as 200  

Example 3-4 shows Aspen being configured. BGP debugging is used to observe the peer session being created. The figure shows that the time from the creation of the BGP configuration (18:24:13) to the beginning of the BGP peer negotiation (18:24:33) is 20 seconds; the TCP connection is established during this interval. BGP then transitions from Idle to Active, and the entire negotiation lasts approximately 10 seconds.

Example 3-4 The debug ip bgp events Command Displays the States of the BGP Finite State Machine as Aspen Peers with Vail

  Aspen#    debug ip bgp events   BGP events debugging is on Aspen#  conf t  Enter configuration commands, one per line.  End with CNTL/Z.  Aspen    (config)#router bgp 100    Aspen    (config-router)#neighbor 192.168.1.221 remote-as 100   Aspen(config-router)#^  Z  Aspen# 18:24:13: %SYS-5-CONFIG_I: Configured from console by console Aspen# 18:24:33: BGP: 192.168.1.221 went from Idle to Active 18:24:41: BGP: 192.168.1.221 went from Active to OpenSent 18:24:42: BGP: 192.168.1.221 went from OpenSent to OpenConfirm 18:24:42: BGP: 192.168.1.221 went from OpenConfirm to Established 18:24:43: BGP: 192.168.1.221 computing updates, neighbor version 0, table version n 1, starting at 0.0.0.0 18:24:43: BGP: 192.168.1.221 update run completed, ran for 0ms, neighbor version  0, start version 1, throttled to 1, check point net 0.0.0.0 Aspen# 

Example 3-5 shows a portion of Aspen's neighbor information.

Example 3-5 Aspen's Neighbor Information Shows That Vail's Router ID Is from One of Its Physical Interfaces

 Aspen#  show ip bgp neighbors  BGP neighbor is 192.168.1.221,  remote AS 100, internal link  Index 1, Offset 0, Mask 0x2  BGP version 4, remote router ID 192.168.1.226  BGP state = Established, table version = 1, up for 00:03:46   Last read 00:00:46, hold time is 180, keepalive interval is 60 seconds   Minimum time between advertisement runs is 5 seconds   Received 6 messages, 0 notifications, 0 in queue   Sent 6 messages, 0 notifications, 0 in queue   Prefix advertised 0, suppressed 0, withdrawn 0   Connections established 1; dropped 0   Last reset never   0 accepted prefixes consume 0 bytes   0 history paths consume 0 bytes Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Local host: 192.168.1.222, Local port: 179 Foreign host: 192.168.1.221, Foreign port: 11000 

Notice that Vail's router ID is 192.168.1.226, the address of its interface to Taos. The rules for selecting a BGP router ID are identical to the rules for selecting an OSPF router ID:

• The router chooses the numerically highest IP address on any of its loopback interfaces.

• If no loopback interfaces are configured with IP addresses, the router chooses the numerically highest IP address on any of its physical interfaces. The interface from which the router ID is taken does not have to be running BGP.

Because Vail does not have a loopback interface configured, the router chose the numerically highest IP address on a physical interface. Using addresses associated with loopback interfaces has two advantages:

• The loopback interface is more stable than any physical interface. It is active when the router boots up, and it fails only if the entire router fails.

• The network administrator has more leeway in assigning predictable or recognizable addresses as the router IDs.

Cisco's BGP continues to use a router ID learned from a physical interface, even if the interface subsequently fails or is deleted. Therefore, the stability of a loopback interface is only a minor advantage. The primary benefit is the capability to control the router ID, making it easily distinguishable from other IP addresses.

Example 3-6 shows how to configure Vail with a unique router ID.

Example 3-6 Configuring Vail with a Unique Router ID

  interface loopback 0   ip address 192.168.255.254 255.255.255.255   !   router bgp 100   neighbor 192.168.1.222 remote-as 100   neighbor 192.168.1.225 remote-as 200  

Just configuring a loopback address on a working BGP router does not change the router ID, however. The command clear ip bgp (discussed in more detail in the section "Configuring Routing Policies") must be issued at Vail to clear all of its BGP sessions. A second look at Aspen's neighbor information in Example 3-7 shows that Vail's router ID is now its loopback 0 address.

Another point of interest in Example 3-7, when compared to Example 3-5, is the table version. After Vail's session is reset, the table version is incremented to 2. The change also is reflected in the Connections established; dropped field. These fields should not change often; if they do, it might indicate an unstable neighbor.

Example 3-7 Vail's Router ID, After a Loopback Address Is Configured and Its BGP Sessions Are Reset, Is Its Loopback Address

 Aspen#  show ip bgp neighbors  BGP neighbor is 192.168.1.221,  remote AS 100, internal link  Index 1, Offset 0, Mask 0x2  BGP version 4, remote router ID 192.168.255.254   BGP state = Established, table version = 2, up for 00:00:42  Last read 00:00:42, hold time is 180, keepalive interval is 60 seconds   Minimum time between advertisement runs is 5 seconds   Received 37 messages, 0 notifications, 0 in queue   Sent 37 messages, 0 notifications, 0 in queue   Prefix advertised 0, suppressed 0, withdrawn 0  Connections established 2; dropped 1  Last reset 00:00:51, due to Peer closed the session   0 accepted prefixes consume 0 bytes   0 history paths consume 0 bytes Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Local host: 192.168.1.222, Local port: 179 Foreign host: 192.168.1.221, Foreign port: 11003 

You also can set the router ID of a BGP speaker manually, overriding both the physical and loopback interface addresses. The command for doing so is bgp router-id. For example, the configuration in Example 3-8 sets the BGP router ID of Vail to 1.1.3.2.

Example 3-8 Setting the BGP Router ID Manually

  interface loopback 0   ip address 192.168.255.254 255.255.255.255   !   router bgp 100    bgp router-id 1.1.3.2    neighbor 192.168.1.222 remote-as 100   neighbor 192.168.1.225 remote-as 200  

The bgp router-id command can prove useful in situations where loopback interfaces are needed for other reasons, such as OSPF router IDs or SNMP functions, but the IP addresses on the interfaces differ from what you desire for the BGP router ID.

Case Study: Injecting IGP Routes into BGP

Chapter 2 emphasizes that at an AS border, outgoing route advertisements affect incoming traffic, and incoming route advertisements affect outgoing traffic. As a result, outgoing and incoming advertisements should be considered separately. This section begins the discussion of BGP route advertisements by examining basic methods of injecting routes into BGP.

Figure 3-3 shows that AS 200 uses EIGRP as its IGP. Taos must advertise three addresses to its EBGP peer: 192.168.200.0/24 is learned via EIGRP, 192.168.100.0/24 is directly attached to Taos, and 192.168.1.216/30 is connecting Taos and AngelFire. Whereas the first two addresses are full class C addresses, the last is a subnet. Other subnets of 192.168.1.0 appear outside of AS 200, so the subnet only, not the major network address, must be advertised.

Figure 3-3. AS 200 Is Using EIGRP as Its IGP

Example 3-9 shows a "first-pass" configuration of Taos.

Example 3-9 Taos' Basic EIGRP and BGP Configuration

  router eigrp 200   passive-interface Serial0   network 192.168.1.0   network 192.168.100.0   !   router bgp 200   redistribute eigrp 200   neighbor 192.168.1.226 remote-as 100  

Example 3-10 shows the results in Vail's BGP table. All EIGRP networks have been advertised over the EBGP link. Notice in the configuration that no metric was specified with the redistribute command. As a result, the metric of each route defaults to the EIGRP metric, as shown in Taos' routing table in Example 3-11. The directly connected networks have a metric of 0, and 192.168.200.0/24 has a metric of 409600. You can change this default method of selecting a metric with the default-metric command.

NOTE

The BGP metric is the MULTI_EXIT_DISC. The use and manipulation of this attribute is demonstrated in the section "Case Study: Using the MULTI_EXIT_DISC Attribute."

Example 3-10 Taos Advertised 192.168.100.0/24 and 192.168.200.0/24 Correctly, but the Subnet 192.168.1.216/30 Was Summarized to the Major Network

 Vail#  show ip bgp  BGP table version is 15, local router ID is 192.168.255.254 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path *> 192.168.1.0      192.168.1.225       281600             0 200 ? *> 192.168.100.0    192.168.1.225            0             0 200 ? *> 192.168.200.0    192.168.1.225       409600             0 200 ? Vail# 

Example 3-11 Taos' Routing Table Shows That the EIGRP Metrics Are the Same as the Metrics in Vail's BGP Table

 Taos#  show ip route  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default        U - per-user static route, o - ODR        T - traffic engineered route Gateway of last resort is not set D    192.168.200.0/24 [90/409600] via 192.168.1.217, 00:52:09, Ethernet0      192.168.1.0/24 is variably subnetted, 3 subnets, 2 masks D       192.168.1.0/24 is a summary, 00:52:11, Null0 C       192.168.1.224/30 is directly connected, Serial0 C       192.168.1.216/30 is directly connected, Ethernet0 C    192.168.100.0/24 is directly connected, Ethernet1 Taos# 

The two major networks in AS 200 are advertised correctly, but you can see in Example 3-9 that the subnet 192.168.1.216/30 has been summarized to the major network. The reason for this is that BGP-4, although it is classless, by default summarizes at network boundaries. In the internetwork of Figure 3-3, this summarization presents no problem. Vail is directly connected to the other two subnets of 192.168.1.0 and therefore knows the two more-specific routes. As the network grows and other subnets of that network are used on other routers, however, the summary can cause incorrect routing. To turn off BGP's automatic summarization, configure Taos as in Example 3-12.

Example 3-12 Taos Configuration to Turn Off BGP Automatic Summarization

  router eigrp 200   passive-interface Serial0   network 192.168.1.0   network 192.168.100.0   !   router bgp 200   redistribute eigrp 200   neighbor 192.168.1.226 remote-as 100    no auto-summary   

Example 3-13 shows the results in Vail's BGP table. The subnets of 192.168.1.0 are now being advertised. However, the major network 192.168.1.0 is still being advertised in addition to the subnets. Another look at Taos' routing table in Example 3-11 shows why. EIGRP also performs automatic route summarization and has entered a summary route to Null0 in the routing table. BGP is picking up this route in addition to the subnets and is advertising it to Vail.

Example 3-13 Vail's BGP Table, After BGP Auto-Summarization Is Turned Off at Taos

 Vail#  show ip bgp  BGP table version is 17, local router ID is 192.168.255.254 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path *> 192.168.1.0      192.168.1.225       281600             0 200 ? *> 192.168.1.216/30 192.168.1.225            0             0 200 ? *> 192.168.1.224/30 192.168.1.225            0             0 200 ? *> 192.168.100.0    192.168.1.225            0             0 200 ? *> 192.168.200.0    192.168.1.225       409600             0 200 ? Vail# 

To turn off EIGRP auto-summarization for the Taos router, you use the same no auto-summary command as demonstrated in Example 3-14.

Example 3-14 Taos Configuration to Turn Off EIGRP Automatic Summarization

  router eigrp 200   passive-interface Serial0   network 192.168.1.0   network 192.168.100.0    no auto-summary    !   router bgp 200   redistribute eigrp 200   neighbor 192.168.1.226 remote-as 100    no auto-summary   

Example 3-15 shows the resulting BGP table at Vail.

Example 3-15 Vail's BGP Table After EIGRP Auto-Summarization Is Turned Off at Taos

 Vail#  show ip bgp  BGP table version is 20, local router ID is 192.168.255.254 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path *> 192.168.1.216/30 192.168.1.225            0             0 200 ? *> 192.168.1.224/30 192.168.1.225            0             0 200 ? *> 192.168.100.0    192.168.1.225            0             0 200 ? *> 192.168.200.0    192.168.1.225       409600             0 200 ? Vail# 

The advantage of using redistribution to inject routes into BGP is that internal changes can be advertised with few or no changes to the BGP configuration. If a network is added or removed within the EIGRP domain of AS 200, the change is automatically advertised to Vail. However, advertising every IGP route is also the major disadvantage of IGP-to-BGP redistribution. For example, the administrators of autonomous systems 100 and 200 might or might not want subnet 192.168.1.224/30 advertised from Taos to Vail, as it is in Example 3-15. If the subnet should not be advertised, a route filter must be used. Later in this chapter, the section "Routing Policies" demonstrates , through several case studies, various options for configuring route filters.

Route filters are almost always necessary when redistributing an IGP's routes into BGP. By default, every route known by the IGP is redistributed. The administrator of the AS might want to advertise only a subset of the IGP routes, and so must filter the others. Or, perhaps a multihomed AS should not be a transit for any of its neighboring autonomous systems. Route filters must be used to prevent external routes learned from one AS from being advertised to other autonomous systems. Then there is the problem of route feedback, in which external routes received from EBGP are advertised into an IGP and then are redistributed from that IGP back into EBGP. At a minimum, best practice dictates that route filters should be used to ensure that only the correct routes are redistributed. In actual practice, redistribution of IGP prefixes into BGP is rarely used because of this lack of precise control.

An alternative to redistributing IGP routes into BGP is to use the network command. As discussed in Chapter 1, this command functions differently under EGP and BGP than it does under an IGP. When used with an IGP, the network command specifies the address of an interface or group of interfaces on which the routing protocol will be enabled. When used with EGP and BGP, network specifies an IP prefix to be advertised. For each prefix specified with the command, BGP looks into the routing table. If an entry in the table exactly matches the network prefix, that prefix is entered into the BGP table and advertised.

Example 3-16 shows the configuration for Taos using the network command rather than redistribution.

Example 3-16 Configuring Taos with the network Command

  router eigrp 200   passive-interface Serial0   network 192.168.1.0   network 192.168.100.0   !   router bgp 200   network 192.168.1.216 mask 255.255.255.252   network 192.168.100.0   network 192.168.200.0   neighbor 192.168.1.226 remote-as 100  

The major networks 192.168.100.0 and 192.168.200.0 are specified alone. For the subnet 192.168.1.216, a mask is also specified. Subnets and masks can be specified only under BGP-4; under EGP or earlier versions of BGP, all of which are classful, only major networks can be specified.

Notice that the no auto-summary command is not used under either EIGRP or BGP in this configuration. Because no redistribution is taking place, turning off auto-summarization is unnecessary. Example 3-17 shows the result of the configuration.

Example 3-17 Vail's BGP Table After Taos Is Reconfigured Using the BGP network Command

 Vail#  show ip bgp  BGP table version is 36, local router ID is 192.168.255.254 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path *> 192.168.1.216/30 192.168.1.225            0             0 200 i *> 192.168.100.0    192.168.1.225            0             0 200 i *> 192.168.200.0    192.168.1.225       409600             0 200 i Vail# 

Unlike in Example 3-15, subnet 192.168.1.224/30 is not advertised, because it was not specified with a network command. The administrator has more control than with redistribution, and no filtering is necessary. Comparing Example 3-15 and Example 3-17, notice that the ORIGIN codes differ. Whereas the redistributed routes in Example 3-15 are tagged with a ?, indicating an ORIGIN of "incomplete," the routes in Example 3-17 are tagged with an i, indicating an ORIGIN of IGP. This tagging can make a difference in some circumstances because the BGP decision process, discussed in Chapter 2, gives a higher preference to ORIGIN code 1 (IGP) than to code 3 (incomplete).

A maximum of 200 addresses can be specified with the network command. If you must advertise more addresses across a BGP connection, you must use redistribution.

Case Study: Injecting BGP Routes into an IGP

Prefixes that are learned from an EBGP neighbor are automatically added to the routing table. In Figure 3-4, for instance, AS 300 is advertising two routes: 192.168.250.0/24 and 192.168.1.212/30. AS 300's IGP, and the configuration of router Tahoe, are unimportant to this example. The important observations are that the prefixes advertised by Tahoe to its external BGP peer are displayed in the Taos routing table as reachable and that pings to a destination in AS 300 are successful (see Example 3-18). An extended ping is used because the subnet of Taos' serial interface, 192.168.1.224/30, is not advertised. The BGP-learned routes are tagged in the routing table with a B.

Figure 3-4. AS 300 Has Been Added to the Topology Presented in Figure 3-3

Example 3-18 A Ping to an Address in AS 300 of Figure 3-4 Is Successful

 Taos#  show ip route  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default        U - per-user static route, o - ODR        T - traffic engineered route Gateway of last resort is not set D    192.168.200.0/24 [90/409600] via 192.168.1.217, 00:25:37, Ethernet0  B    192.168.250.0/24 [20/0] via 192.168.1.226, 16:18:12  192.168.1.0/24 is variably subnetted, 4 subnets, 2 masks D       192.168.1.0/24 is a summary, 00:25:43, Null0 C       192.168.1.224/30 is directly connected, Serial0 C       192.168.1.216/30 is directly connected, Ethernet0  B       192.168.1.212/30 [20/0] via 192.168.1.226, 16:18:12  C    192.168.100.0/24 is directly connected, Ethernet1 Taos#  ping  Protocol [ip]:  Target IP address: 192.168.250.1  Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 192.168.100.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.250.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/64/112 ms Taos# 

Although the networks of AS 300 are reachable from Taos, the BGP routes must be advertised into EIGRP before the networks are reachable from AS 200's interior routers. One way to accomplish this is with redistribution at Taos, as demonstrated by the configuration in Example 3-19.

Example 3-19 Advertising the BGP Routes into EIGRP

  router eigrp 200   redistribute bgp 200 metric 10000 100 255 1 1500   passive-interface Serial0   network 192.168.1.0   network 192.168.100.0   !   router bgp 200   network 192.168.1.216 mask 255.255.255.252   network 192.168.100.0   network 192.168.200.0   neighbor 192.168.1.226 remote-as 100  

Example 3-20 shows that AS 300's prefixes are advertised to AngelFire and that the destinations are reachable. However, many of the same concerns about redistribution exist for inbound routes as for outbound routes. Redistribution picks up every BGP route, but the administrator might want only a subset of the BGP routes to be redistributed. In such a case, route filters are again required to suppress the unwanted routes.

CAUTION

Another vitally important reason exists for not redistributing BGP routes into an IGP. A full Internet routing table consists of more than 80,000 prefixes, and an IGP process will " choke " trying to process so many routes. Redistribution of a full Internet table, or even a large partial table, will inevitably cause a major network crash. The redistribution examples shown in this chapter can be useful in an enterprise network with limited prefixes, but you should never use a BGP-to-IGP redistribution on an Internet- facing router.

Example 3-20 Taos Has Redistributed Its BGP-Learned Routes into EIGRP

 AngelFire#  show ip route  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default        U - per-user static route, o - ODR Gateway of last resort is not set D    192.168.100.0/24 [90/409600] via 192.168.1.218, 01:14:22, Ethernet0/0      192.168.1.0/24 is variably subnetted, 4 subnets, 2 masks D       192.168.1.224/30 [90/2195456] via 192.168.1.218, 01:16:44, Ethernet0/0 C       192.168.1.216/30 is directly connected, Ethernet0/0  D EX    192.168.1.212/30 [170/307200] via 192.168.1.218, 00:03:55, Ethernet0/0   D EX 192.168.250.0/24 [170/307200] via 192.168.1.218, 00:03:55, Ethernet0/0  C    192.168.200.0/24 is directly connected, Ethernet0/1 AngelFire#  ping 192.168.250.1  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.250.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/12 ms AngelFire# 

For more control over which routes are advertised into AS 200, you can use static routes, as demonstrated in Example 3-21.

Example 3-21 Controlling Routes Advertised into AS 200 via Static Routes

  router eigrp 200   redistribute static metric 10000 100 255 1 1500   passive-interface Serial0   network 192.168.1.0   network 192.168.100.0   !   router bgp 200   network 192.168.1.216 mask 255.255.255.252   network 192.168.100.0   network 192.168.200.0   neighbor 192.168.1.226 remote-as 100   !   ip route 192.168.250.0 255.255.255.0 Serial0  

In this configuration, only 192.168.250.0/24 is advertised into the AS. As Example 3-22 shows, AngelFire has no knowledge of subnet 192.168.1.212/30. Using static routes in the configuration has the added benefit of protecting AS 200 from instabilities. If network 192.168.250.0 flaps in AS 300, the changes are not advertised any further into AS 200 than Taos.

Example 3-22 Subnet 192.168.1.212/30 Is Not Advertised to AngelFire

 AngelFire#  show ip route  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default        U - per-user static route, o - ODR Gateway of last resort is not set D    192.168.100.0/24 [90/409600] via 192.168.1.218, 00:14:33, Ethernet0/0      192.168.1.0/24 is variably subnetted, 3 subnets, 2 masks D       192.168.1.224/30 [90/2195456] via 192.168.1.218, 00:14:33, Ethernet0/0 C       192.168.1.216/30 is directly connected, Ethernet0/0  D EX 192.168.250.0/24 [170/307200] via 192.168.1.218, 00:11:17, Ethernet0/0  C    192.168.200.0/24 is directly connected, Ethernet0/1 AngelFire#  ping 192.168.250.1  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.250.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/8 ms AngelFire# 

Of course, in a single- homed AS, such as AS 200 in Figure 3-4, little reason exists to advertise any external routes into the AS at all. Unless there is a need to advertise specific routes into the AS, a default route suffices, as demonstrated by Example 3-23.

Example 3-23 Configuring a Default Route in a Single-Homed AS

  router eigrp 200   redistribute static metric 10000 100 255 1 1500   passive-interface Serial0   network 192.168.1.0   network 192.168.100.0   !   router bgp 200   network 192.168.1.216 mask 255.255.255.252   network 192.168.100.0   network 192.168.200.0   neighbor 192.168.1.226 remote-as 100   !   ip classless   ip route 0.0.0.0 0.0.0.0 Serial0  

In the configuration in Example 3-23, Taos generates a default route and advertises it to all EIGRP speakers ; however, you also can configure BGP to generate a default route. To advertise a default from Vail to its BGP neighbors, use the configuration in Example 3-24.

Example 3-24 Configuring a Default Route to BGP Neighbors

  router bgp 100   network 0.0.0.0   neighbor 192.168.1.210 remote-as 300   neighbor 192.168.1.222 remote-as 100   neighbor 192.168.1.225 remote-as 200   !   ip route 0.0.0.0 0.0.0.0 Null0  

A default route to the Null0 interface is created statically, and the route is advertised with the network command. The assumption with the configuration in Example 3-24 is that Vail has full routing information. All packets are forwarded to Vail; any destination address that cannot be matched to a more-specific route matches the static route and is dropped.

In some design cases, a default should be sent to some neighbors, but not to others. To send a default from Vail to Taos, but not to any of Vail's other neighbors, use the configuration in Example 3-25.

Example 3-25 Configuring a Default Route to Specific BGP Neighbors

  router bgp 100   neighbor 192.168.1.210 remote-as 300   neighbor 192.168.1.222 remote-as 100   neighbor 192.168.1.225 remote-as 200   neighbor 192.168.1.225 default-originate  

The BGP neighbor default-originate command is similar to the OSPF default-information-originate always command in that a default is advertised whether the router actually has a default route or not. Notice in the configuration that the static route from the preceding configuration is no longer present; however, a route to 0.0.0.0/0 is still advertised to Taos, as Example 3-26 shows. Example 3-26 also shows the routing table of Tahoe. You can see that, unlike Taos, Tahoe does not have an entry for 0.0.0.0/0.

Example 3-26 A Default Route Has Been Advertised to Taos, But Not to Tahoe

 Taos#  show ip route  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default        U - per-user static route, o - ODR        T - traffic engineered route  Gateway of last resort is 192.168.1.226 to network 0.0.0.0  D    192.168.200.0/24 [90/409600] via 192.168.1.217, 02:06:34, Ethernet0 B    192.168.250.0/24 [20/0] via 192.168.1.226, 00:46:03      192.168.1.0/24 is variably subnetted, 4 subnets, 2 masks D       192.168.1.0/24 is a summary, 02:06:34, Null0 C       192.168.1.224/30 is directly connected, Serial0 C       192.168.1.216/30 is directly connected, Ethernet0 B       192.168.1.212/30 [20/0] via 192.168.1.226, 00:46:04 C    192.168.100.0/24 is directly connected, Ethernet1  B*   0.0.0.0/0 [20/0] via 192.168.1.226, 00:47:03  Taos# _______________________________________________________________________ Tahoe#  show ip route  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default  Gateway of last resort is not set  B    192.168.100.0 [20/0] via 192.168.1.209, 00:48:26      192.168.1.0 255.255.255.252 is subnetted, 3 subnets B       192.168.1.216 [20/0] via 192.168.1.209, 00:48:26 C       192.168.1.208 is directly connected, Serial0 C       192.168.1.212 is directly connected, Serial1 C    192.168.250.0 is directly connected, Ethernet0 B    192.168.200.0 [20/0] via 192.168.1.209, 00:48:27 Tahoe# 

The advertisement of a default route to a BGP neighbor does not suppress the more-specific routes. In Example 3-26, you can see that the routes from AS 300 are still present in Taos' routing table. In some cases, this can be desirable. For example, an ISP might send to a customer the routes to all of its other customers (a partial Internet table), as well as a default to the rest of the Internet. Such a case is useful when multihomed to the same ISP. The customer network can then make best-path choices to the ISP's customers and use the default route for all other external destinations.

If only the default is to be sent, you must use a route filter to suppress all more-specific routes. The configuration in Example 3-27, using the neighbor distribute-list command, is just one way to filter BGP routes. The section "Routing Policies" demonstrates other techniques.

Example 3-27 Filtering BGP Routes with the neighbor distribute-list Command

  router bgp 100   neighbor 192.168.1.210 remote-as 300   neighbor 192.168.1.222 remote-as 100   neighbor 192.168.1.225 remote-as 200   neighbor 192.168.1.225 default-originate   neighbor 192.168.1.225 distribute-list 1 out   !   access-list 1 permit 0.0.0.0   access-list 1 deny any  

Case Study: IBGP without an IGP

In Figure 3-5, another router is added to AS 100; it connects to another AS via EBGP. AS 100 is now a transit AS, carrying traffic that neither originates nor terminates in AS 100.

Figure 3-5. AS 100 Is Running IBGP to Carry the Transit Traffic Between AS 400 and the Other Two Autonomous Systems

To carry the transit traffic, the interior routers in AS 100 are fully meshed with IBGP, as shown in the configurations in Example 3-28.

Example 3-28 Configuring the Interior Routers in AS 100 to Be Fully Meshed with IBGP

  Vail   router bgp 100   no synchronization   network 192.168.1.208 mask 255.255.255.252   network 192.168.1.224 mask 255.255.255.252   neighbor 192.168.1.197 remote-as 100   neighbor 192.168.1.210 remote-as 300   neighbor 192.168.1.222 remote-as 100   neighbor 192.168.1.225 remote-as 200  _______________________________________________________________________  Aspen   router bgp 100   no synchronization   network 192.168.1.196 mask 255.255.255.252   network 192.168.1.220 mask 255.255.255.252   neighbor 192.168.1.197 remote-as 100   neighbor 192.168.1.221 remote-as 100  _______________________________________________________________________  Telluride   router bgp 100   no synchronization   network 192.168.1.204 mask 255.255.255.252   neighbor 192.168.1.198 remote-as 100   neighbor 192.168.1.205 remote-as 400   neighbor 192.168.1.221 remote-as 100  

Example 3-29 shows Alta's routing table; a few pings demonstrate that the destinations in AS 200 and AS 300 are reachable.

Example 3-29 Routes from AS 200 and AS 300 Have Been Passed Across the IBGP Connections in AS 100 to AS 400

 Alta#  show ip route  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default Gateway of last resort is not set B    192.168.100.0 [20/0] via 192.168.1.206, 02:02:59 C    192.168.75.0 is directly connected, Ethernet1 C    192.168.50.0 is directly connected, Ethernet0      192.168.1.0 255.255.255.252 is subnetted, 8 subnets B       192.168.1.224 [20/0] via 192.168.1.206, 02:02:59 C       192.168.1.200 is directly connected, Ethernet2 C       192.168.1.204 is directly connected, Serial0 B       192.168.1.196 [20/0] via 192.168.1.206, 02:03:30 B       192.168.1.216 [20/0] via 192.168.1.206, 02:02:59 B       192.168.1.220 [20/0] via 192.168.1.206, 02:03:30 B       192.168.1.208 [20/0] via 192.168.1.206, 02:02:59 B       192.168.1.212 [20/0] via 192.168.1.206, 02:02:59 B    192.168.250.0 [20/0] via 192.168.1.206, 02:02:59 B    192.168.200.0 [20/0] via 192.168.1.206, 02:03:00 Alta#  ping 192.168.250.1  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.250.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms Alta#  ping 192.168.200.1  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.200.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms Alta# 

Remember the following important points when configuring IBGP as shown in Figure 3-5:

• Synchronization must be turned off.

• Every IBGP router must be peered with every other IBGP router.

• All networks and subnets connecting the IBGP routers must be known.

In the configurations in Example 3-28, you can see that synchronization is disabled with the command no synchronization. Recall from Chapter 2 that the rule of synchronization states that a router cannot advertise IBGP routes to an EBGP peer unless the routes are known by the IGP. In other words, BGP must be synchronized with the IGP. Neither redistribution nor network statements cause a route to be advertised that is not in the routing table.

The rule of synchronization is circumvented if IBGP-learned routes are entered into the routing table. The redistribution or network statements could match an IBGP route in the routing table and advertise it, even though the IGP does not know about the route. Therefore, when synchronization is enabled, IBGP routes are not entered into the routing table.

Example 3-30 shows what happens at Aspen when synchronization is enabled. The BGP table shows that the router has learned all the routes advertised by its IBGP peers, but the routing table shows that none of the routes have been entered. Although Aspen has no EBGP peers, forwarding is affected. If Telluride forwards a packet destined for 192.168.250.1, for example, Aspen does not have an entry for that destination in its routing table and will drop the packet.

Example 3-30 When Synchronization Is Enabled, IBGP-Learned Routes Are Not Entered into the Routing Table

 Aspen#  show ip bgp  BGP table version is 3, local router ID is 192.168.1.222 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path *> 192.168.1.196/30 0.0.0.0                  0         32768 i * i192.168.1.200/30 192.168.1.205            0    100      0 400 i * i192.168.1.204/30 192.168.1.197            0    100      0 i * i192.168.1.208/30 192.168.1.221            0    100      0 i * i192.168.1.212/30 192.168.1.210            0    100      0 300 i * i192.168.1.216/30 192.168.1.225            0    100      0 200 i *> 192.168.1.220/30 0.0.0.0                  0         32768 i * i192.168.1.224/30 192.168.1.221            0    100      0 i * i192.168.50.0     192.168.1.205            0    100      0 400 i * i192.168.75.0     192.168.1.205            0    100      0 400 i * i192.168.100.0    192.168.1.225            0    100      0 200 i * i192.168.200.0    192.168.1.225       409600    100      0 200 i * i192.168.250.0    192.168.1.210            0    100      0 300 i Aspen#  show ip route  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default        U - per-user static route, o - ODR        T - traffic engineered route Gateway of last resort is not set      192.168.1.0/30 is subnetted, 2 subnets C       192.168.1.196 is directly connected, Ethernet1 C       192.168.1.220 is directly connected, Ethernet0 Aspen# 

In Example 3-31, synchronization is disabled at Aspen, and the IBGP routes are entered into the routing table.

NOTE

If you turn off synchronization on a working BGP process, you must reset the BGP connections with the clear ip bgp * command before the changes will take effect. The use of this command is explained more completely in the section "Resetting BGP Connections."

Example 3-31 Aspen's IBGP Routes Are Entered into the Routing Table When Synchronization Is Disabled

 Aspen#  show ip route  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default        U - per-user static route, o - ODR        T - traffic engineered route Gateway of last resort is not set B    192.168.75.0/24 [200/0] via 192.168.1.205, 00:01:00 B    192.168.200.0/24 [200/409600] via 192.168.1.225, 00:01:00 B    192.168.250.0/24 [200/0] via 192.168.1.210, 00:01:00 B    192.168.50.0/24 [200/0] via 192.168.1.205, 00:01:00      192.168.1.0/30 is subnetted, 8 subnets B       192.168.1.224 [200/0] via 192.168.1.221, 00:01:50 B       192.168.1.200 [200/0] via 192.168.1.205, 00:01:00 B       192.168.1.204 [200/0] via 192.168.1.197, 00:01:52 C       192.168.1.196 is directly connected, Ethernet1 B       192.168.1.216 [200/0] via 192.168.1.225, 00:01:01 C       192.168.1.220 is directly connected, Ethernet0 B       192.168.1.208 [200/0] via 192.168.1.221, 00:01:50 B       192.168.1.212 [200/0] via 192.168.1.210, 00:01:01 B    192.168.100.0/24 [200/0] via 192.168.1.225, 00:01:02 Aspen# 

You can observe in Figure 3-5 and in the configurations for the routers in AS 100 that each of the three routers is peered with the other two routers. The reason for this is that a router does not pass routes learned from one IBGP peer to another IBGP peer. Vail, for instance, learns the addresses of AS 400 from its IBGP session with Telluride. If this session did not exist, Vail would not learn the routes from Aspen. Aspen also learns routes from Vail and Telluride over the respective IBGP connections to those peers. If Aspen did not learn the routes, it would not be able to forward packets between Telluride and Vail.

When an EBGP-learned route is advertised to an IBGP peer, the next-hop address of the route is unchanged. Observe in Aspen's BGP table in Example 3-30 that the next-hop address of all the routes to destinations in other autonomous systems is the interface address of the router that originated the EBGP route. For example, the next-hop address of the route to 192.168.200.0/24 is 192.168.1.225, Taos' interface. These next-hop addresses are entered into the routing table. As a result, all the IBGP routers must know how to reach the next-hop addresses. In the configurations for Figure 3-5, Vail and Telluride both have network statements for the subnet addresses of the links to their EBGP peers. These statements exist solely so that the IBGP peers know how to reach the next-hop addresses on those links.

Aspen also has network statements for its two data links. These exist so that Telluride knows how to reach the next-hop address 192.168.1.221 at Vail, and so that Vail knows how to reach the next-hop address 192.168.1.197 at Telluride. These addresses are also important for the formation of the IBGP peering session between Vail and Telluride. Although the logical connection is between these two routers, as shown in Figure 3-5, the TCP connection that the IBGP session uses passes through Aspen. If Vail and Telluride do not know how to find each other, the TCP connection cannot be established.

The location of these network statements is also important. If the statement network 192.168.1.220 mask 255.255.255.252 was at Vail rather than at Aspen, for example, the subnet would not be advertised past Aspen, and Telluride would not know how to reach next-hop address 192.168.1.221.

The rule that next-hop addresses of EBGP routes do not change when advertised to IBGP peers does not apply in the opposite direction. If a router advertises an IBGP-learned route to an EBGP peer, the next-hop address is the interface of the advertising router. This is true even if the route was originally an EBGP-learned route. Compare the next-hop addresses of the routes in Aspen's BGP table in Example 3-31 with the next-hop addresses of the routes in Alta's BGP table, shown in Example 3-32. Notice that Aspen shows the next-hop address for 192.168.250.0/24 as 192.168.1.210, at Tahoe. Yet Alta's next-hop address for the same route is 192.168.1.206, at Telluride. In fact, every EBGP-learned route at Alta has the same next-hop address.

Example 3-32 The Next-Hop Address for an EBGP-Learned Route Is Always the Address of the EBGP Peer That Advertised the Route

 Alta#  show ip bgp  BGP table version is 102, local router ID is 192.168.75.1 Status codes: s suppressed, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop          Metric LocPrf Weight Path *> 192.168.1.196/30 192.168.1.206                        0 100 i *> 192.168.1.200/30 0.0.0.0                0         32768 i *> 192.168.1.204/30 192.168.1.206          0             0 100 i *> 192.168.1.208/30 192.168.1.206                        0 100 i *> 192.168.1.212/30 192.168.1.206                        0 100 300 i *> 192.168.1.216/30 192.168.1.206                        0 100 200 i *> 192.168.1.220/30 192.168.1.206                        0 100 i *> 192.168.1.224/30 192.168.1.206                        0 100 i *> 192.168.50.0     0.0.0.0                0         32768 i *> 192.168.75.0     0.0.0.0                0         32768 i *> 192.168.100.0    192.168.1.206                        0 100 200 i *> 192.168.200.0    192.168.1.206                        0 100 200 i *> 192.168.250.0    192.168.1.206                        0 100 300 i Alta# 

You can override the rule that the next-hop address of an EBGP route does not change when advertised to an IBGP peer by using the neighbor next-hop-self command. Example 3-33 demonstrates the use of the neighbor next-hop-self command in the configurations for Vail and Telluride in AS 100.

Example 3-33 Forcing the Next-Hop Address of an EBGP Route to Change When Advertised to an IBGP Peer

  Vail   router bgp 100   no synchronization   neighbor 192.168.1.197 remote-as 100   neighbor 192.168.1.197 next-hop-self   neighbor 192.168.1.210 remote-as 300   neighbor 192.168.1.222 remote-as 100   neighbor 192.168.1.222 next-hop-self   neighbor 192.168.1.225 remote-as 200  _______________________________________________________________________  Telluride   router bgp 100   no synchronization   neighbor 192.168.1.198 remote-as 100   neighbor 192.168.1.198 next-hop-self   neighbor 192.168.1.205 remote-as 400   neighbor 192.168.1.221 remote-as 100   neighbor 192.168.1.221 next-hop-self  

Notice in Example 3-33 that at both routers, the network statements of the previous configurations have been removed. Because both routers now advertise their EBGP-learned routes with their own addresses as the next hop, the network statements are no longer needed. Example 3-34 shows Aspen's BGP table after the reconfiguration.

Example 3-34 Vail and Telluride Now Advertise Themselves As the Next Hops for the EBGP-Learned Routes They Send to Aspen

 Aspen#  show ip bgp  BGP table version is 35, local router ID is 192.168.1.222 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path *> 192.168.1.196/30 0.0.0.0                  0         32768 i *>i192.168.1.200/30 192.168.1.197            0    100      0 400 i *>i192.168.1.212/30 192.168.1.221            0    100      0 300 i *>i192.168.1.216/30 192.168.1.221            0    100      0 200 i *> 192.168.1.220/30 0.0.0.0                  0         32768 i *>i192.168.50.0     192.168.1.197            0    100      0 400 i *>i192.168.75.0     192.168.1.197            0    100      0 400 i *>i192.168.100.0    192.168.1.221            0    100      0 200 i *>i192.168.200.0    192.168.1.221       409600    100      0 200 i *>i192.168.250.0    192.168.1.221            0    100      0 300 i Aspen# 

This section serves to demonstrate several fundamental concepts about the behavior of IBGP. However, the approach taken to demonstrate those concepts is certainly not standard. Although you can find many discussions in the routing newsgroups about using IBGP in an AS without an IGP, in practice you rarely, if ever, find such an implementation. For example, this section shows a configuration in which a network statement is used so that internal routers know how to reach external next-hop addresses. "Real-life" IBGP implementations use either the next-hop-self function or run an IGP in passive mode on the external interfaces. A third option occasionally encountered is to redistribute connected interfaces into the IGP on AS border routers, but this can be a heavy-handed approach and is generally frowned upon.

More importantly, an IGP makes the TCP sessions over which IBGP rides, and therefore IBGP itself, more robust. The following section begins to expose you to more-realistic BGP configurations.

Case Study: IBGP Over an IGP

In Figure 3-6, the routers within AS 100 have been reconfigured. In this topology, OSPF is running as the autonomous system's IGP, and IBGP runs only between Vail and Telluride.

Figure 3-6. OSPF Is Added to the Routers in AS 100

Example 3-35 shows the configurations of the three routers in AS 100.

Example 3-35 Configurations for Vail, Aspen, and Telluride in AS 100

  Vail   router ospf 100   redistribute bgp 100 subnets   network 192.168.1.221 0.0.0.0 area 0   !   router bgp 100   neighbor 192.168.1.197 remote-as 100   neighbor 192.168.1.197 next-hop-self   neighbor 192.168.1.210 remote-as 300   neighbor 192.168.1.225 remote-as 200  _______________________________________________________________________  Aspen   router ospf 100   network 192.168.1.0 0.0.0.255 area 0  _______________________________________________________________________  Telluride   router ospf 100   redistribute bgp 100 subnets   network 192.168.1.197 0.0.0.0 area 0   !   router bgp 100   neighbor 192.168.1.205 remote-as 400   neighbor 192.168.1.221 remote-as 100   neighbor 192.168.1.221 next-hop-self  

In the BGP configurations, synchronization is enabled and EBGP routes are redistributed into OSPF. (Synchronization enabled is the default, so no command appears in the configuration.) These two configuration steps are integral to the correct operation of the IBGP link. The redistribution serves the same purpose as the IBGP links to Aspen in the preceding case study. If Aspen receives a packet originated in AS 400 and destined for AS 200, and it does not know the route, it drops the packet.

Synchronization serves as insurance that the redistribution works correctly. If the route to 192.168.100.0/24 is not redistributed into OSPF at Vail, for instance, it will not show up in Telluride's routing table. Telluride knows about the route from the IBGP connection, but because the route is not in its routing table, the router cannot advertise the route to Alta. No traffic to that destination is forwarded from AS 400 to AS 100. If there is an alternative path from AS 400 to AS 200 (not shown in Figure 3-6), that path can be used.

Example 3-36 shows Telluride's BGP table and routing table, and Example 3-37 shows Alta's routing table. Notice from Telluride's configuration that no routes are redistributed from OSPF into BGP, and no BGP network commands are used. All necessary routes are already in Telluride's BGP table, and these are the routes that are advertised to Alta. The routes in Telluride's routing table serve only to satisfy the requirements of synchronization.

Example 3-36 The BGP and Routing Tables of Telluride in Figure 3-6

 Telluride#  show ip bgp  BGP table version is 9, local router ID is 192.168.1.206 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path *> 192.168.1.200/30 192.168.1.205            0             0 400 i *>i192.168.1.212/30 192.168.1.221            0    100      0 300 i *>i192.168.1.216/30 192.168.1.221            0    100      0 200 i *> 192.168.50.0     192.168.1.205            0             0 400 i *> 192.168.75.0     192.168.1.205            0             0 400 i *>i192.168.100.0    192.168.1.221            0    100      0 200 i *>i192.168.200.0    192.168.1.221       409600    100      0 200 i *>i192.168.250.0    192.168.1.221            0    100      0 300 i Telluride#  show ip route  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default        U - per-user static route, o - ODR        T - traffic engineered route Gateway of last resort is not set B    192.168.75.0/24 [20/0] via 192.168.1.205, 15:16:37 O E2 192.168.200.0/24 [110/1] via 192.168.1.198, 15:15:38, Ethernet0 O E2 192.168.250.0/24 [110/1] via 192.168.1.198, 15:15:38, Ethernet0 B    192.168.50.0/24 [20/0] via 192.168.1.205, 15:16:38      192.168.1.0/30 is subnetted, 6 subnets B       192.168.1.200 [20/0] via 192.168.1.205, 15:16:38 C       192.168.1.204 is directly connected, Serial0 C       192.168.1.196 is directly connected, Ethernet0 O E2    192.168.1.216 [110/1] via 192.168.1.198, 15:15:38, Ethernet0 O       192.168.1.220 [110/20] via 192.168.1.198, 15:18:22, Ethernet0 O E2    192.168.1.212 [110/1] via 192.168.1.198, 15:15:38, Ethernet0 O E2 192.168.100.0/24 [110/1] via 192.168.1.198, 15:15:39, Ethernet0 Telluride# 

Example 3-37 Alta's Routing Table in Figure 3-6

 Alta#  show ip route  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default Gateway of last resort is not set B    192.168.100.0 [20/0] via 192.168.1.206, 15:34:05 C    192.168.75.0 is directly connected, Ethernet1 C    192.168.50.0 is directly connected, Loopback0      192.168.1.0 255.255.255.252 is subnetted, 4 subnets C       192.168.1.200 is directly connected, Ethernet2 C       192.168.1.204 is directly connected, Serial0 B       192.168.1.216 [20/0] via 192.168.1.206, 15:33:37 B       192.168.1.212 [20/0] via 192.168.1.206, 15:33:37 B    192.168.250.0 [20/0] via 192.168.1.206, 15:34:05 B    192.168.200.0 [20/0] via 192.168.1.206, 15:34:05 

The topology of Figure 3-6 contains a major vulnerability. If Aspen or one of its links fails, AS 400 is isolated from the rest of the internetwork. In Figure 3-7, a link is added between Vail and Telluride for redundancy, and a second IBGP session is established over the link.

Figure 3-7. A New Link and a Second IBGP Session Are Added Between Vail and Telluride for Redundancy

Example 3-38 shows the configurations of Vail and Telluride.

Example 3-38 Configurations for Vail and Telluride in AS 100

  Vail   router ospf 100   redistribute bgp 100 subnets   network 192.168.1.193 0.0.0.0 area 0   network 192.168.1.221 0.0.0.0 area 0   !   router bgp 100   neighbor 192.168.1.194 remote-as 100   neighbor 192.168.1.194 next-hop-self   neighbor 192.168.1.197 remote-as 100   neighbor 192.168.1.197 next-hop-self   neighbor 192.168.1.210 remote-as 300   neighbor 192.168.1.225 remote-as 200  _______________________________________________________________________  Telluride   router ospf 100   redistribute bgp 100 subnets   network 192.168.1.194 0.0.0.0 area 0   network 192.168.1.197 0.0.0.0 area 0   !   router bgp 100   neighbor 192.168.1.193 remote-as 100   neighbor 192.168.1.193 next-hop-self   neighbor 192.168.1.205 remote-as 400   neighbor 192.168.1.221 remote-as 100   neighbor 192.168.1.221 next-hop-self  

Example 3-39 shows the resulting BGP table at Telluride. All the routes learned from Vail indicate two next-hop addresses, representing the two IBGP connections. A > indicates the path currently being used. If the link fails, the other link is used.

Example 3-39 Telluride's Routing Table Shows Alternative Paths for the Routes from Vail

 Telluride#  show ip bgp  BGP table version is 17, local router ID is 192.168.255.253 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path *> 192.168.1.200/30 192.168.1.205            0             0 400 i *>i192.168.1.212/30 192.168.1.193            0    100      0 300 i * i                 192.168.1.221            0    100      0 300 i *>i192.168.1.216/30 192.168.1.193            0    100      0 200 i * i                 192.168.1.221            0    100      0 200 i *> 192.168.50.0     192.168.1.205            0             0 400 i *> 192.168.75.0     192.168.1.205            0             0 400 i *>i192.168.100.0    192.168.1.193            0    100      0 200 i * i                 192.168.1.221            0    100      0 200 i *>i192.168.200.0    192.168.1.193       409600    100      0 200 i * i                 192.168.1.221       409600    100      0 200 i *>i192.168.250.0    192.168.1.193            0    100      0 300 i * i                 192.168.1.221            0    100      0 300 i Telluride# 

Although the configuration illustrated in Figure 3-7 provides redundancy, the failover can be slow. By default, the BGP keepalive interval is 60 seconds and the hold time is 180 seconds, as shown in Example 3-40. Potentially, 180 seconds could pass before BGP detects a failed IBGP connection and switches to the other link. You can improve the failover time by resetting the BGP keepalive and hold times with the timers bgp command. For example, timers bgp 3 9 sets the keepalive interval to 3 seconds and the hold time to 9 seconds.

Example 3-40 The Default BGP Keepalive Time Is 60 Seconds, and the Default Hold Time Is 180 Seconds

 Telluride#  show ip bgp neighbor 192.168.1.193  BGP neighbor is 192.168.1.193,  remote AS 100, internal link  Index 2, Offset 0, Mask 0x4   NEXT_HOP is always this router   BGP version 4, remote router ID 192.168.255.254   BGP state = Established, table version = 14, up for 00:01:30  Last read 00:00:31, hold time is 180, keepalive interval is 60 seconds  Minimum time between advertisement runs is 5 seconds   Received 6 messages, 0 notifications, 0 in queue   Sent 5 messages, 0 notifications, 0 in queue   Prefix advertised 3, suppressed 0, withdrawn 0   Connections established 1; dropped 0   Last reset 00:02:51, due to User reset   3 accepted prefixes consume 96 bytes   0 history paths consume 0 bytes  --More-- 

Figure 3-8 shows a better way to add redundancy. Instead of creating two IBGP sessions over the alternative paths, a single IBGP session is created between the loopback interfaces of the routers. OSPF takes care of finding the best path for the IBGP session and reroutes the session much faster if a link fails.

Figure 3-8. A Single IBGP Session Is Established Between Vail's and Telluride's Loopback Interfaces

Example 3-41 shows the configurations of Vail and Telluride for the setup in Figure 3-8.

Example 3-41 Configuring a Single IBGP Session Between the Loopback Interfaces of Vail and Telluride

  Vail   interface Loopback0   ip address 192.168.255.254 255.255.255.255   !   router ospf 100   redistribute bgp 100 subnets   network 192.168.1.193 0.0.0.0 area 0   network 192.168.1.221 0.0.0.0 area 0   network 192.168.255.254 0.0.0.0 area 0   !   router bgp 100   neighbor 192.168.1.210 remote-as 300   neighbor 192.168.1.225 remote-as 200   neighbor 192.168.255.253 remote-as 100   neighbor 192.168.255.253 update-source Loopback0   neighbor 192.168.255.253 next-hop-self  _______________________________________________________________________  Telluride   interface Loopback0   ip address 192.168.255.253 255.255.255.255   !   router ospf 100   redistribute bgp 100 subnets   network 192.168.1.194 0.0.0.0 area 0   network 192.168.1.197 0.0.0.0 area 0   network 192.168.255.253 0.0.0.0 area 0   !   router bgp 100   neighbor 192.168.1.205 remote-as 400   neighbor 192.168.255.254 remote-as 100   neighbor 192.168.255.254 update-source Loopback0   neighbor 192.168.255.254 next-hop-self  

The significant difference in these configurations, beyond the obvious creation of loopback addresses, is the neighbor update-source statement. This command causes the BGP messages to be sourced from the IP address of the loopback interface rather than from the physical interface the message is sent on. Without it, the TCP source of the TCP sessions would be the outgoing interface address. The end points of the TCP sessions would not match and would therefore not come up. Also important is the additional network statement under OSPF, advertising the loopback address. Without it, the address is unreachable, and the IBGP session is not created. Example 3-42 shows Telluride's BGP table after the reconfiguration.

Example 3-42 The Next-Hop Address of the Routes from Vail Is Vail's Loopback Address

 Telluride#  show ip bgp  BGP table version is 7, local router ID is 192.168.255.253 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path *> 192.168.1.200/30 192.168.1.205            0             0 400 i *>i192.168.1.212/30 192.168.255.254          0    100      0 300 i *>i192.168.1.216/30 192.168.255.254          0    100      0 200 i *> 192.168.50.0     192.168.1.205            0             0 400 i *> 192.168.75.0     192.168.1.205            0             0 400 i *>i192.168.100.0    192.168.255.254          0    100      0 200 i *>i192.168.200.0    192.168.255.254     409600    100      0 200 i *>i192.168.250.0    192.168.255.254          0    100      0 300 i Telluride# 

CAUTION

The examples in this section use BGP-to-IGP redistribution to better demonstrate basic IBGP behavior. However, it is worth noting one more time that if you are receiving a large number of routes from an external BGP peer, redistribution into your IGP can be very dangerous. In a topology such as the one in Figure 3-8, the safe approach is to configure a full IBGP mesh ”IBGP sessions between the loopback interfaces of all three routers in AS 100. Aspen then learns the necessary information for packet forwarding directly from BGP, and no redistribution is necessary.

Case Study: EBGP Multihop

Just as you can establish an IBGP session between loopback interfaces, as demonstrated in the preceding case study, you also can establish EBGP sessions between loopback interfaces. Figure 3-9 shows such a session. Here, the end points of the EBGP session between Telluride and Alta are loopback interfaces.

Figure 3-9. An EBGP Session Is Established Between Telluride's and Alta's Loopback Interfaces

Example 3-43 shows the preliminary configuration of the two routers in Figure 3-9.

Example 3-43 Configuring an EBGP Session Between the Loopback Interfaces for Telluride and Alta

  Telluride   router bgp 100   network 192.168.1.204 mask 255.255.255.252   neighbor 192.168.255.251 remote-as 400   neighbor 192.168.255.251 update-source Loopback0   neighbor 192.168.255.254 remote-as 100   neighbor 192.168.255.254 update-source Loopback0   neighbor 192.168.255.254 next-hop-self   !   ip route 192.168.255.251 255.255.255.255 192.168.1.205  _______________________________________________________________________  Alta   router bgp 400   network 192.168.50.0   network 192.168.75.0   network 192.168.1.200 mask 255.255.255.252   neighbor 192.168.255.253 remote-as 100   neighbor 192.168.255.253 update-source Loopback3   no auto-summary   !   ip route 192.168.255.253 255.255.255.255 192.168.1.206  

Notice that static routes have been added to each router. These routes are necessary so that each router knows how to find the address of its neighbor's loopback interface to begin the TCP session. In the preceding case study, adding a network statement under OSPF performed the same function. In this scenario, no IGP runs between the routers, so static routes are used. When troubleshooting IBGP, keep in mind that the IBGP routers must know how to find their peers before an IBGP session can be established and BGP routes can be exchanged. If two IBGP neighbors are not peering, one of the first things you should check is whether the routers know how to reach each other.

Unfortunately, the neighbors do not peer with the configurations shown. Example 3-44 offers a hint about the problem. The highlighted line indicates that the neighbors are not directly connected. You already know this; the addresses of the loopback interfaces are indeed not directly connected, which is why the static routes are required. However, the fact that BGP points this out is significant.

Example 3-44 show ip bgp neighbors Output Shows That the EBGP Connection to Alta Is Not Established

 Telluride#  show ip bgp neighbor 192.168.255.251  BGP neighbor is 192.168.255.251,  remote AS 400, external link  Index 1, Offset 0, Mask 0x2   BGP version 4, remote router ID 0.0.0.0   BGP state = Idle, table version = 0   Last read 00:00:11, hold time is 180, keepalive interval is 60 seconds   Minimum time between advertisement runs is 30 seconds   Received 0 messages, 0 notifications, 0 in queue   Sent 0 messages, 0 notifications, 0 in queue   Prefix advertised 0, suppressed 0, withdrawn 0   Connections established 0; dropped 0   Last reset never   0 accepted prefixes consume 0 bytes   0 history paths consume 0 bytes  External BGP neighbor not directly connected.  No active TCP connection Telluride 

The significance is that although you can create IBGP across multiple router hops, EBGP neighbors by default must be directly connected. In Figure 3-9, the packets sourced from Alta's loopback interface must be routed to its serial interface. At Telluride, the packet must be routed from its serial interface to its loopback interface. In other words, the TCP packets must cross two router hops between the loopback interfaces.

The neighbor ebgp-multihop command enables you to override the default one-hop EBGP limit by changing the TTL of EBGP packets from the default value of 1. Example 3-45 shows the neighbor configurations using the neighbor ebgp-multihop command to change the TTL of the EBGP packets to 2.

Example 3-45 Using the neighbor ebgp-multihop Command Overrides the Default One-Hop EBGP Limit for Alta and Telluride

  Telluride   router bgp 100   network 192.168.1.204 mask 255.255.255.252   neighbor 192.168.255.251 remote-as 400   neighbor 192.168.255.251 ebgp-multihop 2   neighbor 192.168.255.251 update-source Loopback0   neighbor 192.168.255.254 remote-as 100   neighbor 192.168.255.254 update-source Loopback0   neighbor 192.168.255.254 next-hop-self   !   ip route 192.168.255.251 255.255.255.255 192.168.1.205  _______________________________________________________________________  Alta   router bgp 400   network 192.168.50.0   network 192.168.75.0   network 192.168.1.200 mask 255.255.255.252   neighbor 192.168.255.253 remote-as 100   neighbor 192.168.255.253 ebgp-multihop 2   neighbor 192.168.255.253 update-source Loopback3   no auto-summary   !   ip route 192.168.255.253 255.255.255.255 192.168.1.206  

Example 3-46 shows the result of the configuration change. The EBGP session is established, and the output indicates the new hop limit.

Example 3-46 show ip bgp neighbors Output Shows That the EBGP Connection to Alta Is Established

 Telluride#  show ip bgp neighbor 192.168.255.251  BGP neighbor is 192.168.255.251,  remote AS 400, external link  Index 1, Offset 0, Mask 0x2   BGP version 4, remote router ID 192.168.255.251   BGP state = Established, table version = 9, up for 00:04:44   Last read 00:00:14, hold time is 180, keepalive interval is 60 seconds   Minimum time between advertisement runs is 30 seconds   Received 9 messages, 0 notifications, 0 in queue   Sent 11 messages, 0 notifications, 0 in queue   Prefix advertised 4, suppressed 0, withdrawn 0   Connections established 1; dropped 0   Last reset 00:25:59, due to User reset   3 accepted prefixes consume 96 bytes   0 history paths consume 0 bytes  External BGP neighbor may be up to 2 hops away  Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Local host: 192.168.255.253, Local port: 11001 Foreign host: 192.168.255.251, Foreign port: 179 

Unlike IBGP, which is normally configured between loopback interfaces, the majority of EBGP sessions are configured between directly connected interfaces. Therefore, ebgp-multihop is not frequently required. An example of where EBGP between loopback interfaces can be useful is when two external neighbors are directly connected with multiple links (such as multiple ATM or Frame Relay virtual circuits) for redundancy, but only a single EBGP session is desired. If the link being used by EBGP fails, the session can be rerouted over an alternative link.

Case Study: Aggregate Routes

Autonomous system 100 in Figure 3-10 contains eight Class C network addresses, all of which can be summarized with the aggregate address 192.168.192.0/21. Stowe is learning the internal networks via EIGRP and is advertising the aggregate to Sugarbush via EBGP.

Figure 3-10. All the Internal Networks of AS 100 Can Be Aggregated into the Single Address 192.168.192.0/21

There are two ways to create an aggregate address under BGP. The first is to create a static entry in the routing table for the aggregate address and then advertise it with the network command. The second way is to use the aggregate-address command.

Aggregation Using Static Routes

Example 3-47 demonstrates a configuration for Stowe using a static entry aggregate address advertised with the network command.

Example 3-47 Creating an Aggregate Address Under BGP Using a Static Entry Advertised with the network Command

  router eigrp 100   network 192.168.199.0   !   router bgp 100   network 192.168.192.0 mask 255.255.248.0   neighbor 192.168.1.253 remote-as 200   !   ip classless   ip route 192.168.192.0 255.255.248.0 Null0  

The static route is pointed at the Null interface because the aggregate itself is not a legitimate end destination. It merely represents the more-specific routes in Stowe's routing table. Packets whose destination addresses belong to one of AS 100's Class C addresses match the aggregate address in routers external to AS 100 and are forwarded to Stowe. At that router, the packet is matched to the more-specific address and forwarded to the correct internal next-hop router. If for some reason the more-specific Class C address is not in Stowe's routing table, the packet is forwarded to the Null interface and dropped.

Example 3-48 shows the BGP tables of Stowe and Sugarbush. Only the aggregate address exists in Stowe's BGP table; that router's BGP configuration has not entered any other address.

Example 3-48 The BGP Tables of Stowe and Sugarbush Both Contain Only the Aggregate Route

 Stowe#  show ip bgp  BGP table version is 2, local router ID is 192.168.199.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path *> 192.168.192.0/21 0.0.0.0                  0         32768 i Stowe# _______________________________________________________________________ Sugarbush#  show ip bgp  BGP table version is 18, local router ID is 172.17.3.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop          Metric LocPrf Weight Path *> 192.168.192.0/21 192.168.1.254          0             0 100 i Sugarbush# 

Suppressing More-Specific Routes

In a simple topology such as the one in Figure 3-10, this first method normally suffices. As the topology and the routing policies grow more complex, however, the options available with the aggregate-address command make that method more useful. The remainder of this case study examines the aggregate-address command and its options.

For the aggregate specified by the aggregate-address command to be advertised, at least one of the more-specific addresses belonging to the aggregate must be entered into the BGP table either through redistribution or the network command. Example 3-49 demonstrates a configuration for Stowe using the aggregate-address command and redistribution.

Example 3-49 Creating an Aggregate Address Under BGP Using the aggregate-address Command

  router eigrp 100   network 192.168.199.0   !   router bgp 100   aggregate-address 192.168.192.0 255.255.248.0 summary-only   redistribute eigrp 100   neighbor 192.168.1.253 remote-as 200  

Example 3-50 shows the resulting BGP tables at Stowe and Sugarbush. Stowe's table looks quite different than it did in Example 3-48 ”all the more-specific routes are included. However, Sugarbush's table looks the same. Only the aggregate address is advertised.

Example 3-50 Stowe's BGP Table Includes All the More-Specific Routes; Only the Aggregate Is Advertised to Sugarbush

 Stowe#  show ip bgp  BGP table version is 23, local router ID is 192.168.199.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path s> 192.168.192.0    192.168.199.1      2297856         32768 ? *> 192.168.192.0/21 0.0.0.0                            32768 i s> 192.168.193.0    192.168.199.1      2297856         32768 ? s> 192.168.194.0    192.168.199.1      2297856         32768 ? s> 192.168.195.0    192.168.199.1      2297856         32768 ? s> 192.168.196.0    192.168.199.1      2297856         32768 ? s> 192.168.197.0    192.168.199.1      2297856         32768 ? s> 192.168.198.0    192.168.199.1      2297856         32768 ? s> 192.168.199.0    0.0.0.0                  0         32768 ? Stowe# _______________________________________________________________________ Sugarbush#  show ip bgp  BGP table version is 2, local router ID is 172.17.3.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop          Metric LocPrf Weight Path *> 192.168.192.0/21 192.168.1.254                        0 100 i Sugarbush# 

The keys to the left of the more-specific routes in Stowe's BGP table indicate that the routes have been suppressed. This suppression results from the summary-only option used with the aggregate-address command. Without that option, both the aggregate and the more-specific routes are advertised.

Advertising Aggregate and More-Specific Routes

Advertising both the aggregate and the more-specific routes makes no sense in the simple topology of Figure 3-10. But Figure 3-11 shows a scenario in which such a scheme can be desirable. Here, AS 100 is multihomed to AS 200. AS 200 needs the full routes from AS 100 to set routing policy, but it must send only the aggregate to AS 300.

Figure 3-11. AS 100 Is Multihomed to AS 200

Although the more-specific routes of AS 100 are advertised, they are sent to AS 200 with a COMMUNITY attribute of NO_EXPORT. As Chapter 2 discusses, routes carrying this attribute cannot be advertised to EBGP peers. As a result, AS 200 knows the routes but does not advertise them to AS 300. Only the aggregate, which does not carry the COMMUNITY NO_EXPORT attribute, is advertised to AS 300. Example 3-51 shows the configuration for Stowe. The configuration for Mammoth is similar and appears later in this section.

Example 3-51 Configuring Stowe to Advertise Both the Aggregate and the More-Specific Routes

  router eigrp 100   network 192.168.199.0   !   router bgp 100   aggregate-address 192.168.192.0 255.255.248.0   redistribute eigrp 100   neighbor 192.168.1.253 remote-as 200   neighbor 192.168.1.253 send-community   neighbor 192.168.1.253 route-map COMMUNITY out   !   ip classless   !   access-list 101 permit ip host 192.168.192.0 host 255.255.248.0   !   route-map COMMUNITY permit 10   match ip address 101   set community none   !   route-map COMMUNITY permit 20   set community no-export  

The summary-only keyword has been removed from the aggregate-address command, so both the aggregate and the more-specific routes are advertised to AS 200. The neighbor 192.168.1.253 send-community command specifies that the COMMUNITY attribute is sent to Sugarbush. The neighbor 192.168.1.253 route-map COMMUNITY out command filters outgoing BGP routes through a route map named COMMUNITY. If the route map matches the update to access list 101, no COMMUNITY attribute is set. If the route does not match access list 101, the route is given a COMMUNITY attribute of NO_EXPORT.

The usage of access list 101 might be new to you. Normally, the first address specified in an extended IP access list is the source address, and the second address is the destination. In this application, however, the first address is the route prefix, and the second address is the prefix's mask. The reason such an odd access list is necessary is because the exact prefix must be identified. If access-list 1 permit 192.168.192.0 0.0.7.255 were used, it would match both the aggregate 192.168.192.0/21 and the more-specific route 192.168.192.0/24.

Example 3-52 shows Sugarbush's BGP table, and you can see that it contains both the aggregate route and the more-specific routes. Additionally, the command show ip bgp community no-export is used to display the routes with the NO_EXPORT COMMUNITY attribute. All routes from Stowe except for the aggregate are listed.

Example 3-52 Sugarbush's BGP Table Contains Both the Aggregate Route and the More-Specific Routes; All the Routes from Stowe Except for the Aggregate Have the NO_EXPORT COMMUNITY Attribute

 Sugarbush#  show ip bgp  BGP table version is 30, local router ID is 172.17.3.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop          Metric LocPrf Weight Path * i192.168.192.0    192.168.1.237    2297856    100      0 100 ? *>                  192.168.1.254    2297856             0 100 ? * i192.168.192.0/21 192.168.1.237               100      0 100 i *>                  192.168.1.254                        0 100 i * i192.168.193.0    192.168.1.237    2297856    100      0 100 ? *>                  192.168.1.254    2297856             0 100 ? * i192.168.194.0    192.168.1.237    2297856    100      0 100 ? *>                  192.168.1.254    2297856             0 100 ? * i192.168.195.0    192.168.1.237    2297856    100      0 100 ? *>                  192.168.1.254    2297856             0 100 ? * i192.168.196.0    192.168.1.237    2297856    100      0 100 ? *>                  192.168.1.254    2297856             0 100 ? * i192.168.197.0    192.168.1.237    2297856    100      0 100 ? *>                  192.168.1.254    2297856             0 100 ? *>i192.168.198.0    192.168.1.237          0    100      0 100 ? *                   192.168.1.254    2681856             0 100 ? * i192.168.199.0    192.168.1.237    2681856    100      0 100 ? *>                  192.168.1.254          0             0 100 ? Sugarbush#  show ip bgp community no-export  BGP table version is 10, local router ID is 172.17.3.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop          Metric LocPrf Weight Path *> 192.168.192.0    192.168.1.254    2297856             0 100 ? *> 192.168.193.0    192.168.1.254    2297856             0 100 ? *> 192.168.194.0    192.168.1.254    2297856             0 100 ? *> 192.168.195.0    192.168.1.254    2297856             0 100 ? *> 192.168.196.0    192.168.1.254    2297856             0 100 ? *> 192.168.197.0    192.168.1.254    2297856             0 100 ? *  192.168.198.0    192.168.1.254    2681856             0 100 ? *> 192.168.199.0    192.168.1.254          0             0 100 ? Sugarbush# 

Example 3-53 shows Burke's BGP table. No routes except the aggregate have been advertised.

Example 3-53 Burke's BGP Table Contains Only the Aggregate Route

 Burke#  show ip bgp  BGP table version is 15, local router ID is 172.21.1.1 Status codes: s suppressed, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop          Metric LocPrf Weight Path *> 192.168.192.0/21 192.168.1.249                        0 200 100 i *                   192.168.1.241                        0 200 100 i Burke# 

Mammoth produces the same advertisements as Stowe. For demonstration purposes, a different configuration (Example 3-54) is used to arrive at the same results. At Mammoth, an IP prefix list is used rather than an access list.

Example 3-54 Configuration for Mammoth in Figure 3-11

  router eigrp 100   network 192.168.198.0   !   router bgp 100   aggregate-address 192.168.192.0 255.255.248.0   redistribute eigrp 100   neighbor 192.168.1.246 remote-as 200   neighbor 192.168.1.246 send-community   neighbor 192.168.1.246 route-map COMMUNITY out   !   ip classless   ip route 192.168.255.251 255.255.255.255 192.168.1.205   !   !   ip prefix-list AGGREGATE seq 5 permit 192.168.192.0/21   !   route-map COMMUNITY permit 10   match ip address prefix-list AGGREGATE   set community none   !   route-map COMMUNITY permit 20   set community no-export  

Like route maps, prefix lists are identified by a name rather than by a number. In Example 3-54, the prefix list is named AGGREGATE. The lines of the list are distinguished by a sequence number ( seq ) that identifies each line's place in a multiple-line list and makes editing the list easier. If you do not type a sequence number when you enter a line, Cisco IOS Software enters it automatically, in the order that you enter the lines. Following the permit deny keyword, a prefix and the prefix length are specified.

The prefix list shown in Mammoth's configuration in Example 3-54 matches 192.168.192.0/21 exactly. However, you can also add an option that matches a range of prefixes. For example, the command ip prefix-list AGGREGATE seq 5 permit 192.168.192.0/21 ge 24 matches all prefixes whose first 21 bits match 192.168.192.0 and whose length is greater than or equal to 24 bits. This line would match all the more-specific routes in AS 100. A keyword of le, on the other hand, is used to match prefixes whose lengths are less than or equal to the specified number of bits.

The BGP table at Diamond looks very similar to the one at Sugarbush; the more-specific routes and the aggregate are entered. In addition to the aggregate from Sugarbush, Burke's BGP table in Example 3-53 shows that the aggregate is also advertised by Diamond. Example 3-55 shows the aggregate and one of the more-specific routes from Diamond's BGP table in greater detail. You can see that the aggregate does not have any COMMUNITY attributes (although it does, as an aggregate, have the ATOMIC_AGGREGATE and AGGREGATOR attributes set), and the more-specific route does.

Example 3-55 A Closer Look at Two of the Routes from Diamond's BGP Table Shows the Attributes of Each

 Diamond#  show ip bgp 192.168.192.0 255.255.248.0  BGP routing table entry for 192.168.192.0/21, version 59 Paths: (2 available, best #1)   Advertised to non peer-group peers:     192.168.1.238 192.168.1.242   100, (aggregated by 100 192.168.198.2)     192.168.1.245 from 192.168.1.245 (192.168.198.2)       Origin IGP, localpref 100, valid, external, atomic-aggregate, best, ref 2  100, (aggregated by 100 192.168.199.2)  192.168.1.238 from 192.168.1.238 (192.168.1.253)  Origin IGP, localpref 100, valid, internal, not synchronized, atomic-aggregate,   ref 2  Diamond# Diamond#  show ip bgp 192.168.199.0  BGP routing table entry for 192.168.199.0/24, version 58 Paths: (2 available, best #1, not advertised to EBGP peer)   Advertised to non peer-group peers:     192.168.1.238   100     192.168.1.245 from 192.168.1.245 (192.168.198.2)       Origin incomplete, metric 2681856, localpref 100, valid, external, best, ref 2  Community: no-export  100     192.168.1.238 from 192.168.1.238 (192.168.1.253)       Origin incomplete, metric 0, localpref 100, valid, internal, not synchronized, ref 2 Diamond# 

Advertising Aggregate and Selected More-Specifics

The previous scenarios send the more-specific routes of AS 100 to AS 200 so that AS 200 can implement routing policy. That is, AS 200 uses the routes to set routing preferences for sending traffic to AS 100. AS 100 also can influence its incoming traffic by manipulating its outgoing advertisements. For example, advertising 192.168.193.0/24 over the Stowe/Sugarbush link and not over the Mammoth/Diamond link causes incoming traffic to use the Stowe/Sugarbush link. An administrator might want to implement such a policy if the AS is geographically diverse. For instance, Stowe might be in Vermont and Mammoth in California. The administrator might want incoming traffic to use the ingress point closest to the destination, to minimize internal routing.

For this demonstration, the following routing policies are implemented in AS 100 of Figure 3-11:

• 192.168.192.0/24, 192.168.193.0/24, and 192.168.194.0/24 are advertised over the Stowe/Sugarbush link.

• 192.168.196.0/24, 192.168.197.0/24, and 192.168.198.0/24 are advertised over the Mammoth/Diamond link.

• 192.168.195.0/24 and 192.168.199.0/24 are not advertised at all.

• An aggregate route is advertised over both links for backup so that if either link fails, all incoming traffic is routed to the remaining link.

To suppress a subset of the aggregated routes, the suppress-map option is used with the aggregate-address command. The listed policies are implemented at Stowe and Mammoth with the configurations in Example 3-56. The COMMUNITY route maps and the EIGRP configurations do not change from the preceding section and so are not shown for simplicity.

Example 3-56 Suppressing Selected Prefixes with the suppress-map Option of the aggregate-address Command

  Stowe   router bgp 100   aggregate-address 192.168.192.0 255.255.248.0 suppress-map VERMONT   redistribute eigrp 100   neighbor 192.168.1.253 remote-as 200   neighbor 192.168.1.253 send-community   neighbor 192.168.1.253 route-map COMMUNITY out   !   access-list 1 permit 192.168.195.0 0.0.0.255   access-list 1 permit 192.168.196.0 0.0.3.255   !   route-map VERMONT permit 10   match ip address 1  _______________________________________________________________________  Mammoth   router bgp 100   aggregate-address 192.168.192.0 255.255.248.0 suppress-map CALIFORNIA   redistribute eigrp 100   neighbor 192.168.1.246 remote-as 200   neighbor 192.168.1.246 send-community   neighbor 192.168.1.246 route-map COMMUNITY out   !   ip prefix-list SUPPRESSEDROUTES seq 5 permit 192.168.192.0/22 le 24   ip prefix-list SUPPRESSEDROUTES seq 10 permit 192.168.199.0/24   !   route-map CALIFORNIA permit 10   match ip address prefix-list SUPPRESSEDROUTES  

Stowe's configuration uses a route map named VERMONT to determine the routes to be suppressed. The route map in turn uses access list 1 to identify the appropriate routes. The access list permits the prefix 192.168.195.0/24 and also all prefixes whose first 22 bits match 192.168.196.0/22. All other prefixes match the implicit "deny any" at the end of the access list and so are not suppressed.

NOTE

The logic of route maps sometimes seems a bit tortured. In this case, a route that is denied by the access list is " denied from being suppressed"; that is, the route is permitted to be advertised. Routes that are permitted by the access list, on the other hand, are "permitted to be suppressed" and so are not advertised.

Mammoth's configuration uses a route map named CALIFORNIA to determine the routes to be suppressed. Mammoth again uses a prefix list rather than an access list to identify the appropriate routes. Sequence 5 of the prefix list permits all prefixes whose first 22 bits match 192.168.192.0/22 and whose length is less than or equal to 24. Sequence 10 of the prefix list permits the prefix 192.168.199.0/24. Advertisements of routes with these permitted prefixes are suppressed; all other routes are implicitly denied by the prefix list and so are not suppressed.

Example 3-57 shows the resulting BGP tables at Sugarbush and Diamond. Sugarbush forwards packets destined for 192.168.193.0/24 to Stowe (192.168.1.254), for example, whereas packets destined for 192.168.196.0/24 are forwarded to Diamond (192.168.1.237). Diamond, in turn, routes the packets destined for 192.168.196.0/24 to Mammoth (192.168.1.245). Both Stowe and Mammoth are advertising the aggregate; if the link to either router fails, the packets that normally would be forwarded across that link will match the aggregate from the remaining link.

Example 3-57 These BGP Tables Show That Stowe and Mammoth Have Advertised Different Subsets of the More-Specific Routes in AS 100, Whereas Both Still Advertise the Aggregate

 Sugarbush#  show ip bgp  BGP table version is 79, local router ID is 192.168.1.253 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop          Metric LocPrf Weight Path *> 192.168.192.0    192.168.1.254    2297856             0 100 ? * i192.168.192.0/21 192.168.1.237               100      0 100 i *>                  192.168.1.254                        0 100 i *> 192.168.193.0    192.168.1.254    2297856             0 100 ? *> 192.168.194.0    192.168.1.254    2297856             0 100 ? *>i192.168.196.0    192.168.1.237    2297856    100      0 100 ? *>i192.168.197.0    192.168.1.237    2297856    100      0 100 ? *>i192.168.198.0    192.168.1.237          0    100      0 100 ? Sugarbush# _______________________________________________________________________ Diamond#  show ip bgp  BGP table version is 137, local router ID is 172.18.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path * i192.168.192.0    192.168.1.238      2297856    100      0 100 ? *> 192.168.192.0/21 192.168.1.245                          0 100 i * i                 192.168.1.238                 100      0 100 i * i192.168.193.0    192.168.1.238      2297856    100      0 100 ? * i192.168.194.0    192.168.1.238      2297856    100      0 100 ? *> 192.168.196.0    192.168.1.245      2297856             0 100 ? *> 192.168.197.0    192.168.1.245      2297856             0 100 ? *> 192.168.198.0    192.168.1.245            0             0 100 ? Diamond# 

Changing the Attributes of the Aggregate

Yet another option that you can use with the aggregate-address command is the attribute-map option. This option enables you to change the attributes of the aggregate route. Notice in Example 3-57, for instance, that all the more-specific routes have an ORIGIN attribute of Incomplete, because the routes are redistributed into BGP from EIGRP. The aggregates have an origin of IGP, however, because they originated within the BGP processes of Stowe and Mammoth. Suppose the administrator wants AS 200 to use the Mammoth/Diamond link for all traffic following the aggregate route and to use the Stowe/Sugarbush link only for backup. The BGP decision process, as discussed in Chapter 2, chooses an ORIGIN of IGP over an ORIGIN of Incomplete when considering two routes to the same destination. If Stowe changes the ORIGIN of its aggregate to Incomplete, the routers in AS 200 will prefer the Mammoth/Diamond link. Example 3-58 shows the configuration for Stowe.

Example 3-58 Stowe Changes Its Aggregate ORIGIN to Incomplete

  router eigrp 100   network 192.168.199.0   !   router bgp 100    aggregate-address 192.168.192.0 255.255.248.0 attribute-map ORIGIN suppress-map     VERMONT    redistribute eigrp 100   neighbor 192.168.1.253 remote-as 200   neighbor 192.168.1.253 send-community   neighbor 192.168.1.253 route-map COMMUNITY out   !   access-list 1 permit 192.168.195.0 0.0.0.255   !   access-list 101 permit ip host 192.168.192.0 host 255.255.248.0   !    route-map ORIGIN permit 10     set origin incomplete    !   route-map COMMUNITY permit 10   match ip address 101   set community none   !   route-map COMMUNITY permit 20   set community no-export   !   route-map VERMONT permit 10   match ip address 1  

Example 3-59 shows the resulting BGP table at Sugarbush. Before the reconfiguration, Sugarbush preferred the aggregate learned via EBGP over the aggregate learned via IBGP (see Example 3-57). However, the ORIGIN attribute has a higher priority in the decision process than IBGP/EBGP, so the IBGP route from Diamond, with an ORIGIN of IGP, is now preferred.

Example 3-59 The Aggregate Advertised by Stowe (192.168.1.254) Now Has an ORIGIN of Incomplete; the Aggregate Advertised by Diamond and Originated by Mammoth Is the Preferred Route

 Sugarbush#  show ip bgp  BGP table version is 17, local router ID is 192.168.1.253 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop          Metric LocPrf Weight Path *> 192.168.192.0    192.168.1.254    2297856             0 100 ? *>i192.168.192.0/21 192.168.1.237               100      0 100 i *                   192.168.1.254                        0 100 ? *> 192.168.193.0    192.168.1.254    2297856             0 100 ? *> 192.168.194.0    192.168.1.254    2297856             0 100 ? *>i192.168.196.0    192.168.1.237    2297856    100      0 100 ? *>i192.168.197.0    192.168.1.237    2297856    100      0 100 ? *>i192.168.198.0    192.168.1.237          0    100      0 100 ? Sugarbush# 

Interestingly, the reconfiguration also affects the routing in AS 300, as demonstrated in Example 3-60. The preferred route at Sugarbush is the IBGP route; synchronization is enabled, so the IBGP route is not advertised to EBGP peer Burke. As a result, Burke learns the aggregate only from Diamond.

Example 3-60 Only Diamond Advertises the Aggregate to Burke

 Burke#  show ip bgp  BGP table version is 3, local router ID is 172.21.1.1 Status codes: s suppressed, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop          Metric LocPrf Weight Path *> 192.168.192.0/21 192.168.1.241                        0 200 100 i Burke# 

Using AS_SET with Aggregates

Figure 3-12 shows a modified version of the internetwork shown in Figure 3-11, including a change in the source of the aggregate address. Here, both AS 100 and AS 200 advertise the full routes of AS 100 to AS 300 and AS 400, without an aggregate.

Figure 3-12. Burke Is Creating an Aggregate and Advertising It to Sun

Router Burke, in AS 300, suppresses the more-specific addresses of AS 100 and sends an aggregate to Sun in AS 400. Burke's configuration in Example 3-61 is similar to configurations you have encountered already in this case study.

Example 3-61 Burke Is Configured to Suppress Specific Addresses of AS 100 and Send an Aggregate to Sun in AS 400

  router bgp 300   aggregate-address 192.168.192.0 255.255.248.0 summary-only   neighbor 192.168.1.234 remote-as 400   neighbor 192.168.1.234 next-hop-self   neighbor 192.168.1.249 remote-as 200   neighbor 192.168.1.249 distribute-list 1 out   !   access-list 1 deny   192.168.192.0   access-list 1 permit any  

One difference between the Burke configuration in Example 3-61 and the previous configurations is the neighbor distribute-list command. This command implements a route filter and operates in the same way as distribute-list commands discussed in TCP/IP Routing, Volume I . In this case, the filter prevents the aggregate from being advertised back to Sugarbush.

Example 3-62 shows the BGP table at Sun. As expected, the table includes the more-specific routes from Sugarbush and the aggregate route from Burke. Of interest in this case study is the AS_PATH associated with the aggregate. The AS_SEQUENCE of the AS_PATH attribute of an aggregate begins with the AS in which the aggregate was originated. Burke originated the aggregate, so the AS_SEQUENCE includes only AS 300. The aggregate actually points to destinations in AS 100; like any summarization, the aggregate has caused a loss of routing information.

Example 3-62 The AS_PATH of the Aggregate from Burke Includes Only AS 300, the AS in Which the Aggregate Was Originated

 Sun#  show ip bgp  BGP table version is 20, local router ID is 192.168.1.234 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path *> 192.168.192.0    192.168.1.229                          0 200 100 ?  *> 192.168.192.0/21 192.168.1.233                          0 300 i  *> 192.168.193.0    192.168.1.229                          0 200 100 ? *> 192.168.194.0    192.168.1.229                          0 200 100 ? *> 192.168.195.0    192.168.1.229                          0 200 100 ? *> 192.168.196.0    192.168.1.229                          0 200 100 ? *> 192.168.197.0    192.168.1.229                          0 200 100 ? *> 192.168.198.0    192.168.1.229                          0 200 100 ? *> 192.168.199.0    192.168.1.229                          0 200 100 ? Sun# 

In Example 3-63, Burke sets the ATOMIC_AGGREGATE and AGGREGATOR attributes in the aggregate to indicate that a loss of information has occurred.

Example 3-63 The Aggregate from Burke Has the ATOMIC_AGGREGATE and AGGREGATOR (aggregated by 300 192.168.1.250) Attributes Set to Indicate a Loss of Path Information

 Sun#  show ip bgp 192.168.192.0 255.255.248.0  BGP routing table entry for 192.168.192.0/21, version 23 Paths: (1 available, best #1)   Advertised to non peer-group peers:     192.168.1.229  300, (aggregated by 300 192.168.1.250)  192.168.1.233 from 192.168.1.233 (192.168.1.250)  Origin IGP, localpref 100, valid, external, atomic-aggregate, best, ref 2  Sun# 

In the case of the topology in Figure 3-12, the loss of path information causes a problem. Unlike Burke, Sun does not have a route filter in place to prevent the aggregate from being advertised to Sugarbush. Because Sugarbush does not see its own AS number in the AS_PATH of the aggregate from Sun, it enters the aggregate into its BGP table, as demonstrated in Example 3-64.

Example 3-64 Sugarbush Accepts the Aggregate Route from Sun Because It Does Not Find Its Own AS Number in the Route's AS_PATH

 Sugarbush#  show ip bgp  BGP table version is 19, local router ID is 172.20.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop          Metric LocPrf Weight Path *> 192.168.192.0    192.168.1.254    2297856             0 100 ?  *> 192.168.192.0/21 192.168.1.230                        0 400 300 i  *> 192.168.193.0    192.168.1.254    2297856             0 100 ? *> 192.168.194.0    192.168.1.254    2297856             0 100 ? *> 192.168.195.0    192.168.1.254    2297856             0 100 ? *> 192.168.196.0    192.168.1.254    2297856             0 100 ? *> 192.168.197.0    192.168.1.254    2297856             0 100 ? *> 192.168.198.0    192.168.1.254    2681856             0 100 ? *> 192.168.199.0    192.168.1.254          0             0 100 ? Sugarbush# 

If one of the more-specific routes from AS 100 becomes invalid, Sugarbush should drop any packets destined for that network. With the aggregate in place, however, the packets will instead be matched to the aggregate route. Suppose, for example, that the interface to network 192.168.197.0/24 in AS 100 fails. Stowe advertises the fact, and the route to that destination is removed from all BGP tables. Next, Sugarbush receives a packet with a destination address of 192.168.197.5. Not finding the more-specific address, the router matches the destination to the aggregate and forwards the packet to Sun. Sun again finds no more-specific address, matches the aggregate, and forwards the packet to Burke. Burke, as the originator of the aggregate, has no more-specific address and drops the packet. The packet to an invalid destination has been unnecessarily forwarded across two extra router hops before being correctly discarded. The problem would be even worse if Sugarbush were advertising an aggregate to Burke. In this case, instead of the packet's being dropped later than necessary, it loops until its TTL expires .

To remedy the problem, Burke can advertise an AS_SET in addition to the AS_SEQUENCE as part of the AS_PATH attribute by adding the as-set keyword to the aggregate-address statement. As discussed in Chapter 2, the AS_SET is an unordered list of the AS numbers along the path to the more-specific addresses that make up the aggregate. Unlike the AS_SEQUENCE, the AS_SET is not used to determine a shortest path; rather, its only purpose is to restore the loop-detection functionality lost in the aggregation.

Example 3-65 shows the configuration for Burke to advertise the AS_SET.

Example 3-65 Configuring Burke to Advertise the AS_SET

  router bgp 300    aggregate-address 192.168.192.0 255.255.248.0 as-set summary-only    neighbor 192.168.1.234 remote-as 400   neighbor 192.168.1.234 next-hop-self   neighbor 192.168.1.249 remote-as 200   neighbor 192.168.1.249 distribute-list 1 out   !   access-list 1 deny   192.168.192.0   access-list 1 permit any  

Example 3-66 shows the resulting BGP table at Sun. All the AS numbers on the path to the more-specific addresses are included in the AS_PATH of the aggregate. When the aggregate is advertised to Sugarbush, that router recognizes its AS number of 200 in the AS_PATH and does not accept the route.

Example 3-66 When Burke Is Configured to Include the AS_SET in the AS_PATH Attribute, All the AS Numbers on the Path to the Aggregated Addresses Are Included

 Sun#  show ip bgp  BGP table version is 10, local router ID is 172.21.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path *> 192.168.192.0    192.168.1.229                          0 200 100 ?  *> 192.168.192.0/21 192.168.1.233                          0 300 200 100 ?  *> 192.168.193.0    192.168.1.229                          0 200 100 ? *> 192.168.194.0    192.168.1.229                          0 200 100 ? *> 192.168.195.0    192.168.1.229                          0 200 100 ? *> 192.168.196.0    192.168.1.229                          0 200 100 ? *> 192.168.197.0    192.168.1.229                          0 200 100 ? *> 192.168.198.0    192.168.1.229                          0 200 100 ? *> 192.168.199.0    192.168.1.229                          0 200 100 ? Sun# 

It is important to know that when the AS_SET is advertised, the aggregate route inherits all the attributes of the aggregated routes. In the case of Figure 3-12, the AS_PATH of all the more-specific routes is (300,200,100). As a result, the AS_SET appears in Sun's BGP table as an ordered sequence, indistinguishable from the AS_SEQUENCEs.

Figure 3-13 shows a different topology. A new AS has been added, and network 192.168.197.0/24 has been moved from AS 100 to the new AS 500. Burke still receives the same routes, but now not all AS_PATH attributes match. As a result, the AS_SET is now advertised as the unordered sequence shown in Example 3-67.

Figure 3-13. Network 192.168.197.0/24 Is Moved from AS 100 to AS 500; Burke Can No Longer Represent the AS_SET as an Ordered Set

Example 3-67 The AS_SET Is Now Displayed in Sun's BGP Table as an Unordered Set, Distinguishable from the Ordered AS_SEQUENCEs

 Sun#  show ip bgp  BGP table version is 35, local router ID is 172.21.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path *> 192.168.192.0    192.168.1.229                          0 200 100 ?  *> 192.168.192.0/21 192.168.1.233                          0 300 {200,100,500} ?  *> 192.168.193.0    192.168.1.229                          0 200 100 ? *> 192.168.194.0    192.168.1.229                          0 200 100 ? *> 192.168.195.0    192.168.1.229                          0 200 100 ? *> 192.168.196.0    192.168.1.229                          0 200 100 ? *> 192.168.197.0    192.168.1.229                          0 200 500 i *> 192.168.198.0    192.168.1.229                          0 200 100 ? *> 192.168.199.0    192.168.1.229                          0 200 100 ? Sun# 

Basing an Aggregate on Selected More-Specific Routes

In some situations, you might want to advertise an aggregate with the AS_SET but do not want the aggregate to inherit all the attributes of all the aggregated routes. In Figure 3-14, Sugarbush receives all the routes from AS 100 and AS 500 and advertises an aggregate to Burke.

Figure 3-14. For Sugarbush to Advertise the Aggregate with an AS_SET, the Aggregate Must Not Inherit the NO_EXPORT COMMUNITY Attribute from 192.168.197.0/24

The problem with the setup in Figure 3-14 is that AS 500 is advertising 192.168.197.0/24 with the COMMUNITY attribute of NO_EXPORT. When Sugarbush uses the AS_SET option, the aggregate inherits the NO_EXPORT attribute, as demonstrated in Example 3-68. Note that the NO_EXPORT attribute is given to the aggregate locally, not added to the advertisement of the aggregate. As a result, Sugarbush acts on the attribute and does not advertise the aggregate route.

Example 3-68 The show ip bgp community no-export Command Displays All Routes with the NO_EXPORT COMMUNITY Attribute; in This Case, the Aggregate Route Has Inherited the Attribute from One of the Aggregated Addresses, 192.168.197.0/24

 Sugarbush#  show ip bgp community no-export  BGP table version is 19, local router ID is 172.20.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop          Metric LocPrf Weight Path *> 192.168.192.0/21 0.0.0.0                          32768 {100,500} ? s> 192.168.197.0    192.168.1.1            0             0 500 i Sugarbush# 

The last option of the aggregate-address command to be discussed, advertise-map, enables you to choose the routes upon which to base the aggregate. In the case of the internetwork in Figure 3-14, if Sugarbush does not consider 192.168.197.0/24 when forming the aggregate, the aggregate does not inherit that route's attributes. Example 3-69 shows the configuration for Sugarbush using the advertise-map option of the aggregate-address command.

Example 3-69 Configuring Sugarbush to Choose the Routes Upon Which to Base the Aggregate

  router bgp 200    aggregate-address 192.168.192.0 255.255.248.0 as-set summary-only advertise-map     ALLOW_ROUTE    neighbor 192.168.1.1 remote-as 500   neighbor 192.168.1.250 remote-as 300   neighbor 192.168.1.254 remote-as 100   !   access-list 1 deny   192.168.197.0   access-list 1 permit any   !   route-map ALLOW_ROUTE permit 10   match ip address 1  

The advertise-map option in the configuration in Example 3-69 points to a route map named ALLOW_ROUTE, which identifies the more-specific routes on which the aggregate is based. The route map in turn points to access list 1, which rejects 192.168.197.0 and permits all other routes. Because Sugarbush now ignores 192.168.197.0/24 when forming the aggregate, the aggregate route does not inherit the NO_EXPORT attribute, as demonstrated in Example 3-70.

Example 3-70 After Sugarbush Is Reconfigured with the advertise-map Option, the Aggregate Route No Longer Has the NO_EXPORT Attribute

 Sugarbush#  show ip bgp community no-export  BGP table version is 18, local router ID is 172.20.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop          Metric LocPrf Weight Path s> 192.168.197.0    192.168.1.1            0             0 500 i Sugarbush# 

Limiting the more-specific prefixes on which an aggregate is based can present some vulnerabilities. In the network of Figure 3-14 and the associated configurations, suppose the link between Stowe and Sugarbush fails. The aggregate is based only on the prefixes from AS 100 and so is no longer advertised. As a result, the destinations within AS 500 are no longer reachable from AS 300 and beyond.