Case Study Peering BGP Routers

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

AS 100 Aspen

Vail

Vail

92.168.1.222/30

192.168.1.221/30

92.168.1.222/30

192.168.1.226/30

192.168.1.226/30

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 * 4 The debug ip bgp events Command Displays the States of the BGP Finite State Machine as Aspen Peers with Vail

Aspen#«tefeu§ ip Hp events

BGP events debugging is on Aspen#conf t

Enter configuration commands, one per line. End with CNTL/Z. A&pen(conf ig}#roi§ter bgp 10«

Aspen(config-router)Neighbor 192.168.1*221 remote-as 100

Aspen(config- router)#AZ Aspen#

18:24:13: %SYS-5-C0NFIG_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 SGP 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, 1/0 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 rule 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.