Examples

This example shows how to begin debugging of IAPP packets:

SOAP-AP# debug iapp packet

This example shows how to begin debugging of IAPP events:

SOAP-AP# debug iapp events

This example shows how to begin debugging of IAPP errors:

SOAP-AP# debug iapp errors

Examples

The following example shows how to enable debugging for IF-MGR EFP extension errors:

Router> enable
Router# debug if-mgr errors efp-ext
Router#

Examples

The following example shows output when you enter the debug ima command while adding two ATM links to an IMA group. Notice that the group has not yet been created with the interface atm slot /ima group-number command, so the links are not activated yet as group members. However, the individual ATM links are deactivated.

Router# debug ima
 
IMA network interface debugging is on
Router# config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# interface atm1/0
Router(config-if)# ima-group 1
Router(config-if)#
01:35:08:IMA shutdown atm layer of link ATM1/0
01:35:08:ima_clear_atm_layer_if ATM1/0
01:35:08:IMA link ATM1/0 removed in firmware
01:35:08:ima_release_channel:ATM1/0 released channel 0.
01:35:08:Bring up ATM1/4 that had been waiting for a free channel.
01:35:08:IMA:no shut the ATM interface.
01:35:08:IMA allocate_channel:ATM1/4 using channel 0.
01:35:08:IMA config_restart ATM1/4
01:35:08:IMA 
adding link 0 to Group ATM1/IMA1ATM1/0 is down waiting for IMA group 1 to be activated
01:35:08:Link 0 was added to Group ATM1/IMA1
01:35:08:ATM1/0 is down waiting for IMA group 1 to be created.
01:35:08:IMA send AIS on link ATM1/0
01:35:08:IMA Link up/down Alarm:port 0, new status 0x10, old_status 0x1.
01:35:10:%LINK-3-UPDOWN:Interface ATM1/4, changed state to up
01:35:10:%LINK-3-UPDOWN:Interface ATM1/0, changed state to down
01:35:11:%LINEPROTO-5-UPDOWN:Line protocol on Interface ATM1/4, changed state to up
01:35:11:%LINEPROTO-5-UPDOWN:Line protocol on Interface ATM1/0, changed state to down
Router(config-if)# int atm1/1
Router(config-if)# ima-group 1
Router(config-if)#
01:37:19:IMA shutdown atm layer of link ATM1/1
01:37:19:ima_clear_atm_layer_if ATM1/1
01:37:19:IMA link ATM1/1 removed in firmware
01:37:19:ima_release_channel:ATM1/1 released channel 1.
01:37:19:Bring up ATM1/5 that had been waiting for a free channel.
01:37:19:IMA:no shut the ATM interface.
01:37:19:IMA allocate_channel:ATM1/5 using channel 1.
01:37:19:IMA config_restart ATM1/5
01:37:19:IMA adding link 1 to Group ATM1/IMA1ATM1/1 is down waiting for IMA group 1 to be activated
01:37:19:Link 1 was added to Group ATM1/IMA1
01:37:19:ATM1/1 is down waiting for IMA group 1 to be created.
01:37:19:IMA send AIS on link ATM1/1
01:37:19:IMA Link up/down Alarm:port 1, new status 0x10, old_status 0x1.
Router(config-if)#
01:37:21:%LINK-3-UPDOWN:Interface ATM1/5, changed state to up
01:37:21:%LINK-3-UPDOWN:Interface ATM1/1, changed state to down
01:37:22:%LINEPROTO-5-UPDOWN:Line protocol on Interface ATM1/5, changed state to up
01:37:22:%LINEPROTO-5-UPDOWN:Line protocol on Interface ATM1/1, changed state to down

Examples

To enable all installer debugs, perform the following:

        infra-p2-3#debug installer all
All installer debugging is on

Examples

The following is sample output from the debug interface command:

Router# debug interface ATM 1/0 vc 0/5
Condition 1 set
*Jan 31 19:36:38.399: ATM VC Debug: Condition 1, atm-vc 0/5 AT1/0 triggered, count 1

Examples

The following is sample output from the debug interface counters exceptions command when backward-going counters are detected. The output is self-explanatory.

Router# debug interface counters exceptions
IF-4-BACKWARD_COUNTERS: Corrected for backward rx_bytes counters (561759 -> 526385) on Multilink1
IF-4-BACKWARD_COUNTERS: Corrected for backward tx_bytes counters (288114 -> 268710) on Multilink1
IF-4-BACKWARD_COUNTERS: Corrected for backward tx_bytes counters (2220 -> 0) on Virtual-Access4 

Examples

The following is sample output from the debug interface counters protocol memorycommand. The output is self-explanatory.

Router# debug interface counters protocol memory
interface counter protocol memory operations debugging is on
*Jan 11 11:34:08.154: IDB_PROTO: Ethernet0/0 created CDP
*Jan 11 11:35:08.154: IDB_PROTO: Ethernet0/0 reset CDP

Examples

The following is sample output from the debug interface statescommand when the shutdown command is executed on an interface. The output is self-explanatory.

Router# debug interface states
interface state transitions debugging is on
Router# debug condition interface fast0/0
Condition 1 set
Router# config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#
*Sep  1 12:24:46.294: [IDB Fa0/0 UARUYY] LSTATE_REQ: Entry
*Sep  1 12:24:46.294: [IDB Fa0/0 UARUYY] LSTATE_REQ: timers not running
*Sep  1 12:24:46.294: [IDB Fa0/0 UARUYY] LSTATE_REQ: Exit
Router(config)# interface fast0/0
Router(config-if)# shut
Router(config-if)#
*Sep  1 12:24:56.294: [IDB Fa0/0 UARUYY] LSTATE_REQ: Entry
*Sep  1 12:24:56.294: [IDB Fa0/0 UARUYY] LSTATE_REQ: timers not running
*Sep  1 12:24:56.294: [IDB Fa0/0 UARUYY] LSTATE_REQ: Exit
*Sep  1 12:24:57.162: [IDB Fa0/0 UARUYY] CSTATE_REQ: Entry, requested
state: A
*Sep  1 12:24:57.162: [IDB Fa0/0 UARUYY] CSTATE_REQ: starting ctimer (2000)
*Sep  1 12:24:57.162: [IDB Fa0/0 AURUYY] CSTATE_REQ: state assign
*Sep  1 12:24:57.162: [IDB Fa0/0 AURUYY] LSTATE_REQ: Entry
*Sep  1 12:24:57.162: [IDB Fa0/0 AURUYY] LSTATE_REQ: Exit
*Sep  1 12:24:57.162: [IDB Fa0/0 AURUYY] CSTATE_REQ: Exit
*Sep  1 12:24:57.162: [IDB Fa0/0 AURUYY] CSTATE_REQ: Entry, requested
state: A
*Sep  1 12:24:57.162: [IDB Fa0/0 AURUYY] CSTATE_REQ: state assign
*Sep  1 12:24:57.162: [IDB Fa0/0 AURUYY] LSTATE_REQ: Entry
*Sep  1 12:24:57.162: [IDB Fa0/0 AURUYY] LSTATE_REQ: Exit
*Sep  1 12:24:57.162: [IDB Fa0/0 AURUYY] CSTATE_REQ: Exit
*Sep  1 12:24:57.166: [IDB Fa0/0 AURUnY] TRANS_ADJ: Entry
*Sep  1 12:24:57.166: [IDB Fa0/0 AURUnn] TRANS_ADJ: propagating change
to subifs
*Sep  1 12:24:57.170: [IDB Fa0/0 AURUnn] TRANS_ADJ: Exit
*Sep  1 12:24:57.170: [IDB Fa0/0 AURUnn] ROUTE_ADJ: Entry
*Sep  1 12:24:57.170: [IDB Fa0/0 AURUnn] ROUTE_ADJ: Exit
*Sep  1 12:24:57.170: [IDB Fa0/0 AURUnn] BRIDGE_ADJ: Entry
*Sep  1 12:24:57.170: [IDB Fa0/0 AURUnn] BRIDGE_ADJ: Exit
*Sep  1 12:24:59.162: [IDB Fa0/0 AURUnn] CSTATE_TMR: Entry
*Sep  1 12:24:59.162: [IDB Fa0/0 AURUnn] CSTATE_TMR: netidb=Fa0/0,
linestate: n
*Sep  1 12:24:59.162: [IDB Fa0/0 AURUnn] LSTATE_REQ: Entry
*Sep  1 12:24:59.162: [IDB Fa0/0 AURUnn] LSTATE_REQ: timers not running
*Sep  1 12:24:59.162: [IDB Fa0/0 AURUnn] LSTATE_REQ: starting lineproto
timer
*Sep  1 12:24:59.162: [IDB Fa0/0 AURUnn] LSTATE_REQ: Exit
*Sep  1 12:24:59.162: [IDB Fa0/0 AURUnn] CSTATE_TMR: transition detected
*Sep  1 12:24:59.162: %ENTITY_ALARM-6-INFO: ASSERT INFO Fa0/0 Physical
Port Administrative State Down
*Sep  1 12:24:59.162: [IDB Fa0/0 AURUnn] TRANS_ADJ: Entry
*Sep  1 12:24:59.162: [IDB Fa0/0 AURUnn] TRANS_ADJ: Exit
*Sep  1 12:24:59.162: [IDB Fa0/0 AURUnn] CSTATE_TMR: Exit
*Sep  1 12:25:00.162: [IDB Fa0/0 AURUnn] LSTATE_TMR: Entry
*Sep  1 12:25:00.162: [IDB Fa0/0 AURUnn] LSTATE_TMR: not spoofing,
current state: n
*Sep  1 12:25:00.162: [IDB Fa0/0 AURUnn] LSTATE_TMR: informing line
state transitions
*Sep  1 12:25:00.162: [IDB Fa0/0 AURUnn] TRANS_ADJ: Entry
*Sep  1 12:25:00.162: [IDB Fa0/0 AURUnn] TRANS_ADJ: Exit
*Sep  1 12:25:00.162: [IDB Fa0/0 AURUnn] ROUTE_ADJ: Entry
*Sep  1 12:25:00.162: [IDB Fa0/0 AURUnn] ROUTE_ADJ: Exit
*Sep  1 12:25:00.162: [IDB Fa0/0 AURUnn] LSTATE_TMR: Exit

Examples

The following is sample output from the debug interfacecommand:

Router# debug interface vasileft 100
Condition 1 set

Examples

The following example shows sample debug output displayed when configuring ACL hash-value generation.

Note	The example in this section shows sample output for a numbered access list. However, you can configure ACL hash-value generation for both numbered and named access lists, and for both standard and extended access lists.

