Given that BGP is a resource intensive protocol in itself, careful consideration should be given before enabling any kind of BGP debugging in production environments. BGP debugging is enabled using the debug ip bgp command. The keywords that can be used in conjunction with this command are shown below:
| R3#debug ip bgp ? A.B.C.D BGP neighbor address all All address families dampening BGP dampening events BGP events groups BGP Config (peer-groups, templates) and Update groups import BGP import routes to a vrf across address-family in BGP Inbound information ipv4 Address family ipv6 Address family keepalives BGP keepalives mpls BGP MPLS label distribution nsap Address family out BGP Outbound information rib-filter Next hop route watch filter events updates BGP updates vpnv4 Address family <cr> |
NOTE: The majority of these options are beyond the scope of the TSHOOT eexam. Only those options that are relevant to this course are described below.
The debug ip bgp [address] updates command will print detailed information about updates received from the specified BGP neighbor. If you wanted to see real-time information about updates from all BGP peers, you would use the debug ip bgp updates command instead. Following is a sample output of the debug ip bgp [address] updates command, which shows detailed information about updates received from the specified neighbor. This information includes NLRI, NEXT_HOP information, MED information, as well as AS_PATH information, amongst other things as can be seen below.
| R3#debug ip bgp 4.4.4.4 updates BGP updates debugging is on for neighbor 4.4.4.4 for address family: IPv4 Unicast R3# R3# R3# *Mar 13 12:53:01.854: BGP(0): 4.4.4.4 send UPDATE (format) 150.4.0.0/24, next 3.3.3.3, metric 0, path 4 8 9 1 *Mar 13 12:53:01.854: BGP(0): 4.4.4.4 send UPDATE (prepend, chgflags: 0x0) 150.5.0.0/24, next 3.3.3.3, metric 0, path 4 8 9 1 *Mar 13 12:53:01.854: BGP(0): 4.4.4.4 send UPDATE (format) 150.2.0.0/24, next 3.3.3.3, metric 0, path 4 5 6 7 *Mar 13 12:53:01.858: BGP(0): 4.4.4.4 send UPDATE (prepend, chgflags: 0x0) 150.3.0.0/24, next 3.3.3.3, metric 0, path 4 5 6 7 *Mar 13 12:53:01.858: BGP(0): 4.4.4.4 send UPDATE (format) 160.0.0.0/24, next 3.3.3.3, metric 0, path 4 6 7 8 *Mar 13 12:53:01.858: BGP(0): 4.4.4.4 send UPDATE (prepend, chgflags: 0x0) 150.9.0.0/24, next 3.3.3.3, metric 0, path 4 6 7 8 *Mar 13 12:53:01.878: BGP(0): 4.4.4.4 rcvd UPDATE w/ attr: nexthop 4.4.4.4, origin ?, metric 0, path 4 6 7 8 *Mar 13 12:53:01.882: BGP(0): 4.4.4.4 rcvd 150.9.0.0/24…duplicate ignored *Mar 13 12:53:01.882: BGP(0): 4.4.4.4 rcvd 160.0.0.0/24…duplicate ignored *Mar 13 12:53:01.882: BGP(0): 4.4.4.4 rcv UPDATE w/ attr: nexthop 4.4.4.4, origin ?, metric 0, originator 0.0.0.0, path 4 2 3 5, community , extended community *Mar 13 12:53:01.882: BGP(0): 4.4.4.4 rcv UPDATE about 150.7.0.0/24 — DENIED due to: AS-PATH contains our own AS; *Mar 13 12:53:01.882: BGP(0): 4.4.4.4 rcv UPDATE about 150.6.0.0/24 — DENIED due to: AS-PATH contains our own AS; *Mar 13 12:53:01.886: BGP(0): 4.4.4.4 rcvd UPDATE w/ attr: nexthop 4.4.4.4, origin ?, metric 0, path 4 8 9 1 *Mar 13 12:53:01.886: BGP(0): 4.4.4.4 rcvd 150.5.0.0/24…duplicate ignored *Mar 13 12:53:01.886: BGP(0): 4.4.4.4 rcvd 150.4.0.0/24…duplicate ignored *Mar 13 12:53:01.886: BGP(0): 4.4.4.4 rcvd UPDATE w/ attr: nexthop 4.4.4.4, origin ?, metric 0, path 4 5 6 7 *Mar 13 12:53:01.890: BGP(0): 4.4.4.4 rcvd 150.3.0.0/24…duplicate ignored *Mar 13 12:53:01.890: BGP(0): 4.4.4.4 rcvd 150.2.0.0/24…duplicate ignored *Mar 13 12:53:01.890: BGP(0): 4.4.4.4 rcv UPDATE w/ attr: nexthop 4.4.4.4, origin ?, metric 0, originator 0.0.0.0, path 4 1 2 3, community , extended community *Mar 13 12:53:01.890: BGP(0): 4.4.4.4 rcv UPDATE about 150.1.0.0/24 — DENIED due to: AS-PATH contains our own AS; *Mar 13 12:53:01.894: BGP(0): 4.4.4.4 rcv UPDATE about 150.0.0.0/24 — DENIED due to: AS-PATH contains our own AS; *Mar 13 12:53:01.894: BGP(0): updgrp 1 – 4.4.4.4 updates replicated for neighbors: |
The debug ip bgp events command will provide real-time information on internal BGP events, such as the BGP Scanner walking the RIB. This command will also provide information about soft and hard peer session sessions resets, for example. Following is a sample of the information that is provided by this command:
| R3#debug ip bgp events BGP events debugging is on R3# *Mar 13 13:25:50.218: BGP: Regular scanner event timer *Mar 13 13:25:50.218: BGP: Import timer expired. Walking from 1 to 1 *Mar 13 13:25:56.846: BGP: 4.4.4.4 start outbound soft reconfig for afi/safi: 1/1 *Mar 13 13:26:05.218: BGP: Regular scanner event timer *Mar 13 13:26:05.218: BGP: Import timer expired. Walking from 1 to 1 *Mar 13 13:26:20.218: BGP: Regular scanner event timer *Mar 13 13:26:20.218: BGP: Import timer expired. Walking from 1 to 1 *Mar 13 13:26:26.978: BGP: 4.4.4.4 refresh timer expired, no pending refresh for afi: 0 *Mar 13 13:26:35.218: BGP: Regular scanner event timer *Mar 13 13:26:35.218: BGP: Performing BGP general scanning *Mar 13 13:26:35.218: BGP(0): scanning IPv4 Unicast routing tables *Mar 13 13:26:35.218: BGP(IPv4 Unicast): Performing BGP Nexthop scanning for general scan *Mar 13 13:26:35.218: BGP(0): Future scanner version: 1295, current scanner version: 1294 *Mar 13 13:26:35.218: BGP(1): scanning IPv6 Unicast routing tables *Mar 13 13:26:35.218: BGP(IPv6 Unicast): Performing BGP Nexthop scanning for general scan *Mar 13 13:26:35.218: BGP(1): Future scanner version: 1296, current scanner version: 1295 *Mar 13 13:26:35.218: BGP(2): scanning VPNv4 Unicast routing tables *Mar 13 13:26:35.218: BGP(VPNv4 Unicast): Performing BGP Nexthop scanning for general scan |
And finally, as was stated at the beginning of this section, the debug ip bgp updates command provides the same information as the debug ip bgp [address] updates command but for all configured BGP peers instead of specific ones. For granularity, the command supports additional keywords that can be used to filter the output. These keywords are illustrated below:
| R3#debug ip bgp updates ? <1-199> Access list <1300-2699> Access list (expanded range) events Update events in Inbound updates out Outbound updates <cr> |
ACLs can be used in conjunction with this command to restrict the output to the prefixes that are included in the ACLs. For example, to restrict the debug output to activities pertaining to the 150.2.0.0 and 150.3.0.0 prefixes, you would perform the following sequence of steps on the router on which you wanted to see the debugging output:
| R3#conf t Enter configuration commands, one per line. End with CNTL/Z. R3(config)#access-list 1 permit host 150.2.0.0 R3(config)#access-list 1 permit host 150.3.0.0 R3(config)#exit R3# R3#debug ip bgp updates 1 BGP updates debugging is on for access list 1 for address family: IPv4 Unicast R3# R3# R3# *Mar 13 13:37:33.154: BGP(0): 4.4.4.4 send UPDATE (format) 150.2.0.0/24, next 3.3.3.3, metric 0, path 4 5 6 7 *Mar 13 13:37:33.158: BGP(0): 4.4.4.4 send UPDATE (prepend, chgflags: 0x0) 150.3.0.0/24, next 3.3.3.3, metric 0, path 4 5 6 7 *Mar 13 13:37:33.182: BGP(0): 4.4.4.4 rcvd UPDATE w/ attr: nexthop 4.4.4.4, origin ?, metric 0, path 4 5 6 7 *Mar 13 13:37:33.182: BGP(0): 4.4.4.4 rcvd 150.3.0.0/24…duplicate ignored *Mar 13 13:37:33.186: BGP(0): 4.4.4.4 rcvd 150.2.0.0/24…duplicate ignored *Mar 13 13:37:33.186: BGP(0): updgrp 1 – 4.4.4.4 updates replicated for neighbors: R3# R3# R3#show ip access-lists 1 Standard IP access list 1 10 permit 150.2.0.0 (6 matches) 20 permit 150.3.0.0 (6 matches) |
NOTE: The same could also be performed using an extended ACL. Such an ACL, for example, might be configured as follows:
access-list 100 permit ip host 150.2.0.0 host 255.255.255.0
access-list 100 permit ip host 150.3.0.0 host 255.255.255.0
Following this, you would then use the debug ip bgp updates 100 command to restrict or filter the debug output to events pertaining to these two networks only.
The events keyword provides real-time information on update events, which includes received updates or updates sent by the local BGP speaker. The following is a sample of the information that is printed by this command:
| R3#debug ip bgp updates events BGP updates debugging is on events for address family: IPv4 Unicast R3# *Mar 13 13:44:21.154: BGP(0): Begin update run for versions 1->148 for 1 update groups for attrs 0->2 *Mar 13 13:44:21.154: BGP(0): pre format update-group 1 leader is 4.4.4.4 with 0/1000 msgs, versions 0/148 *Mar 13 13:44:21.154: BGP(0): post format update-group 1 leader is 4.4.4.4 with 3/1000 msgs, versions 148/148, formatting was not aborted *Mar 13 13:44:21.154: BGP(0): End update run for versions 1->148 (0ms), TX has not completed, 3 updates formatted, formatting was not aborted, 3 attrs – 6 nets visited*Mar 13 13:45:30.142: BGP(0): Begin update run for versions 1->148 for 1 update groups for attrs 0->2 *Mar 13 13:45:30.146: BGP(0): pre format update-group 1 leader is 10.0.0.2 with 0/1000 msgs, versions 0/148 *Mar 13 13:45:30.146: BGP(0): post format update-group 1 leader is 10.0.0.2 with 3/1000 msgs, versions 148/148, formatting was not aborted *Mar 13 13:45:30.146: BGP(0): End update run for versions 1->148 (4ms), TX has not completed, 3 updates formatted, formatting was not aborted, 3 attrs – 6 nets visited |
And finally, the in and out keywords can be used to restrict or filter the debug output to inbound or outbound updates. The default is to print information on both.