Syntax Description

errors	Displays errors that prevent a tunnel from being established or errors that cause an established tunnel to be closed.
events	Displays messages about events that are part of normal tunnel establishment or shutdown.
packets	Displays each protocol packet exchanged. This option may result in a large number of debug messages and should generally only be used on a debug chassis with a single active session.
l2f-errors	Displays L2F protocol errors that prevent L2F establishment or prevent its normal operation.
l2f-events	Displays messages about events that are part of normal tunnels establishment or shutdown for L2F.
l2f-packets	Displays messages about L2F protocol headers and status.

Examples

Debug VPDN Events on a Network Access Server---Normal Operations

The network access server has the following VPDN configuration:

vpdn outgoing cisco.com stella ip 172.21.9.26 
username stella password stella 
 

The following is sample output from the debug vpdn events command on a network access server when the L2F tunnel is brought up and CHAP authentication of the tunnel succeeds:

Router# debug vpdn events
 
%LINK-3-UPDOWN: Interface Async6, changed state to up
*Mar  2 00:26:05.537: looking for tunnel -- cisco.com --
*Mar  2 00:26:05.545: Async6 VPN Forwarding...
*Mar  2 00:26:05.545: Async6 VPN Bind interface direction=1
*Mar  2 00:26:05.553: Async6 VPN vpn_forward_user bum6@cisco.com is forwarded
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async6, changed state to up
*Mar  2 00:26:06.289: L2F:  Chap authentication succeeded for stella.
 

The following is sample output from the debug vpdn events command on a network access server when the L2F tunnel is brought down normally:

Router# debug vpdn events
 
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async6, changed state to down
%LINK-5-CHANGED: Interface Async6, changed state to reset
*Mar  2 00:27:18.865: Async6 VPN cleanup
*Mar  2 00:27:18.869: Async6 VPN reset
*Mar  2 00:27:18.873: Async6 VPN Unbind interface
%LINK-3-UPDOWN: Interface Async6, changed state to down
 

Debug VPDN Events on the Home Gateway---Normal Operations

The home gateway has the following VPDN configuration, which uses stella as the tunnel name and the tunnel authentication name. The tunnel authentication name might be entered in a users file on an AAA server and used to define authentication requirements for the tunnel.

vpdn incoming stella stella virtual-template 1
 

The following is sample output from the debug vpdn events command on the home gateway when the tunnel is brought up successfully:

Router# debug vpdn events
 
L2F:  Chap authentication succeeded for stella.
Virtual-Access3 VPN Virtual interface created for bum6@cisco.com
Virtual-Access3 VPN Set to Async interface
Virtual-Access3 VPN Clone from Vtemplate 1 block=1 filterPPP=0
%LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up
Virtual-Access3 VPN Bind interface direction=2
Virtual-Access3 VPN PPP LCP accepted sent & rcv CONFACK
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up
 

The following is sample output from the debug vpdn events command on a home gateway when the tunnel is brought down normally:

Router# debug vpdn events
 
%LINK-3-UPDOWN: Interface Virtual-Access3, changed state to down
Virtual-Access3 VPN cleanup
Virtual-Access3 VPN reset
Virtual-Access3 VPN Unbind interface
Virtual-Access3 VPN reset
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to down
 

Debug VPDN L2F-Events on the Network Access Server---Normal Operations

The following is sample output from the debug vpdn l2f-events command on the network access server when the L2F tunnel is brought up successfully:

Router# debug vpdn l2f-events
 
%LINK-3-UPDOWN: Interface Async6, changed state to up
*Mar  2 00:41:17.365: L2F Open UDP socket to 172.21.9.26
*Mar  2 00:41:17.385: L2F_CONF received
*Mar  2 00:41:17.389: L2F Removing resend packet (type 1)
*Mar  2 00:41:17.477: L2F_OPEN received
*Mar  2 00:41:17.489: L2F Removing resend packet (type 2)
*Mar  2 00:41:17.493: L2F building nas2gw_mid0
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async6, changed state to up
*Mar  2 00:41:18.613: L2F_OPEN received
*Mar  2 00:41:18.625: L2F Got a MID management packet
*Mar  2 00:41:18.625: L2F Removing resend packet (type 2)
*Mar  2 00:41:18.629: L2F MID synced NAS/HG Clid=7/15 Mid=1 on Async6
 

The following is sample output from the debug vpdn l2f-events command on a network access server when the tunnel is brought down normally:

Router# debug vpdn l2f-events
 
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async6, changed state to down
%LINK-5-CHANGED: Interface Async6, changed state to reset
*Mar  2 00:42:29.213: L2F_CLOSE received
*Mar  2 00:42:29.217: L2F Destroying mid
*Mar  2 00:42:29.217: L2F Removing resend packet (type 3)
*Mar  2 00:42:29.221: L2F Tunnel is going down!
*Mar  2 00:42:29.221: L2F Initiating tunnel shutdown.
*Mar  2 00:42:29.225: L2F_CLOSE received
*Mar  2 00:42:29.229: L2F_CLOSE received
*Mar  2 00:42:29.229: L2F Got closing for tunnel 
*Mar  2 00:42:29.233: L2F Removing resend packet
*Mar  2 00:42:29.233: L2F Closed tunnel structure
%LINK-3-UPDOWN: Interface Async6, changed state to down
*Mar  2 00:42:31.793: L2F Closed tunnel structure
*Mar  2 00:42:31.793: L2F Deleted inactive tunnel
 

Debug VPDN L2F-Events on the Home Gateway---Normal Operations

The following is sample output from the debug vpdn l2f-events command on a home gateway when the L2F tunnel is created:

Router# debug vpdn l2f-events
 
L2F_CONF received
L2F Creating new tunnel for stella
L2F Got a tunnel named stella, responding
L2F Open UDP socket to 172.21.9.25
L2F_OPEN received
L2F Removing resend packet (type 1)
L2F_OPEN received
L2F Got a MID management packet
%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
 

The following is sample output from the debug vpdn l2f-events command on a home gateway when the L2F tunnel is brought down normally:

Router# debug vpdn l2f-events
 
L2F_CLOSE received
L2F Destroying mid
L2F Removing resend packet (type 3)
L2F Tunnel is going down!
L2F Initiating tunnel shutdown.
%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down
L2F_CLOSE received
L2F Got closing for tunnel 
L2F Removing resend packet
L2F Removing resend packet
L2F Closed tunnel structure
L2F Closed tunnel structure
L2F Deleted inactive tunnel
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down
 

Debug VPDN on the Network Access Server---Error Conditions

The following is sample output from the debug vpdn errors command on a network access server when the tunnel is not set up:

Router# debug vpdn errors
 
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async1, changed state to down
%LINK-5-CHANGED: Interface Async1, changed state to reset
%LINK-3-UPDOWN: Interface Async1, changed state to down
%LINK-3-UPDOWN: Interface Async1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async1, changed state to up
VPDN tunnel management packet failed to authenticate
VPDN tunnel management packet failed to authenticate
 

The following is sample output from the debug vpdn l2f-errors command:

Router# debug vpdn l2f-errors
 
%LINK-3-UPDOWN: Interface Async1, changed state to up
L2F Out of sequence packet 0 (expecting 0)
L2F Tunnel authentication succeeded for home.com
 L2F Received a close request for a non-existent mid
 L2F Out of sequence packet 0 (expecting 0)
 L2F packet has bogus1 key 1020868 D248BA0F
L2F packet has bogus1 key 1020868 D248BA0F
 

Debugging VPDN Packets for Complete Information

The following is sample output from the debug vpdn l2f-packets command on a network access server. This example displays a trace for a ping command:

Router# debug vpdn l2f-packets
 
L2F SENDING (17): D0 1 1 10 0 0 0 4 0 11 0 0 81 94 E1 A0 4
L2F header flags: 53249 version 53249 protocol 1 sequence 16 mid 0 cid 4
length 17 offset 0 key 1701976070
L2F RECEIVED (17): D0 1 1 10 0 0 0 4 0 11 0 0 65 72 18 6 5
L2F SENDING (17): D0 1 1 11 0 0 0 4 0 11 0 0 81 94 E1 A0 4
L2F header flags: 53249 version 53249 protocol 1 sequence 17 mid 0 cid 4
length 17 offset 0 key 1701976070
L2F RECEIVED (17): D0 1 1 11 0 0 0 4 0 11 0 0 65 72 18 6 5
L2F header flags: 57345 version 57345 protocol 2 sequence 0 mid 1 cid 4
length 32 offset 0 key 1701976070
L2F-IN Output to Async1 (16): FF 3 C0 21 9 F 0 C 0 1D 41 AD FF 11 46 87
L2F-OUT (16): FF 3 C0 21 A F 0 C 0 1A C9 BD FF 11 46 87
L2F header flags: 49153 version 49153 protocol 2 sequence 0 mid 1 cid 4
length 32 offset 0 key -2120949344
L2F-OUT (101): 21 45 0 0 64 0 10 0 0 FF 1 B9 85 1 0 0 3 1 0 0 1 8 0 62 B1
0 0 C A8 0 0 0 0 0 11 E E0 AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD
AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB
CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD
L2F header flags: 49153 version 49153 protocol 2 sequence 0 mid 1 cid 4
length 120 offset 3 key -2120949344
L2F header flags: 49153 version 49153 protocol 2 sequence 0 mid 1 cid 4
length 120 offset 3 key 1701976070
L2F-IN Output to Async1 (101): 21 45 0 0 64 0 10 0 0 FF 1 B9 85 1 0 0 1 1 0
0 3 0 0 6A B1 0 0 C A8 0 0 0 0 0 11 E E0 AB CD AB CD AB CD AB CD AB CD AB CD
AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB
CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD
 