Router#
*Aug 9 00:24:31.765: %SYS-5-CONFIG_I: Configured from console by console
Router# debug ip access-list hash-generation
Syslog hash code generation debugging is on
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# ip access-list logging hash-generation
Router(config)# access-list 101 permit tcp host 10.1.1.1 host 10.1.1.2 log
Router(config)#
*Aug 9 00:25:31.661: %IPACL-HASHGEN: Hash Input: 101 extended permit 6 host 20.1.1.1 host 20.1.1.2 Hash Output: 0xA363BB54
Router(config)# exit
Router#

Examples

The following is sample output from the debug ip access-list intstatscommand:

Router# debug ip access-list intstats
Router# enable
Router# configure terminal
Router(config)#interface e0/0
Router(config-if)#ip access-group 100 in
*Oct 29 08:52:16.763: IPACL-INTSTATS: ACL swsb created
*Oct 29 08:52:16.763: IPACL-INTSTATS: ACL header stats structure created
*Oct 29 08:52:16.763: IPACL-INTSTATS: I/P stats table created
*Oct 29 08:52:16.763: IPACL-INTSTATS: Statsid bitmap created
*Oct 29 08:52:16.763: IPACL-INTSTATS: Done with static ACEs
Router(config-if)#ip access-group 100 out
*Oct 29 08:52:19.435: IPACL-INTSTATS: O/P stats table created
*Oct 29 08:52:19.435: IPACL-INTSTATS: Done with static ACEs

Examples

The following is sample output from the debug ip access-list turboaclcommand:

Router# debug ip access-list turboacl
 
*Aug 20 00:41:17.843 UTC:Miss at index 73, 19
*Aug 20 00:41:17.843 UTC:Adding dynamic entry, update = 1
*Aug 20 00:41:17.843 UTC:Miss at index 21, 39
*Aug 20 00:41:17.847 UTC:Adding dynamic entry, update = 1
*Aug 20 00:41:17.847 UTC:Miss at index 116, 42
*Aug 20 00:41:17.851 UTC:Adding dynamic entry, update = 1
*Aug 20 00:41:17.851 UTC:Miss at index 119, 28
*Aug 20 00:41:17.851 UTC:Adding dynamic entry, update = 1
*Aug 20 00:41:17.855 UTC:Miss at index 116, 42
*Aug 20 00:41:17.855 UTC:Adding dynamic entry, update = 1
*Aug 20 00:41:17.855 UTC:Miss at index 92, 20
*Aug 20 00:41:17.855 UTC:Adding dynamic entry, update = 1
*Aug 20 00:41:17.855 UTC:Miss at index 119, 28
*Aug 20 00:41:17.855 UTC:Adding dynamic entry, update = 1
*Aug 20 00:41:17.855 UTC:Miss at index 56, 29
*Aug 20 00:41:17.859 UTC:Adding dynamic entry, update = 1
*Aug 20 00:41:17.859try, update = 1
*Aug 20 00:41:19.959 UTC:Miss at index 29, 41
*Aug 20 00:41:19.959 UTC:Adding dynamic entry, update = 1
*Aug 20 00:41:19.959 UTC:Miss at index 29, 38

The table below describes the significant fields shown in the display.

Examples

Router# debug ip admission consent errors
 
IP Admission Consent Errors debugging is on 
Router# debug ip admission consent events
 
IP Admission Consent Events debugging is on 
Router# debug ip admission consent messages
 
IP Admission Consent Messages debugging is on 
Router# 
Router# show debugging
IP Admission Consent: 
IP Admission Consent Errors debugging is on 
IP Admission Consent Events debugging is on 
IP Admission Consent Messages debugging is on

Examples

The following sample output from the debug ip admission eapoudp command shows information about network admission control using EAPoUDP. In the command output, the term “posture” refers to the credentials (for example, antivirus state or version of Cisco IOS software) of the host system.

Router# debug ip admission eapoudp
 
Posture validation session created for client mac= 0001.027c.f364 ip= 10.0.0.1
Total Posture sessions= 1 Total Posture Init sessions= 1 
*Apr  9 19:39:45.684: %AP-6-POSTURE_START_VALIDATION: IP=10.0.0.1|
Interface=FastEthernet0/0.420
*Apr  9 19:40:42.292: %AP-6-POSTURE_STATE_CHANGE: IP=10.0.0.1| STATE=POSTURE ESTAB
*Apr  9 19:40:42.292: auth_proxy_posture_parse_aaa_attributes:  
CiscoDefined-ACL name= #ACSACL#-IP-HealthyACL-40921e54
Apr  9 19:40:42.957: %AP-6-POSTURE_POLICY: Apply access control list
(xACSACLx-IP-HealthyACL-40921e54) policy for host (10.0.0.1)

The fields in the display are self-explanatory.

Examples

The following examples illustrate the output of the debug ip auth-proxy command. In these examples, debugging is on for object creations, object deletions, HTTP, and TCP.

In this example, the client host at 192.168.201.1 is attempting to make an HTTP connection to the web server located at 192.168.21.1. The HTTP debugging information is on for the authentication proxy. The output shows that the router is setting up an authentication proxy entry for the login request:

00:11:10: AUTH-PROXY creates info:
cliaddr - 192.168.21.1, cliport - 36583
seraddr - 192.168.201.1, serport - 80
ip-srcaddr 192.168.21.1
pak-srcaddr 0.0.0.0 

Following a successful login attempt, the debugging information shows the authentication proxy entries created for the client. In this example, the client is authorized for SMTP (port 25), FTP data (port 20), FTP control (port 21), and Telnet (port 23) traffic. The dynamic access control list (ACL) entries are included in the display.

00:11:25:AUTH_PROXY OBJ_CREATE:acl item 61AD60CC
 
00:11:25:AUTH-PROXY OBJ_CREATE:create acl wrapper 6151C7C8 -- acl item 61AD60CC
00:11:25:AUTH-PROXY Src 192.168.162.216 Port [0]
00:11:25:AUTH-PROXY Dst 192.168.162.220 Port [25]
00:11:25:AUTH_PROXY OBJ_CREATE:acl item 6151C908
 
00:11:25:AUTH-PROXY OBJ_CREATE:create acl wrapper 6187A060 -- acl item 6151C908
00:11:25:AUTH-PROXY Src 192.168.162.216 Port [0]
00:11:25:AUTH-PROXY Dst 192.168.162.220 Port [20]
00:11:25:AUTH_PROXY OBJ_CREATE:acl item 61A40B88
 
00:11:25:AUTH-PROXY OBJ_CREATE:create acl wrapper 6187A0D4 -- acl item 61A40B88
00:11:25:AUTH-PROXY Src 192.168.162.216 Port [0]
00:11:25:AUTH-PROXY Dst 192.168.162.220 Port [21]
00:11:25:AUTH_PROXY OBJ_CREATE:acl item 61879550
 
00:11:25:AUTH-PROXY OBJ_CREATE:create acl wrapper 61879644 -- acl item 61879550
00:11:25:AUTH-PROXY Src 192.168.162.216 Port [0]
00:11:25:AUTH-PROXY Dst 192.168.162.220 Port [23]

The next example shows the debug output following a clear ip auth-proxy cache command to clear the authentication entries from the router. The dynamic ACL entries are removed from the router.

00:12:36:AUTH-PROXY OBJ_DELETE:delete auth_proxy cache 61AD6298
00:12:36:AUTH-PROXY OBJ_DELETE:delete create acl wrapper 6151C7C8 -- acl item 61AD60CC
00:12:36:AUTH-PROXY OBJ_DELETE:delete create acl wrapper 6187A060 -- acl item 6151C908
00:12:36:AUTH-PROXY OBJ_DELETE:delete create acl wrapper 6187A0D4 -- acl item 61A40B88
00:12:36:AUTH-PROXY OBJ_DELETE:delete create acl wrapper 61879644 -- acl item 61879550

The following example shows the timer information for a dynamic ACL entry. All times are expressed in milliseconds. The first laststart is the time that the ACL entry is created relative to the startup time of the router. The lastref is the time of the last packet to hit the dynamic ACL relative to the startup time of the router. The exptime is the next expected expiration time for the dynamic ACL. The delta indicates the remaining time before the dynamic ACL expires. After the timer expires, the debugging information includes a message indicating that the ACL and associated authentication proxy information for the client have been removed.

00:19:51:first laststart 1191112
 
00:20:51:AUTH-PROXY:delta 54220 lastref 1245332 exptime 1251112
00:21:45:AUTH-PROXY:ACL and cache are removed 

The following example is sample output with the detailed keyword enabled:

00:37:50:AUTH-PROXY:proto_flag=5, dstport_index=1
00:37:50: SYN SEQ 245972 LEN 0
00:37:50:dst_addr 192.168.127.2 src_addr 192.168.27.1 dst_port 21 src_port 4347
00:37:50:AUTH-PROXY:auth_proxy_half_open_count++ 1
00:37:50:AUTH-PROXY:proto_flag=5, dstport_index=1
00:37:50: ACK 1820245643 SEQ 245973 LEN 0
00:37:50:dst_addr 192.168.127.2 src_addr 192.168.27.1 dst_port 21 src_port 4347
00:37:50:clientport 4347 state 0
00:37:50:AUTH-PROXY:incremented proxy_proc_count=1
00:37:50:AUTH-PROXY:proto_flag=5, dstport_index=1
00:37:50: ACK 1820245674 SEQ 245973 LEN 0
00:37:50:dst_addr 192.168.127.2 src_addr 192.168.27.1 dst_port 21 src_port 4347
00:37:50:clientport 4347 state 0
00:37:57:AUTH-PROXY:proto_flag=5, dstport_index=1
00:37:57: PSH ACK 1820245674 SEQ 245973 LEN 16
00:37:57:dst_addr 192.168.127.2 src_addr 192.168.27.1 dst_port 21 src_port 4347
00:37:57:clientport 4347 state 0
00:37:57:AUTH-PROXY:proto_flag=5, dstport_index=1
00:37:57: ACK 1820245699 SEQ 245989 LEN 0
00:37:57:dst_addr 192.168.127.2 src_addr 192.168.27.1 dst_port 21 src_port 4347
00:37:57:clientport 4347 state 0
00:38:01:AUTH-PROXY:proto_flag=5, dstport_index=1
00:38:01: PSH ACK 1820245699 SEQ 245989 LEN 16
00:38:01:dst_addr 192.168.127.2 src_addr 192.168.27.1 dst_port 21 src_port 4347
00:38:01:clientport 4347 state 0
00:38:01:AUTH-PROXY:Authenticating user ryan
00:38:01:AUTH-PROXY:Session state is INIT.Not updating stats
00:38:01:AUTH-PROXY:Session state is INIT.Not updating stats
00:38:01:AUTH-PROXY:Sent AAA request successfully
00:38:01:AUTH-PROXY:Sent password successfully
00:38:01:AUTH-PROXY:processing authorization data
00:38:01:AUTH-PROXY:Sending accounting start.unique-id 2
00:38:01:AUTH-PROXY:Session state is INIT.Not updating stats
00:38:01:AUTH-PROXY:Session state is INIT.Not updating stats
00:38:01:AUTH-PROXY:wait complete on watched boolean stat=0
00:38:01:AUTH-PROXY:src ip addr is 192.168.127.2, dstaddr=192.168.27.1
00:38:01: SYN ACK 2072458992 SEQ 4051022445 LEN 0
00:38:01:AUTH-PROXY:src ip addr is 192.168.127.2, dstaddr=192.168.27.1
00:38:01: PSH ACK 2072458992 SEQ 4051022446 LEN 49
00:38:02:AUTH-PROXY:src ip addr is 192.168.127.2, dstaddr=192.168.27.1
00:38:02: ACK 2072459003 SEQ 4051022495 LEN 0
00:38:02:AUTH-PROXY:src ip addr is 192.168.127.2, dstaddr=192.168.27.1
00:38:02: PSH ACK 2072459003 SEQ 4051022495 LEN 33
00:38:02:AUTH-PROXY:src ip addr is 192.168.127.2, dstaddr=192.168.27.1
00:38:02: ACK 2072459014 SEQ 4051022528 LEN 0
00:38:02:AUTH-PROXY:src ip addr is 192.168.127.2, dstaddr=192.168.27.1
00:38:02: PSH ACK 2072459014 SEQ 4051022528 LEN 26
00:38:03:AUTH-PROXY:proto_flag=5, dstport_index=1
00:38:03: ACK 1820245725 SEQ 246005 LEN 0
00:38:03:dst_addr 192.168.127.2 src_addr 192.168.27.1 dst_port 21 src_port 4347
00:38:03:clientport 4347 state 3
7200b#

