Scenario : Verifying BGP Operation
This final scenario looks at Cisco IOS mechanisms for monitoring and verifying BGP routing within a Cisco router network.
The BGP topology to see how to use some common show commands to verify that BGP is operating correctly.
Show and debug commands can be valuable, not only in the real-life networks you come across, but also during your certification exams.
This scenario covers the following commands:
- show ip bgp
summary— Displays BGP neighbors in summary mode - show ip bgp— Displays the BGP topology table
- clear ip bgp *— Clears all BGP TCP sessions
- show tcp brief— Displays all TCP sessions (BGP uses TCP)
- debug ip bgp events— Displays any BGP events, such as neighbor state changes
Example 6-73 displays a sample output taken from R1 using the IOS show ip bgp summary command.
Example 6-73. show ip bgp summary on R1
R1#show ip bgp summary
BGP router identifier 131.108.255.13, local AS number 1
BGP table version is 11, main routing table version 11
6 network entries and 10 paths using 854 bytes of memory
3 BGP path attribute entries using 280 bytes of memory
BGP activity 50/44 prefixes, 73/63 paths
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
131.108.1.2 4 1 194 195 11 0 0 00:03:22 2
131.108.255.6 4 1 84 83 11 0 0 00:03:23 3
131.108.255.14 4 1 152 152 11 0 0 00:03:23 3
141.199.1.1 4 1001 0 0 0 0 0 never Idle
Example 6-73 displays a lot of useful information, including the local router identifier 131.108.255.13, the local AS of 1, and the BGP table version of 11. (An increasing version number indicates a network change is occurring; if no changes occur, this number remains the same.) It also shows six network paths on R1, using 854 bytes of memory.
Memory is important in BGP because in a large network, such as the Internet, memory can be a limiting factor. As more BGP entries populate the IP routing table, more memory is required. Example 6-73 displays four configured remote peers: the first three are IBGP (because the AS is 1 and the same as the local AS) and one remote peer that has never been active. (The output indicates an idle session, and the up/down time displays this connection was never established.)
The BGP table is one that confuses most people. Most engineers are familiar with a standard Cisco IOS IP routing table and mistakenly apply the same principles to the BGP table. The BGP table is not an IP routing table. The BGP table displays information, such as remote and local network entries, BGP attributes, and selected paths. Entries are then inserted into the IP routing table.
Example 6-74 displays the BGP table on R1. Notice the show ip bgp command can be performed in executive mode.
Example 6-74. show ip bgp
R1>show ip bgp
BGP table version is 11, local router ID is 131.108.255.13
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
*>i131.108.255.0/30 131.108.1.2 0 100 1000 i
* i 131.108.255.14 0 100 1000 i
*> 131.108.255.4/30 0.0.0.0 0 32768 i
* i 131.108.255.6 0 100 1000 i
*>i131.108.255.8/30 131.108.1.2 0 100 1000 i
* i 131.108.255.6 0 100 1000 i
*> 131.108.255.12/30 0.0.0.0 0 32768 i
* i 131.108.255.14 0 100 1000 i
*>i141.108.1.0/24 131.108.255.6 0 100 1000 i
*>i151.108.1.0/24 131.108.255.14 0 100 1000 i
Again, the BGP table version is displayed as 11 and the local router ID is 131.108.255.13. The various networks are listed along with the next hop address, metric (MED), local preference (Locpref), weight, and the path. The i on the left side (part of the status codes) indicates an internal BGP route and the i on the right side of Example 6-74 indicates the origin. (i is for IGP, part of the origin codes.)
If a BGP configuration change is completed on Cisco IOS routers, the BGP peer session must be cleared. The command to clear all sessions is clear ip bgp *. To clear a single peer router, use the clear ip bgp
peer-ip-address command.
Example 6-75 clears all BGP sessions on R1 after a configuration change to set all IBGP peer localpref attributes to 1000, instead of the default value of 100.
Example 6-75 displays the BGP table after the change is configured and you clear all BGP peers sessions on R1.
Example 6-75. clear ip bgp * and show ip bgp on R1
R1#clear ip bgp ?
* Clear all connections
<1-65535> AS number of the peers
A.B.C.D BGP neighbor address to clear
dampening Clear route flap dampening information
flap-statistics Clear route flap statistics
peer-group Clear BGP connections of peer-group
R1#clear ip bgp *
R1#show ip bgp
BGP table version is 11, local router ID is 131.108.255.13
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
*>i131.108.255.0/30 131.108.1.2 0 1000 1000 i
* i 131.108.255.14 0 1000 1000 i
*> 131.108.255.4/30 0.0.0.0 0 32768 i
* i 131.108.255.6 0 1000 1000 i
*>i131.108.255.8/30 131.108.1.2 0 1000 1000 i
* i 131.108.255.6 0 1000 1000 i
*> 131.108.255.12/30 0.0.0.0 0 32768 i
* i 131.108.255.14 0 1000 1000 i
*>i141.108.1.0/24 131.108.255.6 0 1000 1000 i
*>i151.108.1.0/24 131.108.255.14 0 100 1000 i
The ? tool displays a number of options, including clearing BGP sessions based on AS numbers or remote peer address. On Cisco IOS routers, you must clear the BGP sessions if you want a change to take place because BGP does not update changes after a BGP session is established. You can, however, configure soft configurations with the neighbor
peer address
soft-reconfiguration inbound command, which enables you to make changes and not have to clear the TCP peer, resulting in no downtime.
Example 6-76 displays the output from the show tcp brief command on R1.
Example 6-76. show tcp brief
R1#show tcp brief
TCB Local Address Foreign Address (state)
812CC228 131.108.255.5.11040 131.108.255.6.179 ESTAB
812CF508 131.108.1.1.11039 131.108.1.2.179 ESTAB
812D0054 131.108.255.13.11041 131.108.255.14.179 ESTAB
Router R1, as displayed in Example 6-76, has three TCP sessions in an established state. The TCP port numbers are also listed. This command is useful because you need to be certain that TCP is active at Layer 4 of the OSI model when troubleshooting to discover why two BGP peers are not sending updates, for example. The foreign addresses list the TCP port as 179, and the local address is a number TCP generates. This tells you that R1 has three TCP sessions active, and you can expect BGP to send updates and keepalives across each TCP session.
Debugging BGP is useful. The most widely used tool when establishing why BGP is or is not peering is the debug ip bgp events command. Next, clear all BGP sessions on R1 with this debug command turned on to discover the session you activated.
Example 6-77 displays the sample output taken from R1 when the BGP sessions are cleared for demonstration purposes. You would never use this command during normal working hours, because BGP loses peering to any remote peers. Also, notice that the clear and debug commands are performed in privileged mode.
Example 6-77. debug ip bgp events and clear ip bgp *on R1
R1#debug ip bgp events
BGP events debugging is on
R1#clear ip bgp *
4d01h: BGP: reset all neighbors due to User reset
4d01h: BGP: 131.108.1.2 went from Established to Idle
4d01h: BGP: 131.108.255.6 went from Established to Idle
4d01h: BGP: 131.108.255.14 went from Established to Idle
4d01h: BGP: 131.108.1.2 went from Idle to Active
4d01h: BGP: 131.108.255.6 went from Idle to Active
4d01h: BGP: 131.108.255.14 went from Idle to Active
4d01h: BGP: 131.108.255.6 went from Active to OpenSent
4d01h: BGP: 131.108.255.6 went from OpenSent to OpenConfirm
4d01h: BGP: 131.108.255.6 went from OpenConfirm to Established
4d01h: BGP: 131.108.255.6 computing updates, neighbor version 0, table version 1,
starting at 0.0.0.0
4d01h: BGP: 131.108.255.6 update run completed, ran for 0ms, neighbor version 0,
start version 1, throttled to 1, check point net 0.0.0.0
4d01h: BGP: 131.108.255.14 went from Active to OpenSent
4d01h: BGP: 131.108.255.14 went from OpenSent to OpenConfirm
4d01h: BGP: 131.108.255.14 went from OpenConfirm to Established
4d01h: BGP: 131.108.255.14 computing updates, neighbor version 0, table version 1,
starting at 0.0.0.0
4d01h: BGP: 131.108.255.14 update run completed, ran for 0ms, neighbor version 0,
start version 1, throttled to 1, check point net 0.0.0.0
4d01h: BGP: 131.108.1.2 went from Active to OpenSent
4d01h: BGP: 131.108.1.2 went from OpenSent to OpenConfirm
4d01h: BGP: 131.108.1.2 went from OpenConfirm to Established
4d01h: BGP: 131.108.1.2 computing updates, neighbor version 0, table version 1,
starting at 0.0.0.0
4d01h: BGP: 131.108.1.2 update run completed, ran for 0ms, neighbor version 0,
start version 1, throttled to 1, check point net 0.0.0.0
4d01h: BGP: 131.108.255.6 computing updates, neighbor version 1, table version 9,
starting at 0.0.0.0
4d01h: BGP: 131.108.255.6 update run completed, ran for 0ms, neighbor version 1,
start version 9, throttled to 9, check point net 0.0.0.0
4d01h: BGP: scanning routing tables
4d01h: BGP: scanning routing tables
4d01h: BGP: scanning routing tables
The sample output from Example 6-77 displays the BGP session's teardown state (reset by user) and the re-establishing of TCP sessions to the three peers: 131.108.255.14, 131.108.255.14, and 131.108.1.2. After the sessions are active, only changes are sent across the TCP peers. You can view keepalives with the debug ip bgp keepalives command. Example 6-78 displays a sample output taken from R1 after the TCP peers are established.
Example 6-78. debug ip bgp keepalives on R1
R1#debug ip bgp keepalives
BGP keepalives debugging is on
4d01h: BGP: 131.108.255.6 sending KEEPALIVE
4d01h: BGP: 131.108.255.6 KEEPALIVE rcvd
4d01h: BGP: 131.108.255.14 sending KEEPALIVE
4d01h: BGP: 131.108.255.14 KEEPALIVE rcvd
4d01h: BGP: 131.108.1.2 sending KEEPALIVE
4d01h: BGP: 131.108.1.2 KEEPALIVE rcvd
R1 is sending and receiving keepalives to the three remote peers to ensure that the remote routers are still active. Assume that R1 is reloaded.
If you display the TCP sessions now, you will discover three TCP sessions using a new local TCP port number because the sessions have been re-established and a new random local TCP port number has been chosen by TCP.
Example 6-79 displays the TCP sessions on R1.
Example 6-79. show tcp brief on R1
R1#sh tcp brief
TCB Local Address Foreign Address (state)
812CF984 131.108.255.5.11042 131.108.255.6.179 ESTAB
812CCB20 131.108.1.1.11044 131.108.1.2.179 ESTAB
812CC6A4 131.108.255.13.11043 131.108.255.14.179 ESTAB
No comments:
Post a Comment