Related Commands

Command	Description
debug aaa authentication	Displays information on AAA/TACACS+ authentication.

Syntax Description

protocol	(Optional) Displays all errors for the tunneling protocols used by VPDNs, such as L2TP, L2F, PPTP, and events within these protocols.
flow control	(Optional) Displays L2TP flow control errors.

Command History

Release	Modification
11.2(5)AA	This command was introduced.
12.0(1)T	This command was modified.

Usage Guidelines

Use this command to display VPDN errors and basic events within the protocol, such as state changes. This command does not include packet trace information or information about sent or received individual management packets.

Examples

The following is sample output for the natural sequence of events for an LNS named stella:

Router# debug vpdn event
 
20:47:33: %LINK-3-UPDOWN: Interface Async7, changed state to up
20:47:35: As7 VPDN: Looking for tunnel -- cisco.com --
20:47:35: As7 VPDN: Get tunnel info for cisco.com with NAS stella, IP 172.21.9.13
20:47:35: As7 VPDN: Forward to address 172.21.9.13
20:47:35: As7 VPDN: Forwarding...
20:47:35: As7 VPDN: Bind interface direction=1
20:47:35: Tnl/Cl 8/1 L2TP: Session FS enabled
20:47:35: Tnl/Cl 8/1 L2TP: Session state change from idle to wait-for-tunnel
20:47:35: As7 8/1 L2TP: Create session
20:47:35: Tnl 8 L2TP: SM State idle
20:47:35: Tnl 8 L2TP: Tunnel state change from idle to wait-ctl-reply
20:47:35: Tnl 8 L2TP: SM State wait-ctl-reply
20:47:35: As7 VPDN: bum1@cisco.com is forwarded
20:47:35: Tnl 8 L2TP: Got a challenge from remote peer, stella
20:47:35: Tnl 8 L2TP: Got a response from remote peer, stella
20:47:35: Tnl 8 L2TP: Tunnel Authentication success
20:47:35: Tnl 8 L2TP: Tunnel state change from wait-ctl-reply to established
20:47:35: Tnl 8 L2TP: SM State established
20:47:35: As7 8/1 L2TP: Session state change from wait-for-tunnel to wait-reply
20:47:35: As7 8/1 L2TP: Session state change from wait-reply to established
20:47:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async7, changed state to up
 

The following shows sample debug output on the LAC named stella:

Router# debug vpdn event
 
20:19:17: L2TP: I SCCRQ from stella tnl 8
20:19:17: L2X: Never heard of stella
20:19:17: Tnl 7 L2TP: New tunnel created for remote stella, address 172.21.9.4
20:19:17: Tnl 7 L2TP: Got a challenge in SCCRQ, stella
20:19:17: Tnl 7 L2TP: Tunnel state change from idle to wait-ctl-reply
20:19:17: Tnl 7 L2TP: Got a Challenge Response in SCCCN from stella
20:19:17: Tnl 7 L2TP: Tunnel Authentication success
20:19:17: Tnl 7 L2TP: Tunnel state change from wait-ctl-reply to established
20:19:17: Tnl 7 L2TP: SM State established
20:19:17: Tnl/Cl 7/1 L2TP: Session FS enabled
20:19:17: Tnl/Cl 7/1 L2TP: Session state change from idle to wait-for-tunnel
20:19:17: Tnl/Cl 7/1 L2TP: New session created
20:19:17: Tnl/Cl 7/1 L2TP: O ICRP to stella 8/1
20:19:17: Tnl/Cl 7/1 L2TP: Session state change from wait-for-tunnel to wait-connect
20:19:17: Tnl/Cl 7/1 L2TP: Session state change from wait-connect to established
20:19:17: Vi1 VPDN: Virtual interface created for bum1@cisco.com
20:19:17: Vi1 VPDN: Set to Async interface
20:19:17: Vi1 VPDN: Clone from Vtemplate 1 filterPPP=0 blocking
20:19:18: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
20:19:18: Vi1 VPDN: Bind interface direction=2
20:19:18: Vi1 VPDN: PPP LCP accepting rcv CONFACK
20:19:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
 

Syntax Description

control	(Optional) Displays a one-line statement for each control packet sent, resent, or received.
flow-control	(Optional) Displays information about L2TP flow control.
control detail	(Optional) Displays detailed header field and AVP information, which is contained in control packets that are sent, resent, or received.
data	(Optional) Displays sequence numbers (if present), flags, length, and information about fast switching.

Command History

Release	Modification
11.2(5)AA	This command was introduced.
12.0(1)T	This command was modified.

Usage Guidelines

Use this command with the following keywords:

• control---Use this command to debug to ensure control messages are sent, resent, or received correctly.

• flow-control---Use this command only when you want to debug L2TP flow control issues or where you suspect flow-control is problematic.

• control detail---Use this command when you suspect there is a problem parsing control packets. This command is particularly helpful for tunneling between a Cisco and non-Cisco device.

• data---Use this command when you want to debug the data path or determine the packet's switching path (fast-switched or process-switched).

Caution  The debug vpdn packet command using the data keyword is CPU intensive and may decrease performance-significantly.

Examples

The following is sample output from the debug vpdn packet control where VPDN event exchange is normal:

Router# debug vpdn event protocol
 
20:50:27: %LINK-3-UPDOWN: Interface Async7, changed state to up
20:50:29: Tnl 9 L2TP: O SCCRQ 
20:50:29: Tnl 9 L2TP: O SCCRQ, flg TLF, ver 2, len 131, tnl 0, cl 0, ns 0, nr 0
20:50:29: contiguous buffer, size 131
         C8 02 00 83 00 00 00 00 00 00 00 00 80 08 00 00
         00 00 00 01 80 08 00 00 00 02 01 00 80 0A 00 00
         00 03 00 00 00 03 80 0A 00 00 00 04 00 00 00 ...
20:50:29: Tnl 9 L2TP: Parse AVP 0, len 8, flag 0x0x8000 (M)
20:50:29: Tnl 9 L2TP: Parse SCCRP
20:50:29: Tnl 9 L2TP: Parse AVP 2, len 8, flag 0x0x8000 (M)
20:50:29: Tnl 9 L2TP: Protocol Ver 256
20:50:29: Tnl 9 L2TP: Parse AVP 3, len 10, flag 0x0x8000 (M)
20:50:29: Tnl 9 L2TP: Framing Cap 0x0x3
20:50:29: Tnl 9 L2TP: Parse AVP 4, len 10, flag 0x0x8000 (M)
20:50:29: Tnl 9 L2TP: Bearer Cap 0x0x3
20:50:29: Tnl 9 L2TP: Parse AVP 6, len 8, flag 0x0x0 
20:50:29: Tnl 9 L2TP: Firmware Ver 0x0x1120
20:50:29: Tnl 9 L2TP: Parse AVP 7, len 12, flag 0x0x8000 (M)
20:50:29: Tnl 9 L2TP: Hostname stella
20:50:29: Tnl 9 L2TP: Parse AVP 8, len 25, flag 0x0x0 
20:50:29: Tnl 9 L2TP: Vendor Name Cisco Systems, Inc.
20:50:29: Tnl 9 L2TP: Parse AVP 9, len 8, flag 0x0x8000 (M)
20:50:29: Tnl 9 L2TP: Assigned Tunnel ID 8
20:50:29: Tnl 9 L2TP: Parse AVP 10, len 8, flag 0x0x8000 (M)
20:50:29: Tnl 9 L2TP: Rx Window Size 4
20:50:29: Tnl 9 L2TP: Parse AVP 11, len 22, flag 0x0x8000 (M)
20:50:29: Tnl 9 L2TP: Chlng D807308D106259C5933C6162ED3A1689
20:50:29: Tnl 9 L2TP: Parse AVP 13, len 22, flag 0x0x8000 (M)
20:50:29: Tnl 9 L2TP: Chlng Resp 9F6A3C70512BD3E2D44DF183C3FFF2D1
20:50:29: Tnl 9 L2TP: No missing AVPs in SCCRP
20:50:29: Tnl 9 L2TP: Clean Queue packet 0
20:50:29: Tnl 9 L2TP: I SCCRP, flg TLF, ver 2, len 153, tnl 9, cl 0, ns 0, nr 1
 contiguous pak, size 153
         C8 02 00 99 00 09 00 00 00 00 00 01 80 08 00 00
         00 00 00 02 80 08 00 00 00 02 01 00 80 0A 00 00
         00 03 00 00 00 03 80 0A 00 00 00 04 00 00 00 ...
20:50:29: Tnl 9 L2TP: I SCCRP from stella
20:50:29: Tnl 9 L2TP: O SCCCN  to stella tnlid 8
20:50:29: Tnl 9 L2TP: O SCCCN, flg TLF, ver 2, len 42, tnl 8, cl 0, ns 1, nr 1
20:50:29: contiguous buffer, size 42
         C8 02 00 2A 00 08 00 00 00 01 00 01 80 08 00 00
         00 00 00 03 80 16 00 00 00 0D 4B 2F A2 50 30 13
         E3 46 58 D5 35 8B 56 7A E9 85