Examples

The following is output from the debug ip auth-proxy ezvpn command. The output displays the proxy authentication behavior of a web-based activation.

Router# debug ip auth-proxy ezvpn
*Dec 20 20:25:11.006: AUTH-PROXY: New request received by EzVPN WebIntercept from   10.4.205.205
*Dec 20 20:25:17.150: AUTH-PROXY:GET request received
*Dec 20 20:25:17.150: AUTH-PROXY:Authentication scheme is 401
*Dec 20 20:25:17.362: AUTH-PROXY:Authorization information not present in GET request
*Dec 20 20:25:17.362: AUTH-PROXY: Allocated on credinfo for connect at 0x81EF1A84
*Dec 20 20:25:17.362: AUTH-PROXY: Posting CONNECT request to EzVPN
*
Dec 20 20:25:17.362: EZVPN(tunnel22): Received CONNECT from 10.4.205.205!
*Dec 20 20:25:17.366: EZVPN(tunnel22): Current State: CONNECT_REQUIRED
*Dec 20 20:25:17.366: EZVPN(tunnel22): Event: CONNECT

The output in the display is self-explanatory.

Examples

Following is the sample output from the debug ip bgp command used with vpnv4 keyword:

Router# debug ip bgp vpnv4
 
03:47:14:vpn:bgp_vpnv4_bnetinit:100:2:10.0.0.0/8
03:47:14:vpn:bnettable add:100:2:10.0.0.0/8
03:47:14:vpn:bestpath_hook route_tag_change for vpn2:10.0.0.0/255.0.0.0(ok)
03:47:14:vpn:bgp_vpnv4_bnetinit:100:2:10.0.0.0/8
03:47:14:vpn:bnettable add:100:2:10.0.0.0/8
03:47:14:vpn:bestpath_hook route_tag_change for vpn2:10.0.0.0/255.0.0.0(ok)
03:47:14:vpn:bgp_vpnv4_bnetinit:100:2:10.0.0.0/8
03:47:14:vpn:bnettable add:100:2:10.0.0.0/8
03:47:14:vpn:bestpath_hook route_tag_chacle ip bgp *nge for vpn2:10.0.0.0/255.0.0.0(ok)

The following example shows sample output, including the explicit-null label, from the debug ip bgp updates and the debug ip bgp mpls commands:

Router# debug ip bgp updates 
BGP updates debugging is on
Router# debug ip bgp mpls
BGP MPLS labels debugging is on

Router#
01:33:53: BGP(0): route 10.10.10.10/32 up
01:33:53: BGP(0): nettable_walker 10.10.10.10/32 route sourced locally
01:33:53: BGP: adding MPLS label to 10.10.10.10/32
01:33:53: BGP: check on 10.10.10.10/8 in LDP - ok
01:33:53: BGP: label imp-null allocated via LDP
01:33:53: BGP-IPv4: send exp-null label for 10.10.10.10/32
01:33:53: BGP-IPv4: Send prefix 10.10.10.10/32, label exp-null    !explicit-null label being sent
01:33:53: BGP(0): 10.10.10.11 send UPDATE (format) 10.10.10.10/32, next 10.10.10.12, metric 0, path , mpls label 0 !label value is 0
01:33:53: BGP(0): updgrp 1 - 10.10.10.12 enqueued 1 updates, average/maximum size (bytes) 61/61

Following example shows a sample output from the debug ip bgp command when various arguments are provided in a particular sequence:

Router# debug ip bgp 209.165.200.225
Router# debug ip bgp 209.165.200.225 updates
Router# debug ip bgp keepalives
Router# debug ip bgp events
Router# debug ip bgp in
Router# debug ip bgp out

Router# show debug 
IP routing:
  BGP debugging is on (outbound) for address family: IPv4 Unicast
  BGP events debugging is on
  BGP keepalives debugging is on
  BGP updates debugging is on (outbound) for address family: IPv4 Unicast

The behavior of the command changes when the arguments are provided in a different sequence

Router# debug ip bgp keepalives
Router# debug ip bgp events
Router# debug ip bgp in
Router# debug ip bgp out
Router# debug ip bgp 209.165.200.225
Router# debug ip bgp 209.165.200.225 updates

Router# show debug
IP routing:
  BGP debugging is on for neighbor 209.165.200.225 for address family: IPv4 Unicast
  BGP events debugging is on for neighbor 209.165.200.225
  BGP keepalives debugging is on for neighbor 209.165.200.225 for address family: IPv4 Unicast
  BGP updates debugging is on for neighbor 209.165.200.225 for address family: IPv4 Unicast

Examples

The following sample output from the debug ip bgp groups command shows that peering has been established with neighbor 10.4.9.8 and update-group calculations are occurring for this member:

Router# debug ip bgp groups
 
5w4d: BGP-DYN(0): Comparing neighbor 10.4.9.8 flags 0x0 cap 0x0 and updgrp 1 fl0
5w4d: BGP-DYN(0): Created update-group(0) flags 0x0 cap 0x0 from neighbor 10.4.0
5w4d: BGP-DYN(0): Adding  neighbor 10.4.9.8 flags 0x0 cap 0x0, to update-group 0
5w4d: %BGP-5-ADJCHANGE: neighbor 10.4.9.8 Up 

The following sample output from the debug ip bgp groups command shows the recalculation of update-groups after the clear ip bgp groups command was issued:

Router# debug ip bgp groups
 
5w4d: %BGP-5-ADJCHANGE: neighbor 10.4.9.5 Down User reset
5w4d: BGP-DYN(0): Comparing neighbor 10.4.9.5 flags 0x0 cap 0x0 and updgrp 2 fl0
5w4d: BGP-DYN(0): Update-group 2 flags 0x0 cap 0x0 policies same as 10.4.9.5 fl0
5w4d: %BGP-5-ADJCHANGE: neighbor 10.4.9.8 Down User reset
5w4d: BGP-DYN(0): Comparing neighbor 10.4.9.8 flags 0x0 cap 0x0 and updgrp 2 fl0
5w4d: BGP-DYN(0): Update-group 2 flags 0x0 cap 0x0 policies same as 10.4.9.8 fl0
5w4d: %BGP-5-ADJCHANGE: neighbor 10.4.9.21 Down User reset
5w4d: BGP-DYN(0): Comparing neighbor 10.4.9.21 flags 0x0 cap 0x0 and updgrp 1 f0
5w4d: BGP-DYN(0): Update-group 1 flags 0x0 cap 0x0 policies same as 10.4.9.21 f0
5w4d: %BGP-5-ADJCHANGE: neighbor 10.4.9.5 Up 
5w4d: %BGP-5-ADJCHANGE: neighbor 10.4.9.21 Up 
5w4d: %BGP-5-ADJCHANGE: neighbor 10.4.9.8 Up 

The table below describes the significant fields shown in the display.

Examples

The following example turns on debugging of events related to the system ignoring the IGP metric during bestpath selection:

Router# debug ip bgp igp-metric ignore

Examples

The following example configures IPv4 prefix import debugging messages for both import events and import updates to be displayed on the console of the router:

Router# debug ip bgp import events
 
BGP import events debugging is on
Router# debug ip bgp import updates
BGP import updates debugging is on for access list 3
00:00:50: %BGP-5-ADJCHANGE: neighbor 10.2.2.2 Up 
00:01:06: BGP: reevaluate IPv4 Unicast routes in VRF academic
00:01:06: BGP: 0 routes available (limit: 1000)
00:01:06: BGP: import IPv4 Unicast routes to VRF academic
00:01:06: BGP(2)-VRF(academic): import pfx 100:1:10.30.1.0/24 via 10.2.2.2
00:01:06: BGP: accepted 8 routes (limit: 1000)
00:01:06: BGP: reevaluate IPv4 Multicast routes in VRF multicast
00:01:06: BGP: 0 routes available (limit: 2)
00:01:06: BGP: import IPv4 Multicast routes to VRF multicast
00:01:06: %BGP-4-AFIMPORT: IPv4 Multicast prefixes imported to multicast vrf reached the 
limit 2
00:01:06: BGP: accepted 2 routes (limit: 2)
00:01:06: BGP: reevaluate IPv4 Unicast routes in VRF BLUE 
00:01:06: BGP: 0 routes available (limit: 1000)
00:01:06: BGP: import IPv4 Unicast routes to VRF BLUE 
00:01:06: BGP: accepted 3 routes (limit: 1000)

The table below describes the significant fields shown in the display.

The following is a sample debug message for the IP prefix export from a VRF table to global table:

Device# debug ip bgp import events
 
*Jul 12 10:06:48.357: BGP GBL-IMP: vpn1:VPNv4 Unicast:base 1:1:192.168.4.0/24
-> global:IPv4 Unicast:base Creating importing net.
  4.4.4.4 (metric 11) from 4.4.4.4 (4.4.4.4)
   Origin IGP, metric 0, localpref 100, valid, internal, best
   Extended Community: RT:1:1
   mpls labels in/out nolabel/16

