-
Cisco IOS Release 12.0 Debug Command Reference
-
About This Manual
-
Using Debug Commands
-
Conditionally Triggered Debugging
-
Debug Commands (debug aaa accounting - debug appn trs)
-
Debug Commands (debug arap - debug channel packets)
-
Debug Commands (debug clns esis events - debug dialer events)
-
Debug Commands (debug dlsw - debug ip cef accounting non-recursive)
-
Debug Command (debug ip drp - debug ip packet)
-
Debug Commands (debug ip pim - debug ip wccp packets)
-
Debug Commands (debug ipx ipxwan - debug kerberos)
-
Debug Commands (debug lane client - debug local-ack state)
-
Debug Commands (debug modem - debug ppp)
-
Debug Commands (debug ppp bap - debug sdllc)
-
Debug Commands (debug serial interface - debug tacacs events)
-
Debug Commands (debug tag-switching adjacency - debug tag-switc
-
Debug Commands (debug tarp events - debug voip ccapi inout)
-
Debug Commands (debug vpdn - debug xns routing)
-
Appendix A: X.25 Cause and Diagnostic Codes
-
Appendix B: ISDN Switch Types, Codes, and Values
-
Table Of Contents
debug arap
Use the debug arap EXEC command to display AppleTalk Remote Access Protocol (ARAP) events. The no form of this command disables debugging output.
[no] debug arap {internal | memory | mnp4 | v42bis} [linenum [aux | console | tty | vty]]
Syntax Description
Usage Guidelines
Use the debug arap command with the debug callback command on access servers to debug dial-in and callback events.
Use the debug modem command to help catch problems related to ARAP auto-detection (that is, autoselect arap). These problems are very common and are most often caused by modems, which are the most common cause of failure in ARAP connection and configuration sessions.
Sample Display
The following is sample output from the debug arap internal command:
Router# debug arap internalARAP: ---------- SRVRVERSION ----------ARAP: ---------- ACKing 0 ----------ARAP: ---------- AUTH_CHALLENGE ----------arapsec_local_account setting up callbackARAP: ---------- ACKing 1 ----------ARAP: ---------- AUTH_RESPONSE ----------arap_startup initiating callback ARAP 2.0ARAP: ---------- CALLBACK ----------TTY7 Callback process initiated, user: dialback dialstring 40TTY7 Callback forced wait = 4 secondsTTY7 ARAP Callback Successful - await exec/autoselect pickupTTY7: Callback in effectARAP: ---------- STARTINFOFROMSERVER ----------ARAP: ---------- ACKing 0 ----------ARAP: ---------- ZONELISTINFO ----------ARAP: ---------- ZONELISTINFO ----------ARAP: ---------- ZONELISTINFO ----------ARAP: ---------- ZONELISTINFO ----------ARAP: ---------- ZONELISTINFO ----------Related Commands
debug callback
debug modemdebug arp
Use the debug arp EXEC command to display information on Address Resolution Protocol (ARP) transactions. The no form of this command disables debugging output.
[no] debug arp
Usage Guidelines
Use this command when some nodes on a TCP/IP network are responding, but others are not. It shows whether the router is sending ARPs and whether it is receiving ARPs.
Sample Display
The following is sample output from the debug arp command:
Router# debug arpIP ARP: sent req src 172.16.22.7 0000.0c01.e117, dst 172.16.22.96 0000.0000.0000IP ARP: rcvd rep src 172.16.22.96 0800.2010.b908, dst 172.16.22.7IP ARP: rcvd req src 172.16.6.10 0000.0c00.6fa2, dst 172.16.6.62IP ARP: rep filtered src 172.16.22.7 aa92.1b36.a456, dst 255.255.255.255 ffff.ffff.ffffIP ARP: rep filtered src 172.16.9.7 0000.0c00.6b31, dst 172.16.22.7 0800.2010.b908In the output, each line of output represents an ARP packet that the router sent or received. Explanations for the individual lines of output follow.
The first line indicates that the router at IP address 172.16.22.7 and MAC address 0000.0c01.e117 sent an ARP request for the MAC address of the host at 172.16.22.96. The series of zeros (0000.0000.0000) following this address indicate that the router is currently unaware of the MAC address.
IP ARP: sent req src 172.16.22.7 0000.0c01.e117, dst 172.16.22.96 0000.0000.0000The second line indicates that the router at IP address 172.16.22.7 receives a reply from the host at 172.16.22.96 indicating that its MAC address is 0800.2010.b908:
IP ARP: rcvd rep src 172.16.22.96 0800.2010.b908, dst 172.16.22.7The third line indicates that the router receives an ARP request from the host at 172.16.6.10 requesting the MAC address for the host at 172.16.6.62:
IP ARP: rcvd req src 172.16.6.10 0000.0c00.6fa2, dst 172.16.6.62The fourth line indicates that another host on the network attempted to send the router an ARP reply for its own address. The router ignores meaningless replies. Usually, meaningless replies happen if someone is running a bridge in parallel with the router and is allowing ARP to be bridged. This condition indicates a network misconfiguration.
IP ARP: rep filtered src 172.16.22.7 aa92.1b36.a456, dst 255.255.255.255 ffff.ffff.ffffThe fifth line indicates that another host on the network attempted to inform the router that it is on network 172.16.9.7, but the router does not know that the network is attached to a different router interface. The remote host (probably a PC or an X terminal) is misconfigured. If the router were to install this entry, it would deny service to the real machine on the proper cable.
IP ARP: rep filtered src 172.16.9.7 0000.0c00.6b31, dst 172.16.22.7 0800.2010.b908debug asp packet
Use the debug asp packet EXEC command to display information on all asynchronous security protocols operating on the router. The no form of this command disables debugging output.
[no] debug asp packet
Usage Guidelines
The router uses asynchronous security protocols such as ADT Security Systems, Inc., Adplex, and Diebold to transport alarm blocks between two devices (such as a security alarm system console and an alarm panel). The alarm blocks are transported in passthrough mode using BSTUN encapsulation.
Sample Display
The following is partial sample output from the debug asp packet command for asynchronous security protocols when packet debugging is enabled on an asynchronous line carrying Diebold alarm traffic. In this example, two polls are sent from the Diebold alarm console to two alarm panels that are multidropped from a single RS-232 interface. The alarm panels have device addresses F0 and F1. The example trace indicates that F1 is responding and F0 is not responding. At this point, you need to examine the physical link and possibly use a datascope to determine why the device is not responding.
Router# debug asp packet12:19:48: ASP: Serial5: ADI-Rx: Data (4 bytes): F1FF4C4212:19:49: ASP: Serial5: ADI-Tx: Data (1 bytes): 8812:19:49: ASP: Serial5: ADI-Rx: Data (4 bytes): F0FF9B9412:20:47: ASP: Serial5: ADI-Rx: Data (4 bytes): F1FF757B12:20:48: ASP: Serial5: ADI-Tx: Data (1 bytes): F312:20:48: ASP: Serial5: ADI-Rx: Data (4 bytes): F0FFB1BE12:21:46: ASP: Serial5: ADI-Rx: Data (4 bytes): F1FFE6E812:21:46: ASP: Serial5: ADI-Tx: Data (1 bytes): 6F12:21:46: ASP: Serial5: ADI-Rx: Data (4 bytes): F0FFC1CEdescribes the fields and messages.
Table 20 Debug ASP Packet Field Descriptions
debug atm errors
Use the debug atm errors EXEC command to display Asynchronous Transfer Mode (ATM) errors. The no form of this command disables debugging output.
[no] debug atm errors
Sample Display
The following is sample output from the debug atm errors command:
Router# debug atm errorsATM(ATM2/0): Encapsulation error, link=7, host=836CA86D.ATM(ATM4/0): VCD#7 failed to echo OAM. 4 triesThe first line of output indicates that a packet was routed to the ATM interface, but no static map was set up to route that packet to the proper virtual circuit.
The second line of output shows that an OAM F5 (virtual circuit) cell error occurred.
debug atm events
Use the debug atm events EXEC command to display ATM events. The no form of this command disables debugging output.
[no] debug atm events
Usage Guidelines
This command displays ATM events that occur on the ATM interface processor and is useful for diagnosing problems in an ATM network. It provides an overall picture of the stability of the network. In a stable network, the debug atm events command does not return any information. If the command generates numerous messages, the messages can indicate the possible source of problems.
When configuring or making changes to a router or interface for ATM, enable debug atm events. Doing so alerts you to the progress of the changes or to any errors that might result. Also use this command periodically when you suspect network problems.
Sample Display
The following is sample output from the debug atm events command:
Router# debug atm eventsRESET(ATM4/0): PLIM type is 1, Rate is 100Mbpsaip_disable(ATM4/0): state=1config(ATM4/0)aip_love_note(ATM4/0): asr=0x201aip_enable(ATM4/0)aip_love_note(ATM4/0): asr=0x4000aip_enable(ATM4/0): restarting VCs: 7aip_setup_vc(ATM4/0): vc:1 vpi:1 vci:1aip_love_note(ATM4/0): asr=0x200aip_setup_vc(ATM4/0): vc:2 vpi:2 vci:2aip_love_note(ATM4/0): asr=0x200aip_setup_vc(ATM4/0): vc:3 vpi:3 vci:3aip_love_note(ATM4/0): asr=0x200aip_setup_vc(ATM4/0): vc:4 vpi:4 vci:4aip_love_note(ATM4/0): asr=0x200aip_setup_vc(ATM4/0): vc:6 vpi:6 vci:6aip_love_note(ATM4/0): asr=0x200aip_setup_vc(ATM4/0): vc:7 vpi:7 vci:7aip_love_note(ATM4/0): asr=0x200aip_setup_vc(ATM4/0): vc:11 vpi:11 vci:11aip_love_note(ATM4/0): asr=0x200describes significant fields in the output.
The following line indicates that the ATM Interface Processor (AIP) was reset. The PLIM TYPE detected was 1, so the maximum rate is set to 100 Mbps.
RESET(ATM4/0): PLIM type is 1, Rate is 100MbpsThe following line indicates that the ATM Interface Processor (AIP) was given a shutdown command, but the current configuration indicates that the AIP should be up:
aip_disable(ATM4/0): state=1The following line indicates that a configuration command has been completed by the AIP:
aip_love_note(ATM4/0): asr=0x201The following line indicates that the AIP was given a no shutdown command to take it out of shutdown:
aip_enable(ATM4/0)The following line indicates that the AIP detected a carrier state change. It does not indicate that the carrier is down or up, only that it has changed.
aip_love_note(ATM4/0): asr=0x4000The following line of output indicates that the AIP enable function is restarting all PVCs automatically:
aip_enable(ATM4/0): restarting VCs: 7The following lines of output indicate that PVC 1 was set up and a successful completion code was returned:
aip_setup_vc(ATM4/0): vc:1 vpi:1 vci:1aip_love_note(ATM4/0): asr=0x200debug atm oam
Use the debug atm oam EXEC command to display ATM operation and maintenance (OAM) events. The no form of this command disables debugging output.
[no] debug atm oam
Sample Display
The following is sample output from the debug atm oam command:
Router# debug atm oamATM4/0(O): VCD:0x0 DM:0x300 *OAM Cell* Length:0x390000 0300 0070 007A 0018 0100 0000 05FF FFFF FFFF FFFF FFFF FFFF FFFF FFFFFFFF FFFF FFFF FFFF FF6A 6A6A 6A6A 6A6A 6A6A 6A6A 6A6A 6A6A 6A00 0000
debug atm packet
Use the debug atm packet EXEC command to display per-packet debugging output. The output reports information online when a packet is received or a transmit is attempted. The no form of this command disables debugging output.
[no] debug atm packet [interface atm number [vcd vcd-number] | vc vpi/vci | vc-name]
Syntax Description
Usage Guidelines
The debug atm packet command displays all process-level ATM packets for both outbound and inbound packets. This command is useful for determining whether packets are being received and transmitted correctly.
For transmitted packets, the information is displayed only after the protocol data unit (PDU) is entirely encapsulated and a next hop virtual circuit (VC) is found. If information is not displayed, the address translation probably failed during encapsulation. When a next hop VC is found, the packet is displayed exactly as it will be presented on the wire. Having a display indicates the packets are properly encapsulated for transmission.
For received packets, information is displayed for all incoming frames. The display can show whether the transmitting station properly encapsulates the frames. Because all incoming frames are displayed, this information is useful when performing back-to-back testing and corrupted frames cannot be dropped by an intermediary ATM switch.
The debug atm packet command also displays the initial bytes of the actual PDU in hexadecimal. This information can be decoded only by qualified support or engineering personnel.
Note
Because the debug atm packet command generates a significant amount of output for every packet processed, use it only when traffic on the network is low, so other activity on the system is not adversely affected.
Sample Display
The following is sample output from the debug atm packet command:
Router# debug atm packetATM2/0.5(I): VCD:0x9 VCI:0x23 Type:0x0 SAP:AAAA CTL:03 OUI:000000 TYPE:0800 Length0x704500 002E 0000 0000 0209 92ED 836C A26E FFFF FFFF 1108 006D 0001 0000 0000A5CC 6CA2 0000 000A 0000 6411 76FF 0100 6C08 00FF FFFF 0003 E805 DCFF 0105
The following two lines of output are the binary data, which are the contents of the protocol PDU before encapsulation at the ATM:
4500 002E 0000 0000 0209 92ED 836C A26E FFFF FFFF 1108 006D 0001 0000 0000A5CC 6CA2 0000 000A 0000 6411 76FF 0100 6C08 00FF FFFF 0003 E805 DCFF 0105debug atm pvcd
Use the debug atm pvcd EXEC command to display the PVC Discovery events and ILMI MIB traffic used when discovering PVCs. The no form of this command disables debugging output.
[no] debug atm pvcd
Usage Guidelines
This command is primarily used by your technical support representative.
Sample Display
The following is sample output from the debug atm pvcd command:
Router# debug atm pvcdPVCD: PVCD enabled w/ SubifPVCD(ATM2/0): clearing event queuePVCD: ATM2/0 Forgetting discovered PVCs...PVCD: Removing all dynamic PVCs on ATM2/0PVCD: Restoring MIXED PVCs w/ default parms on ATM2/0PVCD: Marking static PVCs as UNKNWN on ATM2/0PVCD: Marking static PVC 0/50 as UNKNWN on ATM2/0 ...PVCD: Trying to discover PVCs on ATM2/0...PVCD: pvcd_discoverPVCsPVCD: pvcd_pingPVCD: atmfPortEntry.5.0 = 2PVCD: pvcd_getPeerVccTableSizePVCD: atmfAtmLayerEntry.5.0 = 13PVCD:end allocating VccTable size 13PVCD: pvcd_getPeerVccTablePVCD:******* ATM2/0: getNext on atmfVccEntry = NULL TYPE/VALUE numFileds = 19 numVccs = 13PVCD: Creating Dynamic PVC 0/33 on ATM2/0PVCD(ATM2/0): Before atm_update_inheritance() and atm_create_pvc() VC 0/33: DYNAMICPVCD: After atm_create_pvc() VC 0/33: DYNAMIC0/33 on ATM2/0 : UBR PCR = -1PVCD: Creating Dynamic PVC 0/34 on ATM2/0PVCD(ATM2/0): Before atm_update_inheritance() and atm_create_pvc() VC 0/34: DYNAMICPVCD: After atm_create_pvc() VC 0/34: DYNAMIC0/34 on ATM2/0 : UBR PCR -1PVCD: Creating Dynamic PVC 0/44 on ATM2/0PVCD(ATM2/0): Before atm_update_inheritance() and atm_create_pvc() VC 0/44: DYNAMICPVCD: After atm_create_pvc() VC 0/44: DYNAMIC0/44 on ATM2/0 : UBR PCR = -1PVCD: PVC 0/50 with INHERITED_QOSTYPEPVCD: atm_oi_state_change ( 0/50, 1 = ILMI_VC_UP )PVCD: Creating Dynamic PVC 0/60 on ATM2/0PVCD(ATM2/0): Before atm_update_inheritance() and atm_create_pvc() VC 0/60: DYNAMICPVCD: After atm_create_pvc() VC 0/60: DYNAMIC0/60 on ATM2/0 : UBR PCR = -1PVCD: Creating Dynamic PVC 0/80 on ATM2/0PVCD(ATM2/0): Before atm_update_inheritance() and atm_create_pvc() VC 0/80: DYNAMICPVCD: After atm_create_pvc() VC 0/80: DYNAMIC0/80 on ATM2/0 : UBR PCR = -1PVCD: Creating Dynamic PVC 0/99 on ATM2/0debug bri
Use the debug bri EXEC command to display debugging information on Integrated Services Digital Networks (ISDN) Basic Rate Interface (BRI) routing activity. The no form of this command disables debugging output.
[no] debug bri
Usage Guidelines
The debug bri command indicates whether the ISDN code is enabling and disabling the B-channels when attempting an outgoing call. This command is available for the low-end router products that have a multi-BRI network interface module installed.
Note
Sample Display
The following is sample output from the debug bri command:
Router# debug briBRI: write_sid: wrote 1B for subunit 0, slot 1.BRI: write_sid: wrote 15 for subunit 0, slot 1.BRI: write_sid: wrote 17 for subunit 0, slot 1.BRI: write_sid: wrote 6 for subunit 0, slot 1.BRI: write_sid: wrote 8 for subunit 0, slot 1.BRI: write_sid: wrote 11 for subunit 0, slot 1.BRI: write_sid: wrote 13 for subunit 0, slot 1.BRI: write_sid: wrote 29 for subunit 0, slot 1.BRI: write_sid: wrote 1B for subunit 0, slot 1.BRI: write_sid: wrote 15 for subunit 0, slot 1.BRI: write_sid: wrote 17 for subunit 0, slot 1.BRI: write_sid: wrote 20 for subunit 0, slot 1.BRI: Starting Power Up timer for unit = 0.BRI: write_sid: wrote 3 for subunit 0, slot 1.BRI: Starting T3 timer after expiry of PUP timeout for unit = 0, current state is F4.BRI: write_sid: wrote FF for subunit 0, slot 1.BRI: Activation for unit = 0, current state is F7.BRI: enable channel B1BRI: write_sid: wrote 14 for subunit 0, slot 1.%LINK-3-UPDOWN: Interface BRI0: B-Channel 1, changed state to up%LINK-5-CHANGED: Interface BRI0: B-Channel 1, changed state to up.!!!BRI: disable channel B1BRI: write_sid: wrote 15 for subunit 0, slot 1.%LINK-3-UPDOWN: Interface BRI0: B-Channel 1, changed state to down%LINK-5-CHANGED: Interface BRI0: B-Channel 1, changed state to down%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0: B-Channel 1, changed state to downThe following line indicates that an internal command was written to the interface controller. The subunit identifies the first interface in the slot.
BRI: write_sid: wrote 1B for subunit 0, slot 1.The following line indicates that the power-up timer was started for the named unit:
BRI: Starting Power Up timer for unit = 0.The following lines indicate that the channel or the protocol on the interface changed state:
%LINK-3-UPDOWN: Interface BRI0: B-Channel 1, changed state to up%LINK-5-CHANGED: Interface BRI0: B-Channel 1, changed state to up.!!!%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0: B-Channel 1, changed state to downThe following line indicates that the channel was disabled:
BRI: disable channel B1Lines of output not described are for use by support staff only.
Related Commands
debug isdn event
debug isdn q921
debug isdn q931debug bsc event
Use the debug bsc event EXEC command to display all events occurring in the Binary Synchronous Communications (BSC) feature. The no form of this command disables debugging output.
[no] debug bsc event [number]
Syntax Description
Usage Guidelines
This command traces all interfaces configured with a bsc protocol-group number command.
Sample Display
The following is sample output from the debug bsc event command:
Router# debug bsc eventBSC: Serial2 POLLEE-FSM inp:E_LineFail old_st:CU_Down new_st:TCU_EOFileBSC: Serial2 POLLEE-FSM inp:E_LineFail old_st:CU_Down new_st:TCU_EOFileBSC: Serial2 POLLEE-FSM inp:E_LineFail old_st:CU_Down new_st:TCU_EOFile0:04:32: BSC: Serial2 :SDI-rx: 9 bytesBSC: Serial2 POLLEE-FSM inp:E_RxEtx old_st:CU_Down new_st:TCU_EOFile0:04:32: BSC: Serial2 :SDI-rx: 5 bytesBSC: Serial2 POLLEE-FSM inp:E_RxEnq old_st:CU_Down new_st:TCU_EOFileBSC: Serial2 POLLEE-FSM inp:E_Timeout old_st:CU_Down new_st:TCU_InFileBSC: Serial2 POLLEE-FSM inp:E_Timeout old_st:CU_Idle new_st:TCU_InFile%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2, changed state to up%LINK-3-UPDOWN: Interface Serial2, changed state to upBSC: Serial2 POLLEE-FSM inp:E_Timeout old_st:CU_Idle new_st:TCU_InFile0:04:35: BSC: Serial2 :SDI-rx: 9 bytesBSC: Serial2 POLLEE-FSM inp:E_RxEtx old_st:CU_Idle new_st:TCU_InFile0:04:35: BSC: Serial2 :SDI-rx: 5 bytesBSC: Serial2 POLLEE-FSM inp:E_RxEnq old_st:CU_Idle new_st:TCU_InFile0:04:35: BSC: Serial2 :NDI-rx: 3 bytesRelated Commands
debug bsc packet
debug bstun eventsdebug bsc packet
Use the debug bsc packet EXEC command to display all frames traveling through the Binary Synchronous Communications (BSC) feature. The no form of this command disables debugging output.
[no] debug bsc packet [group number] [buffer-size bytes]
Syntax Description
group number
(Optional) Group number.
buffer-size bytes
(Optional) Number of bytes displayed per packet (defaults to 20).
Usage Guidelines
This command traces all interfaces configured with a bsc protocol-group number command.
Sample Display
The following is sample output from the debug bsc packet command:
Router# debug bsc packet0:23:33: BSC: Serial2 :NDI-rx : 27 bytes 401A400227F5C31140C11D60C8C5D3D3D51D40130:23:33: BSC: Serial2 :SDI-tx : 12 bytes 00323237FF3232606040402D0:23:33: BSC: Serial2 :SDI-rx : 2 bytes 10700:23:33: BSC: Serial2 :SDI-tx : 27 bytes 401A400227F5C31140C11D60C8C5D3D3D51D40130:23:33: BSC: Serial2 :SDI-rx : 2 bytes 10610:23:33: BSC: Serial2 :SDI-tx : 5 bytes 00323237FFRelated Commands
debug bsc event
debug bstun eventsdebug bstun events
Use the debug bstun events EXEC command to display BSTUN connection events and status. The no form of this command disables debugging output.
[no] debug bstun events [number]
Syntax Description
Usage Guidelines
When you enable the debug bstun events command, messages showing connection establishment and other overall status messages are displayed.
You can use the debug bstun events command to assist you in determining whether the BSTUN peers are configured correctly and are communicating. For example, if you enable the debug bstun packet command and you do not see any packets, you may want to enable event debugging.
Note
Sample Displays
The following is sample output from the debug bstun events command of keepalive messages working correctly. If the routers are configured correctly, at least one router will show reply messages.
Router# debug bstun packetBSTUN: Received Version Reply opcode from (all[2])_172.16.12.2/1976 at 1360BSTUN: Received Version Request opcode from (all[2])_172.16.12.2/1976 at 1379BSTUN: Received Version Reply opcode from (all[2])_172.16.12.2/1976 at 1390
Note
The following is sample output from the debug bstun events output of an event trace in which the wrong TCP address has been specified for the remote peer. These are non-keepalive related messages.
Router# debug bstun packetBSTUN: Change state for peer (C1[1])172.16.12.22/1976 (closed->opening)BSTUN: Change state for peer (C1[1])172.16.12.22/1976 (opening->open wait)%BSTUN-6-OPENING: CONN: opening peer (C1[1])172.16.12.22/1976, 3BSTUN: tcpd sender in wrong state, dropping packetBSTUN: tcpd sender in wrong state, dropping packetBSTUN: tcpd sender in wrong state, dropping packetRelated Commands
debug bsc event
debug bsc packet
debug bstun packetdebug bstun packet
Use the debug bstun packet EXEC command to display packet information on packets traveling through the BSTUN links. The no form of this command disables debugging output.
[no] debug bstun packet [group number] [buffer-size bytes]
Syntax Description
group number
(Optional) BSTUN group number.
buffer-size bytes
(Optional) Number of bytes displayed per packet (defaults to 20).
Sample Display
The following is sample output from the debug bstun packet command:
Router# debug bstun packetBSTUN bsc-local-ack: 0:00:00 Serial2 SDI: Addr: 40 Data: 02C1C1C1C1C1C1C1C1C1BSTUN bsc-local-ack: 0:00:00 Serial2 SDI: Addr: 40 Data: 02C1C1C1C1C1C1C1C1C1BSTUN bsc-local-ack: 0:00:06 Serial2 NDI: Addr: 40 Data: 0227F5C31140C11D60C8Related Command
debug cable env
Use the debug cable env EXEC command to display information about the Cisco uBR7246 physical environment, including internal temperature, midplane voltages, fan performance, and power supply voltages. The no form of this command disables debugging output.
[no] debug cable env
Usage Guidelines
This command is used to debug the sensor circuitry used to measure internal temperature, midplane voltages, fan performance, and power supply voltages on the Cisco uBR7246 console.
Sample Display
The following is sample output from the debug cable env command:
Router: debug cable envENVM: ps id=0xFF0, v=0x2050, r=0xC0AB, pstype=1ENVM: ps id=0x2FD0, v=0x2050, r=0x24201, pstype=27ENVM: Sensor 0: a2dref=131, a2dact=31, vref=12219, vact=1552Alpha=8990, temp=27describes significant fields in the output.
Related Commands
show environment all
show environment last
show environment tabledebug cable err
Use the debug cable err EXEC command to display errors that occur in the cable MAC protocols. The no form of this command disables debugging output.
[no] debug cable err
Usage Guidelines
This command is used to display unexpected DOCSIS MAC protocol messages. When the
Cisco uBR7246 does not to expect to receive a specific MAC message, an error message and hex dump are printed. Other miscellaneous error conditions may result in output.Sample Display
The following is sample output from the debug cable err command:
Router: debug cable errThis is a UCD MessageThis is a MAP MessageThis is a RNG_RSP MessageThis is a REG_RSP MessageThis is a UCC_REQ MessageThis is a BPKM_RSP MessageThis is a TRI_TCD MessageThis is a TRI_TSI MessageThis is a unrecognized MCNS messageERROR:######TICKS PER MSLOT NOT POWER OF 2####debug cable keyman
Use the debug cable keyman EXEC command to activate debugging of TEK and KEK baseline privacy key activity. The no form of this command disables debugging output.
[no] debug cable keyman
Usage Guidelines
This command activates debugging of the TEK and KEK baseline privacy key activity. When this command is activated, all activity related to KEK and TEK keys will be displayed on the Cisco uBR7246 console. This command is used to display encryption key management debugging output.
Sample Display
The following is sample output from the debug cable keyman command:
Router: debug cable keymanRead Verify DES failed with SID %2xVerify key failed with SID %2x : setvalue = %llx, readback = %llxVerify iv failed with SID %2x : setvalue = %llx, readback = %llxNext TEK lifetime check is set to %u seconds.Next Multicast TEK lifetime check is set to 1 seconds[UCAST_TEK] :", idbp->hw_namestring);show_sid_key_chain(ds, &ds->mcast_sid_key_list_hdr);[MCAST_TEK] :", idbp->hw_namestring);buginf("\nSID : %4x\t", sidkey->sid);buginf("seq : %2x\t current : %2x\n", sidkey->key_seq_num,sidkey->current_key_num);buginf(" Status[0] : %x\tDES IV[0] : %llx\tKey Life[0]: %u sec\n",sidkey->key_status[0], sidkey->des_key[0].iv,compute_remain_lifetime(&sidkey->des_key[0]));buginf(" Status[1] : %x\tDES IV[1] : %llx\tKey Life[1]: %u sec\n",sidkey->key_status[1], sidkey->des_key[1].iv,compute_remain_lifetime(&sidkey->des_key[1]));debug cable phy
Use the debug cable phy EXEC command to activate debugging of messages generated in the cable physical layer. The no form of this command disables debugging output.
[no] debug cable phy
Usage Guidelines
This command activates debugging of messages generated in the cable phy, which is the physical layer where upstream and downstream activity between the Cisco uBR7246 and the HFC network is controlled. When this command is activated, any messages generated in the cable phy will be displayed on the Cisco uBR7246 console.
Sample Display
The following is sample output from the debug cable phy command:
Router: debug cable phycmts_phy_init: mac_version == BCM3210_FPGAbcm3033_set_tx_sym_rate(5056941)stintctl = 0x54484800bcm3033_set_tx_if_freq(44000000)stfreqctl = 0x5BAAAAAAcmts_phy_init_us: U0 part_id = 0x3136, revid = 0x05, rev_id2 = 0x64cmts_phy_init: mac_version == BCM3210_FPGAMedia access controller chip version.bcm3033_set_tx_sym_rate(5056941)stintctl = 0x54484800Physical layer symbol rate register value.00:51:49: bcm3033_set_tx_if_freq(44000000)00:51:49: stfreqctl = 0x5BAAAAAAPhysical layer intermediate frequency (IF) register value.00:51:49: cmts_phy_init_us: U0 part_id = 0x3136, revid = 0x05, rev_id2 = 0x64Physical layer receiver chip part version.debug cable privacy
Use the debug cable privacy EXEC command to activate debugging of baseline privacy. The no form of this command disables debugging output.
[no] debug cable privacy
Usage Guidelines
This command activates debugging of baseline privacy. When this command is activated, any messages generated by the spectrum manager will be displayed on the Cisco uBR7246 console.
Sample Display
The following is sample output from the debug cable privacy command:
Router: debug cable privacyRemoving both odd and even keys for sid %x.Invalid Len for TLV_SERIAL_NUM_TYPE : %d.Invalid Len for TLV_MANUF_ID_TYPE : %d.Invalid Len for TLV_MANUF_ID_TYPE : %d.debug cable qos
Use the debug cable qos EXEC command to activate quality of service (QoS) debugging. The no form of this command disables debugging output.
[no] debug cable qos
Usage Guidelines
This command activates debugging of QoS. When this command is activated, any messages related to QoS parameters will be displayed on the Cisco uBR7246 console.
Sample Display
The following is sample output from the debug cable qos command:
Router: debug cable qosCMTS_QOS_LOG_NO_MORE_QOS_INDEXModems cannot add more entries to the class of service table.CMTS_QOS_LOG_NOMORE_QOSPRF_MEMMemory allocation error when creating class of service table entry.CMTS_QOS_LOG_NO_CREATION_ALLOWEDClass of service entry cannot be created by modem. Use CLI or SNMPinterface instead of the modem's TFTP configuration file.CMTS_QOS_LOG_CANNOT_REGISTER_COS_SIDA service identifier (SID) could not be assigned to the registering modem.CMTS_QOS_LOG_CANNOT_DEREGISTER_COS_SIDThe modem's service identifier (SID) was already removed.CMTS_QOS_LOG_MSLOT_TIMEBASE_WRAPPEDThe 160 KHz timebase clock drives a 26-bit counter which wraps aroundapproximately every 7 minutes. This message is generated every time itwraps around.debug cable range
Use the debug cable range EXEC command to display ranging messages from cable modems on the HFC network. The no form of this command disables debugging output.
[no] debug cable range
Usage Guidelines
This command activates debugging of ranging messages from cable modems on the HFC network. When this command is activated, any ranging messages generated when cable modems request or change their upstream frequencies will be displayed on the Cisco uBR7246 console. Use this command to display the details of the initial and station maintenance procedures. The initial maintenance procedure is used for link establishment. The station maintenance procedure is used for link keep-alive monitoring.
Sample Display
The following is sample output from the debug cable range command when a modem first seeks to establish a link to the Cisco uBR7246:
Router: debug cable rangeGot a ranging requestSID value is 0 on Interface Cable3/0/U0CM mac address 00:10:7B:43:AA:21 Timing offset is 33123E 1E 3F FF 00 00 59 BF 01 15 F8 01 A7 00 0C F0The SID value of 0 indicates that the modem has no assigned service identifier. The "CM mac address" is the MAC address of the modem's radio frequency (RF) interface, not its Ethernet interface. The "Timing offset" is a measure of the distance between the modem and the Cisco uBR7246 expressed in 10.24 MHz clocks. This value is adjusted down to zero by the maintenance procedures. The first 16 bytes of the prepended header of the message are dumped in hexadecimal.
The following is sample output when the modem is first assigned a SID during initial maintenance:
CM mac address 0010.7b43.aa21found..Assigned SID #2 on Interface Cable3/0/U0Timing offset is CF0Power value is 15F8, or -1 dBFreq Error = 423, Freq offset is 1692Ranging Modem with Sid 2 on i/f : Cable3/0/U0The following is sample output when the modem is reassigned the same SID during initial maintenance:
Initial Range Message Received on Interface Cable3/0/U0CMTS reusing old sid : 2 for modem : 0010.7b43.aa21Timing offset is CF0Power value is 15F8, or -1 dBFreq Error = 423, Freq offset is 1692Ranging Modem with Sid 2 on i/f : Cable3/0/U0The following is sample output when the modem is polled by the uBR7246 during station maintenance. Polling happens at a minimum rate of once every 10 seconds:
Ranging Modem with Sid 2 on i/f : Cable3/0/U0Got a ranging requestSID value is 2 on Interface Cable3/0/U0CM mac address 00:10:7B:43:AA:21Timing offset is 0Power value is 1823, or -1 dBFreq Error = 13, Freq offset is 0Ranging has been successful for SID 2 on Interface Cable3/0/U0debug cable reset
Use the debug cable reset EXEC command to display reset messages from cable interfaces. The no form of this command disables debugging output.
[no] debug cable reset
Usage Guidelines
This command activates display of reset messages from cable interfaces.
Sample Display
The following is sample output from the debug cable reset command when the interface is reset due to complete loss of receive packets:
Router: debug cable resetResetting CMTS interface.debug cable specmgmt
Use the debug cable specmgmt EXEC command to debug spectrum management (frequency agility) on the HFC network. The no form of this command disables debugging output.
[no] debug cable specmgmt
Usage Guidelines
This command activates debugging of spectrum management (frequency agility) on the HFC network. When this command is activated, any messages generated due to spectrum group activity will be displayed on the Cisco uBR7246 console. Spectrum group activity can be additions or changes to spectrum groups, or frequency and power lever changes controlled by spectrum groups.
Sample Display
The following is sample output from the debug cable specmgmt command:
Router: debug cable specmgmtcmts_next_frequency(0x60A979AC, 1, 1)The following is sample output when the frequency hop was commanded:
add_interface_to_freq(0x60BD3734, 0x60C44F68)The following is sample output when the interface was added to a frequency's interface list:
set_upstream(0x60A979AC,1,21000000,-5)The following is sample output when the spectrum management has set an upstream port's frequency and power level:
cmts_frequency_hop_decision(0x60B57FEC)debug cable startalloc
Use the debug cable startalloc EXEC command to debug channel allocations on the HFC network. The no form of this command disables debugging output.
[no] debug cable startalloc
Usage Guidelines
This command activates debugging of any channel allocations on the HFC network. When this command is activated, any messages generated when channels are allocated to cable modems on the HFC network will be displayed on the Cisco uBR7246 console.
Sample Display
The following is sample output from the debug cable startalloc command:
Router: debug cable startallocMAP startalloc adjusted by <n> mslotsThis output indicates time-slot MAP processing is active.
debug cable ucc
Use the debug cable ucc EXEC command to debug upstream channel change (UCC) messages generated when cable modems request or are assigned a new channel. The no form of this command disables debugging output.
[no] debug cable ucc
Usage Guidelines
This command activates debugging of any UCC messages generated when cable modems request or are assigned a new channel. When this command is activated, any messages related to upstream channel changes will be displayed on the Cisco uBR7246 console.
Sample Display
The following is sample output from the debug cable ucc command when moving a modem from one upstream channel to another:
Router: debug cable uccSID 2 has been registeredMac Address of CM for UCC00:0E:1D:D8:52:16UCC Message Sent to CMChanging SID 2 from upstream channel 1 to upstream channel 2debug cable ucd
Use the debug cable ucd EXEC command to debug upstream channel descriptor (UCD) messages. The no form of this command disables debugging output.
[no] debug cable ucd
Usage Guidelines
This command activates debugging of any UCD messages. UCD messages contain information about upstream channel characteristics and are sent to the cable modems on the HFC network. Cable modems that are configured to use enhanced upstream channels use these UCD messages to identify and select an enhanced upstream channel to use. When this command is activated, any messages related to upstream channel descriptors will be displayed on the Cisco uBR7246 console.
Sample Display
The following is sample output from the debug cable ucd command:
Router: debug cable ucdUCD MESSAGE-----------FRAME HEADERFC - 0xC2 ==MAC_PARM - 0x00LEN - 0xD3MAC MANAGEMENT MESSAGE HEADERDA - 01E0.2F00.0001SA - 0009.0CEF.3730msg LEN - C1DSAP - 0SSAP t - 0control - 03version - 01type - 02 ==US Channel ID - 1Configuration Change Count - 5Mini-Slot Size - 4DS Channel ID - 1Symbol Rate - 8Frequency - 10000000Preamble Pattern - CC CC CC CC CC CC CC CC CC CC CC CC CCCC 0D 0DBurst Descriptor 0Interval Usage Code - 1Modulation Type - 1 == QPSKDifferential Encoding - 2 == OFFPreamble Length - 64Preamble Value Offset - 56FEC Error Correction - 0FEC Codeword Length - 16Scrambler Seed - 0x0152Maximum Burst Size - 2Guard Time Size - 8Last Codeword Length - 1 == FIXEDScrambler on/off - 1 == ONBurst Descriptor 1Interval Usage Code - 3Modulation Type - 1 == QPSKDifferential Encoding - 2 == OFFPreamble Length - 128Preamble Value Offset - 0FEC Error Correction - 5FEC Codeword Length - 34Scrambler Seed - 0x0152Maximum Burst Size - 0Guard Time Size - 48Last Codeword Length - 1 == FIXEDScrambler on/off - 1 == ONBurst Descriptor 2Interval Usage Code - 4Modulation Type - 1 == QPSKDifferential Encoding - 2 == OFFPreamble Length - 128Preamble Value Offset - 0FEC Error Correction - 5FEC Codeword Length - 34Scrambler Seed - 0x0152Maximum Burst Size - 0Guard Time Size - 48Last Codeword Length - 1 == FIXEDScrambler on/off - 1 == ONBurst Descriptor 3Interval Usage Code - 5Modulation Type - 1 == QPSKDifferential Encoding - 2 == OFFPreamble Length - 72Preamble Value Offset - 48FEC Error Correction - 5FEC Codeword Length - 75Scrambler Seed - 0x0152Maximum Burst Size - 0Guard Time Size - 8Last Codeword Length - 1 == FIXEDScrambler on/off - 1 == ONThe UCD MESSAGE is :0xC2 0x00 0x00 0xD3 0x00 0x00 0x01 0xE00x2F 0x00 0x00 0x01 0x00 0x09 0x0C 0xEF0x37 0x30 0x00 0xC1 0x00 0x00 0x03 0x010x02 0x00 0x01 0x05 0x04 0x01 0x01 0x010x08 0x02 0x04 0x00 0x98 0x96 0x80 0x030x10 0xCC 0xCC 0xCC 0xCC 0xCC 0xCC 0xCC0xCC 0xCC 0xCC 0xCC 0xCC 0xCC 0xCC 0x0D0x0D 0x04 0x25 0x01 0x01 0x01 0x01 0x020x01 0x02 0x03 0x02 0x00 0x40 0x04 0x020x00 0x38 0x05 0x01 0x00 0x06 0x01 0x100x07 0x02 0x01 0x52 0x08 0x01 0x02 0x090x01 0x08 0x0A 0x01 0x01 0x0B 0x01 0x010x04 0x25 0x03 0x01 0x01 0x01 0x02 0x010x02 0x03 0x02 0x00 0x80 0x04 0x02 0x000x00 0x05 0x01 0x05 0x06 0x01 0x22 0x070x02 0x01 0x52 0x08 0x01 0x00 0x09 0x010x30 0x0A 0x01 0x01 0x0B 0x01 0x01 0x040x25 0x04 0x01 0x01 0x01 0x02 0x01 0x020x03 0x02 0x00 0x80 0x04 0x02 0x00 0x000x05 0x01 0x05 0x06 0x01 0x22 0x07 0x020x01 0x52 0x08 0x01 0x00 0x09 0x01 0x300x0A 0x01 0x01 0x0B 0x01 0x01 0x04 0x250x05 0x01 0x01 0x01 0x02 0x01 0x02 0x030x02 0x00 0x48 0x04 0x02 0x00 0x30 0x050x01 0x05 0x06 0x01 0x4B 0x07 0x02 0x010x52 0x08 0x01 0x00 0x09 0x01 0x08 0x0A0x01 0x01 0x0B 0x01 0x01debug callback
Use the debug callback EXEC command to display callback events when the router is using a modem and a chat script to call back on a terminal line. The no form of this command disables debugging output.
[no] debug callback
Usage Guidelines
This command is useful for debugging chat scripts on PPP and ARAP lines that use callback mechanisms. The output provided by the debug callback command shows you how the call is progressing when used with the debug ppp or debug arap commands.
Sample Display
The following is sample output from the debug callback command:
Router# debug callbackTTY7 Callback process initiated, user: exec_test dialstring 123456TTY7 Callback forced wait = 4 secondsTTY7 Exec Callback Successful - await exec/autoselect pickupTTY7: Callback in effectRelated Commands
debug arap
debug pppdebug cdp
Use the debug cdp EXEC command to enable debugging of Cisco Discovery Protocol (CDP). The no form of this command disables debugging output.
[no] debug cdp {packets | adjacency | events}
Syntax Description
packets
Enables packet-related debugging output.
adjacency
Enables adjacency-related debugging output.
events
Enables output related to error messages, such as detecting a bad checksum.
Usage Guidelines
Use debug cdp commands to display information about CDP packet activity, activity between CDP neighbors, and various CDP events.
Sample Display
The following is sample output from debug cdp packets, debug cdp adjacency, and debug cdp events commands:
Router# debug cdp packetsCDP packet info debugging is onRouter# debug cdp adjacencyCDP neighbor info debugging is onRouter# debug cdp eventsCDP events debugging is onCDP-PA: Packet sent out on Ethernet0CDP-PA: Packet received from gray.cisco.com on interface Ethernet0CDP-AD: Deleted table entry for violet.cisco.com, interface Ethernet0CDP-AD: Interface Ethernet2 coming upCDP-EV: Encapsulation on interface Serial2 faileddebug cdp ip
Use the debug cdp ip EXEC command to enable debug output for the IP routing information that is carried and processed by the Cisco Discovery Protocol (CDP). The no form of this command disables debugging output.
[no] debug cdp ip
Usage Guidelines
CDP is a media- and protocol-independent device-discovery protocol that runs on all Cisco routers.
You can use the debug cdp ip command to determine the IP network prefixes CDP is advertising and whether CDP is correctly receiving this information from neighboring routers.
Use the debug cdp ip command with the debug ip routing command to debug problems that occur when on-demand routing (ODR) routes are not installed in the routing table at a hub router. You can also use the debug cdp ip command with the debug cdp packet and debug cdp adjacency commands along with encapsulation-specific debug commands to debug problems that occur in the receipt of CDP IP information.
Sample Display
The following is sample output from the debug cdp ip command. This example shows the transmission of IP-specific information in a CDP update. In this case, three network prefixes are being transmitted, each with a different network mask.
Router# debug cdp ipCDP-IP: Writing prefix 172.1.69.232.112/28CDP-IP: Writing prefix 172.19.89.0/24CDP-IP: Writing prefix 11.0.0.0/8In addition to these messages, you might see the following messages:
•
CDP-IP: Updating prefix 172.1.1.0/24 in routing table•
CDP-IP: IP TLV length (3) invalid•
CDP-IP: Reading prefix 172.1.1.0/24 source 10.0.0.1 via Ethernet0/0Related Commands
debug cdp adjacency
debug cdp packet
debug ip routingdebug channel events
The debug channel events EXEC command displays processing events that occur on the channel adapter interfaces of all installed adapters. This command is valid for the Cisco 7000 series routers only. The no form of this command disables debugging output.
[no] debug channel events
Usage Guidelines
This command displays Channel Interface Processor (CIP) events that occur on the CIP interface processor and is useful for diagnosing problems in an IBM channel attach network. It provides an overall picture of the stability of the network. In a stable network, the debug channel events command does not return any information. If the command generates numerous messages, they can indicate the possible source of the problems. To observe the statistic message (cip_love_letter) transmitted every ten seconds, use the debug channel love command.
When configuring or making changes to a router or interface that supports IBM channel attach, enable debug channel events. Doing so alerts you to the progress of the changes or to any errors that might result. Also use this command periodically when you suspect network problems.
Sample Display
The following is sample output from the debug channel events command:
Router# debug channel eventsChannel3/0: cip_reset(), state administratively downChannel3/0: cip_reset(), state upChannel3/0: sending nodeidChannel3/0: sending command for vc 0, CLAW path C700, device C0The following line indicates that the CIP is being reset to an administrative down state:
Channel3/0: cip_reset(), state administratively downThe following line indicates that the CIP is being reset to an administrative up state:
Channel3/0: cip_reset(), state upThe following line indicates that the node id is being sent to the CIP. This information is the same as the "Local Node" information under the show extended channel slot/port subchannels command. The CIP needs this information to send to the host mainframe.
Channel3/0: sending nodeidThe following line indicates that a CLAW subchannel command is being sent from the RP to the CIP. The value vc 0 indicates that the CIP will use virtual circuit number 0 with this device. The virtual circuit number will also show up when you use the debug channel packets command.
Channel3/0: sending command for vc 0, CLAW path C700, device C0Related Commands
debug channel love
debug channel packetsdebug channel love
Use the debug channel love EXEC command to display Channel Interface Processor (CIP) love letter events. This command is valid for the Cisco 7000 series routers only. The no form of this command disables debugging output.
[no] debug channel love
Usage Guidelines
This command displays Channel Interface Processor (CIP) events that occur on the CIP interface processor and is useful for diagnosing problems in an IBM channel attach network. It provides an overall picture of the stability of the network. In a stable network, the debug channel love command returns a statistic message (cip_love_letter) that is transmitted every ten seconds.
Sample Display
The following is sample output from the debug channel love command:
Router# debug channel loveChannel3/1: love letter received, bytes 3308Channel3/0: love letter received, bytes 3336cip_love_letter: received ll, but no cip_infoThe following line indicates that data was received on the CIP:
Channel3/1: love letter received, bytes 3308The following line indicates that the interface is enabled, but there is no configuration for it. It does not normally indicate a problem, just that the route processor (RP) got statistics from the CIP but has no place to store them.
cip_love_letter: received ll, but no cip_infoRelated Commands
debug channel events
debug channel packetsdebug channel packets
Use the debug channel packets EXEC command to display per-packet debugging output. The output reports information when a packet is received or a transmit is attempted. The no form of this command disables debugging output.
[no] debug channel packets
Usage Guidelines
The debug channel packets command displays all process-level Channel Interface Processor (CIP) packets for both outbound and inbound packets. You will need to disable fast switching and autonomous switching to obtain debugging output. This command is useful for determining whether packets are received or transmitted correctly.
This command is valid for the Cisco 7000 series routers only.
Sample Display
The following is sample output from the debug channel packets command:
Router# debug channel packets(Channel3/0)-out size = 104, vc = 0000, type = 0800, src 172.24.0.11, dst 172.24.1.58(Channel3/0)-in size = 48, vc = 0000, type = 0800, src 172.24.1.58, dst 172.24.15.197(Channel3/0)-in size = 48, vc = 0000, type = 0800, src 172.24.1.58, dst 172.24.15.197(Channel3/0)-out size = 71, vc = 0000, type = 0800, src 172.24.15.197, dst 172.24.1.58(Channel3/0)-in size = 44, vc = 0000, type = 0800, src 172.24.1.58, dst 172.24.15.197describes the fields in the output.
Related Commands
debug channel events
debug channel love