20:50:29: As7 9/1 L2TP: O ICRQ to stella 8/0
20:50:29: As7 9/1 L2TP: O ICRQ, flg TLF, ver 2, len 48, tnl 8, cl 0, ns 2, nr 1
20:50:29: contiguous buffer, size 48
         C8 02 00 30 00 08 00 00 00 02 00 01 80 08 00 00
         00 00 00 0A 80 08 00 00 00 0E 00 01 80 0A 00 00
         00 0F 00 00 00 04 80 0A 00 00 00 12 00 00 00 ...
20:50:29: Tnl 9 L2TP: Clean Queue packet 1
20:50:29: Tnl 9 L2TP: Clean Queue packet 2
20:50:29: Tnl 9 L2TP: I ZLB ctrl ack, flg TLF, ver 2, len 12, tnl 9, cl 0, ns 1, nr 2
 contiguous pak, size 12
         C8 02 00 0C 00 09 00 00 00 01 00 02
20:50:30: As7 9/1 L2TP: Parse AVP 0, len 8, flag 0x0x8000 (M)
20:50:30: As7 9/1 L2TP: Parse ICRP
20:50:30: As7 9/1 L2TP: Parse AVP 14, len 8, flag 0x0x8000 (M)
20:50:30: As7 9/1 L2TP: Assigned Call ID 1
20:50:30: As7 9/1 L2TP: No missing AVPs in ICRP
20:50:30: Tnl 9 L2TP: Clean Queue packet 2
20:50:30: As7 9/1 L2TP: I ICRP, flg TLF, ver 2, len 28, tnl 9, cl 1, ns 1, nr 3
 contiguous pak, size 28
         C8 02 00 1C 00 09 00 01 00 01 00 03 80 08 00 00
         00 00 00 0B 80 08 00 00 00 0E 00 01
20:50:30: As7 9/1 L2TP: O ICCN to stella 8/1
20:50:30: As7 9/1 L2TP: O ICCN, flg TLF, ver 2, len 203, tnl 8, cl 1, ns 3, nr 2
20:50:30: contiguous buffer, size 203
         C8 02 00 CB 00 08 00 01 00 03 00 02 80 08 00 00
         00 00 00 0C 80 0A 00 00 00 18 00 00 DA C0 80 0A
         00 00 00 13 00 00 00 02 00 28 00 00 00 1B 02 ...
20:50:30: Tnl 9 L2TP: Clean Queue packet 3
20:50:30: As7 9/1 L2TP: I ZLB ctrl ack, flg TLF, ver 2, len 12, tnl 9, cl 1, ns 2, nr 4
 contiguous pak, size 12
         C8 02 00 0C 00 09 00 01 00 02 00 04
20:50:30: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async7, changed state to up
 

Syntax Description

This command has no arguments or keywords.

Examples

The debug vpm all command enables all of the debug vpm commands: debug vpm dsp, debug vpm port, debug vpm signal, and debug vpm spi. For more information or sample output, refer to the individual commands in this chapter.

Related Commands

Command	Description
debug vpm dsp	Shows messages from the DSP on the VPM to the router.
debug vpm port	Observes the behavior of the Holst state machine.
debug vpm signal	Collects debug information only for signaling events.
debug vpm spi	Traces how the voice port module SPI interfaces with the call control API.

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

The debug vpm dsp command shows messages from the DSP on the VPM to the router; this command can be useful if you suspect that the VPM is not functional. It is a simple way to check if the VPM is responding to off-hook indications and to evaluate timing for signaling messages from the interface.

Examples

The following output shows the DSP timestamp and the router timestamp for each event and, for SIG_STATUS, the state value shows the state of the ABCD bits in the signaling message. This sample shows a call coming in on an FXO interface.

The router waits for ringing to terminate before accepting the call. State=0x0 indicates ringing; state 0x4 indicates not ringing:

ssm_dsp_message: SEND/RESP_SIG_STATUS: state=0x0 timestamp=58172 systime=40024
ssm_dsp_message: SEND/RESP_SIG_STATUS: state=0x4 timestamp=59472 systime=40154
ssm_dsp_message: SEND/RESP_SIG_STATUS: state=0x4 timestamp=59589 systime=40166
 

The following output shows the digits collected:

vcsm_dsp_message: MSG_TX_DTMF_DIGIT: digit=4
vcsm_dsp_message: MSG_TX_DTMF_DIGIT: digit=1
vcsm_dsp_message: MSG_TX_DTMF_DIGIT: digit=0
vcsm_dsp_message: MSG_TX_DTMF_DIGIT: digit=0
vcsm_dsp_message: MSG_TX_DTMF_DIGIT: digit=0
 

This shows the disconnect indication and the final call statistics reported by the DSP (which are then populated in the call history table):

ssm_dsp_message: SEND/RESP_SIG_STATUS: state=0xC timestamp=21214 systime=42882
vcsm_dsp_message: MSG_TX_GET_TX_STAT: num_tx_pkts=1019 num_signaling_pkts=0 num_comfort_noise_pkts=0 transmit_durtation=24150 voice_transmit_duration=20380 fax_transmit_duration=0

Syntax Description

slot-number	(Optional) Specifies the slot number in the Cisco router where the voice interface card is installed. Valid entries are from 0 to 3, depending on the router being used and the slot where the voice interface card has been installed.
subunit-number	(Optional) Specifies the subunit on the voice interface card where the voice port is located. Valid entries are 0 or 1.
port	(Optional) Specifies the voice port. Valid entries are 0 or 1.

Command History

Release	Modification
11.3(1)	This command was introduced.

Usage Guidelines

This command is not supported on Cisco 7200 series routers or on the Cisco MC3810.

Use this command to limit the debug output to a particular port. The debug output can be quite voluminous for a single channel. A 12-port box might create problems. Use this debug command with any or all of the other debug modes.

Execution of no debug vpm all will turn off all port level debugging. Cisco recommends that you turn off all debugging and then enter the debug commands you are interested in one by one. This process helps to avoid confusion about which ports you are actually debugging.

Examples

The following example shows sample output from the debug vpm port 1/1/0 command during trunk establishment after the no shutdown command has been executed on the voice port:

router# debug vpm port 1/1/0
*Mar  1 03:21:39.799: htsp_process_event: [1/1/0, 0.1 , 2]act_down_inserve
*Mar  1 03:21:39.807: htsp_process_event: [1/1/0, 0.0 , 14]
      act_go_trunkhtsp_trunk_createhtsp_trunk_sig_linkfxols_trunk
*Mar  1 03:21:39.807: htsp_process_event: [1/1/0, 1.0 , 1]trunk_offhookfxols_trunk_down
*Mar  1 03:21:39.807: dsp_sig_encap_config: [1/1/0] packet_len=28 channel_id=128
      packet_id=42 transport_protocol=1 playout_delay=100 signaling_mode=0
      t_ssrc=0 r_ssrc=0 t_vpxcc=0 r_vpxcc=0
*Mar  1 03:21:39.811: dsp_set_sig_state: [1/1/0] packet_len=12
      channel_id=128 packet_id=39 state=0xC timestamp=0x0
*Mar  1 03:21:39.811: trunk_offhook: Trunk Retry Timer Enabled
*Mar  1 03:22:13.095: htsp_process_event: [1/1/0, 1.1, 39]act_trunk_setuphtsp_setup_ind
*Mar  1 03:22:13.095: htsp_process_event: [1/1/0, 1.2 , 8]
*Mar  1 03:22:13.099: hdsprm_vtsp_codec_loaded_ok: G726 firmware needs download
*Mar  1 03:22:13.103: dsp_download: p=0x60E73844 size=34182 (t=1213310):39 FA 6D
*Mar  1 03:22:13.103: htsp_process_event: [1/1/0, 1.2 , 6]act_trunk_proc_connect
*Mar  1 03:22:13.191: dsp_receive_packet: MSG_TX_RESTART_INDICATION: code=0 t=1213319
*Mar  1 03:22:13.191: dsp_download: p=0x60EA8924 size=6224 (t=1213319): 8 55 AE
*Mar  1 03:22:13.207: dsp_receive_packet: MSG_TX_RESTART_INDICATION: code=0 t=1213320
*Mar  1 03:22:13.207: htsp_process_event: [1/1/0, 1.3 , 11] trunk_upfxols_trunk_up
*Mar  1 03:22:13.207: dsp_set_sig_state: [1/1/0] packet_len=12
      channel_id=128 packet_id=39 state=0x4 timestamp=0x0
*Mar  1 03:22:13.207: dsp_sig_encap_config: [1/1/0] packet_len=28 channel_id=128
      packet_id=42 transport_protocol=3 playout_delay=100 headerbytes = 0xA0 
 

Note in the above display that "transport_protocol = 3" indicates Voice-over-Frame Relay. Also note that the second line of the display indicates that a shutdown/no shutdown command sequence was executed on the voice port.

Related Commands

Command	Description
debug vpm all	Enables debugging of all VPM areas.
debug vpm dsp	Shows messages from the DSP on the VPM to the router.
debug vpm signal	Collects debug information only for signaling events.
debug vpm spi	Displays information about how each network indication and application request is handled.

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

The debug vpm signal command collects debug information only for signaling events. This command can also be useful in resolving problems with signaling to a PBX.

Examples

The following output shows that a ring is detected, and that the router waits for the ringing to stop before accepting the call:

ssm_process_event: [1/0/1, 0.2, 15] fxols_onhook_ringing
ssm_process_event: [1/0/1, 0.7, 19] fxols_ringing_not
ssm_process_event: [1/0/1, 0.3, 6] 
ssm_process_event: [1/0/1, 0.3, 19] fxols_offhook_clear
 