Examples

The following output shows that the debug ip bgp range command has been entered and a BGP neighbor at 192.168.3.2 has been dynamically created using the subnet range 192.168.0.0/16. This new neighbor is a member of the peer group named group192.

Router# debug ip bgp range
bgprange_debug = 1, sense = 1
BGP dynamic Range debugging is on
!
*Mar 26 20:05:13.251: BGP:DN: Created a new neighbor *192.168.3.2
in range 192.168.0.0/16, peer-group group192,count = 1

The following sample output from the debug ip bgp range detail command shows more detailed debugging of the addition of dynamic BGP neighbors:

Router# debug ip bgp range detail
bgprange_debug = 1, sense = 1
BGP dynamic Range debugging is on with detail (Dynamic Range neighbors details only)
!
*Mar 26 20:09:12.311: BGP:DN: ACCEPT an OPEN from 192.168.1.2 valid range
0x32123D8:192.168.0.0/16,tcb 0x32114C0 
!
*Mar 26 20:09:12.331: BGP: 192.168.1.2 passive open to 192.168.1.1
*Mar 26 20:09:12.331: BGP:DN: ACCEPTED an OPEN from 192.168.1.2 valid range
0x32123D8:192.168.0.0/16,tcb 0x3494040 
!
*Mar 26 20:09:12.331: BGP:DN: Created a new neighbor *192.168.1.2
in range 192.168.0.0/16, peer-group group192,count = 2

The table below describes the significant field shown in the display.

Examples

The following is sample output from the debug ip bgp sso command with the events keyword. The following output indicates that the 10.34.32.154 BGP session is no longer SSO capable.

*Mar 28 02:29:43.526: BGPSSO: 10.34.32.154 reset SSO and decrement count

Tip	Use the show ip bgp vpnv4 all neighborscommand to display the reason that the SSO-capable BGP session has been disabled.

The following is sample output from the debug ip bgp sso command with the transactions keyword. The following output shows an SSO notification indicating that the SSO capability is pending for 602 BGP neighbors. This notification is generated as the state between the active and standby RP is being synchronized during the bulk synchonization phase of SSO initialization. During this phase, the Transmission Control Blocks (TCBs) must be synchronized with the TCBs on the standby RP before SSO initialization is complete.

*Mar 28 02:32:12.102: BGPSSO: tcp sso notify pending for 602 nbrs

Examples

The following is sample output from the debug ip bgp updates command. The output shows that the BGP session was cleared between neighbor 10.4.9.21 and the local router 10.4.9.4. There are no field description tables for this command because the debugging output from this command depends on the subsequent commands that are entered.

Router# debug ip bgp updates
5w2d: %SYS-5-CONFIG_I: Configured from console by console
5w2d: BGP: 10.4.9.21 went from Idle to Active
5w2d: BGP: 10.4.9.21 open active, delay 7032ms
5w2d: BGP: 10.4.9.21 open active, local address 10.4.9.4
5w2d: BGP: 10.4.9.21 went from Active to OpenSent
5w2d: BGP: 10.4.9.21 sending OPEN, version 4, my as: 101
5w2d: BGP: 10.4.9.21 send message type 1, length (incl. header) 45
5w2d: BGP: 10.4.9.21 rcv message type 1, length (excl. header) 26
5w2d: BGP: 10.4.9.21 rcv OPEN, version 4
5w2d: BGP: 10.4.9.21 rcv OPEN w/ OPTION parameter len: 16
5w2d: BGP: 10.4.9.21 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
5w2d: BGP: 10.4.9.21 OPEN has CAPABILITY code: 1, length 4
5w2d: BGP: 10.4.9.21 OPEN has MP_EXT CAP for afi/safi: 1/1
5w2d: BGP: 10.4.9.21 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
5w2d: BGP: 10.4.9.21 OPEN has CAPABILITY code: 128, length 0
5w2d: BGP: 10.4.9.21 OPEN has ROUTE-REFRESH capability(old) for all address-fams
5w2d: BGP: 10.4.9.21 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
5w2d: BGP: 10.4.9.21 OPEN has CAPABILITY code: 2, length 0
5w2d: BGP: 10.4.9.21 OPEN has ROUTE-REFRESH capability for all address-families
5w2d: BGP: 10.4.9.21 went from OpenSent to OpenConfirm
5w2d: BGP: 10.4.9.21 went from OpenConfirm to Established
5w2d: %BGP-5-ADJCHANGE: neighbor 10.4.9.21 Up 
5w2d: BGP(0): 10.4.9.21 computing updates, afi 0, neighbor version 0, table ver0
5w2d: BGP(0): 10.4.9.21 update run completed, afi 0, ran for 0ms, neighbor vers1
5w2d: BGP(0): 10.4.9.21 initial update completed 

The following is sample output from the debug ip bgp updates outcommand. The output shows that the local router is sending updates with the cost community:

Router# debug ip bgp updates out
*Mar 15 01:41:23.515:BGP(0):10.0.0.5 computing updates, afi 0, neighbor version 0, table
version 64, starting at 0.0.0.0
*Mar 15 01:41:23.515:BGP(0):10.0.0.5 send UPDATE (format) 0.0.0.0/0, next 10.0.0.2, metric
0, path , extended community Cost:igp:1:100
*Mar 15 01:41:23.515:BGP(0):10.0.0.5 send UPDATE (format) 10.2.2.0/24, next 10.20.20.10,
metric 0, path 10, extended community Cost:igp:8:22
*Mar 15 01:41:23.515:BGP(0):10.0.0.5 send UPDATE (format) 10.13.13.0/24, next 10.0.0.8,
metric 0, path

The following is sample output from the debug ip bgp updates incommand. The output shows that the local router is receiving updates with the cost community:

Router# debug ip bgp updates in
*Jan  6 01:27:09.111:BGP(2):10.0.0.8 rcvd UPDATE w/ attr:nexthop 10.0.0.8, origin ?,
localpref 100, metric 0, path 10, extended community RT:100:1 Cost:igp:10:10
Cost:igp:11:11

Examples

The following example shows command output on the active Route Processor:

Router# debug ip bgp vpnv4 checkpoint
3d18h: %HA-5-SYNC_NOTICE: Config sync started.
3d18h: vrf-nsf: vrf vpn2 tableid 1 send OK
3d18h: vrf-nsf: vrf tableid bulk sync complete msg send OK
3d18h: vrf-nsf: CF send ok
3d18h: vrf-nsf: CF send ok
3d18h: %HA-5-SYNC_NOTICE: Config sync completed.
3d18h: %HA-5-SYNC_NOTICE: Standby has restarted.
3d18h: %HA-5-MODE: Operating mode is sso, configured mode is sso.

Examples

The following example shows the command output on the active Route Processor:

Router# debug ip bgp vpnv4 nsf
MPLS VPN NSF Processing debugging is on
Router(config)# ip vrf vpn3
3d18h: vrf-nsf: vrf vpn3 tableid 2 send rpc OK
Router(config-vrf)# no ip vrf vpn3
% IP addresses from all interfaces in VRF vpn3 have been removed
3d18h: vrf-nsf:  rx vrf tableid delete complete msg, tid = 2, name = vpn3

The following example shows the command output on the standby Route Processor:

Router# debug ip bgp vpnv4 nsf
MPLS VPN NSF Processing debugging is on
00:05:21: vrf-nsf: rx vrf tableid rpc msg, tid = 2, name = vpn3
% IP addresses from all interfaces in VRF vpn3 have been removed
00:06:22: vrf-nsf: vrf vpn3 tableid 2 , delete complete, send OK

Examples

The following example enables debugging of MPLS VPN label mode processing:

Router# debug ip bgp vpnv4 unicast labelmode
MPLS VPN Label mode processing debugging is on
Router# config terminal
 
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# mpls label mode all-vrfs protocol bgp-vpnv4 per-vrf
% This command is an unreleased and unsupported feature
Router(config)#
*Oct 18 11:35:01.159: vpn: changing the label mode (Enable: per-vrf) for all-vrfs
*Oct 18 11:35:01.459: vpn: label mode change, bnet walk complete.
*Oct 18 11:35:01.459: BGP: VPNv4 Unicast label mode changed
Router(config)#^Z
Router#
*Oct 18 11:35:21.995: %SYS-5-CONFIG_I: Configured from console by console
Router# show debug
 
Tag VPN:
  MPLS VPN Label mode processing debugging is on
Router#

Examples

The following example enables debugging of MPLS VPN label mode processing:

Router# debug ip bgp vpnv6 unicast labelmode 
MPLS VPN Label mode processing debugging is on
Router# config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# mpls label mode vrf vpn1 protocol bgp-vpnv6 per-vrf
% Command accepted but obsolete, unreleased or unsupported; see documentation.
Router(config)#
6d03h: vpn: changing the label mode (Enable: per-vrf) for vrf vpn1, address family ipv6
6d03h: vpn: setting pervrfaggr label 18 for vrf vpn1:2001:DB8:1:2::/96
6d03h: vpn: setting pervrfaggr label 18 for vrf vpn1:2001:DB8:2::1/128
6d03h: vpn: pervrfaggr, withdraw and free local label 19 for vpn1:2001:DB8:CE1::1/128
6d03h: vpn: setting pervrfaggr label 18 for vrf vpn1:2001:DB8:CE1::1/128
6d03h: vpn: label mode change, bnet walk complete.
6d03h: BGP: VPNv6 Unicast label mode changed
Router(config)# end

Examples

The following is sample output from the debug ip casa affinitiescommand:

Router# debug ip casa affinities
16:15:36:Adding fixed affinity:
16:15:36:    10.10.1.1:54787 -> 10.10.10.10:23 proto = 6
16:15:36:Updating fixed affinity:
16:15:36:    10.10.1.1:54787 -> 10.10.10.10:23 proto = 6
16:15:36:    flags = 0x2, appl addr = 10.10.3.2, interest = 0x5/0x100
16:15:36:    int ip:port = 10.10.2.2:1638, sequence delta = 0/0/0/0
16:15:36:Adding fixed affinity:
16:15:36:    10.10.10.10:23 -> 10.10.1.1:54787 proto = 6
16:15:36:Updating fixed affinity:
16:15:36:    10.10.10.10:23 -> 10.10.1.1:54787 proto = 6
16:15:36:    flags = 0x2, appl addr = 0.0.0.0, interest = 0x3/0x104
16:15:36:    int ip:port = 10.10.2.2:1638, sequence delta = 0/0/0/0

The table below describes the significant fields shown in the display.

Examples

The following is sample output from the debug ip casa packetscommand:

