-
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 == QPSK