The following output shows that the call is connected:

ssm_process_event: [1/0/1, 0.3, 4] fxols_offhook_proc
ssm_process_event: [1/0/1, 0.3, 8] fxols_proc_voice
ssm_process_event: [1/0/1, 0.3, 5] fxols_offhook_connect
 

The following output confirms a disconnect from the switch and release with higher layer code:

ssm_process_event: [1/0/1, 0.4, 27] fxols_offhook_disc
ssm_process_event: [1/0/1, 0.4, 33] fxols_disc_confirm
ssm_process_event: [1/0/1, 0.4, 3] fxols_offhook_release

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

The debug vpm spi command traces how the voice port module SPI interfaces with the call control API. This debug command displays information about how each network indication and application request is handled.

This debug level shows the internal workings of the voice telephony call state machine.

Examples

The following output shows that the call is accepted and presented to a higher layer code:

dsp_set_sig_state: [1/0/1] packet_len=14 channel_id=129 packet_id=39 state=0xC timestamp=0x0
vcsm_process_event: [1/0/1, 0.5, 1] act_up_setup_ind
 

The following output shows that the higher layer code accepts the call, requests addressing information, and starts DTMF and dial-pulse collection. This also shows that the digit timer is started.

vcsm_process_event: [1/0/1, 0.6, 11] act_setup_ind_ack
dsp_voice_mode: [1/0/1] packet_len=22 channel_id=1 packet_id=73 coding_type=1 voice_field_size=160 VAD_flag=0 echo_length=128 comfort_noise=1 fax_detect=1
dsp_dtmf_mode: [1/0/1] packet_len=12 channel_id=1 packet_id=65 dtmf_or_mf=0
dsp_CP_tone_on: [1/0/1] packet_len=32 channel_id=1 packet_id=72 tone_id=3 n_freq=2 freq_of_first=350 freq_of_second=440 amp_of_first=4000 amp_of_second=4000 direction=1 on_time_first=65535 off_time_first=0 on_time_second=65535 off_time_second=0
dsp_digit_collect_on: [1/0/1] packet_len=22 channel_id=129 packet_id=35 min_inter_delay=550 max_inter_delay=3200 mim_make_time=18 max_make_time=75 min_brake_time=18 max_brake_time=75
vcsm_timer: 46653
 

The following output shows the collection of digits one by one until the higher level code indicates it has enough. The input timer is restarted with each digit and the device waits in idle mode for connection to proceed.

vcsm_process_event: [1/0/1, 0.7, 25] act_dcollect_digit
dsp_CP_tone_off: [1/0/1] packet_len=10 channel_id=1 packet_id=71
vcsm_timer: 47055
vcsm_process_event: [1/0/1, 0.7, 25] act_dcollect_digit
dsp_CP_tone_off: [1/0/1] packet_len=10 channel_id=1 packet_id=71
vcsm_timer: 47079
vcsm_process_event: [1/0/1, 0.7, 25] act_dcollect_digit
dsp_CP_tone_off: [1/0/1] packet_len=10 channel_id=1 packet_id=71
vcsm_timer: 47173
vcsm_process_event: [1/0/1, 0.7, 25] act_dcollect_digit
dsp_CP_tone_off: [1/0/1] packet_len=10 channel_id=1 packet_id=71
vcsm_timer: 47197
vcsm_process_event: [1/0/1, 0.7, 25] act_dcollect_digit
dsp_CP_tone_off: [1/0/1] packet_len=10 channel_id=1 packet_id=71
vcsm_timer: 47217
vcsm_process_event: [1/0/1, 0.7, 13] act_dcollect_proc
dsp_CP_tone_off: [1/0/1] packet_len=10 channel_id=1 packet_id=71
dsp_digit_collect_off: [1/0/1] packet_len=10 channel_id=129 packet_id=36
dsp_idle_mode: [1/0/1] packet_len=10 channel_id=1 packet_id=68
 

The following output shows that the network voice path cuts through:

vcsm_process_event: [1/0/1, 0.8, 15] act_bridge
vcsm_process_event: [1/0/1, 0.8, 20] act_caps_ind
vcsm_process_event: [1/0/1, 0.8, 21] act_caps_ack
dsp_voice_mode: [1/0/1] packet_len=22 channel_id=1 packet_id=73 coding_type=6 voice_field_size=20 VAD_flag=1 echo_length=128 comfort_noise=1 fax_detect=1
 

The following output shows that the called-party end of the connection is connected:

vcsm_process_event: [1/0/1, 0.8, 8] act_connect
 

The following output shows the voice quality statistics collected periodically:

vcsm_process_event: [1/0/1, 0.13, 17] 
dsp_get_rx_stats: [1/0/1] packet_len=12 channel_id=1 packet_id=87 reset_flag=0
vcsm_process_event: [1/0/1, 0.13, 28] 
vcsm_process_event: [1/0/1, 0.13, 29] 
vcsm_process_event: [1/0/1, 0.13, 32] 
vcsm_process_event: [1/0/1, 0.13, 17] 
dsp_get_rx_stats: [1/0/1] packet_len=12 channel_id=1 packet_id=87 reset_flag=0
vcsm_process_event: [1/0/1, 0.13, 28] 
vcsm_process_event: [1/0/1, 0.13, 29] 
vcsm_process_event: [1/0/1, 0.13, 32] 
vcsm_process_event: [1/0/1, 0.13, 17] 
dsp_get_rx_stats: [1/0/1] packet_len=12 channel_id=1 packet_id=87 reset_flag=0
vcsm_process_event: [1/0/1, 0.13, 28] 
vcsm_process_event: [1/0/1, 0.13, 29] 
vcsm_process_event: [1/0/1, 0.13, 32] 
 

The following output shows that the disconnection indication is passed to higher level code. The call connection is torn down, and final call statistics are collected:

vcsm_process_event: [1/0/1, 0.13, 4] act_generate_disc
vcsm_process_event: [1/0/1, 0.13, 16] act_bdrop
dsp_CP_tone_off: [1/0/1] packet_len=10 channel_id=1 packet_id=71
vcsm_process_event: [1/0/1, 0.13, 18] act_disconnect
dsp_get_levels: [1/0/1] packet_len=10 channel_id=1 packet_id=89
vcsm_timer: 48762
vcsm_process_event: [1/0/1, 0.15, 34] act_get_levels
dsp_get_tx_stats: [1/0/1] packet_len=12 channel_id=1 packet_id=86 reset_flag=1
vcsm_process_event: [1/0/1, 0.15, 31] act_stats_complete
dsp_CP_tone_off: [1/0/1] packet_len=10 channel_id=1 packet_id=71
dsp_digit_collect_off: [1/0/1] packet_len=10 channel_id=129 packet_id=36
dsp_idle_mode: [1/0/1] packet_len=10 channel_id=1 packet_id=68
vcsm_timer: 48762
dsp_set_sig_state: [1/0/1] packet_len=14 channel_id=129 packet_id=39 state=0x4 timestamp=0x0
vcsm_process_event: [1/0/1, 0.16, 5] act_wrelease_release
dsp_CP_tone_off: [1/0/1] packet_len=10 channel_id=1 packet_id=71
dsp_idle_mode: [1/0/1] packet_len=10 channel_id=1 packet_id=68
dsp_get_rx_stats: [1/0/1] packet_len=12 channel_id=1 packet_id=87 reset_flag=1

Syntax Description

This command has no arguments or keywords.

Command History

Release	Modification
12.0(5)T	This command was introduced.

Usage Guidelines

You can use debug vsi api command to monitor the communication between the VSI master and the XTagATM component about interface changes and cross-connect requests.

Examples

The following is an example of the display you see when you enter debug vsi api:

Router# debug vsi api
 
VSI_M: vsi_exatm_conn_req: 0x000C0200/1/35 -> 0x000C0100/1/50
       desired state up, status OK
VSI_M: vsi_exatm_conn_resp: 0x000C0200/1/33 -> 0x000C0100/1/49
       curr state up, status OK
 

Syntax Description

interface interface	(Optional) Interface number.
slave number	(Optional) Slave number (beginning with zero).

Usage Guidelines

You can use the debug vsi errors command to display information on errors encountered by the VSI master when parsing received messages, as well as information on unexpected conditions encountered by the VSI Master.

If the interface parameter is specified, output is restricted to errors associated with the indicated VSI control interface. If the slave number is specified, output is further restricted to errors associated with the session with the indicated slave.

Note Slave numbers are the same as the session numbers discussed under the show controllers vsi session command.

Multiple uses of the form of the command which specifies slave number allows multiple slaves to be debugged at once. For example, the following commands restrict output to that for errors associated with sessions 0 and 1 on control interface atm2/0 (but for no other sessions).

Router# debug vsi errors interface atm2/0 slave 0
Router# debug vsi errors interface atm2/0 slave 1
 

Some errors are not associated with any particular control interface or session; messages associated with these errors are printed regardless of the interface or slave options which are in effect.

Examples

The following is an example of the display you see when you enter debug vsi errors:

Router# debug vsi errors
 
VSI Master: parse error (unexpected param-group contents) in GEN ERROR RSP rcvd on ATM2/0:0/51 (slave 0)
            errored section is at offset 16, for 2 bytes:
 01.01.00.a0 00.00.00.00 00.12.00.38 00.10.00.34 