Router# debug ip casa packets
16:15:36:Routing CASA packet - TO_MGR:
16:15:36:    10.10.1.1:55299 -> 10.10.10.10:23 proto = 6
16:15:36:    Interest Addr:10.10.2.2   Port:1638
16:15:36:Routing CASA packet - FWD_PKT:
16:15:36:    10.10.1.1:55299 -> 10.10.10.10:23 proto = 6
16:15:36:    Fwd Addr:10.10.3.2
16:15:36:Routing CASA packet - TO_MGR:
16:15:36:    10.10.10.10:23 -> 10.10.1.1:55299 proto = 6
16:15:36:    Interest Addr:10.10.2.2   Port:1638
16:15:36:Routing CASA packet - FWD_PKT:
16:15:36:    10.10.10.10:23 -> 10.10.1.1:55299 proto = 6
16:15:36:    Fwd Addr:0.0.0.0
16:15:36:Routing CASA packet - TICKLE:
16:15:36:    10.10.10.10:23 -> 10.10.1.1:55299 proto = 6
16:15:36:    Interest Addr:10.10.2.2   Port:1638  Interest Mask:SYN 
16:15:36:    Fwd Addr:0.0.0.0
16:15:36:Routing CASA packet - FWD_PKT:
16:15:36:    10.10.1.1:55299 -> 10.10.10.10:23 proto = 6
16:15:36:    Fwd Addr:10.10.3.2

The table below describes the significant fields shown in the display.

Examples

The following is sample output from the debug ip casa wildcardscommand:

Router# debug ip casa wildcards
16:13:23:Updating wildcard affinity:
16:13:23:    10.10.10.10:0 -> 0.0.0.0:0 proto = 6
16:13:23:    src mask = 255.255.255.255, dest mask = 0.0.0.0
16:13:23:    no frag, not advertising
16:13:23:    flags = 0x0, appl addr = 0.0.0.0, interest = 0x8107/0x8104
16:13:23:    int ip:port = 10.10.2.2:1638, sequence delta = 0/0/0/0
16:13:23:Updating wildcard affinity:
16:13:23:    0.0.0.0:0 -> 10.10.10.10:0 proto = 6
16:13:23:    src mask = 0.0.0.0, dest mask = 255.255.255.255
16:13:23:    no frag, advertising
16:13:23:    flags = 0x0, appl addr = 0.0.0.0, interest = 0x8107/0x8102
16:13:23    int ip:port = 10.10.2.2:1638, sequence delta = 0/0/0/0

The table below describes the significant fields shown in the display.

Examples

The following is sample output from the debug ip cef rpfcommandfor a packet that is dropped when it fails the RPF check. IP address 172.17.249.252 is the source address, and Ethernet 2/0/0 is the input interface.

Router# debug ip cef drops rpf
IP CEF drops for RPF debugging is on
00:42:02:CEF-Drop:Packet from 172.17.249.252 via Ethernet2/0/0 -- unicast rpf check

The following is sample output for Cisco Express Forwarding packets that are not switched using information from the FIB table but are received and sent to the next switching layer:

Router# debug ip cef receive
IP CEF received packets debugging is on
00:47:52:CEF-receive:Receive packet for 10.1.104.13

The table below describes the significant fields shown in the display.

The following is sample output from the debug ip cef dialercommandfor a legacy dialer:

Router# debug ip cef dialer
00:19:50:CEF-Dialer (legacy):add link to 10.10.10.2 via Dialer1 through BRI0/0:1
00:19:50:CEF-Dialer:adjacency added:0x81164850
00:19:50:CEF-Dialer:adjacency found:0x81164850; fib->count:1
00:19:50:CEF-Dialer:setup loadinfo with 1 paths

The following is sample output from the debug ip cef dialer command for a dialer profile:

Router# debug ip cef dialer
00:31:44:CEF-Dialer (profile dynamic encap (not MLP)):add link to 10.10.10.2 via Dialer1 through Dialer1
00:31:44:CEF-Dialer:adjacency added:0x81164850
00:31:44:CEF-Dialer:adjacency found:0x81164850; fib->count:1

The table below describes the significant fields shown in the display.

Examples

The following is sample output from the debug ip cef accounting non-recursive command:

Router# debug ip cef accounting non-recursive
03:50:19:CEF-Acct:tmstats_binary:Beginning generation of tmstats 
ephemeral file (mode binary)
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF2000
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF1EA0
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF17C0
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF1D40
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF1A80
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF0740
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF08A0
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF0B60
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF0CC0
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF0F80
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF10E0
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF1240
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF13A0
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF1500
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF1920
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF0E20
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF1660
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF05E0
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF0A00
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF1BE0
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF0480
03:50:19:CEF-Acct:tmstats_binary:aggregation complete, duration 0 seconds
03:50:21:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:24:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:24:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:27:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:29:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:32:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:35:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:38:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:41:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:45:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:48:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:49:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:52:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:55:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:57:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:57:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:57:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:57:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:57:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:57:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:57:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:57:CEF-Acct:tmstats_binary:tmstats file written, status 0

The table below describes the significant fields shown in the display.

Examples

The following is sample output from the debug ip cef fragmentationcommand:

Router# debug ip cef fragmentation
00:59:45:CEF-FRAG:no_fixup path:network_start 0x5397CF8E datagramstart 0x5397CF80 data_start 0x397CF80 data_block 0x397CF40 mtu 1000 datagramsize 1414 data_bytes 1414
00:59:45:CEF-FRAG:send frag:datagramstart 0x397CF80 datagramsize 442 data_bytes 442
00:59:45:CEF-FRAG:send frag:datagramstart 0x38BC266 datagramsize 1006 data_bytes 1006
00:59:45:CEF-FRAG:no_fixup path:network_start 0x5397C60E datagramstart 0x5397C600 data_start 0x397C600 data_block 0x397C5C0 mtu 1000 datagramsize 1414 data_bytes 1414
00:59:45:CEF-FRAG:send frag:datagramstart 0x397C600 datagramsize 442 data_bytes 442
00:59:45:CEF-FRAG:send frag:datagramstart 0x38BC266 datagramsize 1006 data_bytes 1006

The table below describes the significant fields shown in the display.

Examples

The following is sample output from the debug ip cef hashcommand with IP Cisco Express Forwarding load algorithm tunnel information:

Router# debug ip cef hash
01:15:06:%CEF:ip cef load-sharing algorithm tunnel 0
01:15:06:%CEF:Load balancing algorithm:tunnel
01:15:06:%CEF:Load balancing unique id:1F2BA5F6
01:15:06:%CEF:Destroyed load sharing hash table
01:15:06:%CEF:Sending hash algorithm id 2, unique id 1F2BA5F6 to slot 255

The following lines show IP Cisco Express Forwarding load algorithm universal information:

01:15:28:%CEF:ip cef load-sharing algorithm universal 0
01:15:28:%CEF:Load balancing algorithm:universal
01:15:28:%CEF:Load balancing unique id:062063A4
01:15:28:%CEF:Creating load sharing hash table
01:15:28:%CEF:Hash table columns for valid max_index:
01:15:28:12: 9  7  7 4  4 10  0  7 10  4  5  0  4  7  8  4
01:15:28:15: 3 10 10  4 10  4  0  7  1  7 14  6 13 13 11 13
01:15:28:16: 1  3  7 12  4 14  8  7 10  4  1 12  8 15  4  8
01:15:28:%CEF:Sending hash algorithm id 3, unique id 062063A4 to slot 255

The table below describes the significant fields shown in the display.

Examples

The following is sample output from the debug ip cef rrhashcommand:

Router# debug ip cef rrhash
00:27:15:CEF:rrhash/check:found 10.1.104.7 on down idb [ok to delete]
00:27:15:CEF:rrhash/check:found 10.1.104.0 on down idb [ok to delete]
00:27:15:CEF:rrhash/check:found 10.1.104.255 on down idb [ok to delete]
00:27:15:CEF:rrhash/check:found 10.1.104.7 on down idb [ok to delete]
00:27:15:CEF:rrhash/check:found 10.1.104.7 on down idb [ok to delete]
00:27:15:CEF:rrhash/check:found 10.1.104.0 on down idb [ok to delete]
00:27:15:CEF:rrhash/check:found 10.1.104.255 on down idb [ok to delete]
00:27:15:CEF:rrhash/check:found 10.1.104.7 on down idb [ok to delete]

The table below describes the significant fields shown in the display.

Examples

The following is sample output from the debug ip cef subblockcommand:

Router# debug ip cef subblock
00:28:12:CEF-SB:Creating unicast RPF subblock for FastEthernet6/0
00:28:12:CEF-SB:Linked unicast RPF subblock to FastEthernet6/0.
00:28:12:CEF-SB:Encoded unit of unicast RPF data (length 16) for FastEthernet6/0
00:28:12:CEF-SB:Sent 1 data unit to slot 6 in 1 XDR message

Examples

The following is sample output from the debug ip cef subblockcommand:

Router# debug ip cef subblock
00:28:12:CEF-SB:Creating unicast RPF subblock for FastEthernet6/0/0
00:28:12:CEF-SB:Linked unicast RPF subblock to FastEthernet6/0/0.
00:28:12:CEF-SB:Encoded unit of unicast RPF data (length 16) for FastEthernet6/0/0
00:28:12:CEF-SB:Sent 1 data unit to slot 6 in 1 XDR message

The table below describes the significant fields shown in the display.

Examples

The following is sample output from the debug ip cef table command:

Router# debug ip cef table
01:25:46:CEF-Table:Event up, 10.1.1.1/32 (rdbs:1, flags:1000000)
01:25:46:CEF-IP:Checking dependencies of 0.0.0.0/0
01:25:47:CEF-Table:attempting to resolve 10.1.1.1/32
01:25:47:CEF-IP:resolved 10.1.1.1/32 via 10.1.104.1 to 10.1.104.1 Ethernet2/0/0
01:26:02:CEF-Table:Event up, default, 0.0.0.0/0 (rdbs:1, flags:400001)
01:26:02:CEF-IP:Prefix exists - no-op change

Examples

The following is sample output from the debug ip cef table command:

Router# debug ip cef table
01:25:46:CEF-Table:Event up, 10.1.1.1/32 (rdbs:1, flags:1000000)
01:25:46:CEF-IP:Checking dependencies of 0.0.0.0/0
01:25:47:CEF-Table:attempting to resolve 10.1.1.1/32
01:25:47:CEF-IP:resolved 10.1.1.1/32 via 10.1.104.1 to 10.1.104.1  GigabitEthernet2/0/0
01:26:02:CEF-Table:Event up, default, 0.0.0.0/0 (rdbs:1, flags:400001)
01:26:02:CEF-IP:Prefix exists - no-op change

The table below describes the significant fields shown in the display.

Examples

