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.
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.
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.
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.
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.
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.
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.
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 inte |