*00.01*00.69 00.2c.00.00 01.01.00.80 00.00.00.08 
 00.00.00.00 00.00.00.00 00.00.00.00 0f.a2.00.0a 
 00.01.00.00 00.00.00.00 00.00.00.00 00.00.00.00 
 00.00.00.00 
 

Syntax Description

interface interface	(Optional) Specifies the interface number.
slave number	(Optional) Specifies the slave number (beginning with zero).

Command History

Release	Modification
12.0(5)T	This command was introduced.

Usage Guidelines

You can use the debug vsi events command to display information on events associated with the per-session state machines of the VSI master, as well as the per-connection state machines. If the interface parameter is specified, output is restricted to events associated with the indicated VSI control interface. If the slave number is specified, output is further restricted to events associated with the session with the indicated slave.

Note Slave numbers are the same as the session numbers discussed under the show controllers vsi session command.

Multiple uses of the form of the command which specifies slave number allows multiple slaves to be debugged at once. For example, the following commands restrict output to that for events associated with sessions 0 and 1 on control interface atm2/0 (but for no other sessions). Output associated with all per-connection events are displayed regardless of the interface or slave options which are in effect.

Router# debug vsi events interface atm2/0 slave 0
Router# debug vsi events interface atm2/0 slave 1

Examples

The following is an example of the display you see when you enter debug vsi events:

Router# debug vsi events
 
VSI Master: conn 0xC0200/1/37->0xC0100/1/51: 
            CONNECTING -> UP
VSI Master(session 0 on ATM2/0): 
    event CONN_CMT_RSP, state ESTABLISHED -> ESTABLISHED
VSI Master(session 0 on ATM2/0): 
    event KEEPALIVE_TIMEOUT, state ESTABLISHED -> ESTABLISHED
VSI Master(session 0 on ATM2/0): 
    event SW_GET_CNFG_RSP, state ESTABLISHED -> ESTABLISHED
debug vsi packets
 

Syntax Description

interface interface	(Optional) Specifies the interface number.
slave number	(Optional) Specifies the slave number (beginning with zero).

Command History

Release	Modification
12.0(5)T	This command was introduced.

Usage Guidelines

If the interface parameter is specified, output is restricted to messages sent and received on the indicated VSI control interface. If the slave number is specified, output is further restricted to messages sent and received on the session with the indicated slave.

Note Slave numbers are the same as the session numbers discussed under the show controllers vsi session command.

Multiple uses of the form of the command which specifies slave number allows multiple slaves to be debugged at once. For example, the following commands restrict output to that for messages received on atm2/0 for sessions 0 and 1, (but for no other sessions).

Router# debug vsi packets interface atm2/0 slave 0

Router# debug vsi packets interface atm2/0 slave 1

Examples

The following is an example of the display you see when you enter debug vsi packets:

Router# debug vsi packets
 
VSI master(session 0 on ATM2/0): sent msg SW GET CNFG CMD on 0/51
VSI master(session 0 on ATM2/0): rcvd msg SW GET CNFG RSP on 0/51
VSI master(session 0 on ATM2/0): sent msg SW GET CNFG CMD on 0/51
VSI master(session 0 on ATM2/0): rcvd msg SW GET CNFG RSP on 0/51
 

Syntax Description

interface interface	(Optional) Specifies the interface number.
slave number	(Optional) Specifies the slave number (beginning with zero).

Command History

Release	Modification
12.0(5)T	This command was introduced.

Usage Guidelines

This command is most commonly used with the debug vsi packets command to monitor incoming and outgoing VSI messages.

If the:

• Interface parameter is specified---Output is restricted to messages sent and received on the indicated VSI control interface

• Slave number is specified---Output is further restricted to messages sent and received on the session with the indicated slave.

Note Slave numbers are the same as the session numbers discussed under the show controllers vsi session command.

Note param-groups stands for parameter groups. A parameter group is a component of a VSI message.

Multiple uses of the form of the command, which specifies slave number, allows multiple slaves to be debugged at once. For example, the following commands restrict output to that for messages received on atm2/0 for sessions 0 and 1, (but for no other sessions).

Router# debug vsi param-groups interface atm2/0 slave 0
Router# debug vsi param-groups interface atm2/0 slave 1

Examples

The following is an example of the display you see when you enter debug vsi param-groups:

Router# debug vsi param-groups
 
Outgoing VSI msg of 12 bytes (not including encap):
 01.02.00.80 00.00.95.c2 00.00.00.00 
Incoming VSI msg of 72 bytes (not including encap):
 01.02.00.81 00.00.95.c2 00.0f.00.3c 00.10.00.08 
 00.01.00.00 00.00.00.00 01.00.00.08 00.00.00.09 
 00.00.00.09 01.10.00.20 01.01.01.00 0c.08.80.00 
 00.01.0f.a0 00.13.00.15 00.0c.01.00 00.00.00.00 
 42.50.58.2d 56.53.49.31 
Outgoing VSI msg of 12 bytes (not including encap):
 01.02.00.80 00.00.95.c3 00.00.00.00 
Incoming VSI msg of 72 bytes (not including encap):
 01.02.00.81 00.00.95.c3 00.0f.00.3c 00.10.00.08 
 00.01.00.00 00.00.00.00 01.00.00.08 00.00.00.09 
 00.00.00.09 01.10.00.20 01.01.01.00 0c.08.80.00 
 00.01.0f.a0 00.13.00.15 00.0c.01.00 00.00.00.00 
 42.50.58.2d 56.53.49.31 

Syntax Description

This command has no arguments or keywords.

Examples

Router# debug vtemplate
 
VTEMPLATE Reuse vaccess8, New Recycle queue size:50
 
VTEMPLATE set default vaccess8 with no ip address
 
Virtual-Access8 VTEMPLATE hardware address 0000.0c09.ddfd
VTEMPLATE vaccess8 has a new cloneblk vtemplate, now it has vtemplate
VTEMPLATE undo default settings vaccess8
 
VTEMPLATE ************* CLONE VACCESS8 *****************
 
VTEMPLATE Clone from vtemplate1 to vaccess8
interface Virtual-Access8
no ip address
encap ppp
ip unnumbered Ethernet0
no ip mroute-cache
fair-queue 64 256 0
no cdp enable
ppp authentication chap
end
 
%LINK-3-UPDOWN: Interface Virtual-Access8, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access8, changed state to up
 

The following is sample output from the debug vtemplate command when a virtual access interface goes down. The virtual interface is uncloned and returns to the recycle queue.

Router# debug vtemplate
 
%LINK-3-UPDOWN: Interface Virtual-Access8, changed state to down
VTEMPLATE Free vaccess8
 
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access8, changed state to down
VTEMPLATE clean up dirty vaccess queue, size:1
 
VTEMPLATE Found a dirty vaccess8 clone with vtemplate
VTEMPLATE ************ UNCLONE VACCESS8 **************
VTEMPLATE Unclone to-be-freed vaccess8 command#7
interface Virtual-Access8
default ppp authentication chap
default cdp enable
default fair-queue 64 256 0
default ip mroute-cache
default ip unnumbered Ethernet0
default encap ppp
default ip address
end
 
VTEMPLATE set default vaccess8 with no ip address
 
VTEMPLATE remove cloneblk vtemplate from vaccess8 with vtemplate
 
VTEMPLATE Add vaccess8 to recycle queue, size=51
 

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

The debug vtsp all command enables the following debug vtsp commands: debug vtsp session, debug vtsp error, and debug vtsp dsp. For more information or sample output, refer to the individual commands in this chapter.

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

The debug vtsp dsp command shows messages from the DSP on the VFC to the router; this command can be useful if you suspect that the VFC is not functional. It is a simple way to check of the VFC is responding to off-hook indications.

Examples

*Nov 30 00:44:34.491: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT: digit=3
*Nov 30 00:44:36.267: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT: digit=1
*Nov 30 00:44:36.571: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT: digit=0
*Nov 30 00:44:36.711: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT: digit=0
*Nov 30 00:44:37.147: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT: digit=2
 

Syntax Description

slot-number	Specifies the slot number in the Cisco router where the voice interface card is installed. Valid entries are from 0 to 3, depending on the router being used and the slot where the voice interface card has been installed.
subunit-number	Specifies the subunit on the voice interface card where the voice port is located. Valid entries are 0 or 1.
port	Specifies the voice port. Valid entries are 0 or 1.

Command History

Release	Modification
12.0(3)XG	This command was introduced.

Usage Guidelines

This command is not supported on Cisco 7200 series routers or on the Cisco MC3810.

Use this command to limit the debug output to a particular port. The debug output can be quite voluminous for a single channel. A 12-port box might create problems. Use this debug command with any or all of the other debug modes.

Execution of the no debug vtsp all command will turn off all VTSP-level debugging. It is usually a good idea to turn off all debugging and then enter the debug commands you are interested in one by one. This will help to avoid confusion about which ports you are actually debugging.

Examples

The following example shows sample output from the debug vtsp port 1/1/0 command:

router# debug vtsp port 1/1/0
*Mar  1 03:17:33.691: vtsp_tsp_call_setup_ind (sdb=0x613FD514, tdm_info=0x0,
   tsp_info=0x613FD438, calling_number= called_number= redirect_number=): peer_tag=1110
*Mar  1 03:17:33.691: vtsp_do_call_setup_ind
*Mar  1 03:17:33.691: dsp_close_voice_channel: [] packet_len=8 channel_id=1
   packet_id=75