Use the debug ip ddns update command to verify that your configurations are working properly. The following sample configurations are shown for demonstration of possible debug output that could display for each configuration.

Examples

The following scenario has a client configured for IETF DDNS updating of address (A) Resource Records (RRs) during which a Dynamic Host Configuration Protocol (DHCP) server is expected to update the pointer (PTR) RR. The DHCP client discovers the domain name system (DNS) server to update using an Start of Authority (SOA) RR lookup since the IP address to the server to update is not specified. The DHCP client is configured to include an fully qualified domain name (FQDN) DHCP option and notifies the DHCP server that it will be updating the A RRs.

!DHCP Client Configuration
ip ddns update method testing
 ddns
interface Ethernet1
 ip dhcp client update dns
 ip ddns update testing
 ip address dhcp
end
!DHCP Server Configuration
ip dhcp pool test
 network 10.0.0.0 255.0.0.0
 update dns
!Debug Output Enabled
Router# debug ip ddns update
00:14:39: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet1 assigned DHCP address 10.0.0.4, mask 255.0.0.0, hostname canada_reserved
00:14:39: DYNDNSUPD: Adding DNS mapping for canada_reserved.hacks <=> 10.0.0.4
00:14:39: DYNDNSUPD: Sleeping for 3 seconds waiting for interface Ethernet1 configuration to settle
00:14:42: DHCPC: Server performed PTR update
00:14:42: DDNS: Enqueuing new DDNS update 'canada_reserved.hacks' <=> 10.0.0.4
00:14:42: DDNS: Zone name for 'canada_reserved.hacks' is 'hacks'
00:14:42: DDNS: Dynamic Update 1: (sending to server 10.19.192.32)
00:14:42: DDNS:   Zone = hacks
00:14:42: DDNS:   Prerequisite: canada_reserved.hacks not in use
00:14:42: DDNS:   Update: add canada_reserved.hacks IN A 10.0.0.4
00:14:42: DDNS: Dynamic DNS Update 1 (A) for host canada_reserved.hacks returned 0 (NOERROR)
00:14:42: DDNS: Update of 'canada_reserved.hacks' <=> 10.0.0.4 finished
00:14:42: DYNDNSUPD: Another update completed (total outstanding=0)

Examples

The following scenario has the client configured for IETF DDNS updating of both A and DNS RRs and requesting that the DHCP server update neither. The DHCP client discovers the DNS server to update using an SOA RR lookup since the IP address to the server to update is not specified. The DHCP client is configured to include an FQDN DHCP option that instructs the DHCP server to not update either A or PTR RRs.

!DHCP Client Configuration
ip dhcp-client update dns server none
ip ddns update method testing
 ddns both
interface Ethernet1
 ip ddns update testing
 ip address dhcp
end
!DHCP Server Configuration
ip dhcp pool test
 network 10.0.0.0 255.0.0.0
 update dns
!Debug Output Enabled
Router# debug ip ddns update
00:15:33: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet1 assigned DHCP address 10.0.0.5, mask 255.0.0.0, hostname canada_reserved
00:15:33: DYNDNSUPD: Adding DNS mapping for canada_reserved.hacks <=> 10.0.0.5
00:15:33: DYNDNSUPD: Sleeping for 3 seconds waiting for interface Ethernet1 configuration to settle
00:15:36: DDNS: Enqueuing new DDNS update 'canada_reserved.hacks' <=> 10.0.0.5
00:15:36: DDNS: Zone name for '10.0.0.11.in-addr.arpa.' is '10.in-addr.arpa'
00:15:36: DDNS: Dynamic Update 1: (sending to server 10.19.192.32)
00:15:36: DDNS:   Zone = 10.in-addr.arpa
00:15:36: DDNS:   Prerequisite: 10.0.0.11.in-addr.arpa. not in use
00:15:36: DDNS:   Update: add 10.0.0.11.in-addr.arpa. IN PTR canada_reserved.hacks
00:15:36: DDNS: Dynamic DNS Update 1 (PTR) for host canada_reserved.hacks returned 0 (NOERROR)
00:15:36: DDNS: Zone name for 'canada_reserved.hacks' is 'hacks'
00:15:36: DDNS: Dynamic Update 1: (sending to server 10.19.192.32)
00:15:36: DDNS:   Zone = hacks
00:15:36: DDNS:   Prerequisite: canada_reserved.hacks not in use
00:15:36: DDNS:   Update: add canada_reserved.hacks IN A 10.0.0.5
00:15:36: DDNS: Dynamic DNS Update 1 (A) for host canada_reserved.hacks returned 0 (NOERROR)
00:15:36: DDNS: Update of 'canada_reserved.hacks' <=> 10.0.0.5 finished
00:15:36: DYNDNSUPD: Another update completed (total outstanding=0)

Examples

The following scenario has the client configured for IETF DDNS updating of both A and DNS RRs and requesting that the DHCP server update neither. The DHCP client explicitly specifies the server to update. The DHCP client is configured to include an FQDN DHCP option that instructs the DHCP server not to update either A or PTR RRs. The configuration is performed using the ip dhcp client update dns command. The DHCP server is configured to override the client request and update both A and PTR RR anyway.

!DHCP Client Configuration
ip dhcp client update dns server none
ip ddns update method testing
 ddns both
interface Ethernet1
 ip dhcp client update dns server none
 ip ddns update testing
 ip address dhcp
end
!DHCP Server Configuration
ip dhcp pool test
 network 10.0.0.0 255.0.0.0
 update dns both override
!Debug Output Enabled on DHCP Client
Router# debug ip ddns update
00:16:30: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet1 assigned DHCP address 10.0.0.6, mask 255.0.0.0, hostname canada_reserved
00:16:30: DYNDNSUPD: Adding DNS mapping for canada_reserved.hacks <=> 10.0.0.6
00:16:30: DYNDNSUPD: Sleeping for 3 seconds waiting for interface Ethernet1 configuration to settle
00:16:33: DHCPC: Server performed both updates

Examples

The following scenario has the client configured for IETF DDNS updating of both A and DNS RRs and requesting the DHCP server to update neither. The DHCP client is configured to include an FQDN DHCP option which instructs the DHCP server not to update either A or PTR RRs. The DHCP server is configured to allow the client to update whatever RR it chooses.

!DHCP Client Configuration
ip dhcp client update dns server non
ip ddns update method testing
 ddns both
interface Ethernet1
 ip dhcp client update dns server none
 ip ddns update testing host 172.19.192.32
 ip address dhcp
end
!DHCP Server Configuration
ip dhcp pool test
 network 10.0.0.0 255.0.0.0
 update dns
!Debug Output Enabled on DHCP Client
Router# debug ip ddns update
00:17:52: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet1 assigned DHCP address 10.0.0.7, mask 255.0.0.0, hostname canada_reserved
00:17:52: DYNDNSUPD: Adding DNS mapping for canada_reserved.hacks <=> 10.0.0.6
00:17:52: DYNDNSUPD: Sleeping for 3 seconds waiting for interface Ethernet1 configuration to settle
00:17:55: DDNS: Enqueuing new DDNS update 'canada_reserved.hacks' <=> 10.0.0.7
00:17:55: DYNDNSUPD: Adding DNS mapping for canada_reserved.hacks <=> 10.0.0.7 server 10.19.192.32
00:17:55: DDNS: Enqueuing new DDNS update 'canada_reserved.hacks' <=> 10.0.0.7 server 10.19.192.32
00:17:55: DDNS: Zone name for '7.0.0.11.in-addr.arpa.' is '11.in-addr.arpa'
00:17:55: DDNS: Dynamic Update 1: (sending to server 10.19.192.32)
00:17:55: DDNS:   Zone = 11.in-addr.arpa
00:17:55: DDNS:   Prerequisite: 10.0.0.11.in-addr.arpa. not in use
00:17:55: DDNS:   Update: add 10.0.0.11.in-addr.arpa. IN PTR canada_reserved.hacks
00:17:55: DDNS: Zone name for '10.0.0.11.in-addr.arpa.' is '10.in-addr.arpa'
00:17:55: DDNS: Using server 10.19.192.32
00:17:55: DDNS: Dynamic Update 1: (sending to server 10.19.192.32)
00:17:55: DDNS:   Zone = 11.in-addr.arpa
00:17:55: DDNS:   Prerequisite: 10.0.0.11.in-addr.arpa. not in use
00:17:55: DDNS:   Update: add 10.0.0.11.in-addr.arpa. IN PTR canada_reserved.hacks
00:17:55: DDNS: Dynamic DNS Update 1 (PTR) for host canada_reserved.hacks returned 0 (NOERROR)
00:17:55: DDNS: Dynamic DNS Update 1 (PTR) for host canada_reserved.hacks returned 6 (YXDOMAIN)
00:17:55: DDNS: Dynamic Update 2: (sending to server 10.19.192.32)
00:17:55: DDNS:   Zone = 11.in-addr.arpa
00:17:55: DDNS:   Update: delete 10.0.0.11.in-addr.arpa. all PTR RRs
00:17:55: DDNS:   Update: add 10.0.0.11.in-addr.arpa. IN PTR canada_reserved.hacks
00:17:55: DDNS: Dynamic DNS Update 2 (PTR) for host canada_reserved.hacks returned 0 (NOERROR)
00:17:55: DDNS: Zone name for 'canada_reserved.hacks' is 'hacks'
00:17:55: DDNS: Dynamic Update 1: (sending to server 10.19.192.32)
00:17:55: DDNS:   Zone = hacks
00:17:55: DDNS:   Prerequisite: canada_reserved.hacks not in use
00:17:55: DDNS:   Update: add canada_reserved.hacks IN A 10.0.0.7
00:17:55: DDNS: Dynamic DNS Update 1 (A) for host canada_reserved.hacks returned 0 (NOERROR)
00:17:55: DDNS: Update of 'canada_reserved.hacks' <=> 10.0.0.7 finished
00:17:55: DYNDNSUPD: Another update completed (total outstanding=1)
00:17:55: DDNS: Zone name for 'canada_reserved.hacks' is 'hacks'
00:17:55: DDNS: Using server 10.19.192.32
00:17:55: DDNS: Dynamic Update 1: (sending to server 10.19.192.32)
00:17:55: DDNS:   Zone = hacks
00:17:55: DDNS:   Prerequisite: canada_reserved.hacks not in use
00:17:55: DDNS:   Update: add canada_reserved.hacks IN A 10.0.0.7
00:17:55: DDNS: Dynamic DNS Update 1 (A) for host canada_reserved.hacks returned 6 (YXDOMAIN)
00:17:55: DDNS: Dynamic Update 2: (sending to server 10.19.192.32)
00:17:55: DDNS:   Zone = hacks
00:17:55: DDNS:   Update: delete canada_reserved.hacks all A RRs
00:17:55: DDNS:   Update: add canada_reserved.hacks IN A 10.0.0.7
00:17:55: DDNS: Dynamic DNS Update 2 (A) for host canada_reserved.hacks returned 0 (NOERROR)
00:17:55: DDNS: Update of 'canada_reserved.hacks' <=> 10.0.0.7 finished
00:17:55: DYNDNSUPD: Another update completed (total outstanding=0)

