Debugging BGP Information

Debugging BGP Information
Using the debug commands with BGP will provide you with real-time feedback of the BGP
operation. An important item to note is that the debug commands can use a tremendous
amount of the router’s processing power. When using the debug commands, use them wisely.
Below is a list of the possible debug commands for BGP:
R3#debug ip bgp ?
A.B.C.D BGP neighbor address
dampening BGP dampening
events BGP events
keepalives BGP keepalives
updates BGP updates
<cr>
Verifying and Troubleshooting the Operation of BGP 277
We will take a look at each of these commands and what information they can provide.
The debug ip bgp command can be used to view the sending and receiving of OPEN messages
between a local router and the routers that it is trying to peer with. This command can
help you locate a problem in the sending or receiving of an OPEN message:
R3#debug ip bgp
BGP debugging is on
03:53:28: BGP: 2.2.2.2 closing
03:53:28: BGP: 4.4.4.4 closing
03:53:28: BGP: 5.5.5.5 closing
03:53:29: BGP: 2.2.2.2 open active, delay 24384ms
03:53:29: BGP: 4.4.4.4 open active, delay 7660ms
03:53:29: BGP: 5.5.5.5 open active, delay 7192ms
03:53:36: BGP: 5.5.5.5 open active, local address 3.3.3.3
03:53:36: BGP: 5.5.5.5 sending OPEN, version 4
03:53:36: BGP: 5.5.5.5 OPEN rcvd, version 4
03:53:36: BGP: 5.5.5.5 unrecognized OPEN parameter (0x2/0x6)
03:53:36: BGP: 5.5.5.5 unrecognized OPEN parameter (0x2/0x2)
03:53:36: BGP: 5.5.5.5 unrecognized OPEN parameter (0x2/0x2)
03:53:37: BGP: 4.4.4.4 open active, local address 3.3.3.3
03:53:37: BGP: 4.4.4.4 sending OPEN, version 4
03:53:37: BGP: 4.4.4.4 OPEN rcvd, version 4
03:53:53: BGP: 2.2.2.2 open active, local address 3.3.3.3
03:53:53: BGP: 2.2.2.2 open failed: Connection refused by remote host
03:54:10: BGP: 2.2.2.2 passive open
03:54:10: BGP: 2.2.2.2 OPEN rcvd, version 4
03:54:10: BGP: 2.2.2.2 sending OPEN, version 4
The debug ip bgp peer-address updates command is used to view information about the
UPDATE messages being sent between BGP peers. The command lets you view all of the routes
contained in the UPDATE message. This command can aid in locating a route being withdrawn
or added that shouldn’t be. It’s also useful in locating where a route is not being added or withdrawn
that should be:
R3#debug ip bgp 2.2.2.2 updates
BGP updates debugging is on for neighbor 2.2.2.2
03:57:48: BGP: 2.2.2.2 computing updates, neighbor version 0, table
➥version 14, starting at 0.0.0.0
03:57:48: BGP: 2.2.2.2 send UPDATE 3.0.0.0/8, next 20.20.20.2, metric
➥0, path 200
03:57:48: BGP: 2.2.2.2 send UPDATE 4.0.0.0/8 (chgflags: 0x0), next
➥20.20.20.2, path (before routemap/aspath update)
278 Chapter 8  Border Gateway Protocol
03:57:48: BGP: 2.2.2.2 send UPDATE 5.0.0.0/8 (chgflags: 0x0), next
➥20.20.20.2, path (before routemap/aspath update)
03:57:48: BGP: 2.2.2.2 send UPDATE 30.0.0.0/8 (chgflags: 0x0), next
➥20.20.20.2, path (before routemap/aspath update)
03:57:48: BGP: 2.2.2.2 send UPDATE 40.0.0.0/8 (chgflags: 0x0), next
➥20.20.20.2, path (before routemap/aspath update)
03:57:48: BGP: 2.2.2.2 send UPDATE 192.168.100.0/24, next 20.20.20.2,
➥metric 2195456, path 200
03:57:48: BGP: 2.2.2.2 send UPDATE 192.168.200.0/24, next 20.20.20.2,
➥metric 2684416, path 200
03:57:48: BGP: 2.2.2.2 3 updates enqueued (average=54, maximum=58)
03:57:48: BGP: 2.2.2.2 update run completed, ran for 40ms, neighbor
➥version 0, start version 14, throttled to 14, check point net 0.0.0.0
03:57:48: BGP: 2.2.2.2 rcv UPDATE w/ attr: nexthop 2.2.2.2, origin i,
➥metric 2172416, path 100
03:57:48: BGP: 2.2.2.2 rcv UPDATE about 192.168.24.0/24
03:57:48: BGP: 2.2.2.2 rcv UPDATE w/ attr: nexthop 2.2.2.2, origin i,
➥metric 0, path 100
03:57:48: BGP: 2.2.2.2 rcv UPDATE about 10.10.10.0/30
03:57:48: BGP: 2.2.2.2 rcv UPDATE about 20.20.20.0/30
The debug ip bgp dampening command is used to display information about routes being
dampened. This command can aid in locating a routing loop.
To view the state transitions of routers attempting to become BGP peers, use the debug ip bgp
events command. This command can be useful in locating an attempted peering session that is
stuck in a state or oscillating between states:
R3#debug ip bgp events
BGP events debugging is on
04:02:56: BGP: 2.2.2.2 went from Active to Idle
04:02:56: BGP: 2.2.2.2 went from Idle to Connect
04:02:56: BGP: 2.2.2.2 went from Connect to OpenSent
04:02:56: BGP: 2.2.2.2 went from OpenSent to OpenConfirm
04:02:57: BGP: 2.2.2.2 went from OpenConfirm to Established
04:02:57: BGP: 2.2.2.2 computing updates, neighbor version 0, table
➥version 26, starting at 0.0.0.0
04:02:57: BGP: 2.2.2.2 update run completed, ran for 4ms, neighbor version 0,
➥ start version 26, throttled to 26, check point net 0.0.0.0
04:02:58: BGP: 4.4.4.4 computing updates, neighbor version 26, table
➥version 29, starting at 0.0.0.0
04:02:58: BGP: 4.4.4.4 update run completed, ran for 0ms, neighbor version 26,
➥start version 29, throttled to 29, check point net 0.0.0.0
Verifying and Troubleshooting the Operation of BGP 279
04:02:58: BGP: 5.5.5.5 computing updates, neighbor version 26, table
➥version 29, starting at 0.0.0.0
04:02:58: BGP: 5.5.5.5 update run completed, ran for 4ms, neighbor version 26,
➥start version 29, throttled to 29, check point net 0.0.0.0
If you would like to view the KEEPALIVE messages a router is sending and receiving, you
can use the debug ip bgp keepalives command. This command can help you locate a connection
where the potential peer is encountering communication problems:
R3#debug ip bgp keepalives
BGP keepalives debugging is on
04:06:44: BGP: 5.5.5.5 sending KEEPALIVE
04:06:44: BGP: 5.5.5.5 KEEPALIVE rcvd
04:06:44: BGP: 5.5.5.5 sending KEEPALIVE
04:06:44: BGP: 5.5.5.5 KEEPALIVE rcvd
04:06:45: BGP: 4.4.4.4 sending KEEPALIVE
04:06:46: BGP: 4.4.4.4 KEEPALIVE rcvd
04:06:46: BGP: 4.4.4.4 sending KEEPALIVE
04:06:46: BGP: 4.4.4.4 KEEPALIVE rcvd
04:07:25: BGP: 2.2.2.2 sending KEEPALIVE
04:07:26: BGP: 2.2.2.2 KEEPALIVE rcvd
04:07:26: BGP: 2.2.2.2 sending KEEPALIVE
04:07:26: BGP: 2.2.2.2 KEEPALIVE rcvd
The debug ip bgp updates command provides you with information on all UPDATE messages
your router is sending and receiving. With this command, you are able to view all of the
BGP routes that are being added or withdrawn:
R3#debug ip bgp updates
BGP updates debugging is on
04:08:33: BGP: 5.5.5.5 computing updates, neighbor version 0, table version 8,
➥starting at 0.0.0.0
04:08:33: BGP: 5.5.5.5 send UPDATE 3.0.0.0/8, next 3.3.3.3, metric 0, path
04:08:33: BGP: 5.5.5.5 send UPDATE 4.0.0.0/8 (chgflags: 0x8), next 3.3.3.3,
➥path (before routemap/aspath update)
04:08:33: BGP: 5.5.5.5 send UPDATE 5.0.0.0/8 (chgflags: 0x8), next 3.3.3.3,
➥path (before routemap/aspath update)
04:08:33: BGP: 5.5.5.5 send UPDATE 30.0.0.0/8 (chgflags: 0x8), next 3.3.3.3,
➥path (before routemap/aspath update)
04:08:33: BGP: 5.5.5.5 send UPDATE 40.0.0.0/8 (chgflags: 0x8), next 3.3.3.3,
➥path (before routemap/aspath update)
04:08:33: BGP: 5.5.5.5 NEXT_HOP part 1 net 192.168.100.0/24, next 30.30.30.2
04:08:33: BGP: 5.5.5.5 send UPDATE 192.168.100.0/24, next 30.30.30.2,
➥metric 219 5456, path
280 Chapter 8  Border Gateway Protocol
04:08:33: BGP: 5.5.5.5 NEXT_HOP part 1 net 192.168.200.0/24, next 30.30.30.2
04:08:33: BGP: 5.5.5.5 send UPDATE 192.168.200.0/24, next 30.30.30.2,
➥metric 268 4416, path
04:08:33: BGP: 5.5.5.5 3 updates enqueued (average=57, maximum=61)
04:08:33: BGP: 5.5.5.5 update run completed, ran for 44ms, neighbor version 0,
➥start version 8, throttled to 8, check point net 0.0.0.0
04:08:34: BGP: 4.4.4.4 computing updates, neighbor version 0, table version 8,
➥starting at 0.0.0.0
04:08:34: BGP: 4.4.4.4 send UPDATE 3.0.0.0/8, next 3.3.3.3, metric 0, path
04:08:34: BGP: 4.4.4.4 send UPDATE 4.0.0.0/8 (chgflags: 0x8), next 3.3.3.3,
➥path (before routemap/aspath update)
04:08:34: BGP: 4.4.4.4 send UPDATE 5.0.0.0/8 (chgflags: 0x8), next 3.3.3.3,
➥path (before routemap/aspath update)
04:08:34: BGP: 4.4.4.4 send UPDATE 30.0.0.0/8 (chgflags: 0x8), next 3.3.3.3,
➥path (before routemap/aspath update)
04:08:34: BGP: 4.4.4.4 send UPDATE 40.0.0.0/8 (chgflags: 0x8), next 3.3.3.3,
➥path (before routemap/aspath update)
04:08:34: BGP: 4.4.4.4 NEXT_HOP part 1 net 192.168.100.0/24, next 30.30.30.2
04:08:34: BGP: 4.4.4.4 send UPDATE 192.168.100.0/24, next 30.30.30.2,
➥metric 219 5456, path
04:08:34: BGP: 4.4.4.4 NEXT_HOP part 1 net 192.168.200.0/24, next 30.30.30.2
04:08:34: BGP: 4.4.4.4 send UPDATE 192.168.200.0/24, next 30.30.30.2,
➥metric 268 4416, path
04:08:34: BGP: 4.4.4.4 3 updates enqueued (average=57, maximum=61)
04:08:34: BGP: 4.4.4.4 update run completed, ran for 48ms, neighbor version 0,
➥start version 8, throttled to 8, check point net 0.0.0.0
Don’t forget that once you have issued a debug command, you need to enter the undebug
all or no debug all command to turn off debugging. In order to become familiar with the
debug commands, I suggest setting up a lab environment where you can practice them. Do not
attempt to practice debug commands in a live environment. The use of debug commands in a
live environment can cause processing issues with a router. You should use them for troubleshooting
in a live environment only once you have sufficient experience in a lab.