*Mar  1 03:17:33.691: dsp_open_voice_channel: [] packet_len=12
   channel_id=1 packet_id=74 alaw_ulaw_select=0 transport_protocol=2
*Mar  1 03:17:33.695: dsp_set_playout_delay: [] packet_len=18
   channel_id=1 packet_id=76 mode=1 initial=60 min=4 max=200 fax_nom=300
*Mar  1 03:17:33.695: dsp_echo_canceller_control: [] packet_len=10 channel_id=1
   packet_id=66 flags=0x0
*Mar  1 03:17:33.695: dsp_set_gains: [] packet_len=12 channel_id=1 packet_id=91
   in_gain=0 out_gain=65506
*Mar  1 03:17:33.695: dsp_vad_enable: [] packet_len=10 channel_id=1 packet_id=78
   thresh=-38
*Mar  1 03:17:33.695: vtsp_process_event(): [, 0.S_SETUP_INDICATED, E_CC_PROCEEDING]
*Mar  1 03:17:33.699: vtsp_process_event(): [, 0.S_SETUP_INDICATED,
   E_CC_BRIDGE]act_bridge
*Mar  1 03:17:33.699: vtsp_ring_noan_timer_start: 1185370
*Mar  1 03:17:33.699: vtsp_process_event(): [, 0.S_SETUP_INDICATED,
   E_CC_CAPS_IND]act_caps_ind
*Mar  1 03:17:33.699: act_caps_ind: Encap 2, Vad 2, Codec 0x1000, CodecBytes 60,
              FaxRate 2, FaxBytes 30,
              Sub-channel 10, Bitmask 0x0 SignalType 2
*Mar  1 03:17:33.703: vtsp_process_event(): [, 0.S_SETUP_INDICATED,
   E_CC_CAPS_ACK]act_caps_ack
*Mar  1 03:17:33.703: dsp_idle_mode: [] packet_len=8 channel_id=1 packet_id=68
*Mar  1 03:17:33.703: vtsp_process_event(): [, 0.S_SETUP_INDICATED,
   E_CC_CONNECT]act_connect
*Mar  1 03:17:33.703: vtsp_ring_noan_timer_stop: 1185370
*Mar  1 03:17:33.911: vtsp_process_event(): [, 0.S_CONNECT, E_DSPRM_PEND_SUCCESS]
   act_pend_codec_success
*Mar  1 03:17:33.911: dsp_close_voice_channel: [] packet_len=8 channel_id=1
   packet_id=75
*Mar  1 03:17:33.911: dsp_open_voice_channel: [] packet_len=12 channel_id=1
   packet_id=74 alaw_ulaw_select=0 transport_protocol=2
*Mar  1 03:17:33.911: dsp_set_playout_delay: [] packet_len=18 channel_id=1 packet_id=76
   mode=1 initial=60 min=4 max=200 fax_nom=300
*Mar  1 03:17:33.911: dsp_echo_canceller_control: [] packet_len=10 channel_id=1
   packet_id=66 flags=0x0
*Mar  1 03:17:33.911: dsp_set_gains: [] packet_len=12 channel_id=1 packet_id=91
   in_gain=0 out_gain=65506
*Mar  1 03:17:33.911: dsp_vad_enable: [] packet_len=10 channel_id=1 packet_id=78
   thresh=-38
*Mar  1 03:17:33.911: dsp_encap_config: [] packet_len=24 channel_id=1 packet_id=
 92 TransportProtocol 3 SID_support=0 sequence_number=0 rotate_flag=0 header_bytes 0xA0
*Mar  1 03:17:33.915: dsp_voice_mode: [] packet_len=22 channel_id=1 packet_id=73
 coding_type=14 voice_field_size=60 VAD_flag=1 echo_length=128
 comfort_noise=1 fax_detect=1 digit_relay=0

Related Commands

Command	Description
debug vpm all	Enables debugging of all VPM areas.
debug vtsp vofr subframe	Displays the first 10 bytes (including header) of selected VoFR subframes for the interface.

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

The debug vtsp session command traces how the router interacts with the DSP based on the signalling indications from the signalling stack and requests from the application. This debug command displays information about how each network indication and application request is handled, signalling indications, and DSP control messages.

This debug level shows the internal workings of the voice telephony call state machine.

Examples

Accept call and check for incoming dial-peer match:

*Nov 30 00:46:19.535: vtsp_tsp_call_accept_check (sdb=0x60CD4C58,
calling_number=408 called_number=1): peer_tag=0
*Nov 30 00:46:19.535: vtsp_tsp_call_setup_ind (sdb=0x60CD4C58,
tdm_info=0x60B80044, tsp_info=0x60B09EB0, calling_number=408 called_number=1):
peer_tag=1
 

*Nov 30 00:46:19.535: vtsp_do_call_setup_ind:
*Nov 30 00:46:19.535: dsp_open_voice_channel: [0:D:12] packet_len=12
channel_id=8737 packet_id=74 alaw_ulaw_select=0 transport_protocol=2
*Nov 30 00:46:19.535: dsp_set_playout_delay: [0:D:12] packet_len=18
channel_id=8737 packet_id=76 mode=1 initial=60 min=4 max=200 fax_nom=300 
*Nov 30 00:46:19.535: dsp_echo_canceller_control: [0:D:12] packet_len=10
channel_id=8737 packet_id=66 flags=0x0
*Nov 30 00:46:19.539: dsp_set_gains: [0:D:12] packet_len=12 channel_id=8737
packet_id=91 in_gain=0 out_gain=0
*Nov 30 00:46:19.539: dsp_vad_enable: [0:D:12] packet_len=10 channel_id=8737
packet_id=78 thresh=-38
*Nov 30 00:46:19.559: vtsp_process_event: [0:D:12, 0.3, 13] act_setup_ind_ack 
 

*Nov 30 00:46:19.559: dsp_voice_mode: [0:D:12] packet_len=20 channel_id=8737
packet_id=73 coding_type=1 voice_field_size=160 VAD_flag=0 echo_length=64
comfort_noise=1 fax_detect=1
*Nov 30 00:46:19.559: dsp_dtmf_mode: [0:D:12] packet_len=10 channel_id=8737
packet_id=65 dtmf_or_mf=0
*Nov 30 00:46:19.559: dsp_cp_tone_on: [0:D:12] packet_len=30 channel_id=8737
packet_id=72 tone_id=3 n_freq=2 freq_of_first=350 freq_of_second=440
amp_of_first=4000 amp_of_second=4000 direction=1 on_time_first=65535
off_time_first=0 on_time_second=65535 off_time_second=0
*Nov 30 00:46:19.559: vtsp_timer: 278792
*Nov 30 00:46:22.059: vtsp_process_event: [0:D:12, 0.4, 25] act_dcollect_digit 
*Nov 30 00:46:22.059: dsp_cp_tone_off: [0:D:12] packet_len=8 channel_id=8737
packet_id=71
*Nov 30 00:46:22.059: vtsp_timer: 279042
*Nov 30 00:46:22.363: vtsp_process_event: [0:D:12, 0.4, 25] act_dcollect_digit 
*Nov 30 00:46:22.363: dsp_cp_tone_off: [0:D:12] packet_len=8 channel_id=8737
packet_id=71
*Nov 30 00:46:22.363: vtsp_timer: 279072
*Nov 30 00:46:22.639: vtsp_process_event: [0:D:12, 0.4, 25] act_dcollect_digit 
*Nov 30 00:46:22.639: dsp_cp_tone_off: [0:D:12] packet_len=8 channel_id=8737
packet_id=71
*Nov 30 00:46:22.639: vtsp_timer: 279100
*Nov 30 00:46:22.843: vtsp_process_event: [0:D:12, 0.4, 25] act_dcollect_digit 
*Nov 30 00:46:22.843: dsp_cp_tone_off: [0:D:12] packet_len=8 channel_id=8737
packet_id=71
*Nov 30 00:46:22.843: vtsp_timer: 279120
*Nov 30 00:46:23.663: vtsp_process_event: [0:D:12, 0.4, 25] act_dcollect_digit 
*Nov 30 00:46:23.663: dsp_cp_tone_off: [0:D:12] packet_len=8 channel_id=8737
packet_id=71
*Nov 30 00:46:23.663: vtsp_timer: 279202
 

*Nov 30 00:46:23.663: vtsp_process_event: [0:D:12, 0.4, 15] act_dcollect_proc 
*Nov 30 00:46:23.663: dsp_cp_tone_off: [0:D:12] packet_len=8 channel_id=8737
packet_id=71
*Nov 30 00:46:23.663: dsp_idle_mode: [0:D:12] packet_len=8 channel_id=8737
packet_id=68 
 

*Nov 30 00:46:23.699: vtsp_process_event: [0:D:12, 0.5, 17] act_bridge 
*Nov 30 00:46:23.699: vtsp_process_event: [0:D:12, 0.5, 22] act_caps_ind 
*Nov 30 00:46:23.699: vtsp_process_event: [0:D:12, 0.5, 23] act_caps_ack 
Go into voice mode with codec indicated in caps exchange.
*Nov 30 00:46:23.699: dsp_cp_tone_off: [0:D:12] packet_len=8 channel_id=8737
packet_id=71
*Nov 30 00:46:23.699: dsp_idle_mode: [0:D:12] packet_len=8 channel_id=8737
packet_id=68
*Nov 30 00:46:23.699: dsp_voice_mode: [0:D:12] packet_len=20 channel_id=8737
packet_id=73 coding_type=6 voice_field_size=20 VAD_flag=1 echo_length=64
comfort_noise=1 fax_detect=1
 