Examples

In the following scenario, the debug output displays the internal host table updates when the default domain name is hacks. The update method named test specifies that the internal Cisco IOS software host table should be updated. Configuring the update method as “test” should be used when the address on the Ethernet interface 0/0 changes. The hostname is configured for the update on this interface.

!Cisco IOS Software Configuration
ip domain name hacks
ip ddns update method test
 internal
interface ethernet0/0
 ip ddns update test hostname test2
 ip addr dhcp
!Debug Output Enabled
Router# debug ip ddns update
*Jun 4 03:11:10.591: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet0/0 assigned DHCP address 10.0.0.5, mask 255.0.0.0, hostname test2
*Jun 4 03:11:10.591: DYNDNSUPD: Adding DNS mapping for test2.hacks <=> 10.0.0.5
*Jun 4 03:11:10.591: DYNDNSUPD: Adding internal mapping test2.hacks <=> 10.0.0.5

Using the show hosts command displays the newly added host table entry.

Router# show hosts
Default domain is hacks
Name/address lookup uses domain service
Name servers are 255.255.255.255
Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate
       temp - temporary, perm - permanent
       NA - Not Applicable None - Not defined
Host                      Port Flags      Age Type   Address(es)
test2.hacks               None (perm, OK) 0   IP    10.0.0.5

Shutting down the interface removes the host table entry.

interface ethernet0/0
 shutdown
*Jun 4 03:14:02.107: DYNDNSUPD: Removing DNS mapping for test2.hacks <=> 10.0.0.5
*Jun 4 03:14:02.107: DYNDNSUPD: Removing mapping test2.hacks <=> 10.0.0.5

Using the show hosts command confirms that the entry has been removed.

Router# show hosts
Default domain is hacks
Name/address lookup uses domain service
Name servers are 255.255.255.255
Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate
       temp - temporary, perm - permanent
       NA - Not Applicable None - Not defined
Host                      Port Flags      Age Type   Address(es)

Examples

In the following scenario, the debug output shows the HTTP-style DDNS updates. The sample configuration defines a new IP DDNS update method named dyndns that configures a URL to use when adding or changing an address. No URL has been defined for use when removing an address since DynDNS.org does not use such a URL for free accounts. A maximum update interval of 28 days has been configured, which specifies that updates should be sent at least every 28 days. Configuring the new “dyndns” update method should be used for Ethernet interface 1.

!DHCP Client Configuration
ip ddns update method dyndns
 http
    add http://test:test@<s>/nic/update?system=dyndns&hostname=<h>&myip=<a>
    interval max 28 0 0 0
interface ethernet1
 ip ddns update hostname test.dyndns.org
 ip ddns update dyndns host members.dyndns.org
 ip addr dhcp
!Debugging Enabled
Router# debug ip ddns update
00:04:35: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet1 assigned DHCP address 10.32.254.187, mask 255.255.255.240, hostname test.dyndns.org
00:04:35: DYNDNSUPD: Adding DNS mapping for test.dyndns.org <=> 10.32.254.187 server 63.208.196.94
00:04:35: DYNDNSUPD: Sleeping for 3 seconds waiting for interface Ethernet1 configuration to settle
00:04:38: HTTPDNS: Update add called for test.dyndns.org <=> 10.32.254.187
00:04:38: HTTPDNS: Update called for test.dyndns.org <=> 10.32.254.187
00:04:38: HTTPDNS: init
00:04:38: HTTPDNSUPD: Session ID = 0x7
00:04:38: HTTPDNSUPD: URL = 'http://test:test@63.208.196.94/nic/update?system=dyndns&hostname=test.dyndns.org&myip=10.32.254.187'
00:04:38: HTTPDNSUPD: Sending request
00:04:40: HTTPDNSUPD: Response for update test.dyndns.org <=> 10.32.254.187
00:04:40: HTTPDNSUPD: DATA START
good 10.32.254.187
00:04:40: HTTPDNSUPD: DATA END, Status is Response data received, successfully
00:04:40: HTTPDNSUPD: Call returned SUCCESS for update test.dyndns.org <=> 10.32.254.187
00:04:40: HTTPDNSUPD: Freeing response
00:04:40: DYNDNSUPD: Another update completed (outstanding=0, total=0)
00:04:40: HTTPDNSUPD: Clearing all session 7 info
!28 days later, the automatic update happens.
00:05:39: DYNDNSUPD: Adding DNS mapping for test.dyndns.org <=> 10.32.254.187 server 63.208.196.94
00:05:39: HTTPDNS: Update add called for test.dyndns.org <=> 10.32.254.187
00:05:39: HTTPDNS: Update called for test.dyndns.org <=> 10.32.254.187
00:05:39: HTTPDNS: init
00:05:39: HTTPDNSUPD: Session ID = 0x8
00:05:39: HTTPDNSUPD: URL = 'http://test:test@63.208.196.94/nic/update?system=dyndns&hostname=test.dyndns.org&myip=10.32.254.187'
00:05:39: HTTPDNSUPD: Sending request
00:05:39: HTTPDNSUPD: Response for update test.dyndns.org <=> 10.32.254.187
00:05:39: HTTPDNSUPD: DATA START
nochg 10.32.254.187
00:05:39: HTTPDNSUPD: DATA END, Status is Response data received, successfully
00:05:39: HTTPDNSUPD: Call returned SUCCESS for update test.dyndns.org <=> 10.32.254.187
00:05:39: HTTPDNSUPD: Freeing response
00:05:39: DYNDNSUPD: Another update completed (outstanding=0, total=0)
00:05:39: HTTPDNSUPD: Clearing all session 8 info

The table below describes the significant fields shown in the output.

Examples

The following example configures a DFP agent debugging session:

Router# debug ip dfp agent
DFP debugging is on

The following example stops all debugging:

Router# no debug all
All possible debugging has been turned off

Examples

The following example shows a combination of DHCP server events and decoded receptions and transmissions:

Router# debug ip dhcp server events
 
Router# debug ip dhcp server packets
 
DHCPD:DHCPDISCOVER received from client 0b07.1134.a029 through relay 10.1.0.253.
DHCPD:assigned IP address 10.1.0.3 to client 0b07.1134.a029.
DHCPD:Sending DHCPOFFER to client 0b07.1134.a029 (10.1.0.3).
DHCPD:unicasting BOOTREPLY for client 0b07.1134.a029 to relay 10.1.0.253.
DHCPD:DHCPREQUEST received from client 0b07.1134.a029.
DHCPD:Sending DHCPACK to client 0b07.1134.a029 (10.1.0.3).
DHCPD:unicasting BOOTREPLY for client 0b07.1134.a029 to relay 10.1.0.253.
DHCPD:checking for expired leases.

The following example shows database linkage information:

Router# debug ip dhcp server linkage
 
DHCPD:child pool:10.1.0.0 / 255.255.0.0 (subnet10.1)
DHCPD:parent pool:10.0.0.0 / 255.0.0.0 (net10)
DHCPD:child pool:10.0.0.0 / 255.0.0.0 (net10)
DHCPD:pool (net10) has no parent.
DHCPD:child pool:10.1.0.0 / 255.255.0.0 (subnet10.1)
DHCPD:parent pool:10.0.0.0 / 255.0.0.0 (net10)
DHCPD:child pool:10.0.0.0 / 255.0.0.0 (net10)
DHCPD:pool (net10) has no parent.

The following example shows when a DHCP class is removed:

Router# debug ip dhcp server class
DHCPD:deleting class CLASS1

The following example shows the debug output when the configured pattern does not match:

Router# debug ip dhcp server class
 
DHCPD:Searching for a match to 'relay-information
0106000 400020202020800060009e80b8800' in class CLASS1
DHCPD:Searching for a match to 'relay-information 0106000400020202020800060009e80b8800' in class CLASS1
DHCPD:Searching for a match to 'relay-information 0106000

The following example shows the debug output when you unconfigure a DHCP pattern in a DHCP class and then configure the pattern in the DHCP class:

Router# debug ip dhcp server class
 
DHCPD:pattern 'relay-information 123456' removed from class CLASS1
DHCPD:Added pattern 'relay-information 010600040002020202 0800060009e80b8800' for class CLASS1

The following example shows the debug output when the configured pattern does match:

Router# debug ip dhcp server class
 
DHCPD:Searching for a match to 'relay-information
0106000 400020202020800060009e80b8800' in class CLASS1
DHCPD:input pattern 'relay-information 010600040002020202 0800060009e80b8800' matches class CLASS1
DHCPD:input matches class CLASS1

The following example shows the debug output when static mappings are configured:

Router# debug ip dhcp server
Loading abc/static_pool from 10.19.192.33 (via Ethernet0): !
[OK - 333 bytes]
*May 26 23:14:21.259: DHCPD: contacting agent tftp://10.19.192.33/abc/static_pool (attempt 0)
*May 26 23:14:21.467: DHCPD: agent tftp://10.19.192.33/abc/static_pool is responding.
*May 26 23:14:21.467: DHCPD: IFS is ready.
*May 26 23:14:21.467: DHCPD: reading bindings from                              tftp://10.19.192.33/abc/static_pool.
*May 26 23:14:21.707: DHCPD: read 333 / 1024 bytes.
*May 26 23:14:21.707: DHCPD: parsing text line “*time* Apr 22 2002 11:31 AM”
*May 26 23:14:21.707: DHCPD: parsing text line “”
*May 26 23:14:21.707: DHCPD: parsing text line
!IP address Type Hardware address Lease expiration.
*May 26 23:14:21.707: DHCPD: parsing text line
“10.9.9.1/24 id 0063.6973.636f.2d30.3036.302e.3437”
*May 26 23:14:21.707: DHCPD: creating binding for 10.9.9.1
*May 26 23:14:21.707: DHCPD: Adding binding to radix tree (10.9.9.1)
*May 26 23:14:21.707: DHCPD: Adding binding to hash tree
*May 26 23:14:21.707: DHCPD: parsing text line
“10.9.9.4 id 0063.7363.2d30.3036.302e.3762.2e39.3634.632d”
*May 26 23:14:21.711: DHCPD: creating binding for 10.9.9.4
*May 26 23:14:21.711: DHCPD: Adding binding to radix tree (10.9.9.4)
*May 26 23:14:21.711: DHCPD: Adding binding to hash tree
*May 26 23:14:21.711: DHCPD: parsing text line “Infinite”
*May 26 23:14:21.711: DHCPD: parsing text line “”
*May 26 23:14:21.711: DHCPD: parsing text line
!IP address Interface-index Lease expiration VRF.
*May 26 23:14:21.711: DHCPD: parsing text line “*end*”
*May 26 23:14:21.711: DHCPD: read static bindings from tftp://10.19.192.33/smith/static_pool.