*Nov 30 00:46:23.779: vtsp_process_event: [0:D:12, 0.5, 10] act_connect
 

*Nov 30 00:46:30.267: vtsp_process_event: [0:D:12, 0.11, 5] act_generate_disc 
 

*Nov 30 00:46:30.267: vtsp_process_event: [0:D:12, 0.11, 18] act_bdrop 
*Nov 30 00:46:30.267: dsp_cp_tone_off: [0:D:12] packet_len=8 channel_id=8737
packet_id=71
*Nov 30 00:46:30.267: vtsp_process_event: [0:D:12, 0.11, 20] act_disconnect 
*Nov 30 00:46:30.267: dsp_get_error_stat: [0:D:12] packet_len=10 channel_id=0
packet_id=6 reset_flag=1
*Nov 30 00:46:30.267: vtsp_timer: 279862
 

*Nov 30 00:46:30.275: vtsp_process_event: [0:D:12, 0.17, 30] act_get_error 
*Nov 30 00:46:30.275: 0:D:12: rx_dropped=0 tx_dropped=0 rx_control=353
tx_control=338 tx_control_dropped=0 dsp_mode_channel_1=2 dsp_mode_channel_2=0
c[0]=71 c[1]=71 c[2]=71 c[3]=71 c[4]=68 c[5]=71 c[6]=68 c[7]=73 c[8]=83 c[9]=84
c[10]=87 c[11]=83 c[12]=84 c[13]=87 c[14]=71 c[15]=6
*Nov 30 00:46:30.275: dsp_get_levels: [0:D:12] packet_len=8 channel_id=8737
packet_id=89
*Nov 30 00:46:30.279: vtsp_process_event: [0:D:12, 0.17, 34] act_get_levels 
*Nov 30 00:46:30.279: dsp_get_tx_stats: [0:D:12] packet_len=10 channel_id=8737
packet_id=86 reset_flag=1
*Nov 30 00:46:30.287: vtsp_process_event: [0:D:12, 0.17, 31] act_stats_complete 
*Nov 30 00:46:30.287: dsp_cp_tone_off: [0:D:12] packet_len=8 channel_id=8737
packet_id=71
*Nov 30 00:46:30.287: dsp_idle_mode: [0:D:12] packet_len=8 channel_id=8737
packet_id=68
*Nov 30 00:46:30.287: vtsp_timer: 279864
 

*Nov 30 00:46:30.287: vtsp_process_event: [0:D:12, 0.18, 6] act_wrelease_release 
*Nov 30 00:46:30.287: dsp_cp_tone_off: [0:D:12] packet_len=8 channel_id=8737
packet_id=71
*Nov 30 00:46:30.287: dsp_idle_mode: [0:D:12] packet_len=8 channel_id=8737
packet_id=68
*Nov 30 00:46:30.287: dsp_close_voice_channel: [0:D:12] packet_len=8
channel_id=8737 packet_id=75
*Nov 30 00:46:30.287: vtsp_process_event: [0:D:12, 0.16, 42] act_terminate 

Syntax Description

payload	Number used to selectively display subframes of a specific payload. The payload types are: 0---Primary Payload Caution This option may cause network instability 1---Annex-A 2---Annex-B 3---Annex-D 4---All other payloads 5---All payloads Caution This option may cause network instability
from-dsp	(Optional) Displays only the subframes received from the DSP.
to-dsp	(Optional) Displays only the subframes going to the DSP.

Command History

Release	Modification
12.0(3)XG	This command was introduced.

Usage Guidelines

This command is not supported on Cisco 7200 series routers or on the Cisco MC3810.

Each debug output displays the first 10 bytes of the FRF.11 subframe, including header bytes. The from-dsp and to-dsp options can be used to limit the debugs to a single direction. If not specified, debugs are displayed for subframes when they are received from the DSP and before they are sent to the DSP.

Use extreme caution in selecting payload options 0 and 5. These options may cause network instability.

Examples

The following example shows sample output from the debug vtsp vofr subframe command:

router# debug vtsp vofr subframe 2
vtsp VoFR subframe debugging is enabled for payload 2 to and from DSP 3620_vofr#
*Mar  6 18:21:17.413:VoFR frame received from Network (24 bytes):9E 02 19 AA AA AA AA
      AA AA AA
*Mar  6 18:21:17.449:VoFR frame received from DSP (18 bytes):9E 02 19 AA AA AA AA AA AA
      AA
*Mar  6 18:21:23.969:VoFR frame received from Network (24 bytes):9E 02 19 AA AA AA AA
      AA AA AA
*Mar  6 18:21:24.005:VoFR frame received from DSP (18 bytes):9E 02 19 AA AA AA AA AA AA
      AA

Caution This command is processor intensive and can render the router useless. Use this command only when the aggregate of all reportable X.25 traffic is fewer than five packets per second (pps). The generic forms of this command should be restricted to low-speed, low-usage links running at less than 19.2 kbps. Because the debug x25 vc command and the debug x25 vc events command display traffic for only a small subset of virtual circuits, they are safer to use under heavy traffic conditions, as long as events for that virtual circuit are fewer than 25 pps.

To display information about all X.25 traffic, including traffic for X.25, Connection Mode Network Service (CMNS), and X.25 over TCP (XOT) services, use the debug x25 command (default all). Use the no form of this command to disable debugging output.

To display information about all X.25 traffic except data and resource record packets, use the debug x25 events command. Use the no form of this command to disable debugging output.

To display information about a specific X.25 service class, use the following form of the debug x25 command. Use the no form of this command to disable debugging output.

To display information about a specific X.25 or CMNS context, use the following form of the debug x25 command. Use the no form of this command to disable debugging output.

To display information about a specific X.25 or CMNS virtual circuit, use the following form of the debug x25 command. Use the no form of this command to disable debugging output.

To display information about traffic for all virtual circuits using a given number, use the following form of the debug x25 command. The no form of this command removes the filter for a particular virtual circuit from the debug x25 all or debug x25 events output. Use the no form of this command to disable debugging output.

To display information about traffic to or from a specific XOT host, use the following form of the debug x25 xot command. Use the no form of this command to disable debugging output.

Use the debug x25 command with the aodi keyword to display information about an interface running PPP over an X.25 session. The no form of this command disables debugging output. Use the no form of this command to disable debugging output.

Syntax Description

events	(Optional) Displays all traffic except Data and Receiver Ready (RR) packets.
only | cmns | xot	(Optional) Displays information about the specified services: X.25 only, CMNS, or XOT.
all	(Optional) Displays all traffic.
serial-interface	X.25 serial interface.
cmns-interface mac mac-address	MAC address of the CMNS interface and remote host. The interface type can be Ethernet, Token Ring, or FDDI.
vc number	Virtual circuit number, in the range 1 to 4095.
remote ip-address [port number]	(Optional) Remote IP address and, optionally, a port number in the range 1 to 65535.
local ip-address [port number]	(Optional) Local host IP address and, optionally, a port number in the range 1 to 65535.
aodi	Causes the debug x25 command to display Always On/Dynamic ISDN (AO/DI) events and processing information.

Defaults

The default is that all traffic is displayed.

Command History

Release	Modification
10.0	This command was introduced.
12.0(5)T	For DNS-based X.25 routing, additional functionality was added to the debug x25 events command to describe the events occurring while resolving the X.25 address to an IP address using a DNS server. The debug domain command can be used along with debug x25 events to observe the whole DNS-based X.25 routing data flow. (For more details, see "debug x25 events for DNS-Based X.25 Routing" in the "Examples" section.)
12.0(7)T	For the X.25 CUGs feature, functionality was added to the debug x25 events command to describe events occurring during CUG activity. (For more details, see "debug x25 events for X.25 CUGs" in the "Examples" section.)

Usage Guidelines

This command is particularly useful for diagnosing problems encountered when placing calls. The debug x25 all output includes data, control messages, and flow control packets for all virtual circuits of the router.

All debug x25 command forms can take either the events or all keyword. The keyword all is the default and causes all packets meeting the other debug criteria to be reported. The keyword events omits reports of any Data or Receiver Ready (RR) flow control packets; the normal flow of data and RR packets is commonly large and less interesting to the user, so event reporting can significantly decrease the processor load induced by debug reporting.

The debug x25 interface command is useful for diagnosing problems encountered with a single X.25 or CMNS host or virtual circuit.

Because no interface is specified by the debug x25 vc command, traffic on any virtual circuit that has the specified number is reported.

Virtual circuit zero (vc 0) cannot be specified. It is used for X.25 service messages, such as RESTART packets, not virtual circuit traffic. Service messages can be monitored only when no virtual circuit filter is used.

The debug x25 xot output allows you to restrict the debug output reporting to XOT traffic for one or both hosts or host/port combinations. Because each XOT virtual circuit uses a unique TCP connection, an XOT debug request that specifies both host addresses and ports will report traffic only for that virtual circuit. Also, you can restrict reporting to sessions initiated by the local or remote router by specifying 1998 for the remote or local port. (XOT connections are received on port 1998.)

Use the debug x25 aodi command to display interface PPP events running over an X.25 session and to debug X.25 connections between a client and server configured for AO/DI.

Examples

The following is sample output from the debug x25 command, displaying output concerning the functions X.25 restart, call setup, data exchange, and clear:

Router# debug x25
 