Examples

The following example displays debug messages regarding DHCP server and relay agent redundancy events. The last line (and only that line) is output when the debug ip dhcp server redundancy command is enabled. The line indicates that a binding update message has been sent to the standby for the IP address 10.0.0.2 in the pool named “test.”

Router# debug ip dhcp server redundancy
*Mar 22 10:32:21: DHCPD: assigned IP address 10.0.0.2 to client 0063.6973.636f.2d30.3030.342e.3465.6130.2e30.3831.632d.4661.312f.302e.31.
*Mar 22 10:32:21:  DHCPD: lease time = 3600
*Mar 22 10:32:21: DHCPD: dhcpd_lookup_route: host = 10.0.0.2
*Mar 22 10:32:21: DHCPD: dhcpd_lookup_route: index = 0
*Mar 22 10:32:21: DHCPD: dhcpd_create_and_hash_route: host = 10.0.0.2
*Mar 22 10:32:21: DHCPD: dhcpd_create_and_hash_route index = 0
*Mar 22 10:32:21: DHCPD: dhcpd_add_route: lease = 3600 
*Mar 22 10:32:21: DHCPD: dynamic sync completed for 10.0.0.2 in pool test

Examples

The following example shows how to enable debugging and display DHCP server SNMP debugging events:

Router# debug ip dhcp server snmp
 
00:18:01: DHCPD SNMP: pool 'pool1' 'high' utilization trap is ignored
00:18:18: DHCPD SNMP: pool 'pool1' 'low' utilization trap is ignored 
00:20:46: DHCPD SNMP: subnet 4.1.1.0 'high' utilization trap is ignored
00:21:03: DHCPD SNMP: subnet 4.1.1.0 'low' utilization trap is ignored 
00:18:01: DHCPD SNMP: subnet trap is not enabled
00:37:32: DHCPD SNMP: pool trap is not enabled
00:37:57: DHCPD SNMP: interface trap is not enabled
00:27:27: DHCPD SNMP: duplicate trap is not enabled

Examples

The following sample output from the debug ip dns name-list command shows the hostname pattern www.example.com being added to DNS name list 1 as a permit clause. Next, the hostname patterns www.example1.com and www.example2.com are added to DNS name list 2 as deny clauses and permit clauses, respectively. Finally, the hostname pattern www.example1.com is removed from DNS name list 2.

Router# debug ip dns name-list
 
DNS Name-list debugging is on
. 
. 
. 
Router# show debugging
 
DNS Name-list debugging is on
. 
. 
. 
Router# show logging
 
. 
. 
. 
*May 16 14:54:44.326: DNS_NAMELIST: adding permit 'WWW.EXAMPLE' to name-list 1
*May 16 14:54:44.910: DNS_NAMELIST: adding deny 'WWW.EXAMPLE1.COM' to name-list 2
*May 16 14:54:45.202: DNS_NAMELIST: adding permit 'WWW.EXAMPLE2.COM' to name-list 2
*May 16 19:32:20.881: DNS_NAMELIST: removing 'WWW.EXAMPLE1.COM' from name-list 2

Examples

The following sample output from the debug ip dns view command shows the default DNS view being configured:

Router# debug ip dns view
 
DNS View debugging is on
. 
. 
. 
Router# show debugging
 
DNS View debugging is on
. 
. 
. 
Router# show logging
 
. 
. 
. 
DNS_VIEW: creating view view1
DNS_VIEW: Clearing logging in view default
DNS_VIEW: Setting domain lookup in view default
DNS_VIEW: Setting domain name to cisco.com in view default
DNS_VIEW: Setting  domain list example1.com in view default
DNS_VIEW: Setting  domain list example1.com example2.com in view default
DNS_VIEW: Setting  domain list example1.com example2.com example3.com in view default
DNS_VIEW: Setting domain multicast to 192.0.2.10 in view default
DNS_VIEW: Setting domain lookup in view default
DNS_VIEW: Setting domain timeout to 7 in view default
DNS_VIEW: Setting domain retry to 7 in view default
DNS_VIEW: Setting  domain name-server 192.0.2.204 192.0.2.205 in view default
DNS_VIEW: Setting  domain name-server 192.0.2.204 192.0.2.205 192.0.2.206 in view default
DNS_VIEW: Setting domain name-server interface FastEthernet0/1 in view default
DNS_VIEW: Setting domain round-robin to 4 in view default
DNS_VIEW: Setting dns forwarding in view default
DNS_VIEW: Setting  dns forwarder 192.0.2.11 in view default
DNS_VIEW: Setting  dns forwarder 192.0.2.11 192.0.2.12 in view default
DNS_VIEW: Setting  dns forwarder 192.0.2.11 192.0.2.12 192.0.2.13 in view default

Examples

The following sample output from the debug ip dns vies-list command shows the addition of the DNS view list definition named userlist5. Next, five DNS views are added as members of the DNS view list.

Router# debug ip dns view-list
 
DNS View-list debugging is on
. 
. 
. 
Router# show debugging
 
DNS View-list debugging is on
. 
. 
. 
Router# show logging
 
*May 16 23:31:17.491: DNS_VIEWLIST: creating view-list userlist5
*May 16 23:31:17.711: DNS_VIEWLIST: adding member user1 vrf vpn101 order 10 to view-list userlist5
*May 16 23:31:18.583: DNS_VIEWLIST: adding member user2 vrf vpn102 order 20 to view-list userlist5
*May 16 23:31:19.851: DNS_VIEWLIST: adding member user3 vrf vpn103 order 30 to view-list userlist5
*May 16 23:31:21.007: DNS_VIEWLIST: adding member user4 vrf vpn204 order 45 to view-list userlist5
*May 16 23:31:22.199: DNS_VIEWLIST: adding member default order 60 to view-list userlist5

Examples

The following is sample output from the debug ip domain command:

Device> enable
Device# debug ip domain

Domain Name System debugging is on
Device#
*Jul 18 09:16:19.546: DNS: Incoming UDP query (id#8168)
*Jul 18 09:16:19.547: DNS: Type 1 DNS query (id#8168) for host 'abc.google.com' from 209.165.200.230(27106)
*Jul 18 09:16:19.547: DNS: Servicing request using view default
*Jul 18 09:16:19.547: search_nametype_index: abc.google.com
*Jul 18 09:16:19.547: search_nametype_index: found abc.google.com for abc.google.com
*Jul 18 09:16:19.547: search_nametype_index: abc.google.com
*Jul 18 09:16:19.547: search_nametype_index: found abc.google.com for abc.google.com
*Jul 18 09:16:19.547: search_nametype_index: google.com
*Jul 18 09:16:19.547: search_nametype_index: com
*Jul 18 09:16:19.547: search_nametype_index: abc.google.com
*Jul 18 09:16:19.547: search_nametype_index: found abc.google.com for abc.google.com
*Jul 18 09:16:19.547: DNS: Reply to client 209.165.200.230/27106 query A
*Jul 18 09:16:19.547: DNS: Finished processing query (id#8168) in 0.001 secs
*Jul 18 09:16:19.547: DNS: Sending response to 209.165.200.230/27106, len 48

 

Examples

The following is sample output from the debug ip domain replies command:

Device> enable
Device# debug ip domain replies 

Domain Name System Reply debugging is on


*Jul 18 09:17:22.868: DNS: Finished processing query (id#34422) in 0.000 secs
*Jul 18 09:17:23.663: DNS: Finished processing query (id#51171) in 0.000 secs
*Jul 18 09:17:23.665: DNS: Finished processing query (id#46198) in 0.000 secs

 

Examples

Device> enable
Device# debug ip domain replies detail

Domain Name System Reply debugging is on (detailed)


*Jul 18 09:17:58.635: DNS: Send reply from internal information:
*Jul 18 09:17:58.635: DOM: id=47025, response, opcode=0, aa=0, tc=0, rd=1, ra=1
*Jul 18 09:17:58.635:      rcode=0, qdcount=1, ancount=1, nscount=0, arcount=0
*Jul 18 09:17:58.635:      query name is abc.google.com, qtype=1, class=1
*Jul 18 09:17:58.635: Answer section:
*Jul 18 09:17:58.635:    Name='abc.google.com'
*Jul 18 09:17:58.635:    RR type=1, class=1, ttl=10, data length=4
*Jul 18 09:17:58.635:      IP=12.12.12.12
*Jul 18 09:17:58.635: Authority section:
*Jul 18 09:17:58.635: Additional record section:
*Jul 18 09:17:58.635: DNS: Finished processing query (id#47025) in 0.001 secs


*Jul 18 09:17:58.637: DNS: Send reply from internal information:
*Jul 18 09:17:58.637: DOM: id=25881, response, opcode=0, aa=0, tc=0, rd=1, ra=1
*Jul 18 09:17:58.637:      rcode=0, qdcount=1, ancount=1, nscount=0, arcount=0
*Jul 18 09:17:58.637:      query name is abc.google.com, qtype=1, class=1
*Jul 18 09:17:58.637: Answer section:
*Jul 18 09:17:58.637:    Name='abc.google.com'
*Jul 18 09:17:58.637:    RR type=1, class=1, ttl=10, data length=4
*Jul 18 09:17:58.637:      IP=12.12.12.12
*Jul 18 09:17:58.637: Authority section:
*Jul 18 09:17:58.637: Additional record section:
*Jul 18 09:17:58.637: DNS: Finished processing query (id#25881) in 0.001 secs


*Jul 18 09:17:58.638: DNS: Send reply from internal information:
*Jul 18 09:17:58.638: DOM: id=41387, response, opcode=0, aa=0, tc=0, rd=1, ra=1
*Jul 18 09:17:58.638:      rcode=0, qdcount=1, ancount=1, nscount=0, arcount=0
*Jul 18 09:17:58.638:      query name is abc.google.com, qtype=1, class=1
*Jul 18 09:17:58.638: Answer section:
*Jul 18 09:17:58.638:    Name='abc.google.com'
*Jul 18 09:17:58.638:    RR type=1, class=1, ttl=10, data length=4
*Jul 18 09:17:58.638:      IP=12.12.12.12
*Jul 18 09:17:58.638: Authority section:
*Jul 18 09:17:58.638: Additional record section:
*Jul 18 09:17:58.638: DNS: Finished processing query (id#41387) in 0.000 secs