Serial0: X.25 I R/Inactive Restart (5) 8 lci 0
Cause 7, Diag 0 (Network operational/No additional information)
Serial0: X.25 O R3 Restart Confirm (3) 8 lci 0
Serial0: X.25 I P1 Call (15) 8 lci 1
From(6): 170091 To(6): 170090
 Facilities: (0)
 Call User Data (4): 0xCC000000 (ip)
Serial0: X.25 O P3 Call Confirm (3) 8 lci 1
Serial0: X.25 I D1 Data (103) 8 lci 1 PS 0 PR 0
Serial0: X.25 O D1 Data (103) 8 lci 1 PS 0 PR 1
Serial0: X.25 I P4 Clear (5) 8 lci 1
Cause 9, Diag 122 (Out of order/Maintenance action)
Serial0: X.25 O P7 Clear Confirm (3) 8 lci 1
 

The following example shows a sequence of increasingly restrictive debug x25 commands:

Router# debug x25
X.25 packet debugging is on
 
Router# debug x25 events
X.25 special event debugging is on
 
Router# debug x25 interface serial 0
X.25 packet debugging is on
X.25 debug output restricted to interface Serial0 
 
Router# debug x25 vc 1024
X.25 packet debugging is on
X.25 debug output restricted to VC number 1024 
 
Router# debug x25 interface serial 0 vc 1024
X.25 packet debugging is on
X.25 debug output restricted to interface Serial0 
X.25 debug output restricted to VC number 1024 
 
Router# debug x25 interface serial 0 vc 1024 events
X.25 special event debugging is on
X.25 debug output restricted to interface serial 0 
X.25 debug output restricted to VC number 1024
 

The following examples show the normal sequence of events for both the AO/DI client and server sides:

Client Side

Router# debug x25 aodi
PPP-X25: Virtual-Access1: Initiating AODI call request
PPP-X25: Bringing UP X.25 AODI VC
PPP-X25: AODI Client Call Confirm Event Received
PPP-X25: Cloning interface for AODI is Di1
PPP-X25: Queuing AODI Client Map Event
PPP-X25: Event:AODI Client Map
PPP-X25: Created interface Vi2 for AODI service
PPP-X25: Attaching primary link Vi2 to Di1
PPP-X25: Cloning Vi2 for AODI service using Di1
PPP-X25: Vi2: Setting the PPP call direction as OUT
PPP-X25: Vi2: Setting vectors for RFC1598 operation on BRI3/0:0 VC 0
PPP-X25: Vi2: Setting the interface default bandwidth to 10 Kbps
PPP-X25: Virtual-Access2: Initiating AODI call request
PPP-X25: Bringing UP X.25 AODI VC
PPP-X25: AODI Client Call Confirm Event Received
 

Server Side

Router# debug x25 aodi
PPP-X25: AODI Call Request Event Received
PPP-X25: Event:AODI Incoming Call Request
PPP-X25: Created interface Vi1 for AODI service
PPP-X25: Attaching primary link Vi1 to Di1
PPP-X25: Cloning Vi1 for AODI service using Di1
PPP-X25: Vi1: Setting vectors for RFC1598 operation on BRI3/0:0 VC 1
PPP-X25: Vi1: Setting the interface default bandwidth to 10 Kbps
PPP-X25: Binding X.25 VC 1 on BRI3/0:0 to Vi1
 

Router# debug x25 events
00:48:33:Serial1:X.25 I R1 Call (14) 8 lci 1024
00:48:33:  From (3):111 To (3):444
00:48:33:  Facilities:(2)
00:48:33:    Closed User Group (basic):40
00:48:33:  Call User Data (4):0x01000000 (pad) 
00:48:33:X.25 Incoming Call packet, Closed User Group (CUG) protection, selected network CUG not subscribed
00:48:33:Serial1:X.25 O R1 Clear (5) 8 lci 1024
00:48:33:  Cause 11, Diag 65 (Access barred/Facility code not allowed)
 

Router# debug x25 events
00:18:25:Serial1:X.25 I R1 Call (11) 8 lci 1024
00:18:25:  From (0): To (4):444 
00:18:25:  Facilities:(0)
00:18:25:  Call User Data (4):0x01000000 (pad)
00:18:25:X.25 host name sent for DNS lookup is "444"
00:18:26:%3-TRUNCATE_ALT_XOT_DNS_DEST:Truncating excess XOT addresses (3)
returned by DNS
00:18:26:DNS got X.25 host mapping for "444" via network
00:18:32:[10.1.1.8 (pending)]:XOT open failed (Connection timed out; remote host not responding)
00:18:38:[10.1.1.7 (pending)]:XOT open failed (Connection timed out; remote host not responding)
00:18:44:[10.1.1.6 (pending)]:XOT open failed (Connection timed out; remote host not responding)
00:18:50:[10.1.1.5 (pending)]:XOT open failed (Connection timed out; remote host not responding)
00:18:56:[10.1.1.4 (pending)]:XOT open failed (Connection timed out; remote host not responding)
00:20:04:[10.1.1.3,1998/10.1.1.3,11007]:XOT O P2 Call (17) 8 lci 1
00:20:04:  From (0): To (4):444
00:20:04:  Facilities:(6)
00:20:04:    Packet sizes:128 128
00:20:04:    Window sizes:2 2
00:20:04:  Call User Data (4):0x01000000 (pad) 
00:20:04:[10.1.1.3,1998/10.1.1.3,11007]:XOT I P2 Call Confirm (11) 8 lci 1
00:20:04:  From (0): To (0):
00:20:04:  Facilities:(6)
00:20:04:    Packet sizes:128 128
00:20:04:    Window sizes:2 2
00:20:04:Serial1:X.25 O R1 Call Confirm (5) 8 lci 1024
00:20:04:  From (0): To (0):
00:20:04:  Facilities:(0)

Related Commands

Command	Description
debug ppp bap	Displays general BACP transactions.
debug ppp bap negotiation	Displays general BACP transactions, as well as successive steps in negotiations between peers.
debug ppp multilink	Displays information about important multilink events.
debug ppp multilink negotiation	Displays information about important multilink events and events affecting multilink groups controlled by BACP.

Syntax Description

This command has no arguments or keywords.

Examples

The following is sample output while the PAD initiates an X.28 outgoing call:

Router# debug x28
X28 MODE debugging is on
Router# x28
 
*
03:30:43: X.28 mode session started
03:30:43: X28 escape is exit
03:30:43: Speed for console & vty lines :9600 
*call 123456
COM
03:39:04: address ="123456", cud="[none]" 03:39:04: Setting X.3 Parameters for this call...1:1 2:1 3:126 4:0 5:1 6:2 7:2 8:0 9:0 10:0 11:14 12:1 13:0 14:0 15:0 16:127 17:24 18:18 19:2 20:0 21:0 22:0 
 
Router> exit
CLR CONF
 
*
*03:40:50: Session ended
* exit
 
Router#
*03:40:51: Exiting X.28 mode

Syntax Description

This command has no arguments or keywords.

Command History

Release	Modification
12.0(5)T	This command was introduced.
12.0(7)T	Support for this command was extended to the Cisco uBR924 cable modem.

Examples

See the following examples to turn on and off external call control debugging:

AS5300-TGW# debug xcctsp all
External call control all debugging is on
 
AS5300-TGW# no debug xcct all
External call control all debugging is off
 
AS5300-TGW# 

Related Commands

Command	Description
debug xcctsp error	Enables debugging on external call control errors.
debug xcctsp session	Enables debugging on external call control sessions.

Syntax Description

This command has no arguments or keywords.

Command History

Release	Modification
12.0(5)T	This command was introduced.
12.0(7)T	Support for this command was extended to the Cisco uBR924 cable modem.

Examples

See the following examples to turn on and off error-level debugging:

AS5300-TGW# debug xcctsp error
External call control error debugging is on
 
AS5300-TGW# no debug xcctsp error
External call control error debugging is off

Related Commands

Command	Description
debug xcctsp all	Enables debugging on all external call control levels.
debug xcctsp session	Enables debugging on external call control sessions.

Syntax Description

This command has no arguments or keywords.

Command History

Release	Modification
12.0(5)T	This command was introduced.
12.0(7)T	Support for this command was extended to the Cisco uBR924 cable modem.

Examples

See the following examples to turn on and off session-level debugging:

AS5300-TGW# debug xcct session
External call control session debugging is on
 
AS5300-TGW# no debug xcct session
External call control session debugging is off
 
AS5300-TGW# 

Related Commands

Command	Description
debug xcctsp all	Enables debugging on external call control levels.
debug xcctsp error	Enables debugging on external call control errors.

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

To gain the fullest understanding of XNS routing activity, you should enable debug xns routing and debug xns packet together.

Examples

The following is sample output from the debug xns packet command:

Router# debug xns packet
 
XNS: src=5.0000.0c02.6d04, dst=5.ffff.ffff.ffff, packet sent
XNS: src=1.0000.0c00.440f, dst=1.ffff.ffff.ffff, rcvd. on Ethernet0
XNS: src=1.0000.0c00.440f, dst=1.ffff.ffff.ffff, local processing
 

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

To gain the fullest understanding of XNS routing activity, enable debug xns routing and debug xns packet together.

Examples

The following is sample output from the debug xns routing command:

Router# debug xns routing
 
XNSRIP: sending standard periodic update to 5.ffff.ffff.ffff via Ethernet2
 network 1, hop count 1
 network 2, hop count 2
 
XNSRIP: got standard update from 1.0000.0c00.440f socket 1 via Ethernet0
 net 2: 1 hops