Cisco IOS 12.4 Debug CR

Cisco IOS Debug Command Reference
May 2008
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL
STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT
SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE
OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCBs public
domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED AS IS WITH
ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT
LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF
DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING,
WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO
OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way
We Work, Live, Play, and Learn is a service mark; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA,
CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo,
Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient,
IOS, iPhone, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MGX,
Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The
Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United
States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship
between Cisco and any other company. (0805R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the
document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

2008 Cisco Systems, Inc. All rights reserved.
Introduction
The Cisco IOS Debug Command Reference book consists of the following chapters:
Using Debug CommandsExplains how you use debug commands to diagnose and resolve
internetworking problems.
Conditionally Triggered DebuggingDescribes how to obtain debugging messages for packets
entering or leaving a router on a specified interface.
Debug CommandsProvides detailed descriptions of the debug commands and how to use them.
X.25 Cause and Diagnostic CodesDescribes the X.25 causes and diagnostic codes that appear in
certain debug command output.
ISDN Switch Types, Codes, and ValuesContains a list of the supported switch types, the ISDN
cause codes, cause values, bearer capability values, and progress description field values that are
valid within the debug commands for ISDN.
Output formats vary with each debug command. Some commands generate a single line of output per
packet, whereas others generate multiple lines of output per packet. Some generate large amounts of
output; others generate only occasional output. Some generate lines of text, and others generate
information in field format. Therefore, the way debug command output is documented also varies. For
example, the output for debug commands that generate lines of text is usually described line by line, and
the output for debug commands that generate information in field format is usually described in tables.
By default, the network server sends the output from the debug commands to the console. Sending
output to a terminal (virtual console) produces less overhead than sending it to the console. Use the
terminal monitor privileged EXEC command to send output to a terminal. For more information about
redirecting output, see the Using Debug Commands chapter.

May 2008 DB-1
Introduction

DB-2 May 2008
Using Debug Commands
This chapter explains how to use debug commands to diagnose and resolve internetworking problems.
Specifically, this chapter covers the following topics:
Entering debug commands
Using the debug ? command
Using the debug all command
Generating debug command output
Redirecting debug and error message output
Caution Because debugging output is assigned high priority in the CPU process, it can render the system
unusable. For this reason, use debug commands only to troubleshoot specific problems or during
troubleshooting sessions with Cisco technical support staff. Moreover, it is best to use debug commands
during periods of lower network traffic and fewer users. Debugging during these periods decreases the
likelihood that increased debug command processing overhead will affect system use.
Entering debug Commands

All debug commands are entered in privileged EXEC mode, and most debug commands take no
arguments. For example, to enable the debug isdn q931 command, enter the following the command line
in privileged EXEC mode:
debug isdn q931
To turn off the debug isdn q931 command, enter the no form of the command at the command line in
privileged EXEC mode:
no debug isdn q931
To display the state of each debugging option, enter the following at the command line in privileged
EXEC mode:
show debugging

May 2008 DB-3
Using the debug ? Command
Using the debug ? Command

To list and see a brief description of all the debugging command options, enter the following command
at the command line in privileged EXEC mode:
debug ?
Not all debugging commands listed in the debug ? output are described in this document. Commands
are included here based on their usefulness in assisting you to diagnose network problems. Commands
not included are typically used internally by Cisco engineers during the development process and are not
intended for use outside the Cisco environment.
Using the debug all Command

To enable all system diagnostics, enter the following command at the command line in privileged EXEC
mode:
debug all
The no debug all command turns off all diagnostic output. Using the no debug all command is a
convenient way to ensure that you have not accidentally left any debug commands turned on.
Caution Because debugging output takes priority over other network traffic, and because the debug all command
generates more output than any other debug command, it can severely diminish the performance of the
router or even render it unusable. In virtually all cases, it is best to use more specific debug commands.
Generating debug Command Output

Enabling a debug command can result in output similar to the following example for the debug modem
command:
Router# debug modem
15:25:51: TTY4: DSR came up

15:25:51: tty4: Modem: IDLE->READY
15:25:51: TTY4: Autoselect started
15:27:51: TTY4: Autoselect failed
15:27:51: TTY4: Line reset
15:27:51: TTY4: Modem: READY->HANGUP
15:27:52: TTY4: dropping DTR, hanging up
15:27:52: tty4: Modem: HANGUP->IDLE
15:27:57: TTY4: restoring DTR
The router continues to generate such output until you enter the corresponding no debug command (in
this case, the no debug modem command).

DB-4 May 2008
Redirecting debug and Error Message Output
If you enable a debug command and no output is displayed, consider the following possibilities:
The router may not be properly configured to generate the type of traffic you want to monitor. Use
the more system:running-config EXEC command to check its configuration.
Even if the router is properly configured, it may not generate the type of traffic you want to monitor
during the particular period that debugging is turned on. Depending on the protocol you are
debugging, you can use commands such as the TCP/IP ping EXEC command to generate network
traffic.

By default, the network server sends the output from debug commands and system error messages to the
console. If you use this default, monitor debug output using a virtual terminal connection, rather than
the console port.
To redirect debug output, use the logging command options within configuration mode as described in
the following sections.
Possible destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a
syslog server. The syslog format is compatible with 4.3 Berkeley Standard Distribution (BSD) UNIX
and its derivatives.
Note Be aware that the debugging destination you use affects system overhead. Logging to the console
produces very high overhead, whereas logging to a virtual terminal produces less overhead. Logging to
a syslog server produces even less, and logging to an internal buffer produces the least overhead of any
method.
To configure message logging, you need to be in configuration command mode. To enter this mode, use
the configure terminal command at the EXEC prompt.
Enabling Message Logging

To enable message logging to all supported destinations other than the console, enter the following
command:
logging on
The default condition is logging on.

To direct logging to the console only and disable logging output to other destinations, enter the following
command:
no logging on

May 2008 DB-5
Setting the Message Logging Levels

You can set the logging levels when logging messages to the following devices:
Console
Monitor
Syslog server
Table 1 lists and briefly describes the logging levels and corresponding keywords you can use to set the
logging levels for these types of messages. The highest level of message is level 0, emergencies. The
lowest level is level 7, debugging, which also displays the greatest amount of messages. For information
about limiting these messages, see sections later in this chapter.
Table 1 Message Logging Keywords and Levels
Level Keyword Description Syslog Definition

0 emergencies System is unusable. LOG_EMERG
1 alerts Immediate action is needed. LOG_ALERT
2 critical Critical conditions exist. LOG_CRIT
3 errors Error conditions exist. LOG_ERR
4 warnings Warning conditions exist. LOG_WARNING
5 notification Normal, but significant, conditions LOG_NOTICE
exist.
6 informational Informational messages. LOG_INFO
7 debugging Debugging messages. LOG_DEBUG
Limiting the Types of Logging Messages Sent to the Console

To limit the types of messages that are logged to the console, use the logging console router
configuration command. The full syntax of this command follows:
logging console level
no logging console
The logging console command limits the logging messages displayed on the console to messages up to
and including the specified severity level, which is specified by the level argument. Keywords are listed
in order from the most severe level to the least severe.
The no logging console command disables logging to the console.
The following example sets console logging of messages at the debugging level, which is the least severe
level and which displays all logging messages:
logging console debugging

DB-6 May 2008
Logging Messages to an Internal Buffer

The default logging device is the console; all messages are displayed on the console unless otherwise
specified.
To log messages to an internal buffer, use the logging buffered router configuration command. The full
syntax of this command follows:
logging buffered
no logging buffered
The logging buffered command copies logging messages to an internal buffer instead of writing them
to the console. The buffer is circular in nature, so newer messages overwrite older messages. To display
the messages that are logged in the buffer, use the show logging privileged EXEC command. The first
message displayed is the oldest message in the buffer.
The no logging buffered command cancels the use of the buffer and writes messages to the console (the
default).
Limiting the Types of Logging Messages Sent to Another Monitor

To limit the level of messages logged to the terminal lines (monitors), use the logging monitor router
configuration command. The full syntax of this command follows:
logging monitor level
no logging monitor
The logging monitor command limits the logging messages displayed on terminal lines other than the
console line to messages with a level up to and including the specified level argument. To display logging
messages on a terminal (virtual console), use the terminal monitor privileged EXEC command.
The no logging monitor command disables logging to terminal lines other than the console line.
The following example sets the level of messages displayed on monitors other than the console to
notification:
logging monitor notification
Logging Messages to a UNIX Syslog Server

To log messages to a syslog server host, use the logging host global configuration command. The full
syntax of this command follows:
logging host {ip-address | host-name} [xml]
no logging host {ip-address | host-name} [xml]
The logging host command identifies a syslog server host that is to receive logging messages. The
ip-address argument is the IP address of the host. By issuing this command more than once, you build a
list of syslog servers that receive logging messages.
The no logging host command deletes the syslog server with the specified address from the list of
syslogs.

May 2008 DB-7
Limiting Messages to a Syslog Server

To limit the number of messages sent to syslog servers, use the logging trap router configuration
command. The full syntax of this command follows:
logging trap level
no logging trap
The logging trap command limits the logging messages sent to syslog servers to logging messages with
a level up to and including the specified level argument.
To send logging messages to a syslog server, specify its host address with the logging host command.
The default trap level is informational.
The no logging trap command returns the trap level to the default.
The current software generates the following categories of syslog messages:
Error messages at the emergencies level.
Error messages at the alerts level.
Error messages at the critical level.
Error messages about software or hardware malfunctions, displayed at the errors level.
Interface up/down transitions and system restart messages, displayed at the notification level.
Reload requests and low-process stack messages, displayed at the informational level.
Output from the debug commands, displayed at the debugging level.
The show logging privileged EXEC command displays the addresses and levels associated with the
current logging setup. The command output also includes ancillary statistics.
Example of Setting Up a UNIX Syslog Daemon
To set up the syslog daemon on a 4.3 BSD UNIX system, include a line such as the following in the file
/etc/syslog.conf:
local7.debugging /usr/adm/logs/tiplog
The local7 keyword specifies the logging facility to be used.

The debugging keyword specifies the syslog level. See Table 1 for other keywords that can be listed.
The UNIX system sends messages at or above this level to the specified file, in this case
/usr/adm/logs/tiplog. The file must already exist, and the syslog daemon must have permission to write
to it.
For the System V UNIX systems, the line should read as follows:
local7.debug /usr/admin/logs/cisco.log8

DB-8 May 2008
Conditionally Triggered Debugging
When the Conditionally Triggered Debugging feature is enabled, the router generates debugging
messages for packets entering or leaving the router on a specified interface; the router will not generate
debugging output for packets entering or leaving through a different interface. You can specify the
interfaces explicitly. For example, you may want to see debugging messages only for one interface or
subinterface. You can also turn on debugging for all interfaces that meet specified conditions. This
feature is useful on dial access servers, which have a large number of ports.
Normally, the router will generate debugging messages for every interface, resulting in a large number
of messages that consume system resources and can make it difficult to find the specific information you
need. By limiting the number of debugging messages, you can receive messages related to only the ports
you want to troubleshoot.
The Conditionally Triggered Debugging feature controls the output from the following protocol-specific
debug commands:
debug aaa {accounting | authorization | authentication}
debug dialer packets
debug isdn {q921 | q931}
debug modem
debug ppp {packet | negotiation | error | authentication | compression | cbcp}
Although this feature limits the output of the listed commands, it does not automatically enable the
generation of debugging output from these commands. Debugging messages are generated only when
the protocol-specific debug command is enabled. The debug command output is controlled through two
processes:
The protocol-specific debug commands specify which protocols are being debugged. For example,
the debug dialer events command generates debugging output related to dialer events.
The debug condition commands limit these debugging messages to those related to a particular
interface. For example, the debug condition username cisco command generates debugging output
only for interfaces with packets that specify a username of cisco.
To configure Conditionally Triggered Debugging, perform the tasks described in the following sections:
Enabling Protocol-Specific Debug Commands
Enabling Conditional Debugging Commands
Specifying Multiple Conditions

May 2008 DB-9

To generate any debugging output, the protocol-specific debug command for the desired output must be
enabled. Use the show debugging command to determine which types of debugging are enabled. Use
the following commands in privileged EXEC mode to enable or disable the desired protocol-specific
debug commands as needed:
Command Purpose
show debugging Determines which types of debugging are enabled.
debug protocol Enables the desired debugging commands.
no debug protocol Disables the debugging commands that are not desired.
If you want to have no output, disable all the protocol-specific debug commands.

If no debug condition commands are enabled, all debugging output, regardless of the interface, will be
displayed for the enabled protocol-specific debug commands.
The first debug condition command you enter enables conditional debugging. The router will display
messages only for interfaces that meet one of the specified conditions. If multiple conditions are
specified, the interface must meet at least one of the conditions in order for messages to be displayed.
To enable messages for interfaces specified explicitly or for interfaces that meet certain conditions,
perform the tasks described in the following sections:
Displaying Messages for One Interface
Displaying Messages for Multiple Interfaces
Limiting Messages Based on Conditions
Displaying Messages for One Interface

To disable debugging messages for all interfaces except one, use the following command in privileged
EXEC mode:
Command Purpose
debug condition interface interface-type interface-number Disables debugging messages for all
interfaces except one.
If you enter the debug condition interface command, the debugging output will be turned off for all
interfaces except the specified interface. To reenable debugging output for all interfaces, use the no
debug condition interface command.

DB-10 May 2008
Displaying Messages for Multiple Interfaces

To enable debugging messages for multiple interfaces, use the following commands in privileged EXEC
mode:
Command Purpose
debug condition interface interface-type interface-number Disables debugging messages for all
interfaces except one.
To enable debugging messages for
additional interfaces, repeat this
command until debugging messages
are enabled for all desired
interfaces.
If you specify more than one interface by entering this command multiple times, debugging output will
be displayed for all of the specified interfaces. To turn off debugging on a particular interface, use the
no debug interface command. If you use the no debug interface all command or remove the last debug
interface command, debugging output will be reenabled for all interfaces.
Limiting Messages Based on Conditions

The router can monitor interfaces to learn if any packets contain the specified value for one of the
following conditions:
Username
Calling party number
Called party number
If you enter a condition, such as calling number, debug output will be stopped for all interfaces. The
router will then monitor every interface to learn if a packet with the specified calling party number is
sent or received on any interfaces. If the condition is met on an interface or subinterface, debug
command output will be displayed for that interface. The debugging output for an interface is triggered
when the condition has been met. The debugging output continues to be disabled for the other interfaces.
If at some later time the condition is met for another interface, the debug output will become enabled for
that interface as well.
Once debugging output has been triggered on an interface, the output will continue until the interface
goes down. However, the session for that interface might change, resulting in a new username, called
party number, or calling party number. Use the no debug interface command to reset the debug trigger
mechanism for a particular interface. The debugging output for that interface will be disabled until the
interface meets one of the specified conditions.
To limit debugging messages based on a specified condition, use the following command in privileged
EXEC mode:
Command Purpose
debug condition {username username | Enables conditional debugging. The router will display
called dial-string | caller dial-string} messages only for interfaces that meet this condition.
To reenable the debugging output for all interfaces, use the no debug condition all command.

May 2008 DB-11

To limit debugging messages based on more than one condition, use the following commands in
privileged EXEC mode as needed:
Command Purpose
debug condition {username username | Enables conditional debugging and specifies the first
called dial-string | caller dial-string} condition.
debug condition {username username | Specifies the second condition. Repeat this task until all
called dial-string | caller dial-string} conditions are specified.
If you enter multiple debug condition commands, debugging output will be generated if an interface
meets at least one of the conditions. If you use the no debug condition command to remove one of the
conditions, using interfaces that meet only that condition will no longer produce debugging output.
However, interfaces that meet a condition other than the removed condition will continue to generate
output. Only if no active conditions are met for an interface will the output for that interface be disabled.
Conditionally Triggered Debugging Configuration Examples

In this example, four conditions have been set by the following commands:
debug condition interface serial 0
debug condition interface serial 1
debug condition interface virtual-template 1
debug condition username cisco
The first three conditions have been met by one interface. The fourth condition has not yet been met.
Router# show debug condition
Condition 1: interface Se0 (1 flags triggered)

Flags: Se0
Flags: Se1
Condition 3: interface Vt1 (1 flags triggered)
Flags: Vt1
Condition 4: username cisco (0 flags triggered)
When any debug condition command is entered, debugging messages for conditional debugging are
enabled. The following debugging messages show conditions being met on different interfaces as serial
interface 0 and serial interface 1 come up. For example, the second line of output indicates that serial
interface 0 meets the username cisco condition.
*Mar 1 00:04:41.647: %LINK-3-UPDOWN: Interface Serial0, changed state to up
*Mar 1 00:04:41.715: Se0 Debug: Condition 4, username cisco triggered, count 2
*Mar 1 00:04:42.963: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed
state to up
*Mar 1 00:04:43.271: Vi1 Debug: Condition 3, interface Vt1 triggered, count 1
*Mar 1 00:04:43.271: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
*Mar 1 00:04:43.279: Vi1 Debug: Condition 4, username cisco triggered, count 2
*Mar 1 00:04:43.283: Vi1 Debug: Condition 1, interface Se0 triggered, count 3
*Mar 1 00:04:44.039: %IP-4-DUPADDR: Duplicate address 172.27.32.114 on Ethernet 0,
sourced by 00e0.1e3e.2d41

DB-12 May 2008
*Mar 1 00:04:44.283: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1,

changed state to up
*Mar 1 00:04:54.667: %LINK-3-UPDOWN: Interface Serial1, changed state to up
*Mar 1 00:04:54.731: Se1 Debug: Condition 4, username cisco triggered, count 2
*Mar 1 00:04:54.735: Vi1 Debug: Condition 2, interface Se1 triggered, count 4
state to up
After a period of time, the show debug condition command displays the revised list of conditions:

Flags: Se0 Vi1
Flags: Se1 Vi1
Flags: Vt1 Vi1
Flags: Se0 Vi1 Se1
Next, serial interface 1 and serial interface 0 go down. When an interface goes down, conditions for that
interface are cleared.
*Mar 1 00:05:51.443: %LINK-3-UPDOWN: Interface Serial1, changed state to down
*Mar 1 00:05:51.471: Se1 Debug: Condition 4, username cisco cleared, count 1
*Mar 1 00:05:51.479: Vi1 Debug: Condition 2, interface Se1 cleared, count 3
state to down
*Mar 1 00:05:56.859: %LINK-3-UPDOWN: Interface Serial0, changed state to down
*Mar 1 00:05:56.887: Se0 Debug: Condition 4, username cisco cleared, count 1
*Mar 1 00:05:56.895: Vi1 Debug: Condition 1, interface Se0 cleared, count 2
*Mar 1 00:05:56.899: Vi1 Debug: Condition 3, interface Vt1 cleared, count 1
*Mar 1 00:05:56.899: Vi1 Debug: Condition 4, username cisco cleared, count 0
*Mar 1 00:05:56.903: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down
state to down
changed state to down
The final show debug condition output is the same as the output before the interfaces came up:

Flags: Se0
Flags: Se1
Flags: Vt1

May 2008 DB-13

DB-14 May 2008
Debug Commands
This chapter contains an alphabetical listing of the debug commands and their descriptions.
Documentation for each command includes a brief description of its use, command syntax, usage
guidelines, sample output, and a description of that output.

May 2008 DB-15
Debug Commands
debug aaa accounting

To display information on accountable events as they occur, use the debug aaa accounting command in
privileged EXEC mode. To disable debugging output, use the no form of this command.
no debug aaa accounting
Syntax Description This command has no arguments or keywords.
Command Modes Privileged EXEC (#)
Usage Guidelines The information displayed by the debug aaa accounting command is independent of the accounting
protocol used to transfer the accounting information to a server. Use the debug tacacs and debug radius
protocol-specific commands to get more detailed information about protocol-level issues.
You can also use the show accounting command to step through all active sessions and to print all the
accounting records for actively accounted functions. The show accounting command allows you to
display the active accountable events on the system. It provides systems administrators a quick look
at what is happening, and may also be useful for collecting information in the event of a data loss of
some kind on the accounting server. The show accounting command displays additional data on the
internal state of the authentication, authorization, and accounting (AAA) security system if debug aaa
accounting is turned on as well.
Examples The following is sample output from the debug aaa accounting command:
Router# debug aaa accounting
16:49:21: AAA/ACCT: EXEC acct start, line 10

16:49:32: AAA/ACCT: Connect start, line 10, glare
16:49:47: AAA/ACCT: Connection acct stop:
task_id=70 service=exec port=10 protocol=telnet address=172.31.3.78 cmd=glare bytes_in=308
bytes_out=76 paks_in=45 paks_out=54 elapsed_time=14
Related Commands Command Description

debug aaa authentication Displays information on accountable events as they occur.
debug aaa authorization Displays information on AAA/TACACS+ authorization.
debug radius Displays information associated with the RADIUS.
debug tacacs Displays information associated with the TACACS.

DB-16 May 2008
Debug Commands
debug aaa authentication

To display information on authentication, authorization, and accounting (AAA) TACACS+
authentication, use the debug aaa authentication command in privileged EXEC mode. To disable
debugging output, use the no form of this command.
no debug aaa authentication
Usage Guidelines Use this command to learn the methods of authentication being used and the results of these methods.
Examples The following is sample output from the debug aaa authentication command. A single EXEC login that
uses the default method list and the first method, TACACS+, is displayed. The TACACS+ server sends
a GETUSER request to prompt for the username and then a GETPASS request to prompt for the
password, and finally a PASS response to indicate a successful login. The number 50996740 is the
session ID, which is unique for each authentication. Use this ID number to distinguish between different
authentications if several are occurring concurrently.
Router# debug aaa authentication
6:50:12: AAA/AUTHEN: create_user user='' ruser='' port='tty19' rem_addr='172.31.60.15'

authen_type=1 service=1 priv=1
6:50:12: AAA/AUTHEN/START (0): port='tty19' list='' action=LOGIN service=LOGIN
6:50:12: AAA/AUTHEN/START (0): using default list
6:50:12: AAA/AUTHEN/START (50996740): Method=TACACS+
6:50:12: TAC+ (50996740): received authen response status = GETUSER
6:50:12: AAA/AUTHEN (50996740): status = GETUSER
6:50:15: AAA/AUTHEN/CONT (50996740): continue_login
6:50:15: AAA/AUTHEN (50996740): status = GETUSER
6:50:15: AAA/AUTHEN (50996740): Method=TACACS+
6:50:15: TAC+: send AUTHEN/CONT packet
6:50:15: TAC+ (50996740): received authen response status = GETPASS
6:50:15: AAA/AUTHEN (50996740): status = GETPASS
6:50:20: AAA/AUTHEN/CONT (50996740): continue_login
6:50:20: AAA/AUTHEN (50996740): status = GETPASS
6:50:20: AAA/AUTHEN (50996740): Method=TACACS+
6:50:20: TAC+: send AUTHEN/CONT packet
6:50:20: TAC+ (50996740): received authen response status = PASS
6:50:20: AAA/AUTHEN (50996740): status = PASS

May 2008 DB-17
Debug Commands
debug aaa authorization

To display information on authentication, authorization, and accounting (AAA) TACACS+
authorization, use the debug aaa authorization command in privileged EXEC mode. To disable
no debug aaa authorization
Usage Guidelines Use this command to learn the methods of authorization being used and the results of these methods.
Examples The following is sample output from the debug aaa authorization command. In this display, an EXEC
authorization for user carrel is performed. On the first line, the username is authorized. On the second
and third lines, the attribute value (AV) pairs are authorized. The debug output displays a line for each
AV pair that is authenticated. Next, the display indicates the authorization method used. The final line
in the display indicates the status of the authorization process, which, in this case, has failed.
Router# debug aaa authorization
2:23:21: AAA/AUTHOR (0): user='carrel'

2:23:21: AAA/AUTHOR (0): send AV service=shell
2:23:21: AAA/AUTHOR (0): send AV cmd*
2:23:21: AAA/AUTHOR (342885561): Method=TACACS+
2:23:21: AAA/AUTHOR/TAC+ (342885561): user=carrel
2:23:21: AAA/AUTHOR/TAC+ (342885561): send AV service=shell
2:23:21: AAA/AUTHOR/TAC+ (342885561): send AV cmd*
2:23:21: AAA/AUTHOR (342885561): Post authorization status = FAIL
The aaa authorization command causes a request packet containing a series of AV pairs to be sent to
the TACACS+ daemon as part of the authorization process. The daemon responds in one of the following
three ways:
Accepts the request as is
Makes changes to the request
Refuses the request, thereby refusing authorization
Table 2 describes AV pairs associated with the debug aaa authorization command that may appear in
the debug output.

DB-18 May 2008
Debug Commands
Table 2 Attribute Value Pairs for Authorization
Attribute Value Description

service=arap Authorization for the AppleTalk remote access (ARA) protocol is being
requested.
service=shell Authorization for EXEC startup and command authorization is being
requested.
service=ppp Authorization for PPP is being requested.
service=slip Authorization for SLIP is being requested.
protocol=lcp Authorization for LCP is being requested (lower layer of PPP).
protocol=ip Used with service=slip to indicate which protocol layer is being authorized.
protocol=ipx Used with service=ppp to indicate which protocol layer is being authorized.
protocol=atalk Used with service=ppp or service=arap to indicate which protocol layer is
being authorized.
protocol=vines Used with service=ppp for VINES over PPP.
protocol=unknown Used for undefined or unsupported conditions.
cmd=x Used with service=shell, if cmd=NULL, this is an authorization request to
start an EXEC. If cmd is not NULL, this is a command authorization request
and will contain the name of the command being authorized. For example,
cmd=telnet.
cmd-arg=x Used with service=shell. When performing command authorization, the
name of the command is given by a cmd=x pair for each argument listed. For
example, cmd-arg=archie.sura.net.
acl=x Used with service=shell and service=arap. For ARA, this pair contains an
access list number. For service=shell, this pair contains an access class
number. For example, acl=2.
inacl=x Used with service=ppp and protocol=ip. Contains an IP input access list for
SLIP or PPP/IP. For example, inacl=2.
outacl=x Used with service=ppp and protocol=ip. Contains an IP output access list for
SLIP or PPP/IP. For example, outacl=4.
addr=x Used with service=slip, service=ppp, and protocol=ip. Contains the IP
address that the remote host should use when connecting via SLIP or PPP/IP.
For example, addr=172.30.23.11.
routing=x Used with service=slip, service=ppp, and protocol=ip. Equivalent in
function to the /routing flag in SLIP and PPP commands. Can either be true
or false. For example, routing=true.
timeout=x Used with service=arap. The number of minutes before an ARA session
disconnects. For example, timeout=60.
autocmd=x Used with service=shell and cmd=NULL. Specifies an autocommand to be
executed at EXEC startup. For example, autocmd=telnet yxz.com.
noescape=x Used with service=shell and cmd=NULL. Specifies a noescape option to the
username configuration command. Can be either true or false. For example,
noescape=true.

May 2008 DB-19
Debug Commands
Table 2 Attribute Value Pairs for Authorization (continued)
Attribute Value Description

nohangup=x Used with service=shell and cmd=NULL. Specifies a nohangup option to the
username configuration command. Can be either true or false. For example,
nohangup=false.
priv-lvl=x Used with service=shell and cmd=NULL. Specifies the current privilege
level for command authorization as a number from 0 to 15. For example,
priv-lvl=15.
zonelist=x Used with service=arap. Specifies an AppleTalk zonelist for ARA. For
example, zonelist=5.
addr-pool=x Used with service=ppp and protocol=ip. Specifies the name of a local pool
from which to get the address of the remote host.

DB-20 May 2008
Debug Commands
debug aaa cache filterserver

To help troubleshoot your filter cache configurations, use the debug aaa cache filterserver command
in privileged EXEC mode. To disable debugging output, use the no form of this command.
no debug aaa cache filterserver
Command History Release Modification

12.2(13)T This command was introduced.
12.2(28)SB This command was integrated into Cisco IOS Release 12.2(28)SB
12.2SX This command is supported in the Cisco IOS Release 12.2SX train. Support
in a specific 12.2SX release of this train depends on your feature set,
platform, and platform hardware.
12.2(33)SRC This command was integrated into Cisco IOS Release 12.2(33)SRC.
Examples The following is sample output from the debug aaa cache filterserver command:
Router# debug aaa cache filterserver
AAA/FLTSV: need "myfilter" (fetch), call 0x612DAC64

AAA/FLTSV: send req, call 0x612DAC50
AAA/FLTSV: method SERVER_GROUP myradius
AAA/FLTSV: recv reply, call 0x612DAC50 (PASS)
AAA/FLTSV: create cache
AAA/FLTSV: add attr "call-inacl"
AAA/FLTSV: skip attr "filter-cache-refresh"
AAA/FLTSV: skip attr "filter-cache-time"
AAA/CACHE: set "AAA filtserv cache" entry "myfilter" refresh? no
AAA/CACHE: set "AAA filtserv cache" entry "myfilter" cachetime 15
AAA/FLTSV: add attr to list "call-inacl" call 0x612DAC64
AAA/FLTSV: PASS call 0x612DAC64
AAA/CACHE: timer "AAA filtserv cache", next in 10 secs (0 entries)
AAA/CACHE: timer "AAA filtserv cache", next in 10 secs (1 entry)
AAA/CACHE: destroy "AAA filtserv cache" entry "myfilter"
AAA/CACHE: timer "AAA filtserv cache", next in 10 secs (0 entries)

May 2008 DB-21
Debug Commands

aaa authorization cache filterserver Enables AAA authorization caches and the downloading of
ACL configurations from a RADIUS filter server.

DB-22 May 2008
Debug Commands
debug aaa cache group

To debug the caching mechanism and ensure that entries are being cached from AAA Server Responses
and are being found when queried, use the debug aaa cache group command in privileged EXEC mode.
Command Default Debug information for all cached entries is displayed.

12.2(28)SB This command was introduced.
Usage Guidelines Use this command to display debug information about cached entries.
Examples The following example shows how to display debug information about all cached entries:
Router# debug aaa cache group

clear aaa cache group Clears an individual entry or all entries in the cache.
show aaa cache group Displays cache entries stored by the AAA Auth Cache.

May 2008 DB-23
Debug Commands
debug aaa dead-criteria transactions

To display authentication, authorization, and accounting (AAA) dead-criteria transaction values, use the
debug aaa dead-criteria transactions command in privileged EXEC mode. To disable dead-criteria
debugging, use the no form of this command.
no debug aaa dead-criteria transactions
Defaults If the command is not configured, debugging is not turned on.

12.3(6) This command was introduced.
12.3(7)T This command was integrated into Cisco IOS Release 12.3(7)T. The
command output includes two new fields: Current Tries and Elapsed Time.
Usage Guidelines Dead-criteria transaction values may change with every AAA transaction. Some of the values that can
be displayed are estimated outstanding transactions, retransmit tries, and dead-detect intervals. These
values are explained in Table 3.
Examples The following example shows dead-criteria transaction information for a particular server group:
Router# debug aaa dead-criteria transactions
AAA Transaction debugs debugging is on
*Nov 14 23:44:17.403: AAA/SG/TRANSAC: Computed Retransmit Tries: 10, Current Tries: 3,

Current Max Tries: 10
*Nov 14 23:44:17.403: AAA/SG/TRANSAC: Computed Dead Detect Interval: 10s, Elapsed Time:
317s, Current Max Interval: 10s
*Nov 14 23:44:17.403: AAA/SG/TRANSAC: Estimated Outstanding Transactions: 6, Current Max
Transactions: 6

DB-24 May 2008
Debug Commands
Table 3 describes the significant fields shown in the display.
Table 3 debug aaa dead-criteria transactions Field Descriptions
Field Description
AAA/SG/TRANSAC AAA server-group transactions.
Computed Retransmit Tries Currently computed number of retransmissions before the
server is marked as dead.
Current Tries Number of successive failures since the last valid response.
Current Max Tries Maximum number of tries since the last successful
transaction.
Computed Dead Detect Interval Period of inactivity (the number of seconds since the last
successful transaction) that can elapse before the server is
marked as dead. The period of inactivity starts when a
transaction is sent to a server that is considered live. The
dead-detect interval is the period that the router waits for
responses from the server before the router marks the server
as dead.
Elapsed Time Amount of time that has elapsed since the last valid response.
Current Max Interval Maximum period of inactivity since the last successful
transaction.
Estimated Outstanding Transactions Estimated number of transactions that are associated with the
server.
Current Max Transactions Maximum transactions since the last successful transaction.

radius-server dead-criteria Forces one or both of the criteriaused to mark a RADIUS
server as deadto be the indicated constant.
show aaa dead-criteria Displays dead-criteria detection information for an AAA
server.

May 2008 DB-25
Debug Commands
debug aaa per-user
debug aaa per-user

To display debugging information about PPP session per-user activities, use the debug aaa per-user
command in privileged EXEC mode. To turn off debugging, use the no form of this command.
debug aaa per-user
no debug aaa per-user

11.3 T This command has existed since Cisco IOS Release 11.3 T.
12.2(33)SRA This command was integrated into Cisco IOS Release 12.2(33)SRA.
Usage Guidelines The per-user module is responsible for installing per-user attributes for PPP sessions.
Examples The following example displays the configuration commands that were generated by the per-user
process:
Router# debug aaa per-user
AAA/PER-USER: line=[ip access-list standard Virtual-Access2#31]

AAA/PER-USER: line=[deny 10.0.0.2 0.0.0.0]
AAA/PER-USER: line=[permit any]
The fields in the display are self-explanatory.

debug aaa authorization Displays information on AAA TACACS+ authorization.
debug ppp Displays information on traffic and exchanges in an
internetwork implementing the PPP.
debug radius Displays information associated with RADIUS.
debug tacacs Displays information associated with TACACS.

DB-26 May 2008
Debug Commands
debug aaa pod
debug aaa pod

To display debug messages related to packet of disconnect (POD) packets, use the debug aaa pod
command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug aaa pod
no debug aaa pod
Syntax Description This command has no keywords or arguments.
Defaults Debugging for POD packets is not enabled.
Command Modes Privileged EXEC

12.2(2)XB Support for the voice applications as well as support for the
Cisco AS5350, Cisco AS5400 and the Cisco 3600 series was added.
12.2(2)XB1 Support for the Cisco AS5800 was added.
12.2(11)T Support for the Cisco AS5850 was added. This command was
integrated into Cisco IOS Release 12.2(11)T.
12.2SX This command is supported in the Cisco IOS Release 12.2SX train.
Support in a specific 12.2SX release of this train depends on your
feature set, platform, and platform hardware.
Examples The following example shows output from a successful POD request when using the show debug
command:
Router# debug aaa pod
AAA POD packet processing debugging is on
Router# show debug
General OS:
AAA POD packet processing debugging is on
Router#
Apr 25 17:15:59.318:POD:172.19.139.206 request queued
Apr 25 17:15:59.318:voice_pod_request:
Apr 25 17:15:59.318:voip_populate_pod_attr_list:
Apr 25 17:15:59.318:voip_pod_get_guid:
Apr 25 17:15:59.318:voip_pod_get_vsa_attr_val:
Apr 25 17:15:59.318:voip_pod_get_vsa_attr_val:attr_len=50
Apr 25 17:15:59.318:voip_pod_get_vsa_attr_val:attr=h323-conf-id
Apr 25 17:15:59.318:voip_pod_get_vsa_attr_val:attr_len=50 value_len=35

May 2008 DB-27
Debug Commands
debug aaa pod
Apr 25 17:15:59.318:voip_pod_get_guid:conf-id=FFA7785F F7F607BB

00000000 993FB1F4 n_bytes=35
Apr 25 17:15:59.318:voip_pod_get_guid:GUID = FFA7785F F7F607BB 00000000
993FB1F4
Apr 25 17:15:59.318:voip_populate_pod_attr_list:
Apr 25 17:15:59.318:voip_pod_get_vsa_attr_val:
Apr 25 17:15:59.318:voip_pod_get_vsa_attr_val:attr_len=23
Apr 25 17:15:59.318:voip_pod_get_vsa_attr_val:attr=h323-originate
Apr 25 17:15:59.318:voip_pod_get_vsa_attr_val:attr_len=23 value_len=6
Apr 25 17:15:59.318:voip_get_call_direction:
Apr 25 17:15:59.318:voip_get_call_direction:returning answer
Apr 25 17:15:59.318:voip_eval_pod_attr:
Apr 25 17:15:59.318:cc_api_trigger_disconnect:
Apr 25 17:15:59.322:POD:Sending ACK to 172.19.139.206/1700
Apr 25 17:15:59.322:voip_pod_clean:

aaa pod server Enables the POD feature.

DB-28 May 2008
Debug Commands
debug aaa redundancy

To view debug output that displays authentication, authorization, and accounting (AAA) redundancy
events during session activation, session synchronization to the standby device, and dynamic session
updates to the standby device, use the debug aaa redundancy command in privileged EXEC mode. To
disable debugging for AAA redundancy, use the no form of this command.
no debug aaa redundancy

12.2(31)SB2 This command was introduced.
Usage Guidelines This command displays the AAA synchronization data for the session synchronization to the standby
device. This information might be useful for diagnosing any AAA issues related to the session
synchronization.
Examples The following example shows sample output of the debug aaa redundancy command collected while
activating a session and synchronizing the session to the standby device:
Router# debug aaa redundancy
Logs on Active
==============
01:31:55: CCM: New State[Not Ready]

01:31:55: CCM: PPPoE Required
01:31:55: CCM: PPP Required
01:31:55: CCM: LTERM Required
01:31:55: CCM: PPPoE is Initiator
01:31:55: AAA/BIND(0000000B): Bind i/f Virtual-Template1
01:31:55: CCM: AAA Ready
01:31:55: AAA/CCM/(0000000B): AAA sso init completed successfully
01:31:55: SSS INFO: Element type is Access-Type = 3 (PPPoE)
01:31:55: SSS INFO: Element type is Protocol-Type = 0 (PPP)
01:31:55: SSS INFO: Element type is Media-Type = 1 (Ethernet)
01:31:55: SSS INFO: Element type is Switch-Id = 4105 (00001009)
01:31:55: SSS INFO: Element type is Segment-Hdl = 4114 (00001012)
01:31:55: SSS INFO: Element type is AAA-Id = 11 (0000000B)

May 2008 DB-29
Debug Commands
01:31:55: SSS INFO: Element type is AccIe-Hdl = 33554441 (02000009)

01:31:55: SSS INFO: Element type is SHDB-Handle = 1476395017 (58000009)
01:31:55: SSS INFO: Element type is Input Interface = "GigabitEthernet6/0/0"
01:31:55: SSS MGR [uid:10]: Sending a Session Assert ID Mgr event
01:31:55: SSS MGR [uid:10]: Updating ID Mgr with the following keys:
aaa-unique-id 11 (0xB)
01:31:55: SSS MGR [uid:10]: Handling Policy Service Authorize action (1 pending sessions)
01:31:55: SSS PM [uid:10][63D5D594]: RM/VPDN disabled: RM/VPDN author not needed
01:31:55: SSS PM [uid:10][63D5D594]: AAA author needed for registered user
01:31:55: SSS MGR [uid:10]: Got reply Need More Keys from PM
01:31:55: SSS MGR [uid:10]: Handling Need More Keys action
01:31:57: SSS INFO: Element type is Unauth-User = "user1"
01:31:57: SSS INFO: Element type is AccIe-Hdl = 33554441 (02000009)
01:31:57: SSS INFO: Element type is Access-Type = 0 (PPP)
01:31:57: SSS MGR [uid:10]: Sending a Session Update ID Mgr event
username "user1"
01:31:57: SSS MGR [uid:10]: Handling Policy Send More Keys action
01:31:57: SSS PM [uid:10][63D5D594]: AAA author needed for registered user
01:31:57: SSS PM [uid:10][63D5D594]: SGBP disabled: SGF author not needed
01:31:57: SSS MGR [uid:10]: Got reply Local Terminate from PM
01:31:57: SSS MGR [uid:10]: Handling Connect Local Service action
01:31:57: SSS MGR [uid:10]: Need the resource type determined key
01:31:57: SSS MGR [uid:10]: Not yet ready to start the Local service
01:31:57: AAA/AUTHEN/PPP (0000000B): Pick method list 'default'
01:31:57: RADIUS/ENCODE(0000000B):Orig. component type = PPoE
01:31:57: RADIUS: AAA Unsupported Attr: client-mac-address[42] 14
01:31:57: RADIUS: 30 30 30 61 2E 34 32 37 64 2E 65 63 [ 000a.427d.ec]
01:31:57: RADIUS: AAA Unsupported Attr: interface [171] 7
01:31:57: RADIUS: 36 2F 30 2F 30 [ 6/0/0]
01:31:57: RADIUS(0000000B): Config NAS IP: 0.0.0.0
01:31:57: RADIUS/ENCODE(0000000B): acct_session_id: 11
01:31:57: RADIUS(0000000B): sending
01:31:57: RADIUS/ENCODE: Best Local IP-Address 9.2.76.2 for Radius-Server 9.2.36.253
01:31:57: RADIUS(0000000B): Send Access-Request to 9.2.36.253:1645 id 1645/10, len 86
01:31:57: RADIUS: authenticator FD E8 32 9A 71 15 50 44 - BE FF 19 D0 09 D4 8D 15
01:31:57: RADIUS: Framed-Protocol [7] 6 PPP [1]
01:31:57: RADIUS: User-Name [1] 9 "user1"
01:31:57: RADIUS: User-Password [2] 18 *
01:31:57: RADIUS: NAS-Port-Type [61] 6 Virtual [5]
01:31:57: RADIUS: NAS-Port [5] 6 0
01:31:57: RADIUS: NAS-Port-Id [87] 9 "6/0/0/0"
01:31:57: RADIUS: Service-Type [6] 6 Framed [2]
01:31:57: RADIUS: NAS-IP-Address [4] 6 9.2.76.2
01:31:57: RADIUS: Received from id 1645/10 9.2.36.253:1645, Access-Accept, len 32
01:31:57: RADIUS: authenticator E4 68 43 2C 2F E7 B4 57 - 05 70 FF B1 22 13 E8 0F
01:31:57: RADIUS: Idle-Timeout [28] 6 200
01:31:57: RADIUS(0000000B): Received from id 1645/10
01:31:57: SSS INFO: Element type is Auth-User = "user1"
01:31:57: SSS INFO: Element type is AAA-Attr-List = C5000100
01:31:57: SSS INFO: Element type is idletime 200 (0xC8)
01:31:57: SSS INFO: Element type is service-type 2 [Framed]
01:31:57: SSS INFO: Element type is Resource-Determined = 1 (YES)
01:31:57: SSS INFO: Element type is Final = 1 (YES)
01:31:57: SSS MGR [uid:10]: Rcvd an AAA attr list from SIP, pushing it to the PM
01:31:57: SSS MGR [uid:10]: Handling Send Policy Push Cng action

DB-30 May 2008
Debug Commands
01:31:57: SSS AAA AUTHOR [uid:10]: Root SIP PPPoE

01:31:57: SSS AAA AUTHOR [uid:10]: Enable PPPoE parsing
01:31:57: SSS AAA AUTHOR [uid:10]: Enable PPP parsing
01:31:57: SSS AAA AUTHOR [uid:10]: Active key set to Unauth-User
01:31:57: SSS AAA AUTHOR [uid:10]: Authorizing key user1
01:31:57: SSS AAA AUTHOR [uid:10]: Spoofed AAA reply sent for key user1
01:31:57: SSS AAA AUTHOR [uid:10]: Received an AAA pass
01:31:57: SSS AAA AUTHOR [uid:10]: SIP PPP[60A0504C] parsed as Success
01:31:57: SSS AAA AUTHOR [uid:10]: SIP PPP[61571560] parsed as Ignore
01:31:57: SSS AAA AUTHOR [uid:10]: SIP PPPoE[61599FB0] parsed as Success
01:31:57: SSS AAA AUTHOR [uid:10]: SIP Root parser not installed
01:31:57: SSS AAA AUTHOR [uid:10]: No service authorization info found
01:31:57: SSS AAA AUTHOR [uid:10]: Active Handle present
01:31:57: SSS AAA AUTHOR [uid:10]: Freeing Active Handle; SSS Policy Context Handle =
63D5D594
01:31:57: SSS AAA AUTHOR [uid:10]: Free request
01:31:57: SSS MGR [uid:10]: Got reply Apply Config from PM
01:31:57: SSS MGR [uid:10]: Successfully applied policy config
01:31:57: SSS LTERM [uid:10]: Processing Local termination request
01:31:57: SSS LTERM [uid:10]: Sent create-clone request to vtemplate manager
01:31:57: SSS LTERM [uid:10]: Created vaccess interface Vi3
01:31:57: CCM: LTERM Ready
01:31:57: SSS LTERM [uid:10]: Segment provision successful
01:31:57: SSS MGR [uid:10]: Handling Local Service Connected action
01:31:57: SSS MGR [uid:10]: Apply for Vi3: segment 4114, owner 3825205277
01:31:57: SSS MGR [uid:10]: Interface config 212C27B8
01:31:57: SSS MGR [uid:10]: Per-user config 2146BD48
01:31:57: SSS LTERM [uid:10]: Switching session provisioned
01:31:57: SSS MGR [uid:10]: Handling Local Service Connected, Features Applied action
01:31:57: %LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up
01:31:57: SSS LTERM [uid:10]: Installed Vi3 process path switching vector
01:31:57: SSS LTERM [uid:10]: Installed Vi3 fastsend path switching vector
01:31:57: AAA/BIND(0000000B): Bind i/f Virtual-Access3
01:31:57: CCM: PPPoE Ready
01:31:57: CCM: PPP Ready
01:31:57: CCM: PPP Old State[Not Ready] Event[All Ready]
01:31:57: CCM: New State[Ready]
01:31:57: AAA/CCM/(0000000B): No of sync avps = 4 Total sync data len = 94
01:31:57: CCM: PPP Adding Data Type[6] Subtype[0] Length[14]
01:31:57: CCM: PPPoE Adding Data Type[1] Subtype[0] Length[54]
01:31:57: CCM: AAA Adding Data Type[1] Subtype[0] Length[4]
01:31:57: AAA/CCM/(0000000B): Adding sync avp [AAA Unique Id] Length = 4
01:31:57: AAA/CCM/(0000000B): Adding sync avp [AAA Authen Method Index] Length = 2
01:31:57: AAA/CCM/(0000000B): Adding sync avp [AAA Acct Sess id] Length = 4
01:31:57: AAA/CCM/(0000000B): Adding sync avp [AAA Author Data] Length = 84
01:31:57: AAA/CCM: Adding author data entry 32
01:31:57: CCM: LTERM Adding Data Type[1] Subtype[0] Length[4]
01:31:57: SSS LTERM [uid:10]: LTERM segment handle synced

May 2008 DB-31
Debug Commands
01:31:57: CCM: Send[Sync Session] Length[240] NumItems[17] Event[0x0]

01:31:57: Client[PPP] Type[6] Subtype[0] Length[14]
01:31:57: 01 04 05 D4 03 04 C0 23 05 06 03 F4 37 79
01:31:57: 01 04 05 D4 05 06 9A 6B 68 FE
01:31:57: 03 06 07 01 01 01
01:31:57:
01:31:57: 73 75 6D 61 6E 74 68 00
01:31:57: 00 00 00 02
01:31:57: Client[PPPoE] Type[1] Subtype[0] Length[54]
01:31:57: 00 03 A0 10 22 90 00 0A 42 7D EC 38 88 63 11 19
01:31:57: 00 00 00 22 01 02 00 06 61 61 61 5F 68 61 01 04
01:31:57: 00 10 98 99 BB 6D 59 B8 35 33 0B FB 14 B9 07 EB
01:31:57: 83 B4 01 01 00 00
01:31:57: 00 0A
01:31:57: 00 00 10 09
01:31:57: 00 00 10 12
01:31:57: 00 02 06 00 00 00 A6 B8 00 00 00 00 00 00 00 2A
01:31:57: 00 00 FF FF
01:31:57: 00 00 00 03 00 00 00 00 00 00 00 19 00 00 00 1D
01:31:57:
01:31:57: Client[AAA] Type[1] Subtype[0] Length[4]
01:31:57: 00 00 00 0B
01:31:57: 00 00
01:31:57: 00 00 00 0B
01:31:57: 00 00 00 00 00 00 00 00 63 E8 73 D0 00 00 00 0B
01:31:57: 64 02 FE 71 00 00 00 00 00 00 00 00 00 00 00 00
01:31:57: 00 00 00 04 00 00 00 01 00 00 00 20 00 00 00 00
01:31:57: 58 00 00 09 02 0A 00 20 E4 68 43 2C 2F E7 B4 57
01:31:57: 05 70 FF B1 22 13 E8 0F 1C 06 00 00 00 C8 06 06
01:31:57: 00 00 00 02
01:31:57: Client[LTERM] Type[1] Subtype[0] Length[4]
01:31:57: 00 00 20 13
01:31:57: CCM: New State[Dyn Sync]
01:31:58: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state
to up
Logs on Standby
================
01:21:16: CCM ISSU: Received negotiation message type [ISSU_RC_USER_MESSAGE_COMP]

01:21:16: CCM: Receive[Sync Session] Length[240] NumItems[17] Flags[0x0]
01:21:16: CCM: New State[Not Ready]
01:21:16: 01 04 05 D4 03 04 C0 23 05 06 03 F4 37 79
01:21:16: 01 04 05 D4 05 06 9A 6B 68 FE
01:21:16: 03 06 07 01 01 01
01:21:16:

DB-32 May 2008
Debug Commands
01:21:16: 73 75 6D 61 6E 74 68 00
01:21:16: 00 00 00 02
01:21:16: 00 03 A0 10 22 90 00 0A 42 7D EC 38 88 63 11 19
01:21:16: 00 00 00 22 01 02 00 06 61 61 61 5F 68 61 01 04
01:21:16: 00 10 98 99 BB 6D 59 B8 35 33 0B FB 14 B9 07 EB
01:21:16: 83 B4 01 01 00 00
01:21:16: 00 0A
01:21:16: 00 00 10 09
01:21:16: 00 00 10 12
01:21:16: 00 02 06 00 00 00 A6 B8 00 00 00 00 00 00 00 2A
01:21:16: 00 00 FF FF
01:21:16: 00 00 00 03 00 00 00 00 00 00 00 19 00 00 00 1D
01:21:16:
01:21:16: 00 00 00 0B
01:21:16: 00 00
01:21:16: 00 00 00 0B
01:21:16: 00 00 00 00 00 00 00 00 63 E8 73 D0 00 00 00 0B
01:21:16: 64 02 FE 71 00 00 00 00 00 00 00 00 00 00 00 00
01:21:16: 00 00 00 04 00 00 00 01 00 00 00 20 00 00 00 00
01:21:16: 58 00 00 09 02 0A 00 20 E4 68 43 2C 2F E7 B4 57
01:21:16: 05 70 FF B1 22 13 E8 0F 1C 06 00 00 00 C8 06 06
01:21:16: 00 00 00 02
01:21:16: Client[LTERM] Type[1] Subtype[0] Length[4]
01:21:16: 00 00 20 13
01:21:16: CCM:PPPoE Recreate Session Active[0x58000009] Standby[0x98000009]
01:21:16: CCM: PPPoE Required
01:21:16: CCM: PPP Required
01:21:16: CCM: PPPoE is Initiator
01:21:16: AAA/CCM/: return checkpointed aaa id = 0000000B
01:21:16: Adding cache entry for id B
01:21:16: Author cache len 84 84 84
01:21:16: AAA/CCM/(0000000B):return acct_sess_id = 11
01:21:16: CCM: AAA Ready
01:21:16: AAA/CCM/(0000000B): AAA sso init completed successfully
01:21:16: SSS INFO: Element type is Access-Type = 3 (PPPoE)
01:21:16: SSS INFO: Element type is Media-Type = 1 (Ethernet)
01:21:16: SSS INFO: Element type is Switch-Id = 4105 (00001009)
01:21:16: SSS INFO: Element type is Segment-Hdl = 4114 (00001012)
01:21:16: SSS INFO: Element type is AccIe-Hdl = 4127195145 (F6000009)
01:21:16: SSS INFO: Element type is SHDB-Handle = 2550136841 (98000009)
01:21:16: SSS INFO: Element type is Input Interface = "GigabitEthernet6/0/0"
01:21:16: SSS MGR [uid:10]: Sending a Session Assert ID Mgr event
01:21:16: SSS MGR [uid:10]: Handling Policy Service Authorize action (1 pending sessions)
01:21:16: SSS PM [uid:10][63D6963C]: RM/VPDN disabled: RM/VPDN author not needed
01:21:16: SSS MGR [uid:10]: Got reply Need More Keys from PM
01:21:16: SSS INFO: Element type is Unauth-User = "user1"
01:21:16: SSS INFO: Element type is AccIe-Hdl = 4127195145 (F6000009)

May 2008 DB-33
Debug Commands

01:21:16: SSS MGR [uid:10]: Sending a Session Update ID Mgr event
username "user1"
01:21:16: SSS MGR [uid:10]: Handling Policy Send More Keys action
01:21:16: SSS PM [uid:10][63D6963C]: SGBP disabled: SGF author not needed
01:21:16: SSS MGR [uid:10]: Got reply Local Terminate from PM
01:21:16: SSS MGR [uid:10]: Need the resource type determined key
01:21:16: AAA/CCM/(0000000B):return authen_method_index = 0
01:21:16: RADIUS/ENCODE(0000000B):Orig. component type = PPoE
01:21:16: RADIUS: AAA Unsupported Attr: client-mac-address[42] 14
01:21:16: RADIUS: 30 30 30 61 2E 34 32 37 64 2E 65 63 [ 000a.427d.ec]
01:21:16: RADIUS: AAA Unsupported Attr: interface [171] 7
01:21:16: RADIUS: 36 2F 30 2F 30 [ 6/0/0]
01:21:16: RADIUS(0000000B): Config NAS IP: 0.0.0.0
01:21:16: RADIUS/ENCODE(0000000B): acct_session_id: 11
01:21:16: RADIUS(0000000B): sending
01:21:16: RADIUS(0000000B): Send Access-Request to 9.2.36.253:1645 id 1645/10, len 86
01:21:16: RADIUS: authenticator 14 48 25 90 A5 7B 53 02 - 11 05 01 13 6D 34 E2 04
01:21:16: RADIUS: Framed-Protocol [7] 6 PPP [1]
01:21:16: RADIUS: User-Name [1] 9 "user1"
01:21:16: RADIUS: NAS-Port [5] 6 0
01:21:16: RADIUS: NAS-Port-Id [87] 9 "6/0/0/0"
01:21:16: RADIUS: Cached response
01:21:16: RADIUS: authenticator E4 68 43 2C 2F E7 B4 57 - 05 70 FF B1 22 13 E8 0F
01:21:16: RADIUS: Idle-Timeout [28] 6 200
01:21:16: RADIUS(0000000B): Received from id 1645/10
01:21:16: SSS INFO: Element type is Auth-User = "user1"
01:21:16: SSS INFO: Element type is AAA-Attr-List = 20000100
01:21:16: SSS INFO: Element type is idletime 200 (0xC8)
01:21:16: SSS INFO: Element type is service-type 2 [Framed]
01:21:16: SSS INFO: Element type is Resource-Determined = 1 (YES)
01:21:16: SSS INFO: Element type is Final = 1 (YES)
01:21:16: SSS MGR [uid:10]: Rcvd an AAA attr list from SIP, pushing it to the PM
01:21:16: SSS MGR [uid:10]: Handling Send Policy Push Cng action
01:21:16: SSS MGR [uid:10]: Got reply Apply Config from PM
01:21:16: SSS MGR [uid:10]: Successfully applied policy config
01:21:16: SSS LTERM [uid:10]: Processing Local termination request
01:21:16: SSS LTERM [uid:10]: Sent create-clone request to vtemplate manager
01:21:16: SSS LTERM [uid:10]: Created vaccess interface Vi3
01:21:16: CCM: LTERM Ready
01:21:16: SSS LTERM [uid:10]: Segment provision successful
01:21:16: SSS MGR [uid:10]: Handling Local Service Connected action
01:21:16: SSS MGR [uid:10]: Apply for Vi3: segment 4114, owner 2566914077
01:21:16: SSS MGR [uid:10]: Interface config 218170B8
01:21:16: SSS MGR [uid:10]: Per-user config 63E06550

DB-34 May 2008
Debug Commands
01:21:16: SSS LTERM [uid:10]: Switching session provisioned

01:21:16: SSS MGR [uid:10]: Handling Local Service Connected, Features Applied action
01:21:16: SSS LTERM [uid:10]: Installed Vi3 process path switching vector
01:21:16: SSS LTERM [uid:10]: Installed Vi3 fastsend path switching vector
01:21:16: CCM: PPPoE Ready
01:21:16: CCM: PPP Ready
01:21:16: CCM: PPP Old State[Not Ready] Event[All Ready]
01:21:16: CCM: New State[Ready]
Table 4 debug aaa redundancy Field Descriptions
Field Description
(0000000B) AAA unique id for the session.
Adding sync avp Adding synchronization attribute value pair (AVP).
[AAA Unique Id] The AAA synchronization data type.

debug ccm-manager Displays debugging information about Cisco CallManager.

May 2008 DB-35
Debug Commands
debug aaa sg-server selection

To obtain information about why the RADIUS and TACACS+ server group system in a router is choosing
a particular server, use the debug aaa sg-server selection command in privileged EXEC mode. To
disable debugging output, use the no form of this command.
no debug aaa sg-server selection

12.2(28)SB This command was extended for RADIUS server load balancing to show
which server is selected on the basis of a load balancing algorithm.
12.4(11)T This command was integrated into Cisco IOS Release 12.4(11)T.
Examples The following example shows that debugging has been set to display information about server selection:
Router# debug aaa sg-server selection
The following two debug outputs display the behavior of RADIUS transactions within a server group
with the server-reorder-on-failure feature configured.
Debug 1
In the following sample output, the RADIUS server-reorder-on-failure feature is configured. The server
retransmits are set to 0 (so each server is attempted only once before failover to the next configured
server), and the transmissions per transaction are set to 4 (the transmissions will stop on the third
failover). The third server in the server group (192.0.2.118) has accepted the transaction on the third
transmission (second failover).
00:38:35: %SYS-5-CONFIG-I: Configured from console by console
00:38:53: RADIUS/ENCODE(OOOOOOOF) : ask "Username: "
00:38:53: RADIUS/ENCODE (0000000F) : send packet; GET-USER
00:38:58: RADIUS/ENCODE (0000000F) : ask "Password: "
00:38:58: RADIUS/ENCODE(0000000F) : send packet; GET-PASSWORD
00:38:59: RADIUS: AAA Unsupported [152] 4
00:38:59: RADIUS: 7474 [tt]
00:38:59: RADIUS (0000000F) : Storing nasport 2 in rad-db
00:38:59: RADIUS/ENCODE(0000000F) : dropping service type, "radius-server
attribute 6 on-for-login-auth" is off

DB-36 May 2008
Debug Commands
00:38:59: RADIUS (0000000F) : Config NAS IP: 192.0.2.4

00:38:59: RADIUS/ENCODE (0000000F) : acct-session-id: 15
00:38:59: RADIUS (0000000F) : sending
00:38:59: RAPIUS(0000000F) : Send Access-Request to 192.0.2.1:1645 id 21645/11, len 78
00:38:59: RADIUS:: authenticator 4481 E6 65 2D 5F 6F OA -lE F5 81 8F 4E 1478 9C
00:38:59: RADIUS: User-Name [1] 7 "username"
00:38:59: RADIUS: NAS-Port fSl 6 2
00:~8:59: RADIUS: NAS-Port-Type [61] 6 Virtual [5]
00:38:59: RADIUS: Calling-Station-Id [31] 15 "192.0.2.23"
00:39:02: RADIUS: Fail-over to (192.0.2.2:1645,1646) for id 21645/11
00:39:04: RADIUS/ENCODE: Best Local IP-Address 192.0.2.130 for Radius-Server
192.0.2.118
00:39:05: RADIUS: Received from id 21645/11 192.0.2.118:1645, Access-Accept, len 26
00:39:05: RADIUS: authenticator 5609 56 F9 64 4E DF 19- F3 A2 DD 73 EE 3F 9826
00:39:05: RADIUS: Service-Type [6] 6 Login [1]
Debug 2
In the following sample output, the RADIUS server-reorder-on-failure feature is configured. The server
retransmits are set to 0, and the transmissions per transaction are set to 8. In this transaction, the
transmission to server 192.0.2.1 has failed on the eighth transmission.
00:42:30: RADIUS(00000011): Received from id 21645/13
00:43:34: RADIUS/ENCODE(00000012) : ask "Username: "
00:43:34: RADIUS/ENCODE(00000012) : send packet; GET-USER
00:43:39: RADIUS/ENCODE(00000012) : ask "Password: "
00:43:39: RADIUS/ENCODE(00000012) : send packet; GET-PASSWORD
00:43:40: RADIUS: AAA Unsupported [152] 4
00:43:40: RADIUS: 7474 [tt]
00:43:40: RADIUS(00000012) : Storing nasport 2 in rad-db
00:43:40: RADIUS/ENCODE(00000012): dropping service type, "radius-server attribute 6
on-for-login-auth" is off
00:43:40: RADIUS(00000012) : Co~fig NAS IP: 192.0.2.4
00:43:40: RADIUS/ENCODE(00000012) : acct-session-id: 18
00:43:40: RADIUS(00000012) : sending
00:43:40: RADIUS(00000012) : Send Access-Request to 192.0.2.118:1645 id 21645/14, len 78
00:43:40: RADIUS: authenticator B8 OA 51 3A AF A6 0018 -B3 2E 94 5E 07 OB 2A
00:43:40: RADIUS: User-Name [1] 7 "username"
00:43:40: RADIUS: NAS-Port [5] 6 2
00:43:40: RADIUS: Calling-Station-]d [31] 15 "192.0.2.23"
00:43:42: RADIUS: Fail-over to (192.0.2,1:1645,1646) for id 21645/14
00:43:44: RADius: Fail-over to (192.0.2.2:1645,1646) for id 21645/14
00:43:56: RADIUS: No response from (192.0.2.1:1645,1646) for id 21645/14

May 2008 DB-37
Debug Commands
00:43:56:RADIUS/DECODE: parse response no app start; FAIL

00:43:56: RADIUS/DECODE: parse response;FAIL
The field descriptions are self-explanatory.
Debug 3
In the following sample output, the RADIUS server load balancing feature is enabled with a batch size
of 3. The server selection, based on the load balancing algorithm, is shown as five access-requests that
are being sent to the server group.
Router# debug aaa sg-server selection
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: Obtaining least loaded server.

Jul 16 03:15:05: AAA/SG/SERVER_SELECT: [3] transactions remaining in batch. Reusing
server.
server.
server.
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: No more transactions in batch. Obtaining a new
server.
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: Obtaining a new least loaded server.
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: Server[0] load: 3
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: Selected Server[1] with load 0
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: [3] transactions remaining in batch.
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: [2] transactions remaining in batch. Reusing server.
The field descriptions are self-explanatory.

load-balance Enables RADIUS server load balancing for named RADIUS
server groups.
radius-server load-balance Enables RADIUS server load balancing for the global
RADIUS server group.
radius-server retry method reorder Specifies the reordering of RADIUS traffic retries among a
server group.
radius-server transaction max-tries Specifies the maximum number of transmissions per
transaction that may be retried on a RADIUS server.
test aaa group Tests RADIUS load balancing server response manually.

DB-38 May 2008
Debug Commands
debug aaa test
debug aaa test

To show when the idle timer or dead timer has expired, when test packets are being sent, server response
status, and the server state for RADIUS server load balancing, use the debug aaa test command in
debug aaa test
no debug aaa test

Examples In the following sample output, the RADIUS server load balancing feature is enabled. The idle timer has
expired.
Router# debug aaa test
Router#
Jul 16 00:07:01: AAA/SG/TEST: Server (192.0.2.245:1700,1701) quarantined.
Jul 16 00:07:01: AAA/SG/TEST: Sending test request(s) to server (192.0.2.245:1700,1701)
Jul 16 00:07:01: AAA/SG/TEST: Sending 1 Access-Requests, 1 Accounting-Requests in current
batch.
Jul 16 00:07:01: AAA/SG/TEST(Req#: 1): Sending test AAA Access-Request.
Jul 16 00:07:01: AAA/SG/TEST(Req#: 1): Sending test AAA Accounting-Request.
Jul 16 00:07:01: AAA/SG/TEST: Obtained Test response from server (192.0.2.245:1700,1701)
Jul 16 00:07:01: AAA/SG/TEST: Obtained Test response from server (192.0.2.245:1700,1701)
Jul 16 00:07:01: AAA/SG/TEST: Necessary responses received from server
(192.0.2.245:1700,1701)
Jul 16 00:07:01: AAA/SG/TEST: Server (192.0.2.245:1700,1701) marked ALIVE. Idle timer set
for 60 sec(s).
Jul 16 00:07:01: AAA/SG/TEST: Server (192.0.2.245:1700,1701) removed from quarantine.

load-balance Enables RADIUS server load balancing for named RADIUS server groups.
radius-server host Enables RADIUS automated testing for load balancing.

May 2008 DB-39
Debug Commands
debug aaa test
Command Description
radius-server Enables RADIUS server load balancing for the global RADIUS server
load-balance group.
test aaa group Tests RADIUS load balancing server response manually.

DB-40 May 2008
Debug Commands
debug acircuit checkpoint

To enable the display of attachment circuit (AC) events when Any Transport over MPLS (AToM) is
configured for nonstop forwarding/stateful switchover (NSF/SSO) and Graceful Restart, use the debug
acircuit checkpoint command in privileged EXEC mode. To disable the display of these messages, use
the no form of this command.
no debug acircuit checkpoint
Defaults Debugging of the AToM NSF/SSO and Graceful Restart feature is disabled.

12.2(25)S This command was introduced.
12.2(28)SB This command was integrated into Cisco IOS Release 12.2(28)SB.
Usage Guidelines Use debug commands with care. They use a significant amount of CPU time and can affect system
performance.
Examples The debug acircuit checkpoint command is issued on the active RP:
Router# debug mpls l2transport checkpoint
Router# debug acircuit checkpoint
Router# show debug
AToM HA:
AToM checkpointing events and errors debugging is on
AC HA:
Attachment Circuit Checkpoint debugging is on
Router# conf terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface Fa5/1/1.2
Router(config-subif)# xconnect 10.55.55.2 1002 pw-class mpls
AToM HA [10.55.55.2, 1002]: Build provision msg, SSM sw/seg 8192/8194 [0x2000/0x2002] PW i
d 9216 [0x2400] local label 21
AC HA: Dynamic Sync. Event:4 Sw:8192[2000] Se:16385[4001]
AToM HA: CF sync send complete
AC HA CF: Sync send complete. Code:0

May 2008 DB-41
Debug Commands
On the standby RP, the following messages indicate that it receives checkpointing data:
AC HA [10.55.55.2, 1002]: Add to WaitQ. Flags:1
AToM HA [10.55.55.2, 1002]: Received 32-byte provision version 1 CF message
AC HA CF: ClientId:89, Entity:0 Length:40
AToM HA [10.55.55.2, 1002]: Process chkpt msg provision [1], ver 1
AToM HA [10.55.55.2, 1002]: Reserved SSM sw/seg 8192/8194 [0x2000/0x2002] PW id 9216 [0x24
00]
AC HA: Process Msg:35586. Ptr:44CBFD90. Val:0
AC HA: Sync. Event:4 CktType:4 Sw:8192[2000] Se:16385[4001]
AC HA [10.55.55.2, 1002]: Remove from WaitQ. Flags:1[OK][OK]
During a switchover from the active to the backupRoute Processor, the debug messages look similar to
the following:
%HA-5-MODE: Operating mode is hsa, configured mode is sso.
AC HA RF: CId:83, Seq:710, Sta:RF_STATUS_OPER_REDUNDANCY_MODE_CHANGE, Opr:5, St:STANDBY HO
T, PSt:ACTIVE
AToM HA: CID 84, Seq 715, Status RF_STATUS_OPER_REDUNDANCY_MODE_CHANGE, Op 5, State STANDB
Y HOT, Peer ACTIVE
AC HA RF: CId:83, Seq:710, Sta:RF_STATUS_PEER_PRESENCE, Opr:0, St:STANDBY HOT, PSt:ACTIVE
AToM HA: CID 84, Seq 715, Status RF_STATUS_PEER_PRESENCE, Op 0, State STANDBY HOT, Peer AC
TIVE
AC HA RF: CId:83, Seq:710, Sta:RF_STATUS_PEER_COMM, Opr:0, St:STANDBY HOT, PSt:DISABLED
AToM HA: CID 84, Seq 715, Status RF_STATUS_PEER_COMM, Op 0, State STANDBY HOT, Peer DISABL
ED
%HA-2-CUTOVER_NOTICE: Cutover initiated. Cease all console activity until system restarts.
%HA-2-CUTOVER_NOTICE: Do not add/remove RSPs or line cards until switchover completes.
%HA-2-CUTOVER_NOTICE: Deinitializing subsystems...
%OIR-6-REMCARD: Card removed from slot 4, interfaces disabled
%HA-2-CUTOVER_NOTICE: Reinitializing subsystems...
%HA-2-CUTOVER_NOTICE: System preparing to restart...
%HA-5-NOTICE: Resuming initialization...
AC HA RF: CId:83, Seq:710, Sta:RF_STATUS_REDUNDANCY_MODE_CHANGE, Opr:7, St:STANDBY HOT, PS
t:DISABLED
.
.
.
%LDP-5-GR: LDP restarting gracefully. Preserving forwarding state for 250 seconds.
AC HA RF: CId:83, Seq:710, Sta:RF_PROG_ACTIVE, Opr:0, St:ACTIVE, PSt:DISABLED
AToM HA: CID 84, Seq 715, Event RF_PROG_ACTIVE, Op 0, State ACTIVE, Peer DISABLED
AC HA: Process Msg:35588. Ptr:0. Val:0
AC HA: Switchover: Standby->Active
AC HA RF: Reconciling

debug mpls l2transport Enables the display of AToM events when AToM is configured for
checkpoint NSF/SSO and Graceful Restart.

DB-42 May 2008
Debug Commands
debug acircuit
debug acircuit
To display errors and events that occur on the attachment circuits (the circuits between the provider edge
(PE) and customer edge (CE) routers), use the debug acircuit command in privileged EXEC mode. To
debug acircuit {error | event}
no debug acircuit {error | event}
Syntax Description error Displays errors that occur in attachment circuits.

event Displays events that occur in attachment circuits.

12.2(14)S This command was integrated into Cisco IOS Release 12.2(14)S.
12.2(27)SBC Support for this command was integrated into Cisco IOS Release
12.2(27)SBC.
Usage Guidelines Use the debug acircuit command to identify provisioning events, setup failures, circuit up and down
events, and configuration failures on attachment circuits.
An attachment circuit connects a PE router to a CE router. A router can have many attachment circuits.
The attachment circuit manager controls all the attachment circuits from one central location. Therefore,
when you enable the debug messages for the attachment circuit, you receive information about all the
attachment circuits.
Examples The following is sample output from the debug acircuit event command when you enable an interface:
Router# debug acircuit event
*Jan 28 15:19:03.070: ACLIB: ac_cstate() Handling circuit UP for interface Se2/0

*Jan 28 15:19:03.070: ACLIB [11.0.1.1, 200]: pthru_intf_handle_circuit_up() calling
acmgr_circuit_up
*Jan 28 15:19:03.070: ACLIB [11.0.1.1, 200]: Setting new AC state to Ac-Connecting
*Jan 28 15:19:03.070: ACMGR: Receive <Circuit Up> msg
*Jan 28 15:19:03.070: Se2/0 ACMGR: circuit up event, SIP state chg down to connecting,

May 2008 DB-43
Debug Commands
debug acircuit
action is service request

*Jan 28 15:19:03.070: Se2/0 ACMGR: Sent a sip service request
*Jan 28 15:19:03.070: ACLIB [11.0.1.1, 200]: AC updating switch context.
*Jan 28 15:19:03.070: Se2/0 ACMGR: Rcv SIP msg: resp connect forwarded, hdl 9500001D,
l2ss_hdl 700001E
*Jan 28 15:19:03.070: Se2/0 ACMGR: service connected event, SIP state chg connecting to
connected, action is respond forwarded
*Jan 28 15:19:03.070: ACLIB: pthru_intf_response hdl is 9500001D, response is 1
*Jan 28 15:19:03.070: ACLIB [11.0.1.1, 200]: Setting new AC state to Ac-Connected
The following is sample output from the debug acircuit event command when you disable an interface:
Router# debug acircuit event
*Jan 28 15:25:57.014: ACLIB: SW AC interface INTF-DOWN for interface Se2/0

*Jan 28 15:25:57.014: ACLIB [11.0.1.1, 200]: Setting new AC state to Ac-Idle
*Jan 28 15:25:57.014: ACLIB: SW AC interface INTF-DOWN for interface Se2/0
*Jan 28 15:25:57.014: Se2/0 ACMGR: Receive <Circuit Down> msg
*Jan 28 15:25:57.014: Se2/0 ACMGR: circuit down event, SIP state chg connected to end,
action is service disconnect
*Jan 28 15:25:57.014: Se2/0 ACMGR: Sent a sip service disconnect
*Jan 28 15:25:57.014: ACLIB [11.0.1.1, 200]: AC deleting switch context.
*Jan 28 15:25:59.014: %LINK-5-CHANGED: Interface Serial2/0, changed state to
administratively down
*Jan 28 15:25:59.014: ACLIB: ac_cstate() Handling circuit DOWN for interface Se2/0
*Jan 28 15:26:00.014:%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/0, changed
state to down
The following example shows output from the debug acircuit command for an xconnect session on an
Ethernet interface:
Router# debug acircuit
23:28:35: ACLIB [10.0.3.201, 5]: SW AC interface UP for Ethernet interface Et2/1

23:28:35: ACLIB [10.0.3.201, 5]: pthru_intf_handle_circuit_up() calling acmgr_circuit_up
23:28:35: ACLIB [10.0.3.201, 5]: Setting new AC state to Ac-Connecting
23:28:35: ACLIB [10.0.3.201, 5]: SW AC interface UP for Ethernet interface Et2/1
23:28:35: ACLIB [10.0.3.201, 5]: pthru_intf_handle_circuit_up() ignoring up event. Already
connected or connecting.
23:28:35: ACMGR: Receive <Circuit Up> msg
23:28:35: Et2/1 ACMGR: circuit up event, SIP state chg down to connecting, action is
service request
23:28:35: Et2/1 ACMGR: Sent a sip service request
23:28:37: %LINK-3-UPDOWN: Interface Ethernet2/1, changed state to up
23:28:38: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet2/1, changed state to up
23:28:53: Et2/1 ACMGR: Rcv SIP msg: resp connect forwarded, hdl D6000002, sss_hdl 9E00000F
23:28:53: Et2/1 ACMGR: service connected event, SIP state chg connecting to connected,
action is respond forwarded
23:28:53: ACLIB: pthru_intf_response hdl is D6000002, response is 1
23:28:53: ACLIB [10.0.3.201, 5]: Setting new AC state to Ac-Connected
The command output is self-explanatory.

debug vpdn Displays errors and events relating to L2TP configuration and the
surrounding Layer 2 tunneling infrastructure.
debug xconnect Displays errors and events related to an xconnect configuration.

DB-44 May 2008
Debug Commands
debug adjacency
debug adjacency
To enable the display of information about the adjacency database, use the debug adjacency command
in privileged EXEC mode. To disable the display of these events, use the no form of this command.
debug adjacency [epoch | ipc | state | table] [prefix] [interface] [connectionid id] [link {ipv4 | ipv6
| mpls}]
no debug adjacency [epoch | ipc | state | table] [prefix] [interface] [connectionid id] [link {ipv4 |
ipv6 | mpls}]
Syntax Description epoch (Optional) Displays adjacency epoch events.

ipc (Optional) Displays interprocess communication (IPC) events for
adjacencies.
state (Optional) Displays adjacency system state machine events.
table (Optional) Displays adjacency table operations.
prefix (Optional) Displays debugging events for the specified IP address or IPv6
address.
Note On the Cisco 10000 series routers, IPv6 is supported in
Cisco IOS Release 12.2(28)SB and later releases.
interface (Optional) Displays debugging events for the specified interface. For line
cards, you must specify the line card if_number (interface number). Use the
show cef interface command to obtain line card if_numbers.
connectionid id (Optional) Displays debugging events for the specified client connection
identification number.
link {ipv4 | ipv6 | mpls} (Optional) Displays debugging events for the specified link type (IP, IPv6,
or Multiprotocol Label Switching [MPLS] traffic).
Note On the Cisco 10000 series routers, IPv6 is supported in
Cisco IOS Release 12.2(28)SB and later releases.
Defaults Debugging events are not displayed.

12.0(7)XE This command was introduced on the Cisco 7600 series routers.
12.1(1)E This command was implemented on the Cisco 7600 series routers.
12.2(14)SX This command was implemented on the Supervisor Engine 720.
12.2(25)S This command was integrated into Cisco IOS Release 12.2(25)S, and the
prefix, interface, connectionid id, and link {ipv4 | ipv6 | mpls} keywords
and arguments were added.

May 2008 DB-45
Debug Commands
debug adjacency
Release Modification
12.2(28)SB This command was integrated into Cisco IOS Release 12.2(28)SB and
implemented on the Cisco 10000 series routers.
12.2(33)SXH This command was integrated into Cisco IOS Release 12.2(33)SXH.
Usage Guidelines Because debugging output is assigned high priority in the CPU process, you should use debug commands
only to troubleshoot specific problems or during troubleshooting sessions with Cisco technical support
staff. Also, you should use debug commands during periods of lower network traffic and fewer users.
Debugging during these periods decreases the likelihood that increased debug command processing
overhead will affect system use.
You can use any combination of the prefix, interface, connectionid id, and link {ipv4 | ipv6 | mpls}
keywords and arguments (in any order) as a filter to enable debugging for a specified subset of
adjacencies.
Note On the Cisco 10000 series routers, IPv6 is supported in Cisco IOS Release 12.2(28)SB and later releases.
Examples The following example shows how to display information on the adjacency database:
Router# debug adjacency
*Jan 27 06:22:50.543: ADJ-ios_mgr: repopulate adjs on up event for Ethernet3/0

*Jan 27 06:22:50.543: ADJ: IPV6 adj out of Ethernet3/0, addr FE80::20C:CFFF:FEDF:6854
(incomplete) no src set: init/update from interface
(incomplete) no src set: set bundle to IPv6 adjacency oce
(incomplete) no src set: allocated, setup and inserted OK
(incomplete) src IPv6 ND: source IPv6 ND added OK
(incomplete) src IPv6 ND: computed macstring (len 14): OK
*Jan 27 06:22:50.543: ADJ: IPV6 adj out of Ethernet3/0, addr FE80::20C:CFFF:FEDF:6854 src
IPv6 ND: made complete (macstring len 0 to 14/0 octets)
00:04:40: %LINK-3-UPDOWN: Interface Ethernet3/0, changed state to up
00:04:41: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/0, changed

clear adjacency Clears the Cisco Express Forwarding adjacency table.
clear arp-cache Deletes all dynamic entries from the ARP cache.
show adjacency Displays Cisco Express Forwarding adjacency table
information.
show mls cef adjacency Displays information about the hardware Layer 3 switching
adjacency node.

DB-46 May 2008
Debug Commands
debug alarm-interface
To show real-time activities in the data channel or the management channel of the Alarm Interface
Controller (AIC), use the debug alarm-interface command in privileged EXEC mode. To disable
debug alarm-interface slot-number {data | management}
no debug alarm-interface slot-number {data | management}
Syntax Description slot-number Router chassis slot where the AIC network module is installed.
data Displays AIC serial data channel and asynchronous craft port
communication activity.
management Displays IOS-to-AIC communication activity.
Defaults No default behavior or values

12.2(2)XG This command was introduced for the Cisco 2600 series and the
Cisco 3600 series.
Usage Guidelines This command allows you to observe the management channel activity from the AIC in the specified
slot. Such activity shows that the software running on the AIC CPU has reached a minimum level of
working order.
Examples The following is sample output from the debug alarm-interface command:
Router# debug alarm-interface
AIC Slot 1:STATUS received
The following is sample output from the debug alarm-interface 1 data command:
Router# debug alarm-interface 1 data
AIC Slot 1:STATUS received

aic_fastsend:particle count=1, len=1504
aic_pak_to_txring:scattered particle count=1, tx bytes=1504, leftover=0
aic_interrupt:# 30419 gstar=0x1000000

May 2008 DB-47
Debug Commands
aic_safe_start:particle count=1, len=524

aic_process_TXivq:ivq - 0x42040000 at 15, slice 1
aic_scc_rx_intr:sts_dlen=0xC5E10000, len=1504, RSTA=0xA0
aic_serial_RX_interrupt:rxtype=1, len=1504, aic_scc_rx_intr:last_rxbd has aged, 2
aic_process_RXivq:ivq - 0x60000 at 13, slice 1
aic_scc_rx_intr:sts_dlen=0xC20D0000, len=524, RSTA=0xA0
aic_serial_RX_interrupt:rxtype=1, len=524, aic_process_RXivq:ivq - 0x60000 at 14,
slice 1
aic_scc_rx_intr:sts_dlen=0xC00D0000, len=12, RSTA=0xA0
aic_mgmt_RX_interrupt:len=12
aic_mgmt_fastsend:particle count=1, len=20 / 20
aic_scc_rx_intr:last_rxbd has aged, 2
aic_process_RXivq:ivq - 0x10060000 at 37, slice 1

alarm-interface Enters the alarm interface mode and configures the AIC.
reset Resets the AIC CPU.

DB-48 May 2008
Debug Commands
debug alps ascu
debug alps ascu

To enable debugging for airline product set (ALPS) agent set control units (ASCUs) use the debug alps
ascu command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug alps ascu {event | packet | detail | all | format {ipars | router | both}} [interface [ascu id]]
no debug alps ascu {event | packet | detail | all | format {ipars | router | both}} [interface [ascu
id]]
Syntax Description event Displays ASCU events or protocol errors.

packet Displays sent or received packets.
detail Displays all ASCU protocol events.
all Enables event, packet, and detail debugging.
format {ipars | router | both} Specifies how to display ASCU addresses and the hexadecimal
data in the debug output:
iparsDisplays only the IPARS hexadecimal output.
routerDisplays only the router hexadecimal output.
bothDisplays both the IPARS and router hexadecimal
output.
The only difference between the IPARS output and the router
output is the format of the hexadecimal data.
interface (Optional) Enables debugging on a specified interface. Applies
only to the event, packet, detail, and all keywords.
ascu id (Optional) Enables debugging for a specified ASCU.
Defaults Debugging is off.

11.3(6)T This command was introduced for limited availability.
12.0(1) This command was available for general release.
12.0(5)T This command was modified.
12.1(2)T The format, ipars, router, and both keywords were added. The
output for this command was modified to include IPARS and router
formats.

May 2008 DB-49
Debug Commands
debug alps ascu
Usage Guidelines To enable debugging for a group of ASCUs, enter a separate command for each ASCU interface and IA
combination.
The interface option applies only to the event, packet, detail, and all keywords.
Note To specify the particular debug tracing level (event, packet, detail or all) and the format (router, pairs
or both), you must configure the debug alps ascu command two times: once to configure the debug
tracing level and once to configure the format.
Examples The following output is from the debug alps ascu event command, showing events or protocol errors in
router format for ASCU 42 on interface Serial7:
Router# debug alps ascu format router
Router# debug alps ascu event Serial7 42
ALPS ASCU: T1 expired for ascu 42 on i/f Serial7

ALPS ASCU: DOWN event while UP for ascu 42 on i/f Serial7 : C1 count = 1
Note If you specify the ipars or both format for the event or detail tracing level, both the IPARS and router
formats will be displayed.
The following output is from the debug alps ascu event command, showing events or protocol errors in
ipars format for ASCU 42 on interface Serial7:
Router# debug alps ascu format ipars
Router# debug alps ascu event Serial7 42
ALPS ASCU: T1 expired for ascu 42/2F on i/f Serial7

ALPS ASCU: DOWN event while UP for ascu 42/2F on i/f Serial7 : C1 count = 1
The following output is from the debug alps ascu detail command, showing all protocol events in
router format for ASCU 42 on interface Serial6:
Router# debug alps ascu format router
Router# debug alps ascu detail Serial6 42
ALPS ASCU: Tx ALC POLL MSG (+ 0 pad bytes) to ascu 42 on i/f Serial6
ALPS ASCU: ALC GO AHD MSG rcvd from ascu 42 on i/f Serial6
ALPS ASCU: Rx ALC DATA MSG (14 bytes + CCC) from ascu 42 on i/f Serial6, fwd to ckt
RTP_MATIP

DB-50 May 2008
Debug Commands
debug alps ascu
ALPS ASCU: Tx ALC DATA MSG (14 bytes + CCC + 0 pad bytes) to ascu 42 on i/f Serial6
ALPS ASCU: Tx ALC POLL MSG (3 bytes + CCC + 0 pad bytes) to ascu 42 on i/f Serial6
Note If you specify the ipars or both format for the event or detail tracing level, both the IPARS and router
formats will be displayed.
The following output is from the debug alps ascu detail command, showing all protocol events in both
format for ASCU 42 on interface Serial6:
Router# debug alps ascu format both
Router# debug alps ascu detail Serial6 42
ALPS ASCU: Tx ALC POLL MSG (+ 0 pad bytes) to ascu 42/2F on i/f Serial6
ALPS ASCU: ALC GO AHD MSG rcvd from ascu 42/2F on i/f Serial6
ALPS ASCU: Rx ALC DATA MSG (14 bytes + CCC) from ascu 42/2F on i/f Serial6, fwd to ckt
RTP_MATIP
ALPS ASCU: Tx ALC DATA MSG (14 bytes + CCC + 0 pad bytes) to ascu 42/2F on i/f Serial6
ALPS ASCU: Tx ALC POLL MSG (3 bytes + CCC + 0 pad bytes) to ascu 42/2F on i/f Serial6
The following output is from the debug alps ascu packet command, showing all packets sent or received
in router format for ASCU 42 on interface Serial6:
Router# debug alps ascu packet format router Serial6 42
ALPS ASCU: Tx ALC SERVICE MSG (18 bytes + CCC + 0 pad bytes) to ascu 42 on i/f Serial6
02321D26 0C261616
140C0D18 26163135 0611C6
ALPS ASCU: Rx ALC DATA MSG (14 bytes + CCC) from ascu 42 on i/f Serial6, fwd ckt
RTP_MATIP
42607866 65717866
65717966 755124
ALPS ASCU: Tx ALC DATA MSG (14 bytes + CCC + 0 pad bytes) to ascu 42 on i/f Serial6
022038 26253138
26253139 263511E4
in ipars format for ASCU 42 on interface Serial6:
Router# debug alps ascu packet format ipars Serial6 42
ALPS ASCU: Tx ALC SERVICE MSG (18 bytes + CCC + 0 pad bytes) to ascu 42/2F on i/f Serial6
ALPS IPARS Format:
2F2C1126 33262525
35331339 26251C14 271DC6
ALPS ASCU: Rx ALC DATA MSG (14 bytes + CCC) from ascu 42/2F on i/f Serial6, fwd ckt
RTP_MATIP
ALPS IPARS Format:
2F3E3826 161C3826
161C1826 141D24
ALPS IPARS Format:
2F3E38 26161C38
26161C18 26141DE4

May 2008 DB-51
Debug Commands
debug alps ascu
in both formats for ASCU 42 on interface Serial6:
Router# debug alps ascu packet format both Serial6 42
ALPS ASCU: Tx ALC SERVICE MSG (18 bytes + CCC + 0 pad bytes) to ascu 42/2F on i/f Serial6
ALPS Router Format:
02321D26 0C261616
140C0D18 26163135 0611C6
ALPS IPARS Format:
2F2C1126 33262525
35331339 26251C14 271DC6
ALPS ASCU: Rx ALC DATA MSG (14 bytes + CCC) from ascu 42/2F on i/f Serial6, fwd ckt
RTP_MATIP
ALPS Router Format:
42607866 65717866
65717966 755124
ALPS IPARS Format:
2F3E3826 161C3826
161C1826 141D24
ALPS Router Format:
022038 26253138
26253139 263511E4
ALPS IPARS Format:
2F3E38 26161C38
26161C18 26141DE4

DB-52 May 2008
Debug Commands
debug alps circuit event

To enable event debugging for airline product set (ALPS) circuits, use the debug alps circuit event
debug alps circuit event [name]
no debug alps circuit event [name]
Syntax Description name (Optional) Name given to identify an ALPS circuit on the remote customer
premises equipment (CPE).
Defaults If no circuit name is specified, then debugging is enabled for every ALPS circuit.

11.3 T This command was introduced.
Usage Guidelines To enable debugging for a single ALPS circuit, specify the name of the circuit.
To enable debugging for a group of circuits, enter a separate command for each circuit name.
Examples The following is sample output from the debug alps circuit event command for circuit RTP_AX25:
alps-rcpe# debug alps circuit event RTP_AX25
ALPS P1024 CKT: FSM - Ckt= RTP_AX25, State= OPEN, Event= DISABLE:
(CloseAndDisable)->DISC
ALPS P1024 CKT: FSM - Ckt= RTP_AX25, State= DISC, Event= ENABLE:
(TmrStartNullRetry)->INOP
ALPS P1024 CKT: Ckt= RTP_AX25, Open - peer set to 200.100.40.2
ALPS P1024 CKT: Ckt= RTP_AX25, Open - peer open.
ALPS P1024 CKT: FSM - Ckt= RTP_AX25, State= INOP, Event= RETRY_TIMEOUT:
(Open)->OPNG
ALPS P1024 CKT: FSM - Ckt= RTP_AX25, State= OPNG, Event= CKT_OPEN_CFM:
(CacheAndFwdAscuData)->OPEN
alps-ccpe# debug alps circuit event RTP_AX25

May 2008 DB-53
Debug Commands
ALPS AX.25 FSM: Ckt= RTP_AX25, State= OPEN, Event= CktClose, Rsn= 12:
(PvcKill,CktRemove,TmrStartClose)->INOP
ALPS AX.25 FSM: Ckt= RTP_AX25, State= INOP, Event= X25PvcInact, Rsn= 0:
(-,-,-)->INOP
ALPS AX.25 FSM: Ckt= RTP_AX25, State= INOP, Event= X25VcDeleted, Rsn= 0:
(-,CktDestroy,TmrStop)->INOP
ALPS AX.25 FSM: Ckt= RTP_AX25, State= INOP, Event= CktOpReq, Rsn= 4:
(PvcMake,CktAdd,TmrStartOpen)->OPNG
ALPS AX.25 FSM: Ckt= RTP_AX25, State= OPNG, Event= X25ResetTx, Rsn= 0:
(-,-,-)->OPNG
ALPS AX.25 FSM: Ckt= RTP_AX25, State= OPNG, Event= X25VcUp, Rsn= 0:
(-,OpnCfm,TmrStop)->OPEN

DB-54 May 2008
Debug Commands
debug alps peer event
debug alps peer event

To enable event debugging for airline product set (ALPS) peers, use the debug alps peer event command
debug alps peer event ipaddr
no debug alps peer event ipaddr
Syntax Description ipaddr Peer IP address.
Defaults If no IP address is specified, debugging is enabled for every peer connection.

12.2(33)SRA This command was integrated into Cisco IOS Release
12.2(33)SRA.
12.2SX This command is supported in the Cisco IOS Release
12.2SX train. Support in a specific 12.2SX release of
this train depends on your feature set, platform, and
platform hardware.
Usage Guidelines To enable debugging for a single remote ALPS peer, specify the peer IP address.
To enable debugging for a set of remote peers, enter the command for each peer IP address.
Examples The following is sample output from the debug alps peer event command:
Router# debug alps peer event
ALPS PEER: FSM - Peer 200.100.25.2, Event ALPS_CLOSED_IND, State OPENED

ALPS PEER: peer 200.100.25.2 closed - closing peer circuits.
ALPS PEER: Promiscuous peer created for 200.100.25.2
ALPS PEER: TCP Listen - passive open 200.100.25.2(11003) -> 10000
ALPS PEER: FSM - Peer 200.100.25.2, Event ALPS_OPEN_IND, State DISCONN
ALPS PEER: peer 200.100.25.2 opened OK.

May 2008 DB-55
Debug Commands
debug alps peer
debug alps peer

To enable event or packet debugging for airline product set (ALPS) peers, use the debug alps peer
debug alps peer {event | packet} [ip-address]
no debug alps peer {event | packet} [ip-address]
Syntax Description event Specifies debugging for an event.

packet Specifies debugging for a packet.
ip-address (Optional) Remote peer IP address.
Defaults If no IP address is specified, then debugging is enabled for every peer connection.

12.0(1) This command was available for general release.
12.0(5)T The packet keyword was added. The format for the
output was modified for consistency.
12.2(33)SRA.
platform hardware.
Usage Guidelines To enable debugging for a single remote ALPS peer, specify the peer IP address.
To enable debugging for a set of remote peers, enter the command for each peer IP address.
Examples The following is sample output from the debug alps peer packet command:
Router# debug alps peer packet
ALPS PEER:Peer (10.227.50.106, MATIP_A_CKT-1) - TX Peer Data Msg (18 bytes)

040A5320: 01 00001241
040A5330:45546B5F 6F4F7757 67477B5B 51
ALPS PEER:Peer (10.227.50.106, MATIP_A_CKT-1) - RX Peer Data Msg (18 bytes)
04000550: 01000012 4145546B 5F6F4F77
04000560:5767477B 5B51
ALPS PEER:Peer (10.227.50.106, MATIP_A_CKT-1) - TX Peer Data Msg (18 bytes)

DB-56 May 2008
Debug Commands
debug alps peer
0409F6E0: 01 00001241 45546B5F

0409F6F0:6F4F7757 67477B5B 51
ALPS PEER:Peer (10.227.50.106, MATIP_A_CKT-1) - RX Peer Data Msg (18 bytes)
04000680: 01000012 4145546B
04000690:5F6F4F77 5767477B 5B51

May 2008 DB-57
Debug Commands
debug alps snmp
debug alps snmp

To enable debugging for airline product set (ALPS) Simple Network Management Protocol (SNMP)
agents, use the debug alps snmp command in privileged EXEC mode. To disable debugging output, use
debug alps snmp
no debug alps snmp
Defaults Debugging for SNMP agents is not enabled.

12.0(1)T This command was available for general release.
12.0(5)T This command was added to the documentation.
12.1(2)T The output for this command was modified to reflect
MIB and SNMP changes.
12.2(33)SRA.
platform hardware.
Examples The following output is from the debug alps snmp command. The first line shows a circuit event status
change. The second line shows an ASCU status change. The third line shows a peer connection status
change.
Router# debug alps snmp
ALPS CktStatusChange Notification for circuit CKT-1

ALPS AscuStatusChange Notification for ascu (Serial3, 41)
PeerConnStatusChange Notification for peer (10.227.50.106, MATIP_A_CKT-1)
The following output shows that an open failure has occurred on circuit 1:
ALPS CktOpenFailure Notification for circuit CKT1
The following output shows that a partial rejection to an ALPS circuit peer open request has occurred
on circuit 1:
ALPS CktPartialReject Notification for ascu (Serial2, 41) on circuit CKT1

DB-58 May 2008
Debug Commands
debug appfw
debug appfw
To display debug messages about Cisco IOS Firewall events, use the debug appfw command in
debug appfw {application protocol | function-trace | object-creation | object-deletion | events |

timers | detailed}
no debug appfw {application protocol | function-trace | object-creation | object-deletion | events

| timers | detailed}
Syntax Description application protocol Displays messages about protocol events of firewall-inspected applications,
including details about the protocols packets. Currently, the only supported
protocol is HTTP. (Issue the http keyword.)
function-trace Displays messages about software functions called by Cisco IOS Firewall.
object-creation Displays messages about software objects that are being created by
Cisco IOS Firewall. Cisco IOS Firewall-inspected sessions begin when the
object is created.
object-deletion Displays messages about software objects that are being deleted by
Cisco IOS Firewall. Cisco IOS Firewall-inspected sessions close when the
object is deleted.
events Displays messages about Cisco IOS software events, including Cisco IOS
Firewall packet processing.
timers Displays messages about Cisco IOS Firewall timer events, such as an idle
timeout by the Cisco IOS Firewall.
detailed Detailed information for all other enabled Cisco IOS Firewall debugging is
displayed.
Note This keyword should be used in conjunction with other Cisco IOS
Firewall debugging commands.

Examples The following sample configuration shows how to configure an HTTP policy with application firewall
debugging enabled:
Router(config)# appfw policy-name myPolicyAPPFW FUNC:appfw_policy_find
APPFW FUNC:appfw_policy_find -- Policy myPolicy is not found

APPFW FUNC:appfw_policy_alloc

May 2008 DB-59
Debug Commands
debug appfw
APPFW FUNC:appfw_policy_alloc -- policy_alloc 0x65727278

APPFW FUNC:appfw_policy_alloc -- Policy 0x65727278 is set to valid
APPFW FUNC:appfw_policy_alloc -- Policy myPolicy has been created
APPFW FUNC:appfw_policy_command -- memlock policy 0x65727278
! Debugging sample for application (HTTP) creation
Router(cfg-appfw-policy)# application httpAPPFW FUNC:appfw_http_command
APPFW FUNC:appfw_http_appl_find
APPFW FUNC:appfw_http_appl_find -- Application not found
APPFW FUNC:appfw_http_appl_alloc
APPFW FUNC:appfw_http_appl_alloc -- appl_http 0x64D7A25C
APPFW FUNC:appfw_http_appl_alloc -- Application HTTP parser structure 64D7A25C created
! Debugging sample for HTTP-specific application inspection

Router(cfg-appfw-policy-http)#
Router(cfg-appfw-policy-http)# strict-http action reset alarm
APPFW FUNC:appfw_http_subcommand
APPFW FUNC:appfw_http_subcommand -- strict-http cmd turned on
Router# debug appfw detailed
APPFW Detailed Debug debugging is on

fw7-7206a#debug appfw object-creation
APPFW Object Creations debugging is on
fw7-7206a#debug appfw object-deletion
APPFW Object Deletions debugging is on

DB-60 May 2008
Debug Commands
debug apple arp
debug apple arp

To enable debugging of the AppleTalk Address Resolution Protocol (AARP), use the debug apple arp
debug apple arp [type number]
no debug apple arp [type number]
Syntax Description type (Optional) Interface type.

number (Optional) Interface number.
Usage Guidelines This command is helpful when you experience problems communicating with a node on the network you
control (a neighbor). If the debug apple arp display indicates that the router is receiving AARP probes,
you can assume that the problem does not reside at the physical layer.
Examples The following is sample output from the debug apple arp command:
Router# debug apple arp
Ether0: AARP: Sent resolve for 4160.26

Ether0: AARP: Reply from 4160.26(0000.0c00.0453) for 4160.154(0000.0c00.8ea9)
Ether0: AARP: Resolved waiting request for 4160.26(0000.0c00.0453)
Explanations for representative lines of output follow.

The following line indicates that the router has requested the hardware MAC address of the host at
network address 4160.26:
Ether0: AARP: Sent resolve for 4160.26
The following line indicates that the host at network address 4160.26 has replied, giving its MAC address
(0000.0c00.0453). For completeness, the message also shows the network address to which the reply was
sent and its hardware MAC address (also in parentheses).
The following line indicates that the MAC address request is complete:

May 2008 DB-61
Debug Commands
debug apple domain
debug apple domain

To enable debugging of the AppleTalk domain activities, use the debug apple domain command in
debug apple domain
no debug apple domain
Usage Guidelines Use the debug apple domain command to observe activity for domains and subdomains. Use this
command in conjunction with the debug apple remap command to observe interaction between
remapping and domain activity. Messages are displayed when the state of a domain changes, such as
creating a new domain, deleting a domain, and updating a domain.
Examples The following is sample output from the debug apple domain command intermixed with output from
the debug apple remap command; the two commands show related events:
Router# debug apple domain
Router# debug apple remap
AT-REMAP: RemapProcess for net 30000 domain AURP Domain 1

AT-REMAP: ReshuffleRemapList for subdomain 1
AT-REMAP: Could not find a remap for cable 3000-3001
AT-DOMAIN: atdomain_DisablePort for Tunnel0
AT-DOMAIN: CleanUpDomain for domain 1 [AURP Domain 1]
AT-DOMAIN: Disabling interface Ethernet1
AT-DOMAIN: atdomain_DisablePort for Ethernet1
AT-DOMAIN: CleanSubDomain for inbound subdomain 1
AT-REMAP: Remap for net 70 inbound subdomain 1 has been deleted
AT-DOMAIN: DeleteAvRemapList for inbound subdomain 1
AT-DOMAIN: DeleteRemapTable for subdomain 1
AT-DOMAIN: CleanSubDomain for outbound subdomain 1
AT-REMAP: RemapProcess for net 30000 domain AURP Domain 1 Remapped Net 10000
AT-REMAP: Remap for net 50 outbound subdomain 1 has been deleted
AT-DOMAIN: DeleteAvRemapList for outbound subdomain 1

DB-62 May 2008
Debug Commands
debug apple domain

debug apple remap Enables debugging of the AppleTalk remap activities.

May 2008 DB-63
Debug Commands
debug apple eigrp-all

To enable debugging output from the Enhanced IGRP routines, use the debug apple eigrp-all privileged
EXEC command. The no form of this command disables debugging output.
no debug apple eigrp-all

10.0 This command was introduced.
12.2(13)T This command is no longer supported in Cisco IOS Mainline relesaes or in
Technology-based(T-train) releases. It might continue to appear in
12.2S-family releases.
Usage Guidelines The debug apple eigrp-all command can be used to monitor acquisition of routes, aging route table
entries, and advertisement of known routes through Enhanced IGRP.
Caution Because the debug apple eigrp-all command can generate many messages, use it only when the CPU
utilization of the router is less than 50 percent.
Examples The following is sample output from the debug apple eigrp-all command:
Router# debug apple eigrp-all
3:54:34: atigrp2_router: peer is 83.195

3:54:37: AT: atigrp2_write: about to send packet
3:54:37: Ethernet2: output AT packet: enctype UNKNOWN, size 65
3:54:37: 07FFFFFF0000FFFFFFFFFFFF00000C1485B00046|0041ACD100000053FF8F58585802059110
3:54:37: 000000000000000000000000000000010001000C010001000000000F0204000C0053005300
3:54:37: AT: atigrp2, src=Ethernet2:83.143, dst=83-83, size=52, EIGRP pkt sent
3:54:39: atigrp2_router: peer is 83.195
3:54:42: AT: atigrp2_write: about to send packet
3:54:42: Ethernet2: output AT packet: enctype UNKNOWN, size 65
3:54:42: 07FFFFFF0000FFFFFFFFFFFF00000C1485B00046|0041ACD100000053FF8F58585802059110
3:54:42: 000000000000000000000000000000010001000C010001000000000F0204000C0053005300
3:54:42: AT: atigrp2, src=Ethernet2:83.143, dst=83-83, size=52, EIGRP pkt sent

DB-64 May 2008
Debug Commands
Table 5 debug apple eigrp Field Descriptions
Field Description
atigrp2_router: AppleTalk address of the neighbor.
AT: Indicates that this is an AppleTalk packet.
Ethernet2: Name of the interface through which the router received the packet.
src= Name of the interface sending the Enhanced IGRP packet, as well at its
AppleTalk address.
dst= Cable range of the destination of the packet.
size= Size of the packet (in bytes).

May 2008 DB-65
Debug Commands
debug apple errors
debug apple errors

To display errors occurring in the AppleTalk network, use the debug apple errors command in
debug apple errors [type number]
no debug apple errors [type number]

Usage Guidelines In a stable AppleTalk network, the debug apple errors command produces little output.
To solve encapsulation problems, enable debug apple errors and debug apple packet together.
Examples The following is sample output from the debug apple errors command when a router is brought up with
a zone that does not agree with the zone list of other routers on the network:
Router# debug apple errors
%AT-3-ZONEDISAGREES: Ethernet0: AppleTalk port disabled; zone list incompatible with

4160.19
4160.19
4160.19
As the output suggests, a single error message indicates zone list incompatibility; this message is sent
out periodically until the condition is corrected or the debug apple errors command is turned off.
Most of the other messages that the debug apple errors command can generate are obscure or indicate
a serious problem with the AppleTalk network. Some of these other messages follow.
In the following message, RTMPRsp, RTMPReq, ATP, AEP, ZIP, ADSP, or SNMP could replace NBP,
and llap dest not for us could replace wrong encapsulation:
Packet discarded, src 4160.12-254,dst 4160.19-254,NBP,wrong encapsulation
In the following message, in addition to an invalid echo packet error, other possible errors are unsolicited
AEP echo reply, unknown echo function, invalid ping packet, unknown ping function, and bad responder
packet type:
Ethernet0: AppleTalk packet error; no source address available
AT: pak_reply: dubious reply creation, dst 4160.19
AT: Unable to get a buffer for reply to 4160.19
Processing error, src 4160.12-254,dst 4160.19-254,AEP, invalid echo packet

DB-66 May 2008
Debug Commands
debug apple errors
The debug apple errors command can print out additional messages when other debugging commands
are also turned on. When you turn on both the debug apple errors and debug apple events commands,
the following message can be generated:
Proc err, src 4160.12-254,dst 4160.19-254,ZIP,NetInfo Reply format is invalid
In the preceding message, in addition to the NetInfo Reply format is invalid error, other possible errors
are NetInfoReply not for me, NetInfoReply ignored, NetInfoReply for operational net ignored,
NetInfoReply from invalid port, unexpected NetInfoReply ignored, cannot establish primary zone, no
primary has been set up, primary zone invalid, net information mismatch, multicast mismatch, and zones
disagree.
When you turn on both the debug apple errors and debug apple nbp commands, the following message
can be generated:
Processing error,...,NBP,NBP name invalid
In the preceding message, in addition to the NBP name invalid error, other possible errors are NBP type
invalid, NBP zone invalid, not operational, error handling brrq, error handling proxy, NBP fwdreq
unexpected, No route to srcnet, Proxy to * zone, Zone * from extended net, No zone info for *,
and NBP zone unknown.
When you turn on both the debug apple errors and debug apple routing commands, the following
message can be generated:
Processing error,...,RTMPReq, unknown RTMP request
In the preceding message, in addition to an unknown RTMP request error, other possible errors are
RTMP packet header bad, RTMP cable mismatch, routed RTMP data, RTMP bad tuple, and Not Req or
Rsp.

May 2008 DB-67
Debug Commands
debug apple events
debug apple events

To display information about AppleTalk special events, neighbors becoming reachable or unreachable,
and interfaces going up or down, use the debug apple events command in privileged EXEC mode. To
debug apple events [type number]
no debug apple events [type number]

Usage Guidelines Only significant events (for example, neighbor and route changes) are logged.
The debug apple events command is useful for solving AppleTalk network problems because it provides
an overall picture of the stability of the network. In a stable network, the debug apple events command
does not return any information. If the command generates numerous messages, those messages can
indicate possible sources of the problems.
When configuring or making changes to a router or interface for AppleTalk, enable the debug apple
events command to alert you to the progress of the changes or to any errors that might result. Also use
this command periodically when you suspect network problems.
The debug apple events command is also useful to determine whether network flapping (nodes toggling
online and offline) is occurring. If flapping is excessive, look for routers that only support 254 networks.
When you enable the debug apple events command, you will see any messages that the apple
event-logging configuration command normally displays. Turning on the debug apple events
command, however, does not cause the apple event-logging command to be maintained in nonvolatile
memory. Only turning on the apple event-logging command explicitly stores it in nonvolatile memory.
Furthermore, if the apple event-logging command is already enabled, turning on or off the debug apple
events command does not affect the apple event-logging command.

DB-68 May 2008
Debug Commands
debug apple events
Examples The following is sample output from the debug apple events command that describes a nonseed router
coming up in discovery mode:
router# debug apple events
Discovery Ether0: AT: Resetting interface address filters

%AT-5-INTRESTART: Ether0: AppleTalk port restarting; protocol restarted
mode state
Ether0: AppleTalk state changed; unknown -> restarting
changes Ether0: AppleTalk state changed; restarting -> probing
%AT-6-ADDRUSED: Ether0: AppleTalk node up; using address 65401.148
Ether0: AppleTalk state changed; probing -> acquiring
%AT-6-ACQUIREMODE: Ether0: AT port initializing; acquiring net configuration
Ether0: AppleTalk state changed; acquiring -> restarting
Ether0: AppleTalk state changed; restarting -> line down
Ether0: AppleTalk state changed; line down -> restarting
Ether0: AppleTalk state changed; restarting -> probing
Ether0: AppleTalk state changed; acquiring -> requesting zones
Ether0: AT: Resetting interface address filters
Ether0: AppleTalk state changed; requesting zones -> verifying
AT: Sent GetNetInfo request broadcast on Ethernet0
Ether0: AppleTalk state changed; verifying -> checking zones
S2542
Ether0: AppleTalk state changed; checking zones -> operational
As the output shows, the debug apple events command is useful in tracking the discovery mode state
changes through which an interface progresses. When no problems are encountered, the state changes
progress as follows:
1. Line down.
2. Restarting.
3. Probing (for its own address [node ID] using AARP).
4. Acquiring (sending out GetNetInfo requests).
5. Requesting zones (the list of zones for its cable).
6. Verifying (that the routers configuration is correct. If not, a port configuration mismatch is
declared).
7. Checking zones (to make sure its list of zones is correct).
8. Operational (participating in routing).
Explanations for individual lines of output follow.
The following message indicates that a port is set. In this case, the zone multicast address is being reset.
The following messages indicate that the router is changing to restarting mode:
The following message indicates that the router is probing in the startup range of network numbers
(65280 to 65534) to discover its network number:

May 2008 DB-69
Debug Commands
debug apple events
The following message indicates that the router is enabled as a nonrouting node using a provisional
network number within its startup range of network numbers. This type of message only appears if the
network address the router will use differs from its configured address. This is always the case for a
discovery-enabled router; it is rarely the case for a nondiscovery-enabled router.
The following messages indicate that the router is sending out GetNetInfo requests to discover the
default zone name and the actual network number range in which its network number can be chosen:
Now that the router has acquired the cable configuration information, the following message indicates
that it restarts using that information:
Ether0: AppleTalk state changed; acquiring -> restarting
The following messages indicate that the router is probing for its actual network address:
Ether0: AppleTalk state changed; restarting -> line down
Ether0: AppleTalk state changed; line down -> restarting
The following message indicates that the router has found an actual network address to use:
The following messages indicate that the router is sending out GetNetInfo requests to verify the default
zone name and the actual network number range from which its network number can be chosen:
The following message indicates that the router is requesting the list of zones for its cable:
Ether0: AppleTalk state changed; acquiring -> requesting zones
The following messages indicate that the router is sending out GetNetInfo requests to make sure its
understanding of the configuration is correct:
Ether0: AppleTalk state changed; requesting zones -> verifying
AT: Sent GetNetInfo request broadcast on Ethernet0
The following message indicates that the router is rechecking its list of zones for its cable:
Ether0: AppleTalk state changed; verifying -> checking zones
The following message indicates that the router is now fully operational as a routing node and can begin
routing:
Ether0: AppleTalk state changed; checking zones -> operational

DB-70 May 2008
Debug Commands
debug apple events
The following shows sample debug apple events output that describes a nondiscovery-enabled router
coming up when no other router is on the wire.
Ethernet1: AT: Resetting interface address filters

%AT-5-INTRESTART: Ethernet1: AppleTalk port restarting; protocol restarted
Ethernet1: AppleTalk state changed; unknown -> restarting
Ethernet1: AppleTalk state changed; restarting -> probing
%AT-6-ADDRUSED: Ethernet1: AppleTalk node up; using address 4165.204
Indicates a nondiscovery- Ethernet1: AppleTalk state changed; probing -> verifying
enabled router with no AT: Sent GetNetInfo request broadcast on Ethernet1
other router on the wire Ethernet1: AppleTalk state changed; verifying -> operational
S2543
%AT-6-ONLYROUTER: Ethernet1: AppleTalk port enabled; no neighbors found
As the output shows, a nondiscovery-enabled router can come up when no other router is on the wire;
however, it must assume that its configuration (if accurate syntactically) is correct, because no other
router can verify it. Notice that the last line indicates this situation.
The following is sample output from the debug apple events command that describes a
discovery-enabled router coming up when there is no seed router on the wire:
Router# debug apple events

AT: Sent GetNetInfo request broadcast on Ether0
As the output shows, when you attempt to bring up a nonseed router without a seed router on the wire,
it never becomes operational; instead, it hangs in the acquiring mode and continues to send out periodic
GetNetInfo requests.
The following is sample output from the debug apple events command when a nondiscovery-enabled
router is brought up on an AppleTalk internetwork that is in compatibility mode (set up to accommodate
extended as well as nonextended AppleTalk) and the router has violated internetwork compatibility:
E0: AT: Resetting interface address filters

%AT-5-INTRESTART: E0: AppleTalk port restarting; protocol restarted
E0: AppleTalk state changed; restarting -> probing
%AT-6-ADDRUSED: E0: AppleTalk node up; using address 41.19
E0: AppleTalk state changed; probing -> verifying
Indicates AT: Sent GetNetInfo request broadcast on Ethernet0
configuration %AT-3-ZONEDISAGREES: E0: AT port disabled; zone list incompatible with 41.19
S2545
mismatch AT: Config error for E0, primary zone invalid

E0: AppleTalk state changed; verifying -> config mismatch

May 2008 DB-71
Debug Commands
debug apple events
The following three configuration command lines indicate the part of the configuration of the router that
caused the configuration mismatch:
lestat(config)# interface ethernet 0
lestat(config-if)# apple cab 41-41
lestat(config-if)# apple zone Marketing
The router shown had been configured with a cable range of 41-41 instead of 40-40, which would have
been accurate. Additionally, the zone name was configured incorrectly; it should have been Marketing,
rather than being misspelled as Markting.

DB-72 May 2008
Debug Commands
debug apple nbp
debug apple nbp

To display debugging output from the Name Binding Protocol (NBP) routines, use the debug apple nbp
debug apple nbp [type number]
no debug apple nbp [type number]

Usage Guidelines To determine whether the router is receiving NBP lookups from a node on the AppleTalk network, enable
debug apple nbp at each node between the router and the node in question to determine where the
problem lies.
Caution Because the debug apple nbp command can generate many messages, use it only when the CPU
Examples The following is sample output from the debug apple nbp command:
Router# debug apple nbp
AT: NBP ctrl = LkUp, ntuples = 1, id = 77

AT: 4160.19, skt 2, enum 0, name: =:ciscoRouter@Low End SW Lab
AT: LkUp =:ciscoRouter@Low End SW Lab
AT: NBP ctrl = LkUp-Reply, ntuples = 1, id = 77

AT: 4160.154, skt 254, enum 1, name: lestat.Ether0:ciscoRouter@Low End SW Lab

AT: 4160.19, skt 2, enum 0, name: =:IPADDRESS@Low End SW Lab
AT: 4160.19, skt 2, enum 0, name: =:IPGATEWAY@Low End SW Lab

AT: 4160.19, skt 2, enum 0, name: =:IPADDRESS@Low End SW Lab


May 2008 DB-73
Debug Commands
debug apple nbp
The first three lines describe an NBP lookup request:

Table 6 describes the fields in the first line of output.
Table 6 debug apple nbp Field DescriptionsFirst Line of Output
Field Description
AT: NBP Indicates that this message describes an AppleTalk NBP packet.
ctrl = LkUp Identifies the type of NBP packet. Possible values are as follows:
LkUpNBP lookup request.
LkUp-ReplyNBP lookup reply.
ntuples = 1 Indicates the number of name-address pairs in the lookup request
packet. Range: 1 to 31 tuples.
id = 77 Identifies an NBP lookup request value.
Table 7 describes the fields in the second line of output.
Table 7 debug apple nbp Field DescriptionsSecond Line of Output
Field Description
AT: Indicates that this message describes an AppleTalk packet.
4160.19 Indicates the network address of the requester.
skt 2 Indicates the internet socket address of the requester. The responder
will send the NBP lookup reply to this socket address.
enum 0 Indicates the enumerator field. Used to identify multiple names
registered on a single socket. Each tuple is assigned its own
enumerator, incrementing from 0 for the first tuple.
name: =:ciscoRouter@Low Indicates the entity name for which a network address has been
End SW Lab requested. The AppleTalk entity name includes three components:
Object (in this case, a wildcard character [=], indicating that the
requester is requesting name-address pairs for all objects of the
specified type in the specified zone).
Type (in this case, ciscoRouter).
Zone (in this case, Low End SW Lab).
The third line in the output essentially reiterates the information in the two lines above it, indicating that
a lookup request has been made regarding name-address pairs for all objects of the ciscoRouter type in
the Low End SW Lab zone.

DB-74 May 2008
Debug Commands
debug apple nbp
Because the router is defined as an object of type ciscoRouter in zone Low End SW Lab, the router sends
an NBP lookup reply in response to this NBP lookup request. The following two lines of output show
the response of the router:
AT: NBP ctrl = LkUp-Reply, ntuples = 1, id = 77
AT: 4160.154, skt 254, enum 1, name: lestat.Ether0:ciscoRouter@Low End SW Lab
In the first line, ctrl = LkUp-Reply identifies this NBP packet as an NBP lookup request. The same value
in the id field (id = 77) associates this lookup reply with the previous lookup request. The second line
indicates that the network address associated with the entity name of the router
(lestat.Ether0:ciscoRouter@Low End SW Lab) is 4160.154. The fact that no other entity name/network
address is listed indicates that the responder only knows about itself as an object of type ciscoRouter in
zone Low End SW Lab.

May 2008 DB-75
Debug Commands
debug apple packet
debug apple packet

To display per-packet debugging output, use the debug apple packet command in privileged EXEC
mode. To disable debugging output, use the no form of this command.
debug apple packet [type number]
no debug apple packet [type number]

Usage Guidelines With this command, you can monitor the types of packets being slow switched. It displays at least one
line of debugging output per AppleTalk packet processed.
The output reports information online when a packet is received or a transmission is attempted.
When invoked in conjunction with the debug apple routing, debug apple zip, and debug apple nbp
commands, the debug apple packet command adds protocol processing information in addition to
generic packet details. It also reports successful completion or failure information.
When invoked in conjunction with the debug apple errors command, the debug apple packet command
reports packet-level problems, such as those concerning encapsulation.
Caution Because the debug apple packet command can generate many messages, use it only when the CPU
Examples The following is sample output from the debug apple packet command:
Router# debug apple packet
Ether0: AppleTalk packet: enctype SNAP, size 60, encaps000000000000000000000000

AT: src=Ethernet0:4160.47, dst=4160-4160, size=10, 2 rtes, RTMP pkt sent
AT: ZIP Extended reply rcvd from 4160.19
AT: ZIP Extended reply rcvd from 4160.19

DB-76 May 2008
Debug Commands
debug apple packet
Table 8 describes the fields in the first line of output.
Table 8 debug apple packet Field DescriptionsFirst Line of Output
Field Description
Ether0: Name of the interface through which the router received the
packet.
AppleTalk packet Indicates that this is an AppleTalk packet.
enctype SNAP Encapsulation type for the packet.
size 60 Size of the packet (in bytes).
encaps000000000000000000000000 Encapsulation.
Table 9 describes the fields in the second line of output.
Table 9 debug apple packet Field DescriptionsSecond Line of Output
Field Description
AT: Indicates that this is an AppleTalk packet.
src=Ethernet0:4160.47 Name of the interface sending the packet and its AppleTalk address.
dst=4160-4160 Cable range of the destination of the packet.
size=10 Size of the packet (in bytes.)
2 rtes Indicates that two routes in the routing table link these two addresses.
RTMP pkt sent Type of packet sent.
The third line indicates the type of packet received and its source AppleTalk address. This message is
repeated in the fourth line because AppleTalk hosts can send multiple replies to a given GetNetInfo
request.

May 2008 DB-77
Debug Commands
debug apple remap
debug apple remap

To enable debugging of the AppleTalk remap activities, use the debug apple remap command in
debug apple remap
no debug apple remap
Usage Guidelines Use the debug apple remap command with the debug apple domain command to observe activity
between domains and subdomains. Messages from the debug apple remap command are displayed
when a particular remapping function occurs, such as creating remaps or deleting remaps.
Examples The following is sample output from the debug apple remap command intermixed with output from the
debug apple domain command; the two commands show related events.
Router# debug apple remap
Router# debug apple domain
AT-REMAP: RemapProcess for net 30000 domain AURP Domain 1

AT-REMAP: ReshuffleRemapList for subdomain 1
AT-REMAP: Could not find a remap for cable 3000-3001
AT-DOMAIN: atdomain_DisablePort for Tunnel0
AT-DOMAIN: Disabling interface Ethernet1
AT-DOMAIN: atdomain_DisablePort for Ethernet1
AT-REMAP: Remap for net 70 inbound subdomain 1 has been deleted
AT-REMAP: RemapProcess for net 30000 domain AURP Domain 1 Remaped Net 10000
AT-REMAP: Remap for net 50 outbound subdomain 1 has been deleted

DB-78 May 2008
Debug Commands
debug apple remap

debug apple domain Enables debugging of the AppleTalk domain activities.

May 2008 DB-79
Debug Commands
debug apple routing
debug apple routing

To enable debugging output from the Routing Table Maintenance Protocol (RTMP) routines, use the
debug apple routing command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug apple routing [type number]
no debug apple routing [type number]

Usage Guidelines This command can be used to monitor acquisition of routes, aging of routing table entries, and
advertisement of known routes. It also reports conflicting network numbers on the same network if the
network is misconfigured.
Caution Because the debug apple routing command can generate many messages, use it only when router CPU
utilization is less than 50 percent.
Examples The following is sample output from the debug apple routing command:
Router# debug apple routing

AT: src=Ethernet1:41069.25, dst=41069, size=427, 96 rtes, RTMP pkt sent
AT: Route ager starting (97 routes)
AT: Route ager finished (97 routes)
AT: RTMP from 4160.19 (new 0,old 94,bad 0,ign 0, dwn 0)
Table 10 describes the fields in the first line of sample debug apple routing output.
Table 10 debug apple routing Field DescriptionsFirst Line of Output
Field Description
AT: Indicates that this is AppleTalk debugging output.
src=Ethernet0:4160.41 Indicates the source router interface and network address for the RTMP
update packet.
dst=4160-4160 Indicates the destination network address for the RTMP update packet.

DB-80 May 2008
Debug Commands
debug apple routing
Table 10 debug apple routing Field DescriptionsFirst Line of Output (continued)
Field Description
size=19 Displays the size of this RTMP packet (in bytes).
2 rtes Indicates that this RTMP update packet includes information on two
routes.
RTMP pkt sent Indicates that this type of message describes an RTMP update packet
that the router has sent (rather than one that it has received).
The following two messages indicate that the ager has started and finished the aging process for the
routing table and that this table contains 97 entries:
AT: Route ager starting (97 routes)
AT: Route ager finished (97 routes)
Table 11 describes the fields in the following line of the debug apple routing command output:
Table 11 debug apple routing Field Descriptions
Field Description
AT: Indicates that this is AppleTalk debugging output.
RTMP from 4160.19 Indicates the source address of the RTMP update the router received.
new 0 Displays the number of routes in this RTMP update packet that the router
did not already know about.
old 94 Displays the number of routes in this RTMP update packet that the router
already knew about.
bad 0 Displays the number of routes the other router indicates have gone bad.
ign 0 Displays the number of routes the other router ignores.
dwn 0 Displays the number of poisoned tuples included in this packet.

May 2008 DB-81
Debug Commands
debug apple zip
debug apple zip

To display debugging output from the Zone Information Protocol (ZIP) routines, use the debug apple
zip command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug apple zip [type number]
no debug apple zip [type number]

Usage Guidelines This command reports significant events such as the discovery of new zones and zone list queries. It
generates information similar to that generated by the debug apple routing command, but generates it for
ZIP packets instead of Routing Table Maintenance Protocol (RTMP) packets.
You can use the debug apple zip command to determine whether a ZIP storm is taking place in the
AppleTalk network. You can detect the existence of a ZIP storm when you see that no router on a cable
has the zone name corresponding to a network number that all the routers have in their routing tables.
Examples The following is sample output from the debug apple zip command:
Router# debug apple zip

AT: Recvd ZIP cmd 6 from 4160.19-6
AT: 3 query packets sent to neighbor 4160.19
AT: 1 zones for 31902, ZIP XReply, src 4160.19
AT: net 31902, zonelen 10, name US-Florida
The first line indicates that the router has received an RTMP update that includes a new network number
and is now requesting zone information:
The second line indicates that the neighbor at address 4160.19 replies to the zone request with a default
zone:
AT: Recvd ZIP cmd 6 from 4160.19-6
The third line indicates that the router responds with three queries to the neighbor at network address
4160.19 for other zones on the network:
AT: 3 query packets sent to neighbor 4160.19
The fourth line indicates that the neighbor at network address 4160.19 responds with a ZIP extended
reply, indicating that one zone has been assigned to network 31902:
AT: 1 zones for 31902, ZIP XReply, src 4160.19

DB-82 May 2008
Debug Commands
debug apple zip
The fifth line indicates that the router responds that the zone name of network 31902 is US-Florida, and
the zone length of that zone name is 10:
AT: net 31902, zonelen 10, name US-Florida

May 2008 DB-83
Debug Commands
debug appn all
debug appn all

To turn on all possible debugging messages for Advanced Peer-to-Peer Networking (APPN), use the
debug appn all command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
debug appn all
no debug appn all
Note Refer to the other forms of the debug appn command to enable specific debug output selectively.
Usage Guidelines This command shows all APPN events. Use other forms of the debug appn command to display specific
types of events.
Caution Because the debug appn all command can generate many messages and alter timing in the network
node, use it only when instructed by authorized support personnel.
Caution Debugging output takes priority over other network traffic. The debug appn all command generates
more output than any other debug appn command and can alter timing in the network node. This
command can severely diminish router performance or even render it unusable. In virtually all cases, it
is best to use specific debug appn commands.
Examples Refer to the documentation for specific debug appn commands for examples and explanations.

debug appn cs Displays the APPN CS component activity.
debug appn ds Displays debugging information on APPN DS component activity.
debug appn hpr Displays information related to HPR code execution.
debug appn ms Displays debugging information on APPN MS component activity.
debug appn nof Displays information on APPN NOF component activity.
debug appn pc Displays debugging information on APPN PC component activity.
debug appn ps Displays debugging information on APPN PS component activity.
debug appn scm Displays debugging information on APPN SCM component activity.

DB-84 May 2008
Debug Commands
debug appn all
Command Description
debug appn ss Displays SS events.
debug appn ss Displays debugging information on APPN TRS component activity.

May 2008 DB-85
Debug Commands
debug appn cs
debug appn cs
To display Advanced Peer-to-Peer Networking (APPN) Configuration Services (CS) component activity,
use the debug appn cs command in privileged EXEC mode. To disable debugging output, use the no
form of this command.
debug appn cs
no debug appn cs
Usage Guidelines The CS component is responsible for defining link stations, ports, and connection networks. It is
responsible for the activation and deactivation of ports and link stations and handles status queries for
these resources.
Examples The following is sample output from the debug appn cs command. In this example a link station is being
stopped.
Router# debug appn cs
Turned on event 008000FF
Router# appn stop link PATTY
APPN: ----- CS ----- Deq STOP_LS message

APPN: ----- CS ----- FSM LS: 75 17 5 8
APPN: ----- CS ----- Sending DEACTIVATE_AS - station PATTY
APPN: ----- CS ----- deactivate_as_p->ips_header.lpid = A80A60
APPN: ----- CS ----- deactivate_as_p->ips_header.lpid = A80A60
APPN: ----- CS ----- Sending DESTROY_TG to PC - station PATTY - lpid=A80A60
APPN: ----- CS ----- Deq DESTROY_TG - station PATTY
APPN: ----- CS ----- FSM LS: 22 27 8 0
APPN: ----- CS ----- Sending TG update for LS PATTY to TRS
APPN: ----- CS ----- ENTERING XID_PROCESSING: 4
%APPN-6-APPNSENDMSG: Link Station PATTY stopped
Table 12 describes the significant fields and messages shown in the display.
Table 12 debug appn cs Field Descriptions
Field Description
APPN APPN debugging output.
CS CS component output.
Deq CS received a message from another component.

DB-86 May 2008
Debug Commands
debug appn cs
Table 12 debug appn cs Field Descriptions (continued)
Field Description
FSM LS Link station finite state machine is being referenced.
Sending CS is sending a message to another component.

debug appn all Turns on all possible debugging messages for APPN.

May 2008 DB-87
Debug Commands
debug appn ds
debug appn ds
To display debugging information on Advanced Peer-to-Peer Networking (APPN) Directory Services
(DS) component activity, use the debug appn ds command in privileged EXEC mode. To disable
debug appn ds
no debug appn ds
Usage Guidelines The DS component manages searches for resources in the APPN network. DS is also responsible for
registration of resources within the network.
Examples The following is sample output from the debug appn ds command. In this example a search has been
received.
Router# debug appn ds

APPN: NEWDS: LS: search from: NETA.PATTY
APPN: NEWDS: pcid: DD3321E8B5667111
APPN: NEWDS: Invoking FSM NNSolu
APPN: NEWDS: LSfsm_NNSolu: 00A67AA0 pcid: DD3321E8B5667111 row: 0 col: 0 inp: 80200000
APPN: NEWDS: LSfsm_parent: 00A89940 row: 0 col: 0 inp: 80000000
APPN: NEWDS: Rcvd a LMRQ
APPN: NEWDS: LSfsm_child: 00A89BE8 row: 0 col: 0 inp: 80000080
APPN: NEWDS: PQenq REQUEST_ROUTE(RQ) to TRS
APPN: NEWDS: LSfsm_child: 00A8A1C0 row: 1 col: 0 inp: 80000008
APPN: NEWDS: LSfsm_NNSolu: 00A67AA0 pcid: DD3321E8B5667111 row: 5 col: 1 inp: 80C04000
APPN: NEWDS: Rcvd a LMRY
APPN: NEWDS: send locate to node: NETA.PATTY
Table 13 debug appn ds Field Descriptions
Field Description
NEWDS DS component output.
search from Locate was received from NETA.PATTY.

DB-88 May 2008
Debug Commands
debug appn ds
Table 13 debug appn ds Field Descriptions (continued)
Field Description
LSfsm_ Locate Search finite state machine is being referenced.
PQenq Message was sent to another component.
Rcvd Message was received from another component.
send locate Locate will be sent to NETA.PATTY.


May 2008 DB-89
Debug Commands
debug appn hpr
debug appn hpr

To display debugging information related to High Performance Routing (HPR) code execution, use the
debug appn hpr command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
debug appn hpr
no debug appn hpr
Examples The following is sample output from the debug appn hpr command:
Router# debug appn hpr
APPN: -- ncl.ncl_map_dlc_type() -- mapping TOKEN_RING(4) to NCL_TR(3)

APPN: -- ncl.ncl_port() -- called with port_type:3, cisco_idb:893A14, hpr_ssap:C8
APPN: -- ncl.process_port_change() -- port coming up
APPN: -- ncl.process_port_change() -- PORT_UP
APPN: -- ncl.ncl_port_fsm -- FSM Invoked: Input:0, State:0->1, Action:0
APPN: -- ncl.ncl_unmap_dlc_type() -- mapping NCL(3) to CLS(3)
APPN: ----- ANR ----- Sending ACTIVATE_SAP.req
APPN: -- cswncsnd.main() -- received LSA_IPS ips.
APPN: -- ncl.ncl_assign_anr() -- Assigned ANR,anr:8002
APPN: -- ncl.ncl_map_dlc_type() -- mapping TOKEN_RING(4) to NCL_TR(3)
APPN: -- ncl.ncl_populate_anr() -- anr:8002, dlc_type:3, idb 893A14
APPN: -- ncl.ncl_populate_anr() -- send anr_tbl_update to owning cswncsnd
APPN: -- ncl.ncl_ls_fsm -- FSM Invoked: Input:0, State:0->1, Action:0
APPN: ncl.ncl_send_reqopn_stn_req
APPN: -- ncl.ncl_unmap_dlc_type() -- mapping NCL(3) to CLS(3)
APPN: -- ncl.ncl_ls_fsm() -- send anr_tbl_update to owning cswncsnd
APPN: -- cswncsnd.main() -- received ANR_TBL_UPDATE ips.
APPN: -- cswncsnd.apply_anr_table_update() -- ANR:8002
APPN: -- cswncsnd.main() -- received LSA_IPS ips.
APPN: -- ncl.ncl_ls_fsm -- FSM Invoked: Input:1, State:1->2, Action:1
APPN: -- ncl.ncl_ls_fsm -- P_CEP_ID:AAF638
APPN: -- ncl.ncl_ls_fsm() -- send anr_tbl_update to owning cswncsnd
APPN: rtpm: rtp_send() sent data over connection B9D5E8
APPN: hpr timer: rtt start time clocked at 135952 ms
APPN: -- cswncsnd.main() -- received NCL_SND_MSG ips.
APPN: -- cswncsnd.process_nlp_from_rtp() -- label: 8002, send to p_cep 00AAF638.
APPN: hpr timer: rtt end time clocked at 135972 ms
APPN: hpr timer: round trip time measured at 20 ms

DB-90 May 2008
Debug Commands
debug appn hpr
Table 14 debug appn hpr Field Descriptions
Field Description
NCL Network control layer debugging output. Network control layer is the
component that handles ANR packets.
ncl_port_fsm Network control layer port finite state machine has been invoked.
ncl_assign_anr ANR label has been assigned to an activating link station.
ncl_populate_anr System is updating the ANR record with information specific to the link
station.
ncl_ls_fsm Network control layer link finite state machine has been invoked.
rtp_send RTP is about to send a packet.
hpr timer Debugging output related to an HPR timer.
rtt start time RTP is measuring the round-trip time for an HPR status request packet. This
is the start time.
NCL_SND_MSG Network control layer has been requested to send a packet.
process_nlp_from_rtp Network control layer has been requested by RTP to send a packet.
rtt end time RTP is measuring the round-trip time for an HPR status request packet. This
is the time.
round trip time Round-trip time for this HPR status exchange has been computed.


May 2008 DB-91
Debug Commands
debug appn ms
debug appn ms
To display debugging information on Advanced Peer-to-Peer Networking (APPN) Management Services
(MS) component activity, use the debug appn ms command in privileged EXEC mode. To disable
debug appn ms
no debug appn ms
Usage Guidelines The MS component is responsible for generating, sending, and forwarding network management
information in the form of traps and alerts to a network management focal point, such as Netview, in the
APPN network.
Examples The following is sample output from the debug appn ms command. In this example an error occurred
that caused an alert to be generated.
Router# debug appn ms
APPN: ----- MSS00 ---- Deq ALERT_MSU msg

APPN: --- MSP70 --- ALERT MV FROM APPN WITH VALID LGTH
APPN: --- MSCPL --- Find Active FP
APPN: --- MSP30 --- Entering Build MS Transport
APPN: --- MSP31 --- Entering Building Routing Info.
APPN: --- MSP34 --- Entering Build GDS
APPN: --- MSP32 --- Entering Building UOW correlator
APPN: --- MSP34 --- Entering Build GDS
APPN: --- MSP30 --- Building GDS 0x1310
APPN: --- MSP30 --- Building MS Transport
APPN: --- MSP72 --- ACTIVE FP NOT FOUND, SAVE ONLY
APPN: --- MSUTL --- UOW <= 60, ALL COPIED in extract_uow
APPN: --- MSCAT --- by enq_cached_ms QUEUE SIZE OF QUEUE after enq 4
Table 15 debug appn ms Field Descriptions
Field Description
APPN Indicates that this is APPN debugging output.
MSP Indicates that this is MS component output.


DB-92 May 2008
Debug Commands
debug appn nof
debug appn nof

To display debugging information on Advanced Peer-to-Peer Networking (APPN) Node Operator
Facility (NOF) component activity, use the debug appn nof command in privileged EXEC mode. To
debug appn nof
no debug appn nof
Usage Guidelines The NOF component is responsible for processing commands entered by the user such as start, stop,
show, and configuration commands. NOF forwards these commands to the proper component and waits
for the response.
Examples The following is sample output from the debug appn nof command. In this example, an APPN
connection network is being defined.
Router# debug appn nof
Router# config term

Router(config)# appn connection-network NETA.CISCO
Router(config-appn-cn)# port TR0
Router(config-appn-cn)# complete
router(config)#
APPN: ----- NOF ----- Define Connection Network Verb Received

APPN: ----- NOF ----- send define_cn_t ips to cs
APPN: ----- NOF ----- waiting for define_cn rsp from cs
router(config)#
Table 16 debug appn nof Field Descriptions
Field Description
NOF NOF component output.
Received Configuration command was entered.
send Message was sent to CS.
waiting Response was expected from CS.

May 2008 DB-93
Debug Commands
debug appn nof


DB-94 May 2008
Debug Commands
debug appn pc
debug appn pc
To display debugging information on Advanced Peer-to-Peer Networking (APPN) Path Control (PC)
component activity, use the debug appn pc command in privileged EXEC mode. To disable debugging
output, use the no form of this command.
debug appn pc
no debug appn pc
Usage Guidelines The PC component is responsible for passing Message Units (MUs) between the Data Link Control
(DLC) layer and other APPN components. PC implements transmission priority by passing higher
priority MUs to the DLC before lower priority MUs.
Examples The following is sample output from the debug appn pc command. In this example an MU is received
from the network.
Router# debug appn pc

APPN: ----- PC-----PC Deq REMOTE msg variant_name 2251
APPN: --PC-- mu received to PC lpid: A80AEC
APPN: --PC-- mu received from p_cep_id: 67C6F8
APPN: ----- PC-----PC Deq LSA_IPS from DLC
APPN: --PCX dequeued a DATA.IND
APPN: --- PC processing DL_DATA.ind
APPN: --PC-- mu_error_checker with no error, calling frr
APPN: --PC-- calling frr for packet received on LFSID: 1 2 3
APPN: ----- PC-----PC is sending MU to SC A90396
APPN: ----- SC-----send mu: A90396, rpc: 0, nws: 7, rh.b1: 90
APPN: SC: Send mu.snf: 8, th.b0: 2E, rh.b1: 90, dcf: 8
Table 17 debug appn pc Field Descriptions
Field Description
PC PC component output.
Deq REMOTE Message was received from the network.
mu received Message is an MU.

May 2008 DB-95
Debug Commands
debug appn pc
Table 17 debug appn pc Field Descriptions (continued)
Field Description
DATA.IND MU contains data.
sending MU MU is session traffic for an ISR session. The MU is forwarded to the
Session Connector component for routing.


DB-96 May 2008
Debug Commands
debug appn ps
debug appn ps
To display debugging information on Advanced Peer-to-Peer Networking (APPN) Presentation Services
(PS) component activity, use the debug appn ps command in privileged EXEC mode. To disable
debug appn ps
no debug appn ps
Usage Guidelines The PS component is responsible for managing the Transaction Programs (TPs) used by APPN. TPs are
used for sending and receiving searches, receiving resource registration, and sending and receiving
topology updates.
Examples The following is sample output from the debug appn ps command. In this example a CP capabilities
exchange is in progress.
Router# debug appn ps

APPN: ---- CCA --- CP_CAPABILITIES_TP has started
APPN: ---- CCA --- About to wait for Partner to send CP_CAP
APPN: ---- CCA --- Partner LU name: NETA.PATTY
APPN: ---- CCA --- Mode Name: CPSVCMG
APPN: ---- CCA --- CGID: 78
APPN: ---- CCA --- About to send cp_cp_session_act to SS
APPN: ---- CCA --- Waiting for cp_cp_session_act_rsp from SS
APPN: ---- CCA --- Received cp_cp_session_act_rsp from SS
APPN: ---- CCA --- About to send CP_CAP to partner
APPN: ---- CCA --- Send to partner completed with rc=0, 0
APPN: ---- RCA --- Allocating conversation
APPN: ---- RCA --- Sending CP_CAPABILITIES
APPN: ---- RCA --- Getting conversation attributes
APPN: ---- RCA --- Waiting for partner to send CP_CAPABILITIES
APPN: ---- RCA --- Normal processing complete with cgid = 82
APPN: ---- RCA --- Deallocating CP_Capabilities conversation
Table 18 debug appn ps Field Descriptions
Field Description
CCA CP Capabilities TP output.
RCA Receive CP Capabilities TP output.

May 2008 DB-97
Debug Commands
debug appn ps


DB-98 May 2008
Debug Commands
debug appn scm
debug appn scm

To display debugging information on Advanced Peer-to-Peer Networking (APPN) Session Connector
Manager (SCM) component activity, use the debug appn scm command in privileged EXEC mode. To
debug appn scm
no debug appn scm
Usage Guidelines The SCM component is responsible for the activation and deactivation of the local resources that route
an intermediate session through the router.
Examples The following is sample output from the debug appn scm command. In this example an intermediate
session traffic is being routed.
Router# debug appn scm

Router#
APPN: ----- SCM-----SCM Deq a MU
APPN: ----- SCM-----SCM send ISR_INIT to SSI
APPN: ----- SCM-----(i05) Enter compare_fqpcid()
APPN: ----- SCM-----Adding new session_info table entry. addr=A93160
APPN: ----- SCM-----SCM Deq ISR_CINIT message
APPN: ----- SCM-----SCM sends ASSIGN_LFSID to ASM
APPN: ----- SCM-----SCM Rcvd sync ASSIGN_LFSID from ASM
APPN: ----- SCM-----SCM PQenq a MU to ASM
APPN: ----- SCM-----SCM Deq a MU
APPN: ----- SCM-----SCM PQenq BIND rsp to ASM
Table 19 debug appn scm Field Descriptions
Field Description
SCM SCM component output.


May 2008 DB-99
Debug Commands
debug appn ss
debug appn ss
To display session services (SS) events, use the debug appn ss command in privileged EXEC mode. To
debug appn ss
no debug appn ss
Usage Guidelines The SS component generates unique session identifiers, activates and deactivates control
point-to-control point (CP-CP) sessions, and assists logical units (LUs) in initiating and activating
LU-LU sessions.
Examples The following is sample output from the debug appn ss command. In this example CP-CP sessions
between the router and another node are being activated.
Router# debug appn ss

APPN: ----- SS ----- Deq ADJACENT_CP_CONTACTED message
APPN: ----- SS ----- Deq SESSST_SIGNAL message
APPN: ----- SS ----- Deq CP_CP_SESSION_ACT message
APPN: Sending ADJACENT_NN_1015 to SCM, adj_node_p=A6B980,cp_name=NETA.PATTY
APPN: ----- SS ----- Sending REQUEST_LAST_FRSN message to TRS
APPN: ----- SS ----- Receiving REQUEST_LAST_FRSN_RSP from TRS
APPN: ----- SS ----- Sending ACTIVE CP_STATUS CONLOSER message to DS
APPN: ----- SS ----- Sending ACTIVE CP_STATUS CONLOSER message to MS
APPN: ----- SS ----- Sending ACTIVE CP_STATUS CONLOSER message to TRS
APPN: ----- SS ----- Sending CP_CP_SESSION_ACT_RSP message to CCA TP
APPN: ----- SS ----- Sending PENDING_ACTIVE CP_STATUS CONWINNER message to DS
APPN: ----- SS ----- Sending REQUEST_LAST_FRSN message to TRS
APPN: ----- SS ----- Receiving REQUEST_LAST_FRSN_RSP from TRS
APPN: ----- SS ----- Sending ACT_CP_CP_SESSION message to RCA TP
APPN: ----- SS ----- Deq ASSIGN_PCID message
APPN: ----- SS ----- Sending ASSIGN_PCID_RSP message to someone
APPN: ----- SS ----- Deq INIT_SIGNAL message
APPN: ----- SS ----- Sending REQUEST_COS_TPF_VECTOR message to TRS
APPN: ----- SS ----- Receiving an REQUEST_COS_TPF_VECTOR_RSP from TRS
APPN: ----- SS ----- Sending REQUEST_SINGLE_HOP_ROUTE message to TRS
APPN: ----- SS ----- Receiving an REQUEST_SINGLE_HOP_ROUTE_RSP from TRS
APPN: ----- SS ----- Sending ACTIVATE_ROUTE message to CS
APPN: ----- SS ----- Deq ACTIVATE_ROUTE_RSP message
APPN: ----- SS ----- Sending CINIT_SIGNAL message to SM
APPN: ----- SS ----- Deq ACT_CP_CP_SESSION_RSP message
APPN: -- SS----SS ssp00, act_cp_cp_session_rsp received, sense_code=0, cgid=5C,
ips@=A93790
APPN: Sending ADJACENT_NN_1015 to SCM, adj_node_p=A6B980,cp_name=18s

DB-100 May 2008
Debug Commands
debug appn ss
APPN: ----- SS ----- Sending ACTIVE CP_STATUS CONWINNER message to DS

APPN: ----- SS ----- Sending ACTIVE CP_STATUS CONWINNER message to MS
APPN: ----- SS ----- Sending ACTIVE CP_STATUS CONWINNER message to TRS
Table 20 debug appn ss Field Descriptions
Field Description
SS SS component output.


May 2008 DB-101
Debug Commands
debug appn trs
debug appn trs

To display debugging information on Advanced Peer-to-Peer Networking (APPN) Topology and
Routing Services (TRS) component activity, use the debug appn trs command in privileged EXEC
debug appn trs
no debug appn trs
Usage Guidelines The TRS component is responsible for creating and maintaining the topology database, creating and
maintaining the class of service database, and computing and caching optimal routes through the
network.
Examples The following is sample output from the debug appn trs command:
Router# debug appn trs

APPN: ----- TRS ----- Received a QUERY_CPNAME
APPN: ----- TRS ----- Received a REQUEST_ROUTE
APPN: ----- TRS ----- check_node node_name=NETA.LISA
APPN: ----- TRS ----- check_node node_index=0
APPN: ----- TRS ----- check_node node_weight=60
APPN: ----- TRS ----- add index 484 to origin description list
APPN: ----- TRS ----- add index 0 to dest description list
APPN: ----- TRS ----- origin tg_vector is NULL
APPN: ----- TRS ----- weight_to_origin = 0
APPN: ----- TRS ----- weight_to_dest = 0
APPN: ----- TRS ----- u_b_s_f weight = 30
APPN: ----- TRS ----- u_b_s_f prev_weight = 2147483647
APPN: ----- TRS ----- u_b_s_f origin_index = 484
APPN: ----- TRS ----- u_b_s_f dest_index = 0
APPN: ----- TRS ----- b_r_s_f weight = 30
APPN: ----- TRS ----- b_r_s_f origin_index = 484
APPN: ----- TRS ----- b_r_s_f dest_index = 0
APPN: ----- TRS ----- Received a REQUEST_ROUTE
APPN: ----- TRS ----- check_node node_name=NETA.LISA
APPN: ----- TRS ----- check_node node_name=NETA.BART
APPN: ----- TRS ----- add index 484 to origin description list
APPN: ----- TRS ----- add index 0 to dest description list
APPN: ----- TRS ----- origin_tg_weight to non-VN=30
APPN: ----- TRS ----- origin_node_weight to non-VN=60
APPN: ----- TRS ----- weight_to_origin = 90
APPN: ----- TRS ----- weight_to_dest = 0

DB-102 May 2008
Debug Commands
debug appn trs
APPN: ----- TRS ----- u_b_s_f weight = 120

APPN: ----- TRS ----- u_b_s_f prev_weight = 2147483647
APPN: ----- TRS ----- u_b_s_f origin_index = 484
APPN: ----- TRS ----- u_b_s_f dest_index = 0
APPN: ----- TRS ----- b_r_s_f weight = 120
APPN: ----- TRS ----- b_r_s_f origin_index = 484
APPN: ----- TRS ----- b_r_s_f dest_index = 0
Table 21 debug appn trs Field Descriptions
Field Description
TRS TRS component output.

May 2008 DB-103
Debug Commands
debug arap
debug arap
To display AppleTalk Remote Access Protocol (ARAP) events, use the debug arap command in
debug arap {internal | memory | mnp4 | v42bis} [linenum [aux | console | tty | vty]]
no debug arap {internal | memory | mnp4 | v42bis} [linenum [aux | console | tty | vty]]
Syntax Description internal Debugs internal ARA packets.

memory Debugs memory allocation for ARA.
mnp4 Debugs low-level asynchronous serial protocol.
v42bis Debugs V.42bis compression.
linenum (Optional) Line number. The number ranges from 0 to 999, depending on what
type of line is selected.
aux (Optional) Auxiliary line.
console (Optional) Primary terminal line.
tty (Optional) Physical terminal asynchronous line.
vty (Optional) Virtual terminal line.
Usage Guidelines Use the debug arap command with the debug callback command on access servers to debug dialin and
callback events.
Use the debug modem command to help catch problems related to ARAP autodetection (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.
Examples The following is sample output from the debug arap internal command:
Router# debug arap internal
ARAP: ---------- SRVRVERSION ----------

ARAP: ---------- ACKing 0 ----------
ARAP: ---------- AUTH_CHALLENGE ----------
arapsec_local_account setting up callback
ARAP: ---------- ACKing 1 ----------
ARAP: ---------- AUTH_RESPONSE ----------
arap_startup initiating callback ARAP 2.0
ARAP: ---------- CALLBACK ----------
TTY7 Callback process initiated, user: dialback dialstring 40
TTY7 Callback forced wait = 4 seconds
TTY7 ARAP Callback Successful - await exec/autoselect pickup
TTY7: Callback in effect
ARAP: ---------- STARTINFOFROMSERVER ----------
ARAP: ---------- ACKing 0 ----------
ARAP: ---------- ZONELISTINFO ----------

DB-104 May 2008
Debug Commands
debug arap


debug callback Displays callback events when the router is using a modem and a chat script
to call back on a terminal line.
debug modem Observes modem line activity on an access server.

May 2008 DB-105
Debug Commands
debug archive config timestamp

To enable debugging of the processing time for each integral step of a configuration replace operation
and the size of the configuration files being handled, use the debug archive config timestamp command
no debug archive config timestamp

12.2(31)SB2 This command was implemented on the Cisco 10000 series.
implemented on the Cisco 10000 series.
Examples The following is sample output from the debug archive config timestamp command:
Router# debug archive config timestamp
Router# configure replace disk0:myconfig force
Timing Debug Statistics for IOS Config Replace operation:

Time to read file slot0:sample_2.cfg = 0 msec (0 sec)
Number of lines read:55
Size of file :1054
Starting Pass 1
Time to read file system:running-config = 0 msec (0 sec)
Size of file :2539
Time taken for positive rollback pass = 320 msec (0 sec)
Time taken for negative rollback pass = 0 msec (0 sec)
Time taken for negative incremental diffs pass = 59 msec (0 sec)
Time taken by PI to apply changes = 0 msec (0 sec)
Time taken for Pass 1 = 380 msec (0 sec)
Starting Pass 2
Time to read file system:running-config = 0 msec (0 sec)

DB-106 May 2008
Debug Commands

Size of file :1054
Time taken for positive rollback pass = 0 msec (0 sec)
Time taken for negative rollback pass = 0 msec (0 sec)
Time taken for Pass 2 = 0 msec (0 sec)
Total number of passes:1

Rollback Done

debug archive versioning Enables debugging of the Cisco IOS configuration archive activities.

May 2008 DB-107
Debug Commands
debug archive log config persistent

Command Description
debug archive versioning Enables debugging of the Cisco IOS configuration archive activities.
To turn on debugging of configuration logging persistent events and display the results, use the debug
archive log config persistent command in privileged EXEC mode. To disable the debugging and display
of the archive events, use the no form of this command.
no debug archive log config persistent
Command Default If this command is not entered, there is no debugging or display of the configuration logging persistent
events in the archive.

12.2(33)SRA This command was introduced.
Usage Guidelines The configuration logger feature must be enabled in order for the debug capability to work.
Examples The following example turns on the debugging feature and displays the configuration logging persistent
events:
Router# debug archive config log persistent
Router# archive log config persistent save
Configuration logging persistent save triggered.
Saving the config log to disk0:IOS-Config-Logger-database.
Command interface eth0 saved
Command ip address 10.1.1.1 255.255.255.0 saved
Command no shut saved
Router#

DB-108 May 2008
Debug Commands

archive log config Saves the persisted commands in the configuration log to the Cisco IOS
persistent save secure file system.

May 2008 DB-109
Debug Commands
debug archive versioning

To enable debugging of the Cisco IOS configuration archive activities, use the debug archive versioning
no debug archive versioning

12.2(31)SB2 This command was implemented on the Cisco 10000 series.
implemented on the Cisco 10000 series.
Examples The following is sample output from the debug archive versioning command:
Router# debug archive versioning
Jan 9 06:46:28.419:backup_running_config
Jan 9 06:46:28.419:Current = 7
Jan 9 06:46:28.443:Writing backup file disk0:myconfig-7
Jan 9 06:46:29.547: backup worked

debug archive config timestamp Enables debugging of the processing time for each integral
step of a configuration replace operation and the size of the
configuration files being handled.

DB-110 May 2008
Debug Commands
debug arp
debug arp
To enable debugging output for Address Resolution Protocol (ARP) transactions, use the debug arp
debug arp [arp-entry-event | arp-table-event | ha | interface-interaction]
no debug arp [arp-entry-event | arp-table-event | ha | interface-interaction]
Syntax Description arp-entry-event (Optional) Enables debug trace for ARP entry events by specifying one of
the following keywords:
dynamicEnables debugging output for dynamic ARP entry events.
interfaceEnables debugging output for interface ARP entry events.
staticEnables debugging output for static ARP entry events.
subblockingEnables debugging output for ARP subblocking events.
arp-table-event (Optional) Enables debug trace for ARP table events by specifying one of the
following keywords:
tableEnables debugging output for ARP table operations.
timerEnables debugging output for ARP timer operations.
ha (Optional) Enables debug trace for ARP high availability (HA) events.
Note This keyword is available only on HA-capable platforms (that is,
Cisco networking devices that support dual Route Processors [RPs]).
interface-interaction (Optional) Enables debug trace for ARP interface interaction by specifying
one of the following keywords:
adjacencyEnables debugging output for ARP interface events and
Cisco Express Forwarding (CEF) adjacency interface events.
applicationEnables debugging output for ARP application interface
events.
Command Default Debugging output is disabled for ARP transactions.

12.4(11)T The following keywords were added: adjacency, application, dynamic, ha,
interface, static, subblocking, table, and timer.

May 2008 DB-111
Debug Commands
debug arp
Usage Guidelines To enable ARP packet debugging, use this command without a keyword. The debugging information
shows whether the router is sending ARP packets and whether it is receiving ARP packets. Use this
command when some nodes on a TCP/IP network are responding, but others are not.
The amount of debug information displayed is filtered based on an interface, an access list, or both, as
specified by the debug list command.
To list the debugging options enabled on this router, use the show debugging command.
Examples The following example shows how to enable ARP packet debugging filtered on ARP table entries for the
host at 192.0.2.10:
Router(config)# access-list 10 permit host 192.0.2.10
Router(config)# exit
Router# debug list 10
Router# debug arp
ARP packet debugging is on

for access list: 10
The following is sample output from the debug arp command:

IP ARP: sent req src 192.0.2.7 0000.0c01.e117, dst 192.0.2.96 0000.0000.0000
IP ARP: rcvd rep src 192.0.2.96 0800.2010.b908, dst 192.0.2.7
IP ARP: rcvd req src 172.16.6.10 0000.0c00.6fa2, dst 192.0.2.62
IP ARP: rep filtered src 192.0.2.7 aa92.1b36.a456, dst 255.255.255.255 ffff.ffff.ffff
IP ARP: rep filtered src 192.0.2.240 0000.0c00.6b31, dst 192.0.2.7 0800.2010.b908
In 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 192.0.2.7 and MAC address 0000.0c01.e117 sent an
ARP request for the MAC address of the host at 192.0.2.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 192.0.2.7 0000.0c01.e117, dst 192.0.2.96 0000.0000.0000
The second line indicates that the router at IP address 192.0.2.7 receives a reply from the host at
192.0.2.96 indicating that its MAC address is 0800.2010.b908:
IP ARP: rcvd rep src 192.0.2.96 0800.2010.b908, dst 192.0.2.7
The 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 192.0.2.62:
IP ARP: rcvd req src 172.16.6.10 0000.0c00.6fa2, dst 192.0.2.62
The 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 a bridge
is being run in parallel with the router and is allowing ARP to be bridged. This condition indicates a
network misconfiguration.
IP ARP: rep filtered src 192.0.2.7 aa92.1b36.a456, dst 255.255.255.255 ffff.ffff.ffff
The fifth line indicates that another host on the network attempted to inform the router that it is on
network 192.0.2.240, 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 192.0.2.240 0000.0c00.6b31, dst 192.0.2.7 0800.2010.b908

DB-112 May 2008
Debug Commands
debug arp

access-list Configures the extended access list mechanism for filtering frames by both
(extended-ibm) source and destination addresses and arbitrary bytes in the packet.
debug list Enables filtering of debug trace on a per-interface or per-access list basis.
show debugging Lists the debugging options enabled on this router.

May 2008 DB-113
Debug Commands
debug ase
debug ase
To gather Automatic Signature Extraction (ASE) error, log, messaging, reporting, status, and timer
information, use the debug ase command in privileged EXEC mode. To disable error, log, messaging,
reporting, status, and timer information, use the no form of this command.
debug ase {errors | log | messages | reports | status | timing}
no debug ase {errors | log | messages | reports | status | timing}
Syntax Description errors Displays ASE error information.

log Displays ASE logging information.
messages Displays ASE messaging information.
reports Displays ASE reports.
status Displays ASE status information.
timing Displays ASE timer information.
Command Default Disabled

Usage Guidelines This command is used on the Cisco 1800, 2800, and 7200 series routers, Cisco 7301 router, and
Integrated Services Routers (ISRs) as ASE sensors.

DB-114 May 2008
Debug Commands
debug ase

ase collector Enters the ASE collector server IP address so that the ASE sensor has IP
connectivity to the ASE collector.
ase enable Enables the ASE feature on a specified interface.
ase group Identifies the TIDP group number for the ASE feature.
ase signature Enables the ASE feature globally on the router.
extraction
clear ase signature Clears ASE signatures that were detected on the router.
show ase Displays the ASE run-time status, which includes the TIDP group number.

May 2008 DB-115
Debug Commands
debug asnl events
debug asnl events

To trace event logs in the Application Subscribe Notify Layer (ASNL), use the debug asnl events
debug asnl events
no debug asnl events

Usage Guidelines This command traces the event logs in the ASNL, which serves as the interface layer between the
application and protocol stacks. Event logs are generated during normal subscription processing, when
the application responds to the notification request and when the session history table is updated.
Examples The following example shows the ASNL subscription table being generated and the associated
subscription timers as the application responds to the subscription request. The response timer is started
to determine if the application responds to the notification request. If the application that made the
subscription does not respond to the notification request within 5 seconds, the system automatically
removes the subscription. The session-history-record deletion timer is also started. When the timer
expires, the history record is removed from the active subscription table.
Router# debug asnl events
Application Subscribe Notify Layer Events debugging is on

*May 4 06:26:19.091://-1//ASNL:SUB-1:/asnl_process_is_up:Creating subscription table
*May 4 06:26:19.091://5//ASNL:SUB1:/asnl_subscribe:resp = ASNL_SUBCRIBE_PENDING[2]
*May 4 06:26:19.615://5//ASNL:SUB1:/asnl_start_timer:timer (0x63146C44)starts - delay
(5000)
*May 4 06:26:19.619://-1//ASNL:SUB1:/asnl_stop_timer:timer(0x63146C44) stops
*May 4 06:26:19.619://-1//ASNL:SUB1:/asnl_notify_ack:ret=0x0
c5300-5#
(5000)

DB-116 May 2008
Debug Commands
debug asnl events
c5300-5#
(5000)
(5000)
*May 4 06:26:34.667://-1//ASNL:SUB-1:/asnl_create_session_history:Creating Session
History
*May 4 06:26:34.667://-1//ASNL:SUB-1:/asnl_insert_session_history_record:starting history
record deletion_timer of 15 minutes

clear subscription Clears all active subscriptions or a specific subscription.
show subscription Displays information about ASNL-based and non-ASNL-based SIP
subscriptions.
subscription asnl Specifies how long to keep ASNL subscription history records and how
session history many history records to keep in memory.

May 2008 DB-117
Debug Commands
debug asp packet
debug asp packet

To display information on all asynchronous security protocols (ASPs) operating on the router, use the
debug asp packet command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug asp packet
no debug asp packet
Usage Guidelines The router uses asynchronous security protocols from companies including 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 pass-through mode using BSTUN
encapsulation.
Examples 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 EIA/TIA-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 packet
12:19:48: ASP: Serial5: ADI-Rx: Data (4 bytes): F1FF4C42

12:19:49: ASP: Serial5: ADI-Tx: Data (1 bytes): 88
12:19:49: ASP: Serial5: ADI-Rx: Data (4 bytes): F0FF9B94
12:20:47: ASP: Serial5: ADI-Rx: Data (4 bytes): F1FF757B
12:20:48: ASP: Serial5: ADI-Tx: Data (1 bytes): F3
12:20:48: ASP: Serial5: ADI-Rx: Data (4 bytes): F0FFB1BE
12:21:46: ASP: Serial5: ADI-Rx: Data (4 bytes): F1FFE6E8
12:21:46: ASP: Serial5: ADI-Tx: Data (1 bytes): 6F
12:21:46: ASP: Serial5: ADI-Rx: Data (4 bytes): F0FFC1CE
Table 22 debug asp packet Field Descriptions
Field Description
ASP Asyncronous security protocol packet.
Serial5 Interface receiving and sending the packet.
ADI-Rx Packet is being received.
ADI-T Packet is being sent.

DB-118 May 2008
Debug Commands
debug asp packet
Table 22 debug asp packet Field Descriptions (continued)
Field Description
Data (n bytes) Type and size of the packet.
F1FF4c42 Alarm panel device address.

May 2008 DB-119
Debug Commands
debug aspp event
debug aspp event

To display asynchronous point of sale (APOS) event debug messages, use the debug aspp event
debug aspp event
no debug aspp event
Defaults Disabled

Usage Guidelines The debug aspp event command should be used with the debug aspp packet command to display all
available details of the APOS call flow.
Examples The following is sample output from the debug aspp event command for a simple transaction:
Router# debug aspp event
ASPP event debugging is on

Router#
ASPP APOS: Serial0/1: Serial HayesAT: state = DISCONNECTED
ASPP APOS: Serial0/1: Received HayesAT DIAL: state = DISCONNECTED
ASPP APIP: Serial0/1: Serial ENABLE: state = CONNECTING
ASPP APIP: Serial0/1: Network ENABLE: state = CONNECTING
ASPP APOS: Serial0/1: Send HayesAT CONNECT 9600: state = CONNECTED
ASPP APOS: Serial0/1: Response timer expired: state = CONNECTED
ASPP APOS: Serial0/1: Response timer expired: state = CONNECTED
ASPP APOS: Serial0/1: Serial DATA: state = CONNECTED
ASPP APIP: Serial0/1: Serial DATA: state = CONNECTED
ASPP APIP: Serial0/1: Network DATA: state = CONNECTED
ASPP APOS: Serial0/1: Serial ACK: state = CONNECTED
ASPP APOS: Serial0/1: Disconnect timer expired: state = DISCONNECT WAIT
ASPP APIP: Serial0/1: Serial DISABLE: state = DISCONNECTING
ASPP APIP: Serial0/1: Network DISABLE: state = DISCONNECTING

DB-120 May 2008
Debug Commands
debug aspp event
Table 23 debug aspp event Field Descriptions
Field Description
Serial ENABLE: Enable event received from the serial interface.
Network ENABLE: Enable event received from the network.
Send HayesAT CONNECT Interpreted version of the Hayes AT command that is sent to
the serial interface.
Response timer expired The response timer has expired.
Serial DATA: Data received from the serial interface.
Network DATA: Data received from the network.
Disconnect timer expired Hayes AT event is received by the serial interface.
Serial ACK: Acknowledgment received from the serial interface.
Serial DISABLE: Disable event received from the serial interface.
Network DISABLE: Disable event received from the network.

debug aspp packet Displays APOS packet debug messages.

May 2008 DB-121
Debug Commands
debug aspp packet
debug aspp packet

To display asynchronous point of sale (APOS) packet debug messages, use the debug aspp packet
debug aspp packet
no debug aspp packet
Defaults Disabled

Usage Guidelines The debug aspp packet command should be used with the debug aspp event command to display all
available details of the APOS call flow.
Examples The following is sample output from the debug aspp packet command for a simple transaction:
Router# debug aspp packet
ASPP event debugging is on

Router#
ASPP:Serial1/7:ADI-rx:Data (14 bytes): 415456302644325331313D35300D
ASPP:Serial1/7:ADI-tx:Data (2 bytes): 300D
ASPP:Serial1/7:ADI-rx:Data (27 bytes): 4154583453393D3153373D323444543138303039
ASPP:Serial1/7:ADI-tx:Data (1 bytes): 05
ASPP:Serial1/7:ADI-rx:Data (5 bytes): 0212340325
ASPP:Serial1/7:ADI-rx:Data (1 bytes): 06
ASPP:Serial1/7:ADI-tx:Data (1 bytes): 04

DB-122 May 2008
Debug Commands
debug aspp packet
Table 24 debug aspp packet Field Descriptions
Field Description
ASPP Indicates that this is an ASPP debug message.
Serial1/7: The interface that received or transmitted the packet.
ADI-rx Indicates a received packet.
ADI-tx Indicates a transmitted packet.

debug aspp event Displays APOS event debug messages.

May 2008 DB-123
Debug Commands
debug async async-queue

To display debug messages for asynchronous rotary line queueing, use the debug async async-queue
no debug async async-queue

Support in a specific 12.2SX release of this train depends on your feature
set, platform, and platform hardware.
Examples The following example starts the asynchronous rotary line queueing debugging display:
Router# debug async async-queue
*Mar 2 03:50:28.377: AsyncQ: First connection to be queued - starting the AsyncQ manager
*Mar 2 03:50:28.377: AsyncQ: Enabling the AsyncQ manager
*Mar 2 03:50:28.377: AsyncQ: Started the AsyncQ manager process with pid 98
*Mar 2 03:50:28.381: AsyncQ: Created a Waiting TTY on TTY66 with pid 99
*Mar 2 03:50:30.164: WaitingTTY66: Did Authentication on waiting TTY (VTY)
*Mar 2 03:50:30.168: AsyncQ: Received ASYNCQ_MSG_ADD
*Mar 2 03:50:30.168: AsyncQ: New queue, adding this connection as the first element
*Mar 2 03:50:34.920: AsyncQ: Created a Waiting TTY on TTY67 with pid 100
*Mar 2 03:50:36.783: WaitingTTY67: Did Authentication on waiting TTY (VTY)
*Mar 2 03:50:36.787: AsyncQ: Received ASYNCQ_MSG_ADD
*Mar 2 03:50:36.787: AsyncQ: Queue exists, adding this connection to the end of the queue

debug ip tcp transactions Enables the IP TCP transactions debugging display to observe
significant transactions such as state changes, retransmissions,
and duplicate packets.
debug modem Enables the modem debugging display to observe modem line
activity on an access server.

DB-124 May 2008
Debug Commands
debug atm autovc
debug atm autovc

To display information about autoprovisioned ATM permanent virtual circuit (PVC) events and errors, use
the debug atm autovc command in privileged EXEC mode. To disable the display of information about
autoprovisioned ATM PVC events and errors, use the no form of this command.
debug atm autovc {event | error | all}
no debug atm autovc
Syntax Description event Displays all autoprovisioned PVC events.

error Displays all autoprovisioned PVC errors.
all Displays all autoprovisioned PVC events and errors.

12.2(15)B This command was introduced.
Examples The following example shows output for the debug atm autovc command for all autoprovisioned PVC
events and errors:
Router# debug atm autovc all
AutoVC all debugging is on
Router#
00:09:03:AutoVC(ATM1/0):1/101 enqueued
There is incoming traffic on PVC 1/101 and the pvc is enqueued to be processed.
00:09:03:AutoVC(ATM1/0):process VC 1/101
PVC 1/101 is in the process of being autoprovisioned.
00:09:03:AutoVC(ATM1/0.1):bring up vc 1/101
PVC 1/101 is being brought up.
00:09:03:%ATM-5-UPDOWN:Interface ATM1/0.1, Changing autovc 1/101 to UP

This message indicates that the PVC was brought up successfully.

May 2008 DB-125
Debug Commands
debug atm autovc

create on-demand Configures ATM PVC autoprovisioning, which enables a PVC or range of
PVCs to be created automatically on demand.

DB-126 May 2008
Debug Commands
debug atm bundle error

To display debug messages for switched virtual circuit (SVC) bundle errors, use the debug atm bundle
error command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
no debug atm bundle error

Examples The following example provides output for the debug atm bundle error command:
Router# debug atm bundle error

debug atm bundle events Displays SVC bundle events.

May 2008 DB-127
Debug Commands
debug atm bundle events

To display switched virtual circuit (SVC) bundle events, use the debug atm bundle events command in
no debug atm bundle events

Examples The following example provides output for the debug atm bundle events command:
Router# debug atm bundle events
01:14:35:BUNDLE EVENT(test):b_update_vc for four with bstate 1, vc_state4

01:14:35:BUNDLE EVENT(test):bmupdate active precedence 0x01 0
01:14:35:BUNDLE EVENT(test):bmupdate active precedence 0x80 0 -
01:14:35:BUNDLE EVENT(test):bundle precedence updated

.
Table 25 debug atm bundle events Field Descriptions
Field Description
01:14:35 Local time on the router in hours:minutes:seconds.
BUNDLE EVENT(test) Bundle event for bundle by that name.
b_update_vc for four with bstate 1, vc_state 1 Test describing the bundle event.

DB-128 May 2008
Debug Commands

debug atm bundle error Displays debug messages for SVC bundle errors.

May 2008 DB-129
Debug Commands
debug atm cell-packing

To enable the display of ATM cell relay cell-packing debugging information, use the debug atm
cell-packing command in privileged EXEC mode. To disable the display of debugging information, use
no debug atm cell-packing

Examples The following example enables debugging for ATM virtual circuits (VCs) that have been configured with
cell packing:
Router# debug atm cell-packing
ATM Cell Packing debugging is on

00:09:04: ATM Cell Packing: vc 1/100 remote mncp 22 validated
The following example enables debugging for permanent virtual paths (PVPs) that have been configured
with cell packing:
Router# debug atm cell-packing
ATM Cell Packing debugging is on

00:12:33: ATM Cell Packing: vp 1 remote mncp 22 validated
The output indicates that the router received the MNCP information from the remote PE router.

atm mcpt-timers Creates cell-packing timers that specify how long the PE router can wait for
cells to be packed into an MPLS or L2TPv3 packet.
cell-packing Enables the packing of multiple ATM cells into a single MPLS or L2TPv3
packet.
show atm cell-packing Displays information about the VCs and VPs that have ATM cell relay over
MPLS or L2TPv3 cell packing enabled.

DB-130 May 2008
Debug Commands
debug atm events
debug atm events

To display ATM events, use the debug atm events command in privileged EXEC mode. To disable event
debug atm events
no debug atm events
Defaults ATM event debugging is disabled.

12.1(3)XJ This command was introduced on the Cisco 1700 series routers.
12.1(5)XR1 This command was implemented on the Cisco IAD2420 Series.
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 the debug atm events
command. 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.
Examples The following is sample output from the debug atm events command:
Router# debug atm events
RESET(ATM4/0): PLIM type is 1, Rate is 100Mbps

aip_disable(ATM4/0): state=1
config(ATM4/0)
aip_love_note(ATM4/0): asr=0x201
aip_enable(ATM4/0)
aip_enable(ATM4/0): restarting VCs: 7
aip_setup_vc(ATM4/0): vc:1 vpi:1 vci:1

May 2008 DB-131
Debug Commands
debug atm events
Table 26 debug atm events Field Descriptions
Field Description
PLIM type Indicates the interface rate in megabits per second (Mbps). Possible
values are:
1 = TAXI(4B5B) 100 Mbps
2 = SONET 155 Mbps
3 = E3 34 Mbps
state Indicates current state of the ATM Interface Processor (AIP). Possible
values are:
1 = An ENABLE will be issued soon.
0 = The AIP will remain shut down.
asr Defines a bitmask, which indicates actions or completions to
commands. Valid bitmask values are:
0x0800 = AIP crashed, reload may be required.
0x0400 = AIP detected a carrier state change.
0x0n00 = Command completion status. Command completion
status codes are:
n = 8 Invalid Physical Layer Interface Module (PLIM)
detected
n = 4 Command failed
n = 2 Command completed successfully
n = 1 CONFIG request failed
n = 0 Invalid value
The following line indicates that the 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 100Mbps
The following line indicates that the AIP was given a shutdown command, but the current configuration
indicates that the AIP should be up:
aip_disable(ATM4/0): state=1

DB-132 May 2008
Debug Commands
debug atm events
The following line indicates that a configuration command has been completed by the AIP:
The 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.
The following line of output indicates that the AIP enable function is restarting all permanent virtual
circuits (PVCs) automatically:
aip_enable(ATM4/0): restarting VCs: 7
The following lines of output indicate that PVC 1 was set up and a successful completion code was
returned:

May 2008 DB-133
Debug Commands
debug atm ha-error
debug atm ha-error

To debug ATM) high-availability (HA errors on a networking device, use the debug atm ha-error
command in privileged EXEC mode. To disable the display of debugging output, use the no form of this
command.
debug atm ha-error
no debug atm ha-error
Defaults Disabled

12.0(22)S This command was introduced on Cisco 7500, 10000, and 12000 series
Internet routers.
12.2(18)S This command was integrated into Cisco IOS Release 12.2(18)S on
Cisco 7500 series routers.
12.2(20)S Support was added for the Cisco 7304 router. The Cisco 7500 series router
is not supported in Cisco IOS Release 12.2(20)S.
Examples The following example displays debug messages regarding ATM HA errors on the networking device:
Router# debug atm ha-error

debug atm ha-events Debugs ATM HA events on the networking device.
debug atm ha-state Debugs ATM HA state information on the networking device.

DB-134 May 2008
Debug Commands
debug atm ha-events
debug atm ha-events

To debug ATM high-availability (HA) events on the networking device, use the debug atm ha-events
command in privileged EXEC mode. To disable the display of debugging output, use the no form of this
command.
debug atm ha-events
no debug atm ha-events
Defaults Disabled.

Internet routers.
Examples The following example displays debug messages regarding ATM HA events on the networking device:
Router# debug atm ha-events

debug atm ha-error Debugs ATM HA errors on the networking device.
debug atm ha-state Debugs ATM HA state information on the networking device.

May 2008 DB-135
Debug Commands
debug atm ha-state
debug atm ha-state

To debug ATM high-availability (HA) state information on the networking device, use the debug atm
ha-state command in privileged EXEC mode. To disable the display of debugging output, use the no
debug atm ha-state
no debug atm ha-state

Internet routers.
Examples The following example displays debug messages regarding the ATM HA state on the networking device:
Router# debug atm ha-state

debug atm ha-error Debugs ATM HA errors on the networking device.
debug atm ha-events Debugs ATM HA events on the networking device.

DB-136 May 2008
Debug Commands
debug atm l2transport

To enable the display of debugging information related to ATM over MPLS, use the debug atm
l2transport command in privileged EXEC mode. To disable the display of debugging information, use
no debug atm l2transport
Defaults Debugging of ATM over MPLS is not enabled.

Examples The following example shows the events and messages when configuring ATM Cell Relay over MPLS
in VP mode.
Router# debug atm l2transport
ATM L2transport Events and Errors debugging is on
Router# show debug
ATM L2transport:
ATM L2transport Events and Errors debugging is on
Router(config-if)# atm pvp 24 l2transport

Router(cfg-if-atm-l2trans-pvp)# xconnect 11.11.11.11 700 pw-class vp
Router(cfg-if-atm-l2trans-pvp)# end
00:14:51: ATM L2trans(ATM1/0): VP 24 is created

00:14:51: ATM L2trans(ATM1/0): ckt_type 10, ckt_id 1000024 UP
00:14:51: ATM L2trans(ATM1/0): VP 24, response is connect forwarded
The following example shows the events and messages when deleting a PVP.
Router(config-if)# no atm pvp 24 l2transport
00:14:37: ATM L2trans(ATM1/0): ckt_type 10, ckt_id 1000024 DOWN

May 2008 DB-137
Debug Commands

00:14:37: ATM L2trans(ATM1/0): remove xconnect circuit_type=10,
circuit_id=1000024

show mpls l2transport Displays information about AToM circuits that have been enabled to route
vc Layer 2 packets on a router.

DB-138 May 2008
Debug Commands
debug atm lfi
debug atm lfi

To display multilink PPP (MLP) over ATM link fragmentation and interleaving (LFI) debug information,
use the debug atm lfi command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug atm lfi
no debug atm lfi

Examples The following examples show output from the debug atm lfi command. Each example is preceded by an
explanation of the output.
The following output indicates that the packet has dequeued from the per-VC queue that is
associated with the virtual circuit (VC):
00:17:27: MLP-ATM(Virtual-Access3) pak dequeued from per VC Q 15/200,qcount:0
The following output indicates that the packet is enqueued on the per-VC queue associated with the
VC:
00:17:27: MLP-ATM(Virtual-Access3) pak enqueued to per VC Q 15/200, qcount:0
The following output indicates that the packet has dequeued from the MLP bundle queue:
00:17:27: MLP-ATM(Virtual-Access3) pak dequeued from MP Bundle 15/200, qcount:0
The following output indicates that PPP over ATM (PPPoA) encapsulation cannot be added to the
packet for some reason:
00:17:27: MLP-ATM(Virtual-Access3) encapsulation failure - dropping packet
The following output indicates that the VC could not be found on the virtual access interface
associated with the PPPoA session:
00:17:27: MLP-ATM(Virtual-Access3) No VC to transmit- dropping packet
When a permanent virtual circuit (PVC) has been deleted, the following output indicates that MLP
has been deconfigured successfully:
00:17:27: MLP-ATM(Virtual-Access3) mlp de-configured for PVC 15/200

May 2008 DB-139
Debug Commands
debug atm lfi
If the changing of any PVC parameters requires re-creation of the PVC, the following output is
generated during the re-creation of the PVC:
00:17:27: MLP-ATM(Virtual-Access3) MLPoATM re-configured for PVC 15/200
The following output indicates that the MLP over ATM structure associated with a VC has failed to
allocate memory:
00:17:27: MLP-ATM(Virtual-Access3) Memory allocation error
The following output is generated when MLP over ATM is first configured on a PVC:
00:17:27: MLP-ATM(Virtual-Access3) MLPoATM configured for PVC 15/200

show multilink ppp Displays bundle information for MLP bundles.

DB-140 May 2008
Debug Commands
debug atm native
debug atm native

To display ATM switched virtual circuit (SVC) signaling events, use the debug atm native command
debug atm native {[api] | [conn] | [error] | [filter]}
no debug atm native
Syntax Description api (Optional) Native ATM application programming interface (API). Displays
events that occur as a result of the exchange between the native ATM API
and the signaling API.
conn (Optional) Native ATM connection manager. Displays internal connection
manager events for the native ATM API.
error (Optional) Native ATM error. Displays errors that occur during the setup of
an ATM SVC.
filter (Optional) Native ATM filter. Displays the internal network service access
point (NSAP) filter events of the native ATM API.

Usage Guidelines Native ATM API is the layer above the signaling API. Static map and Resource Reservation Protocol
(RSVP) clients use the native ATM API to interact with the signaling API to create ATM SVCs.
Use the debug atm native command to diagnose problems in the creation of static map and RSVP ATM
SVCs.

May 2008 DB-141
Debug Commands
debug atm native
Examples The following is sample output for the debug atm native command with the api keyword:
Router# debug atm native api
0:24:59:NATIVE ATM :associate endpoint

00:24:59:NATIVE ATM :ID (3) prep outgoing call, conn_type 0
00:24:59:NATIVE ATM :ID (3) set connection attribute for 5
00:24:59:NATIVE ATM :ID (3) query connection attribute 8
00:24:59:NATIVE ATM :ID (3) connect outgoing call
00:24:59:NATIVE ATM :ID (3) callback, CONNECT received

DB-142 May 2008
Debug Commands
debug atm nbma
debug atm nbma

To display setup and teardown events for ATM switched virtual circuits (SVCs) configured using the
Resource Reservation Protocol (RSVP), use the debug atm nbma command in privileged EXEC mode.
To disable debugging output, use the no form of this command.
debug atm nbma [api]
no debug atm nbma
Syntax Description api (Optional) Nonbroadcast multiaccess (NBMA) ATM application

programming interface (API). Displays events that occur as a result of the
exchange between RSVP and the NBMA API.

Usage Guidelines Use the debug atm nbma command to diagnose problems in the creation of RSVP SVCs.
The RSVP application creates SVCs by using the NBMA API. The debug atm nbma command with the
api keyword displays events that occur as a result of the exchange between RSVP and the NBMA API.
Examples The following is sample output for the debug atm nbma command:
Router# debug atm nbma api
00:52:50:NBMA-ATM-API - atm_setup_req
00:52:50:NBMA_ATM-API - nbma_atm_fill_blli
00:52:50:NBMA_ATM-API - nbma_atm_fill_bhli
00:52:50:NBMA_ATM-API - nbma_atm_callbackMsg - NATIVE_ATM_OUTGOING_CALL_ACTIVE
00:52:50:NBMA_ATM-API - rcv_outgoing_call_active
00:52:50:NBMA_ATM-API - nbma_svc_lookup

May 2008 DB-143
Debug Commands
debug atm oam cc
debug atm oam cc

To display ATM operation, administration, and maintenance (OAM) F5 continuity check (CC)
management activity, use the debug atm oam cc command in privileged EXEC mode. To disable
debug atm oam cc [interface atm number]
no debug atm oam cc [interface atm number]
Syntax Description interface atm number (Optional) Number of the ATM interface.
Command Default No default behavior or values

12.2(2)XB This command was introduced.
Examples The following sample output for the debug atm oam cc command records activity beginning with the
entry of the oam-pvc manage cc command and ending with the entry of the no oam-pvc manage cc
command. The ATM 0 interface is specified, and the both segment direction is specified. The output
shows an activation request sent and confirmed, a series of CC cells sent by the routers on each end of
the segment, and a deactivation request and confirmation.
Router# debug atm oam cc interface atm0
Generic ATM:
ATM OAM CC cells debugging is on
Router#
00:15:05: CC ACTIVATE MSG (ATM0) I:VCD#1 VC 1/40 OAM Cell Type:4 OAM
Type:8 OAM Func:1 Direction:3 CTag:5
00:15:05: CC ACTIVATE CONFIRM MSG (ATM0) O:VCD#1 VC 1/40 OAM Cell
Type:4 OAM Type:8 OAM Func:1 Direction:3 CTag:5
00:15:06: CC CELL (ATM0) O:VCD#1 VC 1/40 OAM Cell Type:4 OAM Type:1
00:15:07: CC CELL (ATM0) I:VCD#1 VC 1/40 OAM Cell Type:4 OAM Type:1 OAM Func:4
00:15:08: CC CELL (ATM0) O:VCD#1 VC 1/40 OAM Cell Type:4 OAM Type:1 OAM Func:4

DB-144 May 2008
Debug Commands
debug atm oam cc
00:15:19: CC DEACTIVATE MSG (ATM0) I:VCD#1 VC 1/40 OAM Cell Type:4 OAM
Type:8 OAM Func:1 Direction:3 CTag:6
00:15:19: CC DEACTIVATE CONFIRM MSG (ATM0) O:VCD#1 VC 1/40 OAM Cell
Type:4 OAM Type:8 OAM Func:1 Direction:3 CTag:6
Table 27 debug atm oam cc Field Descriptions
Field Description
00:15:05 Time stamp.
CC ACTIVATE MSG (ATM0) Message type and interface.
0 Source.
1 Sink.
VC 1/40 Virtual circuit identifier.
Direction:3 Direction in which the cells are traveling. May be one of the
following values:
1 local router is the sink.
2 local router is the source.
3 both routers operate as the source and sink.

oam-pvc manage cc Configures ATM OAM F5 CC management.
show atm pvc Displays all ATM PVCs and traffic information.

May 2008 DB-145
Debug Commands
debug atm oc3 pom
debug atm oc3 pom

To display debug messages for ATM-OC3 Provisioning Object Manager (POM) network modules, use
the debug atm oc3 pom command in privileged EXEC mode. To disable debugging output, use the no
debug atm oc3 pom {data | flow | pa | sar | sfp | trace}
no debug atm oc3 pom {data | flow | pa | sar | sfp | trace}
Syntax Description data Displays debug messages for incoming packet indications.
flow Displays debug messages for flow control indications.
pa Displays debug messages for online insertion or removal (OIR) of the
ATM-OC3 POM network module.
sar Displays debug messages for blocking commands sent to the segmentation
and reassembly (SAR) and their acknowledgments.
sfp Displays debug messages for OIR of modules in the SFP port of the network
module.
trace Displays debug messages that give the hexadecimal representation of
commands sent to the SAR and their acknowledgments.

Usage Guidelines debug atm oc3 pom data command

Use the debug atm oc3 pom data command to display the incoming packet indications. Each incoming
packet transferred by direct memory access (DMA) to the host memory by the SAR will cause a packet
indication.
debug atm oc3 pom flow command

Use the debug atm oc3 pom flow command to display flow control indications.
When traffic sent to the SAR exceeds the peak cell rate for a particular virtual circuit (VC), the SAR
indicates this to the host by sending flow control indications. These indications inform the host that
either the high watermark or the low watermark has been reached for that VC queue.
When a high watermark is received from the SAR, indicating that the VC queue is full, the host will stop
sending packets to the SAR until a low watermark indication is received. A low watermark indicates that
the VC queue has been drained sufficiently to receive additional packets.

DB-146 May 2008
Debug Commands
debug atm oc3 pom
debug atm oc3 pom pa command

Use the debug atm oc3 pom pa command on those platforms supporting OIR to display the indications
generated when the port adapter (the ATM-OC3 POM network module) is subjected to OIR. This
command is used principally during the port adapter initialization phase.
debug atm oc3 pom sar command

Use the debug atm oc3 pom sar command to display blocking commands or indications sent to or
received from the SAR. This includes commands or indications of the creation or deletion of virtual
circuits or virtual paths.
debug atm oc3 pom sfp command

Use the debug atm oc3 pom sfp command to display the indications generated when a module in the
SFP port is subjected to OIR.
debug atm oc3 pom trace command

Use the debug atm oc3 pom trace command to display the hexadecimal representation of commands
sent to or received from the SAR. To facilitate debugging, use this command in conjunction with the
debug atm oc3 pom sar command.
Examples Example for the debug atm oc3 pom data command
The following is sample output from the debug atm oc3 pom data command:
Router# debug atm oc3 pom data
DATA debugging is on
Router#
*Jun 27 22:03:17.996: Packet Indication:
*Jun 27 22:03:17.996: word 0: 0x00007D24
*Jun 27 22:03:17.996: word 1: 0x00002F02
*Jun 27 22:03:17.996: word 2: 0xEE323464
*Jun 27 22:03:17.996: word 3: 0x006C006D
Table 28 debug atm oc3 pom data Field Descriptions
Field Description
Jun 27 22:03:17.996: Date or time stamp of packet DMA transfer.
word [0 - 3]: 0xXXXXXXXX Hexadecimal representation of four-word acknowledgment
from the SAR when a packet is transferred by DMA to the
host memory by the SAR.
Example for the debug atm oc3 pom flow command

The following example illustrates the output from the debug atm oc3 pom flow command:
Router# debug atm oc3 pom flow
FLOW CNTL INDICATION debugging is on

Router#
*Jun 27 15:14:13.123: Flow Indication:
*Jun 27 15:14:13.123: word 0: 0x00000001
*Jun 27 15:14:13.123: word 1: 0x300012C0
*Jun 27 15:14:13.123: word 2: 0x18001060

May 2008 DB-147
Debug Commands
debug atm oc3 pom
*Jun 27 15:14:13.123: word 3: 0x00080021

*Jun 27 15:14:13.456: word 0: 0x00000001
*Jun 27 15:14:13.456: word 1: 0x300012C0
*Jun 27 15:14:13.456: word 2: 0x18001060
*Jun 27 15:14:13.456: word 3: 0x00090022
Table 29 debug atm oc3 pom flow Field Descriptions
Field Description
Jun 27 15:14:13.456: Date or time stamp of flow indication
word [0 - 3]: 0xXXXXXXXX Hexadecimal representation of four-word indication sent by
the SAR to the host that a high watermark or low watermark
event has occurred.
word 3: 0x00XXYYYY When XX is 08, a high watermark has been received by the
host. The host will stop queueing packets for the VC.
When XX is 09, a low watermark has been received by the
host. The host will resume sending packets to the VC.
YYYY is the running count of flow indication events sent to
the host.
Examples for the debug atm oc3 pom pa command

The following examples illustrate the output from the debug atm oc3 pom pa command.
The first example gives the output when the network module is removed:
Router# debug atm oc3 pom pa
PA debugging is on
*Jun 27 22:40:56.110: %OIR-6-REMCARD: Card removed from slot 2, interfaces disabled

*Jun 27 22:40:56.122: *** Freed 6146 buffers
The second example gives the output when the network module is inserted, and gives the values of
internal registers of the module:
*Jun 27 22:41:08.654: %OIR-6-INSCARD: Card inserted in slot 2, interfaces administratively
shut down
*Jun 27 22:41:11.402: sar_base_addr 0x5C800000
*Jun 27 22:41:11.402: PCI_MEMBAR2_REG after configuring:0x5E000008
*Jun 27 22:41:11.402: PCI_MEMBAR3_REG after configuring:0x5F000000
*Jun 27 22:41:11.402: PCI_COMMAND_REG: Offset= 0x4; value= 0x2A00006
*Jun 27 22:41:11.402: FPGA Base address is 0x5C900000
*Jun 27 22:41:11.402: FPGA PCI config Reg is 0x02200002
Examples for the debug atm oc3 pom sar command

The following examples illustrate the output from the debug atm oc3 pom sar command.
The first example displays command indications for setting up a VC and opening the reassembly channel
and the segmentation channel in the SAR:
Router# debug atm oc3 pom sar

DB-148 May 2008
Debug Commands
debug atm oc3 pom
SAR debugging is on
Router# configure terminal
Router(config)# interface atm 2/0
Router(config-if)# pvc 2/2
Router(config-if-atm-vc)# exit
Router(config-if)#
*Jun 27 22:12:28.816: ATM2/0: Setup_VC: vc:3 vpi:2 vci:2
*Jun 27 22:12:28.816: ATM2/0: Open_Channel(RSY): CH (1), VPI (2), VCI (2)
*Jun 27 22:12:28.816: ATM2/0: HI/LO watermarks: 526/263; PeakRate: 149760
*Jun 27 22:12:28.816: ATM2/0: Open_Channel(SEG): CH (1), VPI (2), VCI (2)
*Jun 27 22:12:28.820: ATM2/0: Setup_Cos: vc:3 wred_name:- max_q:0
The second example displays the commands sent to the SAR and the acknowledgements returned when
the VC is deleted and the segmentation and reassembly channels are closed:
Router(config-if)# no pvc 2/2
Router(config-if)#
*Jun 27 22:12:59.016: ATM2/0: Sent pending EOP successfully
*Jun 27 22:12:59.016: ATM2/0: Close_Channel(RSY): Chan_ID (0x104)
*Jun 27 22:12:59.016: ATM2/0: Close_Channel(RSY): Chan_ID (0x104) CLOSE
*Jun 27 22:12:59.016: ATM2/0: Close_Channel: CLOSE_PENDING
*Jun 27 22:12:59.016: ATM2/0: Close_Channel(SEG): Chan_ID (0x105)
*Jun 27 22:12:59.016: ATM2/0: Close_Channel: CLOSE
Examples for the debug atm oc3 pom sfp command

The following examples illustrate the output from the debug atm oc3 pom sfp command.
The first example gives the output when the module is removed from the SFP port:
Router# debug atm oc3 pom sfp
SFP debugging is on
*Jun 27 22:27:40.792: SFP TX FAULT detected

*Jun 27 22:27:40.808: SFP LOS detected
*Jun 27 22:27:40.812: SFP removal detected
*Jun 27 22:27:41.464: NM-1A-OC3-POM: SFP 2/0 - Removed unique
*Jun 27 22:27:43.464: %LINK-3-UPDOWN: Interface ATM2/0, changed state to down
*Jun 27 22:27:44.464: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM2/0, changed
state to down
The second example gives the output when the module is inserted in the SFP port.
*Jun 27 22:27:47.776: SFP LOS cleared

*Jun 27 22:27:47.776: SFP TX FAULT detected
*Jun 27 22:27:48.276: SFP present detected
*Jun 27 22:27:48.276: SFP TX FAULT cleared
*Jun 27 22:27:48.496: Set the Container_id to 17
*Jun 27 22:27:50.496: %LINK-3-UPDOWN: Interface ATM2/0, changed state to up
*Jun 27 22:27:51.496: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM2/0, changed
state to up
Examples for the debug atm oc3 pom trace command

The first example illustrates the output from the debug atm oc3 pom trace command when it is run
without the debug atm oc3 sar command being activated:
Router# debug atm oc3 pom trace
SAR CMD/ACK debugging is on
router(config-if)# pvc 2/2

May 2008 DB-149
Debug Commands
debug atm oc3 pom
Router(config-if)#
*Jun 27 22:15:09.284: Command Sent:
*Jun 27 22:15:09.284: word 0: 0x00000480
*Jun 27 22:15:09.284: word 1: 0x00012010
*Jun 27 22:15:09.284: word 2: 0x00000000
*Jun 27 22:15:09.284: word 3: 0x00000000
*Jun 27 22:15:09.284: word 4: 0x00200020
*Jun 27 22:15:09.284: word 5: 0x00000000
*Jun 27 22:15:09.284: word 6: 0x00000000
*Jun 27 22:15:09.284: word 7: 0x00000000
*Jun 27 22:15:09.284: word 8: 0x00000000
*Jun 27 22:15:09.284: Command Indication:
*Jun 27 22:15:09.284: word 0: 0x00000000
*Jun 27 22:15:09.284: word 1: 0x01042110
*Jun 27 22:15:09.284: word 2: 0x01050000
*Jun 27 22:15:09.284: word 3: 0x0000003B
*Jun 27 22:15:09.284: ACK received = 200 usecs
*Jun 27 22:15:09.284: word 0: 0x01050480
*Jun 27 22:15:09.284: word 1: 0x00011010
*Jun 27 22:15:09.284: word 2: 0x02000000
*Jun 27 22:15:09.284: word 3: 0x00010003
*Jun 27 22:15:09.284: word 4: 0x00200020
*Jun 27 22:15:09.284: word 5: 0x64B30000
*Jun 27 22:15:09.284: word 6: 0x10C00000
*Jun 27 22:15:09.284: word 7: 0x86850000
*Jun 27 22:15:09.284: word 8: 0x00010040
*Jun 27 22:15:09.284: word 9: 0x00000000
*Jun 27 22:15:09.284: word 0: 0x00010000
*Jun 27 22:15:09.284: word 1: 0x00011110
*Jun 27 22:15:09.284: word 2: 0x02000000
*Jun 27 22:15:09.284: word 3: 0x0001003D
Table 30 debug atm oc3 pom trace Field Descriptions
Field Description
Jun 27 22:15:09.284: Date or time stamp for the command dialog.
word [0 - n]: 0xXXXXXXXX Hexadecimal representation of the n-word command sent to
the SAR (under Command Sent:) and the four-word
acknowledgment returned by the SAR (under Command
Indication:).
ACK received Time (in microseconds) between sending the command to the
SAR and receiving the acknowledgment.
The second example illustrates the output from the debug atm oc3 pom trace command run in
conjunction with the debug atm oc3 pom sar command.
In this example, each command sent to the SAR is displayed by the debug atm oc3 pom sar command.
Then the hexadecimal representation of the command and its acknowledgement are displayed by the
debug atm oc3 pom trace command.
Router# debug atm oc3 pom trace

DB-150 May 2008
Debug Commands
debug atm oc3 pom
Router# debug atm oc3 pom sar

SAR debugging is on
Router(config-if)#
*Jun 27 22:15:09.284: word 0: 0x00000480
*Jun 27 22:15:09.284: word 1: 0x00012010
*Jun 27 22:15:09.284: word 2: 0x00000000
*Jun 27 22:15:09.284: word 3: 0x00000000
*Jun 27 22:15:09.284: word 4: 0x00200020
*Jun 27 22:15:09.284: word 5: 0x00000000
*Jun 27 22:15:09.284: word 6: 0x00000000
*Jun 27 22:15:09.284: word 7: 0x00000000
*Jun 27 22:15:09.284: word 8: 0x00000000
*Jun 27 22:15:09.284: word 0: 0x00000000
*Jun 27 22:15:09.284: word 1: 0x01042110
*Jun 27 22:15:09.284: word 2: 0x01050000
*Jun 27 22:15:09.284: word 3: 0x0000003B
*Jun 27 22:15:09.284: word 0: 0x01050480
*Jun 27 22:15:09.284: word 1: 0x00011010
*Jun 27 22:15:09.284: word 2: 0x02000000
*Jun 27 22:15:09.284: word 3: 0x00010003
*Jun 27 22:15:09.284: word 4: 0x00200020
*Jun 27 22:15:09.284: word 5: 0x64B30000
*Jun 27 22:15:09.284: word 6: 0x10C00000
*Jun 27 22:15:09.284: word 7: 0x86850000
*Jun 27 22:15:09.284: word 8: 0x00010040
*Jun 27 22:15:09.284: word 9: 0x00000000
*Jun 27 22:15:09.284: word 0: 0x00010000
*Jun 27 22:15:09.284: word 1: 0x00011110
*Jun 27 22:15:09.284: word 2: 0x02000000
*Jun 27 22:15:09.284: word 3: 0x0001003D

May 2008 DB-151
Debug Commands
debug atm t3e3
debug atm t3e3

To display debug messages for ATM T3/E3 network modules, use the debug atm t3e3 command in
debug atm t3e3 {data | flow | pa | sar | trace}
no debug atm t3e3 {data | flow | pa | sar | trace}
Syntax Description data Displays debug messages for incoming packet indications.
flow Displays debug messages for flow control indications.
pa Displays debug messages for online insertion or removal (OIR) of the ATM
T3/E3 network module.
sar Displays debug messages for blocking commands sent to the segmentation
and reassembly (SAR) and their acknowledgments.
trace Displays debug messages that give the hexadecimal representation of
commands sent to the SAR and their acknowledgments.

Usage Guidelines debug atm t3e3 data command

Use the debug atm t3e3 data command to display the incoming packet indications. Each incoming
packet transferred by direct memory access (DMA) to the host memory by the SAR will cause a packet
indication.
debug atm t3e3 flow command

Use the debug atm t3e3 flow command to display flow control indications.
When traffic sent to the SAR exceeds the peak cell rate for a particular virtual circuit (VC), the SAR
indicates this to the host by sending flow control indications. These indications inform the host that
either the high watermark or the low watermark has been reached for that VC queue.
When a high watermark is received from the SAR, indicating that the VC queue is full, the host will stop
sending packets to the SAR until a low watermark indication is received. A low watermark indicates that
the VC queue has been drained sufficiently to receive additional packets.

DB-152 May 2008
Debug Commands
debug atm t3e3
debug atm t3e3 pa command

Use the debug atm t3e3 pa command on those platforms supporting OIR to display the indications
generated when the port adapter (the ATM T3/E3 network module) is subjected to OIR. This command
is used principally during the port adapter initialization phase.
debug atm t3e3 sar command

Use the debug atm t3e3 sar command to display blocking commands or indications sent to or received
from the SAR. This includes commands or indications of the creation or deletion of virtual circuits or
virtual paths.
debug atm t3e3 trace command

Use the debug atm t3e3 trace command to display the hexadecimal representation of commands sent
to or received from the SAR. To facilitate debugging, use this command in conjunction with the debug
atm t3e3 sar command.
Examples Example for the debug atm t3e3 data command

The following is sample output from the debug atm t3e3 data command:
Router# debug atm t3e3 data
DATA debugging is on
Router#
*Jun 27 22:03:17.996: Packet Indication:
*Jun 27 22:03:17.996: word 0: 0x00007D24
*Jun 27 22:03:17.996: word 1: 0x00002F02
*Jun 27 22:03:17.996: word 2: 0xEE323464
*Jun 27 22:03:17.996: word 3: 0x006C006D
Table 31 debug atm t3e3 data Field Descriptions
Field Description
Jun 27 22:03:17.996: Date or time stamp of packet DMA transfer.
word [0 - 3]: 0xXXXXXXXX Hexadecimal representation of four-word acknowledgment
from the SAR when a packet is transferred by DMA to the
host memory by the SAR.
Example for the debug atm t3e3 flow command

The following example illustrates the output from the debug atm t3e3 flow command:
Router# debug atm t3e3 flow
FLOW CNTL INDICATION debugging is on

Router#
*Jun 27 15:14:13.123: word 0: 0x00000001
*Jun 27 15:14:13.123: word 1: 0x300012C0
*Jun 27 15:14:13.123: word 2: 0x18001060
*Jun 27 15:14:13.123: word 3: 0x00080021

*Jun 27 15:14:13.456: word 0: 0x00000001
*Jun 27 15:14:13.456: word 1: 0x300012C0

May 2008 DB-153
Debug Commands
debug atm t3e3
*Jun 27 15:14:13.456: word 2: 0x18001060

*Jun 27 15:14:13.456: word 3: 0x00090022
Table 32 debug atm t3e3 flow Field Descriptions
Field Description
Jun 27 15:14:13.456: Date or time stamp of flow indication
word [0 - 3]: 0xXXXXXXXX Hexadecimal representation of four-word indication sent by
the SAR to the host that a high watermark or low watermark
event has occurred.
word 3: 0x00XXYYYY When XX is 08, a high watermark has been received by the
host. The host will stop queueing packets for the VC.
When XX is 09, a low watermark has been received by the
host. The host will resume sending packets to the VC.
YYYY is the running count of flow indication events sent to
the host.
Examples for the debug atm t3e3 pa command

The following examples illustrate the output from the debug atm t3e3 pa command.
The first example gives the output when the network module is removed:
Router# debug atm t3e3 pa
PA debugging is on
*Jun 27 22:40:56.110: %OIR-6-REMCARD: Card removed from slot 2, interfaces disabled

*Jun 27 22:40:56.122: *** Freed 6146 buffers
The second example gives the output when the network module is inserted, and gives the values of
internal registers of the module:
*Jun 27 22:41:08.654: %OIR-6-INSCARD: Card inserted in slot 2, interfaces administratively
shut down
*Jun 27 22:41:11.402: sar_base_addr 0x5C800000
*Jun 27 22:41:11.402: PCI_MEMBAR2_REG after configuring:0x5E000008
*Jun 27 22:41:11.402: PCI_MEMBAR3_REG after configuring:0x5F000000
*Jun 27 22:41:11.402: PCI_COMMAND_REG: Offset= 0x4; value= 0x2A00006
*Jun 27 22:41:11.402: FPGA Base address is 0x5C900000
*Jun 27 22:41:11.402: FPGA PCI config Reg is 0x02200002
Examples for the debug atm t3e3 sar command

The following examples illustrate the output from the debug atm t3e3 sar command.
The first example displays command indications for setting up a VC and opening the reassembly channel
and the segmentation channel in the SAR:
Router# debug atm t3e3 sar
SAR debugging is on

DB-154 May 2008
Debug Commands
debug atm t3e3
Router(config-if)#
The second example displays the commands sent to the SAR and the acknowledgements returned when
the VC is deleted and the segmentation and reassembly channels are closed:
Router(config-if)# no pvc 2/2
Router(config-if)#
*Jun 27 22:12:59.016: ATM2/0: Sent pending EOP successfully
*Jun 27 22:12:59.016: ATM2/0: Close_Channel(RSY): Chan_ID (0x104)
*Jun 27 22:12:59.016: ATM2/0: Close_Channel(RSY): Chan_ID (0x104) CLOSE
*Jun 27 22:12:59.016: ATM2/0: Close_Channel: CLOSE_PENDING
*Jun 27 22:12:59.016: ATM2/0: Close_Channel(SEG): Chan_ID (0x105)
*Jun 27 22:12:59.016: ATM2/0: Close_Channel: CLOSE
Examples for the debug atm t3e3 trace command

The first example illustrates the output from the debug atm t3e3 trace command when it is run without
the debug atm t3e3 sar command being activated:
Router# debug atm t3e3 trace
Router(config-if)#
*Jun 27 22:15:09.284: word 0: 0x00000480
*Jun 27 22:15:09.284: word 1: 0x00012010
*Jun 27 22:15:09.284: word 2: 0x00000000
*Jun 27 22:15:09.284: word 3: 0x00000000
*Jun 27 22:15:09.284: word 4: 0x00200020
*Jun 27 22:15:09.284: word 5: 0x00000000
*Jun 27 22:15:09.284: word 6: 0x00000000
*Jun 27 22:15:09.284: word 7: 0x00000000
*Jun 27 22:15:09.284: word 8: 0x00000000
*Jun 27 22:15:09.284: word 0: 0x00000000
*Jun 27 22:15:09.284: word 1: 0x01042110
*Jun 27 22:15:09.284: word 2: 0x01050000
*Jun 27 22:15:09.284: word 3: 0x0000003B
*Jun 27 22:15:09.284: word 0: 0x01050480
*Jun 27 22:15:09.284: word 1: 0x00011010
*Jun 27 22:15:09.284: word 2: 0x02000000
*Jun 27 22:15:09.284: word 3: 0x00010003
*Jun 27 22:15:09.284: word 4: 0x00200020
*Jun 27 22:15:09.284: word 5: 0x64B30000
*Jun 27 22:15:09.284: word 6: 0x10C00000
*Jun 27 22:15:09.284: word 7: 0x86850000
*Jun 27 22:15:09.284: word 8: 0x00010040
*Jun 27 22:15:09.284: word 9: 0x00000000
*Jun 27 22:15:09.284: word 0: 0x00010000
*Jun 27 22:15:09.284: word 1: 0x00011110
*Jun 27 22:15:09.284: word 2: 0x02000000
*Jun 27 22:15:09.284: word 3: 0x0001003D

May 2008 DB-155
Debug Commands
debug atm t3e3
Table 33 debug atm t3e3 trace Field Descriptions
Field Description
Jun 27 22:15:09.284: Date or time stamp for the command dialog.
word [0 - n]: 0xXXXXXXXX Hexadecimal representation of the n-word command sent to
the SAR (under Command Sent:) and the four-word
acknowledgment returned by the SAR (under Command
Indication:).
ACK received Time (in microseconds) between sending the command to the
SAR and receiving the acknowledgment.
The second example illustrates the output from the debug atm t3e3 trace command run in conjunction
with the debug atm t3e3 sar command.
In this example, each command sent to the SAR is displayed by the debug atm t3e3 sar command. Then
the hexadecimal representation of the command and its acknowledgement are displayed by the debug
atm t3e3 trace command.
Router# debug atm t3e3 trace

Router# debug atm t3e3 sar
SAR debugging is on
Router(config-if)#
*Jun 27 22:15:09.284: word 0: 0x00000480
*Jun 27 22:15:09.284: word 1: 0x00012010
*Jun 27 22:15:09.284: word 2: 0x00000000
*Jun 27 22:15:09.284: word 3: 0x00000000
*Jun 27 22:15:09.284: word 4: 0x00200020
*Jun 27 22:15:09.284: word 5: 0x00000000
*Jun 27 22:15:09.284: word 6: 0x00000000
*Jun 27 22:15:09.284: word 7: 0x00000000
*Jun 27 22:15:09.284: word 8: 0x00000000
*Jun 27 22:15:09.284: word 0: 0x00000000
*Jun 27 22:15:09.284: word 1: 0x01042110
*Jun 27 22:15:09.284: word 2: 0x01050000
*Jun 27 22:15:09.284: word 3: 0x0000003B
*Jun 27 22:15:09.284: word 0: 0x01050480
*Jun 27 22:15:09.284: word 1: 0x00011010
*Jun 27 22:15:09.284: word 2: 0x02000000
*Jun 27 22:15:09.284: word 3: 0x00010003
*Jun 27 22:15:09.284: word 4: 0x00200020
*Jun 27 22:15:09.284: word 5: 0x64B30000
*Jun 27 22:15:09.284: word 6: 0x10C00000
*Jun 27 22:15:09.284: word 7: 0x86850000

DB-156 May 2008
Debug Commands
debug atm t3e3
*Jun 27 22:15:09.284: word 8: 0x00010040

*Jun 27 22:15:09.284: word 9: 0x00000000
*Jun 27 22:15:09.284: word 0: 0x00010000
*Jun 27 22:15:09.284: word 1: 0x00011110
*Jun 27 22:15:09.284: word 2: 0x02000000
*Jun 27 22:15:09.284: word 3: 0x0001003D

May 2008 DB-157
Debug Commands
debug audit
debug audit
To display debug messages for the audit subsystem, use the debug audit command in privileged EXEC
mode. To disable debugging for the audit subsystem, use the no form of this command.
debug audit
no debug audit

12.0(27)S This feature was integrated into Cisco IOS Release 12.0(27)S.
12.2(27)SBC This command was integrated into Cisco IOS Release 12.2(27)SBC.
Usage Guidelines Audit files allow you to track changes that have been made to your router. Each change is logged as a
syslog message, and all syslog messages are kept in the audit file, which is kept in the audit subsystem.
Examples The following example is sample output from the debug audit command:
Router# debug audit
*Sep 14 18:37:31.535:disk0:/forensics.log -> File not found
*Sep 14 18:37:31.535:%AUDIT-1-RUN_VERSION:Hash:
24D98B13B87D106E7E6A7E5D1B3CE0AD User:
*Sep 14 18:37:31.583:%AUDIT-1-RUN_CONFIG:Hash:
4AC2D776AA6FCA8FD7653CEB8969B695 User:
*Sep 14 18:37:31.587:Audit:Trying to hash nvram:startup-config
*Sep 14 18:37:31.587:Audit:nvram:startup-config Done.
*Sep 14 18:37:31.587:Audit:Trying to hash nvram:private-config
*Sep 14 18:37:31.591:Audit:nvram:private-config Done.
*Sep 14 18:37:31.591:Audit:Trying to hash nvram:underlying-config
*Sep 14 18:37:31.591:Audit:nvram:underlying-config Done.
*Sep 14 18:37:31.591:Audit:Trying to hash nvram:persistent-data
*Sep 14 18:37:31.591:Audit:nvram:persistent-data Done.
*Sep 14 18:37:31.595:Audit:Trying to hash nvram:ifIndex-table
*Sep 14 18:37:31.595:Audit:Skipping nvram:ifIndex-table
*Sep 14 18:37:31.595:%AUDIT-1-STARTUP_CONFIG:Hash:
95DD497B1BB61AB33A629124CBFEC0FC User:
*Sep 14 18:37:31.595:Audit:Trying to hash filesystem disk0:

DB-158 May 2008
Debug Commands
debug audit
*Sep 14 18:37:31.775:Audit:Trying to hash attributes of

disk0:c7200-p-mz.120-23.S
*Sep 14 18:37:32.103:Audit:disk0:c7200-p-mz.120-23.S DONE
*Sep 14 18:37:32.103:Audit:disk0:DONE
*Sep 14 18:37:32.103:Audit:Trying to hash filesystem bootflash:
bootflash:c7200-kboot-mz.121-8a.E
*Sep 14 18:37:32.107:Audit:bootflash:c7200-kboot-mz.121-8a.E DONE
bootflash:crashinfo_20030115-182547
*Sep 14 18:37:32.107:Audit:bootflash:crashinfo_20030115-182547 DONE
*Sep 14 18:37:32.107:Audit:bootflash:DONE
*Sep 14 18:37:32.107:%AUDIT-1-FILESYSTEM:Hash:
330E7111F2B526F0B850C24ED5774EDE User:
*Sep 14 18:37:32.107:Audit:Hashing entitymib entry for 7206VXR chassis,
Hw Serial#:28710795, Hw Revision:A
*Sep 14 18:37:32.107:Audit:Hashing entitymib entry for NPE 400 Card, Hw
Serial#:28710795, Hw Revision:A
*Sep 14 18:37:32.107:Audit:Hashing entitymib entry for Chassis Slot
*Sep 14 18:37:32.107:Audit:Hashing entitymib entry for I/O Dual
FastEthernet Controller
*Sep 14 18:37:32.107:Audit:Hashing entitymib entry for i82543
(Livengood)
*Sep 14 18:37:32.107:Audit:Hashing entitymib entry for i82543
(Livengood)
*Sep 14 18:37:32.107:%AUDIT-1-HARDWARE_CONFIG:Hash:
32F66463DDA802CC9171AF6386663D20 User:

audit filesize Changes the size of the audit file.
audit interval Changes the time interval that is used for calculating hashes.

May 2008 DB-159
Debug Commands
debug autoupgrade
debug autoupgrade
To display the debug output of the Cisco IOS Auto-Upgrade Manager (AUM), use the debug
autoupgrade command in privileged EXEC mode. To disable debug output, use the no form of this
command.
debug autoupgrade
no debug autoupgrade
Command Default The debug output is disabled.

Usage Guidelines Use the debug autoupgrade command when you encounter a problem with AUM and provide the output
to TAC. Run the debug autoupgrade command and then run AUM to view the debug messages.
Examples The following example shows how to enable the debugging of Cisco IOS Auto-Upgrade Manager:
Router# debug autoupgrade
Auto Upgrade Manager debugging ON
Router#
Router# upgrade automatic getversion tftp://10.1.0.1/username/aaa
Image not found.
Router#
Jun 14 14:23:08.251 IST: AUM: Currently running software:
flash:c3825-adventerprisek9-mz.CALVIN_AUM_EFT1
Jun 14 14:23:08.251 IST: AUM: Reload type:2 hour:0 min:0
Jun 14 14:23:08.251 IST: AUM: Disk management: 1

Jun 14 14:23:08.251 IST: AUM: Get image tftp://10.1.0.1/username/aaa from local server and
upgrade:
Jun 14 14:23:08.251 IST: AUM: Extracted image name: aaa
Jun 14 14:23:08.339 IST: AUM: get image info: failed to open url
Jun 14 14:23:08.339 IST: AUM: get image info: image size unknown

DB-160 May 2008
Debug Commands
debug autoupgrade

upgrade automatic Downloads a Cisco IOS software image directly from www.cisco.com or
getversion from a non-Cisco server.

May 2008 DB-161
Debug Commands
debug auto-config
debug auto-config
To enable debugging for autoconfiguration applications, use the debug auto-config command in
debug auto-config {all | errors | events | parser}
no debug auto-config {all | errors | events | parser}
Syntax Description all Displays all autoconfiguration debug trace.

errors Displays autoconfiguration errors.
events Displays autoconfiguration events.
parser Displays autoconfiguration parser.

12.3(8)XY This command was introduced on the Communication Media Module.
12.4(3) This command was integrated into Cisco IOS Release 12.4(3).
Examples The following example shows the debug auto-config command used to enable debugging for
autoconfiguration applications and to display autoconfiguration events:
Router# debug auto-config events
.
.
.
Feb 8 02:17:31.119: dnld_app_check_state(0x628C8164)...
Feb 8 02:17:31.123: dnld_chk_app_handle(0x628C8164)
Feb 8 02:17:31.123: dnld_app_check_state: appl = 0x628C8164, state = 0x11
.
.
.

DB-162 May 2008
Debug Commands
debug auto-config
Table 34 describes significant fields shown in the display.
Table 34 debug auto-config Field Descriptions
Field Description
0x628C8164 Identifies the application handle, an auto-generated number for
debugging.
0x11 Displays the state of the application. State values are as follows:
0x11Registered and enabled.
0x1Download application enabled.
0x10Download application registered.

auto-config Enables autoconfiguration or enters auto-config application configuration
mode for the SCCP application.
debug sccp config Enables SCCP event debugging.
show auto-config Displays the current status of autoconfiguration applications.

May 2008 DB-163
Debug Commands
debug backhaul-session-manager session

To debug all the available sessions or a specified session, use the debug backhaul-session-manager
session command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug backhaul-session-manager session {state | xport} {all | session-id}
no debug backhaul-session-manager session {state | xport} {all | session-id}
Caution Use caution when enabling this debug command in a live system. It produces significant amounts of
output, which could lead to a disruption of service.
Syntax Description state Shows information about state transitions. Possible states are as follows:
SESS_SET_IDLE: A session-set has been created.
SESS_SET_OOS: A session(s) has been added to session-group(s). No
ACTIVE notification has been received from Virtual Switch Controller (VSC).
SESS_SET_ACTIVE_IS: An ACTIVE notification has been received over one
in-service session-group. STANDBY notification has not been received on any
available session-group(s).
SESS_SET_STNDBY_IS: A STANDBY notification is received, but there is no
in-service active session-group available.
SESS_SET_FULL_IS: A session-group in-service that has ACTIVE
notification and at least one session-group in-service that has STANDBY
notification.
SESS_SET_SWITCH_OVER: An ACTIVE notification is received on
session-group in-service, which had received STANDBY notification.
xport Provides traces for all packets (protocol data units (PDUs)), application PDUs,
and also session-manager messages.
all All available sessions.
session-id A specified session.
Defaults Debugging for backhaul-session-manager session is not enabled.

DB-164 May 2008
Debug Commands

12.2(2)T Support for this command was introduced on the Cisco 7200 series
routers.
12.2(4)T This command was implemented on the Cisco 2600 series,
Cisco 3600 series, and Cisco MC3810.
12.2(2)XB This command was implemented on the Cisco AS5350 and
Cisco AS5400.
12.2(2)XB1 This command was implemented on the Cisco AS5850 platform.
12.2(8)T This command was implemented on Cisco IAD2420 series
integrated access devices (IADs). This command is not supported on
the access servers in this release.
12.2(11)T This command was implemented on Cisco AS5350, Cisco AS5400,
and Cisco AS5850 platforms.
Examples The following is output for the debug backhaul-session-manager session all command:
Router# debug backhaul-session-manager session all
Router# debug_bsm_command:DEBUG_BSM_SESSION_ALL
23:49:14:SESSION:XPORT:sig rcvd. session = 34, connid = 0x80BA12FC, sig = 5 (CONN-RESET)
23:49:14:SESSION:STATE:(34) old-state:OPEN_WAIT, new-state:CLOSE

23:49:14:SESSION:STATE:(34) state:OPEN_WAIT, use-state:OOS
23:49:14:SESSION:STATE:(34) old-state:OPEN_WAIT, new-state:OPEN_WAIT







May 2008 DB-165
Debug Commands


23:49:34:SESSION:XPORT:sig rcvd. session = 33, connid = 0x80BA14EC, sig = 1 (CONN-FAILED)
23:49:34:SESSION:STATE:(33) old-state:OPEN, new-state:CLOSE_WAIT
The following example displays output for the debug backhaul-session-manager session state all
command:
Router# debug backhaul-session-manager session state all
Router# debug_bsm_command:DEBUG_BSM_SESSION_STATE_ALL


The following example displays output for the debug backhaul-session-manager session xport all
command:
Router# debug backhaul-session-manager session xport all
Router# debug_bsm_command:DEBUG_BSM_SESSION_XPORT
23:51:42:SESSION:XPORT:sig rcvd. session = 33, connid = 0x80BA14EC, sig = 5 (CONN-RESET)

debug backhaul-session-manager set Traces state changes and receives messages and events
for all available session-sets or a specified session-set.

DB-166 May 2008
Debug Commands
debug backhaul-session-manager set

To trace state changes and receive messages and events for all the available session sets or a specified
session set, use the debug backhaul-session-manager set command in privileged EXEC mode. To
debug backhaul-session-manager set {all | name set-name}
no debug backhaul-session-manager set {all | name set-name}
Syntax Description all All available session sets.

name set-name A specified session set.
Defaults Debugging for backhaul session sets is not enabled.

12.2(2)T Support for this command was introduced on the Cisco 7200 series
routers.
12.2(4)T This command was implemented on the Cisco 2600 series,
Cisco 3600 series, and Cisco MC3810.
12.2(2)XB This command was implemented on the Cisco AS5350 and
Cisco AS5400.
12.2(8)T This command was implemented on Cisco IAD2420 series
integrated access devices (IADs). This command is not supported
on the access servers in this release.
12.2(11)T This command was implemented on Cisco AS5350, Cisco AS5400,
and Cisco AS5850 platforms.
12.2(33)SRA.

May 2008 DB-167
Debug Commands
Examples The following is output for the debug backhaul-session-manager set command for all available session
sets:
Router# debug backhaul-session-manager set all
Router# debug_bsm_command:DEBUG_BSM_SET_ALL
Function set_proc_event() is called

Session-Set :test-set
Old State :BSM_SET_OOS
New State :BSM_SET_OOS
Active-Grp :NONE
Session-Grp :g-11
Old State :Group-None
New State :Group-None
Event rcvd :EVT_GRP_INS
BSM:Event BSM_SET_UP is sent to user

New State :BSM_SET_ACTIVE_IS
Active-Grp :g-11
Session-Grp :g-11
New State :Group-Active
Event rcvd :BSM_ACTIVE_TYPE
The following is output for the debug backhaul-session-manager set name set1 command:
Router# debug backhaul-session-manager set name set1
Router# debug_bsm_command:DEBUG_BSM_SET_NAME
Router# Function set_proc_event() is called

New State :BSM_SET_OOS
Active-Grp :NONE
Session-Grp :g-11
New State :Group-None
Event rcvd :EVT_GRP_INS
Router#BSM:Event BSM_SET_UP is sent to user

New State :BSM_SET_ACTIVE_IS
Active-Grp :g-11
Session-Grp :g-11
New State :Group-Active
Event rcvd :BSM_ACTIVE_TYPE

debug backhaul-session-manager session Debugs all available sessions or a specified session.

DB-168 May 2008
Debug Commands
debug backup
debug backup
To monitor the transitions of an interface going down then back up, use the debug backup command in
debug backup
no debug backup
Defaults No default behavior or values.

Usage Guidelines The debug backup command is useful for monitoring dual X.25 interfaces configured as primary and
backup in a Telco data communication network (DCN).
Examples The following example shows how to start the debug backup command:
Router# debug backup

backup active interface Activates primary and backup lines on specific X.25 interfaces.
show backup Displays interface backup status.

May 2008 DB-169
Debug Commands
debug bert
debug bert
To display information on the bit error rate testing (BERT) feature, use the debug bert command in
debug bert
no debug bert

12.0(2)XD This command was introduced.
Usage Guidelines The debug bert command output is used primarily by Cisco technical support representatives. The
debug bert command displays debugging messages for specific areas of executed code.
Examples The following is output from the debug bert command:

Router# debug bert
Bit Error Rate Testing debugging is on
Router# no debug bert
Bit Error Rate Testing debugging is off

bert abort Aborts a bit error rate testing session.
bert controller Starts a bit error rate test for a particular port on a Cisco AS5300 router.
bert profile Sets up various bit error rate testing profiles.

DB-170 May 2008
Debug Commands
debug bfd
debug bfd
To display debugging messages about Bidirectional Forwarding Detection (BFD), use the debug bfd
Cisco IOS Release 12.2(18)SXE, 12.4(4)T, and 12.2(33)SRA
debug bfd {event | packet [ip-address]}
no debug bfd {event | packet [ip-address]}
Cisco IOS Release 12.0(31)S
debug bfd {event | packet [ip-address] | ipc-error | ipc-event | oir-error | oir-event}
no debug bfd {event | packet [ip-address] | ipc-error | ipc-event | oir-error | oir-event}
Syntax Description event (Optional) Displays debugging information about BFD state
transitions.
packet (Optional) Displays debugging information about BFD control
packets.
ip-address (Optional) Displays debugging information about BFD only for the
specified IP address.
ipc-error (Optional) Displays debugging information with interprocess
communication (IPC) errors on the Route Processor (RP) and line
card (LC).
ipc-event (Optional) Displays debugging information with IPC events on the
RP and LC.
oir-error (Optional) Displays debugging information with online insertion and
removal (OIR) errors on the RP and LC.
oir-event (Optional) Displays debugging information with OIR events on the
RP and LC.

12.2(18)SXE This command was introduced.

May 2008 DB-171
Debug Commands
debug bfd
Usage Guidelines The debug bfd command can be used to troubleshoot the BFD feature.
Note Because BFD is designed to send and receive packets at a very high rate, consider the potential effect on
system resources before enabling this command, especially if there are a large number of BFD peers.
The debug bfd packet command should be enabled only on a live network at the direction of Cisco
Technical Assistance Center personnel.
Examples The following example shows output from the debug bfd packet command. The IP address has been
specified in order to limit the packet information to one interface:
Router# debug bfd packet 172.16.10.5
BFD packet debugging is on

*Jan 26 14:47:37.645: Tx*IP: dst 172.16.10.1, plen 24. BFD: diag 2, St/D/P/F (1/0/0/0),
mult 5, len 24, loc/rem discr 1 1, tx 1000000, rx 1000000 100000, timer 1000 ms, #103
*Jan 26 14:47:37.645: %OSPF-5-ADJCHG: Process 10, Nbr 172.16.10.12 on Ethernet1/4 from
FULL to DOWN, Neighbor Down: BFD node down
*Jan 26 14:47:50.685: %OSPF-5-ADJCHG: Process 10, Nbr 172.16.10.12 on Ethernet1/4 from
LOADING to FULL, Loading Done
*Jan 26 14:48:00.905: Rx IP: src 172.16.10.1, plen 24. BFD: diag 0, St/D/P/F (1/0/0/0),
*Jan 26 14:48:00.905: Tx IP: dst 172.16.10.1, plen 24. BFD: diag 2, St/D/P/F (2/0/0/0),
*Jan 26 14:48:00.905: Rx IP: src 172.16.10.1, plen 24. BFD: diag 0, St/D/P/F (3/0/0/0),
*Jan 26 14:48:00.905: Tx IP: dst 172.16.10.1, plen 24. BFD: diag 0, St/D/P/F (3/0/0/0),
The following example shows output from the debug bfd event command when an interface between
two BFD neighbor routers fails and then comes back online:
Router# debug bfd event
22:53:48: BFD: bfd_neighbor - action:DESTROY, proc:1024, idb:FastEthernet0/1,

neighbor:172.16.10.2
22:53:48: BFD: bfd_neighbor - action:DESTROY, proc:512, idb:FastEthernet0/1,
22:53:49: Session [172.16.10.1,172.16.10.2,Fa0/1,1], event DETECT TIMER EXPIRED, state UP
-> FAILING
.
.
.
22:56:35: BFD: bfd_neighbor - action:CREATE, proc:1024, idb:FastEthernet0/1,
22:56:37: Session [172.16.10.1,172.16.10.2,Fa0/1,1], event RX IHY 0, state FAILING -> DOWN
22:56:37: Session [172.16.10.1,172.16.10.2,Fa0/1,1], event RX IHY 0, state DOWN -> INIT
22:56:37: Session [172.16.10.1,172.16.10.2,Fa0/1,1], event RX IHY 1, state INIT -> UP

DB-172 May 2008
Debug Commands
debug bfd
Table 35 debug bfd event Field Descriptions
Field Description
bfd_neighbor - The BFD neighbor will tear down the BFD session.
action:DESTROY
Session [172.16.10.1, IP addresses of the BFD neighbors holding this session that is carried
172.16.10.2, Fa0/1,1] over FastEthernet interface 0/1.
event DETECT TIMER The BFD neighbor has not received BFD control packets within the
EXPIRED negotiated interval and the detect timer has expired.
state UP -> FAILING The BFD event state is changing from Up to Failing.
Session [172.16.10.1, The BFD session between the neighbors indicated by the IP
172.16.10.2, Fa0/1,1], event addresses that is carried over FastEthernet interface 0/1 is changing
RX IHY 0 state from Failing to Down. The I Hear You (IHY) bit value is shown
as 0 to indicate that the remote system is tearing down the BFD
session.
event RX IHY 0, state DOWN The BFD session is still considered down, and the IHY bit value still
-> INIT is shown as 0, and the session state changes from DOWN to INIT to
indicate that the BFD session is again initializing, as the interface
comes back up.
event RX IHY 1, state INIT -> The BFD session has been reestablished, and the IHY bit value
UP changes to 1 to indicate that the session is live. The BFD session state
changes from INIT to UP.
The following example shows output from the debug bfd packet command when an interface between
two BFD neighbor routers fails and then comes back online. The diagnostic code changes from 0 (No
Diagnostic) to 1 (Control Detection Time Expired) because no BFD control packets could be sent (and
therefore detected by the BFD peer) after the interface fails. When the interface comes back online, the
diagnostic code changes back to 0 to signify that BFD packets can be sent and received by the BFD peers.
Router# debug bfd packet
23:03:25: Rx IP: src 172.16.10.2, plen 24. BFD: diag 0, H/D/P/F (0/0/0/0), mult 3, len
24, loc/rem discr 5 1, tx 1000000, rx 100007
23:03:25: Tx IP: dst 172.16.10.2, plen 24. BFD: diag 1, H/D/P/F (0/0/0/0), mult 5, len 24,
loc/rem discr 1 5, tx 1000000, rx 1000008
23:03:25: Tx IP: dst 172.16.10.2, plen 24. BFD: diag 1, H/D/P/F (1/0/0/0), mult 5, len 24,
loc/rem discr 1 5, tx 1000000, rx 1000009
Table 36 debug bfd packet Field Descriptions
Field Description
Rx IP: src 172.16.10.2 The router has received this BFD packet from the BFD router with
source address 172.16.10.2.
plen 24 Length of the BFD control packet, in bytes.

May 2008 DB-173
Debug Commands
debug bfd
Table 36 debug bfd packet Field Descriptions (continued)
Field Description
diag 0 A diagnostic code specifying the local systems reason for the last
transition of the session from Up to some other state.
State values are as follows:
0No Diagnostic
1Control Detection Time Expired
2Echo Function Failed
3Neighbor Signaled Session Down
4Forwarding Plane Reset
5Path Down
6Concentrated Path Down
7Administratively Down
H/D/P/F (0/0/0/0) H bitHear You bit. This bit is set to 0 if the transmitting system
either is not receiving BFD packets from the remote system or is
tearing down the BFD session. During normal operation the I Hear
You bit is set to 1.
D bitDemand Mode bit. If the Demand Mode bit set, the
transmitting system wants to operate in demand mode. BFS has two
modesasynchronous and demand. The Cisco implementation of
BFD supports only asynchronous mode.
P bitPoll bit. If the Poll bit is set, the transmitting system is
requesting verification of connectivity or of a parameter change.
F bitFinal bit. If the Final bit is set, the transmitting system is
responding to a received BFC control packet that had a Poll (P) bit
set.
mult 3 Detect time multiplier. The negotiated transmit interval, multiplied
by the detect time multiplier, determines the detection time for the
transmitting system in BFD asynchronous mode.
The detect time multiplier is similar to the hello multiplier in IS-IS,
which is used to determine the holdtimer: (hellointerval) *
(hellomultiplier) = holdtimer. If a hello packet is not received within
the hold-timer interval, a failure has occurred.
Similarly, for BFD: (transmit interval) * (detect multiplier) = detect
timer. If a BFD control packet is not received from the remote
system within the detect-timer interval, a failure has occurred.
len 24 The BFD packet length.

DB-174 May 2008
Debug Commands
debug bfd
Table 36 debug bfd packet Field Descriptions (continued)
Field Description
loc/rem discr 5 1 The values for My Discriminator (local) and Your Discriminator
(remote) BFD neighbors.
My DiscriminatorUnique, nonzero discriminator value
generated by the transmitting system, used to demultiplex
multiple BFD sessions between the same pair of systems.
Your DiscriminatorThe discriminator received from the
corresponding remote system. This field reflects the received
value of My Discriminator, or is zero if that value is unknown.
tx 1000000 Desired minimum transmit interval.
rx 100007 Required minimum receive interval.

May 2008 DB-175
Debug Commands
debug bgp ipv6 dampening

To display debugging messages for IPv6 Border Gateway Protocol (BGP) dampening, use the debug bgp
ipv6 dampening command in privileged EXEC mode. To disable debugging messages for IPv6 BGP
dampening, use the no form of this command.
debug bgp ipv6 {unicast | multicast} dampening [prefix-list prefix-list-name]
no debug bgp ipv6 {unicast | multicast} dampening [prefix-list prefix-list-name]
Syntax Description unicast Specifies IPv6 unicast address prefixes.

multicast Specifies IPv6 multicast address prefixes.
prefix-list prefix-list-name (Optional) Name of an IPv6 prefix list.
Command Default Debugging for IPv6 BGP dampening packets is not enabled.

12.0(21)ST This command was integrated into Cisco IOS Release 12.0(21)ST.
12.2(13)T The prefix-list keyword was added.
12.0(24)S The prefix-list keyword was added.
12.2(25)SG This command was integrated into Cisco IOS Release 12.2(25)SG.
Usage Guidelines The debug bgp ipv6 dampening command is similar to the debug ip bgp dampening command, except
that it is IPv6-specific.
Use the prefix-list keyword and an argument to filter BGP IPv6 dampening debug information through
an IPv6 prefix list.

DB-176 May 2008
Debug Commands
Note By default, the network server sends the output from debug commands and system error messages to the
console. To redirect debugging output, use the logging command options within global configuration
mode. Destinations are the console, virtual terminals, internal buffer, and UNIX hosts running a syslog
server.
Examples The following is sample output from the debug bgp ipv6 dampening command:
Router# debug bgp ipv6 dampening
00:13:28:BGP(1):charge penalty for 2000:0:0:1::/64 path 2 1 with halflife-time 15

reuse/suppress 750/2000
00:13:28:BGP(1):flapped 1 times since 00:00:00. New penalty is 1000
00:13:28:BGP(1):charge penalty for 2000:0:0:1:1::/80 path 2 1 with halflife-time 15
00:18:28:BGP(1):suppress 2000:0:0:1:1::/80 path 2 1 for 00:27:30 (penalty 2671)

00:18:28:halflife-time 15, reuse/suppress 750/2000
00:18:28:BGP(1):suppress 2000:0:0:1::/64 path 2 1 for 00:27:20 (penalty 2664)
00:18:28:halflife-time 15, reuse/suppress 750/2000
The following example shows output for the debug bgp ipv6 dampening command filtered through the
prefix list named marketing:
Router# debug bgp ipv6 dampening prefix-list marketing
00:16:08:BGP(1):charge penalty for 2001:0DB8::/64 path 30 with halflife-time 15

Table 37 describes the fields shown in the display.
Table 37 debug bgp ipv6 dampening Field Descriptions
Field Description
penalty Numerical value of 1000 assigned to a route by a router configured for
route dampening in another autonomous system each time a route
flaps. Penalties are cumulative. The penalty for the route is stored in
the BGP routing table until the penalty exceeds the suppress limit. If
the penalty exceeds the suppress limit, the route state changes from
history to damp.
flapped Number of times a route is available, then unavailable, or vice versa.
halflife-time Amount of time (in minutes) by which the penalty is decreased after
the route is assigned a penalty. The halflife-time value is half of the
half-life period (which is 15 minutes by default). Penalty reduction
happens every 5 seconds.

May 2008 DB-177
Debug Commands
Table 37 debug bgp ipv6 dampening Field Descriptions (continued)
Field Description
reuse The limit by which a route is unsuppressed. If the penalty for a
flapping route decreases and falls below this reuse limit, the route is
unsuppressed. That is, the route is added back to the BGP table and
once again used for forwarding. The default reuse limit is 750. Routes
are unsuppressed at 10-second increments. Every 10 seconds, the
router determines which routes are now unsuppressed and advertises
them to the world.
suppress Limit by which a route is suppressed. If the penalty exceeds this limit,
the route is suppressed. The default value is 2000.
maximum suppress limit Maximum amount of time (in minutes) a route is suppressed. The
(not shown in sample output) default value is four times the half-life period.
damp state State in which the route has flapped so often that the router will not
(not shown in sample output) advertise this route to BGP neighbors.

debug bgp ipv6 updates Displays debugging messages for IPv6 BGP update packets.

DB-178 May 2008
Debug Commands
debug bgp ipv6 updates

To display debugging messages for IPv6 Border Gateway Protocol (BGP) update packets, use the debug
bgp ipv6 updates command in privileged EXEC mode. To disable debugging messages for IPv6 BGP
update packets, use the no form of this command.
debug bgp ipv6 {unicast | multicast} updates [ipv6-address] [prefix-list prefix-list-name] [in |
out]
no debug bgp ipv6 {unicast | multicast} updates [ipv6-address] [prefix-list prefix-list-name] [in
| out]
Syntax Description unicast Specifies IPv6 unicast address prefixes.

multicast Specifies IPv6 multicast address prefixes.
ipv6-address (Optional) The IPv6 address of a BGP neighbor.
This argument must be in the form documented in RFC 2373 where
the address is specified in hexadecimal using 16-bit values between
colons.
prefix-list prefix-list-name (Optional) Name of an IPv6 prefix list.
in (Optional) Indicates inbound updates.
out (Optional) Indicates outbound updates.
Command Default Debugging for IPv6 BGP update packets is not enabled.

12.2(13)T The prefix-list keyword was added.
12.0(24)S The prefix-list keyword was added.

May 2008 DB-179
Debug Commands
Usage Guidelines The debug bgp ipv6 updates command is similar to the debug ip bgp updates command, except that
it is IPv6-specific.
Use the prefix-list keyword to filter BGP IPv6 updates debugging information through an IPv6 prefix
list.
server. For complete information on debug commands and redirecting debugging output, refer to the
Release 12.2 Cisco IOS Debug Command Reference.
Examples The following is sample output from the debug bgp ipv6 updates command:
Router# debug bgp ipv6 updates
14:04:17:BGP(1):2000:0:0:2::2 computing updates, afi 1, neighbor version 0, table version

1, starting at ::
14:04:17:BGP(1):2000:0:0:2::2 update run completed, afi 1, ran for 0ms, neighbor version
0, start version 1, throttled to 1
14:04:19:BGP(1):sourced route for 2000:0:0:2::1/64 path #0 changed (weight 32768)
14:04:19:BGP(1):2000:0:0:2::1/64 route sourced locally
14:04:19:BGP(1):2000:0:0:2:1::/80 route sourced locally
14:04:22:BGP(1):2000:0:0:2::2 computing updates, afi 1, neighbor version 1, table version
6, starting at ::
14:04:22:BGP(1):2000:0:0:2::2 send UPDATE (format) 2000:0:0:2::1/64, next 2000:0:0:2::1,
metric 0, path
14:04:22:BGP(1):2000:0:0:2::2 send UPDATE (format) 2000:0:0:2:1::/80, next 2000:0:0:2::1,
metric 0, path
14:04:22:BGP(1):2000:0:0:2::2 send UPDATE (prepend, chgflags:0x208) 2000:0:0:3::2/64, next
2000:0:0:2::1, metric 0, path
14:04:22:BGP(1):2000:0:0:2::2 send UPDATE (prepend, chgflags:0x208) 2000:0:0:4::2/64, next
2000:0:0:2::1, metric 0, path
The following is sample output from the debug bgp ipv6 updates command filtered through the prefix
list named sales:
Router# debug bgp ipv6 updates prefix-list sales
00:18:26:BGP(1):2000:8493:1::2 send UPDATE (prepend, chgflags:0x208) 7878:7878::/64, next

2001:0DB8::36C, metric 0, path
Table 38 debug bgp ipv6 updates Field Descriptions
Field Description
BGP(1): BGP debugging for address family index (afi) 1.
afi Address family index.
neighbor version Version of the BGP table on the neighbor from which the update was
received.

DB-180 May 2008
Debug Commands
Table 38 debug bgp ipv6 updates Field Descriptions (continued)
Field Description
table version Version of the BGP table on the router from which you entered the
debug bgp ipv6 updates command.
starting at Starting at the network layer reachability information (NLRI). BGP
sends routing update messages containing NLRI to describe a route
and how to get there. In this context, an NLRI is a prefix. A BGP
update message carries one or more NLRI prefixes and the attributes
of a route for the NLRI prefixes; the route attributes include a BGP
next hop gateway address, community values, and other information.
route sourced locally Indicates that a route is sourced locally and that updates are not sent
for the route.
send UPDATE (format) Indicates that an update message for a reachable network should be
formatted. Addresses include prefix and next hop.
send UPDATE (prepend, Indicates that an update message about a path to a BGP peer should be
chgflags:0x208) written.

debug bgp ipv6 Displays debugging messages for IPv6 BGP dampening packets.
dampening

May 2008 DB-181
Debug Commands
debug bgp nsap dampening

To display debug messages for Border Gateway Protocol (BGP) network service access point (NSAP)
prefix address dampening, use the debug bgp nsap dampening command in privileged EXEC mode. To
debug bgp nsap dampening [filter-list access-list-number]
no debug bgp nsap dampening [filter-list access-list-number]
Syntax Description filter-list access-list-number (Optional) Displays debug messages for BGP NSAP dampening
events that match the access list. The acceptable access list number
range is from 1 to 199.
Command Default Debugging for BGP NSAP dampening events is not enabled.

12.2(33)SRB This command was integrated into Cisco IOS Release 12.2(33)SRB.
Usage Guidelines The debug bgp nsap dampening command is similar to the debug ip bgp dampening command, except
that it is specific to the NSAP address family.
console. To redirect debug output, use the logging command options within global configuration mode.
Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog
server.
Examples The following example shows output for the debug bgp nsap dampening command:
Router# debug bgp nsap dampening
16:21:34: BGP(4): Dampening route-map modified.
Only one line of output is displayed unless the bgp dampening command is configured with a route map
in NSAP address family configuration mode. The following example shows output for the debug bgp
nsap dampening command when a route map is configured:

DB-182 May 2008
Debug Commands
20:07:19: BGP(4): charge penalty for 49.0404 path 65202 65404 with halflife-time 15
20:07:19: BGP(4): flapped 1 times since 00:00:00. New penalty is 1000
20:10:48: BGP(4): suppress 49.0404 path 65202 65404 for 00:28:10 (penalty 2752)
20:10:48: halflife-time 15, reuse/suppress 750/2000
Table 39 debug bgp nsap dampening Field Descriptions
Field Description
penalty Numerical value of 1000 assigned to a route by a router configured for
route dampening in another autonomous system each time a route
flaps. Penalties are cumulative. The penalty for the route is stored in
the BGP routing table until the penalty exceeds the suppress limit. If
the penalty exceeds the suppress limit, the route state changes from
history to damp.
halflife-time Amount by which the penalty is decreased after the route is assigned a
penalty. The half-life-time value is half of the half-life period (which
is 15 minutes by default). Penalty reduction occurs every 5 seconds.
flapped Number of times a route is available, then unavailable, or vice versa.
reuse The limit by which a route is unsuppressed. If the penalty for a flapping
route decreases and falls below this reuse limit, the route is
unsuppressed. That is, the route is added back to the BGP table and
once again used for forwarding. The default reuse limit is 750.
Unsuppressing of routes occurs at 10-second increments. Every
10 seconds, the router learns which routes are now unsuppressed and
advertises them throughout the network.
suppress Limit by which a route is suppressed. If the penalty exceeds this limit,
the route is suppressed. The default value is 2000.
maximum suppress limit Maximum amount of time a route is suppressed. The default value is
(not shown in sample output) four times the half-life period.
damp state State in which the route has flapped so often that the router will not
(not shown in sample output) advertise this route to BGP neighbors.

debug bgp nsap Displays debug messages for BGP NSAP packets.
debug bgp nsap updates Displays debug messages for BGP NSAP update events.

May 2008 DB-183
Debug Commands
debug bgp nsap updates

To display debug messages for Border Gateway Protocol (BGP) network service access point (NSAP)
prefix address update packets, use the debug bgp nsap updates command in privileged EXEC mode.
debug bgp nsap updates [ip-address] [in | out] [filter-set clns-filter-set-name]
no debug bgp nsap updates [ip-address] [in | out] [filter-set clns-filter-set-name]
Syntax Description ip-address (Optional) The IP address of a BGP neighbor.

in (Optional) Indicates inbound updates.
out (Optional) Indicates outbound updates.
filter-set clns-filter-set-name (Optional) Name of a Connectionless Network Service (CLNS)
filter set.
Command Default Debugging for BGP NSAP prefix update packets is not enabled.

Usage Guidelines The debug bgp nsap updates command is similar to the debug ip bgp updates command, except that
it is specific to the NSAP address family.
Use the ip-address argument to display the BGP update debug messages for a specific BGP neighbor.
Use the clns-filter-set-name argument to display the BGP update debug messages for a specific NSAP
prefix.
server.
Examples The following example shows output for the debug bgp nsap updates command:
Router# debug bgp nsap updates

DB-184 May 2008
Debug Commands
02:13:45: BGP(4): 10.0.3.4 send UPDATE (format) 49.0101, next

49.0303.3333.3333.3333.3333.00, metric 0, path 65202 65101
49.0303.3333.3333.3333.3333.00, metric 0, path 65202
49.0303.3333.3333.3333.3333.00, metric 0, path
49.0303.3333.3333.3333.3333.00, metric 0, path 65404
Table 40 debug bgp nsap updates Field Descriptions
Field Description
BGP(4): BGP debug for address family index (afi) 4.
route sourced locally (not Indicates that a route is sourced locally and that updates are not sent
shown in display) for the route.
send UPDATE (format) Indicates that an update message for a reachable network should be
formatted. Addresses include NSAP prefix and next hop.
rcv UPDATE (not shown in Indicates that an update message about a path to a BGP peer has
display) been received. Addresses include NSAP prefix.

debug bgp nsap Displays debug messages for BGP NSAP packets.
debug bgp nsap dampening Displays debug messages for BGP NSAP prefix dampening events.

May 2008 DB-185
Debug Commands
debug bgp nsap
debug bgp nsap

To enable the display of Border Gateway Protocol (BGP) debugging information specific to the network
service access point (NSAP) address family, use the debug bgp nsap command in privileged EXEC
debug bgp nsap
no debug bgp nsap
Command Default Debugging of BGP NSAP address-family code is not enabled.

Usage Guidelines The debug bgp nsap command is similar to the debug ip bgp command, except that it is specific to the
NSAP address family.
server.
Examples The following example shows output for the debug bgp nsap command. The BGP(4) identifies that BGP
version 4 is operational.
Router# debug bgp nsap
00:46:46: BGP(4): removing CLNS route to 49.0101

00:46:46: BGP(4): 10.1.2.1 removing CLNS route 49.0101.1111.1111.1111.1111.00 to
eBGP-neighbor
00:46:46: BGP(4): 10.2.4.4 removing CLNS route 49.0303.4444.4444.4444.4444.00 to
eBGP-neighbor
00:46:59: BGP(4): Applying map to find origin for prefix 49.0202.2222

DB-186 May 2008
Debug Commands
debug bgp nsap
00:46:59: BGP(4): Applying map to find origin for prefix 49.0202.3333

debug bgp nsap dampening Displays debug messages for BGP NSAP prefix dampening events.
debug bgp nsap updates Displays debug messages for BGP NSAP prefix update packets.

May 2008 DB-187
Debug Commands
debug bgp vpnv6 unicast

To display Border Gateway Protocol (BGP) virtual private network (VPN) debugging output, use the
debug bgp vpnv6 unicast command in privileged EXEC mode. To disable debugging output, use the no
no debug bgp vpnv6
Command Default No default behavior or values.

12.2(33)SRB This command was introduced.
Usage Guidelines Use the debug bgp vpnv6 unicast command to help troubleshoot the BGP VPN.
server. For complete information on debug commands and redirecting debugging output, refer to the
Cisco IOS Debug Command Reference, Release 12.4.
Examples The following example enables BGP debugging output for IPv6 VPN instances:
Router# debug bgp vpnv6 unicast

DB-188 May 2008
Debug Commands
debug bri-interface
debug bri-interface
To display debugging information on ISDN BRI routing activity, use the debug bri-interface command
debug bri-interface
no debug bri-interface
Usage Guidelines The debug bri-interface 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.
Caution Because the debug bri-interface command generates a substantial amount of output, use it only when
traffic on the IP network is low, so other activity on the system is not adversely affected.
Examples The following is sample output from the debug bri-interface command:
Router# debug bri-interface
BRI: write_sid: wrote 1B for subunit 0, slot 1.

BRI: write_sid: wrote 15 for subunit 0, slot 1.
BRI: Starting Power Up timer for unit = 0.
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 B1
%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 B1

May 2008 DB-189
Debug Commands
debug bri-interface
%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 down
The following line indicates that an internal command was written to the interface controller. The subunit
identifies the first interface in the slot.
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-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 down
The following line indicates that the channel was disabled:

BRI: disable channel B1
Lines of output not described are for use by support staff only.

debug isdn event Displays ISDN events occurring on the user side (on the router) of the ISDN
interface.
debug isdn q921 Displays data link-layer (Layer 2) access procedures that are taking place at
the router on the D channel (LSPD).
debug isdn q931 Displays information about call setup and teardown of ISDN network
connections (Layer 3) between the local router (user side) and the network.

DB-190 May 2008
Debug Commands
debug bsc event
debug bsc event

To display all events occurring in the Binary Synchronous Communications (Bisync) feature, use the
debug bsc event command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
debug bsc event [number]
no debug bsc event [number]
Syntax Description number (Optional) Group number.
Usage Guidelines This command traces all interfaces configured with a bsc protocol-group number command.
Examples The following is sample output from the debug bsc event command:
Router# debug bsc event
BSC: Serial2 POLLEE-FSM inp:E_LineFail old_st:CU_Down new_st:TCU_EOFile

0:04:32: BSC: Serial2 :SDI-rx: 9 bytes
BSC: Serial2 POLLEE-FSM inp:E_RxEtx old_st:CU_Down new_st:TCU_EOFile
BSC: Serial2 POLLEE-FSM inp:E_RxEnq old_st:CU_Down new_st:TCU_EOFile
BSC: Serial2 POLLEE-FSM inp:E_Timeout old_st:CU_Down new_st:TCU_InFile
BSC: 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 up
BSC: Serial2 POLLEE-FSM inp:E_Timeout old_st:CU_Idle new_st:TCU_InFile
BSC: Serial2 POLLEE-FSM inp:E_RxEtx old_st:CU_Idle new_st:TCU_InFile
BSC: Serial2 POLLEE-FSM inp:E_RxEnq old_st:CU_Idle new_st:TCU_InFile
0:04:35: BSC: Serial2 :NDI-rx: 3 bytes

debug bsc packet Displays all frames traveling through the Bisync feature.
debug bstun events Displays BSTUN connection events and status.

May 2008 DB-191
Debug Commands
debug bsc packet
debug bsc packet

To display all frames traveling through the Binary Synchronous Communications (Bisync) feature, use
the debug bsc packet command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug bsc packet [group number] [buffer-size bytes]
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).
Defaults The default number of bytes displayed is 20.
Usage Guidelines This command traces all interfaces configured with a bsc protocol-group number command.
Examples The following is sample output from the debug bsc packet command:
Router# debug bsc packet
0:23:33: BSC: Serial2 :NDI-rx : 27 bytes 401A400227F5C31140C11D60C8C5D3D3D51D4013

0:23:33: BSC: Serial2 :SDI-tx : 12 bytes 00323237FF3232606040402D
0:23:33: BSC: Serial2 :SDI-rx : 2 bytes 1070
0:23:33: BSC: Serial2 :SDI-tx : 27 bytes 401A400227F5C31140C11D60C8C5D3D3D51D4013
0:23:33: BSC: Serial2 :SDI-rx : 2 bytes 1061
0:23:33: BSC: Serial2 :SDI-tx : 5 bytes 00323237FF

debug bsc event Displays all events occurring in the Bisync feature.

DB-192 May 2008
Debug Commands
debug bstun events
debug bstun events

To display BSTUN connection events and status, use the debug bstun events command in privileged
EXEC mode. To disable debugging output, use the no form of this command.
debug bstun events [number]
no debug bstun events [number]
Syntax Description number (Optional) Group number.
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 Also refer to the debug bsc packet and debug bsc event commands. Currently, these two commands
support the only protocol working through the BSTUN tunnel. Sometimes frames do not go through the
tunnel because they have been discarded at the Bisync protocol level.
Examples 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 events
BSTUN: Received Version Reply opcode from (all[2])_172.16.12.2/1976 at 1360

BSTUN: Received Version Request opcode from (all[2])_172.16.12.2/1976 at 1379
BSTUN: Received Version Reply opcode from (all[2])_172.16.12.2/1976 at 1390
Note In a scenario where there is constantly loaded bidirectional traffic, you might not see keepalive messages
because they are sent only when the remote end has been silent for the keepalive period.
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 events
BSTUN: 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, 3
BSTUN: tcpd sender in wrong state, dropping packet

May 2008 DB-193
Debug Commands
debug bstun events

debug bsc event Displays all events occurring in the Bisync feature.
debug bsc packet Displays all frames traveling through the Bisync feature.
debug bstun packet Displays packet information on packets traveling through the BSTUN links.

DB-194 May 2008
Debug Commands
debug bstun packet
debug bstun packet

To display packet information on packets traveling through the BSTUN links, use the debug bstun
packet command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug bstun packet [group number] [buffer-size bytes]
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).
Defaults The default number of bytes displayed is 20.
Examples The following is sample output from the debug bstun packet command:
Router# debug bstun packet
BSTUN bsc-local-ack: 0:00:00 Serial2 SDI: Addr: 40 Data: 02C1C1C1C1C1C1C1C1C1

BSTUN bsc-local-ack: 0:00:00 Serial2 SDI: Addr: 40 Data: 02C1C1C1C1C1C1C1C1C1
BSTUN bsc-local-ack: 0:00:06 Serial2 NDI: Addr: 40 Data: 0227F5C31140C11D60C8


May 2008 DB-195
Debug Commands
debug bundle errors
debug bundle errors

To enable the display of information on bundle errors, use the debug bundle errors command in
debug bundle errors
no debug bundle errors

Usage Guidelines Use this command to enable the display of error information for a bundle, such as reports of inconsistent
mapping in the bundle.

bump Configures the bumping rules for a VC class that can be assigned to a VC
bundle.
bundle Creates a bundle or modifies an existing bundle to enter bundle
configuration mode.
debug bundle events Enables display of bundle events when use occurs.

DB-196 May 2008
Debug Commands
debug bundle events
debug bundle events

To enable display of bundle events when use occurs, use the debug bundle events command in
privileged EXEC mode. To disable the display, use the no form of this command.
debug bundle events
no debug bundle events

Usage Guidelines Use this command to enable the display of bundle events, such as occurrences of VC bumping, when
bundles were brought up, when they were taken down, and so forth.

debug bstun packet Enables the display of information on bundle errors.

May 2008 DB-197
Debug Commands
debug call fallback detail

To display details of the call fallback, use the debug call fallback detail command in privileged EXEC
no debug call fallback detail
Defaults Disabled

12.2(4)T This command was implemented on the Cisco 7200 series routers.
12.2(4)T3 This command was implemented on the Cisco 7500 series routers
routers.
Usage Guidelines Every time a call request is received, the debug call fallback detail command displays in the command-line
interface (CLI) cache lookup and call acceptance/rejection information. Use this command to monitor call
requests as they enter the call fallback subsystem.
If you have a large amount of calls in your router, enabling this command can cause delays in your
routing functions as the debug statistics are constantly compiled and sent to your terminal. Also, debug
messages on your terminal may make for difficult CLI configuring.
Examples The following example depicts a call coming in to 10.1.1.4 with codec g729r8. Because there is no cache
entry for this destination, a probe is sent and values are inserted into the cache. A lookup is performed
again, entry is found, and a fallback decision is made to admit the call.
Router# debug call fallback detail
When cache is empty:

debug call fallback detail:
2d19h:fb_lookup_cache:10.1.1.4, codec:g729r8
2d19h:fb_lookup_cache:No entry found.

DB-198 May 2008
Debug Commands
2d19h:fb_check:no entry exists, enqueueing probe info... 10.1.1.4, codec:g729r8

2d19h:fb_main:Got FB_APP_INQ event
2d19h:fb_main:Dequeued prob info: 10.1.1.4, codec:g729r8
2d19h:fb_lookup_cache:No entry found.
2d19h:fb_cache_insert:insert:10.1.1.4, codec:g729r8
2d19h:fb_cache_insert:returning entry:10.1.1.4, codec:g729r8
2d19h:fb_initiate_probe:Creating probe... 10.1.1.4, codec:g729r8
2d19h:fb_initiate_probe:Created and started on probe #13, 10.1.1.4, codec:g729r8
2d19h:fb_lookup_cache:Found entry.
2d19h:fb_check:returned FB_CHECK_TRUE, 10.1.1.4, codec:g729r8
2d19h:fb_main:calling callback function with:TRUE
The following example depicts a call coming in to 10.1.1.4 with codec g729r8. A lookup is performed,
entry is found, and a fallback decision is made to admit the call.
Router# debug call fallback detail
When cache is full:

2d19h:fb_lookup_cache:Found entry.
2d19h:fb_check:returned FB_CHECK_TRUE, 10.1.1.4, codec:g729r8
2d19h:fb_main:calling callback function with:TRUE

May 2008 DB-199
Debug Commands
debug call fallback probe

To display details of the call fallback probes, use the debug call fallback probe command in privileged
no debug call fallback probe
Defaults Disabled

12.2(2)XA The call fallback and call fallback reject-cause-code commands
were introduced.
12.2(4)T This command was implemented on the Cisco 7200 series routers.
12.2(4)T3 This command was implemented on the Cisco 7500 series routers.
Usage Guidelines Every time a probe is received, the debug call fallback probe command displays in the command-line
interface (CLI) network traffic information collected by the probe. Use this command to monitor the network
traffic information the probes carry as they enter the call fallback subsystem and log cache entries.
If you have frequent return of probes to your router, enabling this command can cause delays in your
routing functions as the debug statistics are constantly compiled and sent to your terminal. Also, debug
messages on your terminal may make for difficult CLI configuring.
Examples The following example depicts a call coming in to 10.1.1.4 and codec type g729r8. Because there is no
cache entry for this IP address, a g729r8 probe is initiated. The probe consists of 20 packet returns with
an average delay of 43 milliseconds. The jitter out is jitter from source to destination router and jitter
in is jitter from destination to source router. The delay, loss, and Calculated Planning Impairment Factor
(ICPIF) values following g113_calc_icpif are the instantaneous values, whereas those values following
New smoothed values are the values after applying the smoothing with weight 65.
Router# debug call fallback probe
2d19h:fb_initiate_probe:Probe payload is 32

DB-200 May 2008
Debug Commands
2d19h:fb_main:NumOfRTT=20, RTTSum=120, loss=0, delay=43, jitter in=0, jitter out=0->

10.1.1.4, codec:g729r8
2d19h:g113_calc_icpif(delay (w/codec delay)=43, loss=0, expect_factor=10) Icpif=0
2d19h:fb_main:Probe timer expired, 10.1.1.4, codec:g729r8

2d19h:fb_main:NumOfRTT=20, RTTSum=120, loss=0, delay=43, jitter in=0, jitter out=0->
10.1.1.4, codec:g729r8
2d19h:g113_calc_icpif(delay (w/codec delay)=43, loss=0, expect_factor=10) Icpif=0
2d19h:fb_main:New smoothed values:inst_weight=65, ICPIF=0, Delay=43, Loss=0 -> 10.1.1.4,
codec:g729r8

May 2008 DB-201
Debug Commands
debug call filter detail

To display details of the debug trace inside the generic call filter module (GCFM), use the debug call
filter detail command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
no debug call filter detail

Examples The following sample output from the debug call filter detail command shows the detailed activity of
the GCFM, which is the internal module that controls the debug filtering.
Router# debug call filter detail
5d18h: gcfm_call_get_hash_address: hashtable index = 345

5d18h: gcfm_call_search_hash:no found
5d18h: gcfm_init_call_record:
5d18h: gcfm_init_percall_matchlist:
5d18h: === list 1: service_state=2, callp's: 0
5d18h: gcfm_call_enlist: count before this enlist 0 on 624D6000
5d18h: gcfm_call_enlist: tail is empty guid=C2E4C789-214A-11D4-804C-000A8A389BA8
5d18h: gcfm_call_search_hash: search requested guid=C2E4C789-214A-11D4-804C-000A8A389BA8
vs the entry guid=C2E4C789-214A-11D4-804C-000A8A389BA8
5d18h: gcfm_call_search_hash: found
5d18h: gcfm_update_percall_condlist_context:
5d18h: gcfm_update_percall_condlist_context: check cond = 2
5d18h: gcfm_copy_match_cond:
5d18h: gcfm_update_cond_through_matchlist:
5d18h: gcfm_check_percond_with_matchlist: check match-list 1
5d18h: gcfm_matchlist_percond_check:
5d18h: gcfm_matchlist_percond_check: check cond=2
5d18h: gcfm_matchlist_percond_check: compare 42300 to configured 42300
5d18h: gcfm_check_cond_tel_number:
5d18h: gcfm_check_cond_tel_number: matched

DB-202 May 2008
Debug Commands
5d18h: gcfm_matchlist_percond_check: checked result is 1

5d18h: gcfm_is_bitfield_identical:
5d18h: gcfm_update_cond_through_matchlist: service=1, percallmatchlist
tag=1,current_status = 1, service_filter=0
5d18h: gcfm_percall_notify_condition: not linked call record
Table 41 debug call filter detail Field Descriptions
Field Description
5d18h: gcfm_init_percall_matchlist: Shows that the filtering has been initiated.
5d18h: gcfm_call_enlist: tail is empty Shows the global unique identifier (GUID) for the call.
guid=C2E4C789-214A-11D4-804C-00
0A8A389BA8
5d18h: Shows which match list is being checked.
gcfm_check_percond_with_matchlis
t: check match-list 1
5d18h: Shows that the call matched conditions in match list 1.
gcfm_matchlist_percond_check:
checked result is 1

debug call filter inout Displays the debug trace inside the GCFM.
debug condition match-list Runs a filtered debug on a voice call.
show call filter components Displays the components used for filtering calls.

May 2008 DB-203
Debug Commands
debug call filter inout

To display the debug trace inside the generic call filter module (GCFM), use the debug call filter inout
no debug call filter inout

Examples The following sample output from the debug call filter inout command shows the incoming and
outgoing activity of the GCFM, which is the internal module that controls the debug filtering.
Router# debug call filter inout
5d18h: gcfm_generate_guid: component ISDN gets guid

5d18h: gcfm_percall_register: component ISDN
5d18h: gcfm_percall_register: component ISDN return selected=0
5d18h: gcfm_percall_notify_condition: component ISDN for sync=1
5d18h: gcfm_percall_notify_condition: component ISDN successfully selected = 0
5d18h: gcfm_check_percall_status: component TGRM
5d18h: gcfm_check_percall_status: component TGRM return selected=0
5d18h: gcfm_check_percall_status: component TGRM
5d18h: gcfm_check_percall_status: component TGRM return selected=0
5d18h: gcfm_percall_register: component VTSP
5d18h: gcfm_percall_register: component VTSP for return selected value 0
5d18h: gcfm_percall_notify_condition: component VTSP for sync=1
5d18h: gcfm_percall_notify_condition: component VTSP successfully selected = 0
5d18h: gcfm_percall_register: component CCAPI
5d18h: gcfm_percall_register: component CCAPI for return selected value 0
5d18h: gcfm_check_percall_status: component NUMBER-TRANSLATION
5d18h: gcfm_check_percall_status: component NUMBER-TRANSLATION return selected=0
5d18h: gcfm_percall_register: component VOICE-IVR-V2
5d18h: gcfm_percall_register: component VOICE-IVR-V2 for return selected value 0
5d18h: gcfm_check_percall_status: component DIAL-PEER
5d18h: gcfm_check_percall_status: component DIAL-PEER return selected=0

DB-204 May 2008
Debug Commands

5d18h: gcfm_percall_register: component CCAPI
5d18h: gcfm_percall_register: component CCAPI for return selected value 0
5d18h: gcfm_percall_register: component VOICE-IVR-V2
5d18h: gcfm_percall_register: component VOICE-IVR-V2 for return selected value 0
5d18h: gcfm_percall_notify_condition: component VOICE-IVR-V2 for sync=1
5d18h: gcfm_percall_notify_condition: component VOICE-
Router#IVR-V2 successfully selected = 1
5d18h: gcfm_percall_register: component H323
5d18h: gcfm_percall_register: component H323 for return selected value 1
5d18h: gcfm_clear_condition: component VOICE-IVR-V2
5d18h: gcfm_clear_condition: component VOICE-IVR-V2 successfully
5d18h: gcfm_percall_deregister: component CCAPI
5d18h: gcfm_percall_deregister: component CCAPI successfully
5d18h: gcfm_percall_deregister: component H323
5d18h: gcfm_percall_deregister: component H323 successfully
5d18h: gcfm_percall_deregister: component ISDN
5d18h: gcfm_percall_deregister: component ISDN successfully
5d18h: gcfm_percall_deregister: component VOICE-IVR-V2
5d18h: gcfm_percall_deregister: component VOICE-IVR-V2 successfully
5d18h: gcfm_percall_deregister: component CCAPI
5d18h: gcfm_percall_deregister: component CCAPI successfully
5d18h: gcfm_percall_deregister: component VTSP
5d18h: gcfm_percall_deregister: component VTSP successfully
5d18h: gcfm_percall_deregister: component VOICE-IVR-V2
5d18h: gcfm_terminate_track_guid: component VOICE-IVR-V2 terminate, success
5d18h: gcfm_percall_deregister: component VOICE-IVR-V2 successfully
Table 42 debug call filter inout Field Descriptions
Field Description
gcfm_generate_guid: Shows that a GUID has been generated.
gcfm_percall_register: Shows components that have been registered for the call.
gcfm_percall_notify_condition: Shows that a component has been notified of the call.

May 2008 DB-205
Debug Commands
Table 42 debug call filter inout Field Descriptions (continued)
Field Description
gcfm_check_percall_status: Shows the status of a component of the call.
gcfm_percall_register: Shows that a component has been registered.
gcfm_clear_condition: Shows that a condition is cleared for a component.
gcfm_percall_deregister: Shows that a component has been deregistered.
gcfm_terminate_track_guid: Shows that the router is no longer tracking the GUID.

debug call filter detail Displays the details of the debug trace inside the GCFM.
debug condition match-list Runs a filtered debug on a voice call.
show call filter components Displays the components used for filtering calls.

DB-206 May 2008
Debug Commands
debug call rsvp-sync events

To display events that occur during Resource Reservation Protocol (RSVP) setup, use the
debug call rsvp-sync events command in privileged EXEC mode. To disable debugging output, use the
no form of this command.
no debug call rsvp-sync events

12.1(3)XI1 This command was introduced.
12.2(2)XB1 This command was implemented on the Cisco AS5850.
12.2(11)T Support for the command was implemented in Cisco AS5850 images.
Usage Guidelines It is highly recommended that you log the output from the debug call rsvp-sync events command to a
buffer, rather than sending the output to the console; otherwise, the size of the output could severely
impact the performance of the gateway.
Examples The following example shows a portion of sample output for a call initiating RSVP when using the
debug call rsvp-sync events command:
00:03:25: Parameters: localip: 10.19.101.117 :localport: 16660
00:03:25: Parameters: remoteip: 10.19.101.116 :remoteport: 17568
00:03:25: QoS Primitive Event for Call id 0x1 : QoS Listen

00:03:25: Lookup to be done on hashkey 0x1 in hash table 0x61FC2498
00:03:25: Hashed entry 0x1 in call table 0x61FC2498
00:03:25: Entry Not found

May 2008 DB-207
Debug Commands
00:03:25: Parameters: localip: 10.19.101.117
00:03:25: remoteip: 10.19.101.116
00:03:25: QoSpcb : 0x61FC34D8
00:03:25: Response Status : 0

Starting timer for call with CallId 0x1 for 10000 secs
00:03:25: Handling QoS Primitive QoS Listen
00:03:25: Establishing RSVP RESV state : rsvp_request_reservation()
00:03:25: For streams from 10.19.101.116:17568 to 10.19.101.117:16660
00:03:25: RSVP Confirmation required
00:03:25: QoS Primitive Event for Call id 0x1 : QoS Resv

00:03:25: Lookup to be done on hashkey 0x1 in hash table 0x61FC2498
00:03:25: Hashed entry 0x1 in call table 0x61FC2498
00:03:25: Initiating RVSP PATH messages to be Sent : reg_invoke_rsvp_advertise_sender()
00:03:25: Advertizing for streams to 10.19.101.116:17568 from 10.19.101.117:16660
00:03:25: RESV notification event received is : 2
00:03:25: Received RESVCONFIRM
00:03:25: RESV CONFIRM message received from 10.19.101.116 for RESV setup from
10.19.101.117
00:03:25: RESV event received is : 0
00:03:25: RESV message received from 10.19.101.116:17568 for streams from

10.19.101.117:16660
00:03:25: RESERVATIONS ESTABLISHED : CallId: 1Stop timer and notify Session Protocol of
Success (ie. if notification requested)
00:03:25: Invoking spQoSresvCallback with Success

call rsvp-sync Enables synchronization between RSVP and the H.323 voice
signaling protocol.
call rsvp-sync resv-timer Sets the timer for RSVP reservation setup.
debug call rsvp-sync func-trace Displays messages about the software functions called by
RSVP synchronization.
show call rsvp-sync conf Displays the RSVP synchronization configuration.
show call rsvp-sync stats Displays statistics for calls that attempted RSVP reservation.

DB-208 May 2008
Debug Commands
debug call rsvp-sync func-trace

To display messages about software functions called by Resource Reservation Protocol (RSVP), use the
debug call rsvp-sync func-trace command in privileged EXEC mode. To disable debugging output, use
no debug call rsvp-sync func-trace

12.1(3)XI1 This command was introduced.
Usage Guidelines It is highly recommended that you log the output from the debug call rsvp-sync func-trace command
to a buffer, rather than sending the output to the console; otherwise, the size of the output could severely
impact the performance of the gateway.
Examples The following example shows a portion of sample output for a call initiating RSVP when using the
debug call rsvp-sync func-trace command in conjunction with the debug call rsvp-sync events
command:
00:03:41: Entering Function QoS_Listen
00:03:41: Parameters:localip:10.10.101.116 :localport:17568
00:03:41:remoteip:10.10.101.117 :remoteport:0
00:03:41: Entering Function qos_dequeue_event
00:03:41: Entering Function process_queue_event
00:03:41: QoS Primitive Event for Call id 0x2 :QoS Listen

00:03:41: Entering Function get_pcb

May 2008 DB-209
Debug Commands
00:03:41: Entering Function hash_tbl_lookup
00:03:41:Lookup to be done on hashkey 0x2 in hash table 0x61FAECD8
00:03:41: Entering Function hash_func
00:03:41:Hashed entry 0x2 in call table 0x61FAECD8
00:03:41:Entry Not found
00:03:41: Entering Function qos_dequeue_pcb
00:03:41: Entering Function qos_initialize_pcb
00:03:41: Parameters:localip:10.10.101.116
00:03:41: remoteip:10.10.101.117
00:03:41: QoSpcb :0x61FAFD18
00:03:41: Response Status :0
00:03:41: Entering Function hash_tbl_insert_entry
00:03:41: Handling QoS Primitive QoS Listen
00:03:41: Entering Function qos_dequeue_hash_port_entry
00:03:41: Entering Function qos_port_tbl_insert_entry
00:03:41: Doing RSVP Listen :rsvp_add_ip_listen_api()

call rsvp-sync Enables synchronization between RSVP and the H.323 voice
signaling protocol.
call rsvp-sync resv-timer Sets the timer for RSVP reservation setup.
debug call rsvp-sync events Displays the events that occur during RSVP synchronization.
show call rsvp-sync conf Displays the RSVP synchronization configuration.
show call rsvp-sync stats Displays statistics for calls that attempted RSVP reservation.

DB-210 May 2008
Debug Commands
debug call threshold
debug call threshold

To see details of the trigger actions, use the debug call threshold command in privileged EXEC mode.
debug call threshold module
no debug call threshold
Syntax Description module The module argument can be one of the following:
coreTraces the resource information.
detailTraces for detail information.
Defaults Disabled

12.2(2)XA This command was introduced.
12.2(4)T The command was integrated into Cisco IOS Release 12.2(4)T.
Support for the Cisco AS5300, Cisco AS5350, and Cisco AS5400 is
not included in this release.
12.2(8)T This command was integrated into Cisco IOS Release 12.2(8)T and
implemented on Cisco 7200 series routers.
12.2(11)T Support for this command was implemented on Cisco AS5850,
Cisco AS5800, Cisco AS5300, Cisco AS5350, and Cisco AS5400
series images.
Examples The following is sample output from the debug call threshold core command:
Router# debug call threshold core
RSCCAC Core info debugging is on
The following is sample output from the debug call threshold detail command:
Router# debug call threshold detail
All RSCCAC info debugging is on

May 2008 DB-211
Debug Commands
debug call treatment action

To debug the call treatment actions, use the debug call treatment action command in privileged
no debug call treatment action
Defaults Disabled

12.2(11)T Support for this command was implemented on Cisco AS5850,
Cisco AS5800, Cisco AS5300, Cisco AS5350, and Cisco AS5400
series images.
Examples Debug actions are performed on calls by call treatment. The following sample output shows that call
treatment is turned on:
Router# debug call treatment action
Call treatment action debugging is on

DB-212 May 2008
Debug Commands
debug callback
debug callback
To display callback events when the router is using a modem and a chat script to call back on a terminal
line, use the debug callback command in privileged EXEC mode. To disable debugging output, use the
debug callback
no debug callback
Usage Guidelines This command is useful for debugging chat scripts on PPP and AppleTalk Remote Access Protocol
(ARAP) lines that use callback mechanisms. The output provided by the debug callback command
shows you how the call is progressing when used with the debug ppp or debug arap commands.
Examples The following is sample output from the debug callback command:
Router# debug callback
TTY7 Callback process initiated, user: exec_test dialstring 123456

TTY7 Callback forced wait = 4 seconds
TTY7 Exec Callback Successful - await exec/autoselect pickup
TTY7: Callback in effect

debug cable env Displays ARAP events.
debug ppp Displays information on traffic and exchanges in an internetwork
implementing the PPP.

May 2008 DB-213
Debug Commands
debug call-mgmt
debug call-mgmt
To display debugging information for call accounting, including modem and time slot usage, for active
and recent calls, use the debug call-mgmt command in privileged EXEC mode. To disable debugging
debug call-mgmt
no debug call-mgmt

Examples The following is sample output after the debug call-mgmt command has been enabled:
Router# debug call-mgmt
Call Management debugging is on

Router#
Dec 26 13:57:27.710: msg_to_calls_mgmt: msg type CPM_NEW_CALL_CSM_CONNECT received
Dec 26 13:57:27.714: In actv_c_proc_message,
access type CPM_INSERT_NEW_CALL,
call type CPM_ISDN_ANALOG:
CSM completed connecting a new modem call
.
.
.
Dec 26 13:57:45.906: msg_to_calls_mgmt: msg type CPM_NEW_CALL_ISDN_CONNECT received
access type CPM_INSERT_NEW_CALL,
Added a new ISDN analog call to the active-calls list
CC-Slot#7, DSX1-Ctrlr#17, DS0-Timeslot#1
Mdm-Slot#1, Mdm-Port#3, TTY#219
.
.
.
Dec 26 13:58:25.682: Call mgmt per minute statistics:
active list length: 1

DB-214 May 2008
Debug Commands
debug call-mgmt
history list length: 3

Dec 26 13:58:25.682: 0 timeslots active at slot 7, ctrlr 1
Router# clear int as1/03
Dec 26 13:58:26.538: msg_to_calls_mgmt: msg type CPM_VOICE_CALL_REJ_NO_MOD_AVAIL received

access type CPM_REMOVE_DISC_CALL,
Removed a disconnected ISDN analog call
CC-Slot#7, DSX1-Ctrlr#17, DS0-Timeslot#1
Dec 26 13:58:26.538: Mdm-Slot#1, Mdm-Port#3, TTY#219
Table 43 debug call-mgmt Field Descriptions
Field Description
CPM_NEW_CALL_CSM_CONNECT Indicates the arrival of a new call.
access type CPM_INSERT_NEW_CALL, Indicates that the new call is an analog ISDN B channel
call (either a voice call or a call over an analog modem),
rather than a digital (V.110) call.
CC-Slot#7, DSX1-Ctrlr#17, Indicates that the call is connected via the B channel on
DS0-Timeslot#1 Serial7/17:1 to the asynchronous modem resource 1/03
Mdm-Slot#1, Mdm-Port#3, TTY#219 (interface async1/03, also known as line tty219).
Dec 26 13:58:25.682: Call mgmt per minute Displays periodic statistics that give the allocation state
statistics: of each DSX1 interface present in the system, as well as
the number of current (active) and recent (history) calls.
active list length: 1
history list length: 3

May 2008 DB-215
Debug Commands
debug call-mgmt
Table 43 debug call-mgmt Field Descriptions (continued)
Field Description
Dec 26 13:58:26.538: msg_to_calls_mgmt: Indicates that the analog ISDN B channel call has been
msg type disassociated from a modem.
CPM_VOICE_CALL_REJ_NO_MOD_
AVAIL received
access type Indicates that the analog ISDN B channel call has been
CPM_REMOVE_DISC_CALL, disconnected.
Removed a disconnected ISDN analog call
CC-Slot#7, DSX1-Ctrlr#17, Indicates that the call has been disconnected via the
DS0-Timeslot#1 B channel on Serial7/17:1 to the asynchronous modem
resource 1/03 (interface async1/03, also known as line
Dec 26 13:58:26.538: Mdm-Slot#1,
tty219).
Mdm-Port#3, TTY#219

DB-216 May 2008
Debug Commands
debug capf-server
debug capf-server
To collect debug information about the CAPF server, use the debug capf-server command in privileged
EXEC mode. To disable collection of debug information, use the no form of this command.
debug capf-server {all | error | events | messages}
no debug capf-server
Syntax Description all Collect all CAPF information available.

error Collect only information about CAPF errors.
events Collect only information about CAPF status events.
messages Collect only CAPF system messages.
Command Default Collection of CAPF debug information is disabled.
Command History Cisco IOS Release Modification

12.4(4)XC This command was introduced.
Usage Guidelines This command is used with Cisco Unified CallManager Express phone authentication.
Examples The following example shows debug messages for the CAPF server.
Router# debug capf-server all
001891: .Jul 21 18:17:07.014: %IPPHONE-6-UNREGISTER_NORMAL: ephone-1:SEP000E325C9A43

IP:10.10.10.194 So
cket:3 DeviceType:Phone has unregistered normally.
001892: .Jul 21 18:17:20.495: New Connection from phone, socket 1
001893: .Jul 21 18:17:20.495: Created New Handshake Process
001894: .Jul 21 18:17:20.499: SSL Handshake Error -6983
001896: .Jul 21 18:17:22.555: SSL Handshake Successful
001897: .Jul 21 18:17:22.555: ephone_capf_send_auth_req:
001898: .Jul 21 18:17:22.555: ephone_capf_ssl_write: 12 bytes
001899: .Jul 21 18:17:22.711: ephone_capf_ssl_read: Read 35 bytes
001900: .Jul 21 18:17:22.711: ephone_capf_handle_phone_msg: msgtype 2
001901: .Jul 21 18:17:22.711: ephone_capf_process_auth_res_msg: SEP000E325C9A43 AuthMode 2
001902: .Jul 21 18:17:22.711: ephone_capf_send_delete_cert_req_msg: SEP000E325C9A43

May 2008 DB-217
Debug Commands
debug capf-server

001906: .Jul 21 18:17:23.891: certificate delete successful for SEP000E325C9A43
001907: .Jul 21 18:17:24.695: ephone_capf_release_session: SEP000E325C9A43
001908: .Jul 21 18:17:24.695: ephone_capf_send_end_session_msg: SEP000E325C9A43
001910: .Jul 21 18:17:25.095: %IPPHONE-6-REG_ALARM: 22: Name=SEP000E325C9A43 Load=7.2(2.0)
Last=Rese
t-Reset
001911: .Jul 21 18:17:25.099: %IPPHONE-6-REGISTER: ephone-1:SEP000E325C9A43
IP:10.10.10.194 Socket:2 De
viceType:Phone has registered.
001912: .Jul 21 18:18:05.171: %IPPHONE-6-UNREGISTER_NORMAL: ephone-1:SEP000E325C9A43

IP:1.1.1.127 So
cket:2 DeviceType:Phone has unregistered normally.
001913: .Jul 21 18:18:18.288: New Connection from phone, socket 1
001914: .Jul 21 18:18:18.288: Created New Handshake Process
001917: .Jul 21 18:18:20.348: SSL Handshake Successful
001918: .Jul 21 18:18:20.348: ephone_capf_send_auth_req:
001919: .Jul 21 18:18:20.348: ephone_capf_ssl_write: 12 bytes^Z

001922: .Jul 21 18:18:20.492: ephone_capf_process_auth_res_msg: SEP000E325C9A43 AuthMode 2
001923: .Jul 21 18:18:20.492: ephone_capf_send_PhKeyGenReq_msg: SEP000E325C9A43 KeySize
1024
001927: .Jul 21 18:18:20.540: ephone_capf_process_req_in_progress: SEP000E325C9A43 delay
0sh
001928: .Jul 21 18:18:21.924: %SYS-5-CONFIG_I: Configured from console by user1 on console

DB-218 May 2008
Debug Commands
debug cas
debug cas
To debug channel-associated signaling (CAS) messages and to debug the establishment of a
time-division multiplexing (TDM) connection between a DS0 and a digital modem, use the debug cas
debug cas slot slot number port port number
no debug cas slot slot number port port number
Syntax Description slot slot number Slot and slot number. Valid values are 0 and 1.
port port number Port and port number. Valid values are 0 and 1.
Defaults Disabled

12.0(7)T This command was introduced for the Cisco AS5200 and AS5300 platforms.
12.2(2)T This command was integrated into Cisco IOS Release 12.2(2)T and support
was added for the Cisco 2600 series and Cisco 3600 series platforms.
12.3(1) This command was integrated into Cisco IOS Release 12.3(1) and support
was added for the Cisco 2600 XM series, Cisco 2691, and Cisco 3700 series
platforms.
Usage Guidelines When the NM-xCE1T1PRI network module is used with an NM-xDM and a DS0-group is configured
under the controller, you can use the debug cas command to debug CAS signaling messages and the
establishment of a TDM connection between a DS0 and a digital modem. Use the debug cas command
to identify and troubleshoot call connection problems on a T1/E1 interface. With this command, you can
trace the complete sequence of incoming and outgoing calls.
Examples The following shows an example session to enable debugging CAS and generate troubleshooting output:
Router# show debug
Router# debug cas slot 1 port 0
CAS debugging is on
Router#

May 2008 DB-219
Debug Commands
debug cas
debug-cas is on at slot(1) dsx1(0)
Router# show debug
CAS debugging is on
The following example shows output for the first outgoing call:
Router# p 1.1.1.2
Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
*Mar 2 00:17:45: dsx1_alloc_cas_channel: channel 0 dsx1_timeslot
1(0/0): TX SEIZURE (ABCD=0001)(0/0): RX SEIZURE_ACK (ABCD=1101)(0/1):
RX_IDLE (ABCD=1001)(0/2): RX_IDLE (ABCD=1001)(0/3): RX_IDLE
(ABCD=1001)(0/4): RX_IDLE (ABCD=1001)(0/5): RX_IDLE (ABCD=1001)(0/6):
(ABCD=1001)(0/20): RX_IDLE (ABCD=1001)(0/21): RX_IDLE
(ABCD=1001).(0/22): RX_IDLE (ABCD=1001)(0/23): RX_IDLE
(ABCD=1001)(0/29): RX_IDLE (ABCD=1001)(0/30): RX_IDLE
(ABCD=1001)...(0/0): RX ANSWERED (ABCD=0101).
Success rate is 0 percent (0/5)
Router#
*Mar 2 00:18:13.333: %LINK-3-UPDOWN: Interface Async94, changed state to up
*Mar 2 00:18:13.333: %DIALER-6-BIND: Interface As94 bound to profile Di1
*Mar 2 00:18:14.577: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async94, changed
state to up
Router# p 1.1.1.2

!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 160/180/236 ms
The following example shows that the call is cleared on the router:
Router# clear int dialer 1
Router#
(0/0): TX IDLE (ABCD=1001)(0/0): RX IDLE (ABCD=1001)
*Mar 2 00:18:28.617: %LINK-5-CHANGED: Interface Async94, changed state to reset
*Mar 2 00:18:28.617: %DIALER-6-UNBIND: Interface As94 unbound from profile Di1
state to down
et2-c3745-1#
*Mar 2 00:18:33.617: %LINK-3-UPDOWN: Interface Async94, changed state to down
The following example shows a subsequent outbound CAS call:

Router# p 1.1.1.2

6(0/5): TX SEIZURE (ABCD=0001)(0/5): RX SEIZURE_ACK
(ABCD=1101)....(0/5): RX ANSWERED (ABCD=0101).

DB-220 May 2008
Debug Commands
debug cas
Router#
state to up
Router# p 1.1.1.2

!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 160/167/176
ms
The following example shows the call cleared by the switch:

Router#
(0/5): TX IDLE (ABCD=1001)(0/5): RX IDLE (ABCD=1001)
*Mar 2 00:19:26.249: %LINK-5-CHANGED: Interface Async93, changed state to reset
*Mar 2 00:19:26.249: %DIALER-6-UNBIND: Interface As93 unbound from profile Di1
state to down
Router#
*Mar 2 00:19:31.249: %LINK-3-UPDOWN: Interface Async93, changed state to down
The following example shows an incoming CAS call:

Router#
(0/0): RX SEIZURE (ABCD=0001)
1(0/0): TX SEIZURE_ACK (ABCD=1101)(0/0): TX ANSWERED (ABCD=0101)
Router#
state to up

show debug Displays information about the types of debugging that are enabled for your
router.

May 2008 DB-221
Debug Commands
debug ccaal2 session

To display the ccaal2 function calls during call setup and teardown, use the debug ccaal2 session
no debug ccaal2 session
Defaults Debugging for ATM Adaptation Layer type 2 (AAL2) sessions is not enabled.

12.1(1)XA This command was introduced for the Cisco MC3810 series.
12.1(2)T This command was integrated in Cisco IOS Release 12.1(2)T.
12.2(2)T Support for this command was implemented on the Cisco 7200 series
routers.
Usage Guidelines Use this command when troubleshooting an AAL2 trunk setup or teardown problem.
Examples The following example shows sample output from the debug ccaal2 session command for a forced
shutdown of a voice port:
Router# debug ccaal2 session
CCAAL2 Session debugging is on

Router(config)# voice-port 2/0:0
Router(config-voiceport)# shutdown
00:32:45:ccaal2_call_disconnect:peer tag 0
00:32:45:ccaal2_evhandle_call_disconnect:Entered
00:32:45:ccaal2_call_cleanup:freeccb 1, call_disconnected 1
00:32:45:starting incoming timer:Setting accept_incoming to FALSE and
00:32:45:timer 2:(0x622F6270)starts - delay (70000)
00:32:45:ccaal2_call_cleanup:Generating Call record
00:32:45:cause=81 tcause=81 cause_text=unspecified

DB-222 May 2008
Debug Commands
00:32:45:ccaal2_call_cleanup:ccb 0x63FF1700, vdbPtr 0x62DFF2E0

freeccb_flag=1, call_disconnected_flag=1
00:32:45:%LINK-3-UPDOWN:Interface recEive and transMit2/0:0(1),
changed state to Administrative Shutdown
The following example shows sample output from the debug ccaal2 session command for a trunk setup
on a voice port:
Router# debug ccaal2 session
Router(config-voiceport)# no shutdown
Router(config-voiceport)#
00:35:28:%LINK-3-UPDOWN:Interface recEive and transMit2/0:0(1),
changed state to up
00:35:35:ccaal2_call_setup_request:Entered
00:35:35:ccaal2_evhandle_call_setup_request:Entered
00:35:35:ccaal2_initialize_ccb:preferred_codec set(-1)(0)
00:35:35:ccaal2_evhandle_call_setup_request:preferred_codec
set(5)(40). VAD is 1
00:35:35:ccaal2_call_setup_trunk:subchannel linking
successfulccaal2_receive:xmitFunc is NULL
00:35:35:ccaal2_caps_ind:PeerTag = 49
00:35:35: codec(preferred) = 1, fax_rate = 2, vad = 2
00:35:35: cid = 56, config_bitmask = 258, codec_bytes = 40,
signal_type=8
00:35:36:%HTSP-5-UPDOWN:Trunk port(channel) [2/0:0(1)] is up
Router(config-voiceport)#

show debug Shows which debug commands are enabled.

May 2008 DB-223
Debug Commands
debug ccfrf11 session

To display the ccfrf11 function calls during call setup and teardown, use the debug ccfrf11 session
no debug ccfrf11 session

12.0(3)XG This command was introduced for the Cisco 2600 and Cisco 3600 series
routers.
12.0(7)XK This command was first supported on the Cisco MC3810 series.
12.1(2)T Support for this command was implemented in Cisco MC3810 images.
Usage Guidelines Use this command to display debug information about the various FRF.11 VoFR service provider
interface (SPI) functions. Note that this debug command does not display any information regarding the
proprietary Cisco switched-VoFR SPI.
This debug is useful only when the session protocol is frf11-trunk.
Examples The following is sample output from the debug ccfrf11 session command:
Router# debug ccfrf11 session
INCOMING CALL SETUP (port setup for answer-mode):

*Mar 6 18:04:07.693:ccfrf11_process_timers:scb (0x60EB6040) timer (0x60EB6098) expired
*Mar 6 18:04:07.693:Setting accept_incoming to TRUE
*Mar 6 18:04:11.213:ccfrf11_incoming_request:peer tag 800:callingNumber=+2602100,
calledNumber=+3622110
*Mar 6 18:04:11.213:ccfrf11_initialize_ccb:preffered_codec set(-1)(0)
*Mar 6 18:04:11.213:ccfrf11_evhandle_incoming_call_setup_request:calling +2602100,
called +3622110 Incoming Tag 800
*Mar 6 18:04:11.217:ccfrf11_caps_ind:PeerTag = 800
*Mar 6 18:04:11.217: codec(preferred) = 4, fax_rate = 2, vad = 2
*Mar 6 18:04:11.217: cid = 30, config_bitmask = 0, codec_bytes = 20, signal_type=2
*Mar 6 18:04:11.217: required_bandwidth 8192
*Mar 6 18:04:11.217:ccfrf11_caps_ind:Bandwidth reservation of 8192 bytes succeeded.

DB-224 May 2008
Debug Commands
*Mar 6 18:04:11.221:ccfrf11_evhandle_call_connect:Entered
CALL SETUP (MASTER):

5d22h:ccfrf11_call_setup_request:Entered
5d22h:ccfrf11_evhandle_call_setup_request:Entered
5d22h:ccfrf11_initialize_ccb:preffered_codec set(-1)(0)
5d22h:ccfrf11_evhandle_call_setup_request:preffered_codec set(9)(24)
5d22h:ccfrf11_call_setup_trunk:subchannel linking successful
5d22h:ccfrf11_caps_ind:PeerTag = 810
5d22h: codec(preferred) = 512, fax_rate = 2, vad = 2
5d22h: cid = 30, config_bitmask = 1, codec_bytes = 24, signal_type=2
5d22h: required_bandwidth 6500
5d22h:ccfrf11_caps_ind:Bandwidth reservation of 6500 bytes succeeded.
CALL TEARDOWN:
*Mar 6 18:09:14.805:ccfrf11_call_disconnect:peer tag 0
*Mar 6 18:09:14.805:ccfrf11_evhandle_call_disconnect:Entered
*Mar 6 18:09:14.805:ccfrf11_call_cleanup:freeccb 1, call_disconnected 1
*Mar 6 18:09:14.805:ccfrf11_call_cleanup:Setting accept_incoming to FALSE and starting
incoming timer
*Mar 6 18:09:14.809:timer 2:(0x60EB6098)starts - delay (70000)
*Mar 6 18:09:14.809:ccfrf11_call_cleanup:Alive timer stopped
*Mar 6 18:09:14.809:timer 1:(0x60F64104) stops
*Mar 6 18:09:14.809:ccfrf11_call_cleanup:Generating Call record
*Mar 6 18:09:14.809:cause=10 tcause=10 cause_text="normal call clearing."
*Mar 6 18:09:14.809:ccfrf11_call_cleanup:Releasing 8192 bytes of reserved bandwidth
*Mar 6 18:09:14.809:ccfrf11_call_cleanup:ccb 0x60F6404C, vdbPtr 0x610DB7A4
freeccb_flag=1, call_disconnected_flag=1

debug call rsvp-sync events Displays the ccswvoice function calls during call setup and
teardown.
debug ccswvoice vofr-session Displays the ccswvoice function calls during call setup and
teardown.
debug vtsp session Displays the first 10 bytes (including header) of selected VoFR
subframes for the interface.

May 2008 DB-225
Debug Commands
debug cch323 capacity

To track the call capacity of the gatekeeper, use the debug cch323 capacity command in privileged
no debug cch323 capacity

Usage Guidelines Use the debug cch323 capacity command to track the maximum and current call capacity values in the
Registration, Admission, and Status (RAS) Protocol messages and to debug capacity-related problems
while sending RAS messages. This command is entered on the gateway to monitor the call capacity of
the gatekeeper.
The command lists the values for current and maximum call capacity provided by the trunk group
capacity resource manager if and when the H.323 Service Provider Interface (SPI) requests the
information for all or specific groups of circuits.
Examples The following is sample output from the debug cch323 capacity command:
Router# debug cch323 capacity
Call Capacity Information tracing is enabled
5d00h: cch323_process_carrier_update: Registered = 1,Event = 1,Reason = 1

5d00h: cch323_process_carrier_update: CarrierId = CARRIERA_NEWENGLAND
5d00h: cch323_fill_crm_CallCapacities: Reason = 1, GroupID = CARRIERA_NEWENGLAND
5d00h: Capacity Details: Maximum Channels in Group: 23
Max. Voice Calls(In) : 23, Max. Voice Calls(Out): 23
Active Voice Calls(In): 5, Active Voice Calls(Out): 7
Max. Voice Calls(to GK): 23, Avail. Voice Calls(to GK): 11
The gatekeeper displays this output when trunk groups are added, deleted, or modified or when circuits
in a trunk group are deactivated or activated (similar to ISDN layer 2 down/up).

DB-226 May 2008
Debug Commands
5d00h: cch323_process_carrier_update: Registered = 1,Event = 1,Reason = 1

5d00h: cch323_process_carrier_update: CarrierId = CARRIERA_NEWENGLAND
Table 44 debug cch323 capacity Update Field Descriptions
Field Description
Registered Gateway registration:
0=Gateway is not registered to the gatekeeper
1=Gateway is registered to the gatekeeper at the time of
the change
Event Carriers updated:
0=All carriers updated
1=Single carrier updated
Reason Reason for the update notification:
0=CURRENT_CAPACITY_UPDATE
1=MAX_CAPACITY_UPDATE
2=BOTH_CAPACITY_UPDATE
CarrierID ID of the trunk group or carrier to which the change applies.
The gatekeeper displays this output whenever call capacity information is sent to the gatekeeper.
5d00h: cch323_fill_crm_CallCapacities: Reason = 1, GroupID = CARRIERA_NEWENGLAND
5d00h: Capacity Details: Maximum Channels in Group: 23
Max. Voice Calls(In) : 23, Max. Voice Calls(Out): 23
Active Voice Calls(In): 5, Active Voice Calls(Out): 7
Max. Voice Calls(to GK): 23, Avail. Voice Calls(to GK): 11
Table 45 debug cch323 capacity Call Capacity Field Descriptions
Field Description
GroupID The circuits carrier identification (ID) or trunk
group label.
Maximum Channels in Group Maximum number of physical (or configured)
circuits.
Max. Voice Calls(In) Maximum number of allowed incoming voice and
data calls.
Max. Voice Calls(Out) Maximum number of allowed outgoing voice and
data calls.
Active Voice Calls(In) Current number of active incoming voice and data
calls.
Active Voice Calls(Out) Current number of active outgoing voice and data
calls.

May 2008 DB-227
Debug Commands
Table 45 debug cch323 capacity Call Capacity Field Descriptions (continued)
Field Description
Max. Voice Calls(to GK) Maximum call capacity value to be sent to the
gatekeeper in the RAS message.
Avail. Voice Calls(to GK) Available call capacity value to be sent to the
gatekeeper in the RAS message.

endpoint circuit-id h323id Associates a carrier with a non-Cisco endpoint.

DB-228 May 2008
Debug Commands
debug cch323 h225
debug cch323 h225

To provide the trace of the state transition of the H.225 state machine based on the processed events, use
the debug cch323 h225 command in privileged EXEC mode. To disable debugging output, use the no
debug cch323 h225
no debug cch323 h225
Defaults Disabled

11.3(6)NA2 This command was introduced.
Usage Guidelines State Descriptions

The state definitions of the different states of the H.225 state machine are as follows:
H225_IDLEThis is the initial state of the H.225 state machine. The H.225 state machine is in this
state before issuing a call setup request (for the outbound IP call case) or ready to receive an
incoming IP call.
H225_SETUPThis is the call setup state. The state machine transitions to this state after sending
out a call setup request, or after the reception of an incoming call indication.
H225_ALERTThis is the call alerting state. The state machine transitions to this state after
sending the alerting message or after the reception of an alerting message from the peer.
H225_CALLPROCThis is the call proceeding state.
H225_ACTIVEThis is the Call connected state. In this state, the call is active. The state machine
transitions to this state after sending the connect message to the peer or after the reception of the
connect message from the peer.
H225_WAIT_FOR_ARQThis is the state where the H.225 state machine is waiting for the
completion of the ARQ process from the Registration, Admission, and Status Protocol (RAS) state
machine.

May 2008 DB-229
Debug Commands
debug cch323 h225
H225_WAIT_FOR_DRQThis is the state where the H.225 state machine is waiting for the
completion of the DRQ process from the RAS state machine.
H225_WAIT_FOR_H245This is the state where the H.225 state machine is waiting for the
success or failure from the H.245 state machine.
Events Description
The event definitions of the different events of the H.225 state machine are as follows:
H225_EVENT_NONE No event.
H225_EVENT_ALERTThis event indicates the H.225 state machine to send an alerting message
to the peer.
H225_EVENT_ALERT_INDThis event indicates the H.225 state machine that an alerting
message is received from the peer.
H225_EVENT_CALLPROCThis event indicates the H.225 state machine to send a call
proceeding message to the peer.
H225_EVENT_CALLPROC_INDThis event indicates the H.225 state machine that a call
proceeding message is received from the peer.
H225_EVENT_REJECTThis event indicates the H.225 state machine to reject the call setup
request from the peer.
H225_EVENT_REJECT_INDThis event indicates the H.225 state machine that a call setup
request to the peer is rejected.
H225_EVENT_RELEASEThis event indicates the H.225 state machine to send a release
complete message to the peer.
H225_EVENT_RELEASE_INDThis event indicates the H.225 state machine that a release
complete message is received from the peer.
H225_EVENT_SETUPThis event indicates the H.225 state machine to send a setup message to
the peer.
H225_EVENT_SETUP_INDThis event indicates the H.225 state machine that a setup message is
received from the peer.
H225_EVENT_SETUP_CFMThis event indicates the H.225 state machine to send a connect
message to the peer.
H225_EVENT_SETUP_CFM_INDThis event indicates the H.225 state machine that a connect
message from the peer.
H225_EVENT_RAS_SUCCESSThis event indicates the H.225 state machine that the pending
RAS operation is successful.
H225_EVENT_RAS_FAILEDThis event indicates the H.225 state machine that the pending RAS
operation failed.
H225_EVENT_H245_SUCCESSThis event indicates the H.225 state machine that the pending
H.245 operation is successful.
H225_EVENT_H245_FAILEDThis event indicates the H.225 state machine that the pending
H.245 operation failed.

DB-230 May 2008
Debug Commands
debug cch323 h225
Examples The following is sample output from the debug cch323 h225 command:
Router# debug cch323 h225
20:59:17:Set new event H225_EVENT_SETUP

20:59:17:H225 FSM:received event H225_EVENT_SETUP while at state H225_IDLE
20:59:17:Changing from H225_IDLE state to H225_SETUP state
20:59:17:cch323_h225_receiver:received msg of type SETUPCFM_CHOSEN
20:59:17:H225 FSM:received event H225_EVENT_SETUP_CFM_IND while at state
H225_SETUP
20:59:17:Changing from H225_SETUP state to H225_ACTIVE state
20:59:17:Set new event H225_EVENT_H245_SUCCESS
20:59:17:H225 FSM:received event H225_EVENT_H245_SUCCESS while at state
H225_ACTIVE
20:59:20:Set new event H225_EVENT_RELEASE
20:59:20:H225 FSM:received event H225_EVENT_RELEASE while at state
H225_ACTIVE
20:59:20:Changing from H225_ACTIVE state to H225_WAIT_FOR_DRQ state
20:59:20:Set new event H225_EVENT_RAS_SUCCESS
20:59:20:H225 FSM:received event H225_EVENT_RAS_SUCCESS while at state
H225_WAIT_FOR_DRQ
20:59:20:Changing from H225_WAIT_FOR_DRQ state to H225_IDLE state

May 2008 DB-231
Debug Commands
debug cch323 h245
debug cch323 h245

To provide the trace of the state transition of the H.245 state machine based on the processed events, use
the debug cch323 h245 command in privileged EXEC mode. To disable debugging output, use the no
debug cch323 h245
no debug cch323 h245
Defaults Disabled

Usage Guidelines The H.245 state machines include the following three state machines:
Master SlaveDetermination (MSD) state machine
Capability Exchange (CAP) state machine
Open Logical Channel (OLC) state machine
State Definitions
The definitions are as follows:
H245_MS_NONE This is the initial state of the master slave determination state machine.
H245_MS_WAITIn this state, a Master Slave Determination message is sent, waiting for the
reply.
H245_MS_DONE The result is in.
H245_CAP_NONEThis is the initial state of the capabilities exchange state machine.
H245_CAP_WAITIn this state, a cap exchange message is sent, waiting for reply.
H245_CAP_DONEThe result is in.
H245_OLC_NONEThis is the initial state of the open logical channel state machine.

DB-232 May 2008
Debug Commands
debug cch323 h245
H245_OLC_WAIT: OLC message sent, waiting for reply.

H245_OLC_DONE: OLC done.
Event definitions
H245_EVENT_MSDSend MSD message
H245_EVENT_MS_CFMSend MSD acknowledge message
H245_EVENT_MS_REJSend MSD reject message
H245_EVENT_MS_IND Received MSD message
H245_EVENT_CAPSend CAP message
H245_EVENT_CAP_CFMSend CAP acknowledge message
H245_EVENT_CAP_REJSend CAP reject
H245_EVENT_CAP_INDReceived CAP message
H245_EVENT_OLCSend OLC message
H245_EVENT_OLC_CFMSend OLC acknowledge message
H245_EVENT_OLC_REJSend OLC reject message
H245_EVENT_OLC_INDReceived OLC message
Examples The following is sample output from the debug cch323 h245 command:
20:58:23:Changing to new event H245_EVENT_MSD

20:58:23:H245 MS FSM:received event H245_EVENT_MSD while at state
H245_MS_NONE
20:58:23:changing from H245_MS_NONE state to H245_MS_WAIT state
20:58:23:Changing to new event H245_EVENT_CAP
20:58:23:H245 CAP FSM:received event H245_EVENT_CAP while at state
H245_CAP_NONE
20:58:23:changing from H245_CAP_NONE state to H245_CAP_WAIT state
20:58:23:cch323_h245_receiver:received msg of type
M_H245_MS_DETERMINE_INDICATION
20:58:23:Changing to new event H245_EVENT_MS_IND
20:58:23:H245 MS FSM:received event H245_EVENT_MS_IND while at state
H245_MS_WAIT
M_H245_CAP_TRANSFER_INDICATION
20:58:23:Changing to new event H245_EVENT_CAP_IND
20:58:23:H245 CAP FSM:received event H245_EVENT_CAP_IND while at state
H245_CAP_WAIT
M_H245_MS_DETERMINE_CONFIRM
20:58:23:Changing to new event H245_EVENT_MS_CFM
20:58:23:H245 MS FSM:received event H245_EVENT_MS_CFM while at state
H245_MS_WAIT
20:58:23:changing from H245_MS_WAIT state to H245_MS_DONE state
0:58:23:cch323_h245_receiver:received msg of type M_H245_CAP_TRANSFER_CONFIRM
20:58:23:Changing to new event H245_EVENT_CAP_CFM
20:58:23:H245 CAP FSM:received event H245_EVENT_CAP_CFM while at state
H245_CAP_WAIT
20:58:23:changing from H245_CAP_WAIT state to H245_CAP_DONE state
20:58:23:Changing to new event H245_EVENT_OLC
20:58:23:H245 OLC FSM:received event H245_EVENT_OLC while at state

May 2008 DB-233
Debug Commands
debug cch323 h245
H245_OLC_NONE
20:58:23:changing from H245_OLC_NONE state to H245_OLC_WAIT state
M_H245_UCHAN_ESTABLISH_INDICATION
20:58:23:Changing to new event H245_EVENT_OLC_IND
20:58:23:H245 OLC FSM:received event H245_EVENT_OLC_IND while at state
H245_OLC_WAIT
20:58:23:cch323_h245_receiver:received msg of type M_H245_UCHAN_ESTAB_ACK
20:58:23:Changing to new event H245_EVENT_OLC_CFM
20:58:23:H245 OLC FSM:received event H245_EVENT_OLC_CFM while at state
H245_OLC_WAIT
20:58:23:changing from H245_OLC_WAIT state to H245_OLC_DONE state

DB-234 May 2008
Debug Commands
debug cch323 preauth

To enable diagnostic reporting of authentication, authorization, and accounting (AAA) call
preauthentication for H.323 calls, use the debug cch323 preauth command in privileged EXEC mode.
no debug cch323 preauth

Examples The following is debugging output for a single H.323 call:

Router# debug cch323 preauth
CCH323 preauth tracing is enabled

cch323_is_preauth_reqd is TRUE
Jan 23 18:39:56.393: In cch323_send_preauth_req for preauth_id = -1
Jan 23 18:39:56.393: Entering rpms_proc_print_preauth_req
Jan 23 18:39:56.393: Request = 0

Jan 23 18:39:56.393: Preauth id = 86514
Jan 23 18:39:56.393: EndPt Type = 1
Jan 23 18:39:56.393: EndPt = 192.168.81.102
Jan 23 18:39:56.393: Resource Service = 1
Jan 23 18:39:56.393: Call_origin = answer
Jan 23 18:39:56.393: Call_type = voip
Jan 23 18:39:56.393: Calling_num = 2230001
Jan 23 18:39:56.393: Called_num = 1#1130001
Jan 23 18:39:56.393: Protocol = 0
Jan 23 18:39:56.393: cch323_insert_preauth_tree:Created node with preauth_id = 86514 ,ccb
6852D5BC , node 651F87FC
Jan 23 18:39:56.393:rpms_proc_create_node:Created node with preauth_id = 86514
Jan 23 18:39:56.393:rpms_proc_send_aaa_req:uid got is 466725
Jan 23 18:39:56.397:rpms_proc_preauth_response:Context is for preauth_id 86514, aaa_uid
466725
Jan 23 18:39:56.397: Entering Function cch323_rpms_proc_callback_func

May 2008 DB-235
Debug Commands
Jan 23 18:39:56.397:cch323_rpms_proc_callback_func:PREAUTH_SUCCESS for preauth id 86514

aaa_uid 466725 auth_serv 1688218168
Jan 23 18:39:56.397:rpms_proc_preauth_response:Deleting Tree node for preauth id 86514 uid

466725
Jan 23 18:39:56.397:cch323_get_ccb_and_delete_from_preauth_tree:Preauth_id=86514
cch323_get_ccb_and_delete_from_preauth_tree:651F87FC node and 6852D5BC ccb
Table 46 debug cch323 preauth Field Descriptions
Field Description
Request Request Type0 for preauthentication, 1 for disconnect.
Preauth id Identifier for the preauthentication request.
EndPt Type Call Origin End Point Type1 for IP address, 2 for IZCT value.
EndPt Call Origin End Point ValueAn IP address or IZCT value.
Resource Service Resource Service Type1 for Reservation, 2 for Query.
Call_origin Answer.
Call_type Voice over IP (VoIP).
Calling_num Calling Party Number (CLID).
Called_num Called Party Number (DNIS).
Protocol 0 for H.323, 1 for SIP.
function reports Various identifiers and status reports for executed functions.

DB-236 May 2008
Debug Commands
debug cch323 ras
debug cch323 ras

To provide the trace of the state transition of the Registration, Admission, and Status (RAS) Protocol
state machine based on the processed events, use the debug cch323 ras command in privileged EXEC
debug cch323 ras
no debug cch323 ras
Defaults Disabled

Usage Guidelines RAS operates in two state machines. One global state machine controls the overall RAS operation of the
Gateway. The other state machine is a per call state machine that controls the active calls.
State definitions
The state definitions of the different states of the RAS state machine follow:
CCH323_RAS_STATE_NONEThis is the initial state of the RAS state machine.
CCH323_RAS_STATE_GRQThe state machine is in the Gatekeeper Request (GRQ) state. In this
state, the gateway is in the process of discovering a gatekeeper.
CCH323_RAS_STATE_RRQThe state machine is in the Registration Request (RRQ) state. In this
state, the gateway is in the process of registering with a gatekeeper.
CCH323_RAS_STATE_IDLEThe global state machine is in the idle state.
CCH323_RAS_STATE_URQThe state machine is in the Unregistration Request (URQ) state. In
this state, the gateway is in the process of unregistering with a gatekeeper.
CCH323_RAS_STATE_ARQThe per call state machine is in the process of admitting a new call.
CCH323_RAS_STATE_ACTIVEThe per call state machine is in the call active state.

May 2008 DB-237
Debug Commands
debug cch323 ras
CCH323_RAS_STATE_DRQThe per call state machine is in the process of disengaging an active

call.
Event Definitions
These are the event definitions of the different states of the RAS state machine:
CCH323_RAS_EVENT_NONENothing.
CCH323_RAS_EVENT_GWUPGateway is coming up.
CCH323_RAS_EVENT_GWDWNGateway is going down.
CCH323_RAS_EVENT_NEWCALLNew call.
CCH323_RAS_EVENT_CALLDISCCall disconnect.
CCH323_RAS_EVENT_GCFReceived Gatekeeper Confirmation (GCF).
CCH323_RAS_EVENT_GRJReceived Gatekeeper Rejection (GRJ).
CCH323_RAS_EVENT_ACFReceived Admission Confirmation (ACF).
CCH323_RAS_EVENT_ARJReceived Admission Rejection (ARJ).
CCH323_RAS_EVENT_SEND_RRQSend Registration Request (RRQ).
CCH323_RAS_EVENT_RCFReceived Registration Confirmation (RCF).
CCH323_RAS_EVENT_RRJReceived Registration Rejection (RRJ).
CCH323_RAS_EVENT_SEND_URQSend URQ.
CCH323_RAS_EVENT_URQReceived URQ.
CCH323_RAS_EVENT_UCFReceived Unregister Confirmation (UCF).
CCH323_RAS_EVENT_SEND_UCFSend Unregister Confirmation (UCF).
CCH323_RAS_EVENT_URJReceived Unregister Reject (URJ).
CCH323_RAS_EVENT_BCFReceived Bandwidth Confirm (BCF).
CCH323_RAS_EVENT_BRJReceived Bandwidth Rejection (BRJ).
CCH323_RAS_EVENT_DRQReceived Disengage Request (DRQ).
CCH323_RAS_EVENT_DCFReceived Disengage Confirm (DCF).
CCH323_RAS_EVENT_SEND_DCFSend Disengage Confirm (DCF).
CCH323_RAS_EVENT_DRJReceived Disengage Reject (DRJ).
CCH323_RAS_EVENT_IRQReceived Interrupt Request (IRQ).
CCH323_RAS_EVENT_IRRSend Information Request (IRR).
CCH323_RAS_EVENT_TIMEOUTMessage timeout.
Examples The following is sample output from the debug cch323 preauth command:
Router# debug cch323 preauth
20:58:49:Changing to new event CCH323_RAS_EVENT_SEND_RRQ

cch323_run_ras_sm:received event CCH323_RAS_EVENT_SEND_RRQ while at CCH323_RAS_STATE_IDLE
state
cch323_run_ras_sm:changing to CCH323_RAS_STATE_RRQ state
cch323_ras_receiver:received msg of type RCF_CHOSEN
cch323_run_ras_sm:received event CCH323_RAS_EVENT_RCF while at CCH323_RAS_STATE_RRQ state

DB-238 May 2008
Debug Commands
debug cch323 ras
cch323_run_ras_sm:changing to CCH323_RAS_STATE_IDLE state

20:58:59:cch323_percall_ras_sm:received event CCH323_RAS_EVENT_NEWCALL while at
CCH323_RAS_STATE_IDLE state
20:58:59:cch323_percall_ras_sm:changing to new state CCH323_RAS_STATE_ARQ
cch323_ras_receiver:received msg of type ACF_CHOSEN
20:58:59:cch323_percall_ras_sm:received event CCH323_RAS_EVENT_ACF while at
CCH323_RAS_STATE_ARQ state
20:58:59:cch323_percall_ras_sm:changing to new state
CCH323_RAS_STATE_ACTIVE
20:59:02:cch323_percall_ras_sm:received event CCH323_RAS_EVENT_CALLDISC while
at CCH323_RAS_STATE_ACTIVE state
20:59:02:cch323_percall_ras_sm:changing to new state CCH323_RAS_STATE_DRQ
cch323_ras_receiver:received msg of type DCF_CHOSEN
20:59:02:cch323_percall_ras_sm:received event CCH323_RAS_EVENT_DCF while at
CCH323_RAS_STATE_DRQ state
20:59:02:cch323_percall_ras_sm:changing to new state CCH323_RAS_STATE_IDLE
20:59:04:cch323_percall_ras_sm:received event CCH323_RAS_EVENT_IRR while at
CCH323_RAS_STATE_ACTIVE state

May 2008 DB-239
Debug Commands
debug cch323 video
debug cch323 video

To provide debugging output for video components within the H.323 subsystem, use the debug cch323
video command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug cch323 video
no debug cch323 video

Usage Guidelines Use this command to enable a debugging trace for the video component in an H.323 network.
Examples Originating Gateway Example

The following is sample output of the debugging log for an originating Cisco Unified CallManager
Express (Cisco Unified CME) gateway after the debug cch323 video command was enabled:
Router# show log
Syslog logging: enabled (11 messages dropped, 487 messages rate-limited,

0 flushes, 0 overruns, xml disabled, filtering disabled)
Console logging: disabled
Monitor logging: level debugging, 0 messages logged, xml disabled,
filtering disabled
Buffer logging: level debugging, 1144 messages logged, xml disabled,
filtering disabled
Logging Exception size (4096 bytes)
Count and timestamp logging messages: disabled
Trap logging: level informational, 1084 message lines logged
Log Buffer (6000000 bytes):
Jun 13 09:19:42.006: //103030/C7838B198002/H323/cch323_get_peer_info: Entry

Jun 13 09:19:42.006: //103030/C7838B198002/H323/cch323_get_peer_info: Have peer
Jun 13 09:19:42.006: //103030/C7838B198002/H323/cch323_set_pref_codec_list: First
preferred codec(bytes)=16(20)
Jun 13 09:19:42.006: //103030/C7838B198002/H323/cch323_get_peer_info: Flow Mode set to
FLOW_THROUGH

DB-240 May 2008
Debug Commands
debug cch323 video
Jun 13 09:19:42.006: //103030/C7838B198002/H323/cch323_get_caps_chn_info: No peer leg

setup params
Jun 13 09:19:42.006: //103030/C7838B198002/H323/cch323_get_caps_chn_info: Setting
CCH323_SS_NTFY_VIDEO_INFO
Jun 13 09:19:42.006: //103030/C7838B198002/H323/cch323_set_h323_control_options_outgoing:
h245 sm mode = 8463
Jun 13 09:19:42.006: //103030/C7838B198002/H323/cch323_set_h323_control_options_outgoing:
h323_ctl=0x20
Jun 13 09:19:42.010: //103030/C7838B198002/H323/cch323_rotary_validate: No peer_ccb
available
Terminating Gateway Example

The following is sample output of the debugging log for a terminating Cisco Unified Survivable Remote
Site Telephony (Cisco Unified SRST) gateway after the debug cch323 video command was enabled:
Router# show log
Syslog logging: enabled (11 messages dropped, 466 messages rate-limited,

0 flushes, 0 overruns, xml disabled, filtering disabled)
Console logging: disabled
Monitor logging: level debugging, 0 messages logged, xml disabled,
filtering disabled
Buffer logging: level debugging, 829 messages logged, xml disabled,
filtering disabled
Logging Exception size (4096 bytes)
Count and timestamp logging messages: disabled
Trap logging: level informational, 771 message lines logged
Log Buffer (200000 bytes):
Jun 13 09:19:42.011: //103034/C7838B198002/H323/setup_ind: Receive bearer cap infoXRate

24, rateMult 12
Jun 13 09:19:42.011: //103034/C7838B198002/H323/cch323_set_h245_state_mc_mode_incoming:
h245 state m/c mode=0x10F, h323_ctl=0x2F
Jun 13 09:19:42.015: //-1/xxxxxxxxxxxx/H323/cch245_event_handler: callID=103034
Jun 13 09:19:42.019: //-1/xxxxxxxxxxxx/H323/cch245_event_handler: Event
CC_EV_H245_SET_MODE: data ptr=0x465D5760
Jun 13 09:19:42.019: //-1/xxxxxxxxxxxx/H323/cch323_set_mode: callID=103034, flow Mode=1
spi_mode=0x6
Jun 13 09:19:42.019: //103034/C7838B198002/H323/cch323_do_call_proceeding: set_mode NOT
called yet...saved deferred CALL_PROC
Jun 13 09:19:42.019: //103034/C7838B198002/H323/cch323_h245_connection_sm: state=0,
event=0, ccb=4461B518, listen state=0
Jun 13 09:19:42.019: //103034/C7838B198002/H323/cch323_process_set_mode: Setting inbound
leg mode flags to 0x10F, flow-mode to FLOW_THROUGH
Jun 13 09:19:42.019: //103034/C7838B198002/H323/cch323_process_set_mode: Sending deferred
CALL_PROC
Jun 13 09:19:42.019: //103034/C7838B198002/H323/cch323_do_call_proceeding: set_mode called
so we can proceed with CALLPROC
Jun 13 09:19:42.027: //103034/C7838B198002/H323/cch323_h245_connection_sm: state=1,
event=2, ccb=4461B518, listen state=1
Jun 13 09:19:42.027: //103034/C7838B198002/H323/cch323_send_cap_request: Setting mode to
VIDEO MODE
Jun 13 09:19:42.031: //103034/C7838B198002/H323/cch323_h245_cap_ind: Masks au=0xC data=0x2
uinp=0x32

May 2008 DB-241
Debug Commands
debug cch323 video

debug ephone video Sets video debugging for the Cisco Unified IP phone.
show call active video Displays call information for SCCP video calls in progress.
show call history video Displays call history information for SCCP video calls.
show debugging Displays information about the types of debugging that are enabled for your
router.

DB-242 May 2008
Debug Commands
debug cch323
debug cch323
To provide debugging output for various components within the H.323 subsystem, use the debug cch323
debug cch323 {all | error | h225 | h245 | nxe | ras | rawmsg | session}
no debug cch323
Syntax Description all Enables all debug cch323 commands.

error Traces errors encountered in the H.323 subsystem and can be used to help
troubleshoot problems with H.323 calls.
h225 Traces the state transition of the H.225 state machine on the basis of the
processed event.
h245 Traces the state transition of the H.245 state machine on the basis of the
processed events.
nxe Displays Annex E events that have been transmitted and received.
ras Traces the state transition of the Registration, Admission, and Status (RAS)
state machine on the basis of the processed events.
rawmsg Troubleshoots raw message buffer problems.
session Traces general H.323 events and can be used to troubleshoot H.323
problems.

11.3(6)NA2 The debug cch323 command and the following keywords were introduced:
h225, h245, and ras.
12.2(2)XA The nxe keyword was added.
12.2(4)T The following keywords were introduced: all, error, rawmsg, and session.
The nxe keyword was integrated into Cisco IOS Release 12.2(4)T on all
Cisco H.323 platforms. This command does not support the Cisco access
server platforms in this release.

May 2008 DB-243
Debug Commands
debug cch323
Usage Guidelines The debug cch323 Command with the all Keyword
When used with the debug cch323 command, the all keyword provides debug output for various
components within the H.323 subsystem.
The debug cch323 command used with the all keyword enables the following debug cch323 commands:
error Enables a CCH323 Service Provider Interface (SPI) trace.

h225 Enables an H225 state machine debugging trace.
h245 Enables an H245 state machine debugging trace.
nxe Enables an Annex E debugging trace.
ras Enables a RAS state machine debugging trace.
rawmsg Enables a CCH323 RAWMSG debugging trace.
session Enables a Session debugging trace.
Caution Using the debug cch323 all command could slow your system and flood the TTY if there is significant
call traffic.
The debug cch323 Command with the error Keyword

When used with the debug cch323 command, the error keyword allows you to trace errors encountered
in the H.323 subsystem.
Note There is little or no output from this command when there is a stable H.323 network.
The debug cch323 Command with the h225 Keyword

When used with the debug cch323 command, the h225 keyword allows you to trace the state transition
of the H.225 state machine on the basis of the processed event.
The definitions of the different states of the H.225 state machine follow:
H225_IDLEThis is the initial state of the H.225 state machine. The H.225 state machine is in this
state before issuing a call setup request (for the outbound IP call case) or when ready to receive an
incoming IP call.
H225_SETUPThis is the call setup state. The state machine changes to this state after sending out
a call setup request or after receiving an incoming call indication.
H225_ALERTThis is the call alerting state. The state machine changes to this state after sending
the alerting message or after receiving an alerting message from the peer.
H225_CALLPROCThis is the call proceeding state.
H225_ACTIVEThis is the call connected state. In this state, the call is active. The state machine
changes to this state after sending the connect message to the peer or after receiving the connect
message from the peer.
H225_WAIT_FOR_ARQThis is the state in which the H.225 state machine is waiting for the
completion of the Admission Request (ARQ) process from the RAS state machine.

DB-244 May 2008
Debug Commands
debug cch323
H225_WAIT_FOR_DRQThis is the state in which the H.225 state machine is waiting for the
completion of the Disengage Request (DRQ) process from the RAS state machine.
H225_WAIT_FOR_H245This is the state in which the H.225 state machine is waiting for the
success or failure from the H.245 state machine.
The definitions of the different events of the H.225 state machine follow:
H225_EVENT_NONEThere is no event.
H225_EVENT_ALERTThis event instructs the H.225 state machine to send an alert message to
the peer.
H225_EVENT_ALERT_INDThis event indicates to the H.225 state machine that an alert
message arrived from the peer.
H225_EVENT_CALLPROCThis event instructs the H.225 state machine to send a call
proceeding message to the peer.
H225_EVENT_CALLPROC_INDThis event indicates to the H.225 state machine that a call
proceeding message has been received from the peer.
H225_EVENT_REJECTThis event instructs the H.225 state machine to reject the call setup
request from the peer.
H225_EVENT_REJECT_INDThis event indicates to the H.225 state machine that a call setup
request to the peer has been rejected.
H225_EVENT_RELEASEThis event instructs the H.225 state machine to send a release complete
H225_EVENT_RELEASE_INDThis event indicates to the H.225 state machine that a release
complete message has been received from the peer.
H225_EVENT_SETUPThis event instructs the H.225 state machine to send a setup message to
the peer.
H225_EVENT_SETUP_INDThis event indicates to the H.225 state machine that a setup message
has been received from the peer.
H225_EVENT_SETUP_CFMThis event instructs the H.225 state machine to send a connect
H225_EVENT_SETUP_CFM_INDThis event indicates to the H.225 state machine that a connect
message arrived from the peer.
H225_EVENT_RAS_SUCCESSThis event indicates to the H.225 state machine that the pending
RAS operation succeeded.
H225_EVENT_RAS_FAILEDThis event indicates to the H.225 state machine that the pending
RAS operation failed.
H225_EVENT_H245_SUCCESSThis event indicates to the H.225 state machine that the pending
H.245 operation succeeded.
H225_EVENT_H245_FAILEDThis event indicates to the H.225 state machine that the pending
H.245 operation failed.

May 2008 DB-245
Debug Commands
debug cch323
The debug cch323 Command with the h245 Keyword

When used with the debug cch323 command, the h245 keyword allows you to trace the state transition
of the H.245 state machine on the basis of the processed event.
The H.245 state machines include the following three state machines:
Master slave determination (MSD) state machine
Capability exchange (CAP) state machine
Open logical channel (OLC) state machine
The state definitions follow:
H245_MS_NONEThis is the initial state of the MSD state machine.
H245_MS_WAITIn this state, an MSD message is sent, and the device is waiting for the reply.
H245_CAP_NONEThis is the initial state of the CAP state machine.
H245_CAP_WAITIn this state, a CAP message is sent, and the device is waiting for the reply.
H245_CAP_DONEThe result is in.
H245_OLC_NONEThis is the initial state of the OLC state machine.
H245_OLC_WAITIn this state, an OLC message is sent, and the device is waiting for the reply.
H245_OLC_DONEThe result is in.
The event definitions follow:
H245_EVENT_MSDSend MSD message.
H245_EVENT_MS_CFMSend MSD acknowledge message.
H245_EVENT_MS_REJSend MSD reject message.
H245_EVENT_MS_INDReceived MSD message.
H245_EVENT_CAPSend CAP message.
H245_EVENT_CAP_CFMSend CAP acknowledge message.
H245_EVENT_CAP_REJSend CAP reject message.
H245_EVENT_CAP_INDReceived CAP message.
H245_EVENT_OLCSend OLC message.
H245_EVENT_OLC_CFMSend OLC acknowledge message.
H245_EVENT_OLC_REJSend OLC reject message.
H245_EVENT_OLC_INDReceived OLC message.
The debug cch323 Command with the nxe Keyword

When used with the debug cch323 command, the nxe keyword allows you to display the Annex E events
that have been transmitted and received.
The debug cch323 Command with the ras Keyword

When used with the debug cch323 command, the ras keyword allows you to trace the state transition of
the RAS state machine based on the processed events.
RAS operates in two state machines. One global state machine controls the overall RAS operation of the
gateway. The other state machine is a per-call state machine that controls the active calls.

DB-246 May 2008
Debug Commands
debug cch323
The definitions of the different states of the RAS state machine follow:
CCH323_RAS_STATE_NONEThis is the initial state of the RAS state machine.
CCH323_RAS_STATE_GRQThe state machine is in the Gatekeeper Request (GRQ) state. In this
state, the gateway is discovering a gatekeeper.
CCH323_RAS_STATE_RRQThe state machine is in the Registration Request (RRQ) state. In this
state, the gateway is registering with a gatekeeper.
CCH323_RAS_STATE_IDLEThe global state machine is in the idle state.
CCH323_RAS_STATE_URQThe state machine is in the Unregistration Request (URQ) state. In
this state, the gateway is in the process of unregistering with a gatekeeper.
CCH323_RAS_STATE_ARQThe per-call state machine is in the process of admitting a new call.
CCH323_RAS_STATE_ACTIVEThe per-call state machine is in the call active state.
CCH323_RAS_STATE_DRQThe per-call state machine is in the process of disengaging an active
call.
The definitions of the different events of the RAS state machine follow:
CCH323_RAS_EVENT_NONENothing.
CCH323_RAS_EVENT_GWUPGateway is coming up.
CCH323_RAS_EVENT_GWDWNGateway is going down.
CCH323_RAS_EVENT_NEWCALLNew call.
CCH323_RAS_EVENT_CALLDISCCall disconnect.
CCH323_RAS_EVENT_GCFReceived Gatekeeper Confirmation (GCF).
CCH323_RAS_EVENT_GRJReceived Gatekeeper Rejection (GRJ).
CCH323_RAS_EVENT_ACFReceived Admission Confirmation (ACF).
CCH323_RAS_EVENT_ARJReceived Admission Reject (ARJ).
CCH323_RAS_EVENT_SEND_RRQSend Registration Request (RRQ).
CCH323_RAS_EVENT_RCFReceived Registration Confirmation (RCF).
CCH323_RAS_EVENT_RRJReceived Registration Rejection (RRJ).
CCH323_RAS_EVENT_SEND_URQSend Unregistration Request (URQ).
CCH323_RAS_EVENT_URQReceived URQ.
CCH323_RAS_EVENT_UCFReceived Unregister Confirmation (UCF).
CCH323_RAS_EVENT_SEND_UCFSend UCF.
CCH323_RAS_EVENT_URJReceived Unregister Reject (URJ).
CCH323_RAS_EVENT_BCFReceived Bandwidth Confirm (BCF).
CCH323_RAS_EVENT_BRJReceived Bandwidth Rejection (BRJ).
CCH323_RAS_EVENT_DRQReceived Disengage Request (DRQ).
CCH323_RAS_EVENT_DCFReceived Disengage Confirm (DCF).
CCH323_RAS_EVENT_SEND_DCFSend DCF.
CCH323_RAS_EVENT_DRJReceived Disengage Reject (DRJ).
CCH323_RAS_EVENT_IRQReceived Interrupt Request (IRQ).
CCH323_RAS_EVENT_IRRSend Information Request (IRR).

May 2008 DB-247
Debug Commands
debug cch323
CCH323_RAS_EVENT_TIMEOUTMessage timeout.
The debug cch323 Command with the rawmsg Keyword

When used with the debug cch323 command, the rawmsg keyword allows you to troubleshoot raw
message buffer problems.
Caution Using the debug cch323 command with the rawmsg keyword could slow your system and flood the TTY
if there is significant call traffic.
The debug cch323 Command with the session Keyword

Used with the debug cch323 command, the session keyword allows you to trace general H.323 events.
Caution Using the debug cch323 session command could slow your system and flood the TTY if there is
significant call traffic.
Examples The debug cch323 Command with the all Keyword Example
The debug cch323 all command and keyword combination provides output for the following keywords:
error, h225, h245, nxe, ras, rawmsg, and session. Examples of output for each keyword follow.
The debug cch323 Command with the error Keyword Example

The following is sample output from a typical debug cch323 error request on a Cisco 3640 router:
Router# debug cch323 error
cch323_h225_receiver:received msg of unknown type 5
The debug cch323 Command with the h225 Keyword Example

The following is sample output from a typical debug cch323 h225 request on a Cisco 3640 router:
20:59:17:Set new event H225_EVENT_SETUP

20:59:17:H225 FSM:received event H225_EVENT_SETUP while at state H225_IDLE
20:59:17:Changing from H225_IDLE state to H225_SETUP state
20:59:17:cch323_h225_receiver:received msg of type SETUPCFM_CHOSEN
20:59:17:H225 FSM:received event H225_EVENT_SETUP_CFM_IND while at state
H225_SETUP
20:59:17:Changing from H225_SETUP state to H225_ACTIVE state
20:59:17:Set new event H225_EVENT_H245_SUCCESS
20:59:17:H225 FSM:received event H225_EVENT_H245_SUCCESS while at state
H225_ACTIVE
20:59:20:Set new event H225_EVENT_RELEASE
20:59:20:H225 FSM:received event H225_EVENT_RELEASE while at state
H225_ACTIVE
20:59:20:Changing from H225_ACTIVE state to H225_WAIT_FOR_DRQ state
20:59:20:Set new event H225_EVENT_RAS_SUCCESS
20:59:20:H225 FSM:received event H225_EVENT_RAS_SUCCESS while at state
H225_WAIT_FOR_DRQ
20:59:20:Changing from H225_WAIT_FOR_DRQ state to H225_IDLE state

DB-248 May 2008
Debug Commands
debug cch323
Table 47 debug cch323 h225 Field Descriptions
Field Description
H225_EVENT_SETUP This event instructs the H.225 state machine to
send a setup message to the peer.
H225_IDLE The initial state of the H.225 state machine. The
H.225 state machine is in this state before issuing
a call setup request (for the outbound IP call case)
or when ready to receive an incoming IP call.
H225_SETUP The call setup state. The state machine changes to
this state after sending out a call setup request or
after receiving an incoming call indication.
SETUPCFM_CHOSEN The H225 connect message that has been received
from a remote H323 endpoint.
H225_EVENT_SETUP_CFM_IND This event indicates to the H.225 state machine
that a connect message arrived from the peer.
H225_ACTIVE The call connected state. In this state, the call is
active. The state machine changes to this state after
sending the connect message to the peer or after
receiving the connect message from the peer.
H225_EVENT_H425_SUCCESS This event indicates to the H.225 state machine
that the pending H.245 operation succeeded.
H225_EVENT_RELEASE This event instructs the H.225 state machine to
send a release complete message to the peer.
H225_WAIT_FOR_DRQ The state in which the H.225 state machine is
waiting for the completion of the DRQ process
from the RAS state machine.
H225_EVENT_RAS_SUCCESS This event indicates to the H.225 state machine
that the pending RAS operation succeeded.
H225 FSM The finite state machine.
The debug cch323 Command with the h245 Keyword Example

The following is sample output from a typical debug cch323 h245 request on a Cisco 3640 router:
20:58:23:Changing to new event H245_EVENT_MSD

20:58:23:H245 MS FSM:received event H245_EVENT_MSD while at state
H245_MS_NONE
20:58:23:changing from H245_MS_NONE state to H245_MS_WAIT state
20:58:23:Changing to new event H245_EVENT_CAP
20:58:23:H245 CAP FSM:received event H245_EVENT_CAP while at state
H245_CAP_NONE
20:58:23:changing from H245_CAP_NONE state to H245_CAP_WAIT state
M_H245_MS_DETERMINE_INDICATION
20:58:23:Changing to new event H245_EVENT_MS_IND
20:58:23:H245 MS FSM:received event H245_EVENT_MS_IND while at state
H245_MS_WAIT

May 2008 DB-249
Debug Commands
debug cch323

M_H245_CAP_TRANSFER_INDICATION
20:58:23:Changing to new event H245_EVENT_CAP_IND
20:58:23:H245 CAP FSM:received event H245_EVENT_CAP_IND while at state
H245_CAP_WAIT
M_H245_MS_DETERMINE_CONFIRM
20:58:23:Changing to new event H245_EVENT_MS_CFM
20:58:23:H245 MS FSM:received event H245_EVENT_MS_CFM while at state
H245_MS_WAIT
20:58:23:changing from H245_MS_WAIT state to H245_MS_DONE state
0:58:23:cch323_h245_receiver:received msg of type M_H245_CAP_TRANSFER_CONFIRM
20:58:23:Changing to new event H245_EVENT_CAP_CFM
20:58:23:H245 CAP FSM:received event H245_EVENT_CAP_CFM while at state
H245_CAP_WAIT
20:58:23:changing from H245_CAP_WAIT state to H245_CAP_DONE state
20:58:23:Changing to new event H245_EVENT_OLC
20:58:23:H245 OLC FSM:received event H245_EVENT_OLC while at state
H245_OLC_NONE
20:58:23:changing from H245_OLC_NONE state to H245_OLC_WAIT state
M_H245_UCHAN_ESTABLISH_INDICATION
20:58:23:Changing to new event H245_EVENT_OLC_IND
20:58:23:H245 OLC FSM:received event H245_EVENT_OLC_IND while at state
H245_OLC_WAIT
20:58:23:cch323_h245_receiver:received msg of type M_H245_UCHAN_ESTAB_ACK
20:58:23:Changing to new event H245_EVENT_OLC_CFM
20:58:23:H245 OLC FSM:received event H245_EVENT_OLC_CFM while at state
H245_OLC_WAIT
20:58:23:changing from H245_OLC_WAIT state to H245_OLC_DONE state
Table 48 debug cch323 h245 Field Descriptions
Field Description
H245_EVENT_MSD Send MSD event message to the state machine.
H245 MS FSM An H225 master slave determination finite state
machine.
H245_MS_NONE The initial state of the MSD state machine.
H245_MS_WAIT In this state, a MSD message is sent, and the device
is waiting for the reply.
H245_EVENT_CAP Send CAP event message.
H245 CAP FSM This is the H245 terminal CAP finite state
machine.
H245_CAP_NONE The initial state of the CAP state machine.
H245_CAP_WAIT In this state, a CAP message is sent, and the device
is waiting for the reply.
M_H245_MS_DETERMINE _INDICATION The MSD message that has been received by an
H245 terminal from a remote H323 endpoint.
H245_EVENT_MS_IND Received MSD event message.
M_H245_CAP_TRANSFER_INDICATION A CAP message that has been received by the
H245 terminal from an H323 remote endpoint.

DB-250 May 2008
Debug Commands
debug cch323
Table 48 debug cch323 h245 Field Descriptions (continued)
Field Description
H245_EVENT_CAP_IND Received CAP event message.
M_H245_MS_DETERMINE_CONFIRM A confirmation message that the H245 master
slave termination message was sent.
H245_EVENT_MS_CFM Send MSD acknowledge event message.
M_H245_CAP_TRANSFER_CONFIRM An indication to the H245 terminal that the CAP
message was sent.
H245_EVENT_CAP_CFM Send CAP acknowledge event message.
H245_CAP_DONE The result is in.
H245_EVENT_OLC Send OLC event message.
H245_OLC_NONE The initial state of the OLC state machine.
H245_OLC_WAIT In this state, an OLC message is sent, and the
device is waiting for the reply.
M_H245_UCHAN_ESTABLISH_INDICATION The OLC message received by an H245 terminal
from a remote H323 endpoint.
H245_EVENT_OLC_IND Received OLC event message.
M_H245_UCHAN_ESTAB_ACK The OLC message acknowledgment received by an
H245 terminal from a remote H323 endpoint.
H245_EVENT_OLC_CFM Send OLC acknowledge event message.
H245 OLC FSM The OLC finite state machine of the H245
terminal.
H245_EVENT_OLC_CFM Send OLC acknowledge event message.
H245_OLC_DONE The result is in.
The debug cch323 Command with the nxe Keyword Example

The following is sample output from a debug cch323 nxe request:
Router# debug cch323 nxe
00:15:54:nxe_handle_usrmsg_to_remote:User Message size is 227

00:15:54:nxe_msg_send_possible:Msg put in the active Q for CRV [3, direction flag 0]
00:15:54:nxe_send_msg:H323chan returns bytes sent=241, the actual len=241, to IPaddr
[0xA4D4A02], Port [2517]
00:15:54:nxe_handle_usrmsg_to_remote:Usr Msg sent for IPaddr [0xA4D4A02], Port [2517], CRV
[3, direction flag 0]
00:15:54:nxe_parse_msg_from_remote:Msg received from IP [0xA4D4A02], Port [2517]
00:15:54:nxe_parse_msg_from_remote:Value of PDU flags = 0x2
00:15:54:nxe_parse_payload:Transport msg type, Payload flag = 0x0
00:15:54:nxe_receive_ack:Ack received for 1 pdus
00:15:54:nxe_receive_ack:Ack received for seqnum=13 from IPAddr [0xA4D4A02], Port [2517]
00:15:54:nxe_parse_payload:Static msg type, Payload flag = 0xA0
00:15:54:nxe_parse_x_static:Rx H225 msg from IPaddr [0xA4D4A02], Port [2517], CRV [3,
direction flag 0]
00:15:54:nxe_make_ackmsg:NXE ACK Msg made to ack seqnum=14
00:15:54:nxe_send_msg:H323chan returns bytes sent=16, the actual len=16, to IPaddr

May 2008 DB-251
Debug Commands
debug cch323
[0xA4D4A02], Port [2517]

00:15:54:nxe_parse_msg_from_remote:Ack sent for Destination IPaddr [0xA4D4A02], Port
[2517]
00:15:54:nxe_parse_payload:Static msg type, Payload flag = 0xA0
00:15:54:nxe_parse_x_static:Rx H225 msg from IPaddr [0xA4D4A02], Port [2517], CRV [3,
direction flag 0]
The debug cch323 Command with the ras Keyword Example

The following is sample output from a typical debug cch323 ras request on a Cisco 3640 router:
Router# debug cch323 ras
20:58:49:Changing to new event CCH323_RAS_EVENT_SEND_RRQ

cch323_run_ras_sm:received event CCH323_RAS_EVENT_SEND_RRQ while at CCH323_RAS_STATE_IDLE
state
cch323_run_ras_sm:changing to CCH323_RAS_STATE_RRQ state
cch323_ras_receiver:received msg of type RCF_CHOSEN
cch323_run_ras_sm:received event CCH323_RAS_EVENT_RCF while at CCH323_RAS_STATE_RRQ state
cch323_run_ras_sm:changing to CCH323_RAS_STATE_IDLE state
20:58:59:cch323_percall_ras_sm:received event CCH323_RAS_EVENT_NEWCALL while at
CCH323_RAS_STATE_IDLE state
20:58:59:cch323_percall_ras_sm:changing to new state CCH323_RAS_STATE_ARQ
cch323_ras_receiver:received msg of type ACF_CHOSEN
20:58:59:cch323_percall_ras_sm:received event CCH323_RAS_EVENT_ACF while at
CCH323_RAS_STATE_ARQ state
20:59:02:cch323_percall_ras_sm:received event CCH323_RAS_EVENT_CALLDISC while
at CCH323_RAS_STATE_ACTIVE state
20:59:02:cch323_percall_ras_sm:changing to new state CCH323_RAS_STATE_DRQ
cch323_ras_receiver:received msg of type DCF_CHOSEN
20:59:02:cch323_percall_ras_sm:received event CCH323_RAS_EVENT_DCF while at
CCH323_RAS_STATE_DRQ state
20:59:02:cch323_percall_ras_sm:changing to new state CCH323_RAS_STATE_IDLE
20:59:04:cch323_percall_ras_sm:received event CCH323_RAS_EVENT_IRR while at
CCH323_RAS_STATE_ACTIVE state
Table 49 debug cch323 ras Field Descriptions
Field Description
CCH323_RAS_EVENT_SEND_RRQ Send RRQ event message.
CCH323_RAS_STATE_IDLE The global state machine is in the idle state.
CCH323_RAS_STATE_RRQ The state machine is in the RRQ state. In this
state, the gateway is registering with a gatekeeper.
RCF_CHOSEN A registration confirm message that has been
received from a gatekeeper.
CCH323_RAS_EVENT_RCF Received RCF event message.
CCH323_RAS_EVENT_NEWCALL New call event.
CCH323_RAS_STATE_ARQ The per-call state machine is in the process of
admitting a new call.

DB-252 May 2008
Debug Commands
debug cch323
Table 49 debug cch323 ras Field Descriptions (continued)
Field Description
ACF_CHOSEN ACF message that has been received from a
gatekeeper.
CCH323_RAS_EVENT_ACF Received ACF event message.
CCH323_RAS_STATE_ACTIVE The per-call state machine is in the call active
state.
CCH323_RAS_EVENT_CALLDISC Call disconnect event message.
CCH323_RAS_STATE_DRQ The per-call state machine is in the process of
disengaging an active call.
DCF_CHOSEN The disengage confirm message that has been
received from a gatekeeper.
CCH323_RAS_EVENT_DCF Received DCF event message.
CCH323_RAS_EVENT_IRR Send IRR event message.
The debug cch323 Command with the rawmsg Keyword Example

The following is sample output from a typical debug cch323 rawmsg request on a Cisco 3640 router:
Router# debug cch323 rawmsg
00:32:04:cch323_h225_progress_ind:raw message is 4 bytes:1E 02 81 88
00:32:22:cch323_h225_release_ind:raw message is 80 bytes:00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
00:32:22:cch323_h225_release_notify:raw message is 80 bytes:00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
The debug cch323 Command with the session Keyword Examples

Following are two examples of output using the debug cch323 session command and keyword
combination. The first example is for a call setup on an originating gateway. The second example is for
a call setup on a terminating gateway.
The following is sample output from a typical debug cch323 session request for a call setup on an
originating gateway:
Router# debug cch323 session
00:33:49:cch323_call_setup:gw_id=1, callID=16
00:33:49:cch323_get_new_ccb:ccb (0x81D12D2C) is in use

00:33:49:cch323_call_setup:inserted ccb
cch323_get_peer_info:faxrate[21]proto[2]bitmask[10002]t38_inhibit[0]global_fax[0]
00:33:49:Not using Voice Class Codec
00:33:49:cch323_get_peer_info:preffered_codec set to G729IETF with Bytes = 20

00:33:49:cch323_get_peer_info:peer:81FC0D14, peer->voice_peer_tag:12D, ccb:81D12D2C
00:33:49:Call_setup Playout Mode:0,Init 60, Min 40, Max 200
00:33:49:No account/pin number available
00:33:49:cch323_call_setup_normal:for callID 10

May 2008 DB-253
Debug Commands
debug cch323
00:33:49:timer (0x81D130D4)starts - delay (15000)

00:33:49:cch323_ct_main:SOCK 1 Event 0x1
00:33:49:timer(0x81D130D4) stops
00:33:49:Near-end Pref Codecs = G.729 IETF
00:33:49: generic_open_logical_channel:codec is g729
00:33:49:cch323_generic_open_logical_channel:Filling in qosCapability field to 0

00:33:49: [1]towner_data=0x81D13C88, len=105, msgPtr=0x81D07608
00:33:49:cch323_gw_process_read_socket:received msg for H.225
00:33:49:timer(0x81D130D4) stops
00:33:49:Codec:loc(16), rem(16),
Bytes:loc(20), Fwd(20), Rev(20)
00:33:49:cch323_rtp_open_notify:
00:33:50: [1]towner_data=0x81D13C88, len=71, msgPtr=0x81F1F2E0
00:33:50:cch323_caps_ind:cap_modem_proto:0, cap_modem_codec:0, cap_modem_redundancy:0

payload 100
00:33:50:cch323_caps_ind:Load DSP with Negotiated codec(16) g729r8, Bytes=20
00:33:50:cch323_caps_ind:set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_INBAND_VOICE
The following is sample output from a typical debug cch323 session request for a call setup on a
terminating gateway:
Router# debug cch323 session

00:23:27: [1]towner_data=0x81F9CA9C, len=179, msgPtr=0x81D15C6C
00:23:27:cch323_h225_receiver CCB not existing already
00:23:27:cch323_get_new_ccb:ccb (0x81F90184) is in use

00:23:27:cch323_h225_receiver Got a new CCB for call id -2115467564
00:23:27:cch323_h225_setup_ind
00:23:27:cch323_set_peer:peer:81FB3228, peer->voice_peer_tag:12C, ccb:81F90184

00:23:27:Near-end Pref Codecs = G.729 IETF
00:23:27:Codec:loc(16), rem(16),
Bytes:loc(20), Fwd(20), Rev(20)
00:23:27:cch323_build_fastStart_cap_response:Retrieved qosCapability of 0
00:23:27:cch323_build_fastStart_cap_response:In Response Filling in qosCapability field

to 0

DB-254 May 2008
Debug Commands
debug cch323

clear h323 gateway Clears the H.323 gateway counters.
debug h323-annexg Displays all pertinent AnnexG messages that have been transmitted and
received.
debug voip rawmsg Displays the raw message owner, length, and pointer.
show h323 gateway Displays statistics for H.323 gateway messages that have been sent and
received and displays the reasons for which H.323 calls have been
disconnected.

May 2008 DB-255
Debug Commands
debug ccm-manager
debug ccm-manager
To display debugging information about Cisco CallManager, use the debug ccm-manager command in
debug ccm-manager {backhaul {errors | events | packets} | config-download {all | errors |

events | packets | tone | xml} | errors | events | music-on-hold {errors | events | packets} |
packets}
no debug ccm-manager
Syntax Description backhaul Enables debugging of the Cisco CallManager backhaul. The keywords are as
follows:
errorsDisplays Cisco CallManager backhaul errors.
eventsDisplays Cisco CallManager backhaul events.
packetsDisplays Cisco CallManager packets.
config-download Enables debugging of the Cisco CallManager configuration download. The
keywords are as follows:
allDisplays all Cisco CallManager configuration parameters.
errorsDisplays Cisco CallManager configuration errors.
eventsDisplays Cisco CallManager configuration events.
packetsDisplays Cisco CallManager configuration packets.
toneDisplays Cisco CallManager downloaded custom tones.
xmlDisplays the Cisco CallManager configuration XML parser.
errors Displays errors related to Cisco CallManager.
events Displays Cisco CallManager events, such as when the primary
Cisco CallManager server fails and control is switched to the backup
Cisco CallManager server.
music-on-hold Displays music on hold (MOH). The keywords are as follows:
errorsDisplays MOH errors.
eventsDisplays MOH events.
packetsDisplays MOH packets.
packets Displays Cisco CallManager packets.

12.1(3)T This command was introduced for Cisco CallManager Version 3.0 and the
Cisco VG200.
12.2(2)XA This command was implemented on Cisco 2600 series and Cisco 3600 series
routers.

DB-256 May 2008
Debug Commands
debug ccm-manager
12.2(2)XN Support for enhanced MGCP voice gateway interoperability was added to
Cisco CallManager Version 3.1 for the Cisco 2600 series, Cisco 3600 series,
and Cisco VG200.
implemented on the Cisco IAD2420 series.
12.2(15)XJ The tone keyword was added for the following platforms: Cisco 2610XM,
Cisco 611XM, Cisco 2620XM, Cisco 2621XM, Cisco 2650XM,
Cisco 2651XM, Cisco 2691, Cisco 3640A, Cisco 3660, Cisco 3725, and
Cisco 3745.
12.3(4)T The tone keyword was added.
12.3(14)T New output was added relating to the SCCP protocol.
Examples The following is sample output from the debug ccm-manager events command:
Router# debug ccm-manager events
*Feb 28 22:56:05.873: cmapp_mgcpapp_go_down: Setting mgc status to NO_RESPONSE

*Feb 28 22:56:05.873: cmapp_host_fsm: New state DOWN for host 0 (172.20.71.38)
*Feb 28 22:56:05.873: cmapp_mgr_process_ev_active_host_failed: Active host 0
(172.20.71.38) failed
*Feb 28 22:56:05.873: cmapp_mgr_check_hostlist: Active host is 0 (172.20.71.38)
*Feb 28 22:56:05.877: cmapp_mgr_switchover: New actv host will be 1 (172.20.71.44)
*Feb 28 22:56:05.877: cmapp_host_fsm: Processing event GO_STANDBY for host 0
(172.20.71.38) in state DOWN
*Feb 28 22:56:05.877: cmapp_open_new_link: Open link for [0]:172.20.71.38
*Feb 28 22:56:05.877: cmbh_open_tcp_link: Opening TCP link with Rem IP 172.20.71.38, Local
IP 172.20.71.19, port 2428
*Feb 28 22:56:05.881: cmapp_open_new_link: Open initiated OK: Host 0 (172.20.71.38),
session_id=8186DEE4
*Feb 28 22:56:05.881: cmapp_start_open_link_tmr: Host 0 (172.20.71.38), tmr 0
*Feb 28 22:56:05.881: cmapp_host_fsm: New state STANDBY_OPENING for host 0 (172.20.71.38)
*Feb 28 22:56:05.881: cmapp_host_fsm: Processing event GO_ACTIVE for host 1 (172.20.71.44)
in state STANDBY_READY
*Feb 28 22:56:05.885: cmapp_mgr_send_rehome: new addr=172.20.71.44,port=2427
*Feb 28 22:56:05.885: cmapp_host_fsm: New state REGISTERING for host 1 (172.20.71.44)
You can use the debug ccm-manager config-download tone command to verify the parameters
assigned to each locale. The following sample output shows the locale name United Kingdom and lists
all the dual-tone parameters for that region:
Router# debug ccm-manager config-download tone
00:09:07:
cmapp_prefix_process_tag_tones:
00:09:07: cmapp_process_tag_trkLocaleName: region = United Kingdom
00:09:07: cmapp_process_tag_pulse_ratio: pulse ratio = 40
00:09:07: cmapp_process_tag_dtmf_llevel: low frequency level = 65438
00:09:07: cmapp_process_tag_dtmf_hlevel: high frequency level = 65463
00:09:07: cmapp_process_tag_special_oper: operation = uLaw
00:09:07: cmapp_prefix_process_tag_lpig:
00:09:07: cmapp_process_tag_fxs: ignore LPIG for fxs
00:09:07: cmapp_process_tag_fxo: ignore LPIG for fxo

May 2008 DB-257
Debug Commands
debug ccm-manager
00:09:07: cmapp_process_tag_digital: ignore LPIG for digital

00:09:07: cmapp_prefix_process_tag_lpog:
00:09:07: cmapp_process_tag_fxs: ignore LPOG for fxsBoth ports are in service
00:09:07: cmapp_process_tag_fxo: ignore LPOG for fxo
00:09:07: cmapp_process_tag_digital: ignore LPOG for digital
00:09:07: cmapp_prefix_process_tag_tonetable_info:
00:09:07:
cmapp_prefix_process_tag_dualtone: TID=[0:CPTONE_BUSY]
00:09:07: cmapp_process_tag_nf: number of frequencies = 1
00:09:07: cmapp_process_tag_dr: direction = 0
00:09:07: cmapp_process_tag_fof: frequency 1 = 400
00:09:07: cmapp_process_tag_fos: frequency 2 = 0
00:09:07: cmapp_process_tag_fot: frequency 3 = 0
00:09:07: cmapp_process_tag_fo4: frequency 4 = 0
00:09:07: cmapp_prefix_process_tag_aof_level:
00:09:07: cmapp_process_tag_fxs: amplitude of 1st = -200
00:09:07: cmapp_process_tag_fxo: amplitude of 1st = -200
00:09:07: cmapp_process_tag_digital: amplitude of 1st = -240
00:09:07: cmapp_prefix_process_tag_aos_level:
00:09:07: cmapp_process_tag_fxs: amplitude of 2nd = 0
00:09:07: cmapp_process_tag_fxo: amplitude of 2nd = 0
00:09:07: cmapp_process_tag_digital: amplitude of 2nd = 0
00:09:07: cmapp_prefix_process_tag_aot_level:
00:09:07: cmapp_process_tag_fxs: amplitude of 3rd = 0
00:09:07: cmapp_process_tag_fxo: amplitude of 3rd = 0
00:09:07: cmapp_process_tag_digital: amplitude of 3rd = 0
00:09:07: cmapp_prefix_process_tag_ao4_level:
00:09:07: cmapp_process_tag_fxs: amplitude of 4th = 0
00:09:07: cmapp_process_tag_fxo: amplitude of 4th = 0
00:09:07: cmapp_process_tag_digital: amplitude of 4th = 0
00:09:07: cmapp_process_tag_ontf: frequency 1 on time = 375
00:09:07: cmapp_process_tag_oftf: frequency 1 off time = 375
00:09:07: cmapp_process_tag_onts: frequency 2 on time = 0
00:09:07: cmapp_process_tag_ofts: frequency 2 off time = 0
00:09:07: cmapp_process_tag_ontt: frequency 3 on time = 0
00:09:07: cmapp_process_tag_oftt: frequency 3 off time = 0
00:09:07: cmapp_process_tag_ont4: frequency 4 on time = 0
00:09:07: cmapp_process_tag_oft4: frequency 4 off time = 0
00:09:07: cmapp_process_tag_fof2: frequency 1 cadence 2 = 0
00:09:07: cmapp_process_tag_fos2: frequency 2 cadence 2 = 0
00:09:07: cmapp_process_tag_rct1: cadence 1 repeat count = 0
00:09:07:
cmapp_prefix_process_tag_dualtone: TID=[1:CPTONE_RING_BACK]
00:09:07: cmapp_process_tag_fxs: amplitude of 2nd = -190
00:09:07: cmapp_process_tag_fxo: amplitude of 2nd = -190
00:09:07: cmapp_process_tag_digital: amplitude of 2nd = -190

DB-258 May 2008
Debug Commands
debug ccm-manager
00:09:07:
cmapp_prefix_process_tag_dualtone: TID=[2:CPTONE_CONGESTION]
00:09:07: cmapp_process_tag_fxs: amplitude of 2nd = 0
00:09:07: cmapp_process_tag_fxo: amplitude of 2nd = 0
00:09:07: cmapp_process_tag_digital: amplitude of 2nd = 0

May 2008 DB-259
Debug Commands
debug ccm-manager

! end
The following is sample output from the debug ccm-manager config-download all command for an
error case in which the configuration file cannot be accessed for a Skinny Client Control Protocol
(SCCP) download:
*Jan 9 07:28:33.499: cmapp_xml_process_timer:
*Jan 9 07:28:33.499: cmapp_xml_find_ep_by_name: Checking for ep_name [*]
*Jan 9 07:28:33.499: cmapp_xml_exec_fsm: Endpoint is [*]
*Jan 9 07:28:33.499: cmapp_xml_exec_fsm: endpoint = * state = CMAPP_XML_FILE_DNLD, event
= CMAPP_XML_EVT_FILE_DNLD_TIMER
*Jan 9 07:28:33.499: cmapp_xml_file_retry_timer_expired: state = CMAPP_XML_FILE_DNLD,
event = CMAPP_XML_EVT_FILE_DNLD_TIMER
*Jan 9 07:29:14.499: cmapp_xml_tftp_download_file: Unable to read file
tftp://10.6.6.31/Router.cisco.com.cnf.xml, rc=-2
*Jan 9 07:29:14.499: cmapp_xml_get_xml_file: Could not read file
tftp://10.6.6.31/Router.cisco.com.cnf.xml, len = 0
tftp:///Router.cisco.com.cnf.xml, rc=-2
tftp:///Router.cisco.com.cnf.xml, len = 0
tftp:///Router.cisco.com.cnf.xml, rc=-2
tftp:///Router.cisco.com.cnf.xml, len = 0
*Jan 9 07:29:14.499: cmapp_xml_exec_fsm: New state = CMAPP_XML_FILE_DNLD, ep = 6544CFA8
The following is sample output from the debug ccm-manager config-download all command for a
successful SCCP download:
*Jan 9 09:44:45.543: cmapp_sccp_config:
*Jan 9 09:44:45.543: cmapp_sccp_reset_curcfg:
*Jan 9 09:44:45.543: cmapp_sccp_init_curcfg:
*Jan 9 09:44:45.543: cmapp_sccp_download_gw_config_file:
*Jan 9 09:44:45.543: cmapp_sccp_get_gw_name:
*Jan 9 09:44:45.543: cmapp_sccp_get_gw_name: XML file name
generated->SKIGW0C85226910.cnf.xml
*Jan 9 09:44:45.543: cmapp_sccp_get_xml_file_via_tftp:
*Jan 9 09:44:45.543: cmapp_sccp_tftp_download_file:
*Jan 9 09:44:45.543: cmapp_sccp_tftp_get_file_size:
*Jan 9 09:44:45.563: cmapp_sccp_get_buffer:
*Jan 9 09:44:45.575: cmapp_sccp_tftp_download_file: File
(tftp://10.2.6.101/SKIGW0C85226910.cnf.xml) read 8162 bytes
*Jan 9 09:44:45.575: cmapp_sccp_get_xml_file_via_tftp: Read file
tftp://10.2.6.101/SKIGW0C85226910.cnf.xml, len = 8162
*Jan 9 09:44:45.575: cmapp_parse_gw_xml_file:
*Jan 9 09:44:45.579: cmapp_sccp_gw_chardata_handler: ccm found, priority=0

DB-260 May 2008
Debug Commands
debug ccm-manager
The following lines show the conversion of XML data into router configuration information for the
endpoint:
*Jan 9 09:44:45.579: cmapp_sccp_gw_start_element_handler: Unit has been set to 1
*Jan 9 09:44:45.579: cmapp_sccp_gw_start_element_handler: Subunit has been set to 0
*Jan 9 09:44:45.579: cmapp_sccp_gw_start_element_handler: Endpoint has been set to 0
*Jan 9 09:44:45.579: cmapp_sccp_gw_start_element_handler: Subunit has been set to 1
*Jan 9 09:44:45.579: cmapp_sccp_gw_start_element_handler: Unit has been set to 2
Table 50 describes the significant fields shown in the displays.
Table 50 debug ccm-manager Field Descriptions
Field Description
nn:nn:nn: Timestamp time in hours (military format),
minutes, and seconds that indicates when the
Cisco CallManager event occurred.
cmapp_ error message: The Cisco CallManager routine in which the error
event occurred.
LocaleName Region name, such as United Kingdom.
low frequency level DTMF low frequency.
high frequency level DTMF high frequency.
operation Special operations, such as uLaw.

show ccm-manager Displays a list of Cisco CallManager servers, their current status, and their
availability.

May 2008 DB-261
Debug Commands
debug ccsip all
debug ccsip all

To enable all Session Initiation Protocol (SIP)-related debugging, use the debug ccsip all command in
debug ccsip all
no debug ccsip all
Command History 12.1(1)T This command was introduced.

12.1.(3)T The output of this command was changed.
12.2(2)XA Support was added for the Cisco AS5350 and Cisco AS5400
universal gateways.
12.2(2)XB1 This command was implemented on the Cisco AS5850 universal
gateway.
12.2(8)T This command was integrated into Cisco IOS Release 12.2(8)T
and implemented on Cisco 7200 series routers.
Support for the Cisco AS5300 universal access server,
Cisco AS5350, Cisco AS5400, and Cisco AS5850 universal
gateway is not included in this release.
12.2SX This command is supported in the Cisco IOS Release 12.2SX
train. Support in a specific 12.2SX release of this train depends
on your feature set, platform, and platform hardware.
Usage Guidelines The debug ccsip all command enables the following SIP debug commands:
debug ccsip events
debug ccsip error
debug ccsip states
debug ccsip messages
debug ccsip calls

DB-262 May 2008
Debug Commands
debug ccsip all
Examples The following example displays debug output from one side of the call:
Router# debug ccsip all
All SIP call tracing enabled

Router1#
*Mar 6 14:10:42: 0x624CFEF8 : State change from (STATE_NONE, SUBSTATE_NONE) to
(STATE_IDLE, SUBSTATE_NONE)
*Mar 6 14:10:42: Queued event from SIP SPI : SIPSPI_EV_CC_CALL_SETUP
*Mar 6 14:10:42: CCSIP-SPI-CONTROL: act_idle_call_setup
*Mar 6 14:10:42: act_idle_call_setup:Not using Voice Class Codec
*Mar 6 14:10:42: act_idle_call_setup: preferred_codec set[0] type :g711ulaw bytes: 160

*Mar 6 14:10:42: Queued event from SIP SPI : SIPSPI_EV_CREATE_CONNECTION
*Mar 6 14:10:42: 0x624CFEF8 : State change from (STATE_IDLE, SUBSTATE_NONE) to
(STATE_IDLE, SUBSTATE_CONNECTING)
*Mar 6 14:10:42: REQUEST CONNECTION TO IP:166.34.245.231 PORT:5060
*Mar 6 14:10:42: 0x624CFEF8 : State change from (STATE_IDLE, SUBSTATE_CONNECTING) to

*Mar 6 14:10:42: CCSIP-SPI-CONTROL: act_idle_connection_created
*Mar 6 14:10:42: CCSIP-SPI-CONTROL: act_idle_connection_created: Connid(1) created to
166.34.245.231:5060, local_port 54113
*Mar 6 14:10:42: sipSPIAddLocalContact
*Mar 6 14:10:42: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE
*Mar 6 14:10:42: CCSIP-SPI-CONTROL: sip_stats_method
*Mar 6 14:10:42: 0x624CFEF8 : State change from (STATE_IDLE, SUBSTATE_CONNECTING) to
(STATE_SENT_INVITE, SUBSTATE_NONE)
*Mar 6 14:10:42: Sent:
INVITE sip:3660210@166.34.245.231;user=phone;phone-context=unknown SIP/2.0
Via: SIP/2.0/UDP 166.34.245.230:54113
From: "3660110" <sip:3660110@166.34.245.230>
To: <sip:3660210@166.34.245.231;user=phone;phone-context=unknown>
Date: Sat, 06 Mar 1993 19:10:42 GMT
Call-ID: ABBAE7AF-823100CE-0-1CCAA69C@172.18.192.194
Cisco-Guid: 2881152943-2184249548-0-483039712
User-Agent: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled
CSeq: 101 INVITE
Max-Forwards: 6
Timestamp: 731427042
Contact: <sip:3660110@166.34.245.230:5060;user=phone>
Expires: 180
Content-Type: application/sdp
Content-Length: 137
v=0
o=CiscoSystemsSIP-GW-UserAgent 1212 283 IN IP4 166.34.245.230
s=SIP Call
t=0 0
c=IN IP4 166.34.245.230
m=audio 20208 RTP/AVP 0
*Mar 6 14:10:42: Received:

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 166.34.245.230:54113
From: "3660110" <sip:3660110@166.34.245.230>
Date: Mon, 08 Mar 1993 22:36:40 GMT
Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled
CSeq: 101 INVITE
Content-Length: 0

May 2008 DB-263
Debug Commands
debug ccsip all
*Mar 6 14:10:42: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr:

166.34.245.231:5060
*Mar 6 14:10:42: CCSIP-SPI-CONTROL: act_sentinvite_new_message
*Mar 6 14:10:42: CCSIP-SPI-CONTROL: sipSPICheckResponse
*Mar 6 14:10:42: CCSIP-SPI-CONTROL: sip_stats_status_code
*Mar 6 14:10:42: Roundtrip delay 4 milliseconds for method INVITE
*Mar 6 14:10:42: 0x624CFEF8 : State change from (STATE_SENT_INVITE, SUBSTATE_NONE) to

(STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 166.34.245.230:54113
From: "3660110" <sip:3660110@166.34.245.230>
Date: Mon, 08 Mar 1993 22:36:40 GMT
CSeq: 101 INVITE
Content-Length: 137
v=0
s=SIP Call
t=0 0
c=IN IP4 166.34.245.231

166.34.245.231:5060
*Mar 6 14:10:42: CCSIP-SPI-CONTROL: act_recdproc_new_message
*Mar 6 14:10:42: CCSIP-SPI-CONTROL: sipSPICheckResponse : Updating session description
*Mar 6 14:10:42: HandleSIP1xxRinging: SDP MediaTypes negotiation successful!

Negotiated Codec : g711ulaw , bytes :160
Inband Alerting : 0
*Mar 6 14:10:42: 0x624CFEF8 : State change from (STATE_RECD_PROCEEDING,

SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING)
SIP/2.0 200 OK
Via: SIP/2.0/UDP 166.34.245.230:54113
From: "3660110" <sip:3660110@166.34.245.230>
To: <sip:3660210@166.34.245.231;user=phone;phone-context=unknown>;tag=27D3FCA8-C7F
Date: Mon, 08 Mar 1993 22:36:40 GMT
CSeq: 101 INVITE
Content-Length: 137
v=0
s=SIP Call
t=0 0
c=IN IP4 166.34.245.231

DB-264 May 2008
Debug Commands
debug ccsip all

166.34.245.231:5060
*Mar 6 14:10:46: CCSIP-SPI-CONTROL: act_recdproc_new_message: SDP MediaTypes negotiation

successful!
*Mar 6 14:10:46: CCSIP-SPI-CONTROL: sipSPIReconnectConnection

*Mar 6 14:10:46: Queued event from SIP SPI : SIPSPI_EV_RECONNECT_CONNECTION
*Mar 6 14:10:46: CCSIP-SPI-CONTROL: recv_200_OK_for_invite
*Mar 6 14:10:46: 0x624CFEF8 : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_ALERTING) to (STATE_ACTIVE, SUBSTATE_NONE)
*Mar 6 14:10:46: The Call Setup Information is :
Call Control Block (CCB) : 0x624CFEF8

State of The Call : STATE_ACTIVE
TCP Sockets Used : NO
Calling Number : 3660110
Called Number : 3660210
Negotiated Codec : g711ulaw
Source IP Address (Media): 166.34.245.230
Source IP Port (Media): 20208
Destn IP Address (Media): 166.34.245.231
Destn IP Port (Media): 20038
Destn SIP Addr (Control) : 166.34.245.231
Destn SIP Port (Control) : 5060
Destination Name : 166.34.245.231
*Mar 6 14:10:46: HandleUdpReconnection: Udp socket connected for fd: 1 with

166.34.245.231:5060
*Mar 6 14:10:46: Sent:
ACK sip:3660210@166.34.245.231:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 166.34.245.230:54113
From: "3660110" <sip:3660110@166.34.245.230>
Date: Sat, 06 Mar 1993 19:10:42 GMT
Max-Forwards: 6
Content-Length: 137
CSeq: 101 ACK
v=0
s=SIP Call
t=0 0
c=IN IP4 166.34.245.230
*Mar 6 14:10:46: CCSIP-SPI-CONTROL: ccsip_caps_ind

*Mar 6 14:10:46: ccsip_caps_ind: Load DSP with codec (5) g711ulaw, Bytes=160
*Mar 6 14:10:46: ccsip_caps_ind: set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_INBAND_VOICE
*Mar 6 14:10:46: CCSIP-SPI-CONTROL: ccsip_caps_ack
BYE sip:3660110@166.34.245.230:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 166.34.245.231:54835
From: <sip:3660210@166.34.245.231;user=phone;phone-context=unknown>;tag=27D3FCA8-C7F

May 2008 DB-265
Debug Commands
debug ccsip all
To: "3660110" <sip:3660110@166.34.245.230>

Date: Mon, 08 Mar 1993 22:36:44 GMT
Max-Forwards: 6
CSeq: 101 BYE
Content-Length: 0

166.34.245.231:54835
*Mar 6 14:10:50: CCSIP-SPI-CONTROL: act_active_new_message
*Mar 6 14:10:50: CCSIP-SPI-CONTROL: sact_active_new_message_request
*Mar 6 14:10:50: CCSIP-SPI-CONTROL: sipSPIInitiateCallDisconnect : Initiate call
disconnect(16) for outgoing call
*Mar 6 14:10:50: 0x624CFEF8 : State change from (STATE_ACTIVE, SUBSTATE_NONE) to
(STATE_DISCONNECTING, SUBSTATE_NONE)
*Mar 6 14:10:50: Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 166.34.245.231:54835
To: "3660110" <sip:3660110@166.34.245.230>
Date: Sat, 06 Mar 1993 19:10:50 GMT
Content-Length: 0
CSeq: 101 BYE
*Mar 6 14:10:50: Queued event From SIP SPI to CCAPI/DNS : SIPSPI_EV_CC_CALL_DISCONNECT

*Mar 6 14:10:50: CCSIP-SPI-CONTROL: act_disconnecting_disconnect
*Mar 6 14:10:50: CCSIP-SPI-CONTROL: sipSPICallCleanup
*Mar 6 14:10:50: Queued event from SIP SPI : SIPSPI_EV_CLOSE_CONNECTION
*Mar 6 14:10:50: CLOSE CONNECTION TO CONNID:1
*Mar 6 14:10:50: sipSPIIcpifUpdate :CallState: 4 Playout: 1755 DiscTime:48305031 ConnTime

48304651
*Mar 6 14:10:50: 0x624CFEF8 : State change from (STATE_DISCONNECTING, SUBSTATE_NONE) to

(STATE_DEAD, SUBSTATE_NONE)
Call Control Block (CCB) : 0x624CFEF8

State of The Call : STATE_DEAD
*Mar 6 14:10:50:
Disconnect Cause (CC) : 16

Disconnect Cause (SIP) : 200

DB-266 May 2008
Debug Commands
debug ccsip all
*Mar 6 14:10:50: udpsock_close_connect: Socket fd: 1 closed for connid 1 with remote
port: 5060
The following example displays debut output from the other side of the call:
Router# debug ccsip all
All SIP call tracing enabled

3660-2#
Via: SIP/2.0/UDP 166.34.245.230:54113
From: "3660110" <sip:3660110@166.34.245.230>
Date: Sat, 06 Mar 1993 19:10:42 GMT
Cisco-Guid: 2881152943-2184249548-0-483039712
CSeq: 101 INVITE
Max-Forwards: 6
Expires: 180
Content-Length: 137
v=0
s=SIP Call
t=0 0
c=IN IP4 166.34.245.230

166.34.245.230:54113
*Mar 8 17:36:40: CCSIP-SPI-CONTROL: sipSPISipIncomingCall
*Mar 8 17:36:40: 0x624D8CCC : State change from (STATE_NONE, SUBSTATE_NONE) to
*Mar 8 17:36:40: CCSIP-SPI-CONTROL: act_idle_new_message
*Mar 8 17:36:40: CCSIP-SPI-CONTROL: sact_idle_new_message_invite
*Mar 8 17:36:40: sact_idle_new_message_invite:Not Using Voice Class Codec
*Mar 8 17:36:40: sact_idle_new_message_invite: Preferred codec[0] type: g711ulaw Bytes

:160
*Mar 8 17:36:40: sact_idle_new_message_invite: Media Negotiation successful for an
incoming call
*Mar 8 17:36:40: sact_idle_new_message_invite: Negotiated Codec : g711ulaw, bytes

:160
Preferred Codec : g711ulaw, bytes :160

*Mar 8 17:36:40: Num of Contact Locations 1 3660110 166.34.245.230 5060
*Mar 8 17:36:40: 0x624D8CCC : State change from (STATE_IDLE, SUBSTATE_NONE) to

(STATE_RECD_INVITE, SUBSTATE_RECD_INVITE_CALL_SETUP)
*Mar 8 17:36:40: Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 166.34.245.230:54113
From: "3660110" <sip:3660110@166.34.245.230>
Date: Mon, 08 Mar 1993 22:36:40 GMT

May 2008 DB-267
Debug Commands
debug ccsip all
CSeq: 101 INVITE
Content-Length: 0
*Mar 8 17:36:40: Queued event From SIP SPI to CCAPI/DNS : SIPSPI_EV_CC_CALL_PROCEEDING

*Mar 8 17:36:40: CCSIP-SPI-CONTROL: act_recdinvite_proceeding
*Mar 8 17:36:40: Queued event From SIP SPI to CCAPI/DNS : SIPSPI_EV_CC_CALL_ALERTING
*Mar 8 17:36:40: ccsip_caps_ind: codec(negotiated) = 5(Bytes 160)
*Mar 8 17:36:40: CCSIP-SPI-CONTROL: act_recdinvite_alerting
*Mar 8 17:36:40: 180 Ringing with SDP - not likely

*Mar 8 17:36:40: 0x624D8CCC : State change from (STATE_RECD_INVITE,
SUBSTATE_RECD_INVITE_CALL_SETUP) to (STATE_SENT_ALERTING, SUBSTATE_NONE)
*Mar 8 17:36:40: Sent:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 166.34.245.230:54113
From: "3660110" <sip:3660110@166.34.245.230>
Date: Mon, 08 Mar 1993 22:36:40 GMT
CSeq: 101 INVITE
Content-Length: 137
v=0
s=SIP Call
t=0 0
c=IN IP4 166.34.245.231
*Mar 8 17:36:44: Queued event From SIP SPI to CCAPI/DNS : SIPSPI_EV_CC_CALL_CONNECT

*Mar 8 17:36:44: CCSIP-SPI-CONTROL: act_sentalert_connect
*Mar 8 17:36:44: 0x624D8CCC : State change from (STATE_SENT_ALERTING, SUBSTATE_NONE) to
(STATE_SENT_SUCCESS, SUBSTATE_NONE)
*Mar 8 17:36:44: Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 166.34.245.230:54113
From: "3660110" <sip:3660110@166.34.245.230>
Date: Mon, 08 Mar 1993 22:36:40 GMT
CSeq: 101 INVITE
Content-Length: 137
v=0

DB-268 May 2008
Debug Commands
debug ccsip all
s=SIP Call
t=0 0
c=IN IP4 166.34.245.231

Via: SIP/2.0/UDP 166.34.245.230:54113
From: "3660110" <sip:3660110@166.34.245.230>
Date: Sat, 06 Mar 1993 19:10:42 GMT
Max-Forwards: 6
Content-Length: 137
CSeq: 101 ACK
v=0
s=SIP Call
t=0 0
c=IN IP4 166.34.245.230

166.34.245.230:54113
*Mar 8 17:36:44: CCSIP-SPI-CONTROL: act_sentsucc_new_message
*Mar 8 17:36:44: 0x624D8CCC : State change from (STATE_SENT_SUCCESS, SUBSTATE_NONE) to
(STATE_ACTIVE, SUBSTATE_NONE)
Call Control Block (CCB) : 0x624D8CCC

*Mar 8 17:36:47: Queued event From SIP SPI to CCAPI/DNS : SIPSPI_EV_CC_CALL_DISCONNECT

*Mar 8 17:36:47: CCSIP-SPI-CONTROL: act_active_disconnect
*Mar 8 17:36:47: Queued event from SIP SPI : SIPSPI_EV_CREATE_CONNECTION
*Mar 8 17:36:47: 0x624D8CCC : State change from (STATE_ACTIVE, SUBSTATE_NONE) to
(STATE_ACTIVE, SUBSTATE_CONNECTING)
*Mar 8 17:36:47: 0x624D8CCC : State change from (STATE_ACTIVE, SUBSTATE_CONNECTING) to

(STATE_ACTIVE, SUBSTATE_CONNECTING)
*Mar 8 17:36:47: CCSIP-SPI-CONTROL: act_active_connection_created
*Mar 8 17:36:47: CCSIP-SPI-CONTROL: sipSPICheckSocketConnection
*Mar 8 17:36:47: CCSIP-SPI-CONTROL: sipSPICheckSocketConnection: Connid(1) created to
166.34.245.230:5060, local_port 54835
*Mar 8 17:36:47: 0x624D8CCC : State change from (STATE_ACTIVE, SUBSTATE_CONNECTING) to
*Mar 8 17:36:47: Sent:

May 2008 DB-269
Debug Commands
debug ccsip all

Via: SIP/2.0/UDP 166.34.245.231:54835
To: "3660110" <sip:3660110@166.34.245.230>
Date: Mon, 08 Mar 1993 22:36:44 GMT
Max-Forwards: 6
CSeq: 101 BYE
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 166.34.245.231:54835
To: "3660110" <sip:3660110@166.34.245.230>
Date: Sat, 06 Mar 1993 19:10:50 GMT
Content-Length: 0
CSeq: 101 BYE

166.34.245.230:54113
*Mar 8 17:36:47: CCSIP-SPI-CONTROL: act_disconnecting_new_message
*Mar 8 17:36:47: CCSIP-SPI-CONTROL: sact_disconnecting_new_message_response
*Mar 8 17:36:47: Roundtrip delay 4 milliseconds for method BYE

*Mar 8 17:36:47: Queued event from SIP SPI : SIPSPI_EV_CLOSE_CONNECTION

66820420
*Mar 8 17:36:47: 0x624D8CCC : State change from (STATE_DISCONNECTING, SUBSTATE_NONE) to

Call Control Block (CCB) : 0x624D8CCC

*Mar 8 17:36:47:


DB-270 May 2008
Debug Commands
debug ccsip all
port: 5060

debug ccsip calls Shows all SIP SPI call tracing.
debug ccsip error Shows SIP SPI errors.
debug ccsip events Shows all SIP SPI events tracing.
debug ccsip info Shows all SIP SPI message tracing.
debug ccsip states Shows all SIP SPI state tracing.

May 2008 DB-271
Debug Commands
debug ccsip calls
debug ccsip calls

To show all Session Initiation Protocol (SIP) Service Provider Interface (SPI) call tracing, use the debug
ccsip calls command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug ccsip calls
no debug ccsip calls

12.1(3)T The output of this command was changed.
universal gateways.
12.2(2)XB1 This command was introduced on the Cisco AS5850 universal
gateway.
Usage Guidelines This command traces the SIP call details as they are updated in the SIP call control block.
Router1# debug ccsip calls
SIP Call statistics tracing is enabled

Router1#
Call Control Block (CCB) : 0x624D078C


DB-272 May 2008
Debug Commands
debug ccsip calls

Call Control Block (CCB) : 0x624D078C

*Mar 6 14:12:40:

The following example displays debug output from the other side of the call:
Router2# debug ccsip calls
SIP Call statistics tracing is enabled

Router2#
Call Control Block (CCB) : 0x624D9560

*Mar 8 17:38:38: The Call Setup Information is:
Call Control Block (CCB) : 0x624D9560


May 2008 DB-273
Debug Commands
debug ccsip calls

*Mar 8 17:38:38:


debug ccsip all Enables all SIP-related debugging.

DB-274 May 2008
Debug Commands
debug ccsip error
debug ccsip error

To show Session Initiation Protocol (SIP) Service Provider Interface (SPI) errors, use the debug ccsip
command.
debug ccsip error
no debug ccip error

universal gateways.
gateway.
and implemented on Cisco 7200 series routers.
12.2(11)T This command was integrated into Cisco IOS
Release 12.2(11)T. Support for the Cisco AS5300 universal
access server, Cisco AS5350, Cisco AS5400, and Cisco AS5850
universal gateway is not included in this release.
Usage Guidelines This command traces all error messages generated from errors encountered by the SIP subsystem.
Router1# debug ccsip error
SIP Call error tracing is enabled

Router1#
*Mar 6 14:16:41: CCSIP-SPI-CONTROL: act_idle_call_setup
*Mar 6 14:16:41: act_idle_call_setup:Not using Voice Class Codec
*Mar 6 14:16:41: act_idle_call_setup: preferred_codec set[0] type :g711ulaw bytes: 160


May 2008 DB-275
Debug Commands
debug ccsip error
*Mar 6 14:16:41: CCSIP-SPI-CONTROL: act_idle_connection_created

*Mar 6 14:16:41: CCSIP-SPI-CONTROL: act_idle_connection_created: Connid(1) created to
166.34.245.231:5060, local_port 55674
166.34.245.231:5060
*Mar 6 14:16:41: CCSIP-SPI-CONTROL: act_sentinvite_new_message

166.34.245.231:5060
*Mar 6 14:16:41: HandleSIP1xxRinging: SDP MediaTypes negotiation successful!

Inband Alerting : 0

166.34.245.231:5060
*Mar 6 14:16:45: CCSIP-SPI-CONTROL: act_recdproc_new_message: SDP MediaTypes negotiation

successful!
*Mar 6 14:16:45: CCSIP-SPI-CONTROL: sipSPIReconnectConnection

*Mar 6 14:16:45: CCSIP-SPI-CONTROL: recv_200_OK_for_invite
*Mar 6 14:16:45: HandleUdpReconnection: Udp socket connected for fd: 1 with
166.34.245.231:5060
166.34.245.231:56101
*Mar 6 14:16:49: CCSIP-SPI-CONTROL: act_active_new_message
*Mar 6 14:16:49: CCSIP-SPI-CONTROL: sact_active_new_message_request
*Mar 6 14:16:49: CCSIP-SPI-CONTROL: sipSPIInitiateCallDisconnect : Initiate call
*Mar 6 14:16:49: CCSIP-SPI-CONTROL: act_disconnecting_disconnect

48340525
port: 5060

DB-276 May 2008
Debug Commands
debug ccsip error
The following example displays debug output from the other side of the call:
Router2# debug ccsip error
SIP Call error tracing is enabled

Router2#
166.34.245.230:55674
*Mar 8 17:42:39: CCSIP-SPI-CONTROL: sipSPISipIncomingCall
*Mar 8 17:42:39: CCSIP-SPI-CONTROL: act_idle_new_message
*Mar 8 17:42:39: CCSIP-SPI-CONTROL: sact_idle_new_message_invite
*Mar 8 17:42:39: sact_idle_new_message_invite:Not Using Voice Class Codec
*Mar 8 17:42:39: sact_idle_new_message_invite: Preferred codec[0] type: g711ulaw Bytes

:160
*Mar 8 17:42:39: sact_idle_new_message_invite: Media Negotiation successful for an
incoming call
*Mar 8 17:42:39: sact_idle_new_message_invite: Negotiated Codec : g711ulaw, bytes

:160
Preferred Codec : g711ulaw, bytes :160

*Mar 8 17:42:39: Num of Contact Locations 1 3660110 166.34.245.230 5060
*Mar 8 17:42:39: CCSIP-SPI-CONTROL: act_recdinvite_proceeding

*Mar 8 17:42:39: ccsip_caps_ind: codec(negotiated) = 5(Bytes 160)
*Mar 8 17:42:39: CCSIP-SPI-CONTROL: act_recdinvite_alerting
*Mar 8 17:42:39: 180 Ringing with SDP - not likely

*Mar 8 17:42:42: CCSIP-SPI-CONTROL: act_sentalert_connect
166.34.245.230:55674
*Mar 8 17:42:42: CCSIP-SPI-CONTROL: act_sentsucc_new_message
*Mar 8 17:42:47: CCSIP-SPI-CONTROL: act_active_disconnect
*Mar 8 17:42:47: CCSIP-SPI-CONTROL: act_active_connection_created

*Mar 8 17:42:47: CCSIP-SPI-CONTROL: sipSPICheckSocketConnection
*Mar 8 17:42:47: CCSIP-SPI-CONTROL: sipSPICheckSocketConnection: Connid(1) created to
166.34.245.230:5060, local_port 56101
166.34.245.230:55674
*Mar 8 17:42:47: CCSIP-SPI-CONTROL: act_disconnecting_new_message
*Mar 8 17:42:47: CCSIP-SPI-CONTROL: sact_disconnecting_new_message_response
*Mar 8 17:42:47: Roundtrip delay 0 milliseconds for method BYE


66856294

May 2008 DB-277
Debug Commands
debug ccsip error
port: 5060


DB-278 May 2008
Debug Commands
debug ccsip events
debug ccsip events

To enable tracing of events that are specific to service provider interface (SPI), use the debug ccsip
events command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug ccsip events
no debug ccsip events

universal gateways.
12.2(2)XB1 This command was introduced on the Cisco AS5850 universal
gateway.
Release 12.2(11)T.
12.2(15)T Much of the information formerly found in the output of the
debug ccsip events command is now reported in the output of
the debug ccsip info and debug ccsip media commands. The
debug ccsip events command now displays only the debugging
information specifically related to SIP events.
Usage Guidelines This command previously traced all events posted to Session Initiation Protocol (SIP) SPI from all
interfaces and also provided general SIP SPI information. Beginning with Cisco IOS Release 12.2(15)T,
the debug ccsip events command displays only debugging information specifically related to SIP SPI
events. Media stream and SIP SPI information is now reported in the debug ccsip media and debug
ccsip info command output.
Note This command is intended for use by Cisco technicians only.

May 2008 DB-279
Debug Commands
debug ccsip events
Examples The following is sample output from the debug ccsip events command for a Cisco 3660:
Router# debug ccsip events
SIP Call events tracing is enabled

Router#
Nov 15 18:20:25.779: Queued event from SIP SPI : SIPSPI_EV_CC_CALL_SETUP
Nov 15 18:20:25.779: Queued event from SIP SPI : SIPSPI_EV_CREATE_CONNECTION
Nov 15 18:20:25.783: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE
Nov 15 18:20:25.815: Queued event from SIP SPI : SIPSPI_EV_CREATE_CONNECTION
Nov 15 18:20:28.339: Queued event from SIP SPI : SIPSPI_EV_CLOSE_CONNECTION
Nov 15 18:20:50.844: Queued event from SIP SPI : SIPSPI_EV_CLOSE_CONNECTION
Nov 15 18:20:50.848: Queued event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECT

debug ccsip info Enables tracing of general SIP SPI information.
debug ccsip media Enables tracing of SIP call media streams.

DB-280 May 2008
Debug Commands
debug ccsip info
debug ccsip info

To enable tracing of general service provider interface (SPI) information, use the debug ccsip info
debug ccsip info
no debug ccsip info

Usage Guidelines Beginning in Cisco IOS Release 12.2(15)T, the debug ccsip info command is a separate option that
displays general SIP SPI information for debug purposes. In past releases, this output was part of the
debug ccsip events command.
Examples The following is sample output from the debug ccsip info command for a Cisco 3660:
Router# debug ccsip info
SIP Call info tracing is enabled

Router#
Nov 15 18:19:22.670: ****Adding to UAC table
Nov 15 18:19:22.670: adding call id E to table
Nov 15 18:19:22.670: CCSIP-SPI-CONTROL: act_idle_call_setup
Nov 15 18:19:22.670: act_idle_call_setup:Not using Voice Class Codec
Nov 15 18:19:22.670: act_idle_call_setup: preferred_codec set[0] type :g729r8 bytes: 20
Nov 15 18:19:22.670: sipSPICopyPeerDataToCCB: From CLI: Modem NSE payload = 100,
Passthrough = 0,Modem relay = 0, Gw-Xid = 1
SPRT latency 200, SPRT Retries = 12, Dict Size = 1024
String Len = 32, Compress dir = 3
Nov 15 18:19:22.670: ****Deleting from UAC table
Nov 15 18:19:22.670: ****Adding to UAC table
Nov 15 18:19:22.670: sipSPIUsetBillingProfile: sipCallId for billing records =
20A40C3B-D92C11D5-8015E1CC-C91F3F10@12.18.195.49
Nov 15 18:19:22.674: CCSIP-SPI-CONTROL: act_idle_connection_created
Nov 15 18:19:22.674: CCSIP-SPI-CONTROL: act_idle_connection_created: Connid(1) created to
172.18.193.190:5060, local_port 56981

May 2008 DB-281
Debug Commands
debug ccsip info
Nov 15 18:19:22.674: CCSIP-SPI-CONTROL: sipSPIOutgoingCallSDP

Nov 15 18:19:22.674: convert_codec_bytes_to_ptime: Values :Codec: g729r8 codecbytes :20,
ptime: 10
Nov 15 18:19:22.674: sip_generate_sdp_xcaps_list: Modem Relay disabled. X-cap not needed
Nov 15 18:19:22.674: sipSPIAddLocalContact
Nov 15 18:19:22.674: sip_stats_method
Nov 15 18:19:22.690: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr:
172.18.193.190:5060
Nov 15 18:19:22.690: CCSIP-SPI-CONTROL: act_sentinvite_new_message
Nov 15 18:19:22.690: CCSIP-SPI-CONTROL: sipSPICheckResponse
Nov 15 18:19:22.690: sip_stats_status_code
Nov 15 18:19:22.690: Roundtrip delay 16 milliseconds for method INVITE
172.18.193.190:5060
Nov 15 18:19:22.706: CCSIP-SPI-CONTROL: act_recdproc_new_message
Nov 15 18:19:22.706: Roundtrip delay 32 milliseconds for method INVITE
Nov 15 18:19:22.706: sipSPIGetSdpBody : Parse incoming session description
Nov 15 18:19:22.706: HandleSIP1xxSessionProgress: Content-Disposition received in 18x
response:session;handling=required
Nov 15 18:19:22.706: sipSPIDoMediaNegotiation: number of m lines is 1
Nov 15 18:19:22.706: sipSPIDoAudioNegotiation: Codec (g729r8) Negotiation Successful on
Static Payload
Nov 15 18:19:22.706: sipSPIDoPtimeNegotiation: One ptime attribute found - value:10
Nov 15 18:19:22.706: convert_ptime_to_codec_bytes: Values :Codec: g729r8 ptime :10,
codecbytes: 20
ptime: 10
Nov 15 18:19:22.710: sipSPIDoDTMFRelayNegotiation: m-line index 1
Nov 15 18:19:22.710: sipSPIDoDTMFRelayNegotiation: Requested DTMF-RELAY option(s) not
found in Preferred DTMF-RELAY option list!
Nov 15 18:19:22.710: sip_sdp_get_modem_relay_cap_params:
Nov 15 18:19:22.710: sip_sdp_get_modem_relay_cap_params: NSE payload from X-cap = 0
Nov 15 18:19:22.710: sip_do_nse_negotiation: NSE Payload 100 found in SDP
Nov 15 18:19:22.710: sip_do_nse_negotiation: Remote NSE payload = local one = 100, Use it
Nov 15 18:19:22.710: sip_select_modem_relay_params: X-tmr not present in SDP. Disable
modem relay
Nov 15 18:19:22.710: sipSPIDoQoSNegotiation - SDP body with media description
Nov 15 18:19:22.710: ccsip_process_response_contact_record_route
Nov 15 18:19:22.710: CCSIP-SPI-CONTROL: ccsip_bridge: confID = 4, srcCallID = 14,
dstCallID = 13
Nov 15 18:19:22.710: sipSPIUupdateCcCallIds: old src/dest ccCallids: -1/-1, new src/dest
ccCallids: 14/13
Nov 15 18:19:22.710: sipSPIUupdateCcCallIds: old streamcallid=-1, new streamcallid=14
Nov 15 18:19:22.710: CCSIP-SPI-CONTROL: ccsip_caps_ind
Nov 15 18:19:22.710: ccsip_get_rtcp_session_parameters: CURRENT VALUES: stream_callid=14,
current_seq_num=0x1B1B
Nov 15 18:19:22.710: ccsip_get_rtcp_session_parameters: NEW VALUES: stream_callid=14,
current_seq_num=0x180C
Nov 15 18:19:22.710: ccsip_caps_ind: Load DSP with negotiated codec : g729r8, Bytes=20
Nov 15 18:19:22.710: ccsip_caps_ind: set forking flag to 0x0
Nov 15 18:19:22.710: sipSPISetDTMFRelayMode: set DSP for dtmf-relay =
CC_CAP_DTMF_RELAY_INBAND_VOICE_AND_OOB
Nov 15 18:19:22.710: sip_set_modem_caps: Negotiation already Done. Set negotiated Modem
caps
Nov 15 18:19:22.710: sip_set_modem_caps: Modem Relay & Passthru both disabled
Nov 15 18:19:22.710: sip_set_modem_caps: nse payload = 100, ptru mode = 0, ptru-codec=0,
redundancy=0, xid=0, relay=0, sprt-retry=12, latecncy=200, compres-dir=3, dict=1024,
strnlen=32
Nov 15 18:19:22.710: ccsip_caps_ind: Load DSP with codec : g729r8, Bytes=20
Nov 15 18:19:22.710: CCSIP-SPI-CONTROL: ccsip_caps_ack
Nov 15 18:19:22.710: ccsip_caps_ack: set forking flag to 0x60FD1EAC
Nov 15 18:19:22.710: CCSIP-SPI-CONTROL: act_recdproc_connection_created

DB-282 May 2008
Debug Commands
debug ccsip info
Nov 15 18:19:22.710: CCSIP-SPI-CONTROL: sipSPICheckSocketConnection: Connid(2) created to

172.18.193.190:5060, local_port 51663
172.18.193.190:5060
Nov 15 18:19:22.722: Roundtrip delay 48 milliseconds for method PRACK
172.18.193.190:5060
Nov 15 18:19:24.706: Roundtrip delay 2032 milliseconds for method PRACK
Nov 15 18:19:24.706: sipSPIGetSdpBody : Parse incoming session description
Nov 15 18:19:24.710: CCSIP-SPI-CONTROL: sipSPIUACSessionTimer
Nov 15 18:19:24.710: CCSIP-SPI-CONTROL: act_recdproc_continue_200_processing
Nov 15 18:19:24.710: CCSIP-SPI-CONTROL: act_recdproc_continue_200_processing: *** This ccb
is the parent
Nov 15 18:19:24.710: sipSPICompareRespMediaInfo
Nov 15 18:19:24.710: sipSPIDoMediaNegotiation: number of m lines is 1
Nov 15 18:19:24.710: sipSPIDoAudioNegotiation: Codec (g729r8) Negotiation Successful on
Static Payload
Nov 15 18:19:24.710: sipSPIDoPtimeNegotiation: One ptime attribute found - value:10
Nov 15 18:19:24.710: convert_ptime_to_codec_bytes: Values :Codec: g729r8 ptime :10,
codecbytes: 20
ptime: 10
Nov 15 18:19:24.710: sipSPIDoDTMFRelayNegotiation: m-line index 1
Nov 15 18:19:24.710: sipSPIDoDTMFRelayNegotiation: Requested DTMF-RELAY option(s) not
found in Preferred DTMF-RELAY option list!
Nov 15 18:19:24.710: sip_sdp_get_modem_relay_cap_params:
Nov 15 18:19:24.710: sip_sdp_get_modem_relay_cap_params: NSE payload from X-cap = 0
Nov 15 18:19:24.710: sip_do_nse_negotiation: NSE Payload 100 found in SDP
Nov 15 18:19:24.710: sip_do_nse_negotiation: Remote NSE payload = local one = 100, Use it
Nov 15 18:19:24.710: sip_select_modem_relay_params: X-tmr not present in SDP. Disable
modem relay
Nov 15 18:19:24.710: sipSPIProcessMediaChanges
Nov 15 18:19:24.710: ccsip_process_response_contact_record_route
Nov 15 18:19:24.710: CCSIP-SPI-CONTROL: sipSPIProcess200OKforinvite
Nov 15 18:19:24.710: udpsock_close_connect: Socket fd: 1 closed for connid 1 with remote
port: 5060
172.18.193.190:52180
Nov 15 18:19:37.483: ****Found CCB in UAC table
Nov 15 18:19:37.483: CCSIP-SPI-CONTROL: act_active_new_message
Nov 15 18:19:37.483: CCSIP-SPI-CONTROL: sact_active_new_message_request
Nov 15 18:19:37.483: CCSIP-SPI-CONTROL: sipSPIInitiateCallDisconnect : Initiate call
Nov 15 18:19:37.483: udpsock_close_connect: Socket fd: 2 closed for connid 2 with remote
port: 5060
Nov 15 18:19:37.483: CCSIP-SPI-CONTROL: act_disconnecting_disconnect
Nov 15 18:19:37.483: CCSIP-SPI-CONTROL: sipSPICallCleanup
Nov 15 18:19:37.483: sipSPIIcpifUpdate :CallState: 4 Playout: 10230 DiscTime:1745148
ConnTime 1743871
Nov 15 18:19:37.483: ****Deleting from UAC table
Nov 15 18:19:37.483: Removing call id E
Nov 15 18:19:37.483: freeing ccb 63330954

May 2008 DB-283
Debug Commands
debug ccsip info

debug ccsip events Enables tracing of events that are specific to SIP SPI.
debug ccsip media Enables tracing of SIP call media streams.

DB-284 May 2008
Debug Commands
debug ccsip media
debug ccsip media

To enable tracing of Session Initiation Protocol (SIP) call media streams, use the debug ccsip media
debug ccsip media
no debug ccsip media

Usage Guidelines Beginning in Cisco IOS Release 12.2(15)T, the debug ccsip media command is a separate option that
displays debugging information specific to SIP media stream processing. In past releases, this output was
part of the debug ccsip events command.
Examples The following is sample output from the debug ccsip media command for a Cisco 3660:
Router# debug ccsip media
SIP Call media tracing is enabled

Router#
Nov 15 18:19:53.835: sipSPISetMediaSrcAddr: media src addr for stream 1 = 172.18.195.49
Nov 15 18:19:53.835: sipSPIReserveRtpPort: reserved port 16500 for stream 1
Nov 15 18:19:53.867: sipSPIReplaceSDP
Nov 15 18:19:53.871: sipSPICopySdpInfo
Nov 15 18:19:53.871: sipSPIUpdCallWithSdpInfo:
Preferred Codec : g729r8, bytes :20
Preferred DTMF relay : inband-voice
Preferred NTE payload : 101
Early Media : No
Delayed Media : No
Bridge Done : No
New Media : No
DSP DNLD Reqd : No
M-line Index : 1

May 2008 DB-285
Debug Commands
debug ccsip media
State : STREAM_ADDING (3)

Callid : -1
Negotiated Codec : g729r8, bytes :20
Negotiated DTMF relay : inband-voice
Negotiated NTE payload : 0
Media Srce Addr/Port : 172.18.195.49:16500
Media Dest Addr/Port : 172.18.193.190:19148
Nov 15 18:19:53.871: sipSPIProcessRtpSessions
Nov 15 18:19:53.871: sipSPIAddStream: Adding stream 1 (callid 16) to the VOIP RTP library
Nov 15 18:19:53.871: sipSPIUpdateRtcpSession: for m-line 1
Nov 15 18:19:53.871: sipSPIUpdateRtcpSession: rtcp_session info
laddr = 172.18.195.49, lport = 16500, raddr = 172.18.193.190, rport=19148
Nov 15 18:19:53.871: sipSPIUpdateRtcpSession: No rtp session, creating a new one
Nov 15 18:19:53.871: sipSPISetStreamInfo: num_streams = 1
Nov 15 18:19:53.871: sipSPISetStreamInfo: adding stream type 0 from mline 1
Nov 15 18:19:53.871: sipSPISetStreamInfo: caps.stream_count=1,
caps.stream[0].stream_type=0x1, caps.stream_list.xmitFunc=voip_rtp_xmit,
caps.stream_list.context=0x634F1F2C (gccb)
Nov 15 18:19:55.555: sipSPICompareSDP
Nov 15 18:19:55.555: sipSPICompareStreams: stream 1 dest_port: old=19148 new=19148
Nov 15 18:19:55.555: sipSPICompareStreams: Flags set for stream 1: RTP_CHANGE=No
CAPS_CHANGE=No
Nov 15 18:19:55.555: sipSPICompareSDP: Flags set for call: NEW_MEDIA=No DSPDNLD_REQD=No
Nov 15 18:19:55.555: sipSPIReplaceSDP
Nov 15 18:19:55.555: sipSPICopySdpInfo
Preferred Codec : g729r8, bytes :20
Preferred DTMF relay : inband-voice
Preferred NTE payload : 101
Early Media : No
Delayed Media : No
Bridge Done : Yes
New Media : No
DSP DNLD Reqd : No
M-line Index : 1
State : STREAM_ACTIVE (3)
Callid : 16
Negotiated Codec : g729r8, bytes :20
Negotiated DTMF relay : inband-voice
Negotiated NTE payload : 0
Media Srce Addr/Port : 172.18.195.49:16500
Media Dest Addr/Port : 172.18.193.190:19148

debug ccsip events Enables tracing of events that are specific to SIP SPI.
debug ccsip info Enables tracing of general SIP SPI events.

DB-286 May 2008
Debug Commands

To show all Session Initiation Protocol (SIP) Service Provider Interface (SPI) message tracing, use the
debug ccsip messages command in privileged EXEC mode. To disable debugging output, use the no
no debug ccsip messages

12.1.(3)T The output of this command was changed.
universal gateways.
gateway.
12.2(8)T This command was implemented on Cisco 7200 series routers.
Release 12.2(11)T. Support for the Cisco AS5300 universal
access server, Cisco AS5350, Cisco AS5400, and Cisco AS5850
universal gateway is not included in this release.
Usage Guidelines This command traces the Session Initiation Protocol (SIP) messages exchanged between the SIP UA
client (UAC) and the access server.
Examples The following example shows debug output from one side of the call:
Router1# debug ccsip messages
SIP Call messages tracing is enabled

Router1#
*Mar 6 14:19:14: Sent:
Via: SIP/2.0/UDP 166.34.245.230:55820
From: "3660110" <sip:3660110@166.34.245.230>

May 2008 DB-287
Debug Commands
Date: Sat, 06 Mar 1993 19:19:14 GMT
Call-ID: ABBAE7AF-823100E2-0-1CD274BC@172.18.192.194
Cisco-Guid: 2881152943-2184249568-0-483551624
CSeq: 101 INVITE
Max-Forwards: 6
Expires: 180
Content-Length: 138
v=0
s=SIP Call
t=0 0
c=IN IP4 166.34.245.230

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 166.34.245.230:55820
From: "3660110" <sip:3660110@166.34.245.230>
Date: Mon, 08 Mar 1993 22:45:12 GMT
CSeq: 101 INVITE
Content-Length: 0

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 166.34.245.230:55820
From: "3660110" <sip:3660110@166.34.245.230>
Date: Mon, 08 Mar 1993 22:45:12 GMT
CSeq: 101 INVITE
Content-Length: 138
v=0
s=SIP Call
t=0 0
c=IN IP4 166.34.245.231

SIP/2.0 200 OK
Via: SIP/2.0/UDP 166.34.245.230:55820
From: "3660110" <sip:3660110@166.34.245.230>
To: <sip:3660210@166.34.245.231;user=phone;phone-context=unknown>;tag=27DBC6D8-1357
Date: Mon, 08 Mar 1993 22:45:12 GMT
CSeq: 101 INVITE

DB-288 May 2008
Debug Commands
Content-Length: 138
v=0
s=SIP Call
t=0 0
c=IN IP4 166.34.245.231
*Mar 6 14:19:16: Sent:

Via: SIP/2.0/UDP 166.34.245.230:55820
From: "3660110" <sip:3660110@166.34.245.230>
Date: Sat, 06 Mar 1993 19:19:14 GMT
Max-Forwards: 6
Content-Length: 138
CSeq: 101 ACK
v=0
s=SIP Call
t=0 0
c=IN IP4 166.34.245.230

Via: SIP/2.0/UDP 166.34.245.231:53600
From: <sip:3660210@166.34.245.231;user=phone;phone-context=unknown>;tag=27DBC6D8-1357
To: "3660110" <sip:3660110@166.34.245.230>
Date: Mon, 08 Mar 1993 22:45:14 GMT
Max-Forwards: 6
CSeq: 101 BYE
Content-Length: 0
*Mar 6 14:19:19: Sent:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 166.34.245.231:53600
To: "3660110" <sip:3660110@166.34.245.230>
Date: Sat, 06 Mar 1993 19:19:19 GMT
Content-Length: 0
CSeq: 101 BYE
The following example show debug output from the other side of the call:
Router2# debug ccsip messages
SIP Call messages tracing is enabled

Router2#
Via: SIP/2.0/UDP 166.34.245.230:55820
From: "3660110" <sip:3660110@166.34.245.230>

May 2008 DB-289
Debug Commands
Date: Sat, 06 Mar 1993 19:19:14 GMT

Cisco-Guid: 2881152943-2184249568-0-483551624
CSeq: 101 INVITE
Max-Forwards: 6
Expires: 180
Content-Length: 138
v=0
s=SIP Call
t=0 0
c=IN IP4 166.34.245.230
*Mar 8 17:45:12: Sent:

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 166.34.245.230:55820
From: "3660110" <sip:3660110@166.34.245.230>
Date: Mon, 08 Mar 1993 22:45:12 GMT
CSeq: 101 INVITE
Content-Length: 0
*Mar 8 17:45:12: Sent:

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 166.34.245.230:55820
From: "3660110" <sip:3660110@166.34.245.230>
Date: Mon, 08 Mar 1993 22:45:12 GMT
CSeq: 101 INVITE
Content-Length: 138
v=0
s=SIP Call
t=0 0
c=IN IP4 166.34.245.231
*Mar 8 17:45:14: Sent:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 166.34.245.230:55820
From: "3660110" <sip:3660110@166.34.245.230>
Date: Mon, 08 Mar 1993 22:45:12 GMT
CSeq: 101 INVITE
Content-Length: 138

DB-290 May 2008
Debug Commands
v=0
s=SIP Call
t=0 0
c=IN IP4 166.34.245.231

Via: SIP/2.0/UDP 166.34.245.230:55820
From: "3660110" <sip:3660110@166.34.245.230>
Date: Sat, 06 Mar 1993 19:19:14 GMT
Max-Forwards: 6
Content-Length: 138
CSeq: 101 ACK
v=0
s=SIP Call
t=0 0
c=IN IP4 166.34.245.230
*Mar 8 17:45:17: Sent:

Via: SIP/2.0/UDP 166.34.245.231:53600
To: "3660110" <sip:3660110@166.34.245.230>
Date: Mon, 08 Mar 1993 22:45:14 GMT
Max-Forwards: 6
CSeq: 101 BYE
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 166.34.245.231:53600
To: "3660110" <sip:3660110@166.34.245.230>
Date: Sat, 06 Mar 1993 19:19:19 GMT
Content-Length: 0
CSeq: 101 BYE
Related Commands debug ccsip all Enables all SIP-related debugging.


May 2008 DB-291
Debug Commands
debug ccsip preauth
debug ccsip preauth

To enable diagnostic reporting of authentication, authorization, and accounting (AAA) preauthentication
for Session Initiation Protocol (SIP) calls, use the debug ccsip preauth command in privileged EXEC
debug ccsip preauth
no debug ccsip preauth

Examples The following example shows debug output for a single SIP call:
Router# debug ccsip preauth
SIP Call preauth tracing is enabled

Jan 23 18:43:17.898::Preauth Required
Jan 23 18:43:17.898: In sipSPISendPreauthReq for preauth_id = 86515, ccb = 67AF4E10
Jan 23 18:43:17.898: Entering rpms_proc_print_preauth_req
Jan 23 18:43:17.898: Request = 0

Jan 23 18:43:17.898: Preauth id = 86515
Jan 23 18:43:17.898: EndPt Type = 1
Jan 23 18:43:17.898: EndPt = 192.168.80.70
Jan 23 18:43:17.898: Resource Service = 1
Jan 23 18:43:17.898: Call_origin = answer
Jan 23 18:43:17.898: Call_type = voip
Jan 23 18:43:17.898: Calling_num = 2270001
Jan 23 18:43:17.898: Called_num = 1170001
Jan 23 18:43:17.898: Protocol = 1
Jan 23 18:43:17.898:sipSPISendPreauthReq:Created node with preauth_id = 86515, ccb
67AF4E10 , node 6709C280
Jan 23 18:43:17.898:rpms_proc_create_node:Created node with preauth_id = 86515
Jan 23 18:43:17.898:rpms_proc_send_aaa_req:uid got is 466728
Jan 23 18:43:17.902:rpms_proc_preauth_response:Context is for preauth_id 86515, aaa_uid
466728
Jan 23 18:43:17.902:rpms_proc_preauth_response:Deleting Tree node for preauth id 86515 uid
466728

DB-292 May 2008
Debug Commands
debug ccsip preauth
Jan 23 18:43:17.902:sipSPIGetNodeForPreauth:Preauth_id=86515
Jan 23 18:43:17.902: ccsip_spi_process_preauth_event:67AF4E10 ccb & 6709C280 node

Jan 23 18:43:17.902: In act_preauth_response:67AF4E10 ccb
Jan 23 18:43:17.902: act_preauth_response:Deleting node 6709C280 from tree
Table 51 debug ccsip preauth Field Descriptions
Field Description
Request Request Type0 for preauthentication, 1 for disconnect.
Preauth id Identifier for the preauthentication request.
EndPt Type Call Origin End Point Type1 for IP address, 2 for Interzone ClearToken
(IZCT) value.
EndPt Call Origin End Point ValueAn IP address or IZCT value.
Resource Service Resource Service Type1 for Reservation, 2 for Query.
Call_origin Answer.
Call_type Voice over IP (VoIP).
Calling_num Calling Party Number (CLID).
Called_num Called Party Number (DNIS).
Protocol 0 for H.323, 1 for SIP.
function reports Various identifiers and status reports for executed functions.

May 2008 DB-293
Debug Commands
debug ccsip states
debug ccsip states

To show all Session Initiation Protocol (SIP) Service Provider Interface (SPI) state tracing, use the
debug ccsip states command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug ccsip states
no debug ccsip states

universal gateways.
gateway.
12.2(8)T This command was implemented on Cisco 7200 series routers.
Usage Guidelines This command traces the state machine changes of SIP SPI and displays the state transitions.
Examples The following example shows all SIP SPI state tracing:
Router1# debug ccsip states
SIP Call states tracing is enabled

Router1#
*Jan 2 18:34:37.793:0x6220C634 :State change from (STATE_NONE, SUBSTATE_NONE) to
*Jan 2 18:34:37.797:0x6220C634 :State change from (STATE_IDLE, SUBSTATE_NONE) to
*Jan 2 18:34:37.797:0x6220C634 :State change from (STATE_IDLE, SUBSTATE_CONNECTING) to

DB-294 May 2008
Debug Commands
debug ccsip states
*Jan 2 18:34:37.801:0x6220C634 :State change from (STATE_IDLE, SUBSTATE_CONNECTING) to

(STATE_SENT_INVITE, SUBSTATE_NONE)
*Jan 2 18:34:37.809:0x6220C634 :State change from (STATE_SENT_INVITE, SUBSTATE_NONE) to
(STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)
*Jan 2 18:34:37.853:0x6220C634 :State change from (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING)
*Jan 2 18:34:38.261:0x6220C634 :State change from (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_ALERTING) to (STATE_ACTIVE, SUBSTATE_NONE)
*Jan 2 18:35:09.860:0x6220C634 :State change from (STATE_ACTIVE, SUBSTATE_NONE) to
*Jan 2 18:35:09.868:0x6220C634 :State change from (STATE_DISCONNECTING, SUBSTATE_NONE) to
*Jan 2 18:28:38.404: Queued event from SIP SPI :SIPSPI_EV_CLOSE_CONNECTION


May 2008 DB-295
Debug Commands
debug ccsip transport

To enable tracing of the Session Initiation Protocol (SIP) transport handler and the TCP or User
Datagram Protocol (UDP) process, use the debug ccsip transport command in privileged EXEC mode.
no debug ccsip transport

Usage Guidelines Use the debug ccsip transport command to debug issues related to connection and transport usage and
to see the flow of the messages being sent or received.
Examples The following is sample output from the debug ccsip transport command for a Cisco 3660:
Router# debug ccsip transport
.
.
.
1w1d: //18/8E16980D800A/SIP/Transport/sipSPISendInvite: Sending Invite to the transport
layer
1w1d: //18/8E16980D800A/SIP/Transport/sipSPIGetSwitchTransportFlag: Return the Global
configuration, Switch Transport is TRUE
1w1d: //18/8E16980D800A/SIP/Transport/sipSPITransportSendMessage: msg=0x64082D50,
addr=172.18.194.183, port=5060, sentBy_port=0, is_req=1, transport=1, switch=1,
callBack=0x614FAB58
1w1d: //18/8E16980D800A/SIP/Transport/sipSPITransportSendMessage: Proceedable for sending
msg immediately
1w1d: //18/8E16980D800A/SIP/Transport/sipTransportLogicSendMsg: switch transport is 1
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportGetInterfaceMtuSize: MTU size for remote
address 172.18.194.183 is 500
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportVerifyMsgForMTUThreshold: Interface MTU
Size 500, Msg Size 1096
1w1d: //18/8E16980D800A/SIP/Transport/sipTransportLogicSendMsg: Switching msg=0x64082D50
transport UDP->TCP
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportSetAgeingTimer: Aging timer initiated
for holder=0x64084058,addr=172.18.194.183
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipCreateConnHolder: Created new holder=0x64084058,
addr=172.18.194.183
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostRequestConnection: Posting TCP conn
create request for addr=172.18.194.183, port=5060, context=0x64128D5C

DB-296 May 2008
Debug Commands
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportSetConnWaitTimer: Wait timer set for

connection=0x64129BF4,addr=172.18.194.183, port=5060
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipCreateConnInstance: Created new initiated
conn=0x64129BF4, connid=-1, addr=172.18.194.183, port=5060, transport=tcp
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerProcessConnCreated:
gConnTab=0x64128D5C, addr=172.18.194.183, port=5060, connid=1, transport=tcp
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipInstanceHandleConnectionCreated: Moving
connection=0x64129BF4, connid=1state to pending
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWConnectionCreated:
context=0x64128D5C
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerProcessConnCreated:
gConnTab=0x64128D5C, addr=172.18.194.183, port=5060, connid=1, transport=tcp
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage: Posting send for
msg=0x64082D50, addr=172.18.194.183, port=5060, connId=1 for TCP
.
.
.
Table 52 debug ccsip transport Field Descriptions
Field Description
Sending Invite to the Indicates that the SIP signaling state machine has invoked transport layer
transport layer operations such as transport arbitration logic and the connection
management interface.
switch transport is 1 Indicates that the gateway has been provisioned to enable the transport
switching functionality based on the message size. 1 is true and 0 is false.
MTU size for remote Indicates that the bound outgoing Ethernet interface that sends the message
address to the given remote address is configured for an MTU size of the indicated
value.
Interface MTU Size Indicates that the size of the message is larger than the size of the MTU; thus
500, Msg Size 1096 transport switching (from UDP to TCP) should be enabled.
Switching msg=... Indicates that transport switching from UDP to TCP is occurring for the
transport UDP->TCP handled message because of the large size of the message.
Aging timer initiated for Indicates that the connection algorithm is started; that is, the counter begins
holder to age out the TCP or UDP connection if inactivity occurs.
Posting TCP conn Indicates a request for a TCP connection from a lower TCP process.
create request
sipSPITransportSendM Indicates all the transport related attributes that the SIP signaling state
essage:msg=0x64082D machine originally gives to the transport layer to send out the message. The
50, addr=...transport=1, attributes are:
switch=1,
transport: 1 for UDP; 2 for TCP.
callBack=0x614FAB58
switch (switching transport enabled or disabled for large messages): 1
for enabled; 0 for disabled.
Posting send for Indicates that all transport and connection related operations are complete.
msg=0x64082D50, The message is sent out on the network targeted to the given address, port,
addr=...for TCP and transport.

May 2008 DB-297
Debug Commands

debug ccsip info Enables tracing of general SIP SPI information.
transport switch Enables switching between UDP and TCP transport mechanisms globally for
large SIP messages.
voice-class sip Enables switching between UDP and TCP transport mechanisms for large
transport switch SIP messages for a specific dial peer.

DB-298 May 2008
Debug Commands
debug ccswvoice vo-debug

To display detailed debugging information related to ccswvoice function calls during call setup and
teardown, use the debug ccswvoice vo-debug command in privileged EXEC mode. To disable
no debug ccswvoice vo-debug

11.3(1)MA This command was introduced on the Cisco MC3810 networking device.
12.0(7)XK This command was implemented on the Cisco 3600 series router.
Usage Guidelines Use this command when attempting to troubleshoot a Vo call that uses the cisco-switched session
protocol. This command provides the same information as the debug ccswvoice vo-session command,
but includes additional debugging information relating to the calls.
Examples The following shows sample output from the debug ccswvoice vo-debug command:
Router# debug ccswvoice vo-debug
2w2d: ccswvoice: callID 529927 pvcid -1 cid -1 state NULL event O/G SETUP
2w2d: ccswvoice_out_callinit_setup: callID 529927 using pvcid 1 cid 15
2w2d: ccswvoice: callID 529927 pvcid 1 cid 15 state O/G INIT event I/C PROC
2w2d: ccswvoice: callID 529927 pvcid 1 cid 15 state O/G PROC event I/C
ALERTccfrf11_caps_ind: codec(preferred) = 1
2w2d: ccswvoice: callID 529927 pvcid 1 cid 15 state O/G ALERT event I/C CONN
2w2d: ccswvoice_bridge_drop: dropping bridge calls src 529927 dst 529926 pvcid 1 cid 15
state ACTIVE
2w2d: ccswvoice: callID 529927 pvcid 1 cid 15 state ACTIVE event O/G REL
2w2d: ccswvoice: callID 529927 pvcid 1 cid 15 state RELEASE event I/C RELCOMP
2w2d: ccswvo_store_call_history_entry: cause=10 tcause=10 cause_text=normal call
clearing.

May 2008 DB-299
Debug Commands

debug ccswvoice vo-session Displays the first 10 bytes (including header) of selected VoFR

DB-300 May 2008
Debug Commands
debug ccswvoice vofr-debug

To display the ccswvoice function calls during call setup and teardown, use the debug ccswvoice
vofr-debug command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
no debug ccswvoice vofr-debug

12.0(3)XG This command was introduced on the Cisco 2600 and Cisco 3600 series
routers.
12.0(7)XK This command was implemented on the Cisco MC3810 networking
device.
Usage Guidelines Use this command when troubleshooting a VoFR call that uses the cisco-switched session protocol.
This command provides the same information as the debug ccswvoice vofr-session command, but
includes additional debugging information relating to the calls.
Examples The following shows sample output from the debug ccswvoice vofr-debug command:
Router# debug ccswvoice vofr-debug
CALL TEARDOWN:
3640_vofr(config-voiceport)#
*Mar 1 03:02:08.719:ccswvofr_bridge_drop:dropping bridge calls src 17 dst 16 dlci 100
cid 9 state ACTIVE
*Mar 1 03:02:08.727:ccswvofr:callID 17 dlci 100 cid 9 state ACTIVE event O/G REL
*Mar 1 03:02:08.735:ccswvofr:callID 17 dlci 100 cid 9 state RELEASE event I/C RELCOMP
*Mar 1 03:02:08.735:ccswvofr_store_call_history_entry:cause=22 tcause=22
cause_text=no circuit.
CALL SETUP (outgoing):

*Mar 1 03:03:22.651:ccswvofr:callID 23 dlci -1 cid -1 state NULL event O/G SETUP
*Mar 1 03:03:22.651:ccswvofr_out_callinit_setup:callID 23 using dlci 100 cid 10
*Mar 1 03:03:22.659:ccswvofr:callID 23 dlci 100 cid 10 state O/G INIT event I/C PROC

May 2008 DB-301
Debug Commands
*Mar 1 03:03:22.667:ccswvofr:callID 23 dlci 100 cid 10 state O/G PROC event I/C CONN
ccfrf11_caps_ind:codec(preferred) = 0

debug cch323 Displays the ccfrf11 function calls during call setup and teardown.
debug ccsw voice vo-debug Displays the ccswvoice function calls during call setup and teardown.

DB-302 May 2008
Debug Commands
debug ccswvoice vofr-session

To display the ccswvoice function calls during call setup and teardown, use the debug ccswvoice
vofr-session command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
no debug ccswvoice vofr-session

12.0(3)XG This command was introduced on the Cisco 2600 and Cisco 3600 series
routers.
12.0(7)XK This command was implemented on the Cisco MC3810 networking
device.
Usage Guidelines Use this command to show the state transitions of the cisco-switched-vofr state machine as a call is
processed, and when attempting to troubleshoot a VoFR call that uses the cisco-switched session
protocol.
Examples The following shows sample output from the debug ccswvoice vofr-session command:
Router# debug ccswvoice vofr-session
CALL TEARDOWN:
*Mar 1 02:58:13.203:ccswvofr:callID 14 dlci 100 cid 8 state ACTIVE event O/G REL
*Mar 1 02:58:13.215:ccswvofr:callID 14 dlci 100 cid 8 state RELEASE event I/C RELCOMP
CALL SETUP (outgoing):

*Mar 1 02:59:46.551:ccswvofr:callID 17 dlci -1 cid -1 state NULL event O/G SETUP
*Mar 1 02:59:46.559:ccswvofr:callID 17 dlci 100 cid 9 state O/G INIT event I/C PROC
*Mar 1 02:59:46.567:ccswvofr:callID 17 dlci 100 cid 9 state O/G PROC event I/C CONN

May 2008 DB-303
Debug Commands

debug cch323 Displays the ccfrf11 function calls during call setup and teardown.
debug call rsvp-sync events Displays events that occur during RSVP setup.

DB-304 May 2008
Debug Commands
debug ccswvoice vo-session

To display the first 10 bytes (including header) of selected VoFR subframes for the interface, use the
debug ccswvoice vo-session command in privileged EXEC mode. To disable debugging output, use the
no debug ccswvoice vo-session

11.3(1)MA This command was introduced on the Cisco MC3810 networking device.
12.0(7)XK This command was implemented on the Cisco 3600 series router.
Usage Guidelines Use this command to show the state transitions of the cisco-switched-vo state machine as a call is
processed. This command should be used when attempting to troubleshoot a Vo call that uses the
cisco-switched session protocol.
Examples The following shows sample output from the debug ccswvoice vo-session command:
Router# debug ccswvoice vo-session
2w2d: ccswvoice: callID 529919 pvcid -1 cid -1 state NULL event O/G SETUP
2w2d: ccswvoice: callID 529919 pvcid 1 cid 11 state O/G INIT event I/C PROC
2w2d: ccswvoice: callID 529919 pvcid 1 cid 11 state O/G PROC event I/C ALERT
2w2d: ccswvoice: callID 529919 pvcid 1 cid 11 state O/G ALERT event I/C CONN
2w2d: ccswvoice: callID 529919 pvcid 1 cid 11 state ACTIVE event O/G REL
2w2d: ccswvoice: callID 529919 pvcid 1 cid 11 state RELEASE event I/C RELCOMP

debug ccswvoice vo-debug Displays detailed debugging information related to ccswvoice
function calls during call setup and teardown.

May 2008 DB-305
Debug Commands
debug cdapi
debug cdapi
To display information about the Call Distributor Application Programming Interface (CDAPI), use the
debug cdapi command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug cdapi {detail | events}
no debug cdapi {detail | events}
Syntax Description detail Displays when applications register or become unregistered with CDAPI,
when calls are added or deleted from the CDAPI routing table, and when
CDAPI messages are created and freed.
events Displays the events passing between CDAPI and an application or
signalling stack.
Defaults Debugging output is disabled.

12.1(5)XM2 This command was implemented on the Cisco AS5350 and
Cisco AS5400.
This command was enhanced to show V.110 call types.
12.3(4)T This command was enhanced to show V.120 call types.
12.2(33)SRA.
Usage Guidelines The detail keyword is useful for determining if messages are being lost (or not freed). It is also useful
for determining the size of the raw messages passed between CDAPI and other applications to ensure
that the correct number of bytes is being passed.
The events keyword is useful for determining if certain ISDN messages are not being received by an
application and if calls are not being directed to an application.
The following bandwidths are supported:
56 kbps
64 kbps

DB-306 May 2008
Debug Commands
debug cdapi
Examples The following Media Gateway Control Protocol (MGCP) packet received example shows V.110 call
debugging output for the debug cdapi detail command. In this example, the modem is not yet in
STEADY_STATE.
Router# debug cdapi detail
Sep 26 19:12:25.327:MGCP Packet received from 10.0.44.109:2427-

CRCX 6318 s7/ds1-0/24 MGCP 1.0
C:111
M:nas/data
L:b:64, nas/bt:v.110, nas/cdn:234567
R:nas/au, nas/ax,nas/of, nas/crq
X:101
Sep 26 19:12:25.327:CDAPI:cdapi_create_msg():CDAPI Pool Count:959, Raw Length = 0

Sep 26 19:12:25.327:CDAPI Se7/1:23:cdapi_add_entry_callRoutingTbl() -
Sep 26 19:12:25.327: Added entry for call 0x7017 for application CSM
Sep 26 19:12:25.331:CDAPI:cdapi_create_msg():CDAPI Pool Count:958,
router# Raw Length = 0
Sep 26 19:12:25.331:CDAPI:cdapi_free_msg():Raw Length = 0, freeRaw = 1, Raw Msg = 0x0
Sep 26 19:12:25.331:CDAPI:cdapi_free_msg():CDAPI Pool Count:959
Sep 26 19:12:25.331:send_mgcp_msg, MGCP Packet sent to 10.0.44.109:2427 --->
Sep 26 19:12:25.331:200 6318 Alert

I:64524608
Sep 26 19:12:25.339:CDAPI:cdapi_crea
router#te_msg():CDAPI Pool Count:959, Raw Length = 0
router#
DLCX 6319 s7/ds1-0/24 MGCP 1.0

Sep 26 19:12:33.227:CDAPI:cdapi_create_msg():CDAPI Pool Count:958, Raw
router# Length = 0
Sep 26 19:12:33.227:CDAPI Se7/1:23:cdapi_del_entry_callRoutingTbl() -
Sep 26 19:12:33.227: Deleted entry for call 0x7017
Sep 26 19:12:33.227:send_mgcp_msg, MGCP Packet sent
router#to 10.0.44.109:2427 --->
Sep 26 19:12:33.227:200 6319 OK
The following partial example shows V.120 call debugging output for the debug cdapi detail command:
Router# debug cdapi detail
May 14 19:12:25.327:MGCP Packet received from 10.0.44.109:2427-

CRCX 6318 s7/ds1-0/24 MGCP 1.0
C:111
M:nas/data
L:b:64, nas/bt:v.120, nas/cdn:234567

May 2008 DB-307
Debug Commands
debug cdapi
X:101
May 14 19:12:25.327:CDAPI:cdapi_create_msg():CDAPI Pool Count:959, Raw Length = 0

May 14 19:12:25.327:CDAPI Se7/1:23:cdapi_add_entry_callRoutingTbl() -
May 14 19:12:25.327: Added entry for call 0x7017 for application CSM
May 14 19:12:25.331:CDAPI:cdapi_create_msg():CDAPI Pool Count:958,
router# Raw Length = 0
May 14 19:12:25.331:CDAPI:cdapi_free_msg():Raw Length = 0, freeRaw = 1, Raw Msg = 0x0
May 14 19:12:25.331:CDAPI:cdapi_free_msg():CDAPI Pool Count:959
May 14 19:12:25.331:CDAPI:cdapi_free_msg():Raw Length = 0, freeRaw = 1, Raw Msg = 0x0
May 14 19:12:25.331:CDAPI:cdapi_free_msg():CDAPI Pool Count:960
May 14 19:12:25.331:send_mgcp_msg, MGCP Packet sent to 10.0.44.109:2427 --->
.
.
.
The following MGCP packet received example shows V.120 call debugging output for the debug cdapi
events command:
Router# debug cdapi events

CRCX 6322 s7/ds1-0/24 MGCP 1.0
C:111
M:nas/data
L:b:64, nas/bt:v.120, nas/cdn:234567
X:101
Sep 26 19:14:39.027:Se7/0:23 CDAPI:TX -> CDAPI_MSG_CONNECT_IND to CSM call = 0x7017

Sep 26 19:14:39.027: From Appl/Stack = XCSP
Sep 26 19:14:39.027: Call Type = V.120
Sep 26 19:14:39.027: B Channel = 23
Sep 26 19:14:39.027: dslId = 0
Sep 26 19:14:39.027: Idb = 0
Sep
router#26 19:14:39.027: BChanIdb = 64519A14
Sep 26 19:14:39.027: Handle = 63CB8DF4
Sep 26 19:14:39.027: RPA = 6388506C
Sep 26 19:14:39.027: Cause = 0
Sep 26 19:14:39.027: ApplCause = 0
Sep 26 19:14:39.027: ApplSpecData = 0
Sep 26 19:14:39.027: Calling Party Number =
Sep 26 19:14:39.027: Called Party Number = 234567
Sep 26 19:14:39.027: Overlap = 0
Sep 26 19:14:39.027:Se7/0:23 CDAPI:TX -> CDAPI_MSG_CONNECT_RESP to XCSP call = 0x7017
Sep 26 19:14:39.027: From Appl
router#/Stack = CSM
Sep 26 19:14:39.027: Call Type = MODEM
Sep 26 19:14:39.027: B Channel = 23
Sep 26 19:14:39.027: dslId = 0
Sep 26 19:14:39.027: Idb = 0
Sep 26 19:14:39.027: BChanIdb = 64519A14
Sep 26 19:14:39.027: Handle = 63CB8DF4
Sep 26 19:14:39.027: RPA = 0
Sep 26 19:14:39.027: Cause = 0
Sep 26 19:14:39.027: ApplCause = 0
Sep 26 19:14:39.027: Overlap = 0
Sep 26 19:14:39.031:send_mgcp_msg, MGCP Pa
router#cket sent to 10.0.44.109:2427 --->
Sep 26 19:14:39.031:200 6322 Alert

I:64524608

DB-308 May 2008
Debug Commands
debug cdapi
Sep 26 19:14:39.039:Se7/0:23 CDAPI:TX -> CDAPI_MSG_CONN_ACT_REQ to XCSP call = 0x7017

Sep 26 19:14:39.039: From Appl/Stack = CSM
Sep 26 19:14:39.039: B Channel = 23
Sep 26 19:14:39.039: dslId = 0
Sep 26 19:14:39.039: Idb = 0
Sep 26 19:14:39.039: BChanIdb = 64519A14
Sep 26 19:14:39.039: Handle = 63CB8DF4
Sep 26 19:14:39.039: R
router#PA = 0
Sep 26 19:14:39.039: Cause = 0
Sep 26 19:14:39.039: ApplCause = 0
Sep 26 19:14:39.039: Overlap = 0
router#
DLCX 6323 s7/ds1-0/24 MGCP 1.0
Sep 26 19:14:48.963:Se7/0:23 CDAPI:TX -> CDAPI_MSG_DISCONNECT_IND to CSM call = 0x7017

Sep 26 19:14:48.963: Call Type = V.120
Sep 26 19:14:48.963: B Channel = 23
Sep 26 19:14:48.963: dslId = 0
Sep 26 19:14:48.963: Idb = 0
Sep 26 19:14:48.963: BChanIdb = 64519A14
Sep 26 19:14:48.963: Handle = 63CB8DF4
Sep 26 19:14
router#:48.963: RPA = 6388506C
Sep 26 19:14:48.963: Cause = 0
Sep 26 19:14:48.963: ApplCause = 0
Sep 26 19:14:48.963: Overlap = 0
Sep 26 19:14:48.963:Se7/0:23 CDAPI:TX -> CDAPI_MSG_SUBTYPE_RELEASE_REQ to XCSP call =
0x7017
Sep 26 19:14:48.963: From Appl/Stack = CSM
Sep 26 19:14:48.963: B Channel = 23
Sep 26 19:14:48.963: dslId = 0
Sep 26 19:14:48.963: Idb = 0
Sep 26 19:14:48
router#.963: BChanIdb = 64519A14
Sep 26 19:14:48.963: Handle = 63CB8DF4
Sep 26 19:14:48.963: RPA = 0
Sep 26 19:14:48.963: Cause = 0
Sep 26 19:14:48.963: ApplCause = 1
Sep 26 19:14:48.963: Overlap = 0
Sep 26 19:14:48.963:Se7/0:23 CDAPI:TX -> CDAPI_MSG_SUBTYPE_REL_COMP_IND to CSM call =
0x7017
Sep 26 19:14:48.963: Call Type = V.120
Sep 26 19:14:48.963: B Channel = 23
Sep 26 19:
router#14:48.963: dslId = 0
Sep 26 19:14:48.963: Idb = 0
Sep 26 19:14:48.963: BChanIdb = 64519A14
Sep 26 19:14:48.963: Handle = 63CB8DF4
Sep 26 19:14:48.963: RPA = 6388506C
Sep 26 19:14:48.963: Cause = 0
Sep 26 19:14:48.963: ApplCause = 0
Sep 26 19:14:48.963: Overlap = 0

May 2008 DB-309
Debug Commands
debug cdapi
Sep 26 19:14:48.963:send_mgcp_msg, MGCP Packet sent to 10.0.44.109:2427 --->
Sep 26 19:14:48.963:200 6323 OK
Table 53 debug cdapi Field Descriptions
Field Description
L:b:64, nas/bt The bearer type parameter includes v.110 and v.120 for V.110 and V.120
calls.
Call Type Call types are V.110, V.120, and modem.

debug mgcp packet Displays the MGCP signaling message received and sent to the called
agent.
debug voip rawmsg Displays the raw message owner, length, and pointer.

DB-310 May 2008
Debug Commands
debug cdma pdsn a10 ahdlc
debug cdma pdsn a10 ahdlc

To display debug messages for Asynchronous High-Level Data Link Control (AHDLC), use the debug
cdma pdsn a10 ahdlc command in privileged EXEC mode. To disable debugging output, use the no
debug cdma pdsn a10 ahdlc [errors | events ]
no debug cdma pdsn a10 ahdlc [errors | events ]
Syntax Description errors (Optional) Displays details of AHDLC packets in error.

events (Optional) Displays AHDLC events.
Defaults If the command is entered without any optional keywords, all of the types of debug information are
enabled.

12.2(8)BY Keywords were made optional.
Examples The following is sample output from the debug cdma pdsn a10 ahdlc command:
Router# debug cdma pdsn a10 ahdlc errors
ahdlc error packet display debugging is on

Router# debug cdma pdsn a10 ahdlc events
ahdlc events display debugging is on
Router#
*Jan 1 00:18:30:%LINK-3-UPDOWN:Interface Virtual-Access1, changed state to up
*Jan 1 00:18:30:*****OPEN AHDLC*****
*Jan 1 00:18:30: ahdlc_mgr_channel_create
*Jan 1 00:18:30: ahdlc_mgr_allocate_available_channel:
*Jan 1 00:18:30:ahdlc:tell h/w open channel 9 from engine 0

May 2008 DB-311
Debug Commands
debug cdma pdsn a10 gre

To display debug messages for A10 Generic Routing Encapsulation (GRE) interface errors, events, and
packets, use the debug cdma pdsn a10 gre command in privileged EXEC mode. To disable debugging
debug cdma pdsn a10 gre [errors | events | packets] [tunnel-key key]
no debug cdma pdsn a10 gre [errors | events | packets]
Syntax Description errors (Optional) Displays A10 GRE errors.

events (Optional) Displays A10 GRE events.
packets (Optional) Displays transmitted or received A10 GRE packets.
tunnel-key key (Optional) Specifies the GRE key.
enabled.

12.1(3)XS This command was introduced.
12.2(8)BY The tunnel-key keyword was added and the existing keywords were made
optional.
Examples The following is sample output from the debug cdma pdsn a10 gre events tunnel-key command:
Router# debug cdma pdsn a10 gre events tunnel-key 1
Router# show debug
CDMA:
CDMA PDSN A10 GRE events debugging is on for tunnel key 1
PDSN#
*Mar 1 04:00:57.847:CDMA-GRE:CDMA-Ix1 (GRE/CDMA) created with src 5.0.0.2 dst 0.0.0.0
*Mar 1 04:00:57.847:CDMA-GRE:(in) found session 5.0.0.2-4.0.0.1-1

DB-312 May 2008
Debug Commands


May 2008 DB-313
Debug Commands
debug cdma pdsn a10 ppp

To display debug messages for A10 Point-to-Point protocol (PPP) interface errors, events, and packets,
use the debug cdma pdsn a10 ppp command in privileged EXEC mode. To disable debugging output,
use the no form of this command.
debug cdma pdsn a10 ppp [errors | events | packets]
no debug cdma pdsn a10 ppp [errors | events | packets]
Syntax Description errors (Optional) Displays A10 PPP errors.

events (Optional) Displays A10 PPP events.
packets (Optional) Displays transmitted or received A10 PPP packets.
enabled.

Examples The following is sample output from the debug cdma pdsn a10 ppp command:
Router# debug cdma pdsn a10 ppp errors
CDMA PDSN A10 errors debugging is on
Router# debug cdma pdsn a10 ppp events

CDMA PDSN A10 events debugging is on
Router# debug cdma pdsn a10 ppp packets

CDMA PDSN A10 packet debugging is on
Router# show debug

*Jan 1 00:13:09:CDMA-PPP:create_va tunnel=CDMA-Ix1 virtual-template
template=Virtual-Template2 ip_enabled=1
*Jan 1 00:13:09:CDMA-PPP:create_va va=Virtual-Access1
*Jan 1 00:13:09:CDMA-PPP:clone va=Virtual-Access1 subif_state=1 hwidb->state=0
*Jan 1 00:13:09: linestate=1 ppp_lineup=0
*Jan 1 00:13:09:CDMA-PPP:clone va=Virtual-Access1 subif_state=1 hwidb->state=4

DB-314 May 2008
Debug Commands
*Jan 1 00:13:09: linestate=0 ppp_lineup=0

*Jan 1 00:13:09:*****OPEN AHDLC*****

May 2008 DB-315
Debug Commands
debug cdma pdsn a11
debug cdma pdsn a11

To display debug messages for A11 interface errors, events, and packets, use the debug cdma pdsn a11
debug cdma pdsn a11 [errors | events | packets ] [mnid]
no debug cdma pdsn a11 [errors | events | packets ]
Syntax Description errors (Optional) Displays A11 protocol errors.

events (Optional) Displays A11 events.
packets (Optional) Displays transmitted or received packets.
mnid (Optional) Specifies the ID of the mobile station.
enabled.

12.2(8)BY The mnid argument was added and the existing keywords were made
optional.
Examples The following is sample output from the debug cdma pdsn a11 commands:
Router# debug cdma pdsn a11 errors
CDMA PDSN A11 errors debugging is on
Router# show debug
1d21h:CDMA-RP:(in) rp_msgs, code=1, status=0

1d21h:CDMA-RP:(enqueue req) type=1 homeagent=5.0.0.2 coaddr=4.0.0.1
1d21h: id=0xBEF750F0-0xBA53E0F lifetime=65535
1d21h:CDMA-RP:len=8, 00-00-00-00-00-00-00-F1 convert to 00000000000001
(14 digits), type=IMSI
1d21h:CDMA-RP:(req) process_rp_req, homeagent=5.0.0.2 coaddr=4.0.0.1
1d21h: lifetime=65535 id=BEF750F0-BA53E0F
imsi=00000000000001
1d21h:CDMA-RP:(req) rp_req_create, 5.0.0.2-4.0.0.1-1 imsi=00000000000001
1d21h:CDMA-RP:(out) rp_reply session=5.0.0.2-4.0.0.1-1, lifetime=65535

DB-316 May 2008
Debug Commands
debug cdma pdsn a11
1d21h:CDMA-RP:(out) setup_rp_out_msg, ha=5.0.0.2 coa=4.0.0.1 key=1

1d21h:%LINK-3-UPDOWN:Interface Virtual-Access2000, changed state to up
1d21h:CDMA-RP:ipmobile_visitor add/delete=1, mn=8.0.2.132, ha=7.0.0.2
1d21h:%LINEPROTO-5-UPDOWN:Line protocol on Interface Virtual-Access2000,
changed state to up
Router# debug cdma pdsn a11 packets events
Router# show debug
CDMA:
CDMA PDSN A11 packet debugging is on for mnid 000000000000001
CDMA PDSN A11 events debugging is on for mnid 000000000000001
Router#
*Mar 1 03:15:32.507:CDMA-RP:len=8, 01-00-00-00-00-00-00-10 convert to 000000000000001 (15
digits), type=IMSI
*Mar 1 03:15:32.511:CDMA-RP:extension type=38, len=0
*Mar 1 03:15:32.511: 00 00 01 00 EE 1F FC 43 0A 7D F9 36 29 C2 BA 28
*Mar 1 03:15:32.511: 5A 64 D5 9C
*Mar 1 03:15:32.511:CDMA-RP:(req) process_rp_req, homeagent=5.0.0.2 coaddr=4.0.0.1
*Mar 1 03:15:32.511: lifetime=1800 id=AF3BFE55-69A109D IMSI=000000000000001
*Mar 1 03:15:32.511:CDMA-RP:(req) rp_req_create, ha=5.0.0.2, coa=4.0.0.1, key=1
IMSI=000000000000001
*Mar 1 03:15:32.511:CDMA-RP:(out) rp_reply session=5.0.0.2-4.0.0.1-1, lifetime=1800
*Mar 1 03:15:32.511:CDMA-RP:(out) Setup RP out message, ha=5.0.0.2 coa=4.0.0.1 key=1
*Mar 1 03:15:38.555:CDMA-RP:simple ip visitor added, mn=9.2.0.1, ha=0.0.0.0
Router#
digits), type=IMSI
*Mar 1 03:15:54.755: 00 00 01 00 EA 9C C6 4C BA B9 F9 B6 DD C4 19 76
*Mar 1 03:15:54.755: 51 5A 56 45
*Mar 1 03:15:54.755: lifetime=0 id=AF3BFE6B-4616E475 IMSI=000000000000001
*Mar 1 03:15:54.755:CDMA-RP:(req) rp_req_lifetime_zero 5.0.0.2-4.0.0.1-1
*Mar 1 03:15:54.755: IMSI=000000000000001
Router# debug cdma pdsn a11 event mnid 000000000000001
Router# show debug
CDMA:
CDMA PDSN A11 events debugging is on for mnid 000000000000001
Router#
digits), type=IMSI
*Mar 1 03:09:34.339: lifetime=1800 id=AF3BFCEE-DC9FC751
IMSI=000000000000001
*Mar 1 03:09:34.339:CDMA-RP:(req) rp_req_create, ha=5.0.0.2, coa=4.0.0.1, key=1
IMSI=000000000000001
*Mar 1 03:09:40.379:CDMA-RP:simple ip visitor added, mn=9.2.0.1, ha=0.0.0.0

May 2008 DB-317
Debug Commands
debug cdma pdsn a11
Router#
close the session

Router#
digits), type=IMSI
*Mar 1 03:10:00.575: lifetime=0 id=AF3BFD09-18040319 IMSI=000000000000001
*Mar 1 03:10:00.575:CDMA-RP:(req) rp_req_lifetime_zero 5.0.0.2-4.0.0.1-1
*Mar 1 03:10:00.575: IMSI=000000000000001
Router# debug cdma pdsn a11 packet mnid 000000000000001
Router# show debug
CDMA:
CDMA PDSN A11 packet debugging is on for mnid 000000000000001
Router#
*Mar 1 03:13:37.803: 00 00 01 00 A8 5B 30 0D 4E 2B 83 FE 18 C6 9D C2
*Mar 1 03:13:37.803: 15 BF 5B 57

*Mar 1 03:13:51.575: 00 00 01 00 58 77 E5 59 67 B5 62 15 17 52 83 6D
*Mar 1 03:13:51.579: DC 0A B0 5B

DB-318 May 2008
Debug Commands
debug cdma pdsn accounting flow

To display debug messages for accounting flow, use the debug cdma pdsn accounting flow command
no debug cdma pdsn accounting flow

Examples The following is sample output from the debug cdma pdsn accounting flow command:
Router# debug cdma pdsn accounting flow
CDMA PDSN flow based accounting debugging is on

pdsn-6500#
01:59:40:CDMA-SM:cdma_pdsn_flow_acct_upstream sess id 1 flow type 0 bytes 100 addr
20.20.20.1
01:59:40:CDMA-SM:cdma_pdsn_flow_acct_downstream sess id 1 flow type 0 bytes 100 addr
20.20.20.1

May 2008 DB-319
Debug Commands
debug cdma pdsn accounting time-of-day

To display the timer value, use the debug cdma pdsn accounting time-of-day command in privileged
no debug cdma pdsn accounting time-of-day

Examples The following is sample output from the debug cdma pdsn accounting time-of-day command:
Router# debug cdma pdsn accounting time-of-day
CDMA PDSN accounting time-of-day debugging is on
Feb 15 19:13:23.634:CDMA-TOD:Current timer expiring in 22 seconds

Feb 15 19:13:24.194:%SYS-5-CONFIG_I:Configured from console by console
Router#
Feb 15 19:13:45.635:CDMA-TOD:Timer expired...Rearming timer
Feb 15 19:13:45.635:CDMA-TOD:Gathering session info
Feb 15 19:13:45.635:CDMA-TOD:Found 0 sessions

DB-320 May 2008
Debug Commands
debug cdma pdsn accounting

To display debug messages for accounting events, use the debug cdma pdsn accounting command in
no cdma pdsn accounting

Examples The following is sample output from the debug cdma pdsn accounting command:
Router# debug cdma pdsn accounting
CDMA PDSN accounting debugging is on

Router#
*Jan 1 00:15:32:CDMA/ACCT:null vaccess in session_start
*Jan 1 00:15:32:CDMA/ACCT: Current Attribute type:0x[1A] len:[9]
*Jan 1 00:15:32:CDMA/ACCT: VSA Vid:5535 type:[44] len:[3] 01 Processing Y1
*Jan 1 00:15:32:CDMA/ACCT: Setup airlink record received
*Jan 1 00:15:32:CDMA/ACCT: VSA Vid:5535 type:[41] len:[6] 00 00 00 02 CDMA/ACCT:
Processing Y2
*Jan 1 00:15:32:CDMA/ACCT: VSA Vid:5535 type:[42] len:[3] 12 CDMA/ACCT: Processing Y3
*Jan 1 00:15:32:CDMA/ACCT: Current Attribute type:0x[1F] len:[17] 30 30 30 30 30 30 30 30
30 30 30 30 30 30 32 Processing A1
*Jan 1 00:15:32:CDMA/ACCT: VSA Vid:5535 type:[9] len:[6] 04 04 04 05 Processing D3
*Jan 1 00:15:32:CDMA/ACCT: VSA Vid:5535 type:[10] len:[8] 00 00 04 04 04 05
Processing D4
*Jan 1 00:15:32:CDMA/ACCT: VSA Vid:5535 type:[44] len:[3] 02 Processing Y1
*Jan 1 00:15:32:CDMA/ACCT: Start airlink record received

May 2008 DB-321
Debug Commands
*Jan 1 00:15:32:CDMA/ACCT: VSA Vid:5535 type:[41] len:[6] 00 00 00 02 CDMA/ACCT:

Processing Y2
*Jan 1 00:15:32:CDMA/ACCT: VSA Vid:5535 type:[42] len:[3] 13 CDMA/ACCT: Processing Y3
*Jan 1 00:15:32:CDMA/ACCT: VSA Vid:5535 type:[11] len:[4] 00 02 Processing E1
*Jan 1 00:15:32:CDMA/ACCT: VSA Vid:5535 type:[12] len:[4] 00 F1 Processing F1

DB-322 May 2008
Debug Commands
debug cdma pdsn cluster
debug cdma pdsn cluster

To display the error messages, event messages, and packets received, use the debug cdma pdsn cluster
debug cdma pdsn cluster {message [error | events | packets] redundancy [error | events |
packets ]}
no debug cdma pdsn cluster {message [error | events | packets] redundancy [error | events |
packets ]}
Syntax Description message Displays cluster messages for errors, events and packets received.
redundancy Displays redundancy information for errors, events, and sent or received
packets.
error Displays either cluster or redundancy error messages.
events Displays either all cluster or all redundancy events.
packets Displays all transmitted or received cluster or redundancy packets.

Usage Guidelines This debug is only allowed on PDSN c6-mz images, and helps to monitor prepaid information.
Examples The following is sample output from the debug cdma pdsn cluster command:
Router# debug cdma pdsn cluster ?
message Debug PDSN cluster controller messages

redundancy Debug PDSN cluster controller redundancy

May 2008 DB-323
Debug Commands
debug cdma pdsn ipv6

To display IPV6 error or event messages, use the debug cdma pdsn IPV6 command in privileged EXEC
mode. To disable debug messages, use the no form of this command.
no debug cdma pdsn ipv6
Syntax Description There are no arguments or keywords for this command.

12.3(14)YX This command was introduced.
Usage Guidelines The following example illustrates the debug cdma pdsn ipv6 command:
Router# debug cdma pdsn ipv6

DB-324 May 2008
Debug Commands
debug cdma pdsn prepaid

To display debug messages about prepaid flow, use the debug cdma pdsn prepaid command in
no debug cdma pdsn prepaid

12.2(8)BY This command was introduced.
Usage Guidelines This debug is only allowed on PDSN c6-mz images, and helps to monitor prepaid information.
Examples The following is sample output from the debug cdma pdsn prepaid command:
Router# debug cdma pdsn prepaid
*Mar 1 00:09:38.391: CDMA-PREPAID: Initialized the authorization request

*Mar 1 00:09:38.391: CDMA-PREPAID: Added username into A-V list
*Mar 1 00:09:38.391: CDMA-PREPAID: Added CLID into A-V list
*Mar 1 00:09:38.391: CDMA-PREPAID: Added session id for prepaid
*Mar 1 00:09:38.391: CDMA-PREPAID: Added correlation id into A-V list
*Mar 1 00:09:38.391: CDMA-PREPAID: Added auth reason for prepaid into A-V list
*Mar 1 00:09:38.391: CDMA-PREPAID: Added USER_ID for prepaid
*Mar 1 00:09:38.391: CDMA-PREPAID: Added service id for prepaid
*Mar 1 00:09:38.391: CDMA-PREPAID: Built prepaid VSAs
*Mar 1 00:09:38.391: CDMA-PREPAID: Sent the request to AAA
*Mar 1 00:09:38.391: CDMA-PREPAID: Auth_reason: CRB_RSP_PEND_INITIAL_QUOTA
*Mar 1 00:09:38.395: CDMA-PREPAID: Received prepaid response: status 2
*Mar 1 00:09:38.395: CDMA-PREPAID: AAA authorised parms being processed
*Mar 1 00:09:38.395: CDMA-PREPAID: Attr in Grp Prof: crb-entity-type
*Mar 1 00:09:38.395: (0x4B000000) CDMA/PREPAID: AAA_AT_CRB_ENTITY_TYPE
*Mar 1 00:09:38.395: (0x4B000000) CDMA/PREPAID: entity type returns 1
*Mar 1 00:09:38.395: CDMA-PREPAID: Attr in Grp Prof: crb-duration
*Mar 1 00:09:38.395: (0x4B000000) CDMA/PREPAID: AAA_AT_CRB_DURATION
*Mar 1 00:09:38.395: (0x4B000000) CDMA/PREPAID: duration returns 120

May 2008 DB-325
Debug Commands
*Mar 1 00:09:38.395: CDMA-PREPAID: Retrieved attributes successfully

*Mar 1 00:09:38.395: CDMA-PREPAID: Reset duration to 120, mn 9.3.0.1
*Mar 1 00:09:38.395: CDMA-PREPAID: : Started duration timer for 120 sec

DB-326 May 2008
Debug Commands
debug cdma pdsn qos
debug cdma pdsn qos

To display debug messages about quality of service features, use the debug cdma pdsn qos command
in privileged EXEC mode. To disable debug messages, use the no form of this command.
debug cdma pdsn qos
no debug cdma pdsn qos
Syntax Description There are no arguments or keywords for this command.
Defaults There are no default values for this command.

12.3(8)XW This command was introduced.
Examples There are currently no sample outputs for this command.

May 2008 DB-327
Debug Commands
debug cdma pdsn resource-manager
debug cdma pdsn resource-manager

To display debug messages that help you monitor the resource-manager information, use the debug
cdma pdsn resource-manager command in privileged EXEC mode. To disable debugging output, use
debug cdma pdsn resource-manager [error | events]
no debug cdma pdsn resource-manager [error | events]
Syntax Description errors Displays Packet Data Service node (PDSN) resource manager errors.
events Displays PDSN resource manager events.

12.2(8)BY This command was introduced.
Examples The following is sample output from the debug cdma pds resource-manager command:
Router# debug cdma pdsn resource-manager
errors CDMA PDSN resource manager errors

events CDMA PDSN resource manager events

DB-328 May 2008
Debug Commands
debug cdma pdsn selection

To display debug messages for the intelligent Packet Data Serving Node (PDSN) selection feature, use
the debug cdma pdsn selection command in privileged EXEC mode. To disable debugging output, use
debug cdma pdsn selection {errors | events | packets}
no debug cdma pdsn selection {errors | events | packets}
Syntax Description errors Displays PDSN selection errors.

events Displays PDSN selection events.
packets Displays transmitted or received packets.

Examples The following is sample output from the debug cdma pdsn selection command with the keyword events
specified:
Router# debug cdma pdsn selection events
CDMA PDSN selection events debugging is on

Router#
00:27:46: CDMA-PSL: Message(IN) pdsn 51.4.2.40 interface 70.4.2.40
00:27:46: Keepalive 10
00:27:46: Count 0
00:27:46: Capacity 16000
00:27:46: Weight 0
00:27:46: Hostname 11 7206-PDSN-2
00:27:46: CDMA-PSL: Reset keepalive, pdsn 51.4.2.40 current 10 new 10
00:27:46: CDMA-PSL: Message processed, pdsn 51.4.2.40 tsize 0 pendings 0
00:27:47: CDMA-PSL: Send KEEPALIVE, len 32
00:27:47: CDMA-PSL: Message(OUT) dest 224.0.0.11
00:27:47: Keepalive 10
00:27:47: Count 1
00:27:47: Capacity 16000
00:27:47: Weight 0

May 2008 DB-329
Debug Commands
00:27:47: Hostname 11 7206-PDSN-1

00:27:47: CDMA-PSL: RRQ sent, s=70.4.1.40 (FastEthernet0/1), d=224.0.0.11

DB-330 May 2008
Debug Commands
debug cdma pdsn service-selection

To display debug messages for service selection, use the debug cdma pdsn service-selection command
no debug cdma pdsn service-selection

Examples The following is sample output from the debug cdma pdsn service-selection command:
Router# debug cdma pdsn service-selection
CDMA PDSN service provisioning debugging is on

Router#
1d02h:%LINK-3-UPDOWN:Interface Virtual-Access3, changed state to up
1d02h:Vi3 CDMA-SP:user_class=1, ms_ipaddr_req=1, apply_acl=0
1d02h:Vi3 CDMA-SP:Adding simple ip flow, user=bsip, mn=6.0.0.2,
1d02h:%LINEPROTO-5-UPDOWN:Line protocol on Interface Virtual-Access3,
changed state to up

May 2008 DB-331
Debug Commands
debug cdma pdsn session
debug cdma pdsn session

To display debug messages for Session Manager errors, events, and packets, use the debug cdma pdsn
session command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug cdma pdsn session [errors | events ]
no debug cdma pdsn session [errors | events ]
Syntax Description errors (Optional) Displays session protocol errors.

events (Optional) Displays session events.
enabled.

Examples The following is sample output from the debug cdma pdsn session command:
Router# debug cdma pdsn session events
CDMA PDSN session events debugging is on
Router# debug cdma pdsn session errors

CDMA PDSN session errors debugging is on
Router# show debug

CDMA:
CDMA PDSN session events debugging is on
CDMA PDSN session errors debugging is on
Router#
*Jan 1 00:22:27:CDMA-SM:create_session 5.5.5.5-4.4.4.5-2
*Jan 1 00:22:27:CDMA-SM:create_tunnel 5.5.5.5-4.4.4.5
*Jan 1 00:22:29:CDMA-SM:create_flow mn=0.0.0.0, ha=8.8.8.8 nai=l2tp2@cisco.com
*Jan 1 00:22:30:%LINEPROTO-5-UPDOWN:Line protocol on Interface Virtual-Access1, changed
state to up

DB-332 May 2008
Debug Commands
debug cdp ip
debug cdp ip
To enable debug output for the IP routing information that is carried and processed by the
Cisco Discovery Protocol (CDP), use the debug cdp ip command in privileged EXEC mode. To disable
debug cdp ip
no debug cdp ip
Usage Guidelines CDP is a media- and protocol-independent device-discovery protocol that runs on all Cisco routers.
You can use the debug cdp ip command to determine the IP network prefixes CDP is advertising and
whether CDP is correctly receiving this information from neighboring routers.
Use the debug cdp ip command with the debug ip routing command to debug problems that occur when
on-demand routing (ODR) routes are not installed in the routing table at a hub router. You can also use
the debug cdp ip command with the debug cdp packet and debug cdp adjacency commands along with
encapsulation-specific debug commands to debug problems that occur in the receipt of CDP IP
information.
Examples The following is sample output from the debug cdp ip command. This example shows the transmission
of IP-specific information in a CDP update. In this case, three network prefixes are being sent, each with
a different network mask.
Router# debug cdp ip
CDP-IP: Writing prefix 172.1.69.232.112/28

CDP-IP: Writing prefix 172.19.89.0/24
CDP-IP: Writing prefix 11.0.0.0/8
In addition to these messages, you might see the following messages:

This message indicates that CDP is attempting to install the prefix 172.16.1.0/24 into the IP routing
table:
CDP-IP: Updating prefix 172.16.1.0/24 in routing table
This message indicates a protocol error occurred during an attempt to decode an incoming CDP
packet:
CDP-IP: IP TLV length (3) invalid
This message indicates the receipt of the IP prefix 172.16.1.0/24 from a CDP neighbor connected
via Ethernet interface 0/0. The neighbor IP address is 10.0.01.
CDP-IP: Reading prefix 172.16.1.0/24 source 10.0.0.1 via Ethernet0/0

May 2008 DB-333
Debug Commands
debug cdp ip

debug ip routing Displays information on RIP routing table updates and route
cache updates.

DB-334 May 2008
Debug Commands
debug cdp
debug cdp
To enable debugging of the Cisco Discovery Protocol (CDP), use the debug cdp command in privileged
debug cdp {packets | adjacency | events}
no debug cdp {packets | adjacency | events}
Syntax Description packets Enables packet-related debugging output.

adjacency Enables adjacency-related debugging output.
events Enables output related to error messages, such as detecting a bad
checksum.
Usage Guidelines Use debug cdp commands to display information about CDP packet activity, activity between CDP
neighbors, and various CDP events.
Examples The following is sample output from debug cdp packets, debug cdp adjacency, and debug cdp events
commands:
Router# debug cdp packets
CDP packet info debugging is on
Router# debug cdp adjacency
CDP neighbor info debugging is on
Router# debug cdp events
CDP events debugging is on
CDP-PA: Packet sent out on Ethernet0

CDP-PA: Packet received from gray.cisco.com on interface Ethernet0
CDP-AD: Deleted table entry for violet.cisco.com, interface Ethernet0

CDP-AD: Interface Ethernet2 coming up
CDP-EV: Encapsulation on interface Serial2 failed

May 2008 DB-335
Debug Commands
debug cef
debug cef
To enable the display of information about Cisco Express Forwarding events, use the debug cef
command in privileged EXEC mode. To disable the display of Cisco Express Forwarding events, use the
debug cef {all | assert | background | broker | consistency-check | elog | epoch | fib [attached
export | subblock] | hardware {notification | queries} | hash | high-availability | interest |
interface | iprm | issu | loadinfo | memory | non-ip | path [extension | list | scope ]] | subtree
context | switching background | table | xdr}
no debug cef {all | assert | background | broker | consistency-check | elog | epoch | fib [attached
export | subblock] | hardware {notification | queries} | hash | high-availability | interest |
interface | iprm | issu | loadinfo | memory | non-ip | path [extension | list | scope ]] | subtree
context | switching background | table | xdr}
Syntax Description all Displays debug messages for all Cisco Express Forwarding
events.
assert Displays debug messages for Cisco Express Forwarding assert
events.
background Displays debug messages for Cisco Express Forwarding
background events.
broker Displays debug messages for Cisco Express Forwarding broker
events.
consistency-check Displays debug messages for Cisco Express Forwarding
consistency checker events.
elog Displays debug messages for Cisco Express Forwarding elog
events.
epoch Displays debug messages for Cisco Express Forwarding epoch
events.
fib [attached export | subblock] Displays debug messages for Cisco Express Forwarding
Forwarding Information Base entry events.
hardware {notification | queries} Displays debug messages for Cisco Express Forwarding
hardware API notifications or hardware API queries.
hash Displays debug messages for Cisco Express Forwarding
load-balancing hash algorithms.
high-availability Displays debug messages for Cisco Express Forwarding high
availability events.
interest Displays debug messages for Cisco Express Forwarding interest
list events.
interface Displays debug messages for Cisco Express Forwarding
interface events.
iprm Displays debug messages for Cisco Express Forwarding IP
rewrite manager events. (This keyword is not available in
Cisco IOS Release 12.2(33)SRA.)
issu Displays debug messages for Cisco Express Forwarding
In Service Software Upgrade (ISSU) events.

DB-336 May 2008
Debug Commands
debug cef
loadinfo Displays debug messages for Cisco Express Forwarding loadinfo

events.
memory Displays debug messages for Cisco Express Forwarding memory
events.
non-ip Displays debug messages for Cisco Express Forwarding non-IP
entry events.
path [extension | list | scope] Displays debug messages for Cisco Express Forwarding path
events.
subtree context Displays debug messages for Cisco Express Forwarding subtree
context events.
switching background Displays debug messages for Cisco Express Forwarding
switching background events.
table Displays debug messages for Cisco Express Forwarding table
events.
xdr Displays debug messages for Cisco Express Forwarding
External Data Representation (XDR) events.
Defaults Debugging information about Cisco Express Forwarding events is not displayed.

staff. Moreover, you should use debug commands during periods of lower network traffic and fewer
users. Debugging during these periods decreases the likelihood that increased debug command
processing overhead will affect system use.
Examples The following is sample output from the debug cef all command:
Router# debug cef all
06:23:38: HW-API: Counter poll: Label[label=implicit-null]


May 2008 DB-337
Debug Commands
debug cef

06:23:43: FIBbg: Timer 'FIB checkers: IPv4 scan-rib-ios scanner' expired, callin
g 0x40FA03FC, context 0x00010003)
06:23:43: FIBbg: Restarting timer 'FIB checkers: IPv4 scan-rib-ios scanner' with
delay 60000
06:23:43: FIBbg: Timer 'FIB checkers: IPv4 scan-ios-rib scanner' expired, callin
06:23:43: FIBbg: Restarting timer 'FIB checkers: IPv4 scan-ios-rib scanner' with
delay 60000
06:23:43: FIBbg: Timer 'FIB checkers: IPv6 scan-ios-rib scanner' expired, callin
06:23:43: FIBbg: Restarting timer 'FIB checkers: IPv6 scan-ios-rib scanner' with
delay 60000
06:23:43: FIBbg: Timer 'FIB checkers: IPv4 scan-rp-lc scanner' expired, calling
0x40FA03FC, context 0x00010002)
06:23:43: FIBbg: Restarting timer 'FIB checkers: IPv4 scan-rp-lc scanner' with d
elay 60000
06:23:43: FIBbg: Timer 'FIB checkers: IPv6 scan-rp-lc scanner' expired, calling
06:23:43: FIBbg: Restarting timer 'FIB checkers: IPv6 scan-rp-lc scanner' with d
elay 60000
06:24:06: FIBtable: IPv4: Event modified, 0.0.0.0/0, vrf Default, 1 path, flags
00420005
06:24:06: FIBpath: Configuring IPv4 path 444B2AB0 from rib (idb=NULL, gw=9.1.41.
1, gw_table=0, rr=1) and host prefix 0.0.0.0
06:24:06: FIBpath: Configured recursive-nexthop 9.1.41.1[0] 444B2AB0 path
06:24:06: FIBfib: [v4-0.0.0.0/0 (44AAC750)] Mod type - null
06:24:06: FIBtable: IPv4: Event up, default, 0.0.0.0/0, vrf Default, 1 path, fla
gs 00420005
06:24:06: FIBtable: IPv4: Adding route for 0.0.0.0/0 but route already exists. T
rying modify.
06:24:06: FIBpath: Configuring IPv4 path 444B2AA0 from rib (idb=NULL, gw=9.1.41.
1, gw_table=0, rr=1) and host prefix 0.0.0.0sh ip
06:24:06: FIBpath: Configured recursive-nexthop 9.1.41.1[0] 444B2AA0 path
06:24:06: FIBfib: [v4-0.0.0.0/0 (44AAC750)] Mod type - null vrf
06:24:07: FIBbg: Timer 'FIB checkers: IPv4 scan-hw-sw scanner' expired, calling
06:24:07: FIBbg: Restarting timer 'FIB checkers: IPv4 scan-hw-sw scanner' with d
elay 60000
06:24:07: FIBbg: Timer 'FIB checkers: IPv4 scan-sw-hw scanner' expired, calling
06:24:07: FIBbg: Restarting timer 'FIB checkers: IPv4 scan-sw-hw scanner' with d
elay 60000
Name Default RD Interfaces
red 1:1 Ethernet4/0/5

DB-338 May 2008
Debug Commands
debug cef

cef table consistency-check Enables Cisco Express Forwarding consistency checker table
values by type and parameter.
clear cef table Clears the Cisco Express Forwarding tables.
clear ip cef inconsistency Clears Cisco Express Forwarding inconsistency statistics and
records found by the Cisco Express Forwarding consistency
checkers.
debug ip cef table Enables the collection of events that affect entries in the
Cisco Express Forwarding tables.
show cef table consistency-check Displays Cisco Express Forwarding consistency checker table
values.
show ip cef inconsistency Displays Cisco Express Forwarding IP prefix inconsistencies.

May 2008 DB-339
Debug Commands
debug cellular driver
debug cellular driver

To debug the Cisco IOS driver for the cellular interface, use the debug cellular driver command in
EXEC mode.
debug cellular slot/wic_slot/port driver {crcdump | errdump | errors}
Syntax Description slot/wic_slot/port Numeric values that indicate the router slot, WAN interface card (WIC) slot,
and port.
crcdump CRC error details.
errdump Other error details.
errors Errors debugging.
Command Default None
Command Modes EXEC

12.4(11)XV This command was introduced.
Usage Guidelines Use this command for debugging purposes only.

debug cellular messages async Debugs cellular async.
debug cellular messages data Prints Cisco IOS data path debug messages.
debug cellular firmware Displays Cisco IOS firmware information.
debug cellular messages Prints management path messages, such as CnS.
management
debug cellular messages dm Prints diagnostics monitor (DM) messages from the Qualcomm
CDMA chipset.
debug cellular messages Redirects the Nios II console driver messages to display them in the
virt-con Cisco IOS router console environment.

DB-340 May 2008
Debug Commands
debug cellular firmware
debug cellular firmware

To see the Cisco IOS firmware information, use the debug cellular firmware command in EXEC mode.
debug cellular slot/wic_slot/port firmware
and port.
Command Modes EXEC


debug cellular driver Debugs the Cisco IOS driver.
management
CDMA chipset.

May 2008 DB-341
Debug Commands
debug cellular messages all
debug cellular messages all

To print all Cisco IOS driver debug messages, use the debug cellular messages all command in EXEC
mode.
debug cellular slot/wic_slot/port messages all
and port.
Command Modes EXEC


management
CDMA chipset.

DB-342 May 2008
Debug Commands
debug cellular messages async
debug cellular messages async

To debug cellular async, use the debug cellular messages async command in EXEC mode.
debug cellular slot/wic_slot/port messages async
and port.
Command Modes EXEC


debug cellular messages all Prints all Cisco IOS driver debug messages.
management
CDMA chipset.

May 2008 DB-343
Debug Commands
debug cellular messages data
debug cellular messages data

To print Cisco IOS data path debug messages, use the debug cellular messages data command in EXEC
mode.
show cellular slot/wic_slot/port messages data
and port.
Command Modes EXEC


management
CDMA chipset.

DB-344 May 2008
Debug Commands
debug cellular messages dm
debug cellular messages dm

To print Diagnostics Monitor (DM) messages from the Qualcomm CDMA chipset, use the debug
cellular messages dm command in EXEC mode.
debug cellular slot/wic_slot/port messages dm
and port.
Command Default There is no default for this command.
Command Modes EXEC


management

May 2008 DB-345
Debug Commands
debug cellular messages management
debug cellular messages management

To print management path messages, such as CnS, use the debug cellular messages management
command in EXEC mode.
debug cellular slot/wic_slot/port messages management
and port.
Command Modes EXEC



DB-346 May 2008
Debug Commands
debug cellular messages virt-con

To redirect the Nios II console driver messages to display them in the Cisco IOS router console
environment, use the debug cellular virt-con command in EXEC mode.
debug cellular slot/wic_slot/port virt-con {clear | disable | dump-data-structs | log | monitor |

wrapper-on | wrapper-off}
and port.
clear (Optional) Clears all virtual console debug log messages.
disable (Optional) Disables virtual console real-time debug monitoring.
dump-data-structurs (Optional) Dumps virtual console data structures.
log (Optional) Displays virtual console messages from the debug log.
monitor (Optional) Enables monitoring of real-time virtual console debug messages.
wrapper-on (Optional) Disables wraparound for virtual console log messages.
wrapper-off (Optional) Enables wraparound for virtual console log messages.
Command Default There is no default for this command.
Command Modes EXEC



May 2008 DB-347
Debug Commands
Command Description
management
CDMA chipset.

DB-348 May 2008
Debug Commands
debug cem ls errors
debug cem ls errors

To debug connection errors or null data structures, use the debug cem ls errors command in privileged
EXEC mode. To disable this form of debugging, use the no form of this command.
debug cem ls errors
no debug cem ls errors

12.2(33)SRC This command was introduced on the Cisco 7600 series routers.
Usage Guidelines Use the show debug command to see debug information.
Examples The following command turns on CEM local switching error debugging:
Router# debug cem ls errors

debug cem ls events Enables debugging of events relating to CEM
local switching.

May 2008 DB-349
Debug Commands
debug cem ls events
debug cem ls events

To debug CEM local switching events, use the debug cem ls events command in privileged EXEC mode.
To disable this form of debugging, use the no form of this command.
debug cem ls events
no debug cem ls events

12.2(33)SRC This command was introduced on the Cisco 7600 series routers.
Usage Guidelines Use the show debug command to see debug information.
Examples The following command turns on debugging for CEM local switching events.
Router# debug cem ls events

debug cem ls errors Enables debugging of connection errors or null
data structures.

DB-350 May 2008
Debug Commands
debug ces-conn
debug ces-conn
To display information from circuit emulation service (CES) clients, use the debug ces-conn command
debug ces-conn [all | errors | events]
no debug ces-conn
Syntax Description all (Optional) Displays all error and event information.
errors (Optional) Displays only error information.
events (Optional) Displays only event information.

12.1(5)XM This command is supported on Cisco 3600 series routers.
Examples The following example shows debug output for a CES connection:
Router# debug ces-conn all
CES all debugging is on

Router#
Router(config)# connect conn1 t1 3/0 1 atm1/0 1/100
Router(config-ces-conn)# exit
Router(config)#
*Mar 6 18:32:27:CES_CLIENT:vc QoS parameters are PCR = 590, CDV =
5000, CAS_ENABLED = 1,partial fill = 0, multiplier = 8,cbr rate = 64,
clock recovery = 0,service_type = 3, error method = 0,sdt_size = 196,
billing count = 0
*Mar 6 18:32:27:CES_CLIENT:attempt 1 to activate segment>

May 2008 DB-351
Debug Commands
debug channel events

To display processing events on Cisco 7000 series routers that occur on the channel adapter interfaces
of all installed adapters, use the debug channel events command in privileged EXEC mode. To disable
no debug channel events

Usage Guidelines This command displays CMCC adapter events that occur on the Channel Interface Processor (CIP) or
Channel Port Adapter (CPA) and is useful for diagnosing problems in an IBM channel attach network.
It provides an overall picture of the stability of the network. In a stable network, the debug channel
events command does not return any information. If the command generates numerous messages, the
messages can indicate the possible source of the problems. To observe the statistic message
(cip_love_letter) sent every 10 seconds, use the debug channel love command.
When configuring or making changes to a router or interface that supports IBM channel attach, enable
the debug channel events command. 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.
Examples The following sample output is from the debug channel events command:
Router# debug channel events
Channel3/0: cip_reset(), state administratively down

Channel3/0: cip_reset(), state up
Channel3/0: sending nodeid
Channel3/0: sending command for vc 0, CLAW path C700, device C0
The following line indicates that the CIP is being reset to an administrative down state:
Channel3/0: cip_reset(), state administratively down
The following line indicates that the CIP is being reset to an administrative up state:
Channel3/0: cip_reset(), state up

DB-352 May 2008
Debug Commands
The following line indicates that the node ID is being sent to the CIP. This information is the same as
the Local Node information under the show extended channel slot/port subchannels command. The
CIP needs to send this information to the host mainframe.
Channel3/0: sending nodeid
The following line indicates that a Common Link Access for Workstations (CLAW) subchannel
command is being sent from the Route Processor (RP) to the CIP. The value vc 0 indicates that the CIP
will use virtual circuit number 0 with this device. The virtual circuit number also shows up when you
use the debug channel packets command.
Channel3/0: sending command for vc 0, CLAW path C700, device C0
The following is a sample output that is generated by the debug channel events command when a
CMPC+ IP TG connection is activated with the host:
1d05h:Channel4/2:Received route UP for tg (768)
1d05h:Adding STATIC ROUTE for vc:768
The following is a sample output from the debug channel events command when a CMPC+ IP TG
connection is deactivated:
1d05h:Channel4/2:Received route DOWN for tg (768)
1d05h:Deleting STATIC ROUTE for vc:768

debug channel ilan Displays CIP love letter events.
debug channel packets Displays per-packet debugging output.

May 2008 DB-353
Debug Commands
debug channel ilan
debug channel ilan

To display messages relating to configuration and bridging using Cisco Mainframe Channel Connection
(CMCC) internal LANs and to help debug source-route bridging (SRB) problems related to CMCC
internal LANs, use the debug channel ilan command in privileged EXEC mode. To disable debugging
debug channel ilan
no debug channel ilan

Usage Guidelines The debug channel ilan command displays events related to CMCC internal LANs. This command is
useful for debugging problems associated with CMCC internal LAN configuration. It is also useful for
debugging problems related to SRB packet flows through internal LANs.
Examples The following is sample output from the debug channel ilan command:
Router# debug channel ilan
Channel internal LANs debugging is on
The following line indicates that a packet destined for the CMCC via a configured internal MAC adapter
configured on an internal LAN was dropped because the Logical Link Control (LLC) end station in
Cisco IOS software did not exist:
CIP ILAN(Channel3/2-Token): Packet dropped - NULL LLC
The following line indicates that a packet destined for the CMCC via a configured internal MAC adapter
configured on an internal LAN was dropped because the CMCC had not yet acknowledged the internal
MAC adapter configuration command:
Channel3/2: ILAN Token-Ring 3 - CIP internal MAC adapter not acknowledged
DMAC(4000.7000.0001) SMAC(0c00.8123.0023)

DB-354 May 2008
Debug Commands
debug channel ilan

debug channel events Displays processing that occurs on the channel adapter interfaces of all
installed adapters.
debug source bridge Displays information about packets and frames transferred across a
source-route bridge.

May 2008 DB-355
Debug Commands
debug channel love
debug channel love

To display Channel Interface Processor (CIP) love letter events, use the debug channel love command
debug channel love
no debug channel love
Usage Guidelines This command displays CIP love letter events (an operating status or configuration message) that occur
on the CIP interface processor and is useful for diagnosing problems in an IBM channel attach network.
It provides an overall picture of the stability of the network. In a stable network, the debug channel love
command returns a statistic message (cip_love_letter) that is sent every 10 seconds. This command is
valid for the Cisco 7000 series routers only.
Examples The following is sample output from the debug channel love command:
Router# debug channel love
Channel3/1: love letter received, bytes 3308

cip_love_letter: received ll, but no cip_info
The following line indicates that data was received on the CIP:
The following line indicates that the interface is enabled, but there is no configuration for it. It does not
normally indicate a problem, just that the Route Processor (RP) got statistics from the CIP but has no
place to store them.
cip_love_letter: received ll, but no cip_info

debug channel events Displays processing that occurs on the channel adapter interfaces of
all installed adapters.
debug channel packets Displays per-packet debugging output.

DB-356 May 2008
Debug Commands
debug channel packets

To display per-packet debugging output, use the debug channel packets command in privileged EXEC
no debug channel packets
Usage Guidelines The debug channel packets command displays all process-level Channel Interface Processor (CIP)
packets for both outbound and inbound packets. The output reports information when a packet is
received or a transmission is attempted. You will need to disable fast switching and autonomous
switching to obtain debugging output. This command is useful for determining whether packets are
received or sent correctly.
This command is valid for the Cisco 7000 series routers only.
Examples The following is sample output from the debug channel packets command:
Router# debug channel packets
(Channel3/0)-out size = 104, vc = 0000, type = 0800, src 172.24.0.11, dst 172.24.1.58
(Channel3/0)-in size = 48, vc = 0000, type = 0800, src 172.24.1.58, dst 172.24.15.197
(Channel3/0)-out size = 71, vc = 0000, type = 0800, src 172.24.15.197, dst 172.24.1.58
Table 54 debug channel packets Field Descriptions
Field Description
(Channel3/0) Interface slot and port.
in/out In is a packet from the mainframe to the router.
Out is a packet from the router to the mainframe.
size = Number of bytes in the packet, including internal overhead.
vc = Value from 0 to 511 that maps to the claw interface configuration command. This
information is from the MAC layer.
type = Encapsulation type in the MAC layer. The value 0800 indicates an IP datagram.
src Origin, or source, of the packet, as opposed to the previous hop address.
dst Destination of the packet, as opposed to the next-hop address.

May 2008 DB-357
Debug Commands
debug clns esis events

To display uncommon End System-to-Intermediate System (ES-IS) events, including previously
unknown neighbors, neighbors that have aged out, and neighbors that have changed roles (ES-IS, for
example), use the debug clns esis events command in privileged EXEC mode. To disable debugging
no debug clns esis events
Examples The following is sample output from the debug clns esis events command:
Router# debug clns esis events
ES-IS: ISH from aa00.0400.2c05 (Ethernet1), HT 30

ES-IS: ESH from aa00.0400.9105 (Ethernet1), HT 150
ES-IS: ISH sent to All ESs (Ethernet1): NET 49.0001.AA00.0400.6904.00, HT 299, HLEN 20
The following line indicates that the router received a hello packet (ISH) from the IS at MAC address
aa00.0400.2c05 on Ethernet interface 1. The hold time (or number of seconds to consider this packet
valid before deleting it) for this packet is 30 seconds.
ES-IS: ISH from aa00.0400.2c05 (Ethernet1), HT 30
The following line indicates that the router received a hello packet (ESH) from the ES at MAC address
aa00.0400.9105 on the Ethernet interface 1. The hold time is 150 seconds.
ES-IS: ESH from aa00.0400.9105 (Ethernet1), HT 150
The following line indicates that the router sent an IS hello packet on the Ethernet interface 0 to all ESs
on the network. The network entity title (NET) address of the router is 49.0001.0400.AA00.6904.00; the
hold time for this packet is 299 seconds; and the header length of this packet is 20 bytes.
ES-IS: ISH sent to All ESs (Ethernet1): NET 49.0001.AA00.0400.6904.00, HT 299, HLEN 20

DB-358 May 2008
Debug Commands
debug clns esis packets

To enable display information on End System-to-Intermediate System (ES-IS) packets that the router has
received and sent, use the debug clns esis packets command in privileged EXEC mode. To disable
no debug clns esis packets
Examples The following is sample output from the debug clns esis packets command:
Router# debug clns esis packets
ES-IS: ISH sent to All ESs (Ethernet0): NET

47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 33
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 34
ES-IS: ISH from aa00.0400.6408 (Ethernet0), HT 299
ES-IS: ISH sent to All ESs (Tunnel0): NET
47.0005.80ff.ef00.0000.0001.5940.1600.O906.4023.00, HT 299, HLEN 34
IS-IS: ESH from 0000.0c00.bda8 (Ethernet0), HT 300
The following line indicates that the router has sent an IS hello packet on Ethernet interface 0 to all ESs
on the network. This hello packet indicates that the NET of the router is
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00. The hold time for this packet is 299 seconds.
The packet header is 33 bytes in length.
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 33
The following line indicates that the router has sent an IS hello packet on Ethernet interface 1 to all ESs
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 34
The following line indicates that the router received a hello packet on Ethernet interface 0 from an
intermediate system, aa00.0400.6408. The hold time for this packet is 299 seconds.
ES-IS: ISH from aa00.0400.6408 (Ethernet0), HT 299
The following line indicates that the router has sent an IS hello packet on Tunnel interface 0 to all ESs
ES-IS: ISH sent to All ESs (Tunnel0): NET
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 34

May 2008 DB-359
Debug Commands
The following line indicates that on Ethernet interface 0, the router received a hello packet from an end
system with an SNPA of 0000.0c00.bda8. The hold time for this packet is 300 seconds.
IS-IS: ESH from 0000.0c00.bda8 (Ethernet0), HT 300

DB-360 May 2008
Debug Commands
debug clns events
debug clns events

To display Connectionless Network Service (CLNS) events that are occurring at the router, use the
debug clns events command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug clns events
no debug clns events
Examples The following is sample output from the debug clns events command:
Router# debug clns events
CLNS: Echo PDU received on Ethernet3 from 39.0001.2222.2222.2222.00!

CLNS: Sending from 39.0001.3333.3333.3333.00 to 39.0001.2222.2222.2222.00
via 2222.2222.2222 (Ethernet3 0000.0c00.3a18)
CLNS: Forwarding packet size 117
from 39.0001.2222.2222.2222.00
to 49.0002.0001.AAAA.AAAA.AAAA.00
via 49.0002 (Ethernet3 0000.0c00.b5a3)
CLNS: RD Sent on Ethernet3 to 39.0001.2222.2222.2222.00 @ 0000.0c00.3a18,
redirecting 49.0002.0001.AAAA.AAAA.AAAA.00 to 0000.0c00.b5a3
The following line indicates that the router received an echo protocol data unit (PDU) on Ethernet
interface 3 from source network service access point (NSAP) 39.0001.2222.2222.2222.00. The
exclamation point at the end of the line has no significance.
CLNS: Echo PDU received on Ethernet3 from 39.0001.2222.2222.2222.00!
The following lines indicate that the router at source NSAP 39.0001.3333.3333.3333.00 is sending a
CLNS echo packet to destination NSAP 39.0001.2222.2222.2222.00 via an IS with system ID
2222.2222.2222. The packet is being sent on Ethernet interface 3, with a MAC address of
0000.0c00.3a18.
CLNS: Sending from 39.0001.3333.3333.3333.00 to 39.0001.2222.2222.2222.00
via 2222.2222.2222 (Ethernet3 0000.0c00.3a18)
The following lines indicate that a CLNS echo packet 117 bytes in size is being sent from source NSAP
39.0001.2222.2222.2222.00 to destination NSAP 49.0002.0001.AAAA.AAAA.AAAA.00 via the router
at NSAP 49.0002. The packet is being forwarded on the Ethernet interface 3, with a MAC address of
0000.0c00.b5a3.
from 39.0001.2222.2222.2222.00
to 49.0002.0001.AAAA.AAAA.AAAA.00
via 49.0002 (Ethernet3 0000.0c00.b5a3)

May 2008 DB-361
Debug Commands
debug clns events
The following lines indicate that the router sent a redirect packet on the Ethernet interface 3 to the NSAP
39.0001.2222.2222.2222.00 at MAC address 0000.0c00.3a18 to indicate that NSAP
49.0002.0001.AAAA.AAAA.AAAA.00 can be reached at MAC address 0000.0c00.b5a3.
CLNS: RD Sent on Ethernet3 to 39.0001.2222.2222.2222.00 @ 0000.0c00.3a18,
redirecting 49.0002.0001.AAAA.AAAA.AAAA.00 to 0000.0c00.b5a3

DB-362 May 2008
Debug Commands
debug clns igrp packets

To display debugging information on all ISO-IGRP routing activity, use the debug clns igrp packets
privileged EXEC command. The no form of this command disables debugging output.
no debug clns igrp packets
Examples The following is sample output from the debug clns igrp packets command:
Router# debug clns igrp packets
ISO-IGRP: Hello sent on Ethernet3 for DOMAIN_green1

ISO-IGRP: Received hello from 39.0001.3333.3333.3333.00, (Ethernet3), ht 51
ISO-IGRP: Originating level 1 periodic update
ISO-IGRP: Advertise dest: 2222.2222.2222
ISO-IGRP: Sending update on interface: Ethernet3
ISO-IGRP: Advertise dest: 0001
ISO-IGRP: Received update from 3333.3333.3333 (Ethernet3)
ISO-IGRP: Opcode: area
ISO-IGRP: Received level 2 adv for 0001 metric 1100
ISO-IGRP: Opcode: station
ISO-IGRP: Received level 1 adv for 3333.3333.3333 metric 1100
The following line indicates that the router is sending a hello packet to advertise its existence in the
DOMAIN_green1 domain:
ISO-IGRP: Hello sent on Ethernet3 for DOMAIN_green1
The following line indicates that the router received a hello packet from a certain network service access
point (NSAP) on Ethernet interface 3. The hold time for this information is 51 seconds.
ISO-IGRP: Received hello from 39.0001.3333.3333.3333.00, (Ethernet3), ht 51
The following lines indicate that the router is generating a Level 1 update to advertise reachability to
destination NSAP 2222.2222.2222 and that it is sending that update to all systems that can be reached
through Ethernet interface 3:
ISO-IGRP: Advertise dest: 2222.2222.2222
The following lines indicate that the router is generating a Level 2 update to advertise reachability to
destination area 1 and that it is sending that update to all systems that can be reached through Ethernet
interface 3:
ISO-IGRP: Advertise dest: 0001
The following lines indicate that the router received an update from NSAP 3333.3333.3333 on Ethernet
interface 3. This update indicated the area that the router at this NSAP could reach.

May 2008 DB-363
Debug Commands
ISO-IGRP: Received update from 3333.3333.3333 (Ethernet3)

ISO-IGRP: Opcode: area
The following lines indicate that the router received an update advertising that the source of that update
can reach area 1 with a metric of 1100. A station opcode indicates that the update included system
addresses.
ISO-IGRP: Received level 2 adv for 0001 metric 1100
ISO-IGRP: Opcode: station

DB-364 May 2008
Debug Commands
debug clns packet
debug clns packet

To display information about packet receipt and forwarding to the next interface, use the debug clns
packet command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug clns packet
no debug clns packet
Examples The following is sample output from the debug clns packet command:
Router# debug clns packet

from 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.00 STUPI-RBS
to 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00
via 1600.8906.4017 (Ethernet0 0000.0c00.bda8)
CLNS: Echo PDU received on Ethernet0 from
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00!
CLNS: Sending from 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00 to
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00
In the following lines, the first line indicates that a Connectionless Network Service (CLNS) packet of
size 157 bytes is being forwarded. The second line indicates the network service access point (NSAP)
and system name of the source of the packet. The third line indicates the destination NSAP for this
packet. The fourth line indicates the next hop system ID, interface, and subnetwork point of attachment
(SNPA) of the router interface used to forward this packet.
from 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.00 STUPI-RBS
to 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00
In the following lines, the first line indicates that the router received an echo protocol data unit (PDU)
on the specified interface from the source NSAP. The second line indicates which source NSAP is used
to send a CLNS packet to the destination NSAP, as shown on the third line. The fourth line indicates the
next hop system ID, interface, and SNPA of the router interface used to forward this packet.
CLNS: Echo PDU received on Ethernet0 from
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00!
CLNS: Sending from 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00 to
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00

May 2008 DB-365
Debug Commands
debug clns routing
debug clns routing

To display debugging information for all Connectionless Network Service (CLNS) routing cache
updates and activities involving the CLNS routing table, use the debug clns routing command in
debug clns routing
no debug clns routing
Examples The following is sample output from the debug clns routing command:
Router# debug clns routing
CLNS-RT: cache increment:17

CLNS-RT: Add 47.0023.0001.0000.0000.0003.0001 to prefix table, next hop 1920.3614.3002
CLNS-RT: Aging cache entry for: 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.06
CLNS-RT: Deleting cache entry for: 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.06
The following line indicates that a change to the routing table has resulted in an addition to the
fast-switching cache:
CLNS-RT: cache increment:17
The following line indicates that a specific prefix route was added to the routing table, and indicates the
next hop system ID to that prefix route. In other words, when the router receives a packet with the prefix
47.0023.0001.0000.0000.0003.0001 in the destination address of that packet, it forwards that packet to
the router with the MAC address 1920.3614.3002.
CLNS-RT: Add 47.0023.0001.0000.0000.0003.0001 to prefix table, next hop 1920.3614.3002
The following lines indicate that the fast-switching cache entry for a certain network service access point
(NSAP) has been invalidated and then deleted:
CLNS-RT: Aging cache entry for: 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.06
CLNS-RT: Deleting cache entry for: 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.06

DB-366 May 2008
Debug Commands
debug cls message
debug cls message

To display information about Cisco Link Services (CLS) messages, use the debug cls message command
debug cls message
no debug cls message
Usage Guidelines The debug cls message command displays the primitives (state), selector, header length, and data size.
Examples The following is sample output from the debug cls message command. For example, CLS-->DLU
indicates the direction of the flow that is described by the status. From CLS to dependent logical unit
(DLU), a request was established to the connection endpoint. The header length is 48 bytes, and the data
size is 104 bytes.
Router# debug cls message
(FRAS Daemon:CLS-->DLU):
ID_STN.Ind to uSAP: 0x607044C4 sel: LLC hlen: 40, dlen: 54
ID_STN.Ind to uSAP: 0x6071B054 sel: LLC hlen: 40, dlen: 46
(FRAS Daemon:DLU-->SAP):
REQ_OPNSTN.Req to pSAP: 0x608021F4 sel: LLC hlen: 48, dlen: 104
REQ_OPNSTN.Cfm(NO_REMOTE_STN) to uCEP: 0x607FFE84 sel: LLC hlen: 48, dlen: 104
The status possibilities include the following: enabled, disabled, request open station, open station, close
station, activate SA, deactivate service access point (SAP), XID, exchange identification (XID) station,
connect station, signal station, connect, disconnect, connected, data, flow, unnumbered data, modify
SAP, test, activate ring, deactivate ring, test station, and unnumbered data station.

debug fras error Displays information about FRAS protocol errors.
debug fras message Displays general information about FRAS messages.
debug fras state Displays information about FRAS data-link control state changes.

May 2008 DB-367
Debug Commands
debug cls vdlc
debug cls vdlc

To display information about Cisco Link Services (CLS) Virtual Data Link Control (VDLC), use the
debug cls vdlc command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
debug cls vdlc
no debug cls vdlc
Usage Guidelines The debug cls message command displays primitive state transitions, selector, and source and
destination MAC and service access points (SAPs).
Also use the show cls command to display additional information on CLS VDLC.
Caution Use the debug cls vdlc command with caution because it can generate a substantial amount of output.
Examples The following messages are sample output from the debug cls vdlc command. In the following scenario,
the systems network architecture (SNA) service pointalso called native service point (NSP)is
setting up two connections through VDLC and data-link switching (DLSw): one from NSP to VDLC and
one from DLSw to VDLC. VDLC joins the two.
The NSP initiates a connection from 4000.05d2.0001 as follows:
VDLC: Req Open Stn Req PSap 0x7ACE00, port 0x79DF98
4000.05d2.0001(0C)->4000.1060.1000(04)
In the next message, VDLC sends a test station request to DLSw for destination address 4000.1060.1000.
VDLC: Send UFrame E3: 4000.05d2.0001(0C)->4000.1060.1000(00)
In the next two messages, DLSw replies with test station response, and NSP goes to a half-open state.
NSP is waiting for the DLSw connection to VDLC.
VDLC: Sap to Sap TEST_STN_RSP VSap 0x7B68C0 4000.1060.1000(00)->4000.05d2.0001(0C)
VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_OPENING->VDLC_HALF_OPEN
The NSP sends an exchange identification (XID) and changes state as follows:
VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_HALF_OPEN->VDLC_XID_RSP_PENDING
VDLC: CEP to SAP ID_REQ 4000.05d2.0001(0C)->4000.1060.1000(04) via bridging SAP (DLSw)

DB-368 May 2008
Debug Commands
debug cls vdlc
In the next several messages, DLSw initiates its connection, which matches the half-open connection
with NSP:
VDLC: Req Open Stn Req PSap 0x7B68C0, port 0x7992A0
4000.1060.1000(04)->4000.05d2.0001(0C)
VDLC: two-way connection established
VDLC: 4000.1060.1000(04)->4000.05d2.0001(0C): VDLC_IDLE->VDLC_OPEN
In the following messages, DLSw sends an XID response, and the NSP connection goes from the state
XID Response Pending to Open. The XID exchange follows:
VDLC: CEP to CEP ID_RSP 4000.1060.1000(04)->4000.05d2.0001(0C)
VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_XID_RSP_PENDING->VDLC_OPEN
VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_OPEN->VDLC_XID_RSP_PENDING
VDLC: CEP to CEP ID_REQ 4000.05d2.0001(0C)->4000.1060.1000(04)
When DLSw is ready to connect, the front-end processor (FEP) sends a set asynchronous balanced mode
extended (SABME) command as follows:
VDLC: CEP to CEP CONNECT_REQ 4000.1060.1000(04)->4000.05d2.0001(0C)
In the following messages, NSP accepts the connection and sends an unnumbered acknowledgment (UA)
to the FEP:
VDLC: CEP to CEP CONNECT_RSP 4000.05d2.0001(0C)->4000.1060.1000(04)
VDLC: FlowReq QUENCH OFF 4000.1060.1000(04)->4000.05d2.0001(0C)
The following messages show the data flow:

VDLC: DATA 4000.1060.1000(04)->4000.05d2.0001(0C)
VDLC: DATA 4000.05d2.0001(0C)->4000.1060.1000(04)
.
.
.
VDLC: DATA 4000.1060.1000(04)->4000.05d2.0001(0C)
VDLC: DATA 4000.05d2.0001(0C)->4000.1060.1000(04)

debug cls message Displays information about CLS messages.

May 2008 DB-369
Debug Commands
debug cme-xml
debug cme-xml
To generate debug messages for the Cisco Unified CallManager Express XML application, use the
debug cme-xml command in privileged EXEC mode. To disable debugging, use the no form of the
command.
debug cme-xml
no debug cme-xml

Usage Guidelines The show fb-its-log command displays the contents of the XML event table.
Examples The following example shows the progress of an XML request that has been sent to
Cisco Unified CallManager Express:
Router# debug cme-xml
*Aug 5 06:27:25.727: CME got a raw XML message.

*Aug 5 06:27:25.727: doc 0x63DB85E8, doc->doc_type 3, req 0x655FDCD0
*Aug 5 06:27:25.727: CME extracted a XML document
*Aug 5 06:27:25.727: Response buffer 0x63DCFD58, len = 4096
*Aug 5 06:27:25.727: First Tag ID SOAP_HEADER_TAG_ID 58720257
*Aug 5 06:27:25.727: First Attribute ID SOAP_ENV_ATTR 50331649
*Aug 5 06:27:25.727: cme_xml_process_soap_header
*Aug 5 06:27:25.727: cme_xml_process_soap_body
*Aug 5 06:27:25.731: cme_xml_process_axl
*Aug 5 06:27:25.731: cme_xml_process_request
*Aug 5 06:27:25.731: cme_xml_process_ISgetGlobal
*Aug 5 06:27:25.731: CME XML sent 811 bytes response.

show fb-its-log Displays Cisco Unified CallManager Express XML API information.

DB-370 May 2008
Debug Commands
debug cns config
debug cns config

To turn on debugging messages related to the Cisco Networking Services (CNS) Configuration Agent,
use the debug cns config command in privileged EXEC mode. To disable debugging output, use the no
debug cns config {agent | all | connection | notify}
no debug cns config {agent | all | connection | notify}
Syntax Description agent Displays debugging messages related to the CNS configuration agent.
all Displays all debugging messages.
connection Displays debugging messages related to configuration connections.
notify Displays debugging messages related to CNS configurations.

12.2(8)T This command was implemented on the Cisco 2600 and Cisco 3600 series.
Usage Guidelines Use this command to turn on or turn off debugging messages related to the CNS Configuration Agent.
Examples In the following example, debugging messages are enabled for CNS configuration processes:
Router# debug cns config all
00:04:09: config_id_get: entered

00:04:09: config_id_get: Invoking cns_id_mode_get()
00:04:09: config_id_get: cns_id_mode_get() returned INTERNAL
00:04:09: config_id_get: successful exit cns_config_id=minna1,cns_config_id_len=6
00:04:09: cns_establish_connect_intf(): The device is already connected with the config
server
00:04:09: cns_initial_config_agent(): connecting with port 80
00:04:09: pull_config() entered
00:04:09: cns_config_id(): returning config_id=minna1
00:04:09: Message finished 150 readend
00:04:09: %CNS-4-NOTE: SUCCESSFUL_COMPLETION

May 2008 DB-371
Debug Commands
debug cns config
-Process= "CNS Initial Configuration Agent", ipl= 0, pid= 82

00:04:10: %SYS-5-CONFIG_I: Configured from console by console

cns config cancel Cancels a CNS configuration.
cns config initial Starts the initial CNS Configuration Agent.
cns config partial Starts the partial CNS Configuration Agent.
cns config retrieve Gets the configuration of a routing device using CNS.
debug cns event Displays information on CNS events.
debug cns exec Displays information on CNS management.
debug cns xml-parser Displays information on the CNS XML parser.
show cns config Displays information about the CNS Configuration Agent.

DB-372 May 2008
Debug Commands
debug cns event
debug cns event

To turn on debugging messages related to the Cisco Networking Services (CNS) Event Gateway, use the
debug cns event command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
debug cns event {agent | all | connection | subscriber}
no debug cns event {agent | all | connection | subscriber}
Syntax Description agent Displays debugging messages related to the event agent.
connection Displays debugging messages related to event connections.
subscriber Displays debugging messages related to subscribers.

12.0(18)ST This command was integrated into the Cisco IOS Release 12.0(18)ST.
12.2(8)T This command was implemented on Cisco 2600 series and Cisco 3600
series routers.
12.2(31)SB2 This command was integrated into Cisco IOS Release 12.2(31)SB2.
Usage Guidelines Use this command to turn on or turn off debugging messages related to the CNS Event Gateway.
Examples In the following example, debugging messages about all CNS Events are enabled:
Router# debug cns event all

00:09:14: event_agent():event_agent starting ..
00:09:14: event_agent_open_connection(): attempting socket connect to Primary Gateway
00:09:14: event_agent_open_connection():cns_socket_connect() succeeded:return_code=0
00:09:14: event_agent_open_connection():timeout_len=1:ka_total_timeout =0:
total_timeout=0
00:09:14: event_id_get: entered
00:09:14: event_id_get: Invoking cns_id_mode_get()

May 2008 DB-373
Debug Commands
debug cns exec
debug cns exec

To display debugging messages about Cisco Networking Services (CNS) exec agent services, use the
debug cns exec command in privileged EXEC mode. To disable debugging output, use the no or
undebug form of this command.
debug cns exec {agent | all | decode | messages}
no debug cns exec {agent | all | decode | messages}
undebug cns exec {agent | all | decode | messages}
Syntax Description agent Displays debugging messages related to the exec agent.
decode Displays debugging messages related to image agent connections.
messages Displays debugging output related to messages generated by exec agent
services.

Usage Guidelines Use the debug cns exec command to troubleshoot CNS exec agent services.
Examples The following example shows a debugging message for the CNS exec agent when a response has been
posted to HTTP:
Router# debug cns exec agent
4d20h: CNS exec agent: response posted

cns exec Configures CNS Exec Agent services.

DB-374 May 2008
Debug Commands
debug cns image
debug cns image

To display debugging messages about Cisco Networking Services (CNS) image agent services, use the
debug cns image command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
debug cns image {agent | all | connection | error}
no debug cns image {agent | all | connection | error}
Syntax Description agent Displays debugging messages related to the image agent.
connection Displays debugging messages related to image agent connections.
error Displays debugging messages related to errors generated by image agent
services.
Defaults If no keyword is specified, all debugging messages are displayed.

Usage Guidelines Use the debug cns image command to troubleshoot CNS image agent services.

May 2008 DB-375
Debug Commands
debug cns management

To display information about Cisco Networking Services (CNS) management, use the debug cns
management command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug cns management {snmp | xml}
no debug cns management {snmp | xml}
Syntax Description snmp Displays debugging messages related to nongranular Simple Network
Management Protocol (SNMP) encapsulated CNS-management events.
xml Displays debugging messages related to granular eXtensible Markup
Language (XML) encapsulated CNS-management events.

Examples In the following example, debugging messages about SNMP- and XML-encapsulated CNS-management
events are enabled:
Router# debug cns management snmp
Router# debug cns management xml
Router# show debugging
CNS Management (SNMP Encapsulation) debugging is on

CNS Management (Encap XML) debugging is on
Router# show running-config | include cns
cns mib-access encapsulation snmp

cns mib-access encapsulation xml
cns notifications encapsulation snmp
cns notifications encapsulation xml
cns event 10.1.1.1 11011
Router#
00:12:50: Enqueued a notification in notif_q
00:12:50: ea_produce succeeded Subject:cisco.cns.mibaccess:notification Message Length:385
00:12:50: Trap sent via CNS Transport Mapping.
Router#
00:13:31: Response sent via CNS Transport Mapping.
Router#
00:14:38: Received a request
00:14:38: ea_produce succeeded Subject:cisco.cns.mibaccess:response Message Length:241

DB-376 May 2008
Debug Commands

cns event Configures the CNS event gateway, which provides CNS event
services to Cisco IOS clients.
debug cns config Displays information on CNS configurations.
debug cns xml-parser Displays information on the CNS XML parser.
show debugging Displays information about the types of debugging that are enabled
for your router.
show running-config Displays the current running configuration.

May 2008 DB-377
Debug Commands
debug cns xml
debug cns xml

To turn on debugging messages related to the Cisco Networking Services (CNS) eXtensible Markup
Language (XML) parser, use the debug cns xml command in privileged EXEC mode. To disable
debug cns xml {all | decode | dom | parser}
no debug cns xml {all | decode | dom | parser}
Syntax Description all Displays all CNS debugging.

decode Reports usage of common XML decoding library functions by applications
and reports the decoded contents.
dom Displays failures in the Document Object Model (DOM) infrastructure
messages tree built by the XML parser.
parser Displays failures and progress of the parsing of an XML message by the
XML parser.

12.3(2)T This command was introduced. This command replaces the debug cns
xml-parser command.
Examples In the following example, debugging messages for the CNS XML parser are enabled:
Router# debug cns xml parser
00:12:05: Registering tag <config-server>

00:12:05: Registering tag <server-info>
00:12:05: Registering tag <ip-address>
00:12:05: Registering tag <web-page>
00:12:05: Registering tag <config-event>
00:12:05: Registering tag <identifier>
00:12:05: Registering tag <config-id>
00:12:05: Registering tag <config-data>
00:12:05: Registering tag <cli>
00:12:05: Registering tag <error-info>
00:12:05: Registering tag <error-message>
00:12:05: Registering tag <line-number>
00:12:05: Registering tag <config-write>
00:12:05: Registering tag <exec-cmd-event>
00:12:05: Registering tag <identifier-exec>

DB-378 May 2008
Debug Commands
debug cns xml
00:12:05: Registering tag <event-response>

00:12:05: Registering tag <reply-subject>
00:12:05: Registering tag <server-response>
00:12:05: Registering tag <ip-address-exec>
00:12:05: Registering tag <port-number>
00:12:05: Registering tag <url>
00:12:05: Registering tag <cli-exec>
00:12:05: Registering tag <config-pwd>
00:12:06: Pushing tag <config-data> on to stack
00:12:06: open tag is <config-data>
00:12:06: Pushing tag <config-id> on to stack
00:12:06: open tag is <config-id>
00:12:06: Popping tag <config-id> off stack
00:12:06: close tag is </config-id>
00:12:06: Pushing tag <cli> on to stack
00:12:06: open tag is <cli>
00:12:06: Popping tag <cli> off stack
00:12:06: close tag is </cli>
00:12:06: Popping tag <config-data> off stack
00:12:06: close tag is </config-data>

cns event Configures the CNS Event Gateway.
show cns event Displays information about the CNS Event Agent.

May 2008 DB-379
Debug Commands
debug cns xml-parser

Note Effective with Cisco IOS Release 12.3(2)T, the debug cns xml-parser command is replaced by the
debug cns xml command. See the debug cns xml command for more information.
To turn on debugging messages related to the Cisco Networking Services (CNS) eXtensible Markup
Language (XML) parser, use the debug cns xml-parser command in privileged EXEC mode. To disable
no debug cns xml-parser

12.2(8)T This command was implemented on the Cisco 2600 and Cisco 3600 series.
12.3(2)T This command was replaced by the debug cns xml command.
Examples In the following example, debugging messages for the CNS XML parser are enabled:
Router# debug cns xml-parser
00:12:05: Registering tag <config-server>

00:12:05: Registering tag <server-info>
00:12:05: Registering tag <ip-address>
00:12:05: Registering tag <web-page>
00:12:05: Registering tag <config-event>
00:12:05: Registering tag <identifier>
00:12:05: Registering tag <config-id>
00:12:05: Registering tag <config-data>
00:12:05: Registering tag <cli>
00:12:05: Registering tag <error-info>
00:12:05: Registering tag <error-message>
00:12:05: Registering tag <line-number>
00:12:05: Registering tag <config-write>
00:12:05: Registering tag <exec-cmd-event>
00:12:05: Registering tag <identifier-exec>
00:12:05: Registering tag <event-response>
00:12:05: Registering tag <reply-subject>

DB-380 May 2008
Debug Commands
00:12:05: Registering tag <server-response>

00:12:05: Registering tag <ip-address-exec>
00:12:05: Registering tag <port-number>
00:12:05: Registering tag <url>
00:12:05: Registering tag <cli-exec>
00:12:05: Registering tag <config-pwd>
00:12:06: Pushing tag <config-data> on to stack
00:12:06: open tag is <config-data>
00:12:06: Pushing tag <config-id> on to stack
00:12:06: open tag is <config-id>
00:12:06: Popping tag <config-id> off stack
00:12:06: close tag is </config-id>
00:12:06: Pushing tag <cli> on to stack
00:12:06: open tag is <cli>
00:12:06: Popping tag <cli> off stack
00:12:06: close tag is </cli>
00:12:06: Popping tag <config-data> off stack
00:12:06: close tag is </config-data>

cns event Configures the CNS Event Gateway.
show cns event Displays information about the CNS Event Agent.

May 2008 DB-381
Debug Commands
debug compress
debug compress
To debug compression, enter the debug compress command in privileged EXEC mode. To disable
debug compress
no debug compress
Defaults Disabled.

Usage Guidelines Use this command to display output from the compression and decompression configuration you made.
Live traffic must be configured through the Cisco 2600 access router with a data compression Advanced
Interface Module (AIM) installed for this command to work.
Examples The following example is output from the debug compress command, which shows that compression is
taking place on a Cisco 2600 access router using data compression AIM hardware compression is
configured correctly:
Router# debug compress
COMPRESS debugging is on
Router#compr-in:pak:0x810C6B10 npart:0 size:103
pak:0x810C6B10 start:0x02406BD4 size:103 npart:0
compr-out:pak:0x8118C8B8 stat:0x00000000 npart:1 size:71 lcb:0xED
pak:0x8118C8B8 start:0x0259CD3E size:71 npart:1
mp:0x8118A980 start:0x0259CD3E size:71
decmp-in:pak:0x81128B78 start:0x0255AF44 size:42 npart:1 hdr:0xC035

pak:0x81128B78 start:0x0255AF44 size:42 npart:1
mp:0x81174480 start:0x0255AF44 size:42
decmp-out:pak:0x8118C8B8 start:0x025B2C42 size:55 npart:1 stat:0
pak:0x8118C8B8 start:0x025B2C42 size:55 npart:1
mp:0x8118B700 start:0x025B2C42 size:55

DB-382 May 2008
Debug Commands
debug compress
Table 55 debug compress Field Descriptions
Field Description
compr-in Indicates that a packet needs to be compressed.
compr-out Indicates completion of compression of packet.
decmp-in Indicates receipt of a compressed packet that needs
to be decompressed.
decmp-out Indicates completion of decompression of a packet.
pak:0x810C6B10 Provides the address in memory of a software
structure that describes the compressed packet.
start:0x02406BD4 size:103 npart:0 The npart:0 indicates that the packet is contained
in a single, contiguous area of memory. The start
address of the packet is 0x02406bd4 and the size of
the packet is 103.
start:0x0259CD3E size:71 npart:1 The npart:1 indicates that the packet is contained
in 1 or more regions of memory. The start address
of the packet is 0x0259CD3E and the size of the
packet is 71.
mp:0x8118A980 start:0x0259CD3e size:71 Describes one of these regions of memory.
mp:0x8118A980 Provides the address of a structure describing this
region.
start 0x0259CD3E Provides the address of the start of this region.

debug frame-relay Displays debugging information about the packets that are received on a
Frame Relay interface.
debug ppp Displays information on traffic and exchanges in an internetwork
implementing the PPP.
show compress Displays compression statistics.
show diag Displays hardware information including DRAM, SRAM, and the
revision-level information on the line card.

May 2008 DB-383
Debug Commands
debug condition application voice

To display debugging messages for only the specified VoiceXML application, use the debug condition
application voice command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
debug condition application voice application-name
no debug condition application voice application-name
Syntax Description application-name Name of the VoiceXML application for which you want to display all
enabled debugging messages.
Defaults If this command is not configured, debugging messages are enabled for all VoiceXML applications.

12.2(11)T This command was introduced for the Cisco 3640, Cisco 3660,
Cisco AS5300, Cisco AS5350, and Cisco AS5400.
Usage Guidelines This command filters debugging output only for the debug vxml and debug http client commands,
except that it does not filter output for the debug vxml error, debug vxml background, debug http
client error, or debug http client background commands. It does not filter messages for any other
debug commands such as the debug voip ivr command or the debug voice ivr command.
This command filters debugging output for all VoiceXML applications except the application named
in the command. When this command is configured, the gateway displays debugging messages only
for the specified VoiceXML application.
To filter debugging output with this command, the <cisco-debug> element must be enabled in the
VoiceXML document. For more information about the <cisco-debug> element, refer to the
Cisco VoiceXML Programmers Guide.
To see debugging output for VoiceXML applications, you must first configure global debug
commands such as the debug vxml command or the debug http client command. If no global debug
commands are turned on, you do not see debugging messages even if the debug condition
application voice command is configured and the <cisco-debug> element is enabled in the
VoiceXML document.
This command can be configured multiple times to display output for more than one application.
To see which debug conditions have been set, use the show debug condition command.

DB-384 May 2008
Debug Commands
Examples The following example disables debugging output for all applications except the myapp1 application, if
the <cisco-debug> element is enabled in the VoiceXML documents that are executed by myapp1:
Router# debug condition application voice myapp1

debug http client Displays debugging messages for the HTTP client.
debug vxml Displays debugging messages for VoiceXML features.
show debug condition Displays the debugging conditions that have been enabled for
VoiceXML application.

May 2008 DB-385
Debug Commands
debug condition glbp
debug condition glbp

To display debugging messages about Gateway Load Balancing Protocol (GLBP) conditions, use the
debug condition glbp command in privileged EXEC mode. To disable debugging output, use the no
debug condition glbp interface-type interface-number group [forwarder]
no debug condition glbp interface-type interface-number group [forwarder]
Syntax Description interface-type Interface type for which output is displayed.

interface-number Interface number for which output is displayed.
group GLBP group number in the range from 0 to 1023.
forwarder (Optional) Number in the range from 1 to 255 used to identify a virtual MAC
address.

12.2(17b)SXA This command was integrated into Cisco IOS Release 12.2(17b)SXA.
Examples The following is sample output from the debug condition glbp command:
Router# debug condition glbp fastethernet 0/0 10 1
Condition 1 set
5d23h: Fa0/0 GLBP10.1 Debug: Condition 1, glbp Fa0/0 GLBP10.1 triggered, count 1

debug glbp errors Displays debugging messages about GLBP errors.
debug glbp events Displays debugging messages about GLBP events.
debug glbp packets Displays debugging messages about GLBP packets.
debug glbp terse Displays a limited range of debugging messages about GLBP errors, events,
and packets.

DB-386 May 2008
Debug Commands
debug condition interface

To limit output for some debug commands on the basis of the interface, virtual circuit (VC), or VLAN,
use the debug condition interface command in privileged EXEC mode. To remove the interface
condition and reset the interface so that it must be triggered by a condition, use the no form of this
command.
debug condition interface interface-type interface-number [dlci dlci] [vc {vci | vpi/vci}] [vlan-id
vlan-id]
no debug condition interface interface-type interface-number [dlci dlci] [vc {vci | vpi/vci}]
[vlan-id vlan-id]
Syntax Description interface-type interface-number Interface type and number. No space is required between the
interface type and number. Some interfaces require a slash
between the type and number.
dlci dlci (Optional) If the interface to be debugged is a Frame
Relay-encapsulated interface, specifies the data-link
connection identifier (DLCI).
vc {vci | vpi/vci} (Optional) If the interface to be debugged is an
ATM-encapsulated interface, specifies the virtual channel
identifier (VCI) or virtual path identifier/virtual channel
identifier (VPI/VCI) pair. (The slash is required.)
vlan-id vlan-id (Optional) If the interface to be debugged is ATM, Ethernet,
Fast Ethernet, or Gigabit Ethernet, specifies the VLAN ID.
Defaults All debugging messages for enabled debug commands are displayed.

12.0(28)S The dlci and vc keywords were added for additional Frame Relay and ATM
functionality.
12.2(28)SB This command was integrated into Cisco IOS Release 12.2(28)SB, and the
ability to filter debug output on the basis of VLAN ID was added.

May 2008 DB-387
Debug Commands
Usage Guidelines Use this command to restrict the debugging output for some commands on the basis of an interface or
virtual circuit. When you enter this command, debugging output is turned off for all interfaces except
the specified interface or virtual circuit. In addition, this command enables conditional debugging to
limit output for specific debugging events. Messages are displayed as different interfaces meet specific
conditions.
The no form of the command has two functions:
It disables the debug condition interface command for the specified interface. Output is no longer
generated for the interface, assuming that the interface meets no other applicable conditions. If the
interface meets other conditions that have been set by another debug condition command,
debugging output will still be generated for the interface.
If some other debug condition command has been enabled, output is stopped for that interface until
the condition is met on the interface. You will be asked for confirmation before the last condition or
all conditions are removed.
Not all debugging output is affected by the debug condition command. Some commands generate output
whenever they are enabled, regardless of whether they meet any conditions. The commands that are
affected by the debug condition commands are generally related to dial access functions, where a large
amount of output is expected. Output from the following commands is controlled by the debug
condition command:
debug aaa
debug atm
debug dialer events
debug frame-relay
debug isdn
debug modem
debug ppp
One or more ATM-encapsulated interfaces must be enabled, and one or more of the following debug
commands must be enabled to use conditional debugging with ATM:
debug atm arp
debug atm counters
debug atm errors
debug atm events
debug atm oam
debug atm packet
debug atm state
One or more of the following debug commands must be enabled to use conditional debugging with
Frame Relay:
debug frame-relay adjacency
debug frame-relay ipc
debug frame-relay lmi
debug frame-relay packet
debug frame-relay pseudowire

DB-388 May 2008
Debug Commands
Examples In the following example, only debug command output related to serial interface 1 is displayed. The
condition identifier for this command is 1.
Router# debug condition interface serial 1
Condition 1 set
The following example enables an ATM interface, specifies an IP address for the interface, turns on
conditional debugging for that interface with a VPI/VCI pair of 255/62610, and verifies that debugging
has been enabled:
Router> enable
Password:

Router(config)# interface ATM 2/0
Router(config-if)# ip address 10.0.0.5 255.255.255.0
Router(config-if-atm-vc)# no shutdown
Router(config-if)# exit
2w3d: %SYS-5-CONFIG_I: Configured from console by console
Router# debug atm state
ATM VC States debugging is on
Router# debug condition interface ATM2/0 vc 255/62610
Condition 1 set
2w3d: ATM VC Debug: Condition 1, atm-vc 255/62610 AT2/0 triggered, count 1
Condition 1: atm-vc 255/62610 AT2/0 (1 flags triggered)
Flags: ATM VC
In the following example, Frame Relay conditional debugging is enabled on Frame Relay DLCI 105:
Router# debug condition interface serial 4/3 dlci 105
Router# debug frame-relay packet

debug condition Limits output for some debug commands on the basis of specific conditions.

May 2008 DB-389
Debug Commands
debug condition match-list

To run a filtered debug on a voice call, use the debug condition match-list command in privileged
debug condition match-list number {exact-match | partial-match}
no debug condition match-list number {exact-match | partial-match}
Syntax Description number Numeric label that uniquely identifies the match list. Range is 1 to 16. The
number for the match list is set using the call filter match-list command.
exact-match All related debug output is filtered until all conditions in the match list are
explicitly met. This is the best choice for most situations because the output
is the most concise.
partial-match No related debug output is filtered until there is a single explicit match
failure. As long as zero or more conditions are met, debug output will not be
filtered. This choice is useful in debugging call startup problems like digit
collection, but is not ideal for many situations because there is much debug
output until matches explicitly fail.

Examples In this output example, the following configuration was used:

call filter match-list 1 voice
incoming calling-number 8288807
incoming called-number 6560729
incoming port 7/0:D
The following is sample output for the debug condition match-list 1 command. The next several lines
match the above conditions.
Router# debug condition match-list 1
07:22:19://-1/3C0B9468-15C8-11D4-8013-000A8A389BA8/VTSP:(7/0:D):0:0:0/vtsp_gcfm_incoming_c
ond_notify: add incoming port cond success: 7/0:D
07:22:19://-1/3C0B9468-15C8-11D4-8013-000A8A389BA8/VTSP:(7/0:D):0:0:0/vtsp_gcfm_incoming_c
ond_notify: add incoming dialpeer tag success:1

DB-390 May 2008
Debug Commands
07:22:19://-1/3C0B9468-15C8-11D4-8013-000A8A389BA8/VTSP:(7/0:D):0:0:0/vtsp_update_dsm_stre
am_mgr_filter_flag: cannot find dsp_stream_mgr_t
07:22:19://-1/3C0B9468-15C8-11D4-8013-000A8A389BA8/VTSP:(7/0:D):0:0:0/vtsp_update_dsm_stre
am_mgr_filter_flag: update dsp_stream_mgr_t debug flag
07:22:19: //49/3C0B9468-15C8-11D4-8013-000A8A389BA8/VTSP:(7/0:D):0:0:0/vtsp_insert_cdb:
,cdb 0x6482C518, CallID=49
07:22:19://49/3C0B9468-15C8-11D4-8013-000A8A389BA8/VTSP:(7/0:D):0:0:0/vtsp_do_call_setup_i
nd: Call ID=98357, guid=3C0B9468-15C8-11D4-8013-000A8A389BA8
Table 56 debug condition match-list Field Descriptions
Field Description
3C0B9468-15C8-11D4-8013-000A8A389BA8 Shows the global unique identifier (GUID).
VTSP: Identifies the voice telephony service provider
(VTSP) module.
(7/0:D):0:0:0 Shows the port name, channel number, DSP slot,
and DSP channel number for the VTSP module.

call filter match-list voice Creates a call filter match list for debugging voice calls.
show call filter match-list Displays call filter match lists.

May 2008 DB-391
Debug Commands
debug condition standby

To filter the output of the debug standby command on the basis of interface and Hot Standby Router
Protocol (HSRP) group number, use the debug condition standby command in privileged EXEC mode.
To remove the specified filter condition, use the no form of this command.
debug condition standby interface group-number
no debug condition standby interface group-number
Syntax Description interface Filters output on the basis of the interface.

group-number Filters output on the basis of HSRP group number. The range is 0 to 255
for HSRP Version 1 and 0 to 4095 for HSRP Version 2.
Defaults All debugging messages for the debug standby command aregenerated.

Usage Guidelines Use the debug condition standby command to restrict the debug output for the debug standby
command. If the debug condition standby command is enabled, output is generated only for the
interfaces and HSRP group numbers specified. The interface you specify must be a valid interface
capable of supporting HSRP. The group can be any group (0 to 255 for HSRPv1 and 0 to 4095 for
HSRPv2).
Use the no form of this command to remove the HSRP debug condition. If the last condition is removed,
debugging output resumes for all interfaces. You will be asked for confirmation before removing the last
condition or all conditions.
You can set debug conditions for groups that do not exist, which allows you to capture debug information
during the initialization of a new group.
You must enable the debug standby command in order for any HSRP debug output to be produced. If
you do not configure the debug condition standby command after entering the debug standby
command, then debug output is produced for all groups on all interfaces.
Examples In the following example, the router displays debugging messages only for Ethernet interface 0/0 that
are part of HSRP group 23:
Router# debug standby

DB-392 May 2008
Debug Commands
HSRP debugging is on
Router# debug condition standby ethernet0/0 23
Condition 1 set
00:27:39: HSRP: Et0/0 Grp 23 Hello out 10.0.0.1 Active pri 100 vIP 172.16.6.5
The following example shows how to remove an HSRP debug condition:

Router# no debug condition standby ethernet0/0 23
This condition is the last hsrp condition set.

Removing all conditions may cause a flood of debugging
messages to result, unless specific debugging flags
are first removed.
Proceed with removal? [yes/no]: Y

Condition 1 has been removed.

debug condition interface Limits output for some debugging commands based on the
interfaces.
debug standby Displays HSRP state changes.
debug standby errors Displays error messages related to HSRP.
debug standby events Displays events related to HSRP.
debug standby events icmp Displays debugging messages for the HSRP ICMP redirects filter.
debug standby packets Displays debugging information for packets related to HSRP.

May 2008 DB-393
Debug Commands
debug condition voice-port

To limit output for debug commands based on the voice port, use the debug condition voice-port
command in privileged EXEC mode. To disable the condition, use the no form of this command.
debug condition voice-port port
no debug condition voice-port port
Syntax Description port Voice port for which you want to display all enabled debugging messages.
Note Port syntax is platform-dependent; type ? to determine.
Command Default Debugging messages are enabled for all voice ports.

Usage Guidelines This command filters out debugging output for all voice ports except the port specified in the
command. When this command is configured, the gateway displays debugging messages only for
the specified port.
To see debugging output, you must first enable debug commands such as the debug voip
application stcapp all command or the debug sccp all command. If no debug commands are turned
on, you do not see debugging messages even if the debug condition voice-port command is enabled.
This command can be configured multiple times to display output for more than one voice port.
To see which debug conditions have been set, use the show debug command.
Before disabling conditions, first disable any debugging commands; otherwise output for all ports
could flood the logging buffer.
Examples The following example filters debugging output so that only output for ports 2/1 and 2/3 is displayed:
Router# debug condition voice-port 2/1
Condition 1 set
*Mar 1 22:24:15.102: Debug: Condition 1, voice-port 2/1 triggered, count 1
Router# debug condition voice-port 2/3
Condition 2 set

DB-394 May 2008
Debug Commands
*Mar 1 22:24:24.794: Debug: Condition 2, voice-port 2/3 triggered, count 2
Router# show debug
Condition 1: voice-port 2/1 (1 flags triggered)

Flags: voice-port condition
Condition 2: voice-port 2/3 (1 flags triggered)
Flags: voice-port condition

debug sccp all Displays debugging information for Simple Client Control Protocol
(SCCP).
debug voip application stcapp Displays debugging information for the components of the SCCP
all Telephony Control Application (STCAPP).
debug voip application stcapp Enables STCAPP debugging for a specific port.
port
show debug Displays the types of debugging and the debugging conditions that
are enabled on your router.

May 2008 DB-395
Debug Commands
debug condition xconnect

To conditionally filter debug messages related to xconnect configurations, use the debug condition
xconnect command in privileged EXEC configuration mode. To disable the filtering of xconnect debug
messages, use the no form of this command.
debug condition xconnect {fib type | interface type number [dlci | vp number | vc number] | peer
ip-address vcid vcid | segment segment-id}
no debug condition xconnect {fib type | interface type number [dlci | vp number | vc number] |
peer ip-address vcid vcid | segment segment-id}
Syntax Description fib type Filters control-plane and data-plane debug messages for the xconnect
segment pair specified by matching against the Forwarding Information Base
(FIB) Interface Descriptor Block (IDB) information associated with a
particular interface on a line card.
interface type number Filters control-plane and data-plane debug messages for the xconnect
segment pair specified by the interface type and number on a Route
Processor.
dlci (Optional) The Frame Relay data-link connection identifier (DLCI) for the
xconnect segment pair associated with a Frame Relay segment.
vp number (Optional) The ATM virtual path (VP) number for the xconnect segment pair
associated with an ATM segment.
vc number (Optional) The ATM virtual circuit (VC) number for the xconnect segment
pair associated with an ATM segment.
peer Filters control-plane and data-plane debug messages for the xconnect
segment pair specified by the remote peer IP address and the pseudowire
virtual circuit ID (VCID).
ip-address The IP address of the remote peer router.
vcid vcid The VCID of the xconnect pseudowire.
segment Filters data-plane debug messages for the xconnect segment pair specified by
a segment ID.
segment-id The segment ID. The segment ID value can be found in the output of the
show ssm id command.
Command Default Debug messages are not filtered.

DB-396 May 2008
Debug Commands

Usage Guidelines Use the debug condition xconnect command to specify conditions for filtering the debug messages
displayed by related subscriber service switch (SSS), xconnect, and attachment circuit debug
commands.
Examples The following example sets filter conditions that allow related debug commands to display debug
messages for only the xconnect segment pair specified by the remote peer IP address and the pseudowire
VCID:
debug condition xconnect peer 10.0.0.1 vcid 100
The following example sets filter conditions that allow related debug commands to display debug
messages for only the xconnect segment pair specified by the serial interface number and DLCI:
debug condition xconnect interface serial 0/0 100
messages for only the xconnect segment pair specified by the port mode ATM interface number:
debug condition xconnect interface atm 0/0
messages for only the xconnect segment pair specified by the VP mode ATM interface number:
debug condition xconnect interface atm 0/0 vp 1
messages for only the xconnect segment pair specified by the VC mode ATM interface number:
debug condition xconnect interface atm 0/0 vc 1/40
The following example finds the segment ID associated with an L2TPv3 xconnect segment pair and sets
filter conditions that allow related debug commands to display debug messages for only that xconnect
segment pair:
Router# show ssm id
!
Segment-ID: 8193 Type: L2TPv3[8]
!
Router# debug conditional xconnect segment 8193

debug acircuit Displays errors and events that occur on the attachment circuits.
debug sss aaa Displays messages about AAA authorization events that are part of normal
authorization event call establishment.
debug sss aaa Displays information about AAA authorization state changes.
authorization fsm

May 2008 DB-397
Debug Commands
Command Description
debug sss error Displays diagnostic information about errors that may occur during SSS call
setup.
debug sss event Displays diagnostic information about SSS call setup events.
debug sss fsm Displays diagnostic information about the SSS call setup state.
debug xconnect Displays debug messages related to an xconnect configuration.
show ssm id Displays SSM information for switched Layer 2 segments.

DB-398 May 2008
Debug Commands
debug condition
debug condition
To filter debugging output for certain debug commands on the basis of specified conditions, use the
debug condition command in privileged EXEC mode. To remove the specified condition, use the no
debug condition {called dial-string | caller dial-string | calling tid/imsi string | domain
domain-name | ip ip-address | mac-address hexadecimal-MAC-address | portbundle ip
ip-address bundle bundle-number | session-id session-number | username username | vcid
vc-id}
no debug condition {condition-id | all}
Syntax Description called dial-string Filters output on the basis of the called party number.
caller dial-string Filters output on the basis of the calling party number.
calling tid/imsi string Filters debug messages for general packet radio service (GPRS)
tunneling protocol (GTP) processing on the gateway GPRS support node
(GGSN) based on the tunnel identifier (TID) or international mobile
system identifier (IMSI) in a Packet Data Protocol (PDP) Context Create
Request message.
domain domain-name Filters output on the basis of the specified domain.
ip ip-address Filters output on the basis of the specified IP address.
mac-address Filters messages on the specified MAC address.
hexadecimal-MAC-address
portbundle ip IP-address Filters output on the basis of the port-bundle host key (PBHK) that
uniquely identifies the session.
bundle bundle-number Specifies the port bundle.
session-id session-number Filters output on the specified Intelligent Service Architecture (ISA)
session identifier.
username username Filters output on the basis of the specified username.
vcid vc-id Filters output on the basis of the specified VC ID.
condition-id Removes the condition indicated.
all Removes all debugging conditions, and conditions specified by the
debug condition interface command. Use this keyword to disable
conditional debugging and reenable debugging for all interfaces.
Defaults All debugging messages for enabled protocol-specific debug commands are generated.

May 2008 DB-399
Debug Commands
debug condition

11.3(2)AA This command was introduced.
This command was updated with the vcid and ip keywords to
support the debugging of Any Transport over MPLS (AToM)
messages.
12.2(15)T This command was integrated into Cisco IOS Relese 12.2(15)T.
12.3(2)XB This command was introduced on the GGSN.
12.3(8)T The calling keyword and tid/imsi string argument were added.
12.2(28)SB The ability to filter output on the following conditions was added:
domain, MAC address, PBHK, and ISA session ID.
12.2(33)SRA.
Usage Guidelines Use the debug condition command to restrict the debug output for some commands. If any debug
condition commands are enabled, output is generated only for interfaces associated with the specified
keyword. In addition, this command enables debugging output for conditional debugging events.
Messages are displayed as different interfaces meet specific conditions.
If multiple debug condition commands are enabled, output is displayed if at least one condition
matches. All the conditions do not need to match.
The no form of this command removes the debug condition specified by the condition identifier. The
condition identifier is displayed after you use a debug condition command or in the output of the show
debug condition command. If the last condition is removed, debugging output resumes for all interfaces.
You will be asked for confirmation before removing the last condition or all conditions.
Not all debugging output is affected by the debug condition command. Some commands generate output
whenever they are enabled, regardless of whether they meet any conditions.
The following components are supported for Intelligent Service Architecture (ISA) distributed
conditional debugging:
Authentication, authorization, and accounting (AAA) and RADIUS
ATM components
Feature Manager
Policy Manager
PPP
PPP over Ethernet (PPPoE)
Session Manager
Virtual Private Dialup Network (VPDN)

DB-400 May 2008
Debug Commands
debug condition
Ensure that you enable TID/IMSI-based conditional debugging by entering debug condition calling
before configuring debug gprs gtp and debug gprs charging. In addition, ensure that you disable the
debug gprs gtp and debug gprs charging commands using the no debug all command before disabling
conditional debugging using the no debug condition command. This will prevent a flood of debugging
messages when you disable conditional debugging.
Examples Example 1
In the following example, the router displays debugging messages only for interfaces that use a username
of user1. The condition identifier displayed after the command is entered identifies this particular
condition.
Router# debug condition username user1
Condition 1 set
Example 2
The following example specifies that the router should display debugging messages only for VC 1000:
Router# debug condition vcid 1000
Condition 1 set
01:12:32: 1000 Debug: Condition 1, vcid 1000 triggered, count 1
01:12:32: 1000 Debug: Condition 1, vcid 1000 triggered, count 1
The following example enables other debugging commands. These debugging commands will only
display information for VC 1000.
Router# debug mpls l2transport vc event
AToM vc event debugging is on
Router# debug mpls l2transport vc fsm
AToM vc fsm debugging is on
The following commands shut down the interface on which VC 1000 is established.
Router(config)# interface s3/1/0
Router(config-if)# shut
The debugging output shows the change to the interface where VC 1000 is established.
01:15:59: AToM MGR [13.13.13.13, 1000]: Event local down, state changed from established
to remote ready
01:15:59: AToM MGR [13.13.13.13, 1000]: Local end down, vc is down
01:15:59: AToM SMGR [13.13.13.13, 1000]: Processing imposition update, vc_handle 6227BCF0,
update_action 0, remote_vc_label 18
01:15:59: AToM SMGR [13.13.13.13, 1000]: Imposition Disabled
01:15:59: AToM SMGR [13.13.13.13, 1000]: Processing disposition update, vc_handle
6227BCF0, update_action 0, local_vc_label 755
01:16:01:%LINK-5-CHANGED: Interface Serial3/1/0, changed state to administratively down
01:16:02:%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/1/0, changed state to
down

debug condition interface Limits output for some debugging commands based on the
interfaces.

May 2008 DB-401
Debug Commands
debug configuration lock

To enable debugging of the Cisco IOS configuration lock, use the debug configuration lock command
no debug command lock

Examples The following is sample output with debug configuration lock enabled (assuming that the feature is
enabled using the configuration mode exclusive manual command in global configuration mode):
Router# debug configuration lock
Session1 from console

==========================
Router# configure terminal lock

Configuration mode locked exclusively. The lock will be cleared once you exit out of
configuration mode using end/exit
Router(config)#
Parser : LOCK REQUEST in EXCLUSIVE mode
Parser: <configure terminal lock> - Config. Lock requested by process <3> client <PARSER
Client>
Parser: <configure terminal lock> - Config. Lock acquired successfully !
Router(config)#
Session2 VTY (User from session2 is trying to enter single user config (exclusive) config
mode)
=================================
Router# configure terminal lock

Configuration mode locked exclusively by user 'unknown' process '3' from terminal '0'.
Please try later.
Router#

DB-402 May 2008
Debug Commands
Session1 from console

=======================
Router(config)#
Parser : LOCK REQUEST in EXCLUSIVE mode
Parser: <configure terminal lock> - Config. Lock requested by process <104> client <PARSER
Client>
Parser: <configure terminal lock> - NON_BLOCKING : Config mode locked <EXCLUSIVE> owner
<3>
Router(config)#
Router(config)# end
Router#
%SYS-5-CONFIG_I: Configured from console by console
Parser: <Configure terminal> - Config. EXC UnLock requested by user<3>
Parser: <Configure terminal> - Config UNLOCKED !
Router#

configuration mode exclusive Enables single-user (exclusive) access functionality for the
Cisco IOS CLI.
show configuration lock Displays information about the lock status of the running
configuration file during a configuration replace operation.

May 2008 DB-403
Debug Commands
debug confmodem
debug confmodem
To display information associated with the discovery and configuration of the modem attached to the
router, use the debug confmodem command in privileged EXEC mode. To disable debugging output,
debug confmodem
no debug confmodem
Usage Guidelines The debug confmodem command is used in debugging configurations that use the modem autoconfig
command.
Examples The following is sample output from the debug confmodem command. In the first three lines, the router
is searching for a speed at which it can communicate with the modem. The remaining lines show the
actual sending of the modem command.
Router# debug confmodem
TTY4:detection speed(115200) response ------

TTY4:detection speed(57600) response ------
TTY4:detection speed(38400) response ---OK---
TTY4:Modem command: --AT&F&C1&D2S180=3S190=1S0=1--
TTY4: Modem configuration succeeded
TTY4: Done with modem configuration

DB-404 May 2008
Debug Commands
debug conn
debug conn
To display information from the connection manager, time-division multiplexing (TDM) and digital
signal processor (DSP) clients, use the debug conn command in privileged EXEC mode. To disable
debug conn
no debug conn

12.1(5)XM This command is supported on Cisco 3600 series routers.
12.2(4)T This command is supported on Cisco 2600 series routers and was integrated
into Cisco IOS Release 12.2(4)T.
Examples The following example shows connection manager debugging output:

Router# debug conn
Connection Manager debugging is on
Router(config)# connect conn1 t1 3/0 1 t1 4/0 1
Router(config-tdm-conn)# exit
*Mar 6 18:30:59:%CONN TDM:Segment attached to dsx1

*Mar 6 18:30:59:%CONN TDM:Parsed segment 1
*Mar 6 18:30:59:%CONN TDM:Segment attached to dsx1
*Mar 6 18:30:59:%CONN TDM:Parsed segment 2
*Mar 6 18:30:59:%CONN:Creating new connection

May 2008 DB-405
Debug Commands
debug conn
Router(config)#
*Mar 6 18:31:01:%CONN TDM:Interwork Segments
*Mar 6 18:31:01:CONN TDM:Init Segment @ 61C26980
*Mar 6 18:31:01:CONN TDM:Init Segment @ 61C26A44
*Mar 6 18:31:01:%CONN TDM:Activating Segment @ 61C26980
*Mar 6 18:31:01:%CONN:Segment alarms for conn conn1 are 2
*Mar 6 18:31:01:%CONN TDM:Activating Segment @ 61C26A44
*Mar 6 18:31:01:%CONN:Segment alarms for conn conn1 are 0
*Mar 6 18:31:01:%CONN TDM:Connecting Segments
*Mar 6 18:31:01:%CONN TDM:MAKING CONNECTION
*Mar 6 18:31:01:%CONN:cm_activate_connection, stat = 5
Router(config)#

DB-406 May 2008
Debug Commands
debug control-plane
debug control-plane
To display debugging output from the control-plane routines, use the debug control plane command in
debug control-plane [all | host | port-filtering | queue-thresholding | log]
no debug control-plane [all | host | port-filtering | queue-thresholding | log]
Syntax Description all (Optional) Displays all events on all control-plane interfaces.
host (Optional) Displays all events on the control-plane host interface.
port-filtering (Optional) Displays TCP/IP protocol port-filtering events.
queue-thresholding (Optional) Displays TCP/IP protocol queue-thresholding events.
log (Optional) Displays control-plane logging events.
Command Default The default is debugging off.
Command History Release Moditication

12.4(6)T The log keyword was added to support control plane logging.
Usage Guidelines Use the debug control plane command if you want to display the debugging output from the
control-plane routines.
Examples The following example show a display from the debug control-plane command:
Router# debug control-plane
Control-plane infrastructure events debugging is on
Router# cp_receive_classify - marking pak host
ingress pak marked cef-exception
The following example shows a display from the debug control-plane command using the port-filtering
option:
Router# debug control-plane port-filtering
TCP/IP Port filtering events debugging is on
Dropped UDP dport 1243 sport 62134 saddr 209.165.200.225

May 2008 DB-407
Debug Commands
debug control-plane
Table 57 debug control plane field descriptions
Field Description
dport UPD destination port.
sport UPD source port.
saddr Source address of the IP packets.

clear control-plane Clears packet counters for control-plane interfaces and subinterfaces.
control-plane Enters control-plane configuration mode, which allows users to associate or
modify attributes or parameters that are associated with the control plane of
the device.
show control-plane Displays the control plane packet counters for the control plane
cef-exception counters CEF-exception subinterface.
show control-plane Displays the configured features for the control plane CEF-exception
cef-exception features subinterface.
show control-plane Displays the control-plane packet counters for the aggregate control-plane
counters interface.
show control-plane Displays the configured features for the aggregate control-plane interface.
features
show control-plane Displays the control plane packet counters for the control plane host
host counters subinterface.
show control-plane Displays the configured features for the control plane host subinterface.
host features
show control-plane Displays a list of open TCP/UDP ports that are registered with the port-filter
host open-ports database.
show control-plane Displays the control plane packet counters for the control plane transit
transit counters subinterface.

DB-408 May 2008
Debug Commands
debug cops
debug cops
To display a one-line summary of each Common Open Policy Service (COPS) message sent from and
received by the router, use the debug cops command in privileged EXEC mode. To disable debugging
debug cops [detail]
no debug cops [detail]
Syntax Description detail (Optional) Displays additional debug information, including the contents of
COPS and Resource Reservation Protocol (RSVP) messages.
Defaults COPS process debugging is not enabled.

Usage Guidelines To generate a complete record of the policy process, enter this command and, after entering a carriage
return, enter the additional command debug ip rsvp policy.
Examples This first example displays the one-line COPS message summaries, as the router goes through six
different events.
Router# debug cops
COPS debugging is on
Event 1
The router becomes configured to communicate with a policy server:
Router(config)# ip rsvp policy cops servers 2.0.0.1
Router(config)#
15:13:45:COPS: Opened TCP connection to 2.0.0.1/3288

May 2008 DB-409
Debug Commands
debug cops
15:13:45:COPS: ** SENDING MESSAGE **

15:13:45:COPS OPN message, Client-type:1, Length:28. Handle:[NONE]
15:13:45:COPS: ** RECEIVED MESSAGE **
15:13:45:COPS CAT message, Client-type:1, Length:16. Handle:[NONE]
Router(config)#
Event 2
The router receives a Path message:
15:13:53:COPS:** SENDING MESSAGE **
15:13:53:COPS REQ message, Client-type:1, Length:216. Handle:[ 00 00 04 01]
15:13:53:COPS:** RECEIVED MESSAGE **
15:13:53:COPS DEC message, Client-type:1, Length:104. Handle:[ 00 00 04 01]
Router(config)#
Event 3
The router receives a unicast FF Resv message:
15:14:00:COPS REQ message, Client-type:1, Length:148. Handle:[ 00 00 05 01]
15:14:00:COPS DEC message, Client-type:1, Length:64. Handle:[ 00 00 05 01]
15:14:00:COPS RPT message, Client-type:1, Length:24. Handle:[ 00 00 05 01]
Router(config)#
Event 4
The router receives a Resv tear:
15:14:06:COPS DRQ message, Client-type:1, Length:24. Handle:[ 00 00 05 01]
Router(config)#
Event 5
The router receives a Path tear:
15:14:11:COPS DRQ message, Client-type:1, Length:24. Handle:[ 00 00 04 01]
Router(config)#
Event 6
The router gets configured to cease communicating with the policy server:
Router(config)# no ip rsvp policy cops servers

15:14:23:COPS CC message, Client-type:1, Length:16. Handle:[NONE]
15:14:23:COPS:Closed TCP connection to 2.0.0.1/3288
Router(config)#

DB-410 May 2008
Debug Commands
debug cops
This second example uses the detail keyword to display the contents of the COPS and RSVP messages,
and additional debugging information:
Router# debug cops detail

COPS HEADER:Version 1, Flags 0, Opcode 1 (REQ), Client-type:1, Length:216
HANDLE (1/1) object. Length:8. 00 00 21 01
CONTEXT (2/1) object. Length:8. R-type:5. M-type:1
IN_IF (3/1) object. Length:12. Address:10.1.2.1. If_index:4
OUT_IF (4/1) object. Length:12. Address:10.33.0.1. If_index:3
CLIENT SI (9/1) object. Length:168. CSI data:
02:13:29: SESSION type 1 length 12:
02:13:29: Destination 10.33.0.1, Protocol_Id 17, Don't Police , DstPort 44
02:13:29: HOP type 1 length 12:0A010201
02:13:29: :00000000
02:13:29: TIME_VALUES type 1 length 8 :00007530
02:13:29: SENDER_TEMPLATE type 1 length 12:
02:13:29: Source 10.31.0.1, udp_source_port 44
02:13:29: SENDER_TSPEC type 2 length 36:
02:13:29: version=0, length in words=7
02:13:29: Token bucket fragment (service_id=1, length=6 words
02:13:29: parameter id=127, flags=0, parameter length=5
02:13:29: average rate=1250 bytes/sec, burst depth=10000 bytes
02:13:29: peak rate =1250000 bytes/sec
02:13:29: min unit=0 bytes, max unit=1514 bytes
02:13:29: ADSPEC type 2 length 84:
02:13:29: version=0 length in words=19
02:13:29: General Parameters break bit=0 service length=8
02:13:29: IS Hops:1
02:13:29: Minimum Path Bandwidth (bytes/sec):1250000
02:13:29: Path Latency (microseconds):0
02:13:29: Path MTU:1500
02:13:29: Guaranteed Service break bit=0 service length=8
02:13:29: Path Delay (microseconds):192000
02:13:29: Path Jitter (microseconds):1200
02:13:29: Path delay since shaping (microseconds):192000
02:13:29: Path Jitter since shaping (microseconds):1200
02:13:29: Controlled Load Service break bit=0 service length=0
02:13:29:COPS:Sent 216 bytes on socket,
02:13:29:COPS:Message event!
02:13:29:COPS:State of TCP is 4
02:13:29:In read function
02:13:29:COPS:Read block of 96 bytes, num=104 (len=104)
COPS HEADER:Version 1, Flags 1, Opcode 2 (DEC), Client-type:1, Length:104
DECISION (6/1) object. Length:8. COMMAND cmd:1, flags:0
DECISION (6/3) object. Length:56. REPLACEMENT 00 10 0E 01 61 62 63 64 65 66 67
68 69 6A 6B 6C 00 24 0C 02 00
00 00 07 01 00 00 06 7F 00 00 05 44 9C 40 00 46 1C 40 00 49 98
96 80 00 00 00 C8 00 00 01 C8
02:13:29:Notifying client (callback code 2)

COPS HEADER:Version 1, Flags 1, Opcode 3 (RPT), Client-type:1, Length:24
REPORT (12/1) object. Length:8. REPORT type COMMIT (1)

May 2008 DB-411
Debug Commands
debug cops

02:13:29:Timer for connection entry is zero
To see an example where the debug cops command is used along with the debug ip rsvp policy
command, refer to the second example of the debug ip rsvp policy command.

debug ip rsvp policy Displays debugging messages for RSVP policy processing.

DB-412 May 2008
Debug Commands
debug cot
debug cot
To display information about the Continuity Test (COT) functionality, use the debug cot command in
debug cot {api | dsp | queue | detail}
no debug cot {api | dsp | queue | detail}
Syntax Description api Displays information about the COT application programming interface
(API).
dsp Displays information related to the COT/Digital Signal Processor
configuration (DSP) interface. Typical DSP functions include data modems,
voice codecs, fax modems and codecs, and low-level signaling such as
channel-associated signaling (CAS)/R2.
queue Display information related to the COT internal queue.
detail Display information about COT internal detail; summary of the debug cot
api, debug cot dsp, and debug cot queue commands.

Examples The following is sample output from the debug cot api command:
Router# debug cot api
COT API debugging is on

08:29:55: cot_request_handler(): CDB@0x60DEDE14, req(COT_CHECK_TONE_ON):
08:29:55: shelf 0 slot 0 appl_no 1 ds0 1
08:29:55: freqTX 2010 freqRX 1780 key 0xFFF1 duration 60000
Table 58 debug cot api Field Descriptions
Field Description
CDB Internal controller information.
req Type of COT operation requested.

May 2008 DB-413
Debug Commands
debug cot
Table 58 debug cot api Field Descriptions (continued)
Field Description
shelf Shelf ID of the COT operation request.
slot Designates the slot number, 1 to 4.
appl-no Hardware unit that provides the external interface connections from a router
to the network.
ds0 Number of the COT operation request.
key COT operation identifier.
duration Timeout duration of the COT operation.
freqTX Requested transmit tone frequency.
freqRX Requested receive tone frequency.
The following is sample output from the debug cot dsp command:
Router# debug cot dsp
Router#
00:10:42:COT:DSP (1/1) Allocated
00:10:43:In cot_callback
00:10:43: returned key 0xFFF1, status = 0
00:10:43:COT:Received DSP Q Event
00:10:43:COT:DSP (1/1) Done
00:10:43:COT:DSP (1/1) De-allocated
Table 59 debug cot dsp Field Descriptions
Field Description
DSP (1/1) Allocated Slot and port of the DSP allocated for the COT operation.
Received DSP Q Event Indicates the COT subsystem received an event from the DSP.
DSP (1/1) Done Slot and port of the DSP transitioning to IDLE state.
DSP (1/1) De-allocated Slot and port of the DSP de-allocated after the completion of the COT
operation.
The following is sample output from the debug cot queue command:
Router# debug cot queue
Router#
00:11:26:COT(0x60EBB48C):Adding new request (0x61123DBC) to In
Progress Q
00:11:26:COT(0x60EBB48C):Adding COT(0x61123DBC) to the Q head

DB-414 May 2008
Debug Commands
debug cot
Table 60 debug cot api Field Descriptions
Field Description
COT Internal COT operation request.
Adding new request Internal COT operation request queue.
The following is sample output from the debug cot detail command.
Router# debug cot detail
Router#
00:04:57:cot_request_handler():CDB@0x60EBB48C, req(COT_CHECK_TONE_ON):

00:04:57: freqTX 1780 freqRX 2010 key 0xFFF1 duration 1000
00:04:57:COT:DSP (1/0) Allocated

00:04:57:COT:Request Transition to COT_WAIT_TD_ON
00:04:57:COT(0x60EBB48C):Adding new request (0x61123DBC) to In
Progress Q
00:04:57:COT(0x60EBB48C):Adding COT(0x61123DBC) to the Q head
00:04:57:COT:Start Duration Timer for Check Tone Request
00:04:58:COT:Received Timer Event
00:04:58:COT:T24 Timer Expired
00:04:58:COT Request@ 0x61123DBC, CDB@ 0x60EBB48C, Params@0x61123E08
00:04:58: request type = COT_CHECK_TONE_ON
00:04:58: duration 1000 key FFF1 freqTx 1780 freqRx 2010
00:04:58: state COT_WAIT_TD_ON_CT
00:04:58: event_proc(0x6093B55C)
00:04:58:Invoke NI2 callback to inform COT request status

00:04:58:Return from NI2 callback
00:04:58:COT:Request Transition to IDLE
00:04:58:COT:Received DSP Q Event
00:04:58:COT:DSP (1/0) Done
00:04:58:COT:DSP (1/0) De-allocated
Because the debug cot detail command is a summary of the debug cot api, debug cot dsp, and debug
cot queue commands, the field descriptions are the same.

May 2008 DB-415
Debug Commands
debug cpp event
debug cpp event

Note Effective with Release 12.3(4)T, the debug cpp event command is no longer available in Cisco IOS
12.3(T) releases.
To display general Combinet Proprietary Protocol (CPP) events, use the debug cpp event command in
privileged EXEC mode. The no form of this command disables debugging output.
debug cpp event
no debug cpp event

12.3(4)T This command is no longer available in Cisco IOS 12.(3)T releases.
Usage Guidelines CPP allows a router to engage in negotiation over an ISDN B channel to establish connections with a
Combinet bridge.
The debug cpp event command displays events such as CPP sequencing, group creation, and keepalives.
Examples One or more of the messages in Table 61 appear when you use the debug cpp event command. Each
message begins with the short name of the interface the event occurred on (for example, SERIAL0:1 or
BRI0:1) and might contain one or more packet sequence numbers or remote site names.
Table 61 debug cpp event Messages
Message Description
BRI0:1: negotiation complete Call was set up on the interface (in this example, BRI0:1).
BRI0:1: negotiation timed out Call timed out.
BRI0:1: sending negotiation packet Negotiation packet was sent to set up the call.
BRI0:1: out of sequence packet - got 10, Packet was received that was out of sequence. The first
range 1 8 number displayed in the message is the sequence number
received, and the following numbers are the range of valid
sequence numbers.

DB-416 May 2008
Debug Commands
debug cpp event
Table 61 debug cpp event Messages (continued)
Message Description
BRI0:1: Sequence timer expired - Timer expired before the packet was received. The first
Lost 11 Trying sequence 12 number displayed in the message is the sequence number
of the packet that was lost, and the second number is the
next sequence number.
BRI0:1: Line Integrity Violation Router fails to maintain keepalives.
BRI0:1: create cpp group ber19 Dialer group is created on the remote site (in this example,
destroyed cpp group ber19 ber19).

debug cpp negotiation Displays CPP negotiation events.
debug cpp packet Displays CPP packets.

May 2008 DB-417
Debug Commands
debug cpp negotiation

Note Effective with Release 12.3(4)T, the debug cpp negotiation command is no longer available in
Cisco IOS 12.3T releases.
To display Combinet Proprietary Protocol (CPP) negotiation events, use the debug cpp negotiation
command in privileged EXEC mode. The no form of this command disables debugging output.
no debug cpp negotiation

12.3(4)T This command is no longer available in Cisco IOS 12.3T releases.
Combinet bridge.
The debug cpp negotiation command displays events such as the type of packet and packet size being
sent.
Examples The following is sample output from the debug cpp negotiation command. In this example, a sample
connection is shown.
Router# debug cpp negotiation
%LINK-3-UPDOWN: Interface BRI0: B-Channel 2, changed state to down

%LINK-3-UPDOWN: Interface BRI0, changed state to up
BR0:1:(I) NEG packet - len 77
attempting proto:2
ether id:0040.f902.c7b4
port 1 number:5559876
port 2 number:5559876
origination port:1
remote name:berl9
password is correct
Table 62 describes the significant fields in the display.

DB-418 May 2008
Debug Commands
Table 62 debug CPP negotiation Field Descriptions
Field Description
BR0:1 (I) NEG packet - len 77 Interface name, packet type, and packet size.
attempting proto: CPP protocol type.
ether id: Ethernet address of the destination router.
port 1 number: ISDN phone number of remote B channel #1.
port 2 number: ISDN phone number of remote B channel #2.
origination port: B channel 1 or 2 called.
remote name: Remote site name to which this call is connecting.
password is correct Password is accepted so the connection is established.

debug cot Displays information about the COT functionality.
debug cpp packet Displays CPP packets.

May 2008 DB-419
Debug Commands
debug cpp packet
debug cpp packet

Note Effective with Release 12.3(4)T, the debug cpp packet command is no longer available in Cisco IOS
12.3T Releases.
To display Combinet Proprietary Protocol (CPP) packets, use the debug cpp packet command in
privileged EXEC mode. The no form of this command disables debugging output.
debug cpp packet
no debug cpp packet

12.3(4)T This command is no longer available in Cisco IOS 12.3T releases.
Combinet bridge.
The debug cpp packet command displays the hexadecimal values of the packets.
Examples The following is sample output from the debug cpp packet command. This example shows the interface
name, packet type, packet size, and the hexadecimal values of the packet.
Router# debug cpp packet
BR0:1:input packet - len 60

00 00 00 00 00 00 00 40 F9 02 C7 B4 08 0.!6 00 01
08 00 06 04 00 02 00 40 F9 02 C7 B4 83 6C A1 02!!!
BR0:1 output packet - len 116
06 00 00 40 F9 02 C7 B4 00 00 0C 3E 12 3A 08 00
45 00 00 64 00 01 00 00 FF 01 72 BB 83 6C A1 01

debug cot Displays information about the COT functionality.
debug cpp negotiation Displays CPP negotiation events.

DB-420 May 2008
Debug Commands
debug credentials
debug credentials
To set debugging on the credentials service that runs between the Cisco Unified CME CTL provider and
CTL client or between the Cisco Unified SRST router and Cisco Unified CallManager, use the debug
credentials command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug credentials
no debug credentials

12.3(14)T This command was introduced for Cisco Unified SRST.
12.4(4)XC This command was introduced for Cisco Unified CME.
12.4(9)T This command was integrated into Cisco IOS Release 12.4(9)T for
Cisco Unified CME.
Usage Guidelines Cisco Unified CME

Use this command with Cisco Unified CME phone authentication to monitor a CTL provider as it
provides credentials to the CTL client.
Cisco Unified SRST

Use this command to monitor Cisco Unified CallManager while it requests certificates from the
Cisco Unified SRST router. It sets debugging on the credentials service that runs between the SRST
router and Cisco Unified CallManager
Examples Cisco Unified CME

The following sample output displays the CTL provider establishing a TLS session with the CTL client
and providing all the relevant credentials for the services that are running on this router to the CTL client.
Router# debug credentials
Credentials server debugging is enabled
May 25 12:08:17.944: Credentials service: Start TLS Handshake 1 10.5.43.174 4374

May 25 12:08:17.948: Credentials service: TLS Handshake returns OPSSLReadWouldBlockErr

May 2008 DB-421
Debug Commands
debug credentials
May 25 12:08:20.964: Credentials service: TLS Handshake completes
Cisco Unified SRST

The following is sample output showing the credentials service that runs between the
Cisco Unified SRST router and Cisco Unified CallManager. The credentials service provides
Cisco Unified CallManager with the certificate from the SRST router.
Router# debug credentials
Credentials server debugging is enabled

Router#
May 25 12:08:17.944: Credentials service: Start TLS Handshake 1 10.5.43.174 4374
May 25 12:08:20.964: Credentials service: TLS Handshake completes
Table 63 debug credentials Field Descriptions
Field Description
Start TLS Handshake 1 Indicates the beginning of the TLS handshake between the secure
10.5.43.174 4374 Cisco Unified SRST router and Cisco Unified CallManager. In this
example, 1 indicates the socket, 10.5.43.174 is the IP address, and 4374
is the port of Cisco Unified CallManager.
TLS Handshake returns Indicates that the handshake is in process.
OPSSLReadWouldBlockErr
TLS Handshake completes Indicates that the TLS handshake has finished and that the
Cisco Unified CallManager has received the secure Cisco Unified SRST
device certificate.

credentials Enters credentials configuration mode to configure a
Cisco Unified CME CTL provider certificate or a
Cisco Unified SRST router certificate.
ctl-service admin Specifies a user name and password to authenticate the CTL client
during the CTL protocol.
ip source-address Enables the Cisco Unified CME or SRST router to receive
(credentials) messages through the specified IP address and port.
show credentials Displays the credentials settings on a Cisco Unified CME or
SRST router.
show debugging Displays information about the types of debugging that are
enabled for your router.
trustpoint (credentials) Specifies the name of the trustpoint to be associated with a
Cisco Unified CME CTL provider certificate or with a
Cisco Unified SRST router certificate.

DB-422 May 2008
Debug Commands
debug crm
debug crm
To troubleshoot the Carrier Resource Manager (CRM), use the debug crm command in privileged EXEC
debug crm [all | default | detail | error [call [informational] | software [informational]] |
function | inout]
no debug crm
Syntax Description all (Optional) Displays all CRM debugging messages.

default (Optional) Displays detail, error, and inout information. This option also
runs if no keywords are added.
detail (Optional) Displays non-inout information related to call processing, such as
call updates or call acceptance checking.
error (Optional) Displays CRM error messages.
call (Optional) Displays call processing errors.
informational (Optional) Displays minor errors and major errors. Without the
informational keyword, only major errors are displayed.
software (Optional) Displays software errors.
function (Optional) Displays CRM function names and exit points from each function
so that call processing can be traced within the CRM subsystem.
inout (Optional) Displays information from the functions that form the external
interfaces of CRM to other modules or subsystems.
Defaults Debugging is not enabled.

12.3(8)T The all, default, detail, error, call, informational, software, function, and
inout keywords were added.
Usage Guidelines Disable console logging and use buffered logging before using the debug crm command. Using the
debug crm command generates a large volume of debugs, which can affect router performance.

May 2008 DB-423
Debug Commands
debug crm
Examples The following is sample output from the debug crm all command for an incoming ISDN call on a trunk
group:
Router# debug crm all
01:21:23: //-1/xxxxxxxxxxxx/CRM/crm_send_periodic_update:
01:21:23: //-1/xxxxxxxxxxxx/CRM/print_event:
RouteLabel=2023, CarrierType=TDM, EventType=Single RouteLabel Update, EventReason=Both
Capacity Update,
Max Capacity mask 0x0000001F, Current Capacity Mask 0x0000001F
01:21:23: //-1/xxxxxxxxxxxx/CRM/crm_call_update:
Increment the call count
CarrierID=2023, TrunkGroupLabel=2023
Update is for TrunkGroupLabel, Mask=0x00000001
IncomingVoiceCalls=1
Router#
Capacity Update,
Capacity Update,
Router#
Decrement the call count
CarrierID=2023, TrunkGroupLabel=2023
Update is for TrunkGroupLabel, Mask=0x00000001
IncomingVoiceCalls=0
Table 64 debug crm all Field Descriptions
Field Description
//-1/xxxxxxxxxxxx/CRM/print_event: The format of this message is
//callid/GUID/CRM/function name:
CallEntry ID is -1. This indicates that the CallEntry ID is
unavailable.
GUID is xxxxxxxxxxxxxxxxx. This indicates that the
GUID is unavailable.
CRM is the module name.
The print_event: field shows that the CRM is showing the
print event function.
RouteLabel Either the trunk group label or carrier ID.
CarrierType Indicates the type of trunk.
EventType Indicates if a single route or all routes are updated.
EventReason Shows the reason for this event being sent.

DB-424 May 2008
Debug Commands
debug crm

max-calls Specifies the maximum number of calls the trunk group can handle.

May 2008 DB-425
Debug Commands
debug crypto ace b2b

To enable IPSec VPN SPA debugging for a Blade Failure Group, use the debug crypto ace b2b
command in privileged EXEC mode.

12.2(18)SXE2 This command was introduced.
Examples The following example enables IPSec VPN SPA debugging for a Blade Failure Group:
Router# debug crypto ace b2b
ACE B2B Failover debugging is on

linecard-group feature Assigns a group ID to a Blade Failure Group.
card
show crypto ace Displays information about a Blade Failure Group.
redundancy
show redundancy Displays the components of a Blade Failure Group.
linecard-group

DB-426 May 2008
Debug Commands
debug crypto condition unmatched

To display crypto conditional debug messages when context information is unavailable to check against
debug conditions, use the debug crypto condition unmatched command in privileged EXEC mode. To
disable debugging, use the no form of this command.
debug crypto condition unmatched [isakmp | ipsec | engine]
no debug crypto condition unmatched [isakmp | ipsec | engine]
Syntax Description isakmp | ipsec | engine (Optional) One or more of these keywords can be enabled to display debug
messages for the specified areas. If none of these keywords are entered,
debug messages for all crypto areas will be shown.
Defaults Debug messages that do not have context information to match any debug conditions (filters) will not be
printed.

12.2(18)SXD This command was integrated into Cisco IOS Release 12.2(18)SXD.
Usage Guidelines After the debug crypto condition command has been enabled, you can use the debug crypto condition
unmatched command to define whether the debug output is being printed when no context information
is available in the code to check against the debug filters. For example, if the crypto engines
connection-ID is the filter that the debug conditions are being checked against, the debug crypto
condition unmatched command displays debug messages in the early negotiation phase when a
connection-ID is unavailable to check against debug conditions.
Examples The following example shows how to enable debug messages for all crypto-related areas:
Router# debug crypto condition unmatched

debug crypto condition Defines conditional debug filters.
show crypto debug-condition Displays crypto debug conditions that have already been
enabled in the router.

May 2008 DB-427
Debug Commands
Command Description
show crypto ipsec sa Displays the settings used by current SAs.
show crypto isakmp sa Displays all current IKE SAs at a peer.

DB-428 May 2008
Debug Commands
debug crypto condition

To define conditional debug filters, use the debug crypto condition command in privileged EXEC
mode. To disable conditional debugging, use the no form of this command.
debug crypto condition [connid integer engine-id integer] [flowid integer engine-id integer]
[gdoi-group groupname] [isakmp profile profile-name] [fvrf string] [ivrf string]
[local ipv4 ip-address] [peer [group string] [hostname string] [ipv4 ipaddress]
[subnet subnet mask] [username string]] [spi integer] [reset] [unmatched [engine]
[gdoi-group] [ipsec] [isakmp] [username string]]
no debug crypto condition [connid integer engine-id integer] [flowid integer engine-id integer]
[gdoi-group groupname] [isakmp profile profile-name] [fvrf string] [ivrf string]
[local ipv4 ip-address] [peer [group string] [hostname string] [ipv4 ipaddress]
[subnet subnet mask] [username string]] [spi integer] [reset] [unmatched [engine]
[gdoi-group] [ipsec] [isakmp] [username string]]
Syntax Description connid integer1 (Optional) Internet Key Exchange (IKE) and IP Security (IPSec)
connection ID filter. Valid values range from 1 to 32766.
engine-id integer (Optional) Crypto engine ID value, which can be retrieved via the show
crypto isakmp sa detail command. Valid values are 1, which
represents software engines, and 2, which represents hardware engines.
flowid integer (Optional) IPSec flow-ID filter. Valid values range from 1 to 32766.
gdoi-group groupname (Optional) Group Domain of Interpretation (GDOI) group filter.
The groupname value is the name of the GDOI group.
isakmp profile profile-name (Optional) Filter for Internet Security Association Key Management
Protocol (ISAKMP) profile.
The profile-name value is the name of the ISAKMP profile to be
filtered.
fvrf string1 (Optional) Front-door virtual private network (VPN) routing and
forwarding (FVRF) filter. The string argument must be the name string
of an FVRF instance.
ivrf string1 (Optional) Inside VRF (IVRF) filter. The string argument must be the
name string of an IVRF instance.
local ipv4 ip-address (Optional) IKE local address filter.
The ip-address value is the IP address of the local crypto endpoint.
1
peer (Optional) IKE peer filter. At least one of the following keywords and
arguments must be used:
group stringUnity group name filter of the IKE peer.
hostname stringFully qualified domain name (FQDN) host
name filter of the IKE peer.
ipv4 ipaddressIP address filter of the IKE peer.
subnet subnet maskRange of IKE peer IP addresses.
username stringFQDN username filter of the IKE peer.

May 2008 DB-429
Debug Commands
spi integer1 (Optional) Security policy index (SPI) filter. The integer must be a
32-bit unsigned integer.
reset (Optional) Deletes all crypto debug filters.
Note It is suggested that you turn off all crypto global debugging
before using this keyword; otherwise, your system may be
flooded with debug messages.
unmatched (Optional) Filters all debug messages or only specified debug messages
by choosing any of the following keywords:
engineOutput crypto engine debugs even if no context available.
gdoi-groupOutput GDOI group debugs even if no match occurs.
ipsecOutput IPsec debugs even if no context available.
isakmpOutput IKE debugs even if no context available.
username string (Optional) XAUTH or PKI-aaa username filter.
1. Additional conditional filters (ipv4 address, subnet mask, username, hostname, group, connection-ID, flow-ID, SPI, FVRF,
and IVRF) can be specified more than once by repeating the debug crypto condition command with any of the available
filters.
Defaults Crypto conditional debugging is not enabled.

12.4(11)T The gdoi-group groupname, isakmp profile profile-name, local ipv4
ip-address, unmatched, and username string keywords and arguments were
added.
12.2SX This command is supported in the Cisco IOS 12.2SX family of releases.
Support in a specific 12.2SX release is dependent on your feature set,
Usage Guidelines Before enabling the debug crypto condition command, you must decide what debug condition types
(also known as debug filters) and values will be used. The volume of debug messages is dependent on
the number of conditions you define.
Note Specifying numerous debug conditions may consume CPU cycles and have a negative effect on router
performance.

DB-430 May 2008
Debug Commands
To begin crypto conditional debugging, you must also enable at least one global crypto debug
commanddebug crypto isakmp, debug crypto ipsec, and debug crypto engine; otherwise,
conditional debugging will not occur. This requirement helps to ensure that the performance of the router
will not be impacted when conditional debugging is not being used.
Note Debug message filtering for hardware crypto engines is not supported.
Examples The following example shows how to display debug messages when the peer IP address is 10.1.1.1,
10.1.1.2, or 10.1.1.3 and when the connection-ID 2000 of crypto engine 0 is used. This example also
shows how to enable global debug crypto CLIs and enable the show crypto debug-condition command
to verify conditional settings.
Router# debug crypto condition connid 2000 engine-id 1
Router# debug crypto condition peer ipv4 10.1.1.1
Router# debug crypto condition unmatched
! Verify crypto conditional settings.
Router# show crypto debug-condition
Crypto conditional debug currently is turned ON

IKE debug context unmatched flag:ON
IPsec debug context unmatched flag:ON
Crypto Engine debug context unmatched flag:ON
IKE peer IP address filters:

10.1.1.1 10.1.1.2 10.1.1.3
Connection-id filters:[connid:engine_id]2000:1,
! Enable global crypto CLIs to start conditional debugging.
Router# debug crypto isakmp
Router# debug crypto ipsec
Router# debug crypto engine
The following example shows how to disable all crypto conditional settings via the reset keyword:
Router# no debug crypto isakmp
Router# no debug crypto ipsec
Router# no debug crypto engine
Router# debug crypto condition reset
! Verify that all crypto conditional settings have been disabled.
Router# show crypto debug-condition
Crypto conditional debug currently is turned OFF

IKE debug context unmatched flag:OFF
IPsec debug context unmatched flag:OFF
Crypto Engine debug context unmatched flag:OFF

May 2008 DB-431
Debug Commands

show crypto debug-condition Displays crypto debug conditions that have already been
enabled in the router.
show crypto debug-condition unmatched Displays crypto conditional debug messages when
context information is unavailable to check against
debug conditions.
show crypto ipsec sa Displays the settings used by current SAs.
show crypto isakmp sa Displays all current IKE SAs at a peer.

DB-432 May 2008
Debug Commands
debug crypto ctcp
debug crypto ctcp

To display information about a Cisco Tunnel Control Protocol (cTCP) session, use the debug crypto
ctcp command in privileged EXEC mode. To turn off debugging, use the no form of this command.
debug crypto ctcp
no debug crypto ctcp
Command Default Debugging is turned off.

Usage Guidelines You can use this command if a cTCP session fails to come up.
Examples The following example shows that debugging has been turned on for a cTCP session:
Router# debug crypto ctcp

crypto ctcp Configures cTCP encapsulation for Easy VPN.

May 2008 DB-433
Debug Commands
debug crypto engine accelerator logs

To enable logging of commands and associated parameters sent from the virtual private network (VPN)
module driver to the VPN module hardware using a debug flag, use the debug crypto engine
accelerator logs command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
no debug crypto engine accelerator logs
Defaults The logging of commands sent from the VPN module driver to the VPN module hardware is disabled.

12.1(1)XC This command was introduced on the Cisco 1720 and Cisco 1750 routers.
Usage Guidelines Use the debug crypto engine accelerator logs command when encryption traffic is sent to the router
and a problem with the encryption module is suspected.
This command is intended only for Cisco TAC personnel to collect debugging information.
Examples The debug crypto engine accelerator logs command uses a debug flag to log commands and associated
parameters sent from the VPN module driver to the VPN module hardware as follows:
Router# debug crypto engine accelerator logs
encryption module logs debugging is on

crypto engine accelerator Enables or disables the crypto engine accelerator if it
exists.
show crypto engine accelerator logs Prints information about the last 32 CGX Library packet
processing commands, and associated parameters sent
from the VPN module driver to the VPN module hardware.

DB-434 May 2008
Debug Commands
Command Description
show crypto engine accelerator Prints active (in-use) entries in the platform-specific VPN
sa-database module database.
show crypto engine configuration Displays the Cisco IOS crypto engine of your router.

May 2008 DB-435
Debug Commands
debug crypto engine
debug crypto engine

To display debugging messages about crypto engines, which perform encryption and decryption, use the
debug crypto engine command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug crypto engine
no debug crypto engine

Usage Guidelines Use the debug crypto engine command to display information pertaining to the crypto engine, such as
when Cisco IOS software is performing encryption or decryption operations.
The crypto engine is the actual mechanism that performs encryption and decryption. A crypto engine
can be software or a hardware accelerator. Some platforms can have multiple crypto engines; therefore,
the router will have multiple hardware accelerators.
Examples The following is sample output from the debug crypto engine command. The first sample output shows
messages from a router that successfully generates Rivest, Shamir, and Adelma (RSA) keys. The second
sample output shows messages from a router that decrypts the RSA key during Internet Key Exchange
(IKE) negotiation.
00:25:13:CryptoEngine0:generate key pair

00:25:13:CryptoEngine0:CRYPTO_GEN_KEY_PAIR
00:25:13:CRYPTO_ENGINE:key process suspended and continued
00:25:14:CRYPTO_ENGINE:key process suspended and continuedcr
00:27:45:%SYS-5-CONFIG_I:Configured from console by console

00:27:51:CryptoEngine0:generate alg parameter
00:27:51:CRYPTO_ENGINE:Dh phase 1 status:0
00:27:51:CRYPTO_ENGINE:Dh phase 1 status:0
00:27:51:CryptoEngine0:generate alg parameter
00:27:52:CryptoEngine0:calculate pkey hmac for conn id 0

DB-436 May 2008
Debug Commands
debug crypto engine
00:27:52:CryptoEngine0:create ISAKMP SKEYID for conn id 1

00:27:52:Crypto engine 0:RSA decrypt with public key
00:27:52:CryptoEngine0:CRYPTO_RSA_PUB_DECRYPT
00:27:52:CryptoEngine0:generate hmac context for conn id 1
00:27:52:Crypto engine 0:RSA encrypt with private key
00:27:52:CryptoEngine0:CRYPTO_RSA_PRIV_ENCRYPT
00:27:53:CryptoEngine0:clear dh number for conn id 1
00:27:53:validate proposal 0
00:27:53:validate proposal request 0
00:27:54:ipsec allocate flow 0
00:27:54:ipsec allocate flow 0

crypto key generate rsa Generates RSA key pairs.

May 2008 DB-437
Debug Commands
debug crypto error
debug crypto error

To enable error debugging for a crypto area, use the debug crypto error command in privileged EXEC
mode. To disable crypto error debugging, use the no form of this command.
debug crypto {isakmp | ipsec | engine} error
no debug crypto {isakmp | ipsec | engine} error
Syntax Description isakmp Debug messages are shown for Internet Key Exchange (IKE)-related error
operations only.
ipsec Debug messages are shown for IP Security (IPSec)-related error operations
only.
engine Debug messages are shown for crypto engine-related error operations only.
Defaults Crypto error debugging is not enabled.

12.2(18)SXD This command was integrated into Cisco IOS Release 12.2(!8)SXD.
Usage Guidelines The debug crypto error command will display only error-related debug messages; that is, an error
debug will not be shown if the operation is functioning properly.
This command should be used when debug conditions cannot be determined; for example, enable this
command when a random, small subset of IKE peers is failing negotiation.
Note The global crypto command-line interfaces (CLIs) (the debug crypto isakmp, debug crypto ipsec, and
debug crypto engine commands) will override the debug crypto error command. Thus, this command
should not be used in conjunction with the global CLIs because you may overwhelm the router.
Note Debug message filtering for crypto hardware engines is not supported.
Examples The following example shows how to enable IPSec-related error messages:

DB-438 May 2008
Debug Commands
debug crypto error
Router# debug crypto error ipsec error

May 2008 DB-439
Debug Commands
debug crypto gdoi
debug crypto gdoi

To display information about a Group Domain of Interpretation (GDOI) configuration, use the debug
crypto gdoi command in privileged EXEC mode. To disable crypto GDOI debugging, use the no form
of this command.
debug crypto gdoi [detail | error | event | gm | infra | ks [coop] | packet | replay | terse]
no debug crypto gdoi [detail | error | event | gm | infra | ks [coop] | packet | replay | terse]
Syntax Description detail (Optional) Displays detailed debug information.

error (Optional) Displays information about error debugs.
event (Optional) Displays user-level information.
gm (Optional) Displays information about group members.
infra (Optional) Displays information about the GDOI infrastructure.
ks (Optional) Displays information about key servers.
coop (Optional) Displays information about cooperative key servers.
packet (Optional) Displays information about packet-level debugs
(administrator-level information).
replay (Optional) Displays information about the pseudotime stamp that is
contained in a packet.
terse (Optional) Displays lowest-level debugs (message-level information).
Note The detail, error, event, packet, and terse keywords can be used with the other nonlevel
keywords (for example, gm error, infra error, ks coop event, replay error).
Command Default Debugging is turned off.

12.4(11)T The detail, error, event, gm, infra, ks, coop, packet, replay, and terse
keywords were added.
Usage Guidelines Using this command displays various GDOI debugs. For debugging information for cooperative key
servers, use the debug crypto gdoi ks coop command.

DB-440 May 2008
Debug Commands
debug crypto gdoi
Examples The following example shows group member registration debug output:
Router# debug crypto gdoi
00:00:40: GDOI:(0:0:N/A:0):GDOI group diffint

00:00:40: %CRYPTO-5-GM_REGSTER: Start registration for group diffint using address
10.0.3.1
00:00:40: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
00:00:40: GDOI:(0:1001:HW:0:3333):beginning GDOI exchange, M-ID of 1167145075
00:00:40: GDOI: Group Number is 3333
00:00:40: GDOI:(0:1001:HW:0:3333):GDOI: GDOI ID sent successfully
00:00:40: GDOI:(0:1001:HW:0:3333):processing GDOI SA Payload, message ID + 1167145075
00:00:40: GDOI:(0:1001:HW:0):processing GDOI SA KEK Payload
00:00:40: GDOI:(0:0:N/A:0): KEK_ALGORITHM 5
00:00:40: GDOI:(0:0:N/A:0): KEY_LENGTH 24
00:00:40: GDOI:(0:0:N/A:0): KEY_LIFETIME 299
00:00:40: GDOI:(0:0:N/A:0): SIG_HASH_ALG 2
00:00:40: GDOI:(0:0:N/A:0): SIG_ALG 1
00:00:40: GDOI:(0:0:N/A:0): SIG_KEY_LEN 94
00:00:40: GDOI:(0:0:N/A:0): Completed KEK Processing
00:00:40: GDOI:(0:1001:HW:0):processing GDOI SA TEK Payload
00:00:40: GDOI:(0:1001:HW:0:3333): Completed TEK Processing
00:00:40: GDOI:(0:1001:HW:0:3333): Completed TEK Processing
00:00:40: GDOI:(0:1001:HW:0:3333):GDOI ACK sent successfully by GM
00:00:40: GDOI:received payload type 18
00:00:40: GDOI:(0:1001:HW:0:3333):processing GDOI Seq Payload, message_id 1167145075
00:00:40: GDOI:(0:1001:HW:0:3333):Completed SEQ Processing for seq 0
00:00:40: GDOI:(0:1001:HW:0:3333):processing GDOI KD Payload, message_id 1167145075
00:00:40: GDOI:(0:1001:HW:0:3333):processing GDOI Key Packet, message_id 38649336
00:00:40: GDOI:(0:1001:HW:0:3333):procesing TEK KD: spi is 56165461, spi
00:00:40: GDOI:(0:1001:HW:0:3333):TEK Integrity Key 20 bytes
00:00:40: GDOI:(0:1001:HW:0:3333):Completed KeyPkt Processing
00:00:40: GDOI:(0:1001:HW:0:3333):procesing TEK KD: spi is 56165522, spi
00:00:40: GDOI:(0:1001:HW:0:3333):TEK Integrity Key 20 bytes
00:00:40: GDOI:(0:1001:HW:0:3333): Processing KEK KD
00:00:40: GDOI:(0:1001:HW:0:3333):KEK Alg Key 32 bytes
00:00:40: GDOI:(0:1001:HW:0:3333):KEK Sig Key 94 bytes
00:00:40: %GDOI-5-GM_REGS_COMPL: Registration complete for group diffint using address
10.0.3.1
enc(config-if)#
00:00:40: GDOI:(0:0:N/A:0):Registration installed 2 new ipsec SA(s) for group diffint.
The following output example shows key server registration debugs:

00:00:40: GDOI:(0:1001:HW:0):processing GDOI ID payload, message ID = 1167145075

00:00:40: GDOI:(0:1001:HW:0):The GDOI ID is a Number: 3333
00:00:40: GDOI:(0:0:N/A:0): Adding KEK Policy to the current ks_group
00:00:40: GDOI:(0:0:N/A:0):Setting MULTICAST TEK rekey lifetime 30
00:00:40: GDOI:(0:0:N/A:0):Setting MULTICAST TEK rekey lifetime 30
00:00:40: GDOI:(0:1001:HW:0:3333):GDOI SA sent successfully by KS
00:00:40: GDOI:(0:1001:HW:0:3333):GDOI KD sent successfully by KS
The following output example shows group member rekey debugs:

May 2008 DB-441
Debug Commands
debug crypto gdoi
00:02:00: GDOI:(0:1002:HW:0):Received Rekey Message!

00:02:00: GDOI:(0:1002:HW:0):Signature Valid!
00:02:00: GDOI:(0:1002:HW:0):processing GDOI Seq Payload, message_id 0
00:02:00: GDOI:(0:1002:HW:0):Completed SEQ Processing for seq 8
00:02:00: GDOI:(0:1002:HW:0):processing GDOI SA Payload, message ID + 0
00:02:00: GDOI:(0:1002:HW:0):processing GDOI SA KEK Payload
00:02:00: GDOI:(0:1002:HW:0): KEK_ALGORITHM 5
00:02:00: GDOI:(0:1002:HW:0): KEY_LENGTH 24
00:02:00: GDOI:(0:1002:HW:0): KEY_LIFETIME 219
00:02:00: GDOI:(0:1002:HW:0): SIG_HASH_ALG 2
00:02:00: GDOI:(0:1002:HW:0): SIG_ALG 1
00:02:00: GDOI:(0:1002:HW:0): Completed KEK Processing
00:02:00: GDOI:(0:1002:HW:0): Completed TEK Processing
00:02:00: GDOI:(0:1002:HW:0): Completed TEK Processing
00:02:00: GDOI:(0:1002:HW:0):processing GDOI KD Payload, message_id 0
00:02:00: GDOI:(0:1002:HW:0):processing GDOI Key Packet, message_id 38649336
00:02:00: GDOI:(0:1002:HW:0):procesing TEK KD: spi is 49193284, spi
00:02:00: GDOI:(0:1002:HW:0):TEK Integrity Key 20 bytes
00:02:00: GDOI:(0:1002:HW:0):Completed KeyPkt Processing
enc(config-if)#
00:02:00: GDOI:(0:1002:HW:0):procesing TEK KD: spi is 49193345, spi
00:02:00: GDOI:(0:1002:HW:0):TEK Integrity Key 20 bytes
00:02:00: GDOI:(0:1002:HW:0): Processing KEK KD

DB-442 May 2008
Debug Commands
debug crypto ha
debug crypto ha
To display crypto high availability debugging information, use the debug crypto ha command in
privileged EXEC mode. To disable debugging messages, use the no form of this command.
debug crypto ha
no debug crypto ha

Examples The following example is sample output from the debug crypto ha command:
Router# debug crypto ha
Active router:
Router# show debug
Cryptographic Subsystem:
Crypto High Availability Manager debugging is on
vrf-lite-R1#
*Sep 28 21:27:50.899:Sending IKE Add SA Message
*Sep 28 21:27:50.899:HA Message 0:flags=0x01 len=394 HA_IKE_MSG_ADD_SA (2)
*Sep 28 21:27:50.899: ID:04000003
*Sep 28 21:27:50.899: attr HA_IKE_ATT_MY_COOKIE (2) len 8
*Sep 28 21:27:50.899: 9B 1A 76 AA 99 11 1A 1F
*Sep 28 21:27:50.899: attr HA_IKE_ATT_HIS_COOKIE (3) len 8
*Sep 28 21:27:50.899: E2 A2 A3 5F 53 1D EA 15
*Sep 28 21:27:50.899: attr HA_IKE_ATT_SRC (4) len 4
*Sep 28 21:27:50.899: 04 00 00 05
*Sep 28 21:27:50.899: attr HA_IKE_ATT_DST (5) len 4
*Sep 28 21:27:50.899: 04 00 00 03
*Sep 28 21:27:50.899: attr HA_IKE_ATT_PEER_PORT (6) len 2
*Sep 28 21:27:50.899: 01 F4
*Sep 28 21:27:50.899: attr HA_IKE_ATT_F_VRF (7) len 1
*Sep 28 21:27:50.899: 00
*Sep 28 21:27:50.899: attr HA_IKE_ATT_INIT_OR_RESP (8) len 1
*Sep 28 21:27:50.899: 00
*Sep 28 21:27:50.899: attr HA_IKE_ATT_NAT_DISCOVERY (9) len 1
*Sep 28 21:27:50.899: 02
*Sep 28 21:27:50.899: attr HA_IKE_ATT_IDTYPE (38) len 1
*Sep 28 21:27:50.899: 01
*Sep 28 21:27:50.899: attr HA_IKE_ATT_PROTOCOL (39) len 1

May 2008 DB-443
Debug Commands
debug crypto ha
*Sep 28 21:27:50.899: 11
*Sep 28 21:27:50.899: attr HA_IKE_ATT_PORT (40) len 2
*Sep 28 21:27:50.899: 01 F4
*Sep 28 21:27:50.899: attr HA_IKE_ATT_ADDR (41) len 4
*Sep 28 21:27:50.899: 04 00 00 05
*Sep 28 21:27:50.899: attr HA_IKE_ATT_MASK (42) len 4
*Sep 28 21:27:50.899: 00 00 00 00
*Sep 28 21:27:50.899: attr HA_IKE_ATT_ID_STR (44) len 4
*Sep 28 21:27:50.899: 00 00 00 00
*Sep 28 21:27:50.899: attr HA_IKE_ATT_PEERS_CAPABILITIES (11) len 4
*Sep 28 21:27:50.899: 00 00 07 7F
*Sep 28 21:27:50.899: attr HA_IKE_ATT_MY_CAPABILITIES (12) len 4
*Sep 28 21:27:50.899: 00 00 07 7F
*Sep 28 21:27:50.899: attr HA_IKE_ATT_STATE_MASK (13) len 4
*Sep 28 21:27:50.899: 00 00 27 FF
.
.
.

debug crypto ipsec ha Enables debugging messages for IPSec high
availability.
debug crypto isakmp ha Enables debugging messages for ISAKMP high
availability.

DB-444 May 2008
Debug Commands
debug crypto ipsec client ezvpn

To display information about voice control messages that have been captured by the Voice DSP Control
Message Logger and about Cisco Easy VPN remote connections, use the debug crypto ipsec client
ezvpn command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
no debug crypto ipsec client ezvpn

12.2(4)YA This command was introduced on Cisco 806, Cisco 826, Cisco 827, and
Cisco 828 routers; Cisco 1700 series routers; and Cisco uBR905 and
Cisco uBR925 cable access routers.
12.3(4)T This command was expanded to support the Easy VPN Remote feature.
Usage Guidelines To force the Voice DSP Contol Message Logger to reestablish the virtual private network (VPN)
connections, use the clear crypto sa and clear crypto isakmp commands to delete the IPSec security
associations and Internet Key Exchange (IKE) connections, respectively.
Examples The following example shows debugging messages when the Voice DSP Contol Message Logger is
turned on and typical debugging messages that appear when the VPN tunnel is created:
Router# debug crypto ipsec client ezvpn
EzVPN debugging is on
router#
00:02:28: EZVPN(hw1): Current State: IPSEC_ACTIVE
00:02:28: EZVPN(hw1): Event: RESET
00:02:28: EZVPN(hw1): ezvpn_close
00:02:28: EZVPN(hw1): New State: CONNECT_REQUIRED
00:02:28: EZVPN(hw1): Current State: CONNECT_REQUIRED

May 2008 DB-445
Debug Commands
00:02:28: EZVPN(hw1): Event: CONNECT

00:02:28: EZVPN(hw1): ezvpn_connect_request
00:02:28: EZVPN(hw1): New State: READY
00:02:29: EZVPN(hw1): Current State: READY
00:02:29: EZVPN(hw1): Event: MODE_CONFIG_REPLY
00:02:29: EZVPN(hw1): ezvpn_mode_config
00:02:29: EZVPN(hw1): ezvpn_parse_mode_config_msg
00:02:29: EZVPN: Attributes sent in message:
00:02:29: Address: 10.0.0.5
00:02:29: Default Domain: cisco.com
00:02:29: EZVPN(hw1): ezvpn_nat_config
00:02:29: EZVPN(hw1): New State: SS_OPEN
00:02:29: EZVPN(hw1): Current State: SS_OPEN
00:02:29: EZVPN(hw1): Event: SOCKET_READY
00:02:29: EZVPN(hw1): No state change
00:02:30: EZVPN(hw1): Event: MTU_CHANGED
00:02:30: EZVPN(hw1): No state change
00:02:30: EZVPN(hw1): Event: SOCKET_UP
00:02:30: ezvpn_socket_up
00:02:30: EZVPN(hw1): New State: IPSEC_ACTIVE
The following example shows the typical display for a VPN tunnel that is reset with the clear crypto
ipsec client ezvpn command:
3d17h: EZVPN: Current State: READY
3d17h: EZVPN: Event: RESET
3d17h: ezvpn_reconnect_request
3d17h: ezvpn_close
3d17h: ezvpn_connect_request
3d17h: EZVPN: New State: READY
3d17h: EZVPN: Current State: READY
3d17h: EZVPN: Event: MODE_CONFIG_REPLY
3d17h: ezvpn_mode_config
3d17h: ezvpn_parse_mode_config_msg
3d17h: EZVPN: Attributes sent in message:
3d17h: DNS Primary: 172.16.0.250
3d17h: DNS Secondary: 172.16.0.251
3d17h: NBMS/WINS Primary: 172.16.0.252
3d17h: NBMS/WINS Secondary: 172.16.0.253
3d17h: Split Tunnel List: 1
3d17h: Address : 172.16.0.128
3d17h: Mask : 255.255.255.128
3d17h: Protocol : 0x0
3d17h: Source Port: 0
3d17h: Dest Port : 0
3d17h: Split Tunnel List: 2
3d17h: Address : 172.16.1.128
3d17h: Mask : 255.255.255.128
3d17h: Protocol : 0x0
3d17h: Source Port: 0
3d17h: Dest Port : 0
3d17h: Default Domain: cisco.com
3d17h: ezvpn_nat_config
3d17h: EZVPN: New State: SS_OPEN
3d17h: EZVPN: Current State: SS_OPEN
3d17h: EZVPN: Event: SOCKET_READY
3d17h: EZVPN: No state change
3d17h: EZVPN: Event: SOCKET_READY
3d17h: EZVPN: Event: MTU_CHANGED

DB-446 May 2008
Debug Commands

3d17h: EZVPN: Event: SOCKET_UP
3d17h: EZVPN: New State: IPSEC_ACTIVE
3d17h: EZVPN: Current State: IPSEC_ACTIVE
3d17h: EZVPN: Event: MTU_CHANGED
3d17h: EZVPN: Current State: IPSEC_ACTIVE
3d17h: EZVPN: Event: SOCKET_UP
The following example shows the typical display for a VPN tunnel that is removed from the interface
with the no crypto ipsec client ezvpn command:
4d16h: EZVPN: Current State: IPSEC ACTIVE
4d16h: EZVPN: Event: REMOVE INTERFACE CFG
4d16h: ezvpn_close_and_remove
4d16h: ezvpn_close
4d16h: ezvpn_remove
4d16h: EZVPN: New State: IDLE

debug crypto ipsec Displays debugging messages for generic IPSec events.
debug crypto isakmp Displays debugging messages for IKE events.

May 2008 DB-447
Debug Commands
debug crypto ipsec ha

To enable debugging messages for IP Security (IPSec) high availability, use the debug crypto ipsec ha
debug crypto ipsec ha [detail] [update]
no debug crypto ipsec ha [detail] [update]

update (Optional) Displays updates for inbound and outbound related data.

Examples The following example is sample output of the debug crypto ipsec ha command for both the active and
stanby router:
Active Router
Router# debug crypto ipsec ha
Crypto IPSEC High Availability debugging is on
*Sep 29 17:03:01.851:IPSec HA (crypto_ha_ipsec_notify_add_sa):called
*Sep 29 17:03:01.851:IPSec HA (crypto_ha_ipsec_notify_add_sa):New IPsec SA added...

notifying HA Mgr
Standby Router
Router# debug crypto ipsec ha
Crypto IPSEC High Availability debugging is on

vrf-lite-R1#
*Sep 29 17:03:01.031:IPSec HA (crypto_ha_ipsec_mgr_recv_add_sas):HA mgr wants to insert
the following bundle
*Sep 29 17:03:01.031:IPSec HA (crypto_ha_ipsec_mgr_recv_add_sas):This SA Supports DPD
*Sep 29 17:03:01.031:IPSec HA (crypto_ha_ipsec_gen_sa):Sending Kei to IPSec num_kei 2
*Sep 29 17:03:01.039:IPSec HA (crypto_ha_ipsec_notify_add_sa):operation not performed as

standby ip 4.0.0.3
The following example is sample debug output with the detail keyword:
Active Router

DB-448 May 2008
Debug Commands
*Sep 29 17:05:48.803:IPSec HA (crypto_ha_ipsec_mgr_set_state_common):called for vip

4.0.0.3
*Sep 29 17:06:11.655:IPSec HA (crypto_ha_ipsec_mgr_bulk_sync_sas):Bulk sync request from

standby for local addr 4.0.0.3
*Sep 29 17:06:44.059:IPSec HA (crypto_ha_ipsec_notify_add_sa):New IPsec SA added...

notifying HA Mgr
Standby Router
Router# debug crypto ipsec ha detail
Crypto IPSEC High Availability Detail debugging is on

vrf-lite-R1#
*Sep 29 17:06:44.063:IPSec HA (crypto_ha_ipsec_mgr_recv_add_sas):HA mgr wants to insert
the following bundle
*Sep 29 17:06:44.063:IPSec HA (crypto_ha_ipsec_mgr_recv_add_sas):This SA Supports DPD
*Sep 29 17:06:44.063:IPSec HA (crypto_ha_ipsec_gen_sa):Sending Kei to IPSec num_kei 2
*Sep 29 17:06:44.071:IPSec HA (crypto_ha_ipsec_notify_add_sa):operation not performed as

standby ip 4.0.0.3
The following example is sample debug output with the update keyword:
Active Router
*Sep 29 17:27:30.839:IPSec HA(check_and_send_replay_update):Replay triggered update
seq_num 1000 last-sent 0 dir inbound
*Sep 29 17:27:30.839:IPSec HA(create_update_struct):Sending inbound update

*Sep 29 17:27:30.839:IPSec HA(send_update_struct):
Outbound - New KB 0, New replay 0
Inbound - New KB 3998772, New replay 1000






Standby Router
*Sep 29 17:27:28.887:IPSec HA(crypto_ha_ipsec_mgr_recv_update_sa):called

May 2008 DB-449
Debug Commands
*Sep 29 17:27:28.887:IPSec HA(crypto_ha_ipsec_mgr_recv_update_sa):UPDATING INBOUND SA:ip =

4.0.0.3, protocol = 50, spi = B8A47EC9,
NEW KB LIFE = 3998772,
NEW REPLAY WINDOW START = 1000,




debug crypto ha Displays crypto high availability debugging information.
debug crypto isakmp ha Enables debugging messages for ISAKMP high availability.

DB-450 May 2008
Debug Commands
debug crypto ipsec
debug crypto ipsec

To display IP Security (IPSec) events, use the debug crypto ipsec command in privileged EXEC mode.
debug crypto ipsec
no debug crypto ipsec
Examples The following is sample output from the debug crypto ipsec command. In this example, security
associations (SAs) have been successfully established.
Router# debug crypto ipsec
IPSec requests SAs between 172.21.114.123 and 172.21.114.67, on behalf of the permit ip host
172.21.114.123 host 172.21.114.67 command. It prefers to use the transform set esp-des
w/esp-md5-hmac, but it will also consider ah-sha-hmac.
00:24:30: IPSEC(sa_request): ,
(key eng. msg.) src= 172.21.114.123, dest= 172.21.114.67,
src_proxy= 172.21.114.123/255.255.255.255/0/0 (type=1),
dest_proxy= 172.21.114.67/255.255.255.255/0/0 (type=1),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 120s and 4608000kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4
00:24:30: IPSEC(sa_request): ,
src_proxy= 172.21.114.123/255.255.255.255/0/0 (type=1),
dest_proxy= 172.21.114.67/255.255.255.255/0/0 (type=1).,
protocol= AH, transform= ah-sha-hmac ,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0.
Internet Key Exchange (IKE) asks for Service Provider Interfaces (SPIs) from IPSec. For inbound
security associations, IPSec controls its own SPI space.
00:24:34: IPSEC(key_engine): got a queue event...
00:24:34: IPSEC(spi_response): getting spi 302974012ld for SA
from 172.21.114.67 to 172.21.114.123 for prot 3
from 172.21.114.67 to 172.21.114.123 for prot 2
IKE will ask IPSec if it accepts the SA proposal. In this case, it will be the one sent by the local IPSec
in the first place:
00:24:34: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) dest= 172.21.114.67, src= 172.21.114.123,
dest_proxy= 172.21.114.67/255.255.255.255/0/0 (type=1),
src_proxy= 172.21.114.123/255.255.255.255/0/0 (type=1),

May 2008 DB-451
Debug Commands
debug crypto ipsec
After the proposal is accepted, IKE finishes the negotiations, generates the keying
material, and then notifies IPSec of the new security associations (one security
association for each direction).
The following output pertains to the inbound SA. The conn_id value references an entry in the crypto
engine connection table.
00:24:35: IPSEC(initialize_sas): ,
dest_proxy= 172.21.114.123/255.255.255.255/0/0 (type=1),
src_proxy= 172.21.114.67/255.255.255.255/0/0 (type=1),
lifedur= 120s and 4608000 kb,
spi= 0x120F043C(302974012), conn_id= 29, keysize= 0, flags= 0x4
The following output pertains to the outbound SA:

src_proxy= 172.21.114.123/255.255.255.255/0/0 (type=1),
dest_proxy= 172.21.114.67/255.255.255.255/0/0 (type=1),
spi= 0x38914A4(59315364), conn_id= 30, keysize= 0, flags= 0x4
IPSec now installs the SA information into its SA database.

00:24:35: IPSEC(create_sa): sa created,
(sa) sa_dest= 172.21.114.123, sa_prot= 50,
sa_spi= 0x120F043C(302974012),
sa_trans= esp-des esp-md5-hmac , sa_conn_id= 29
(sa) sa_dest= 172.21.114.67, sa_prot= 50,
sa_spi= 0x38914A4(59315364),
The following is sample output from the debug crypto ipsec command as seen on the peer router. In this
example, IKE asks IPSec if it will accept an SA proposal. Although the peer sent two proposals, IPSec
accepted the first proposal.
00:26:15: IPSEC(validate_proposal_request): proposal part #1,
dest_proxy= 172.21.114.67/255.255.255.255/0/0 (type=1),
src_proxy= 172.21.114.123/255.255.255.255/0/0 (type=1),
IKE asks for SPIs.

from 172.21.114.123 to 172.21.114.67 for prot 3
IKE does the remaining processing, completing the negotiation and generating keys. It then tells IPSec
about the new SAs.

DB-452 May 2008
Debug Commands
debug crypto ipsec
The following output pertains to the inbound SA:

dest_proxy= 172.21.114.67/0.0.0.0/0/0 (type=1),
src_proxy= 172.21.114.123/0.0.0.0/0/0 (type=1),
spi= 0x38914A4(59315364), conn_id= 25, keysize= 0, flags= 0x4
The following output pertains to the outbound SA:

src_proxy= 172.21.114.67/0.0.0.0/0/0 (type=1),
dest_proxy= 172.21.114.123/0.0.0.0/0/0 (type=1),
spi= 0x120F043C(302974012), conn_id= 26, keysize= 0, flags= 0x4
IPSec now installs the SA information into its SA database:

(sa) sa_dest= 172.21.114.67, sa_prot= 50,
sa_spi= 0x38914A4(59315364),
(sa) sa_dest= 172.21.114.123, sa_prot= 50,
sa_spi= 0x120F043C(302974012),

May 2008 DB-453
Debug Commands
debug crypto ipv6 ipsec

To display IP Security (IPSec) events for IPv6 networks, use the debug crypto ipv6 ipsec command in
no debug crypto ipv6 ipsec
Command Default Debugging for IPv6 IPSec events is not enabled.

Usage Guidelines Use this command to display IPSec events while setting up or removing policy definitions during OSPF
configuration.
Examples The following example enables the display of IPSec events for IPv6 networks:
Router# debug crypto ipv6 ipsec

debug crypto engine Displays debugging messages about crypto engines, which
perform encryption and decryption.
debug crypto ipv6 packet Displays debug messages for IPv6 packets allowing you to
see the contents of packets outbound from a Cisco router
when the remote node is not a Cisco node.
debug crypto socket Displays communication between the client and IPSec
during policy setup and removal processes.
debug ipv6 ospf authentication Displays the interaction between OSPF and IPSec,
including creation or removal of policies.

DB-454 May 2008
Debug Commands
debug crypto ipv6 packet

To display the contents of IPv6 packets, use the debug crypto ipv6 packet command in privileged
no debug crypto ipv6 packet
Command Default Debugging for IPv6 IPSec packets is not enabled.

Usage Guidelines Consult Cisco Technical Support before using this command.
Use this command to display the contents of IPv6 packets. This command is useful when the remote node
is not a Cisco device and communication between the Cisco and non-Cisco router cannot be established.
This command enables you to look at the contents of the packets outbound from the Cisco router.
This command examines the content of every IPv6 packet and may slow network performance.
Examples This example shows the ouptut of each packet when the debug crypto ipv6 packet command is enabled:
Router# debug crypto ipv6 packet
Crypto IPv6 IPSEC packet debugging is on
Router#
*Oct 30 16:57:06.330:
IPSECv6:before Encapsulation of IPv6 packet:
0E37A7C0: 6E000000 00285901 n....(Y.
0E37A7D0:FE800000 00000000 020A8BFF FED42C1D ~...........~T,.
0E37A7E0:FF020000 00000000 00000000 00000005 ................
0E37A7F0:03010028 01010104 00000001 8AD80000 ...(.........X..
0E37A800:00000006 01000013 000A0028 0A0250CF ...........(..PO
0E37A810:01010104 0A0250CF ......PO
*Oct 30 16:57:06.330:
IPSECv6:Encapsulated IPv6 packet
:
0E37A7B0:6E000000 00403301 FE800000 00000000 n....@3.~.......

May 2008 DB-455
Debug Commands
0E37A7C0:020A8BFF FED42C1D FF020000 00000000 ....~T,.........

0E37A7D0:00000000 00000005 59040000 000022B8 ........Y....."8
0E37A7E0:0000001A 38AB1ED8 04C1C6FB FF1248CF ....8+.X.AF{..HO
0E37A7F0:03010028 01010104 00000001 8AD80000 ...(.........X..
0E37A800:00000006 01000013 000A0028 0A0250CF ...........(..PO
0E37A810:01010104 0A0250CF ......PO
*Oct 30 16:57:11.914:
IPSECv6:Before Decapsulation of IPv6 packet
:
0E004A50: 6E000000 00403301 n....@3.
0E004A60:FE800000 00000000 023071FF FE7FE81D ~........0q.~.h.
0E004A70:FF020000 00000000 00000000 00000005 ................
0E004A80:59040000 000022B8 00001D88 F5AC68EE Y....."8....u,hn
0E004A90:1AC00088 947C6BF2 03010028 0A0250CF .@...|kr...(..PO
0E004AA0:00000001 E9080000 00000004 01000013 ....i...........
0E004AB0:000A0028 0A0250CF 01010104 01010104 ...(..PO........
0E004AC0:
*Oct 30 16:57:11.914:
IPSECv6:Decapsulated IPv6 packet
:
0E004A70:6E000000 00285901 FE800000 00000000 n....(Y.~.......
0E004A80:023071FF FE7FE81D FF020000 00000000 .0q.~.h.........
0E004A90:00000000 00000005 03010028 0A0250CF ...........(..PO
0E004AA0:00000001 E9080000 00000004 01000013 ....i...........
0E004AB0:000A0028 0A0250CF 01010104 01010104 ...(..PO........
0E004AC0:
*Oct 30 16:57:16.330:
IPSECv6:before Encapsulation of IPv6 packet:
0E003DC0: 6E000000 00285901 n....(Y.
0E003DD0:FE800000 00000000 020A8BFF FED42C1D ~...........~T,.
0E003DE0:FF020000 00000000 00000000 00000005 ................
0E003DF0:03010028 01010104 00000001 8AD80000 ...(.........X..
0E003E00:00000006 01000013 000A0028 0A0250CF ...........(..PO
0E003E10:01010104 0A0250CF ......PO
*Oct 30 16:57:16.330:
IPSECv6:Encapsulated IPv6 packet
:
0E003DB0:6E000000 00403301 FE800000 00000000 n....@3.~.......
0E003DC0:020A8BFF FED42C1D FF020000 00000000 ....~T,.........
0E003DD0:00000000 00000005 59040000 000022B8 ........Y....."8
0E003DE0:0000001B F8E3C4E2 4CC4B690 DDF32B5C ....xcDbLD6.]s+\
0E003DF0:03010028 01010104 00000001 8AD80000 ...(.........X..
0E003E00:00000006 01000013 000A0028 0A0250CF ...........(..PO
0E003E10:01010104 0A0250CF ......PO

debug crypto engine Displays debugging messages about crypto engines, which
perform encryption and decryption.
debug crypto ipv6 ipsec Displays IPSec events for IPv6 networks.
debug crypto socket Displays communication between the client and IPSec
during policy setup and removal processes.

DB-456 May 2008
Debug Commands
debug crypto isakmp ha

To enable debugging messages for Internet Security Association and Key Management Protocol
(ISAKMP) high availability, use the debug crypto isakmp ha command in privileged EXEC mode. To
disable debugging messages, use the no form of this command.
debug crypto isakmp ha [detail]
no debug crypto isakmp ha [detail]

Examples The following is sample output for a standby router from the debug crypto isakmp ha command:
Active Router
no debug message
Standby Router
Router# debug crypto isakmp ha
Crypto ISAKMP High Availability debugging is on

vrf-lite-R1#
*Sep 28 21:54:41.815:IKE HA:(4.0.0.3) Adding STANDBY IKE SA
*Sep 28 21:54:41.843:IKE HA:Create peer struct for local 4.0.0.3 remote 4.0.0.5 & locked
*Sep 28 21:54:41.843:IKE HA:IKE SA inserted on standby with src = 4.0.0.5, dst = 4.0.0.3
The following sample output is displayed when the detail keyword is issued. (Note that debug output
without issuing the detail keyword is the same as the debug output with the detail keyword.)
Active Router
Router# debug crypto isakmp ha detail
Crypto ISAKMP High Availability detailed debugging is on

vrf-lite-R1#
*Sep 29 16:59:15.035:IKE HA:IKE SA is already failed over
Standby Router
Router# debug crypto isakmp ha detail
Crypto ISAKMP High Availability detailed debugging is on

vrf-lite-R2#
*Sep 29 16:59:14.371:IKE HA:(4.0.0.3) Adding STANDBY IKE SA

May 2008 DB-457
Debug Commands
*Sep 29 16:59:14.411:IKE HA:Create peer struct for local 4.0.0.3 remote 4.0.0.5 & locked
*Sep 29 16:59:14.411:IKE HA:IKE SA inserted on standby with src = 4.0.0.5, dst = 4.0.0.3

debug crypto ha Displays crypto high availability debugging information.
debug crypto ipsec ha Enables debugging messages for IPSec high availability.

DB-458 May 2008
Debug Commands
debug crypto isakmp
debug crypto isakmp

To display messages about Internet Key Exchange (IKE) events, use the debug crypto isakmp command
debug crypto isakmp [aaa]
no debug crypto isakmp [aaa]
Syntax Description aaa (Optional) Specifies accounting events.
Command History Release Modifications

12.2(15)T The aaa keyword was added.
Examples The following is sample output from the debug crypto isakmp command for an IKE peer that initiates
an IKE negotiation.
First, IKE negotiates its own security association (SA), checking for a matching IKE policy.
Router# debug crypto isakmp
20:26:58: ISAKMP (8): beginning Main Mode exchange

20:26:58: ISAKMP (8): processing SA payload. message ID = 0
20:26:58: ISAKMP (8): Checking ISAKMP transform 1 against priority 10 policy
20:26:58: ISAKMP: encryption DES-CBC
20:26:58: ISAKMP: hash SHA
20:26:58: ISAKMP: default group 1
20:26:58: ISAKMP: auth pre-share
20:26:58: ISAKMP (8): atts are acceptable. Next payload is 0
IKE has found a matching policy. Next, the IKE SA is used by each peer to authenticate the other peer.
20:26:58: ISAKMP (8): SA is doing pre-shared key authentication
20:26:59: ISAKMP (8): processing KE payload. message ID = 0
20:26:59: ISAKMP (8): processing NONCE payload. message ID = 0
20:26:59: ISAKMP (8): SKEYID state generated
20:26:59: ISAKMP (8): processing ID payload. message ID = 0
20:26:59: ISAKMP (8): processing HASH payload. message ID = 0
20:26:59: ISAKMP (8): SA has been authenticated
Next, IKE negotiates to set up the IP Security (IPSec) SA by searching for a matching transform set.
20:26:59: ISAKMP (8): beginning Quick Mode exchange, M-ID of 767162845

May 2008 DB-459
Debug Commands
debug crypto isakmp
20:26:59: ISAKMP (8): processing SA payload. message ID = 767162845

20:26:59: ISAKMP (8): Checking IPSec proposal 1
20:26:59: ISAKMP: transform 1, ESP_DES
20:26:59: ISAKMP: attributes in transform:
20:26:59: ISAKMP: encaps is 1
20:26:59: ISAKMP: SA life type in seconds
20:26:59: ISAKMP: SA life duration (basic) of 600
20:26:59: ISAKMP: SA life type in kilobytes
20:26:59: ISAKMP: SA life duration (VPI) of
0x0 0x46 0x50 0x0
20:26:59: ISAKMP: authenticator is HMAC-MD5
20:26:59: ISAKMP (8): atts are acceptable.
A matching IPSec transform set has been found at the two peers. Now the IPSec SA can be created (one
SA is created for each direction).
20:26:59: ISAKMP (8): processing NONCE payload. message ID = 767162845
20:26:59: ISAKMP (8): Creating IPSec SAs
20:26:59: inbound SA from 155.0.0.2 to 155.0.0.1 (proxy 155.0.0.2 to 155.0.0.1 )
20:26:59: has spi 454886490 and conn_id 9 and flags 4
20:26:59: lifetime of 600 seconds
20:26:59: lifetime of 4608000 kilobytes
20:26:59: outbound SA from 155.0.0.1 to 155.0.0.2 (proxy 155.0.0.1
to 155.0.0.2 )
20:26:59: has spi 75506225 and conn_id 10 and flags 4
20:26:59: lifetime of 600 seconds
20:26:59: lifetime of 4608000 kilobytes
The following is sample output from the debug crypto isakmp command using the aaa keyword:
Router# debug crypto isakmp aaa
Start Example
01:38:55: ISAKMP AAA: Sent Accounting Message
01:38:55: ISAKMP AAA: Accounting message successful
01:38:55: ISAKMP AAA: Rx Accounting Message
01:38:55: ISAKMP AAA: Adding Client Attributes to Accounting Record
01:38:55: ISAKMP AAA: Accounting Started
Update Example
01:09:55: ISAKMP AAA: Accounting received kei with flags 0x1042

01:09:55: ISAKMP AAA: Updating Stats
01:09:55: Previous in acc (PKTS) IN: 10 OUT: 10
01:09:55: Traffic on sa (PKTS) IN: 176 OUT: 176

crypto isakmp profile Defines an ISAKMP profile and audits IPSec user sessions.
crypto map (global IPSec) Enters crypto map configuration mode and creates or modifies
a crypto map entry, creates a crypto profile that provides a
template for configuration of a dynamically created crypto map,
or configures a client accounting list.

DB-460 May 2008
Debug Commands
debug crypto key-exchange

To show Digital Signature Standard (DSS) public key exchange messages, use the debug crypto
key-exchange command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
no debug crypto key-exchange
Usage Guidelines Encryption and authentication are provided by a software service on the router called a crypto engine.
The crypto engine performs authentication through DSS public and private keys when a connection is
set up. DSS is a means of sending a signature at the end of a message that positively identifies the
author of the message. The signature cannot be forged or duplicated by others, so whoever received a
message with a DSS signature knows exactly who sent the message.
If the process of exchanging DSS public keys with a peer router by means of the config crypto
key-exchange command is not successful, try to exchange DSS public keys again after enabling the
debug crypto key-exchange command to help you diagnose the problem.
Examples The following is sample output from the debug crypto key-exchange command. The first shows output
from the initiating router in a key exchange. The second shows output from the passive router in a key
exchange. The number of bytes received should match the number of bytes sent from the initiating side,
although the number of messages can be different.
Router# debug crypto key-exchange
CRYPTO-KE: Sent 4 bytes.

Router# debug crypto key-exchange
CRYPTO-KE: Received 4 bytes.


debug crypto sesmgmt Displays connection setup messages and their flow through the router.

May 2008 DB-461
Debug Commands
debug crypto mib
debug crypto mib

To display debug messages for the IP Security (IPsec) MIB subsystem, use the debug crypto mib
debug crypto mib [detail | error]
no debug crypto mib [detail | error]
Syntax Description detail (Optional) Displays different events as they occur in the IPsec MIB
subsystem.
Note Because the output for this keyword can be quite long, due
consideration should be given to enabling debug crypto mib detail.
error (Optional) Displays error events in the MIB agent.
Defaults Message notification debugging is not enabled.

12.1(4)E This command was introduced.
12.4(4)T The detail and error keywords were added.
Examples The following example shows IPsec MIB debug message notification being enabled:
Router# debug crypto mib
Crypto IPSec Mgmt Entity debugging is on
The following example shows that detailed information about events that are occurring in the subsystem
has been requested:
Router# debug crypto mib detail
The following example shows that information has been requested about error events in the MIB agent:
Router# debug crypto mib error

DB-462 May 2008
Debug Commands
debug crypto mib

show crypto mib ipsec flowmib history failure size Displays the size of the IPSec failure
history table.
show crypto mib ipsec flowmib history tunnel size Displays the size of the IPSec tunnel
history table.
show crypto mib ipsec flowmib version Displays the IPSec Flow MIB version used
by the router.

May 2008 DB-463
Debug Commands
debug crypto pki messages

To display debugging messages for the details of the interaction (message dump) between the
certification authority (CA) and the router, use the debug crypto pki messages command in privileged
no debug crypto pki messages
Defaults Disabled.

Usage Guidelines The debug crypto pki messages command displays messages about the actual data being sent and
received during public key infrastructure (PKI) transactions. This command is internal for use by Cisco
support personnel.
You can use the show crypto ca certificates command to display information about your certificate.
Examples The following is sample output from the debug crypto pki messages command:
Router# debug crypto pki messages
Fingerprint: 2CFC6265 77BA6496 3AEFCB50 29BC2BF2

00:48:23:Write out pkcs#10 content:274
00:48:23:30 82 01 0E 30 81 B9 02 01 00 30 22 31 20 30 1E 06 09 2A 86
00:48:23:48 86 F7 0D 01 09 02 16 11 70 6B 69 2D 33 36 61 2E 63 69 73
00:48:23:63 6F 2E 63 6F 6D 30 5C 30 0D 06 09 2A 86 48 86 F7 0D 01 01
00:48:23:01 05 00 03 4B 00 30 48 02 41 00 DD 2C C6 35 A5 3F 0F 97 6C
00:48:23:11 E2 81 95 01 6A 80 34 25 10 C4 5F 3D 8B 33 1C 19 50 FD 91
00:48:23:6C 2D 65 4C B6 A6 B0 02 1C B2 84 C1 C8 AC A4 28 6E EF 9D 3B
00:48:23:30 98 CB 36 A2 47 4E 7E 6F C9 3E B8 26 BE 15 02 03 01 00 01
00:48:23:A0 32 30 10 06 09 2A 86 48 86 F7 0D 01 09 07 31 03 13 01 63
00:48:23:30 1E 06 09 2A 86 48 86 F7 0D 01 09 0E 31 11 14 0F 30 0D 30
00:48:23:0B 06 03 55 1D 0F 04 04 03 02 05 A0 30 0D 06 09 2A 86 48 86
00:48:23:F7 0D 01 01 04 05 00 03 41 00 2C FD 88 2C 8A 13 B6 81 88 EA
00:48:23:5C FD AE 52 8F 2C 13 95 9E 9D 8B A4 C9 48 32 84 BF 05 03 49

DB-464 May 2008
Debug Commands
00:48:23:63 27 A3 AC 6D 74 EB 69 E3 06 E9 E4 9F 0A A8 FB 20 F0 02 03
00:48:23:BE 90 57 02 F2 75 8E 0F 16 60 10 6F BE 2B
00:48:23:Enveloped Data ...
00:48:23:30 80 06 09 2A 86 48 86 F7 0D 01 07 03 A0 80 30 80 02 01 00
00:48:23:31 80 30 82 01 0F 02 01 00 30 78 30 6A 31 0B 30 09 06 03 55
00:48:23:04 06 13 02 55 53 31 0B 30 09 06 03 55 04 08 13 02 43 41 31
00:48:23:13 30 11 06 03 55 04 07 13 0A 53 61 6E 74 61 20 43 72 75 7A
00:48:23:31 15 30 13 06 03 55 04 0A 13 0C 43 69 73 63 6F 20 53 79 73
00:48:23:74 65 6D 31 0E 30 0C 06 03 55 04 0B 13 05 49 50 49 53 55 31
00:48:23:Signed Data 1382 bytes
00:48:23:30 80 06 09 2A 86 48 86 F7 0D 01 07 02 A0 80 30 80 02 01 01
00:48:23:31 0E 30 0C 06 08 2A 86 48 86 F7 0D 02 05 05 00 30 80 06 09
00:48:23:2A 86 48 86 F7 0D 01 07 01 A0 80 24 80 04 82 02 75 30 80 06
00:48:23:02 55 53 31 0B 30 09 06 03 55 04 08 13 02 43 41 31 13 30 11
00:48:23:33 34 5A 17 0D 31 30 31 31 31 35 31 38 35 34 33 34 5A 30 22
00:48:23:31 20 30 1E 06 09 2A 86 48 86 F7 0D 01 09 02 16 11 70 6B 69
00:48:23:2D 33 36 61 2E 63 69 73 63 6F 2E 63 6F 6D 30 5C 30 0D 06 09
00:48:23:2A 86 48 86 F7 0D 01 01 01 05 00 03 4B 00 30 48 02 41 00 DD
00:48:23:2C C6 35 A5 3F 0F 97 6C 11 E2 81 95 01 6A 80 34 25 10 C4 5F
00:48:23:3D 8B 33 1C 19 50 FD 91 6C 2D 65 4C B6 A6 B0 02 1C B2 84 C1
00:48:23:86 F7 0D 01 01 01 05 00 04 40 C6 24 36 D6 D5 A6 92 80 5D E5
00:48:23:15 F7 3E 15 6D 71 E1 D0 13 2B 14 64 1B 0C 0F 96 BF F9 2E 05
00:48:23:EF C2 D6 CB 91 39 19 F8 44 68 0E C5 B5 84 18 8B 2D A4 B1 CD
00:48:23:3F EC C6 04 A5 D9 7C B1 56 47 3F 5B D4 93 00 00 00 00 00 00
00:48:23:00 00
00:48:24:Received pki message:1778 types
.
.
.

crypto ca enroll Obtains the certificate of your router from the CA.
debug crypto pki transactions Displays debugging messages for the trace of interaction
(message type) between the CA and the router.
show crypto ca certificates Displays information about your certificate, the certificate of the
CA, and any RA certificates.

May 2008 DB-465
Debug Commands
debug crypto pki server

To enable debugging for a crypto public key infrastructure (PKI) certificate server, use the debug crypto
pki server command in privileged EXEC mode. To disable debugging, use the no form of this command.
no debug crypto pki server

Examples The following example shows how to enable debugging for a certificate server. This example also
contains sample debug messages, which allow users to troubleshoot the various
certificate-request-related stages and tasks that are handled by the certificate server.
Router# debug crypto pki server
Crypto PKI Certificate Server debugging is on
Oct 15 19:50:41.003:CRYPTO_CS:old RA cert flag 0x4

Oct 15 19:50:41.003:CRYPTO_CS:new RA cert flag 0x1000C
Oct 15 19:50:41.003:CRYPTO_CS:nvram filesystem
Oct 15 19:50:41.279:CRYPTO_CS:serial number 0x1 written.
Oct 15 19:50:53.383:CRYPTO_CS:created a new serial file.
Oct 15 19:50:53.383:CRYPTO_CS:SCEP server started
Oct 15 19:50:53.419:%SYS-5-CONFIG_I:Configured from console by console
Oct 15 19:50:53.731:CRYPTO_CS:received a SCEP GetCACert request
Oct 15 19:50:53.739:CRYPTO_CS:CA certificate sent
Oct 15 19:50:54.355:CRYPTO_CS:received a SCEP GetCACert request
Oct 15 19:50:54.363:CRYPTO_CS:CA certificate sent
Oct 15 19:50:57.791:CRYPTO_CS:received a SCEP request
Oct 15 19:50:57.795:CRYPTO_CS:read SCEP:registered and bound service
SCEP_READ_DB_8
Oct 15 19:50:57.947:CRYPTO_CS:scep msg type - 19
Oct 15 19:50:57.947:CRYPTO_CS:trans id -
3673CE2FF0235A4AE6F26242B00A4BB4
Oct 15 19:50:58.679:CRYPTO_CS:read SCEP:unregistered and unbound
service SCEP_READ_DB_8
Oct 15 19:50:58.683:CRYPTO_CS:received an enrollment request
Oct 15 19:50:58.691:CRYPTO_CS:request has been authorized, transaction
id=3673CE2FF0235A4AE6F26242B00A4BB4
Oct 15 19:50:58.699:CRYPTO_CS:byte 2 in key usage in PKCS#10 is 0x7

DB-466 May 2008
Debug Commands
Oct 15 19:50:58.699:CRYPTO_CS:signature
Oct 15 19:50:58.699:CRYPTO_CS:key_usage is 1
Oct 15 19:50:58.703:CRYPTO_CS:enrollment request with pendingID 1 sent
to the CA
Oct 15 19:50:58.707:CRYPTO_CS:write SCEP:registered and bound service
SCEP_WRTE_DB_8
Oct 15 19:50:59.531:CRYPTO_CS:write SCEP:unregistered and unbound
service SCEP_WRTE_DB_8
.....
Oct 15 19:53:08.403:CRYPTO_CS:CS_RA_REQUEST:save cert in dbase,

pending id = 2
Oct 15 19:53:08.403:CRYPTO_CS:enrollment request 2 granted
Oct 15 19:53:08.403:CRYPTO_PKI:All enrollment requests completed for
trustpoint ra.
Oct 15 19:53:08.403:%CRYPTO-6-CERTRET:Certificate received from
Certificate Authority
trustpoint ra.
trustpoint ra.
trustpoint ra.
Oct 15 19:53:19.623:IPSEC(key_engine):major = 1
Oct 15 19:53:19.623:IPSEC(key_engine):expired_timer:skip ...
Oct 15 19:53:35.707:CRYPTO_CS:received a SCEP request
Oct 15 19:53:35.711:CRYPTO_CS:read SCEP:registered and bound service
SCEP_READ_DB_14
Oct 15 19:53:35.859:CRYPTO_CS:scep msg type - 20
Oct 15 19:53:35.859:CRYPTO_CS:trans id -
4D774FFE2F7CA9991A7F6A785E803E77
Oct 15 19:53:36.591:CRYPTO_CS:read SCEP:unregistered and unbound
service SCEP_READ_DB_14
Oct 15 19:53:36.595:CRYPTO_CS:received an enrollment request
Oct 15 19:53:36.595:CRYPTO_CS:write SCEP:registered and bound service
SCEP_WRTE_DB_14
Oct 15 19:53:37.623:CRYPTO_CS:write SCEP:unregistered and unbound
service SCEP_WRTE_DB_14
Oct 15 19:53:37.631:CRYPTO_CS:Certificate sent to requestor

crypto pki server Enables a Cisco IOS certificate server and enters certificate server
configuration mode.

May 2008 DB-467
Debug Commands
debug crypto pki transactions

To display debugging messages for the trace of interaction (message type) between the certification
authority (CA) and the router, use the debug crypto pki transactions command in privileged EXEC
no debug crypto pki transactions
Defaults Disabled

Usage Guidelines Use the debug crypto pki transactions command to display debugging messages pertaining to public
key infrastructure (PKI) certificates. The messages will show status information during certificate
enrollment and verification.
You can also use the show crypto ca certificates command to display information about your certificate.
Examples The following example, which authenticates and enrolls a CA, contains sample output for the debug
crypto pki transactions command:
Router(config)# crypto ca authenticate msca
Certificate has the following attributes:

Fingerprint:A5DE3C51 AD8B0207 B60BED6D 9356FB00
% Do you accept this certificate? [yes/no]:y
Router# debug crypto pki transactions
00:44:00:CRYPTO_PKI:Sending CA Certificate Request:

GET /certsrv/mscep/mscep.dll/pkiclient.exe?operation=GetCACert&message=msca HTTP/1.0
00:44:00:CRYPTO_PKI:http connection opened

00:44:01:CRYPTO_PKI:HTTP response header:
HTTP/1.1 200 OK

DB-468 May 2008
Debug Commands
Server:Microsoft-IIS/5.0
Date:Fri, 17 Nov 2000 18:50:59 GMT
Content-Length:2693
Content-Type:application/x-x509-ca-ra-cert
Content-Type indicates we have received CA and RA certificates.
00:44:01:CRYPTO_PKI:WARNING:A certificate chain could not be constructed while selecting

certificate status
00:44:01:CRYPTO_PKI:WARNING:A certificate chain could not be constructed while selecting

certificate status
00:44:01:CRYPTO_PKI:Name:CN = msca-rootRA, O = Cisco System, C = US

00:44:01:CRYPTO_PKI:Name:CN = msca-rootRA, O = Cisco System, C = US
00:44:01:CRYPTO_PKI:transaction GetCACert completed
00:44:01:CRYPTO_PKI:CA certificate received.
00:44:01:CRYPTO_PKI:CA certificate received.
Router(config)# crypto ca enroll msca
%
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
password to the CA Administrator in order to revoke your certificate.
For security reasons your password will not be saved in the configuration.
Please make a note of it.
Password:
Re-enter password:
% The subject name in the certificate will be:Router.cisco.com

% Include the router serial number in the subject name? [yes/no]:n
% Include an IP address in the subject name? [yes/no]:n
Request certificate from CA? [yes/no]:y
% Certificate request sent to Certificate Authority
% The certificate request fingerprint will be displayed.
% The 'show crypto ca certificate' command will also show the fingerprint.
Router(config)#
00:44:29:CRYPTO_PKI:transaction PKCSReq completed

00:44:29:CRYPTO_PKI:status:
00:44:29:CRYPTO_PKI:http connection opened
00:44:29:CRYPTO_PKI: received msg of 1924 bytes
00:44:29:CRYPTO_PKI:HTTP response header:
HTTP/1.1 200 OK
Server:Microsoft-IIS/5.0
Date:Fri, 17 Nov 2000 18:51:28 GMT
Content-Length:1778
Content-Type:application/x-pki-message
00:44:29:CRYPTO_PKI:signed attr:pki-message-type:
00:44:29:13 01 33
00:44:29:CRYPTO_PKI:signed attr:pki-status:
00:44:29:13 01 30
00:44:29:CRYPTO_PKI:signed attr:pki-recipient-nonce:
00:44:29:04 10 B4 C8 2A 12 9C 8A 2A 4A E1 E5 15 DE 22 C2 B4 FD
00:44:29:CRYPTO_PKI:signed attr:pki-transaction-id:
00:44:29:13 20 34 45 45 41 44 42 36 33 38 43 33 42 42 45 44 45 39 46
00:44:29:34 38 44 33 45 36 39 33 45 33 43 37 45 39
00:44:29:CRYPTO_PKI:status = 100:certificate is granted
00:44:29:CRYPTO__PKI:All enrollment requests completed.
00:44:29:%CRYPTO-6-CERTRET:Certificate received from Certificate Authority

May 2008 DB-469
Debug Commands

crypto ca authenticate Authenticates the CA (by getting the certificate of the CA).
crypto ca enroll Obtains the certificate of your router from the CA.
debug crypto pki messages Displays debugging messages for details of the interaction
(message dump) between the CA and the router.
show crypto ca certificates Displays information about your certificate, the certificate of the
CA, and any RA certificates.

DB-470 May 2008
Debug Commands
debug crypto provisioning

To display information about an easy secure device provisioning (SDP) operation, use the
debug crypto provisioning command in privileged EXEC mode. To disable debugging output, use the
no debug crypto provisioning

12.3(14)T This command replaced the debug crypto wui command.
Usage Guidelines For more detailed information about authentication, authorization, and accounting (AAA), use the
debug aaa authorization command.
Examples The following is sample output from the debug crypto provisioning command. The output includes
explanations of the process.
Router# debug crypto provisioning
Petitioner device
! The user starts the Welcome phase.
Nov 7 03:15:48.171: CRYPTO_WUI_TTI: received welcome get request.
! The router generates a Rivest, Shamir, and Adelman (RSA) keypair for future enrollment.
Nov 7 03:15:48.279: CRYPTO_WUI_TTI: keyhash 'A506BE3B83C6F4B4A6EFCEB3D584AACA'
! The TTI transaction is completed.
Nov 7 03:16:10.607: CRYPTO_WUI_TTI: received completion post request.
Registrar device
!. During the introduction phase, the browser prompts for login information.
06:39:18: CRYPTO_WUI_TTI: received introduction post request.
06:39:18: CRYPTO_WUI_TTI: checking AAA authentication (ipsecca_script_aaalist, ttiuser)
! This happens if the user types in the wrong username or password.
06:39:19: CRYPTO_WUI_TTI: authentication declined by AAA, or AAA server not found - 0x3
06:39:19: CRYPTO_WUI_TTI: aaa query fails!

May 2008 DB-471
Debug Commands
! The user re-enters login information.

06:39:19: CRYPTO_WUI_TTI: received introduction post request.
06:39:19: CRYPTO_WUI_TTI: checking AAA authentication (ipsecca_script_aaalist, ttiuser)
06:39:20: CRYPTO_WUI_TTI: checking AAA authorization (ipsecca_script_aaalist, ttiuser)
! The login attempt succeeds and authorization information is retrieved from the AAA
database.
06:39:21: CRYPTO_WUI_TTI: aaa query ok!
! These attributes are inserted into the configuration template.
06:39:21: CRYPTO_WUI_TTI: building TTI av pairs from AAA attributes
06:39:21: CRYPTO_WUI_TTI: "subjectname" = "CN=user, O=company, C=country"
06:39:21: CRYPTO_WUI_TTI: "$1" = "ntp server 192.0.2.1"
06:39:21: CRYPTO_WUI_TTI: "$2" = "hostname user-vpn"
! The registrar stores this subject name and overrides the subject name in the subsequent
enrollment request.
06:39:21: CRYPTO_WUI_TTI: subjectname=CN=user, O=company, C=country
! The registrar stores this key information so that it may be used to automatically grant
the subsequent enrollment request.
06:39:21: CRYPTO_WUI_TTI: key_hash=A506BE3B83C6F4B4A6EFCEB3D584AACA

authentication list (tti-registrar) Authenticates the introducer in an SDP operation.
authorization list (tti-registrar) Specifies the appropriate authorized fields for the
certificate subject name and list of template variables to
be expanded into the Cisco IOS CLI snippet that is sent
back to the petitioner in an SDP operation.
debug aaa authorization Displays information on AAA TACACS+ authorization.
template config Specifies a remote URL for a Cisco IOS CLI
configuration template.
template username Establishes a template username and password to access
the configuration template on the file system.

DB-472 May 2008
Debug Commands
debug crypto sesmgmt

To show connection setup messages and their flow through the router, use the debug crypto sesmgmt
no debug crypto sesmgmt
Usage Guidelines Encryption and authentication are provided by a software service on the router called a crypto engine.
The crypto engine performs authentication through Digital Signature Standard (DSS) public and private
keys when a connection is set up. DSS is a means of sending a signature at the end of a message that
positively identifies the author of the message. The signature cannot be forged or duplicated by others,
so whoever receives a message with a DSS signature knows exactly who sent the message.
When connections are not completing, use the debug crypto sesmgmt command to follow the progress
of connection messages as a first step in diagnosing the problem. You see a record of each connection
message as the router discovers it, and can track its progress through the necessary signing, verifying,
and encryption session setup operations. Other significant connection setup events, such as the
pregeneration of Diffie-Hellman public numbers, are also shown. For information on Diffie-Hellman
public numbers, refer to the Cisco IOS Security Configuration Guide.
Also use the show crypto connections command to display additional information on connections.
Examples The following is sample output from the debug crypto sesmgmt command. The first shows messages
from a router that initiates a successful connection. The second shows messages from a router that
receives a connection.
Router# debug crypto sesmgmt
CRYPTO: Dequeued a message: Inititate_Connection

CRYPTO: DH gen phase 1 status for conn_id 2 slot 0:OK
CRYPTO: Signing done. Status:OK
CRYPTO: ICMP message sent: s=172.21.114.163, d=172.21.114.162
CRYPTO-SDU: send_nnc_req: NNC Echo Request sent
CRYPTO: Dequeued a message: CRM
CRYPTO: Verify done. Status=OK
CRYPTO-SDU: recv_nnc_rpy: NNC Echo Confirm sent
CRYPTO: Create encryption key for conn_id 2 slot 0:OK
CRYPTO: Replacing -2 in crypto maps with 2 (slot 0)
Router# debug crypto sesmgmt
CRYPTO: Dequeued a message: CIM


May 2008 DB-473
Debug Commands

CRYPTO-SDU: act_on_nnc_req: NNC Echo Reply sent
CRYPTO: Create encryption key for conn_id 1 slot 0:OK
CRYPTO: Replacing -2 in crypto maps with 1 (slot 0)
CRYPTO: Dequeued a message: CCM

debug crypto key-exchange Displays DSS public key exchange messages.

DB-474 May 2008
Debug Commands
debug csm neat (New Command)

To turn on debugging for all Call Switching Module (CSM) Voice over IP (VoIP) calls, use the debug
csm neat command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug csm neat [slot | dspm | dsp | dsp-channel]
no debug csm neat [slot | dspm | dsp | dsp-channel]
Syntax Description slot | dspm | dsp | dsp-channel (Optional) Identifies the location of a particular digital signal
processor (DSP) channel.

train. Support in a specific 12.2SX release of this train depends on
your feature set, platform, and platform hardware.
Usage Guidelines The debug csm neat command turns on debugging for all CSM VoIP calls. If no arguments are specified,
debugging is enabled for all voice calls.
Note The debug csm neat command does not display any information if you try to debug ISDN voice calls.
To view debugging information about ISDN calls, use the debug cdapi command.
The no debug cms neat command turns off debugging information for all voice calls.
If the slot, dspm, dsp, or dsp-channel arguments are specified (if the specified DSP channel is engaged
in a CSM call), CSM call-related debugging information is turned on for this channel. The no form of
this command turns off debugging for that particular channel.
Examples The following examples show sample output from the debug csm neat command. The following shows
that CSM has received an event from ISDN.
Router# debug csm neat
March 18 04:05:07.052: EVENT_FROM_ISDN::dchan_idb=0x60D7B6B8, call_id=0xCF, ces=0x1

bchan=0x0, event=0x1, cause=0x0

May 2008 DB-475
Debug Commands
Table 65 debug csm neat Field Descriptions
Field Description
dchan_idb Indicates the address of the hardware interface description block
(IDB) for the D channel.
call_id Indicates the call ID assigned by ISDN.
call-id Indicates the call ID assigned by ISDN
bchan Indicates the number of the B channel assigned for this call
cause Indicates the ISDN event cause
The following example shows that CSM has allocated the CSM voice control block for the DSP device
on slot 1 port 10 for this call.
March 18 04:05:07.052: VDEV_ALLOCATE: slot 1 and port 10 is allocated.
In this example, CSM must first allocate the CSM voice control block to initiate the state machine. After
the voice control block has been allocated, CSM obtains from the DSP Resource Manager the actual DSP
channel that will be used for the call. At that point, CSM will switch to the actual logical port number.
The slot number in this example refers to the physical slot on the Cisco AS5400 access server. The port
number is the logical DSP number interpreted as listed in Table 66.
Table 66 Logical DSP Numbers
Logical Port Physical DSP Channel

0 DSPRM 1 DSP 1 DSP channel 1

DB-476 May 2008
Debug Commands
Table 66 Logical DSP Numbers (continued)
Logical Port Physical DSP Channel

The following example shows that the function csm_vtsp_init_tdm() has been called with a voice control
block of address 0x60B8562C. This function will be called only when the call is treated as a voice call.
March 18 04:05:07.052: csm_vtsp_init_tdm (voice_vdev=0x60B8562C)
The following example shows that CSM has obtained a DSP channel from the DSP Resource Manager:
March 18 04:05:07.052: csm_vtsp_init_tdm: dsprm_tdm_allocate: tdm slot 1, dspm 2, dsp 5,
dsp_channel 1csm_vtsp_init_tdm: dsprm_tdm_allocate: tdm stream 5, channel 9, bank 0,
bp_channel 10
Table 67 describes the significant fields shown in the DSP channel initialized TDM display.
Table 67 debug csm neat TDM Channel Field Descriptions
Field Description
TDM slot 1, dspm 2, dsp 5, Indicates the physical DSP channel that will be used for this call.
dsp_channel 1
TDM stream 5, channel 9, Indicates the on-chip and backplane TDM channel assigned to
bank 0, bp_channel 10 this DSP channel. Stream 5, channel 9 gives the on-chip TDM
channel mapped to the DSP; bank 0, bp_channel 10 means that
the backplane stream 0 and backplane channel #1 are assigned to
this DSP.

May 2008 DB-477
Debug Commands
The following shows that CSM received an incoming call event from ISDN:
March 18 04:05:07.052: EVENT_FROM_ISDN:(00CF): DEV_INCALL at slot 1 and port 20
Slot 1, port 20 means the logical DSP channel 20 (mapped to DSPRM 2, DSP 5, DSP channel 1).
The following shows that the DEV_INCALL message been translated into a
CSM_EVENT_ISDN_CALL message:
March 18 04:05:07.052: CSM_PROC_IDLE: CSM_EVENT_ISDN_CALL at slot 1, port 20
This message is passed to the CSM central state machine while it is in the CSM_IDLE state and is in the
CSM_PROC_IDLE procedure. The logical DSP channel port 20 on slot 1 is used to handle this call.
The following shows that CSM has invoked the vtsp_ic_notify() function with a CSM voice call control
block 0x60B8562C.
March 18 04:05:07.052: vtsp_ic_notify : (voice_vdev= 0x60B8562C)
Inside this function, CSM will send a SETUP INDICATION message to the VTSP. This function will be
invoked only if the call is a voice call.
The following shows that CSM received a SETUP INDICATION RESPONSE message from the VTSP
as an acknowledgment.
March 18 04:05:07.056: csm_vtsp_call_setup_resp (vdev_info=0x60B8562C,
vtsp_cdb=0x60FCA114)
This means that the VTSP received the CALL SETUP INDICATION message previously sent and has
proceeded to process the call.
vdev_infoContains the address of the CSM voice data block.
vtsp_cdbContains the address of the VTSP call control block.
The following shows that CSM received a CALL CONNECT message from the VTSP:
March 18 04:05:07.596: csm_vtsp_call_connect (vtsp_cdb=0x60FCA114, voice_vdev=0x60B8562C)
This indicates that the VTSP received a CONNECT message for the call leg initiated to the Internet side.
voice_vdevContains the address of the CSM voice data block.
The following shows that while CSM is in the CSM_IC2_RING state, it receives a SETUP
INDICATION RESPONSE from the VTSP. This message is translated into
CSM_EVENT_MODEM_OFFHOOK and passed to the CSM central state machine.
March 18 04:05:07.596: CSM_PROC_IC2_RING: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 20
The following shows that CSM received a CONNECT message from ISDN for the call using the logical
DSP channel on slot 1 and port 20:
March 18 04:05:07.616: EVENT_FROM_ISDN:(00CF): DEV_CONNECTED at slot 1 and port 20
The following shows that CSM translated the CONNECT event from ISDN into the
CSM_EVENT_ISDN_CONNECTED message, which is then passed to the CSM central state machine:
March 18 04:05:07.616: CSM_PROC_IC4_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1,
port 20
The following shows that CSM received a CALL SETUP REQUEST from the VTSP:
May 16 12:22:27.580: csm_vtsp_call_setup_request (vtsp_cdb=0x60FCFA20,
vtsp_sdb=0x60DFB608)

DB-478 May 2008
Debug Commands
This represents a request to make an outgoing call to the PSTN.

vtsp_sdbContains the address of the signalling data block for the signalling interface to be used
to send the outgoing call.
The following shows that the physical DSP channel has been allocated for this outgoing call:
May 16 12:22:27.580: csm_vtsp_call_setup_request: tdm slot 1, dspm 5, dsp 4, dsp_channel 1
The following shows the on-chip and backplane TDM channel assigned to this DSP channel:
May 16 12:22:27.580: csm_vtsp_call_setup_request: tdm stream 5, channel 25, bank 0,
bp_channel 27
In this sample output, tdm stream 5, channel 25, bank 0, bp_channel 27 indicates the on-chip and
backplane TDM channel assigned to this DSP channel. Stream 5, channel 25 gives the on-chip TDM
channel mapped to the DSP; bank 0, bp_channel 27 means that the backplane stream 0 and backplane
channel 1 are assigned to this DSP.
The following shows the calling number and the called number for this call.
May 16 12:22:27.580: csm_vtsp_call_setup_request: calling number: 10001, called number:
30001
The following shows that the CALL SETUP REQUEST from the VTSP has been translated into the '
CSM_EVENT_MODEM_OFFHOOK message and is passed to the CSM central state machine:
May 16 12:22:27.580: CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 54
The logical DSP channel number for the DSP (slot 1, port 54) is now displayed, which maps to the
physical DSP channel slot 1, dspm 5, dsp 4, dsp_channel 1.
The following shows that CSM collected all the digits for dialing out:
May 16 12:22:27.580: CSM_PROC_OC3_COLLECT_ALL_DIGIT: CSM_EVENT_GET_ALL_DIGITS at slot 1,

port 54
For PRI and for applications that do not require digit collection of outdialing digits (for example, voice
calls), the intermediate digit collection states are omitted and the CSM state machine moves to this state
directly, pretending that the digit collection has been done.
The following shows an information message:
March 16 12:22:27.580: CSM_PROC_OC3_COLLECT_ALL_DIGIT: called party num: (30001) at slot
1, port 54
The following shows that CSM attempts to find a free signalling D channel to direct the outgoing call:
March 16 12:22:27.580: csm_vtsp_check_dchan (voice_vdev=0x60B8562C)
March 16 12:22:27.580: csm_vtsp_check_dchan (vtsp requested dchan=0x60D7ACB0,
dchan_idb=0x60E8ACF0)
March 16 12:22:27.580: csm_vtsp_check_dchan (voice_vdev=0x60B8562C)
March 16 12:22:27.580: csm_vtsp_check_dchan (vtsp requested dchan=0x60D7ACB0,
dchan_idb=0x60D7ACB0)
In the case of voice calls, the free signaling D channel must match the voice interface specified inside
the signalling data block (vtsp_sdb) passed from the VTSP.
The following shows that CSM has received an event from ISDN:

May 2008 DB-479
Debug Commands
March 16 12:22:27.624: EVENT_FROM_ISDN::dchan_idb=0x60D7ACB0, call_id=0xA121, ces=0x1

bchan=0x1E, event=0x3, cause=0x0
In this sample output:

dchan_idbIndicates the address of the hardware IDB for the D channel
call_idIndicates the call id assigned by ISDN
bchanIndicates the number of the B channel assigned for this call
causeIndicates the ISDN event cause
The following shows that CSM has received a CALL PROCEEDING message from ISDN.
March 16 12:22:27.624: EVENT_FROM_ISDN:(A121): DEV_CALL_PROC at slot 1 and port 54
The following shows that the CALL PROCEEDING event received from ISDN has been interpreted as
a CSM_EVENT_ISDN_BCHAN_ASSIGNED message:
*March 16 12:22:27.624: CSM_PROC_OC4_DIALING: CSM_EVENT_ISDN_BCHAN_ASSIGNED at slot 1,
port 54
ISDN has assigned a B channel for this outgoing call. This B channel must be on the same PRI span as
the signalling D channel allocated previously.
The following shows that the csm_vtsp_setup_for_oc function is called:
March 16 12:22:27.624: csm_vtsp_setup_for_oc (voice_vdev=0x60B8562C)
This is invoked when an outgoing call initiated by the VTSP receives a response from the ISDN stack.
The following shows that ISDN has sent a CONNECT message to CSM indicating that the call leg to the
PSTN side has been established:
March 16 12:22:28.084: EVENT_FROM_ISDN::dchan_idb=0x60D7ACB0, call_id=0xA121, ces=0x1
March 16 12:22:28.084: EVENT_FROM_ISDN:(A121): DEV_CONNECTED at slot 1 and port 54
The following shows that while CSM is in the OC5_WAIT_FOR_CARRIER state, it has received the
'CONNECT' message from ISDN and has translated it into the CSM_EVENT_ISDN_CONNECTED
message, which is passed to the CSM central state machine:
March 16 12:22:28.084: CSM_PROC_OC5_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1,
port 54
The following shows that the function vtsp_confirm_oc() has been called:
March 16 12:22:28.084: vtsp_confirm_oc : (voice_vdev= 0x60B8562C)
This is invoked after CSM received the CONNECT message from ISDN. CSM sends a confirmation of
the CONNECT to the VTSP.

DB-480 May 2008
Debug Commands
debug csm tgrm
debug csm tgrm

To view Call Switching Module (CSM) trunk group resource manager information, use the debug csm
tgrm command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug csm tgrm
no debug csm tgrm
Defaults Disabled

Usage Guidelines Disable console logging and use buffered logging before using the debug csm tgrm command. Using
the debug csm tgrm command generates a large volume of debugs, which can affect router performance.
Examples The following is sample output from the debug csm tgrm command. The output shows that the call type
is voice, the direction is incoming, and the call is accepted by the CSM.
Router# debug csm tgrm
Router#
00:02:25:CSM-TGRM:csm_rx_cas_event_from_neat(EVENT_DIAL_IN) - c(T1 7/1:1:3)
call_type=VOICE, dir=INCOMING
Router#
00:02:30:CSM-TGRM:csm_proc_ic3_wait_for_res_resp() c(T1 7/1:1:3) VOICE <ACCEPTED !!>

May 2008 DB-481
Debug Commands
debug csm tgrm
Table 68 debug csm tgrm Field Descriptions
Field Description
call_type Type of call: VOICE or MODEM.
dir Direction of the call: INCOMING or OUTGOING.

DB-482 May 2008
Debug Commands
debug csm voice
debug csm voice

To turn on debugging for all Call Switching Module (CSM) Voice over IP (VoIP) calls, use the debug
csm voice command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug csm voice [slot | dspm | dsp | dsp-channel]
no debug csm voice [slot | dspm | dsp | dsp-channel]
Syntax Description slot | dspm | dsp | dsp-channel (Optional) Identifies the location of a particular digital signal
processor (DSP) channel.
Usage Guidelines The debug csm voice command turns on debugging for all CSM VoIP calls. If this command has no
keyword specified, then debugging is enabled for all voice calls.
Note The debug csm voice command does not display any information if you try to debug isdn voice
calls. To view debugging information about isdn calls, use the debug cdapi command.
The no debug cms voice command turns off debugging information for all voice calls.
If the slot | dspm | dsp | dsp-channel argument is specified, then (if the specified DSP channel is engaged
in a CSM call) CSM call-related debugging information will be turned on for this channel. The no form
of this command turns off debugging for that particular channel.
Examples The following examples show sample output from the debug csm voice command. The following shows
that CSM has received an event from ISDN.
Router# debug csm voice
Oct 18 04:05:07.052: EVENT_FROM_ISDN::dchan_idb=0x60D7B6B8, call_id=0xCF, ces=0x1

In this example, terms are explained as follows:

dchan_idbIndicates the address of the hardware interface description block (IDB) for the
D channel
call_idIndicates the call ID assigned by ISDN
The following shows that CSM has allocated the CSM voice control block for the DSP device on slot 1
port 10 for this call.
Oct 18 04:05:07.052: VDEV_ALLOCATE: slot 1 and port 10 is allocated.

May 2008 DB-483
Debug Commands
debug csm voice
This AS5300 access server might not be actually used to handle this call. CSM must first allocate the
CSM voice control block to initiate the state machine. After the voice control block has been allocated,
CSM obtains from the DSP Resource Manager the actual DSP channel that will be used for the call. At
that point, CSM will switch to the actual logical port number. The slot number refers to the physical slot
on the AS5300 access server. The port number is the logical DSP number interpreted as listed in
Table 69.
Table 69 Logical DSP Numbers
Logical Port Number Physical DSP Channel

Port 0 DSPRM 1, DSP 1, DSP channel 1

DB-484 May 2008
Debug Commands
debug csm voice
Table 69 Logical DSP Numbers (continued)
Logical Port Number Physical DSP Channel

The following shows that the function csm_vtsp_init_tdm() has been called with a voice control block
of address 0x60B8562C. This function will be called only when the call is treated as a voice call.
Oct 18 04:05:07.052: csm_vtsp_init_tdm (voice_vdev=0x60B8562C)
The following shows that CSM has obtained a DSP channel from the DSP Resource Manager:
Oct 18 04:05:07.052: csm_vtsp_init_tdm: dsprm_tdm_allocate: tdm slot 1, dspm 2, dsp 5,
dsp_channel 1csm_vtsp_init_tdm: dsprm_tdm_allocate: tdm stream 5, channel 9, bank 0,
bp_channel 10
The DSP channel has the following initialized TDM channel information:
TDM slot 1, dspm 2, dsp 5, dsp_channel 1Indicates the physical DSP channel that will be used
for this call.
TDM stream 5, channel 9, bank 0, bp_channel 10Indicates the on-chip and backplane TDM
channel assigned to this DSP channel. Stream 5, channel 9 gives the on-chip TDM channel mapped
to the DSP; bank 0, bp_channel 10 means that the backplane stream 0 and backplane channel #1 are
assigned to this DSP.
The following shows that CSM has received an incoming call event from ISDN:
Oct 18 04:05:07.052: EVENT_FROM_ISDN:(00CF): DEV_INCALL at slot 1 and port 20
Slot 1, port 20 means the logical DSP channel 20 (mapped to DSPRM 2, DSP 5, DSP channel 1).
The following shows that the DEV_INCALL message has been translated into a
CSM_EVENT_ISDN_CALL message:
Oct 18 04:05:07.052: CSM_PROC_IDLE: CSM_EVENT_ISDN_CALL at slot 1, port 20
This message is passed to the CSM central state machine while it is in the CSM_IDLE state and is in the
CSM_PROC_IDLE procedure. The logical DSP channel port 20 on slot 1 is used to handle this call.
The following shows that CSM has invoked the vtsp_ic_notify() function with a CSM voice call control
block 0x60B8562C.
Oct 18 04:05:07.052: vtsp_ic_notify : (voice_vdev= 0x60B8562C)
Inside this function, CSM will send a SETUP INDICATION message to the VTSP. This function will be
invoked only if the call is a voice call.
The following shows that CSM has received a SETUP INDICATION RESPONSE message from the
VTSP as an acknowledgment.
Oct 18 04:05:07.056: csm_vtsp_call_setup_resp (vdev_info=0x60B8562C, vtsp_cdb=0x60FCA114)

May 2008 DB-485
Debug Commands
debug csm voice
This means that the VTSP has received the CALL SETUP INDICATION message previously sent and
has proceeded to process the call.
vdev_infoContains the address of the CSM voice data block.
The following shows that CSM has received a CALL CONNECT message from the VTSP:
Oct 18 04:05:07.596: csm_vtsp_call_connect (vtsp_cdb=0x60FCA114, voice_vdev=0x60B8562C)
This indicates that the VTSP has received a CONNECT message for the call leg initiated to the Internet
side.
voice_vdevContains the address of the CSM voice data block.
The following shows that while CSM is in the CSM_IC2_RING state, it receives a SETUP
INDICATION RESPONSE from the VTSP. This message is translated into
CSM_EVENT_MODEM_OFFHOOK and passed to the CSM central state machine.
Oct 18 04:05:07.596: CSM_PROC_IC2_RING: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 20
The following shows that CSM has received a CONNECT message from ISDN for the call using the
logical DSP channel on slot 1 and port 20:
Oct 18 04:05:07.616: EVENT_FROM_ISDN:(00CF): DEV_CONNECTED at slot 1 and port 20
The following shows that CSM has translated the CONNECT event from ISDN into the
CSM_EVENT_ISDN_CONNECTED message, which is then passed to the CSM central state machine:
Oct 18 04:05:07.616: CSM_PROC_IC4_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1,
port 20
The following shows that CSM has received a CALL SETUP REQUEST from the VTSP:
May 16 12:22:27.580: csm_vtsp_call_setup_request (vtsp_cdb=0x60FCFA20,
vtsp_sdb=0x60DFB608)
This represents a request to make an outgoing call to the PSTN.

vtsp_sdbContains the address of the signalling data block for the signalling interface to be used
to send the outgoing call.
The following shows that the physical DSP channel has been allocated for this outgoing call:
May 16 12:22:27.580: csm_vtsp_call_setup_request: tdm slot 1, dspm 5, dsp 4, dsp_channel 1
The following shows the on-chip and backplane TDM channel assigned to this DSP channel:
May 16 12:22:27.580: csm_vtsp_call_setup_request: tdm stream 5, channel 25, bank 0,
bp_channel 27
In this sample output, tdm stream 5, channel 25, bank 0, bp_channel 27 indicates the on-chip and
backplane TDM channel assigned to this DSP channel. Stream 5, channel 25 gives the on-chip TDM
channel mapped to the DSP; bank 0, bp_channel 27 means that the backplane stream 0 and backplane
channel 1 are assigned to this DSP.
The following shows the calling number and the called number for this call.
May 16 12:22:27.580: csm_vtsp_call_setup_request: calling number: 10001, called number:
30001

DB-486 May 2008
Debug Commands
debug csm voice
The following shows that the CALL SETUP REQUEST from the VTSP has been translated into the '
CSM_EVENT_MODEM_OFFHOOK message and is passed to the CSM central state machine:
May 16 12:22:27.580: CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 54
The logical DSP channel number for the DSP (slot 1, port 54) is now displayed, which maps to the
physical DSP channel slot 1, dspm 5, dsp 4, dsp_channel 1.
The following shows that CSM has collected all the digits for dialing out:
May 16 12:22:27.580: CSM_PROC_OC3_COLLECT_ALL_DIGIT: CSM_EVENT_GET_ALL_DIGITS at slot 1,

port 54
For PRI and for applications that do not require digit collection of outdialing digits (for example, voice
calls), the intermediate digit collection states are omitted and the CSM state machine moves to this state
directly, pretending that the digit collection has been done.
The following shows an information message:
May 16 12:22:27.580: CSM_PROC_OC3_COLLECT_ALL_DIGIT: called party num: (30001) at slot 1,
port 54
The following shows that CSM attempts to find a free signalling D channel to direct the outgoing call:
May 16 12:22:27.580: csm_vtsp_check_dchan (voice_vdev=0x60B8562C)
May 16 12:22:27.580: csm_vtsp_check_dchan (vtsp requested dchan=0x60D7ACB0,
dchan_idb=0x60E8ACF0)
May 16 12:22:27.580: csm_vtsp_check_dchan (voice_vdev=0x60B8562C)
May 16 12:22:27.580: csm_vtsp_check_dchan (vtsp requested dchan=0x60D7ACB0,
dchan_idb=0x60D7ACB0)
In the case of voice calls, the free signaling D channel must match the voice interface specified inside
the signalling data block (vtsp_sdb) passed from the VTSP.
The following shows that CSM has received an event from ISDN:
May 16 12:22:27.624: EVENT_FROM_ISDN::dchan_idb=0x60D7ACB0, call_id=0xA121, ces=0x1
In this sample output:

dchan_idbindicates the address of the hardware IDB for the D channel
call_idIndicates the call id assigned by ISDN
The following shows that CSM has received a CALL PROCEEDING message from ISDN.
May 16 12:22:27.624: EVENT_FROM_ISDN:(A121): DEV_CALL_PROC at slot 1 and port 54
The following shows that the CALL PROCEEDING event received from ISDN has been interpreted as
a CSM_EVENT_ISDN_BCHAN_ASSIGNED message:
*May 16 12:22:27.624: CSM_PROC_OC4_DIALING: CSM_EVENT_ISDN_BCHAN_ASSIGNED at slot 1, port
54
ISDN has assigned a B channel for this outgoing call. This B channel must be on the same PRI span as
the signalling D channel allocated previously.

May 2008 DB-487
Debug Commands
debug csm voice
The following shows that the csm_vtsp_setup_for_oc function is called:

May 16 12:22:27.624: csm_vtsp_setup_for_oc (voice_vdev=0x60B8562C)
This is invoked when an outgoing call initiated by the VTSP receives a response from the ISDN stack.
The following shows that ISDN has sent a CONNECT message to CSM indicating that the call leg to the
PSTN side has been established:
May 16 12:22:28.084: EVENT_FROM_ISDN::dchan_idb=0x60D7ACB0, call_id=0xA121, ces=0x1
May 16 12:22:28.084: EVENT_FROM_ISDN:(A121): DEV_CONNECTED at slot 1 and port 54
The following shows that while CSM is in the OC5_WAIT_FOR_CARRIER state, it has received the
'CONNECT' message from ISDN and has translated it into the CSM_EVENT_ISDN_CONNECTED
message, which is passed to the CSM central state machine:
May 16 12:22:28.084: CSM_PROC_OC5_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1,
port 54
The following shows that the function vtsp_confirm_oc() has been called:
May 16 12:22:28.084: vtsp_confirm_oc : (voice_vdev= 0x60B8562C)
This is invoked after CSM received the CONNECT message from ISDN. CSM sends a confirmation of
the CONNECT to the VTSP.

DB-488 May 2008
Debug Commands
debug ctl-client
debug ctl-client
To collect debug information about the CTL client, use the debug ctl-client command in privileged
EXEC configuration mode. To disable collection of debug information, use the no form of this
command.
debug ctl-client
no debug ctl-client
Command Default Collection of CTL client debug information is disabled.

Usage Guidelines This command is used with Cisco Unified CME phone authentication.
Examples The following example shows debug messages for the CTL client:
Router# debug ctl-client
001954: .Jul 21 18:23:02.136: ctl_client_create_ctlfile:

001955: .Jul 21 18:23:02.272: create_ctl_record: Function 0 Trustpoint cisco1
001956: .Jul 21 18:23:02.276: create_ctl_record: record added for function 0
001957: .Jul 21 18:23:02.276: create_ctl_record: Function 0 Trustpoint sast2
001965: .Jul 21 18:23:02.424: ctl_client_create_ctlfile: Signature length 128
001966: .Jul 21 18:23:02.640: CTL File Created Successfully

May 2008 DB-489
Debug Commands
debug ctunnel
debug ctunnel
To display debugging messages for the IP over a Connectionless Network Service (CLNS) Tunnel
feature, use the debug ctunnel command in privileged EXEC mode. To disable debugging messages, use
debug ctunnel
no debug ctunnel

Examples As packets are sent over the virtual interface, the following type of output will appear on the console
when the debug ctunnel command is used:
Router# debug ctunnel
4d21h: CTunnel1: IPCLNP encapsulated 49.0001.1111.1111.1111.00->49.0001.2222.2222.2222.00

(linktype=7, len=89)

DB-490 May 2008
Debug Commands
debug custom-queue
debug custom-queue
To enable custom queueing output, use the debug custom-queue command in privileged EXEC mode.
debug custom-queue
no debug custom-queue
Examples The following is an example of enabling custom queueing output:

Router# debug custom-queue
Custom output queueing debugging is on
The following is sample output from the debug custom-queue command:

00:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 1 now 1

debug priority Enables priority queueing output.

May 2008 DB-491
Debug Commands
debug dampening
debug dampening
To display debug trace information messages for interface dampening, use the debug dampening
debug dampening [all | interface]
no debug dampening [all | interface]
Syntax Description all (Optional) Enables trace debugging for all dampening features.
interface (Optional) Enables trace debugging for IP event dampening.

Examples The following sample output is similar to the output that will be displayed when the debug dampening
command is entered with the interface keyword. The sample output shows the following information:
Ethernet interface 1/1 is configured with the IP Event Dampening feature. The half-life period is set
to 30 seconds, the reuse threshold to 500, the suppress threshold to 1000, and the restart penalty to
90.
The shutdown command and then the no shutdown command was entered on Ethernet interface
1/1. The interface was suppressed and then reused by the IP Event Dampening feature.
Router# debug dampening interface
00:07:17:IF-EvD(Ethernet1/1):CLNS Routing reports state transition from UP to DOWN

00:07:17:EvD(Ethernet1/1):charge penalty 1000, new accum. penalty 1000, flap count 1
00:07:17:EvD(Ethernet1/1):accum. penalty 1000, now suppressed with a reuse intervals of 30
00:07:17:IF-EvD(Ethernet1/1):update CLNS Routing state to DOWN, interface is suppressed
00:07:17:IF-EvD(Ethernet1/1):IP Routing reports state transition from DOWN to DOWN
00:07:17:IF-EvD(Ethernet1/1):update IP Routing state to DOWN, interface is suppressed
00:07:17:IF-EvD(Ethernet1/1):CLNS Routing reports state transition from DOWN to UP

DB-492 May 2008
Debug Commands
debug dampening

00:07:17:EvD(Ethernet1/1):accum. penalty decayed to 1000 after 0 second(s)
00:07:17:IF-EvD(Ethernet1/1):IP Routing reports state transition from UP to UP
00:07:20:IF-EvD(Ethernet1/1):CLNS Routing reports state transition from UP to UP
00:07:47:IF-EvD:unsuppress interfaces
00:08:36:IF-EvD:unsuppress interfaces
00:08:36:EvD(Ethernet1/1):accum. penalty 483, now unsuppressed
00:08:36:IF-EvD(Ethernet1/1):update IP Routing state to UP, interface is not suppressed
00:08:36:IF-EvD(Ethernet1/1):update CLNS Routing state to UP, interface is not suppressed
00:08:36:IF-EvD(Ethernet1/1):CLNS Routing reports state transition from UP to UP
Table 70 debug dampening Field Descriptions
Field Description
... Routing reports state transition Displays the status of the specified interface from the perspective
from UP to DOWN of the specified protocol. Interface state changes are displayed.
The interface is specified within parentheses. The protocol is
specified at the beginning of the message.
charge penalty 1000, new accum. Displays the penalty assigned to the flapping interface and amount
penalty 1000, flap count 1 of penalty that is added to the accumulated penalty. The interface
flap count is also displayed.
accum. penalty 1000, now Displays the status of the interface, accumulated penalty, and
suppressed with a reuse intervals configured reuse threshold.
of 30
update CLNS Routing state to Displays the status of the specified interface. Interface state
DOWN, interface is suppressed changes and suppression status are displayed.
accum. penalty decayed to 1000 Displays the decay rate of the accumulated penalty.
after 0 second(s)
unsuppress interfaces Indicates that dampened interfaces have been unsuppressed.

May 2008 DB-493
Debug Commands
debug data-store
debug data-store
To display persistant storage device (PSD)-related debugging messages for the , use the debug
data-store command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug data-store
no debug data-store

12.3(14)YU This command was introduced.
12.4(2)XB This command was integrated into Cisco IOS Release 12.4(2)XB.
Usage Guidelines This command displays PSD-related debugging messages for the GGSN.
during periods of lower network flows and fewer users. Debugging during these periods reduces the
effect these commands have on other users on the system.
Examples The following example configures a debugging session to check PSD-related parameters:
Router# debug data-store

DB-494 May 2008
Debug Commands
debug data-store detail

To display extended details for persistent storage device (PSD)-related debugging information, use the
debug data-store detail command in privileged EXEC mode. To disable debugging output, use the no
no debug data-store detail

12.4(2)XB This command was integrated into Cisco IOS Release 12.4(2)XB.
Usage Guidelines This command displays PSD-related debugging messages for the GGSN.
Examples The following example configures a detailed PSD-related debugging session:

Router# debug data-store details

May 2008 DB-495
Debug Commands

auto-retrieve Configures the GGSN to automatically initiate a retrieval of G-CDRs from
PSDs defined in a PSD server group.
clear data-store Clears PSD-related statistics.
statistics
show data-store Displays the status of the PSD client and PSD server-related information.
show data-store Displays statistics related to the PSD client.
statistics

DB-496 May 2008
Debug Commands
debug dbconn all
debug dbconn all

To turn on all debug flags for Database Connection, use the debug dbconn all command in privileged
debug dbconn all
no debug dbconn all
Defaults Debugging is not enabled for Database Connection.
Usage Guidelines The debug dbconn all command displays debug output for Advanced Program-to-Program
Communication (APPC), Database Connection configuration, Distributed Relational Database
Architecture (DRDA), error messages, event traces, and TCP. The Database Connection debug flags are
appc, config, drda, event, and tcp.
Examples See the sample output provided for the debug dbconn appc, debug dbconn config, debug dbconn
drda, debug dbconn event, and debug dbconn tcp commands.

debug dbconn appc Displays APPC-related trace or error messages.
debug dbconn config Displays trace or error messages for Database Connection
configuration and control blocks.
debug dbconn drda Displays error messages and stream traces for DRDA.
debug dbconn event Displays trace or error messages for CTRC events related to DB2
communications.
debug dbconn tcp Displays error messages and traces for TCP.

May 2008 DB-497
Debug Commands
debug dbconn appc
debug dbconn appc

To display Advanced Program-to-Program Communication (APPC)-related trace or error messages, use
the debug dbconn appc command in privileged EXEC mode. To disable debugging output, use the no
debug dbconn appc
no debug dbconn appc
Usage Guidelines In a router with stable Database Connection, the alias_cp_name field in the trace message should not be
blank. There should be no other APPC error message. You can use Advanced Peer-to-Peer Networking
(APPN) debug commands with this debug command to track APPN-related errors.
Examples The following is sample output from the debug dbconn appc command. In a normal situation, only the
following message is displayed:
DBCONN-APPC: alias_cp_name is "ASH"
The following error messages are displayed if there is a network configuration error or other
APPN-related problem:
DBCONN-APPC-612C2B28: APPC error: opcode 0x1, primary_rc 0x0003,
secondary_rc 0x00000004
DBCONN-APPC-612C2B28: Verb block =
DBCONN-APPC-612C2B28: 0001 0200 0003 0000 0000 0004 0020 100C
DBCONN-APPC-612C2B28: 610A 828B 0000 0000 0000 0000 0000 0000
DBCONN-APPC-612C2B28: 0000 0000 8014 0003 0000 0000 0000 0000
DBCONN-APPC-612C2B28: D3E4 F6F2 E2E3 C1D9 C4C2 F240 4040 4040
DBCONN-APPC-612C2B28: 4040 4040 4040 4040 4040 4040 4040 4040
DBCONN-APPC-612C2B28: 4040 4040 4040 4040 4040 4040 4040 4040
DBCONN-APPC-612C2B28: 4040 4040 4040 4040 4040 4040 4040 4040
DBCONN-APPC-612C2B28: 4040 4040 4040 4040 0200 0000 0000 0000
DBCONN-APPC-612C2B28: 0000 0000 D4C5 D9D9 C9C5 4040 4040 D7C5
DBCONN-APPC-612C2B28: E3C5 D940 4040 4040 0000 0000 0000 0000
DBCONN-APPC-612C2B28: 00E2 E3C1 D9E6 4BE3 D6D9 C3C8 4040 4040
DBCONN-APPC-612C2B28: 4040 0000 0000 0000 0000 0000
DBCONN-APPC-612C2B28: ALLOCATE verb block =
DBCONN-APPC-612C2B28: 0001 0200 0003 0000 0000 0004 0020 100C
DBCONN-APPC-612C2B28: 610A 828B 0000 0000 0000 0000 0000 0000
DBCONN-APPC-612C2B28: 0000 0000 8014 0003 0000 0000 0000 0000
DBCONN-APPC-612C2B28: D3E4 F6F2 E2E3 C1D9 C4C2 F240 4040 4040
DBCONN-APPC-612C2B28: 4040 4040 4040 4040 4040 4040 4040 4040
DBCONN-APPC-612C2B28: 4040 4040 4040 4040 4040 4040 4040 4040
DBCONN-APPC-612C2B28: 4040 4040 4040 4040 4040 4040 4040 4040
DBCONN-APPC-612C2B28: 4040 4040 4040 4040 0200 0000 0000 0000

DB-498 May 2008
Debug Commands
debug dbconn appc
You can use the debug appn command to obtain more information.
The following message is displayed if a database connection is manually cleared and an outstanding
APPC verb is pending:
DBCONN-APPC-%612C2B28: Canceling pending APPC verb 0x1

debug dbconn all Turns on all debug flags for Database Connection.
debug dbconn event Displays trace or error messages for Database Connection events.

May 2008 DB-499
Debug Commands
debug dbconn config
debug dbconn config

To display trace or error messages for Database Connection configuration and control blocks, use the
debug dbconn config command in privileged EXEC mode. To disable debugging output, use the no
debug dbconn config
no debug dbconn config
Usage Guidelines Most of the messages for Database Connection and control blocks do not report any errors. If a
connection is inactive and cannot be cleared, use this command with the debug dbconn appc, debug
dbconn tcp, and debug appn commands to locate the problem. The alias_cp_name field must match the
configured APPN cpname.
Examples The following is sample output from the debug dbconn config command:
Router# debug dbconn config
DBCONN-CONFIG: alias_cp_name is "ASH "

DBCONN-CONFIG: connection 612BDAAC matching server on 198.147.235.5:0 with
rdbname=STELLA
DBCONN-CONFIG: APPN shutdown; clearing connection 1234abcd
DBCONN-CONFIG: created server 612C2720
DBCONN-CONFIG: server 612C2720 (listen 60F72E94) is active
DBCONN-CONFIG: server 612C2720 (listen 60F72E94) is active
DBCONN-CONFIG: new connection 612BDAAC
DBCONN-CONFIG: listen 60F72E94 accepts connection 612BDAAC
DBCONN-CONFIG: server 60F74614 takes connection 612BDAAC
DBCONN-CONFIG: listen 60F72E94 releases connection 612BDAAC
DBCONN-CONFIG: server 60F74614 releases connection 612BDAAC
DBCONN-CONFIG: deleting connection 612BDAAC
DBCONN-CONFIG: listen 60F72E94 abandons connection 612BDAAC
DBCONN-CONFIG: server 612C2720 abandons connection 612BDAAC
DBCONN-CONFIG: deleting server 612C2720
DBCONN-CONFIG: daemon 60381738 takes zombie connection 612BDAAC
DBCONN-CONFIG: daemon 60381738 releases zombie connection 612BDAAC

DB-500 May 2008
Debug Commands
debug dbconn config

debug dbconn event Displays trace or error messages for Database Connection
events.

May 2008 DB-501
Debug Commands
debug dbconn drda
debug dbconn drda

To display error messages and stream traces for Distributed Relational Database Architecture (DRDA),
use the debug dbconn drda command in privileged EXEC mode. To disable debugging output, use the
debug dbconn drda
no debug dbconn drda
Defaults Debugging is not enabled for the dbconn subsystem.

Examples The following is sample output from the debug dbconn drda command:
Router# debug dbconn drda
*Jun 30 16:09:32.363: DBCONN-DRDA-62008300: DSS X'006CD0410001', length 108, in chain,

REQDSS, correlator 1
*Jun 30 16:09:32.363: DBCONN-DRDA-62008300: OBJECT X'00661041', length 98, code point
X'1041'
*Jun 30 16:09:32.363: DBCONN-DRDA-62008300: OBJECT X'0020115E' in COLLECTION X'1041',
length 28, code point X'115E'
*Jun 30 16:09:32.363: DBCONN-DRDA-62008300: OBJECT X'000C116D' in COLLECTION X'1041',
length 8, code point X'116D'
*Jun 30 16:09:32.363: DBCONN-DRDA-62008300: OBJECT X'0013115A' in COLLECTION X'1041',
length 15, code point X'115A' (skipping...)


DB-502 May 2008
Debug Commands
debug dbconn drda
Command Description
communications.

May 2008 DB-503
Debug Commands
debug dbconn event
debug dbconn event

To display trace or error messages for Cisco Transaction Connection (CTRC) events related to
DATABASE2 (DB2) communications, use the debug dbconn event command in privileged EXEC
debug dbconn event
no debug dbconn event

Examples The following examples display output from the debug dbconn event command in a variety of
situations. A normal trace for the debug dbconn event displays as follows:
Router# debug dbconn event
DBCONN-EVENT: Dispatch to 60FD6C00, from 0, msg 60F754CC, msgid 6468 'dh',

buffer 0.
DBCONN-EVENT: [*] Post to 61134240(cn), from 60EC5470(tc), msg 611419E4,
msgid 0x6372 'cr', buffer 612BF68C.
DBCONN-EVENT: Flush events called for pto 61182742, pfrom 61239837.
DBCONN-EVENT: Event discarded: to 61182742 (cn), from 61239837(ap), msg
61339273, msgid 0x6372 'cr' buffer 0.
DBCONN-EVENT: == Send to 1234abcd, from 22938acd, msg 72618394, msgid
0x6372 'cr', buffer 0.
If the following messages are displayed, contact Cisco technical support personnel:
DBCONN-TCPFSM-1234abcd: Cannot occur in state 2 on input 6363 ('cc')
DBCONN-APPCFSM-1234abcd: Cannot occur in state 3 on input 6363 ('cc')

DB-504 May 2008
Debug Commands
debug dbconn event

debug dbconn config Display trace or error messages for Database Connection configuration and
control blocks.
show debugging Displays the state of each debugging option.

May 2008 DB-505
Debug Commands
debug dbconn tcp
debug dbconn tcp

To display error messages and traces for TCP, use the debug dbconn tcp command in privileged EXEC
debug dbconn tcp
no debug dbconn tcp

Examples The following is sample output from the debug dbconn tcp command:
Router# debug dbconn tcp
DBCONN-TCP-63528473: tcpdriver_passive_open returned NULL

DBCONN-TCP-63528473: (no memory) tcp_reset(63829482) returns 4
DBCONN-TCP: tcp_accept(74625348,&error) returns tcb 63829482, error 4
DBCONN-TCP: (no memory) tcp_reset(63829482) returns 4
DBCONN-TCP-63528473: (open) tcp_create returns 63829482, error = 4
DBCONN-TCP-63528473: tcb_connect(63829482,1.2.3.4,2010) returns 4
DBCONN-TCP-63528473: (open error) tcp_reset(63829482) returns 4
DBCONN-TCP-63528473: tcp_create returns 63829482, error = 4
DBCONN-TCP-63528473: tcb_bind(63829482,0.0.0.0,2001) returns 4
DBCONN-TCP-63528473: tcp_listen(63829482,,) returns 4
DBCONN-TCP-63528473: (errors) Calling tcp_close (63829482)


DB-506 May 2008
Debug Commands
debug dbconn tcp
Command Description
debug dbconn config Displays trace or error messages for Database Connection configuration
and control blocks.
communications.

May 2008 DB-507
Debug Commands
debug decnet adj
debug decnet adj

To display debugging information on DECnet adjacencies, use the debug decnet adj command in
debug decnet adj
no debug decnet adj
Examples The following is sample output from the debug decnet adj command:
Router# debug decnet adj
DNET-ADJ: Level 1 hello from 1.3

DNET-ADJ: sending hellos
DNET-ADJ: Sending hellos to all routers on interface Ethernet0, blksize 1498
DNET-ADJ: 1.5 adjacency initializing
DNET-ADJ: sending triggered hellos
DNET-ADJ: 1.5 adjacency up
DNET-ADJ: 1.5 adjacency down, listener timeout
The following line indicates that the router is sending hello messages to all routers on this segment,
which in this case is Ethernet 0:
The following line indicates that the router has heard a hello message from address 1.5 and is creating
an adjacency entry in its table. The initial state of this adjacency will be initializing.
DNET-ADJ: 1.5 adjacency initializing
The following line indicates that the router is sending an unscheduled (triggered) hello message as a
result of some event, such as new adjacency being heard:
DNET-ADJ: sending triggered hellos
The following line indicates that the adjacency with 1.5 is now up, or active:
DNET-ADJ: 1.5 adjacency up
The following line indicates that the adjacency with 1.5 has timed out, because no hello message has
been heard from adjacency 1.5 in the time interval originally specified in the hello message from 1.5:
DNET-ADJ: 1.5 adjacency down, listener timeout

DB-508 May 2008
Debug Commands
debug decnet adj
The following line indicates that the router is sending an unscheduled hello message, as a result of some
event, such as the adjacency state changing:
DNET-ADJ: hello update triggered by state changed in dn_add_adjacency

May 2008 DB-509
Debug Commands
debug decnet connects

To display debugging information of all connect packets that are filtered (permitted or denied) by
DECnet access lists, use the debug decnet connects command in privileged EXEC mode. To disable
no debug decnet connects
Usage Guidelines When you use connect packet filtering, it may be helpful to use the decnet access-group configuration
command to apply the following basic access list:
access-list 300 permit 0.0 63.1023 eq any
You can then log all connect packets sent on interfaces to which you applied this list, in order to
determine those elements on which your connect packets must be filtered.
Note Packet password and account information is not logged in the debug decnet connects message, nor is it
displayed by the show access EXEC command. If you specify password or account information in your
access list, they can be viewed by anyone with access to the configuration of the router.
Examples The following is sample output from the debug decnet connects command:
Router# debug decnet connects
DNET-CON: list 300 item #2 matched src=19.403 dst=19.309 on Ethernet0: permitted

srcname=RICK srcuic=[0,017]
dstobj=42 id=USER
Table 71 describes significant fields shown in the output.
Table 71 debug decnet connects Field Descriptions
Field Description
DNET-CON: Indicates that this is a debug decnet connects packet.
list 300 item #2 matched Indicates that a packet matched the second item in access list 300.
src=19.403 Indicates the source DECnet address for the packet.
dst=19.309 Indicates the destination DECnet address for the packet.
on Ethernet0: Indicates the router interface on which the access list filtering the
packet was applied.
permitted Indicates that the access list permitted the packet.

DB-510 May 2008
Debug Commands
Table 71 debug decnet connects Field Descriptions (continued)
Field Description
srcname = RICK Indicates the originator user of the packet.
srcuic=[0,017] Indicates the source UIC of the packet.
dstobj=42 Indicates that DECnet object 42 is the destination.
id=USER Indicates the access user.

May 2008 DB-511
Debug Commands
debug decnet events
debug decnet events

To display debugging information on DECnet events, use the debug decnet events command in
debug decnet events
no debug decnet events
Examples The following is sample output from the debug decnet events command:
Router# debug decnet events
DNET: Hello from area 50 rejected - exceeded max area' parameter (45)
DNET: Hello from area 50 rejected - exceeded max area' parameter (45)
The following line indicates that the router received a hello message from a router whose area was
greater than the max-area parameter with which this router was configured:
DNET: Hello from area 50 rejected - exceeded'max area' parameter (45)
The following line indicates that the router received a hello message from a router whose node ID was
greater than the max-node parameter with which this router was configured:
DNET: Hello from node 1002 rejected - exceeded'max node' parameter (1000)

DB-512 May 2008
Debug Commands
debug decnet packet
debug decnet packet

To display debugging information on DECnet packet events, use the debug decnet packet command in
debug decnet packet
no debug decnet packet
Examples The following is sample output from the debug decnet packet command:
Router# debug decnet packet
DNET-PKT: src 1.4 dst 1.5 sending to PHASEV

DNET-PKT: Packet fwded from 1.4 to 1.5, via 1.5, snpa 0000.3080.cf90, TokenRing0
The following line indicates that the router is sending a converted packet addressed to node 1.5 to
Phase V:
DNET-PKT: src 1.4 dst 1.5 sending to PHASEV
The following line indicates that the router forwarded a packet from node 1.4 to node 1.5. The packet is
being sent to the next hop of 1.5 whose subnetwork point of attachment (MAC address) on that interface
is 0000.3080.cf90.
DNET-PKT: Packet fwded from 1.4 to 1.5, via 1.5, snpa 0000.3080.cf90, TokenRing0

May 2008 DB-513
Debug Commands
debug decnet routing

To display all DECnet routing-related events occurring at the router, use the debug decnet routing
no debug decnet routing
Examples The following is sample output from the debug decnet routing command:
Router# debug decnet routing
DNET-RT: Received level 1 routing from 1.3 on Ethernet0 at 1:16:34

DNET-RT: Sending routes
DNET-RT: Sending normal routing updates on Ethernet0
DNET-RT: Sending level 1 routing updates on interface Ethernet0
DNET-RT: Level1 routes from 1.5 on Ethernet0: entry for node 5 created
DNET-RT: route update triggered by after split route pointers in dn_rt_input
DNET-RT: Received level 1 routing from 1.5 on Ethernet 0 at 1:18:35
DNET-RT: Sending L1 triggered routes
DNET-RT: Sending L1 triggered routing updates on Ethernet0
DNET-RT: removing route to node 5
The following line indicates that the router has received a level 1 update on Ethernet interface 0:
DNET-RT: Received level 1 routing from 1.3 on Ethernet0 at 1:16:34
The following line indicates that the router is sending its scheduled updates on Ethernet interface 0:
DNET-RT: Sending normal routing updates on Ethernet0
The following line indicates that the route will send an unscheduled update on this interface as a result
of some event. In this case, the unscheduled update is a result of a new entry created in the routing table
of the interface.
DNET-RT: route update triggered by after split route pointers in dn_rt_input
The following line indicates that the router sent the unscheduled update on Ethernet 0:
DNET-RT: Sending L1 triggered routes
DNET-RT: Sending L1 triggered routing updates on Ethernet0
The following line indicates that the router removed the entry for node 5 because the adjacency with
node 5 timed out, or the route to node 5 through a next-hop router was disconnected:
DNET-RT: removing route to node 5

DB-514 May 2008
Debug Commands
debug dhcp redundancy

To display debugging information about DHCP proxy client redundancy events, use the debug dhcp
redundancy command in privileged EXEC mode. To disable the display of debugging output, use the
no debug dhcp redundancy
Command Default Debugging output is disabled for DHCP redundancy events.

Examples The following example displays debug messages regarding DHCP redundancy events. The last line is
output when the debug dhcp redundancy command is enabled. The line indicates that the active Route
Processor has sent a dynamic lease synchronization message for IP address 10.1.1.1:
Router# debug dhcp redundancy
*Mar 15 10:32:21: DHCPD: assigned IP address 10.1.1.1 to client

*Mar 15 10:32:21: DHCPD: dynamic sync sent for 10.1.1.1

debug ip dhcp server Displays debugging information about DHCP server and relay agent
redundancy redundancy events.

May 2008 DB-515
Debug Commands
debug dhcp
debug dhcp
To display debugging information about the Dynamic Host Configuration Protocol (DHCP) client
activities and to monitor the status of DHCP packets, use the debug dhcp command in privileged EXEC
debug dhcp [detail]
no debug dhcp [detail]
Syntax Description detail (Optional) Displays additional debugging information.

12.3(8)T The output of this command was enhanced to display default static routes.
Usage Guidelines You can also use the debug dhcp command to monitor the subnet allocation and releasing for on-demand
address pools.
For debugging purposes, the debug dhcp detail command provides the most useful information such as
the lease entry structure of the client and the state transitions of the lease entry. The debug output shows
the scanned option values from received DHCP messages that are replies to a router request. The values
of the op, htype, hlen, hops, server identifier option, xid, secs, flags, ciaddr, yiaddr, siaddr, and giaddr
fields of the DHCP packet are shown in addition to the length of the options field.
Examples The following examples show and explain some of the typical debugging messages you may see when
using the debug dhcp detail command.
The following sample output shows when a DHCP client sends a DHCPDISCOVER broadcast message
to find its local DHCP server:
Router# debug dhcp detail
00:07:16:DHCP:DHCP client process started:10

00:07:16:RAC:Starting DHCP discover on Ethernet2
00:07:16:DHCP:Try 1 to acquire address for Ethernet2
00:07:19:DHCP:Shutting down from get_netinfo()
00:07:19:DHCP:Attempting to shutdown DHCP Client
00:07:21:DHCP:allocate request
00:07:21:DHCP:new entry. add to queue

DB-516 May 2008
Debug Commands
debug dhcp
00:07:21:DHCP:SDiscover attempt # 1 for entry:
The first seven lines of the following output show the current values stored in the lease entry structure
for the client:
00:07:21:Temp IP addr:0.0.0.0 for peer on Interface:Ethernet2
00:07:21:Temp sub net mask:0.0.0.0
00:07:21: DHCP Lease server:0.0.0.0, state:1 Selecting
00:07:21: DHCP transaction id:582
00:07:21: Lease:0 secs, Renewal:0 secs, Rebind:0 secs
00:07:21: Next timer fires after:00:00:03
00:07:21: Retry count:1 Client-ID:cisco-0010.7b6e.afd8-Et2
00:07:21:DHCP:SDiscover:sending 308 byte length DHCP packet
00:07:21:DHCP:SDiscover 308 bytes
00:07:21: B'cast on Ethernet2 interface from 0.0.0.0
The following output shows the offered addresses and parameters sent to the DHCP client by the DHCP
server via a DHCPOFFER message. The messages containing the Scan field indicate the options that
were scanned from the received BOOTP packet and the corresponding values:
00:07:23:DHCP:Received a BOOTREP pkt
00:07:23:DHCP:Scan:Message type:DHCP Offer
00:07:23:DHCP:Scan:Server ID Option:10.1.1.1 = A010101
00:07:23:DHCP:Scan:Lease Time:180
00:07:23:DHCP:Scan:Renewal time:90
00:07:23:DHCP:Scan:Rebind time:157
00:07:23:DHCP:Scan:Subnet Address Option:255.255.255.0
The following output shows selected fields in the received BOOTP packet:
00:07:23:DHCP:rcvd pkt source:10.1.1.1, destination: 255.255.255.255
00:07:23: UDP sport:43, dport:44, length:308
00:07:23: DHCP op:2, htype:1, hlen:6, hops:0
00:07:23: DHCP server identifier:10.1.1.1
00:07:23: xid:582, secs:0, flags:8000
00:07:23: client:0.0.0.0, your:10.1.1.2
00:07:23: srvr: 0.0.0.0, gw:0.0.0.0
00:07:23: options block length:60
00:07:23:DHCP Offer Message Offered Address:10.1.1.2

00:07:23:DHCP:Lease Seconds:180 Renewal secs: 90 Rebind secs:157
00:07:23:DHCP:Server ID Option:10.1.1.1
00:07:23:DHCP:offer received from 10.1.1.1
The following output shows when the DHCP client sends a DHCPREQUEST broadcast message to the
DHCP server to accept the offered parameters:
00:07:23:DHCP:SRequest attempt # 1 for entry:
00:07:23:Temp IP addr:10.1.1.2 for peer on Interface:Ethernet2
00:07:23:Temp sub net mask:255.255.255.0
00:07:23: DHCP Lease server:10.1.1.1, state:2 Requesting
00:07:23: DHCP transaction id:582
00:07:23: Lease:180 secs, Renewal:0 secs, Rebind:0 secs
00:07:23: Next timer fires after:00:00:02
00:07:23: Retry count:1 Client-ID:cisco-0010.7b6e.afd8-Et2
00:07:23:DHCP:SRequest- Server ID option:10.1.1.1
00:07:23:DHCP:SRequest- Requested IP addr option:10.1.1.2
00:07:23:DHCP:SRequest placed lease len option:180
00:07:23:DHCP:SRequest:326 bytes
00:07:23:DHCP:SRequest:326 bytes
00:07:23: B'cast on Ethernet2 interface from 0.0.0.0

May 2008 DB-517
Debug Commands
debug dhcp
The following output shows when the DHCP server sends a DHCPACK message to the client with the
full set of configuration parameters:
00:07:23:DHCP:Received a BOOTREP pkt
00:07:23:DHCP:Scan:Message type:DHCP Ack
00:07:23:DHCP:Scan:Server ID Option:10.1.1.1 = A010101
00:07:23:DHCP:Scan:Lease Time:180
00:07:23:DHCP:Scan:Renewal time:90
00:07:23:DHCP:Scan:Rebind time:157
00:07:23:DHCP:Scan:Subnet Address Option:255.255.255.0
00:07:23:DHCP:rcvd pkt source:10.1.1.1, destination: 255.255.255.255
00:07:23: UDP sport:43, dport:44, length:308
00:07:23: DHCP op:2, htype:1, hlen:6, hops:0
00:07:23: DHCP server identifier:10.1.1.1
00:07:23: xid:582, secs:0, flags:8000
00:07:23: client:0.0.0.0, your:10.1.1.2
00:07:23: srvr: 0.0.0.0, gw:0.0.0.0
00:07:23: options block length:60
00:07:23:DHCP Ack Message

00:07:23:DHCP:Lease Seconds:180 Renewal secs: 90 Rebind secs:157
00:07:23:DHCP:Server ID Option:10.1.1.1Interface Ethernet2 assigned DHCP address 10.1.1.2,
mask 255.255.255.0
00:07:26:DHCP Client Pooling:***Allocated IP address:10.1.1.2

00:07:26:Allocated IP address = 10.1.1.2 255.255.255.0
The following output shows when a default gateway (option 3) is assigned a static IP address that is the
default route and that static routes were added from the DHCP server:
*Oct 2 06:22:24: Setting default_gateway to 68.8.8.1 ! This is the option 3 default
gateway.
*Oct 2 06:22:24: Adding default route 68.8.8.1
*Oct 2 06:22:24: DHCP: Adding static route to 4.3.2.1 255.255.255.255 via 68.8.8.1
Most fields are self-explanatory; however, fields that may need further explanation are described in
Table 72.
Table 72 debug dhcp Field Descriptions
Fields Description
DHCP:Scan:Subnet Address Option:255.255.255.0 Subnet mask option (option 1).
DHCP server identifier:1.1.1.1 Value of the DHCP server ID option (option 54).
Note that this is not the same as the siaddr field,
which is the server IP address.
srvr:0.0.0.0, gw:0.0.0.0 srvr is the value of the siaddr field. gw is the
value of the giaddr field.

debug ip ddns update Enables debugging for DDNS updates.
debug ip dhcp server Enables DHCP server debugging.
host (host-list) Specifies a list of hosts that will receive DDNS updates of A and PTR RRs.
ip ddns update Enables a host to be used for DDNS updates of A and PTR RRs.
hostname

DB-518 May 2008
Debug Commands
debug dhcp
Command Description
ip ddns update method Specifies a method of DDNS updates of A and PTR RRs and the maximum
interval between the updates.
ip dhcp client update Enables DDNS updates of A RRs using the same hostname passed in the
dns hostname and FQDN options by a client.
ip dhcp-client update Enables DDNS updates of A RRs using the same hostname passed in the
ip dhcp update dns Enables DDNS updates of A and PTR RRs for most address pools.
ip host-list Specifies a list of hosts that will receive DDNS updates of A and PTR RRs.
show ip ddns update Displays information about the DDNS updates.
show ip ddns update Displays information about the DDNS update method.
method
show ip dhcp server Displays DHCP server pool statistics.
pool
show ip host-list Displays the assigned hosts in a list.
update dns Dynamically updates a DNS with A and PTR RRs for some address pools.

May 2008 DB-519
Debug Commands
debug dialer events
debug dialer events

To display debugging information about the packets received on a dialer interface, use the debug dialer
command.
debug dialer events
no debug dialer events
Usage Guidelines When dial-on-demand routing (DDR) is enabled on the interface, information concerning the cause of
any call (called the Dialing cause) is displayed.
Examples In the following example, the line of output for an IP packet lists the name of the DDR interface and the
source and destination addresses of the packet:
Router# debug dialer events
Dialing cause: Serial0: ip (s=172.16.1.111 d=172.16.2.22)
The following line of output for a bridged packet lists the DDR interface and the type of packet (in
hexadecimal). For information on these packet types, see the Ethernet Type Codes appendix of the
Cisco IOS Bridging and IBM Networking Command Reference publication.
Dialing cause: Serial1: Bridge (0x6005)
Most messages are self-explanatory; however, messages that may need some explanation are described
in Table 73.
Table 73 debug dialer events Message Descriptions
Message Description
Dialer0: Already xxx call(s) in progress Number of calls in progress (xxx) exceeds the maximum
on Dialer0, dialing not allowed number of calls set on the interface.
Dialer0: No free dialer - starting fast All the lines in the interface or rotary group are busy, and a
idle timer packet is waiting to be sent to the destination.
BRI0: rotary group to xxx overloaded Number dialer (xxx) exceeds the load set on the interface
(yyy) (yyy).
BRI0: authenticated host xxx with no No dialer profile matches xxx, the Challenge Handshake
matching dialer profile Authentication Protocol (CHAP) name or remote name of
the remote host.

DB-520 May 2008
Debug Commands
debug dialer events
Table 73 debug dialer events Message Descriptions (continued)
Message Description
BRI0: authenticated host xxx with no No dialer map matches xxx, the CHAP name or remote name
matching dialer map of the remote host.
BRI0: Cant place call, verify Dialer string or dialer pool on an interface not set.
configuration
Table 74 describes the messages that the debug dialer events command can generate for a serial
interface used as a V.25bis dialer for DDR.
Table 74 debug dialer events Command Message Descriptions for DDR
Message Description
Serial 0: Dialer result = xxxxxxxxxx Result returned from the V.25bis dialer. It is useful in debugging
if calls are failing. On some hardware platforms, this message
cannot be displayed due to hardware limitations. Possible values
for the xxxxxxxxxx variable depend on the V.25bis device with
which the router is communicating.
Serial 0: No dialer string defined. Packet is received that should cause a call to be placed.
Dialing cannot occur. However, no dialer string is configured, so dialing cannot occur.
This message usually indicates a configuration problem.
Serial 0: Attempting to Packet has been received that passes the dial-on-demand access
dial xxxxxxxxxx lists. That packet causes phone number xxxxxxxxxx to be dialed.
Serial 0: Unable to dial xxxxxxxxxx Phone call to xxxxxxxxxx cannot be placed. This failure might be
due to a lack of memory, full output queues, or other problems.
Serial 0: disconnecting call Router hangs up a call.
Serial 0: idle timeout One of these three messages is displayed when a dialer timer
expires. These messages are mostly informational, but are useful
Serial 0: re-enable timeout
for debugging a disconnected call or call failure.
Serial 0: wait for carrier timeout

debug decnet packet Displays debugging information about the packets received on a
dialer interface.

May 2008 DB-521
Debug Commands
debug dialer forwarding

To display debugging information about the control plane at the home gateway (HGW) for Layer 2
Tunneling Protocol (L2TP) dialout, use the debug dialer forwarding command in privileged EXEC
mode. The no form of this command disables debugging output.
no debug dialer forwarding
Defaults This command is disabled by default.

in a specific 12.2SX release of this train depends on your feature set, platform,
and platform hardware.
Usage Guidelines Use the debug dialer forwarding command to configure a virtual private dialout network (VPDN) on
the HGW and a network access server (NAS) to dial from the HGW to the client.
An L2TP tunnel is created between the HGW and the NAS and the packets are forwarded transparently
at the NAS.
Examples The following is sample output from the debug dialer forwarding command for dialing from the HGW
to the client.
Note DDR-FWD is debug dialer forwarding information. (DDR= dial-on-demand routing.)
Router# debug dialer forwarding
Dialer forwarding events debugging is on
Router# ping
Protocol [ip]:
Target IP address:1.1.1.3
Repeat count [5]:1
Datagram size [100]:

DB-522 May 2008
Debug Commands
Timeout in seconds [2]:

Extended commands [n]:
Sweep range of sizes [n]:
1d00h:Vi3 DDR-FWD 83093A60:event [REQUEST] state before [IDLE]

1d00h:Vi3 DDR-FWD 83093A60:VPN Authorization started
1d00h:Vi3 DDR-FWD 83093A60:VPN author result 1
1d00h:Vi3 DDR-FWD 83093A60:event [AUTHOR FOUND] state before [AUTHORIZING]
1d00h:Vi3 DDR-FWD 83093A60:event [FORWARDED] state before [FORWARDING]
1d00h:Vi3 DDR-FWD 83093A60:Connection is up, start LCP now
*Mar 2 00:31:33:%LINK-3-UPDOWN:Interface Virtual-Access3, changed state to up.
R2604#
*Mar 2 00:31:35:%LINEPROTO-5-UPDOWN:Line protocol on Interface Virtual-Access3, changed
state to up
Router#
Outgoing call disconnected:

Router#
1d00h:Vi3 DDR-FWD 83093A60:event [VPDN DISC] state before [FORWARDED]
*Mar 2 00:33:33:%LINK-3-UPDOWN:Interface Virtual-Access3, changed state to down
*Mar 2 00:33:34:%LINEPROTO-5-UPDOWN:Line protocol on Interface Virtual-Access3, changed
state to down

debug dialer events Displays debugging information about events on a dialer interface.
debug dialer packets Displays debugging information about packets received on a dialer
interface.

May 2008 DB-523
Debug Commands
debug dialer map
debug dialer map

To display debugging information about the creation and deletion of dynamic dialer maps, use the debug
dialer map command in privileged EXEC mode. The no form of this command disables debugging
output.
debug dialer map
no debug dialer map

12.1(5.1) This command was introduced.
Usage Guidelines Use the debug dialer map command to track large-scale dialout (LSDO) and incoming calls that use
dynamic dialer maps. This command shows the whole trace including when the map is created and
removed.
If an interface is configured for dial-on-demand routing (DDR), and a map to a specified address does
not exist, then a dynamic dialer map is created and when the call disconnects, the dialer map is removed.
Note Do not configure a dialer string or a dialer map on the incoming interface.
Examples In the following sample output from the debug dialer map command, a dialer map is created when an
incoming call is connected and removed when that call is disconnected:
Router# debug dialer map
Dial on demand dynamic dialer maps debugging is on
Incoming call connected:

Router#
*Mar 22 12:19:15.597:%LINK-3-UPDOWN:Interface BRI0/0:1, changed state to up
*Mar 22 12:19:17.748:BR0/0:1 DDR:dialer_create_dynamic_map map created for 11.0.0.1

DB-524 May 2008
Debug Commands
debug dialer map
*Mar 22 12:19:18.734:%LINEPROTO-5-UPDOWN:Line protocol on Interface BRI0/0:1, changed

state to up
*Mar 22 12:19:21.598:%ISDN-6-CONNECT:Interface BRI0/0:1 is now connected to unknown R2604
Incoming call disconnected:

Router#
*Mar 22 12:21:15.597:%ISDN-6-DISCONNECT:Interface BRI0/0:1 disconnected from R2604, call
lasted 120 seconds
*Mar 22 12:21:15.645:%LINK-3-UPDOWN:Interface BRI0/0:1, changed state to down
*Mar 22 12:21:15.649:BR0/0:1 DDR:dialer_remove_dynamic_map map 11.0.0.1 removed
*Mar 22 12:21:16.647:%LINEPROTO-5-UPDOWN:Line protocol on Interface BRI0/0:1, changed
state to down

debug dialer events Displays debugging information about events on a dialer interface.
debug dialer packets Displays debugging information about packets received on a dialer
interface.

May 2008 DB-525
Debug Commands
debug dialpeer
debug dialpeer
Note Effective with release 12.3(8)T, the debug dialpeer command is replaced by the debug voip dialpeer
command. See the debug voip dialpeer command for more information.
To view dial peer information, use the debug dialpeer command in privileged EXEC mode. To disable
debug dialpeer
no debug dialpeer
Defaults Disabled

12.3(8)T This command was replaced by the debug voip dialpeer command.
Usage Guidelines Disable console logging and use buffered logging before using the debug dialpeer command. Using the
debug dialpeer command generates a large volume of debugging messages, which can affect router
performance.
Examples The following is sample output for the debug dialpeer command. The output shows the destination
pattern configured on the matched dial-peer. Expanded string is the string after applying number
translation to the original number. It shows that dial-peer 1311 was an incoming dial-peer match. It also
shows that routing label was att1. It shows that dial-peer 5108888 and 111399 are an outgoing dial-peer
match.
Router# debug dialpeer
Router#
00:22:28: Inside dpMatchCore:
00:22:28: destination pattn:5108880101 expanded string:5108880101
00:22:28:MatchNextPeer:Peer 1311 matched

DB-526 May 2008
Debug Commands
debug dialpeer

00:22:28: dpAssociateIncomingPeer_T:Matching route label att1
00:22:28: dpAssociateIncomingPeer_T:Matching peer with src route label att1 failed
00:22:28: Inside dpMatchPeersMoreArg
00:22:28:dpMatchPeersMoreArg:Match Dest. pattern; called (5108880101)
00:22:28: destination pa
Router#ttn:5108880101 expanded string:5108880101
00:22:28:dpMatchPeersMoreArg:Result=0 after MATCH_ORIGINATE
Table 75 debug dialpeer Field Descriptions
Field Description
destination pattn Destination pattern configured on the dial peer.
expanded string The string after applying number translation to the original number.
Match Dest. pattern; called Indicates that dial-peer match is going to match destination pattern
against the called number.
Matching route label The trunk group label or carrier id that is used for matching a dial peer.
MatchNextPeer Indicates the dial peer tag that matched.
Result Indicates the result of dial peer matching algorithm:
0 = Successful
1 = More digits needed for a possible match
-1 = No match (match failed)
-2 = The digits matched, but the destination address could not
be obtained

call-block (dial peer) Enables blocking of incoming calls on the dial peer.
carrier-id (dial-peer) Identifies the carrier handling the incoming call.
session target (ENUM) Specifies the ENUM search table for the target session.
show dial-peer voice Displays the configuration of the dial peer.
translation-profile (dial-peer) Assigns a translation profile to the dial peer.
trunkgroup (dial-peer) Assigns a trunk group to the dial peer.
trunk-group-label (dial-peer) Identifies the trunk group handling the incoming call.

May 2008 DB-527
Debug Commands
debug diameter
debug diameter
To display information about the Diameter Protocol, use the debug diameter command in privileged
debug diameter [dcca | connection | error | packet | event | fsm | failover]
no debug diameter [dcca | connection | error | packet | event | fsm | failover]
Syntax Description dcca (Optional) Enables debugging for Diameter-Credit Control Accounting.
connection (Optional) Enables debugging output for the connection between two
Diameter nodes.
error (Optional) Enables debugging output for Diameter errors.
packet (Optional) Enables debugging output for Diameter data packets.
event (Optional) Enables debugging output for Diameter events.
fsm (Optional) Enables debugging output for the finite state machine.
failover (Optional) Enables debugging output for Diameter redundancy.

Usage Guidelines Use this command to display information about any of the listed classes of information about the
Diameter Protocol.
Examples The following examples show output from the debug diameter command:
Peer configuration and peer connection after a peer is configured

Router# debug diameter all
*May 9 17:58:14.832: Dia Base: Diameter Peer configured. Allocate connection context.
*May 9 17:58:14.832: Dia Base: Allocate the peer connection context 50F63888, handle
C000000C *May 9 17:58:14.832: Dia Base: (C000000C): Received peer configuration event
*May 9 17:58:14.832: Dia Peer FSM (50F63888): input event START in state CLOSED *May 9
17:58:14.832: Dia Peer FSM (50F63888): Starting Connection timer *May 9 17:58:14.832: Dia
Peer FSM (50F63888): event START, state
CLOSED-->WAIT_CONN_ACK
*May 9 17:58:14.836: Dia Transport: socket 0 - connecting to 9.113.33.6
(3868)
*May 9 17:58:14.836: Dia Transport: socket 0 - connection in progress *May 9
17:58:14.836: Dia Transport: socket 0 - local address 9.113.33.5

DB-528 May 2008
Debug Commands
debug diameter
(49214)
*May 9 17:58:14.836: Dia Transport: socket 0 - resume socket write - nothing to write
*May 9 17:58:14.836: Dia Base: (C000000C): Received peer connection event from transport
*May 9 17:58:14.836: Dia Peer FSM (50F63888): input event RCV_CONN_ACK in state
WAIT_CONN_ACK *May 9 17:58:14.836: Dia Base: Sending diameter message to peer "Unknown"
*May 9 17:58:14.836: DIAMETER: CER message, ver=1, len=120, app=0,
[2328318322/2328318322]
*May 9 17:58:14.836: DIAMETER: Origin-host-name [264]
"host" (M)
*May 9 17:58:14.836: DIAMETER: Origin-Realm [296]
"cisco" (M)
*May 9 17:58:14.836: DIAMETER: Host-IP-address [257]
9.113.33.5 (M)
*May 9 17:58:14.836: DIAMETER: Vendor-ID [266] 9
(M)
*May 9 17:58:14.836: DIAMETER: Product-name [269]
"C7200-G8IS-M"
*May 9 17:58:14.836: DIAMETER: Auth-Application-ID [258] 4
(M)
*May 9 17:58:14.836: DIAMETER: Firmware-Revision [267] 1
50D0B710: 01000078 80000101 00000000 ...x........

50D0B720: 8AC75172 8AC75172 00000108 4000000C .GQr.GQr....@...
50D0B730: 686F7374 00000128 4000000D 63697363 host...(@...cisc
50D0B740: 6F000000 00000101 4000000E 00010971 o.......@......q
50D0B750: 21050000 0000010A 4000000C 00000009 !.......@.......
50D0B760: 0000010D 00000014 43373230 302D4738 ........C7200-G8
50D0B770: 49532D4D 00000102 4000000C 00000004 IS-M....@.......
50D0B780: 0000010B 0000000C 00000001 00 .............
*May 9 17:58:14.836: Dia Base: Request message hash ctx created for
[2328318322/2328318322] *May 9 17:58:14.836: Dia Peer FSM (50F63888): Starting CER timer
*May 9 17:58:14.836: Dia Peer FSM (50F63888): event RCV_CONN_ACK, state
WAIT_CONN_ACK-->WAIT_CEA *May 9 17:58:14.836: Dia Transport: Dia Transport write message
event *May 9 17:58:14.836: Dia Transport: socket 0 - complete msg sent *May 9
17:58:14.840: Dia Transport: socket 0 - complete read of 20 bytes *May 9 17:58:14.840:
Dia Transport: complete header read from socket 0 *May 9 17:58:14.840: Dia Transport:
read msg (172) bytes from socket 0 *May 9 17:58:14.840: Dia Transport: socket 0 -
complete read of 172 bytes *May 9 17:58:14.840: Dia Base: Diameter message received from
the peer "Unknown"
*May 9 17:58:14.840: DIAMETER: CEA message, ver=1, len=192, app=0,
[2328318322/2328318322]
*May 9 17:58:14.840: DIAMETER: Result-code [268]
2001 (M)
"diameter2.cisco.com" (M)
"cisco.com" (M)
*May 9 17:58:14.840: DIAMETER: Host-IP-address [257]
10.77.154.80 (M)
*May 9 17:58:14.840: DIAMETER: Vendor-ID [266] 9
(M)
*May 9 17:58:14.840: DIAMETER: Product-name [269]
"Diameter-Server"
*May 9 17:58:14.840: DIAMETER: Supported-Vendor-ID [265]
10415 (M)
*May 9 17:58:14.840: DIAMETER: Supported-Vendor-ID [265]
12645 (M)
*May 9 17:58:14.840: DIAMETER: Supported-Vendor-ID [265] 9
(M)
*May 9 17:58:14.840: DIAMETER: Supported-Vendor-ID [265] 9
(M)

May 2008 DB-529
Debug Commands
debug diameter
*May 9 17:58:14.840: DIAMETER: Auth-Application-ID [258] 4

(M)
65940780: 010000C0 00000101 00000000 ...@........
65940790: 8AC75172 8AC75172 0000010C 4000000C .GQr.GQr....@...
659407A0: 000007D1 00000108 4000001B 6469616D ...Q....@...diam
659407B0: 65746572 322E6369 73636F2E 636F6D00 eter2.cisco.com.
659407C0: 00000128 40000011 63697363 6F2E636F ...(@...cisco.co
659407D0: 6D000000 00000101 4000000E 00010A4D m.......@......M
659407E0: 9A500000 0000010A 4000000C 00000009 .P......@.......
659407F0: 0000010D 00000017 4469616D 65746572 ........Diameter
65940800: 2D536572 76657200 00000109 4000000C -Server.....@...
65940810: 000028AF 00000109 4000000C 00003165 ..(/....@.....1e
65940820: 00000109 4000000C 00000009 00000109 ....@...........
65940830: 4000000C 00000009 00000102 4000000C @...........@...
65940840: 00000004 00 .....
*May 9 17:58:14.840: Dia Base: Request message hash ctx removed for
[2328318322/2328318322] *May 9 17:58:14.840: Dia Base: (C000000C): Received msg event
from message i/o *May 9 17:58:14.840: Dia Peer FSM (50F63888): input event RCV_CEA in
state WAIT_CEA *May 9 17:58:14.840: Dia Peer FSM (50F63888): Starting Watchdog timer *May
9 17:58:14.840: %DIABASE-4-DIA_PEER_UP: Diameter peer 9.113.33.6 port 3868 TCP UP *May 9
17:58:14.840: Dia Peer FSM (50F63888): event RCV_CEA, state WAIT_CEA-->OPEN
Periodic watch-dog message exchanges

*May 9 17:59:14.840: Dia Peer FSM (50F63888): input event TIMEOUT in
state OPEN
*May 9 17:59:14.840: Dia Base: Sending diameter message to peer
"diameter2.cisco.com"
*May 9 17:59:14.840: DIAMETER: DWR message, ver=1, len=48, app=0,
[2328318323/2328318323]
"host" (M)
"cisco" (M)
50D0B710: 01000030 80000118 00000000 ...0........
50D0B720: 8AC75173 8AC75173 00000108 4000000C .GQs.GQs....@...
50D0B730: 686F7374 00000128 4000000D 63697363 host...(@...cisc
50D0B740: 6F000000 FD o...}
[2328318323/2328318323]
*May 9 17:59:14.840: Dia Peer FSM (50F63888): Starting Watchdog timer,
[60] left for next timeout*May 9 17:59:14.840: Dia Peer FSM (50F63888):
event TIMEOUT, state OPEN-->OPEN
*May 9 17:59:14.840: Dia Transport: Dia Transport write message event
*May 9 17:59:14.840: Dia Transport: socket 0 - complete msg sent
*May 9 17:59:14.840: Dia Transport: socket 0 - complete read of 20
bytes
*May 9 17:59:14.840: Dia Transport: complete header read from socket 0
*May 9 17:59:14.840: Dia Transport: read msg (60) bytes from socket 0
bytes
*May 9 17:59:14.840: Dia Base: Diameter message received from the peer
*May 9 17:59:14.840: DIAMETER: DWA message, ver=1, len=80, app=0,
[2328318323/2328318323]
2001 (M)

DB-530 May 2008
Debug Commands
debug diameter

"cisco.com" (M)
65940780: 01000050 00000118 00000000 ...P........
65940790: 8AC75173 8AC75173 0000010C 4000000C .GQs.GQs....@...
659407A0: 000007D1 00000108 4000001B 6469616D ...Q....@...diam
659407B0: 65746572 322E6369 73636F2E 636F6D00 eter2.cisco.com.
659407C0: 00000128 40000011 63697363 6F2E636F ...(@...cisco.co
659407D0: 6D000000 00 m....
[2328318323/2328318323]
*May 9 17:59:14.840: Dia Base: (C000000C): Received msg event from
message i/o
*May 9 17:59:14.840: Dia Peer FSM (50F63888): input event RCV_DWA in
state OPEN
*May 9 17:59:14.840: Dia Peer FSM (50F63888): Starting Watchdog timer
*May 9 17:59:14.840: Dia Peer FSM (50F63888): event RCV_DWA, state
OPEN-->OPEN
Periodic connection attempt when the peer connection is broken

*May 9 18:07:18.472: Dia Transport: socket 0 READ event: UP->CLOSE due
to bytes read = 0
*May 9 18:07:18.472: Dia Base: (8600000E): Received peer disconnection
event from transport
*May 9 18:07:18.472: %DIABASE-4-DIA_PEER_DOWN: Diameter peer 9.113.33.6
port 3868 TCP DOWN
*May 9 18:07:18.472: Dia Peer FSM (2068FF44): input event PEER_DISC in
state OPEN
*May 9 18:07:18.472: Dia Peer FSM (2068FF44): Starting Reconnect timer
*May 9 18:07:18.472: Dia Peer FSM (2068FF44): event PEER_DISC, state
OPEN-->CLOSED
*May 9 18:07:48.472: Dia Peer FSM (2068FF44): input event START in
state CLOSED
*May 9 18:07:48.472: Dia Peer FSM (2068FF44): Starting Connection timer
*May 9 18:07:48.472: Dia Peer FSM (2068FF44): event START, state
CLOSED-->WAIT_CONN_ACK
*May 9 18:07:48.472: Dia Transport: socket 0 - connecting to 9.113.33.6
(3868)
*May 9 18:07:48.472: Dia Transport: socket 0 - connection in progress
*May 9 18:07:48.472: Dia Transport: socket 0 - local address 9.113.33.5
(61122)
*May 9 18:07:48.472: Dia Transport: socket 0 - CONN_WAIT->CLOSE
*May 9 18:07:48.472: Dia Base: (8600000E): Received peer disconnection
event from transport
*May 9 18:07:48.472: Dia Peer FSM (2068FF44): input event PEER_DISC in
state WAIT_CONN_ACK
*May 9 18:07:48.472: Dia Peer FSM (2068FF44): Starting Reconnect timer
*May 9 18:07:48.472: Dia Peer FSM (2068FF44): event PEER_DISC, state
WAIT_CONN_ACK-->CLOSED
Peer disconnection when a peer configuration is removed

Ginger(config)#no diameter peer watch
Ginger(config)#
*May 9 18:05:02.812: Dia Base: Peer unconfigured, start peer
disconnection
*May 9 18:05:02.812: Dia Base: (C000000C): Received peer
unconfiguration event
*May 9 18:05:02.812: Dia Peer FSM (50F63888): input event STOP in state
OPEN

May 2008 DB-531
Debug Commands
debug diameter
*May 9 18:05:02.812: Dia Base: Sending diameter message to peer

*May 9 18:05:02.812: DIAMETER: DPR message, ver=1, len=60, app=0,
[2328318329/2328318329]
"host" (M)
"cisco" (M)
*May 9 18:05:02.816: DIAMETER: Peer-disconnect-reason [273]
Server-do-not-want-to-talk (M)
653D1810: 0100003C 8000011A ...<....
653D1820: 00000000 8AC75179 8AC75179 00000108 .....GQy.GQy....
653D1830: 4000000C 686F7374 00000128 4000000D @...host...(@...
653D1840: 63697363 6F000000 00000111 4000000C cisco.......@...
653D1850: 00000002 00 .....
[2328318329/2328318329]
*May 9 18:05:02.816: Dia Peer FSM (50F63888): Starting DPR timer
*May 9 18:05:02.816: Dia Peer FSM (50F63888): event STOP, state
OPEN-->CLOSING
*May 9 18:05:02.816: Dia Transport: Dia Transport write message event
*May 9 18:05:02.816: Dia Transport: socket 0 - complete msg sent
bytes
*May 9 18:05:02.816: Dia Transport: complete header read from socket 0
*May 9 18:05:02.816: Dia Transport: read msg (60) bytes from socket 0
bytes
*May 9 18:05:02.816: Dia Base: Diameter message received from the peer
*May 9 18:05:02.816: DIAMETER: DPA message, ver=1, len=80, app=0,
[2328318329/2328318329]
2001 (M)
"cisco.com" (M)
65913A20: 01000050 ...P
65913A30: 0000011A 00000000 8AC75179 8AC75179 .........GQy.GQy
65913A40: 0000010C 4000000C 000007D1 00000108 ....@......Q....
65913A50: 4000001B 6469616D 65746572 322E6369 @...diameter2.ci
65913A60: 73636F2E 636F6D00 00000128 40000011 sco.com....(@...
65913A70: 63697363 6F2E636F 6D000000 00 cisco.com....
[2328318329/2328318329]
*May 9 18:05:02.816: Dia Base: (C000000C): Received msg event from
message i/o
*May 9 18:05:02.816: Dia Peer FSM (50F63888): input event RCV_DPA in
state CLOSING
*May 9 18:05:02.816: Dia Base: (C000000C): Free the peer connection
context 50F63888

show diameter peer Displays Diameter peer configuration information.

DB-532 May 2008
Debug Commands
debug dlsw
debug dlsw
To enable debugging of data-link switching plus (DLSw+), use the debug dlsw command in privileged
debug dlsw [border-peers [interface interface | ip address ip-address] | core [flow-control

messages | state | xid] [circuit-number] | local-circuit circuit-number | peers
[interface interface [fast-errors | fast-paks] | ip address ip-address [fast-errors | fast-paks |
fst-seq | udp]] | reachability [error | verbose] [sna | netbios]
no debug dlsw [border-peers [interface interface | ip address ip-address] | core [flow-control

messages | state | xid] [circuit-number] | local-circuit circuit-number | peers
[interface interface [fast-errors | fast-paks] | ip address ip-address [fast-errors | fast-paks |
fst-seq | udp]] | reachability [error | verbose] [sna | netbios]
Syntax Description border-peers (Optional) Enables debugging output for border peer events.
interface interface (Optional) Specifies a remote peer to debug by a direct interface.
ip address ip-address (Optional) Specifies a remote peer to debug by its IP address.
core (Optional) Enables debugging output for DLSw core events.
flow-control (Optional) Enables debugging output for congestion in the WAN or
at the remote end station.
messages (Optional) Enables debugging output of core messagesspecific
packets received by DLSw either from one of its peers or from a local
medium via the Cisco link services interface.
state (Optional) Enables debugging output for state changes on the circuit.
xid (Optional) Enables debugging output for the exchange identification
state machine.
circuit-number (Optional) Specifies the circuit for which you want core debugging
output to reduce the output.
local-circuit circuit-number (Optional) Enables debugging output for circuits performing local
conversion. Local conversion occurs when both the input and output
data-link connections are on the same local peer and no remote peer
exists.
peers (Optional) Enables debugging output for peer events.
fast-errors (Optional) Debugs errors for fast-switched packets.
fast-paks (Optional) Debugs fast-switched packets.
fst-seq (Optional) Debugs Fast-Sequenced Transport (FST) sequence
numbers on fast switched packets.
udp (Optional) Debugs User Datagram Protocol (UDP) packets.
reachability (Optional) Enables debugging output for reachability events
(explorer traffic). If no options are specified, event-level information
is displayed for all protocols.

May 2008 DB-533
Debug Commands
debug dlsw
error | verbose (Optional) Specifies how much reachability information you want
displayed. The verbose keyword displays everything, including
errors and events. The error keyword displays error information
only. If no option is specified, event-level information is displayed.
sna | netbios (Optional) Specifies that reachability information be displayed for
only Systems Network Architecture (SNA) or Network Basic
Input/Output System (NetBIOS) protocols. If no option is specified,
information for all protocols is displayed.
Usage Guidelines When you specify no optional keywords, the debug dlsw command enables all available DLSW
debugging output.
Normally you need to use only the error or verbose option of the debug dlsw reachability command
to help identify problems. The error option is recommended for use by customers and provides a subset
of the messages from the normal event-level debugging. The verbose option provides a very detailed
view of events, and is typically used only by service personnel.
To reduce the amount of debug information displayed, use the sna or netbios option with the debug dlsw
reachability command if you know that you have an SNA or NetBIOS problem.
The DLSw core is the engine that is responsible for the establishment and maintenance of remote
circuits. If possible, specifying the index of the specific circuit you want to debug reduces the amount
of output displayed. However, if you want to watch a circuit initially come up, do not use the
circuit-number option with the core keyword.
The core flow-control option provides information about congestion in the WAN or at the remote end
station. In these cases, DLSw sends Receiver Not Ready (RNR) frames on its local circuits, slowing data
traffic on established sessions and giving the congestion an opportunity to clear.
The core state option allows you to see when the circuit changes state. This capability is especially
useful for determining why a session cannot be established or why a session is being disconnected.
The core XID option allows you to track the exchange identification (XID)-state machine. The router
tracks XID commands and responses used in negotiations between end stations before establishing a
session.
Examples The following examples show and explain some of the typical DLSw debugging messages you might see
when using the debug dlsw command.
The following example enables UDP packet debugging for a specific remote peer:
Router# debug dlsw peers ip-address 1.1.1.6 udp
The following message is sample output from the debug dlsw border-peers command:
*Mar 10 17:39:56: CSM: delete group mac cache for group 0
*Mar 10 17:39:56: CSM: delete group name cache for group 0
*Mar 10 17:40:19: CSM: update group cache for mac 0000.3072.1070, group 10
*Mar 10 17:40:22: DLSw: send_to_group_members(): copy to peer 10.19.32.5
The following message is from a router that initiated a TCP connection:

DLSw: START-TPFSM (peer 10.3.8.7(2065)): event:ADMIN-OPEN CONNECTION state:DISCONN
DLSw: dtp_action_a() attempting to connect peer 10.3.8.7(2065)
DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:DISCONN->WAIT_WR
DLSw: Async Open Callback 10.3.8.7(2065) -> 11002

DB-534 May 2008
Debug Commands
debug dlsw
DLSw: START-TPFSM (peer 10.3.8.7(2065)): event:TCP-WR PIPE OPENED state:WAIT_WR

DLSw: dtp_action_f() start read open timer for peer 10.3.8.7(2065)
DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:WAIT_WR->WAIT_RD
DLSw: passive open 10.3.8.7(11004) -> 2065
DLSw: START-TPFSM (peer 10.3.8.7(2065)): event:TCP-RD PIPE OPENED state:WAIT_RD
DLSw: dtp_action_g() read pipe opened for peer 10.3.8.7(2065)
DLSw: CapExId Msg sent to peer 10.3.8.7(2065)
DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:WAIT_RD->WAIT_CAP
DLSw: START-TPFSM (peer 10.3.8.7(2065)): event:SSP-CAP MSG RCVD state:WAIT_CAP
DLSw: dtp_action_j() cap msg rcvd from peer 10.3.8.7(2065)
DLSw: Recv CapExId Msg from peer 10.3.8.7(2065)
DLSw: Pos CapExResp sent to peer 10.3.8.7(2065)
DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:WAIT_CAP->WAIT_CAP
DLSw: Recv CapExPosRsp Msg from peer 10.3.8.7(2065)
DLSw: Processing delayed event:SSP-CAP EXCHANGED - prev state:WAIT_CAP
DLSw: START-TPFSM (peer 10.3.8.7(2065)): event:SSP-CAP EXCHANGED state:WAIT_CAP
DLSw: dtp_action_k() cap xchged for peer 10.3.8.7(2065)
DLSw: closing read pipe tcp connection for peer 10.3.8.7(2065)
DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:WAIT_CAP->PCONN_WT
DLSw: Processing delayed event:TCP-PEER CONNECTED - prev state:PCONN_WT
DLSw: START-TPFSM (peer 10.3.8.7(2065)): event:TCP-PEER CONNECTED state:PCONN_WT
DLSw: dtp_action_m() peer connected for peer 10.3.8.7(2065)
DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:PCONN_WT->CONNECT
DLSw: START-TPFSM (peer 10.3.8.7(2065)): event:CORE-ADD CIRCUIT state:CONNECT
DLSw: dtp_action_u(), peer add circuit for peer 10.3.8.7(2065)
DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:CONNECT->CONNECT
The following message is from a router that received a TCP connection:

DLSw: passive open 10.10.10.4(11002) -> 2065
DLSw: START-TPFSM (peer 10.10.10.4(2065)): event:TCP-RD PIPE OPENED state:DISCONN
DLSw: dtp_action_c() opening write pipe for peer 10.10.10.4(2065)
DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:DISCONN->WWR_RDOP
DLSw: Async Open Callback 10.10.10.4(2065) -> 11004
DLSw: START-TPFSM (peer 10.10.10.4(2065)): event:TCP-WR PIPE OPENED state:WWR_RDOP
DLSw: dtp_action_i() write pipe opened for peer 10.10.10.4(2065)
DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:WWR_RDOP->WAIT_CAP
DLSw: START-TPFSM (peer 10.10.10.4(2065)): event:SSP-CAP EXCHANGED state:WAIT_CAP
DLSw: dtp_action_k() cap xchged for peer 10.10.10.4(2065)
DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:WAIT_CAP->PCONN_WT
DLSw: dlsw_tcpd_fini() for peer 10.10.10.4(2065)
DLSw: dlsw_tcpd_fini() closing write pipe for peer 10.10.10.4
DLSw: START-TPFSM (peer 10.10.10.4(2065)): event:TCP-CLOSE WR PIPE state:PCONN_WT
DLSw: dtp_action_l() close write pipe for peer 10.10.10.4(2065)
DLSw: closing write pipe tcp connection for peer 10.10.10.4(2065)
DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:PCONN_WT->PCONN_WT
DLSw: Processing delayed event:TCP-PEER CONNECTED - prev state:PCONN_WT
DLSw: START-TPFSM (peer 10.10.10.4(2065)): event:TCP-PEER CONNECTED state:PCONN_WT
DLSw: dtp_action_m() peer connected for peer 10.10.10.4(2065)
DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:PCONN_WT->CONNECT

May 2008 DB-535
Debug Commands
debug dlsw
DLSw: START-TPFSM (peer 10.10.10.4(2065)): event:CORE-ADD CIRCUIT state:CONNECT

DLSw: dtp_action_u(), peer add circuit for peer 10.10.10.4(2065)
DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:CONNECT->CONNECT
The following message is from a router that initiated an FST connection:

DLSw: START-FSTPFSM (peer 10.10.10.4(0)): event:ADMIN-OPEN CONNECTION state:DISCONN
DLSw: dfstp_action_a() attempting to connect peer 10.10.10.4(0)
DLSw: Connection opened for peer 10.10.10.4(0)
DLSw: END-FSTPFSM (peer 10.10.10.4(0)): state:DISCONN->WAIT_CAP
DLSw: START-FSTPFSM (peer 10.10.10.4(0)): event:SSP-CAP MSG RCVD state:WAIT_CAP
DLSw: dfstp_action_e() cap msg rcvd for peer 10.10.10.4(0)
DLSw: END-FSTPFSM (peer 10.10.10.4(0)): state:WAIT_CAP->WAIT_CAP
DLSw: START-FSTPFSM (peer 10.10.10.4(0)): event:SSP-CAP EXCHANGED state:WAIT_CAP
DLSw: dfstp_action_f() cap xchged for peer 10.10.10.4(0)
DLSw: END-FSTPFSM (peer 10.10.10.4(0)): state:WAIT_CAP->CONNECT
The following message is from a router that received an FST connection:

DLSw: START-FSTPFSM (peer 10.3.8.7(0)): event:SSP-CAP MSG RCVD state:DISCONN
DLSw: dfstp_action_c() cap msg rcvd for peer 10.3.8.7(0)
DLSw: END-FSTPFSM (peer 10.3.8.7(0)): state:DISCONN->WAIT_CAP
DLSw: START-FSTPFSM (peer 10.3.8.7(0)): event:SSP-CAP EXCHANGED state:WAIT_CAP
DLSw: dfstp_action_f() cap xchged for peer 10.3.8.7(0)
DLSw: END-FSTPFSM (peer 10.3.8.7(0)): state:WAIT_CAP->CONNECT
The following message is from a router that initiated an LLC2 connection:

DLSw-LLC2: Sending enable port ; port no : 0
PEER-DISP Sent : CLSI Msg : ENABLE.Req dlen: 20
DLSw: Peer Received : CLSI Msg : ENABLE.Cfm CLS_OK dlen: 20
DLSw-LLC2 : Sending activate sap for Serial1 - port_id = 887C3C
port_type = 7 dgra(UsapID) = 952458
PEER-DISP Sent : CLSI Msg : ACTIVATE_SAP.Req dlen: 60
DLSw: Peer Received : CLSI Msg : ACTIVATE_SAP.Cfm CLS_OK dlen: 60
DLSw Got ActSapcnf back for Serial1 - port_id = 8978204, port_type = 7, psap_id = 0
DLSw: START-LLC2PFSM (peer on interface Serial1): event:ADMIN-OPEN CONNECTION

state:DISCONN
DLSw: dllc2p_action_a() attempting to connect peer on interface Serial1
PEER-DISP Sent : CLSI Msg : REQ_OPNSTN.Req dlen: 106
DLSw: END-LLC2PFSM (peer on interface Serial1): state:DISCONN->ROS_SENT
DLSw: Peer Received : CLSI Msg : REQ_OPNSTN.Cfm CLS_OK dlen: 106

DLSw: START-LLC2PFSM (peer on interface Serial1): event:CLS-REQOPNSTN.CNF state:ROS_SENT
DLSw: dllc2p_action_c()
PEER-DISP Sent : CLSI Msg : CONNECT.Req dlen: 16
DLSw: END-LLC2PFSM (peer on interface Serial1): state:ROS_SENT->CON_PEND

DB-536 May 2008
Debug Commands
debug dlsw
DLSw: Peer Received : CLSI Msg : CONNECT.Cfm CLS_OK dlen: 28

DLSw: START-LLC2PFSM (peer on interface Serial1): event:CLS-CONNECT.CNF state:CON_PEND
DLSw: dllc2p_action_e() send capabilities to peer on interface Serial1
PEER-DISP Sent : CLSI Msg : SIGNAL_STN.Req dlen: 8
PEER-DISP Sent : CLSI Msg : DATA.Req dlen: 418
DLSw: CapExId Msg sent to peer on interface Serial1
DLSw: END-LLC2PFSM (peer on interface Serial1): state:CON_PEND->WAIT_CAP
DLSw: Peer Received : CLSI Msg : DATA.Ind dlen: 418

DLSw: START-LLC2PFSM (peer on interface Serial1): event:SSP-CAP MSG RCVD state:WAIT_CAP
DLSw: dllc2p_action_k() cap msg rcvd for peer on interface Serial1
DLSw: Recv CapExId Msg from peer on interface Serial1
DLSw: Pos CapExResp sent to peer on interface Serial1
DLSw: END-LLC2PFSM (peer on interface Serial1): state:WAIT_CAP->WAIT_CAP

DLSw: Recv CapExPosRsp Msg from peer on interface Serial1

DLSw: START-LLC2PFSM (peer on interface Serial1): event:SSP-CAP EXCHANGED state:WAIT_CAP
DLSw: dllc2p_action_l() cap xchged for peer on interface Serial1
DLSw: END-LLC2PFSM (peer on interface Serial1): state:WAIT_CAP->CONNECT
The following message is from a router that received a Logical Link Control, type 2 (LLC2) connection:
DLSw-LLC2: Sending enable port ; port no : 0
PEER-DISP Sent : CLSI Msg : ENABLE.Req dlen: 20
DLSw: Peer Received : CLSI Msg : ENABLE.Cfm CLS_OK dlen: 20
DLSw-LLC2 : Sending activate sap for Serial0 - port_id = 887C3C
port_type = 7 dgra(UsapID) = 93AB34
PEER-DISP Sent : CLSI Msg : ACTIVATE_SAP.Req dlen: 60
DLSw: Peer Received : CLSI Msg : ACTIVATE_SAP.Cfm CLS_OK dlen: 60
DLSw Got ActSapcnf back for Serial0 - port_id = 8944700, port_type = 7, psap_id = 0
DLSw: Peer Received : CLSI Msg : CONECT_STN.Ind dlen: 39

DLSw: START-LLC2PFSM (peer on interface Serial0): event:CLS-CONNECT_STN.IND state:DISCONN
DLSw: dllc2p_action_s() conn_stn for peer on interface Serial0
PEER-DISP Sent : CLSI Msg : REQ_OPNSTN.Req dlen: 106
DLSw: END-LLC2PFSM (peer on interface Serial0): state:DISCONN->CONS_PEND
DLSw: Peer Received : CLSI Msg : REQ_OPNSTN.Cfm CLS_OK dlen: 106

DLSw: START-LLC2PFSM (peer on interface Serial0): event:CLS-REQOPNSTN.CNF state:CONS_PEND
DLSw: dllc2p_action_h() send capabilities to peer on interface Serial0
PEER-DISP Sent : CLSI Msg : CONNECT.Rsp dlen: 20
DLSw: CapExId Msg sent to peer on interface Serial0
DLSw: END-LLC2PFSM (peer on interface Serial0): state:CONS_PEND->WAIT_CAP
DLSw: Peer Received : CLSI Msg : CONNECTED.Ind dlen: 8

DLSw: START-LLC2PFSM (peer on interface Serial0): event:CLS-CONNECTED.IND state:WAIT_CAP

DLSw: Recv CapExId Msg from peer on interface Serial0
DLSw: Pos CapExResp sent to peer on interface Serial0

May 2008 DB-537
Debug Commands
debug dlsw

DLSw: Recv CapExPosRsp Msg from peer on interface Serial0

DLSw: START-LLC2PFSM (peer on interface Serial0): event:SSP-CAP EXCHANGED state:WAIT_CAP
DLSw: dllc2p_action_l() cap xchged for peer on interface Serial0
DLSw: END-LLC2PFSM (peer on interface Serial0): state:WAIT_CAP->CONNECT
The following messages occur when a CUR_ex (CANUREACH explorer) frame is received from other
peers, and the peer statements or the promiscuous keyword have not been enabled so that the router is
not configured correctly:
22:42:44: DLSw: Not promiscuous - Rej conn from 172.20.96.1(2065)
22:42:51: DLSw: Not promiscuous - Rej conn from 172.20.99.1(2065)
In the following messages, the router sends a keepalive message every 30 seconds to keep the peer
connected. If three keepalive messages are missed, the peer is torn down. These messages are displayed
only if keepalives are enabled (by default, keepalives are disabled):
22:44:03: DLSw: Keepalive Request sent to peer 172.20.98.1(2065) (168243148)
22:44:03: DLSw: Keepalive Response from peer 172.20.98.1(2065) (168243176)
22:44:34: DLSw: Keepalive Request sent to peer 172.20.98.1(2065) (168274148)
22:44:34: DLSw: Keepalive Response from peer 172.20.98.1(2065) (168274172)
The following peer debugging messages indicate that the local peer is disconnecting from the specified
remote peer because of missed peer keepalives:
0:03:24: DLSw: keepalive failure for peer on interface Serial0
0:03:24: DLSw: action_d(): for peer on interface Serial0
0:03:24: DLSW: DIRECT aborting connection for peer on interface Serial0
0:03:24: DLSw: peer on interface Serial0, old state CONNECT, new state DISCONN
The following peer debugging messages result from an attempt to connect to an IP address that does not
have DLSw enabled. The local router attempts to connect in 30-second intervals:
23:13:22: action_a() attempting to connect peer 172.20.100.1(2065)
23:13:22: DLSw: CONN: peer 172.20.100.1 open failed, rejected [9]
23:13:22: action_a() retries: 8 next conn time: 861232504
23:13:52: DLSw: CONN: peer 172.20.100.1 open failed, rejected [9]
23:13:52: action_a() retries: 9 next conn time: 861292536
The following peer debugging messages that indicates a remote peer statement is missing on the router
(address 172.20.100.1) to which the connection attempt is sent:
23:14:52: DLSw: action_a(): Write pipe opened for peer 172.20.100.1(2065)
23:14:52: DLSw: peer 172.20.100.1(2065), old state DISCONN, new state WAIT_RD
23:14:52: DLSw: dlsw_tcpd_fini() closing connection for peer 172.20.100.1
23:14:52: DLSw: action_d(): for peer 172.20.100.1(2065)
23:14:52: DLSw: aborting tcp connection for peer 172.20.100.1(2065)
23:14:52: DLSw: peer 172.20.100.1(2065), old state WAIT_RD, new state DISCONN
The following messages show a peer connection opening with no errors or abnormal events:
23:16:37: DLSw: action_a(): Write pipe opened for peer 172.20.100.1(2065)
23:16:37: DLSw: peer 172.20.100.1(2065), old state DISCONN, new state WAIT_RD
23:16:37: DLSW: passive open 172.20.100.1(17762) -> 2065
23:16:37: DLSw: action_c(): for peer 172.20.100.1(2065)
23:16:37: DLSw: peer 172.20.100.1(2065), old state WAIT_RD, new state CAP_EXG

DB-538 May 2008
Debug Commands
debug dlsw
23:16:37: DLSw: peer 172.20.100.1(2065) conn_start_time set to 861397784

23:16:37: DLSw: CapExId Msg sent to peer 172.20.100.1(2065)
23:16:37: DLSw: Recv CapExId Msg from peer 172.20.100.1(2065)
23:16:37: DLSw: Pos CapExResp sent to peer 172.20.100.1(2065)
23:16:37: DLSw: action_e(): for peer 172.20.100.1(2065)
23:16:37: DLSw: Recv CapExPosRsp Msg from peer 172.20.100.1(2065)
23:16:37: DLSw: action_e(): for peer 172.20.100.1(2065)
23:16:37: DLSw: peer 172.20.100.1(2065), old state CAP_EXG, new state CONNECT
23:16:37: DLSw: dlsw_tcpd_fini() closing write pipe for peer 172.20.100.1
23:16:37: DLSw: action_g(): for peer 172.20.100.1(2065)
23:16:37: DLSw: closing write pipe tcp connection for peer 172.20.100.1(2065)
23:16:38: DLSw: peer_act_on_capabilities() for peer 172.20.100.1(2065)
The following two messages show that an information frame is passing through the router:
DLSw: dlsw_tr2fct() lmac:c000.a400.0000 rmac:0800.5a29.75fe ls:5 rs:4 i:34
DLSw: dlsw_tr2fct() lmac:c000.a400.0000 rmac:0800.5a29.75fe ls:4 rs:4 i:34
Sample debug DLSw Reachability Messages

The messages in this section are based on the following criteria:
Reachability is stored in cache. DLSw+ maintains two reachability caches: one for MAC addresses
and one for NetBIOS names. Depending on how long entries have been in the cache, they are either
fresh or stale.
If a router has a fresh entry in the cache for a certain resource, it answers a locate request for that
resource without verifying that it is still available. A locate request is typically a TEST frame for
MAC addresses or a FIND_NAME_QUERY for NetBIOS.
If a router has a stale entry in the cache for a certain resource, it verifies that the entry is still valid
before answering a locate request for the resource by sending a frame to the last known location of
the resource and waits for a resource. If the entry is a REMOTE entry, the router sends a CUR_ex
frame to the remote peer to verify. If the entry is a LOCAL entry, it sends either a TEST frame or a
NetBIOS FIND_NAME_QUERY on the appropriate local port.
By default, all reachability cache entries remain fresh for 4 minutes after they are learned. For MAC
addresses, you can change this time with the dlsw timer sna-verify-interval command. For
NetBIOS names, you can change this time with the dlsw timer netbios-verify-interval command.
By default, all reachability cache entries age out of the cache 16 minutes after they are learned. For
MAC addresses, you can change this time with the dlsw timer sna-cache-timeout command. For
NetBIOS names, you can change the time with the dlsw timer netbios-cache-timeout command.
Table 76 describes the debug output indicating that the DLSW router received an SSP message that is
flow controlled and should be counted against the window of the sender.
Dec 6 11:26:49: CSM: Received SSP CUR csex flags = 80, mac 4000.90b1.26cf,
The csex flags = 80 means that this is an CUR_ex (explorer).
Dec 5 10:48:33: DLSw: 1620175180 decr r - s:27 so:0 r:27 ro:0
Table 76 debug dlsw Field Descriptions
Field Description
decr r Decrement received count.
s This DLSW routers granted units for the circuit.
so 0=This DLSW router does not owe a flow control
acknowledgment.
1=This router owes a flow control acknowledgment.

May 2008 DB-539
Debug Commands
debug dlsw
Table 76 debug dlsw Field Descriptions (continued)
Field Description
r Partners number of granted units for the circuit.
ro Indicates whether the partner owes flow control
acknowledgment.
The following message shows that DLSW is sending an I frame to a LAN:

Dec 5 10:48:33: DISP Sent : CLSI Msg : DATA.Req dlen: 1086
The following message shows that DLSW received the I frame from the LAN:
Dec 5 10:48:35: DLSW Received-disp : CLSI Msg : DATA.Ind dlen: 4
The following messages show that the reachability cache is cleared:

Router# clear dlsw rea
23:44:11: CSM: Clearing CSM cache

23:44:11: CSM: delete local mac cache for port 0
23:44:11: CSM: delete local name cache for port 0
23:44:11: CSM: delete remote mac cache for peer 0
23:44:11: CSM: delete remote name cash dlsw rea
The next group of messages show that the DLSW reachability cache is added, and that a name query is
perform from the router MARIAN:
23:45:11: CSM: core_to_csm CLSI_MSG_PROC - port_id 5EFBB4
23:45:11: CSM: 0800.5a30.7a9b passes local mac excl. filter
23:45:11: CSM: update local cache for mac 0800.5a30.7a9b, port 5EFBB4
23:45:11: CSM: update local cache for name MARIAN , port 5EFBB4
23:45:11: CSM: Received CLS_UDATA_STN from Core
23:45:11: CSM: Received netbios frame type A
23:45:11: CSM: Processing Name Query
23:45:11: CSM: Netbios Name Query: ws_status = 6
23:45:11: CSM: Write to peer 0 ok.
23:45:11: CSM: Freeing clsi message
23:45:11: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB4
23:45:11: CSM: update local cache for mac 0800.5a30.7a9b, port 658AB4
23:45:11: CSM: update local cache for name MARIAN , port 658AB4
23:45:11: CSM: DLXNR_PEND match found.... drop name query

DB-540 May 2008
Debug Commands
debug dlsw

23:45:18: CSM: Deleting Reachability cache
23:45:18: CSM: Deleting DLX NR pending record....
23:45:38: CSM: Received netbios frame type 8
The following messages show that the router named MARIAN is added to the network:

May 2008 DB-541
Debug Commands
debug dlsw
In the next group of messages, an attempt is made to add the router named GINGER on the Ethernet
interface:
0:07:44: CSM: 0004.f545.24e6 passes local mac excl. filter
0:07:44: CSM: update local cache for mac 0004.f545.24e6, port 658AB4
0:07:44: CSM: update local cache for name GINGER , port 658AB4
In the following example, the output from the show dlsw reachability command indicates that GINGER
is on the Ethernet interface and MARIAN is on the Token Ring interface:
Router# show dlsw reachability
DLSw MAC address reachability cache list

Mac Addr status Loc. peer/port rif
0004.f545.24e6 FOUND LOCAL P007-S000 --no rif--
0800.5a30.7a9b FOUND LOCAL P000-S000 06C0.0621.7D00
P007-S000 F0F8.0006.A6FC.005F.F100.0000.0000.0000
DLSw NetBIOS Name reachability cache list

NetBIOS Name status Loc. peer/port rif
GINGER FOUND LOCAL P007-S000 --no rif--
MARIAN FOUND LOCAL P000-S000 06C0.0621.7D00
P007-S000 --no rif--

DB-542 May 2008
Debug Commands
debug dmsp doc-to-fax

Note In release 12.3(8)T, the debug dmsp doc-to-fax command is replaced by the debug fax dmsp command.
See the debug fax dmsp command for more information.
To display debugging messages for the doc Media Service Provider (docMSP) TIFF or text2Fax engine,
use the debug dmsp doc-to-fax command in privileged EXEC mode. To disable debugging output, use
debug dmsp doc-to-fax [text-to-fax | tiff-reader]
no debug dmsp doc-to-fax [text-to-fax | tiff-reader]
Syntax Description text-to-fax (Optional) Displays debugging messages that occur while the DocMSP
Component is receiving text packets and producing T4 fax data.
tiff-reader (Optional) Displays debugging messages that occur while the DocMSP
Component is receiving TIFF packets and producing T4 fax data.

12.1(3)XI This command was introduced on the Cisco AS5300 access server.
12.3(8)T This command was replaced by the debug fax dmsp command in the
Cisco IOS 12.3T release.
Examples The following is sample output from the debug dmsp doc-to-fax command:
Router# debug dmsp doc-to-fax
Jan 1 04:58:39.898: docmsp_call_setup_request: callid=18

Jan 1 04:58:39.902: docmsp_call_setup_request(): ramp data dir=OFFRAMP, conf dir=SRC
Jan 1 04:58:39.902: docmsp_caps_ind: call id=18, src=17
Jan 1 04:58:39.902: docmsp_bridge cfid=5, srccid=18, dstcid=17
Jan 1 04:58:39.902: docmsp_bridge(): ramp data dir=OFFRAMP, conf dir=SRC, encode out=2
Jan 1 04:58:39.902: docmsp_rcv_msp_ev: call id =18, evID = 42
Jan 1 04:58:39.902: docmsp_bridge cfid=6, srccid=18, dstcid=15

May 2008 DB-543
Debug Commands
Jan 1 04:58:39.902: docmsp_bridge(): ramp data dir=OFFRAMP, conf dir=DEST, encode out=2
Jan 1 04:58:39.902: docmsp_process_rcv_data: call id src=0, dst=18
Jan 1 04:58:39.902: docmsp_generate_page:
Jan 1 04:58:39.902: docmsp_generate_page: new context for Call 18
Jan 1 04:58:39.922: docmsp_get_msp_event_buffer:
Jan 1 04:58:42.082: docmsp_xmit: call id src=15, dst=18
Jan 1 04:58:42.082: offramp_data_process:

debug dmsp fax-to-doc Displays debugging messages for doc MPS fax-to-doc.

DB-544 May 2008
Debug Commands
debug dmsp fax-to-doc

Note In release 12.3(8)T, the debug dmsp fax-to-doc command is replaced by the debug fax dmsp command.
See the debug fax dmsp command for more information.
To display debugging messages for doc MSP (docMSP) fax-to-doc, use the debug dmsp fax-to-doc
debug dmsp fax-to-doc [tiff-writer]
no debug dmsp fax-to-doc [tiff-writer]
Syntax Description tiff-writer (Optional) Displays debug messages that occur while the DocMSP
Component is receiving T4 fax data and producing TIFF packets.

12.3(8)T This command was replaced by the debug fax dmsp command in the
Cisco IOS 12.3T release.
Examples The following is sample output from the debug dmsp fax-to-doc command:
Router# debug dmsp fax-to-doc
*Oct 16 08:29:54.487: docmsp_call_setup_request: callid=22

*Oct 16 08:29:54.487: docmsp_call_setup_request(): ramp data dir=OFFRAMP, conf dir=SRC
*Oct 16 08:29:54.487: docmsp_caps_ind: call id=22, src=21
*Oct 16 08:29:54.487: docmsp_bridge cfid=15, srccid=22, dstcid=21
*Oct 16 08:29:54.487: docmsp_bridge(): ramp data dir=OFFRAMP, conf dir=SRC, encode out=2
*Oct 16 08:29:54.487: docmsp_bridge(): ramp data dir=OFFRAMP, conf dir=DEST, encode out=2
*Oct 16 08:29:54.487: docmsp_xmit: call id src=17, dst=22
*Oct 16 08:29:54.487: docmsp_process_rcv_data: call id src=17, dst=22
*Oct 16 08:29:54.487: offramp_data_process:
*Oct 16 08:29:54.515: docmsp_get_msp_event_buffer:

May 2008 DB-545
Debug Commands
*Oct 16 08:29:56.115: docmsp_call_setup_request: callid=24

*Oct 16 08:29:56.115: docmsp_call_setup_request(): ramp data dir=ONRAMP, conf dir=DEST
*Oct 16 08:29:56.115: docmsp_caps_ind: call id=24, src=20

debug dmsp doc-to-fax Displays debugging messages for the doc Media Service Provider
TIFF or text2Fax engine.

DB-546 May 2008
Debug Commands
debug dmvpn
debug dmvpn
To debug Dynamic Multipoint VPN (DMVPN) sessions, use the debug dmvpn command in privileged
debug dmvpn {[{condition [unmatched] | [peer [nbma | tunnel {ip-address}]] | [vrf {vrf-name}]
| [interface {tunnel number}]}] | [{error | detail | packet | all} {nhrp | crypto | tunnel | socket
| all}]}
no debug dmvpn {[{condition [unmatched] | [peer [nbma | tunnel {ip-address}]] | [vrf

{vrf-name}] | [interface {tunnel number}]}] | [{error | detail | packet | all} {nhrp | crypto |
tunnel | socket | all}]}
Syntax Description condition (Optional) Specifies conditional debugging based on error level setting.
unmatched (Optional) Specifies debugging when context information is not available.
peer (Optional) Specifies information for a specific DMVPN peer.
nbma (Optional) Displays DMVPN information based on peer mapping
nonbroadcast access (NBMA) address.
tunnel (Optional) Displays DMVPN information based on the peer virtual private
network (VPN) address.
ip-address (Optional) Specifies DMVPN peer IP address.
vrf vrf-name (Optional) Displays information based on the specified virtual routing
forwarding (VRF) name.
interface (Optional) Displays DMVPN information based on a specific interface.
tunnel number (Optional) Specifies the tunnel address for a DMVPN peer.
error (Optional) Enables error level debugging.
detail (Optional) Enables detail level debugging.
packet (Optional) Enables packet level debugging.
all (Optional) Enables all levels of debugging.
nhrp (Optional) Enables Next Hop Resolution Protocol (NHRP) debugging only.
crypto (Optional) Enables crypto Internet Key Exchange (IKE) and IPsec
debugging only.
tunnel (Optional) Enables tunnel protection debugging only.
socket (Optional) Enables crypto secure socket debugging only.
all (Optional) Enables NHRP, sockets, tunnel protection and crypto debugging.
Command Default DMVPN debugging is not enabled.

May 2008 DB-547
Debug Commands
debug dmvpn

Usage Guidelines Conditional debugging will be in effect once the debug level has been specified. Either error level, detail
level, packet level, or all debug levels may be turned on. Once conditional debugging is enabled, the
condition keyword must be specified if you wish to disable conditional debugging.
There are three levels of debugging. From the least detailed information to the most detailed information,
the DMVPN debugging levels are: error level, detail level, and packet level.
Error Level Debugging

When error level debugging is enabled with the debug dmvpn error command, the following debugging
commands are enabled by default:
debug crypto ipsec error
debug crypto isakmp error
debug nhrp error
Detail Level Debugging

When event level debugging is enabled with the debug dmvpn detail command, the following
debugging commands are enabled by default:
debug crypto ipsec
debug crypto isakmp
debug crypto sockets
debug nhrp
debug nhrp cache
debug nhrp rate
debug tunnel protection
Packet Level Debugging

When event level debugging is enabled with the debug dmvpn packet command, the following
debugging commands are enabled by default:
debug nhrp extension
debug nhrp packet
Note Executing debug dmvpn all all with a high number of active sessions, may result in high CPU utilization
and large data output.
Examples The following example shows how to enable conditional DMVPN debugging for a specific peer NBMA
address:

DB-548 May 2008
Debug Commands
debug dmvpn
Router# debug dmvpn condition peer nbma 192.0.2.1

The following example shows how to enable conditional DMVPN debugging when context is not
available to check against debugging conditions:
Router# debug dmvpn condition unmatched
The following example shows how to disable conditional debugging for a specific tunnel interface,
tunnel1:
Router# no debug dmvpn condition interface tunnel1
The following example shows how to disable all conditional debugging:

Router# no debug dmvpn condition

debug nhrp condition Enables NHRP conditional debugging.
debug nhrp error Displays NHRP error level debugging information.

May 2008 DB-549
Debug Commands
debug dot11 aaa
debug dot11 aaa

To enable debugging of dot11 authentication, authorization, and accounting (AAA) operations, use the
debug dot11 aaa command in privileged EXEC mode. To disable or stop the debug operation, use the
debug dot11 aaa {accounting | authenticator {all | dispatcher | mac-authen | process | rxdata |
state-machine | txdata} | dispatcher | manager {all | dispatcher | keys | rxdata |
state-machine | supplicant | txdata}}
no debug dot11 aaa {accounting | authenticator {all | dispatcher | mac-authen | process | rxdata
| state-machine | txdata} | dispatcher | manager {all | dispatcher | keys | rxdata |
state-machine | supplicant | txdata}}
Syntax Descriptionn accounting Provides information about 802.11 AAA accounting packets.
authenticator Provides information about MAC and Extensible Authentication Protocol (EAP)
authentication packets.
Use the following options to activate authenticator debugging:
allActivates debugging for all authenticator packets
dispatcherActivates debugging for authentication request handler packets
mac-authenActivates debugging for MAC authentication packets
processActivates debugging for authenticator process packets
rxdataActivates debugging for EAP over LAN (EAPOL) packets from
client devices
state-machineActivates debugging for authenticator state-machine
packets
txdataActivates debugging for EAPOL packets sent to client devices
dispatcher Provides information about 802.11 AAA dispatcher (interface between
association and manager) packets.
manager Provides information about the AAA manager. Use these options to activate AAA
manager debugging:
allActivates all AAA manager debugging
dispatcherActivates debug information for AAA manager-authenticator
dispatch traffic
keysActivates debug information for AAA manager key processing
rxdataActivates debugging for AAA manager packets received from client
devices
state-machineActivates debugging for AAA manager state-machine
packets
supplicantActivates debugging for Light Extensible Authentication
Protocol (LEAP) supplicant packets
txdataActivates debugging for AAA manager packets sent to client
devices.

DB-550 May 2008
Debug Commands
debug dot11 aaa
Command Default Debugging is disabled.

12.2(4)JA This command was introduced.
12.2(15)JA This command was modified to include the accounting, authenticator,
dispatcher, and manager debugging options.
Usage Guidelines Use this command to display debugging information about dot11 AAA operations.
Examples The following example shows how to activate debugging for 802.11 AAA accounting packets:
Router# debug dot11 aaa accounting

debug dot11 Enables debugging of radio functions.
debug dot11 dot11radio Enables radio debug options.

May 2008 DB-551
Debug Commands
debug dot11 cac
debug dot11 cac

Use the debug dot11 cac privileged EXEC command to begin debugging of admission control radio
functions. Use the no form of this command to stop the debug operation.
[no] debug dot11 cac

{events | unit}
Note This command is not supported on repeaters.
Syntax Description events Activates debugging of radio admission control events.

unit Activates verbose debugging of radio admission control events.

Examples This example shows how to begin debugging of all admission control radio-related events:
SOAP-AP# debug dot11 cac events
This example shows how to begin verbose debugging of all admission control radio-related events:
SOAP-AP# debug dot11 cac unit
This example shows how to stop debugging of all admission control radio-related events:
SOAP-AP# debug dot11 cac events
This example shows how to stop verbose debugging of all admission control radio-related events:
SOAP-AP# no debug dot11 cac unit

DB-552 May 2008
Debug Commands
debug dot11 cac

admin-traffic (SSID Enables CAC admission control for an SSID on the access point.
configuration mode)
admit-traffic (QOS Class Configures CAC admission control on the access point.
interface configuration mode)
show debugging Displays all debug settings and the debug packet headers
show dot11 ids eap Displays all CAC radio events on the access point.
traffic-stream Configures CAC traffic data rates and priorities for a radio interface
on the access point.

May 2008 DB-553
Debug Commands
debug dot11 dot11radio

To enable radio debug options, use the debug dot11 dot11radio command in privileged EXEC mode.
To disable debug options, use the no form of this command.
debug dot11 dot11radio interface {accept-radio-firmware | dfs simulate [channel] | monitor {ack
| address | beacon | crc | lines | plcp | print | probe | store} | print {hex | if | iv | lines | mic |
plcp | printf | raw | shortadr} | stop-on-failure | trace {off | print | store}}
no debug dot11 dot11radio interface {accept-radio-firmware | dfs simulate [channel] | monitor

{ack | address | beacon | crc | lines | plcp | print | probe | store} | print {hex | if | iv | lines |
mic | plcp | printf | raw | shortadr} | stop-on-failure | trace {off | print | store}}
Syntax Description interface The radio interface. The 2.4-GHz radio is 0. The 5-GHz radio is 1.
accept-radio-firmware Configures the access point to disable checking the radio firmware version.
dfs simulate Configures the access point to simulate radar generation as part of Dynamic
Frequency Selection (DFS).
channel (Optional) Radio channel to move to. Range is 24 to 161.
monitor Enables RF monitor mode. Use these options to turn on monitor modes:
ackDisplays ACK packets. ACK packets acknowledge receipt of a
signal, information, or packet.
addressDisplays packets to or from the specified IP address
beaconDisplays beacon packets
crcDisplays packets with CRC errors
linesSpecifies a print line count
plcpDisplays Physical Layer Control Protocol (PLCP) packets
printEnables RF monitor printing mode
probeDisplays probe packets
storeEnables RF monitor storage mode
print Enables packet printing. Use these options to turn on packet printing:
hexPrints entire packets without formatting
ifPrints the in and out interfaces for packets
ivPrints the packet Wired Equivalent Privacy (WEP) IV
linesPrints the line count for the trace
micPrints the Cisco Message Integrity Check (MIC)
plcpDisplays the PLCP
printfPrints using printf instead of buginf
rawPrints without formatting data
shortadrPrints MAC addresses in short form

DB-554 May 2008
Debug Commands
stop-on-failure Configures the access point to not restart when the radio driver fails.
trace Enables trace mode. Use these options to turn on trace modes:
offTurns off traces
printEnables trace printing
storeEnables trace storage

Usage Guidelines Use this command to display debugging information about radio options.
Examples This example shows how to begin monitoring of all packets with CRC errors:
Router# debug dot11 dot11radio 0 monitor crc

debug dot11 Enables debugging of radio functions.
debug dot11 aaa Enables debugging of dot11 AAA operations.

May 2008 DB-555
Debug Commands
debug dot11 ids
debug dot11 ids

Use the debug dot11 ids eap privileged EXEC command to enable debugging for wireless IDS
monitoring. Use the no form of the command to disable IDS debugging.
[no] debug dot11 ids {eap | cipher-errors}
Note This command is not supported on 1400 series bridges.
Syntax Description eap Activates debugging of IDS authentication events

cipher-errors Activates debugging of cipher errors detected by IDS

Examples This example shows how to activate wireless IDS debugging for authentication events:
SOAP-AP# debug dot11 ids eap

dot11 ids eap attempts Configures limits on authentication attempts and EAPOL
flooding on scanner access points in monitor mode
show dot11 ids eap Displays wireless IDS statistics

DB-556 May 2008
Debug Commands
debug dot11 ids mfp
debug dot11 ids mfp

Use the debug dot11 ids mfp privileged EXEC command to debug Management Frame Protection
(MFP) operations on the access point.
[no] debug dot11 ids mfp

ap [all] [detectors] [events] [generators] [io] [reporting] |
wds [all] [detectors] [events] [generators] [reporting] [statistics] |
wlccp
Syntax Description ap Debugs MFP events on the access point.

all Debugs all MFP events.
detectors Debugs MFP detector key management events.
events Debugs high level MFP events.
generators Debugs MFP generator key management events.
io Debugs MFP IO (generate or detect frame) events.
reporting Debugs MFP reporting events.
statistics Debugs MFP WDS statistics received from the detectors.
wds Debugs MFP WDS events.
wlccp Debugs MFP WLCCP messages.
Defaults There are no defaults for this command.

Examples This example shows how to debug the MFP detectors on the access point:
ap(config)# debug dot11 ids mfp ap detectors

dot11 ids mfp Configures MFP parameters on the access point.
show dot11 ids mfp Displays MFP parameters on the access point.

May 2008 DB-557
Debug Commands
debug dot11
debug dot11
Use the debug dot11 privileged EXEC command to begin debugging of radio functions. Use the no form
of this command to stop the debug operation.
[no] debug dot11

{events | packets | forwarding | mgmt | network-map | syslog | virtual-interface}
Syntax Description events Activates debugging of all radio related events

packets Activates debugging of radio packets received and transmitted
forwarding Activates debugging of radio forwarded packets
mgmt Activates debugging of radio access point management activity
network-map Activates debugging of radio association management network map
syslog Activates debugging of radio system log
virtual-interface Activates debugging of radio virtual interfaces

Examples This example shows how to begin debugging of all radio-related events:
SOAP-AP# debug dot11 events
This example shows how to begin debugging of radio packets:

SOAP-AP# debug dot11 packets
This example shows how to begin debugging of the radio system log:
SOAP-AP# debug dot11 syslog
This example shows how to stop debugging of all radio related events:
SOAP-AP# no debug dot11 events

DB-558 May 2008
Debug Commands
debug dot11

show interfaces dot11radio Displays configuration and status information for the radio interface

May 2008 DB-559
Debug Commands
debug dot1x (EtherSwitch)

To enable debugging of the 802.1x protocol when an Ethernet switch network module is installed, use
the debug dot1x command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
debug dot1x {all | authsm | backend | besm | core | reauthsm}
no debug dot1x {all | authsm | backend | besm | core | reauthsm}
Syntax Description all Enables debugging of all conditions.

authsm Enables debugging of the authenticator state machine, which is responsible
for controlling access to the network through 802.1x-enabled ports.
backend Enables debugging of the interaction between the 802.1x process and the router
RADIUS client.
besm Enables debugging of the backend state machine, which is responsible for
relaying authentication request between the client and the authentication
server.
core Enables debugging of the 802.1x process, which includes 802.1x initialization,
configuration, and the interaction with the port manager module.
reauthsm Enables debugging of the reauthentication state machine, which manages
periodic reauthentication of the client.
Defaults Debugging is disabled.

12.1(6)EA2 This command was introduced.
12.2(15)ZJ This command was implemented on the following platforms: Cisco 2600
series, Cisco 3600 series, and Cisco 3700 series routers.
12.3(4)T This command was integrated into Cisco IOS Release 12.3(4)T on the
following platforms: Cisco 2600 series, Cisco 3600 series, and Cisco 3700
series routers.
Usage Guidelines The undebug dot1x command is the same as the no debug dot1x command.

DB-560 May 2008
Debug Commands

show debugging Displays information about the types of debugging that are enabled.
show dot1x Displays 802.1x statistics, administrative status, and operational status for
the router or for the specified interface.

May 2008 DB-561
Debug Commands
debug dot1x
debug dot1x
To display 802.1X debugging information, use the debug dot1x command in privileged EXEC mode. To
debug dot1x [all | errors | events | feature | packets | redundancy | registry | state-machine]
no debug dot1x [all | errors | events | feature | packets | redundancy | registry | state-machine]
Syntax Description all (Optional) Enables all 802.1X debugging messages.

errors (Optional) Provides information about all 802.1X errors.
events (Optional) Provides information about all 802.1X events.
feature (Optional) Provides information about 802.1X features for switches only.
packets (Optional) Provides information about all 802.1X packets.
redundancy (Optional) Provides information about 802.1X redundancy.
registry (Optional) Provides information about 802.1X registries.
state-machine (Optional) Provides information regarding the 802.1X state machine.

12.1(11)AX This command was introduced.
12.1(14)EA1 The authsm, backend, besm, core, and reauthsm keywords were removed.
The errors, events, packets, registry, and state-machine keywords were
added.
12.3(2)XA This command was integrated into Cisco IOS Release 12.3(2)XA.
12.3(11)T The supplicant keyword was added.
12.2(25)SEE The feature keyword was added for switches only.
12.4(6)T The redundancy keyword was added. The aaa, process, rxdata,
supplicant, txdata, and vlan keywords were deleted.
Examples The following is sample output for the debug dot1x command:
Router# debug dot1x
Router-871#debug dot1x all

*Nov 7 13:07:56.872: dot1x-ev:dot1x_mgr_pre_process_eapol_pak: Role determination not
required on FastEthernet1.

DB-562 May 2008
Debug Commands
debug dot1x
*Nov 7 13:07:56.876: dot1x-packet:dot1x_mgr_process_eapol_pak: queuing an EAPOL pkt on

Authenticator Q
*Nov 7 13:07:56.876: dot1x-ev:Enqueued the eapol packet to the global authenticator queue
*Nov 7 13:07:56.876: dot1x-packet:Received an EAPOL frame on interface FastEthernet1
*Nov 7 13:07:56.876: dot1x-ev:Received pkt saddr =000f.23c4.a401 , daddr =
0180.c200.0003,
pae-ether-type = 888e.0202.0000
*Nov 7 13:07:56.876: dot1x-packet:Received an EAPOL-Logoff packet on interface
FastEthernet1
*Nov 7 13:07:56.876: EAPOL pak dump rx
*Nov 7 13:07:56.876: EAPOL Version: 0x2 type: 0x2 length: 0x0000
*Nov 7 13:07:56.876: dot1x-sm:Posting EAPOL_LOGOFF on Client=82AC85CC
*Nov 7 13:07:56.876: dot1x_auth Fa1: during state auth_authenticating, got event
7(eapolLogoff)
The fields in the output are self-explanatory.

clear dot1x Clears 802.1X interface information.
identity profile default Creates an identity profile and enters identity profile configuration
mode.
show dot1x Displays details for an identity profile.

May 2008 DB-563
Debug Commands
debug drip event
debug drip event

To display debugging messages for Duplicate Ring Protocol (DRiP) events, use the debug drip event
debug drip event
no debug drip event
Defaults Debugging is disabled for DRiP events.

Usage Guidelines When a TrBRF interface is configured on the Remote Switch Module (RSM), the DRiP protocol is
activated. The DRiP protocol adds the VLAN ID specified in the router command to its database and
recognizes the VLAN as a locally configured, active VLAN.
Examples The following is sample output from the debug drip event command:
Router# debug drip event
DRiP gets a packet from the network:

612B92C0: 01000C00 00000000 0C501900 0000AAAA .........P....**
612B92D0: 0300000C 00020000 00000100 0CCCCCCC .............LLL
612B92E0: 00000C50 19000020 AAAA0300 000C0102 ...P... **......
612B92F0: 01010114 00000002 00000002 00000C50 ...............P
612B9300: 19000001 04C00064 04 .....@.d.
DRiP gets a packet from the network:

Recvd. pak
DRiP recognizes that the VLAN ID it is getting is a new one from the network:
6116C840: 0100 0CCCCCCC ...LLL
6116C850: 00102F72 CBFB0024 AAAA0300 000C0102 ../rK{.$**......
6116C860: 01FF0214 0002E254 00015003 00102F72 ......bT..P.../r

DB-564 May 2008
Debug Commands
debug drip event
6116C870: C8000010 04C00014 044003EB 14 H....@...@.k.

DRIP : remote update - Never heard of this vlan
DRiP attempts to resolve any conflicts when it discovers a new VLAN. The value action = 1 means to
notify the local platform of change in state.
DRIP : resolve remote for vlan 20 in VLAN0
DRIP : resolve remote - action = 1
The local platform is notified of change in state:

DRIP Change notification active vlan 20
Another new VLAN ID was received in the packet:

DRIP : resolve remote for vlan 1003 in Vlan0
No action is required:
DRIP : resolve remote - action = 0
Thirty seconds have expired, and DRiP sends its local database entries to all its trunk ports:
DRIP : local timer expired
DRIP : transmit on 0000.0c50.1900, length = 24
612B92C0: 01000C00 00000000 0C501900 0000AAAA .........P....**
612B92D0: 0300000C 00020000 00000100 0CCCCCCC .............LLL
612B92E0: 00000C50 19000020 AAAA0300 000C0102 ...P... **......
612B92F0: 01FF0114 00000003 00000002 00000C50 ...............P
612B9300: 19000001 04C00064 04 .....@.d.

May 2008 DB-565
Debug Commands
debug drip packet
debug drip packet

To display debugging messages for Duplicate Ring Protocol (DRiP) packets, use the debug drip packet
debug drip packet
no debug drip packet
Defaults Debugging is not enabled for DRiP packets.

Usage Guidelines Before you use this command, you can optionally use the clear drip command first. As a result the DRiP
counters are reset to 0. If the DRiP counters begin to increment, the router is receiving packets.
Examples The following is sample output from the debug drip packet command:
Router# debug drip packet
The following type of output is displayed when a packet is entering the router and you use the show
debug command:
039E5FC0: 0100 0CCCCCCC 00E0A39B 3FFB0028 ...LLL.`#.?{.(
039E5FD0: AAAA0300 000C0102 01FF0314 0000A5F6 **............%v
039E5FE0: 00008805 00E0A39B 3C000000 04C00028 .....`#.<....@.(
039E5FF0: 04C00032 044003EB 0F .@.2.@.k.
039FBD20: 01000C00 00000010 ........
The following type of output is displayed when a packet is sent by the router:
039FBD30: A6AEB450 0000AAAA 0300000C 00020000 &.4P..**........
039FBD40: 00000100 0CCCCCCC 0010A6AE B4500020 .....LLL..&.4P.
039FBD50: AAAA0300 000C0102 01FF0114 00000003 **..............
039FBD60: 00000002 0010A6AE B4500001 04C00064 ......&.4P...@.d
039FBD70: 04 .

DB-566 May 2008
Debug Commands
debug drip packet

debug drip event Displays debugging messages for DRiP events.

May 2008 DB-567
Debug Commands
debug dsc clock
debug dsc clock

To display debugging output for the time-division multiplexing (TDM) clock-switching events on the dial
shelf controller (DSC), use the debug dsc clock command in privileged EXEC mode. To disable
[execute-on] debug dsc clock
[execute-on] no debug dsc clock
Syntax Description This command has no arguments or keywords; however, it can be used with the execute-on command.

Usage Guidelines To perform this command from the router shelf on the Cisco AS5800 series platform, use the execute-on
slot slot-number debug dsc clock form of this command.
The debug dsc clock command displays TDM clock-switching events on the dial shelf controller. The
information displayed includes the following:
Clock configuration messages received from trunks via NBUS
Dial shelf controller clock configuration messages from the router shelf over the dial shelf interface
link
Clock switchover algorithm events
Examples The following example shows that the debug dsc clock command has been enabled, and that trunk
messages are received, and that the configuration message has been received:
AS5800# debug dsc clock
Dial Shelf Controller Clock debugging is on

AS5800#
00:02:55: Clock Addition msg of len 12 priority 8 from slot 1 port 1 on line 0
00:02:55: Trunk 1 has reloaded

DB-568 May 2008
Debug Commands
debug dsc clock

execute-on Executes commands remotely on a line card.
show dsc clock Displays information about the dial shelf controller clock.

May 2008 DB-569
Debug Commands
debug dsip
debug dsip
To display debugging output for Distributed System Interconnect Protocol (DSIP) used between a router shelf
and a dial shelf, use the debug dsip command in privileged EXEC mode. To disable debugging output, use
debug dsip {all | api | boot | console | trace | transport}
no debug dsip {all | api | boot | console | trace | transport}
Syntax Description all View all DSIP debugging messages.

api View DSIP client interface (API) debugging messages.
boot View DSIP booting messages that are generated when a download of the
feature board image is occurring properly.
console View DSIP console operation while debugging.
trace Enable logging of header information concerning DSIP packets entering the
system into a trace buffer. This logged information can be viewed with the
show dsip tracing command.
transport Debug the DSIP transport layer, the module that interacts with the underlying
physical media driver.

Usage Guidelines The debug dsip command is used to enable the display of debugging messages for DSIP between the
router shelf and the dial shelf. Using this command, you can display booting messages generated when
the download of an image occurs, view console operation, and trace logging of MAC header information
and DSIP transport layer information as modules interact with the underlying physical media driver. This
command can be applied to a single modem or a group of modems.
Once the debug dsip trace command has been enabled, you can read the information captured in the
trace buffer using the show dsip tracing command.

DB-570 May 2008
Debug Commands
debug dsip
Examples The following example indicates the debug dsip trace command logs MAC headers of the various
classes of DSIP packets. To view the logged information, use the show dsip tracing command:
AS5800# debug dsip trace
NIP tracing debugging is on
AS5800# show dsip tracing
NIP Control Packet Trace

------------------------------------------------------------
Dest:00e0.b093.2238 Src:0007.4c72.0058 Type:200B SrcShelf:1 SrcSlot:11
MsgType:0 MsgLen:82 Timestamp: 00:49:14
------------------------------------------------------------
Dest:00e0.b093.2238 Src:0007.4c72.0028 Type:200B SrcShelf:1 SrcSlot:5
MsgType:0 MsgLen:82 Timestamp: 00:49:14
------------------------------------------------------------

debug modem Displays information about the dial shelf, including clocking
information.
show dsip tracing Displays DSIP media header information logged using the
debug dsip trace command.

May 2008 DB-571
Debug Commands
debug dspapi
debug dspapi
Note Effective with release 12.3(8)T, the debug dspapi command is replaced by the debug voip dspapi
command. See the debug voip dspapi command for more information.
To enable debugging for Digital Signal Processor (DSP) application programming interface (API)
message events, use the debug dspapi command in privileged EXEC mode. To reset the default value
for this feature, use the no form of this command.
debug dspapi {all | command | detail | error | notification | response}
no debug dspapi {all | command | detail | error | notification | response}
Syntax Description all Enables all debug dspapi options (command, detail, error, notification and
response).
command Displays commands sent to the DSPs.
detail Displays additional detail for the DSP API debugs enabled.
error Displays any DSP API errors.
notification Displays notification messages sent from the DSP (for example, tone detection
notification).
response Displays responses sent by the DSP (for example, responses to statistic
requests).
Defaults This command is not enabled.

12.1(5)XM This command was introduced on the Cisco AS5300 and Cisco AS5800.
12.1(5)XM1 This command was implemented on the Cisco AS5350 and Cisco AS5400.
12.2(2)T This command was implemented on the Cisco 1700, Cisco 2600 series,
Cisco 3600 series, and the Cisco 3810.
12.3(8)T This command was replaced by the debug voip dspapi command.
12.2SX This command is supported in the Cisco IOS Release 12.2SX train. Support in
a specific 12.2SX release of this train depends on your feature set, platform, and
platform hardware.

DB-572 May 2008
Debug Commands
debug dspapi
Usage Guidelines DSP API message events used to communicate with DSPs are intended for use with Connexant
(Nextport) and Texas Instrument (54x) DSPs. This command severely impacts performance and should
be used only for single-call debug capture.
Examples The following example shows how to enable debugging for all DSP API message events:
Router# debug dspapi all

debug hpi Enables debugging for HPI message events.

May 2008 DB-573
Debug Commands
debug dspfarm
debug dspfarm
To display digital signal processor (DSP) farm service debugging information, use the debug dspfarm
debug dspfarm {all | errors | events | packets}
no debug dspfarm
Syntax Description all All DSP-farm debug-trace information.

errors DSP-farm errors.
events DSP-farm events.
packets DSP-farm packets.

12.1(5)YH This command was introduced on the Cisco VG200.
12.2(13)T This command was implemented on the Cisco 2600 series, Cisco 3620,
Cisco 3640, Cisco 3660, and Cisco 3700 series.
Usage Guidelines The router on which this command is used must be equipped with one or more digital T1/E1 packet voice
trunk network modules (NM-HDVs) or high-density voice (HDV) transcoding/conferencing DSP farms
(NM-HDV-FARMs) to provide DSP resources.
Debugging is turned on for all DSP-farm-service sessions. You can debug multiple sessions
simultaneously, with different levels of debugging for each.
Examples The following is sample output from the debug dspfarm events command:
Router# debug dspfarm events
DSP Farm service events debugging is on
*Mar 1 00:45:51: Sent 180 bytes to DSP 4 channel 2


DB-574 May 2008
Debug Commands
debug dspfarm

*Mar 1 00:46:01: xapi_dspfarm_modify_connection: sess_id 26, conn_id 2705, conn_mode 3,
ripaddr 10.10.1.7, rport 20170
*Mar 1 00:46:01: dspfarm_process_appl_event_queue: XAPP eve 6311C4B0 rcvd
*Mar 1 00:46:01: dspfarm_find_stream: stream 63121F1C, found in sess 631143CC, cid 2705
*Mar 1 00:46:01: dspfarm_modify_connection: old_mode 4, new_mode 3
*Mar 1 00:46:01: dspfarm_close_local_rtp: stream 63121F1C, local_rtp_port 22656
*Mar 1 00:46:01: xapi_dspfarm_enqueue_event_to_appl: handle 63120634, event 6311C4C8,
eve_id 5, context 6311426C, result 0
*Mar 1 00:46:01: xapi_dspfarm_delete_connection: sess_id 26, conn_id 2705
*Mar 1 00:46:01: dspfarm_process_appl_event_queue: XAPP eve 6311C4E0 rcvd
*Mar 1 00:46:01: dspfarm_find_stream: stream 63121F1C, found in sess 631143CC, cid 2705
*Mar 1 00:46:01: dspfarm_close_local_rtp: stream 63121F1C, local_rtp_port 0
*Mar 1 00:46:01: dspfarm_release_dsp_resource: sess 631143CC, stream 63121F1C, num_stream
3, sess_type 2, sess_dsp_id 2040000, stream_dsp_id 2040002
*Mar 1 00:46:01: dspfarm_drop_conference:slot 2 dsp 4 ch 2
*Mar 1 00:46:01: dspfarm_send_drop_conf: Sent drop_conference to DSP 4 ch 2
*Mar 1 00:46:01: dspfarm_xapp_enq: Sent msg 8 to DSPFARM
*Mar 1 00:46:01: xapi_dspfarm_enqueue_event_to_appl: handle 63120634, event 6311C4F8,
eve_id 9, context 6311426C, result 0
*Mar 1 00:46:01: dspfarm_process_dsp_event_queue: DSP eve 6312078C rcvd
*Mar 1 00:46:01: dspfarm_delete_stream: sess_id 26, conn_id 2705, stream 63121F1C, in
sess 631143CC is freed
*Mar 1 00:46:05: dspfarm_process_appl_event_queue: XAPP eve 6311C510 rcvd
*Mar 1 00:46:05: dspfarm_find_stream: stream 63121E34, found in sess 631143CC, cid 2689
*Mar 1 00:46:05: dspfarm_close_local_rtp: stream 63121E34, local_rtp_port 25834
*Mar 1 00:46:05: xapi_dspfarm_enqueue_event_to_appl: handle 63120634, event 6311C528,
eve_id 5, context 63114244, result 0
*Mar 1 00:46:05: dspfarm_find_stream: stream 63121E34, found in sess 631143CC, cid 2689
*Mar 1 00:46:05: dspfarm_close_local_rtp: stream 63121E34, local_rtp_port 0
*Mar 1 00:46:05: dspfarm_release_dsp_resource: sess 631143CC, stream 63121E34, num_stream
*Mar 1 00:46:05: dspfarm_send_drop_conf: Sent drop_conference to DSP 4 ch 1
*Mar 1 00:46:05: dspfarm_delete_stream: sess_id 26, conn_id 2689, stream 63121E34, in
*Mar 1 00:46:05: dspfarm_find_stream: stream 63122004, found in sess 631143CC, cid 2721
*Mar 1 00:46:05: dspfarm_close_local_rtp: stream 63122004, local_rtp_port 19912
*Mar 1 00:46:05: dspfarm_process_appl_event_queue: XAPP eve 6311C5A0 rcvd
*Mar 1 00:46:05: dspfarm_find_stream: stream 63122004, found in sess 631143CC, cid 2721
*Mar 1 00:46:05: dspfarm_close_local_rtp: stream 63122004, local_rtp_port 0
*Mar 1 00:46:05: dspfarm_release_dsp_resource: sess 631143CC, stream 63122004, num_stream
*Mar 1 00:46:05: dspfarm_drop_conference: Last conferee - closing the conf session

May 2008 DB-575
Debug Commands
debug dspfarm
*Mar 1 00:46:05: dspfarm_send_close_conf: Sent close_conference to DSP 4

*Mar 1 00:46:05: dspfarm_drop_conference: Removed the conf in dsp 4
*Mar 1 00:46:05: xapi_dspfarm_enqueue_event_to_appl: handle 63120634, event 6311C5B8,
*Mar 1 00:46:05: dspfarm_delete_stream: sess_id 26, conn_id 2721, stream 63122004, in

debug frame-relay vc-bundle Sets debugging for SCCP and its applications at one of four levels.
dspfarm (DSP farm) Enables DSP-farm service.
sccp Enables SCCP and its associated transcoding and conferencing
applications.
show dspfarm Displays summary information about DSP resources.

DB-576 May 2008
Debug Commands
debug dspu activation

To display information on downstream physical unit (DSPU) activation, use the debug dspu activation
debug dspu activation [name]
no debug dspu activation [name]
Syntax Description name (Optional) The host or physical unit (PU) name designation.
Usage Guidelines The debug dspu activation command displays all DSPU activation traffic. To restrict the output to a
specific host or PU, include the host or PU name argument. You cannot turn off debugging output for an
individual PU if that PU has not been named in the debug dspu activation command.
Examples The following is sample output from the debug dspu activation command. Not all intermediate numbers
are shown for the activated and deactivated logical unit (LU) address ranges.
Router# debug dspu activation
DSPU: LS HOST3745 connected

DSPU: PU HOST3745 activated
DSPU: LU HOST3745-2 activated
.
.
.
DSPU: LU HOST3745-2 deactivated

.
.
.
DSPU: LS HOST3745 disconnected
DSPU: PU HOST3745 deactivated

May 2008 DB-577
Debug Commands
Table 77 debug dspu activation Field Descriptions
Field Description
DSPU Downstream PU debugging message.
LS Link station (LS) event triggered the message.
PU PU event triggered the message.
LU LU event triggered the message.
HOST3745 Host name or PU name.
HOST3745-253 Host name or PU name and the LU address, separated by a dash.
connected Event that occurred to trigger the message.
activated
disconnected
deactivated

debug dspu packet Displays information on a DSPU packet.
debug dspu state Displays information on DSPU FSM state changes.
debug dspu trace Displays information on DSPU trace activity.

DB-578 May 2008
Debug Commands
debug dspu packet
debug dspu packet

To display information on a downstream physical unit (DSPU) packet, use the debug dspu packet
debug dspu packet [name]
no debug dspu packet [name]
Syntax Description name (Optional) The host or PU name designation.
Usage Guidelines The debug dspu packet command displays all DSPU packet data flowing through the router. To restrict
the output to a specific host or physical unit (PU), include the host or PU name argument. You cannot
turn off debugging output for an individual PU if that PU has not been named in the debug dspu packet
command.
Examples The following is sample output from the debug dspu packet command:
Router# debug dspu packet
DSPU: Rx: PU HOST3745 data length 12 data:

2D0003002BE16B80 000D0201
DSPU: Tx: PU HOST3745 data length 25 data:
2D0000032BE1EB80 000D020100850000 000C060000010000 00
DSPU: Rx: PU HOST3745 data length 12 data:
2D0004002BE26B80 000D0201
DSPU: Tx: PU HOST3745 data length 25 data:
2D0000042BE2EB80 000D020100850000 000C060000010000 00
Table 78 debug dspu packet Field Descriptions
Field Description
DSPU: Rx: Received frame (packet) from the remote PU to the router PU.
DSPU: Tx: Transmitted frame (packet) from the router PU to the remote PU.
PU HOST3745 Host name or PU associated with the transmit or receive.
data length 12 data: Number of bytes of data, followed by up to 128 bytes of displayed data.

debug drip event Displays debugging messages for DRiP packets.

May 2008 DB-579
Debug Commands
debug dspu state
debug dspu state

To display information on downstream physical unit (DSPU) finite state machine (FSM) state changes,
use the debug dspu state command in privileged EXEC mode. To disable debugging output, use the no
debug dspu state [name]
no debug dspu state [name]
Usage Guidelines Use the debug dspu state command to display only the FSM state changes. To see all FSM activity, use
the debug dspu trace command. You cannot turn off debugging output for an individual PU if that PU
has not been named in the debug dspu state command.
Examples The following is sample output from the debug dspu state command. Not all intermediate numbers are
shown for the activated and deactivated logical unit (LU) address ranges.
Router# debug dspu state
DSPU: LS HOST3745: input=StartLs, Reset -> PendConOut

DSPU: LS HOST3745: input=ReqOpn.Cnf, PendConOut -> Xid
DSPU: LS HOST3745: input=Connect.Ind, Xid -> ConnIn
DSPU: LS HOST3745: input=Connected.Ind, ConnIn -> Connected
DSPU: PU HOST3745: input=Actpu, Reset -> Active
DSPU: LU HOST3745-2: input=uActlu, Reset -> upLuActive
.
.
.
DSPU: LS HOST3745: input=PuStopped, Connected -> PendDisc

DSPU: LS HOST3745: input=Disc.Cnf, PendDisc -> PendClose
DSPU: LS HOST3745: input=Close.Cnf, PendClose -> Reset
DSPU: PU HOST3745: input=T2ResetPu, Active -> Reset
DSPU: LU HOST3745-2: input=uStopLu, upLuActive -> Reset
.
.
.

DB-580 May 2008
Debug Commands
debug dspu state
Table 79 debug dspu state Field Descriptions
Field Description
DSPU Downstream PU debug message.
PU PU event triggered the message.
HOST3745-253 Host name or PU name and LU address.
input=input, Input received by the FSM.
previous-state, -> Previous state and current new state as seen by the FSM.
current-state

debug drip packet Displays information on DSPU packet.

May 2008 DB-581
Debug Commands
debug dspu trace
debug dspu trace

To display information on downstream physical unit (DSPU) trace activity, which includes all finite state
machine (FSM) activity, use the debug dspu trace command in privileged EXEC mode. To disable
debug dspu trace [name]
no debug dspu trace [name]
Usage Guidelines Use the debug dspu trace command to display all FSM state changes. To see FSM state changes only,
use the debug dspu state command. You cannot turn off debugging output for an individual PU if that
PU has not been named in the debug dspu trace command.
Examples The following is sample output from the debug dspu trace command:
Router# debug dspu trace
DSPU: LS HOST3745 input = 0 ->(1,a1)

DSPU: LU HOST3745-2 in:0 s:0->(2,a1)
DSPU: LU HOST3745-3 in:0 s:0->(2,a1)
DSPU: LU HOST3745-252 in:0 s:0->(2,a1)
DSPU: LU HOST3745-253 in:0 s:0->(2,a1)
DSPU: LU HOST3745-254 in:0 s:0->(2,a1)

DB-582 May 2008
Debug Commands
debug dspu trace
Table 80 describes significant fields shown in the output.
Table 80 debug dspu trace Field Descriptions
Field Description
7:23:57 Time stamp.
DSPU Downstream PU debug message.
PU A PU event triggered the message.
HOST3745-253 Host name or PU name and LU address.
in:input s:state ->(new-state, String describing the following:
action)
inputLU FSM input
stateCurrent FSM state
new-stateNew FSM state
actionFSM action
input=input -> String describing the following:
(new-state,action) inputPU or LS FSM input
new-stateNew PU or LS FSM state
actionPU or LS FSM action

debug drip packet Displays information on DSPU packet.

May 2008 DB-583
Debug Commands
debug dss ipx event
debug dss ipx event

To display debugging messages for route change events that affect Internetwork Packet Exchange (IPX)
Multilayer Switching (MLS), use the debug dss ipx event command in privileged EXEC mode. To
debug dss ipx event
no debug dss ipx event

Examples The following is sample output from the debug dss ipx event command:
Router# debug dss ipx event
DSS IPX events debugging is on
Router(config)# interface vlan 22
Router(config-if)# ipx access-group 800 out
05:51:36:DSS-feature:dss_ipxcache_version():idb:NULL, reason:42,
prefix:0, mask:FFFFFFFF
05:51:36:DSS-feature:dss_ipx_access_group():idb:Vlan22
05:51:36:DSS-feature:dss_ipx_access_list()
05:51:36:DSS-base 05:51:33.834 dss_ipx_invalidate_interface Vl22
05:51:36:DSS-base 05:51:33.834 dss_set_ipx_flowmask_reg 2
05:51:36:%IPX mls flowmask transition from 1 to 2 due to new status of
simple IPX access list on interfaces

DB-584 May 2008
Debug Commands
debug dss ipx event

debug mls rp Displays various MLS debugging elements.

May 2008 DB-585
Debug Commands
debug eap
debug eap
To display information about Extensible Authentication Protocol (EAP), use the debug eap command
debug eap [all | method] [authenticator | peer ] {all | errors | events | packets | sm}
no debug eap [all | method] [authenticator | peer ] {all | errors | events | packets | sm}
Syntax Description all | method (Optional) Specifies the method to which the debug command refers.
The all keyword turns on debugging for all EAP methods, including the
EAP framework.
The method argument turns on debugging for specific methods.
This keyword or argument is dynamically linked into the parse chain and
is present only if the method itself is present.
If this keyword or argument is omitted, the debug command is applied
to the EAP framework.
authenticator (Optional) Limits the scope of the output to only authenticator contexts.
peer (Optional) Limits the scope of the output to only peer contexts.
all Debugging is turned on for all debug types.
errors Displays information about EAP packet errors.
events Displays information about EAP events.
packets Turns on packet debugging for the specified method or methods.
sm Turns on state machine debugging for the specified method or methods.

12.4(6)T The method argument and authenticator and peer keywords were added.
Examples The following sample output from the debug eap all command shows all EAP information:
Router# debug eap all
*Nov 7 13:05:58.512: EAP-EVENT: Received get canned status from lower layer (0x00000000)
*Nov 7 13:05:59.460: EAP-EVENT: Received context create from lower layer (0x00000009)
*Nov 7 13:05:59.460: eap_authen : initial state eap_auth_initialize has enter

DB-586 May 2008
Debug Commands
debug eap
*Nov 7 13:05:59.460: EAP-EVENT: Started 'Authenticator Start' timer (1s) for EAP sesion
handle 0xD6000008
*Nov 7 13:05:59.460: EAP-EVENT: Allocated new EAP context (handle = 0xD6000008)
*Nov 7 13:05:59.464: EAP-EVENT: Started EAP tick timer
*Nov 7 13:06:00.488: EAP-EVENT: 'Authenticator Start' timer expired for EAP sesion handle
0xD6000008
*Nov 7 13:06:00.488: eap_authen : during state eap_auth_initialize, got event
21(eapStartTmo)
*Nov 7 13:06:00.488: @@@ eap_authen : eap_auth_initialize -> eap_auth_select_action
*Nov 7 13:06:00.488: eap_authen : during state eap_auth_select_action, got event
17(eapDecisionPropose)
*Nov 7 13:06:00.488: @@@ eap_authen : eap_auth_select_action -> eap_auth_propose_method

debug eou Displays information about EAPoUDP.

May 2008 DB-587
Debug Commands
debug eigrp fsm
debug eigrp fsm

To display debugging information about Enhanced Interior Gateway Routing Protocol (EIGRP) feasible
successor metrics (FSMs), use the debug eigrp fsm command in privileged EXEC mode. To disable
debug eigrp fsm
no debug eigrp fsm

12.4(6)T Support for IPv6 was added.
12.2(37)SE This command was integrated into Cisco IOS Release 12.2(37)SE.
Usage Guidelines This command helps you observe EIGRP feasible successor activity and to determine whether route
updates are being installed and deleted by the routing process.
Examples The following is sample output from the debug eigrp fsm command:
Router# debug eigrp fsm
DUAL: dual_rcvupdate(): 172.25.166.0 255.255.255.0 via 0.0.0.0 metric 750080/0

DUAL: Find FS for dest 172.25.166.0 255.255.255.0. FD is 4294967295, RD is 42949
67295 found
DUAL: RT installed 172.25.166.0 255.255.255.0 via 0.0.0.0
DUAL: dual_rcvupdate(): 192.168.4.0 255.255.255.0 via 0.0.0.0 metric 4294967295/
4294967295
DUAL: 0.0.0.0 metric 4294967295/4294967295not found Dmin is 4294967295
DUAL: Dest 192.168.4.0 255.255.255.0 not entering active state.
DUAL: Removing dest 192.168.4.0 255.255.255.0, nexthop 0.0.0.0
DUAL: No routes. Flushing dest 192.168.4.0 255.255.255.0
In the first line, DUAL stands for diffusing update algorithm. It is the basic mechanism within EIGRP
that makes the routing decisions. The next three fields are the Internet address and mask of the
destination network and the address through which the update was received. The metric field shows the

DB-588 May 2008
Debug Commands
debug eigrp fsm
metric stored in the routing table and the metric advertised by the neighbor sending the information. If
shown, the term Metric... inaccessible usually means that the neighbor router no longer has a route to
the destination, or the destination is in a hold-down state.
In the following output, EIGRP is attempting to find a feasible successor for the destination. Feasible
successors are part of the DUAL loop avoidance methods. The FD field contains more loop avoidance
state information. The RD field is the reported distance, which is the metric used in update, query, or
reply packets.
The indented line with the not found message means a feasible successor (FS) was not found for
192.168.4.0 and EIGRP must start a diffusing computation. This means it begins to actively probe (sends
query packets about destination 192.168.4.0) the network looking for alternate paths to 192.164.4.0.
DUAL: 0.0.0.0 metric 4294967295/4294967295not found Dmin is 4294967295
The following output indicates the route DUAL successfully installed into the routing table:
DUAL: RT installed 172.25.166.0 255.255.255.0 via 0.0.0.0
The following output shows that no routes to the destination were discovered and that the route
information is being removed from the topology table:
DUAL: Dest 192.168.4.0 255.255.255.0 not entering active state.
DUAL: Removing dest 192.168.4.0 255.255.255.0, nexthop 0.0.0.0
DUAL: No routes. Flushing dest 192.168.4.0 255.255.255.0

May 2008 DB-589
Debug Commands
debug eigrp neighbor

To display neighbors discovered by the Enhanced Interior Gateway Routing Protocol (EIGRP), use the
debug eigrp neighbor command in privileged EXEC mode. To disable debugging output, use the no
debug eigrp neighbor [siatimer] [static]
no debug eigrp neighbor [siatimer] [static]
Syntax Description siatimer (Optional) Stuck-in-active (SIA) timer messages.

static (Optional) Static routes.
Command Default Debugging for EIGRP neighbors is not enabled.

Examples The following is sample output from the debug eigrp neighbor command:
Router# debug eigrp neighbor static
EIGRP Static Neighbors debugging is on
Router(config)# router eigrp 100
Router(config-router)# neighbor 10.1.1.1 e3/1
Router(config-router)#
22:40:07:EIGRP:Multicast Hello is disabled on Ethernet3/1!
22:40:07:EIGRP:Add new static nbr 10.1.1.1 to AS 100 Ethernet3/1
Router(config-router)# no neighbor 10.1.1.1 e3/1

DB-590 May 2008
Debug Commands
Router(config-router)#
22:41:23:EIGRP:Static nbr 10.1.1.1 not in AS 100 Ethernet3/1 dynamic list
22:41:23:EIGRP:Delete static nbr 10.1.1.1 from AS 100 Ethernet3/1
22:41:23:EIGRP:Multicast Hello is enabled on Ethernet3/1!

neighbor Defines a neighboring router with which to exchange routing information.
show ip eigrp neighbors Displays EIGRP neighbors.
show ipv6 eigrp Displays IPv6 EIGRP neighbors.
neighbors

May 2008 DB-591
Debug Commands
debug eigrp nsf
debug eigrp nsf

To display nonstop forwarding (NSF) events in the console of the router, use the debug eigrp nsf
debug eigrp nsf
no debug eigrp nsf

Usage Guidelines The output from the debug eigrp nsf command displays NSF-specific events. This command can be
issued on an NSF-capable or NSF-aware router.
Examples The following example enables Enhanced Interior Gateway Routing Protocol (EIGRP) NSF debugging:
Router# debug eigrp nsf

timers nsf route-hold Sets the route-hold timer for NSF-aware routers that run EIGRP.

DB-592 May 2008
Debug Commands
debug eigrp notifications
debug eigrp notifications

To debug notifications sent from the L2L3 API interface, use the debug eigrp notifications command
in privileged EXEC mode. To turn off debugging, use the no form of this command.
debug eigrp notifications {rib | interface}
Syntax Description rib Captures notifications from the routing information base (RIB)
interface Captures notifications from the interface.
Defaults Debugging of EIGRP notifications for the L2L3 API interface is not enabled.

12.4(15)XF This command was introduced.
Usage Guidelines Consult Cisco technical support before using this command.
Caution Use of debug commands can have severe performance penalties and should be used with extreme
caution. For this reason, Cisco recommends that you contact Cisco technical support before enabling a
debug command.
Examples The following example displays information about the L2L3 API Interface:
Router# debug eigrp notifications rib

eigrp interface Sets a threshold value to minimize hysteresis in a router-to-radio
configuration.
interface vmi Creates a virtual multipoint interface (VMI) that can be configured and
applied dynamically.

May 2008 DB-593
Debug Commands
debug eigrp packet
debug eigrp packet

To display debugging information for Enhanced Interior Gateway Routing Protocol (EIGRP) for IPv6
packets, use the debug eigrp packet command in privileged EXEC mode. To disable debugging output,
debug eigrp packet [SIAquery | SIAreply | ack | hello | ipxsap | probe | query | reply | request |
retry | stub | terse | update | verbose]
no debug eigrp packet
Syntax Description SIAquery (Optional) Displays information about Stuck-in-Active (SIA) query messages.
SIAreply (Optional) Displays information about SIA reply messages.
ack (Optional) Displays information about EIGRP acknowledgment packets.
hello (Optional) Displays information about EIGRP hello packets.
ipxsap (Optional) Displays information about IPX EIGRP SAP packets.
probe (Optional) Displays information about EIGRP probe packets.
query (Optional) Displays information about EIGRP query packets.
reply (Optional) Displays information about EIGRP reply packets.
request (Optional) Displays information about EIGRP request packets.
retry (Optional) Displays information about EIGRP retry packets.
stub (Optional) Displays information about EIGRP stub packets.
terse (Optional) Displays information about all EIGRP packets except Hello packets.
update (Optional) Displays information about EIGRP update packets.
verbose (Optional) Displays information about all EIGRP packets.

12.4 The keywords were supported.
Usage Guidelines If a communication session is closing when it should not be, an end-to-end connection problem can be
the cause. The debug eigrp packet command is useful for analyzing the messages traveling between the
local and remote hosts.

DB-594 May 2008
Debug Commands
debug eigrp packet
Note Although this command accepts a number of keywords, we dont recommend their use unless directed
by TAC.
Examples The following is sample output from the debug eigrp packet command:
Router# debug eigrp packet
EIGRP: Sending HELLO on Ethernet0/1

AS 109, Flags 0x0, Seq 0, Ack 0
EIGRP: Received UPDATE on Ethernet0/1 from 192.195.78.24,
EIGRP: Sending HELLO/ACK on Ethernet0/1 to 192.195.78.24,
EIGRP: Sending HELLO/ACK on Ethernet0/1 to 192.195.78.24,
EIGRP: Received UPDATE on Ethernet0/1 from 192.195.78.24,
The output shows transmission and receipt of EIGRP packets. These packet types may be hello, update,
request, query, or reply packets. The sequence and acknowledgment numbers used by the EIGRP reliable
transport algorithm are shown in the output. Where applicable, the network-layer address of the
neighboring router is also included.
Table 81 debug eigrp packet Field Descriptions
Field Description
EIGRP: EIGRP packet information.
AS n Autonomous system number.
Flags 0x0 A flag of 1 means the sending router is indicating to the receiving
router that this is the first packet it has sent to the receiver.
A flag of 2 is a multicast that should be conditionally received by
routers that have the conditionally receive (CR) bit set. This bit gets
set when the sender of the multicast has previously sent a sequence
packet explicitly telling it to set the CR bit.
HELLO Hello packets are the neighbor discovery packets. They are used to
determine whether neighbors are still alive. As long as neighbors
receive the hello packets the router is sending, the neighbors validate
the router and any routing information sent. If neighbors lose the
hello packets, the receiving neighbors invalidate any routing
information previously sent. Neighbors also send hello packets.

May 2008 DB-595
Debug Commands
debug eigrp transmit

To display transmittal messages sent by the Enhanced Interior Gateway Routing Protocol (EIGRP), use
the debug eigrp transmit command in privileged EXEC mode. To disable debugging output, use the no
debug eigrp transmit [ack] [build] [detail] [link] [packetize] [peerdown] [sia] [startup]
[strange]
no debug eigrp transmit [ack] [build] [detail] [link] [packetize] [peerdown] [sia] [startup]
[strange]
Syntax Description ack (Optional) Information for acknowledgment (ACK) messages sent by the
system.
build (Optional) Build information messages (messages that indicate that a
topology table was either successfully built or could not be built).
detail (Optional) Additional detail for debug output.
link (Optional) Information regarding topology table linked-list management.
packetize (Optional) Information regarding topology table linked-list management.
peerdown (Optional) Information regarding the impact on packet generation when a
peer is down.
sia (Optional) Stuck-in-active (SIA) messages.
startup (Optional) Information regarding peer startup and initialization packets that
have been transmitted.
strange (Optional) Unusual events relating to packet processing.
Command Default Debugging for EIGRP transmittal messages is not enabled.


DB-596 May 2008
Debug Commands
Examples The following is sample output from the debug eigrp transmit command:
Router# debug eigrp transmit
EIGRP Transmission Events debugging is on

(ACK, PACKETIZE, STARTUP, PEERDOWN, LINK, BUILD, STRANGE, SIA, DETAIL)

Router#(config)# router eigrp 100
Router#(config-router)# network 10.4.9.0 0.0.0.255
Router#(config-router)#
5d22h: DNDB UPDATE 10.0.0.0/8, serno 0 to 1, refcount 0
Router#(config-router)#

May 2008 DB-597
Debug Commands
debug eou
debug eou
To display information about Extensible Authentication Protocol over User Datagram Protocol (UDP)
(EAPoUDP), use the debug eou command in privileged EXEC mode. To disable debugging output, use
debug eou {all | eap | errors | events | packets | ratelimit | sm}
no debug eou {all | eap | errors | events | packets | ratelimit | sm}
Syntax Description all Displays all EAPoUDP information.

eap Displays EAPoUDP packets.
errors Displays information about EAPoUDP packet errors.
events Displays information about EAPoUDP events.
packets Displays EAPoUDP packet-related information.
ratelimit Displays EAPoUDP posture-validation information.
sm Displays EAPoUDP state machine transitions.
Defaults If you do not enter any keywords, debugging is turned on for all EAPoUDP messages.

Examples The following sample output from the debug eou all command shows all EAPoUDP information:
Router# debug eou all
*Apr 9 19:30:40.782: eou-ev:EOU Init Validation for idb= FastEthernet0/0.420 src_mac=

0001.027c.f364 src_ip= 10.0.0.1
*Apr 9 19:30:40.786: eou_auth 10.0.0.1: initial state eou_initialize has enter
*Apr 9 19:30:40.786: @@@ eou_auth 10.0.0.1: eou_initialize -> eou_hello
*Apr 9 19:30:40.786: eou-ev:eou_send_hello_request: Send Hello Request host= 10.0.0.15
eou_port= 5566 (hex)
*Apr 9 19:30:40.790: EAPoUDP (tx) Flags:0 Ver=1 opcode=2 Len=8 MsgId=3839857370 Assoc
ID=0
*Apr 9 19:30:40.790: Dumping TLV contents
*Apr 9 19:30:40.790: TLV M:1 R:0 Type=ASSOCIATION ID Length=4 Association=-1994800267
*Apr 9 19:30:40.999: EAPoUDP (rx) Flags:128 Ver=1 opcode=2 Len=24 MsgId=3839857370 Assoc

DB-598 May 2008
Debug Commands
debug eou
ID=2300167029
*Apr 9 19:30:40.999: Dumping TLV contents
*Apr 9 19:30:40.999: TLV M:1 R:0 Type=COOKIE PAYLOAD Length=12
07167CE0: 8919C375 259B6D41 5FEA5D27 ..Cu%.mA_j]'
07167CF0:
*Apr 9 19:30:40.999: TLV M:1 R:0 Type=ASSOCIATION ID Length=4 Association=1016688999
*Apr 9 19:31:50.048: @@@ eou_auth 10.0.0.1: eou_eap -> eou_eap

*Apr 9 19:31:50.048: eou-ev:10.0.0.1: msg = 24(eventEouEapSuccess)
*Apr 9 19:31:50.048: eou_auth 10.0.0.1: during state eou_eap, got event
14(eouEapSuccess)
*Apr 9 19:31:50.048: @@@ eou_auth 10.0.0.1: eou_eap -> eou_result
*Apr 9 19:31:50.052: eou-ev:Starting RESULT timer 3(10.0.0.1)

debug eap Displays information about EAP messages.
debug ip admission eapoudp Displays information about EAPoUDP network
admission control events.

May 2008 DB-599
Debug Commands
debug ephone alarm
debug ephone alarm

To set SkinnyStation alarm messages debugging for the Cisco IP phone, use the debug ephone alarm
debug ephone alarm [mac-address mac-address]
no debug ephone alarm [mac-address mac-address]
Syntax Description mac-address (Optional) Defines the MAC address of the Cisco IP phone.
mac-address (Optional) Specifies the MAC address of the Cisco IP phone.

12.2(2)XT This command was introduced on the following platforms:
Cisco 1750, Cisco 1751, Cisco 2600 series and
Cisco 3600 series multiservice routers; and
Cisco IAD2420 series Integrated Access Devices (IADs).
12.2(8)T This command was implemented on the Cisco 3725 and
Cisco 3745 routers.
12.2(8)T1 This command was implemented on the Cisco 2600-XM and
Cisco 2691 routers.
12.2(11)T This command was implemented on the Cisco 1760 routers.
Usage Guidelines The debug ephone alarm command shows all the SkinnyStation alarm messages sent by the
Cisco IP phone. Under normal circumstances, this message is sent by the Cisco IP phone just before it
registers, and the message has the severity level for the alarm set to Informational and contains the
reason for the phone reboot or re-register. This type of message is entirely benign and does not indicate
an error condition.
If the mac-address keyword is not used, the debug ephone alarm command debugs all Cisco IP phones
that are registered to the router. You can remove debugging for the Cisco IP phones that you do not want
to debug by using the mac-address keyword with the no form of this command.
You can enable or disable debugging on any number of Cisco IP phones. To see the Cisco IP phones that
have debugging enabled, enter the show ephone command and look at the debug field in the output.
When debugging is enabled for a Cisco IP phone, the debug output is displayed for the directory
numbers associated with the Cisco IP phone.

DB-600 May 2008
Debug Commands
debug ephone alarm
Examples The following example shows a SkinnyStation alarm message that is sent before the Cisco IP phone
registers:
Router# debug ephone alarm
phone keypad reset

CM-closed-TCP
CM-bad-state

debug ephone detail Sets detail debugging for the Cisco IP phone.
debug ephone error Sets error debugging for the Cisco IP phone.
debug ephone keepalive Sets keepalive debugging for the Cisco IP phone.
debug ephone loopback Sets MWI debugging for the Cisco IP phone.
debug ephone pak Provides voice packet level debugging and prints the contents of
one voice packet in every 1024 voice packets.
debug ephone raw Provides raw low-level protocol debugging display for all SCCP
messages.
debug ephone register Sets registration debugging for the Cisco IP phone.
debug ephone state Sets state debugging for the Cisco IP phone.
debug ephone statistics Sets statistics debugging for the Cisco IP phone.

May 2008 DB-601
Debug Commands
debug ephone blf
debug ephone blf

To display debugging information for Busy Lamp Field (BLF) presence features, use the debug ephone
blf command in privileged EXEC mode. To disable debugging, use the no form of this command.
debug ephone blf [mac-address mac-address]
no debug ephone blf [mac-address mac-address]
Syntax Description mac-address mac-address (Optional) Specifies the MAC address of a specific IP phone.

12.4(11)XJ This command was introduced.
Usage Guidelines Use this command for troubleshooting BLF speed-dial and BLF call-list features for phones in a
presence service.
Examples The following is sample output from the debug ephone blf command.
Router# debug ephone blf
EPHONE BLF debugging is enabled
*Sep 4 07:18:26.307: skinny_asnl_callback: subID 16 type 4

*Sep 4 07:18:26.307: ASNL_RESP_NOTIFY_INDICATION
*Sep 4 07:18:26.307: ephone-1[1]:ASNL notify indication message, feature index 4, subID
[16]
*Sep 4 07:18:26.307: ephone-1[1]:line status 6, subID [16]
*Sep 4 07:18:26.307: ephone-1[1]:StationFeatureStatV2Message sent, status 2
[23]
[16]

DB-602 May 2008
Debug Commands
debug ephone blf

[23]

blf-speed-dial Enables BLF monitoring for a speed-dial number on a phone registered to
Cisco Unified CME.
presence call-list Enables BLF monitoring for call lists and directories on phones registered to
a Cisco Unified CME router.
show presence global Displays configuration information about the presence service.
show presence Displays information about active presence subscriptions.
subscription

May 2008 DB-603
Debug Commands
debug ephone ccm-compatible

To display Cisco CallManager notification updates for calls between Cisco CallManager and
Cisco CallManager Express, use the debug ephone ccm-compatible command in privileged EXEC
debug ephone ccm-compatible [mac-address mac-address]
no debug ephone ccm-compatible [mac-address mac-address]
Syntax Description mac-address mac-address (Optional) Specifies the MAC address of a Cisco IP phone for
debugging.

12.2SX This command is supported in the Cisco IOS Release 12.2SX train. Support in a
specific 12.2SX release of this train depends on your feature set, platform, and
platform hardware.
Usage Guidelines This command displays call flow notification information for all calls between Cisco CallManager and
Cisco CallManager Express, but it is most useful for filtering out specific information for transfer and
forward cases. For basic call information, use the debug ephone state command.
If you do not specify the mac-address keyword, the debug ephone ccm-compatible command debugs
all Cisco IP phones that are registered to the router. You can remove debugging for the Cisco IP phones
that you do not want to debug by using the no form of this command with the mac-address keyword.
Debugging can be enabled or disabled on any number of Cisco IP phones. Cisco IP phones that have
debugging enabled are listed in the debug field of the show ephone command output. When debugging
is enabled for a Cisco IP phone, debug output is displayed for all phone extensions (virtual voice ports)
associated with that phone.
Examples The following sample output displays call flow notifications between Cisco CallManager and
Cisco CallManager Express:
Router# debug ephone ccm-compatible
*May 1 04:30:02.650:ephone-2[2]:DtAlertingTone/DtHoldTone - mediaActive reset during

CONNECT
*May 1 04:30:02.654:ephone-2[2]:DtHoldTone - force media STOP state
*May 1 04:30:02.654://93/xxxxxxxxxxxx/CCAPI/ccCallNotify:(callID=0x5D,nData->
bitmask=0x00000007)
*May 1 04:30:02.654://93/xxxxxxxxxxxx/VTSP:(50/0/3):-1:0:5/vtsp_process_event:
vtsp:[50/0/3 (93), S_CONNECT, E_CC_SERVICE_MSG]
*May 1 04:30:02.654://93/xxxxxxxxxxxx/VTSP:(50/0/3):-1:0:5/act_service_msg_dow
n:.

DB-604 May 2008
Debug Commands
*May 1 04:30:02.658:dn_callerid_update DN 3 number= 12009 name= CCM7960 in state

CONNECTED
*May 1 04:30:02.658:dn_callerid_update (incoming) DN 3 info updated to
*May 1 04:30:02.658:calling= 12009 called= 13003 origCalled=
*May 1 04:30:02.658:callingName= CCM7960, calledName= , redirectedTo =
*May 1 04:30:02.658:ephone-2[2][SEP003094C2999A]:refreshDisplayLine for line 1
DN 3 chan 1
*May 1 04:30:03.318:ephone-2[2]:DisplayCallInfo incoming call
*May 1 04:30:03.318:ephone-2[2]:Call Info DN 3 line 1 ref 24 called 13003 calling 12009
origcalled 13003 calltype 1
*May 1 04:30:03.318:ephone-2[2]:Original Called Name UUT4PH3
*May 1 04:30:03.318:ephone-2[2]:CCM7960 calling
*May 1 04:30:03.318:ephone-2[2]:UUT4PH3

debug ephone state Displays call state information.
router.
show ephone Displays information about registered Cisco IP phones.

May 2008 DB-605
Debug Commands
debug ephone detail
debug ephone detail

To set detail debugging for the Cisco IP phone, use the debug ephone detail command in privileged
debug ephone detail [mac-address mac-address]
no debug ephone detail [mac-address mac-address]

12.1(5)YD This command was introduced on the following platforms:
Cisco 2600 series and Cisco 3600 series multiservice routers, and
12.2(2)XT This command was implemented on the Cisco 1750 and
Cisco 1751 multiservice routers.
implemented on the Cisco 3725 and Cisco 3745 routers.
12.2(8)T1 This command was implemented on the Cisco 2600-XM and Cisco 2691
routers.
Usage Guidelines The debug ephone detail command includes the error and state levels.
If the mac-address keyword is not used, the debug ephone detail command debugs all Cisco IP phones

DB-606 May 2008
Debug Commands
debug ephone detail
Examples The following is sample output of detail debugging of the Cisco IP phone with MAC address
0030.94c3.8724. The sample is an excerpt of some of the activities that takes place during call setup,
connected state, active call, and the call being disconnected.
Router# debug ephone detail mac-address 0030.94c3.8724
Ephone detail debugging is enabled
1d04h: ephone-1[1]:OFFHOOK
.
.
1d04h: Skinny Call State change for DN 1 SIEZE
.
.
1d04h: ephone-1[1]:SetCallState line 1 DN 1 TsOffHook
.
.
1d04h: ephone-1[1]:SetLineLamp 1 to ON
.
.
1d04h: ephone-1[1]:KeypadButtonMessage 5
.
.
.
.
.
.
.
.
1d04h: ephone-1[1]:Store ReDial digit: 5002
.
SkinnyTryCall to 5002 instance 1
.
.
1d04h: ephone-1[1]:Store ReDial digit: 5002
1d04h: ephone-1[1]:
SkinnyTryCall to 5002 instance 1
.
.
1d04h: Skinny Call State change for DN 1 ALERTING
.
.
1d04h: ephone-1[1]:SetCallState line 1 DN 1 TsRingOut
.
.
1d04h: SetCallInfo calling dn 1 dn 1
calling [5001] called [5002]
.
.
1d04h: ephone-1[1]: Jane calling
1d04h: ephone-1[1]: Jill
.
.
1d04h: SkinnyUpdateDnState by EFXS_RING_GENERATE
for DN 2 to state RINGING
.
.
1d04h: SkinnyGetCallState for DN 2 CONNECTED
.

May 2008 DB-607
Debug Commands
debug ephone detail
.
1d04h: ephone-1[1]:UpdateCallState DN 1 state 4 calleddn 2
.
.
1d04h: Skinny Call State change for DN 1 CONNECTED
.
.
1d04h: ephone-1[1]:OpenReceive DN 1 codec 4:G711Ulaw64k duration 10 ms bytes 80
.
.
1d04h: ephone-1[1]:OpenReceiveChannelAck 1.2.172.21 port=20180
1d04h: ephone-1[1]:Outgoing calling DN 1 Far-ephone-2 called DN 2
1d04h: SkinnyGetCallState for DN 1 CONNECTED
.
.
1d04h: ephone-1[1]:SetCallState line 3 DN 2 TsOnHook
.
.
1d04h: ephone-1[1]:SetLineLamp 3 to OFF
.
.
.
.
1d04h: ephone-1[1]:Clean Up Speakerphone state
1d04h: ephone-1[1]:SpeakerPhoneOnHook
1d04h: ephone-1[1]:Clean up activeline 1
1d04h: ephone-1[1]:StopTone sent to ephone
1d04h: ephone-1[1]:Clean Up phone offhook state
1d04h: SkinnyGetCallState for DN 1 IDLE
1d04h: called DN -1, calling DN -1 phone -1
1d04h: ephone-1[1]:SetLineLamp 1 to OFF
1d04h: UnBinding ephone-1 from DN 1
1d04h: UnBinding called DN 2 from DN 1
1d04h: ephone-1[1]:ONHOOK
1d04h: ephone-1[1]:ONHOOK NO activeline
.
Related Commands. Command Description

debug ephone alarm Sets SkinnyStation alarm messages debugging for the
Cisco IP phone.
messages.

DB-608 May 2008
Debug Commands
debug ephone extension-assigner

To display status messages produced by the extension assigner application, use the debug ephone
extension-assigner command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
no debug ephone extension-assigner
Command Default Debug ephone extension-assigner is disabled.
Command History Cisco IOS Release Cisco Product Modification

12.4(4)XC4 Cisco Unified CME 4.0(3) This command was introduced.
12.4(11)XJ Cisco Unified CME 4.1 This command was introduced.
12.4(15)T Cisco Unified CME 4.1 This command was integrated into Cisco IOS
Release 12.4(15)T.
12.2SX This command is supported in the Cisco IOS
Release 12.2SX train. Support in a specific
12.2SX release of this train depends on your
Usage Guidelines This command displays status messages produced by the extension assigner application, including
messages related to the functions performed by the following Tcl commands:
phone queryVerifies whether the ephone tag has been assigned a MAC address.
phone assignBinds the MAC address from the callers phone to a preexisting ephone template.
phone unassignRemoves the MAC address from the ephone tag.
Before using this command, you must load the Tcl script for the extension assigner application.
Examples The following is sample output of extension assigner debugging as the extension assigner application
queries phones for their status and issues commands to assign or unassign extension numbers.
*Jun 9 19:08:10.627: ephone_query: inCallID=47, tag=4, ephone_tag=4
*Jun 9 19:08:10.627: extAssigner_IsEphoneMacPreset: ephone_tag = 4,
ipKeyswitch.max_ephones = 96
*Jun 9 19:08:10.627: extAssigner_IsEphoneMacPreset: ephone_ptr->mac_addr_str =
000B46BDE075, MAC_EXT_RESERVED_VALUE = 02EAEAEA0000
*Jun 9 19:08:10.627: SkinnyGetActivePhoneIndexFromCallid: callID = 47

May 2008 DB-609
Debug Commands
*Jun 9 19:08:10.627: SkinnyGetActivePhoneIndexFromCallid: vdbPtr->physical_interface_type

(26); CV_VOICE_EFXS (26)
*Jun 9 19:08:10.627: SkinnyGetActivePhoneIndexFromCallid: vdbPtr->type (6);
CC_IF_TELEPHONY (6)
*Jun 9 19:08:10.627: SkinnyGetActivePhoneIndexFromCallid: htsp->sig_type (26);
CV_VOICE_EFXS (26)
*Jun 9 19:08:10.627: SkinnyGetActivePhoneIndexFromCallid: dn = 4, chan = 1
*Jun 9 19:08:10.627: ephone_query: EXTASSIGNER_RC_SLOT_ASSIGNED_TO_CALLING_PHONE
*Jun 9 19:08:22.763: ephone_unassign: inCallID=47, tag=4, ephone_tag=4
*Jun 9 19:08:22.763: extAssigner_IsEphoneMacPreset: ephone_tag = 4,
ipKeyswitch.max_ephones = 96
*Jun 9 19:08:22.763: extAssigner_IsEphoneMacPreset: ephone_ptr->mac_addr_str =

000B46BDE075, MAC_EXT_RESERVED_VALUE = 02EAEAEA000
*Jun 9 19:08:22.763: is_ephone_auto_assigned: button-1 dn_tag=4
*Jun 9 19:08:22.763: is_ephone_auto_assigned: NO
*Jun 9 19:08:22.763: SkinnyGetActivePhoneIndexFromCallid: callID = 47
*Jun 9 19:08:22.763: SkinnyGetActivePhoneIndexFromCallid: vdbPtr->physical_interface_type
(26); CV_VOICE_EFXS (26)
*Jun 9 19:08:22.767: SkinnyGetActivePhoneIndexFromCallid: vdbPtr->type (6);
CC_IF_TELEPHONY (6)
*Jun 9 19:08:22.767: SkinnyGetActivePhoneIndexFromCallid: htsp->sig_type (26);
CV_VOICE_EFXS (26)
*Jun 9 19:08:22.767: SkinnyGetActivePhoneIndexFromCallid: dn = 4, chan = 1
*Jun 9 19:08:29.795: ephone-4[8]:fStationOnHookMessage: Extension Assigner request
restart, cmd=2, new mac=02EAEAEA0004, ephone_tag=4
*Jun 9 19:08:30.063: %IPPHONE-6-UNREGISTER_NORMAL: ephone-4:SEP000B46BDE075 IP:5.5.0.1
Socket:8 DeviceType:Phone has unregistered normally.
*Jun 9 19:08:30.063: ephone-4[8][SEP000B46BDE075]:extAssigner_assign: new
mac=02EAEAEA0004, ephone-tag=4
*Jun 9 19:08:30.063: extAssigner_simple_assign: mac=02EAEAEA0004, tag=4
*Jun 9 19:08:30.063: ephone_updateCNF: update cnf_file ephone_tag=4
*Jun 9 19:08:30.063: extAssigner_assign: restart again (mac=02EAEAEA0004) ephone_tag=4
*Jun 9 19:08:30.131: %IPPHONE-6-REG_ALARM: 23: Name=SEP000B46BDE075 Load=8.0(2.0)
Last=Reset-Restart
*Jun 9 19:08:30.135: %IPPHONE-6-REGISTER_NEW: ephone-7:SEP000B46BDE075 IP:5.5.0.1
Socket:10 DeviceType:Phone has registered.
*Jun 9 19:08:30.503: %IPPHONE-6-UNREGISTER_NORMAL: ephone-7:SEP000B46BDE075 IP:5.5.0.1
Socket:10 DeviceType:Phone has unregistered normally.
*Jun 9 19:08:43.127: %IPPHONE-6-REG_ALARM: 22: Name=SEP000B46BDE075 Load=8.0(2.0)
Last=Reset-Reset
*Jun 9 19:08:43.131: %IPPHONE-6-REGISTER: ephone-7:SEP000B46BDE075 IP:5.5.0.1 Socket:13
DeviceType:Phone has registered.

debug ephone state Sets state debugging for Cisco IP phones.
debug voip application Displays status messages produced by voice over IP application scripts.
script

DB-610 May 2008
Debug Commands
debug ephone error
debug ephone error

To set error debugging for the Cisco IP phone, use the debug ephone error command in privileged
debug ephone error [mac-address mac-address]
no debug ephone error [mac-address mac-address]

routers.
Usage Guidelines The debug ephone error command cancels debugging at the detail and state level.
If the mac-address keyword is not used, the debug ephone error command debugs all Cisco IP phones

May 2008 DB-611
Debug Commands
debug ephone error
Examples The following is sample output of error debugging for the Cisco IP phone with MAC address
0030.94c3.8724:
Router# debug ephone error mac-address 0030.94c3.8724
EPHONE error debugging is enabled
socket [2] send ERROR 11

Skinny Socket [2] retry failure

Cisco IP phone.
messages.

DB-612 May 2008
Debug Commands
debug ephone keepalive

To set keepalive debugging for the Cisco IP phone, use the debug ephone keepalive command in
debug ephone keepalive [mac-address mac-address]
no debug ephone keepalive [mac-address mac-address]

12.2(8)T This command was implemented on the Cisco 3725 and Cisco 3745
routers.
routers.
Usage Guidelines The debug ephone keepalive command sets keepalive debugging.
If the mac-address keyword is not used, the debug ephone keepalive command debugs all
Cisco IP phones that are registered to the router. You can remove debugging for the Cisco IP phones that
you do not want to debug by using the mac-address keyword with the no form of this command.

May 2008 DB-613
Debug Commands
Examples The following is sample output of the keepalive status for the Cisco IP phone with MAC address
0030.94C3.E1A8:
Router# debug ephone keepalive mac-address 0030.94c3.E1A8
EPHONE keepalive debugging is enabled for phone 0030.94C3.E1A8
1d05h: ephone-1 Set interface FastEthernet0/0 ETHERNET

1d05h: ephone-1[1]:Keepalive socket[1] SEP003094C3E1A8
1d05h: Skinny Checking for stale sockets
1d05h: Skinny active socket list (3/96): 1 2 4

Cisco IP phone.
messages.

DB-614 May 2008
Debug Commands
debug ephone loopback

To set debugging for loopback calls, use the debug ephone loopback command in privileged EXEC
mode. To disable debugging, use the no form of this command.
debug ephone loopback [mac-address mac-address]
no debug ephone loopback [mac-address mac-address]
Syntax Description mac-address mac-address (Optional) Specifies the MAC address of a Cisco IP phone
for debugging.

12.2(2)XT This command was introduced for Cisco IOS Telephony Services
(now known as Cisco CallManager Express) Version 2.0 on the Cisco 1750,
Cisco 1751, Cisco 2600 series, Cisco 3600 series, and Cisco IAD2420
series.
implemented on the Cisco 3725 and Cisco 3745.
12.2(8)T1 This command was implemented on the Cisco 2600-XM and Cisco 2691.
Usage Guidelines The debug ephone loopback command sets debugging for incoming and outgoing calls on all
loopback-dn pairs or on the single loopback-dn pair that is associated with the IP phone that has the
MAC address specified in this command.
If you enable the debug ephone loopback command and the debug ephone pak command at the same
time, the output displays packet debug output for the voice packets that are passing through the
loopback-dn pair.
numbers associated with that Cisco IP phone.
Examples The following example contains two excerpts of output for a call that is routed through a loopback. The
first excerpt is output from the show running-config command and displays the loopback configuration
used for this example. The second excerpt is output from the debug ephone loopback command.
Router# show running-config

May 2008 DB-615
Debug Commands
.
.
.
ephone-dn 14
number 1514
!
!
ephone-dn 42
number 17181..
loopback-dn 43 forward 4
no huntstop
!
!
ephone-dn 43
number 19115..
loopback-dn 42 forward 4
!
.
.
.
A loopback call is started. An incoming call to 1911514 (ephone-dn 43) uses the loopback pair of
ephone-dns to become an outgoing call to extension 1514. The number in the outgoing call has only four
digits because the loopback-dn command specifies forwarding of four digits. The outgoing call uses
ephone-dn 42, which is also specified in the loopback-dn command under ephone-dn 43. When the
extension at 1514 rings, the following debug output is displayed:
Router# debug ephone loopback
Mar 7 00:57:25.376:Pass processed call info to special DN 43 chan 1

Mar 7 00:57:25.376:SkinnySetCallInfoLoopback DN 43 state IDLE to DN 42 state IDLE
Mar 7 00:57:25.376:Called Number = 1911514 Called Name =
Mar 7 00:57:25.376:Calling Number = 8101 Calling Name =
orig Called Number =
Copy Caller-ID info from Loopback DN 43 to DN 42
Mar 7 00:57:25.376:DN 43 Forward 1514
Mar 7 00:57:25.376:PredictTarget match 1514 DN 14 is idle
Mar 7 00:57:25.380:SkinnyUpdateLoopbackState DN 43 state RINGING calledDn -1
Mar 7 00:57:25.380:Loopback DN 42 state IDLE
Mar 7 00:57:25.380:Loopback DN 43 calledDN -1 callingDn -1 G711Ulaw64k
Mar 7 00:57:25.380:SkinnyUpdateLoopbackState DN 43 to DN 42 signal OFFHOOK
Mar 7 00:57:25.380:SetDnCodec Loopback DN 43 codec 4:G711Ulaw64k vad 0 size 160
Mar 7 00:57:25.380:SkinnyDnToneLoopback DN 42 state SIEZE to DN 43 state RINGING
Mar 7 00:57:25.380:TONE ON DtInsideDialTone
Mar 7 00:57:25.380:SkinnyDnToneLoopback called number = 1911514
Mar 7 00:57:25.380:DN 43 Forward 1514
Mar 7 00:57:25.380:DN 42 from 43 Dial 1514
Mar 7 00:57:25.384:SkinnyDnToneLoopback DN 42 state ALERTING to DN 43 state RINGING
Mar 7 00:57:25.384:TONE OFF
Mar 7 00:57:25.384:TONE OFF
Mar 7 00:57:25.384:SkinnyUpdateLoopbackState DN 42 state ALERTING calledDn -1
Mar 7 00:57:25.384:Loopback DN 43 state RINGING
Mar 7 00:57:25.384:Loopback Alerting DN 42 calledDN -1 callingDn -1 G711Ulaw64k
Mar 7 00:57:25.388:ephone-5[7]:DisplayCallInfo incoming call
Mar 7 00:57:25.388:TONE ON DtAlertingTone
Mar 7 00:57:25.388:SkinnyDnToneLoopback DN 42 to DN 43 deferred alerting by
DtAlertingTone
Mar 7 00:57:25.388:EFXS_STATE_ONHOOK_RINGING already done for DN 43 chan 1
Mar 7 00:57:25.388:Set prog_ind 0 for DN 42 chan 1
.
.

DB-616 May 2008
Debug Commands
.
When extension 1514 answers the call, the following debug output is displayed:
.
.
.
Mar 7 00:57:32.158:TONE OFF
Mar 7 00:57:32.158:dn_support_g729 true DN 42 chan 1 (loopback)
Mar 7 00:57:32.158:SkinnyUpdateLoopbackState DN 42 state CALL_START calledDn 14
Mar 7 00:57:32.158:SkinnyUpdateLoopbackState DN 42 to DN 43 deferred alerting by
CALL_START already sent
Mar 7 00:57:32.158:SetDnCodec reassert defer_start for DN 14 chan 1
Mar 7 00:57:32.158:Delay media until loopback DN 43 is ready
Mar 7 00:57:32.158:SkinnyUpdateLoopbackCodec check for DN 14 chan 1 from DN 42 loopback
DN 43
Mar 7 00:57:32.158:SkinnyUpdateLoopbackCodec DN chain is 14 1, other=42, lb=43, far=-1 1,
final=43 1
Mar 7 00:57:32.158:SkinnyUpdateLoopbackCodec DN 14 chan 1 DN 43 chan 1 codec 4 match
Mar 7 00:57:32.162:SkinnyUpdateLoopbackState DN 42 state CONNECTED calledDn 14
Mar 7 00:57:32.162:SkinnyUpdateLoopbackState DN 42 to DN 43 signal ANSWER
Mar 7 00:57:32.162:Loopback DN 42 calledDN 14 callingDn -1 G711Ulaw64k
Mar 7 00:57:32.162:Loopback DN 43 calledDN -1 callingDn -1 incoming G711Ulaw64k
Mar 7 00:57:32.162:ephone-5[7][SEP000DBDBEF37D]:refreshDisplayLine for line 1 DN 14 chan
1
Mar 7 00:57:32.162:dn_support_g729 true DN 43 chan 1 (loopback)
Mar 7 00:57:32.162:SkinnyUpdateLoopbackState DN 43 state CALL_START calledDn -1
Mar 7 00:57:32.162:Loopback DN 42 state CONNECTED
Mar 7 00:57:32.162:SkinnyUpdateLoopbackState DN 43 has defer_dn 14 chan 1 set
Mar 7 00:57:32.162:SkinnyUpdateLoopbackState DN 43 has defer_dn 14 chan 1:
-invoke SkinnyOpenReceive
Mar 7 00:57:32.162:SkinnyUpdateLoopbackCodec check for DN 14 chan 1 from DN 42 loopback
DN 43
Mar 7 00:57:32.162:SkinnyUpdateLoopbackCodec DN chain is 14 1, other=42, lb=43, far=-1 1,
final=43 1
Mar 7 00:57:32.162:SkinnyUpdateLoopbackCodec DN 14 chan 1 DN 43 chan 1 codec 4 match
Mar 7 00:57:32.162:SkinnyUpdateLoopbackState DN 43 state CALL_START calledDn -1
Mar 7 00:57:32.454:SkinnyGetDnAddrInfo DN 43 LOOPBACK
update media address to 10.0.0.6 25390 from DN 14
Mar 7 00:57:33.166:ephone-5[7]:DisplayCallInfo incoming call
.
.
.
When the called extension, 1514, goes back on-hook, the following debug output is displayed:
.
.
.
Mar 7 00:57:39.224:Loopback DN 42 disc reason 16 normal state CONNECTED
Mar 7 00:57:39.224:SkinnyUpdateLoopbackState DN 42 state CALL_END calledDn -1
Mar 7 00:57:39.224:SkinnyUpdateLoopbackState DN 42 to DN 43 signal ONHOOK
Mar 7 00:57:39.236:SkinnyDnToneLoopback DN 42 state IDLE to DN 43 state IDLE
Mar 7 00:57:39.236:TONE OFF
Mar 7 00:57:39.236:SkinnyDnToneLoopback DN 43 state IDLE to DN 42 state IDLE
Mar 7 00:57:39.236:TONE OFF

May 2008 DB-617
Debug Commands
Table 82 debug ephone loopback Field Descriptions
Field Description
Called Number Original called number as presented to the incoming side of the loopback-dn.
Forward Outgoing number that is expected to be dialed by the outgoing side of the
loopback-dn pair.
PredictTarget Match Extension (ephone-dn) that is anticipated by the loopback-dn to be the
far-end termination for the call.
signal OFFHOOK Indicates that the outgoing side of the loopback-dn pair is going off-hook
prior to placing the outbound call leg.
Dial Outbound side of the loopback-dn that is actually dialing the outbound call
leg.
deferred alerting Indicates that the alerting, or ringing, tone is returning to the original
inbound call leg in response to the far-end ephone-dn state.
DN chain Chain of ephone-dns that has been detected, starting from the far-end that
terminates the call. Each entry in the chain indicates an ephone-dn tag and
channel number. Entries appear in the following order, from left to right:
Ephone-dn tag and channel of the far-end call terminator (in this
example, ephone-dn 14 is extension 1514).
otherEphone-dn tag of the outgoing side of the loopback.
lbEphone-dn tag of the incoming side of the loopback.
farEphone-dn tag and channel of the far-end call originator, or -1 for
a nonlocal number.
finalEphone-dn tag for the originator of the call on the incoming side
of the loopback. If the originator is not a local ephone-dn, this is set
to -1. This number represents the final ephone-dn tag in the chain,
looking toward the originator.
codec match Indicates that there is no codec conflict between the two calls on either side
of the loopback-dn.
GetDnAddrInfo IP address of the IP phone at the final destination extension (ephone-dn),
after resolving the chain of ephone-dns involved.
disc_reason Disconnect cause code, in decimal. These are normal CC_CAUSE code
values that are also used in call control API debugging. Common cause
codes include the following:
16Normal disconnect.
17User busy.
19No answer.
28Invalid number.

DB-618 May 2008
Debug Commands

debug ephone pak Provides voice packet level debugging.
loopback-dn Configures loopback-dn virtual loopback voice ports used to
establish demarcation points for VoIP voice calls and
supplementary services.
show ephone Displays information about registered Cisco IP phones.
show ephone-dn loopback Displays information for ephone-dns that have been set up for
loopback calls.

May 2008 DB-619
Debug Commands
debug ephone message

To enable message tracing between ephones, use the debug ephone message command in privileged
debug ephone message [detail]
no debug ephone message
Syntax Description detail (Optional) Displays signaling connection control protocol (SCCP) messages
sent and received between ephones in the Cisco Unified CallManager
Express (Cisco Unified CME) system.

Usage Guidelines The debug ephone message command enables message tracing between ephones.
The debug ephone command debugs all ephones associated with a Cisco Unified CME router.
You can enable or disable debugging on any number of ephones. To see the ephones that have debugging
enabled, enter the show ephone command and look at the debug field in the output. When debugging is
enabled for a ephone, the debug output is displayed for the directory numbers associated with the
ephone.
Examples The following is sample output for the debug ephone message command for ephones:
Router# debug ephone message
EPHONE skinny message debugging is enabled

*Jul 17 12:12:54.883: Received message from phone 7, SkinnyMessageID = StationKe
epAliveMessageID
*Jul 17 12:12:54.883: Sending message to phone 7, SkinnyMessageID = StationKe
epAliveAckMessageID
The following command disables ephone message debugging:

Router# no debug ephone message
EPHONE skinny message debugging is disabled

DB-620 May 2008
Debug Commands

debug ephone alarm Sets SkinnyStation alarm messages debugging for the ephone.
debug ephone detail Sets detail debugging for the ephone.
debug ephone error Sets error debugging for the ephone.
debug ephone mwi Sets MWI debugging for the ephone.
debug ephone pak Provides voice packet level debugging and displays the contents
of one voice packet in every 1024 voice packets.
messages.
debug ephone register Sets registration debugging for the ephone.
debug ephone state Sets state debugging for the ephone.
debug ephone statistics Sets statistics debugging for the ephone.
debug ephone video Sets video debugging for the ephone.
show ephone Displays information about ephones.

May 2008 DB-621
Debug Commands
debug ephone moh
debug ephone moh

To set debugging for music on hold (MOH), use the debug ephone moh command in privileged EXEC
mode. To disable debugging, use the no form of this command.
debug ephone moh [mac-address mac-address]
no debug ephone moh [mac-address mac-address]
for debugging.

12.2(2)XT This command was introduced for Cisco IOS Telephony Services
(now known as Cisco CallManager Express) Version 2.0 and Cisco
Survivable Remote Site Telephony (SRST) Version 2.0 on the
Cisco 1750, Cisco 1751, Cisco 2600 series, Cisco 3600 series, and
Cisco IAD2420 series.
implemented on the Cisco 3725 and Cisco 3745.
Cisco 2691.
Usage Guidelines Always use the no moh command before modifying or replacing the MOH file in Flash memory.
When a configuration using the multicast moh command is used and the debug ephone moh command
is enabled, if you delete or modify the MOH file in the router's Flash memory, the debug output can be
excessive and can flood the console. The multicast MOH configuration should be removed before using
the no moh command when the debug ephone moh command is enabled.
Examples The following sample output shows MOH activity prior to the first MOH session. Note that if you enable
multicast MOH, that counts as the first session.
Router# debug ephone moh
Mar 7 00:52:33.817:MOH AU file

Mar 7 00:52:33.817:skinny_open_moh_play set type to 3
Mar 7 00:52:33.825: 2E73 6E64 0000 0018 0007 3CCA 0000 0001
Mar 7 00:52:33.825: 0000 1F40 0000 0001 FFFF FFFF FFFF FFFF
Mar 7 00:52:33.825: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF

DB-622 May 2008
Debug Commands
debug ephone moh
Mar 7 00:52:33.825:
Mar 7 00:52:33.825:AU file processing Found .snd
Mar 7 00:52:33.825:AU file data start at 24 end at 474338
Mar 7 00:52:33.825:AU file codec Media_Payload_G711Ulaw64k
Mar 7 00:52:33.825:MOH read file header type AU start 24 end 474338
Mar 7 00:52:33.825:MOH pre-read block 0 at write-offset 0 from 24
Mar 7 00:52:33.833:MOH pre-read block 1 at write-offset 8000 from 8024
Mar 7 00:52:33.845:Starting read server with play-offset 0 write-offset 16000
Table 83 debug ephone moh Field Descriptions
Field Description
type 0invalid
1raw file
2wave format file (.wav)
3AU format (.au)
4live feed
AU file processing Found .snd A .snd header was located in the AU file.
AU file data start at, end at Data start and end file offset within the MOH file, as
indicated by the file header.
read file header type File format found (AU, WAVE, or RAW).
pre-read block, write-offset Location in the internal MOH buffer to which data is being
written, and location from which that data was read in the
file.
play-offset, write-offset Indicates the relative positioning of MOH file read-ahead
buffering. Data is normally written from a Flash file into the
internal circular buffer, ahead of the location from which
data is being played or output.

moh Generates an audio stream from a file for MOH in a Cisco CME system.
(telephony-service)
multicast moh Uses the MOH audio stream as a multicast source in a Cisco CME system.

May 2008 DB-623
Debug Commands
debug ephone mwi
debug ephone mwi

To set message waiting indication (MWI) debugging for the Cisco IOS Telephony Service router, use the
debug ephone mwi command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug ephone mwi
no debug ephone mwi

12.2(2)XT This command was introduced on the following platforms:
Cisco 1750, Cisco 1751, Cisco 2600 series and
Cisco 3600 series multiservice routers; and
12.2(8)T This command was implemented on the Cisco 3725 and
Cisco 3745 routers.
Cisco 2691 routers.
Usage Guidelines The debug ephone mwi command sets message waiting indication debugging for the Cisco IOS
Telephony Service router. Because the MWI protocol activity is not specific to any individual
Cisco IP phone, setting the MAC address keyword qualifier for this command is not useful.
Note Unlike the other related debug ephone commands, the mac-address keyword does not help debug a
particular Cisco IP phone.
Examples The following is sample output of the message waiting indication status for the Cisco IOS Telephony
Service router:
Router# debug ephone mwi

DB-624 May 2008
Debug Commands
debug ephone mwi

Cisco IP phone.
messages.
show debugging Displays information about the types of debugging that are enabled
for your router.

May 2008 DB-625
Debug Commands
debug ephone pak
debug ephone pak

To provide voice packet level debugging and to print the contents of one voice packet in every 1024 voice
packets, use the debug ephone pak command in privileged EXEC mode. To disable debugging output,
debug ephone pak [mac-address mac-address]
no debug ephone pak [mac-address mac-address]

Cisco 2600 series and Cisco 3600 series multiservice routers,
and Cisco IAD2420 series Integrated Access Devices (IADs).
and implemented on the Cisco 3725 and Cisco 3745 routers.
Cisco 2691 routers.
Usage Guidelines The debug ephone pak command provides voice packet level debugging and prints the contents of one
voice packet in every 1024 voice packets.
If the mac-address keyword is not used, the debug ephone pak command debugs all Cisco IP phones

DB-626 May 2008
Debug Commands
debug ephone pak
Examples The following is sample output of packet debugging for the Cisco IP phone with MAC address
0030.94c3.8724:
Router# debug ephone pak mac-address 0030.94c3.8724
EPHONE packet debugging is enabled for phone 0030.94c3.8724
01:29:14: ***ph_xmit_ephone DN 3 tx_pkts 5770 dest=10.2.1.1 orig len=32

pakcopy=0 discards 27 ip_enctype 0 0 last discard: unsupported payload type
01:29:14: to_skinny_duration 130210 offset -30 last -40 seq 0 adj 0
01:29:14: IP: 45B8 003C 0866 0000 3F11 3F90 2800 0001 0A02 0101
01:29:14: TTL 63 TOS B8 prec 5
01:29:14: UDP: 07D0 6266 0028 0000
01:29:14: sport 2000 dport 25190 length 40 checksum 0
01:29:14: RTP: 8012 16AF 9170 6409 0E9F 0001
01:29:14: is_rtp:1 is_frf11:0 vlen:0 delta_t:160 vofr1:0 vofr2:0
scodec:11 rtp_bits:8012 rtp_codec:18 last_bad_payload 19
01:29:14: vencap FAILED
01:29:14: PROCESS SWITCH
01:29:34: ***SkinnyPktIp DN 3 10.2.1.1 to 40.0.0.1 pkts 4880 FAST sw
01:29:34: from_skinny_duration 150910
01:29:34: nw 3BBC2A8 addr 3BBC2A4 mac 3BBC2A4 dg 3BBC2C4 dgs 2A
01:29:34: MAC: 1841 0800
01:29:34: IP: 45B8 0046 682E 0000 3E11 E0BD 0A02 0101 2800 0001
01:29:34: TTL 62 TOS B8 prec 5
01:29:34: UDP: 6266 07D0 0032 0000
01:29:34: RTP: 8012 55FF 0057 8870 3AF4 C394
01:29:34: RTP: rtp_bits 8012 seq 55FF ts 578870 ssrc 3AF4C394
01:29:34: PAYLOAD:
01:29:34: 1409 37C9 54DE 449C 3B42 0446 3AAB 182E
01:29:34: 56BC 5184 58E5 56D3 13BE 44A7 B8C4
01:29:34:
01:29:37: ***ph_xmit_ephone DN 3 tx_pkts 6790 dest=10.2.1.1 orig len=32
pakcopy=0 discards 31 ip_enctype 0 0 last discard: unsupported payload type
01:29:37: to_skinny_duration 153870 offset -150 last -40 seq 0 adj 0
01:29:37: IP: 45B8 003C 0875 0000 3F11 3F81 2800 0001 0A02 0101
01:29:37: TTL 63 TOS B8 prec 5
01:29:37: UDP: 07D0 6266 0028 0000
01:29:37: RTP: 8012 1AAF 9173 4769 0E9F 0001
01:29:37: is_rtp:1 is_frf11:0 vlen:0 delta_t:160 vofr1:0 vofr2:0

Cisco IP phone.
messages.

May 2008 DB-627
Debug Commands
debug ephone pak
Command Description

DB-628 May 2008
Debug Commands
debug ephone qov
debug ephone qov

To display quality of voice (QOV) statistics for calls when preset limits are exceeded, use the debug
ephone qov command in privileged EXEC mode. To disable debugging, use the no form of this
command.
debug ephone qov [mac-address mac-address]
no debug ephone qov [mac-address mac-address]
for debugging.

12.2(15)ZJ2 This command was introduced for Cisco CallManager Express 3.0 and
Cisco Survivable Remote Site Telephony (SRST) Version 3.0.
Usage Guidelines Once enabled, the debug ephone qov command produces output only when the QOV statistics reported
by phones exceed preset limits. Phones are polled every few seconds for QOV statistics on VoIP calls
only, not on local PSTN calls. An output report is produced when limits are surpassed for either or both
of the following:
Lost packetsA report is triggered when two adjacent QOV samples show an increase of four or
more lost packets between samples. The report is triggered by an increase of lost packets in a short
period of time, not by the total number of lost packets.
Jitter and latencyA report is triggered when either jitter or latency exceeds 100 milliseconds.
To receive a QOV report at the end of each call regardless of whether the QOV limits have been
exceeded, enable the debug ephone alarm command in addition to the debug ephone qov command.
The debug ephone statistics command displays the raw statistics that are polled from phones and used
to generate QOV reports.

May 2008 DB-629
Debug Commands
debug ephone qov
Examples The following sample output describes QOV statistics for a call on ephone 5:
Router# debug ephone qov
Mar 7 00:54:57.329:ephone-5[7]:QOV DN 14 chan 1 (1514) ref 4 called=1514 calling=8101

Mar 7 00:54:57.329:ephone-5[7][SEP000DBDBEF37D]:Lost 91 Jitter 0 Latency 0
Mar 7 00:54:57.329:ephone-5[7][SEP000DBDBEF37D]:previous Lost 0 Jitter 0 Latency 0
Mar 7 00:54:57.329:ephone-5[7][SEP000DBDBEF37D]:Router sent 1153 pkts, current phone got
1141
received by all (shared) phones 0
Mar 7 00:54:57.329:ephone-5[7]:worst jitter 0 worst latency 0
Mar 7 00:54:57.329:ephone-5[7]:Current phone sent 1233 packets
Mar 7 00:54:57.329:ephone-5[7]:Signal Level to phone 3408 (-15 dB) peak 3516 (-15 dB)
Table 84 debug ephone qov Field Descriptions
Field Description
Lost Number of lost packets reported by the IP phone.
Jitter, Latency The most recent jitter and latency parameters reported by the
IP phone.
previous Lost, Jitter, Latency Values from the previous QOV statistics report that were
used as the comparison points against which the current
statistics triggered generation of the current report.
Router sent pkts Number of packets sent by the router to the IP phone. This
number is the total for the entire call, even if the call is moved
from one phone to another during a call, which can happen
with shared lines.
current phone got Number of packets received by the phone currently
terminating the call. This number is the total for the entire
call, even if the call is moved from one phone to another
during a call, which can happen with shared lines.
worst jitter, worst latency Highest value reported by the phone during the call.
Current phone sent packets Number of packets that the current phone claims it sent
during the call.
Signal Level to phone Signal level seen in G.711 voice packet data prior to the
sending of the most recent voice packet to the phone. The
first number is the raw sample value, converted from G.711
to 16-bit linear format and left-justified. The number in
parentheses is the value in decibels (dB), assuming that
32,767 is about +3 dB.
Note This value is meaningful only if the call uses a G.711
codec.

debug ephone alarm Displays alarm messages for IP phones.
debug ephone statistics Displays call statistics for IP phones.

DB-630 May 2008
Debug Commands
debug ephone raw
debug ephone raw

To provide raw low-level protocol debugging display for all Skinny Client Control Protocol (SCCP)
messages, use the debug ephone raw command in privileged EXEC mode. To disable debugging output,
debug ephone raw [mac-address mac-address]
no debug ephone raw [mac-address mac-address]

12.2(8)T This command was implemented on the Cisco 3725 and Cisco 3745 routers.
routers.
Usage Guidelines The debug ephone raw command provides raw low-level protocol debug display for all SCCP messages.
The debug display provides byte level display of Skinny TCP socket messages.
If the mac-address keyword is not used, the debug ephone raw command debugs all Cisco IP phones

May 2008 DB-631
Debug Commands
debug ephone raw
Examples The following is sample output of raw protocol debugging for the Cisco IP phone with MAC address
0030.94c3.E1A8:
Router# debug ephone raw mac-address 0030.94c3.E1A8
EPHONE raw protocol debugging is enabled for phone 0030.94C3.E1A8
1d05h: skinny socket received 4 bytes on socket [1]

0 0 0 0
1d05h:
1d05h: SkinnyMessageID = 0
1d05h: skinny send 4 bytes
4 0 0 0 0 0 0 0 0 1 0 0
1d05h: socket [1] sent 12 bytes OK (incl hdr) for ephone-(1)
1d06h: skinny socket received 4 bytes on socket [1]

0 0 0 0
1d06h:
1d06h: SkinnyMessageID = 0
1d06h: skinny send 4 bytes
4 0 0 0 0 0 0 0 0 1 0 0
1d06h: socket [1] sent 12 bytes OK (incl hdr) for ephone-(1)

Cisco IP phone.

DB-632 May 2008
Debug Commands
debug ephone register

To set registration debugging for the Cisco IP phone, use the debug ephone register command in
debug ephone register [mac-address mac-address]
no debug ephone register [mac-address mac-address]

routers.
Usage Guidelines The debug ephone register command sets registration debugging for the Cisco IP phones.
If the mac-address keyword is not used, the debug ephone register command debugs all

May 2008 DB-633
Debug Commands
Examples The following is sample output of registration debugging for the Cisco IP phone with MAC address
0030.94c3.8724:
Router# debug ephone register mac-address 0030.94c3.8724
Ephone registration debugging is enabled
1d06h: New Skinny socket accepted [1] (2 active)

1d06h: sin_family 2, sin_port 50778, in_addr 10.1.0.21
1d06h: skinny_add_socket 1 10.1.0.21 50778
1d06h: ephone-(1)[1] StationRegisterMessage (2/3/12) from 10.1.0.21
1d06h: ephone-(1)[1] Register StationIdentifier DeviceName SEP003094C3E1A8
1d06h: ephone-(1)[1] StationIdentifier Instance 1 deviceType 7
1d06h: ephone-1[-1]:stationIpAddr 10.1.0.21
1d06h: ephone-1[-1]:maxStreams 0
1d06h: ephone-(1) Allow any Skinny Server IP address 10.1.0.6
.
.
.
1d06h: ephone-1[1]:RegisterAck sent to ephone 1: keepalive period 30
.

Cisco IP phone.
messages.

DB-634 May 2008
Debug Commands
debug ephone sccp-state

To set debugging for the SCCP call state, use the debug ephone sccp-state command in privileged
debug ephone sccp-state [mac-address mac-address]
no debug ephone sccp-state [mac-address mac-address]
Syntax Description mac-address (Optional) Specifies the MAC address of a phone.

mac-address
Command Default Debugging is not enabled for SCCP state.

Usage Guidelines This command is used with Cisco Unified CallManager Express (Cisco Unified CME).
This command outputs only the debug messages that correspond to SCCP messages sent to IP phones to
indicate the SCCP phone call state, such as RingIn, OffHook, Connected, and OnHook. These debug
messages are also included in the output for the debug ephone detail command among other
information.
Examples The following example sets SCCP state debugging for one Cisco Unified CME phone with the MAC
address of 678B.AEF9.DAB5.
Router# debug ephone sccp-state mac-address 678B.AEF9.DAB5
EPHONE SCCP state message debugging is enabled

for ephones 000B.BEF9.DFB5
*Mar 8 06:38:45.863: %ISDN-6-CONNECT: Interface Serial2/0/0:22 is now connected to

4085254871 unknown
*Mar 8 06:38:50.487: ephone-2[13]:SetCallState line 4 DN 60(60) chan 1 ref 100 TsRingIn
*Mar 8 06:38:52.399: ephone-2[13]:SetCallState line 4 DN 60(-1) chan 1 ref 100 TsOffHook
*Mar 8 06:38:52.399: ephone-2[13]:SetCallState line 4 DN 60(-1) chan 1 ref 100
TsConnected
*Mar 8 06:38:58.415: %ISDN-6-CONNECT: Interface Serial2/0/0:22 is now connected to
4085254871 unknown

May 2008 DB-635
Debug Commands
*Mar 8 06:38:59.963: ephone-2[13]:SetCallState line 4 DN 60(-1) chan 1 ref 100 TsOnHook

*Mar 8 06:38:59.975: %ISDN-6-DISCONNECT: Interface Serial2/0/0:22 disconnected from
4085254871 , call lasted 7 seconds

debug ephone detail Sets detail debugging for one or all Cisco Unified IP phones.

DB-636 May 2008
Debug Commands
debug ephone state
debug ephone state

To set state debugging for the Cisco IP phone, use the debug ephone state command in privileged EXEC
debug ephone state [mac-address mac-address]
no debug ephone state [mac-address mac-address]

routers.
12.2(11)T This command was implemented on Cisco 1760 routers.
Usage Guidelines The debug ephone state command sets state debugging for the Cisco IP phones.
If the mac-address keyword is not used, the debug ephone state command debugs all Cisco IP phones

May 2008 DB-637
Debug Commands
debug ephone state
Examples The following is sample output of state debugging for the Cisco IP phone with MAC address
0030.94c3.E1A8:
Router# debug ephone state mac-address 0030.94c3.E1A8
EPHONE state debugging is enabled for phone 0030.94C3.E1A8
1d06h: ephone-1[1]:OFFHOOK
1d06h: ephone-1[1]:SIEZE on activeline 0
1d06h: ephone-1[1]:SetCallState line 1 DN 1 TsOffHook
1d06h: ephone-1[1]:Skinny-to-Skinny call DN 1 to DN 2 instance 1
1d06h: ephone-1[1]:SetCallState line 1 DN 1 TsRingOut
1d06h: ephone-1[1]:Call Info DN 1 line 1 ref 158 called 5002 calling 5001
1d06h: ephone-1[1]:SetCallState line 3 DN 2 TsRingIn
1d06h: ephone-1[1]:Call Info DN 2 line 3 ref 159 called 5002 calling 5001
1d06h: ephone-1[1]:SetCallState line 3 DN 2 TsCallRemoteMultiline
1d06h: ephone-1[1]:SetCallState line 1 DN 1 TsConnected
1d06h: ephone-1[1]:OpenReceive DN 1 codec 4:G711Ulaw64k duration 10 ms bytes 80
1d06h: ephone-1[1]:OpenReceiveChannelAck 1.2.172.21 port=24010
1d06h: ephone-1[1]:StartMedia 1.2.172.22 port=24612
1d06h: DN 1 codec 4:G711Ulaw64k duration 10 ms bytes 80
1d06h: ephone-1[1]:CloseReceive
1d06h: ephone-1[1]:StopMedia
1d06h: ephone-1[1]:ONHOOK
1d06h: SkinnyReportDnState DN 1 ONHOOK

Cisco IP phone.
messages.
debug ephone Sets statistics debugging for the Cisco IP phone.

DB-638 May 2008
Debug Commands
debug ephone statistics

To set call statistics debugging for the Cisco IP phone, use the debug ephone statistics command in
debug ephone statistics [mac-address mac-address]
no debug ephone statistics [mac-address mac-address]

routers.
Usage Guidelines The debug ephone statistics command provides a debug monitor display of the periodic messages from
the Cisco IP phone to the router. These include transmit-and-receive packet counts and an estimate of
drop packets. The call statistics can also be displayed for live calls using the show ephone command.
If the mac-address keyword is not used, the debug ephone statistics command debugs all

May 2008 DB-639
Debug Commands
Examples The following is sample output of statistics debugging for the Cisco IP phone with MAC address
0030.94C3.E1A8:
Router# debug ephone statistics mac-address 0030.94C3.E1A8
EPHONE statistics debugging is enabled for phone 0030.94C3.E1A8
1d06h: Clear Call Stats for DN 1 call ref 162

1d06h: ephone-1[1]:GetCallStats line 1 ref 162 DN 1: 5001
1d06h: ephone-1[1]:Call Stats for line 1 DN 1 5001 ref 162
1d06h: ephone-1[1]:TX Pkts 0 bytes 0 RX Pkts 0 bytes 0
1d06h: ephone-1[1]:Pkts lost 4504384 jitter 0 latency 0
1d06h: ephone-1[1]:Src 0.0.0.0 0 Dst 0.0.0.0 0 bytes 80 vad 0 G711Ulaw64k
1d06h: ephone-1[1]:GetCallStats line 1 ref 162 DN 1: 5001
1d06h: STATS: DN 1 Packets Sent 0
1d06h: STATS: DN 2 Packets Sent 0
1d06h: ephone-1[1]:Call Stats found DN -1 from Call Ref 162
1d06h: ephone-1[1]:Call Stats for line 0 DN -1 5001 ref 162
1d06h: ephone-1[1]:TX Pkts 275 bytes 25300 RX Pkts 275 bytes 25300
1d06h: ephone-1[1]:Pkts lost 0 jitter 0 latency 0

Cisco IP phone.
messages.

DB-640 May 2008
Debug Commands
debug ephone video
debug ephone video

To set video debugging for ephones, use the debug ephone video command in privileged EXEC mode.
debug ephone video
no debug ephone video
Command Default Debugging is disabled for ephone video.

Usage Guidelines The debug ephone video command sets ephone video traces, which provide information about different
video states for the call, including video capabilities selection, start, and stop.
The debug ephone command debugs all ephones that are registered to the Cisco Unified CallManager
Express (Cisco Unified CME) system.
You can enable or disable debugging on any number of ephones. To see the ephones that have debugging
enabled, enter the show ephone command and look at the debug field in the output. When debugging is
enabled for a ephone, the debug output is displayed for the directory numbers associated with the
ephone.
Examples The following is sample output for the debug ephone video command for ephones:
Router# debug ephone video
*Mar 13 16:10:02.703: SkinnyVideoCodecMatch_Caps2Caps: match capability: tx_idxcap = 4,

tx_idxpref = 3,
*Mar 13 16:10:02.703: rx_idxcap = 0, rx_idxpref = 0, videoBitRate = 7040
tx_mpi = 1
*Mar 13 16:10:04.711: ephone-19[1][SEPFFFA00000019]:checkToOpenMultiMedia: dn=19, chan=1
*Mar 13 16:10:04.711: ephone-19[1]:skinnyDP[19].s2s = 0
*Mar 13 16:10:04.711: ephone-19[1]:s2s is not set - hence not video capable
*Mar 13 16:10:04.719: ephone-19[1][SEPFFFA00000019]:SkinnyStartMultiMediaTransmission:
chan 1 dn 19

May 2008 DB-641
Debug Commands
debug ephone video
*Mar 13 16:10:04.723: ephone-19[1]:Accept OLC and open multimedia channel

*Mar 13 16:10:04.723: ephone-19[1][SEPFFFA00000019]:SkinnyOpenMultiMediaReceiveChannel: dn
19 chan 1
*Mar 13 16:10:04.967: ephone-19[1][SEPFFFA00000019]:fStationOpenReceiveChannelAckMessage:
MEDIA_DN 19 MEDIA_CHAN 1
*Mar 13 16:10:04.967: ephone-19[1]:fStationOpenMultiMediaReceiveChannelAckMessage:
*Mar 13 16:10:04.967: ephone-19[1]:Other_dn == -1
sk3745-2#
*Mar 13 16:10:14.787: ephone-19[1]:SkinnyStopMedia: Stop Multimedia
*Mar 13 16:10:14.787: ephone-19[1][SEPFFFA00000019]:SkinnyCloseMultiMediaReceiveChannel:
passThruPartyID = 0, callReference = 23
*Mar 13 16:10:14.787: ephone-19[1]:SkinnyStopMultiMediaTransmission: line 1 chan 1 dn 19

debug ephone alarm Sets SkinnyStation alarm messages debugging for the ephone.
debug ephone detail Sets detail debugging for the ephone.
debug ephone error Sets error debugging for the ephone.
debug ephone message Sets message debugging for the ephone.
debug ephone mwi Sets MWI debugging for the ephone.
debug ephone pak Provides voice packet level debugging and displays the contents
of one voice packet in every 1024 voice packets.
messages.
debug ephone register Sets registration debugging for the ephone.
debug ephone state Sets state debugging for the ephone.
debug ephone statistics Sets statistics debugging for the ephone.
show ephone Displays information about registered ephones.

DB-642 May 2008
Debug Commands
debug ephone vm-integration

To display pattern manipulation information used for integration with voice-mail applications, use the
debug ephone vm-integration command in privileged EXEC mode. To disable debugging output, use
debug ephone vm-integration [mac-address mac-address]
no debug ephone vm-integration [mac-address mac-address]
Syntax Description mac-address mac-address (Optional) Specifies the MAC address of a Cisco IP phone for
debugging.

platform hardware.
Usage Guidelines This command displays the voice-mail integration patterns that were created using the pattern
commands in vm-integration configuration mode. The patterns are used to forward calls to a voice-mail
number that is set with the voicemail command.
If you do not specify the mac-address keyword, the debug ephone vm-integration command debugs
all Cisco IP phones that are registered to the router. To remove debugging for Cisco IP phones, enter the
no form of this command with the mac-address keyword.
Examples The following sample output shows information for the vm-integration tokens that have been defined:
Router# debug ephone vm-integration
*Jul 23 15:38:03.294:ephone-3[3]:StimulusMessage 15 (1) From ephone 2

*Jul 23 15:38:03.294:ephone-3[3]:Voicemail access number pattern check
*Jul 23 15:38:03.294:SkinnyGetCallState for DN 3 chan 1 IDLE
*Jul 23 15:38:03.294:called DN -1 chan 1, calling DN -1 chan 1 phone -1 s2s:0
*Jul 23 15:38:03.294:dn number for dn 3 is 19003
*Jul 23 15:38:03.294:Updated number for token 1 is 19003
*Jul 23 15:38:03.294:CDN number for dn 3 is
*Jul 23 15:38:03.294:Updated number for token 2 is
*Jul 23 15:38:03.294:Updated number for token 0 is
*Jul 23 15:38:03.294:Update is 219003*
*Jul 23 15:38:03.294:New Voicemail number is 19101219003*

May 2008 DB-643
Debug Commands
Table 85 debug ephone vm-integration Field Descriptions
Field Description
token 0 First token that was defined in the pattern.
token 1 Second token that was defined in the pattern.
token 2 Third token that was defined in the pattern.

pattern direct Configures the DTMF digit pattern forwarding necessary to
activate the voice-mail system when a user presses the
Messages button on a phone.
pattern ext-to-ext busy Configures the DTMF digit pattern forwarding necessary to
activate the voice-mail system once an internal extension
reaches a busy extension and the call is forwarded to voice
mail.
pattern ext-to-ext no-answer Configures the DTMF digit pattern forwarding necessary to
activate the voice-mail system once an internal extension
fails to connect to an extension and the call is forwarded to
voice mail.
pattern trunk-to-ext busy Configures the DTMF digit pattern forwarding necessary to
activate the voice-mail system once an external trunk call
reaches a busy extension and the call is forwarded to voice
mail.
pattern trunk-to-ext no-answer Configures the DTMF digit pattern forwarding necessary to
activate the voice-mail system when an external trunk call
reaches an unanswered extension and the call is forwarded
to voice mail.
vm-integration Enters voice-mail integration configuration mode and
enables voice-mail integration with DTMF and analog
voice-mail systems.
voicemail Defines the telephone number that is speed-dialed when the
Messages button on a Cisco IP phone is pressed.

DB-644 May 2008
Debug Commands
debug errors
debug errors
To display errors, use the debug errors command in privileged EXEC mode. To disable debugging
debug errors
no debug errors
Examples The following is sample output from the debug errors command:
Router# debug errors
(2/0): Encapsulation error, link=7, host=836CA86D.

(4/0): VCD#7 failed to echo OAM. 4 tries
The first line of output indicates that a packet was routed to the 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.

May 2008 DB-645
Debug Commands
debug eswilp
debug eswilp
To enable debugging of Ethernet switch network module features, use the debug eswilp command in
debug eswilp {dot1x | filtermgr | fltdrv | igmp | port-driver | power-supply | span | switch-pm}
no debug eswilp {dot1x | filtermgr | fltdrv | igmp | port-driver | power-supply | span |

switch-pm}
Syntax Description dot1x Displays Ethernet Switch with Inline Power (ESWILP) 802.1x debugging
messages.
filtermgr Displays ESWILP filter manager debugging messages.
fltdrv Displays ESWILP filter driver debugging messages.
igmp Displays ESWILP Internet Group Management Protocol (IGMP) debugging
messages.
port-driver Displays ESWILP port driver debugging messages.
power-supply Displays ESWILP power supply information debugging messages.
span Displays ESWILP Switched Port Analyzer (SPAN) debugging messages.
switch-pm Displays ESWILP switch port manager debugging messages.

series, Cisco 3600 series, and Cisco 3700 series routers. The dot1x,
filtermgr, and fltdrv keywords were added.
following platforms: Cisco 2600 series, Cisco 3600 series, and Cisco 3700
series routers.
Usage Guidelines The undebug eswilp command is the same as the no debug eswilp command.

DB-646 May 2008
Debug Commands
debug eswilp
Examples The following example shows debugging messages for the IGMP snooping services on the Ethernet
switch network module being displayed:
Router# debug eswilp igmp


May 2008 DB-647
Debug Commands
debug ethernet cfm all

To enable all Ethernet connectivity fault management (CFM) debug messages, use the debug ethernet
cfm all command in privileged EXEC mode. To disable all Ethernet CFM debug messages, use the no
debug ethernet cfm all [domain domain-name | level level-id] [vlan vlan-id]
no debug ethernet cfm all [domain domain-name | level level-id] [vlan vlan-id]
Syntax Description domain (Optional) Indicates that a domain is specified.

domain-name (Optional) String with a maximum of 154 characters that identifies the
specified domain.
level (Optional) Indicates that a maintenance level is specified.
level-id (Optional) Integer in the range of 0 to 7 that specifies the maintenance level.
vlan (Optional) Indicates that a VLAN is specified.
vlan-id (Optional) Integer in the range of 1 to 4095 that identifies the affected
VLAN.
Command Default All debug commands are enabled.

Usage Guidelines This command allows you to conditionally enable debug messages for a specific:
Maintenance domain
Maintenance level
Maintenance domain plus VLAN
Maintenance level plus VLAN
Additionally, you can filter debug messages by the following:
Maintenance domain
Maintenance level
VLAN

DB-648 May 2008
Debug Commands
Combination of maintenance domain and VLAN

Combination of maintenance level and VLAN
The output from the debug ethernet cfm all command is a log of activity that shows all Ethernet
CFM-related debug messages. Use this command to troubleshoot Ethernet CFM in your network.
Examples The following example shows output of the debug ethernet cfm all command for the domain named
testdomain on VLAN 1010:
Router# debug ethernet cfm all domain testdomain vlan 1010
00:01:51: CFM-PKT: Received a cc packet from interface Ethernet1/0

00:01:51: CFM-PKT: cfm packet dump - 104 bytes, interface Ethernet1/0, vlan 3
00:01:51: CFM-PKT: ethernet CFM message dump,
dest: 0100.0ccc.ccc1
src: aabb.cc00.0602
Version: 0
Maintenance Level: 1
MsgType: CC(0)
Transaction Id: 3042953420
00:01:51: 01 00 0C CC CC C1 AA BB CC 00 06 02 00 5A AA AA
00:01:51: 03 00 00 0C 01 26 00 01 00 08 B5 5F C8 CC 01 00
00:01:51: 29 00 63 73 69 5F 6F 70 65 72 61 74 6F 72 5F 6C
00:01:51: 31 5F 31 5F 33 3A 44 4F 4D 41 49 4E 5F 4F 50 45
00:01:51: 52 41 54 4F 52 5F 4C 31 5F 31 02 00 02 00 3A 03
00:01:51: 00 02 00 4B 04 00 02 00 02 05 00 0B 6D 69 6E 6E
00:01:51: 65 61 70 6F 6C 69 73 00
00:01:51:
00:01:51: CFM-PKT: TLV Service ID 'csi_operator_l1_1_3:DOMAIN_OPERATOR_L1_1'
00:01:51: CFM-PKT: TLV MPID 58
00:01:51: CFM-PKT: TLV LIFETIME 75
00:01:51: CFM-PKT: TLV PORT_STATE 0x2 (DOWN)
00:01:51: CFM-PKT: Received a CC packet with MPID 58, level 1, vlan 3 from interface
Ethernet1/0
00:01:51: CFM-EV: Adding new MEP entry for mac aabb.cc00.0602 level 1 svlan 3
00:01:51: CFM-EV: initialize mac elem for slvan table
00:01:51: CFM-EV: Initilize elem in mac table
00:01:51: CFM-EV: Added mac aabb.cc00.0602 at level 1 vlan 3 successfully
00:01:51: CFM-EVT:Inserted rmep in CC db. level 1 vlan 3 mac aabb.cc00.0602 intf
Ethernet1/0.2
00:01:51: CFM-PKT: Sending out mep 8 CC message, level 5, vlan 3

debug ethernet cfm Enables low-level diagnostic debugging of Ethernet CFM general or
diagnostic packet-related events.
debug ethernet cfm errors Enables debugging of Ethernet CFM errors.
debug ethernet cfm events Enables debugging of Ethernet CFM events.
debug ethernet cfm packets Enables debugging of Ethernet CFM mesage packets.

May 2008 DB-649
Debug Commands
debug ethernet cfm diagnostic

To enable low-level diagnostic debugging of Ethernet connectivity fault management (CFM) general
events or packet-related events, use the debug ethernet cfm diagnostic command in privileged EXEC
mode. To disable the debugging, use the no form of this command.
debug ethernet cfm diagnostic [events | packets]
no debug ethernet cfm diagnostic [events | packets]
Syntax Description events (Optional) Triggers only events related to debugs.

packets (Optional) Triggers only packets related to debugs.
Command Default Diagnostic debugging for both events and packets is enabled.

Usage Guidelines The output from this command is a log of activity. Use this command to troubleshoot Ethernet CFM in
your network.
Examples The following example shows output of the debug ethernet cfm diagnostic command with no options
specified:
Router# debug ethernet cfm diagnostic
00:05:39: CFM-PKT: Received a cc packet from interface Ethernet1/0

00:05:39: CFM-PKT: cfm packet dump - 101 bytes, interface Ethernet1/0, vlan 2
00:05:39: CFM-PKT: ethernet CFM message dump,
dest: 0100.0ccc.ccc6
src: aabb.cc00.0300
Version: 0
Maintenance Level: 6
MsgType: CC(0)
Transaction Id: 2183808794
00:05:39: 01 00 0C CC CC C6 AA BB CC 00 03 00 00 57 AA AA
00:05:39: 03 00 00 0C 01 26 00 06 00 08 82 2A 47 1A 01 00
00:05:39: 29 00 63 73 69 5F 70 72 6F 76 69 64 65 72 5F 6C

DB-650 May 2008
Debug Commands
00:05:39: 36 5F 31 5F 32 3A 44 4F 4D 41 49 4E 5F 50 52 4F
00:05:39: 56 49 44 45 52 5F 4C 36 5F 31 02 un al00 02 00 15 03
00:05:39: 00 02 00 4B 04 00 02 00 01 05 00 08 63 6F 6C 75
00:05:39: 6D 62 75 73 00

debug ethernet cfm all Enables all Ethernet CFM debug messages.

May 2008 DB-651
Debug Commands
debug ethernet cfm errors

To enable debugging of Ethernet connectivity fault management (CFM) errors, use the debug ethernet
cfm errors command in privileged EXEC mode. To disable the debugging, use the no form of this
command.
no debug ethernet cfm errors

Usage Guidelines The output from this command is a log of activity. Use this command to troubleshoot Ethernet CFM in
your network.
Examples The following example shows output of the debug ethernet cfm errors command:
Router# debug ethernet cfm errors
10:46:26: CFM-ERR: MPID matched with a local MEP!, level 5, svlan 2, mpid 50
10:46:26: CFM-ERR: Received duplicate mpid 50 due to configuration error for level 5,
svlan 2
10:48:55: CFM-ERR: Lifetime timer fired for level 4, svlan 2 mac aabb.cc00.0501, mpid 43

debug ethernet cfm Enables low-level diagnostic debugging of Ethernet CFM general
diagnostic events or packet-related events.

DB-652 May 2008
Debug Commands
Command Description

May 2008 DB-653
Debug Commands
debug ethernet cfm events

To enable debugging of Ethernet connectivity fault management (CFM) events, use the debug ethernet
cfm events command in privileged EXEC mode. To disable debugging, use the no form of this
command.
debug ethernet cfm events [domain domain-name | level level-id] [vlan vlan-id]
no debug ethernet cfm events [domain domain-name | level level-id] [vlan vlan-id]

specified domain.
VLAN.
Command Default Event debugging is disabled for all domains and all VLANs.

Usage Guidelines This command provides capability to filter debug messages by:
Maintenance domain
Maintenance level
VLAN
The output from this command is a log of activity. Use this command to troubleshoot Ethernet CFM in
your network.

DB-654 May 2008
Debug Commands
Examples The following example shows output of the debug ethernet cfm events command for the domain named
testdomain on VLAN 1010:
Router# debug ethernet cfm events domain testdomain vlan 1010
10:48:58: CFM-EV: Adding new MEP entry for mac aabb.cc00.0100 level 5 svlan 5
10:48:58: CFM-EVT:Inserted rmep in CC db. level 5 vlan 5 mac aabb.cc00.0100 intf
Ethernet1/0
10:48:59: CFM-EVT: Found remote mep for level 5 svlan 5, mpid 60
10:49:07: CFM-EVT: Found remote mep for level 5 svlan 5, mpid 38


May 2008 DB-655
Debug Commands
debug ethernet cfm packets

To enable debugging of Ethernet connectivity fault management (CFM) message packets, use the debug
ethernet cfm packets command in privileged EXEC mode. To disable the debugging, use the no form
of this command.
debug ethernet cfm packets [domain domain-name | level level-id] [vlan vlan-id]
no debug ethernet cfm packets [domain domain-name | level level-id] [vlan vlan-id]

specified domain.
VLAN.
Command Default Debugging is enabled for all domains and VLANs.

Usage Guidelines Use the debug ethernet cfm packets command in privileged EXEC mode to enable debugging of
Ethernet CFM message packets. This command provides capability to filter debug messages by:
Maintenance domain
Maintenance level
VLAN
The output from this command is a log of activity. Use this command to troubleshoot Ethernet CFM in
your network.

DB-656 May 2008
Debug Commands
Examples The following example shows output of the debug ethernet cfm packets command for the domain
named testdomain on VLAN 1010:
Router# debug ethernet cfm packets domain testdomain vlan 1010
10:52:50: CFM-PKT: TLV Service ID 'csi_operator_l5_1_5:DOMAIN_OPERATOR_L5_1'
10:52:50: CFM-PKT: TLV MPID 38
10:52:50: CFM-PKT: TLV LIFETIME 75
10:52:50: CFM-PKT: TLV PORT_STATE 0x1 (UP)
10:52:50: CFM-PKT: Received a CC packet with MPID 38, level 5, vlan 5 from interface
Ethernet1/0


May 2008 DB-657
Debug Commands
debug ethernet lmi
debug ethernet lmi

To enable debugging of Ethernet local management interface (LMI) messages on all interfaces or on a
specified interface, use the debug ethernet lmi command in privileged EXEC mode. To disable
debug ethernet lmi {all | errors | events | packets} [interface type number]
no debug ethernet lmi {all | errors | events | packets} [interface type number]
Syntax Description all All debug messages are to be filtered.

errors All errors are to be filtered.
events All events are to be filtered.
packets All decoded messages are to be filtered.
interface (Optional) Specifies an interface to use to filter debug messages.
type (Optional) String that identifies the type of interface. Valid options
are the following:
ethernetEthernet IEEE 802.3 interface
fastethernetFast Ethernet IEEE 802.3 interface
gigabitethernetGigabit Ethernet IEEE 802.3z interface
number (Optional) Integer that identifies the interface.

12.2(33)SRB Support for this command on the Cisco 7600 router was integrated into
Cisco IOS Release 12.2(33)SRB.
Usage Guidelines When you use the all keyword, keep in mind how many interfaces support Ethernet LMI. Some messages
may be lost if many interfaces are supported.
Use of the errors keyword enables debugging of Ethernet LMI errors such as invalid messages; for
example, unexpected information element (IE) and mandatory IE missing.
Use of the events keyword enables debugging of Ethernet LMI events such as status changes, timeouts,
and messages received.

DB-658 May 2008
Debug Commands
debug ethernet lmi
Use of the packets keyword enables debugging of decoded Ethernet LMI packets.
The output from this command is a log of activity. Use this command to troubleshoot Ethernet LMI in
your network.
Examples The following example output from the debug ethernet lmi all command shows event and packet
messages:
Router# debug ethernet lmi all
Ethernet LMI errors debugging is on

Ethernet LMI packets debugging is on
Ethernet LMI events debugging is on
Ethernet LMI packets hex debugging is on
00:29:32: ELMI Et0/0 EVENT: ce_event: State 0x0, Event 0x4

00:29:32: ELMI Et0/0 EVENT: Old State=0x0, Event=0x4, New State=0x2
00:29:32: ELMI Et0/0 EVENT: Updated Stat Type: ETHER_LMI_ST_LMSG_SENT
00:29:32: ELMI Et0/0 PKT HEX: TX->:0x01750101010202B4B30305000000000400000000000

00:29:32: ELMI Et0/0 PACKET: Outgoing
Protocol Version : 0x1
Message : STATUS ENQ (0x75)
Report Type : Check
Sequence Number : Snd(0xB4), Rcv(0xB3)
Data Instance : Value(0x4)
00:29:32: ELMI Et0/0 PKT HEX: RX<-:0x017D0101010202B4B40305000000000400000000000

00:29:32: ELMI Et0/0 PACKET: Incoming
Message : STATUS (0x7D)
Report Type : Check
Sequence Number : Snd(0xB4), Rcv(0xB4)
00:29:32: ELMI Et0/0 EVENT: Update seq: current send 0xB4 rcv 0xB3
00:29:32: ELMI Et0/0 EVENT: Updated Stat Type: ETHER_LMI_ST_LMSG_RCVD
The following example output from the debug ethernet lmi all command shows detailed information
about the user-network interfaces (UNIs) and Ethernet virtual connections (EVCs) for packet messages.
Router# debug ethernet lmi all
Ethernet LMI errors debugging is on

Ethernet LMI packets debugging is on
Ethernet LMI events debugging is on
Ethernet LMI packets hex debugging is on
Jun 16 18:59:49.372: ELMI Gi0/1 PKT HEX: RX<-:0x017D0101000202D30103050000000004

Jun 16 18:59:49.372: ELMI Gi0/1 PACKET: Incoming
Report Type : Full
Sequence Number : Snd(0xD3), Rcv(0x1)
UNI : Bundle
UNI Id : 'uni_sandiego'
EVC Status : Evc Ref(0x1), New, Active
EVC Parameters : Point-to-Point
EVC Id : 'EVC_P2P_110'
Remote UNI Sum : Cfgd(1), Up(1)

May 2008 DB-659
Debug Commands
debug ethernet lmi
EVC Status : Evc Ref(0x2), New, Active

EVC Parameters : MultiPoint-to-MultiPoint
EVC Id : 'EVC_MP2MP_101'
Remote UNI Sum : Cfgd(2), Up(2)
CEVLAN EVC Map : Evc Ref(0x1), Seq(0x1)
EVC Map : Num Vlans(1), 110
CEVLAN EVC Map : Evc Ref(0x2), Seq(0x1)
EVC Map : Num Vlans(1), 101
Remote UNI Status : Evc Ref(0x1), Uni Ref(0x26), Up
UNI Id o deb al : 'cisco_newyork'
Remote UNI Status : Evc Ref(0x2), Uni Ref(0x1D), Up
UNI Id : 'uni_newyork'
Remote UNI Status : Evc Ref(0x2), Uni Ref(0x96), Up
UNI Id : 'miami-detroit'
Jun 16 18:59:49.372: ELMI Gi0/1 EVENT: ce_event: State 0x1, Event 0x0
Jun 16 18:59:49.372: ELMI Gi0/1 EVENT: Update seq: current send 0x1 rcv 0x0
Jun 16 18:59:49.372: ELMI Gi0/1 EVENT: Update uni:
Jun 16 18:59:49.372: ELMI Gi0/1 EVENT: Update evc_sts: ref_id: 0x1
Jun 16 18:59:49.372: ELMI Gi0/1 EVENT: Update evc_param: type 0x0
Jun 16 18:59:49.372: ELMI Gi0/1 EVENT: Update evc_id
Jun 16 18:59:49.372: ELMI Gi0/1 EVENT: Update remote_uni_sum cfgd 1 up 1
Jun 16 18:59:49.372: ELMI Gi0/1 EVENT: Update evc_sts: ref_id: 0x2
Jun 16 18:59:49.372: ELMI Gi0/1 EVENT: Update evc_param: type 0x1
Jun 16 18:59:49.372: ELMI Gi0/1 EVENT: Update evc_id
Jun 16 18:59:49.372: ELMI Gi0/1 EVENT: Update remote_uni_sum cfgd 2 up 2
Jun 16 18:59:49.372: ELMI Gi0/1 EVENT: Update cevlan_evc_map: ref_id: 0x1 seq#1
Jun 16 18:59:49.372: ELMI Gi0/1 EVENT: Update evc_map: num_vlans 1
Jun 16 18:59:49.372: ELMI Gi0/1 EVENT: Update cevlan_evc_map: ref_id: 0x2 seq# 1
Jun 16 18:59:49.372: ELMI Gi0/1 EVENT: Update evc_map: num_vlans 1
Jun 16 18:59:49.372: ELMI Gi0/1 EVENT: Update remote_uni_det: evc ref_id: 0x1 u6
Jun 16 18:59:49.372: ELMI Gi0/1 EVENT: Update remote_uni_det: evc ref_id: 0x2 uD
Jun 16 18:59:49.372: ELMI Gi0/1 EVENT: Update remote_uni_det: evc ref_id: 0x2 u6
Jun 16 18:59:49.372: ELMI Gi0/1 EVENT: upd_lmi_db: new uni_evc ref 0x1
Jun 16 18:59:49.372: ELMI Gi0/1 EVENT: upd_lmi_db: new uni_evc ref 0x2
Jun 16 18:59:49.372: %ETHER_LMI-6-MISMATCHED_VLAN_NOT_CONFIGURED: VLAN 101,110 1
Jun 16 18:59:49.372: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthn
Jun 16 18:59:49.376: ELMI Gi0/1 EVENT: Update di: current 0x0 rcvd 0x4
Jun 16 18:59:49.376: ELMI Gi0/1 EVENT: Old State=0x1, Event=0x0, New State=0x0
Jun 16 18:59:49.376: ELMI Gi0/1 EVENT: Updated Stat Type: ETHER_LMI_ST_LFULL_MSD
Jun 16 18:59:50.100: %SYS-5-CONFIG_I: Configured from console by console
Jun 16 18:59:59.376: ELMI Gi0/1 EVENT: ce_event: State 0x0, Event 0x4
Jun 16 18:59:59.376: ELMI Gi0/1 EVENT: Old State=0x0, Event=0x4, New State=0x2
Jun 16 18:59:59.376: ELMI Gi0/1 EVENT: Updated Stat Type: ETHER_LMI_ST_LMSG_SENT
The following example shows output of the debug ethernet lmi all interface command for
interface Ethernet 0/0.
Router# debug ethernet lmi all interface ethernet 0/0
Ethernet LMI errors debugging is on for Ethernet0/0

Ethernet LMI packets debugging is on for Ethernet0/0
Ethernet LMI events debugging is on for Ethernet0/0
Ethernet LMI packets hex debugging is on for Ethernet0/0

00:45:14: ELMI Et0/0 EVENT: Updated Stat Type: ETHER_LMI_ST_LMSG_SENT
00:45:14: ELMI Et0/0 PKT HEX: TX->:0x0175010101020213120305000000000400000000000
00:45:14: ELMI Et0/0 PACKET: Outgoing
Message : STATUS ENQ (0x75)
Report Type : Check
Sequence Number : Snd(0x13), Rcv(0x12)

DB-660 May 2008
Debug Commands
debug ethernet lmi
00:45:14: ELMI Et0/0 PKT HEX: RX<-:0x017D010101020213130305000000000400000000000

00:45:14: ELMI Et0/0 PACKET: Incoming
Report Type : Check
Sequence Number : Snd(0x13), Rcv(0x13)

00:45:14: ELMI Et0/0 EVENT: Update seq: current send 0x13 rcv 0x12
00:45:14: ELMI Et0/0 EVENT: Updated Stat Type: ETHER_LMI_ST_LMSG_RCVD

May 2008 DB-661
Debug Commands
debug ethernet oam
debug ethernet oam

To enable all Ethernet operations, administration, and maintenance (OAM) debugging, use the debug
ethernet oam command in privileged EXEC mode. To disable Ethernet OAM debuging, use the no form
of this command.
debug ethernet oam {all | config | ha | link-monitor | loopback | packet {decode | rx | tx} | sm}
no debug ethernet oam {all | config | ha | link-monitor | loopback | packet {decode | rx | tx} | sm}
Syntax Description all Debugging for all Ethernet OAM flags is on.
config Debugging for Ethernet OAM configurations is on.
ha Debugging for Ethernet OAM high-availability events is on.
link-monitor Debugging for Ethernet OAM link monitoring is on.
loopback Debugging for Ethernet OAM loopback messages is on.
packet Debugging for Ethernet OAM protocol data units (PDUs) is on.
decode Decoding for ingress or egress OAMPDUs, or both, is on.
rx Debugging for Ethernet ingress OAMPDUs is on.
tx Debugging for Ethernet egress OAMPDUs is on.
sm Debugging for the Ethernet OAM state machine is on.
Command Default All Ethernet OAM debug commands are enabled.

Usage Guidelines When you use the all keyword, keep in mind the number of interfaces supporting Ethernet OAM. If many
interfaces are supported, some messages may be lost and system performance can degrade.
The output from this command is a log of activity. Use this command to troubleshoot Ethernet OAM in
your network.
Examples The following example shows output of the debug ethernet oam all command:
Router# debug ethernet oam all

DB-662 May 2008
Debug Commands
debug ethernet oam
*Aug 17 14:00:53.732: ether_oam_port Gi2/9: during state INACTIVE,

got event 3(link_up)
*Aug 17 14:00:53.732: @@@ ether_oam_port Gi2/9: INACTIVE -> FAULT
*Aug 17 14:00:53.732: ether_oam_port Gi2/9: idle during state FAULT
*Aug 17 14:00:53.732: @@@ ether_oam_port Gi2/9: FAULT -> FAULT2
*Aug 17 14:00:53.732: ether_oam_port Gi2/9: during state FAULT2, got
event 6(mode_active)
*Aug 17 14:00:53.732: @@@ ether_oam_port Gi2/9: FAULT2 -> ACTIVE_SEND_LOCAL
*Aug 17 14:00:54.212: EOAM RX PAK(Gi2/9):
*Aug 17 14:00:54.212: 03 00 08 00 01 10 01 00 00 00 0D 05 DC 00 00 0C *Aug 17
14:00:54.212: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00
*Aug 17 14:00:54.212: 00 00 00 00 00 00 00 00
*Aug 17 14:00:54.212: ether_oam_port Gi2/9: during state
SEND_LOCAL_REMOTE, got event 8(local_satisfied)
1w5d: %ETHERNET_OAM-6-ENTER_SESSION: The client on interface Gi2/11 has entered the OAM
session.
*Aug 17 14:00:55.212: EOAM RX PAK(Gi2/9):
*Aug 17 14:00:55.212: 03 00 50 00 01 10 01 00 00 00 0D 05 DC 00 00 0C
*Aug 17 14:00:55.212: 00 00 00 SYMPRD w=104857600 lt=1 ht=0
elapsed_time=1032(ms) rx_sym=1000000000 err_sym=0 *Aug 17 14:00:55.740: EOAM LM(Gi2/9):
FRM w=1 lt=1 ht=0 t_frm=0 err_frm=0
*Aug 17 14:00:55.740: EOAM LM(Gi2/9): FRMPRD w=10000000 lt=1 ht=0 t_frm=1 err_frm=0
*Aug 17 14:00:55.740: EOAM LM(Gi2/9): w=1 lt=10 ht=0 err_frm=0
*Aug 17 14:00:55.832: EOAM TX PAK(Gi2/9):
*Aug 17 14:00:55.832: 03 00 50 00 0 1 10 01 00 00 00 0D 05 DC 00 00 0C
*Aug 17 14:00:55.832: 00 00 00 01 02 10 01 00 00 00 0D 05 DC 00 00 0C *Aug 17
14:00:55.832: 00 00 00 01 *Aug 17 14:00:55.832: EOAM TX PAK(Gi2/9): 00 00 00 0D 05 DC 00
00 0C
*Aug 17 14:00:56.212: 00 00 00 01 02 10 01 00 00 00 0D 05 DC 00 00 0C
*Aug 17 14:00:56.212: 00 00 00 01 00 00 00 00 00 00 00 00 00 00
*Aug 17 14:00:56.212: EOAM RX PAK(Gi2/9): infotlv w/ same revision *Aug 17 14:00:56.820:
EOAM LM(Gi2/9): SYMPRD w=104857600 lt=1 ht=0
elapsed_time=1000(ms) rx_sym=1000000000 err_sym=0
*Aug 17 14:00:56.820: EOAM LM(Gi2/9): FRM w=1 lt=1 ht=0 t_frm=0 err_frm=0
*Aug 17 14:00:56.820: EOAM LM(Gi2/9): 05 FRMPRD w=10000000 lt=1 ht=0 t_frm=3 err_frm=0
*Aug 17 14:00:57.856: EOAM TX PAK(Gi2/9):
*Aug 17 14:00:57.856: 03 00 50 00 01 10 01 00 00 00 0D 05 DC 00 00 0C
*Aug 17 14:00:57.856: 00 00 00 01 02 10 01 00 00 00 0D 17 14:00:58.212: 05 DC 00 00 0C
*Aug 17 14:00:57.856: 00 00 00 01
*Aug 17 14:00:57.856: EOAM TX PAK(Gi2/9): sent OAMPDU w/ op=0
*Aug 17 14:00:58.212: EOAM RX PAK(Gi2/9):
*Aug 17 14:00:58.212: EOAM RX PAK(Gi2/9): infotlv w/ same revision
*Aug 17 14:00:58.820: EOAM LM(Gi2/9): SYMPRD w=104857600 lt=1 ht=0
*Aug 17 14:00:58.856: EOAM TX PAK(Gi2/9):
*Aug 17 14:00:58.856: 03 00 50 00 01 10 01 00 00 00 0D 05 DC 00 00 0C
*Aug 17 14:00:58.856: 00 00 00 01 02 10 01 00 00 00 0D 05 DC 00 00 0C
*Aug 17 14:00:58.856: 00 sent OAMPDU w/ op=0w=1 lt=10 ht=0 err_frm=0
*Aug 17 14:00:59.856: EOAM TX PAK(Gi2/9):
*Aug 17 14:00:59.856: 03 00 50 00 01 10 01 00 00
*Aug 17 14:01:00.832: EOAM LM(Gi2/9): SYMPRD w=104857600 lt=1 ht=0
*Aug 17 14:01:00.832: EOA M LM(Gi2/9): w=1 lt=10 ht=0 err_frm=0
*Aug 17 14:01:00.856: EOAM TX PAK(Gi2/9):

May 2008 DB-663
Debug Commands
debug ethernet oam
*Aug 17 14:01:00.856: 03 00 50 00 01 10 01 00 00 00 0D 05 DC 00 00 0C
*Aug 17 14:01:00.856: 00 00

DB-664 May 2008
Debug Commands
debug ethernet service

To enable debugging of Ethernet customer service instances, use the debug ethernet service command
privileged EXEC mode. To disable debugging, use the no form of this command.
debug ethernet service {all | api | error | evc [evc-id] | instance [id id | interface type number |
qos] | interface type number | microblock | oam-mgr}
debug ethernet service {all | api | error | evc | instance | interface | microblock | oam-mgr}
Syntax Description all Displays all Ethernet customer-service debug messages.

api Displays debug messages about the interaction between the Ethernet
infrastructure and its clients.
error Displays Ethernet customer service error messages occurring in the Ethernet
infrastructure subsystem.
evc Displays Ethernet virtual connection (EVC) debug messages.
evc-id (Optional) String from 1 to 100 characters that identifies an EVC for debugging.
instance Displays debug messages related to Ethernet customer service instances.
id (Optional) Displays Ethernet service-instance debug messages for a specific
Ethernet service instance ID and interface.
id (Optional) Integer in the range from 1 to 4294967295 that is the service
identifier.
interface Displays debugging for Ethernet services on all interfaces or on a specified
interface.
(Optional) When used as an option with the instance keyword, service instance
debug messages for the interface are displayed.
type number Type and number of the physical interface.
qos Displays debug messages for the Ethernet service quality of service (QoS).
microblock Displays debug messages for the Ethernet service microblocks.
oam-mgr Displays debug messages for the Ethernet operations, administration, and
maintenance (OAM) manager component of the infrastructure.
Command Default Ethernet service debugging is disabled.

12.2(25)SEG This command was introduced.
12.2(33)SRB This command was implemented on the Cisco 7600 series routers.

May 2008 DB-665
Debug Commands
Usage Guidelines The debug ethernet service command is useful for troubleshooting. The undebug ethernet service
command is the same as the no debug ethernet service command.
When you use the evc keyword without specifying an EVC ID, debugging is enabled for all EVCs on the
system.
When you use the instance keyword without specifying options, debugging for all service instances is
enabled. If a service instance ID and interface are specified, only debug messages for the associated
service instance are displayed. If only an interface is specified, debug messages for all service instances
on that interface only are displayed.
Examples The following example shows output after issuing the debug ethernet service all command:
Router# debug ethernet service all
Ethernet service error debugging is on
Ethernet service api debugging is on
Ethernet service interface debugging is on
Ethernet service instance debugging is on
Ethernet service instance qos debugging is on
Ethernet service evc debugging is on
Ethernet service OAM Manager debugging is on


DB-666 May 2008
Debug Commands
debug event manager
debug event manager

To turn on the debugging output of Embedded Event Manager (EEM) processes, use the debug event
manager command in privileged EXEC mode. To turn off debugging output, use the no form of this
command or the undebug command.
debug event manager {action cli | action cns | action mail | all | api calls | api errors | detector
all | detector application | detector cli | detector counter | detector interface | detector
ioswdsysmon | detector none | detector snmp | detector syslog | detector timer | metricdir |
policydir | server events | server scheduling | tcl cli_library | tcl commands | tcl
smtp_library}
no debug event manager {action cli | action cns | action mail | all | api calls | api errors | detector
all | detector application | detector cli | detector counter | detector interface | detector
ioswdsysmon | detector none | detector snmp | detector syslog | detector timer | metricdir |
policydir | server events | server scheduling | tcl cli_library | tcl commands | tcl
smtp_library}
Syntax Description action cli Displays debugging messages about command-line interface (CLI) event
messages.
action cns Displays debugging messages about CNS event messages.
action mail Displays debugging messages about e-mail event messages.
api calls Displays debugging messages about application programming interface
(API) calls.
api errors Displays debugging messages about API errors.
detector all Displays all event detector debugging messages.
detector application Displays debugging messages about the application-specific event detector.
detector cli Displays debugging messages about the CLI event detector.
detector counter Displays debugging messages about the counter event detector.
detector interface Displays debugging messages about the interface counter event detector.
detector ioswdsysmon Displays debugging messages about the watchdog event detector.
detector none Displays debugging messages about the none event detector.
detector snmp Displays debugging messages about the Simple Network Management
Protocol (SNMP) event detector.
detector syslog Displays debugging messages about the syslog event detector.
detector timer Displays debugging messages about the timer event detector.
metricdir Displays debugging messages about the EEM metrics event detector.
policydir Displays debugging messages about the EEM policy director.
server events Displays debugging messages about the EEM server events.
server scheduling Displays all debugging messages about the EEM server scheduling events.
tcl cli_library Displays all debugging messages about the Tool Command Language (Tcl)
command-line interface (CLI) library.

May 2008 DB-667
Debug Commands
debug event manager
tcl commands Displays all debugging messages about the Tcl commands.
tcl smtp_library Displays all debugging messages about the Tcl Simple Mail Transfer
Protocol (SMTP) library.

12.3(2)XE This command was integrated into Cisco IOS Release 12.3(2)XE.
12.3(14)T The action cli, action mail, detector all, detector cli, detector none, and
metricdir keywords were added.
12.2(18)SXF4 This command was integrated into Cisco IOS Release 12.2(18)SXF4 to
support Software Modularity images only.
12.2(18)SXF5 This command was integrated into Cisco IOS Release 12.2(18)SXF5.
Usage Guidelines Use the debug event manager command to troubleshoot EEM command operations.
Caution Use any debugging command with caution because the volume of generated output can slow or stop the
router operations. We recommend that this command be used only under the supervision of a Cisco
engineer.
Examples The following example turns on debugging messages about EEM server events and then configures an
applet to write a messageTest messageto syslog. The debug output that follows displays the various
EEM operations that occur as the applet is processed.
Router# debug event manager server events
Debug Embedded Event Manager server events debugging is on

Router(config)# event manager applet timer-test
Router(config-applet)# event timer countdown time 20
Router(config-applet)# action label1 syslog msg "Test message"
Router(config-applet)# end
Router#
03:46:55: fh_server: fh_io_msg: received msg 6 from client jobid 11

03:46:55: fh_server: fh_io_msg: handling event register with esid = 23

DB-668 May 2008
Debug Commands
debug event manager
03:46:55: fh_msg_send_to_fd: receive a reply msg, minor: 5

03:47:15: fd_pulse_hndlr: received a pulse from /dev/fm/fd_timer
03:47:15: fd_pulse_hndlr: received FH_MSG_EVENT_PUBLISH
03:47:15: fh_schedule_callback: fh_schedule_callback: cc=632C0B68 prev_epc=0; epc=63A41670
03:47:15: fh_io_msg: received FH_MSG_API_INIT; jobid=13, processid=82, client=3, job
name=EEM Callback Thread
03:47:15: %HA_EM-6-LOG: timer-test: Test message
03:47:15: fh_schedule_callback: fh_schedule_callback: cc=632C0B68 prev_epc=63A41670; epc=0
03:47:15: fh_io_msg: received FH_MSG_API_CLOSE client=3
Table 86 describes some of the significant fields shown in the display.
Table 86 debug event manager Field Descriptions
Field Description
Debug Embedded Event Manager Indicates the type of debugging output and whether the
server events debugging debugging is on or off.
fh_server Indicates a server event message.
fh_io_msg Indicates that a message has been sent to, or received from, a
client process.
fh_msg_send_to_fd Indicates that a message has been sent to the event detector.
fd_pulse_hndlr Indicates that a message has been received by the event
detector pulse handler.

May 2008 DB-669
Debug Commands
debug events
debug events
To display events, use the debug events command in privileged EXEC mode. To disable debugging
debug events
no debug events
Usage Guidelines This command displays events that occur on the interface processor and is useful for diagnosing
problems in an network. It provides an overall picture of the stability of the network. In a stable network,
the debug 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, enable the debug events command.
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.
Examples The following is sample output from the debug events command:
Router# debug events
RESET(4/0): PLIM type is 1, Rate is 100Mbps

aip_disable(4/0): state=1
config(4/0)
aip_love_note(4/0): asr=0x201
aip_enable(4/0)
aip_enable(4/0): restarting VCs: 7
aip_setup_vc(4/0): vc:1 vpi:1 vci:1

DB-670 May 2008
Debug Commands
debug events
Table 87 debug events Field Descriptions
Field Description
PLIM type Indicates the interface rate in Mbps. Possible values are:
1 = TAXI(4B5B) 100 Mbps
2 = SONET 155 Mbps
3 = E3 34 Mbps
state Indicates current state of the ATM Interface Processor (AIP). Possible values
are:
1 = An ENABLE will be issued soon.
0 = The AIP will remain shut down.
asr Defines a bitmask, which indicates actions or completions to commands.
Valid bitmask values are:
0x0800 = AIP crashed, reload may be required.
0x0400 = AIP detected a carrier state change.
0x0n00 = Command completion status. Command completion status
codes are:
n = 8 Invalid physical layer interface module (PLIM) detected
n = 4 Command failed
n = 2 Command completed successfully
n = 1 CONFIG request failed
n = 0 Invalid value
The following line indicates that the AIP was reset. The PLIM detected was 1, so the maximum rate is
set to 100 Mbps.
RESET(4/0): PLIM type is 1, Rate is 100Mbps
The following line indicates that the AIP was given a shutdown command, but the current configuration
indicates that the AIP should be up:
aip_disable(4/0): state=1
The following line indicates that a configuration command has been completed by the AIP:
The following line indicates that the AIP was given a no shutdown command to take it out of the
shutdown state:
aip_enable(4/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.
The following line of output indicates that the AIP enable function is restarting all permanent virtual
circuits (PVCs) automatically:

May 2008 DB-671
Debug Commands
debug events
aip_enable(4/0): restarting VCs: 7
The following lines of output indicate that PVC 1 was set up and a successful completion code was
returned:

DB-672 May 2008
Debug Commands
debug fax dmsp
debug fax dmsp

To troubleshoot the fax Document Media Service Provider (DMSP), use the debug fax dmsp command
debug fax dmsp [all | default | detail | error [call [informational] | software [informational]] |
event | function | inout]
no debug fax dmsp
Syntax Description all (Optional) Displays all fax DMSP debugging messages.
default (Optional) Displays fax DMSP error and inout information. This option also
detail (Optional) Displays fax DMSP background messages.
error (Optional) Displays fax DMSP error messages.
event (Optional) Displays fax DMSP events.
function (Optional) Displays fax DMSP functions.
inout (Optional) Displays fax DMSP in/out functions.

12.3(8)T This command replaces the debug dmsp doc-to-fax and debug dmsp
fax-to-doc commands.
Examples The following is sample output from the debug fax dmsp all command:
Router# debug fax dmsp all
2d07h: //70/67D6061D8012/DMSP/docmsp_call_setup_request:
ramp data dir=ONRAMP, conf dir=DEST
2d07h: //70/67D6061D8012/DMSP/docmsp_caps_ind:
cid(0x46), srcCallID(0x44)
2d07h: //70/67D6061D8012/DMSP/docmsp_bridge:
conf id(0x33), srcCallID(0x46), dstCallID(0x44),

May 2008 DB-673
Debug Commands
debug fax dmsp
ramp data dir=ONRAMP, conf dir=DEST, encode out=1

Bridge done
conf id(0x34), srcCallID(0x46), dstCallID(0x45),
ramp data dir=ONRAMP, conf dir=SRC, encode out=1
Bridge done
2d07h: //70/67D6061D8012/DMSP/docmsp_xmit:
srcCallID(0x44), dstCallID(0x46), direction=0
2d07h: //68/67D6061D8012/DMSP/docmsp_process_rcv_data:
evID=0, proto_flag=3, srcCallID(0x44), dstCallID(0x46)
2d07h: //70/67D6061D8012/DMSP_ON/docmsp_tiff_writer_data_process:
START_OF_CONNECTION
2d07h: //70/67D6061D8012/DMSP_ON/docmsp_tiff_writer_data_process:
START_OF_FAX_PAGE
2d07h: //70/67D6061D8012/DMSP_ON/docmsp_tiff_writer_get_buffer_callback:
tiff_segment=0x63A88ECC
2d07h: //70/67D6061D8012/DMSP_ON/docmsp_tiff_writer_get_buffer_callback:
tiff_segment=0x63D58944
2d07h: //70/67D6061D8012/DMSP/docmsp_process_rcv_data:
Done
Table 88 debug fax dmsp Field Descriptions
Field Description
//70/67D6061D8012/DMSP/ The format of this message is
docmsp_call_setup_request: //callid/GUID/DMSP/function name:
CallEntry ID is 70. This indicates a unique call leg.
GUID is 67D6061D8012. This identifies the call.
DMSP is the module name.
The docmsp_call_setup_request field shows that the
DMSP is requesting a call setup.
ramp data dir Indicates if the data direction is on-ramp or off-ramp.
conf dir Indicates if the data is from the source or destination.
docmsp_bridge: Indicates that the DMSP is setting up a bridge to the
destination.
docmsp_xmit: Indicates that the DMSP is transmitting.
docmsp_process_rcv_data: Indicates that the DMSP is starting the process to receive
data.
docmsp_tiff_writer_data_process: Indicates the process that is being started.
docmsp_tiff_writer_get_buffer_ Indicates the segment for the DMSP TIFF writer
callback: get_buffer_callback parameter.

DB-674 May 2008
Debug Commands
debug fax fmsp
debug fax fmsp

To troubleshoot the Fax Media Service Provider (FMSP), use the debug fax fmsp command in
debug fax fmsp [all | default | detail | error [call [informational] | software [informational]] |
event | function | inout | receive | send]
no debug fax fmsp
Syntax Description all (Optional) Displays all fax FMSP debugging messages.
default (Optional) Displays fax FMSP error and inout information. This option also
detail (Optional) Displays fax FMSP background messages.
error (Optional) Displays fax FMSP error messages.
event (Optional) Displays fax FMSP events.
function (Optional) Displays fax FMSP functions.
inout (Optional) Displays fax FMSP in/out functions.
receive (Optional) Receives T.30 or T.38 debugs.
send (Optional) Sends T.30 or T.38 debugs.

12.3(8)T This command replaces the debug fmsp receive and debug fmsp send
commands.
Examples The following is sample output from the debug fax fmsp all command:
Router# debug fax fmsp all
2d08h: //76/90A52CB88014/FMSP/faxmsp_call_setup_request:
session(0x63A8A474), vdbPtr(0x62CA45A8),data dir=ONRAMP, conf dir=DEST
2d08h: //76/90A52CB88014/FMSP/faxmsp_bridge:

May 2008 DB-675
Debug Commands
debug fax fmsp
confID(0x38), srcCID(0x4C), dstCID(0x4B)

ramp data dir=ONRAMP, conf dir=DEST
Explicit caps ind. done; Wait for registry cap ind
2d08h: //76/90A52CB88014/FMSP/faxmsp_caps_ind:
per_bridge_info(0x63D52FD8), cap_ind_state(0x6)
2d08h: //76/90A52CB88014/FMSP/faxmsp_caps_ind[1617]:
2d08h: //76/90A52CB88014/FMSP/faxmsp_caps_ack:
direction=0, srcCID(0x4B), dstCID(0x0)
2d08h: //76/90A52CB88014/FMSP/faxmsp_codec_download_done:
per_bridge_info(0x63D52FD8), application_data(0x63C54698), state(0x2), direction=2
2d08h: //76/90A52CB88014/FMSP/faxMsp_get_tx_buffer:
event(0x402897C0), bufferBegin(0x63A86B5C), dataBegin(0x402897EC)
event(0x40289B50), bufferBegin(0x63C55794), dataBegin(0x40289B7C)
event(0x40851E58), bufferBegin(0x63D4EAE4), dataBegin(0x40851E84)
2d08h: //76/90A52CB88014/FMSP/faxmsp_xmit:
srcCallID(0x4B), dstCallID(0x4C)
2d08h: //76/90A52CB88014/FMSP/faxmsp_xmit[1813]:
2d08h: //76/90A52CB88014/FMSP/faxmsp_process_rcv_data:
state(0x1), evID=918065, evProtoFlag=2
2d08h: //76/90A52CB88014/FMSP/t38_rx_buffer:
t38 rx msg dump (size=6):
00 00 01 00 00 00
2d08h: //76/90A52CB88014/FMSP/faxmsp_process_rcv_data[1994]:
2d08h: //76/90A52CB88014/FMSP/fax2_phaseB_receive:
CSI_PACKET(8881111)
DIS_PACKET(speed=5, resolution=1, encoding=1)
event(0x40289690), bufferBegin(0x63A7E798), dataBegin(0x402896BC)
event(0x4028858C), bufferBegin(0x63B89AC0), dataBegin(0x402885B8)
2d08h: //76/90A52CB88014/FMSP/t38_tx_command:
t38 tx msg dump (size=47):
00 04 2A C0 04 80 00 16 FF C0 02 8C 8C 8C 8C 1C 1C 1C 04 04
04 04 04 04 04 04 04 04 04 04 04 28 00 09 FF C8 01 00 77 1F
01 01 19 80 40 00 00
2d08h: //76/90A52CB88014/FMSP/fax2_phaseB_receive:
fax2_response_receive, PROCESSING
Table 89 debug fax fmsp all Field Descriptions
Field Description
//76/90A52CB88014/FMSP/ The format of this message is
faxmsp_call_setup_request: //callid/GUID/FMSP/function name
GUID is 90A52CB88014. This identifies the call.
FMSP is the module name.
The faxmsp_call_setup_request field shows that the
FMSP is requesting a call setup.
ramp data dir Indicates if the data direction is on-ramp or off-ramp.
conf dir Indicates if the data is from the source or destination.

DB-676 May 2008
Debug Commands
debug fax fmsp
Table 89 debug fax fmsp all Field Descriptions (continued)
Field Description
faxmsp_bridge: Indicates that the FMSP is setting up a bridge to the
destination.
faxmsp_xmit: Indicates that the FMSP is transmitting data.
faxmsp_process_rcv_data: Indicates that the FMSP is beginning the process to receive
data.
t38_rx_buffer: Shows the contents of the T.38 transmit buffer.
t38_tx_command: Shows the T.38 transmit command.

May 2008 DB-677
Debug Commands
debug fax foip
debug fax foip

To troubleshoot fax mail, use the debug fax foip command in privileged EXEC mode. To disable
debug fax foip [all | default | detail | error [call [informational] | software [informational]] |
no debug fax foip
Syntax Description all (Optional) Displays all fax mail debugging messages.
default (Optional) Displays fax mail error and inout information. This option also
detail (Optional) Displays fax mail background messages.
error (Optional) Displays fax mail error messages.
event (Optional) Displays fax mail events.
function (Optional) Displays fax mail functions.
inout (Optional) Displays fax mail in/out functions.

12.3(8)T This command replaces the debug foip off-ramp and debug foip on-ramp
commands.
Examples The following is sample output from the debug fax foip all command:
Router# debug fax foip all
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_call_handoff:
Authentication:
Id: 0
Method: IVR or unknown
Status: SUCCESS
Enabled: FALSE

DB-678 May 2008
Debug Commands
debug fax foip
Template:
List: fax
MailtoAddress: Calling Oct3A=0x0
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_conference_vtsp_fmsp:
Begin Conferencing VTSP and FMSP
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_conference_vtsp_fmsp[887]:
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_change_state:
Old State=0, New State=1
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_call_handoff[2953]:
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_validate_context[930]:
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_conference_created:
VTSP and FMSP Are Conferenced;
Waiting for FMSP Call Detail Event
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_change_state:
Old State=1, New State=2
2d07h: %ISDN-6-CONNECT: Interface Serial2:30 is now connected to unknown
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_validate_context[930]:
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_msp_event:
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_setup_mspi:
Prepare MSPI Call Setup Request
Envelope From=FAX=7771111@cisco.com
Envelope To=jdoe@server.cisco.com
RFC822 To Comment=dileung
Faxmail Subject=hagar-c5300-bw12 subject line here
Disposition Notification=
Originator TSI=RFC822 From Comment=
Auth/Account ID: `0'
Call Setup Request To MSPI
2d07h: //37/67E715B7800A/FOIP_ON/lapp_on_setup_mspi[748]:
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_conference_fmsp_dmsp:
Starting Conference with FMSP and DMSP
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_conference_fmsp_dmsp:
Tiff File Created; Time=2003:06:05 22:46:48
Table 90 debug fax foip all Field Descriptions
Field Description
//35/67E715B7800A/FOIP_ON/ The format of this message is
lapp_on_call_handoff: //callid/GUID/FOIP_ON/function name:
GUID is 67E715B7800A. This identifies the call.
FOIP_ON identifies the fax mail onramp call leg.
FOIP_OFF would identify an offramp call leg.
The lapp_on_call_handoff field shows that the fax mail
is initiating a call handoff.
lapp_on_conference_vtsp_fmsp: Indicates that fax mail is starting a conference for VTSP and
FMSP.

May 2008 DB-679
Debug Commands
debug fax foip
Table 90 debug fax foip all Field Descriptions (continued)
Field Description
lapp_on_change_state Indicates that the fax mail is changing state.
lapp_on_conference_created Indicates that the conference is working properly between
the VTSP and FMSP.
lapp_on_setup_mspi: Indicates that fax mail is displaying an MPSI event.
lapp_on_conference_fmsp_dmsp: Indicates that fax mail is starting a conference for FMSP and
DMSP.

DB-680 May 2008
Debug Commands
debug fax mmoip aaa
debug fax mmoip aaa

To display output relating to authentication, authorization, and accounting (AAA) services using
multimedia mail over IP (MMoIP) for the Store and Forward Fax feature, use the debug fax mmoip aaa
debug fax mmoip aaa [all | default | error [call [informational] | software [informational]] |
inout]
no debug fax mmoip aaa
Syntax Description all (Optional) Displays all MMoIP AAA debugging messages.
default (Optional) Displays MMoIP AAA error and inout information. This option
also runs if no keywords are added.
error (Optional) Displays MMoIP AAA error messages.
inout (Optional) Displays MMoIP AAA in/out functions.

12.3(8)T This command replaces the debug mmoip aaa command.
Examples The following example shows output from the debug fax mmoip aaa all command for an onramp fax
connection:
Router# debug fax mmoip aaa all
16:22:04: //3/D9242FD08002/MMOIP_AAA_ON/mmoip_aaa_accounting_onramp:
UID=3
fax_account_id_origin=NONE_ID
fax_msg_id=00012003151904623@Router.cisco.com, Length=39
fax_pages=0

May 2008 DB-681
Debug Commands
debug fax mmoip aaa
fax_connect_speed=disable bps
fax_mdn_flag=FALSE
fax_auth_status=USER NOT AUTHENTICATED
email_server_address=172.19.140.112
email_server_ack_flag=TRUE
gateway_id=Router.cisco.com
call_type=Fax Receive
abort_cause=10
Table 91 debug fax mmoip aaa all Field Descriptions
Field Description
//3/D9242FD08002/ The format of this message is
MMOIP_AAA_ON/ //callid/GUID/module name/function name:
mmoip_aaa_accounting_onramp
GUID is D9242FD08002. This identifies the call.
MMOIP_AAA_ON identifies the fax mail
onrampMMOIP AAA call leg. MMOIP_AAA_OFF
would identify the offramp call leg.
The mmoip_aaa_accounting_onramp field shows that
the accounting for an onramp fax is active.
fax_msg_id=00012003151904623 Displays the fax message ID.
@Router.cisco.com
gateway_id=Router.cisco.com Displays the name of the router.
call_type=Fax Receive Indicates that the fax is being received.

DB-682 May 2008
Debug Commands
debug fax mspi
debug fax mspi

To troubleshoot the fax Mail Service Provider Interface (MSPI), use the debug fax mspi command in
debug fax mspi [all | default | detail | error [call [informational] | software [informational]] |
no debug fax mspi
Syntax Description all (Optional) Displays all fax MSPI debugging messages.
default (Optional) Displays fax MSPI error and inout information. This option also
detail (Optional) Displays fax MSPI background messages.
error (Optional) Displays fax MSPI error messages.
event (Optional) Displays fax MSPI events.
function (Optional) Displays fax MSPI functions.
inout (Optional) Displays fax MSPI in/out functions.

12.3(8)T This command replaces the debug mspi receive and debug mspi send
commands.
Examples The following is sample output from the debug fax mspi all command:
Router# debug fax mspi all
Router#
2d07h: //41/ACF704FA800B/MSPI_ON/mspi_call_setup_request:
Outgoing Peer Tag=22
Envelope From=FAX=5550121@cisco.com
Envelope To=jdoe@server.cisco.com

May 2008 DB-683
Debug Commands
debug fax mspi
Mime Outer Type=2

2d07h: //41/ACF704FA800B/MSPI_ON/mspi_check_connect:
MMccb(Count=0)
2d07h: //41/ACF704FA800B/MSPI_ON/mspi_check_connect:
SMTP Connected To The Server !
2d07h: //41/ACF704FA800B/MSPI/mspi_bridge:
MMccb(State=CONNECTED, Type=Onramp), Destination Call Id=0x2A
2d07h: //41/ACF704FA800B/MSPI_ON/mspi_xmit:
MMccb(State=CONFERENCED, Type=Onramp, Buffer Count=0), Source Call Id=0x2A
2d07h: //41/ACF704FA800B/MSPI_ON/mspi_onramp_buff_finished_callback:
MMccb(Call State=CONFERENCED, Buffer Count=9)
Router#
Table 92 debug fax mspi all Field Descriptions
Field Description
/41/ACF704FA800B/MSPI_ON/mspi_ The format of this message is
call_setup_request: //callid/GUID/module name/function name:
GUID is ACF704FA800B. This identifies the call.
MSPI_ON identifies the fax mail onramp MSPI call leg.
MSPI_OFF would identify the offramp call leg.
The mspi_call_setup_request field shows that the MSPI
is requesting a call setup.
Outgoing Peer Tag=22 Indicates the unique dial peer tag.
Envelope Indicates the sender of the fax mail message.
From=FAX=5550121@cisco.com
Envelope To=jdoe@server.cisco.com Indicates the receiver of the fax mail message.
mspi_xmit: Indicates that the MSPI is transmitting data.

DB-684 May 2008
Debug Commands
debug fax mspi
Table 92 debug fax mspi all Field Descriptions (continued)
Field Description
State=CONFERENCED Describes the MPSI state.
Type=Onramp Describes whether the fax is on-ramp or off-ramp.
Buffer Count=0 Indicates the buffer count.
Source Call Id=0x2A Identifies the source call ID.

May 2008 DB-685
Debug Commands
debug fax mta
debug fax mta

To troubleshoot the fax Mail Transfer Agent (MTA), use the debug fax mta command in privileged
debug fax mta [all | default | detail | error [call [informational] | software [informational]] |
no debug fax mta
Syntax Description all (Optional) Displays all fax MTA debugging messages.
default (Optional) Displays fax MTA error and inout information. This option also
detail (Optional) Displays fax MTA background messages.
error (Optional) Displays fax MTA error messages.
event (Optional) Displays fax MTA events.
function (Optional) Displays fax MTA functions.
inout (Optional) Displays fax MTA in/out functions.

12.3(8)T This command replaces the debug mta receive all, debug mta send all, and
debug mta send rcpt-to commands.
Examples The following is sample output from the debug fax mta all command:
Router# debug fax mta all

2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_new_context_guid[2177]:
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_open:
from=FAX=7771111@cisco.com, to=jdoe@server.cisco.com
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_open[1868]:
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_add_headers:

DB-686 May 2008
Debug Commands
debug fax mta
from_comment=
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_work_routine:
socket 0 readable for first time
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_getln:
(C)R: 220 vip2-das.cisco.com ESMTP Sendmail 8.9.3/8.9.3; Thu, 5 Jun 2003 23:24:54 -0700
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_writeln:
(C)S: EHLO Router.cisco.com
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_write:
return code=0
(C)R: 250-vip2-das.cisco.com Hello [172.19.140.108], pleased to meet you
(C)R: 250-EXPN
(C)R: 250-VERB
(C)R: 250-8BITMIME
(C)R: 250-SIZE
(C)R: 250-DSN
(C)R: 250-ONEX
(C)R: 250-ETRN
(C)R: 250-XUSR
(C)R: 250 HELP
(C)S: MAIL FROM:<FAX=7771111@cisco.com>
return code=0
(C)R: 250 <FAX=7771111@cisco.com>... Sender ok
(C)S: RCPT TO:<jdoe@server.cisco.com>
return code=0
(C)R: 250 <jdoe@server.cisco.com>... Recipient ok
return code=0
(C)R: 354 Enter mail, end with "." on a line by itself
(C)S: Received: by Router.cisco.com for <jdoe@server.cisco.com> (with Cisco NetWorks);
Thu, 05 Jun 2003 23:11:09 +0000
return code=0
(C)S: To: "jdoe" <jdoe@server.cisco.com>
return code=0
(C)S: Message-ID: <00222003231109198@Router.cisco.com>
return code=0
(C)S: Date: Thu, 05 Jun 2003 23:11:09 +0000
return code=0

May 2008 DB-687
Debug Commands
debug fax mta
Table 93 debug fax mta all Field Descriptions
Field Description
//-1/CEB9FA0B800E/SMTPC/ The format of this message is
esmtp_client_engine_open: //callid/GUID/module name/function name:
CallEntry ID is -1. This indicates that a call leg has not
been identified.
GUID is CEB9FA0B800E. This identifies the call.
SMTPC is the module name.
The esmtp_client_engine_open field shows that the fax
mail client engine is opening a session.
from=FAX=7771111@cisco.com Indicates the sender of the fax mail message.
to=jdoe@server.cisco.com Indicates the receiver of the fax mail message.
esmtp_client_engine_writeln: Indicates that the fax mail client engine is writing data.
esmtp_client_engine_getln: Indicates that the fax mail client engine is receiving data.

DB-688 May 2008
Debug Commands
debug fax relay t30
debug fax relay t30

To display debugging messages for T.30 real-time fax, use the debug fax relay t30 command in
debug fax relay t30 {all | calling-number string | called-number string}
no debug fax relay t30
Syntax Description all Enables debugging for all incoming and outgoing calls.
calling-number Enables debugging for incoming numbers that begin with a
specified string of digits.
called-number Enables debugging for outgoing numbers that begin with a specified
string of digits.
string Digits that specify the incoming or outgoing number.

12.2(2)XB1 The debug fax relay t30 command was introduced on
Cisco AS5350, Cisco AS5400, and Cisco AS5850 access servers.
12.2(11)T This command was integrated into Cisco IOS Release 12.2(11)T for
the Cisco AS5350, Cisco AS5400, and Cisco AS5850 access
servers.
Usage Guidelines The incoming or outgoing numbers must be a valid E.164 destination. The period symbol (.) as a
wildcard should not be used. Instead of a wildcard, leave the space blank to indicate that any numbers
can be valid.
There are no limits to the number of debug entries. The number entered generates a match if the calling
or called number matches up to the final number of the debug entry. For example, the 408555 entry
would match 408555, 4085551, 4085551212, or any other number starting with 408555.
Examples The following command enables debugging for any incoming calls that start with 408555:
Router# debug fax relay t30 calling-number 408555
Debugging fax relay t30 from 408555

May 2008 DB-689
Debug Commands
debug fax relay t30
The following command enables debugging for any calls received to a number starting with 555-1212:
Router# debug fax relay t30 called-number 4155551212
Debugging fax relay t30 to 4155551212
The following command displays all debug entries:

Router# debug fax relay t30 all
Debugging fax relay t30 from 408555

Debugging fax relay t30 to 4155551212

DB-690 May 2008
Debug Commands
debug fddi smt-packets

To display information about Station Management (SMT) frames received by the router, use the debug
fddi smt-packets command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
no debug fddi smt-packets
Examples The following is sample output from the debug fddi smt-packets command. In this example, an SMT
frame has been output by FDDI 1/0. The SMT frame is a next station addressing (NSA) neighbor
information frame (NIF) request frame with the parameters as shown.
Router# debug fddi smt-packets
SMT O: Fddi1/0, FC=NSA, DA=ffff.ffff.ffff, SA=00c0.eeee.be04,

class=NIF, type=Request, vers=1, station_id=00c0.eeee.be04, len=40
- code 1, len 8 -- 000000016850043F
- code 2, len 4 -- 00010200
- code 3, len 4 -- 00003100
- code 200B, len 8 -- 0000000100000000
Table 94 debug fddi smt-packets Field Descriptions
Field Description
SMT O SMT frame was sent from FDDI interface 1/0. Also, SMT I indicates
that an SMT frame was received on the FDDI interface 1/0.
Fddi1/0 Interface associated with the frame.
FC Frame control byte in the MAC header.
DA, SA Destination and source addresses in FDDI form.
class Frame class. Values can be echo frame (ECF), neighbor information
frame (NIF), parameter management frame (PMF), request denied
frame (RDF), status information frame (SIF), and status report frame
(SRF).
type Frame type. Values can be Request, Response, and Announce.
vers Version identification. Values can be 1 or 2.
station_id Station identification.

May 2008 DB-691
Debug Commands
Table 94 debug fddi smt-packets Field Descriptions (continued)
Field Description
len Packet size.
code 1, len 8 -- Parameter type X0001upstream neighbor address (UNA),
000000016850043F parameter length in bytes, and parameter value. SMT parameters are
described in the SMT specification ANSI X3T9.

DB-692 May 2008
Debug Commands
debug filesystem
debug filesystem
To enable ATA ROM monitor library (monlib) debugging messages, use the debug filesystem command
in privileged EXEC mode. To disable ATA monlib debugging messages, use the no form of this
command.
debug filesystem {disk0 | disk1}
no debug filesystem {disk0 | disk1}
Syntax Description disk0 Selects disk 0 as the disk on which to enable or disable debugging.
disk1 Selects disk 1 as the disk on which to enable or disable debugging.

Usage Guidelines The debug filesystem command enables the display of ATA monlib debugging messages during boot
operations.
To display the debugging messages when ROMMON accesses the PCMCIA disk, the ROMMON must
have disk support. In other words, if a dev command is entered in ROMMON mode, the output should
display the supported disks as shown in the following example:
rommon 1> dev
Devices in device table:

id name
bootflash: boot flash
slot0: PCMCIA slot 0
slot1: PCMCIA slot 1
disk0: PCMCIA slot 0
disk1: PCMCIA slot 1
eprom: eprom
Examples The following example shows how to enable ATA monlib debugging messages on disk 0, reboot the
router to view ATA monlib debugging messages, and then disable ATA monlib debugging messages:
Router# debug filesystem disk0
rommon 1> boot disk0:c7200-is-mz.123-5.7.PI3a
Initializing ATA monitor library.......

May 2008 DB-693
Debug Commands
debug filesystem
ATA_read_sector:dev = 0
ATA_data_xfer:1:dev = 0, command = 32, nsecs = 8, sector = 3, cyl_low = 0,
cyl_high = 0, head = 171
ATA_read_sector:dev = 0, retval = 0
dfs_openfile:Using monlib version 2
dfs_openfile:Using version info 1
dfs_openfile:finding file.. /c7200-is-mz.123-5.7.PI3a
dfs_openfile:opened file.. /c7200-is-mz.123-5.7.PI3a with fd = 0
DFSLIB_read:reading file.. fd = 0, byte_count = 4
DFSLIB_read:read from.. fd = 0, byte_count = 4, retval = 4
.
.
.
.
.
.
Self decompressing the image
:#####################################################################
##########################################################################################
##########
############################################################### [OK]
Router# no debug filesystem disk0
Table 95 debug filesystem Field Descriptions
Field Description
dev = The number of the device being accessed.
command = The operation that is being executed.
nsecs = The number of sectors on the device.
sector = The starting sector.
cyl_low =, cyl_high = The starting cylinder, low and high.

DB-694 May 2008
Debug Commands
debug filesystem
Table 95 debug filesystem Field Descriptions (continued)
Field Description
head = The head number.
retval = The status of the operation being executed.

May 2008 DB-695
Debug Commands
debug flow exporter
debug flow exporter

To enable debugging output for Flexible NetFlow flow exporters, use the debug flow exporter
debug flow exporter [[name] exporter-name] [error] [event] [packets number]
no debug flow exporter [[name] exporter-name] [error] [event] [packets number]
Syntax Description name exporter-name (Optional) The name of a flow exporter that you previously configured.
error (Optional) Enables debugging for flow exporter errors.
event (Optional) Enables debugging for flow exporter events.
packets (Optional) Enables packet level debugging for flow exporters.
number (Optional) Configures the number of packets to debug for packet level
debugging of flow exporters.
Command Default Debugging output for Flexible NetFlow flow exporters is disabled.

Usage Guidelines You must have already enabled traffic monitoring with Flexible NetFlow using an exporter before you
can use the debug flow exporter command.
Examples The following example indicates that a flow exporter packet has been queued for process send:
Router# debug flow exporter
May 21 21:29:12.603: FLOW EXP: Packet queued for process send

clear flow exporter Clears the Flexible NetFlow statistics for exporters.
debug flow exporter Enables debugging output for Flexible NetFlow flow exporters.

DB-696 May 2008
Debug Commands
debug flow exporter
Command Description
destination Configures an export destination for Flexible NetFlow flow exporters.
dscp Configure optional DSCP parameters for Flexible NetFlow flow exporters.
flow exporter Creates a Flexible NetFlow flow exporter.
export-protocol Configures the export protocol version for Flexible NetFlow flow exporters.
option Configure options for Flexible NetFlow flow exporters.
show flow exporter Displays Flexible NetFlow flow exporter status and statistics.
source Configures the source IP address interface for Flexible NetFlow flow
exporters.
template Configures the template resend timeout for Flexible NetFlow flow exporters.
transport Configures the transport protocol for Flexible NetFlow flow exporters.
ttl Configures the TTL value for Flexible NetFlow flow exporters.

May 2008 DB-697
Debug Commands
debug flow monitor
debug flow monitor

To enable debugging output for Flexible NetFlow flow monitors, use the debug flow monitor command
debug flow monitor [error] [{[name] monitor-name [cache] [error] [packets packets]}]
no debug flow monitor [error] [{[name] monitor-name [cache] [error] [packets packets]}]
Syntax Description name monitor-name (Optional) The name of a flow monitor that you previously configured.
cache (Optional) Enables debugging for the flow monitor cache.
error (Optional) Enables debugging for flow monitor errors.
packets (Optional) Enables packet level debugging for flow monitors.
packets (Optional) The number of packets to debug for packet-level debugging of
flow monitors.
Command Default Debugging output for Flexible NetFlow flow monitors is disabled.

Usage Guidelines You must have already enabled traffic monitoring with Flexible NetFlow before you can use the
debug flow monitor command.
Examples The following example shows that the cache for FLOW-MONITOR-1 was deleted:
Router# debug flow monitor FLOW-MONITOR-1 cache
May 21 21:53:02.839: FLOW MON: 'FLOW-MONITOR-1' deleted cache

cache Configures flow cache parameters for Flexible NetFlow flow monitors.
clear flow monitor Clears the Flexible NetFlow flow monitor.
debug flow monitor Enables debugging output for Flexible NetFlow flow monitors.

DB-698 May 2008
Debug Commands
debug flow monitor
Command Description
exporter Specifies a flow exporter for Flexible NetFlow flow monitors.
flow monitor Creates a Flexible NetFlow flow monitor.
protocol-distribution Configures the collection of protocol distribution statistics for Flexible
NetFlow flow monitors.
record Configures a flow record a for Flexible NetFlow flow monitor.
show flow monitor Displays Flexible NetFlow flow monitor status and statistics.
size-distribution Configures the collection of size distribution statistics for Flexible NetFlow
flow monitors.

May 2008 DB-699
Debug Commands
debug flow record
debug flow record

To enable debugging output for Flexible NetFlow flow records, use the debug flow record command in
debug flow record [[name] record-name | netflow-original] | netflow ipv4 record [peer] | options
{{exporter-statistics | interface-table | sampler-table} [detailed | error]}]
no debug flow record [[name] record-name | netflow-original] | netflow ipv4 record [peer] |
options {{exporter-statistics | interface-table | sampler-table} [detailed | error]}]
Syntax Description name record-name (Optional) The name of a flow record that you previously configured.
netflow-original (Optional) Traditional IPv4 input NetFlow with origin autonomous
systems.
netflow ipv4 record (Optional) The name of the NetFlow predefined record that you want to
run debugging on. See Table 96.
peer (Optional) Includes peer information for the NetFlow predefined records
that support the peer keyword.
Note The peer keyword is not supported for every type of NetFlow
predefined record. See Table 96.
options (Optional) Includes information on other flow record options.
exporter-statistics (Optional) Information on the flow exporter statistics.
interface-table (Optional) Information on the interface tables.
sampler-table (Optional) Information on the sampler tables.
detailed (Optional) Show detailed information.
error (Optional) Only show errors.
Command Default Debugging output for Flexible NetFlow flow records is disabled


DB-700 May 2008
Debug Commands
debug flow record
Usage Guidelines You must have already enabled traffic monitoring with Flexible NetFlow before you can use the
debug flow record command.
Keywords and Descriptions for the record Argument

Table 96 describes the keywords and descriptions for the record argument.
Table 96 Keywords and Descriptions for the record Argument
as Autonomous system record.

as-tos Autonomous systems and TOS record.
bgp-nexthop-tos BGP next-hop and TOS record.
destination-prefix Destination Prefix record.
destination-prefix-tos Destination Prefix and TOS record.
original-input Traditional IPv4 input NetFlow.
original-output Traditional IPv4 output NetFlow.
prefix Source and Destination Prefixes record.
prefix-port Prefix Port record.
Note The peer keyword is not available for this record.
prefix-tos Prefix TOS record.
protocol-port Protocol Ports record.
protocol-port-tos Protocol Port and TOS record.
source-prefix Source AS and Prefix record.
source-prefix-tos Source Prefix and TOS record.
Examples There are no examples available for this command.

collect counter Configures the counters as a non-key field and collect the counter values.
collect flow Configures flow identifying fields as a non-key fields and collect their
values.
collect interface Configure the input and/or output interface as a non-key field and collect the
values.
collect ipv4 Configures an IPv4 field as a non-key field and collect the value in it.
collect routing Configures a routing attribute as a non-key field and collect the value of the
field.
collect timestamp Configures the timestamp fields as a non-key field and collect the values.
collect transport Configures a transport layer field as a non-key field and collect the values.
debug flow record Enables debugging output for Flexible NetFlow flow records.

May 2008 DB-701
Debug Commands
debug flow record
Command Description
flow record Create a Flexible NetFlow flow record.
match flow Configures one or more of the flow fields as key fields.
match interface Configures the direction that traffic flows in respect to an interface (interface
field) as a key field.
match ipv4 Configures one or more of the IPv4 fields as a key field.
match routing Configures one or more of the routing fields as a key field.
match timestamp Configures a timestamp field as a key field.
match transport Configures one or more of the transport fields as a key field.
show flow record Displays Flexible NetFlow flow record status and statistics.

DB-702 May 2008
Debug Commands
debug flow-sampler
debug flow-sampler
To enable debugging output for NetFlow sampler activity, use the debug flow-sampler command in
privileged EXEC mode. To disable debugging output for NetFlow sampler activity, use the no form of
this command.
debug flow-sampler {class-based | events | ipc | match}
no debug flow-sampler {class-based | events | ipc | match}
Syntax Description class-based Displays debug messages for class-based NetFlow samplers.
events Displays debug messages when a NetFlow sampler map is added, deleted, or applied
to an interface.
ipc Displays NetFlow sampler-related debug messages for interprocess communications
(IPC) between the route processor and line cards.
match Displays debug messages when a packet is sampled (is matched with a
NetFlow sampler).
Command Default Debugging output for NetFlow sampler activity is disabled.

12.3(4)T The class-based keyword was added.
staff. Moreover, you should use debug commands during periods of lower network traffic and fewer
users. Debugging during these periods reducess the likelihood that increased debug command processing
overhead will affect system use.
Examples The following is sample output from the debug flow-sampler events command:

May 2008 DB-703
Debug Commands
debug flow-sampler
Router# debug flow-sampler events
Flow sampler events debugging is on

Router(config# no flow-sampler mysampler2
Router(config)#
5d00h: Flow: Sampler mysampler2 detached from FastEthernet0/1
5d00h: Flow: Sampler mysampler2 deleted
The following is sample output from the debug flow-sampler match command:
Router# debug flow-sampler match
Flow sampler match debugging is on

Router#
4d23h: Flow: Packet matched sampler mysampler1 on interface FastEthernet0/0
Router#
Router#
Router#
Table 97 debug flow-sampler Field Descriptions
Field Description
Sampler Name of the NetFlow sampler.
id Unique ID of the NetFlow sampler.
packets matched Number of packets matched (sampled) for the NetFlow
sampler.
mode NetFlow sampling mode.
sampling interval is NetFlow sampling interval (in packets).

flow-sampler Enables a Random Sampled NetFlow sampler.
flow-sampler-map Defines a Random Sampled NetFlow sampler map.
ip flow-export Enables the export of NetFlow data to a collector.
mode (flow sampler map) Specifies a Random Sampled NetFlow sampling mode and sampling
rate.
netflow-sampler Enables a class-based NetFlow sampler.
show flow-sampler Displays attributes (including mode, sampling rate, and number of
sampled packets) of one or all Random Sampled NetFlow samplers.
show ip flow export Displays the statistics for the NetFlow data export.

DB-704 May 2008
Debug Commands
debug fm private-hosts
debug fm private-hosts
To enable debug messages for the Private Hosts feature manager, use the debug fm private-hosts
debug fm private-hosts {all | vmr | unusual | events}
Syntax Description all Enable debug messages for all Private Hosts errors and events.
vmr Enable debug messages for the Multicast VLAN Registration (MVR) feature.
unusual Enable debug messages for unexpected Private Hosts behavior.
events Enable debug messages for Private Hosts events.
Defaults This command has no default settings.

Examples The following example shows sample command output:

Router# debug fm private-hosts all
fm private-hosts vmr debugging is on
fm private-hosts unusual debugging is on
fm private-hosts events debugging is on
Router#

debug private-hosts Enables debug messages for Private Hosts.

May 2008 DB-705
Debug Commands
debug fmsp receive
debug fmsp receive

Note Effective with release 12.3(8)T, the debug fmsp receive command is replaced by the debug fax fmsp
command. See the debug fax fmsp command for more information.
To display debugging messages for Fax Media Services Provider (FMSP) receive, use the debug fmsp
receive command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug fmsp receive [t30 | t38]
no debug fmsp receive [t30 | t38]
Syntax Description t30 (Optional) Specifies the T.30 fax protocol.

t38 (Optional) Specifies the T.38 fax protocol.

12.2(8)T This command was implemented on the Cisco 1751 access routers,
Cisco 3725 access routers, and Cisco 3745 access routers.
12.2(13)T Support for this command was implemented in Cisco 7200 series
images.
12.3(8)T This command was replaced by the debug fax fmsp command.
Examples The following is sample output from the debug fmsp receive command:
Router# debug fmsp receive
*Oct 16 08:31:33.243: faxmsp_call_setup_request: call id=28

*Oct 16 08:31:33.243: faxmsp_call_setup_request: ramp data dir=ONRAMP, conf dir=DEST
*Oct 16 08:31:33.243: faxmsp_bridge(): cfid=19, srccid=28, dstcid=27
*Oct 16 08:31:33.243: faxmsp_bridge(): ramp data dir=ONRAMP, conf dir=DEST

*Oct 16 08:31:33.243: faxmsp_bridge(): Explicit caps ind. done; will wait for registry
caps ind

DB-706 May 2008
Debug Commands
debug fmsp receive
*Oct 16 08:31:33.243: faxmsp_caps_ind: call id=28, src=27

*Oct 16 08:31:33.243: faxmsp_caps_ack: call id src=27
*Oct 16 08:31:33.279: faxmsp_call_setup_request: call id=29
*Oct 16 08:31:33.279: faxmsp_call_setup_request: ramp data dir=OFFRAMP, conf dir=SRC
*Oct 16 08:31:33.283: faxmsp_bridge(): cfid=20, srccid=29, dstcid=26
*Oct 16 08:31:33.283: faxmsp_bridge(): ramp data dir=OFFRAMP, conf dir=SRC

*Oct 16 08:31:33.283: faxmsp_bridge(): Explicit caps ind. done; will wait for registry
caps ind
*Oct 16 08:31:33.283: faxmsp_caps_ind: call id=29, src=26
*Oct 16 08:31:33.283: faxmsp_caps_ack: call id src=26
*Oct 16 08:31:33.635: faxmsp_codec_download_done: call id=29
*Oct 16 08:31:33.635: faxmsp_codec_download_done: call id=28
*Oct 16 08:31:33.643: faxmsp_xmit: callid src=26, dst=29
*Oct 16 08:31:33.643: faxmsp_xmit: callid src=27, dst=28
*Oct 16 08:31:33.643: faxmsp_process_rcv_data: call id src=26, dst=29

debug fmsp send Displays debugging messages for FMSP send.

May 2008 DB-707
Debug Commands
debug fmsp send
debug fmsp send

Note Effective with release 12.3(8)T, the debug fmsp send command is replaced by the debug fax fmsp
command. See the debug fax fmsp command for more information.
To display debugging messages for Fax Media Services Provider (FMSP) send, use the debug fmsp send
debug fmsp send [t30 | t38]
no debug fmsp send [t30 | t38]
Syntax Description t30 (Optional) Specifies the T.30 fax protocol.

t38 (Optional) Specifies the T.38 fax protocol.

12.2(13)T This feature was implemented on the Cisco 7200 series routers.
12.3(8)T This command was replaced by the debug fax fmsp command.
Examples The following is sample output from the debug fmsp send command:
Router# debug fmsp send
Jan 1 05:02:56.782: faxmsp_call_setup_request: call id=21

Jan 1 05:02:56.782: faxmsp_call_setup_request: ramp data dir=OFFRAMP, conf dir=SRC
Jan 1 05:02:56.782: faxmsp_bridge(): cfid=7, srccid=21, dstcid=20
Jan 1 05:02:56.782: faxmsp_bridge(): ramp data dir=OFFRAMP, conf dir=SRC

Jan 1 05:02:56.782: faxmsp_bridge(): Explicit caps ind. done; will wait for registry caps
ind
Jan 1 05:02:56.782: faxmsp_caps_ind: call id=21, src=20
Jan 1 05:02:56.782: faxmsp_caps_ack: call id src=20
Jan 1 05:02:57.174: faxmsp_codec_download_done: call id=21

DB-708 May 2008
Debug Commands
debug fmsp send
Jan 1 05:02:57.174: faxMsp_tx_buffer callID=21

Jan 1 05:02:57.182: faxmsp_xmit: callid src=20, dst=21
Jan 1 05:02:57.182: faxmsp_process_rcv_data: call id src=20, dst=21

debug fax relay t30 Displays debugging messages for FMSP receive.

May 2008 DB-709
Debug Commands
debug foip off-ramp
debug foip off-ramp

Note Effective with release 12.3(8)T, the debug foip off-ramp command is replaced by the debug fax foip
command. See the debug fax foip command for more information.
To display debugging messages for off-ramp fax mail, use the debug foip off-ramp command in
debug foip off-ramp
no debug foip off-ramp

12.2(8)T This command was introduced on the Cisco 1751 access routers,
12.3(8)T This command was replaced by the debug fax foip command.
Examples The following is sample output from the debug foip off-ramp command:
Router# debug foip off-ramp
Jan 1 02:31:17.539: lapp off: CC_EV_CALL_HANDOFF, cid(0xB)

Jan 1 02:31:17.539: loffHandoff: called number=5271714, callid=0xB
Jan 1 02:31:17.543: loffSetupPeer: cid1(0xB)
Jan 1 02:31:17.543: destPat(5271714),matched(1),pref(5),tag(20),encap(1)
Jan 1 02:31:22.867: lapp off: CC_EV_CALL_CONNECTED, cid(0xC)
Jan 1 02:31:22.867: st=CALL_SETTING cid(0xB,0x0,0x0,0xC),cfid(0x0,0x0,0x0)
Jan 1 02:31:22.867: loffConnected
Jan 1 02:31:22.867: loffFlushPeerTagQueue cid(11) peer list: (empty)
Jan 1 02:31:22.867: lapp off: CC_EV_CONF_CREATE_DONE, cid(0xC), cid2(0xD), cfid(0x1)
Jan 1 02:31:22.867: st=CONFERENCING3 cid(0xB,0x0,0xD,0xC),cfid(0x0,0x0,0x1)
Jan 1 02:31:22.867: loffConfDone3
Jan 1 02:31:30.931: lapp off: CC_EV_FROM_FMSP_ON_CALL_DETAIL, cid(0xD)
Jan 1 02:31:30.931: st=WAIT_SESS_INFO cid(0xB,0x0,0xD,0xC),cfid(0x0,0x0,0x1)

DB-710 May 2008
Debug Commands
debug foip off-ramp
Jan 1 02:31:30.931: loffSessionInfo

Jan 1 02:31:30.931: encd=2, resl=2, spd=26, min_scan_len=0, csid= 4085271714
Jan 1 02:31:30.931: lapp off: CC_EV_CONF_CREATE_DONE, cid(0xD), cid2(0xE), cfid(0x2)
Jan 1 02:31:30.931: st=CONFERENCING2 cid(0xB,0xE,0xD,0xC),cfid(0x0,0x2,0x1)
Jan 1 02:31:30.931: loffConfDone2

debug foip on-ramp Displays debugging messages for on-ramp fax mail.

May 2008 DB-711
Debug Commands
debug foip on-ramp
debug foip on-ramp

Note Effective with release 12.3(8)T, the debug foip on-ramp command is replaced by the debug fax foip
command. See the debug fax foip command for more information.
To display debugging messages for on-ramp fax mail, use the debug foip on-ramp command in
debug foip on-ramp
no debug foip on-ramp

12.2(8)T This command was introduced on the Cisco 1751 access routers,
12.3(8)T This command was replaced by the debug fax foip command.
Examples The following is sample output from the debug foip on-ramp command:
Router# debug foip on-ramp
*Oct 16 08:07:01.947: lapp_on_application: Incoming Event: (15 = CC_EV_CALL_HANDOFF),

CID(11), DISP(0)
*Oct 16 08:07:01.947: lapp_on_call_handoff: Authentication enabled = FALSE
*Oct 16 08:07:01.947: lapp_on_call_handoff: Authentication ID = 0
*Oct 16 08:07:01.947: lapp_on_call_handoff: Authentication ID source = IVR or unknown
*Oct 16 08:07:01.947: lapp_on_call_handoff: Authentication status = SUCCESS
*Oct 16 08:07:01.947: lapp_on_call_handoff: Accounting enabled = FALSE
*Oct 16 08:07:01.947: lapp_on_call_handoff: Accounting method list = fax
*Oct 16 08:07:01.947: lapp_on_conference_vtsp_fmsp: Begin conferencing VTSP and FMSP...
*Oct 16 08:07:01.951: lapp_on_change_state: old state(0) new state(1)
*Oct 16 08:07:01.951: lapp_on_application: Incoming Event: (29 = CC_EV_CONF_CREATE_DONE),
CID(11), DISP(0)
*Oct 16 08:07:01.951: lapp_on_application: Current call state = 1

DB-712 May 2008
Debug Commands
debug foip on-ramp
*Oct 16 08:07:01.951: lapp_on_conference_created: The VTSP and the FMSP are conferenced
*Oct 16 08:07:01.951: lapp_on_conference_created: Wait for FMSP call detail event

debug foip off-ramp Displays debugging messages for off-ramp fax mail.

May 2008 DB-713
Debug Commands
debug fpm event
debug fpm event

To display protocol information from the designated protocol header description field (PHDF), use the
debug fpm event command in privileged EXEC mode. To disable debugging messages, use the no form
of this command.
debug fpm event
no debug fpm event

12.2(18)ZY This command was integrated into Cisco IOS Release 12.2(18)ZY on the
Catalyst 6500 series of switches equipped with the Programmable Intelligent
Services Accelerator (PISA).
Examples The following sample output is from the debug fpm event command:
Router# debug fpm event
*Jun 21 09:22:21.607: policy-classification-inline(): matches class: class-default *Jun 21

09:22:21.607: packet-access-control(): policy-map: fpm-policy, dir: input, match. retval:
0x0, ip-flags: 0x80000000

DB-714 May 2008
Debug Commands

To display information pertaining to an adjacent node that has one or more Frame Relay permanent
virtual circuit (PVC) bundles, use the debug frame-relay adjacency command in privileged EXEC
mode. To stop displaying the adjacent node information, use the no form of this command.
debug frame-relay adjacency {pvc [dlci] | vc-bundle [vc-bundle-name]}
no debug frame-relay adjacency {pvc [dlci] | vc-bundle [vc-bundle-name]}
Syntax Description pvc Displays information regarding the adjacent PVC only.
dlci (Optional) Data-link connection identifier for a specific PVC.
vc-bundle Displays information regarding the adjacent PVC bundle and its members.
vc-bundle-name (Optional) Name of the PVC bundle.
Defaults No default behaviors or values.

Usage Guidelines Use this command to monitor adjacency activity and status for an adjacent node.
Note Debug messages that are prefixed with FR_ADJ (instead of FR-ADJ) indicate serious failures in the
Frame Relay PVC bundle performance. Contact the Cisco Technical Assistance Center (TAC) if you see
debugging messages with this prefix.

May 2008 DB-715
Debug Commands
Examples The following sample output from the debug frame-relay adjacency vc-bundle command shows PVC
bundle MP-4-dynamic going down. Each bundle member PVC is marked for removal from the CEF
adjacency table, and then the adjacency for the PVC bundle itself is marked for removal. The adjacencies
are actually removed from the table later when a background clean-up process runs.
Router# debug frame-relay adjacency vc-bundle MP-4-dynamic
00:46:35: FR-ADJ: vcb MP-4-dynamic: ip 10.2.2.2: member 400: removing adj

00:46:35: FR-ADJ: vcb MP-4-dynamic: ip 10.2.2.2: removing primary adj

debug frame-relay vc-bundle Displays information pertaining to all the PVC bundles configured
on the router.

DB-716 May 2008
Debug Commands
debug frame-relay callcontrol

To display Frame Relay Layer 3 (network layer) call control information, use the debug frame-relay
callcontrol command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
no debug frame-relay callcontrol
Usage Guidelines The debug frame-relay callcontrol command is used specifically for observing FRF.4/Q.933 signalling
messages and related state changes. The FRF.4/Q.933 specification describes a state machine for call
control. The signalling code implements the state machine. The debug statements display the actual
event and state combinations.
The Frame Relay switched virtual circuit (SVC) signalling subsystem is an independent software
module. When used with the debug frame-relay networklayerinterface command, the
debug frame-relay callcontrol command provides a better understanding of the call setup and teardown
sequence. The debug frame-relay networklayerinterface command provides the details of the
interactions between the signalling subsystem on the router and the Frame Relay subsystem.
Examples State changes can be observed during a call setup on the calling party side. The debug frame-relay
networklayerinterface command shows the following state changes or transitions:
STATE_NULL -> STATE_CALL_INITIATED -> STATE_CALL_PROCEEDING->STATE_ACTIVE
The following messages are samples of output generated during a call setup on the calling side:
6d20h: U0_SetupRequest: Serial0
6d20h: L3SDL: Ref: 1, Init: STATE_NULL, Rcvd: SETUP_REQUEST, Next: STATE_CALL_INITIATED
6d20h: U1_CallProceeding: Serial0
6d20h: L3SDL: Ref: 1, Init: STATE_CALL_INITIATED, Rcvd: MSG_CALL_PROCEEDING, Next:
STATE_CALL_PROCEEDING
6d20h: U3_Connect: Serial0
6d20h: L3SDL: Ref: 1, Init: STATE_CALL_PROCEEDING, Rcvd: MSG_CONNECT, Next: STATE_ACTIVE
6d20h:
The following messages are samples of output generated during a call setup on the called party side. Note
the state transitions as the call goes to the active state:
STATE_NULL -> STATE_CALL_PRESENT-> STATE_INCOMING_CALL_PROCEEDING->STATE_ACTIVE
1w4d: U0_Setup: Serial2/3

1w4d: L3SDL: Ref: 32769, Init: STATE_NULL, Rcvd: MSG_SETUP, Next: STATE_CALL_PRESENT 1w4d:
L3SDL: Ref: 32769, Init: STATE_CALL_PRESENT, Rcvd: MSG_SETUP, Next:
STATE_INCOMING_CALL_PROC 1w4d: L3SDL: Ref: 32769, Init: STATE_INCOMING_CALL_PROC,
Rcvd: MSG_SETUP, Next: STATE_ACTIVE

May 2008 DB-717
Debug Commands
Table 98 explains the possible call states.
Table 98 Frame Relay Switched Virtual Circuit Call States
Call State Description

Null No call exists.
Call Initiated User has requested the network to establish a call.
Outgoing Call Proceeding User has received confirmation from the network that
the network has received all call information necessary
to establish the call.
Call Present User has received a request to establish a call but has
not yet responded.
Incoming Call Proceeding User has sent acknowledgment that all call information
necessary to establish the call has been received (for an
incoming call).
Active On the called side, the network has indicated that the
calling user has been awarded the call.
On the calling side, the remote user has answered the
call.
Disconnect Request User has requested that the network clear the
end-to-end call and is waiting for a response.
Disconnect Indication User has received an invitation to disconnect the call
because the network has disconnected the call.
Release Request User has requested that the network release the call and
is waiting for a response.

debug fax relay t30 Displays debugging information about the packets
that are received on a Frame Relay interface.
debug frame-relay networklayerinterface Displays NLI information.

DB-718 May 2008
Debug Commands
debug frame-relay end-to-end keepalive

To display debug messages for the Frame Relay End-to-End Keepalive feature, use the debug
frame-relay end-to-end keepalive command. Use the no form of this command to disable the display
of debug messages.
debug frame-relay end-to-end keepalive {events | packet}
no debug frame-relay end-to-end keepalive {events | packet}
Syntax Description events Displays keepalive events.

packet Displays keepalive packets sent and received.

Usage Guidelines We recommend that both commands be enabled.
Examples The following examples show typical output from the debug frame-relay end-to-end keepalive packet
command. The following example shows output for an outgoing request packet:
EEK (o, Serial0.1 DLCI 200): 1 1 1 3 2 4 3
The seven number fields that follow the colon signify the following:
Field Description
first (example value = 1) Information Element (IE) type.
second (example value = 1) IE length.
third (example value = 1) Report ID. 1 = request, 2 = reply.
fourth (example value = 3) Next IE type. 3 = LIV ID (Keepalive ID).
fifth (example value = 2) IE length. (This IE is a Keepalive IE.)
sixth (example value = 4) Send sequence number.
seventh (example value = 3) Receive sequence number.

May 2008 DB-719
Debug Commands
The following example shows output for an incoming reply packet:

EEK (i, Serial0.1 DLCI 200): 1 1 2 3 2 4 4
The seven number fields that follow the colon signify the following:
Field Description
first (example value = 1) Information Element (IE) type.
second (example value = 1) IE length.
third (example value = 2) Report ID. 1 = request, 2 = reply.
fourth (example value = 3) Next IE type. 3 = LIV ID (Keepalive ID).
fifth (example value = 2) IE length. (This IE is a Keepalive IE.)
sixth (example value = 4) Send sequence number.
seventh (example value = 4) Receive sequence number.
The following example shows typical output from the debug frame-relay end-to-end keepalive events
command:
EEK SUCCESS (request, Serial0.2 DLCI 400)
EEK SUCCESS (reply, Serial0.1 DLCI 200)
EEK sender timeout (Serial0.1 DLCI 200)

DB-720 May 2008
Debug Commands
debug frame-relay events

To display debugging information about Frame Relay Address Resolution Protocol (ARP) replies on
networks that support a multicast channel and use dynamic addressing, use the debug frame-relay events
no debug frame-relay events

12.0(23)S This command was integrated into Cisco IOS Release 12.0(23)S for the
Frame Relay over MPLS feature.
Usage Guidelines This command is useful for identifying the cause of end-to-end connection problems during the
installation of a Frame Relay network or node.
Note Because the debug frame-relay events command does not generate much output, you can use it at any
time, even during periods of heavy traffic, without adversely affecting other users on the system.
Examples The following is sample output from the debug frame-relay events command:
Router# debug frame-relay events
Serial2(i): reply rcvd 172.16.170.26 126


May 2008 DB-721
Debug Commands
As the output shows, the debug frame-relay events command returns one specific message type. The
first line, for example, indicates that IP address 172.16.170.26 sent a Frame Relay ARP reply; this packet
was received as input on serial interface 2. The last field (126) is the data-link connection identifier
(DLCI) to use when communicating with the responding router.
For Frame Relay over MPLS, the following is sample output for the debug frame-relay events
command. The command output shows the status of the VCs.
Router# debug frame-relay events
Frame Relay events debugging is on
This example shows the messages that are displayed when you shut the core-facing interface on a
provider edge (PE) router:
04:40:38:%SYS-5-CONFIG_I: Configured from console by consolenf t
Router(config)# interface hssi2/0
04:40:43:%OSPF-5-ADJCHG: Process 10, Nbr 12.12.12.12 on Hssi2/0 from FULL to DOWN,

Neighbor Down: Interface down or detached
04:40:43: FRoMPLS [12.12.12.12, 100]: PW pvc_status set INACTIVE
04:40:43: FRoMPLS [12.12.12.12, 100]: Setting pw segment DOWN
04:40:43: FRoMPLS [12.12.12.12, 100]: Setting connection DOWN
04:40:43: FRoMPLS [12.12.12.12, 101]: Setting pw segment DOWN
04:40:45:%LINK-5-CHANGED: Interface Hssi2/0, changed state to administratively down
04:40:46:%LINEPROTO-5-UPDOWN: Line protocol on Interface Hssi2/0, changed state to down
This example shows the messages that are displayed when you enable the core-facing interface on a PE
router:
Router(config-if)# no shut
04:40:56:%LINK-3-UPDOWN: Interface Hssi2/0, changed state to up

04:40:57:%LINEPROTO-5-UPDOWN: Line protocol on Interface Hssi2/0, changed state to up
04:41:06:%OSPF-5-ADJCHG: Process 10, Nbr 12.12.12.12 on Hssi2/0 from LOADING to FULL,
Loading Done
04:41:19: FRoMPLS [12.12.12.12, 100]: PW pvc_status set ACTIVE
04:41:19: FRoMPLS [12.12.12.12, 100]: Setting pw segment UP
This example shows the messages that are displayed when you shut the edge-facing interface on a PE
router:
Router(config)# interface pos4/0
04:42:50: FRoMPLS [12.12.12.12, 100]: acmgr_circuit_down

04:42:52:%LINK-5-CHANGED: Interface POS4/0, changed state to administratively down
04:42:53:%LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, changed state to down
This example shows the messages that are displayed when you enable the edge-facing interface on a PE
router:
Router(config)# interface pos4/0
04:43:20:%LINK-3-UPDOWN: Interface POS4/0, changed state to up

DB-722 May 2008
Debug Commands
c72-33-2(config-if)#
04:43:20: FRoMPLS [12.12.12.12, 100]: Local up, sending acmgr_circuit_up
04:43:20: FRoMPLS [12.12.12.12, 100]: PW nni_pvc_status set ACTIVE

May 2008 DB-723
Debug Commands
debug frame-relay foresight

To observe Frame Relay traces relating to traffic shaping with router ForeSight enabled, use the debug
frame-relay foresight command in privileged EXEC mode. To disable debugging output, use the no
no debug frame-relay foresight
Examples The following is sample output that shows the display message returned in response to the debug
frame-relay foresight command:
Router# debug frame-relay foresight
FR rate control for DLCI 17 due to ForeSight msg
This message indicates the router learned from the ForeSight message that data-link connection
identifier (DLCI) 17 is now experiencing congestion. The output rate for this circuit should be slowed
down, and in the router this DLCI is configured to adapt traffic shaping in response to foresight
messages.

show frame-relay pvc Displays statistics about PVCs for Frame Relay interfaces.

DB-724 May 2008
Debug Commands
debug frame-relay fragment

To display information related to Frame Relay fragmentation on a permanent virtual circuit (PVC), use
the debug frame-relay fragment command in privileged EXEC mode. To disable debugging output, use
debug frame-relay fragment [event | interface type number dlci]
no debug frame-relay fragment [event | interface type number dlci]
Syntax Description event (Optional) Displays event or error messages related to Frame Relay
fragmentation.
interface (Optional) Displays fragments received or sent on the specified interface.
type (Optional) The interface type for which you wish to display fragments received
or sent.
number (Optional) The Interface number.
dlci (Optional) The data-link connection identifier (DLCI) value of the PVC for
which you wish to display fragments received or sent.

12.0(3)XG This command was introduced.
Usage Guidelines This command will display event or error messages related to Frame Relay fragmentation; it is only
enabled at the PVC level on the selected interface.
This command is not supported on the Cisco MC3810 networking device for fragments received by a
PVC configured via the voice-encap command.
Examples The following is sample output from the debug frame-relay fragment command:
Router# debug frame-relay fragment interface serial 0/0 109
This may severely impact network performance.

You are advised to enable 'no logging console debug'. Continue?[confirm]
Frame Relay fragment/packet debugging is on
Displaying fragments/packets on interface Serial0/0 dlci 109 only
Serial0/0(i): dlci 109, rx-seq-num 126, exp_seq-num 126, BE bits set, frag_hdr 04 C0 7E

May 2008 DB-725
Debug Commands
Serial0/0(o): dlci 109, tx-seq-num 82, BE bits set, frag_hdr 04 C0 52
The following is sample output from the debug frame-relay fragment event command:
Router# debug frame-relay fragment event
This may severely impact network performance.

You are advised to enable 'no logging console debug'. Continue?[confirm]
Frame Relay fragment event/errors debugging is on
Frame-relay reassembled packet is greater than MTU size, packet dropped on serial 0/0
dlci 109
Unexpected B bit frame rx on serial0/0 dlci 109, dropping pending segments
Rx an out-of-sequence packet on serial 0/0 dlci 109, seq_num_received 17

seq_num_expected 19

debug ccfrf11 session Displays the ccfrf11 function calls during call setup and
teardown.
debug ccsip all Displays the ccswvoice function calls during call setup and
teardown.
debug ccsw voice vofr-session Displays the ccswvoice function calls during call setup and
teardown.
debug voice vofr Displays Cisco trunk and FRF.11 trunk call setup attempts;
shows which dial peer is used in the call setup.
debug vpm error Displays the behavior of the Holst state machine.
debug vtsp port Displays the behavior of the VTSP state machine.
debug vtsp vofr subframe Displays the first 10 bytes (including header) of selected VoFR

DB-726 May 2008
Debug Commands
debug frame-relay hqf

To display debug messages for Frame Relay (FR) hierarchical queueing framework (HQF) events, use
the debug frame-relay hqf command in privileged EXEC mode. To disable debugging output, use the
no debug frame-relay hqf

Usage Guidelines Use the debug frame-relay hqf command to track which quality of service (QoS) features are being
used on an interface. QoS for a given FR interface changes depending on the commands being used.
Note You cannot configure weighted fair queueing (WFQ) with HQF; they are mutually exclusive.
To use HQF on an interface, you must complete the following tasks:

Install an interface level service policy without legacy queueing or payload compression.
Attach a Modular Quality of Service (QoS) Command-Line Interface (CLI) (MQC) service policy
to a permanent virtual circuit (PVC) with no legacy restrictions.
This task is accomplished by adding a service policy to a frame map class. A valid MQC service
policy shapes all traffic via the class default and has a child policy to support any further traffic
classification, as shown in the following example:
policy-map llq
class voice
priority 32
policy-map shape1
class class-default
shape average 96000
service-policy llq
policy-map shape2
class class-default
shape average 128000
service-policy llq
map-class frame-relay mqc-class1

May 2008 DB-727
Debug Commands
service-policy output shape1

map-class frame-relay mqc-class2
service-policy output shape2
interface serial4/0
encapsulation frame-relay
frame-relay class mqc-class1 <----- Map-class installed
frame-relay interface-dlci 16 <----- Inherits map-class1
frame-relay interface-dlci 17
class mqc-class2 <----- Map-class installed for DLCI 17
Examples The following is sample output from the debug frame-relay hqf command:
Router# debug frame-relay hqf
debug frame-relay hqf is enabled
Router# show running-configuration

.
.
.
00:25:54: %SYS-5-CONFIG_I: Configured from console by console serial4/1
Building configuration...
Current configuration : 167 bytes

!
interface Serial4/1
serial restart-delay 0
service-policy output shape
end
The following commands and subsequent output show events that occur when HQF is enabled or
disabled as a result of queueing changes at the interface level while debugging is on:
Router(config)# interface serial4/1
Router(config-if)# policy-map shape
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape average 128000 1000
Router(config-pmap-c)# interface serial4/1
Router(config-if)# encapsulation frame-relay
Router(config-if)# frame-relay fragment 80 end-to-end
Router(config-if)# service-policy output shape
Router(config-if)# frame-relay map ip 10.0.0.1 16 payload frf9 stac
00:26:52: Serial4/1- Setting up interface for legacy QOS. <---Indicates legacy QoS is
being installed on an interface.
00:26:52: Legacy fair-queueing installed on interface. <---Indicates that legacy QoS is

being installed and HQF is being removed. You see this only with interface fragmentation
and service policies since these policies must be able to support both QoS mechanisms.
This usually means that either payload compression has been enabled on an interface or
legacy queueing has been set up on the main interface.
Router(config-if)# no frame-relay map ip 10.0.0.1 16 payload frf9 stac
00:27:08: Serial4/1- Setting up HQF/MQC QOS. <---Indicates that the last legacy
restriction has been removed and HQF is being installed on the interface.

DB-728 May 2008
Debug Commands
00:27:08: Serial4/1- Setting up interface for legacy QOS. <--- Indicates that legacy QoS
is being installed on the interface.

Router(config-if)# frame-relay map ip 10.0.0.1 16
Router(config-if)# no service-policy output shape
Router(config-if)# no frame-relay fragment 80 end-to-end
The following commands and subsequent output show events that occur when HQF is enabled or
disabled as a result of queueing changes at the PVC level while debugging is on:
Router(config-if)# map-class frame-relay frts-shape
Router(config-map-class)# frame-relay fragment 80
Router(config-map-class)# service-policy output shape
Router(config-map-class)# interface serial4/1
Router(config-if)# frame-relay interface-dlci 16
Router(config-fr-dlci)# class frts-shape
00:28:54: Serial4/1- Setting up HQF/MQC QOS. <---Indicates that the last legacy
restriction has been removed and that HQF is being installed on the interface.
Router(config-fr-dlci)# no class frts-shape
00:29:02: Serial4/1- Setting up interface for legacy QOS. <--- Indicates that legacy QoS
has been installed on the interface.

show debug Displays active debug output.

May 2008 DB-729
Debug Commands
debug frame-relay informationelements

To display information about Frame Relay Layer 3 (network layer) information element parsing and
construction, use the debug frame-relay informationelements command in privileged EXEC mode. To
no debug frame-relay informationelements
Usage Guidelines Within the FRF.4/Q.933 signalling specification, messages are divided into subunits called information
elements. Each information element defines parameters specific to the call. These parameters can be
values configured on the router, or values requested from the network.
The debug frame-relay informationelements command shows the signalling message in hexadecimal
format. Use this command to determine parameters being requested and granted for a call.
Note Use the debug frame-relay informationelements command when the debug frame-relay callcontrol
command does not explain why calls are not being set up.
Caution The debug frame-relay informationelements command displays a substantial amount of information
in bytes. You must be familiar with FRF.4/Q.933 to decode the information contained within the debug
output.
Examples The following is sample output from the debug frame-relay informationelements command. In this
example, each information element has a length associated with it. For those with odd-numbered lengths,
only the specified bytes are valid, and the extra byte is invalid. For example, in the message Call Ref,
length: 3, 0x0200 0x0100, only 02 00 01 is valid; the last 00 is invalid.
lw0d# debug frame-relay informationelements
Router: Outgoing MSG_SETUP
Router: Dir: U --> N,

Type: Prot Disc, length: 1, 0x0800
Type: Call Ref, length: 3, 0x0200 0x0100
Type: Message type, length: 1, 0x0500
Type: Bearer Capability, length: 5, 0x0403 0x88A0 0xCF00
Type: DLCI, length: 4, 0x1902 0x46A0
Type: Link Lyr Core, length: 27, 0x4819 0x090B 0x5C0B 0xDC0A
Router: 0x3140 0x31C0 0x0B21 0x4021
Router: 0xC00D 0x7518 0x7598 0x0E09
Router: 0x307D 0x8000
Router: Dir: U --> N, Type: Calling Party, length: 12, 0x6C0A 0x1380 0x3837 0x3635

DB-730 May 2008
Debug Commands
Router: 0x3433 0x3231

Router: Dir: U --> N, Type: Calling Party Subaddr, length: 4, 0x6D02 0xA000
Router: Dir: U --> N, Type: Called Party, length: 11, 0x7009 0x9331 0x3233 0x3435
Router: 0x3637 0x386E
Router: Dir: U --> N, Type: Called Party Subaddr, length: 4, 0x7102 0xA000
Router: Dir: U --> N, Type: Low Lyr Comp, length: 5, 0x7C03 0x88A0 0xCE65
Router: Dir: U --> N, Type: User to User, length: 4, 0x7E02 0x0000
Table 99 explains the information elements shown in the example.
Table 99 Information Elements in a Setup Message
Information Element Description

Prot Disc Protocol discriminator.
Call Ref Call reference.
Message type Message type such as setup, connect, and call proceeding.
Bearer Capability Coding format such as data type, and Layer 2 and Layer 3 protocols.
DLCI Data-link connection identifier.
Link Lyr Core Link-layer core quality of service (QoS) requirements.
Calling Party Type of source number (X121/E164) and the number.
Calling Party Subaddr Subaddress that originated the call.
Called Party Type of destination number (X121/E164) and the number.
Called Party Subaddr Subaddress of the called party.
Low Lyr Comp Coding format, data type, and Layer 2 and Layer 3 protocols intended
for the end user.
User to User Information between end users.

debug frame-relay callcontrol Displays Frame Relay Layer 3 (network layer) call control
information.

May 2008 DB-731
Debug Commands
debug frame-relay ip tcp header-compression

To display debugging information about TCP/IP header compression on Frame Relay interfaces, use the
debug frame-relay ip tcp header-compression command in privileged EXEC mode. To disable
no debug frame-relay ip tcp header-compression
Defaults Disabled

12.4(9)T This command was modified to display debugging output for control
protocol frames for Frame Relay Forum Implementation Agreement
(FRF) .20.
12.4(11)T This command was modified to display debugging output for Enhanced
Compressed Real-Time Transport Protocol (ECRTP).
Usage Guidelines The debug frame-relay ip tcp header-compression command shows the control packets that are passed
to initialize IP header compression (IPHC) on a permanent virtual circuit (PVC). For Cisco IPHC,
typically two packets are passed: one sent and one received per PVC. (Inverse Address Resolution
Protocol (InARP) packets are sent on PVCs that do not have a mapping defined between a destination
protocol address and the data-link connection identifier (DLCI) or Frame Relay PVC bundle that
connects to the destination address.) For FRF .20 IPHC, typically four packets are passed per PVC.
Debug messages are displayed only if the IPHC control protocol is renegotiated (for an interface or PVC
state change or for a configuration change).

DB-732 May 2008
Debug Commands
Examples The following is sample output from the debug frame-relay ip tcp header-compression command
when Cisco IPHC (not FRF .20 IPHC) is configured in the IPHC profile:
Router# debug frame-relay ip tcp header-compression
*Nov 14 09:22:07.991: InARP REQ: Tx compr_flags 43 *Nov 14 09:22:08.103: InARP RSP: Rx

compr_flags: 43
The following is sample output from the debug frame-relay ip tcp header-compression command
when FRF .20 IPHC (without either Real-time Transport Protocol (RTP) or ECRTP) is configured in the
IPHC profile:
FRF20(DLCI 16): Rxed Request, state 0

: ident 0, tot len 19, conf_opts FE, len 15
negotiation codes 1, version 1
Par: IPV4, len 12, TCP_SPACE 16, NON_TCP_SPACE 0,
F_MAX_PERIOD 256, F_MAX_TIME 5, MAX_HEADER 168 FRF20(DLCI 16): Txed Ack, state 0
F_MAX_PERIOD 256, F_MAX_TIME 5, MAX_HEADER 168 FRF20(DLCI 16): Txed Request, state
0
F_MAX_PERIOD 256, F_MAX_TIME 5, MAX_HEADER 168 FRF20(DLCI 16): Rxed Ack, state 2
F_MAX_PERIOD 256, F_MAX_TIME 5, MAX_HEADER 168 *Nov 14 09:18:37.019:
FRF20(DLCI 16): STARTING IPHC
when FRF .20 IPHC and RTP are configured in the IPHC profile:
FRF20(DLCI 16): Txed Request, state 1

F_MAX_PERIOD 256, F_MAX_TIME 5, MAX_HEADER 168
01:33:06: Subopt: rtp enabled
when FRF .20 IPHC and ECRTP are configured in the IPHC profile:
FRF20(DLCI 16): Txed Request, state 1

F_MAX_PERIOD 256, F_MAX_TIME 5, MAX_HEADER 168
01:33:06: Subopt: ecrtp enabled

May 2008 DB-733
Debug Commands
Table 100 debug frame-relay ip tcp header-compression Field Descriptions
Field Description
InARP REQ: Tx Indicates that an InARP request was sent or received. Following are the
possible values:
InARP REQ TxAn InARP request was sent.
InARP REQ RxAn InARP request was received.
InARP RSP: Rx Indicates that an InARP response was sent or received. Following are the
possible values:
InARP REQ TxAn InARP response was sent.
InARP REQ RxAn InARP response was received.
compr_flags: 43 Compression flags that Frame Relay peers use to negotiate Cisco IPHC
options. It consists of a bit mask, and the number is displayed in hexadecimal
format. Following are the bits:
0x0001TCP IPHC
0x0002RTP IPHC
0x0004Passive TCP compression
0x0008Passive RTP compression
0x0040Frame Relay IPHC options
FRF20(DLCI 16) Indicates that the DLCI for this packet is configured with FRF .20 IPHC.
Txed Request Direction of the IPHC control protocol message. Following are the possible
values:
Txed Request
Txed Ack
Rxed Request
Rxed Ack
Txed (transmitted) or Rxed (received) indicates the message direction, and
Request or Ack (acknowledgement) indicates the message type.
A peer sends a request indicating its configuration, and the other peer replies
with an acknowledgement indicating its configuration. The lowest
configuration value of this two-frame exchange sets the parameters in one
direction. This means that typically four frames are exchanged in total: two
Request/Ack pairs, with each pair negotiating the parameters in one direction.

DB-734 May 2008
Debug Commands
Table 100 debug frame-relay ip tcp header-compression Field Descriptions (continued)
Field Description
state 1 State of the FRF .20 IPHC protocol request. Following are the possible values:
0FRF20_DISABLED. FRF .20 is disabled (because of an inactive PVC, an
interface that is down, or a configuration mismatch).
1FRF20_REQ_SENT. An FRF .20 control protocol request has been sent.
2FRF20_REQ_RXED. An FRF .20 control protocol request has been
received.
3FRF20_WAIT_REQ. An FRF .20 control protocol request has been sent
and acknowledged, and the local end is waiting for a request from the peer.
4FRF20_OPERATIONAL. The FRF .20 control protocol is successfully
negotiated, and frames can be compressed.
ident 0 Identifier. This is the transaction number used to correlate an FRF .20 control
protocol request with an acknowledgement. This number is the same in
messages that correspond to each other.
tot len 21 Sum (in bytes) of the lengths of the following:
All parameters
Negotiation codes
Identifier
Suboptions for each parameter set (IPV4 or IPV6)
conf_opts FE Type of PPP parameter (expressed in hexadecimal). For FRF .20, the only
possible value is FE (254 in decimal).
len 17 Total length of all parameters (in bytes).
negotiation codes 1 Negotiation state with the peer. Following are the possible values:
0Reply with response only.
1Reply with response and initiate request.
With a response only, sending a response frame completes the negotiation.
With a response and initiate request, the local peer also must send a request.
version 1 Version of the FRF .20 control protocol.
Par List of parameters and values.
IPV4 Datagram type. The value is always IPV4, because Cisco IPHC does not
support IPv6.
len 14 Total length (in bytes) of all parameters starting with IP type and ending with
associated suboptions (if any). The value is greater than or equal to 12
depending on the suboptions.
TCP_SPACE 16 Maximum value of a TCP context identifier (CID) in the space of context
identifiers allocated for TCP. Range: 3255. Default value: 16. A value of zero
means that TCP headers are not being compressed.

May 2008 DB-735
Debug Commands
Table 100 debug frame-relay ip tcp header-compression Field Descriptions (continued)
Field Description
NON_TCP_SPACE 16 Maximum value of a context identifier (CID) in the space of context
identifiers allocated for non-TCP. Range: 31000. Cisco routers do not
support the maximum value (65535) of the FRF .20 specification. Default
value: 16. A value of zero means that non-TCP headers are not being
compressed. These context identifiers are carried in
COMPRESSED_NON_TCP, COMPRESSED_UDP and
COMPRESSED_RTP packet headers.
F_MAX_PERIOD 256 Largest number of compressed non-TCP headers that can be sent without
sending a full header. Range: 165535. Default value: 256. A value of zero
indicates infinity, which means that the number of consecutive
COMPRESSED_NON_TCP headers is unlimited.
F_MAX_TIME 5 Maximum time interval (in seconds) between full (uncompressed) headers.
Range: 1255. Default value: 5. A value of zero indicates infinity (meaning
that no full headers will be transmitted).
MAX_HEADER 168 Largest header size (in bytes) that can be compressed. Range: 60168. Cisco
routers do not support the full range of values (6065535) of the FRF .20
specification. Default value: 168.
01:33:06 Timestamp of the debug command output.
Subopt Compression suboptions that are enabled. The value is either rtp or ecrtp.

DB-736 May 2008
Debug Commands
debug frame-relay lapf

To display Frame Relay switched virtual circuit (SVC) Layer 2 information, use the debug frame-relay
lapf command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
no debug frame-relay lapf
Usage Guidelines Use the debug frame-relay lapf command to troubleshoot the data-link control portion of Layer 2 that
runs over data-link connection identifier (DLCI) 0. Use this command only if you have a problem
bringing up Layer 2. You can use the show interface serial command to determine the status of Layer 2.
If it shows a Link Access Procedure, Frame Relay (LAPF) state of down, Layer 2 has a problem.
Examples The following is sample output from the debug frame-relay lapf command. In this example, a line being
brought up indicates an exchange of set asynchronous balanced mode extended (SABME) and
unnumbered acknowledgment (UA) commands. A SABME is initiated by both sides, and a UA is the
response. Until the SABME gets a UA response, the line is not declared to be up. The p/f value indicates
the poll/final bit setting. TX means send, and RX means receive.
Router# debug frame-relay lapf
Router: *LAPF Serial0 TX -> SABME Cmd p/f=1

Router: *LAPF Serial0 Enter state 5
Router: *LAPF Serial0 RX <- UA Rsp p/f=1
Router: *LAPF Serial0 lapf_ua_5
Router: *LAPF Serial0 Link up!
Router: *LAPF Serial0 RX <- SABME Cmd p/f=1
Router: *LAPF Serial0 lapf_sabme_78
Router: *LAPF Serial0 TX -> UA Rsp p/f=1
In the following example, a line in an up LAPF state should see a steady exchange of RR (receiver ready)
messages. TX means send, RX means receive, and N(R) indicates the receive sequence number.
Router# debug frame-relay lapf
Router: *LAPF Serial0 T203 expired, state = 7

Router: *LAPF Serial0 lapf_rr_7
Router: *LAPF Serial0 TX -> RR Rsp p/f=1, N(R)= 3
Router: *LAPF Serial0 RX <- RR Cmd p/f=1, N(R)= 3
Router: *LAPF Serial0 TX -> RR Rsp p/f=1, N(R)= 3
Router: *LAPF Serial0 RX <- RR Cmd p/f=1, N(R)= 3

May 2008 DB-737
Debug Commands

To display information on the local management interface (LMI) packets exchanged by the router and
the Frame Relay service provider, use the debug frame-relay lmi command in privileged EXEC mode.
debug frame-relay lmi [interface name]
no debug frame-relay lmi [interface name]
Syntax Description interface name (Optional) The name of interface.
Usage Guidelines You can use this command to determine whether the router and the Frame Relay switch are sending and
receiving LMI packets properly.
Note Because the debug frame-relay lmi command does not generate much output, you can use it at any time,
even during periods of heavy traffic, without adversely affecting other users on the system.
Examples The following is sample output from the debug frame-relay lmi command:
router# debug frame-relay lmi
LMI Serial1(out): StEnq, clock 20212760, myseq 206, mineseen 205, yourseen 136, DTE up
exchange Serial1(in): Status, clock 20212764, myseq 206
RT IE 1, length 1, type 1
KA IE 3, length 2, yourseq 138, myseq 206
Serial1(out): StEnq, clock 20222760, myseq 207, mineseen 206, yourseen 138, DTE up
Serial1(in): Status, clock 20222764, myseq 207
Serial1(out): clock 20232760, myseq 208, mineseen 207, yourseen 140, line up
Serial1(out): StEnq, clock 20252760, myseq 210, mineseen 209, yourseen 144, DTE up
Full LMI Serial1(in): Status, clock 20252764,
status RT IE 1, length 1, type 0
message PVC IE 0x7, length 0x6, dlci 400, status 0, bw 56000
S2546
PVC IE 0x7, length 0x6, dlci 401, status 0, bw 56000
The first four lines describe an LMI exchange. The first line describes the LMI request the router has
sent to the switch. The second line describes the LMI reply the router has received from the switch. The
third and fourth lines describe the response to this request from the switch. This LMI exchange is
followed by two similar LMI exchanges. The last six lines consist of a full LMI status message that
includes a description of the two permanent virtual circuits (PVCs) of the router.

DB-738 May 2008
Debug Commands
Table 101 describes the significant fields shown in the first line of the display.
Table 101 debug frame-relay lmi Field Descriptions
Field Description
Serial1(out) Indicates that the LMI request was sent out on serial interface 1.
StEnq Command mode of message, as follows:
StEnqStatus inquiry
StatusStatus reply
clock 20212760 System clock (in milliseconds). Useful for determining whether an appropriate
amount of time has transpired between events.
myseq 206 Myseq counter maps to the CURRENT SEQ counter of the router.
yourseen 136 Yourseen counter maps to the LAST RCVD SEQ counter of the switch.
DTE up Line protocol up/down state for the DTE (user) port.
Table 102 describes the significant fields shown in the third and fourth lines of the display.
Field Description
RT IE 1 Value of the report type information element.
length 1 Length of the report type information element (in bytes).
type 1 Report type in RT IE.
KA IE 3 Value of the keepalive information element.
length 2 Length of the keepalive information element (in bytes).
yourseq 138 Yourseq counter maps to the CURRENT SEQ counter of the switch.
myseq 206 Myseq counter maps to the CURRENT SEQ counter of the router.
Table 103 describes the significant fields shown in the last line of the display.
Field Description
PVC IE 0x7 Value of the PVC information element type.
length 0x6 Length of the PVC IE (in bytes).

May 2008 DB-739
Debug Commands
Table 103 debug frame-relay lmi Field Descriptions (continued)
Field Description
dlci 401 DLCI decimal value for this PVC.
status 0 Status value. Possible values include the following:
0x00Added/inactive
0x02Added/active
0x04Deleted
0x08New/inactive
0x0aNew/active
bw 56000 Committed information rate (in decimal) for the DLCI.

DB-740 May 2008
Debug Commands
debug frame-relay multilink

To display debug messages for multilink Frame Relay bundles and bundle links, use the debug
frame-relay multilink command in privileged EXEC mode. To disable debugging output, use the no
debug frame-relay multilink [control [mfr number | serial number]]
no debug frame-relay multilink
Syntax Description control (Optional) Displays incoming and outgoing bundle link control messages
and bundle link status changes.
mfr number (Optional) Displays information for a specific bundle interface.
serial number (Optional) Displays information for a specific bundle link interface.

12.0(24)S This command was introduced on VIP-enabled Cisco 7500 series routers.
Usage Guidelines Caution Using the debug frame-relay multilink command without the control keyword could
severely impact router performance and is not recommended.
Using the debug frame-relay multilink command without the mfr or serial keywords displays error
conditions that occur at the bundle layer.
Examples The following example shows output from the debug frame-relay multilink command for bundle
MFR0, which has three bundle links:
Router# debug frame-relay multilink control MFR0
00:42:54:Serial5/3(o):msg=Add_link, Link=Serial5/3, Bundle=MFR0, Link id=Serial5/3,

BL state=Idle
E1 00 01 01 07 4D 46 52 30 00

May 2008 DB-741
Debug Commands

BL state=Idle
E1 00 01 01 07 4D 46 52 30 00
BL state=Idle
E1 00 01 01 07 4D 46 52 30 00
00:42:54:%LINK-3-UPDOWN:Interface MFR0, changed state to down
00:42:54:Serial5/3(i):msg=Add_link_ack, Link=Serial5/3, Bundle=MFR0, Link id=Serial5/3,
BL state=Add_sent
E1 00 02 01 07 4D 46 52 30 00
BL state=Add_sent
E1 00 02 01 07 4D 46 52 30 00
BL state=Add_sent
E1 00 02 01 07 4D 46 52 30 00
00:43:00:Serial5/1(i):msg=Add_link, Link=Serial5/1, Bundle=MFR0, Link id=Serial5/1,
BL state=Ack_rx
E1 00 01 01 07 4D 46 52 30 00
00:43:00:Serial5/1(o):msg=Add_link_ack, Link=Serial5/1, Bundle=MFR0, Link id=Serial5/1,
BL state=Ack_rx
E1 00 02 01 07 4D 46 52 30 00
00:43:00:%LINK-3-UPDOWN:Interface MFR0, changed state to up
00:43:00:Serial5/1(i):msg=Hello, Link=Serial5/1, Bundle=MFR0, Linkid=Serial5/1, BL
state=Up
E1 00 04 03 06 30 A7 E0 54 00
00:43:00:Serial5/1(o):msg=Hello_ack, Link=Serial5/1, Bundle=MFR0, Link id=Serial5/1, BL
state=Up
E1 00 05 03 06 90 E7 0F C2 06
BL state=Ack_rx
E1 00 01 01 07 4D 46 52 30 00
BL state=Ack_rx
E1 00 02 01 07 4D 46 52 30 00
state=Up
E1 00 04 03 06 30 A7 E0 54 00
00:43:01:Serial5/2(o):msg=Hello_ack, Link=Serial5/2, Bundle=MFR0, Link id=Serial5/2,
BL state=Up
E1 00 05 03 06 90 E7 0F C2 06
00:43:01:%LINEPROTO-5-UPDOWN:Line protocol on Interface Serial5/1, changed state to up
BL state=Ack_rx
E1 00 01 01 07 4D 46 52 30 00
BL state=Ack_rx
E1 00 02 01 07 4D 46 52 30 00
state=Up
E1 00 04 03 06 30 A7 E0 54 00
00:43:01:Serial5/3(o):msg=Hello_ack, Link=Serial5/3, Bundle=MFR0, Link id=Serial5/3,
BL state=Up
E1 00 05 03 06 90 E7 0F C2 06
00:43:02:%LINEPROTO-5-UPDOWN:Line protocol on Interface Serial5/2 , changed state to up
00:43:02:%LINEPROTO-5-UPDOWN:Line protocol on Interface Serial5/3 , changed state to up

DB-742 May 2008
Debug Commands
Table 104 debug frame-relay multilink Field Descriptions
Field Description
msg Type of bundle link control message that was sent or received.
Link Interface number of the bundle link.
Bundle Bundle with which the link is associated.
Link id Bundle link identification name.
BL state Operational state of the bundle link.

show frame-relay multilink Displays configuration information and statistics about multilink
Frame Relay bundles and bundle links.

May 2008 DB-743
Debug Commands
debug frame-relay networklayerinterface

To display Network Layer Interface (NLI) information, use the debug frame-relay
networklayerinterface command in privileged EXEC mode. To disable debugging output, use the no
no debug frame-relay networklayerinterface
Usage Guidelines The Frame Relay switched virtual circuit (SVC) signaling subsystem is decoupled from the rest of the
router code by means of the NLI intermediate software layer.
The debug frame-relay networklayerinterface command shows activity within the network-layer
interface when a call is set up or torn down. All output that contains an NL relates to the interaction
between the Q.933 signaling subsystem and the NLI.
Note The debug frame-relay networklayerinterface command has no significance to anyone not familiar
with the inner workings of the Cisco IOS software. This command is typically used by service personnel
to debug problem situations.
Examples The following is sample output from the debug frame-relay networklayerinterface command. This
example displays the output generated when a call is set up. The second example shows the output
generated when a call is torn down.
Router# debug frame-relay networklayerinterface
Router: NLI STATE: L3_CALL_REQ, Call ID 1 state 0

Router: NLI: Walking the event table 1
Router: NLI: NL0_L3CallReq
Router: NLI: State: STATE_NL_NULL, Event: L3_CALL_REQ, Next: STATE_L3_CALL_REQ
Router: NLI: Enqueued outgoing packet on holdq
Router: NLI: Map-list search: Found maplist bermuda
Router: daddr.subaddr 0, saddr.subaddr 0, saddr.subaddr 0
Router: saddr.subaddr 0, daddr.subaddr 0, daddr.subaddr 0
Router: nli_parameter_negotiation
Router: NLI STATE: NL_CALL_CNF, Call ID 1 state 10

DB-744 May 2008
Debug Commands

Router: NLI: NLx_CallCnf
Router: NLI: State: STATE_L3_CALL_REQ, Event: NL_CALL_CNF, Next: STATE_NL_CALL_CNF
Router: Checking maplist junk
Router: working with maplist bermuda
Router: Checking maplist bermuda
Router: working with maplist bermuda
Router: NLI: Emptying holdQ, link 7, dlci 100, size 104
Router# debug frame-relay networklayerinterface
Router: NLI: L3 Call Release Req for Call ID 1

Router: NLI STATE: L3_CALL_REL_REQ, Call ID 1 state 3
Router: NLI: NLx_L3CallRej
Router: NLI: State: STATE_NL_CALL_CNF, Event: L3_CALL_REL_REQ, Next: STATE_L3_CALL_REL_REQ
Router: NLI: junk: State: STATE_NL_NULL, Event: L3_CALL_REL_REQ, Next: STATE_NL_NULL
Router: NLI: Map-list search: Found maplist junk
Router: daddr.subaddr 0, saddr.subaddr 0, saddr.subaddr 0
Router: saddr.subaddr 0, daddr.subaddr 0, daddr.subaddr 0
Router: nli_parameter_negotiation
Router: NLI STATE: NL_REL_CNF, Call ID 1 state 0
Router: NLI: NLx_RelCnf
Router: NLI: State: STATE_NL_NULL, Event: NL_REL_CNF, Next: STATE_NL_NULL
Table 105 describes the significant states and events shown in the display.
Table 105 NLI State and Event Descriptions
State and Event Description

L3_CALL_REQ Internal call setup request. Network layer indicates that an SVC is
required.
STATE_NL_NULL Call in initial stateno call exists.
STATE_L3_CALL_REQ Setup message sent out and waiting for a reply. This is the state the
network-layer state machine changes to when a call request is
received from Layer 3 but no confirmation has been received from
the network.
NL_CALL_CNF Message sent from the Q.933 signalling subsystem to the NLI
asking that internal resources be allocated for the call.

May 2008 DB-745
Debug Commands
Table 105 NLI State and Event Descriptions (continued)
State and Event Description

STATE_L3_CALL_CNF Q.933 state indicating that the call is active. After the network
confirms a call request using a connect message, the Q.933 state
machine changes to this state.
STATE_NL_CALL_CNF Internal software state indicating that software resources are
assigned and the call is up. After Q.933 changes to the
STATE_L3_CALL_CNF state, it sends an NL_CALL_CNF
message to the network-layer state machine, which then changes to
the STATE_NL_CALL_CNF state.
L3_CALL_REL_REQ Internal request to release the call.
STATE_L3_CALL_REL_REQ Internal software state indicating the call is in the process of being
released. At this point, the Q.933 subsystem is told that the call is
being released and a disconnect message goes out for the Q.933
subsystem.
NL_REL_CNF Indication from the Q.933 signalling subsystem that the signalling
subsystem is releasing the call. After receiving a release complete
message from the network indicating that the release process is
complete, the Q.933 subsystem sends an NL_REL_CNF event to
the network-layer subsystem.

debug frame-relay callcontrol Displays Frame Relay Layer 3 (network layer) call control
information.

DB-746 May 2008
Debug Commands

To display information on packets that have been sent on a Frame Relay interface, use the debug
frame-relay packet command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug frame-relay packet [interface name [dlci value]]
no debug frame-relay packet [interface name [dlci value]]
Syntax Description interface name (Optional) Name of interface or subinterface.

dlci value (Optional) Data-link connection indentifier (DLCI) decimal value.
Usage Guidelines This command helps you analyze the packets that are sent on a Frame Relay interface. Because the
debug frame-relay packet command generates a substantial amount of output, only use it when traffic
on the Frame Relay network is fewer than 25 packets per second. Use the options to limit the debugging
output to a specific DLCI or interface.
To analyze the packets received on a Frame Relay interface, use the debug frame-relay command.
Examples The following is sample output from the debug frame-relay packet command:
router# debug frame-relay packets
Serial0: broadcast = 1, link 809B, addr 65535.255

Serial0(o):DLCI 500 type 809B size 24
Groups of Serial0: broadcast - 0, link 809B, addr 10.2
output lines Serial0(o):DLCI 100 type 809B size 104
Serial0: broadcast search
S2547
The debug frame-relay packet output consists of groups of output lines; each group describes a Frame
Relay packet that has been sent. The number of lines in the group can vary, depending on the number of
DLCIs on which the packet was sent. For example, the first two pairs of output lines describe two
different packets, both of which were sent out on a single DLCI. The last three lines describe a single
Frame Relay packet that was sent out on two DLCIs.

May 2008 DB-747
Debug Commands
Table 106 debug frame-relay packet Field Descriptions
Field Description
Serial0: Interface that has sent the Frame Relay packet.
broadcast = 1 Destination of the packet. Possible values include the following:
broadcast = 1Broadcast address
broadcast = 0Particular destination
broadcast searchSearches all Frame Relay map entries for this particular
protocol that include the broadcast keyword.
link 809B Link type, as documented in the debug frame-relay command.
addr 65535.255 Destination protocol address for this packet. In this case, it is an AppleTalk
address.
Serial0(o): (o) indicates that this is an output event.
DLCI 500 Decimal value of the DLCI.
type 809B Packet type, as documented under the debug frame-relay command.
size 24 Size of this packet (in bytes).
The following lines describe a Frame Relay packet sent to a particular address; in this case AppleTalk
address 10.2:
Serial0: broadcast - 0, link 809B, addr 10.2
The following lines describe a Frame Relay packet that went out on two different DLCIs, because two
Frame Relay map entries were found:
The following lines do not appear. They describe a Frame Relay packet sent to a true broadcast address.
Serial1(o):DLCI 400 type 800 size 288

DB-748 May 2008
Debug Commands
debug frame-relay ppp

To display debugging information, use the debug frame-relay ppp command in privileged EXEC mode.
no debug frame-relay ppp
Usage Guidelines This command displays error messages for link states and Local Management Interface (LMI) status
changes for PPP over Frame Relay sessions.
To debug process-switched packets, use the debug frame-relay packet or debug ppp packet
commands. To analyze the packets that have been sent on a Frame Relay interface, use the debug
frame-relay packet command.
The debug frame-relay ppp command is generated from process-level switching only and is not CPU
intensive.
Examples The following shows output from the debug frame-relay ppp command where the encapsulation failed
for VC 100.
Router# debug frame-relay ppp
FR-PPP: encaps failed for FR VC 100 on Serial0 down

FR-PPP: input- Serial0 vc or va down, pak dropped
The following shows the output from the debug frame relay ppp and debug frame-relay packet
commands. This example shows a virtual interface (virtual interface 1) establishing a PPP connection
over PPP.
Vi1 LCP: O CONFREQ [Closed] id 1 len 10

Vi1 LCP: MagicNumber 0xE0638565 (0x0506E0638565)
Serial2/1(o): dlci 201(0x3091), NLPID 0x3CF(PPP), datagramsize 16
Vi1 PPP: I pkt type 0xC021, datagramsize 14
Vi1 LCP: I CONFACK [REQsent] id 1 len 10
Vi1 LCP: MagicNumber 0xE0638565 (0x0506E0638565)
Vi1 LCP: I CONFREQ [ACKrcvd] id 6 len 10
Vi1 LCP: MagicNumber 0x000EAD99 (0x0506000EAD99)
Vi1 LCP: O CONFACK [ACKrcvd] id 6 len 10
Vi1 LCP: MagicNumber 0x000EAD99 (0x0506000EAD99)
Vi1 IPCP: O CONFREQ [Closed] id 1 len 10
Vi1 IPCP: Address 170.100.9.10 (0x0306AA64090A)

May 2008 DB-749
Debug Commands

Vi1 PPP: I pkt type 0x8021, datagramsize 14
Vi1 IPCP: I CONFREQ [REQsent] id 1 len 10
Vi1 IPCP: Address 170.100.9.20 (0x0306AA640914)
Vi1 IPCP: O CONFACK [REQsent] id 1 len 10
Vi1 IPCP: Address 170.100.9.20 (0x0306AA640914)
Vi1 PPP: I pkt type 0x8021, datagramsize 14
Vi1 IPCP: I CONFACK [ACKsent] id 1 len 10
Vi1 IPCP: Address 170.100.9.10 (0x0306AA64090A)
Vi1 LCP: I ECHOREQ [Open] id 1 len 12 magic 0x000EAD99
Vi1 LCP: O ECHOREP [Open] id 1 len 12 magic 0xE0638565
Vi1 LCP: O ECHOREQ [Open] id 1 len 12 magic 0xE0638565
Vi1 LCP: echo_cnt 4, sent id 1, line up
The following shows the output for the debug frame-relay ppp and debug frame-relay packet
commands that report a failed PPP over Frame Relay session. The problem is due to a challenge
handshake authentication protocol (CHAP) failure.
Vi1 LCP: O CONFREQ [Listen] id 24 len 10

Vi1 LCP: MagicNumber 0xE068EC78 (0x0506E068EC78)
Vi1 LCP: I CONFREQ [REQsent] id 18 len 15
Vi1 LCP: AuthProto CHAP (0x0305C22305)
Vi1 LCP: MagicNumber 0x0014387E (0x05060014387E)
Vi1 LCP: O CONFACK [REQsent] id 18 len 15
Vi1 LCP: AuthProto CHAP (0x0305C22305)
Vi1 LCP: MagicNumber 0x0014387E (0x05060014387E)
Vi1 LCP: I CONFACK [ACKsent] id 24 len 10
Vi1 LCP: MagicNumber 0xE068EC78 (0x0506E068EC78)
Vi1 CHAP: I CHALLENGE id 12 len 28 from "krishna"
Vi1 LCP: O TERMREQ [Open] id 25 len 4
Vi1 LCP: I TERMACK [TERMsent] id 25 len 4
Serial2/1(i): dlci 201(0x3091), pkt type 0x2000, datagramsize 303
Vi1 LCP: TIMEout: Time 0x199580 State Listen

DB-750 May 2008
Debug Commands

To display events and error conditions that occur when binding a Frame Relay data-link connection
identifier (DLCI) to a pseudowire, use the debug frame-relay pseudowire command in privileged
EXEC mode. To disable the display of these events and error conditions, use the no form of this
command.
no debug frame-relay pseudowire
Syntax Description This command contains no arguments or keywords.
Defaults DLCI events and errors are not displayed.

Usage Guidelines The following are examples of Frame Relay pseudowire events:
Command-line interface (CLI) provisioning events
Pseudowire circuit status updates
Failures occurring during the management of these events
Examples The following example enables the display of Frame Relay pseudowire events. In this example, the
interface has been shut down and then enabled.
Router# debug frame-relay pseudowire
Router(config)# interface hssi1/0/0
Router(config-if)# shutdown
09:18:33.303: FRoPW [10.15.15.15, 100]: acmgr_circuit_down

09:18:33.303: FRoPW [10.15.15.15, 100]: SW AC update circuit state to down
09:18:33.303: FRoPW [10.15.15.15, 100]: Setting connection DOWN
09:18:35.299: %LINK-5-CHANGED: Interface Hssi1/0/0, changed state to administratively down

May 2008 DB-751
Debug Commands
09:18:36.299: %LINEPROTO-5-UPDOWN: Line protocol on Interface Hssi1/0/0, changed state to

down
Router(config-if)# no shutdown
09:18:41.919: %LINK-3-UPDOWN: Interface Hssi1/0/0, changed state to up

09:18:41.919: FRoPW [10.15.15.15, 100]: Local up, sending acmgr_circuit_up
09:18:41.919: FRoPW [10.15.15.15, 100]: Setting pw segment UP
09:18:41.919: FRoPW [10.15.15.15, 100]: PW nni_pvc_status set ACTIVE
09:18:41.919: label_oce_get_label_bundle: flags 14 label 28
09:18:42.919: %LINEPROTO-5-UPDOWN: Line protocol on Interface Hssi1/0/0, changed state to
up
Table 107 debug frame-relay pseudowire Field Descriptions
Field Description
Time (09.18.41) When the event occurred (in hours, minutes, and seconds).
[10.15.15.15, 100] 10.15.15.15 is the IP address of the peer provider edge (PE) router.
100 is the DLCI number of the Frame Relay permanent virtual circuit (PVC)
used for this pseudowire.

DB-752 May 2008
Debug Commands
debug frame-relay redundancy

To debug Frame Relay and Multilink Frame Relay redundancy on the networking device, use the debug
frame-relay redundancy command in privileged EXEC mode. To disable the display of debugging
no debug frame-relay redundancy

12.0(22)S This command was introduced on the Cisco 7500 series and Cisco 10000
series Internet routers.
12.0(28)S SSO support was added to the Multilink Frame Relay feature on the
Cisco 12000 series Internet router.
12.2(25)S SSO support was added to the Multilink Frame Relay feature on the
Cisco 12000 series Internet router.
Usage Guidelines Use this command to debug Frame Relay synchronization problems. The debug frame-relay
redundancy command logs synchronization events and errors.
Examples The following example displays debug messages regarding Frame Relay redundancy on the networking
device:
Router# debug frame-relay redundancy

May 2008 DB-753
Debug Commands

frame-relay Configures LMI synchronization parameters.
redundancy auto-sync
lmi-sequence-numbers

DB-754 May 2008
Debug Commands
debug frame-relay switching

To display debugging messages for switched Frame Relay permanent virtual circuits (PVCs), use the
debug frame-relay switching command in privileged EXEC mode. To disable debugging output, use
debug frame-relay switching interface interface dlci [interval interval]
no debug frame-relay switching
Syntax Description interface interface The name of the Frame Relay interface.
dlci The DLCI number of the switched PVC to be debugged.
interval interval (Optional) Interval in seconds at which debugging messages will be
updated.
Defaults The default interval is 1 second.

Usage Guidelines The debug frame-relay switching command can be used only on switched Frame Relay PVCs, not
terminated PVCs.
Debug statistics are displayed only if they have changed.
Note Although statistics are displayed at configured intervals, there may be a delay between the occurrence
of a debug event (such as a packet drop) and the display of that event. The delay may be as much as the
configured interval plus 10 seconds.

May 2008 DB-755
Debug Commands
Examples The following is sample output from the debug frame-relay switching command:
Router# debug frame-relay switching interface s2/1 1000 interval 2
Frame Relay switching debugging is on

Display frame switching debug on interface Serial2/1 dlci 1000
1d02h: Serial2/1 dlci 1000: 32 packets switched to Serial2/0 dlci 1002
1d02h: Serial2/1 dlci 1000: 1800 packets output
1d02h: Serial2/1 dlci 1000: 4 packets dropped - outgoing PVC inactive
1d02h: Serial2/1 dlci 1000: Incoming PVC status changed to ACTIVE
1d02h: Serial2/1 dlci 1000: Outgoing PVC status changed to ACTIVE
1d02h: Serial2/1 dlci 1000: Incoming interface hardware module state changed to UP
1d02h: Serial2/1 dlci 1000: Outgoing interface hardware module state changed to UP

DB-756 May 2008
Debug Commands
debug frame-relay vc-bundle

To display information about the Frame Relay permanent virtual circuit (PVC) bundles that are
configured on a router, use the debug frame-relay vc-bundle command in privileged EXEC mode. To
stop the display, use the no form of this command.
debug frame-relay vc-bundle {detail | state-change} [vc-bundle-name]
no debug frame-relay vc-bundle {detail | state-change} [vc-bundle-name]
Syntax Description detail Displays detailed information about the members of the bundle specified by
vc-bundle-name. Displays detailed information about the members of all
PVC bundles if vc-bundle-name is not specified.
state-change Displays information pertaining only to the state changes of the PVC bundle
and PVC bundle members specified by vc-bundle-name. Displays
state-change information for all PVC bundles and bundle members if
vc-bundle-name is not specified.
vc-bundle-name (Optional) Specifies a particular PVC bundle.

Usage Guidelines Use this command to monitor state changes and Inverse ARP activity for one or all of the PVC bundles
and bundle members configured on a router.
Note Debugging messages that are prefixed with FR_VCB (instead of FR-VCB) indicate serious failures
in the Frame Relay PVC bundle performance. Contact the Cisco Technical Assistance Center (TAC) if
you see debugging messages with this prefix.
Examples The following is sample output from the debug frame-relay vc-bundle command that shows Inverse
ARP information for the PVC bundle. PVC bundle member 406 is the only PVC in the bundle to handle
Inverse ARP packets. The Inverse ARP packets coming in on other bundle member PVCs are dropped.
Router# debug frame-relay vc-bundle
00:23:48:FR-VCB:MP-4-dynamic:inarp received on elected member 406

00:23:48:FR-VCB:MP-4-dynamic:installing dynamic map
00:23:48:FR-VCB:MP-4-dynamic:dropping inarp received on member 407

May 2008 DB-757
Debug Commands
00:23:52:FR-VCB:MP-4-dynamic:sending inarp pkt on member 406
In the following example the PVC bundle goes down because the protected group goes down. All
information about active transmission on each PVC is removed.
00:58:27:FR-VCB:MP-4-dynamic:member 402 state changed to DOWN
00:58:27:FR-VCB:MP-4-dynamic:protected group is DOWN
00:58:27:FR-VCB:MP-4-dynamic:state changed to DOWN
00:58:27:FR-VCB:MP-4-dynamic:active table reset
The following is sample output from the debug frame-relay vc-bundle detail command. State change
and Inverse ARP activity is displayed for all PVC bundles and bundle members on the router.
Router# debug frame-relay adjacency vc-bundle detail
00:33:40: FR-VCB: MP-4-dynamic: member 404 state changed to UP

00:33:40: FR-VCB: MP-4-dynamic: active table update
00:33:40: FR-VCB: MP-3-static: sending inarp pkt on member 300
00:33:41: FR-VCB: MP-3-static: inarp received on elected member 300
00:33:48: FR-VCB: MP-3-static: inarp received on elected member 300
00:33:48: FR-VCB: MAIN-1-static: dropping inarp received on member 100
00:33:48: FR-VCB: MP-4-dynamic: dropping inarp received on member 404
00:33:48: FR-VCB: MP-4-dynamic: dropping inarp received on member 405
00:33:48: FR-VCB: P2P-5: dropping inarp received on member 507
00:33:48: FR-VCB: MP-3-static: dropping inarp received on member 303
00:33:48: FR-VCB: MAIN-2-dynamic: dropping inarp received on member 202
00:33:48: FR-VCB: MP-3-static: dropping inarp received on member 305

debug frame-relay adjacency Displays information pertaining to an adjacent node that has one
or more Frame Relay PVC bundles.

DB-758 May 2008
Debug Commands
debug frame-relay virtual
debug frame-relay virtual

To display debugging messages for the virtual Frame Relay interface, use the debug frame-relay virtual
debug frame-relay virtual destination interface
Syntax Description destination interface Enables the debugging messages for that specific interface.

Usage Guidelines Use the debug frame-relay virtual command to display debugging messages for the virtual Frame
Relay interface. The debug frame-relay virtual command produces output only when problems occur.
Examples The following example shows the output if one of the routers has not been configured. This output occurs
when the other end is trying to send the receiving box Frame Relay packets.
VFR: Radio1/0 has no VFR for 00:00:C068:6F:AA

frame-relay over radio Links the virtual Frame Relay interface to the specified radio
interface and destination MAC address.
interface virtual-framerelay Defines the virtual interface and then associates the interface with a
specific wireless connection.
show virtual-framerelay Shows the output of the interface virtual-frame relay command.

May 2008 DB-759
Debug Commands
debug frame-relay
debug frame-relay
To display debugging information about the packets received on a Frame Relay interface, use the debug
frame-relay command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug frame-relay
no debug frame-relay

12.2(13)T Support for Banyan VINES was removed.
Usage Guidelines This command helps you analyze the packets that have been received. However, because the debug
frame-relay command generates a substantial amount of output, use it only when the rate of traffic on
the Frame Relay network is less than 25 packets per second.
To analyze the packets that have been sent on a Frame Relay interface, use the debug frame-relay
packet command.
Examples The following is sample output from the debug frame-relay command:
Router# debug frame-relay
Serial0(i): dlci 500(0x7C41), pkt type 0x809B, datagramsize 24

Serial1(i): dlci 1023(0xFCF1), pkt type 0x309, datagramsize 13
Serial1(i): dlci 1023(0xFCF1), pkt type 0x309, datagramsize 13

DB-760 May 2008
Debug Commands
debug frame-relay
Table 108 debug frame-relay Field Descriptions
Field Description
Serial0(i): Indicates that serial interface 0 has received this Frame Relay datagram
as input.
dlci 500(0x7C41) Indicates the value of the data-link connection identifier (DLCI) for
this packet in decimal (and q922). In this case, 500 has been configured
as the multicast DLCI.

May 2008 DB-761
Debug Commands
debug frame-relay
Table 108 debug frame-relay Field Descriptions (continued)
Field Description
pkt type 0x809B Indicates the packet type code.
Possible supported signalling message codes are as follows:
0x308Signalling message; valid only with a DLCI of 0
0x309LMI message; valid only with a DLCI of 1023
Possible supported Ethernet type codes are:
0x0201IP on a 3 MB net
0x0201Xerox ARP on 10 MB networks
0xCCRFC 1294 (only for IP)
0x0600XNS
0x0800IP on a 10 MB network
0x0806IP ARP
0x0808Frame Relay Address Resolution Protocol (ARP)
Possible High-Level Data Link Control (HDLC) type codes are as
follows:
0x6001DEC Maintenance Operation Protocol (MOP) booting
protocol
0x6002DEC MOP console protocol
0x6003DECnet Phase IV on Ethernet
0x6004DEC LAT on Ethernet
0x8005HP Probe
0x8035RARP
0x8038DEC spanning tree
0x809bApple EtherTalk
0x80f3AppleTalk ARP
0x8019Apollo domain
0x8137Internetwork Packet Exchange (IPX)
0x9000Ethernet loopback packet IP
0x1A58IPX, standard form
0xFEFEConnectionless Network Service (CLNS)
0xEFEFEnd System-to-Intermediate System (ES-IS)
0x1998Uncompressed TCP
0x1999Compressed TCP
0x6558Serial line bridging
datagramsize 24 Indicates size of this datagram (in bytes).

DB-762 May 2008
Debug Commands
debug fras error
debug fras error

To display information about Frame Relay access support (FRAS) protocol errors, use the debug fras
command.
debug fras error
no debug fras error
Usage Guidelines For complete information on the FRAS process, use the debug fras message along with the debug fras
error command.
Examples The following is sample output from the debug fras error command. This example shows that no logical
connection exists between the local station and remote station in the current setup.
Router# debug fras error
FRAS: No route, lmac 1000.5acc.7fb1 rmac 4fff.0000.0000, lSap=0x4, rSap=0x4

FRAS: Can not find the Setup

debug cls message Displays information about CLS messages.

May 2008 DB-763
Debug Commands
debug fras message
debug fras message

To display general information about Frame Relay access support (FRAS) messages, use the debug fras
message command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug fras message
no debug fras message
Usage Guidelines For complete information on the FRAS process, use the debug fras error command along with the
debug fras message command.
Examples The following is sample output from the debug fras message command. This example shows incoming
Cisco Link Services (CLS) primitives.
Router# debug fras message
FRAS: receive 4C23

FRAS: receive CC09

debug cls message Limits output for some debugging commands based on the interfaces.

DB-764 May 2008
Debug Commands
debug fras state
debug fras state

To display information about Frame Relay access support (FRAS) data-link control link-state changes,
use the debug fras state command in privileged EXEC mode. To disable debugging output, use the no
debug fras state
no debug fras state
Examples The following is sample output from the debug fras state command. This example shows the state
changing from a request open station is sent state to an exchange XID state.
Possible states are the following: reset, request open station is sent, exchange xid, connection request is
sent, signal station wait, connection response wait, connection response sent, connection established,
disconnect wait, and number of link states.
Router# debug fras state
FRAS: TR0 (04/04) oldstate=LS_RQOPNSTNSENT, input=RQ_OPNSTN_CNF

FRAS: newstate=LS_EXCHGXID

debug cls message Limits output for some debug commands based on the interfaces.

May 2008 DB-765
Debug Commands
debug fras-host activation

To display the Logical Link Control, Type 2 (LLC2) session activation and deactivation frames (such as
XID, SABME, DISC, UA) that are being handled by the Frame Relay access support (FRAS) host, use
the debug fras-host activation command in privileged EXEC mode. To disable debugging output, use
no debug fras-host activation
Usage Guidelines If many LLC2 sessions are being activated or deactivated at any time, this command may generate a
substantial amount of output to the console.
Examples The following is sample output from the debug fras-host activation command:
Router# debug fras-host activation
FRHOST: Snd TST C to HOST, DA = 4001.3745.1088 SA = 400f.dddd.001e DSAP = 0x00 SSAP =

0x04
FRHOST: Fwd BNN XID to HOST, DA = 4001.3745.1088 SA = 400f.dddd.001e DSAP = 0x04 SSAP =
0x04
FRHOST: Fwd HOST XID to BNN, DA = 400f.dddd.001e SA = 4001.3745.1088 DSAP = 0x04 SSAP =
0x05
0x04
FRHOST: Fwd HOST SABME to BNN, DA = 400f.dddd.001e SA = 4001.3745.1088 DSAP = 0x04 SSAP =
0x04
FRHOST: Fwd BNN UA to HOST, DA = 4001.3745.1088 SA = 400f.dddd.001e DSAP = 0x04 SSAP =
0x05
The first line indicates that the FRAS Host sent a TEST Command to the host. In the second line, the
FRAS Host forwards an XID frame from a BNN device to the host. In the third line, the FRAS Host
forwards an XID from the host to the BNN device.
Table 109 debug fras-host activation Field Descriptions
Field Description
DA Destination MAC address of the frame.
SA Source MAC address of the frame.
DSAP Destination SAP of the frame.
SSAP Source SAP of the frame.

DB-766 May 2008
Debug Commands
debug fras-host error

To enable the Frame Relay access support (FRAS) Host to send error messages to the console, use the
debug fras-host error command in privileged EXEC mode. To disable debugging output, use the no
no debug fras-host error
Examples The following is sample output from the debug fras-host error command when the I-field in a TEST
Response frame from a host does not match the I-field of the TEST Command sent by the FRAS Host:
Router# debug fras-host error
FRHOST: SRB TST R Protocol Violation - LLC I-field not maintained.

May 2008 DB-767
Debug Commands
debug fras-host packet

To see which Logical Link Control, type 2 (LLC2) session frames are being handled by the Frame Relay
access support (FRAS) Host, use the debug fras-host packet command in privileged EXEC mode. To
no debug fras-host packet
Usage Guidelines
Caution Use this command with great care. If many LLC2 sessions are active and passing data, this command
may generate a substantial amount of output to the console and impact device performance.
Examples The following is sample output from the debug fras-host packet command:
Router# debug fras-host packet
FRHOST: Snd TST C to HOST, DA = 4001.3745.1088 SA = 400f.dddd.001e DSAP = 0x00 SSAP =

0x04
0x04
FRHOST: Fwd HOST XID to BNN, DA = 400f.dddd.001e SA = 4001.3745.1088 DSAP = 0x04 SSAP =
0x05
0x04
FRHOST: Fwd HOST SABME to BNN, DA = 400f.dddd.001e SA = 4001.3745.1088 DSAP = 0x04 SSAP =
0x04
FRHOST: Fwd BNN UA to HOST, DA = 4001.3745.1088 SA = 400f.dddd.001e DSAP = 0x04 SSAP =
0x05
FRHOST: Fwd HOST LLC-2 to BNN, DA = 400f.dddd.001e SA = 4001.3745.1088 DSAP = 0x04 SSAP =
0x04
FRHOST: Fwd BNN LLC-2 to HOST, DA = 4001.3745.1088 SA = 400f.dddd.001e DSAP = 0x04 SSAP =
0x05
FRHOST: Fwd HOST LLC-2 to BNN, DA = 400f.dddd.001e SA = 4001.3745.1088 DSAP = 0x04 SSAP =
0x04
FRHOST: Fwd BNN LLC-2 to HOST, DA = 4001.3745.1088 SA = 400f.dddd.001e DSAP = 0x04 SSAP =
0x04
The debug fras-host packet output contains all of the output from the debug fras-host activation
command and additional information. The first six lines of this sample display are the same as the output
from the debug fras-host activation command. The last lines show LLC-2 frames being sent between
the Frame Relay Boundary Network Node (BNN) device and the host.

DB-768 May 2008
Debug Commands
Table 110 debug fras-host packet Field Descriptions
Field Description
DA Destination MAC address of the frame.
SA Source MAC address of the frame.
DSAP Destination service access point (SAP) of the frame.
SSAP Source SAP of the frame.

May 2008 DB-769
Debug Commands
debug fras-host snmp

To display messages to the console describing Simple Network Management Protocol (SNMP) requests
to the Frame Relay access support (FRAS) Host MIB, use the debug fras-host snmp command in
no debug fras-host snmp
Usage Guidelines Use of this command may result in a substantial amount of output to the screen. Only use this command
for problem determination.
Examples The following is sample output from the debug fras-host snmp command. In this example, the MIB
variable k_frasHostConnEntry_get() is providing SNMP information for the FRAS host.
Router# debug fras-host snmp
k_frasHostConnEntry_get(): serNum = -1, vRingIfIdx = 31, frIfIdx = 12

Hmac = 4001.3745.1088, frLocSap = 4, Rmac = 400f.dddd.001e, frRemSap = 4
Table 111 debug fras-host snmp Field Descriptions
Field Description
serNum Serial number of the SNMP request.
vRingIfIdx Interface index of a virtual Token Ring.
frIfIdx Interface index of a Frame Relay serial interface.
Hmac MAC address associated with the host for this connection.
frLocSap SAP associated with the host for this connection.
Rmac MAC address associated with the FRAD for this connection.
frRemSap LLC 2 SAP associated with the FRAD for this connection.

DB-770 May 2008
Debug Commands
debug ftpserver
debug ftpserver
To display information about the FTP server process, use the debug ftpserver command in privileged
debug ftpserver
no debug ftpserver
Examples The following is sample output from the debug ftpserver command:
Router# debug ftpserver
Mar 3 10:21:10: %FTPSERVER-6-NEWCONN: FTP Server - new connection made.

-Process= "TCP/FTP Server", ipl= 0, pid= 53
Mar 3 10:21:10: FTPSRV_DEBUG:FTP Server file path: 'disk0:'
Mar 3 10:21:10: FTPSRV_DEBUG:(REPLY) 220
Mar 3 10:21:10: FTPSRV_DEBUG:FTProuter IOS-FTP server (version 1.00) ready.
Mar 3 10:21:10: FTPSRV_DEBUG:FTP Server Command received: 'USER aa'
Mar 3 10:21:20: FTPSRV_DEBUG:Password required for 'aa'.
Mar 3 10:21:20: FTPSRV_DEBUG:FTP Server Command received: 'PASS aa'
Mar 3 10:21:21: FTPSRV_DEBUG:Logged in.
Mar 3 10:21:21: FTPSRV_DEBUG:FTP Server Command received: 'SYST'
Mar 3 10:21:21: FTPSRV_DEBUG:Cisco IOS Type: L8 Version: IOS/FTP 1.00
Mar 3 10:21:21: FTPSRV_DEBUG:FTP Server Command received: 'PWD'
Mar 3 10:21:39: FTPSRV_DEBUG:FTP Server Command received: 'CWD disk0:/syslogd.d'r/'
Mar 3 10:21:45: FTPSRV_DEBUG:FTP Server file path: 'disk0:/syslogd.dir'
Mar 3 10:21:45: FTPSRV_DEBUG:CWD command successful.
Mar 3 10:21:45: FTPSRV_DEBUG:FTP Server Command received: 'PORT 171,69,30,20,22',32
Mar 3 10:21:46: FTPSRV_DEBUG:PORT command successful.
Mar 3 10:21:46: FTPSRV_DEBUG:FTP Server Command received: 'LIST'
Mar 3 10:21:47: FTPSRV_DEBUG:FTP Server file path: 'disk0:/syslogd.dir/.'
Mar 3 10:23:11: FTPSRV_DEBUG:Opening ASCII mode data connection for file list.
Mar 3 10:23:12: FTPSRV_DEBUG:Transfer complete.
Mar 3 10:23:12: FTPSRV_DEBUG:FTP Server Command received: 'TYPE I'
Mar 3 10:23:14: FTPSRV_DEBUG:Type set to I.
Mar 3 10:23:14: FTPSRV_DEBUG:FTP Server Command received: 'PORT 171,69,30,20,22',51
Mar 3 10:23:20: FTPSRV_DEBUG:PORT command successful.
Mar 3 10:23:20: FTPSRV_DEBUG:FTP Server Command received: 'RETR syslogd.1'
Mar 3 10:23:21: FTPSRV_DEBUG:FTP Server file path: 'disk0:/syslogd.dir/syslogd.1'
Mar 3 10:23:21: FTPSRV_DEBUG:FTPSERVER: Input path passed Top-dir(disk0:/syslogd.dir/)
test.

May 2008 DB-771
Debug Commands
debug ftpserver

Mar 3 10:23:21: FTPSRV_DEBUG:Opening BINARY mode data connection for syslogd.1 (607317
bytes).
Mar 3 10:23:29: FTPSRV_DEBUG:Transfer complete.
The sample output corresponds to the following FTP client session. In this example, the user connects
to the FTP server, views the contents of the top-level directory, and gets a file.
FTPclient% ftp FTProuter
Connected to FTProuter.cisco.com.
220 FTProuter IOS-FTP server (version 1.00) ready.
Name (FTProuter:me): aa
331 Password required for 'aa'.
Password:
230 Logged in.
Remote system type is Cisco.
ftp> pwd
257 "disk0:/syslogd.dir/" is current directory.
ftp> dir
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
syslogd.1
syslogd.2
syslogd.3
syslogd.4
syslogd.5
syslogd.6
syslogd.7
syslogd.8
syslogd.9
syslogd.cur
226 Transfer complete.
ftp> bin
200 Type set to I.
ftp> get syslogd.1
200 PORT command successful.
150 Opening BINARY mode data connection for syslogd.1 (607317 bytes).
226 Transfer complete.
607317 bytes received in 7.7 seconds (77 Kbytes/s)
ftp>
The following debug ftpserver command output indicates that no top-level directory is specified.
Therefore, the client cannot access any location on the FTP server. Use the ftp-server topdir command
to specify the top-level directory.
Mar 3 10:29:14: FTPSRV_DEBUG:Access denied to 'disk0:'

DB-772 May 2008
Debug Commands
debug gatekeeper gup

To display the Gatekeeper Update Protocol (GUP) events or Abstract Syntax Notation 1 (ASN.1) details,
use the debug gatekeeper gup command in privileged EXEC mode. To disable debugging output, use
debug gatekeeper gup {events | asn1}
no debug gatekeeper gup {events | asn1}
Syntax Description events Displays a message whenever a GUP announcement is sent or received.
GUP is the protocol used between individual gatekeepers in a cluster, which
keeps all the gatekeepers synchronized with all endpoints registered on the
cluster.
asn1 ASN.1 library. ASN.1 is an International Telecommunication Union (ITU)
standard for protocol syntax and message encoding. Entering this keyword
causes a packet dump of all GUP announcement messages.

12.1(5)XM This command was introduced.
12.2(2)XB1 This command was implemented on the Cisco AS5850 universal gateway.
Examples The following example shows how to enable a packet dump of all GUP announcement messages:
Router# debug gatekeeper gup asn1
00:10:21:ENCODE BUFFER::= 00 0A2A8648 86F70C0A 00000120 001E8001

86A08001 86A00547 656E6576 614E0000 00000142 80004700 65006E00 65007600
61080050 00610072 00690073 00000000 0000
00:10:21:
00:10:21:PDU ::=
value GUP_Information ::=
protocolIdentifier { 1 2 840 113548 10 0 0 1 }

message announcementIndication :
announcementInterval 30
endpointCapacity 100000

May 2008 DB-773
Debug Commands
callCapacity 100000
hostName '47656E657661'H
percentMemory 39
percentCPU 0
currentCalls 0
currentEndpoints 0
zoneInformation
gatekeeperIdentifier {"Geneva"}
altGKIdentifier {"Paris"}
totalBandwidth 0
interzoneBandwidth 0
remoteBandwidth 0
RAW_BUFFER::=
00 0A2A8648 86F70C0A 00000120 001E800B 858A8001 86A00144 80007400 6F007200 6E006100
64006F00 2D006700 6B120063 00790063 006C006F 006E0065 002D0067 006B0000 00000000
*Mar 3 15:40:31:
*Mar 3 15:40:31:Sending GUP ANNOUNCEMENT INDICATION to 172.18.195.140RAW_BUFFER::=
00 0A2A8648 86F70C0A 00000120 001E800A EF8A8001 86A00144 80006300 79006300 6C006F00
6E006500 2D006700 6B120074 006F0072 006E0061 0064006F 002D0067 006B0000 00000000
*Mar 3 15:40:31:PDU DATA = 60EAB248
value GUP_Information ::=
protocolIdentifier { 1 2 840 113548 10 0 0 1 }

message announcementIndication :
{
announcementInterval 30
endpointCapacity 716682
callCapacity 100000
zoneInformation
gatekeeperIdentifier {"cyclone-gk"}
altGKIdentifier {"tornado-gk"}
totalBandwidth 0
interzoneBandwidth 0
remoteBandwidth 0
Mar 3 15:40:31:Received GUP ANNOUNCEMENT INDICATION from 172.18.195.140
u all
All possible debugging has been turned off

load-balance Configures load balancing.

DB-774 May 2008
Debug Commands
debug gatekeeper load

To display gatekeeper load-balancing debug events, use the debug gatekeeper load command in
debug gatekeeper load {events}
no debug gatekeeper load {events}
Syntax Description events Displays a message whenever a load-balancing message is sent or received.

12.1(5)XM This command was introduced.
12.2(2)XB1 This command was implemented on the Cisco AS5850 universal gateway.
Examples The following is sample output for the debug gatekeeper load command.
Note The following output examples are independent of each other and would not ordinarily be seen at the
same time.
Router# debug gatekeeper load
Router#
gk load-balancing debug level = Events

Router#
gk_load_overloaded:Overloaded, 5-second CPU utilization too high
gk_load_overloaded:Overloaded due to excessive calls/endpoints
gk_load_balance_endpt_request:load balance occurred. New load_balance_count=2

May 2008 DB-775
Debug Commands

load-balance Configures load balancing.

DB-776 May 2008
Debug Commands
debug gatekeeper server

To trace all the message exchanges between the Cisco IOS Gatekeeper and the external applications, use
the debug gatekeeper server command in privileged EXEC mode. To disable debugging output, use the
no debug gatekeeper server
Defaults Disabled

Usage Guidelines Use this command to see information about a Gatekeeper server. This command shows any errors that
occur in sending messages to the external applications or in parsing messages from the external
applications.
Examples The following example shows debugging information about a Gatekeeper server:
Router# debug gatekeeper servers
Router# show debug
Gatekeeper:
Gatekeeper Server Messages debugging is on
To turn the Gatekeeper server debugging message off, see the following examples:
Router# no debug all
Router# no debug gatekeeper servers

show gatekeeper server Displays information about the Gatekeeper servers configured on
your network by ID.

May 2008 DB-777
Debug Commands
debug ggsn quota-server [detail | packets [dump] | events | parsing | errors]No default behavior or
values.
This command is useful for system operators and development engineers if problems are encountered
with communication between the GGSN quota server process and the CSG.
The following example enables the display of detailed quota server processing debug
outputpre-allocated quota and quota push:
Router#debug ggsn quota-server detail
ggsn quota-server details debugging is on
Router#
Jun 2 02:40:39.391: GGSN-QS:Encoding QUOTA PUSH REQUEST
Jun 2 02:40:39.391: GGSN-QS:Adding TLV USER_INDEX
Jun 2 02:40:39.391: GGSN-QS: IP Address: 3.3.3.1 User ID: 12345
Jun 2 02:40:39.391: GGSN-QS:Adding TLV SERVICE_ID: 1
Jun 2 02:40:39.391: GGSN-QS:Adding TLV QUADRANS_GRANTED
Jun 2 02:40:39.391: GGSN-QS: Quadrans: 1250 Threshold: 1000 Units: SECONDS
Jun 2 02:40:39.391: GGSN-QS:Adding TLV QUADRANS_GRANTED
Jun 2 02:40:39.391: GGSN-QS: Quadrans: 5000 Threshold: 5000 Units: BYTES_IP
Jun 2 02:40:39.391: GGSN-QS:Adding TLV TIMEOUT: 50000
Jun 2 02:40:39.391: GGSN-QS:Adding TLV TARIFF_TIME: 1147698000
Jun 2 02:40:39.391: GGSN-QS:Sending QUOTA_PUSH_REQ from QS (4.4.4.4:3386) to CSG
(30.1.1.1:3386)
Jun 2 02:40:39.395: pak=0x6523B5B0, datagramstart=0x200143D8, network_start=0x200143BC
datagramsize 91
Jun 2 02:40:39.395: GGSN-QS msgtype 0xF0, seq 1, len 85, from 4.4.4.4:3386 to
30.1.1.1:3386
200143D0: 0FF00055 00017E01 .p.U..~.
200debug ggsn quota-server detail143E0: FC005001 31000000 4A002E00 46001400
|.P.1...J...F...
200143F0: 09030303 01313233 34350015 00013100 .....12345....1.
20014400: 2D000E00 00000000 0004E201 03000003 -.........b.....
20014410: E8002D00 0E000000 00000013 88020300 h.-.............
20014420: 00138800 17000400 00C35000 4D000444 .........CP.M..D
20014430: 687B50 h{P
Jun 2 02:40:39.395: GGSN-QS:Received Data Record Transfer Response from (30.1.1.1:3386)
Sequence number 1
Jun 2 02:40:39.395: GGSN-QS:Cause = 128
Jun 2 02:40:39.395: GGSN-QS:Request Responded Sequence Number = 1
Jun 2 02:40:39.395: GGSN-QS:Private Ext IE length 32 QM Rsp length 29
Jun 2 02:40:39.395: GGSN-QS:Received message QUOTA_PUSH_RESP from CSG
Jun 2 02:40:39.395: GGSN-QS:UserIndex TLV: IP Address 3.3.3.1 UserName/MSISDN 12345
Jun 2 02:40:39.395: GGSN-QS:Session ID TLV: 1736898353
Jun 2 02:40:39.395: GGSN-QS:Service ID TLV: 1
Jun 2 02:40:39.399: GGSN-QS:Detected real CSG 30.1.1.1 for virtual CSG 30.1.1.1
Jun 2 02:40:39.399: GGSN-QS:real CSG newly detected
ggsn quota-server details debugging is on
Router#

DB-778 May 2008
Debug Commands
debug glbp errors
debug glbp errors

To display debugging messages about Gateway Load Balancing Protocol (GLBP) error conditions, use
the debug glbp errors command in privileged EXEC mode. To disable debugging output, use the no
debug glbp errors
no debug glbp errors

Examples The following is sample output from the debug glbp errors command:
Router# debug glbp errors
GLBP Errors debugging is on

1d19h: GLBP: Fa0/0 API active virtual address 10.21.8.32 not found

debug condition glbp Displays debugging messages about GLBP that match specific conditions.

May 2008 DB-779
Debug Commands
debug glbp events
debug glbp events

To display debugging messages about Gateway Load Balancing Protocol (GLBP) events that are
occurring, use the debug glbp events command in privileged EXEC mode. To disable debugging output,
debug glbp events [all | api | detail | ha | icmp | protocol | redundancy | terse | track]
no debug glbp events [all | api | detail | ha | icmp | protocol | redundancy | terse | track]
Syntax Description all (Optional) Displays all debugging output about GLBP events.
api (Optional) Displays GLBP API events.
detail (Optional) Displays detailed debugging output about GLBP events.
ha (Optional) Displays GLBP high-availability (HA) events.
icmp (Optional) Displays GLBP Internet Control Message Protocol (ICMP) events.
protocol (Optional) Displays GLBP protocol events.
redundancy (Optional) Displays GLBP redundancy events.
terse (Optional) Displays a limited range of debugging output about GLBP events.
track (Optional) Displays GLBP tracking events.

12.2(31)SB2 This command was enhanced to display information about GLBP support
of Stateful Switchover (SSO). The ha keyword was added.
Examples The following is sample output from the debug glbp events command when the terse keyword is
specified:
Router# debug glbp events terse
GLBP Events debugging is on

(protocol, redundancy, track)
The following is sample output from the debug glbp events command on an active RP displaying an
interface shutdown event:
Router# debug glbp events

DB-780 May 2008
Debug Commands
debug glbp events
*Sep 15 09:14:53.583: GLBP: Et0/0 API Software interface going down

*Sep 15 09:14:53.583: GLBP: Et0/0 Interface down
*Sep 15 09:14:53.583: GLBP: Et0/0 1.1 Listen: e/Forwarder disabled
*Sep 15 09:14:53.583: GLBP: Et0/0 1.1 Listen -> Init
*Sep 15 09:14:53.583: GLBP: Et0/0 Fwd 1.1 HA Encoded (state Init) into sync buffer
*Sep 15 09:14:53.583: GLBP: Et0/0 1.2 Active: e/Forwarder disabled
*Sep 15 09:14:53.583: GLBP: Et0/0 1.2 Active -> Init
*Sep 15 09:14:53.583: %GLBP-6-FWDSTATECHANGE: Ethernet0/0 Grp 1 Fwd 2 state Active -> Init
*Sep 15 09:14:53.583: GLBP: Et0/0 1 Standby: e/GLBP disabled
*Sep 15 09:14:53.583: GLBP: Et0/0 1 Active router IP is unknown, was 172.24.1.2
*Sep 15 09:14:53.583: GLBP: Et0/0 1 Standby router is unknown, was local
*Sep 15 09:14:53.583: GLBP: Et0/0 1 Standby -> Init
*Sep 15 09:14:53.583: GLBP: Et0/0 Grp 1 HA Encoded (state Init) into sync buffer
*Sep 15 09:14:55.583: %LINK-5-CHANGED: Interface Ethernet0/0, changed state to
*Sep 15 09:14:55.587: GLBP: API Hardware state change
*Sep 15 09:14:56.595: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed
state to down
The following is sample output from the debug glbp events command on a standby RP
displaying an interface shutdown event:
RouterRP-standby# debug glbp events

.
.
.
*Sep 15 09:14:53.691: GLBP: Et0/0 Fwd 1.1 HA sync, state Listen -> Init
*Sep 15 09:14:53.691: GLBP: Et0/0 Fwd 1.2 HA sync, state Active -> Init
*Sep 15 09:14:53.691: GLBP: Et0/0 Grp 1 HA sync, state Standby -> Init


May 2008 DB-781
Debug Commands
debug glbp events
debug glbp events

To display debugging messages about Gateway Load Balancing Protocol (GLBP) events that are
occurring, use the debug glbp events command in privileged EXEC mode. To disable debugging output,
debug glbp events [all | api | cache | detail | ha | icmp | protocol | redundancy | terse | track]
no debug glbp events [all | api | cache | detail | ha | icmp | protocol | redundancy | terse | track]
Syntax Description all (Optional) Displays all debugging output about GLBP events.
api (Optional) Displays GLBP API events.
cache (Optional) Displays GLBP client cache events.
detail (Optional) Displays detailed debugging output about GLBP events.
ha (Optional) Displays GLBP high-availability (HA) events.
icmp (Optional) Displays GLBP Internet Control Message Protocol (ICMP) events.
protocol (Optional) Displays GLBP protocol events.
redundancy (Optional) Displays GLBP redundancy events.
terse (Optional) Displays a limited range of debugging output about GLBP events.
track (Optional) Displays GLBP tracking events.

12.2(31)SB2 This command was enhanced to display information about GLBP support
of Stateful Switchover (SSO). The ha keyword was added.
12.4(6th)T The cache keyword was added.
Examples The following is sample output from the debug glbp events command when the terse keyword is
specified:
Router# debug glbp events terse


DB-782 May 2008
Debug Commands
debug glbp events
The following is sample output from the debug glbp events command on an active RP displaying an
interface shutdown event:
Router# debug glbp events

*Sep 15 09:14:53.583: GLBP: Et0/0 Interface down
*Sep 15 09:14:53.583: GLBP: Et0/0 1.1 Listen: e/Forwarder disabled
*Sep 15 09:14:53.583: GLBP: Et0/0 1.1 Listen -> Init
*Sep 15 09:14:53.583: GLBP: Et0/0 1.2 Active: e/Forwarder disabled
*Sep 15 09:14:53.583: GLBP: Et0/0 1.2 Active -> Init
*Sep 15 09:14:53.583: %GLBP-6-FWDSTATECHANGE: Ethernet0/0 Grp 1 Fwd 2 state Active -> Init
*Sep 15 09:14:53.583: GLBP: Et0/0 1 Standby: e/GLBP disabled
*Sep 15 09:14:53.583: GLBP: Et0/0 1 Active router IP is unknown, was 172.24.1.2
*Sep 15 09:14:53.583: GLBP: Et0/0 1 Standby router is unknown, was local
*Sep 15 09:14:53.583: GLBP: Et0/0 1 Standby -> Init
*Sep 15 09:14:53.583: GLBP: Et0/0 Grp 1 HA Encoded (state Init) into sync buffer
*Sep 15 09:14:55.583: %LINK-5-CHANGED: Interface Ethernet0/0, changed state to
*Sep 15 09:14:55.587: GLBP: API Hardware state change
*Sep 15 09:14:56.595: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed
state to down
The following is sample output from the debug glbp events command on a standby RP
displaying an interface shutdown event:
RouterRP-standby# debug glbp events

.
.
.
*Sep 15 09:14:53.691: GLBP: Et0/0 Fwd 1.1 HA sync, state Listen -> Init
*Sep 15 09:14:53.691: GLBP: Et0/0 Fwd 1.2 HA sync, state Active -> Init
*Sep 15 09:14:53.691: GLBP: Et0/0 Grp 1 HA sync, state Standby -> Init


May 2008 DB-783
Debug Commands
debug glbp packets
debug glbp packets

To display summary information about Gateway Load Balancing Protocol (GLBP) packets being sent or
received, use the debug glbp packets command in privileged EXEC mode. To disable debugging output,
debug glbp packets [all | detail | hello | reply | request | terse]
no debug glbp packets [all | detail | hello | reply | request | terse]
Syntax Description all (Optional) Displays all debugging output about GLBP packets.
detail (Optional) Displays detailed debugging output about GLBP packets.
hello (Optional) Displays debugging output about GLBP hello packets.
reply (Optional) Displays debugging output about GLBP reply packets.
request (Optional) Displays debugging output about GLBP request packets.
terse (Optional) Displays a limited range of debugging output about GLBP packets.

Examples The following sample output from the debug glbp packets command shows debugging output about
GLBP hello packets:
Router# debug glbp packets hello
GLBP Packets debugging is on

(Hello)
1d19h: GLBP: Fa0/0 Grp 10 Hello out 10.21.8.32 VG Active pri 254 vIP 10.21.8.10 1


DB-784 May 2008
Debug Commands
debug glbp terse
debug glbp terse

To display a limited range of debugging messages about Gateway Load Balancing Protocol (GLBP)
errors, events, and packets, use the debug glbp terse command in privileged EXEC mode. To disable
debug glbp terse
no debug glbp terse

Examples The following is sample output from the debug glbp terse command:
Router# debug glbp terse
GLBP:
GLBP Errors debugging is on
GLBP Packets debugging is on
(Request, Reply)

debug glbp errors Displays debugging messages about GLBP errors.
debug glbp events Displays debugging messages about GLBP events.
debug glbp packets Displays debugging messages about GLBP packets.
debug gprs category fsm event No default behavior or values.

This command is useful for system operators and development engineers if problems are encountered
with eGGSN processing.

May 2008 DB-785
Debug Commands
debug glbp terse
Example 1PDPs with Pre-Allocated Quota

The following example enables the display of eGGSN events and state transactionspre-allocated
quota. This is
Example 2PDPs without Pre-Allocated Quota

The following example enables the display of eGGSN events and state transactionsfor PDPs without
pre-allocated quota.
PDP Context Create:
Router#
Jun 2 02:58:45.727: GPRS:1234050000000010:created service-aware subblock
Jun 2 02:58:48.623: GPRS:1234050000000010:it is the only one PDP of the user, need CCR
msg
Jun 2 02:58:48.623: GPRS:1234050000000010:sent ccr_init
Router#
PDP Context Delete:

Router#
Jun 2 02:59:06.975: GPRS:1234050000000010:eggsn_get_final_usage_report
Jun 2 02:59:06.975: GPRS:1234050000000010:freeing all categories
Jun 2 02:59:06.975: GPRS:1234050000000010:freeing service-aware subblock
Router

DB-786 May 2008
Debug Commands
debug gprs charging
debug gprs charging

To display information about general packet radio service (GPRS) charging functions on the gateway
GPRS support node (GGSN), use the debug gprs charging command in privileged EXEC mode. To
debug gprs charging {events | packets}
no debug gprs charging {events | packets}
Syntax Description events Displays events related to GPRS charging processing on the GGSN.
packets Displays GPRS charging packets that are sent between the GGSN and the
charging gateway.

12.1(1)GA This command was introduced.
12.2(4)MX This command was integrated into Cisco IOS Release 12.2(4)MX.
12.2(8)YD This command was integrated into Cisco IOS Release 12.2(8)YD.
12.2(8)B This command was integrated into Cisco IOS Release 12.2(8)B.
12.2(8)YY This command was integrated into Cisco IOS Release 12.2(8)YY.
Usage Guidelines This command is useful for system operators if problems are encountered with GPRS charging
functions.
Caution Because the debug gprs charging command generates a substantial amount of output, use it only when
traffic on the GPRS network is low, so other activity on the system is not adversely affected.
Examples The following example enables the display of events related to GPRS charging events on the GGSN:
Router# debug gprs charging events

May 2008 DB-787
Debug Commands
debug gprs charging
The following example enables the display of GPRS charging packets sent between the GGSN and the
charging gateway:
Router# debug gprs charging events
display troubleshooting information about Diameter Credit Control Application (DCCA) processing on
the gateway GPRS support node (GGSN)debug gprs dccaNo default behavior or values.
This command is useful for system operators and development engineers if Diameter protocol problems
are encountered on the GGSN.
Examples The following is a sample of DCCA debug information with pre-allocated quota.
Router#debug gprs dcca
Router#
Jun 2 03:13:45.827: GPRS:1234050000000010:GPRS:DCCA: 3GPP-IMSI : 214350000000000
Jun 2 03:13:45.831: GPRS:1234050000000010:GPRS:DCCA: 3GPP-Charging-Id : 613053186
Jun 2 03:13:45.831: GPRS:1234050000000010:GPRS:DCCA: 3GPP-PDP-Type : 0
Jun 2 03:13:45.831: GPRS:1234050000000010:GPRS:DCCA: 3GPP-CG-Address : 20.1.1.1
Jun 2 03:13:45.831: GPRS:1234050000000010:GPRS:DCCA: 3GPP-QoS-Profile :
99-0911012964FFFF1100FFFF
Jun 2 03:13:45.831: GPRS:1234050000000010:GPRS:DCCA: 3GPP-SGSN-Address : 11.20.1.1
Jun 2 03:13:45.831: GPRS:1234050000000010:GPRS:DCCA: 3GPP-GGSN-Address : 10.20.61.1
Jun 2 03:13:45.831: GPRS:1234050000000010:GPRS:DCCA: 3GPP-IMSI-MCC-MNC : 21435
Jun 2 03:13:45.831: GPRS:1234050000000010:GPRS:DCCA: 3GPP-GGSN-MCC-MNC : 001002
Jun 2 03:13:45.831: GPRS:1234050000000010:GPRS:DCCA: 3GPP-NSAPI : 1
Jun 2 03:13:45.831: GPRS:1234050000000010:GPRS:DCCA: 3GPP-Selection-Mode : 0
Jun 2 03:13:45.831: GPRS:1234050000000010:3GPP-Charging-Char : 0100
Jun 2 03:13:45.831: GPRS:1234050000000010:GPRS DCCA: Starting Tx timer , value = 100000
Jun 2 03:13:45.831: GPRS:1234050000000010:DCCA FSM:Event = CCR_INITIAL, Old State = IDLE,
New State = PENDING_I
Jun 2 03:13:46.287: GPRS:1234050000000010:GPRS DCCA: Result-Code = 2001
Jun 2 03:13:46.287: GPRS:1234050000000010:GPRS DCCA: Stopping Tx timer
Jun 2 03:13:46.287: GPRS:1234050000000010:GPRS DCCA: Result-Code for Category : 1 =
2001
Jun 2 03:13:46.287: GPRS:1234050000000010:DCCA FSM:Event = CCA_SUCCESS, Old State =
PENDING_I, New State = OPEN
Router#
Router#show gprs gtp pdp tid 1234050000000010 ser all
Diameter Credit Control: Enabled
Current Billing status: Prepaid
Reason to convert to postpaid: N/A
Charging Profile Index: 1
DCCA profile name: dcca-profile1, Source: charging profile
Rule base id: 1, Source: DCCA server
ServiceID State Quota(octets)
1 AUTHORIZED 5000
Router#
PDP being deleted

The following is a sample of DCCA debug information without pre-allocated quota.
Router#show debug
GPRS:
GPRS DCCA Events debugging is on
Router#

DB-788 May 2008
Debug Commands
debug gprs charging

99-0911012964FFFF1100FFFF
Jun 2 03:05:07.743: GPRS:1234050000000010:GPRS DCCA: Starting Tx timer , value = 100000
Jun 2 03:05:07.743: GPRS:1234050000000010:DCCA FSM:Event = CCR_INITIAL, Old State = IDLE,
New State = PENDING_I
Jun 2 03:05:08.167: GPRS:1234050000000010:GPRS DCCA: Result-Code = 2001
Jun 2 03:05:08.167: GPRS:1234050000000010:DCCA FSM:Event = CCA_SUCCESS, Old State =
PENDING_I, New State = OPEN
Router#
gprs5-72b#sgpt 1234050000000010 ser all
Diameter Credit Control: Enabled
Current Billing status: Prepaid
Reason to convert to postpaid: N/A
Charging Profile Index: 1
DCCA profile name: dcca-profile1, Source: charging profile
Rule base id: 1, Source: DCCA server
ServiceID State Quota(octets)
gprs5-72b#clear gprs gtp pdp all
PDP deleted
Router#
99-0911012964FFFF1100FFFF
Jun 2 03:05:28.463: GPRS:1234050000000010:DCCA FSM:Event = CCR_FINAL, Old State = OPEN,
New State = PENDING_T
Jun 2 03:05:28.871: GPRS:GPRS DCCA: DCCA request was cancelled, Droping AAA reply
Router#
Router#sgpt 1234050000000010 ser all
%ERROR: Cannot find the PDP
Router#

May 2008 DB-789
Debug Commands
debug gprs dfp
debug gprs dfp

To display debug messages for GPRS DFP weight calculation, use the debug gprs dfp privileged EXEC
command. To disable debugging output, use the no form of this command.
debug gprs dfp
no debug gprs dfp

12.1(9)E This command was introduced.
12.2(4)MX This command was incorporated in Cisco IOS Release 12.2(4)MX.
12.2(8)YD This command was incorporated in Cisco IOS Release 12.2(8)YD.
12.2(8)YW This command was incorporated in Cisco IOS Release 12.2(8)YW.
12.3(2)XB This command was incorporated in Cisco IOS Release 12.3(2)XB.
12.3(8)XU This command was incorporated in Cisco IOS Release 12.3(8)XU.
12.3(11)YJ This command was incorporated in Cisco IOS Release 12.3(11)YJ.
12.3(14)YQ This command was incorporated in Cisco IOS Release 12.3(14)YQ.
Usage Guidelines See the following caution before using debug commands:
This command displays debug messages for GPRS DFP weight calculation. To display debug messages
for the DFP agent subsystem, use the debug ip dfp agent command.

DB-790 May 2008
Debug Commands
debug gprs dfp
Examples The following example configures a debug session to check all GPRS DFP weight calculation:
Router# debug gprs dfp
GPRS DFP debugging is on
Router#
The following example stops all debugging:

Router#

May 2008 DB-791
Debug Commands
debug gprs dhcp
debug gprs dhcp

To display information about Dynamic Host Configuration Protocol (DHCP) processing on the GGSN,
use the debug gprs dhcp privileged EXEC command. To disable debugging output, use the no form of
this command.
debug gprs dhcp
no debug gprs dhcp

12.2(4)MX This command was introduced.
Usage Guidelines This command is useful for system operators and development engineers if problems are encountered
with DHCP processing on the GGSN. To display standard debug messages between the DHCP client on
the router and a DHCP server, you can also use the debug dhcp or debug dhcp detail commands with
the debug gprs dhcp command.
Caution Because the debug gprs dhcp command generates a significant amount of output, use it only when
Examples The following example shows sample output for DHCP processing on the GGSN:
Router# debug gprs dhcp
2d13h: GPRS:DHCP req:TID 1111111100000099, Req 1
2d13h: GPRS:Requesting IP address for pdp 1111111100000099 from server 172.16.0.8 tableid
0
2d13h: GPRS:DHCP ip allocation pass (10.88.17.43) for pdp 1111111100000099
2d13h: GPRS:Using DHCP ip address 10.88.17.43 for pdp 1111111100000099

DB-792 May 2008
Debug Commands
debug gprs dhcp
The following example shows sample output for standard debug messaging for DHCP processing on the
router between the DHCP client and a DHCP server:
2d13h: DHCP: proxy allocate request
2d13h: DHCP: new entry. add to queue
2d13h: DHCP: SDiscover attempt # 1 for entry:
2d13h: DHCP: SDiscover: sending 283 byte length DHCP packet
2d13h: DHCP: SDiscover with directed serv 172.16.0.8, 283 bytes
2d13h: DHCP: XID MATCH in dhcpc_for_us()
2d13h: DHCP: Received a BOOTREP pkt
2d13h: DHCP: offer received from 172.16.0.8
2d13h: DHCP: SRequest attempt # 1 for entry:
2d13h: DHCP: SRequest- Server ID option: 172.16.0.8
2d13h: DHCP: SRequest- Requested IP addr option: 10.88.17.43
2d13h: DHCP: SRequest placed lease len option: 604800
2d13h: DHCP: SRequest: 301 bytes
2d13h: DHCP: SRequest: 301 bytes
2d13h: DHCP: XID MATCH in dhcpc_for_us()
2d13h: DHCP: Received a BOOTREP pkt
2d13h: DHCP Proxy Client Pooling: ***Allocated IP address: 10.88.17.43

debug dhcp Displays debug messages between the DHCP client on the router and a
DHCP server.

May 2008 DB-793
Debug Commands
debug gprs gtp parsing

To display information about the parsing of GPRS Tunneling Protocol (GTP) information elements (IEs)
in signaling requests, use the debug gprs gtp parsing privileged EXEC command. To disable debugging
no debug gprs gtp parsing

Usage Guidelines This command is useful for system operators and development engineers to verify parsing of GTP IEs
in signaling requests that are received by GDM or by the GGSN. If the packet is parsed successfully, you
will receive a message along with the TID for the packet as shown in the following example:
GPRS:TID:7300000000000000:Packet Parsed successfully
The debug gprs gtp parsing command can be used to verify GDM or GGSN processing of IEs.
Caution Because the debug gprs gtp parsing command generates a significant amount of output, use it only
when traffic on the GPRS network is low, so other activity on the system is not adversely affected.
Examples The following example enables the display of debug messages that occur while GDM or the GGSN
parses GTP IEs:
Router# debug gprs gtp parsing

DB-794 May 2008
Debug Commands
debug gprs gtp ppp
debug gprs gtp ppp

To display information about PPP PDP type processing on the GGSN, use the debug gprs gtp ppp
privileged EXEC command. To disable debugging output, use the no form of this command.
debug gprs gtp ppp {events | details}
no debug gprs gtp ppp {events | details}
Syntax Description events Displays messages specific to certain conditions that are occurring during
PPP PDP type processing.
details Displays more extensive and lower-level messages related to PPP PDP type
processing.

with PPP PDP type processing on the GGSN.
You can enable both forms of the debug gprs gtp ppp command at the same time, as separate command
line entries. The events keyword generates output specific to certain conditions that are occurring, which
helps qualify the output being received using the details option.
Caution Because the debug gprs gtp ppp command generates a significant amount of output, use it only when
Examples The following debug examples provide sample output for a create PDP context request and clear PDP
context using PPP PDP type on the GGSN. The examples show output while both debug events and
details are enabled on the GGSN.

May 2008 DB-795
Debug Commands
debug gprs gtp ppp
Example 1
The following example displays details and events output related to PPP PDP context processing for a
create PDP context requested received by the GGSN:
Router# debug gprs gtp ppp events
GTP PPP events display debugging is on
Router# debug gprs gtp ppp details
GTP PPP details display debugging is on
7200b#
3d23h: GPRS:
3d23h: GTP-PPP Fa1/0: Create new gtp_ppp_info
3d23h: GPRS:
3d23h: GTP-PPP: domain gprs.cisco.com not in any VPDN group
3d23h: GPRS:
3d23h: GTP-PPP: aaa-group accounting not configured under APN gprs.cisco.com
3d23h: GPRS:GTP-PPP: Don't cache internally generated pak's header
3d23h: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up
3d23h: GPRS:
3d23h: GTP-PPP Vi2: gtp_ppp_cstate_react changing states
3d23h: GPRS:GTP-PPP: pdp_entry 0x62F442A4, recv ppp data pak
3d23h: GPRS:GTP-PPP Vi2: proc_udp_input pak's linktype = 30
3d23h: GPRS:
3d23h: GTP-PPP: Vi2: Concat names user00 & gprs.cisco.com
3d23h: GPRS:
3d23h: GTP-PPP: New username after concat: user00@gprs.cisco.com
3d23h: GPRS:
3d23h: GTP-PPP: Vi2: Concat names user00@gprs.cisco.com & gprs.cisco.com
3d23h: GPRS:
3d23h: GTP-PPP: New username after concat: user00@gprs.cisco.com
3d23h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to
up
3d23h: GPRS:
3d23h: GTP-PPP Vi2: gtp_ppp_protocol_up is notified about intf UP
3d23h: GPRS:
3d23h: GTP-PPP Vi2: PDP w/ MS addr 98.102.0.1 inserted into IP radix tree
Example 2
The following example displays both details and events related to PPP PDP type processing after
clearing PDP contexts on the GGSN:
Router# clear gprs gtp pdp-context all
3d23h: GPRS:

DB-796 May 2008
Debug Commands
debug gprs gtp ppp
3d23h: GTP-PPP Vi2: gtp_ppp_pdp_terminate shutting down the vaccess

3d23h: GPRS:
3d23h: GTP-PPP Vi2: gtp_ppp_pdp_shut_va shutting down intf
3d23h: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to down
3d23h: GPRS:
3d23h: GTP-PPP Vi2: gtp_ppp_cstate_react changing states
3d23h: GPRS:
3d23h: GTP-PPP Vi2: gtp_ppp_free_va resetting intf vectors
3d23h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to
down

May 2008 DB-797
Debug Commands
debug gprs gtp ppp-regeneration

To display information about PPP regeneration processing on the GGSN, use the debug gprs gtp
ppp-regeneration privileged EXEC command. To disable debugging output, use the no form of this
command.
debug gprs gtp ppp-regeneration {events | details}
no debug gprs gtp ppp-regeneration {events | details}
Syntax Description events Displays messages specific to certain conditions that are occurring during
PPP regeneration processing.
details Displays more extensive and lower-level messages related to PPP
regeneration processing.

with communication between GDM and a GGSN.
You can enable both forms of the debug gprs gtp ppp-regeneration command at the same time, as
separate command line entries. The events keyword generates output specific to certain conditions that
are occurring, which helps qualify the output being received using the details option.
Caution Because the debug gprs gtp ppp-regeneration command generates a significant amount of output, use
it only when traffic on the GPRS network is low, so other activity on the system is not adversely affected.
Examples The following debug examples provide sample output for a create PDP context request and clear PDP
context using PPP regeneration on the GGSN. The examples show output while both debug events and
details are enabled on the GGSN.

DB-798 May 2008
Debug Commands
Example 1
The following example displays details and events output related to PPP regeneration processing for a
create PDP context requested received by the GGSN:
Router# debug gprs gtp ppp-regeneration details
GTP PPP regeneration details display debugging is on
Router# debug gprs gtp ppp-regeneration events
GTP PPP regeneration events display debugging is on
06:24:02: PPP-REGEN state counters: pending counter is 0
06:24:02: State[IDLE] counter is 0
06:24:02: State[AUTHORIZING] counter is 0
06:24:02: State[VPDN CONNECTING] counter is 0
06:24:02: State[PPP NEGOTIATING] counter is 0
06:24:02: State[PPP CONNECTED] counter is 0
06:24:02: State[PPP TERMINATING] counter is 0
06:24:02: GPRS:1011111111500001:Authen: PAP username: tomy1@corporate_1.com
06:24:02: GPRS:1011111111500001:Session timer started
06:24:02: GPRS:Processing PPP regen reqQ
06:24:02: GPRS:1011111111500001:Processing Initiate PPP regen from reqQ
06:24:02: GPRS:1011111111500001:got event [REQUEST PPP REGEN] in state [IDLE]
06:24:02: GPRS:1011111111500001:state [IDLE->AUTHORIZING] on event [REQUEST PPP REGEN]
06:24:02: GPRS:1011111111500001:Got VPN authorization info
06:24:02: GPRS:1011111111500001:got event [AUTHOR SUCCESS] in state [AUTHORIZING]
06:24:02: GPRS:1011111111500001:state [AUTHORIZING->VPDN CONNECTING] on event [AUTHOR
SUCCESS]
06:24:02: GPRS:1011111111500001:Author succeeded, establishing the tunnel
06:24:02: GPRS:1011111111500001:Create/Clone vaccess to negotiate PPP
06:24:02: GPRS:1011111111500001:no need to set NS ppp_config
06:24:02: GPRS:1011111111500001:MS no static IP addr. Get one via IPCP
06:24:02: GPRS:1011111111500001:VPDN to inform PPP regen: CONNECTED
06:24:02: GPRS:1011111111500001:got event [VPDN CONNECTED] in state [VPDN CONNECTING]
06:24:02: GPRS:1011111111500001:state [VPDN CONNECTING->PPP NEGOTIATING] on event [VPDN
CONNECTED]
06:24:02: GPRS:1011111111500001:Start PPP negotiations on vaccess
06:24:02: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up

May 2008 DB-799
Debug Commands
06:24:02: GPRS:1011111111500001:IPCP is up
06:24:02: GPRS:1011111111500001:LNS allocates 10.100.1.1 for MS
06:24:02: GPRS:1011111111500001:IP addr 10.100.1.1 is negotiated for MS
06:24:02: GPRS:1011111111500001:PPP connected
06:24:02: GPRS:1011111111500001:got event [PPP NEGOTIATED] in state [PPP NEGOTIATING]
06:24:02: GPRS:1011111111500001:state [PPP NEGOTIATING->PPP CONNECTED] on event [PPP
NEGOTIATED]
06:24:02: GPRS:1011111111500001:PPP succeeded negotiation, session established
06:24:02: GPRS:1011111111500001:Session timer stopped
to up
Example 2
The following example displays both details and events related to PPP regeneration processing after
clearing PDP contexts on the GGSN:
Router# clear gprs gtp pdp-context all
06:28:05: GPRS:1011111111500001:PPP regen current state PPP CONNECTED
06:28:05: GPRS:1011111111500001:GTP disconnecting the PPP regen session
06:28:05: GPRS:Processing PPP regen reqQ
06:28:05: GPRS:1011111111500001:Processing Disconnect PPP regen from reqQ
06:28:05: GPRS:1011111111500001:got event [CANCEL REGEN'ED PPP] in state [PPP CONNECTED]
06:28:05: GPRS:1011111111500001:state [PPP CONNECTED->PPP TERMINATING] on event [CANCEL
REGEN'ED PPP]
06:28:05: GPRS:1011111111500001:Cancel request after VPND tunnel is up
06:28:05: GPRS:1011111111500001:PPP down
06:28:05: GPRS:1011111111500001:got event [PPP FAILED] in state [PPP TERMINATING]

DB-800 May 2008
Debug Commands
06:28:05: GPRS:1011111111500001:state [PPP TERMINATING->IDLE] on event [PPP FAILED]

06:28:05: GPRS:1011111111500001:LCP went down
06:28:05: GPRS:1011111111500001:VPDN disconnect
06:28:05: GPRS:1011111111500001:got event [CLEANUP CONTEXT] in state [IDLE]
06:28:05: GPRS:1011111111500001:state [IDLE->IDLE] on event [CLEANUP CONTEXT]
06:28:05: GPRS:1011111111500001:Freeing context structure
06:28:05: GPRS:1011111111500001:VPDN handle invalid, no need to free it
06:28:05: GPRS:1011111111500001:remove PPP regen context from Vi2
06:28:05: GPRS:1011111111500001:Session timer stopped
06:28:05: GPRS:1011111111500001:PPP regen context 0x633F196C released
06:28:05: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to down
to down

May 2008 DB-801
Debug Commands
debug gprs gtp
debug gprs gtp

To display information about the GPRS Tunneling Protocol (GTP), use the debug gprs gtp privileged
EXEC command. To disable debugging output, use the no form of this command.
debug gprs gtp {events | messages | packets}
no debug gprs gtp {events | messages | packets}
Syntax Description events Displays events related to GTP processing on the GGSN.
messages Displays GTP signaling messages that are sent between the SGSN and
GGSN.
packets Displays GTP packets that are sent between the SGSN and GGSN.

12.2(4)MX This command was incorporated in Cisco IOS Release 12.2(4)MX, and the
ppp {details | events} option was added.
with communication between the GGSN and the SGSN using GTP.
Caution Because the debug gprs gtp command generates a significant amount of output, use it only when traffic
on the GPRS network is low, so other activity on the system is not adversely affected.
Examples The following example enables the display of events related to GTP processing on the GGSN:
Router# debug gprs gtp events

DB-802 May 2008
Debug Commands
debug gprs gtp
The following example enables the display of GTP signaling messages:

Router# debug gprs gtp messages
The following example enables the display of GTP packets sent between the SGSN and GGSN:
Router# debug gprs gtp packets
The following example enables the display of GTP PPP events between the SGSN and GGSN:
The following example enables the display of detailed GTP PPP debug output along with GTP PPP
events between the SGSN and GGSN:
Router# debug gprs gtp ppp details
The following debug examples provide sample output for a create PDP context request, delete PDP
context request, and clear PDP context using PPP regeneration on the GGSN. The first three examples
show output related to debug events messaging only. The last three examples show output while both
debug events and details are enabled on the GGSN.
Example 1
Example 2
Example 3
*Mar 1 00:04:50.083: GPRS:1111110000000000:GTP disconnecting the PPP regen session
*Mar 1 00:04:50.083: GPRS:1111110000000000:Processing Disconnect PPP regen from reqQ
*Mar 1 00:04:50.083: GPRS:1111110000000000:got event [CANCEL REGEN'ED PPP] in state [PPP
CONNECTED]
*Mar 1 00:04:50.083: GPRS:1111110000000000:state [PPP CONNECTED->PPP TERMINATING] on
event [CANCEL REGEN'ED PPP]
*Mar 1 00:04:50.083: GPRS:1111110000000000:Cancel request after VPND tunnel is up
*Mar 1 00:04:50.087: GPRS:1111110000000000:PPP down
*Mar 1 00:04:50.087: GPRS:1111110000000000:got event [PPP FAILED] in state [PPP
TERMINATING]
*Mar 1 00:04:50.091: GPRS:1111110000000000:state [PPP TERMINATING->IDLE] on event [PPP
FAILED]
*Mar 1 00:04:50.091: GPRS:1111110000000000:PPP failed negotiation
*Mar 1 00:04:50.091: GPRS:1111110000000000:got event [CLEANUP CONTEXT] in state [IDLE]
*Mar 1 00:04:50.091: GPRS:1111110000000000:VPDN to inform PPP regen: DISCONNECTED
*Mar 1 00:04:50.091: GPRS:1111110000000000:got event [VPDN DISCONNECTED] in state [IDLE]
*Mar 1 00:04:50.091: GPRS:1111110000000000:state [IDLE->IDLE] on event [CLEANUP CONTEXT]
*Mar 1 00:04:50.091: GPRS:1111110000000000:Freeing context structure
Example 4
*Mar 1 00:05:21.083: PPP-REGEN state counters: pending counter is 0
*Mar 1 00:05:21.083: State[IDLE] counter is 0
*Mar 1 00:05:21.083: State[AUTHORIZING] counter is 0
*Mar 1 00:05:21.083: State[VPDN CONNECTING] counter is 0
*Mar 1 00:05:21.083: State[PPP NEGOTIATING] counter is 0
*Mar 1 00:05:21.083: State[PPP CONNECTED] counter is 0
*Mar 1 00:05:21.083: State[PPP TERMINATING] counter is 0

May 2008 DB-803
Debug Commands
debug gprs gtp

*Mar 1 00:05:21.087: GPRS:1111110000000000:Authen: PAP username: user@pdn.com
*Mar 1 00:05:21.087: GPRS:1111110000000000:Session timer started
*Mar 1 00:05:21.087: GPRS:1111110000000000:Processing Initiate PPP regen from reqQ
*Mar 1 00:05:21.087: GPRS:1111110000000000:got event [REQUEST PPP REGEN] in state [IDLE]
*Mar 1 00:05:21.087: GPRS:1111110000000000:state [IDLE->AUTHORIZING] on event [REQUEST
PPP REGEN]
*Mar 1 00:05:21.087: GPRS:1111110000000000:Got VPN authorization info
*Mar 1 00:05:21.087: GPRS:1111110000000000:got event [AUTHOR SUCCESS] in state
[AUTHORIZING]
*Mar 1 00:05:21.087: GPRS:1111110000000000:state [AUTHORIZING->VPDN CONNECTING] on event
[AUTHOR SUCCESS]
*Mar 1 00:05:21.087: GPRS:1111110000000000:Author succeeded, establishing the tunnel
*Mar 1 00:05:21.087: GPRS:1111110000000000:Create/Clone vaccess to negotiate PPP
*Mar 1 00:05:21.091: GPRS:1111110000000000:MS no static IP addr. Get one via IPCP
*Mar 1 00:05:21.127: GPRS:1111110000000000:VPDN to inform PPP regen: CONNECTED
*Mar 1 00:05:21.127: GPRS:1111110000000000:got event [VPDN CONNECTED] in state [VPDN
CONNECTING]
*Mar 1 00:05:21.127: GPRS:1111110000000000:state [VPDN CONNECTING->PPP NEGOTIATING] on
event [VPDN CONNECTED]
*Mar 1 00:05:21.127: GPRS:1111110000000000:Start PPP negotiations on vaccess
*Mar 1 00:05:21.131: %LINK-3-UPDOWN: Interface Virtual-Access5, changed state to up
changed state to up
*Mar 1 00:05:23.143: GPRS:1111110000000000:IPCP is up
*Mar 1 00:05:23.143: GPRS:1111110000000000:LNS allocates 10.10.1.187 for MS
*Mar 1 00:05:23.143: GPRS:1111110000000000:IP addr 10.10.1.187 is negotiated for MS
*Mar 1 00:05:23.143: GPRS:1111110000000000:DNS - Primary: 10.3.0.1 Secondary: 0.0.0.0
NetBios - Primary: 0.0.0.0, Secondary: 0.0.0.0
*Mar 1 00:05:23.143: GPRS:1111110000000000:PPP connected
*Mar 1 00:05:23.143: GPRS:1111110000000000:got event [PPP NEGOTIATED] in state [PPP
NEGOTIATING]

DB-804 May 2008
Debug Commands
debug gprs gtp
*Mar 1 00:05:23.143: GPRS:1111110000000000:state [PPP NEGOTIATING->PPP CONNECTED] on

event [PPP NEGOTIATED]
*Mar 1 00:05:23.143: GPRS:1111110000000000:PPP succeeded negotiation, session established
*Mar 1 00:05:23.143: GPRS:1111110000000000:Session timer stopped
Example 5
*Mar 1 00:05:52.399: GPRS:1111110000000000:PPP regen current state PPP CONNECTED
CONNECTED]
*Mar 1 00:05:52.403: GPRS:1111110000000000:PPP down
TERMINATING]
FAILED]
*Mar 1 00:05:52.407: GPRS:1111110000000000:PPP regen context 0x6219F4BC released
*Mar 1 00:05:52.407: GPRS:GTP-PPP-REGEN context magic(0x619D4FBC) invalid

changed state to downExample 6

May 2008 DB-805
Debug Commands
debug gprs gtp

*Mar 1 00:06:34.907: GPRS:1111110000000000:PPP regen current state PPP CONNECTED
CONNECTED]
*Mar 1 00:06:34.911: GPRS:1111110000000000:PPP down
TERMINATING]
FAILED]
*Mar 1 00:06:34.915: GPRS:1111110000000000:PPP regen context 0x62196E10 released
*Mar 1 00:06:34.915: GPRS:GTP-PPP-REGEN context magic(0x619D4FBC) invalid

DB-806 May 2008
Debug Commands
debug gprs radius
debug gprs radius

To display information about Remote Access Dial-In User Service (RADIUS) processing on the GGSN,
use the debug gprs radius privileged EXEC command. To disable debugging output, use the no form
of this command.
debug gprs radius
no debug gprs radius

with communication between a RADIUS server and the GGSN.
Caution Because the debug gprs radius command generates a significant amount of output, use it only when
Examples The following example enables the display of debug messages related to RADIUS processing on the
GGSN:
Router# debug gprs radius

May 2008 DB-807
Debug Commands
debug gprs redundancy

To display debug messages, errors, events, or packets related to GTP session redundancy (GTP-SR), use
the debug gprs redundancy privileged EXEC command. To disable debugging output, use the no form
of this command.
debug gprs redundancy [debug | errors | events | packets]
no debug gprs redundancy [debug | errors | events | packets]
Syntax Description debug Displays debug messages related to GTP-SR.

errors Displays errors related to GTP-SR.
events Displays events related to GTP-SR.
packets Displays packets related to GTP-SR packets.

12.3(11)YJ This command was introduced.
Usage Guidelines This command displays debug level messages, errors, events, or packets for GTP-SR. It is useful for
system operators and development engineers if problems are encountered with communication between
the two GGSNs configured as an redundant pair and on which GTP-SR is enabled.
Examples Example 1.
The following sample outputs is for a GGSN failover and switchover of Standby to Active. There is no
PDP context involved in this debug collection.
Active GGSN:
Router-a#show gprs redundancy
GPRS redundancy is enabled and Unit-Status is Standby
Redundancy Transport Infrastructure status

Redundancy Infrastructure state: STANDBY HOT
Peer Redundancy Infrastructure state: ACTIVE
GGSN Redundancy system up since: 21:29:21 EDT Aug 19 2000

Time of last switchover: never
Total Number of Switchovers: 2
GPRS Redundancy Statistics

Last cleared: never
CheckPointed-From-Active Statistics

DB-808 May 2008
Debug Commands
Total Number of Messages: 129

Number of Context Setup messages: 19
Number of Context Modify messages: 3
Number of Context Remove messages: 19
Number of Path Setup messages: 34
Number of Path Modify messages: 5
Number of Path Remove messages: 34
Number of CGF Ready messages: 1
Number of CGF Modify messages: 0
Number of CGF Remove messages: 0
Number of Internal State messages: 7
Router-a#debug gprs redundancy

GPRS CF packets debugging is on
GPRS CF events debugging is on
GPRS CF errors debugging is on
GPRS CF debug debugging is on
Router-a#
Router-a#
Router-a#
MWAM 10/2: 000064: Jun 1 2006 18:19:00.975 EDT: %HSRP-6-STATECHANGE:
GigabitEthernet0/0.1100 Grp 51 state Standby -> Active
MWAM 10/2: 000065: Jun 1 2006 18:19:00.975 EDT: GTP-SR:
RF_Status=403-RF_STATUS_MAINTENANCE_ENABLE RFState=9-ACTIVE-FAST operand=0
RFPeerState=13-ACTIVE
MWAM 10/2: 000066: Jun 1 2006 18:19:00.979 EDT: GTP-SR: RF_Event=200-RF_PROG_ACTIVE_FAST
RFState=9-ACTIVE-FAST operand=0 RFPeerState=13-ACTIVE
MWAM 10/2: 000067: Jun 1 2006 18:19:00.979 EDT: GTP-SR: Received RF Progression Active
Fast
MWAM 10/2: 000068: Jun 1 2006 18:19:00.979 EDT: GTP-SR: RF_Event=201-RF_PROG_ACTIVE_DRAIN
RFState=10-ACTIVE-DRAIN operand=0 RFPeerState=13-ACTIVE
Drain
RF_Event=202-RF_PROG_ACTIVE_PRECONFIG RFState=11-ACTIVE_PRECONFIG operand=0
PreConfig
RF_Event=203-RF_PROG_ACTIVE_POSTCONFIG RFState=12-ACTIVE_POSTCONFIG operand=0
PostConfig
MWAM 10/2: 000074: Jun 1 2006 18:19:00.979 EDT: GTP-SR: RF_Event=204-RF_PROG_ACTIVE
RFState=13-ACTIVE operand=0 RFPeerState=13-ACTIVE
MWAM 10/2: 000076: Jun 1 2006 18:19:00.979 EDT: GTP-SR: Start of the Standby-to-Active
transition
MWAM 10/2: 000077: Jun 1 2006 18:19:00.979 EDT: GTP_SR: Old State Standby,Event Active
Fast Received, New State Active
MWAM 10/2: 000078: Jun 1 2006 18:19:00.979 EDT: GTP-SR:Context Type OWN, Handler Sync,
Context Event OWN Ready, Context Sub Event No Sub Event
MWAM 10/2: 000079: Jun 1 2006 18:19:00.979 EDT: GTP-SR:State of Redundancy Context is
Initialized
MWAM 10/2: 000080: Jun 1 2006 18:19:00.979 EDT: GTP-SR: Event OWN Ready, Sub Event No Sub
Event
MWAM 10/2: 000081: Jun 1 2006 18:19:00.979 EDT: GTP-SR: Removing element from state-list
Initialized, final count 2
MWAM 10/2: 000082: Jun 1 2006 18:19:00.979 EDT: GTP-SR: adding element in state-list Bulk
Synch Ready, final count 2
MWAM 10/2: 000083: Jun 1 2006 18:19:00.979 EDT: GTP-SR:Context Type CGF, Handler Sync,
Context Event CGF Ready, Context Sub Event No Sub Event
Initialized

May 2008 DB-809
Debug Commands
MWAM 10/2: 000085: Jun 1 2006 18:19:00.979 EDT: GTP-SR: Event CGF Ready, Sub Event No Sub
Event
MWAM 10/2: 000088: Jun 1 2006 18:19:00.979 EDT: GTP-SR: Invalid shdb 0x0
MWAM 10/2: 000089: Jun 1 2006 18:19:00.979 EDT: GTP-SR: Transition CG 10.0.250.114 to
(state 0)
MWAM 10/2: 000090: Jun 1 2006 18:19:00.979 EDT: GTP-SR: Invalid shdb 0x0
MWAM 10/2: 000091: Jun 1 2006 18:19:00.979 EDT: GTP-SR: Transition CG 10.0.250.115 to
(state 0)
MWAM 10/2: 000092: Jun 1 2006 18:19:00.983 EDT: GTP-SR: SHDB AVL tree cleanup to start in
10 sec
MWAM 10/2: 000093: Jun 1 2006 18:19:00.983 EDT: GTP-SR: Completion of Standby-to-Active
transition
MWAM 10/2: 000094: Jun 1 2006 18:19:00.983 EDT: GTP-SR: Chkpt Status Flow Off Indication
RF_Status=400-RF_STATUS_PEER_PRESENCE RFState=13-ACTIVE operand=0 RFPeerState=13-ACTIVE
MWAM 10/2: 000097: Jun 1 2006 18:19:00.987 EDT: GTP-SR: zero elements to move to other
list
MWAM 10/2: 000098: Jun 1 2006 18:19:00.987 EDT: GTP-SR: zero elements to move to other
list
MWAM 10/2: 000099: Jun 1 2006 18:19:00.987 EDT: GTP-SR: RF_Status=401-RF_STATUS_PEER_COMM
RFState=13-ACTIVE operand=0 RFPeerState=1-DISABLED
Router-2#
MWAM 10/2: 000106: Jun 1 2006 18:19:10.983 EDT: GTP-SR: SHDB AVL tree cleanup has 3 nodes
removed, 0 leftover
Router-a#
Router-a#
Router-a#
MWAM 10/2: 000107: Jun 1 2006 18:20:25.947 EDT: GTP-SR: Chkpt Status Flow Off Indication
RF_Status=400-RF_STATUS_PEER_PRESENCE RFState=13-ACTIVE operand=1 RFPeerState=1-DISABLED
MWAM 10/2: 000109: Jun 1 2006 18:20:25.947 EDT: GTP-SR: RF_Status=401-RF_STATUS_PEER_COMM
RFState=13-ACTIVE operand=1 RFPeerState=1-DISABLED
RF_Event=300-RF_PROG_PLATFORM_SYNC RFState=13-ACTIVE operand=0 RFPeerState=0-UNKNOWN
MWAM 10/2: 000111: Jun 1 2006 18:20:25.947 EDT: GTP-SR: Received RF Progression Platform
Sync
RF_Event=102-RF_PROG_STANDBY_CONFIG RFState=13-ACTIVE operand=0 RFPeerState=5-STANDBY
COLD-CONFIG
MWAM 10/2: 000113: Jun 1 2006 18:20:53.899 EDT: GTP-SR: Received RF Progression Standby
Config
RF_Event=103-RF_PROG_STANDBY_FILESYS RFState=13-ACTIVE operand=0 RFPeerState=6-STANDBY
COLD-FILESYS
MWAM 10/2: 000115: Jun 1 2006 18:20:53.899 EDT: GTP-SR: Received RF Progression Stadnby
Filesys

DB-810 May 2008
Debug Commands
MWAM 10/2: 000116: Jun 1 2006 18:20:53.899 EDT: GTP-SR: RF_Event=104-RF_PROG_STANDBY_BULK

RFState=13-ACTIVE operand=0 RFPeerState=7-STANDBY COLD-BULK
Bulk
MWAM 10/2: 000118: Jun 1 2006 18:20:53.899 EDT: GTP-SR: Active GGSN sending Bulk Sync
finished Msg
MWAM 10/2: 000119: Jun 1 2006 18:20:53.899 EDT: GTP-SR: packing csg_path vaddr:
10.0.250.91
MWAM 10/2: 000120: Jun 1 2006 18:20:53.899 EDT: GTP-SR: packing csg_path port: 4386
MWAM 10/2: 000121: Jun 1 2006 18:20:53.899 EDT: GTP-SR: packing csg_path state: 1
MWAM 10/2: 000122: Jun 1 2006 18:20:53.899 EDT: GTP-SR: Ckpt Message was sucessfully sent
Bulk Synch Ready, final count 2
MWAM 10/2: 000124: Jun 1 2006 18:20:53.899 EDT: GTP-SR: adding element in state-list
Synched, final count 1
MWAM 10/2: 000125: Jun 1 2006 18:20:53.899 EDT: GTP-SR: sync next charging id 0x1C0AA436,
local rsn 0x6B76EBDE
MWAM 10/2: 000126: Jun 1 2006 18:20:53.899 EDT: GTP-SR: Packing Pair Boot time 21:29:21
EDT Aug 19 2000
MWAM 10/2: 000127: Jun 1 2006 18:20:53.899 EDT: GTP-SR: Packing Switcover Count 3
MWAM 10/2: 000128: Jun 1 2006 18:20:53.899 EDT: GTP-SR: Packing local restart_count 21
MWAM 10/2: 000132: Jun 1 2006 18:20:53.899 EDT: GTP-SR: sync cgf gw 10.0.250.114,
operatemode NOT ACTIVE, nextseq 0x7530
MWAM 10/2: 000133: Jun 1 2006 18:20:53.899 EDT: GTP-SR: sync cgf gw 10.0.250.115,
operatemode NOT ACTIVE, nextseq 0x7530
MWAM 10/2: 000137: Jun 1 2006 18:20:53.899 EDT: GTP-SR:Active took time of 0 msec to
transfer data for bulk sync
MWAM 10/2: 000138: Jun 1 2006 18:20:53.899 EDT: GTP-SR: Empty list to sync
MWAM 10/2: 000139: Jun 1 2006 18:20:53.899 EDT: GTP-SR: Redundancy RF Event Received is
Standby Bulk Sync End
MWAM 10/2: 000140: Jun 1 2006 18:20:53.899 EDT: GTP-SR: Redundancy Event is Invalid
MWAM 10/2: 000141: Jun 1 2006 18:20:53.899 EDT: GTP-SR: RF_Event=105-RF_PROG_STANDBY_HOT
RFState=13-ACTIVE operand=0 RFPeerState=8-STANDBY HOT
Hot
Router-b
Router-b#show gprs redundancy
GPRS redundancy is enabled and Unit-Status is Active

Redundancy Infrastructure state: ACTIVE
Peer Redundancy Infrastructure state: STANDBY HOT

Time of last switchover:

Last cleared: never
CheckPointed-To-Standby Statistics


May 2008 DB-811
Debug Commands

Example 2
The following sample outputs is for PDP context setup, prepaid user traffic, and then PDP context
teardown. The debug is given for both Active and Standby GGSN. There is no GGSN switchover.
Active GGSN:
Router-a#debug gprs redundancy
Router-a#show gprs redundancy
GPRS redundancy is enabled and Unit-Status is Active

Redundancy Infrastructure state: ACTIVE
Peer Redundancy Infrastructure state: STANDBY HOT

Time of last switchover:

Last cleared: never
CheckPointed-To-Standby Statistics

Router-a#
MWAM 10/2: 000073: Aug 24 2000 23:18:55.947 EDT: GTP-SR:pdpmcb handle for pdpmcb
(0x24D2FC3C) is (0x3A000001)
MWAM 10/2: 000074: Aug 24 2000 23:18:55.963 EDT: GTP-SR: Need to allocate redundancy
context
MWAM 10/2: 000075: Aug 24 2000 23:18:55.963 EDT: GTP-SR: adding element in state-list
context
MWAM 10/2: 000078: Aug 24 2000 23:18:55.963 EDT: GTP-SR:Context Type Path, Handler Sync,
Context Event Path Setup, Context Sub Event No Sub Event

DB-812 May 2008
Debug Commands
MWAM 10/2: 000079: Aug 24 2000 23:18:55.963 EDT: GTP-SR:State of Redundancy Context is
Initialized
MWAM 10/2: 000080: Aug 24 2000 23:18:55.963 EDT: GTP-SR: Event Path Setup, Sub Event No
Sub Event
MWAM 10/2: 000081: Aug 24 2000 23:18:55.963 EDT: GTP-SR: Removing element from state-list
Dynamic Sync Ready, final count 1
context
MWAM 10/2: 000085: Aug 24 2000 23:18:55.963 EDT: GTP-SR:Context Type Path, Handler Sync,
Initialized
MWAM 10/2: 000087: Aug 24 2000 23:18:55.963 EDT: GTP-SR: Event Path Setup, Sub Event No
Sub Event
MWAM 10/2: 000090: Aug 24 2000 23:18:55.963 EDT: GTP-SR:packing pathcb->gtpv 1
MWAM 10/2: 000091: Aug 24 2000 23:18:55.963 EDT: GTP-SR:Local IP address 166.11.0.11, and
port 2123
MWAM 10/2: 000092: Aug 24 2000 23:18:55.963 EDT: GTP-SR:Remote IP address 10.10.50.3, and
port 2123
MWAM 10/2: 000093: Aug 24 2000 23:18:55.963 EDT: GTP-SR:packing pathcb->num_data_socks 0
MWAM 10/2: 000094: Aug 24 2000 23:18:55.963 EDT: GTP-SR:packing pathcb->flags 9
MWAM 10/2: 000095: Aug 24 2000 23:18:55.963 EDT: GTP-SR:packing
pathcb->restart_count_remote 1
MWAM 10/2: 000096: Aug 24 2000 23:18:55.963 EDT: GTP-SR: Different lengths during path
create: allowed: 63, packed: 23
MWAM 10/2: 000097: Aug 24 2000 23:18:55.963 EDT: GTP-SR: Ckpt Message was sucessfully sent
MWAM 10/2: 000100: Aug 24 2000 23:18:55.963 EDT: GTP-SR:packing pathcb->gtpv 1
MWAM 10/2: 000101: Aug 24 2000 23:18:55.963 EDT: GTP-SR:Local IP address 166.11.0.11, and
port 2152
MWAM 10/2: 000102: Aug 24 2000 23:18:55.963 EDT: GTP-SR:Remote IP address 10.10.50.3, and
port 2152
MWAM 10/2: 000103: Aug 24 2000 23:18:55.967 EDT: GTP-SR:packing pathcb->num_data_socks 0
MWAM 10/2: 000104: Aug 24 2000 23:18:55.967 EDT: GTP-SR:packing pathcb->flags 8
pathcb->restart_count_remote 0
MWAM 10/2: 000106: Aug 24 2000 23:18:55.967 EDT: GTP-SR: Different lengths during path
create: allowed: 63, packed: 23
MWAM 10/2: 000110: Aug 24 2000 23:18:55.967 EDT: GTP-SR: Empty list to sync
MWAM 10/2: 000112: Aug 24 2000 23:19:01.583 EDT: GTP-SR: Creating red context for category
ID 4 username 100000000000000 on APN ms-apn
context

May 2008 DB-813
Debug Commands
MWAM 10/2: 000117: Aug 24 2000 23:19:01.583 EDT: GPRS:0100000000000050:shdb 0x95000008
created for category 4 (handle 0xD0000001)
MWAM 10/2: 000118: Aug 24 2000 23:19:01.591 EDT: GTP-SR: Don't checkpoint QP4QR Clear for
Create/Update after a Quota Push Resp
MWAM 10/2: 000119: Aug 24 2000 23:19:01.591 EDT: GTP-SR:Context Type PDP, Handler Sync,
Context Event Context Setup, Context Sub Event No Sub Event
Initialized
MWAM 10/2: 000121: Aug 24 2000 23:19:01.591 EDT: GTP-SR: Event Context Setup, Sub Event No
Sub Event
MWAM 10/2: 000124: Aug 24 2000 23:19:01.591 EDT: GTP-SR: for pdpmcb: 221 bytes to be
packed
MWAM 10/2: 000125: Aug 24 2000 23:19:01.591 EDT: GTP-SR: pdpmcb bitmap = 14346
MWAM 10/2: 000126: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpmcb->user-name
91100000000000000
MWAM 10/2: 000127: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpmcb->msisdn
9101000000000000F000
MWAM 10/2: 000128: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpmcb->selection_mode 0
MWAM 10/2: 000129: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpmcb->remove_staticIP 0
MWAM 10/2: 000130: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpmcb->llcframenum 0
MWAM 10/2: 000131: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpmcb->idle_timeout 3600
MWAM 10/2: 000132: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpmcb->session_timeout 0
MWAM 10/2: 000133: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpmcb->pdpmcb_handle
973078529
MWAM 10/2: 000134: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpmcb->shdb 2080374789
MWAM 10/2: 000135: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing apn_name ms-apn
MWAM 10/2: 000136: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing apnvalue ms-apn
MWAM 10/2: 000137: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpmcb->teid 4194305
MWAM 10/2: 000138: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpmcb->imsi
01000000000000F0
pdpmcb->pdpaddr.static_addr_allocated 0
pdpmcb->pdpaddr.dynamic_addr_allocated 1
pdpmcb->pdpaddr.dynamic_addr_requested 1
pdpmcb->pdpaddr.addr_source 3
pdpmcb->pdpaddr.allocated_prefix_len 16
pdpmcb->pdpaddr.aggregate_prefix_len 16
pdpmcb->pdpaddr.pdp_type_org 1
pdpmcb->pdpaddr.pdp_type_num 33
MWAM 10/2: 000147: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpmcb->pdpaddr.addrlen 6
MWAM 10/2: 000148: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpmcb-ggsn_addr_si
166.11.0.11
MWAM 10/2: 000149: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpmcb-ggsn_addr_data
166.11.0.11
MWAM 10/2: 000150: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpmcb->msisdn_len
9nGTP-SR:packing aaa charging profile index -1,
MWAM 10/2: 000151: Aug 24 2000 23:19:01.591 EDT: GTP-SR:pdpmcb encoded len_t 0
MWAM 10/2: 000152: Aug 24 2000 23:19:01.591 EDT: GTP-SR: pdpcb bitmap = 0
MWAM 10/2: 000153: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->teid_cntl_remote 1
MWAM 10/2: 000154: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->teid_data_local
4194306

DB-814 May 2008
Debug Commands
MWAM 10/2: 000155: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->teid_data_remote

1000
MWAM 10/2: 000156: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->tid
0100000000000050
MWAM 10/2: 000157: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing naspi = 5
MWAM 10/2: 000158: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->internal_flags
9175041
MWAM 10/2: 000159: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->mnrgflag 0
MWAM 10/2: 000160: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->open_cdr_sent 0
MWAM 10/2: 000161: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->charging_reserved 0
MWAM 10/2: 000162: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->pri 1
MWAM 10/2: 000163: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->fastswitchable 0
MWAM 10/2: 000164: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb-sgsn_addr_sig
10.10.50.3
MWAM 10/2: 000165: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb-sgsn_addr_data
10.10.50.3
MWAM 10/2: 000166: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->sequence_sig 1
MWAM 10/2: 000167: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->fl_sig_up 0
MWAM 10/2: 000168: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->fl_data1_up 0
MWAM 10/2: 000169: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->fl_sig_down 0
MWAM 10/2: 000170: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->fl_data1_down 0
MWAM 10/2: 000171: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->fl_data2 0
MWAM 10/2: 000172: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->cause 128
MWAM 10/2: 000173: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->restart_count 0
MWAM 10/2: 000174: Aug 24 2000 23:19:01.591 EDT: GTP-SR: packing pdpcb->create_time Aug 24
2000 23:18:56
MWAM 10/2: 000175: Aug 24 2000 23:19:01.591 EDT: GTP-SR: packing pdpcb->last_access_time
Aug 24 2000 23:18:56
pdpcb->gtpv1_qos_req.qos_profile 152109353l
pdpcb->gtpv1_qos_neg.qos_profile 152109353l
MWAM 10/2: 000178: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->teid_cntl_remote 1
MWAM 10/2: 000179: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->teid_data_local
4194306
MWAM 10/2: 000180: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->teid_data_remote
1000
MWAM 10/2: 000181: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->charging_id
471179447
MWAM 10/2: 000182: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing pdpcb->cdr_recseqnum 0
MWAM 10/2: 000183: Aug 24 2000 23:19:01.591 EDT: GTP-SR: packing of
pdpcb->reorder_required FF
MWAM 10/2: 000184: Aug 24 2000 23:19:01.591 EDT: GPRS:0100000000000050:
GTP-SR: Successfully pack PDP
MWAM 10/2: 000185: Aug 24 2000 23:19:01.591 EDT: GTP-SR: rulebase ID MS packed
MWAM 10/2: 000186: Aug 24 2000 23:19:01.591 EDT: GTP-SR: cc_session ccfh 0
failover_supported 1 reqnum 1 packed
MWAM 10/2: 000187: Aug 24 2000 23:19:01.591 EDT: GTP-SR: cc_session dest_host
ips-clcis1.cisco.com dest_realm cisco.com packed
MWAM 10/2: 000188: Aug 24 2000 23:19:01.591 EDT: GTP-SR: category ID 4 packed:
MWAM 10/2: 000189: Aug 24 2000 23:19:01.591 EDT: GTP-SR: sync data len 164
MWAM 10/2: 000190: Aug 24 2000 23:19:01.591 EDT: GTP-SR: active shdb 0x95000008
MWAM 10/2: 000191: Aug 24 2000 23:19:01.591 EDT: GTP-SR: CSG session ID 27599459844129
MWAM 10/2: 000192: Aug 24 2000 23:19:01.591 EDT: GTP-SR: chrg last svc rec seqnum 0
MWAM 10/2: 000193: Aug 24 2000 23:19:01.591 EDT: GTP-SR: category state AUTHORIZED
MWAM 10/2: 000194: Aug 24 2000 23:19:01.591 EDT: GTP-SR: category state trigger flags
0x3
MWAM 10/2: 000195: Aug 24 2000 23:19:01.591 EDT: GTP-SR: category sub flags 0x0
MWAM 10/2: 000196: Aug 24 2000 23:19:01.591 EDT: GTP-SR: sync flag 0x0
MWAM 10/2: 000197: Aug 24 2000 23:19:01.591 EDT: GTP-SR: quotas included
MWAM 10/2: 000198: Aug 24 2000 23:19:01.591 EDT: GTP-SR: last req timestamp 0
MWAM 10/2: 000199: Aug 24 2000 23:19:01.591 EDT: GTP-SR: last req seqnum 0

May 2008 DB-815
Debug Commands
MWAM 10/2: 000204: Aug 24 2000 23:19:03.939 EDT: GTP-SR:Context Type PDP, Handler Sync,
Synched
MWAM 10/2: 000206: Aug 24 2000 23:19:03.939 EDT: GTP-SR: Event Context Setup, Sub Event No
Sub Event
MWAM 10/2: 000207: Aug 24 2000 23:19:04.463 EDT: GTP-SR: Checkpoint SGSN init deletion via
a category before final MCB deletion
MWAM 10/2: 000208: Aug 24 2000 23:19:04.463 EDT: GTP-SR:Context Type Category, Handler
Update, Context Event Category update, Context Sub Event No Sub Event
Synched
MWAM 10/2: 000210: Aug 24 2000 23:19:04.463 EDT: GTP-SR: Event Category update, Sub Event
No Sub Event
MWAM 10/2: 000211: Aug 24 2000 23:19:04.463 EDT: GTP-SR: MCB internal flags 0x5802 packed
MWAM 10/2: 000212: Aug 24 2000 23:19:04.463 EDT: GTP-SR: cc_session reqnum 1 packed
MWAM 10/2: 000213: Aug 24 2000 23:19:04.463 EDT: GTP-SR: category ID 4 packed:
MWAM 10/2: 000214: Aug 24 2000 23:19:04.463 EDT: GTP-SR: sync data len 52
MWAM 10/2: 000215: Aug 24 2000 23:19:04.463 EDT: GTP-SR: active shdb 0x95000008
MWAM 10/2: 000216: Aug 24 2000 23:19:04.463 EDT: GTP-SR: CSG session ID 27599459844129
MWAM 10/2: 000217: Aug 24 2000 23:19:04.463 EDT: GTP-SR: chrg last svc rec seqnum 0
MWAM 10/2: 000218: Aug 24 2000 23:19:04.463 EDT: GTP-SR: category state
PENDING_SERVICE_STOP
MWAM 10/2: 000219: Aug 24 2000 23:19:04.463 EDT: GTP-SR: category state trigger flags
0x3
MWAM 10/2: 000220: Aug 24 2000 23:19:04.463 EDT: GTP-SR: category sub flags 0x0
MWAM 10/2: 000221: Aug 24 2000 23:19:04.463 EDT: GTP-SR: sync flag 0xA
MWAM 10/2: 000222: Aug 24 2000 23:19:04.463 EDT: GTP-SR: quotas not included
MWAM 10/2: 000223: Aug 24 2000 23:19:04.463 EDT: GTP-SR: last req timestamp 0
MWAM 10/2: 000224: Aug 24 2000 23:19:04.463 EDT: GTP-SR: last req seqnum 0
MWAM 10/2: 000225: Aug 24 2000 23:19:04.463 EDT: GTP-SR: Different lengths during category
sync: allowed 188, packed 56
MWAM 10/2: 000227: Aug 24 2000 23:19:04.467 EDT: GTP-SR: Checkpoint final MCB deletion
after sending a CCR Final
MWAM 10/2: 000228: Aug 24 2000 23:19:04.467 EDT: GTP-SR:Context Type PDP, Handler Delete,
Context Event Context Remove, Context Sub Event No Sub Event
Synched
MWAM 10/2: 000230: Aug 24 2000 23:19:04.467 EDT: GTP-SR: Event Context Remove, Sub Event
No Sub Event
MWAM 10/2: 000231: Aug 24 2000 23:19:04.467 EDT: GTP-SR: Checkpoint final MCB deletion
MWAM 10/2: 000232: Aug 24 2000 23:19:04.467 EDT: GTP-SR:Context Type PDP, Handler Delete,
Context Event Context Remove, Context Sub Event No Sub Event
Synched
MWAM 10/2: 000234: Aug 24 2000 23:19:04.467 EDT: GTP-SR: Event Context Remove, Sub Event
No Sub Event
MWAM 10/2: 000235: Aug 24 2000 23:19:04.467 EDT: GTP-SR: Different lengths during PDP
delete: allowed: 40, packed: 0
Delete, final count 1
Delete, final count 0
MWAM 10/2: 000240: Aug 24 2000 23:19:04.467 EDT: GTP-SR: No redundancy context for sending
a down event to standby

DB-816 May 2008
Debug Commands
Router-a#
Router-a#
Standby GGSN:
Router-b#debug gprs redundancy
Router-b#sh gprs redun
GPRS redundancy is enabled and Unit-Status is Standby

Redundancy Infrastructure state: STANDBY HOT
Peer Redundancy Infrastructure state: ACTIVE

Time of last switchover: never

Last cleared: never
CheckPointed-From-Active Statistics

Router-b#
Create Redundancy Context
MWAM 10/2: 000066: Jun 1 2006 18:28:06.591 EDT: GTP-SR: Redundancy Event is Path Setup
MWAM 10/2: 000067: Jun 1 2006 18:28:06.591 EDT: GTP-SR: Need to allocate redundancy
context
MWAM 10/2: 000069: Jun 1 2006 18:28:06.591 EDT: GTP-SR Packet Dump: Len for dump:
org_len=63, len=63
MWAM 10/2: 000070: Jun 1 2006 18:28:06.591 EDT: 1 0 0 0 0 0 0 0 9 1 A6 B 0 B
8 4B
MWAM 10/2: 000071: Jun 1 2006 18:28:06.591 EDT: A A 32 3 8 4B 1 0 0 0 0 0 0 0
0 0
MWAM 10/2: 000072: Jun 1 2006 18:28:06.591 EDT: 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0
MWAM 10/2: 000073: Jun 1 2006 18:28:06.595 EDT: 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0
MWAM 10/2: 000074: Jun 1 2006 18:28:06.595 EDT: GTP-SR: un-packing u_path->gtpv 1
MWAM 10/2: 000075: Jun 1 2006 18:28:06.595 EDT: GTP-SR: Local IP address 166.11.0.11, and
port 2123
MWAM 10/2: 000076: Jun 1 2006 18:28:06.595 EDT: GTP-SR: Remote IP address 10.10.50.3, and
port 2123

May 2008 DB-817
Debug Commands
MWAM 10/2: 000077: Jun 1 2006 18:28:06.595 EDT: GTP-SR: un-packing u_path->num_data_socks
0
MWAM 10/2: 000078: Jun 1 2006 18:28:06.595 EDT: GTP-SR: un-packing u_path->flags 9
MWAM 10/2: 000079: Jun 1 2006 18:28:06.595 EDT: GTP-SR: un-packing restart_count_remote 1
MWAM 10/2: 000080: Jun 1 2006 18:28:06.595 EDT: GTP-SR:Context Type Path, Handler Sync,
Initialized
MWAM 10/2: 000082: Jun 1 2006 18:28:06.595 EDT: GTP-SR: Event Path Setup, Sub Event No
Sub Event
MWAM 10/2: 000086: Jun 1 2006 18:28:06.595 EDT: GTP-SR: Redundancy Event is Path Setup
context
org_len=63, len=63
MWAM 10/2: 000090: Jun 1 2006 18:28:06.595 EDT: 1 0 0 0 0 0 0 0 8 1 A6 B 0 B
8 68
MWAM 10/2: 000091: Jun 1 2006 18:28:06.595 EDT: A A 32 3 8 68 0 0 0 0 0 0 0 0
0 0
MWAM 10/2: 000092: Jun 1 2006 18:28:06.595 EDT: 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0
MWAM 10/2: 000093: Jun 1 2006 18:28:06.595 EDT: 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0
MWAM 10/2: 000094: Jun 1 2006 18:28:06.595 EDT: GTP-SR: un-packing u_path->gtpv 1
MWAM 10/2: 000095: Jun 1 2006 18:28:06.595 EDT: GTP-SR: Local IP address 166.11.0.11, and
port 2152
MWAM 10/2: 000096: Jun 1 2006 18:28:06.595 EDT: GTP-SR: Remote IP address 10.10.50.3, and
port 2152
MWAM 10/2: 000097: Jun 1 2006 18:28:06.595 EDT: GTP-SR: un-packing u_path->num_data_socks
0
MWAM 10/2: 000098: Jun 1 2006 18:28:06.595 EDT: GTP-SR: un-packing u_path->flags 8
MWAM 10/2: 000099: Jun 1 2006 18:28:06.595 EDT: GTP-SR: un-packing restart_count_remote 0
MWAM 10/2: 000100: Jun 1 2006 18:28:06.595 EDT: GTP-SR:Context Type Path, Handler Sync,
Initialized
MWAM 10/2: 000102: Jun 1 2006 18:28:06.595 EDT: GTP-SR: Event Path Setup, Sub Event No
Sub Event
MWAM 10/2: 000106: Jun 1 2006 18:28:12.223 EDT: GTP-SR: Redundancy Event is Context Setup
context
org_len=755, len=128
MWAM 10/2: 000110: Jun 1 2006 18:28:12.223 EDT: 1 1 39 31 31 30 30 30 30 30 30 30 30
30 30 30
MWAM 10/2: 000111: Jun 1 2006 18:28:12.223 EDT: 30 30 30 0 0 0 0 91 1 0 0 0 0 0
0 F0

DB-818 May 2008
Debug Commands
MWAM 10/2: 000112: Jun 1 2006 18:28:12.223 EDT: 0 0 0 0 0 0 E 10 0 0 0 0 0 0

0 0
MWAM 10/2: 000113: Jun 1 2006 18:28:12.223 EDT: C0 23 1 8 5 63 69 73 63 6F 31 31 31
63 69 73
MWAM 10/2: 000114: Jun 1 2006 18:28:12.227 EDT: 63 6F 0 7C 0 0 5 0 0 8 0 0 0 0
0 0
MWAM 10/2: 000115: Jun 1 2006 18:28:12.227 EDT: 0 0 0 40 0 1 1 0 0 0 0 0 0
F0 B 1
MWAM 10/2: 000116: Jun 1 2006 18:28:12.227 EDT: 0 1 0 0 0 0 0 0 0 0 0 0 0 0
0 0
MWAM 10/2: 000117: Jun 1 2006 18:28:12.227 EDT: 0 0 0 1 1 0 0 0 3 10 10 1 21 0
6 0
MWAM 10/2: 000118: Jun 1 2006 18:28:12.227 EDT: ...
MWAM 10/2: 000119: Jun 1 2006 18:28:12.231 EDT: GTP-SR:pdpmcb handle for pdpmcb
(0x24AA0CCC) is (0x41000001)
MWAM 10/2: 000120: Jun 1 2006 18:28:12.231 EDT: GTP-SR: un-packing # of PDPs packed = 1
MWAM 10/2: 000121: Jun 1 2006 18:28:12.231 EDT: GTP-SR: un-packing pdpmcb->user-name
91100000000000000
MWAM 10/2: 000122: Jun 1 2006 18:28:12.231 EDT: GTP-SR: un-packing pdpmcb->msisdn
9101000000000000F000
MWAM 10/2: 000123: Jun 1 2006 18:28:12.235 EDT: GTP-SR: un-packing pdpmcb->selection_mode
0
MWAM 10/2: 000124: Jun 1 2006 18:28:12.235 EDT: GTP-SR: un-packing
pdpmcb->remove_staticIP 0
MWAM 10/2: 000125: Jun 1 2006 18:28:12.235 EDT: GTP-SR: un-packing pdpmcb->llcframenum 0
MWAM 10/2: 000126: Jun 1 2006 18:28:12.235 EDT: GTP-SR: un-packing pdpmcb->idle_timeout
3600
pdpmcb->session_timeout 0
MWAM 10/2: 000128: Jun 1 2006 18:28:12.235 EDT: GTP-SR: pdpmcb bitmap = 30730
MWAM 10/2: 000129: Jun 1 2006 18:28:12.235 EDT: GTP-SR: apn name is ms-apn
MWAM 10/2: 000130: Jun 1 2006 18:28:12.235 EDT: GTP-SR: packing pdpmcb->teid 4194305
MWAM 10/2: 000131: Jun 1 2006 18:28:12.235 EDT: GTP-SR: un-packing pdpmcb->imsi
01000000000000F0
pdpmcb->pdpaddr.pdp_addr 11.1.0.1
pdpmcb->pdpaddr.static_addr_allocated 0
pdpmcb->pdpaddr.dynamic_addr_allocated 1
pdpmcb->pdpaddr.dynamic_addr_requested 1
pdpmcb->pdpaddr.addr_source 3
pdpmcb->pdpaddr.allocated_prefix_len 16
pdpmcb->pdpaddr.aggregate_prefix_len 16
pdpmcb->pdpaddr.pdp_type_org 1
pdpmcb->pdpaddr.pdp_type_num 33
pdpmcb->pdpaddr.addrlen 6
pdpmcb->pdpaddr.dhcp_addr 0.0.0.0
MWAM 10/2: 000143: Jun 1 2006 18:28:12.235 EDT: GTP-SR: un-packing pdpmcb-ggsn_addr_si
166.11.0.11
MWAM 10/2: 000144: Jun 1 2006 18:28:12.235 EDT: GTP-SR: un-packing pdpmcb-ggsn_addr_data
166.11.0.11
MWAM 10/2: 000145: Jun 1 2006 18:28:12.235 EDT: GTP-SR: un-packing pdpmcb->msisdn_len 9
MWAM 10/2: 000146: Jun 1 2006 18:28:12.247 EDT: GTP-SR: Got teid=4194305, as requested

May 2008 DB-819
Debug Commands

pdpcb->gtpv1_qos_req.qos_profile 152109353l
pdpcb->gtpv1_qos_neg.qos_profile 152109353l
MWAM 10/2: 000149: Jun 1 2006 18:28:12.247 EDT: GTP-SR: un-packing pdpcb bitmap = 0
pdpcb->tid0100000000000050
MWAM 10/2: 000151: Jun 1 2006 18:28:12.251 EDT: GTP-SR: un-packing nsapi = 5
MWAM 10/2: 000152: Jun 1 2006 18:28:12.251 EDT: GTP-SR: un-packing pdpcb->internal_flags
9175041
MWAM 10/2: 000153: Jun 1 2006 18:28:12.251 EDT: GTP-SR: un-packing pdpcb->mnrgflag 0
MWAM 10/2: 000154: Jun 1 2006 18:28:12.251 EDT: GTP-SR: un-packing pdpcb->open_cdr_sent
0
pdpcb->charging_reserved 0
MWAM 10/2: 000156: Jun 1 2006 18:28:12.251 EDT: GTP-SR: un-packing pdpcb->pri 1
MWAM 10/2: 000157: Jun 1 2006 18:28:12.251 EDT: GTP-SR: un-packing pdpcb->fastswitchable
0
MWAM 10/2: 000158: Jun 1 2006 18:28:12.251 EDT: GTP-SR: un-packing pdpcb-sgsn_addr_sig
10.10.50.3
MWAM 10/2: 000159: Jun 1 2006 18:28:12.251 EDT: GTP-SR: un-packing pdpcb-sgsn_addr_data
10.10.50.3
MWAM 10/2: 000160: Jun 1 2006 18:28:12.251 EDT: GTP-SR: un-packing of pdpcb->sequence_sig
1
MWAM 10/2: 000161: Jun 1 2006 18:28:12.251 EDT: GTP-SR: un-packing of pdpcb->fl_sig_up 0
MWAM 10/2: 000162: Jun 1 2006 18:28:12.251 EDT: GTP-SR: un-packing of pdpcb->fl_data1_up
0
MWAM 10/2: 000163: Jun 1 2006 18:28:12.251 EDT: GTP-SR: un-packing of pdpcb->fl_sig_down
0
MWAM 10/2: 000164: Jun 1 2006 18:28:12.251 EDT: GTP-SR: un-packing of
pdpcb->fl_data1_down 0
MWAM 10/2: 000165: Jun 1 2006 18:28:12.251 EDT: GTP-SR: un-packing of pdpcb->fl_data2 0
MWAM 10/2: 000166: Jun 1 2006 18:28:12.251 EDT: GTP-SR: un-packing of pdpcb->cause 128
pdpcb->restart_count 0
MWAM 10/2: 000168: Jun 1 2006 18:28:12.251 EDT: GTP-SR: un-packing of pdpcb->create_time
Apr 13 2006 01:25:25
pdpcb->last_access_time Apr 13 2006 01:25:25
MWAM 10/2: 000170: Jun 1 2006 18:28:12.251 EDT: GTP-SR: unpacking pdpcb->teid_cntl_remote
1
MWAM 10/2: 000171: Jun 1 2006 18:28:12.251 EDT: GTP-SR: unpacking pdpcb->teid_data_local
4194306
MWAM 10/2: 000172: Jun 1 2006 18:28:12.251 EDT: GTP-SR: unpacking pdpcb->teid_data_remote
1000
MWAM 10/2: 000173: Jun 1 2006 18:28:12.251 EDT: GTP-SR: unpacking pdpcb->charging_id
471179447
MWAM 10/2: 000174: Jun 1 2006 18:28:12.251 EDT: GTP-SR: unpacking pdpcb->cdr_recseqnum 0
pdpcb->reorder_required FF
MWAM 10/2: 000176: Jun 1 2006 18:28:12.251 EDT: GTP-SR: We wanted teid 4194306, and got
4194306
MWAM 10/2: 000177: Jun 1 2006 18:28:12.251 EDT: GTP-SR: Got teid 4194306 as requested
MWAM 10/2: 000178: Jun 1 2006 18:28:12.251 EDT: pdp_create_by_tid on standby:tid
100000050, pdp 24A90B24
MWAM 10/2: 000179: Jun 1 2006 18:28:12.251 EDT: GPRS:0100000000000050:
GTP-SR: Successfully unpack PDP
MWAM 10/2: 000180: Jun 1 2006 18:28:12.251 EDT: GTP-SR: rulebase ID MS unpacked
MWAM 10/2: 000181: Jun 1 2006 18:28:12.251 EDT: GTP-SR: cc_session ccfh 0
failover_supported 1 reqnum 1 packed
MWAM 10/2: 000182: Jun 1 2006 18:28:12.251 EDT: GTP-SR: new cc_session dest_host
ips-clcis1.cisco.com unpacked
MWAM 10/2: 000183: Jun 1 2006 18:28:12.251 EDT: GTP-SR: new cc_session dest_realm
cisco.com unpacked

DB-820 May 2008
Debug Commands
MWAM 10/2: 000184: Jun 1 2006 18:28:12.251 EDT: GTP-SR: Unpacking 1 categories
MWAM 10/2: 000185: Jun 1 2006 18:28:12.251 EDT: GTP-SR: Unpacking category of ID 4
MWAM 10/2: 000186: Jun 1 2006 18:28:12.255 EDT: GTP-SR: Creating red context for category
ID 4 username 100000000000000 on APN ms-apn
context
MWAM 10/2: 000191: Jun 1 2006 18:28:12.255 EDT: GPRS:0100000000000050:shdb 0xC6000008
created for category 4 (handle 0xDE000001)
MWAM 10/2: 000192: Jun 1 2006 18:28:12.255 EDT: GTP-SR: red context installed for the new
category (shdb: active 0x95000008, standby 0xC6000008)
MWAM 10/2: 000193: Jun 1 2006 18:28:12.255 EDT: GTP-SR: new category ID 4 unpacked:
MWAM 10/2: 000194: Jun 1 2006 18:28:12.255 EDT: GTP-SR: sync data len 164
MWAM 10/2: 000195: Jun 1 2006 18:28:12.255 EDT: GTP-SR: active shdb 0x95000008
MWAM 10/2: 000196: Jun 1 2006 18:28:12.255 EDT: GTP-SR: CSG session ID 27599459844129
MWAM 10/2: 000197: Jun 1 2006 18:28:12.255 EDT: GTP-SR: chrg last svc rec seqnum 0
MWAM 10/2: 000198: Jun 1 2006 18:28:12.255 EDT: GTP-SR: category state AUTHORIZED
MWAM 10/2: 000199: Jun 1 2006 18:28:12.255 EDT: GTP-SR: category state trigger flags
0x3
MWAM 10/2: 000200: Jun 1 2006 18:28:12.255 EDT: GTP-SR: category sub flags 0x0
MWAM 10/2: 000201: Jun 1 2006 18:28:12.255 EDT: GTP-SR: sync flag 0x0
MWAM 10/2: 000202: Jun 1 2006 18:28:12.255 EDT: GTP-SR: quotas included
MWAM 10/2: 000203: Jun 1 2006 18:28:12.255 EDT: GTP-SR: last req timestamp 0
MWAM 10/2: 000204: Jun 1 2006 18:28:12.255 EDT: GTP-SR: last req seqnum 0
MWAM 10/2: 000205: Jun 1 2006 18:28:12.255 EDT: GTP-SR: address received from active with
radius source is
MWAM 10/2: 000206: Jun 1 2006 18:28:12.259 EDT: GTP-SR:Context Type PDP, Handler Sync,
Initialized
MWAM 10/2: 000208: Jun 1 2006 18:28:12.259 EDT: GTP-SR: Event Context Setup, Sub Event No
Sub Event
Update Redundancy Context
MWAM 10/2: 000212: Jun 1 2006 18:28:15.091 EDT: GTP-SR: Redundancy Event is Category
update
MWAM 10/2: 000213: Jun 1 2006 18:28:15.091 EDT: GTP-SR: red context found (active shdb
0x95000008, standby shdb 0xC6000008)
org_len=188, len=128
MWAM 10/2: 000215: Jun 1 2006 18:28:15.091 EDT: 7C 0 0 5 0 0 58 2 0 0 0 1 0
34 34 0
MWAM 10/2: 000216: Jun 1 2006 18:28:15.091 EDT: 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 95
MWAM 10/2: 000217: Jun 1 2006 18:28:15.091 EDT: 0 0 8 0 0 19 1A 0 0 0 21 0 0 0
0 0
MWAM 10/2: 000218: Jun 1 2006 18:28:15.091 EDT: 0 0 9 0 0 0 3 0 0 A 0 0 0 0
0 0
MWAM 10/2: 000219: Jun 1 2006 18:28:15.091 EDT: 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0
MWAM 10/2: 000220: Jun 1 2006 18:28:15.095 EDT: 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0
MWAM 10/2: 000221: Jun 1 2006 18:28:15.095 EDT: 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0

May 2008 DB-821
Debug Commands
MWAM 10/2: 000222: Jun 1 2006 18:28:15.095 EDT: 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0
MWAM 10/2: 000223: Jun 1 2006 18:28:15.095 EDT: ...
MWAM 10/2: 000224: Jun 1 2006 18:28:15.095 EDT: GTP-SR: category found with handle
0xDE000001 shdbs: active 0x95000008 standby 0xC6000008 (MCB shdbs: active 0x7C000005,
standby 0xC6000008)
MWAM 10/2: 000225: Jun 1 2006 18:28:15.095 EDT: GTP-SR: MCB internal flags 0x5802
unpacked
MWAM 10/2: 000226: Jun 1 2006 18:28:15.095 EDT: GTP-SR: cc_session reqnum 1 unpacked and
installed
MWAM 10/2: 000227: Jun 1 2006 18:28:15.095 EDT: GTP-SR: Unpacking category of ID 4
MWAM 10/2: 000228: Jun 1 2006 18:28:15.095 EDT: GTP-SR: sync obj created in prep for MCB
deletion
MWAM 10/2: 000229: Jun 1 2006 18:28:15.095 EDT: GTP-SR: category ID 4 unpacked:
MWAM 10/2: 000230: Jun 1 2006 18:28:15.095 EDT: GTP-SR: sync data len 52
MWAM 10/2: 000231: Jun 1 2006 18:28:15.095 EDT: GTP-SR: active shdb 0x95000008
MWAM 10/2: 000232: Jun 1 2006 18:28:15.095 EDT: GTP-SR: CSG session ID 27599459844129
MWAM 10/2: 000233: Jun 1 2006 18:28:15.095 EDT: GTP-SR: chrg last svc rec seqnum 0
MWAM 10/2: 000234: Jun 1 2006 18:28:15.095 EDT: GTP-SR: category state
PENDING_SERVICE_STOP
MWAM 10/2: 000235: Jun 1 2006 18:28:15.095 EDT: GTP-SR: category state trigger flags
0x3
MWAM 10/2: 000236: Jun 1 2006 18:28:15.095 EDT: GTP-SR: category sub flags 0x0
MWAM 10/2: 000237: Jun 1 2006 18:28:15.095 EDT: GTP-SR: sync flag 0xA
MWAM 10/2: 000238: Jun 1 2006 18:28:15.095 EDT: GTP-SR: quotas not included
MWAM 10/2: 000239: Jun 1 2006 18:28:15.095 EDT: GTP-SR: last req timestamp 0
MWAM 10/2: 000240: Jun 1 2006 18:28:15.095 EDT: GTP-SR: last req seqnum 0
Redundancy Context Delete
MWAM 10/2: 000242: Jun 1 2006 18:28:15.095 EDT: GTP-SR: Redundancy Event is Context
Remove
org_len=40, len=40
MWAM 10/2: 000244: Jun 1 2006 18:28:15.095 EDT: 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0
MWAM 10/2: 000245: Jun 1 2006 18:28:15.095 EDT: 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0
MWAM 10/2: 000246: Jun 1 2006 18:28:15.095 EDT: 0 0 0 0 0 0 0 0
MWAM 10/2: 000247: Jun 1 2006 18:28:15.095 EDT: GPRS:GTP-SR: Deleting v1 MCB on the
standby
MWAM 10/2: 000248: Jun 1 2006 18:28:15.095 EDT: GPRS:0100000000000050:GTP-SR: Deleting v1
PDP on the standby
MWAM 10/2: 000249: Jun 1 2006 18:28:15.095 EDT: GTP-SR: MCB deletion sync obj deleted
MWAM 10/2: 000253: Jun 1 2006 18:29:15.103 EDT: GTP-SR: Redundancy Event is Path Remove
MWAM 10/2: 000254: Jun 1 2006 18:29:15.103 EDT: GTP-SR:Context Type Path, Handler
Delete, Context Event Path Remove, Context Sub Event No Sub Event
Bulk Synch Ready
MWAM 10/2: 000256: Jun 1 2006 18:29:15.103 EDT: GTP-SR: Event Path Remove, Sub Event No
Sub Event
MWAM 10/2: 000259: Jun 1 2006 18:29:15.103 EDT: GTP-SR: Redundancy Event is Path Remove
MWAM 10/2: 000260: Jun 1 2006 18:29:15.103 EDT: GTP-SR:Context Type Path, Handler
Delete, Context Event Path Remove, Context Sub Event No Sub Event

DB-822 May 2008
Debug Commands
Bulk Synch Ready
MWAM 10/2: 000262: Jun 1 2006 18:29:15.103 EDT: GTP-SR: Event Path Remove, Sub Event No
Sub Event

clear gprs redundancy Clears statistics related to GTP-SR.
statistics
gprs redundancy Enables GTP-SR on a GGSN.
gprs redundancy Configures the window size used to determine when the CDR record
charging sync-window sequence number needs to be synchronized to the Standby GGSN.
cdr rec-seqnum
gprs redundancy Configures the window size used to determine when the GTP sequence
charging sync-window number needs to be synchronized to the Standby GGSN.
gtpp seqnum
show gprs redundancy Displays statistics related to GTP-SR.

May 2008 DB-823
Debug Commands
debug gvrp
debug gvrp
To display GVRP debugging information, use the debug gvrp command in privileged EXEC mode. To
disable debugging outpu, use the no form of this command.
debug gvrp {all | config | error | event | ha | packets | switch}
no debug gvrp
Syntax Description all (Optional) Enables all levels of debugging

config (Optional) Displays user configuration.
error (Optional) Enables error level debugging.
event
ha
packets (Optional) Enables packet level debugging.
switch (Optional) Enables switch level debugging.
Command Default

Usage Guidelines Conditional interface debugging can be used to limit the debugging output messages related to an
interface.
Examples The following example shows how to enable all levels of debugging:
debug gvrp all

show gvrp interface Displays details of the adininstrative and operational GVRP states of all or
one particular .1Q trunk port in the device.
show gvrp summary Displays the GVRP configuration at the device leve.

DB-824 May 2008
Debug Commands
debug h225 asn1
debug h225 asn1

To display ASN1 contents of RAS and Q.931 messages, use the debug h255 asn1 privileged EXEC command.
The no form of this command disables debugging output.
debug h255 asn1
no debug h255 asn1

11.3(2)NA This command was introduced.
Usage Guidelines
Caution This command slows down the system considerably. Connections may time out.
Examples Example 1
The following output shows two proxy call scenarios. A trace is collected on the gatekeeper with ASN1
turned on. The call is being established.
Router# debug h225 asn1
H.225 ASN1 Messages debugging is on

Router#24800006 03C00030 00300036 00380041 00450037 00430030 00300030 00300030
00300030 00310140 0F007000 74006500 6C003200 33004000 7A006F00 6E006500
32002E00 63006F00 6D020180 AAAA4006 00700074 0065006C 00320031 0033401E
0000015F C8490FB4 B9D111BF AF0060B0 00E94500
value RasMessage ::= admissionRequest :
{
requestSeqNum 7,
callType pointToPoint : NULL,
endpointIdentifier "0068AE7C00000001",
destinationInfo
{
h323-ID : "ptel23@zone2.com"
},
srcInfo
{
e164 : "7777",
h323-ID : "ptel213"
},
bandWidth 7680,
callReferenceValue 1,

May 2008 DB-825
Debug Commands
debug h225 asn1
conferenceID '5FC8490FB4B9D111BFAF0060B000E945'H,
activeMC FALSE,
answerCall FALSE
}
value RasMessage ::= admissionConfirm :
{
requestSeqNum 7,
bandWidth 7680,
callModel direct : NULL,
destCallSignalAddress ipAddress :
{
ip '65000001'H,
port 1720
},
irrFrequency 30
}
29000006 401E0000 65000001 06B8001D
2480001D 03C00030 00300036 00380041 00390036 00300030 00300030 00300030
00300030 00320140 0F007000 74006500 6C003200 33004000 7A006F00 6E006500
32002E00 63006F00 6D014006 00700074 0065006C 00320031 00334002 8000015F
C8490FB4 B9D111BF AF0060B0 00E94540
{
requestSeqNum 30,
endpointIdentifier "0068A96000000002",
destinationInfo
{
},
srcInfo
{
h323-ID : "ptel213"
},
bandWidth 640,
activeMC FALSE,
answerCall TRUE
}
value ACFnonStandardInfo ::=
{
srcTerminalAlias
{
e164 : "7777",
h323-ID : "ptel213"
},
dstTerminalAlias
{
},
dstProxyAlias
{
h323-ID : "px2"
},
dstProxySignalAddress
{
ip '66000001'H,
port 1720
}
}
C00203AA AA800600 70007400 65006C00 32003100 3301800F 00700074 0065006C
00320033 0040007A 006F006E 00650032 002E0063 006F006D 01800200 70007800
32660000 0106B8

DB-826 May 2008
Debug Commands
debug h225 asn1

{
requestSeqNum 30,
bandWidth 7680,
{
ip '66000001'H,
port 1720
},
irrFrequency 30,
nonStandardData
{
nonStandardIdentifier h221NonStandard :
{
t35CountryCode 181,
t35Extension 0,
manufacturerCode 18
},
data
'C00203AAAA8006007000740065006C00320031003301800F007000740065006C003200 ...'H
}
}
2980001D 401E0000 66000001 06B8001D 40B50000 1247C002 03AAAA80 06007000
74006500 6C003200 31003301 800F0070 00740065 006C0032 00330040 007A006F
006E0065 0032002E 0063006F 006D0180 02007000 78003266 00000106 B8
24C0001E 03C00030 00300036 00380041 00390036 00300030 00300030 00300030
00300030 00320140 0F007000 74006500 6C003200 33004000 7A006F00 6E006500
32002E00 63006F00 6D006600 000106B8 020180AA AA400600 70007400 65006C00
32003100 33401E00 00435FC8 490FB4B9 D111BFAF 0060B000 E94500
{
requestSeqNum 31,
destinationInfo
{
},
{
ip '66000001'H,
port 1720
},
srcInfo
{
e164 : "7777",
h323-ID : "ptel213"
},
bandWidth 7680,
activeMC FALSE,
answerCall FALSE
}
{
requestSeqNum 31,
bandWidth 7680,
{
ip '66000001'H,
port 1720

May 2008 DB-827
Debug Commands
debug h225 asn1
},
irrFrequency 30
}
Example 2
The following output shows two proxy call scenarios. A trace is collected on the source proxy with
ASN1 turned on. The call is being torn down

Router#
value H323-UserInformation ::=
{
h323-uu-pdu
{
h323-message-body setup :
{
protocolIdentifier { 0 0 8 2250 0 1 },
sourceAddress
{
h323-ID : "ptel213"
},
sourceInfo
{
terminal
{
},
mc FALSE,
undefinedNode FALSE
},
destinationAddress
{
},
activeMC FALSE,
conferenceGoal create : NULL,
sourceCallSignalAddress ipAddress :
{
ip '3200000C'H,
port 1720
}
}
}
}
{
requestSeqNum 30,
destinationInfo
{
},
srcInfo
{
h323-ID : "ptel213"
},
bandWidth 640,

DB-828 May 2008
Debug Commands
debug h225 asn1
activeMC FALSE,
answerCall TRUE
}
2480001D 03C00030 00300036 00380041 00390036 00300030 00300030 00300030
00300030 00320140 0F007000 74006500 6C003200 33004000 7A006F00 6E006500
32002E00 63006F00 6D014006 00700074 0065006C 00320031 00334002 8000015F
C8490FB4 B9D111BF AF0060B0 00E94540
2980001D 401E0000 66000001 06B8001D 40B50000 1247C002 03AAAA80 06007000
74006500 6C003200 31003301 800F0070 00740065 006C0032 00330040 007A006F
006E0065 0032002E 0063006F 006D0180 02007000 78003266 00000106 B8
{
requestSeqNum 30,
bandWidth 7680,
{
ip '66000001'H,
port 1720
},
irrFrequency 30,
nonStandardData
{
nonStandardIdentifier h221NonStandard :
{
t35CountryCode 181,
t35Extension 0,
manufacturerCode 18
},
data
'C00203AAAA8006007000740065006C00320031003301800F007000740065006C003200 ...'H
}
}
C00203AA AA800600 70007400 65006C00 32003100 3301800F 00700074 0065006C
00320033 0040007A 006F006E 00650032 002E0063 006F006D 01800200 70007800
32660000 0106B8
value ACFnonStandardInfo ::=
{
srcTerminalAlias
{
e164 : "7777",
h323-ID : "ptel213"
},
dstTerminalAlias
{
},
dstProxyAlias
{
h323-ID : "px2"
},
dstProxySignalAddress
{
ip '66000001'H,
port 1720
}
}
{
requestSeqNum 31,
destinationInfo
{

May 2008 DB-829
Debug Commands
debug h225 asn1
},
{
ip '66000001'H,
port 1720
},
srcInfo
{
e164 : "7777",
h323-ID : "ptel213"
},
bandWidth 7680,
activeMC FALSE,
answerCall FALSE
}
24C0001E 03C00030 00300036 00380041 00390036 00300030 00300030 00300030
00300030 00320140 0F007000 74006500 6C003200 33004000 7A006F00 6E006500
32002E00 63006F00 6D006600 000106B8 020180AA AA400600 70007400 65006C00
32003100 33401E00 00435FC8 490FB4B9 D111BFAF 0060B000 E94500
2900001E 401E0000 66000001 06B8001D
{
requestSeqNum 31,
bandWidth 7680,
{
ip '66000001'H,
port 1720
},
irrFrequency 30
}
{
h323-uu-pdu
{
h323-message-body callProceeding :
{
destinationInfo
{
gateway
{
protocol
{
h323 :
{
}
}
},
mc FALSE,
undefinedNode FALSE
}
}
}
}
01000600 08914A00 01088001 2800
{
h323-uu-pdu
{

DB-830 May 2008
Debug Commands
debug h225 asn1
h323-message-body setup :
{
sourceAddress
{
h323-ID : "ptel213"
},
sourceInfo
{
vendor
{
vendor
{
t35CountryCode 181,
t35Extension 0,
manufacturerCode 18
}
},
gateway
{
protocol
{
h323 :
{
}
}
},
mc FALSE,
undefinedNode FALSE
},
destinationAddress
{
},
{
ip '66000001'H,
port 1720
},
activeMC FALSE,
conferenceGoal create : NULL,
sourceCallSignalAddress ipAddress :
{
ip '65000001'H,
port 1720
},
remoteExtensionAddress h323-ID : "ptel23@zone2.com"
}
}
}
00B80600 08914A00 01014006 00700074 0065006C 00320031 00332800 B5000012
40012800 01400F00 70007400 65006C00 32003300 40007A00 6F006E00 65003200
2E006300 6F006D00 66000001 06B8005F C8490FB4 B9D111BF AF0060B0 00E94500
0E070065 00000106 B822400F 00700074 0065006C 00320033 0040007A 006F006E
00650032 002E0063 006F006D
{
h323-uu-pdu
{
h323-message-body callProceeding :
{

May 2008 DB-831
Debug Commands
debug h225 asn1
destinationInfo
{
gateway
{
protocol
{
h323 :
{
}
}
},
mc FALSE,
undefinedNode FALSE
}
}
}
}
{
h323-uu-pdu
{
h323-message-body alerting :
{
destinationInfo
{
mc FALSE,
undefinedNode FALSE
}
}
}
}
{
h323-uu-pdu
{
h323-message-body alerting :
{
destinationInfo
{
mc FALSE,
undefinedNode FALSE
}
}
}
}
03000600 08914A00 010000
{
h323-uu-pdu
{
h323-message-body connect :
{
h245Address ipAddress :
{
ip '66000001'H,
port 11011
},
destinationInfo
{
gateway
{

DB-832 May 2008
Debug Commands
debug h225 asn1
protocol
{
h323 :
{
}
}
},
mc FALSE,
undefinedNode FALSE
},
conferenceID '5FC8490FB4B9D111BFAF0060B000E945'H
}
}
}
{
h323-uu-pdu
{
h323-message-body connect :
{
h245Address ipAddress :
{
ip '65000001'H,
port 11007
},
destinationInfo
{
gateway
{
protocol
{
h323 :
{
}
}
},
mc FALSE,
undefinedNode FALSE
},
conferenceID '5FC8490FB4B9D111BFAF0060B000E945'H
}
}
}
02400600 08914A00 01006500 00012AFF 08800128 005FC849 0FB4B9D1 11BFAF00
60B000E9 45
Example 3
The following output shows two proxy call scenarios. A trace is collected on a destination router where
both destination proxy and destination Gatekeeper coexist. Both RAS and H.225 traces are enabled for
one complete call.
px2#
RASLib::RASRecvData: successfully rcvd message of length 80 from 40.0.0.33:1585
RASLib::RASRecvData: LRQ rcvd from [40.0.0.33:1585] on sock [6880372]
RASlib::ras_sendto: msg length 111 sent to 40.0.0.33
RASLib::RASSendLCF: LCF sent to 40.0.0.33
H225Lib::h225TAccept: TCP connection accepted from 101.0.0.1:11002 on
socket [2]
H225Lib::h225TAccept: Q.931 Call State is initialized to be [Null].
Hex representation of the received TPKT
030000A60802008005040488988CA56C0591373737377E008D0500B8060008914A000101400

May 2008 DB-833
Debug Commands
debug h225 asn1
6007000740065006C0032003100332800B50000124001280001400F007000740065006C00320
0330040007A006F006E00650032002E0063006F006D006600000106B8003DC8490FB4B9D111B
FAF0060B000E945000E07006500000106B822400F007000740065006C003200330040007A006
F006E00650032002E0063006F006D
H225Lib::h225RecvData: Q.931 SETUP received from socket [2]
H225Lib::h225RecvData: State changed to [Call Present].
RASLib::RASSendARQ: ARQ sent to 102.0.0.1
RASLib::RASRecvData: ARQ rcvd from [102.0.0.1:24999] on sock [0x68FC74]
RASLib::RASSendACF: ACF sent to 70.0.0.31
RASLib::RASRecvData: ACF rcvd from [102.0.0.1:1719] on sock [0x67E6A4]
RASLib::RASSendARQ: ARQ sent to 102.0.0.1
RASLib::RASRecvData: ACF rcvd from [102.0.0.1:1719] on sock [0x67E6A4]
Hex representation of the CALL PROCEEDING TPKT to send.
0300001B08028080027E000F050100060008914A00010880012800
H225Lib::h225CallProcRequest: Q.931 CALL PROCEEDING sent from socket
[2]. Call state remains unchanged (Q.931 FSM simplified for H.225.0)
H225Lib::h225TConn: connect in progress on socket [4]
H225Lib::h225TConn: Q.931 Call State is initialized to be [Null].
Hex representation of the SETUP TPKT to send.
030000A50802008005040388C0A56C0591373737377E008D0500B8060008914A00010140060
07000740065006C0032003100332800B50000124001280001400F007000740065006C0032003
30040007A006F006E00650032002E0063006F006D005A00000D06B8003DC8490FB4B9D111BFA
F0060B000E945000E07006600000106B822400F007000740065006C003200330040007A006F0
06E00650032002E0063006F006D
H225Lib::h225SetupRequest: Q.931 SETUP sent from socket [4]
H225Lib::h225SetupRequest: Q.931 Call State changed to [Call Initiated].
0300001808028080027E000C050100060008914A00010200
H225Lib::h225RecvData: Q.931 CALL PROCEEDING received from socket [4]
0300001808028080017E000C050300060008914A00010200
H225Lib::h225RecvData: Q.931 ALERTING received from socket [4]
H225Lib::h225RecvData: Q.931 Call State changed to [Call Delivered].
Hex representation of the ALERTING TPKT to send.
0300001808028080017E000C050300060008914A00010000
H225Lib::h225AlertRequest: Q.931 ALERTING sent from socket [2]. Call
state changed to [Call Received].
0300003508028080070404889886A57E0023050240060008914A0001005A00000D06A402003
DC8490FB4B9D111BFAF0060B000E945
H225Lib::h225RecvData: Q.931 CONNECT received from socket [4]
H225Lib::h225RecvData: Q.931 Call State changed to [Active].
Hex representation of the CONNECT TPKT to send.
030000370802808007040388C0A57E0026050240060008914A000100660000012AFC0880012
8003DC8490FB4B9D111BFAF0060B000E945
H225Lib::h225SetupResponse: Q.931 CONNECT sent from socket [2]
H225Lib::h225SetupResponse: Q.931 Call State changed to [Active].
RASLib::RASSendIRR: IRR sent to 102.0.0.1

DB-834 May 2008
Debug Commands
debug h225 asn1
RASLib::RASRecvData: IRR rcvd from [102.0.0.1:24999] on sock [0x68FC74]

RASLib::RASRecvData: IRR rcvd from [90.0.0.13:1700] on sock [0x68FC74]
0300001A080280805A080280107E000A050500060008914A0001
H225Lib::h225RecvData: Q.931 RELEASE COMPLETE received from socket [2]
H225Lib::h225RecvData: Q.931 Call State changed to [Null].
RASLib::RASSendDRQ: DRQ sent to 102.0.0.1
H225Lib::h225RecvData: no connection on socket [2]
RASLib::RASRecvData: DRQ rcvd from [102.0.0.1:24999] on sock [0x68FC74]
RASLib::RASSendDCF: DCF sent to 70.0.0.31
Hex representation of the RELEASE COMPLETE TPKT to send.
0300001A080280805A080280107E000A050500060008914A0001
H225Lib::h225TerminateRequest: Q.931 RELEASE COMPLETE sent from socket [2]. Call
state changed to [Null].
H225Lib::h225TClose: TCP connection from socket [2] closed
RASLib::RASSendDRQ: DRQ sent to 102.0.0.1
RASLib::RASRecvData: DCF rcvd from [102.0.0.1:1719] on sock [0x67E6A4]
RASLib::RASRecvData: DCF rcvd from [102.0.0.1:1719] on sock [0x67E6A4]
0300001A080280805A080280107E000A050500060008914A0001

May 2008 DB-835
Debug Commands
debug h225 events
debug h225 events

To display Q.931 events, use the debug h225 events privileged EXEC command. The no form of this
command disables debugging output.
debug h225 events
no debug h255 events

Examples The following are sample output from the debug h225 events command.
Example 1
H.225 turned on. The call is being established.
Router# debug h225 events
H.225 Event Messages debugging is on
Router# H225Lib::h225TAccept: TCP connection accepted from 50.0.0.12:1701 on
socket [2]
H225Lib::h225TAccept: Q.931 Call State is initialized to be [Null].
0300007408020001050404889886A56C0580373737377E005B0500B0060008914A000101400
6007000740065006C003200310033020001400F007000740065006C003200330040007A006F0
06E00650032002E0063006F006D004EC8490FB4B9D111BFAF0060B000E945000C07003200000
C06B8
H225Lib::h225RecvData: Q.931 SETUP received from socket [2]
H225Lib::h225RecvData: State changed to [Call Present].
Hex representation of the CALL PROCEEDING TPKT to send.
0300001B08028001027E000F050100060008914A00010880012800
H225Lib::h225CallProcRequest: Q.931 CALL PROCEEDING sent from socket
[2]. Call state remains unchanged (Q.931 FSM simplified for H.225.0)
H225Lib::h225TConn: connect in progress on socket [4]
H225Lib::h225TConn: Q.931 Call State is initialized to be [Null].
Hex representation of the SETUP TPKT to send.
030000A60802008405040488988CA56C0591373737377E008D0500B8060008914A000101400
6007000740065006C0032003100332800B50000124001280001400F007000740065006C00320
0330040007A006F006E00650032002E0063006F006D006600000106B8004EC8490FB4B9D111B
FAF0060B000E945000E07006500000106B822400F007000740065006C003200330040007A006
F006E00650032002E0063006F006D
H225Lib::h225SetupRequest: Q.931 SETUP sent from socket [4]
H225Lib::h225SetupRequest: Q.931 Call State changed to [Call Initiated].
0300001B08028084027E000F050100060008914A00010880012800

DB-836 May 2008
Debug Commands
debug h225 events
H225Lib::h225RecvData: Q.931 CALL PROCEEDING received from socket [4]

0300001808028084017E000C050300060008914A00010000
H225Lib::h225RecvData: Q.931 ALERTING received from socket [4]
H225Lib::h225RecvData: Q.931 Call State changed to [Call Delivered].
Hex representation of the ALERTING TPKT to send.
0300001808028001017E000C050300060008914A00010000
H225Lib::h225AlertRequest: Q.931 ALERTING sent from socket [2]. Call
state changed to [Call Received].
030000370802808407040388C0A57E0026050240060008914A000100660000012AFF0880012
8004EC8490FB4B9D111BFAF0060B000E945
H225Lib::h225RecvData: Q.931 CONNECT received from socket [4]
H225Lib::h225RecvData: Q.931 Call State changed to [Active].
Hex representation of the CONNECT TPKT to send.
0300003808028001070404889886A57E0026050240060008914A000100650000012AFC08800
128004EC8490FB4B9D111BFAF0060B000E945
H225Lib::h225SetupResponse: Q.931 CONNECT sent from socket [2]
H225Lib::h225SetupResponse: Q.931 Call State changed to [Active].
Example 2
H.225 turned on. The call is being torn down.

Router#
0300001A080200015A080200907E000A050500060008914A0001
H225Lib::h225RecvData: Q.931 RELEASE COMPLETE received from socket [2]
H225Lib::h225RecvData: Q.931 Call State changed to [Null].
H225Lib::h225RecvData: no connection on socket [2]
0300001A080280015A080280107E000A050500060008914A0001
0300001A080280845A080280107E000A050500060008914A0001

May 2008 DB-837
Debug Commands
debug h225
debug h225
To display additional information about the actual contents of H.225 Registration, Admission, and Status
Protocol (RAS) messages, use the debug h225 command in privileged EXEC mode. To disable
debug h225 {asn1 | events}
no debug h225
Syntax Description asn1 Indicates that only the Abstract Syntax Notation One (ASN.1) contents of
any H.225 message sent or received will be displayed.
events Indicates that key Q.931 events that occur when placing an H.323 call from
one gateway to another will be displayed.
Defaults Disabled

Usage Guidelines Both versions of the debug h225 command display information about H.225 messages. H.225 messages
are used to exchange RAS information between gateways and gatekeepers as well as to exchange Q.931
information between gateways.
The debug h225 events command displays key Q.931 events that occur when placing an H.323 call from
one gateway to another. Q.931 events are carried in H.225 messages. This command enables you to
monitor Q.931 state changes such as setup, alert, connected, and released.
Note Although the debug information includes the hexadecimal output of the entire H.225 message, only the
key state changes are decoded.
The debug h225 asn1 command displays the ASN.1 contents of any H.225 message sent or received that
contains ASN.1 content. Not all H.225 messages contain ASN.1 content. Some messages contain both
Q.931 information and ASN.1 information; if you enter this command, only ASN.1 information will be
displayed.

DB-838 May 2008
Debug Commands
debug h225
Examples The following sample output for the debug h225 events command shows a call being placed from
gateway GW13 to gateway GW14. Before the call was placed, the gateway exchanged RAS messages
with the gatekeeper. Because RAS messages do not contain Q.931 information, these messages do not
appear in this output.
Router#
*Mar 2 02:47:14.689: H225Lib::h225TConn:connect in progress on socket [2]

*Mar 2 02:47:14.689: H225Lib::h225TConn:Q.931 Call State is initialized to be
[Null].
*Mar 2 02:47:14.697:Hex representation of the SETUP TPKT to
send.0300004D080200DC05040380C0A36C0991313323313333303070099131342331343330307E00260500800
60008914A000102004B1F5E5D8990006C0000000005BF7454000C0700000000000000
*Mar 2 02:47:14.701:
*Mar 2 02:47:14.701: H225Lib::h225SetupRequest:Q.931 SETUP sent from socket [2]
*Mar 2 02:47:14.701: H225Lib::h225SetupRequest:Q.931 Call State changed to
[Call Initiated].
*Mar 2 02:47:14.729:Hex representation of the received
TPKT03000021080280DC013401017E0012050340060008914A000100000109350E2B28
*Mar 2 02:47:14.729:
*Mar 2 02:47:14.729: H225Lib::h225RecvData:Q.931 ALERTING received from socket [2]
*Mar 2 02:47:14.729: H225Lib::h225RecvData:Q.931 Call State changed to
[Call Delivered].
TPKT03000034080280DC07040380C0A37E0023050240060008914A0001000109350E2B2802004B1F5E5D899000
6C0000000005BF7454
*Mar 2 02:47:17.569:
*Mar 2 02:47:17.569: H225Lib::h225RecvData:Q.931 CONNECT received from socket [2]
*Mar 2 02:47:17.569: H225Lib::h225RecvData:Q.931 Call State changed to [Active].
TPKT0300001A080280DC5A080280107E000A050500060008914A0001
*Mar 2 02:47:23.273:
*Mar 2 02:47:23.273: H225Lib::h225RecvData:Q.931 RELEASE COMPLETE received from
socket [2]
*Mar 2 02:47:23.273: H225Lib::h225RecvData:Q.931 Call State changed to [Null].
*Mar 2 02:47:23.293:Hex representation of the RELEASE COMPLETE TPKT
to send.0300001A080200DC5A080280107E000A050500060008914A0001
*Mar 2 02:47:23.293:
*Mar 2 02:47:23.293: H225Lib::h225TerminateRequest:Q.931 RELEASE COMPLETE sent from
socket [2]. Call state changed to [Null].
*Mar 2 02:47:23.293: H225Lib::h225TClose:TCP connection from socket [2] closed
The following output shows the same call being placed from gateway GW13 to gateway GW14 using the
debug h225 asn1 command. The output is very long, but you can track the following information:
The admission request to the gatekeeper.
The admission confirmation from the gatekeeper.
The ASN.1 portion of the H.225/Q.931 setup message from the calling gateway to the called
gateway.
The ASN.1 portion of the H.225/Q.931 setup response from the called gateway, indicating that the
call has proceeded to alerting state.
The ASN.1 portion of the H.225/Q.931 message from the called gateway, indicating that the call has
been connected.
The ASN.1 portion of the H.225/Q.931 message from the called gateway, indicating that the call has
been released.

May 2008 DB-839
Debug Commands
debug h225
The ANS.1 portion of the H.225 RAS message from the calling gateway to the gatekeeper, informing
it that the call has been disengaged.
The ASN.1 portion of the H.225 RAS message from the gatekeeper to the calling gateway,
confirming the disengage request.
The ASN.1 portion of the H.225/Q.931 release complete message sent from the called gateway to
the calling gateway.
Router#

*Mar 2 02:48:18.445: {
*Mar 2 02:48:18.445: requestSeqNum 03320,
*Mar 2 02:48:18.445: callType pointToPoint :NULL,
*Mar 2 02:48:18.445: callModel direct :NULL,
*Mar 2 02:48:18.445: endpointIdentifier "60D6BA4C00000001",
*Mar 2 02:48:18.445: destinationInfo
*Mar 2 02:48:18.445: {
*Mar 2 02:48:18.445: e164 :"14#14300"
*Mar 2 02:48:18.445: },
*Mar 2 02:48:18.449: srcInfo
*Mar 2 02:48:18.449: {
*Mar 2 02:48:18.449: e164 :"13#13300"
*Mar 2 02:48:18.449: },
*Mar 2 02:48:18.449: bandWidth 0640,
*Mar 2 02:48:18.449: callReferenceValue 0224,
*Mar 2 02:48:18.449: conferenceID '4B1F5E5D899000720000000005C067A4'H,
*Mar 2 02:48:18.449: activeMC FALSE,
*Mar 2 02:48:18.449: answerCall FALSE
*Mar 2 02:48:18.449: }
*Mar 2 02:48:18.449:25800CF7 00F00036 00300044 00360042 00410034 00430030 00300030
00300030
00300030 00310103 80470476 33010380 46046633 40028000 E04B1F5E 5D899000
72000000 0005C067 A400
29000CF7 40028000 0109350E 06B80077
*Mar 2 02:48:18.469: {
*Mar 2 02:48:18.469: bandWidth 0640,
*Mar 2 02:48:18.469: callModel direct :NULL,
*Mar 2 02:48:18.469: destCallSignalAddress ipAddress :
*Mar 2 02:48:18.469: {
*Mar 2 02:48:18.469: ip '0109350E'H,
*Mar 2 02:48:18.469: port 01720
*Mar 2 02:48:18.469: },
*Mar 2 02:48:18.469: irrFrequency 0120
*Mar 2 02:48:18.473: }
*Mar 2 02:48:18.473:value H323-UserInformation ::=
*Mar 2 02:48:18.481:{
*Mar 2 02:48:18.481: h323-uu-pdu
*Mar 2 02:48:18.481: {
*Mar 2 02:48:18.481: h323-message-body setup :
*Mar 2 02:48:18.481: {
*Mar 2 02:48:18.481: protocolIdentifier { 0 0 8 2250 0 1 },
*Mar 2 02:48:18.481: sourceInfo
*Mar 2 02:48:18.481: {
*Mar 2 02:48:18.481: terminal
*Mar 2 02:48:18.481: {
*Mar 2 02:48:18.481: },

DB-840 May 2008
Debug Commands
debug h225
*Mar 2 02:48:18.481: mc FALSE,

*Mar 2 02:48:18.481: undefinedNode FALSE
*Mar 2 02:48:18.481: },
*Mar 2 02:48:18.481: activeMC FALSE,
*Mar 2 02:48:18.481: conferenceGoal create :NULL,
*Mar 2 02:48:18.485: callType pointToPoint :NULL,
*Mar 2 02:48:18.485: sourceCallSignalAddress ipAddress :
*Mar 2 02:48:18.485: {
*Mar 2 02:48:18.485: ip '00000000'H,
*Mar 2 02:48:18.485: port 00
*Mar 2 02:48:18.485: }
*Mar 2 02:48:18.485: }
*Mar 2 02:48:18.485: }
*Mar 2 02:48:18.485:}
*Mar 2 02:48:18.485:00800600 08914A00 0102004B 1F5E5D89 90007200 00000005 C067A400
0C070000
00000000 00
*Mar 2 02:48:18.525:{
*Mar 2 02:48:18.525: h323-uu-pdu
*Mar 2 02:48:18.525: {
*Mar 2 02:48:18.525: h323-message-body alerting :
*Mar 2 02:48:18.525: {
*Mar 2 02:48:18.525: {
*Mar 2 02:48:18.525: mc FALSE,
*Mar 2 02:48:18.525: },
*Mar 2 02:48:18.525: h245Address ipAddress :
*Mar 2 02:48:18.525: {
*Mar 2 02:48:18.525: ip '0109350E'H,
*Mar 2 02:48:18.525: port 011050
*Mar 2 02:48:18.525: }
*Mar 2 02:48:18.525: }
*Mar 2 02:48:18.525: }
*Mar 2 02:48:18.525:}
*Mar 2 02:48:22.753:{
*Mar 2 02:48:22.753: h323-uu-pdu
*Mar 2 02:48:22.753: {
*Mar 2 02:48:22.753: h323-message-body connect :
*Mar 2 02:48:22.753: {
*Mar 2 02:48:22.753: h245Address ipAddress :
*Mar 2 02:48:22.753: {
*Mar 2 02:48:22.753: ip '0109350E'H,
*Mar 2 02:48:22.753: port 011050
*Mar 2 02:48:22.753: },
*Mar 2 02:48:22.753: {
*Mar 2 02:48:22.753: terminal
*Mar 2 02:48:22.753: {
*Mar 2 02:48:22.753: },
*Mar 2 02:48:22.757: mc FALSE,
*Mar 2 02:48:22.757: },
*Mar 2 02:48:22.757: conferenceID '4B1F5E5D899000720000000005C067A4'H
*Mar 2 02:48:22.757: }
*Mar 2 02:48:22.757: }
*Mar 2 02:48:22.757:}
*Mar 2 02:48:27.109:{

May 2008 DB-841
Debug Commands
debug h225
*Mar 2 02:48:27.109: h323-uu-pdu

*Mar 2 02:48:27.109: {
*Mar 2 02:48:27.109: h323-message-body releaseComplete :
*Mar 2 02:48:27.109: {
*Mar 2 02:48:27.109: protocolIdentifier { 0 0 8 2250 0 1 }
*Mar 2 02:48:27.109: }
*Mar 2 02:48:27.109: }
*Mar 2 02:48:27.109:}
*Mar 2 02:48:27.109:value RasMessage ::= disengageRequest :
*Mar 2 02:48:27.117: {
*Mar 2 02:48:27.117: endpointIdentifier "60D6BA4C00000001",
*Mar 2 02:48:27.121: callReferenceValue 0224,
*Mar 2 02:48:27.121: disengageReason normalDrop :NULL
*Mar 2 02:48:27.121: }
*Mar 2 02:48:27.121:3C0CF81E 00360030 00440036 00420041 00340043 00300030 00300030
00300030
00300031 4B1F5E5D 89900072 00000000 05C067A4 00E020
400CF8
value RasMessage ::= disengageConfirm :
*Mar 2 02:48:27.133: {
*Mar 2 02:48:27.133: requestSeqNum 03321
*Mar 2 02:48:27.133: }
*Mar 2 02:48:27.133:{
*Mar 2 02:48:27.133: h323-uu-pdu
*Mar 2 02:48:27.133: {
*Mar 2 02:48:27.133: h323-message-body releaseComplete :
*Mar 2 02:48:27.133: {
*Mar 2 02:48:27.133: protocolIdentifier { 0 0 8 2250 0 1 }
*Mar 2 02:48:27.133: }
*Mar 2 02:48:27.133: }
*Mar 2 02:48:27.133:}
*Mar 2 02:48:27.133:05000600 08914A00 01

DB-842 May 2008
Debug Commands
debug h245 asn1
debug h245 asn1

To display Abstract Syntax Notation One (ASN.1) contents of H.245 messages, use the debug h245 asn1
debug h245 asn1
no debug h245 asn1

Usage Guidelines
Caution This command slows the system down considerably. Connections may time out.

May 2008 DB-843
Debug Commands
debug h245 events
debug h245 events

To display H.245 events, use the debug h245 events command in privileged EXEC mode. To disable
debug h245 events
no debug h245 events


DB-844 May 2008
Debug Commands
debug h245 srtp
debug h245 srtp

To display H.245 Secure Real-Time Transport Protocol (SRTP) messages, use the debug h245 srtp
debug h245 srtp
no debug h245 srtp

12.4(6)T1 This command was introduced.
Usage Guidelines To reduce the system impact of the output that this command generates, use the debug h245 srtp
command during times of minimal system traffic. To reduce system overhead and redirect logging to an
internal buffer, use the logging buffered command.
Use the debug h225 asn1 command to display Abstract Syntax Notation One (ASN.1) contents of H.225
messages.
Use the debug h245 asn1 command to display ASN.1 contents of H.245 messages.
The output from the debug h245 srtp command is primarily used by Cisco technical personnel. See the
Examples section for an explanation of selected fields.
Examples The following example displays SRTP messages exchanged during H.225 and H.245 signaling:
Router# debug h245 srtp
H.245 SRTP Messages debugging is on
SY3725_1#
000072: Mar 16 16:46:38.237: //-1/xxxxxxxxxxxx/H323/cch323_post_call_setup_request:

cch323_post_call_setup_request:1015: SRTP added to ev for stream:SRTP_TX_STREAM.
000073: Mar 16 16:46:38.237: //-1/xxxxxxxxxxxx/H323/cch323_dump_srtp_caps:

crypto_bm=0x1,
codec_bm=0xB.
000074: Mar 16 16:46:38.237: //-1/xxxxxxxxxxxx/H323/cch323_dump_srtp_media_params:
The following lines show SRTP media parameters:

ssrc_sel=0x0,

May 2008 DB-845
Debug Commands
debug h245 srtp
srtp_ssrc=0x0,
crypto_services=0x0,
crypto_suite=0x0,
master_key_len=0x0,
master_salt_len=0x0,
master_key=0xxxxxxxxxxxxxxxxx,
master_salt=0xxxxxxxxxxxxxxx
000075: Mar 16 16:46:38.237: //-1/xxxxxxxxxxxx/H323/cch323_dump_srtp_sess_params:
The following lines show SRTP session parameters:

lifetime=0x0,
mki=0x,
mki_length=0x0,
kdr=0x0,
encryptedsrtp=0x0,
encryptedsrtcp=0x0,
fecorder=0x0,
windowsizehint=0x0
000076: Mar 16 16:46:38.237: cch323_post_call_setup_request:993:
callID = 0x4PeercallID = 0x3params->incomingCallid = 0x3srtp_params_caps = 0x0i=1
000077: Mar 16 16:46:38.237: //-1/xxxxxxxxxxxx/H323/cch323_post_call_setup_request:
cch323_post_call_setup_request:1021: SRTP NOT added to ev
000078: Mar 16 16:46:38.241: //4/CCB23DEA8003/H323/cch323_set_srtp_call:
../voip/cch323/gw/os/src/h323_gw_dialpeer.c:cch323_set_srtp_call:3420: SRTP configuration:
The following lines show SRTP configuration. Fields having a value set to 1 show that SRTP is enabled.
peer->voice_peer_tag = 101, ccb->srtp_call = 1, ccb->srtp_fallback = 1,
ccb->srtp_transparent = 1
000079: Mar 16 16:46:38.241: //4/CCB23DEA8003/H323/cch323_get_caps_chn_info: Local[TX]

SRTP Info:../voip/cch323/gw/src/cch323_h245_iwf_util.c:cch323_get_caps_chn_info:148
000080: Mar 16 16:46:38.241: //4/CCB23DEA8003/H323/cch323_dump_srtp_caps:
The following lines show SRTP capabilities:
crypto_bm=0x1,
codec_bm=0xB.
000081: Mar 16 16:46:38.241: //4/CCB23DEA8003/H323/cch323_dump_srtp_media_params:
ssrc_sel=0x0,
srtp_ssrc=0x0,
crypto_suite=0x0,
master_key_len=0x0,
000082: Mar 16 16:46:38.241: //4/CCB23DEA8003/H323/cch323_dump_srtp_sess_params:
lifetime=0x0,
mki=0x,
mki_length=0x0,
kdr=0x0,
encryptedsrtp=0x0,
encryptedsrtcp=0x0,
fecorder=0x0,
windowsizehint=0x0
000083: Mar 16 16:46:38.241: //4/CCB23DEA8003/H323/cch323_get_caps_chn_info: Remote[RX]
SRTP Info:../voip/cch323/gw/src/cch323_h245_iwf_util.c:cch323_get_caps_chn_info:151

DB-846 May 2008
Debug Commands
debug h245 srtp
The following line shows SRTP capability for the DSP, indicated by the crypto_bm field. A value of 0x0
indicates the DSP is not SRTP capable.
crypto_bm=0x0,
codec_bm=0x0.
ssrc_sel=0x0,
srtp_ssrc=0x0,
crypto_suite=0x0,
master_key_len=0x0,
lifetime=0x0,
mki=0x,
mki_length=0x0,
kdr=0x0,
encryptedsrtp=0x0,
encryptedsrtcp=0x0,
fecorder=0x0,
windowsizehint=0x0
000087: Mar 16 16:46:38.245:
//4/CCB23DEA8003/H323/cch323_build_local_encoded_fastStartOLCs:
../voip/cch323/gw/src/cch323_h245_util.c:cch323_build_local_encoded_fastStartOLCs:1518:
OGW: generating Keys.
000088: Mar 16 16:46:38.245: //4/CCB23DEA8003/H323/cch323_generate_srtp_info:
../voip/cch323/gw/os/src/h323_gw_srtpapi.c:cch323_generate_srtp_info:31: Entry
000089: Mar 16 16:46:38.245: //4/CCB23DEA8003/H323/cch323_generate_srtp_info: Generated
SRTP info:../voip/cch323/gw/os/src/h323_gw_srtpapi.c:cch323_generate_srtp_info:83
crypto_bm=0x1,
codec_bm=0xB.
ssrc_sel=0x0,
srtp_ssrc=0x0,
crypto_suite=0x1,
master_key_len=0x10,
master_salt_len=0xE,
lifetime=0x0,
mki=0x,
mki_length=0x0,
kdr=0x18,
encryptedsrtp=0x1,
encryptedsrtcp=0x1,
fecorder=0x0,
windowsizehint=0x40
../voip/cch323/gw/os/src/h323_gw_srtpapi.c:cch323_generate_srtp_info:86: Exit
../voip/cch323/gw/os/src/h323_gw_srtpapi.c:cch323_generate_srtp_info:31: Entry
000095: Mar 16 16:46:38.249: //4/CCB23DEA8003/H323/cch323_generate_srtp_info: Generated
SRTP info:../voip/cch323/gw/os/src/h323_gw_srtpapi.c:cch323_generate_srtp_info:83
crypto_bm=0x0,
codec_bm=0x0.
ssrc_sel=0x0,
srtp_ssrc=0x0,

May 2008 DB-847
Debug Commands
debug h245 srtp
crypto_suite=0x0,
lifetime=0x0,
mki=0x,
mki_length=0x0,
kdr=0x18,
encryptedsrtp=0x1,
encryptedsrtcp=0x1,
fecorder=0x0,
windowsizehint=0x40
../voip/cch323/gw/os/src/h323_gw_srtpapi.c:cch323_generate_srtp_info:86: Exit
000100: Mar 16 16:46:38.249: //4/CCB23DEA8003/H323/build_fastStart_OLCs: FWD OLC SRTP
params:../voip/cch323/gw/src/cch323_h245_util.c:build_fastStart_OLCs:1403
000101: Mar 16 16:46:38.249: //4/CCB23DEA8003/H323/build_fastStart_OLCs: RVR OLC SRTP

Params:../voip/cch323/gw/src/cch323_h245_util.c:build_fastStart_OLCs:1417
000102: Mar 16 16:46:38.301: //4/CCB23DEA8003/H323/cch323_build_olc_for_ccapi:
../voip/cch323/gw/src/cch323_h245_util.c:cch323_build_olc_for_ccapi:1690: WE ARE OGW.
The following lines show the outgoing gateway sending SRTP capabilities:
000103: Mar 16 16:46:38.301: //4/CCB23DEA8003/H323/cch323_build_olc_for_ccapi: Local SRTP

Info:../voip/cch323/gw/src/cch323_h245_util.c:cch323_build_olc_for_ccapi:1779
crypto_bm=0x1,
codec_bm=0xB.

ssrc_sel=0x0,
srtp_ssrc=0x0,
crypto_suite=0x1,
lifetime=0x0,
mki=0x,
mki_length=0x0,
kdr=0x18,
encryptedsrtp=0x1,
encryptedsrtcp=0x1,
fecorder=0x0,
windowsizehint=0x40
The following lines show that the gateway has received SRTP capabilities from the remote end:
000107: Mar 16 16:46:38.301: //4/CCB23DEA8003/H323/cch323_build_olc_for_ccapi: Remote SRTP

Info:../voip/cch323/gw/src/cch323_h245_util.c:cch323_build_olc_for_ccapi:1783

crypto_bm=0x1,
codec_bm=0x1.

DB-848 May 2008
Debug Commands
debug h245 srtp

ssrc_sel=0x0,
srtp_ssrc=0x0,
crypto_suite=0x1,
lifetime=0x0,
mki=0x,
mki_length=0x0,
kdr=0x18,
encryptedsrtp=0x1,
encryptedsrtcp=0x1,
fecorder=0x0,
windowsizehint=0x40
000111: Mar 16 16:46:38.305: //4/CCB23DEA8003/H323/h323_common_setup_rtcp_parameters:

../voip/cch323/gw/os/src/h323_gw_rtpapi.c:h323_common_setup_rtcp_parameters:378:olc->rtcp_
session.srtp_services:3
000112: Mar 16 16:46:38.305: vtsp_call_ssrc_update: updated ssrc=0x5227F02
000113: Mar 16 16:46:38.305: //4/CCB23DEA8003/H323/cch323_setup_srtp_session:

../voip/cch323/gw/os/src/h323_gw_srtpapi.c:cch323_setup_srtp_session:369: Entry

../voip/cch323/gw/os/src/h323_gw_srtpapi.c:cch323_setup_srtp_session:416: TX [Local] SRTP
Info .
ssrc_sel=0x0,
srtp_ssrc=0x0,
crypto_suite=0x1,
../voip/cch323/gw/os/src/h323_gw_srtpapi.c:cch323_setup_srtp_session:448: RX [Remote] SRTP
Info .

ssrc_sel=0x0,
srtp_ssrc=0x0,
crypto_suite=0x1,
% SRTP Library session creation, id:0x80000002, context:0x653E0CF8, num_context=2,

rtp:0x653D2CF4, rtp_session:0x66D79B00

../voip/cch323/gw/os/src/h323_gw_srtpapi.c:cch323_setup_srtp_session:514: Exit

May 2008 DB-849
Debug Commands
debug h245 srtp



Info .

ssrc_sel=0x0,
srtp_ssrc=0x0,
crypto_suite=0x1,
Info .

ssrc_sel=0x0,
srtp_ssrc=0x0,
crypto_suite=0x1,
% SRTP Library session update with 2 keysid:0x80000002 context:0x653E0CF8




Info .

ssrc_sel=0x0,
srtp_ssrc=0x0,
crypto_suite=0x1,

Info .

DB-850 May 2008
Debug Commands
debug h245 srtp

ssrc_sel=0x0,
srtp_ssrc=0x0,
crypto_suite=0x1,
% SRTP Library session update with 2 keysid:0x80000002 context:0x653E0CF8

000136: Mar 16 16:46:38.321: //4/CCB23DEA8003/H323/cch323_h245_cap_ind: Updated

CCB(0x66D8D2D4) with TCS Remote SRTP Info:

crypto_bm=0x1,
codec_bm=0xB.
ssrc_sel=0x0,
srtp_ssrc=0x0,
crypto_suite=0x1,
lifetime=0x0,
mki=0x,
mki_length=0x0,
kdr=0x18,
encryptedsrtp=0x1,
encryptedsrtcp=0x1,
fecorder=0x0,
windowsizehint=0x40
000140: Mar 16 16:46:38.321: //4/CCB23DEA8003/H323/cch323_update_tcs_nonstd_info:
cch323_update_tcs_nonstd_info:5800: Posting TCS SRTP caps to other callleg.
crypto_bm=0x1,
codec_bm=0xB.

ssrc_sel=0x0,
srtp_ssrc=0x0,
crypto_suite=0x1,
lifetime=0x0,
mki=0x,
mki_length=0x0,
kdr=0x18,
encryptedsrtp=0x1,
encryptedsrtcp=0x1,

May 2008 DB-851
Debug Commands
debug h245 srtp
fecorder=0x0,
windowsizehint=0x40
000144: Mar 16 16:46:38.325: //4/CCB23DEA8003/H323/cch323_h245_cap_ind:

cch323_h245_cap_ind:360 cch323_update_tcs_nonstd_info failed

debug h225 asn1 Displays ASN.1 contents of H.225 messages.
debug h245 asn1 Displays ASN.1 contents of H.245 messages.
logging buffered Enables system message logging to a local buffer.
srtp (voice) Enables secure calls globally.
srtp (dial-peer) Enables secure calls for a specific dial peer.

DB-852 May 2008
Debug Commands
debug h323-annexg
debug h323-annexg
To display all pertinent Annex G messages that have been transmitted and received, use the debug
h323-annexg command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug h323-annexg {asn1 | errors | events | inout}
no debug h323-annexg
Syntax Description. asn1 Displays the Annex G ASN.1 messages.

errors Displays the Annex G error messages encountered during processing.
events Displays the Annex G events received from the state machine.
inout (Optional) This functionality is not yet implemented.

12.2(11)T This command was implemented on the Cisco AS5850.
Examples The following is sample output from the debug h323-annexg events command:
Router# debug h323-annexg events
Aug 16 14:03:40.983:be_process:BE QUEUE_EVENT (minor 73) wakeup

Aug 16 14:03:40.983:be_sm:Received event BE_EV_DO_QUERY
Aug 16 14:03:40.983:<- query_neighbor:Sent descriptorIDRequest to
172.18.195.46:2099 [320]
Aug 16 14:03:40.983:be_sm:Started query-timer of 1 minutes for
neighbor at 172.18.195.46
Aug 16 14:03:40.991:-> nxg_recv_msg:Rcvd dscrptrIDCnfrmtn from
172.18.195.46:2099 [320]
Aug 16 14:03:41.531:<- send_descriptor_request:Sent descriptorRequest
to 172.18.195.46:2099 [321]
Aug 16 14:03:41.539:-> nxg_recv_msg:Rcvd descriptorConfirmation from
172.18.195.46:2099 [321]
Aug 16 14:03:41.539:handle_descriptor_cfm:Descriptor from neighbor
172.18.195.46 unchanged, TTL is 60 Seconds

May 2008 DB-853
Debug Commands
debug h323-annexg

emulate Displays all pertinent Annex E messages that have been transmitted and
received.

DB-854 May 2008
Debug Commands
debug hccp timing
debug hccp timing

To display debug messages for the timing of HCCP events, use the debug hccp timing command in
privileged EXEC mode. To disable the debug message output, use the no form of this command.
debug hccp timing [if-config]
no debug hccp timing [if-config]
Syntax Description if-config (Optional) Displays debugging messages showing the timing of the
reconfiguration of cable interfaces during HCCP redundancy operations.

12.1(3a)EC This command was introduced.
12.2(4)XF1, Support was added for the N+1 (1:n) RF Switch with the Cisco uBR10012
12.2(4)BC1 router.
12.2(11)BC1 Support was added for the N+1 (1:n) RF Switch with the
Cisco uBR7246VXR router.
12.2(15)BC1 The if-config option was added.
Usage Guidelines You must activate the debug hccp events command before the debug hccp timing command will
generate any debug message output.
Examples The following example shows typical output for the debug hccp timing command:
Router# debug hccp events
Router# debug hccp timing
HCCP timing measurement debugging is on
May 31 10:21:07.609 HCCP P is busy. Deactivating 1 6

May 31 10:21:07.609 HCCP P is busy. Deactivating 2 6
May 31 10:21:08.705 HCCP hwif_goingdown for Cable8/1/0. Deactivate 1 6
May 31 10:21:08.773 HCCP 2 6 Working: become standby - 68 msec
May 31 10:21:08.793 HCCP 1 6 Working: become standby - 20 msec
May 31 10:21:10.730 HCCP 1 1 Working: turn on "uc" - 8 msec
May 31 10:21:10.730 HCCP 1 1 Working: turn on "nru" - 0 msec
May 31 10:21:10.734 HCCP 1 1 Working: become active - 4 msec
May 31 10:21:10.774 HCCP 2 1 Working: turn on "uc" - 52 msec
May 31 10:21:10.774 HCCP 2 1 Working: turn on "nru" - 0 msec

May 2008 DB-855
Debug Commands
debug hccp timing

May 31 10:21:13.726 HCCP 1 1 Protect: turn off "uc" - 1972 msec
May 31 10:21:13.790 HCCP 2 1 Protect: turn off "uc" - 2036 msec
May 31 10:21:14.422 HCCP 1 1 Protect: turn off "nru" - 696 msec
May 31 10:21:14.422 HCCP 1 1 Protect: unload config (if) - 0 msec
May 31 10:21:14.438 HCCP 1 1 Protect: unload config (subif) - 16 msec
May 31 10:21:14.702 HCCP 1 1 Protect: unload config (ds) - 264 msec
May 31 10:21:14.702 HCCP 1 1 Protect: become standby - 0 msec
May 31 10:21:16.078 HCCP 2 1 Protect: turn off "nru" - 2288 msec
May 31 10:21:16.078 HCCP 2 1 Protect: unload config (if) - 0 msec
May 31 10:21:16.078 HCCP 2 1 Protect: unload config (subif) - 0 msec
May 31 10:21:16.599 HCCP 2 1 Protect: unload config (ds) - 520 msec
May 31 10:21:16.599 HCCP 2 1 Protect: become standby - 0 msec
May 31 10:21:17.014 HCCP: P missed hello ack in LEARN state and is locked. Deactivate 4 1
May 31 10:21:17.014 HCCP 4 1 Protect: turn off "rfswitch" - 52 msec
May 31 10:21:17.593 HCCP 3 1 Working: turn on "rfswitch" - 0 msec
May 31 10:21:18.112 HCCP 1 1 Protect: load config (if) - 0 msec
May 31 10:21:18.112 HCCP 1 1 Protect: load config (subif) - 4 msec
May 31 10:21:18.331 HCCP 1 1 Protect: load config (ds) - 100 msec
May 31 10:21:18.331 HCCP 2 1 Working: turn off "rfswitch" - 0 msec
May 31 10:21:18.331 HCCP 2 Cable5/0/1 Protect: resolve conflict Learn->Teach
May 31 10:21:18.331 HCCP 2 1 Protect: load config (if) - 0 msec
May 31 10:21:18.331 HCCP 2 1 Protect: load config (subif) - 0 msec
May 31 10:21:20.112 HCCP 2 1 Protect: turn on "rfswitch" - 48 msec
May 31 10:21:20.112 HCCP 2 1 Protect: become active - 0 msec
May 31 10:21:20.112 HCCP 2 1 Protect: turn on "rfswitch" - 48 msec
May 31 10:21:20.112 HCCP 2 1 Protect: become active - 0 msec
The following example shows typical output for the debug hccp timing if-config command:
Router# debug hccp events
Router# debug hccp timing if-config
HCCP Timing measurements messages of (UN)LOAD IF config CLI is on
HCCP 1 1 Working: unload config (ds) - 112 msec

HCCP 1 1 Protect: load config (ds) - 123 msec
HCCP 1 1 Protect: load config (chnl set freq) - 35 msec

debug hccp Displays authentication debug messages for HCCP groups.
authentication
debug hccp Displays debug messages related to an RF or channel switch that is being
channel-switch used for HCCP N+1 (1:n) redundancy.
debug hccp events Displays debug messages for all HCCP group interaction.

DB-856 May 2008
Debug Commands
debug hccp timing
Command Description
debug hccp inter-db Displays debug messages for the inter-database events during HCCP
operations.
debug hccp plane Displays debug messages for HCCP-related messages sent between the
routers control plane and data backplane.
debug hccp sync Displays debug messages for HCCP synchronization messages.

May 2008 DB-857
Debug Commands
debug hpi
debug hpi
Note Effective with release 12.3(8)T, the debug hpi command is replaced by the debug voip hpi command.
See the debug voip hpi command for more information.
To enable debugging for Host Port Interface (HPI) message events, use the debug hpi command in
debug hpi {all | buffer size | capture | command | destination url | detail | error | notification |
response | stats}
no debug hpi {all | buffer size | capture | command | destination url | detail | error | notification
| response | stats}
Syntax Description all Enables all HPI debug options (command, detail, error, notification, and
response).
buffer size Sets the maximum amount of memory (in bytes) that the capture system
allocates for its buffers when it is active. Valid size range is from 0 to
9000000. Default is 0.
capture Displays HPI capture.
command Displays commands that are being sent to the 54x DSP.
destination url Turns capture on if it was off and sends the output to the specified URL. If
capture was previously enabled for a different URL, the existing URL is
closed, the new URL is opened, and output is sent to the new URL.
detail Displays additional detail for the HPI debugs that are enabled.
error Displays any HPI errors.
notification Displays notification messages sent that are from the 54x DSP (for example,
tone detection notification).
response Displays responses (to commands) that are sent by the 54x DSP
(for example, responses to statistic requests).
stats Displays HPI statistics.

12.1(5)XM This command was introduced on the Cisco AS5300 and
Cisco AS5800.
12.2(2)T This command was implemented on the Cisco 1700,
Cisco 2600 series, Cisco 3600 series, and the Cisco MC3810. The
stats keyword was added.

DB-858 May 2008
Debug Commands
debug hpi
12.2(10), 12.2(11)T This command was implemented on the Cisco 827, Cisco 2400,
Cisco 7200 series, and Cisco CVA 120. The following keywords
were added: buffer, capture, and destination.
12.3(8)T This command was replaced by the debug voip hpi command.
Usage Guidelines This command enables debugging for HPI message events, which are used to communicate with digital
signal processors (DSPs).
When used with the Voice DSP Contol Message Logger feature, the debug hpi buffer command sets the
maximum amount of memory (in bytes) that the capture system can allocate for its buffers when it is
active. The debug hpi capture destination url command turns capture on if it was off and sends the
output to the given URL. If capture was previously enabled for a different URL, the existing URL is
closed, the new URL is opened, and output is sent to the new URL.
When you use the no debug hpi capture command, the capture option is turned off if it was on, any
open files are closed, and any allocated memory is released.
Use the debug hpi all command to view gateway DSP modem relay termination codes. The DSP-to-host
messages for the modem relay termination indicate to the host the modem relay session termination time,
physical or link layer, and other probable causes for disconnection. On receiving this indication from the
DSP, the host can disconnect the call or place the channel in the modem passthrough state.
When this command is used on a Cisco AS5300 during a calling session, the Cisco AS5300 displays the
following information (of severity 6 whereas ordinary debug information is severity 7) on the screen by
default:
2w6d:%ISDN-6-DISCONNECT:Interface Serial0:18 disconnected from 22022 , call lasted 12
seconds
2w6d:%ISDN-6-DISCONNECT:Interface Serial1:9 disconnected from 32010 , call lasted 14
seconds
2w6d:%ISDN-6-CONNECT:Interface Serial3:2 is now connected to 52003
2w6d:%ISDN-6-CONNECT:Interface Serial2:11 is now connected to 42002
To disable this default information on the Cisco AS5300 and to block the display of the
debug hpi capture and show voice hpi capture commands, set the login console to a severity lower
than 6.
Examples The following example turns on the debug output from capture routines:
Router# debug hpi capture
HPI Capture/Logger debugging is on

show voice hpi capture Verifies capture status and statistics.

May 2008 DB-859
Debug Commands
debug http client cookie

To display debugging traces for cookie-related processes, including sending, receiving, validating,
storing, and expiring a cookie, use the debug http client cookie command in privileged EXEC mode.
no debug http client cookie

Examples The following sample output from the debug http client cookie command shows that a cookie is being
received and stored:
Router# debug http client cookie
*May 6 23:23:41.995: //38//HTTPC:/httpc_decode_msgheader: received

cookie:TestCookieX=username; path=/; domain=.cisco.com
URL:http://rtsp-ws.cisco.com/cookie.php
*May 6 23:23:41.995: //38//HTTPC:/httpc_decode_msgheader: received
cookie:TestCookieY=password; expires=Thu, 06-May-04 22:30:47 GMT; path=/;
domain=.cisco.com URL:http://rtsp-ws.cisco.com/cookie.php
*May 6 23:23:41.995: //38//HTTPC:/httpc_cookie_store: validating
cookie:TestCookieX=username; path=/; domain=.cisco.com
*May 6 23:23:41.995: //38//HTTPC:/httpc_cookie_store: store cookie:TestCookieX=username
path=/ domain=.cisco.com
*May 6 23:23:41.995: //38//HTTPC:/httpc_cookie_store:
rtsp-7#validating cookie:TestCookieY=password; expires=Thu, 06-May-04 22:30:47 GMT;
path=/; domain=.cisco.com
*May 6 23:23:41.995: //38//HTTPC:/httpc_cookie_store: store cookie:TestCookieY=password
path=/ domain=.cisco.com
*May 6 23:23:41.995: //38//HTTPC:/httpc_process_response: TestCookieY=password path=/
domain=.cisco.com
TestCookieX=username path=/ domain=.cisco.com

http client cache memory Configures the memory limits for the HTTP client cache.
http client cache refresh Configures the refresh time for the HTTP client cache.

DB-860 May 2008
Debug Commands
Command Description
http client cookie Enables the HTTP client to send and receive cookies.
show http client cookie Displays cookies that are being stored by the HTTP client.

May 2008 DB-861
Debug Commands
debug http client
debug http client

To display debugging messages for the HTTP client, use the debug http client command in privileged
debug http client {all | api | background | cache | error | main | msg | socket}
no debug http client {all | api | background | cache | error | main | msg | socket}
Syntax Description all Displays all debugging messages for the HTTP client.
api Displays debugging information for the HTTP client application
programming interface (API) process.
background Displays background messages.
cache Displays debugging information for the HTTP client cache module.
error Displays the HTTP client error messages.
main Displays debugging information for the HTTP client main process.
msg Displays the HTTP client messages.
socket Displays the HTTP client socket messages.

12.2(2)XB This command was introduced on the Cisco AS5300,
Cisco AS5350, and Cisco AS5400.
12.2(11)T This command was implemented on the Cisco 3640 and Cisco 3660,
and the background keyword was added.
Usage Guidelines The output of this command is effected by the debug condition application voice command. If the
debug condition application voice command is configured and the <cisco-debug> element is enabled
in the VoiceXML document, debugging output is limited to the VoiceXML application named in the
debug condition application voice command.
Note We recommend that you log output from the debug http client msg and debug http client socket
commands to a buffer, rather than sending the output to the console; otherwise, the size of the output
could severely impact the performance of the gateway.

DB-862 May 2008
Debug Commands
debug http client
Examples The following is sample output from the debug http client api command:
Router# debug http client api
HTTP Client API Process debugging is on
*Jan 3 10:58:48.609: httpc_send_ev: event sent to HTTP Client:

*Jan 3 10:58:48.609: method (GET), url (http://serverX.com/vxml/test/prompts/9.au)
*Jan 3 10:58:48.609: callback (61008E78), argp (63590DB4), sid (0), timeout (60),
retries (2)
*Jan 3 10:58:48.609: httpc_free: app freeing response data(626FA608)
*Jan 3 10:58:59.353: method (GET), url (http://1.7.100.1/vxml/test/dropoffRecord)
*Jan 3 10:58:59.353: callback (61008E78), argp (6393B684), sid (0), timeout (60),
retries (0)
*Jan 3 10:58:59.369: httpc_free: app freeing response data(626F9348)
*Jan 3 10:59:45.033: method (POST), url
(http://rtsp-ws/dropoffAppend.php?append=&disconnect=1)
*Jan 3 10:59:45.033: callback (60FE9064), argp (63448820), sid (7179), timeout (0),
retries (0)
*Jan 3 10:59:57.369: httpc_free: app freeing response data(626F9340)
The following is sample output from the debug http client cache command:
Router# debug http client cache
HTTP Client Cache Module debugging is on
*Jan 3 11:53:52.817: httpc_cache_rsp_return:

cache(626F8E50)URL:http://serverX.com/vxml/test/root.vxml
*Jan 3 11:53:52.829: httpc_cache_entry_free:
cache(626F8B30)URL:http://serverX.com/vxml/test/getPhoneInfo.vxml?ani=1234567&dnis=7654321
cache(626F9710)URL:http://1.7.100.1/vxml/test/engine.vxml?flow=iso
cache(626F8B30)URL:http://1.7.100.1/vxml/test/root.vxml
cache(626F9030)URL:http://1.7.100.1/vxml/test/getExtension.vxml
cache(626F9170)URL:http://1.7.100.1/vxml/test/checkExtension.vxml?extension=1234&attempt=1
cache(626F9A30)URL:http://1.7.100.1/vxml/test/dropoff.vxml
cache(626F9DF0)URL:http://serverX.com/vxml/test/init.vxml
cache(626FA430)URL:http://1.7.100.1/vxml/test/dropoffRecord
*Jan 4 00:20:23.474: httpc_cache_store: entry(http://ServerY.com/vxml/init.vxml)
size(10114 bytes) is too large to cache.
The following is sample output from the debug http client main command:
Router# debug http client main
HTTP Client Main Process debugging is on
*Jan 3 11:56:05.885: httpc_get, url: http://serverX.com/vxml/test/root.vxml

*Jan 3 11:56:05.889: httpc_msg_send, sid: 0, method: 83951618
*Jan 3 11:56:05.889: httpc_enqueue_wmsg, sid: 0, method: 83951618
*Jan 3 11:56:05.893: httpc_process_write_queue, socket writeble fd: 0, process enqueued
msg, sid: 0, method: 83951618
*Jan 3 11:56:05.893: httpc_msg_write, sid: 0, method: 83951618
*Jan 3 11:56:05.901: HTTPC_MSG_COMPLETE:
rsp_code(304),msg(62C9C25C)URL:http://serverX.com/vxml/test/root.vxml, fd(0)

May 2008 DB-863
Debug Commands
debug http client
*Jan 3 11:56:05.901: httpc_process_redirect_rsp:

msg(62C9C25C)URL:http://serverX.com/vxml/test/root.vxml, response code
HTTPC_NOT_MODIFIED_304
*Jan 3 11:56:05.913: httpc_get, url:
http://serverX.com/vxml/test/getPhoneInfo.vxml?ani=1234567&dnis=7654321
msg,
sid: 0, method: 65538
rsp_code(200),msg(62CB5824)URL:http://serverX.com/vxml/test/getPhoneInfo.vxml?ani=1234567&
dnis=7654321, fd(1)
*Jan 3 11:56:05.929: httpc_get, url: http://1.7.100.1/vxml/test/engine.vxml?flow=iso
*Jan 3 11:56:05.929: httpc_process_free_rsp: User returns noncache response (626F9670)
msg,
sid: 0, method: 65538
rsp_code(200),msg(62CB03AC)URL:http://1.7.100.1/vxml/test/engine.vxml?flow=iso, fd(1)
The following is sample output from the debug http client msg command:
Router# debug http client msg
HTTP Client:
HTTP Client Messages debugging is on
*Jan 1 05:07:30.534: HTTP Client write buffer fd(0):

GET /vxml/abcdefg/test/init.vxml HTTP/1.1
Host: c5300-2
Content-Type: application/x-www-form-urlencoded
Connection: Keep-Alive
Accept: text/vxml; level = 1, text/plain, text/html, audio/basic
User-Agent: Cisco-IOS-C5300/12.2(20010829:180555) VoiceXML/1.0
*Jan 1 05:07:30.538: about to send data to socket 0 :

first 263 bytes of data:
62397130: 47455420 GET

62397140: 2F76786D 6C2F6162 63646566 672F7465 /vxml/abcdefg/te
62397150: 73742F69 6E69742E 76786D6C 20485454 st/init.vxml HTT
62397160: 502F312E 310D0A48 6F73743A 20633533 P/1.1..Host: c53
62397170: 30302D32 0D0A436F 6E74656E 742D5479 00-2..Content-Ty
62397180: 70653A20 6170706C 69636174 696F6E2F pe: application/
62397190: 782D7777 772D666F 726D2D75 726C656E x-www-form-urlen
623971A0: 636F6465 640D0A43 6F6E6E65 6374696F coded..Connectio
623971B0: 6E3A204B 6565702D 416C6976 650D0A41 n: Keep-Alive..A
623971C0: 63636570 743A2074 6578742F 76786D6C ccept: text/vxml
623971D0: 3B206C65 76656C20 3D20312C 20746578 ; level = 1, tex
623971E0: 742F706C 61696E2C 20746578 742F6874 t/plain, text/ht
623971F0: 6D6C2C20 61756469 6F2F6261 7369630D ml, audio/basic.
62397200: 0A557365 722D4167 656E743A 20436973 .User-Agent: Cis
62397210: 636F2D49 4F532D43 35333030 2F31322E co-IOS-C5300/12.
62397220: 32283230 30313038 32393A31 38303535 2(20010829:18055
62397230: 35292056 6F696365 584D4C2F 312E300D 5) VoiceXML/1.0.
62397240: 0A0D0A00 ....
*Jan 1 05:07:30.546: read data from socket 0 :
first 400 bytes of data:

DB-864 May 2008
Debug Commands
debug http client
628DE8F0: 48545450 2F312E31 20323030 HTTP/1.1 200

628DE900: 204F4B0D 0A446174 653A2046 72692C20 OK..Date: Fri,
628DE910: 33312041 75672032 30303120 30373A30 31 Aug 2001 07:0
628DE920: 363A3335 20474D54 0D0A5365 72766572 6:35 GMT..Server
628DE930: 3A204170 61636865 2F312E33 2E313120 : Apache/1.3.11
628DE940: 28556E69 78292041 70616368 654A5365 (Unix) ApacheJSe
628DE950: 72762F31 2E300D0A 4C617374 2D4D6F64 rv/1.0..Last-Mod
628DE960: 69666965 643A2057 65642C20 3233204D ified: Wed, 23 M
628DE970: 61792032 30303120 31353A35 333A3233 ay 2001 15:53:23
628DE980: 20474D54 0D0A4554 61673A20 22323430 GMT..ETag: "240
628DE990: 37642D31 39322D33 62306264 63663322 7d-192-3b0bdcf3"
628DE9A0: 0D0A4163 63657074 2D52616E 6765733A ..Accept-Ranges:
628DE9B0: 20627974 65730D0A 436F6E74 656E742D bytes..Content-
628DE9C0: 4C656E67 74683A20 3430320D 0A4B6565 Length: 402..Kee
628DE9D0: 702D416C 6976653A 2074696D 656F7574 p-Alive: timeout
628DE9E0: 3D352C20 6D61783D 31300D0A 436F6E6E =5, max=10..Conn
628DE9F0: 65637469 6F6E3A20 4B656570 2D416C69 ection: Keep-Ali
628DEA00: 76650D0A 436F6E74 656E742D 54797065 ve..Content-Type
628DEA10: 3A207465 78742F76 786D6C0D 0A0D0A3C : text/vxml....<
628DEA20: 3F786D6C 20766572 73696F6E 3D22312E ?xml version="1.
628DEA30: 30223F3E 0A3C7678 6D6C2076 65727369 0"?>.<vxml versi
628DEA40: 6F6E3D22 312E3022 20617070 6C696361 on="1.0" applica
628DEA50: 74696F6E 3D22726F 6F742E76 786D6C22 tion="root.vxml"
628DEA60: 3E0A2020 3C666F72 6D3E0A20 2020203C >. <form>. <
628DEA70: 626C6F63 6B3E0A20 20202020 203C212D block>. <!-
628DEA80: 2D0A2020 20 -.
*Jan 1 05:07:30.550: httpc_decode_msgheader: Client ignores this header: Server:
Apache/1.3.11 (Unix) ApacheJServ/1.0
*Jan 1 05:07:30.554: httpc_decode_msgheader: Client ignores this header: Accept-Ranges:
bytes
*Jan 1 05:07:30.554: processing server rsp msg:
msg(62C711C4)URL:http://vvv.com/vxml/abcdefg/test/init.vxml, fd(0):
*Jan 1 05:07:30.554: Request msg: GET /vxml/abcdefg/test/init.vxml HTTP/1.1
*Jan 1 05:07:30.554: Message Response Code: 200
*Jan 1 05:07:30.554: Message Rsp Decoded Headers:
*Jan 1 05:07:30.554: Date:Fri, 31 Aug 2001 07:06:35 GMT
*Jan 1 05:07:30.554: Content-Length:402
*Jan 1 05:07:30.554: Content-Type:text/vxml
*Jan 1 05:07:30.554: ETag:"2407d-192-3b0bdcf3"
*Jan 1 05:07:30.554: Last-Modified:Wed, 23 May 2001 15:53:23 GMT
*Jan 1 05:07:30.554: Connection:Keep-Alive
*Jan 1 05:07:30.554: Keep-Alive:timeout=5, max=10
*Jan 1 05:07:30.554: httpc_dump_msg: headers:
*Jan 1 05:07:30.554: HTTP/1.1 200 OK
Date: Fri, 31 Aug 2001 07:06:35 GMT
Server: Apache/1.3.11 (Unix) ApacheJServ/1.0
Last-Modified: Wed, 23 May 2001 15:53:23 GMT
ETag: "2407d-192-3b0bdcf3"
Accept-Ranges: bytes
Content-Length: 402
Keep-Alive: timeout=5, max=10
Connection: Keep-Alive
Content-Type: text/vxml
*Jan 1 05:07:30.558: httpc_dump_msg: body:

*Jan 1 05:07:30.558: <?xml version="1.0"?>
<vxml version="1.0" application="root.vxml">
<form>
<block>

<var name="ani" expr="1234567"/>

May 2008 DB-865
Debug Commands
debug http client
<var name="dnis" expr="7654321"/>

<submit next="getPhoneInfo.vxml" method="get" namelist="ani dnis"/>
</block>
</form>
</vxml>
The following is sample output from the debug http client socket command:
Router# debug http client socket
HTTP Client Sockets debugging is on
*Jan 3 11:32:38.353: httpc_process_read_ev: HTTPC SOCK_PENDING --> SOCK_CONNECTED fd(0)

port(80)
port(80)
*Jan 3 11:32:38.381: httpc_socket_cleanup: fd(1)
port(80)
port(80)
*Jan 3 11:40:43.557: httpc socket_connect failed fd(2)
The following is sample output from the debug http client error command:
Router# debug http client error
HTTP Client Error debugging is on
*Jan 3 12:07:40.209: HTTPC URL:http://serverX.com/vxml/test.vxml, Server rsp_code(404),

fd(0)
*Jan 3 12:08:01.677: HTTPC SOCK_FAIL() - msg(62CA5FB4)URL:http://serverX/vxml/test.vxml
*Jan 3 12:08:01.677: httpc_free: NULL pointer argument
*Jan 3 12:08:01.677: HTTPC URL:http://serverX/vxml/test.vxml, MSG_XMIT_ERROR, fd(-1)
Jan 3 23:44:06 PDT: HTTPC
URL:http://serverY.com:9000/ivr/sid-351/dropoffDeposit?pri=0&disconnect=1, TIMEOUT(60000
msec), fd(-1)
Jan 3 23:44:07 PDT: HTTPC msg timeout waiting for rsp - fd(21)
Jan 3 23:44:07 PDT: httpc_free: NULL pointer argument
Jan 4 02:45:07 PDT: HTTPC msg timeout waiting for rsp - fd(0)
Jan 4 02:45:07 PDT: HTTPC URL:http://rtsp-ws/dropoffAppend.php?append=&disconnect=1,
TIMEOUT(10000 msec), fd(-1)
Jan 4 02:46:07 PDT: httpc_msg_read: URL(http://1.7.100.1/vxml/root.vxml) - msg length

not available.Failed to parse message body.
Jan 4 02:46:07 PDT: httpc_msg_read: ERROR - DECODE
Jan 4 02:46:08 PDT: HTTPC bad message read - fd(6), conp(632A93B4),
msg(63280794)URL:http://1.7.100.1/vxml/test/root.vxml, len(1611)
Jan 4 02:46:08 PDT: First 400 bytes read from socket:
6241D9C0: 3C3F78 <?x

6241D9D0: 6D6C2076 65727369 6F6E3D22 312E3022 ml version="1.0"
6241D9E0: 3F3E0A3C 76786D6C 20766572 73696F6E ?>.<vxml version
6241D9F0: 3D22312E 30223E0A 0A20203C 70726F70 ="1.0">.. <prop
6241DA00: 65727479 206E616D 653D2263 61636869 erty name="cachi
6241DA10: 6E672220 76616C75 653D2273 61666522 ng" value="safe"
6241DA20: 2F3E0A20 203C7072 6F706572 7479206E />. <property n
6241DA30: 616D653D 2274696D 656F7574 22207661 ame="timeout" va
6241DA40: 6C75653D 22333073 222F3E0A 20203C70 lue="30s"/>. <p
6241DA50: 726F7065 72747920 6E616D65 3D226665 roperty name="fe

DB-866 May 2008
Debug Commands
debug http client
6241DA60: 74636874 696D656F 75742220 76616C75 tchtimeout" valu

6241DA70: 653D2236 3073222F 3E0A2020 3C70726F e="60s"/>. <pro
6241DA80: 70657274 79206E61 6D653D22 696E7075 perty name="inpu
6241DA90: 746D6F64 65732220 76616C75 653D2264 tmodes" value="d
6241DAA0: 746D6622 2F3E0A0A 20203C76 6172206E tmf"/>.. <var n
6241DAB0: 616D653D 22736964 22206578 70723D22 ame="sid" expr="
6241DAC0: 27313131 31312722 2F3E0A20 203C7661 '11111'"/>. <va
6241DAD0: 72206E61 6D653D22 6C632220 65787072 r name="lc" expr
6241DAE0: 3D222765 6E2D7573 27222F3E 0A20203C ="'en-us'"/>. <
6241DAF0: 76617220 6E616D65 3D226861 6E646C65 var name="handle
6241DB00: 22206578 70723D22 74727565 222F3E0A " expr="true"/>.
6241DB10: 0A20203C 63617463 68206576 656E743D . <catch event=
6241DB20: 2274656C 6570686F 6E652E64 6973636F "telephone.disco
6241DB30: 6E6E6563 74222063 6F6E643D 2268616E nnect" cond="han
6241DB40: 646C6522 3E0A2020 20203C61 73736967 dle">. <assig
6241DB50: 6E206E61 6D653D22 68616E64 6C65 n name="handle
Jan 4 02:47:08 PDT: httpc_free: NULL pointer argument
Jan 4 02:47:09 PDT: HTTPC URL:http://1.7.100.1/vxml/test/root.vxml, MSG_DECODE_ERROR,
fd(6)
Jan 4 03:47:09 PDT: WARNING:httpc_msg_retry:
msg(6325CDD4):http://vvv.com/vxml/prompts/5.au

debug condition application voice Displays debugging messages for only the specified
VoiceXML application.
debug voip ivr Displays debugging messages for VoIP IVR interactions.
debug vxml Displays debugging messages for VoIP VoiceXML
interactions.

May 2008 DB-867
Debug Commands
debug hw-module all upgrade

To enable debug messages for field-programmable devices (FPDs), use the debug hw-module all
upgrade command in privileged EXEC configuration mode. To disable debug messages, use the no form
of the command.
debug hw-module all upgrade [error | event]
no debug hw-module all upgrade [error | event]
Syntax Description all Enable debug messaging for all supported modules in the system.
error (Optional) Enables display of FPD upgrade error messages.
event (Optional) Enables display of FPD upgrade event messages.

platform hardware.
Usage Guidelines The debug hw-module all upgrade command is intended for use by Cisco Systems technical support
personnel.
If you attempt to use this command without a SPA installed, or with an incompatible SPA installed, the
keyword options are not provided.
troubleshooting sessions with Cisco Systems technical support personnel. Moreover, it is best to use
debug commands during periods of lower network traffic and fewer users. Debugging during these
periods decreases the likelihood that increased debug command processing overhead will affect system
use.
For more information about FPD upgrades on SPA interface processors (SIPs) and shared port adapters
(SPAs), refer to the Cisco 7600 Series Router SIP, SSC, and SPA Software Configuration Guide.

DB-868 May 2008
Debug Commands
Examples The following example enables FPD upgrade debug messages for all supported card types on the
Cisco 7600 series router:
Router# debug hw-module all upgrade

May 2008 DB-869
Debug Commands
debug hw-module subslot

To debug a shared port adapter (SPA) and all of its interfaces, use the debug hw-module subslot
command in privileged EXEC configuration mode.
debug hw-module subslot slot/subslot {all | driver | fpga | if | mac | phy | tcam | upgrade [error
| event] intr | force-intr}
no debug hw-module subslot slot/subslot {all | driver | fpga | if | mac | phy | tcam | upgrade [error
| event] intr | force-intr}
Syntax Description slot Chassis slot number.

Refer to the appropriate hardware manual for slot information. For SIPs, refer
to the platform-specific SPA hardware installation guide or the corresponding
Identifying Slots and Subslots for SIPs and SPAs topic in the
platform-specific SPA software configuration guide.
/subslot Secondary slot number on a SIP where a SPA is installed.
Refer to the platform-specific SPA hardware installation guide and the
corresponding Specifying the Interface Address on a SPA topic in the
platform-specific SPA software configuration guide for subslot information.
all Enables all SPA debug messages.
driver Enables debug messages for SPA drivers.
fpga Enables debug messages related to SPA field programmable gate array (FPGA)
processing.
if Enables debug messages related to SPA interface processing
mac Enables debug messages related to SPA MAC driver processing.
phy Enables debug messages related to SPA PHY driver processing.
tcam Enables debug messages related to SPA ternary content addressable memory
(TCAM) processing.
upgrade [error | Enables debug messages related to Field-Programmable Device (FPD) upgrade
event] information.
errorSpecifies that upgrade error messages are displayed.
eventSpecifies that upgrade event messages are displayed.
intr Enables debug messages related to SPA interrupts.
Caution The intr option should be used only under the supervision of Cisco
Systems technical support personnel and is not intended for
production networks.
force-intr Enables debug messages related to manually forced SPA interrupts.
Caution The force-intr option should be used only under the supervision of
Cisco Systems technical support personnel and is not intended for
production networks.

DB-870 May 2008
Debug Commands

12.2(20)S2 This command was introduced.
platform hardware.
Usage Guidelines The debug hw-module subslot command is intended for use by Cisco Systems technical support
personnel.
If you attempt to use this command without a SPA installed, or with an incompatible SPA installed, the
keyword options are not provided.
use.
Examples The following example enables interface debug messages for the 4-Port 10/100 Fast Ethernet SPA
located in the top subslot (0) of the MSC that is installed in slot 4 of the Cisco 7304 router and shows an
interface being shut down and restarted:
Router# debug hw-module subslot 4/0 if
SPA 4xFE/2xGE interface debugging is on
Router# conf t
Router(config)# int fast 4/0/0
Router(config-if)#
4d01h: Interface FastEthernet4/0/0, stopping the devices
4d01h: Interface FastEthernet4/0/0, Turning off the port LED
Router(config-if)#
4d01h: %LINK-5-CHANGED: Interface FastEthernet4/0/0, changed state to administratively
down
4d01h: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet4/0/0, changed state to
down
Router(config-if)#
Router(config-if)#
4d01h: Interface FastEthernet4/0/0, stopping the devices
4d01h: Interface FastEthernet4/0/0, clearing the MAC address filter table
4d01h: Interface FastEthernet4/0/0, Disabling promiscuous mode
4d01h: Interface FastEthernet4/0/0, setting the MAC address to 00b0.64ff.4480
4d01h: Interface FastEthernet4/0/0, Disabling promiscuous mode

May 2008 DB-871
Debug Commands
4d01h: Interface FastEthernet4/0/0, configuring media_type = RJ45, speed = Auto Speed,

duplex = Auto Duplex, mode = auto-negotiation
4d01h: Interface FastEthernet4/0/0, starting the devices
4d01h: Interface FastEthernet4/0/0, clearing the hardware counters
4d01h: %LINK-3-UPDOWN: Interface FastEthernet4/0/0, changed state to up
4d01h: Interface FastEthernet4/0/0, Setting port LED to green
4d01h: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet4/0/0, changed state to
up

DB-872 May 2008
Debug Commands
debug hw-module subslot commands

To enable debug messages for control plane configuration and commands on a shared port adapter (SPA),
use the debug hw-module subslot commands command in privileged EXEC configuration mode. To
disable debug messages, use the no form of the command.
debug hw-module subslot {slot/subslot | all} commands
no debug hw-module subslot {slot/subslot | all} commands

/subslot Secondary slot number on a SPA interface processor (SIP) where a SPA is
installed.
all Enable debug messaging for all supported modules in the system.

platform hardware.
Usage Guidelines The debug hw-module subslot commands are intended for use by Cisco Systems technical support
personnel.
If you attempt to use a debug hw-module subslot command without a SPA installed, or with an
incompatible SPA installed, the keyword options are not provided.

May 2008 DB-873
Debug Commands
use.
Examples The following example enables control plane debug messages for the SPA located in the top subslot (0)
of the SIP that is installed in slot 4 of a router:
Router# debug hw-module subslot 4/0 commands

DB-874 May 2008
Debug Commands
debug hw-module subslot errors

To enable debug messages for error handling and race conditions on a shared port adapter (SPA), use the
debug hw-module subslot errors command in privileged EXEC configuration mode. To disable debug
messages, use the no form of the command.
debug hw-module subslot {slot/subslot | all} errors
no debug hw-module subslot {slot/subslot | all} errors

installed.

platform hardware.
personnel.

May 2008 DB-875
Debug Commands
use.
Examples The following example enables error handling debug messages for the SPA located in the top subslot (0)
Router# debug hw-module subslot 4/0 errors

DB-876 May 2008
Debug Commands
debug hw-module subslot events

To enable debug messages for control plane event notifications on a shared port adapter (SPA), use the
debug hw-module subslot events command in privileged EXEC configuration mode. To disable debug
debug hw-module subslot {slot/subslot | all} events
no debug hw-module subslot {slot/subslot | all} events

installed.

platform hardware.
personnel.

May 2008 DB-877
Debug Commands
use.
Examples The following example enables control plane event messages for the SPA located in the top subslot (0)
Router# debug hw-module subslot 4/0 events

DB-878 May 2008
Debug Commands
debug hw-module subslot interrupts

To enable debug messages for interrupt handling on a shared port adapter (SPA), use the debug
hw-module subslot interrupts command in privileged EXEC configuration mode. To disable debug
debug hw-module subslot {slot/subslot | all} interrupts
no debug hw-module subslot {slot/subslot | all} interrupts

installed.

a specific 12.2SX release of this train depends on your feature set, platform,
personnel.

May 2008 DB-879
Debug Commands
use.
Examples The following example enables interrupt handling debug messages for the SPA located in the top subslot
(0) of the SIP that is installed in slot 4 of a router:
Router# debug hw-module subslot 4/0 interrupts

DB-880 May 2008
Debug Commands
debug hw-module subslot ipcshim
debug hw-module subslot ipcshim

To enable debug messages for Inter-Process Communication (IPC) shim application processing for all
supported modules in the system, use the debug hw-module subslot ipcshim command in privileged
EXEC configuration mode. To disable debug messages, use the no form of the command.
debug hw-module subslot all ipcshim
no debug hw-module subslot all ipcshim

platform hardware.
personnel.
The debug hw-module subslot ipcshim command is only supported by certain shared port adapters
(SPAs).
use.
Examples The following example enables IPC SHIM application debug messages for all supported modules in the
router:
Router# debug hw-module subslot all ipcshim

May 2008 DB-881
Debug Commands
debug hw-module subslot oir

To enable debug messages for online insertion and removal (OIR) processing on a shared port adapter
(SPA), use the debug hw-module subslot oir command in privileged EXEC configuration mode. To
disable debug messages, use the no form of the command.
debug hw-module subslot {slot/subslot | all} oir {plugin | state-machine}
no debug hw-module subslot {slot/subslot | all} oir {plugin | state-machine}

installed.
plugin Enable debug messaging for platform-provided plugin routines.
state-machine Enable debug messaging for SPA OIR state machines.

platform hardware.
personnel.

DB-882 May 2008
Debug Commands
use.
Examples The following example shows enabling of OIR plugin debug messages for the SPA located in subslot 1
of the SIP that is installed in slot 4 of the router, and the corresponding messages during a SPA reload:
Router# debug hw-module subslot 4/1 oir plugin
WARNING: This command is not intended for production use
and should only be used under the supervision of
Cisco Systems technical support personnel.
SPA subslot 4/1:

SPA specific oir handling debugging is on
Router# hw-module subslot 4/1 reload
Router#
Mar 26 01:35:04: cwrp_handle_spa_oir_tsm_event: subslot 4/1 event=9
Router#

May 2008 DB-883
Debug Commands
debug hw-module subslot periodic

To enable debug messages for periodic processing on a shared port adapter (SPA), use the debug
hw-module subslot periodic command in privileged EXEC configuration mode. To disable debug
debug hw-module subslot {slot/subslot | all} periodic
no debug hw-module subslot {slot/subslot | all} periodic

installed.

platform hardware.
personnel.

DB-884 May 2008
Debug Commands
use.
Examples The following example enables periodic processing debug messages for the SPA located in the top
subslot (0) of the SIP that is installed in slot 4 of a router:
Router# debug hw-module subslot 4/0 periodic

May 2008 DB-885
Debug Commands
debug iapp
debug iapp
Use the debug iapp privileged EXEC command to begin debugging of IAPP operations. Use the no form
of this command to stop the debug operation.
[no] debug iapp

{packets | event | error}
Syntax Description packets Displays IAPP packets sent and received by the access point. Link test
packets are not displayed
event Displays significant IAPP events
error Displays IAPP software and protocol errors
Defaults This command has no default setting.

Examples This example shows how to begin debugging of IAPP packets:

SOAP-AP# debug iapp packet
This example shows how to begin debugging of IAPP events:

SOAP-AP# debug iapp events
This example shows how to begin debugging of IAPP errors:

SOAP-AP# debug iapp errors

show debugging Displays all debug settings

DB-886 May 2008
Debug Commands
debug ima
debug ima
To display debugging messages for inverse multiplexing over AMT (IMA) groups and links, use the
debug ima command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug ima
no debug ima
Defaults Debugging for IMA groups is not enabled.

12.0(5)XK This command was modified.
Examples The following example shows output when you enter the debug ima command while adding two ATM
links to an IMA group. Notice that the group has not yet been created with the interface atm
slot/imagroup-number command, so the links are not activated yet as group members. However, the
individual ATM links are deactivated.
Router# debug ima
IMA network interface debugging is on

Router# config terminal
Router(config)# interface atm1/0
Router(config-if)# ima-group 1
Router(config-if)#
01:35:08:IMA shutdown atm layer of link ATM1/0
01:35:08:ima_clear_atm_layer_if ATM1/0
01:35:08:IMA link ATM1/0 removed in firmware
01:35:08:ima_release_channel:ATM1/0 released channel 0.
01:35:08:Bring up ATM1/4 that had been waiting for a free channel.
01:35:08:IMA:no shut the ATM interface.
01:35:08:IMA allocate_channel:ATM1/4 using channel 0.
01:35:08:IMA config_restart ATM1/4
01:35:08:IMA adding link 0 to Group ATM1/IMA1ATM1/0 is down waiting for IMA group 1 to be
activated
01:35:08:Link 0 was added to Group ATM1/IMA1

May 2008 DB-887
Debug Commands
debug ima
01:35:08:ATM1/0 is down waiting for IMA group 1 to be created.

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

debug backhaul-session-manager set Displays debugging messages for ATM errors, and
reports specific problems such as encapsulation errors
and errors related to OAM cells.
debug events Displays debugging messages for ATM events, and
reports specific events such as PVC setup completion,
changes in carrier states, and interface rates.

DB-888 May 2008
Debug Commands
debug ip access-list intstats

To display debugging information about ACL interface level statistics, use the debug ip access-list
intstats command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
no debug ip access-list intstats

12.4(6)T This command was modified to include support for ACL interface level
statistics.
Usage Guidelines The debug ip access-list intstats command is useful for debugging problems associated with ACL
interface level statistics. These interface level statistics are ACL statistics that are maintained per
interface and per traffic direction (input/output). This means that when a packet matches an entry in an
ACL, the corresponding ACL statistics are updated for the interface on which the ACL is applied and
the direction (input/output) in which the ACL is applied.
Examples The following example is sample output from the debug ip access-list intstats command:
Router# debug ip access-list intstats

Router(config)# interface FastEthernet 0/0
Router(config-if)# ip access-group 150 in
000042: *Mar 14 11:36:04.367 UTC: IPACL-INTSTATS: ACL swsb created
000043: *Mar 14 11:36:04.367 UTC: IPACL-INTSTATS: ACL header stats structure created
000044: *Mar 14 11:36:04.367 UTC: IPACL-INTSTATS: I/P stats table created
000045: *Mar 14 11:36:04.367 UTC: IPACL-INTSTATS: Statsid bitmap created
000046: *Mar 14 11:36:04.367 UTC: IPACL-INTSTATS: Done with static ACEs
Router(config-if)# no ip access-group 150 in

000047: *Mar 14 11:36:36.575 UTC: IPACL-INTSTATS: Freeing I/P stats table
000048: *Mar 14 11:36:36.575 UTC: IPACL-INTSTATS: Succesfully removed ACL from interface
000049: *Mar 14 11:36:36.575 UTC: IPACL-INTSTATS: ACL swsb destroyed

May 2008 DB-889
Debug Commands

show ip access-list Displays the contents of all current IP access lists.

DB-890 May 2008
Debug Commands
debug ip access-list turboacl

To display debugging information about turbo access control lists (ACLs), use the debug ip access-list
turboacl command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
no debug ip access-list turboacl
Defaults No default behaviors or values

12.3(3)T This command was modified to include support for turbo ACLs.
Usage Guidelines The debug ip access-list turboacl command is useful for debugging problems associated with turbo
ACLs. Turbo ACLs compile the ACLs into a set of lookup tables, while maintaining the first packet
matching requirements. Packet headers are used to access these tables in a small, fixed, number of
lookups, independent of the existing number of ACL entries.
Examples The following is sample output from the debug ip access-list turboacl command:
Router# debug ip access-list turboacl
*Aug 20 00:41:17.843 UTC:Miss at index 73, 19

*Aug 20 00:41:17.843 UTC:Adding dynamic entry, update = 1

May 2008 DB-891
Debug Commands

*Aug 20 00:41:17.859try, update = 1
Table 112 debug ip access-list turboacl Field Descriptions
Field Description
Aug 20 00:41:17.843 UTC Date and Coordinated Universal Time (UTC) the command was
used to debug the turbo ACL.
Miss at index 73, 19 Location in the compiled access list tables where a new packet
lookup does not match an existing entry.
Adding dynamic entry, update = 1 Action taken to add a new entry in the compiled access list
tables as a result of a packet being processed.

DB-892 May 2008
Debug Commands
debug ip admission consent
debug ip admission consent

To display authentication proxy consent page information on the router, use the debug ip admission
consent command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug ip admission consent [events | errors | messages]
no debug ip admission consent
Syntax Description errors (Optional) Displays only error messages.

events (Optional) Displays only event-related messages.
messages (Optional) Displays only packet-related messages.
Command Default If an option is not selected, all debug messages are displayed.

Examples Router# debug ip admission consent errors

IP Admission Consent Errors debugging is on
Router# debug ip admission consent events

IP Admission Consent Events debugging is on
Router# debug ip admission consent messages

IP Admission Consent Messages debugging is on
Router#
IP Admission Consent:
IP Admission Consent Errors debugging is on
IP Admission Consent Events debugging is on
IP Admission Consent Messages debugging is on

May 2008 DB-893
Debug Commands
debug ip admission eapoudp

To display information about Extensible Authentication Protocol over User Datagram Protocol (UDP)
(EAPoUDP) network admission control events, use the debug ip admission eapoudp command in
no debug ip admission eapoudp

Examples The following sample output from the debug ip admission eapoudp command shows information about
network admission control using EAPoUDP. In the command output, the term posture refers to the
credentials (for example, antivirus state or version of Cisco IOS software) of the host system.
Router# debug ip admission eapoudp
Posture validation session created for client mac= 0001.027c.f364 ip= 10.0.0.1
Total Posture sessions= 1 Total Posture Init sessions= 1
*Apr 9 19:39:45.684: %AP-6-POSTURE_START_VALIDATION: IP=10.0.0.1|
Interface=FastEthernet0/0.420
*Apr 9 19:40:42.292: %AP-6-POSTURE_STATE_CHANGE: IP=10.0.0.1| STATE=POSTURE ESTAB
*Apr 9 19:40:42.292: auth_proxy_posture_parse_aaa_attributes:
CiscoDefined-ACL name= #ACSACL#-IP-HealthyACL-40921e54
Apr 9 19:40:42.957: %AP-6-POSTURE_POLICY: Apply access control list
(xACSACLx-IP-HealthyACL-40921e54) policy for host (10.0.0.1)
The fields in the display are self-explanatory.

show ip admission Displays IP admission control cache entries or the running admission control
configuration.

DB-894 May 2008
Debug Commands
debug ip auth-proxy
debug ip auth-proxy
To display the authentication proxy configuration information on the router, use the debug ip
auth-proxy command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug ip auth-proxy {detailed | ftp | function-trace | object-creation | object-deletion | telnet |

timers}
no debug ip auth-proxy
Syntax Description detailed Displays details of the TCP events during an authentication proxy process.
The details are generic to all FTP, HTTP, and Telnet protocols.
ftp Displays FTP events related to the authentication proxy.
function-trace Displays the authentication proxy functions.
object-creation Displays additional entries to the authentication proxy cache.
object-deletion Displays deletion of cache entries for the authentication proxy.
telnet Displays Telnet-related authentication proxy events.
timers Displays authentication proxy timer-related events.

12.3(1) The detailed keyword was added.
12.2(33)SRA.
12.2SX train. Support in a specific 12.2SX release of this
train depends on your feature set, platform, and platform
hardware.
Usage Guidelines Use the debug ip auth-proxy command to display authentication proxy activity.
Note The function-trace debugging information provides low-level software information for Cisco technical
support representatives. No output examples are provided for this keyword option.

May 2008 DB-895
Debug Commands
debug ip auth-proxy
Examples The following examples illustrate the output of the debug ip auth-proxy command. In these examples,
debugging is on for object creations, object deletions, HTTP, and TCP.
In this example, the client host at 192.168.201.1 is attempting to make an HTTP connection to the web
server located at 192.168.21.1. The HTTP debugging information is on for the authentication proxy. The
output shows that the router is setting up an authentication proxy entry for the login request:
00:11:10: AUTH-PROXY creates info:
cliaddr - 192.168.21.1, cliport - 36583
seraddr - 192.168.201.1, serport - 80
ip-srcaddr 192.168.21.1
pak-srcaddr 0.0.0.0
Following a successful login attempt, the debugging information shows the authentication proxy entries
created for the client. In this example, the client is authorized for SMTP (port 25), FTP data (port 20),
FTP control (port 21), and Telnet (port 23) traffic. The dynamic access control list (ACL) entries are
included in the display.
00:11:25:AUTH_PROXY OBJ_CREATE:acl item 61AD60CC
00:11:25:AUTH-PROXY OBJ_CREATE:create acl wrapper 6151C7C8 -- acl item 61AD60CC

00:11:25:AUTH-PROXY Src 192.168.162.216 Port [0]
00:11:25:AUTH-PROXY Dst 192.168.162.220 Port [25]
00:11:25:AUTH_PROXY OBJ_CREATE:acl item 6151C908
00:11:25:AUTH-PROXY OBJ_CREATE:create acl wrapper 6187A060 -- acl item 6151C908

00:11:25:AUTH_PROXY OBJ_CREATE:acl item 61A40B88
00:11:25:AUTH-PROXY OBJ_CREATE:create acl wrapper 6187A0D4 -- acl item 61A40B88

00:11:25:AUTH_PROXY OBJ_CREATE:acl item 61879550
00:11:25:AUTH-PROXY OBJ_CREATE:create acl wrapper 61879644 -- acl item 61879550

The next example shows the debug output following a clear ip auth-proxy cache command to clear the
authentication entries from the router. The dynamic ACL entries are removed from the router.
00:12:36:AUTH-PROXY OBJ_DELETE:delete auth_proxy cache 61AD6298
00:12:36:AUTH-PROXY OBJ_DELETE:delete create acl wrapper 6151C7C8 -- acl item 61AD60CC
00:12:36:AUTH-PROXY OBJ_DELETE:delete create acl wrapper 6187A060 -- acl item 6151C908
00:12:36:AUTH-PROXY OBJ_DELETE:delete create acl wrapper 6187A0D4 -- acl item 61A40B88
00:12:36:AUTH-PROXY OBJ_DELETE:delete create acl wrapper 61879644 -- acl item 61879550
The following example shows the timer information for a dynamic ACL entry. All times are expressed
in milliseconds. The first laststart is the time that the ACL entry is created relative to the startup time of
the router. The lastref is the time of the last packet to hit the dynamic ACL relative to the startup time of
the router. The exptime is the next expected expiration time for the dynamic ACL. The delta indicates
the remaining time before the dynamic ACL expires. After the timer expires, the debugging information
includes a message indicating that the ACL and associated authentication proxy information for the
client have been removed.
00:19:51:first laststart 1191112
00:20:51:AUTH-PROXY:delta 54220 lastref 1245332 exptime 1251112

00:21:45:AUTH-PROXY:ACL and cache are removed
The following example is sample output with the detailed keyword enabled:

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

show debug Displays the debug options set on the router.

May 2008 DB-897
Debug Commands
debug ip auth-proxy ezvpn

To display information related to proxy authentication behavior for web-based activation, use the debug
ip auth-proxy ezvpn command in privileged EXEC mode. To turn off debugging, use the no form of
this command.
no debug ip auth-proxy ezvpn
Defaults Debugging is not turned on.

Usage Guidelines
Caution Using this command may result in considerable output if simultaneous authentications are taking place.
Examples The following is output from the debug ip auth-proxy ezvpn command. The output displays the proxy
authentication behavior of a web-based activation.
Router# debug ip auth-proxy ezvpn
*Dec 20 20:25:11.006: AUTH-PROXY: New request received by EzVPN WebIntercept from

10.4.205.205
*Dec 20 20:25:17.150: AUTH-PROXY:GET request received
*Dec 20 20:25:17.150: AUTH-PROXY:Authentication scheme is 401
*Dec 20 20:25:17.362: AUTH-PROXY:Authorization information not present in GET request
*Dec 20 20:25:17.362: AUTH-PROXY: Allocated on credinfo for connect at 0x81EF1A84
*Dec 20 20:25:17.362: AUTH-PROXY: Posting CONNECT request to EzVPN
*Dec 20 20:25:17.362: EZVPN(tunnel22): Received CONNECT from 10.4.205.205!
*Dec 20 20:25:17.366: EZVPN(tunnel22): Current State: CONNECT_REQUIRED
*Dec 20 20:25:17.366: EZVPN(tunnel22): Event: CONNECT
The output in the display is self-explanatory.

DB-898 May 2008
Debug Commands

xauth userid mode Specifies how the Cisco Easy VPN Client handles Xauth requests or prompts
from the server.

May 2008 DB-899
Debug Commands
debug ip bgp
debug ip bgp
To display information related to processing of the Border Gateway Protocol (BGP), use the debug ip
bgp command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug ip bgp [A.B.C.D. | dampening | events | in | keepalives | out | updates | vpnv4 | mpls]
no debug ip bgp [A.B.C.D. | dampening | events | in | keepalives | out | updates | vpnv4 | mpls]
Cisco 10000 Series Router
debug ip bgp [A.B.C.D. | dampening | events | in | keepalives | out | updates | vpnv4 | mpls | all |
groups | import | ipv4 | ipv6]
no debug ip bgp [A.B.C.D. | dampening | events | in | keepalives | out | updates | vpnv4 | mpls |
all | groups | import | ipv4 | ipv6]
Syntax Description A.B.C.D. (Optional) Displays the BGP neighbor IP address.

dampening (Optional) Displays BGP dampening.
events (Optional) Displays BGP events.
in (Optional) Displays BGP inbound information.
keepalives (Optional) Displays BGP keepalives.
out (Optional) Displays BGP outbound information.
updates (Optional) Displays BGP updates.
vpnv4 (Optional) Displays Virtual Private Network version 4 (VPNv4) Network
Layer Reachability Information (NLRI).
mpls (Optional) Displays the Multiprotocol Label Switching (MPLS)
information.
all (Optional) Displays all address family information.
groups (Optional) Displays BGP configuration and update groups information.
import (Optional) Displays BGP import routes to a VPN routing and forwarding
(VRF) instance across address family information.
ipv4 (Optional) Displays BGP IPv4 address family information.
ipv6 (Optional) Displays BGP IPv6 address family information.

12.0(21)ST This command was integrated into Cisco IOS Release 12.0(21)ST. The
mpls keyword was added.

DB-900 May 2008
Debug Commands
debug ip bgp
12.2(11)S This feature was integrated into Cisco IOS Release 12.2(11)S.
12.2(13)T The mpls keyword was added.
12.0(27)S The command output was modified to show explicit-null label information.
Usage Guidelines Use this command with the updates and mpls keywords to display explicit-null label information.
Examples The following is sample output from the debug ip bgp command:
Router# debug ip bgp vpnv4
03:47:14:vpn:bgp_vpnv4_bnetinit:100:2:10.0.0.0/8
03:47:14:vpn:bnettable add:100:2:10.0.0.0/8
03:47:14:vpn:bestpath_hook route_tag_change for vpn2:10.0.0.0/255.0.0.0(ok)
03:47:14:vpn:bestpath_hook route_tag_change for vpn2:10.0.0.0/255.0.0.0(ok)
03:47:14:vpn:bestpath_hook route_tag_chacle ip bgp *nge for vpn2:10.0.0.0/255.0.0.0(ok)
The following example shows sample output, including the explicit-null label, from the debug ip bgp
updates and the debug ip bgp mpls commands:
Router# debug ip bgp updates
BGP updates debugging is on
Router# debug ip bgp mpls
BGP MPLS labels debugging is on
Router#
01:33:53: BGP(0): route 10.10.10.10/32 up
01:33:53: BGP(0): nettable_walker 10.10.10.10/32 route sourced locally
01:33:53: BGP: adding MPLS label to 10.10.10.10/32
01:33:53: BGP: check on 10.10.10.10/8 in LDP - ok
01:33:53: BGP: label imp-null allocated via LDP
01:33:53: BGP-IPv4: send exp-null label for 10.10.10.10/32

May 2008 DB-901
Debug Commands
debug ip bgp
01:33:53: BGP-IPv4: Send prefix 10.10.10.10/32, label exp-null !explicit-null label

being sent
01:33:53: BGP(0): 10.10.10.11 send UPDATE (format) 10.10.10.10/32, next 10.10.10.12,
metric 0, path , mpls label 0 !label value is 0
01:33:53: BGP(0): updgrp 1 - 10.10.10.12 enqueued 1 updates, average/maximum size (bytes)
61/61

DB-902 May 2008
Debug Commands
debug ip bgp groups
debug ip bgp groups

To display information related to the processing of Border Gateway Protocol (BGP) update-groups, use
the debug ip bgp update privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug ip bgp groups [index-group | ip-address]
no debug ip bgp groups
Syntax Description index-group (Optional) Specifies that update-group debugging information for the
corresponding index number will be displayed. The range of update-group
index numbers is from 1 to 4294967295.
ip-address (Optional) Specifies that update-group debugging information for a single
peer will be displayed.
Command Default No information about BGP update-groups is displayed.

Usage Guidelines The output of this command displays information about update-group calculations and the addition and
removal of update-group members. Information about peer-groups, peer-policy, and peer-session
templates will also be displayed in the output of this command as neighbor configurations change.
Note The output of this command can be very verbose. This command should not be deployed in a production
network unless you are troubleshooting a problem.
When a change to outbound policy occurs, the router automatically recalculates update-group
memberships and applies the changes by triggering an outbound soft reset after a 1-minute timer expires.
This behavior is designed to provide the network operator with time to change the configuration if a
mistake is made. You can manually enable an outbound soft reset before the timer expires by entering
the clear ip bgp ip-address soft out command.

May 2008 DB-903
Debug Commands
debug ip bgp groups
Note In Cisco IOS Release 12.0(25)S, 12.3(2)T, and prior releases the update group recalculation delay timer
is set to 3 minutes.
Examples The following sample output from the debug ip bgp groups command shows that peering has been
established with neighbor 10.4.9.8 and update-group calculations are occurring for this member:
Router# debug ip bgp groups
5w4d: BGP-DYN(0): Comparing neighbor 10.4.9.8 flags 0x0 cap 0x0 and updgrp 1 fl0
5w4d: BGP-DYN(0): Created update-group(0) flags 0x0 cap 0x0 from neighbor 10.4.0
5w4d: BGP-DYN(0): Adding neighbor 10.4.9.8 flags 0x0 cap 0x0, to update-group 0
5w4d: %BGP-5-ADJCHANGE: neighbor 10.4.9.8 Up
The following sample output from the debug ip bgp groups command shows the recalculation of
update-groups after the clear ip bgp groups command was issued:
Router# debug ip bgp groups
5w4d: %BGP-5-ADJCHANGE: neighbor 10.4.9.5 Down User reset

5w4d: BGP-DYN(0): Update-group 2 flags 0x0 cap 0x0 policies same as 10.4.9.5 fl0
5w4d: BGP-DYN(0): Update-group 2 flags 0x0 cap 0x0 policies same as 10.4.9.8 fl0
5w4d: BGP-DYN(0): Comparing neighbor 10.4.9.21 flags 0x0 cap 0x0 and updgrp 1 f0
5w4d: BGP-DYN(0): Update-group 1 flags 0x0 cap 0x0 policies same as 10.4.9.21 f0
Table 113 debug ip bgp groups Field Descriptions
Field Description
%BGP-5-ADJCHANGE: A BGP neighbor has come Up or gone Down. The IP address of the
neighbor is specified in the output string.
BGP-DYN(0): This line is displayed when a neighbor adjacency is established. The
BGP dynamic update group algorithm analyzes the policies of the
new neighbor and then adds the neighbor to the appropriate BGP
update group.

clear ip bgp Resets a BGP connection or session.
clear ip bgp update-group Clears BGP update-group member sessions.
show ip bgp replication Displays BGP update-group replication statistics.
show ip bgp update-group Displays information about BGP update-groups.

DB-904 May 2008
Debug Commands
debug ip bgp import
debug ip bgp import

To display debugging information related to importing IPv4 prefixes from the global routing table into
a VRF table, use the debug ip bgp import command in privileged EXEC mode. To disable the display
of IPv4 prefix import debugging information, use the no form of this command.
debug ip bgp import {events | updates [access-list | expanded-access-list]}
no debug ip bgp import {events | updates [access-list | expanded-access-list]}
Syntax Description events Displays event messages related to IPv4 prefix import.
updates Displays messages related to IPv4 prefix import updates.
access-list (Optional) Number of access list used to filter debugging messages. The
range that can be specified is from 1 to 199.
expanded-access-list (Optional) Number of expanded access lists used to filter debugging
messages. The range that can be specified is from 1300 to 2699.

Usage Guidelines Use this command to display debugging information related to the BGP Support for IP Prefix Import
from Global Table into a VRF Table feature. This feature provides the capability to import IPv4 unicast
prefixes from the global routing table into a Virtual Private Network (VPN) routing and forwarding
(VRF) instance table using an import route map.
Examples The following example configures IPv4 prefix import debugging messages for both import events and
import updates to be displayed on the console of the router:
Router# debug ip bgp import events
BGP import events debugging is on
Router# debug ip bgp import updates

May 2008 DB-905
Debug Commands
debug ip bgp import
BGP import updates debugging is on for access list 3
00:00:50: %BGP-5-ADJCHANGE: neighbor 10.2.2.2 Up

00:01:06: BGP: reevaluate IPv4 Unicast routes in VRF academic
00:01:06: BGP: 0 routes available (limit: 1000)
00:01:06: BGP: import IPv4 Unicast routes to VRF academic
00:01:06: BGP(2)-VRF(academic): import pfx 100:1:10.30.1.0/24 via 10.2.2.2
00:01:06: BGP: accepted 8 routes (limit: 1000)
00:01:06: BGP: reevaluate IPv4 Multicast routes in VRF multicast
00:01:06: BGP: import IPv4 Multicast routes to VRF multicast
00:01:06: %BGP-4-AFIMPORT: IPv4 Multicast prefixes imported to multicast vrf reached the
limit 2
00:01:06: BGP: reevaluate IPv4 Unicast routes in VRF BLUE
00:01:06: BGP: import IPv4 Unicast routes to VRF BLUE
Table 114 debug ip bgp import Field Descriptions
Field Description
BGP: accepted 2 routes (limit: 2) Number of routes imported into the VRF, and the default or
user-defined prefix import limit.
BGP: reevaluate IPv4 Unicast routes in Prefix was imported during BGP convergence and is being
VRF BLUE reevaluated for the next scan cycle.
BGP: 0 routes available (limit: 1000) Number of routes available from import source, and the
default or user-defined prefix import limit.
BGP: import IPv4 Unicast routes to Import map and prefix type (unicast or multicast) that is
VRF BLUE being imported into the specified VRF.

clear ip bgp Resets a BGP connection.

DB-906 May 2008
Debug Commands
debug ip bgp range
debug ip bgp range

To display debugging information related to Border Gateway Protocol (BGP) dynamic subnet range
neighbors, use the debug ip bgp range command in privileged EXEC mode. To disable debugging
debug ip bgp range [detail]
no debug ip bgp range
Syntax Description detail (Optional) Specifies that detailed debugging information about BGP dynamic
subnet range neighbors will be displayed.
Command Default No debugging information about BGP dynamic subnet range neighbors is displayed.

12.2(33)SXH This command was introduced.
Usage Guidelines The output of this command displays information about the identification and creation of BGP dynamic
subnet range neighbors. BGP dynamic neighbors are configured using a range of IP addresses and BGP
peer groups. After a subnet range is configured for a BGP peer group, and a TCP session is initiated for
an IP address in the subnet range, a new BGP neighbor is dynamically created as a member of that group.
The new BGP neighbor will inherit any configuration or templates for the group.
Examples The following output shows that the debug ip bgp range command has been entered and a BGP neighbor
at 192.168.3.2 is dynamically created using the subnet range 192.168.0.0/16. This new neighbor is a
member of the peer group named group192.
Router# debug ip bgp range
bgprange_debug = 1, sense = 1
BGP dynamic Range debugging is on
!
*Mar 26 20:05:13.251: BGP:DN: Created a new neighbor *192.168.3.2
in range 192.168.0.0/16, peer-group group192,count = 1
The following sample output from the debug ip bgp range detail command shows more detailed
debugging of the addition of dynamic BGP neighbors:
Router# debug ip bgp range detail

May 2008 DB-907
Debug Commands
debug ip bgp range
bgprange_debug = 1, sense = 1
BGP dynamic Range debugging is on with detail (Dynamic Range neighbors details only)
!
*Mar 26 20:09:12.311: BGP:DN: ACCEPT an OPEN from 192.168.1.2 valid range
0x32123D8:192.168.0.0/16,tcb 0x32114C0
!
*Mar 26 20:09:12.331: BGP: 192.168.1.2 passive open to 192.168.1.1
*Mar 26 20:09:12.331: BGP:DN: ACCEPTED an OPEN from 192.168.1.2 valid range
0x32123D8:192.168.0.0/16,tcb 0x3494040
!
*Mar 26 20:09:12.331: BGP:DN: Created a new neighbor *192.168.1.2
in range 192.168.0.0/16, peer-group group192,count = 2
Table 115 describes the significant field shown in the display.
Table 115 debug ip bgp range Field Descriptions
Field Description
BGP:DN: A potential dynamic BGP neighbor has been identified as opening a
TCP session with an IP address in a subnet associated with a BGP peer
group. BGP accepts the session and creates a new neighbor. The new
neighbor becomes a member of the peer group associated with its
subnet range.

bgp listen Configures BGP dynamic neighbor parameters.
clear ip bgp peer-group Clears BGP peer group member sessions.
show ip bgp peer-group Displays information about BGP peer groups.

DB-908 May 2008
Debug Commands
debug ip bgp sso
debug ip bgp sso

To display Border Gateway Protocol (BGP)-related stateful switchover (SSO) events or debugging
information for BGP-related interactions between the active Route Processor (RP) and the standby RP,
use the debug ip bgp sso command in privileged EXEC mode. To disable debugging output, use the no
debug ip bgp sso {events | transactions} [detail]
no debug ip bgp sso {events | transactions} [detail]
Syntax Description events Displays BGP-related SSO failures.

transactions Displays debugging information for failed BGP-related interactions between
the active RP and the standby RP.
detail (Optional) Displays detailed debugging information about successful
BGP-related SSO operations and successful BGP-related intereactions
between the active and the standby RP.

Usage Guidelines The debug ip bgp sso command is used to display BGP-related SSO events or debugging information
for BGP-related interactions between the active RP and the standby RP. This command is useful for
monitoring or troubleshooting BGP sessions on a provider edge (PE) router during an RP switchover or
during a planned In-Service Software Upgrade (ISSU).
Examples The following is sample output from the debug ip bgp sso command with the events keyword. The
following output indicates that the 10.34.32.154 BGP session is no longer SSO capable.
*Mar 28 02:29:43.526: BGPSSO: 10.34.32.154 reset SSO and decrement count
Tip Use the show ip bgp vpnv4 all neighbors command to display the reason that the SSO-capable BGP
session has been disabled.
The following is sample output from the debug ip bgp sso command with the transactions keyword.
The following output shows an SSO notification indicating that the SSO capability is pending for 602
BGP neighbors. This notification is generated as the state between the active and standby RP is being

May 2008 DB-909
Debug Commands
debug ip bgp sso
synchronized during the bulk synchonization phase of SSO initialization. During this phase, the
Transmission Control Blocks (TCBs) must be synchronized with the TCBs on the standby RP before
SSO initialization is complete.
*Mar 28 02:32:12.102: BGPSSO: tcp sso notify pending for 602 nbrs

DB-910 May 2008
Debug Commands
debug ip bgp updates

To display information about the processing of Border Gateway Protocol (BGP) updates, use the debug
ip bgp updates command in privileged EXEC mode. To disable the display of BGP update information,
debug ip bgp updates [access-list | expanded-access-list] [in | out] [events]
no debug ip bgp updates [access-list | expanded-access-list] [in | out] [events]
Syntax Description access-list (Optional) Number of access list used to filter debugging messages. The
range that can be specified is from 1 to 199.
expanded-access-list (Optional) Number of expanded access lists used to filter debugging
messages. The range that can be specified is from 1300 to 2699.
in (Optional) Specifies debugging messages for inbound BGP update
information.
out (Optional) Specifies debugging messages for outbound BGP update
information.
events (Optional) Specifies debugging messages for BGP update events.

Examples In the following sample output, the output shows that the BGP session was cleared between neighbor
10.4.9.21 and the local router 10.4.9.4. There are no field description tables for this command because
the debugging output from this command depends on the subsequent commands that are entered.
Router# debug ip bgp updates
5w2d: %SYS-5-CONFIG_I: Configured from console by console

5w2d: BGP: 10.4.9.21 went from Idle to Active
5w2d: BGP: 10.4.9.21 open active, delay 7032ms
5w2d: BGP: 10.4.9.21 open active, local address 10.4.9.4
5w2d: BGP: 10.4.9.21 went from Active to OpenSent
5w2d: BGP: 10.4.9.21 sending OPEN, version 4, my as: 101
5w2d: BGP: 10.4.9.21 send message type 1, length (incl. header) 45
5w2d: BGP: 10.4.9.21 rcv message type 1, length (excl. header) 26
5w2d: BGP: 10.4.9.21 rcv OPEN, version 4

May 2008 DB-911
Debug Commands
5w2d: BGP: 10.4.9.21 rcv OPEN w/ OPTION parameter len: 16

5w2d: BGP: 10.4.9.21 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
5w2d: BGP: 10.4.9.21 OPEN has CAPABILITY code: 1, length 4
5w2d: BGP: 10.4.9.21 OPEN has MP_EXT CAP for afi/safi: 1/1
5w2d: BGP: 10.4.9.21 OPEN has ROUTE-REFRESH capability(old) for all address-fams
5w2d: BGP: 10.4.9.21 OPEN has ROUTE-REFRESH capability for all address-families
5w2d: BGP: 10.4.9.21 went from OpenSent to OpenConfirm
5w2d: BGP: 10.4.9.21 went from OpenConfirm to Established
5w2d: BGP(0): 10.4.9.21 computing updates, afi 0, neighbor version 0, table ver0
5w2d: BGP(0): 10.4.9.21 update run completed, afi 0, ran for 0ms, neighbor vers1
5w2d: BGP(0): 10.4.9.21 initial update completed
In the following sample, the output shows that the local router is sending updates with the cost
community:
Router# debug ip bgp updates out
*Mar 15 01:41:23.515:BGP(0):10.0.0.5 computing updates, afi 0, neighbor version 0, table

version 64, starting at 0.0.0.0
*Mar 15 01:41:23.515:BGP(0):10.0.0.5 send UPDATE (format) 0.0.0.0/0, next 10.0.0.2, metric
0, path , extended community Cost:igp:1:100
*Mar 15 01:41:23.515:BGP(0):10.0.0.5 send UPDATE (format) 10.2.2.0/24, next 10.20.20.10,
metric 0, path 10, extended community Cost:igp:8:22
*Mar 15 01:41:23.515:BGP(0):10.0.0.5 send UPDATE (format) 10.13.13.0/24, next 10.0.0.8,
metric 0, path
In the following sample, the output shows that the local router is receiving updates with the cost
community:
Router# debug ip bgp updates in
*Jan 6 01:27:09.111:BGP(2):10.0.0.8 rcvd UPDATE w/ attr:nexthop 10.0.0.8, origin ?,

localpref 100, metric 0, path 10, extended community RT:100:1 Cost:igp:10:10
Cost:igp:11:11

DB-912 May 2008
Debug Commands
debug ip bgp vpnv4 checkpoint

To display the events for the Virtual Routing and Forwarding (VRF) checkpointing system between the
active and standby route processors, use the debug ip bgp vpnv4 checkpoint command in privileged
EXEC mode. To disable the display of these events, use the no form of this command.
no debug ip bgp vpnv4 checkpoint

implemented on the Cisco 10000 series router.
Examples The following example shows command output on the active route processor:
Router# debug ip bgp vpnv4 checkpoint
3d18h: %HA-5-SYNC_NOTICE: Config sync started.

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

debug ip bgp vpnv4 nsf Displays the nonstop forwarding events for the VRF table-id
synchronization subsystem between the active and standby route processors.

May 2008 DB-913
Debug Commands
debug ip bgp vpnv4 nsf

To display the nonstop forwarding events for the VRF table-id synchronization subsystem between the
active and standby Route Processors, use the debug ip bgp vpnv4 nsf command in privileged EXEC
mode. To disable the display of these events, use the no form of this command.
no debug ip bgp vpnv4 nsf

Examples The following example shows the command output on the active Route Processor:
Router# debug ip bgp vpnv4 nsf
MPLS VPN NSF Processing debugging is on
Router(config)# ip vrf vpn3
3d18h: vrf-nsf: vrf vpn3 tableid 2 send rpc OK
Router(config-vrf)# no ip vrf vpn3
% IP addresses from all interfaces in VRF vpn3 have been removed

3d18h: vrf-nsf: rx vrf tableid delete complete msg, tid = 2, name = vpn3
The following example shows the command output on the standby Route Processor:
Router# debug ip bgp vpnv4 nsf
MPLS VPN NSF Processing debugging is on

00:05:21: vrf-nsf: rx vrf tableid rpc msg, tid = 2, name = vpn3
% IP addresses from all interfaces in VRF vpn3 have been removed
00:06:22: vrf-nsf: vrf vpn3 tableid 2 , delete complete, send OK

DB-914 May 2008
Debug Commands

debug ip bgp vpnv4 Display the events for the VRF checkpointing system between the active and
checkpoint standby Route Processors.

May 2008 DB-915
Debug Commands
debug ip casa affinities

To display debugging messages for affinities, use the debug ip casa affinities command in privileged
no debug ip casa affinities
Defaults Debugging for affinities is not enabled.

Examples The following is sample output from the debug ip casa affinities command:
Router# debug ip casa affinities
16:15:36:Adding fixed affinity:

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

DB-916 May 2008
Debug Commands
Table 116 debug ip casa affinities Field Descriptions
Field Description
Adding fixed affinity Adding a fixed affinity to affinity table.
Updating fixed affinity Modifying a fixed affinity table with information from the services
manager.
flags Bit field indicating actions to be taken on this affinity.
fwd addr Address to which packets will be directed.
interest Services manager that is interested in packets for this affinity.
int ip:port Services manager port to which interest packets are sent.
sequence delta Used to adjust TCP sequence numbers for this affinity.

May 2008 DB-917
Debug Commands
debug ip casa packets

To display debugging messages for packets, use the debug ip casa packets command in privileged
no debug ip casa packets
Defaults Debugging for packets is not enabled.

Examples The following is sample output from the debug ip casa packets command:
Router# debug ip casa packets
16:15:36:Routing CASA packet - TO_MGR:

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

DB-918 May 2008
Debug Commands
Table 117 debug ip casa packets Field Descriptions
Field Description
Routing CASA packet - Forwarding Agent is routing a packet to the services manager.
TO_MGR
Routing CASA packet - Forwarding Agent is routing a packet to the forwarding address.
FWD_PKT
Routing CASA packet - TICKLE Forwarding Agent is signaling services manager while allowing
the packet in question to take the appropriate action.
Interest Addr Services manager address.
Interest Port Port on the services manager where packet is sent.
Fwd Addr Address to which packets matching the affinity are sent.
Interest Mask Services manager that is interested in packets for this affinity.

May 2008 DB-919
Debug Commands
debug ip casa wildcards

To display debugging messages for wildcards, use the debug ip casa wildcards command in privileged
no debug ip casa wildcards
Defaults Debugging for wildcards is not enabled.

Examples The following is sample output from the debug ip casa wildcards command:
Router# debug ip casa wildcards
16:13:23:Updating wildcard affinity:

16:13:23: 10.10.10.10:0 -> 0.0.0.0:0 proto = 6
16:13:23: src mask = 255.255.255.255, dest mask = 0.0.0.0
16:13:23: no frag, not advertising
16:13:23:Updating wildcard affinity:
16:13:23: 0.0.0.0:0 -> 10.10.10.10:0 proto = 6
16:13:23: src mask = 0.0.0.0, dest mask = 255.255.255.255
16:13:23: no frag, advertising
16:13:23 int ip:port = 10.10.2.2:1638, sequence delta = 0/0/0/0

DB-920 May 2008
Debug Commands
Table 118 debug ip casa wildcards Field Descriptions
Field Description
src mask Source of connection.
dest mask Destination of connection.
no frag, not advertising Not accepting IP fragments.
flags Bit field indicating actions to be taken on this affinity.
fwd addr Address to which packets matching the affinity will be directed.
interest Services manager that is interested in packets for this affinity.
int ip: port Services manager port to which interest packets are sent.
sequence delta Used to adjust sequence numbers for this affinity.

May 2008 DB-921
Debug Commands
debug ip cef accounting non-recursive

To troubleshoot Cisco Express Forwarding accounting records, use the debug ip cef accounting
non-recursive command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
no debug ip cef accounting non-recursive
Defaults This command is disabled.

11.1CC This command was introduced.
Usage Guidelines This command records accounting events for nonrecursive prefixes when the ip cef accounting
non-recursive command is enabled in global configuration mode.
Examples The following is sample output from the debug ip cef accounting non-recursive command:
Router# debug ip cef accounting non-recursive
03:50:19:CEF-Acct:tmstats_binary:Beginning generation of tmstats

ephemeral file (mode binary)
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF2000
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF1EA0
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF17C0
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF1D40
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF1A80
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF0B60
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF0CC0

DB-922 May 2008
Debug Commands
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF0F80

03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF10E0
03:50:19:CEF-Acct:snapshoting loadinfo 0x63FF1BE0
03:50:19:CEF-Acct:tmstats_binary:aggregation complete, duration 0 seconds
03:50:21:CEF-Acct:tmstats_binary:writing 45 bytes
03:50:57:CEF-Acct:tmstats_binary:tmstats file written, status 0
Table 119 debug ip cef accounting non-recursive Field Descriptions
Field Description
Beginning generation of tmstats ephemeral file (mode Tmstats file is being created.
binary)
CEF-Acct:snapshoting loadinfo 0x63FF2000 Baseline counters are being written to the
tmstats file for each nonrecursive prefix.
CEF-Acct:tmstats_binary:aggregation complete, Tmstats file creation is complete.
duration 0 seconds
CEF-Acct:tmstats_binary:writing 45 bytes Nonrecursive accounting statistics are being
updated to the tmstats file.
CEF-Acct:tmstats_binary:tmstats file written, status 0 Update of the tmstats file is complete.

debug ip cef Troubleshoots various Cisco Express Forwarding events.
ip cef accounting Enables Cisco Express Forwarding network accounting.
show ip cef Displays entries or a summary of the FIB table.

May 2008 DB-923
Debug Commands
debug ip cef fragmentation

To report fragmented IP packets when Cisco Express Forwarding is enabled, use the debug ip cef
fragmentation command in privileged EXEC mode. To disable debugging output, use the no form of
this command:
no debug ip cef fragmentation

Usage Guidelines This command is used to troubleshoot fragmentation problems when Cisco Express Forwarding
switching is enabled.
Examples The following is sample output from the debug ip cef fragmentation command:
Router# debug ip cef fragmentation
00:59:45:CEF-FRAG:no_fixup path:network_start 0x5397CF8E datagramstart 0x5397CF80

data_start 0x397CF80 data_block 0x397CF40 mtu 1000 datagramsize 1414 data_bytes 1414
00:59:45:CEF-FRAG:send frag:datagramstart 0x397CF80 datagramsize 442 data_bytes 442
00:59:45:CEF-FRAG:send frag:datagramstart 0x38BC266 datagramsize 1006 data_bytes 1006
00:59:45:CEF-FRAG:no_fixup path:network_start 0x5397C60E datagramstart 0x5397C600
data_start 0x397C600 data_block 0x397C5C0 mtu 1000 datagramsize 1414 data_bytes 1414
00:59:45:CEF-FRAG:send frag:datagramstart 0x397C600 datagramsize 442 data_bytes 442
00:59:45:CEF-FRAG:send frag:datagramstart 0x38BC266 datagramsize 1006 data_bytes 1006

DB-924 May 2008
Debug Commands
Table 120 debug ip cef fragmentation Field Descriptions
Field Description
no_fixup path A packet is being fragmented in the no_fixup path.
network_start 0x5397CF8E Memory address of the IP packet.
datagramstart 0x5397CF80 Memory address of the encapsulated IP packet.
data_start 0x397CF80 For particle systems, the memory address where data starts for the
first packet particle.
data_block 0x397C5C0 For particle systems, the memory address of the first packet particle
data block.
mtu 1000 Maximum transmission unit of the output interface.
datagramsize 1414 Size of the encapsulated IP packet.
data_bytes 1414 For particle systems, the sum of the particle data bytes that make
up the packet.
send frag Fragment is being forwarded.


May 2008 DB-925
Debug Commands
debug ip cef hash
debug ip cef hash

To record Cisco Express Forwarding load sharing hash algorithm events, use the debug ip cef hash
debug ip cef hash
no debug ip cef hash

12.2(28)SB This command was integrated into Cisco IOS Release 12.2(28)SB. This
command is not supported on the Cisco 10000 series routers.
12.2(33)SRA This command was integrated into Cisco IOS Release 12.2(33)SRA.This
command is not supported on the Cisco 7600 router.
Usage Guidelines Use this command when changing the load sharing algorithm to display the hash table details.
Examples The following is sample output from the debug ip cef hash command with IP Cisco Express Forwarding
load algorithm tunnel information:
Router# debug ip cef hash
01:15:06:%CEF:ip cef load-sharing algorithm tunnel 0

01:15:06:%CEF:Load balancing algorithm:tunnel
01:15:06:%CEF:Load balancing unique id:1F2BA5F6
01:15:06:%CEF:Destroyed load sharing hash table
01:15:06:%CEF:Sending hash algorithm id 2, unique id 1F2BA5F6 to slot 255

DB-926 May 2008
Debug Commands
debug ip cef hash
The following lines show IP Cisco Express Forwarding load algorithm universal information:
01:15:28:%CEF:ip cef load-sharing algorithm universal 0
01:15:28:%CEF:Load balancing algorithm:universal
01:15:28:%CEF:Load balancing unique id:062063A4
01:15:28:%CEF:Creating load sharing hash table
01:15:28:%CEF:Hash table columns for valid max_index:
01:15:28:12: 9 7 7 4 4 10 0 7 10 4 5 0 4 7 8 4
01:15:28:15: 3 10 10 4 10 4 0 7 1 7 14 6 13 13 11 13
01:15:28:16: 1 3 7 12 4 14 8 7 10 4 1 12 8 15 4 8
01:15:28:%CEF:Sending hash algorithm id 3, unique id 062063A4 to slot 255
Table 121 debug ip cef hash Field Descriptions
Field Description
ip cef load-sharing algorithm tunnel 0 Echo of the user command.
Load balancing algorithm:tunnel Load sharing algorithm is set to tunnel.
Load balancing unique id:1F2BA5F6 ID field in the command is usually 0. In this instance, the
router chose a pseudo random ID of 1F2BA5F6.
Destroyed load sharing hash table Purge the existing hash table.
Sending hash algorithm id 2, unique id Algorithm is being distributed.
1F2BA5F6 to slot 255
Creating load sharing hash table Hash table is being created.
Hash table columns for valid max_index: Generated hash table.

debug ip cef rrhash Records Cisco Express Forwarding removal of receive hash
events.

May 2008 DB-927
Debug Commands
debug ip cef rrhash
debug ip cef rrhash

To record Cisco Express Forwarding removal of receive hash events, use the debug ip cef rrhash
debug ip cef rrhash
no debug ip cef rrhash

12.2(28)SB This command was integrated into Cisco IOS Release 12.2(28)SB. This
command is not supported on the Cisco 10000 series routers.
12.2(33)SRA This command was integrated into Cisco IOS Release 12.2(33)SRA. This
command is not supported on the Cisco 7600 routers.
Usage Guidelines Use this command to verify the removal of receive hash events when you are shutting down or deleting
an interface.
Examples The following is sample output from the debug ip cef rrhash command:
Router# debug ip cef rrhash
00:27:15:CEF:rrhash/check:found 10.1.104.7 on down idb [ok to delete]


DB-928 May 2008
Debug Commands
debug ip cef rrhash
Table 122 debug ip cef rrhash Field Descriptions
Field Description
rrhash/check Verify address is on the receive list.
found 10.1.104.7 on down idb Found a valid address on the receive list for a shutdown interface
[ok to delete] that can be deleted.

debug ip cef hash Records Cisco Express Forwarding removal of receive hash
events.

May 2008 DB-929
Debug Commands
debug ip cef subblock

To troubleshoot Cisco Express Forwarding subblock events, use the debug ip cef subblock command in
debug ip cef subblock [id {all | hw hw-id | sw sw-id }] [xdr {all | control | event | none | statistic}]
no debug ip cef subblock [id {all | hw hw-id | sw sw-id }] [xdr {all | control | event | none |
statistic}]
Syntax Description id (Optional) Subblock types.

all (Optional) All subblock types.
hw hw-id (Optional) Hardware subblock and identifier.
sw sw-id (Optional) Software subblock and identifier.
xdr (Optional) Exernal Data Representation (XDR) message types.
control (Optional) All XDR message types.
event (Optional) Event XDR messages only.
none (Optional) No XDR messages.
statistic (Optional) Statistic XDR messages.

12.0S This command was introduced.
Usage Guidelines This command is used to record Cisco Express Forwarding subblock messages and events.

DB-930 May 2008
Debug Commands
Examples The following is sample output from the debug ip cef subblock command:
Router# debug ip cef subblock
00:28:12:CEF-SB:Creating unicast RPF subblock for FastEthernet6/0

00:28:12:CEF-SB:Linked unicast RPF subblock to FastEthernet6/0.
00:28:12:CEF-SB:Encoded unit of unicast RPF data (length 16) for FastEthernet6/0
00:28:12:CEF-SB:Sent 1 data unit to slot 6 in 1 XDR message
Cisco 10000 Series Router Example

The following is sample output from the debug ip cef subblock command:
Router# debug ip cef subblock
00:28:12:CEF-SB:Creating unicast RPF subblock for FastEthernet6/0/0

00:28:12:CEF-SB:Linked unicast RPF subblock to FastEthernet6/0/0.
00:28:12:CEF-SB:Encoded unit of unicast RPF data (length 16) for FastEthernet6/0/0
00:28:12:CEF-SB:Sent 1 data unit to slot 6 in 1 XDR message
Table 123 debug ip cef subblock Field Descriptions
Field Description
Creating unicast RPF subblock for FastEthernet6/0/0 Creating an Unicast Reverse Path Forwarding
(Unicast RPF) interface descriptor subblock.
Linked unicast RPF subblock to FastEthernet6/0/0 Linked the subblock to the specified interface.
Encoded unit of unicast RPF data (length 16) for Encoded the subblock information in an XDR.
FastEthernet6/0/0
Sent 1 data unit to slot 6 in 1 XDR message Sent the XDR message to a line card through
the IPC.


May 2008 DB-931
Debug Commands
debug ip cef table
debug ip cef table

To enable the collection of events that affect entries in the Cisco Express Forwarding tables, use the
debug ip cef table command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug ip cef table [access-list | consistency-checkers]
no debug ip cef table [access-list | consistency-checkers]
Syntax Description access-list (Optional) Controls collection of consistency checker

parameters from specified lists.
consistency-checkers (Optional) Sets consistency checking characteristics.

11.2GS This command was introduced.
11.1CC Support was added for multiple platforms.
12.0(15)S The consistency-checkers keyword was added.
Usage Guidelines This command is used to record Cisco Express Forwarding table events related to the Forwarding
Information Base (FIB) table. Possible types of events include the following:
Routing updates that populate the FIB table
Flushing of the FIB table
Adding or removing of entries to the FIB table
Table reloading process

DB-932 May 2008
Debug Commands
debug ip cef table
Examples The following is sample output from the debug ip cef table command:
Router# debug ip cef table
01:25:46:CEF-Table:Event up, 10.1.1.1/32 (rdbs:1, flags:1000000)

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

The following is sample output from the debug ip cef table command:
Router# debug ip cef table
01:25:46:CEF-Table:Event up, 10.1.1.1/32 (rdbs:1, flags:1000000)

01:25:46:CEF-IP:Checking dependencies of 0.0.0.0/0
01:25:47:CEF-Table:attempting to resolve 10.1.1.1/32
01:25:47:CEF-IP:resolved 10.1.1.1/32 via 10.1.104.1 to 10.1.104.1 GigabitEthernet2/0/0
01:26:02:CEF-Table:Event up, default, 0.0.0.0/0 (rdbs:1, flags:400001)
01:26:02:CEF-IP:Prefix exists - no-op change
Table 124 debug ip cef table Field Descriptions
Field Description
CEF-Table Indicates a table event.
Event up, 10.1.1.1/32 IP prefix 10.1.1.1/32 is being added.
rdbs:1 Event is from routing descriptor block 1.
flags:1000000 Indicates the network descriptor block
flags.
CEF-IP Indicates a Cisco Express Forwarding IP
event.
Checking dependencies of 0.0.0.0/0 Resolves the next hop dependencies for
0.0.0.0/0.
attempting to resolve 10.1.1.1/32 Resolves the next hop dependencies.
resolved 10.1.1.1/32 via 10.1.104.1 to 10.1.104.1 Next hop to IP prefix 10.1.1.1/32 is set and
Ethernet2/0/0 is added to the table.
Event up, default, 0.0.0.0/0 Prefix exists - no-op change Indicates no table change is necessary for
0.0.0.0/32.

May 2008 DB-933
Debug Commands
debug ip cef table

cef table consistency-check Enables Cisco Express Forwarding consistency checker table
values by type and parameter.
clear cef table Clears the Cisco Express Forwarding tables.
clear ip cef inconsistency Clears Cisco Express Forwarding inconsistency statistics and
records found by the Cisco Express Forwarding consistency
checkers.
debug cef Enables the display of information about Cisco Express
Forwarding events.
show cef table consistency-check Displays Cisco Express Forwarding consistency checker table
values.
show ip cef inconsistency Displays Cisco Express Forwarding IP prefix inconsistencies.

DB-934 May 2008
Debug Commands
debug ip cef
debug ip cef
To troubleshoot various Cisco Express Forwarding events, use the debug ip cef command in privileged
debug ip cef {drops [rpf [access-list]] [access-list] | receive [access-list] | events [access-list] |
interface | dialer}
no debug ip cef {drops [rpf [access-list]] [access-list] | receive [access-list] | events [access-list]
| interface | dialer}
Specific to Interprocess Communication (IPC) Records
debug ip cef {ipc | interface-ipc | prefix-ipc [access-list]}
no debug ip cef {ipc | interface-ipc | prefix-ipc [access-list]}
Cisco 10000 Series Routers Only
debug ip cef {drops [rpf [access-list]] [access-list] | receive [access-list] | events [access-list]}
no debug ip cef {drops [rpf [access-list]] [access-list] | receive [access-list] | events [access-list]}
Cisco 10000 Series Routers OnlySpecific to IPC Records
debug ip cef ipc
no debug ip cef ipc
Syntax Description drops Records dropped packets.

rpf (Optional) Records the result of the Reverse Path Forwarding (RPF) check
for packets.
access-list (Optional) Limits debugging collection to packets that match the list.
receive Records packets that are ultimately destined to the router and packets
destined to a tunnel endpoint on the router. If the decapsulated tunnel is IP,
the packets are Cisco Express Forwarding switched; otherwise the packets
are process switched.
events Records general Cisco Express Forwarding events.
interface Records IP Cisco Express Forwarding interface events.
dialer Records IP Cisco Express Forwarding interface events for dialer interfaces.
ipc Records information related to IPC in Cisco Express Forwarding. Possible
types of events are the following:
IPC messages received out of sequence
Status of resequenced messages
Status of buffer space for IPC messages
Transmission status of IPC messages
Throttle requests sent from a line card to the Route Processor

May 2008 DB-935
Debug Commands
debug ip cef
interface-ipc Records IPC updates related to interfaces. Possible reporting includes an

interface coming up or going down and updates to fibhwidb and fibidb.
prefix-ipc Records updates related to IP prefix information. Possible updates include
the following:
Debugging of IP routing updates in a line card
Reloading of a line card with a new table
Updates related to exceeding the maximum number of routes
Control messages related to Forwarding Information Base (FIB) table
prefixes

11.2GS This command was introduced.
11.1CC Support for multiple platforms was added.
12.0(5)T The rpf keyword was added.
12.2(4)T The dialer keyword was added.
Usage Guidelines This command gathers additional information for the handling of Cisco Express Forwarding interface,
IPC, or packet events.
Note For packet events, we recommend that you use an access control list (ACL) to limit the messages
recorded.

DB-936 May 2008
Debug Commands
debug ip cef
Examples The following is sample output from the debug ip cef rpf command for a packet that is dropped when
it fails the RPF check. IP address 172.17.249.252 is the source address, and Ethernet 2/0/0 is the input
interface.
Router# debug ip cef drops rpf
IP CEF drops for RPF debugging is on

00:42:02:CEF-Drop:Packet from 172.17.249.252 via Ethernet2/0/0 -- unicast rpf check
The following is sample output for Cisco Express Forwarding packets that are not switched using
information from the FIB table but are received and sent to the next switching layer:
Router# debug ip cef receive
IP CEF received packets debugging is on

00:47:52:CEF-receive:Receive packet for 10.1.104.13
Table 125 debug ip cef receive Field Descriptions
Field Description
CEF-Drop:Packet from 172.17.249.252 via A packet from IP address 172.17.249.252 is
Ethernet2/0/0 -- unicast rpf check dropped because it failed the RPF check.
CEF-receive:Receive packet for 10.1.104.13 Cisco Express Forwarding has received a packet
addressed to the router.
The following is sample output from the debug ip cef dialer command for a legacy dialer:
Router# debug ip cef dialer
00:19:50:CEF-Dialer (legacy):add link to 10.10.10.2 via Dialer1 through BRI0/0:1

00:19:50:CEF-Dialer:adjacency added:0x81164850
00:19:50:CEF-Dialer:adjacency found:0x81164850; fib->count:1
00:19:50:CEF-Dialer:setup loadinfo with 1 paths
The following is sample output from the debug ip cef dialer command for a dialer profile:
Router# debug ip cef dialer
00:31:44:CEF-Dialer (profile dynamic encap (not MLP)):add link to 10.10.10.2 via Dialer1
through Dialer1
00:31:44:CEF-Dialer:adjacency added:0x81164850
00:31:44:CEF-Dialer:adjacency found:0x81164850; fib->count:1
Table 126 debug ip cef dialer Field Descriptions
Field Description
CEF-Dialer (legacy):add link to 10.10.10.2 via A link was added to IP address 10.10.10.2 for legacy
Dialer1 through BRI0/0:1 Dialer1 through physical interface BRI0/0:1.
CEF-Dialer (profile dynamic encap (not A link was added to IP address 10.10.10.2 for dialer
MLP)):add link to 10.10.10.2 via Dialer1 profile Dialer1 through Dialer1.
through Dialer1

May 2008 DB-937
Debug Commands
debug ip cef

ip cef Enables Cisco Express Forwarding on the RPC card.
show ip cef Displays entries in the FIB or displays a summary of the FIB.

DB-938 May 2008
Debug Commands
debug ip ddns update

To enable debugging for Dynamic Domain Name System (DDNS) updates, use the debug ip ddns
update command in privileged EXEC mode. To disable the debugging, use the no form of this command.
no debug ip ddns update

12.3(8)YA This command was introduced.
Examples Use the debug ip ddns update command to verify that your configurations are working properly. The
following sample configurations are shown for demonstration of possible debug output that could
display for each configuration.
Sample Configuration for the Client to Update A RRs and the Server to Update PTR RRs
The following scenario has a client configured for IETF DDNS updating of address (A) Resource
Records (RRs) during which a Dynamic Host Configuration Protocol (DHCP) server is expected to
update the pointer (PTR) RR. The DHCP client discovers the domain name system (DNS) server to
update using an Start of Authority (SOA) RR lookup since the IP address to the server to update is not
specified. The DHCP client is configured to include an fully qualified domain name (FQDN) DHCP
option and notifies the DHCP server that it will be updating the A RRs.
!DHCP Client Configuration
ip ddns update method testing
ddns
interface Ethernet1
ip dhcp client update dns
ip ddns update testing
ip address dhcp
end
!DHCP Server Configuration

ip dhcp pool test
network 10.0.0.0 255.0.0.0
update dns

May 2008 DB-939
Debug Commands
!Debug Output Enabled

Router# debug ip ddns update
00:14:39: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet1 assigned DHCP address 10.0.0.4, mask

255.0.0.0, hostname canada_reserved
00:14:39: DYNDNSUPD: Adding DNS mapping for canada_reserved.hacks <=> 10.0.0.4
00:14:39: DYNDNSUPD: Sleeping for 3 seconds waiting for interface Ethernet1 configuration
to settle
00:14:42: DHCPC: Server performed PTR update
00:14:42: DDNS: Enqueuing new DDNS update 'canada_reserved.hacks' <=> 10.0.0.4
00:14:42: DDNS: Zone name for 'canada_reserved.hacks' is 'hacks'
00:14:42: DDNS: Dynamic Update 1: (sending to server 10.19.192.32)
00:14:42: DDNS: Zone = hacks
00:14:42: DDNS: Prerequisite: canada_reserved.hacks not in use
00:14:42: DDNS: Update: add canada_reserved.hacks IN A 10.0.0.4
00:14:42: DDNS: Dynamic DNS Update 1 (A) for host canada_reserved.hacks returned 0
(NOERROR)
00:14:42: DDNS: Update of 'canada_reserved.hacks' <=> 10.0.0.4 finished
00:14:42: DYNDNSUPD: Another update completed (total outstanding=0)
Sample Configuration for the Client to Update Both A and DNS RRs and the Server to Update Neither
The following scenario has the client configured for IETF DDNS updating of both A and DNS RRs and
requesting that the DHCP server update neither. The DHCP client discovers the DNS server to update
using an SOA RR lookup since the IP address to the server to update is not specified. The DHCP client
is configured to include an FQDN DHCP option that instructs the DHCP server to not update either A
or PTR RRs.
ip dhcp-client update dns server none

ddns both
interface Ethernet1
ip address dhcp
end

ip dhcp pool test
network 10.0.0.0 255.0.0.0
update dns


to settle
00:15:36: DDNS: Zone name for '10.0.0.11.in-addr.arpa.' is '10.in-addr.arpa'
00:15:36: DDNS: Zone = 10.in-addr.arpa
00:15:36: DDNS: Prerequisite: 10.0.0.11.in-addr.arpa. not in use
00:15:36: DDNS: Update: add 10.0.0.11.in-addr.arpa. IN PTR canada_reserved.hacks
00:15:36: DDNS: Dynamic DNS Update 1 (PTR) for host canada_reserved.hacks returned 0
(NOERROR)

DB-940 May 2008
Debug Commands

(NOERROR)
Sample Configuration for the Client to Update A and DNS RRs and the Server to Update Neither
requesting that the DHCP server update neither. The DHCP client explicitly specifies the server to
update. The DHCP client is configured to include an FQDN DHCP option that instructs the DHCP server
not to update either A or PTR RRs. The configuration is performed using the ip dhcp client update dns
command. The DHCP server is configured to override the client request and update both A and PTR RR
anyway.
ip dhcp client update dns server none

ddns both
interface Ethernet1
ip address dhcp
end

ip dhcp pool test
network 10.0.0.0 255.0.0.0
update dns both override
!Debug Output Enabled on DHCP Client


to settle
00:16:33: DHCPC: Server performed both updates
Sample Configuration for the Client to Update A and DNS RRs and the Server to Update Neither
requesting the DHCP server to update neither. The DHCP client is configured to include an FQDN
DHCP option which instructs the DHCP server not to update either A or PTR RRs. The DHCP server is
configured to allow the client to update whatever RR it chooses.
ip dhcp client update dns server non

ddns both
interface Ethernet1
ip ddns update testing host 172.19.192.32
ip address dhcp
end

May 2008 DB-941
Debug Commands

ip dhcp pool test
network 10.0.0.0 255.0.0.0
update dns
!Debug Output Enabled on DHCP Client


to settle
00:17:55: DYNDNSUPD: Adding DNS mapping for canada_reserved.hacks <=> 10.0.0.7 server
10.19.192.32
00:17:55: DDNS: Enqueuing new DDNS update 'canada_reserved.hacks' <=> 10.0.0.7 server
10.19.192.32
00:17:55: DDNS: Using server 10.19.192.32
(NOERROR)
(YXDOMAIN)
00:17:55: DDNS: Update: delete 10.0.0.11.in-addr.arpa. all PTR RRs
(NOERROR)
(NOERROR)
00:17:55: DDNS: Using server 10.19.192.32
(YXDOMAIN)
00:17:55: DDNS: Update: delete canada_reserved.hacks all A RRs
(NOERROR)

DB-942 May 2008
Debug Commands
Sample Configuration for Updating the Internal Host Table

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

internal
interface ethernet0/0
ip ddns update test hostname test2
ip addr dhcp

*Jun 4 03:11:10.591: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet0/0 assigned DHCP address

10.0.0.5, mask 255.0.0.0, hostname test2
*Jun 4 03:11:10.591: DYNDNSUPD: Adding DNS mapping for test2.hacks <=> 10.0.0.5
*Jun 4 03:11:10.591: DYNDNSUPD: Adding internal mapping test2.hacks <=> 10.0.0.5
Using the show hosts command displays the newly added host table entry.
Router# show hosts
Default domain is hacks

Name/address lookup uses domain service
Name servers are 255.255.255.255
Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate

temp - temporary, perm - permanent
NA - Not Applicable None - Not defined
Host Port Flags Age Type Address(es)

test2.hacks None (perm, OK) 0 IP 10.0.0.5
Shutting down the interface removes the host table entry.

interface ethernet0/0
shutdown
*Jun 4 03:14:02.107: DYNDNSUPD: Removing DNS mapping for test2.hacks <=> 10.0.0.5
*Jun 4 03:14:02.107: DYNDNSUPD: Removing mapping test2.hacks <=> 10.0.0.5
Using the show hosts command confirms that the entry has been removed.
Router# show hosts
Default domain is hacks

Name/address lookup uses domain service
Name servers are 255.255.255.255
Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate

temp - temporary, perm - permanent
NA - Not Applicable None - Not defined
Host Port Flags Age Type Address(es)

May 2008 DB-943
Debug Commands
Sample Configuration of HTTP DDNS Updates

In the following scenario, the debug output shows the HTTP-style DDNS updates. The sample
configuration defines a new IP DDNS update method named dyndns that configures a URL to use when
adding or changing an address. No URL has been defined for use when removing an address since
DynDNS.org does not use such a URL for free accounts. A maximum update interval of 28 days has been
configured, which specifies that updates should be sent at least every 28 days. Configuring the new
dyndns update method should be used for Ethernet interface 1.
ip ddns update method dyndns
http
add http://test:test@<s>/nic/update?system=dyndns&hostname=<h>&myip=<a>
interval max 28 0 0 0
interface ethernet1
ip ddns update hostname test.dyndns.org
ip ddns update dyndns host members.dyndns.org
ip addr dhcp
!Debugging Enabled
00:04:35: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet1 assigned DHCP address 10.32.254.187,

mask 255.255.255.240, hostname test.dyndns.org
00:04:35: DYNDNSUPD: Adding DNS mapping for test.dyndns.org <=> 10.32.254.187 server
63.208.196.94
to settle
00:04:38: HTTPDNS: Update add called for test.dyndns.org <=> 10.32.254.187
00:04:38: HTTPDNS: Update called for test.dyndns.org <=> 10.32.254.187
00:04:38: HTTPDNS: init
00:04:38: HTTPDNSUPD: Session ID = 0x7
00:04:38: HTTPDNSUPD: URL =
'http://test:test@63.208.196.94/nic/update?system=dyndns&hostname=test.dyndns.org&myip=10.
32.254.187'
00:04:38: HTTPDNSUPD: Sending request
00:04:40: HTTPDNSUPD: Response for update test.dyndns.org <=> 10.32.254.187
00:04:40: HTTPDNSUPD: DATA START
good 10.32.254.187
00:04:40: HTTPDNSUPD: DATA END, Status is Response data received, successfully
00:04:40: HTTPDNSUPD: Call returned SUCCESS for update test.dyndns.org <=> 10.32.254.187
00:04:40: HTTPDNSUPD: Freeing response
00:04:40: DYNDNSUPD: Another update completed (outstanding=0, total=0)
00:04:40: HTTPDNSUPD: Clearing all session 7 info
!28 days later, the automatic update happens.
00:05:39: DYNDNSUPD: Adding DNS mapping for test.dyndns.org <=> 10.32.254.187 server
63.208.196.94
00:05:39: HTTPDNS: Update add called for test.dyndns.org <=> 10.32.254.187
00:05:39: HTTPDNS: Update called for test.dyndns.org <=> 10.32.254.187
00:05:39: HTTPDNS: init
00:05:39: HTTPDNSUPD: Session ID = 0x8
00:05:39: HTTPDNSUPD: URL =
'http://test:test@63.208.196.94/nic/update?system=dyndns&hostname=test.dyndns.org&myip=10.
32.254.187'
00:05:39: HTTPDNSUPD: Sending request
00:05:39: HTTPDNSUPD: Response for update test.dyndns.org <=> 10.32.254.187
00:05:39: HTTPDNSUPD: DATA START
nochg 10.32.254.187
00:05:39: HTTPDNSUPD: DATA END, Status is Response data received, successfully
00:05:39: HTTPDNSUPD: Call returned SUCCESS for update test.dyndns.org <=> 10.32.254.187

DB-944 May 2008
Debug Commands
00:05:39: HTTPDNSUPD: Freeing response

00:05:39: DYNDNSUPD: Another update completed (outstanding=0, total=0)
00:05:39: HTTPDNSUPD: Clearing all session 8 info
Table 127 describes the significant fields shown in the output.
Table 127 debug ip ddns update Field Descriptions
Field Description
HTTPDNSUPD Reflects the method of update. In this case, the update
method is HTTP.
HTTPDNSUPD: URL = URL that is used to update the DNS.

debug dhcp Displays debugging information about the DHCP client and monitors the
status of DHCP packets.
debug ip dhcp server Enables DHCP server debugging.
hostname
method
pool

May 2008 DB-945
Debug Commands
debug ip dfp agent
debug ip dfp agent

To display debugging messages for the Dynamic Feedback Protocol (DFP) agent subsystem, use the
debug ip dfp command in user EXEC or privileged EXEC mode. To stop debugging output, use the no
debug ip dfp agent
no debug ip dfp agent
Command Modes User EXEC or privileged EXEC mode

12.1(8a)E This command was introduced.
Usage Guidelines This command displays debugging messages for the DFP agent subsystem.
See the following caution before using debug commands:
Caution Because debugging output is assigned a high priority in the CPU process, it can render the system
Examples The following example configures a DFP agent debugging session:

Router# debug ip dfp agent
DFP debugging is on

DB-946 May 2008
Debug Commands
debug ip dfp agent


May 2008 DB-947
Debug Commands
debug ip dhcp server redundancy

To display debugging information about DHCP server and relay agent redundancy events, use the debug
ip dhcp server redundancy command in privileged EXEC mode. To disable the display of debugging
no debug ip dhcp server redundancy
Command Default Debugging output is disabled for DHCP server and relay agent redundancy events.

Usage Guidelines Use this command with caution. Many bindings being synchronized between the active and standby
Route Processor (RP) can trigger a large amount of debugging output.
Examples The following example displays debug messages regarding DHCP server and relay agent redundancy
events. The last line (and only that line) is output when the debug ip dhcp server redundancy command
is enabled. The line indicates that a binding update message has been sent to the standby for the IP
address 10.0.0.2 in the pool named test.
Router# debug ip dhcp server redundancy
*Mar 22 10:32:21: DHCPD: assigned IP address 10.0.0.2 to client

0063.6973.636f.2d30.3030.342e.3465.6130.2e30.3831.632d.4661.312f.302e.31.
*Mar 22 10:32:21: DHCPD: lease time = 3600
*Mar 22 10:32:21: DHCPD: dhcpd_lookup_route: host = 10.0.0.2
*Mar 22 10:32:21: DHCPD: dhcpd_lookup_route: index = 0
*Mar 22 10:32:21: DHCPD: dhcpd_create_and_hash_route: host = 10.0.0.2
*Mar 22 10:32:21: DHCPD: dhcpd_create_and_hash_route index = 0
*Mar 22 10:32:21: DHCPD: dhcpd_add_route: lease = 3600
*Mar 22 10:32:21: DHCPD: dynamic sync completed for 10.0.0.2 in pool test

DB-948 May 2008
Debug Commands

debug dhcp Displays debugging information about DHCP proxy client redundancy
redundancy events.

May 2008 DB-949
Debug Commands
debug ip dhcp server

To enable Cisco IOS Dynamic Host Configuration Protocol (DHCP) server debugging, use the debug ip
dhcp server command in privileged EXEC mode. To disable DHCP server debugging, use the no form
of this command.
debug ip dhcp server {events | packets | linkage | class}
no debug ip dhcp server {events | packets | linkage | class}
Syntax Description events Reports server events, such as address assignments and database updates.
packets Decodes DHCP receptions and transmissions.
linkage Displays database linkage information, such as parent-child relationships in
a radix tree.
class Displays DHCP class-based information.

12.2(13)ZH The class keyword was added.
12.3(4)T The class keyword was integrated into Cisco IOS Release 12.3(4)T.
12.3(11)T The output was enhanced to show the static mappings.
Examples The following example shows a combination of DHCP server events and decoded receptions and
transmissions:
Router# debug ip dhcp server events
Router# debug ip dhcp server packets
DHCPD:DHCPDISCOVER received from client 0b07.1134.a029 through relay 10.1.0.253.

DHCPD:assigned IP address 10.1.0.3 to client 0b07.1134.a029.
DHCPD:Sending DHCPOFFER to client 0b07.1134.a029 (10.1.0.3).
DHCPD:unicasting BOOTREPLY for client 0b07.1134.a029 to relay 10.1.0.253.
DHCPD:DHCPREQUEST received from client 0b07.1134.a029.
DHCPD:Sending DHCPACK to client 0b07.1134.a029 (10.1.0.3).
DHCPD:unicasting BOOTREPLY for client 0b07.1134.a029 to relay 10.1.0.253.
DHCPD:checking for expired leases.
The following example shows database linkage information:

Router# debug ip dhcp server linkage
DHCPD:child pool:10.1.0.0 / 255.255.0.0 (subnet10.1)

DB-950 May 2008
Debug Commands
DHCPD:parent pool:10.0.0.0 / 255.0.0.0 (net10)

DHCPD:child pool:10.0.0.0 / 255.0.0.0 (net10)
DHCPD:pool (net10) has no parent.
DHCPD:child pool:10.1.0.0 / 255.255.0.0 (subnet10.1)
DHCPD:parent pool:10.0.0.0 / 255.0.0.0 (net10)
DHCPD:child pool:10.0.0.0 / 255.0.0.0 (net10)
DHCPD:pool (net10) has no parent.
The following example shows when a DHCP class is removed:

Router# debug ip dhcp server class
DHCPD:deleting class CLASS1
The following example shows the debug output when the configured pattern does not match:
DHCPD:Searching for a match to 'relay-information

0106000 400020202020800060009e80b8800' in class CLASS1
DHCPD:Searching for a match to 'relay-information 0106000400020202020800060009e80b8800' in
class CLASS1
DHCPD:Searching for a match to 'relay-information 0106000
The following example shows the debug output when you unconfigure a DHCP pattern in a DHCP class
and then configure the pattern in the DHCP class:
DHCPD:pattern 'relay-information 123456' removed from class CLASS1

DHCPD:Added pattern 'relay-information 010600040002020202 0800060009e80b8800' for class
CLASS1
The following example shows the debug output when the configured pattern does match:
DHCPD:Searching for a match to 'relay-information

0106000 400020202020800060009e80b8800' in class CLASS1
DHCPD:input pattern 'relay-information 010600040002020202 0800060009e80b8800' matches
class CLASS1
DHCPD:input matches class CLASS1
The following example shows the debug output when static mappings are configured:
Router# debug ip dhcp server
Loading abc/static_pool from 10.19.192.33 (via Ethernet0): !

[OK - 333 bytes]
*May 26 23:14:21.259: DHCPD: contacting agent tftp://10.19.192.33/abc/static_pool (attempt

0)
*May 26 23:14:21.467: DHCPD: agent tftp://10.19.192.33/abc/static_pool is responding.
*May 26 23:14:21.467: DHCPD: IFS is ready.
*May 26 23:14:21.467: DHCPD: reading bindings from
tftp://10.19.192.33/abc/static_pool.
*May 26 23:14:21.707: DHCPD: read 333 / 1024 bytes.
*May 26 23:14:21.707: DHCPD: parsing text line *time* Apr 22 2002 11:31 AM
*May 26 23:14:21.707: DHCPD: parsing text line
!IP address Type Hardware address Lease expiration.

10.9.9.1/24 id 0063.6973.636f.2d30.3036.302e.3437

May 2008 DB-951
Debug Commands
*May 26 23:14:21.707: DHCPD: creating binding for 10.9.9.1

*May 26 23:14:21.707: DHCPD: Adding binding to radix tree (10.9.9.1)
*May 26 23:14:21.707: DHCPD: Adding binding to hash tree
10.9.9.4 id 0063.7363.2d30.3036.302e.3762.2e39.3634.632d
*May 26 23:14:21.711: DHCPD: creating binding for 10.9.9.4
*May 26 23:14:21.711: DHCPD: Adding binding to radix tree (10.9.9.4)
*May 26 23:14:21.711: DHCPD: Adding binding to hash tree
*May 26 23:14:21.711: DHCPD: parsing text line Infinite
!IP address Interface-index Lease expiration VRF.
*May 26 23:14:21.711: DHCPD: parsing text line *end*

*May 26 23:14:21.711: DHCPD: read static bindings from
tftp://10.19.192.33/smith/static_pool.

debug dhcp Displays debugging information about the DHCP client and monitors the
status of DHCP packets.
debug ip ddns update Enables debugging for DDNS updates.
hostname
dns hostname and FQDN options by a client on an interface.
method
pool

DB-952 May 2008
Debug Commands
debug ip dhcp server snmp

To enable DHCP server Simple Network Management Protocol (SNMP) debugging, use the debug ip
dhcp server snmp command in privileged EXEC mode. To disable DHCP server SNMP debugging, use
no debug ip dhcp server snmp

12.2(33)SRC This command was introduced.
Examples The following example shows how to enable debugging and display DHCP server SNMP debugging
events:
Router# debug ip dhcp server snmp
00:18:01: DHCPD SNMP: pool 'pool1' 'high' utilization trap is ignored

00:18:18: DHCPD SNMP: pool 'pool1' 'low' utilization trap is ignored
00:20:46: DHCPD SNMP: subnet 4.1.1.0 'high' utilization trap is ignored

00:21:03: DHCPD SNMP: subnet 4.1.1.0 'low' utilization trap is ignored
00:18:01: DHCPD SNMP: subnet trap is not enabled

00:37:32: DHCPD SNMP: pool trap is not enabled
00:37:57: DHCPD SNMP: interface trap is not enabled

00:27:27: DHCPD SNMP: duplicate trap is not enabled

May 2008 DB-953
Debug Commands
debug ip dns name-list

To enable debugging output for Domain Name System (DNS) name list events, use the debug ip dns
name-list command in privileged EXEC mode. To disable debugging output for DNS name list events,
no debug ip dns name-list
Command Default Debugging output is disabled for DNS name lists.

Usage Guidelines This command enables the writing of DNS name list event messages to system message logging (syslog)
output. A DNS name list event can be either of the following:
The addition or removal of a DNS name list entry (a hostname pattern and action to perform on an
incoming DNS query for a hostname that matches the pattern). To add or remove a DNS name list
entry, use the ip dns name-list command.
The removal of a DNS name list.
Note The addition of a DNS name list is reported as an addition of a name list entry.
To display which debugging options are enabled (DNS name list, DNS view, or DNS view list), use the
show debugging command. To display the syslog history statistics and buffer contents, use the show
logging command. To display a particular DNS name list or all configured name lists, use the show ip
dns name-list command.

DB-954 May 2008
Debug Commands
Examples The following sample output from the debug ip dns name-list command shows the hostname pattern
www.example.com being added to DNS name list 1 as a permit clause. Next, the hostname patterns
www.example1.com and www.example2.com are added to DNS name list 2 as deny clauses and permit
clauses, respectively. Finally, the hostname pattern www.example1.com is removed from DNS name list
2.
Router# debug ip dns name-list
DNS Name-list debugging is on

.
.
.
DNS Name-list debugging is on

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

ip dns name-list Defines a list of pattern-matching rules in which each rule permits or denies
the use of a DNS view list member to handle a DNS query based on whether
the query hostname matches the specified regular expression.
show ip dns name-list Displays a particular DNS name list or all configured name lists.
show logging Displays the contents of logging buffers.

May 2008 DB-955
Debug Commands
debug ip dns view
debug ip dns view

To enable debugging output for Domain Name System (DNS) view events, use the debug ip dns view
command in privileged EXEC mode. To disable debugging output for a DNS view, use the no form of
this command.
debug ip dns view
no debug ip dns view
Command Default Debugging output is disabled for DNS views.

Usage Guidelines This command enables the writing of DNS view event messages to system message logging (syslog)
output. A DNS view event can be any of the following:
The addition or removal of a DNS view definition.
The addition or removal of a DNS forwarding name server setting for a DNS view.
The addition or removal of a DNS resolver setting for a DNS view.
The enabling or disabling of logging of a syslog message each time a DNS view is used.
To display which debugging options are enabled (DNS name list, DNS view, or DNS view list), use the
show debugging command. To show the syslog history statistics and buffer contents, use the show
logging command.
Examples The following sample output from the debug ip dns view command shows the default DNS view being
configured:
Router# debug ip dns view
DNS View debugging is on

.
.
.

DB-956 May 2008
Debug Commands
debug ip dns view
DNS View debugging is on

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

ip dns view Enters DNS view configuration mode for the specified DNS view so that the
logging setting, forwarding parameters, and resolving parameters can be
configured for the view.

May 2008 DB-957
Debug Commands
debug ip dns view-list

To enable debugging output for Domain Name System (DNS) view list events, use the debug ip dns
view-list command in privileged EXEC mode. To disable debugging output for a DNS view list, use the
no debug ip dns view-list
Command Default Debugging output is disabled for DNS view lists.

Usage Guidelines This command enables the writing of DNS view list event messages to system message logging (syslog)
output. A DNS view list event can be any of the following:
The addition or removal of a DNS view list definition. To add or remove a DNS view list definition,
use the ip dns view-list command.
The addition or removal of a DNS view list member (a DNS view and the relative order in which it
is to be checked in the view list) to or from a DNS view list. To add or remove a DNS view list
member, use the view command.
The setting or clearing of a DNS view list assignment as the default view list (using the ip dns server
view-group command) or to an interface (using the ip dns view-group command).
To show which debugging options are enabled (DNS name list, DNS view, or DNS view list), use the
show debugging command. To show the syslog history statistics and buffer contents, use the show
logging command.
Examples The following sample output from the debug ip dns vies-list command shows the addition of the DNS
view list definition named userlist5. Next, five DNS views are added as members of the DNS view list.
Router# debug ip dns view-list
DNS View-list debugging is on

.
.

DB-958 May 2008
Debug Commands
.
DNS View-list debugging is on

.
.
.
*May 16 23:31:17.491: DNS_VIEWLIST: creating view-list userlist5

*May 16 23:31:17.711: DNS_VIEWLIST: adding member user1 vrf vpn101 order 10 to view-list
userlist5
userlist5
userlist5
userlist5
*May 16 23:31:22.199: DNS_VIEWLIST: adding member default order 60 to view-list userlist5

ip dns server Specifies the DNS view list to use to determine which DNS view to use
view-group handle incoming queries that arrive on an interface not configured with a
DNS view list.
ip dns view-group Specifies the DNS view list to use to determine which DNS view to use to
handle incoming DNS queries that arrive on a specific interface.
ip dns view-list Enters DNS view list configuration mode so that DNS views can be added to
or removed from the ordered list of DNS views.
view Enters DNS view list member configuration mode so that usage restrictions
can be configured for the view list member.

May 2008 DB-959
Debug Commands
debug ip drp
debug ip drp
To display Director Response Protocol (DRP) information, use the debug ip drp command in privileged
debug ip drp
no debug ip drp
Usage Guidelines The debug ip drp command is used to debug the director response agent used by the Distributed Director
product. The Distributed Director can be used to dynamically respond to Domain Name System (DNS)
queries with the IP address of the best host based on various criteria.
Examples The following is sample output from the debug ip drp command. This example shows the packet
origination, the IP address that information is routed to, and the route metrics that were returned.
Router# debug ip drp
DRP: received v1 packet from 172.69.232.8, via Ethernet0

DRP: RTQUERY for 172.69.58.94 returned internal=0, external=0
Table 128 debug ip drp Field Descriptions
Field Description
DRP: received v1 packet from Router received a version 1 DRP packet from the IP address shown,
172.69.232.8, via Ethernet0 via the interface shown.
DRP: RTQUERY for DRP packet contained two Route Query requests. The first request
172.69.58.94 was for the distance to the IP address 171.69.113.50.
internal If nonzero, the metric for the internal distance of the route that the
router uses to send packets in the direction of the client. The internal
distance is the distance within the autonomous system of the router.
external If nonzero, the metric for the Border Gateway Protocol (BGP) or
external distance used to send packets to the client. The external
distance is the distance outside the autonomous system of the router.

DB-960 May 2008
Debug Commands
debug ip dvmrp
debug ip dvmrp
Note Support for DVMRP has been removed from 12.2SR releases beginning in Cisco IOS Release
12.2(33)SRB. This command is no longer available in Cisco IOS Release 12.2(33)SRB and subsequent
12.2SR releases.
To display information on Distance Vector Multiprotocol Routing Protocol (DVMRP) packets received
and sent, use the debug ip dvmrp command in privileged EXEC mode. To disable debugging output,
debug ip dvmrp [detail [access-list] [in | out]]
no debug ip dvmrp [detail [access-list] [in | out]]
Syntax Description detail (Optional) Enables a more detailed level of output and displays
packet contents.
access-list (Optional) Causes the debug ip dvmrp command to restrict output to
one access list.
in (Optional) Causes the debug ip dvmrp command to output packets
received in DVMRP reports.
out (Optional) Causes the debug ip dvmrp command to output packets
sent in DVMRP reports.
Usage Guidelines Use the debug ip dvmrp detail command with care. This command generates a substantial amount of
output and can interrupt other activity on the router when it is invoked.
Examples The following is sample output from the debug ip dvmrp command:
Router# debug ip dvmrp
DVMRP: Received Report on Ethernet0 from 172.19.244.10

DVMRP: Building Report for Ethernet0 224.0.0.4
DVMRP: Send Report on Ethernet0 to 224.0.0.4
DVMRP: Sending IGMP Reports for known groups on Ethernet0
DVMRP: Received Report on Tunnel0 from 192.168.199.254
DVMRP: Building Report for Tunnel0 224.0.0.4
DVMRP: Send Report on Tunnel0 to 192.168.199.254

May 2008 DB-961
Debug Commands
debug ip dvmrp

DVMRP: Radix tree walk suspension
The following lines show that the router received DVMRP routing information and placed it in the
mroute table:
The following lines show that the router is creating a report to send to another DVMRP router:
DVMRP: Building Report for Ethernet0 224.0.0.4
DVMRP: Send Report on Ethernet0 to 224.0.0.4
Table 129 provides a list of internet multicast addresses supported for host IP implementations.
Table 129 Internet Multicast Addresses
Address Description RFC

224.0.0.0 Base address (reserved) RFC 1112
224.0.0.1 All systems on this subnet RFC 1112
224.0.0.2 All routers on this subnet
224.0.0.3 Unassigned
224.0.0.4 DVMRP routers RFC 1075
224.0.0.5 OSPFIGP all routers RFC 1583
The following lines show that a protocol update report has been sent to all known multicast groups. Hosts
use Internet Group Management Protocol (IGMP) reports to communicate with routers and to request to
join a multicast group. In this case, the router is sending an IGMP report for every known group to the
host, which is running mrouted. The host then responds as though the router were a host on the LAN
segment that wants to receive multicast packets for the group.
The following is sample output from the debug ip dvmrp detail command:
Router# debug ip dvmrp detail

DVMRP: Advertise group 224.2.224.2 on Ethernet0
DVMRP: Origin 150.166.53.0/24, metric 13, distance 0

DB-962 May 2008
Debug Commands
debug ip dvmrp
The following lines show that this group is available to the DVMRP router. The mrouted process on the
host will forward the source and multicast information for this group through the DVMRP cloud to other
members.
The following lines show the DVMRP route information:

The metric is the number of hops the route has covered, and the distance is the administrative distance.

May 2008 DB-963
Debug Commands
debug ip eigrp notifications

To display Enhanced Interior Gateway Routing Protocol (EIGRP) events and notifications in the console
of the router, use the debug ip eigrp notifications command in privileged EXEC mode. To disable
no debug ip eigrp notifications

Usage Guidelines The output from the debug ip eigrp notifications command displays EIGRP events and notifications.
Examples The following example output shows that the NSF-aware router has received the restart notification. The
NSF-aware router will now wait for end of transmission (EOT) to be sent from the restarting neighbor
(NSF-capable).
Router# debug ip eigrp notifications
*Oct 4 11:39:18.092:EIGRP:NSF:AS2. Rec RS update from 135.100.10.1,

00:00:00. Wait for EOT.
*Oct 4 11:39:18.092:%DUAL-5-NBRCHANGE:IP-EIGRP(0) 2:Neighbor
135.100.10.1 (POS3/0) is up:peer NSF restarted

timers nsf-route-hold Sets the route-hold timer for NSF-aware routers that run EIGRP.

DB-964 May 2008
Debug Commands
debug ip eigrp
debug ip eigrp
To display information on Enhanced Interior Gateway Routing Protocol (EIGRP) protocol packets, use
the debug ip eigrp command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug ip eigrp
no debug ip eigrp
Usage Guidelines This command helps you analyze the packets that are sent and received on an interface. Because the
debug ip eigrp command generates a substantial amount of output, only use it when traffic on the
network is light.
Examples The following is sample output from the debug ip eigrp command:
Router# debug ip eigrp
IP-EIGRP: Processing incoming UPDATE packet

IP-EIGRP: Ext 192.168.3.0 255.255.255.0 M 386560 - 256000 130560 SM 360960 - 256000 104960
IP-EIGRP: Ext 192.168.0.0 255.255.255.0 M 386560 - 256000 130560 SM 360960 - 256000 104960
IP-EIGRP: Ext 192.168.3.0 255.255.255.0 M 386560 - 256000 130560 SM 360960 - 256000 104960
IP-EIGRP: 172.69.43.0 255.255.255.0, - do advertise out Ethernet0/1
IP-EIGRP: Ext 172.69.43.0 255.255.255.0 metric 371200 - 256000 115200
Table 130 debug ip eigrp Field Descriptions
Field Description
IP-EIGRP: Indicates that this is an IP EIGRP message.
Ext Indicates that the following address is an external destination rather
than an internal destination, which would be labeled as Int.

May 2008 DB-965
Debug Commands
debug ip eigrp
Table 130 debug ip eigrp Field Descriptions (continued)
Field Description
M Displays the computed metric, which includes the value in the SM
field and the cost between this router and the neighbor. The first
number is the composite metric. The next two numbers are the
inverse bandwidth and the delay, respectively.
SM Displays the metric as reported by the neighbor.

DB-966 May 2008
Debug Commands
debug ip error
debug ip error
To display IP errors, use the debug ip error command in privileged EXEC mode. To disable debugging
errors, use the no form of this command.
debug ip error access-list-number [detail] [dump]
no debug ip error
Syntax Description access-list-number (Optional) The IP access list number that you can specify. If the datagram is
not permitted by that access list, the related debugging output (or IP error) is
suppressed. Standard, extended, and expanded access lists are supported.
The range of standard and extended access lists is from 1 to 199. The range
of expanded access lists is from 1300 to 2699.
detail (Optional) Displays detailed IP error debugging information.
dump (Hidden) Displays IP error debugging information along with raw packet
data in hexadecimal and ASCII forms. This keyword can be enabled with
individual access lists and also with the detail keyword.
Note The dump keyword is not fully supported and should be used only
in collaboration with Cisco Technical Support. See the caution notes
below, in the usage guidelines, for more specific information.
Usage Guidelines This command is used for IP error debugging. The output displays IP errors which are locally detected
by this router.
Caution Enabling this command will generate output only if IP errors occur. However, if the router starts to
receive many packets that contain errors, substantial output may be generated and severely affect system
performance. This command should be used with caution in production networks. It should only be
enabled when traffic on the IP network is low, so other activity on the system is not adversely affected.
Enabling the detail and dump keywords use the highest level of system resources of the available
configuration options for this command, so a high level of caution should be applied when enabling
either of these keywords.

May 2008 DB-967
Debug Commands
debug ip error
Caution The dump keyword is not fully supported and should be used only in collaboration with Cisco Technical
Support. Because of the risk of using significant CPU utilization, the dump keyword is hidden from the
user and cannot be seen using the ? prompt. The length of the displayed packet information may
exceed the actual packet length and include additional padding bytes that do not belong to the IP packet.
Also note that the beginning of a packet may start at different locations in the dump output depending
on the specific router, interface type, and packet header processing that may have occurred before the
output is displayed.
Examples The following is sample output from the debug ip error command:
Router# debug ip error
IP packet errors debugging is on
04:04:45:IP:s=10.8.8.1 (Ethernet0/1), d=10.1.1.1, len 28, dispose ip.hopcount
The IP error in the above output was caused when the router attempted to forward a packet with a
time-to-live (TTL) value of 0. The ip.hopcount traffic counter is incremented when a packet is dropped
because of an error. This error is also displayed in the output of the show ip traffic command by the bad
hop count traffic counter.
Table 131 debug ip error Field Descriptions
Field Description
IP:s=10.8.8.1 (Ethernet0/1) The packet source IP address and interface.
d=10.1.1.1, len 28 The packet destination IP address and prefix length.
dispose ip.hopcount This traffic counter increments when an IP packet is dropped
because of an error.
The following is sample output from the debug ip error command enabled with the detail keyword:
Router# debug ip error detail
IP packet errors debugging is on (detailed)
1d08h:IP:s=10.0.19.100 (Ethernet0/1), d=10.1.1.1, len 28, dispose udp.noport

1d08h: UDP src=41921, dst=33434
1d08h:IP:s=10.0.19.100 (Ethernet0/1), d=10.2.2.2, len 28, dispose ip.hopcount

1d08h: UDP src=33691, dst=33434
The detailed output includes layer 4 information in addition to the standard output. The IP error in the
above output was caused when the router received a UDP packet when no application was listening to
the UDP port. The udp.noport traffic counter is incremented when the router drops a UDP packet
because of this error. This error is also displayed in the output of the show ip traffic command by the
no port traffic counter under UDP statistics.

DB-968 May 2008
Debug Commands
debug ip error
Table 132 debug ip error detail Field Descriptions
Field Description
IP:s=10.0.19.100 (Ethernet0/1) The IP packet source IP address and interface.
d=10.1.1.1, len 28 The IP packet destination and prefix length.
dispose udp.noport The traffic counter that is incremented when a UDP packet is
dropped because of this error.
The following is sample output from the debug ip error command enabled with the detail and dump
keywords:
Router# debug ip error detail dump
IP packet errors debugging is on (detailed) (dump)
1d08h:IP:s=10.0.19.100 (Ethernet0/1), d=10.1.1.1, len 28, dispose udp.noport

1d08h: UDP src=37936, dst=33434
03D72360: 0001 42AD4242 ..B-BB
03D72370:0002FCA5 DC390800 4500001C 30130000 ..|%\9..E...0...
03D72380:01116159 0A001364 0A010101 9430829A ..aY...d.....0..
03D72390:0008C0AD ..@-
1d08h:IP:s=10.0.19.100 (Ethernet0/1), d=10.2.2.2, len 28, dispose ip.hopcount

1d08h: UDP src=41352, dst=33434
03C01600: 0001 42AD4242 ..B-BB
03C01610:0002FCA5 DC390800 4500001C 302A0000 ..|%\9..E...0*..
03C01620:01116040 0A001364 0A020202 A188829A ..`@...d....!...
03C01630:0008B253 ..2S
Note The dump keyword is not fully supported and should be used only in collaboration with Cisco Technical
Support. See the caution in the usage guidelines section of this command reference page for more
specific information.
The output from the debug ip error command, when the dump keyword is enabled, provides raw packet
data in hexadecimal and ASCII forms. This addtional output is displayed in addition to the standard
output. The dump keyword can be used with all of the available configuration options of this command.
Table 133 debug ip error detail dump Field Descriptions
Field Description
IP:s=10.0.19.100 (Ethernet0/1) The IP packet source IP address and interface.
d=10.1.1.1, len 28 The IP packet destination and prefix length.
dispose udp.noport The traffic counter that is incremented when a UDP packet is
dropped because of this error.

show ip traffic Displays statistics about IP traffic.

May 2008 DB-969
Debug Commands
debug ip flow cache
debug ip flow cache

To enable debugging output for NetFlow cache, use the debug ip flow cache command in user EXEC or
debug ip flow cache
no debug ip flow cache
Command Default Debugging output for NetFlow data export is disabled.
Command Modes User EXEC

Privileged EXEC

12.3(1) Debugging output for NetFlow v9 data export was added.
12.3(7)T Debugging output for NetFlow for IPv6 was added.
Examples The following is sample output from the debug ip flow export command:
Router# debug ip flow cache
IP Flow cache allocation debugging is on
Router# show ipv6 flow
IP packet size distribution (0 total packets):

1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000
IP Flow Switching Cache, 0 bytes

0 active, 0 inactive, 0 added
0 ager polls, 0 flow alloc failures
Active flows timeout in 30 minutes

DB-970 May 2008
Debug Commands
debug ip flow cache
Inactive flows timeout in 15 seconds

SrcAddress InpIf DstAddress
OutIf Prot SrcPrt DstPrt Packets
c7200-vxr-2#
000037: 01:56:26: IPFLOW: Allocating Sub-Flow cache, without hash flags.
000038: 01:56:26: IPFLOW: Sub-Flow table enabled.
000039: 01:56:26: IPFLOW: Sub-Flow numbers are:
24 sub-flows per chunk, 0 hashflag len,
1 chunks allocated, 12 max chunks,
24 allocated records, 24 free records, 960 bytes allocated
000040: 01:56:26: IPFLOW: Sub-Flow cache removed

export destination Enables the exporting of information from NetFlow
aggregation caches.
ip flow-aggregation cache Enables NetFlow aggregation cache schemes.
ip flow-export Enables the exporting of information in NetFlow cache
entries.
ipv6 flow-aggregation cache Enables NetFlow aggregation cache schemes for IPv6
configurations.
ipv6 flow export Enables the exporting of information in NetFlow cache
entries for IPv6 NetFlow configurations.
show ip cache flow aggregation Displays the NetFlow aggregation cache configuration.
show ip flow export Display the statistics for NetFlow data export.

May 2008 DB-971
Debug Commands
debug ip flow export

To enable debugging output for NetFlow data export, use the debug ip flow export command in user
EXEC or privileged EXEC mode. To disable debugging output for NetFlow data export, use the no form
of this command.
no debug ip flow export
Command Default Debugging output for NetFlow data export is disabled.

Privileged EXEC

12.3(1) Debugging output for NetFlow v9 data export was added.
12.3(7)T This command was modified so that NetFlow v9 data is collected for both
IPv4 and IPv6.
12.2(18)SXF This command was integrated into Cisco IOS Release 12.2(18)SXF.
Examples The following is sample output from the debug ip flow export command:
Router# debug ip flow export
IP Flow export mechanism debugging is on

*Mar 6 22:56:21.627:IPFLOW:Sending export pak to 2001::FFFE/64 port 9999
*Mar 6 22:56:21.627:IPFLOW:Error sending export packet:Adjacency failure

DB-972 May 2008
Debug Commands

export destination Enables the exporting of information from NetFlow aggregation
caches.
ipv6 flow-aggregation cache Enables NetFlow aggregation cache schemes for IPv6.
ipv6 flow-export Enables the exporting of information in NetFlow cache entries.
show ip cache flow aggregation Displays the NetFlow accounting aggregation cache statistics.
show ip flow export Displays the statistics for NetFlow data export.
show ipv6 flow export Displays the statistics for NetFlow data export for IPv6.

May 2008 DB-973
Debug Commands
debug ip ftp
debug ip ftp
To activate the debugging option to track the transactions submitted during an FTP session, use the
debug ip ftp command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug ip ftp
no debug ip ftp
Usage Guidelines The debug ip ftp command is useful for debugging problems associated with FTP.
Examples The following is an example of the debug ip ftp command:

Router# debug ip ftp
FTP transactions debugging is on
The following is sample output from the debug ip ftp command:

FTP: 220 ProFTPD 1.2.0pre8 Server (DFW Nostrum FTP Server) [defiant.dfw.nostrum.com]
Dec 27 22:12:09.133: FTP: ---> USER router
Dec 27 22:12:09.133: FTP: 331 Password required for router.
Dec 27 22:12:09.137: FTP: ---> PASS WQHK5JY2
Dec 27 22:12:09.153: FTP: 230 Anonymous access granted, restrictions apply.
Dec 27 22:12:09.153: FTP: ---> TYPE I
Dec 27 22:12:09.157: FTP: 200 Type set to I.
Dec 27 22:12:09.157: FTP: ---> PASV
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Dec 27 22:12:09.173: FTP: ---> QUIT
Dec 27 22:12:09.181: FTP: 221 Goodbye.

DB-974 May 2008
Debug Commands
debug ip http all
debug ip http all

To enable debugging output for all HTTP processes on the system, use the debug ip http all command
debug ip http all
no debug ip http all
Defaults Disabled

Usage Guidelines Use this command to enable debugging messages for all HTTP processes and activity. Issuing this
command is equivalent to issuing the following commands:
debug ip http authentication
debug ip http ezsetup
debug ip http ssi
debug ip http token
debug ip http transaction
debug ip http url

May 2008 DB-975
Debug Commands
debug ip http all
Examples For sample output and field descriptions of this command, see the documentation of the commands listed
in the Usage Guidelines section.

debug ip http authentication Enables debugging output for all processes for HTTP
server and client access.
debug ip http ezsetup Displays the configuration changes that occur during the
EZ Setup process.
debug ip http ssi Displays SSI translations and SSI ECHO command
execution.
debug ip http token Displays individual tokens parsed by the HTTP server.
debug ip http transaction Displays HTTP server transaction processing.
debug ip http url Displays the URLs accessed from the router.

DB-976 May 2008
Debug Commands

To troubleshoot HTTP authentication problems, use the debug ip http authentication command in
no debug ip http authentication

Usage Guidelines Use this command to display the authentication method the router attempted and authentication-specific
status messages.
Examples The following is sample output from the debug ip http authentication command:
Router# debug ip http authentication
Authentication for url / / level 15 privless /

Authentication username = local15 priv-level = 15 auth-type = local
Table 134 debug ip http authentication Field Descriptions
Field Description
Authentication for url Provides information about the URL in different forms.
Authentication username Identifies the user.
priv-level Indicates the user privilege level.
auth-type Indicates the authentication method.
Related Commands

May 2008 DB-977
Debug Commands
Command Description
debug ip http all Displays authentication processes for all HTTP server
processes on the system.
EZ Setup process.
execution.

DB-978 May 2008
Debug Commands
debug ip http client

To enable debugging output for the HTTP client, use the debug ip http client command in privileged
EXEC mode. To disable debugging output for the HTTP client, use the no or undebug form of this
command.
debug ip http client {all | api | cache | error | main | msg | socket}
no debug ip http client {all | api | cache | error | main | msg | socket}
undebug ip http client {all | api | cache | error | main | msg | socket}
Syntax Description all Enables debugging for all HTTP client elements.
api Enables debugging output for the HTTP client application interface (API).
cache Enables debugging output for the HTTP client cache.
error Enables debugging output for HTTP communication errors.
main Enables debugging output specific to the Voice XML (VXML) applications
interacting with the HTTP client.
msg Enables debugging output of HTTP client messages.
socket Enables debugging output specific to the HTTP client socket.

Usage Guidelines Use this command to display transactional information for the HTTP client for debugging purposes.
Examples The following example shows sample debugging output for a failed copy transfer operation when the
host name resolution fails:
Router# debug ip http client all
2w4d: Cache ager called

Router# copy http://www.example.com/index.html flash:index.html
Destination filename [index.html]?
Erase flash: before copying? [confirm] no
Translating "www.example.com"

May 2008 DB-979
Debug Commands
% Bad IP address for host www.example.com

%Error opening http://www.example.com/index.html (I/O error)
Router#
2w4d: http_client_request:
2w4d: httpc_setup_request:
2w4d: http_client_process_request:
2w4d: HTTPC: Host name resolution failed for www.example.com
2w4d: http_transaction_free:
2w4d: http_transaction_free: freed httpc_transaction_t
The following example shows sample debugging output for a failed copy transfer operation when the
source file is not available:
Router# copy http://example.com/hi/file.html flash:/file.html
Destination filename [file.html]?
%Error opening http://example.com/hi/file.html (No such file or directory)
Router#
2w4d: http_client_request:
2w4d: httpc_setup_request:
2w4d: http_client_process_request:
2w4d: httpc_request:Dont have the credentials
Thu, 17 Jul 2003 07:05:25 GMT http://209.168.200.225/hi/file.html ok

Protocol = HTTP/1.1
Content-Type = text/html; charset=iso-8859-1
Date = Thu, 17 Jul 2003 14:24:29 GMT
2w4d: http_transaction_free:
2w4d: http_transaction_free:freed httpc_transaction_t
2w4d: http_client_abort_request:
2w4d: http_client_abort_request:Bad Transaction Id
Router#
Table 135 debug ip http client Field Descriptions
Field Description
2w4d: In the examples shown, the string 2w4d is the timestamp
configured on the system. Indicates two weeks and four days
since the last system reboot.
The time-stamp format is configured using the service
timestamps debug global configuration mode
command.
HTTPC: Indicates the HTTP client in Cisco IOS software.
or
httpc

DB-980 May 2008
Debug Commands
Table 135 debug ip http client Field Descriptions (continued)
Field Description
httpc_request:Dont have the credentials Indicates that this HTTP client request did not supply any
authentication information to the server.
The authentication information consists of a username and
password combination.
The message is applicable to both HTTP and HTTPS.
Thu, 17 Jul 2003 07:05:25 GMT The ok in this line indicates that there were no internal
http://209.168.200.225/hi/file.html ok errors relating to processing this HTTP client transaction by
the HTTP client. In other words, the HTTP client was able
to send the request and receive some response.
Note The ok value in this line does not indicate file
availability (200: OK message or 404: File Not
Found message).

copy Copies a file from any supported remote location to a local file system,
or from a local file system to a remote location, or from a local file system
to a local file system.
ip http client connection Configures the HTTP client connection.
ip http client password Configures a password for all HTTP client connections.
ip http client proxy-server Configures an HTTP proxy server.
ip http client Configures a source interface for the HTTP client.
source-interface
ip http client username Configures a login name for all HTTP client connections.
service timestamps Configures the time-stamping format for debugging or system logging
messages.
show ip http client Displays a report about HTTP client active connections.
connection
show ip http client history Displays the URLs accessed by the HTTP client.
show ip http client Displays a report about sessions that have registered with the HTTP
session-module client.

May 2008 DB-981
Debug Commands

To display the configuration changes that occur during the EZ Setup process, use the debug ip http
ezsetup command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
no debug ip http ezsetup

Usage Guidelines Use this command to verify the EZ Setup actions without changing the configuration of the router.
EZ Setup is a form you fill out to perform basic router configuration from most HTML browsers.
Examples The following sample output from the debug ip http ezsetup command shows the configuration changes
for the router when the EZ Setup form has been submitted:
Router# debug ip http ezsetup
service timestamps debug

service timestamps log
service password-encryption
!
hostname router-name
!
enable secret router-pw
line vty 0 4
password router-pw
!
interface ethernet 0
ip address 172.69.52.9 255.255.255.0
no shutdown
ip helper-address 172.31.2.132
ip name-server 172.31.2.132
isdn switch-type basic-5ess
username Remote-name password Remote-chap
interface bri 0
ip unnumbered ethernet 0

DB-982 May 2008
Debug Commands
encapsulation ppp
no shutdown
dialer map ip 192.168.254.254 speed 56 name Remote-name Remote-number
isdn spid1 spid1
isdn spid2 spid2
ppp authentication chap callin
dialer-group 1
!
ip classless
access-list 101 deny udp any any eq snmp
access-list 101 deny udp any any eq ntp
access-list 101 permit ip any any
dialer-list 1 list 101
ip route 0.0.0.0 0.0.0.0 192.168.254.254
ip route 192.168.254.254 255.255.255.255 bri 0
logging buffered
snmp-server community public RO
ip http server
ip classless
ip subnet-zero
!
end

debug ip http authentication Displays authentication processes for HTTP server and
client access.
execution.

May 2008 DB-983
Debug Commands
debug ip http secure-all

To generate the following output, use the debug ip http secure-all command in privileged EXEC mode:
The debugging information generated by the debug ip http secure-session command
The debugging information generated by the debug ip http secure-state command
Debugging information for each call to the SSL driver, for use primarily by Cisco support personnel
To disable this debugging, use the no form of this command.
no debug ip http secure-all
Defaults Disabled.

12.1(11b)E This command was introduced.
Usage Guidelines This command generates the following:

The debugging information generated by the debug ip http secure-session command. See the
debug ip http secure-session command page for example debugging output.
The debugging information generated by the debug ip http secure-state command. See the debug
ip http secure-state command page for example debugging output.
Debugging information for each call to the SSL driver, for use primarily by Cisco support personnel
Examples The following example generates the following output:

The debugging information generated by the debug ip http secure-session command
The debugging information generated by the debug ip http secure-state command
Debugging information for each call to the SSL driver
Router# debug ip http secure-all

DB-984 May 2008
Debug Commands

debug ip http Generates debugging information about each new secure HTTPS session
secure-session when it is created.
debug ip http Generates debugging information each time the secure HTTPS server
secure-state changes state.

May 2008 DB-985
Debug Commands
debug ip http secure-session

To generate debugging information about each new secure HTTPS session when it is created, use the
debug ip http secure-session command in privileged EXEC mode. To disable this debugging, use the
no debug ip http secure-session
Defaults Disabled.

Usage Guidelines This command generates debugging information about each new HTTPS session when it is created.
When a new HTTPS session is created, debugging information is generated in the following format:
HTTPS SSL Session Established/Handshake done - Peer 10.0.0.1
state = SSL negotiation finished successfully
SessionInfo: Digest=RC4-MD5 SSLVer=SSLv3 KeyEx=RSA Auth=RSA Cipher=RC4(128) Mac=MD5
The SessionInfo fields provide the following information about the session:
Digestdigest mechanism
SSLVerSSL or TSL version
KeyExkey exchange mechanism
Authauthentication mechanism
Cipherencryption algorithm
MacMessage Authentication Code algorithm
Examples The following example generates debugging information about each new HTTPS session when it is
created:

DB-986 May 2008
Debug Commands

debug ip http Enables all other debugging ip http secure-x commands and generates
secure-all debugging information for each call to the HTTPS server driver.
debug ip http Generates debugging information each time the HTTPS server changes
secure-state state.

May 2008 DB-987
Debug Commands
debug ip http secure-state

To generate debugging output each time the Secure HTTP (HTTPS) feature changes state, use the debug
ip http secure-state command in privileged EXEC mode. To disable this debugging, use the no form
of this command.
no debug ip http secure-state
Defaults Disabled.

Usage Guidelines This command generates debugging information each time the Secure HTTP (HTTPS) feature changes
state. When the Secure HTTP (HTTPS) feature changes state, debugging information is generated in the
following format:
HTTPS SSL State Change - Peer 10.0.0.1
Old State = SSLv3 read finished A, New State = SSL negotiation finished successfully
Examples The following example generates debugging information each time the Secure HTTP (HTTPS) feature
changes state:

debug ip http Enables all other debugging ip http secure-x commands and generates
secure-all debugging information for each call to the HTTPS server driver.
debug ip http Generates debugging information each time the HTTPS server changes
secure-state state.

DB-988 May 2008
Debug Commands
debug ip http ssi
debug ip http ssi

To display information about the HTML SSI EXEC command or HTML SSI ECHO command, use the
debug ip http ssi command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
debug ip http ssi
no debug ip http ssi

Examples The following is sample output from the debug ip http ssi command:
Router# debug ip http ssi
HTML: filtered command exec cmd="show users"

HTML: SSI command exec
HTML: SSI tag cmd = "show users"
HTML: Executing CLI show users in mode exec done
The following line shows the contents of the SSI EXEC command:
HTML: filtered command exec cmd="show users"
The following line indicates the type of SSI command that was requested:
HTML: SSI command exec
The following line shows the show users argument assigned to the tag command:
HTML: SSI tag cmd = "show users"
The following line indicates that the show users command is being executed in EXEC mode:
HTML: Executing CLI show users in mode exec done

May 2008 DB-989
Debug Commands
debug ip http ssi

client access.
EZ Setup process.

DB-990 May 2008
Debug Commands
debug ip http ssl error

To enable debugging messages for the secure HTTP (HTTPS) web server and client, use the debug ip
http ssl error command in privileged EXEC mode. To disable debugging messages for the HTTPS web
server and client, use the no form of this command.
no debug ip http ssl error
Command Default Debugging message output is disabled.

Usage Guidelines This command displays output for debugging purposes related to the HTTPS server and HTTPS client.
HTTPS services use the Secure Socket Layer (SSL) protocol, version 3.0, for encryption.
Examples The following is sample debugging output from the debug ip http ssl error command:
Router# 000030:00:08:01:%HTTPS:Key pair generation failed
Router# 000030:00:08:10:%HTTPS:Failed to generate self-signed cert
Router# 000030:00:08:15:%HTTPS:SSL handshake fail
Router# 000030:00:08:21:%HTTPS:SSL read fail, uninitialized hndshk ctxt
Router# 000030:00:08:25:%HTTPS:SSL write fail, uninitialized hndshk ctxt

May 2008 DB-991
Debug Commands
Table 136describes the debug messages shown above.
Table 136 debug ip http ssl error Field Descriptions
Field Description
%HTTPS:Key pair generation failed The RSA key pair generation failed.
%HTTPS:Failed to generate The HTTPS server or client failed to generate a self-signed
self-signed cert certificate.
%HTTPS:SSL handshake fail SSL connection handshake failed.
%HTTPS:SSL read fail, uninitialized A read operation failed for SSL with an unitialized
hndshk ctxt handshake context

ip http secure-server Enables the secure HTTP (HTTPS) server.

DB-992 May 2008
Debug Commands
debug ip http token
debug ip http token

To display individual tokens parsed by the HTTP server, use the debug ip http token command in
debug ip http token
no debug ip http token

Usage Guidelines Use the debug ip http token command to display low-level HTTP server parsings. To display high-level
HTTP server parsings, use the debug ip http transaction command.
Examples The following is part of sample output from the debug ip http token command. In this example, the
browser accessed the routers home page http://router-name/. The output gives the token parsed by the
HTTP server and its length.
Router# debug ip http token
HTTP: token len 3: 'GET'

HTTP: token len 1: ' '
HTTP: token len 1: '/'
HTTP: token len 4: 'HTTP'
HTTP: token len 1: '1'
HTTP: token len 1: '.'
HTTP: token len 2: '\15\12'
HTTP: token len 7: 'Referer'
HTTP: token len 1: ':'
HTTP: token len 4: 'http'
HTTP: token len 3: 'www'

May 2008 DB-993
Debug Commands
debug ip http token
HTTP: token len 3: 'thesite'

HTTP: token len 3: 'com'
HTTP: token len 10: 'Connection'
HTTP: token len 4: 'Keep'
HTTP: token len 1: '-'
HTTP: token len 5: 'Alive'
HTTP: token len 4: 'User'
HTTP: token len 1: '-'
HTTP: token len 5: 'Agent'
HTTP: token len 7: 'Mozilla'
.
.
.

client access.
EZ Setup process.
execution.

DB-994 May 2008
Debug Commands

To display HTTP server transaction processing, use the debug ip http transaction command in
no debug ip http transaction

Usage Guidelines Use the debug ip http transaction command to display what the HTTP server is parsing at a high level.
To display what the HTTP server is parsing at a low level, use the debug ip http token command.
Examples The following is sample output from the debug ip http transaction command. In this example, the
browser accessed the routers home page http://router-name/.
Router# debug ip http transaction
HTTP: parsed uri '/'

HTTP: client version 1.1
HTTP: parsed extension Referer
HTTP: parsed line http://www.company.com/
HTTP: parsed extension Connection
HTTP: parsed line Keep-Alive
HTTP: parsed extension User-Agent
HTTP: parsed line Mozilla/2.01 (X11; I; FreeBSD 2.1.0-RELEASE i386)
HTTP: parsed extension Host
HTTP: parsed line router-name
HTTP: parsed extension Accept
HTTP: parsed line image/gif, image/x-xbitmap, image/jpeg, image/
HTTP: parsed extension Authorization
HTTP: parsed authorization type Basic
HTTP: received GET ''

May 2008 DB-995
Debug Commands
Table 137 debug ip http transaction Field Descriptions
Field Description
HTTP: parsed uri '/' Uniform resource identifier that is requested.
HTTP: client version 1.1 Client HTTP version.
HTTP: parsed extension Referer HTTP extension.
HTTP: parsed line Value of HTTP extension.
http://www.company.com/
HTTP: received GET '' HTTP request method.

client access.
EZ Setup process.
execution.

DB-996 May 2008
Debug Commands
debug ip http url
debug ip http url

To show the URLs accessed from the router, use the debug ip http url command in privileged EXEC
debug ip http url
no debug ip http url

Usage Guidelines Use the debug ip http url command to keep track of the URLs that are accessed and to determine from
which hosts the URLs are accessed.
Examples The following is sample output from the debug ip http url command. In this example, the HTTP server
accessed the URLs and /exec. The output shows the URL being requested and the IP address of the host
requesting the URL.
Router# debug ip http url
HTTP: processing URL '/' from host 172.31.2.141

HTTP: processing URL '/exec' from host 172.31.2.141

client access.
EZ Setup process.
execution.

May 2008 DB-997
Debug Commands
debug ip http url
Command Description

DB-998 May 2008
Debug Commands
debug ip icmp
debug ip icmp
To display information on Internal Control Message Protocol (ICMP) transactions, use the debug ip
icmp command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug ip icmp
no debug ip icmp
Usage Guidelines This command helps you determine whether the router is sending or receiving ICMP messages. Use it,
for example, when you are troubleshooting an end-to-end connection problem.
Note For more information about the fields in debug ip icmp command output, refer to RFC 792, Internet
Control Message Protocol; Appendix I of RFC 950, Internet Standard Subnetting Procedure; and
RFC 1256, ICMP Router Discovery Messages.
Examples The following is sample output from the debug ip icmp command:
Router# debug ip icmp
ICMP: rcvd type 3, code 1, from 10.95.192.4

ICMP: src 10.56.0.202, dst 172.69.16.1, echo reply
ICMP: dst (10.120.1.0) port unreachable rcv from 10.120.1.15
ICMP: dst (255.255.255.255) protocol unreachable rcv from 10.31.7.21

May 2008 DB-999
Debug Commands
debug ip icmp
Table 138 debug ip icmp Field Descriptions
Field Description
ICMP: Indication that this message describes an ICMP packet.
rcvd type 3 The type field can be one of the following:
0Echo Reply
3Destination Unreachable
4Source Quench
5Redirect
8Echo
9Router Discovery Protocol Advertisement
10Router Discovery Protocol Solicitations
11Time Exceeded
12Parameter Problem
13Timestamp
14Timestamp Reply
15Information Request
16Information Reply
17Mask Request
18Mask Reply

DB-1000 May 2008
Debug Commands
debug ip icmp
Table 138 debug ip icmp Field Descriptions (continued)
Field Description
code 1 This field is a code. The meaning of the code depends upon the type
field value, as follows:
Echo and Echo ReplyThe code field is always zero.
Destination UnreachableThe code field can have the following
values:
0Network unreachable
1Host unreachable
2Protocol unreachable
3Port unreachable
4Fragmentation needed and DF bit set
5Source route failed
Source QuenchThe code field is always 0.
RedirectThe code field can have the following values:
0Redirect datagrams for the network
1Redirect datagrams for the host
2Redirect datagrams for the command mode of service and
network
3Redirect datagrams for the command mode of service and host
Router Discovery Protocol Advertisements and
SolicitationsThe code field is always zero.
Time ExceededThe code field can have the following values:
0Time to live exceeded in transit
1Fragment reassembly time exceeded
Parameter ProblemThe code field can have the following values:
0General problem
1Option is missing
2Option missing, no room to add
Timestamp and Timestamp ReplyThe code field is always zero.
Information Request and Information ReplyThe code field is
always zero.
Mask Request and Mask ReplyThe code field is always zero.
from 10.95.192.4 Source address of the ICMP packet.
Table 139 describes the significant fields shown in the second line of the display.

May 2008 DB-1001
Debug Commands
debug ip icmp
Table 139 debug ip icmp Field Descriptions
Field Description
ICMP: Indicates that this message describes an ICMP packet.
src 10.56.10.202 Address of the sender of the echo.
dst 172.69.16.1 Address of the receiving router.
echo reply Indicates that the router received an echo reply.
Other messages that the debug ip icmp command can generate follow.
When an IP router or host sends out an ICMP mask request, the following message is generated when
the router sends a mask reply:
ICMP: sending mask reply (255.255.255.0) to 172.69.80.23 via Ethernet0
The following two lines are examples of the two forms of this message. The first form is generated when
a mask reply comes in after the router sends out a mask request. The second form occurs when the router
receives a mask reply with a nonmatching sequence and ID. Refer to Appendix I of RFC 950, Internet
Standard Subnetting Procedures, for details.
ICMP: mask reply 255.255.255.0 from 172.69.80.31
ICMP: unexpected mask reply 255.255.255.0 from 172.69.80.32
The following output indicates that the router sent a redirect packet to the host at address 172.69.80.31,
instructing that host to use the gateway at address 172.69.80.23 in order to reach the host at destination
address 172.69.1.111:
ICMP: redirect sent to 172.69.80.31 for dest 172.69.1.111 use gw 172.69.80.23
The following message indicates that the router received a redirect packet from the host at address
172.69.80.23, instructing the router to use the gateway at address 172.69.80.28 in order to reach the host
at destination address 172.69.81.34:
ICMP: redirect rcvd from 172.69.80.23 -- for 172.69.81.34 use gw 172.69.80.28
The following message is displayed when the router sends an ICMP packet to the source address
(172.69.94.31 in this case), indicating that the destination address (172.69.13.33 in this case) is
unreachable:
ICMP: dst (172.69.13.33) host unreachable sent to 172.69.94.31
The following message is displayed when the router receives an ICMP packet from an intermediate
address (172.69.98.32 in this case), indicating that the destination address (172.69.13.33 in this case) is
unreachable:
ICMP: dst (172.69.13.33) host unreachable rcv from 172.69.98.32
Depending on the code received (as Table 123 describes), any of the unreachable messages can have any
of the following strings instead of the host string in the message:
net
protocol
port
frag. needed and DF set
source route failed
prohibited

DB-1002 May 2008
Debug Commands
debug ip icmp
The following message is displayed when the TTL in the IP header reaches zero and a time exceed ICMP
message is sent. The fields are self-explanatory.
ICMP: time exceeded (time to live) send to 10.95.1.4 (dest was 172.69.1.111)
The following message is generated when parameters in the IP header are corrupted in some way and
the parameter problem ICMP message is sent. The fields are self-explanatory.
ICMP: parameter problem sent to 128.121.1.50 (dest was 172.69.1.111)
Based on the preceding information, the remaining output can be easily understood:
ICMP: parameter problem rcvd 172.69.80.32
ICMP: source quench rcvd 172.69.80.32
ICMP: source quench sent to 128.121.1.50 (dest was 172.69.1.111)
ICMP: sending time stamp reply to 172.69.80.45
ICMP: sending info reply to 172.69.80.12
ICMP: rdp advert rcvd type 9, code 0, from 172.69.80.23
ICMP: rdp solicit rcvd type 10, code 0, from 172.69.80.43

May 2008 DB-1003
Debug Commands
debug ip igmp snooping
debug ip igmp snooping

To display debugging messages about Internet Group Management Protocol (IGMP) snooping services,
use the debug ip igmp snooping command in privileged EXEC mode. To disable debugging output, use
debug ip igmp snooping {group | management | router | timer}
no debug ip igmp snooping {group | management | router | timer}
Syntax Description group Displays debugging messages related to multicast groups.

management Displays debugging messages related to IGMP management services.
router Displays debugging messages related to the local router.
timer Displays debugging messages related to the IGMP timer.

series, Cisco 3600 series, and Cisco 3700 series routers.
following platforms: Cisco 2600 series, Cisco 3600 series, and
Examples The following example shows debugging messages for the IGMP snooping services being displayed:
Router# debug ip igmp snooping
IGMP snooping enabled

show ip igmp snooping Displays the IGMP snooping configuration.

DB-1004 May 2008
Debug Commands
debug ip igmp
debug ip igmp
To display Internet Group Management Protocol (IGMP) packets received and sent, and IGMP-host
related events, use the debug ip igmp command in privileged EXEC mode. To disable debugging output,
debug ip igmp [vrf vrf-name] [group-address]
no debug ip igmp [vrf vrf-name] [group-address]
Syntax Description vrf (Optional) Supports the multicast Virtual Private Network (VPN) routing
and forwarding (VRF) instance.
vrf-name (Optional) Name assigned to the VRF.
group-address (Optional) Address of a particular group about which to display IGMP
information.

12.1(3)T Fields were added to the output of this command to support the Source
Specific Multicast (SSM) feature.
12.0(23)S The vrf keyword and vrf-name argument were added.
12.2(13)T The vrf keyword and vrf-name argument were added.
12.3(2)T Fields were added to the output of this command to support the SSM
Mapping feature. The group-address attribute was added.
12.2(18)SXD3 This command was integrated into Cisco IOS Release 12.2(18)SXD3.
Usage Guidelines This command helps discover whether the IGMP processes are functioning. In general, if IGMP is not
working, the router process never discovers that another host is on the network that is configured to
receive multicast packets. In dense mode, this situation will result in packets being delivered
intermittently (a few every 3 minutes). In sparse mode, packets will never be delivered.
Use this command in conjunction with the debug ip pim and debug ip mrouting commands to observe
additional multicast activity and to learn the status of the multicast routing process, or why packets are
forwarded out of particular interfaces.

May 2008 DB-1005
Debug Commands
debug ip igmp
When SSM mapping is enabled, a debug message is displayed to indicate that the router is converting an
IGMP version 2 report from the group (G) into an IGMP version 3 join. After SSM mapping has
generated the appropriate IGMP version 3 report, any debug output that follows is seen as if the router
had received the same IGMP version 3 report directly.
Examples The following is sample output from the debug ip igmp command:
Router# debug ip igmp
IGMP: Received Host-Query from 172.16.37.33 (Ethernet1)

IGMP: Received Host-Report from 172.16.37.192 (Ethernet1) for 224.0.255.1
The messages displayed by the debug ip igmp command show query and report activity received from
other routers and multicast group addresses.
The following is sample output from the debug ip igmp command when SSM is enabled. Because IGMP
version 3 lite (IGMPv3lite) requires the host to send IGMP version 2 (IGMPv2) packets, IGMPv2 host
reports also will be displayed in response to the router IGMPv2 queries. If SSM is disabled, the word
ignored will be displayed in the debug ip igmp command output.
IGMP:Received v3-lite Report from 10.0.119.142 (Ethernet3/3), group count 1
IGMP:Received v3 Group Record from 10.0.119.142 (Ethernet3/3) for 232.10.10.10
IGMP:Update source 224.1.1.1
IGMP:Send v2 Query on Ethernet3/3 to 224.0.0.1
IGMP:Received v2 Report from 10.0.119.142 (Ethernet3/3) for 232.10.10.10
IGMP:Update source 224.1.1.1
The following is sample output from the debug ip igmp command when SSM static mapping is enabled.
The following output indicates that the router is converting an IGMP version 2 join for group (G) into
an IGMP version 3 join:
IGMP(0): Convert IGMPv2 report (*,232.1.2.3) to IGMPv3 with 2 source(s) using STATIC.
The following is sample output from the debug ip igmp command when SSM DNS-based mapping is
enabled. The following output indicates that a DNS lookup has succeeded:
IGMP(0): Convert IGMPv2 report (*,232.1.2.3) to IGMPv3 with 2 source(s) using DNS.
The following is sample output from the debug ip igmp command when SSM DNS-based mapping is
enabled and a DNS lookup has failed:
IGMP(0): DNS source lookup failed for (*, 232.1.2.3), IGMPv2 report failed

debug ip mrm Displays MRM control packet activity.
debug ip mrouting Displays changes to the mroute table.
debug ip pim Displays PIM packets received and sent and PIM-related events.

DB-1006 May 2008
Debug Commands
debug ip igrp events

To display summary information on Interior Gateway Routing Protocol (IGRP) routing messages that
indicate the source and destination of each update, and the number of routes in each update, use the
debug ip igrp events command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug ip igrp events [ip-address]
no debug ip igrp events [ip-address]
Syntax Description ip-address (Optional) The IP address of an IGRP neighbor.
Usage Guidelines If the IP address of an IGRP neighbor is specified, the resulting debug ip igrp events output includes
messages describing updates from that neighbor and updates that the router broadcasts toward that
neighbor. Messages are not generated for each route.
This command is particularly useful when there are many networks in your routing table. In this case,
using debug ip igrp transactions could flood the console and make the router unusable. Use debug ip
igrp events instead to display summary routing information.
Examples The following is sample output from the debug ip igrp events command:
router# debug ip igrp events
Updates sent IGRP: sending update to 255.255.255.255 via Ethernet1 (160.89.33.8)

to these two IGRP: Update contains 26 interior, 40 system, and 3 exterior routes.
destination IGRP: Total routes in update: 69
IGRP: sending update to 255.255.255.255 via Ethernet0 (160.89.32.8)
addresses IGRP: Update contains 1 interior, 0 system, and 0 exterior routes.
IGRP: Total routes in update: 1
Updates IGRP: received update from 160.89.32.24 on Ethernet0
received from IGRP: Update contains 17 interior, 1 system, and 0 exterior routes.
these source IGRP: Total routes in update: 18
IGRP: received update from 160.89.32.7 on Ethernet0
addresses S2548
IGRP: Update contains 5 interior, 1 system, and 0 exterior routes.

May 2008 DB-1007
Debug Commands
This shows that the router has sent two updates to the broadcast address 255.255.255.255. The router
also received two updates. Three lines of output describe each of these updates.
The first line indicates whether the router sent or received the update packet, the source or destination
address, and the interface through which the update was sent or received. If the update was sent, the IP
address assigned to this interface is shown (in parentheses).
IGRP: sending update to 255.255.255.255 via Ethernet1 (160.89.33.8)
The second line summarizes the number and types of routes described in the update:
IGRP: Update contains 26 interior, 40 system, and 3 exterior routes.
The third line indicates the total number of routes described in the update:

DB-1008 May 2008
Debug Commands
debug ip igrp transactions

To display transaction information on Interior Gateway Routing Protocol (IGRP) routing transactions,
use the debug ip igrp transactions command in privileged EXEC mode. To disable debugging output,
debug ip igrp transactions [ip-address]
no debug ip igrp transactions [ip-address]
Syntax Description ip-address (Optional) The IP address of an IGRP neighbor.
Usage Guidelines If the IP address of an IGRP neighbor is specified, the resulting debug ip igrp transactions output
includes messages describing updates from that neighbor and updates that the router broadcasts toward
that neighbor.
When many networks are in your routing table, the debug ip igrp transactions command can flood the
console and make the router unusable. In this case, use the debug ip igrp events command instead to
display summary routing information.
Examples The following is sample output from the debug ip igrp transactions command:
Router# debug ip igrp transactions
Updates IGRP: received update from 160.89.80.240 on Ethernet

received from subnet 160.89.66.0, metric 1300 (neighbor 1200)
these two subnet 160.89.56.0, metric 8676 (neighbor 8576)
source subnet 160.89.48.0, metric 1200 (neighbor 1100)
addresses subnet 160.89.50.0, metric 1300 (neighbor 1200)
subnet 160.89.40.0, metric 8676 (neighbor 8576)
network 192.82.152.0, metric 158550 (neighbor 158450)
network 192.68.151.0, metric 1115511 (neighbor 1115411)
network 150.136.0.0, metric 16777215 (inaccessible)
exterior network 129.140.0.0, metric 9676 (neighbor 9576)
exterior network 140.222.0.0, metric 9676 (neighbor 9576)
IGRP: received update from 160.89.80.28 on Ethernet
Updates sent subnet 160.89.15.0, metric 16777215 (inaccessible)
to these two IGRP: sending update to 255.255.255.255 via Ethernet0 (160.89.64.31)
subnet 160.89.94.0, metric=847
destination
IGRP: sending update to 255.255.255.255 via Serial1 (160.89.94.31)
addresses subnet 160.89.80.0, metric=16777215
240853
subnet 160.89.64.0, metric=1100

May 2008 DB-1009
Debug Commands
The output shows that the router being debugged has received updates from two other routers on the
network. The router at source address 160.89.80.240 sent information about ten destinations in the
update; the router at source address 160.89.80.28 sent information about three destinations in its update.
The router being debugged also sent updatesin both cases to the broadcast address 255.255.255.255
as the destination address.
On the second line the first field refers to the type of destination information: subnet (interior),
network (system), or exterior (exterior). The second field is the Internet address of the destination
network. The third field is the metric stored in the routing table and the metric advertised by the neighbor
sending the information. Metric... inaccessible usually means that the neighbor router has put the
destination in a hold down state.
The entries show that the router is sending updates that are similar, except that the numbers in
parentheses are the source addresses used in the IP header. A metric of 16777215 is inaccessible.
Other examples of output that the debug ip igrp transactions command can produce follow.
The following entry indicates that the routing table was updated and shows the new edition number (97
in this case) to be used in the next IGRP update:
IGRP: edition is now 97
Entries such as the following occur on startup or when some event occurs such as an interface making a
transition or a user manually clearing the routing table:
IGRP: broadcasting request on Ethernet0
IGRP: broadcasting request on Ethernet1
The following type of entry can result when routing updates become corrupted between sending and
receiving routers:
IGRP: bad checksum from 172.69.64.43
An entry such as the following should never appear. If it does, the receiving router has a bug in the
software or a problem with the hardware. In either case, contact your technical support representative.
IGRP: system 45 from 172.69.64.234, should be system 109

DB-1010 May 2008
Debug Commands
debug ip inspect ha
debug ip inspect ha
To display messages about Cisco IOS stateful failover high availability (HA) events, use the debug ip
inspect ha command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug ip inspect ha [manager | packet | update]
no debug ip inspect ha [manager | packet | update]
Syntax Description manager (Optional) Displays detailed messages for interaction of firewall HA manager
with the box-to-box high availability infrastructure.
packet (Optional) Used to debug the processing of the first packet postfailover on the
new active device.
update (Optional) Used to debug the periodic update messages between the active and
standby. The Firewall HA sends periodical messages to update the standby of
the firewall sessions state on the active.

Examples The following is sample output from the debug ip inspect ha command. This example shows an add
session message and a delete session message received by the the active and standby devices:
Router# debug ip inspect ha
Active debugs -
*Apr 13 17:15:20.795: FW-HA:Send add session msg for session 2C6B820
*Apr 13 17:15:36.919: FW-HA:Send delete session msg for session 2C6B820
Standby debugs -
*Apr 13 17:19:00.471: FW-HA:Received add session message
(10.0.0.10:56733:0)=>(11.0.0.10:23:0)
*Apr 13 17:19:12.051: FW-HA:Received delete session message
(10.0.0.10:56733:0)=>(11.0.0.10:23:0)
The following is sample output from the debug ip inspect ha manager command. Using the manager
keyword provides a more detailed debug analysis:
Router# debug ip inspect ha manager

May 2008 DB-1011
Debug Commands
debug ip inspect ha
*Apr 13 17:23:28.995: HA Message 0:flags=0x01 len=727 FW_HA_MSG_INSERT_SESSION (1)

*Apr 13 17:23:28.995: ID: grp1
*Apr 13 17:23:28.995: attr FW_HA_ATT_INITIATOR_ADDR (1) len 4
*Apr 13 17:23:28.995: 0A 00 00 0A
*Apr 13 17:23:28.995: attr FW_HA_ATT_RESPONDER_ADDR (2) len 4
*Apr 13 17:23:28.995: 0B 00 00 0A
*Apr 13 17:23:28.995: attr FW_HA_ATT_INITIATOR_PORT (3) len 2
*Apr 13 17:23:28.995: BF 1C
*Apr 13 17:23:28.995: attr FW_HA_ATT_RESPONDER_PORT (4) len 2
*Apr 13 17:23:28.995: 00 17
*Apr 13 17:23:28.995: attr FW_HA_ATT_L4_PROTOCOL (5) len 4
*Apr 13 17:23:28.995: 00 00 00 01
*Apr 13 17:23:28.995: attr FW_HA_ATT_SRC_TABLEID (6) len 1
*Apr 13 17:23:28.995: 00
*Apr 13 17:23:28.995: attr FW_HA_ATT_DST_TABLEID (7) len 1
*Apr 13 17:23:28.995: 00
*Apr 13 17:23:28.995: attr FW_HA_ATT_R_RCVNXT (20) len 4
*Apr 13 17:23:28.995: 79 EA E2 9A
*Apr 13 17:23:28.995: attr FW_HA_ATT_R_SNDNXT (21) len 4
*Apr 13 17:23:28.995: 6C 7D E4 04
*Apr 13 17:23:28.995: attr FW_HA_ATT_R_RCVWND (22) len 4
*Apr 13 17:23:28.995: 00 00 10 20
*Apr 13 17:23:28.995: attr FW_HA_ATT_R_LAST_SEQ_TO_SND (23) len 4
*Apr 13 17:23:28.995: 00 00 00 00
*Apr 13 17:23:28.995: attr FW_HA_ATT_I_RCVNXT (24) len 4
*Apr 13 17:23:28.995: 6C 7D E4 04
*Apr 13 17:23:28.995: attr FW_HA_ATT_I_SNDNXT (25) len 4
*Apr 13 17:23:28.995: 79 EA E2 9A
*Apr 13 17:23:28.995: attr FW_HA_ATT_I_RCVWND (26) len 4
*Apr 13 17:23:28.995: 00 00 10 20
*Apr 13 17:23:28.995: attr FW_HA_ATT_I_LAST_SEQ_TO_SND (27) len 4
*Apr 13 17:23:28.995: 00 00 00 00
*Apr 13 17:23:28.995: attr FW_HA_ATT_TCP_STATE (28) len 4
*Apr 13 17:23:28.995: 00 00 00 04
*Apr 13 17:23:28.995: attr FW_HA_ATT_INITIATOR_ALT_ADDR (8) len 4
*Apr 13 17:23:28.995: 0A 00 00 0A
*Apr 13 17:23:28.995: attr FW_HA_ATT_RESPONDER_ALT_ADDR (9) len 4
*Apr 13 17:23:28.995: 0B 00 00 0A
*Apr 13 17:23:28.995: attr FW_HA_ATT_INITIATOR_ALT_PORT (10) len 2
*Apr 13 17:23:28.995: BF 1C
*Apr 13 17:23:28.995: attr FW_HA_ATT_RESPONDER_ALT_PORT (11) len 2
*Apr 13 17:23:28.995: 00 00
*Apr 13 17:23:28.995: attr FW_HA_ATT_L7_PROTOCOL (12) len 4
*Apr 13 17:23:28.995: 00 00 00 05
*Apr 13 17:23:28.995: attr FW_HA_ATT_INSP_DIR (13) len 4
*Apr 13 17:23:28.995: 00 00 00 01
*Apr 13 17:23:28.995: attr FW_HA_ATT_I_ISN (29) len 4
*Apr 13 17:23:28.995: 79 EA E2 99
*Apr 13 17:23:28.995: attr FW_HA_ATT_R_ISN (30) len 4
*Apr 13 17:23:28.995: 6C 7D E4 03
*Apr 13 17:23:28.995: attr FW_HA_ATT_APPL_INSP_FLAGS (15) len 2
*Apr 13 17:23:28.995: 00 10
*Apr 13 17:23:28.995: attr FW_HA_ATT_TERM_FLAGS (16) len 1
*Apr 13 17:23:28.995: 00
*Apr 13 17:23:28.995: attr FW_HA_ATT_IS_LOCAL_TRAFFIC (17) len 1
*Apr 13 17:23:28.995: 00
*Apr 13 17:23:28.995: attr FW_HA_ATT_DATA_DIR (18) len 4
*Apr 13 17:23:28.995: 00 00 00 00
*Apr 13 17:23:28.995: attr FW_HA_ATT_SESSION_LIMITING_DONE (19) len 1
*Apr 13 17:23:28.995: 00
*Apr 13 17:23:28.995: attr FW_HA_ATT_INSPECT_RULE (14) len 256
*Apr 13 17:23:28.995: 74 65 73 74 00 00 00 00

DB-1012 May 2008
Debug Commands
debug ip inspect L2-transparent

To enable debugging messages for transparent firewall events, use the debug ip inspect L2-transparent
command in privileged EXEC mode. To disable debugging messages, use the no form of this command.
debug ip inspect L2-transparent {packet | dhcp-passthrough}
no debug ip inspect L2-transparent {packet | dhcp-passthrough}
Syntax Description packet Displays messages for all debug packets that are inspected by the transparent
firewall.
Note Only IP packets (TCP, User Datagram Protocol [UDP], and Internet
Control Management Protocol [ICMP]) are subjected to inspection
by the transparent firewall.
dhcp-passthrough Displays debug messages only for DHCP pass-through traffic that the
transparent firewall forwards across the bridge.
To allow a transparent firewall to forward DHCP pass-through traffic, use the
ip inspect L2-transparent dhcp-passthrough command.

Usage Guidelines The debug ip inspect L2-transparent command can be used to help verify and troubleshoot transparent
firewall-related configurations, such as a Telnet connection from the client to the server with inspection
configured.
Examples The following example shows how the transparent firewall debug command works in a basic transparent
firewall configuration. (Note that each debug message is preceded by an asterisk (*).)
! Enable debug commands.
Router# debug ip inspect L2-transparent packet
INSPECT L2 firewall debugging is on
Router# debug ip inspect object-creation

INSPECT Object Creations debugging is on
Router# debug ip inspect object-deletion

INSPECT Object Deletions debugging is on
! Start the transparent firewall configuration process
Router# config terminal

May 2008 DB-1013
Debug Commands

! Configure bridging
Router(config)# bridge 1 protocol ieee

Router(config)# bridge irb
Router(config)# bridge 1 route ip
Router(config)# interface bvi1
*Mar 1 00:06:42.511:%LINK-3-UPDOWN:Interface BVI1, changed state to down.

! Configure inspection
Router(config)# ip inspect name test tcp

! Following debugs show the memory allocated for CBAC rules.
*Mar 1 00:07:21.127:CBAC OBJ_CREATE:create irc 817F04F0 (test)
*Mar 1 00:07:21.127:CBAC OBJ_CREATE:create irt 818AED20 Protocol:tcp Inactivity time:0
test
Router(config)# ip inspect name test icmp

Router(config)#
*Mar 1 00:07:39.211:CBAC OBJ_CREATE:create irt 818AEDCC Protocol:icmp Inactivity time:0
! Configure Bridging on ethernet0 interface
Router(config)# interface ethernet0
Router(config-if)# bridge-group 1
*Mar 1 00:07:49.071:%LINK-3-UPDOWN:Interface BVI1, changed state to up
*Mar 1 00:07:50.071:%LINEPROTO-5-UPDOWN:Line protocol on Interface BVI1, changed state to
up
! Configure inspection on ethernet0 interface
Router(config-if)# ip inspect test in

Router(config-if)#
*Mar 1 00:07:57.543:CBAC OBJ_CREATE:create idbsb 8189CBFC (Ethernet0)
! Incremented the number of bridging interfaces configured for inspection */

*Mar 1 00:07:57.543:L2FW:Incrementing L2FW i/f count
Router(config-if)# interface ethernet1

! Configure bridging and ACL on interface ethernet1
Router(config-if)# bridge-group 1
Router(config-if)# ip access-group 101 in
*Mar 1 00:08:26.711:%LINEPROTO-5-UPDOWN:Line protocol on Interface Ethernet1, changed
state to up
Router(config-if)# end

ip inspect L2-transparent dhcp-passthrough Allows a transparent firewall to forward DHCP
pass-through traffic.

DB-1014 May 2008
Debug Commands
debug ip inspect
debug ip inspect
To display messages about Cisco IOS Firewall events, use the debug ip inspect command in privileged
debug ip inspect {function-trace | object-creation | object-deletion | events | timers | protocol |

detailed | update}
Firewall MIB Statistics Syntax
debug ip inspect mib {object-creation | object-deletion | events | retrieval | update}
no debug ip inspect
Syntax Description mib (Optional) Displays messages about MIB functionality.

function-trace Displays messages about software functions called by the Cisco IOS Firewall.
object-creation Displays messages about software objects being created by the Cisco IOS
Firewall. Object creation corresponds to the beginning of Cisco IOS
Firewall-inspected sessions.
object-deletion Displays messages about software objects being deleted by the Cisco IOS
Firewall. Object deletion corresponds to the closing of Cisco IOS
Firewall-inspected sessions.
events Displays messages about Cisco IOS Firewall software events, including
information about Cisco IOS Firewall packet processing or MIB special
events.
timers Displays messages about Cisco IOS Firewall timer events such as when the
Cisco IOS Firewall idle timeout is reached.
protocol Displays messages about Cisco IOS Firewall-inspected protocol events,
including details about the packets of the protocol. Table 140 provides a list
of protocol keywords.
detailed Displays detailed information to be displayed for all the other enabled
Cisco IOS Firewall debugging. Use this form of the command in conjunction
with other Cisco IOS Firewall debug commands.
retrieval Displays messages of statistics requested via Simple Network Management
Protocol (SNMP) or command-line interface (CLI).
update Displays messages about Cisco IOS Firewall software updates or updates to
MIB counters.
Table 140 Protocol Keywords for the debug ip inspect Command
Application Protocol Protocol Keyword

Transport-layer protocols
ICMP icmp
TCP tcp
User Datagram Protocol (UDP) udp

May 2008 DB-1015
Debug Commands
debug ip inspect
Table 140 Protocol Keywords for the debug ip inspect Command (continued)
Application Protocol Protocol Keyword

Application-layer protocols
CU-SeeMe cuseeme
FTP commands and responses ftp-cmd
FTP tokens (enables tracing of the FTP tokens ftp-tokens
parsed)
H.323 (version 1 and version 2) h323
HTTP http
IMAP imap
Microsoft NetShow netshow
POP3 pop3
RealAudio realaudio
Remote procedure call (RPC) rpc
Real Time Streaming Protocol (RTSP) rtsp
Session Initiation Protocol (SIP) sip
Simple Mail Transfer Protocol (SMTP) smtp
Skinny Client Control Protocol (SCCP) skinny
Structured Query Language*Net (SQL*Net) sqlnet
StreamWorks streamworks
TFTP tftp
UNIX r-commands (rlogin, rexec, rsh) rcmd
VDOLive vdolive

11.2 P This command was introduced.
12.0(5)T NetShow support was added.
12.0(7)T H.323 V2 and RTSP protocol support were added.
12.2(11)YU Support for the ICMP and SIP protocols was added.
12.3(1) Support for the skinny protocol was added.
12.3(14)T Support for the IMAP and POP3 protocols was added.
12.4(6)T The MIB syntax was added.

DB-1016 May 2008
Debug Commands
debug ip inspect
11.2 P This command was introduced.
Examples The following is sample output from the debug ip inspect function-trace command:
Router# debug ip inspect function-trace
*Mar 2 01:16:16: CBAC FUNC: insp_inspection

*Mar 2 01:16:16: CBAC FUNC: insp_pre_process_sync
*Mar 2 01:16:16: CBAC FUNC: insp_find_tcp_host_entry addr 40.0.0.1 bucket 41
*Mar 2 01:16:16: CBAC FUNC: insp_find_pregen_session
*Mar 2 01:16:16: CBAC FUNC: insp_get_idbsb
*Mar 2 01:16:16: CBAC FUNC: insp_get_irc_of_idb
*Mar 2 01:16:16: CBAC FUNC: insp_create_sis
*Mar 2 01:16:16: CBAC FUNC: insp_inc_halfopen_sis
*Mar 2 01:16:16: CBAC FUNC: insp_link_session_to_hash_table
*Mar 2 01:16:16: CBAC FUNC: insp_inspect_pak
*Mar 2 01:16:16: CBAC FUNC: insp_l4_inspection
*Mar 2 01:16:16: CBAC FUNC: insp_process_tcp_seg
*Mar 2 01:16:16: CBAC FUNC: insp_listen_state
*Mar 2 01:16:16: CBAC FUNC: insp_ensure_return_traffic
*Mar 2 01:16:16: CBAC FUNC: insp_add_acl_item
*Mar 2 01:16:16: CBAC FUNC: insp_ensure_return_traffic
*Mar 2 01:16:16: CBAC FUNC: insp_add_acl_item
*Mar 2 01:16:16: CBAC FUNC: insp_process_syn_packet
*Mar 2 01:16:16: CBAC FUNC: insp_create_tcp_host_entry
*Mar 2 01:16:16: CBAC* FUNC: insp_fast_inspection
*Mar 2 01:16:16: CBAC* FUNC: insp_inspect_pak
*Mar 2 01:16:16: CBAC* FUNC: insp_l4_inspection
*Mar 2 01:16:16: CBAC* FUNC: insp_process_tcp_seg
*Mar 2 01:16:16: CBAC* FUNC: insp_synrcvd_state
*Mar 2 01:16:16: CBAC* FUNC: insp_fast_inspection
*Mar 2 01:16:16: CBAC* FUNC: insp_inspect_pak
*Mar 2 01:16:16: CBAC* FUNC: insp_l4_inspection
*Mar 2 01:16:16: CBAC* FUNC: insp_process_tcp_seg
*Mar 2 01:16:16: CBAC* FUNC: insp_synrcvd_state
*Mar 2 01:16:16: CBAC FUNC: insp_dec_halfopen_sis
*Mar 2 01:16:16: CBAC FUNC: insp_remove_sis_from_host_entry
This output shows the functions called by the Cisco IOS Firewall as a session is inspected. Entries with
an asterisk (*) after the word CBAC are entries when the fast path is used; otherwise, the process path
is used.
The following is sample output from the debug ip inspect object-creation and debug ip inspect
object-deletion commands:
*Mar 2 01:18:30: CBAC OBJ_CREATE: create pre-gen sis 25A3574

*Mar 2 01:18:30: CBAC OBJ_CREATE: create acl wrapper 25A36FC -- acl item 25A3634

May 2008 DB-1017
Debug Commands
debug ip inspect
*Mar 2 01:18:30: CBAC OBJ_CREATE: create sis 25C1CC4

*Mar 2 01:18:30: CBAC OBJ_DELETE: delete pre-gen sis 25A3574
*Mar 2 01:18:30: CBAC OBJ_CREATE: create host entry 25A3574 addr 10.0.0.1 bucket 31
*Mar 2 01:18:30: CBAC OBJ_DELETE: delete sis 25C1CC4
*Mar 2 01:18:30: CBAC OBJ_DELETE: delete create acl wrapper 25A36FC -- acl item 25A3634
*Mar 2 01:18:31: CBAC OBJ_DELETE: delete host entry 25A3574 addr 10.0.0.1
The following is sample output from the debug ip inspect object-creation, debug ip inspect
object-deletion, and debug ip inspect events commands:
Router# debug ip inspect events
*Mar 2 01:18:51: CBAC OBJ_CREATE: create pre-gen sis 25A3574

*Mar 2 01:18:51: CBAC OBJ_CREATE: create acl wrapper 25A36FC -- acl item 25A3634
*Mar 2 01:18:51: CBAC Src 10.1.0.1 Port [1:65535]
*Mar 2 01:18:51: CBAC Dst 10.0.0.1 Port [46406:46406]
*Mar 2 01:18:51: CBAC Pre-gen sis 25A3574 created: 10.1.0.1[1:65535]
30.0.0.1[46406:46406]
*Mar 2 01:18:51: CBAC OBJ_CREATE: create sis 25C1CC4
*Mar 2 01:18:51: CBAC sis 25C1CC4 initiator_addr (10.1.0.1:20) responder_addr
(30.0.0.1:46406) initiator_alt_addr (40.0.0.1:20) responder_alt_addr (10.0.0.1:46406)
*Mar 2 01:18:51: CBAC OBJ_DELETE: delete pre-gen sis 25A3574
*Mar 2 01:18:51: CBAC OBJ_CREATE: create host entry 25A3574 addr 10.0.0.1 bucket 31
*Mar 2 01:18:51: CBAC OBJ_DELETE: delete sis 25C1CC4
*Mar 2 01:18:51: CBAC OBJ_DELETE: delete create acl wrapper 25A36FC -- acl item 25A3634
*Mar 2 01:18:51: CBAC OBJ_DELETE: delete host entry 25A3574 addr 10.0.0.1
The following is sample output from the debug ip inspect timers command:
Router# debug ip inspect timers
*Mar 2 01:19:15: CBAC Timer Init Leaf: Pre-gen sis 25A3574

*Mar 2 01:19:15: CBAC Timer Start: Pre-gen sis 25A3574 Timer: 25A35D8 Time: 30000
milisecs
*Mar 2 01:19:15: CBAC Timer Init Leaf: sis 25C1CC4
*Mar 2 01:19:15: CBAC Timer Stop: Pre-gen sis 25A3574 Timer: 25A35D8
*Mar 2 01:19:15: CBAC Timer Start: sis 25C1CC4 Timer: 25C1D5C Time: 30000 milisecs
*Mar 2 01:19:15: CBAC Timer Stop: sis 25C1CC4 Timer: 25C1D5C
The following is sample output from the debug ip inspect tcp command:
Router# debug ip inspect tcp
*Mar 2 01:20:43: CBAC* sis 25A3604 pak 2541C58 TCP P ack 4223720032 seq 4200176225(22)
(10.0.0.1:46409) => (10.1.0.1:21)
*Mar 2 01:20:43: CBAC* sis 25A3604 ftp L7 inspect result: PROCESS-SWITCH packet
*Mar 2 01:20:43: CBAC sis 25A3604 pak 2541C58 TCP P ack 4223720032 seq 4200176225(22)
(10.0.0.1:46409) => (10.1.0.1:21)
*Mar 2 01:20:43: CBAC sis 25A3604 ftp L7 inspect result: PASS packet
*Mar 2 01:20:43: CBAC* sis 25A3604 pak 2544374 TCP P ack 4200176247 seq 4223720032(30)
(10.0.0. 1:46409) <= (10.1.0.1:21)
*Mar 2 01:20:43: CBAC* sis 25A3604 ftp L7 inspect result: PASS packet
*Mar 2 01:20:43: CBAC* sis 25A3604 pak 25412F8 TCP P ack 4223720062 seq 4200176247(15)
(10.0.0. 1:46409) => (10.1.0.1:21)
*Mar 2 01:20:43: CBAC* sis 25A3604 ftp L7 inspect result: PASS packet
*Mar 2 01:20:43: CBAC sis 25C1CC4 pak 2544734 TCP S seq 4226992037(0) (10.1.0.1:20) =>
(10.0.0.1:46411)
*Mar 2 01:20:43: CBAC* sis 25C1CC4 pak 2541E38 TCP S ack 4226992038 seq 4203405054(0)
(10.1.0.1:20) <= (10.0.0.1:46411)

DB-1018 May 2008
Debug Commands
debug ip inspect
This sample shows TCP packets being processed and lists the corresponding acknowledge (ACK) packet
numbers and sequence (SEQ) numbers. The number of data bytes in the TCP packet is shown in
parenthesesfor example, (22). For each packet shown, the addresses and port numbers are shown
separated by a colon. For example, (10.1.0.1:21) indicates an IP address of 10.1.0.1 and a TCP port
number of 21.
Entries with an asterisk (*) after the word CBAC are entries when the fast path is used; otherwise, the
process path is used.
The following is sample output from the debug ip inspect tcp and debug ip inspect detailed commands:
Router# debug ip inspect tcp
Router# debug ip inspect detailed
*Mar 2 01:20:58: CBAC* Pak 2541E38 Find session for (30.0.0.1:46409) (40.0.0.1:21) tcp
*Mar 2 01:20:58: P ack 4223720160 seq 4200176262(22)
*Mar 2 01:20:58: CBAC* Pak 2541E38 Addr:port pairs to match: (30.0.0.1:46409)
(40.0.0.1:21)
*Mar 2 01:20:58: CBAC* sis 25A3604 SIS_OPEN
*Mar 2 01:20:58: CBAC* Pak 2541E38 IP: s=30.0.0.1 (Ethernet0), d=40.0.0.1 (Ethernet1),
len 76,proto=6
*Mar 2 01:20:58: CBAC sis 25A3604 Saving State: SIS_OPEN/ESTAB iisn 4200176160 i_rcvnxt
4223720160 i_sndnxt 4200176262 i_rcvwnd 8760 risn 4223719771 r_rcvnxt 4200176262 r_sndnxt
4223720160 r_rcvwnd 8760
*Mar 2 01:20:58: CBAC* sis 25A3604 pak 2541E38 TCP P ack 4223720160 seq 4200176262(22)
(30.0.0.1:46409) => (40.0.0.1:21)
*Mar 2 01:20:58: CBAC* sis 25A3604 pak 2541E38 SIS_OPEN/ESTAB TCP seq 4200176262(22)
Flags: ACK 4223720160 PSH
*Mar 2 01:20:58: CBAC* sis 25A3604 pak 2541E38 --> SIS_OPEN/ESTAB iisn 4200176160
i_rcvnxt 4223720160 i_sndnxt 4200176284 i_rcvwnd 8760 risn 4223719771 r_rcvnxt 4200176262
r_sndnxt 4223720160 r_rcvwnd 8760
*Mar 2 01:20:58: CBAC* sis 25A3604 L4 inspect result: PASS packet 2541E38
(30.0.0.1:46409) (40.0.0.1:21) bytes 22 ftp
*Mar 2 01:20:58: CBAC sis 25A3604 Restoring State: SIS_OPEN/ESTAB iisn 4200176160
i_rcvnxt 4223
720160 i_sndnxt 4200176262 i_rcvwnd 8760 risn 4223719771 r_rcvnxt 4200176262 r_sndnxt
4223720160 r_rcvwnd 8760
*Mar 2 01:20:58: CBAC* Bump up: inspection requires the packet in the process
path(30.0.0.1) (40.0.0.1)
*Mar 2 01:20:58: CBAC Pak 2541E38 Find session for (30.0.0.1:46409) (40.0.0.1:21) tcp
*Mar 2 01:20:58: P ack 4223720160 seq 4200176262(22)
*Mar 2 01:20:58: CBAC Pak 2541E38 Addr:port pairs to match: (30.0.0.1:46409)
(40.0.0.1:21)
*Mar 2 01:20:58: CBAC sis 25A3604 SIS_OPEN
*Mar 2 01:20:58: CBAC Pak 2541E38 IP: s=30.0.0.1 (Ethernet0), d=40.0.0.1 (Ethernet1), len
76, proto=6
The following is sample output from the debug ip inspect icmp and debug ip inspect detailed
commands:
Router# debug ip inspect icmp
Router# debug ip inspect detailed
1w6d:CBAC sis 81073F0C SIS_CLOSED

1w6d:CBAC Pak 80D2E9EC IP:s=192.168.133.3 (Ethernet1), d=0.0.0.0 (Ethernet0), len 98,
proto=1
1w6d:CBAC ICMP:sis 81073F0C pak 80D2E9EC SIS_CLOSED ICMP packet (192.168.133.3:0) =>
(0.0.0.0:0) datalen 56
1w6d:CBAC ICMP:start session from 192.168.133.3
1w6d:CBAC sis 81073F0C --> SIS_OPENING (192.168.133.3:0) (0.0.0.0:0)
1w6d:CBAC sis 81073F0C L4 inspect result:PASS packet 80D2E9EC (192.168.133.3:0)
(0.0.0.0:0) bytes 56 icmp

May 2008 DB-1019
Debug Commands
debug ip inspect
1w6d:CBAC sis 81073F0C SIS_OPENING

1w6d:CBAC Pak 80E72BFC IP:s=0.0.0.0 (Ethernet0), d=192.168.133.3 (Ethernet1), len 98,
proto=1
1w6d:CBAC ICMP:sis 81073F0C pak 80E72BFC SIS_OPENING ICMP packet (192.168.133.3:0) <=
(0.0.0.0:0) datalen 56
1w6d:CBAC sis 81073F0C --> SIS_OPEN (192.168.133.3:0) (0.0.0.0:0)
1w6d:CBAC sis 81073F0C L4 inspect result:PASS packet 80E72BFC (0.0.0.0:0)
(192.168.133.3:0) bytes 56 icmp
1w6d:CBAC* sis 81073F0C SIS_OPEN
1w6d:CBAC* Pak 80D2F2C8 IP:s=192.168.133.3 (Ethernet1), d=0.0.0.0 (Ethernet0), len 98,
proto=1
1w6d:CBAC* ICMP:sis 81073F0C pak 80D2F2C8 SIS_OPEN ICMP packet (192.168.133.3:0) =>
(0.0.0.0:0) datalen 56
1w6d:CBAC* sis 81073F0C --> SIS_OPEN (192.168.133.3:0) (0.0.0.0:0)
1w6d:CBAC* sis 81073F0C L4 inspect result:PASS packet 80D2F2C8 (192.168.133.3:0)
(0.0.0.0:0) bytes 56 icmp
1w6d:CBAC* Pak 80E737CC IP:s=0.0.0.0 (Ethernet0), d=192.168.133.3 (Ethernet1), len 98,
proto=1
1w6d:CBAC* ICMP:sis 81073F0C pak 80E737CC SIS_OPEN ICMP packet (192.168.133.3:0) <=
(0.0.0.0:0) datalen 56
1w6d:CBAC* sis 81073F0C L4 inspect result:PASS packet 80E737CC (0.0.0.0:0)
(192.168.133.3:0) bytes 56 icmp
1w6d:CBAC* Pak 80F554F0 IP:s=192.168.133.3 (Ethernet1), d=0.0.0.0 (Ethernet0), len 98,
proto=1
1w6d:CBAC* ICMP:sis 81073F0C pak 80F554F0 SIS_OPEN ICMP packet (192.168.133.3:0) =>
(0.0.0.0:0) datalen 56
1w6d:CBAC* sis 81073F0C L4 inspect result:PASS packet 80F554F0 (192.168.133.3:0)
(0.0.0.0:0) bytes 56 icmp
1w6d:CBAC* Pak 80E73AC0 IP:s=0.0.0.0 (Ethernet0), d=192.168.133.3 (Ethernet1), len 98,
proto=1
1w6d:CBAC* ICMP:sis 81073F0C pak 80E73AC0 SIS_OPEN ICMP packet (192.168.133.3:0) <=
(0.0.0.0:0) datalen 56
1w6d:CBAC* sis 81073F0C L4 inspect result:PASS packet 80E73AC0 (0.0.0.0:0)
(192.168.133.3:0) bytes 56 icmp

DB-1020 May 2008
Debug Commands
debug ip ips
debug ip ips
To enable debugging messages for Cisco IOS Intrusion Prevention System (IPS), use the debug ip ips
command in privileged EXEC mode. To disable debugging messages, use the no form of this command.
debug ip ips [engine] [detailed] [service-msrpc] [service-sm]
no debug ip ips [engine] [detailed]
Syntax Description engine (Optional) Displays debugging messages only for a specific signature
engine.
detailed (Optional) Displays detailed debugging messages for the specified signature
engine or for all IPS actions.
service-msrpc (Optional) Displays debugging messages for Microsoft RPC (Remote
Procedure Call) (MSRPC) actions.
service-sm (Optional) Displays debugging messages for Microsoft SMB(Server
Message Block) actions.

12.4(15)T The service-msrpc and the service-sm keywords were added to support
Microsoft communication protocols MSRPC and SMB.
Examples The following example shows how to enable debugging messages for the Cisco IOS IPS:
Router# debug ip ips

May 2008 DB-1021
Debug Commands
debug ip mbgp dampening
debug ip mbgp dampening

To log route flap dampening activity related to multiprotocol Border Gateway Protocol (BGP), use the
debug ip mbgp dampening command in privileged EXEC mode. To disable debugging output, use the
debug ip mbgp dampening [access-list-number]
no debug ip mbgp dampening [access-list-number]
Syntax Description access-list-number (Optional) The number of an access list in the range from 1 to 99. If an
access list number is specified, debugging occurs only for the routes
permitted by the access list.
Defaults Logging for route flap dampening activity is not enabled.

11.1(20)CC This command was introduced.
Examples The following is sample output from the debug ip mbgp dampening command:
Router# debug ip mbgp dampening
BGP: charge penalty for 173.19.0.0/16 path 49 with halflife-time 15 reuse/suppress

750/2000
BGP: flapped 1 times since 00:00:00. New penalty is 1000
BGP: charge penalty for 173.19.0.0/16 path 19 49 with halflife-time 15 reuse/suppress
750/2000
BGP: flapped 1 times since 00:00:00. New penalty is 1000

DB-1022 May 2008
Debug Commands
debug ip mbgp updates

To log multiprotocol Border Gateway Protocol (BGP)-related information passed in BGP update
messages, use the debug ip mbgp updates command in privileged EXEC mode. To disable debugging
no debug ip mbgp updates
Defaults Logging for multiprotocol BGP-related information in BGP update messages is not enabled.

11.1(20)CC This command was introduced.
Examples The following is sample output from the debug ip mbgp updates command:
Router# debug ip mbgp updates
BGP: NEXT_HOP part 1 net 200.10.200.0/24, neigh 171.69.233.49, next 171.69.233.34

BGP: 171.69.233.49 send UPDATE 200.10.200.0/24, next 171.69.233.34, metric 0, path 33 34
19 49 109 65000 297 3561 6503
19 49 109 65000 297 1239 1800 3597
BGP: 171.69.233.49 rcv UPDATE about 222.2.2.0/24, next hop 171.69.233.49, path 49 109
metric 0
metric 0
metric 0
BGP: 171.69.233.49 rcv UPDATE about 1.0.0.0/8, next hop 171.69.233.49, path 49 19 metric 0
metric 0
BGP: 171.69.233.49 rcv UPDATE about 171.69.0.0/16, next hop 171.69.233.49, path 49 metric
0
BGP: 171.69.233.49 rcv UPDATE about 172.19.0.0/16, next hop 171.69.233.49, path 49 metric
0
BGP: nettable_walker 172.19.0.0/255.255.0.0 calling revise_route
BGP: revise route installing 172.19.0.0/255.255.0.0 -> 171.69.233.49

May 2008 DB-1023
Debug Commands
BGP: 171.69.233.19 computing updates, neighbor version 267099, table version 267100,
starting at 0.0.0.0
BGP: 1 updates (average = 46, maximum = 46)
BGP: 171.69.233.19 updates replicated for neighbors : 171.69.233.34, 171.69.233.49,
171.69.233.56
BGP: 171.69.233.19 1 updates enqueued (average=46, maximum=46)
BGP: 171.69.233.19 update run completed, ran for 0ms, neighbor version 267099, start
version 267100, throttled to 267100, check point net 0.0.0.0

DB-1024 May 2008
Debug Commands
debug ip mcache
debug ip mcache
To display IP multicast fast-switching events, use the debug ip mcache command in privileged EXEC
debug ip mcache [vrf vrf-name] [hostname | group-address]
no debug ip mcache [vrf vrf-name] [hostname | group-address]
Syntax Description vrf (Optional) Supports the Multicast Virtual Private Network (VPN) routing
hostname (Optional) The host name.
group-address (Optional) The group address.

Usage Guidelines Use this command when multicast fast switching appears not to be functioning.
Examples The following is sample output from the debug ip mcache command when an IP multicast route is
cleared:
Router# debug ip mcache
IP multicast fast-switching debugging is on
Router# clear ip mroute *
MRC: Build MAC header for (172.31.60.185/32, 224.2.231.173), Ethernet0

MRC: Fast-switch flag for (172.31.60.185/32, 224.2.231.173), off -> on, caller
ip_mroute_replicate-1

May 2008 DB-1025
Debug Commands
debug ip mcache
Table 141 debug ip mcache Field Descriptions
Field Description
MRC Multicast route cache.
Fast-switch flag Route is fast switched.
(172.31.60.185/32) Host route with 32 bits of mask.
off -> on State has changed.
caller ... The code function that activated the state change.

debug ip dvmrp Displays information on DVMRP packets received and
sent.
debug ip igmp Displays IGMP packets received and sent, and IGMP-host
related events.
debug ip igrp transactions Displays transaction information on IGRP routing
transactions.
debug ip sd Displays all SD announcements received.

DB-1026 May 2008
Debug Commands
debug ip mds ipc
debug ip mds ipc

To debug multicast distributed switching (MDS) interprocessor communication, that is, synchronization
between the Multicast Forwarding Information Base (MFIB) on the line card and the multicast routing
table in the Route Processor (RP), use the debug ip mds ipc command in privileged EXEC mode. To
debug ip mds ipc {event | packet}
no debug ip mds ipc {event | packet}
Syntax Description event Displays MDS events when there is a problem.

packet Displays MDS packets.
Usage Guidelines Use this command on the line card or RP.
Examples The following is sample output from the debug ip mds ipc packet command:
Router# debug ip mds ipc packet
MDFS ipc packet debugging is on

Router#
MDFS: LC sending statistics message to RP with code 0 of size 36
MDFS: LC sending window message to RP with code 36261 of size 8
MDFS: LC received IPC packet of size 60 sequence 36212
The following is sample output from the debug ip mds ipc event command:
Router# debug ip mds ipc event
MDFS: LC received invalid sequence 21 while expecting 20

May 2008 DB-1027
Debug Commands
debug ip mds mevent
debug ip mds mevent

To debug Multicast Forwarding Information Base (MFIB) route creation, route updates, and so on, use
the debug ip mds mevent command in privileged EXEC mode. To disable debugging output, use the no
debug ip mds mevent
no debug ip mds mevent
Usage Guidelines Use this command on the line card.
Examples The following is sample output from the debug ip mds mevent command:
Router# debug ip mds mevent
MDFS mroute event debugging is on

Router#clear ip mdfs for *
Router#
MDFS: Create (*, 239.255.255.255)
MDFS: Create (192.168.1.1/32, 239.255.255.255), RPF POS2/0/0
MDFS: Add OIF for mroute (192.168.1.1/239.255.255.255) on Fddi0/0/0
MDFS: Create (*, 224.2.127.254)
MDFS: Add OIF for mroute (192.168.1.1/224.2.127.254) on Fddi0/0/0

DB-1028 May 2008
Debug Commands
debug ip mds mpacket

To debug multicast distributed switching (MDS) events such as packet drops, interface drops, and
switching failures, use the debug ip mds mpacket command in privileged EXEC mode. To disable
no debug ip mds mpacket
Usage Guidelines Use this command on the line card.

May 2008 DB-1029
Debug Commands
debug ip mds process

To debug line card process level events, use the debug ip mds process command in privileged EXEC
no debug ip mds process
Usage Guidelines Use this command on the line card or Route Processor (RP).
Examples The following is sample output from the debug ip mds process command:
Router# debug ip mds process
MDFS process debugging is on

Mar 19 16:15:47.448: MDFS: RP queueing mdb message for (210.115.194.5, 224.2.127.254) to
all linecards
Mar 19 16:15:47.448: MDFS: RP queueing midb message for (210.115.194.5, 224.2.127.254) to
all linecards
Mar 19 16:15:47.628: MDFS: RP servicing low queue for LC in slot 0
Mar 19 16:15:47.628: MDFS: RP servicing low queue for LC in slot 2
all linecards
all linecards
all linecards
all linecards
all linecards
all linecards
all linecards

DB-1030 May 2008
Debug Commands
debug ip mhbeat
debug ip mhbeat
To monitor the action of the heartbeat trap, use the debug ip mhbeat command in privileged EXEC
debug ip mhbeat
no debug ip mhbeat

12.1(2)XH This command was introduced.
Examples The following is sample output from the debug ip mhbeat command.
Router# debug ip mhbeat
IP multicast heartbeat debugging is on
Router debug snmp packets
SNMP packet debugging is on
!
Router(config)# ip multicast heartbeat intervals-of 10
Dec 23 13:34:21.132: MHBEAT: ip multicast-heartbeat group 224.0.1.53 port 0

source 0.0.0.0 0.0.0.0 at-least 3 in 5 intervals-of 10 secondsd

May 2008 DB-1031
Debug Commands
debug ip mhbeat
Router#
Dec 23 13:34:23: %SYS-5-CONFIG_I: Configured from console by console
Dec 23 13:34:31.136: MHBEAT: timer ticked, t=1,i=1,c=0
Dec 23 13:35:21.135: Send SNMP Trap for missing heartbeat
Dec 23 13:35:21.135: SNMP: Queuing packet to 171.69.55.12
Dec 23 13:35:21.135: SNMP: V1 Trap, ent ciscoExperiment.2.3.1, addr 4.4.4.4, gentrap 6,
spectrap 1
ciscoIpMRouteHeartBeat.1.0 = 224.0.1.53
ciscoIpMRouteHeartBeat.2.0 = 0.0.0.0
ciscoIpMRouteHeartBeat.3.0 = 10

ip multicast heartbeat Monitors the health of multicast delivery, and alerts when the delivery
fails to meet certain parameters.

DB-1032 May 2008
Debug Commands
debug ip mobile advertise

The debug ip mobile advertise command was consolidated with the debug ip mobile command. See
the description of the debug ip mobile command in the Debug Commands chapter for more
information.
To display advertisement information, use the debug ip mobile advertise EXEC command .
no debug ip mobile advertise
Defaults No default values.
Command Modes EXEC mode

Examples The following is sample output from the debug ip mobile advertise command. Table 142 describes
significant fields shown in the display.
Router# debug ip mobile advertise
MobileIP: Agent advertisement sent out Ethernet1/2: type=16, len=10, seq=1,

lifetime=36000,
flags=0x1400(rbhFmGv-rsv-),
Care-of address: 14.0.0.31
Prefix Length ext: len=1 (8 )
Table 142 Debug IP Mobile Advertise Field Descriptions
Field Description
type Type of advertisement.
len Length of extension in bytes.
seq Sequence number of this advertisement.
lifetime Lifetime in seconds.
flags Capital letters represent bits that are set, lower case letters represent unset
bits.

May 2008 DB-1033
Debug Commands
Table 142 Debug IP Mobile Advertise Field Descriptions
Field Description
Care-of address IP address.
Prefix Length ext Number of prefix lengths advertised. This is the bits in the mask of the
interface sending this advertisement. Used for roaming detection.

DB-1034 May 2008
Debug Commands
debug ip mobile host
debug ip mobile host

The debug ip mobile host command was consolidated with the debug ip mobile command. See the
description of the debug ip mobile command in the Debug Commands chapter for more information.
Use the debug ip mobile host EXEC command to display IP mobility events.
debug ip mobile host [[access-list-number]|[nai {NAI username | username@realm}]
no debug ip mobile host [[access-list-number]|[nai {NAI username | username@realm}]
Syntax Description host (Optional) The mobile node host.

[access-list-number]
nai {NAI username | (Optional) Mobile host identified by NAI.
username@realm}

Examples The following is sample output from the debug ip mobile host command:
Router# debug ip mobile host
MobileIP: HA received registration for MN 10.0.0.6 on interface Ethernet1 using COA

14.0.0.31 HA 15.0.0.5 lifetime 30000 options sbdmgvT
MobileIP: Authenticated FA 15.0.0.31 using SPI 110 (MN 20.0.0.6)
MobileIP: Authenticated MN 11.0.0.6 using SPI 300
MobileIP: HA accepts registration from MN 11.0.0.6

MobileIP: Mobility binding for MN 11.0.0.6 updated
MobileIP: Roam timer started for MN 11.0.0.6, lifetime 30000
MobileIP: MH auth ext added (SPI 300) in reply to MN 11.0.0.6
MobileIP: HF auth ext added (SPI 220) in reply to MN 11.0.0.6
MobileIP: HA sent reply to MN 11.0.0.6

May 2008 DB-1035
Debug Commands
debug ip mobile mib
debug ip mobile mib

To display debugging messages for mobile networks, use the debug ip mobile mib command in
privileged EXEC mode. To disable, use the no form of this command.
debug ip mobile mib
no debug ip mobile mib
Defaults Disabled

Usage Guidelines This command is useful for customers deploying mobile networks functionality that need to monitor and
debug mobile router information via the Simple Network Management Protocol (SNMP).
Set operations (performed from a Network Management System) are supported for mobile network
services. While setting the values for MIBs, a set operation may fail. The debug ip mobile mib
command allows error messages explaining the failure to be displayed on the console of the home agent .
Examples The following mobile networks deployment MIB debug messages are displayed only on certain
conditions or when a certain condition fails.
Router# debug ip mobile mib
! Mobile router is not enabled

MIPMIB: Mobile Router is not enabled
! Care-of-interface can be set as transmit-only only if its a Serial interface

MIPMIB: Serial interfaces can only be set as transmit-only
! The Care of address can be configured only if foreign agent is running

MIPMIB: FA cannot be started
! Check if home agent is active

MIPMIB: HA is not enabled
! For mobile router configuration, host configuration must have been done already
MIPMIB: MN <address> is not configured

DB-1036 May 2008
Debug Commands
debug ip mobile mib
! Mobile Network does not match the existing mobile network

MIPMIB: Conflict with existing mobile networks <name>
! Mobile router present

MIPMIB: MR <address> is not configured
! Static mobile networks can be configured only for single member mobilenetgroups
MIPMIB: MR is part of group <name>, network cannot be configured
! If a binding exists for this mobile router, then delete the route for this unconfigured
! mobile network
MIBMIB: Delete static mobile net for MR
! Check if its a dynamically registered mobile network

nMIPMIB: Mobile network <address mask> is dynamically registered, cannot be removed
! Check if the mobile network has already been configured for another group
nMIPMIB: Mobile network already configured for MR
! Check if the network has been dynamically registered

nMIPMIB: Deleted dynamic mobnet <address mask> for MR <name>
! Check if the redundancy group exists

MIPMIB: Redundancy group <name> does not exist
! CCOA configuration, use primary interface address as the CCoA

MIPMIB: No IP address on this interface
! CCOA configuration, CCoA address shouldn't be the same as the Home Address
nMIPMIB: Collocated CoA is the same as the Home Address, registrations will fail

May 2008 DB-1037
Debug Commands
debug ip mobile redundancy

The debug ip mobile redundancy command was consolidated with the debug ip mobile command. See
the description of the debug ip mobile command in the Debug Commands chapter for more
information.
Use the debug ip mobile redundancy EXEC command to display IP mobility events.
no debug ip mobile redundancy

Examples The following is sample output from the debug ip mobile redundancy command:
Router# debug ip mobile redundancy
00:19:21: MobileIP: Adding MN service flags to bindupdate

00:19:21: MobileIP: Adding MN service flags 0 init registration flags 1
00:19:21: MobileIP: Adding a hared version cvse - bindupdate
00:19:21: MobileIP: HARelayBindUpdate version number 2MobileIP: MN 14.0.0.20 - sent
BindUpd to HA 11.0.0.3 HAA 11.0.0.4
00:19:21: MobileIP: HA standby maint started - cnt 1
00:19:21: MobileIP: MN 14.0.0.20 - HA rcv BindUpdAck accept from 11.0.0.3 HAA 11.0.0.4
00:19:22: MobileIP: HA standby maint started - cnt 1

DB-1038 May 2008
Debug Commands
debug ip mobile router

To display debugging messages for the mobile router, use the debug ip mobile router command in
debug ip mobile router [detail]
no debug ip mobile router [detail]
Syntax Description detail (Optional) Displays detailed mobile router debug messages.

12.2(13)T This command was enhanced to display information about the addition and
deletion of mobile networks.
Usage Guidelines The mobile router operations can be debugged. The following conditions trigger debugging messages:
Agent discovery
Registration
Mobile router state change
Routes and tunnels created or deleted
Roaming information
Debugging messages are prefixed with MobRtr and detail messages are prefixed with MobRtrX.
Examples The following is sample output from the debug ip mobile router command:
Router# debug ip mobile router
MobileRouter: New FA 27.0.0.12 coa 27.0.0.12 int Ethernet0/1 MAC 0050.50c1.c855

2w2d: MobileRouter: Register reason: isolated
2w2d: MobileRouter: Snd reg request agent 27.0.0.12 coa 27.0.0.12 home 9.0.0.1 ha 29.0.0.4
lifetime 36000 int Ethernet0/1 flag sbdmgvt cnt 0 id B496B69C.55E77974
2w2d: MobileRouter: Status Isolated -> Pending

May 2008 DB-1039
Debug Commands
The following is sample output from the debug ip mobile router detail command:
Router# debug ip mobile router detail
1d09h: MobRtr: New agent 20.0.0.2 coa 30.0.0.2 int Ethernet3/1 MAC 00b0.8e35.a055
1d09h: MobRtr: Register reason: left home
1d09h: MobRtrX: Extsize 18 add 1 delete 0
1d09h: MobRtrX: Add network 20.0.0.0/8
MobileIP: MH auth ext added (SPI 100) to HA 100.0.0.3
1d09h: MobRtr: Register to fa 20.0.0.2 coa 30.0.0.2 home 100.0.0.1 ha 100.0.0.3 life 120
int Ethernet3/1 flag sbdmgvt cnt 0 id BE804340.447F50A4
1d09h: MobRtr: Status Isolated -> Pending
1d09h: MobRtr: MN rcv accept (0) reply on Ethernet3/1 from 20.0.0.2 lifetime 120
MobileIP: MN 100.0.0.3 - authenticating HA 100.0.0.3 using SPI 100
MobileIP: MN 100.0.0.3 - authenticated HA 100.0.0.3 using SPI 100
1d09h: MobRtr: Status Pending -> Registered
1d09h: MobRtr: Add default gateway 20.0.0.2 (Ethernet3/1)
1d09h: MobRtr: Add default route via 20.0.0.2 (Ethernet3/1)

debug ip mobile Displays Mobile IP information.

DB-1040 May 2008
Debug Commands
debug ip mobile
debug ip mobile
To display IP mobility activities, use the debug ip mobile command in privileged EXEC mode.
debug ip mobile [advertise | host [access-list-number] | local-area | redundancy |

udp-tunneling]
Syntax Description advertise (Optional) Advertisement information.

host (Optional) The mobile node host.
access-list-number (Optional) The number of an IP access list.
local-area (Optional) The local area.
redundancy (Optional) Redundancy activities.
udp-tunneling (Optional) User Datagram Protocol (UDP) tunneling activities.

12.0(2)T The standby keyword was added.
12.2(8)T The standby keyword was replaced by the redundancy keyword.
12.2(13)T This command was enhanced to display information about foreign agent
reverse tunnels and the mobile networks attached to the mobile router.
12.3(8)T The udp-tunneling keyword was added and the command was enhanced to
display information about NAT traversal using UDP tunneling.
12.3(7)XJ This command was enhanced to include the Resource Management
capability.
Usage Guidelines Use the debug ip mobile redundancy command to troubleshoot redundancy problems.
No per-user debugging output is shown for mobile nodes using the network access identifier (NAI) for
the debug ip mobile host command. Debugging of specific mobile nodes using an IP address is possible
through the access list.

May 2008 DB-1041
Debug Commands
debug ip mobile
Examples The following is sample output from the debug ip mobile command when foreign agent reverse
tunneling is enabled:
MobileIP:MN 14.0.0.30 deleted from ReverseTunnelTable of Ethernet2/1(Entries 0)
The following is sample output from the debug ip mobile advertise command:
Router# debug ip mobile advertise
MobileIP: Agent advertisement sent out Ethernet1/2: type=16, len=10, seq=1,

lifetime=36000,
flags=0x1400(rbhFmGv-rsv-),
Care-of address: 68.0.0.31
Prefix Length ext: len=1 (8 )
FA Challenge value:769C808D
Table 143 debug ip mobile advertise Field Descriptions
Field Description
type Type of advertisement.
len Length of extension (in bytes).
seq Sequence number of this advertisement.
lifetime Lifetime (in seconds).
flags Capital letters represent bits that are set; lowercase letters represent unset
bits.
Care-of address IP address.
Prefix Length ext Number of prefix lengths advertised. This is the bits in the mask of the
interface sending this advertisement. Used for roaming detection.
FA Challenge value Foreign Agent challenge value (randomly generated by the foreign agent.)
The following is sample output from the debug ip mobile host command:
Router# debug ip mobile host
MobileIP: HA received registration for MN 20.0.0.6 on interface Ethernet1 using COA

68.0.0.31 HA 66.0.0.5 lifetime 30000 options sbdmgvT
MobileIP: Authenticated FA 68.0.0.31 using SPI 110 (MN 20.0.0.6)
MobileIP: Authenticated MN 20.0.0.6 using SPI 300
MobileIP: HA accepts registration from MN 20.0.0.6

MobileIP: Mobility binding for MN 20.0.0.6 updated
MobileIP: Roam timer started for MN 20.0.0.6, lifetime 30000
MobileIP: MH auth ext added (SPI 300) in reply to MN 20.0.0.6
MobileIP: HF auth ext added (SPI 220) in reply to MN 20.0.0.6
MobileIP: HA sent reply to MN 20.0.0.6
The following is sample output from the debug ip mobile redundancy command. In this example, the
active home agent receives a registration request from mobile node 20.0.0.2 and sends a binding update
to peer home agent 1.0.0.2:
MobileIP:MN 20.0.0.2 - sent BindUpd to HA 1.0.0.2 HAA 20.0.0.1
MobileIP:HA standby maint started - cnt 1
MobileIP:MN 20.0.0.2 - sent BindUpd id 3780410816 cnt 0 elapsed 0

DB-1042 May 2008
Debug Commands
debug ip mobile
adjust -0 to HA 1.0.0.2 in grp 1.0.0.10 HAA 20.0.0.1
In this example, the standby home agent receives a binding update for mobile node 20.0.0.2 sent by the
active home agent:
MobileIP:MN 20.0.0.2 - HA rcv BindUpd from 1.0.0.3 HAA 20.0.0.1
The following is sample output from the debug ip mobile udp-tunneling command and displays the
registration, authentication, and establishment of UDP tunneling of a mobile node (MN) with a foreign
agent (FA):
Dec 31 12:34:25.707: UDP: rcvd src=10.10.10.10(434),dst=10.30.30.1(434), length=54
Dec 31 12:34:25.707: MobileIP: ParseRegExt type MHAE(32) addr 2000FEEC end 2000FF02
Dec 31 12:34:25.707: MobileIP: ParseRegExt skipping 10 to next
Dec 31 12:34:25.707: MobileIP: FA rcv registration for MN 10.10.10.10 on Ethernet2/2 using
COA 10.30.30.1 HA 10.10.10.100 lifetime 65535 options sbdmg-T-identification
C1BC0D4FB01AC0D8
Dec 31 12:34:25.707: MobileIP: Ethernet2/2 glean 10.10.10.10 accepted
Dec 31 12:34:25.707: MobileIP: Registration request byte count = 74
Dec 31 12:34:25.707: MobileIP: FA queued MN 10.10.10.10 in register table
Dec 31 12:34:25.707: MobileIP: Visitor registration timer started for MN 10.10.10.10,
lifetime 120
Dec 31 12:34:25.707: MobileIP: Adding UDP Tunnel req extension
Dec 31 12:34:25.707: MobileIP: Authentication algorithm MD5 and 16 byte key
Dec 31 12:34:25.707: MobileIP: MN 10.10.10.10 FHAE added to HA 10.10.10.100 using SPI 1000
Dec 31 12:34:25.707: MobileIP: FA forwarded registration for MN 10.10.10.10 to HA
10.10.10.100
Dec 31 12:34:25.715: UDP: rcvd src=10.10.10.100(434), dst=10.30.30.1(434), length=94
Dec 31 12:34:25.715: MobileIP: ParseRegExt type NVSE(134) addr 20010B28 end 20010B6A
Dec 31 12:34:25.715: MobileIP: ParseRegExt type MN-config NVSE(14) subtype 1 (MN prefix
length) prefix length (24)
Dec 31 12:34:25.715: MobileIP: ParseRegExt type MHAE(32) addr 20010B36 end 20010B6A
Dec 31 12:34:25.715: MobileIP: ParseRegExt type UDPTUNREPE(44) addr 20010B4C end 20010B6A
Dec 31 12:34:25.715: Parsing UDP Tunnel Reply Extension - length 6
Dec 31 12:34:25.715: MobileIP: ParseRegExt type FHAE(34) addr 20010B54 end 20010B6A
Dec 31 12:34:25.715: MobileIP: FA rcv accept (0) reply for MN 10.10.10.10 on Ethernet2/3
using HA 10.10.10.100 lifetime 65535
Dec 31 12:34:25.719: MobileIP: Authenticating HA 10.10.10.100 using SPI 1000
Dec 31 12:34:25.719: MobileIP: Authenticated HA 10.10.10.100 using SPI 1000 and 16 byte
key
Dec 31 12:34:25.719: MobileIP: HA accepts UDP Tunneling
Dec 31 12:34:25.719: MobileIP: Update visitor table for MN 10.10.10.10
Dec 31 12:34:25.719: MobileIP: Enabling UDP Tunneling
Dec 31 12:34:25.719: MobileIP: Tunnel0 (MIPUDP/IP) created with src 10.30.30.1 dst
10.10.10.100
Dec 31 12:34:25.719: MobileIP: Setting up UDP Keep-Alive Timer for tunnel 10.30.30.1:0 -
10.10.10.100:0 with keep-alive 30
Dec 31 12:34:25.719: MobileIP: Starting the tunnel keep-alive timer
Dec 31 12:34:25.719: MobileIP: ARP entry for MN 10.10.10.10 using 10.10.10.10 inserted on
Ethernet2/2
Dec 31 12:34:25.719: MobileIP: FA route add 10.10.10.10 successful. Code = 0
Dec 31 12:34:25.719: MobileIP: MN 10.10.10.10 added to ReverseTunnelTable of Ethernet2/2
(Entries 1)
Dec 31 12:34:25.719: MobileIP: FA dequeued MN 10.10.10.10 from register table
Dec 31 12:34:25.719: MobileIP: MN 10.10.10.10 using 10.10.10.10 visiting on Ethernet2/2
Dec 31 12:34:25.719: MobileIP: Reply in for MN 10.10.10.10 using 10.10.10.10, accepted
Dec 31 12:34:25.719: MobileIP: registration reply byte count = 84

May 2008 DB-1043
Debug Commands
debug ip mobile
Dec 31 12:34:25.719: MobileIP: FA forwarding reply to MN 10.10.10.10 (10.10.10.10 mac

0060.70ca.f021)
Dec 31 12:34:26.095: MobileIP: agent advertisement byte count = 48
Dec 31 12:34:26.095: MobileIP: Agent advertisement sent out Ethernet2/2: type=16, len=10,
seq=55, lifetime=65535, flags=0x1580(rbhFmG-TU),
Dec 31 12:34:26.095: Care-of address: 10.30.30.1
Dec 31 12:34:26.719: MobileIP: swif coming up Tunnel0
!
Dec 31 12:34:35.719: UDP: sent src=10.30.30.1(434), dst=10.10.10.100(434)
Dec 31 12:34:35.719: UDP: rcvd src=10.10.10.100(434), dst=10.30.30.1(434), length=32d0
The following is sample output from the debug ip mobile udp-tunneling command and displays the
registration, authentication, and establishment of UDP tunneling of a MN with a home agent (HA):
Dec 31 12:34:26.167: MobileIP: ParseRegExt type UDPTUNREQE(144) addr 2001E762 end 2001E780
Dec 31 12:34:26.167: MobileIP: Parsing UDP Tunnel Request Extension - length 6
Dec 31 12:34:26.167: MobileIP: ParseRegExt type FHAE(34) addr 2001E76A end 2001E780
Dec 31 12:34:26.167: MobileIP: HA 167 rcv registration for MN 10.10.10.10 on Ethernet2/1
using HomeAddr 10.10.10.10 COA 10.30.30.1 HA 10.10.10.100 lifetime 65535 options
sbdmg-T-identification C1BC0D4FB01AC0D8
Dec 31 12:34:26.167: MobileIP: NAT detected SRC:10.10.10.50 COA: 10.30.30.1
Dec 31 12:34:26.167: MobileIP: UDP Tunnel Request accepted 10.10.10.50:434
Dec 31 12:34:26.167: MobileIP: Authenticating FA 10.30.30.1 using SPI 1000
Dec 31 12:34:26.167: MobileIP: Authentication algorithm MD5 and truncated key
Dec 31 12:34:26.167: MobileIP: Authenticated FA 10.30.30.1 using SPI 1000 and 16 byte key
Dec 31 12:34:26.167: MobileIP: Authenticating MN 10.10.10.10 using SPI 1000
Dec 31 12:34:26.167: MobileIP: Authenticated MN 10.10.10.10 using SPI 1000 and 16 byte key
Dec 31 12:34:26.167: MobileIP: Mobility binding for MN 10.10.10.10 created
Dec 31 12:34:26.167: MobileIP: NAT detected for MN 10.10.10.10. Terminating tunnel on
10.10.10.50
Dec 31 12:34:26.167: MobileIP: Tunnel0 (MIPUDP/IP) created with src 10.10.10.100 dst
10.10.10.50
Dec 31 12:34:26.167: MobileIP: Setting up UDP Keep-Alive Timer for tunnel 10.10.10.100:0 -
10.10.10.50:0 with keep-alive 30
Dec 31 12:34:26.167: MobileIP: Starting the tunnel keep-alive timer
Dec 31 12:34:26.167: MobileIP: MN 10.10.10.10 Insert route for 10.10.10.10/255.255.255.255
via gateway 10.10.10.50 on Tunnel0
Dec 31 12:34:26.167: MobileIP: MN 10.10.10.10 is now roaming
Dec 31 12:34:26.171: MobileIP: Gratuitous ARPs sent for MN 10.10.10.10 MAC 0002.fca5.bc39
Dec 31 12:34:26.171: MobileIP: Mask for address is 24
Dec 31 12:34:26.171: MobileIP: HA accepts registration from MN 10.10.10.10
Dec 31 12:34:26.171: MobileIP: Dynamic and Static Network Extension Length 0 - 0
Dec 31 12:34:26.171: MobileIP: Composed mobile network extension length:0
Dec 31 12:34:26.171: MobileIP: Added prefix length vse in reply
Dec 31 12:34:26.171: MobileIP: MN 10.10.10.10 MHAE added to MN 10.10.10.10 using SPI 1000
Dec 31 12:34:26.171: MobileIP: MN 10.10.10.10 FHAE added to FA 10.10.10.50 using SPI 1000
Dec 31 12:34:26.171: MobileIP: MN 10.10.10.10 - HA sent reply to 10.10.10.50
Dec 31 12:34:26.171: MobileIP: MN 10.10.10.10 HHAE added to HA 10.10.10.3 using SPI 1000
Dec 31 12:34:26.175: MobileIP: ParseRegExt type CVSE(38) addr 2000128C end 200012AE
Dec 31 12:34:26.175: MobileIP: ParseRegExt type HA red. version CVSE(6)
Dec 31 12:34:26.175: MobileIP: ParseRegExt type HHAE(35) addr 20001298 end 200012AE

DB-1044 May 2008
Debug Commands
debug ip mobile
Dec 31 12:34:26.175: MobileIP: Authenticating HA 10.10.10.3 using SPI 1000

Dec 31 12:34:26.175: MobileIP: Authenticated HA 10.10.10.3 using SPI 1000 and 16 byte key
Dec 31 12:34:27.167: MobileIP: swif coming up Tunnel0d0

May 2008 DB-1045
Debug Commands
debug ip mpacket
debug ip mpacket
To display IP multicast packets received and sent, use the debug ip mpacket command in privileged
debug ip mpacket [vrf vrf-name] [detail | fastswitch] [access-list] [group]
no debug ip mpacket [vrf vrf-name] [detail | fastswitch] [access-list] [group]
detail (Optional) Displays IP header information and MAC address information.
fastswitch (Optional) Displays IP packet information in the fast path.
access-list (Optional) The access list number.
group (Optional) The group name or address.
Defaults The debug ip mpacket command displays all IP multicast packets switched at the process level.

12.1(2)T The fastswitch keyword was added.
Usage Guidelines This command displays information for multicast IP packets that are forwarded from this router. Use the
access-list or group argument to limit the display to multicast packets from sources described by the
access list or a specific multicast group.
Use this command with the debug ip packet command to display additional packet information.
Note The debug ip mpacket command generates many messages. Use this command with care so that
performance on the network is not affected by the debug message traffic.

DB-1046 May 2008
Debug Commands
debug ip mpacket
Examples The following is sample output from the debug ip mpacket command:
Router# debug ip mpacket 224.2.0.1
IP: s=10.188.34.54 (Ethernet1), d=224.2.0.1 (Tunnel0), len 88, mforward

Table 144 debug ip mpacket Field Descriptions
Field Description
IP IP packet.
s=10.188.34.54 Source address of the packet.
(Ethernet1) Name of the interface that received the packet.
d=224.2.0.1 Multicast group address that is the destination for this packet.
(Tunnel0) Outgoing interface for the packet.
len 88 Number of bytes in the packet. This value will vary depending on the
application and the media.
mforward Packet has been forwarded.

debug ip dvmrp Displays information on DVMRP packets received and sent.
debug ip igmp Displays IGMP packets received and sent, and IGMP host-related events.
debug ip packet Displays general IP debugging information and IPSO security transactions.

May 2008 DB-1047
Debug Commands
debug ip mrm
debug ip mrm
To display Multicast Routing Monitor (MRM) control packet activity, use the debug ip mrm command
debug ip mrm
no debug ip mrm
Defaults Debugging for MRM is not enabled.

Examples The following is sample output from the debug ip mrm command on the different devices:
On Manager
*Feb 28 16:25:44.009: MRM: Send Beacon for group 239.1.1.1, holdtime 86100 seconds
*Feb 28 16:26:01.095: MRM: Receive Status Report from 10.1.4.2 on Ethernet0
*Feb 28 16:26:01.099: MRM: Send Status Report Ack to 10.1.4.2 for group 239.1.1.1
On Test-Sender
MRM: Receive Test-Sender Request/Local trigger from 1.1.1.1 on Ethernet0
MRM: Send TS request Ack to 1.1.1.1 for group 239.1.2.3
MRM: Send test packet src:2.2.2.2 dst:239.1.2.3 manager:1.1.1.1
On Test-Receiver
MRM: Receive Test-Receiver Request/Monitor from 1.1.1.1 on Ethernet0
MRM: Send TR request Ack to 1.1.1.1 for group 239.1.2.3
MRM: Receive Beacon from 1.1.1.1 on Ethernet0
MRM: Send Status Report to 1.1.1.1 for group 239.1.2.3
MRM: Receive Status Report Ack from 1.1.1.1 on Ethernet0

DB-1048 May 2008
Debug Commands
debug ip mrouting
debug ip mrouting
To display information about activity in the multicast route (mroute) table, use the debug ip mrouting
debug ip mrouting [vrf vrf-name] [rpf-events | timers] [group-address]
no debug ip mrouting [vrf vrf-name] [rpf-events | timers] [group-address]
Command Syntax in Cisco IOS 12.2(33)SXH and Subsequent 12.2SX Releases
debug ip mrouting [vrf vrf-name] [high-availability | rpf-events [group-address] | timers

group-address]
no debug ip mrouting [vrf vrf-name] [high-availability | rpf-events [group-address] | timers

group-address]
Syntax Description vrf vrf-name (Optional) Displays debugging information related to mroute activity
associated with the Multicast Virtual Private Network (MVPN) routing and
forwarding (MVRF) instance specified for the vrf-name argument.
high-availability (Optional) Displays high availability (HA) events associated with
supervisor engine switchovers on Catalyst 6500 series switches, in Cisco
IOS Release 12.2(33)SXH and subsequent 12.2SX releases.
rpf-events (Optional) Displays Reverse Path Forwarding (RPF) events associated with
mroutes in the mroute table.
timers (Optional) Displays timer-related events associated with mroutes in the
mroute table.
group-address (Optional) IP address or Domain Name System (DNS) name of a multicast
group. Entering a multicast group address restricts the output to only
display mroute activity associated with the multicast group address
specified for the optional group-address argument.

12.0(22)S The rpf-events keyword was added.
12.2(13)T The timers keyword, vrf keyword, and vrf-name argument were added.
12.2(14)S The timers keyword, vrf keyword, and vrf-name argument were added.
12.2(33)SXH This command was integrated into Cisco IOS Release 12.2(33)SXH. The
high-availability keyword was added in support of the PIM Triggered Joins
feature.

May 2008 DB-1049
Debug Commands
debug ip mrouting
Usage Guidelines This command indicates when the router has made changes to the mroute table. Use the debug ip pim
and debug ip mrouting commands consecutively to obtain additional multicast routing information. In
addition, use the debug ip igmp command to learn why an mroute message is being displayed.
This command generates a substantial amount of output. Use the optional group-address argument to
limit the output to a single multicast group.
In Cisco IOS 12.2(33)SXH and subsequent 12.2SX releases, the high-availability keyword was added
in support of the PIM Triggered Joins feature to monitor HA events in the event of a supervisor engine
switchover on a Catalyst 6500 series switch. The PIM Triggered Joins feature is an HA multicast
enhancement that improves the reconvergence of mroutes after a supervisor engine switchover on a
Catalyst 6500 series switch. After a service engine switchover, all instances of PIM running on the newly
active supervisor engine will modify the value of the Generation ID (GenID) that is included in PIM
hello messages sent to adjacent PIM neighbors. When an adjacent PIM neighbor receives a PIM hello
message on an interface with a new GenID, the PIM neighbor will interpret the modified GenID as an
indication that all mroutes states on that interface have been lost. A modified GenID, thus, is utilized as
a mechanism to alert all adjacent PIM neighbors that PIM forwarding on that interface has been lost,
which then triggers adjacent PIM neighbors to send PIM joins for all (*, G) and (S, G) mroute states that
use that interface as an RPF interface.
Examples The following is sample output from the debug ip mrouting command:
Router# debug ip mrouting 224.2.0.1
MRT: Delete (10.0.0.0/8, 224.2.0.1)

MRT: Delete (10.4.0.0/16, 224.2.0.1)
MRT: Delete (10.6.0.0/16, 224.2.0.1)
MRT: Delete (10.9.0.0/16, 224.2.0.1)
MRT: Delete (10.16.0.0/16, 224.2.0.1)
MRT: Create (*, 224.2.0.1), if_input NULL
MRT: Create (224.69.15.0/24, 225.2.2.4), if_input Ethernet0, RPF nbr 224.69.61.15
The following lines show that multicast IP routes were deleted from the routing table:
MRT: Delete (10.0.0.0/8, 224.2.0.1)
MRT: Delete (10.4.0.0/16, 224.2.0.1)
MRT: Delete (10.6.0.0/16, 224.2.0.1)
The (*, G) entries are generally created by receipt of an Internet Group Management Protocol (IGMP)
host report from a group member on the directly connected LAN or by a Protocol Independent Multicast
(PIM) join message (in sparse mode) that this router receives from a router that is sending joins toward
the Route Processor (RP). This router will in turn send a join toward the RP that creates the shared tree
(or RP tree).
MRT: Create (*, 224.2.0.1), if_input NULL
The following lines are an example of creating an (S, G) entry that shows that an IP multicast packet
(mpacket) was received on Ethernet interface 0. The second line shows a route being created for a source
that is on a directly connected LAN. The RPF means Reverse Path Forwarding, whereby the router
looks up the source address of the multicast packet in the unicast routing table and determines which
interface will be used to send a packet to that source.

DB-1050 May 2008
Debug Commands
debug ip mrouting

The following lines show that multicast IP routes were added to the routing table. Note the 224.0.0.0 as
the RPF, which means the route was created by a source that is directly connected to this router.
If the source is not directly connected, the neighbor address shown in these lines will be the address of
the router that forwarded the packet to this router.
The shortest path tree state maintained in routers consists of source (S), multicast address (G), outgoing
interface (OIF), and incoming interface (IIF). The forwarding information is referred to as the multicast
forwarding entry for (S, G).
An entry for a shared tree can match packets from any source for its associated group if the packets come
through the proper incoming interface as determined by the RPF lookup. Such an entry is denoted as
(*, G). A (*, G) entry keeps the same information a (S, G) entry keeps, except that it saves the rendezvous
point address in place of the source address in sparse mode or as 24.0.0.0 in dense mode.
Table 145 debug ip mrouting Field Descriptions
Field Description
MRT Multicast route table.
RPF Reverse Path Forwarding.
nbr Neighbor.

debug ip igmp Displays IGMP packets received and sent, and IGMP host-related events.
debug ip packet Displays general IP debugging information and IPSO security transactions.
debug ip pim Displays all PIM announcements received.

May 2008 DB-1051
Debug Commands
debug ip mrouting limits

To display debugging information for mroute state limiters configured on interfaces, use the debug ip
mrouting limits command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
debug ip mrouting [vrf vrf-name] limits [group-address]
no debug ip mrouting [vrf vrf-name] limits [group-address]
Syntax Description. vrf vrf-name (Optional) Logs mroute state limiter events for the Multicast Virtual Private
Network (VPN) routing and forwarding (MVRF) instance specified for the
vrf-name argument.
group-address (Optional) Hostname or IP address of a multicast group for which mroute
state limiter events are logged.

Usage Guidelines This command may generate a substantial amount of output. Use the optional group-address argument
to restrict the output to display only mroute state limiter events related to a particular multicast group.
Examples The following output is from the debug ip mrouting limits command. The output displays the following
events:
An mroute state being created and the corresponding mroute state limiter counter being increased
by the default cost of 1 on incoming Ethernet interface 1/0.
An mroute olist member being removed from the olist membership list and the corresponding
mroute limiter being decreased by the default cost of 1 on outgoing Ethernet interface 1/0.
An mroute being denied by the mroute state limiter because the maximum number of mroute states
has been reached.
An mroute state being created and the corresponding mroute state limiter counter being increased
by the cost of 2 on incoming Ethernet interface 1/0.
An mroute olist member being removed from the olist membership list and the corresponding
mroute limiter being decreased by a cost of 2 on outgoing Ethernet interface 1/0.
Router# debug ip mrouting limits

DB-1052 May 2008
Debug Commands
MRL(0): incr-ed acl rpf-list to (13 < max 32), [n:0,p:0], (main) Ethernet1/0,
(10.41.0.41, 225.30.200.60)
MRL(0): decr-ed acl out-list to (10 < max 32), [n:0,p:0], (main) Ethernet1/0, (*,
225.40.202.60)
MRL(0): Add mroute (10.43.0.43, 225.30.200.60) denied for Ethernet0/2, acl std-list, (16 =
max 16)
MRL(0): incr-ed limit-acl `rpf-list' to (12 < max 32), cost-acl 'cost-list' cost 2,
[n:0,p:0], (main) Ethernet1/0, (10.41.0.41, 225.30.200.60)
MRL(0): decr-ed limit-acl `out-list' to (8 < max 32), cost-acl 'cost-list'' cost 2,
[n:0,p:0], (main) Ethernet1/0, (*, 225.40.202.60)

clear ip multicast limit Resets exceeded counters for mroute state limiters.
ip multicast limit Configures mroute state limiters on an interface.
ip multicast limit cost Applies costs to mroutes state limiters.
show ip multicast Displays general information about IP multicast, including information
about interfaces configured for IP multicast and information about mroute
state limiters configured on interfaces.

May 2008 DB-1053
Debug Commands
debug ip msdp resets
debug ip msdp resets

To debug Multicast Source Discovery Protocol (MSDP) peer reset reasons, use the debug ip msdp resets
debug ip msdp [vrf vrf-name] resets


DB-1054 May 2008
Debug Commands
debug ip msdp
debug ip msdp
To debug Multicast Source Discovery Protocol (MSDP) activity, use the debug ip msdp command in
debug ip msdp [vrf vrf-name] [peer-address | name] [detail] [routes]
no debug ip msdp [vrf vrf-name] [peer-address | name] [detail] [routes]
peer-address | name (Optional) The peer for which debug events are logged.
detail (Optional) Provides more detailed debugging information.
routes (Optional) Displays the contents of Source-Active messages.

Examples The following is sample output from the debug ip msdp command:
Router# debug ip msdp
MSDP debugging is on
Router#
MSDP: 224.150.44.254: Received 1388-byte message from peer
MSDP: 224.150.44.254: SA TLV, len: 1388, ec: 115, RP: 172.31.3.92
MSDP: 224.150.44.254: Peer RPF check passed for 172.31.3.92, used EMBGP peer
MSDP: 224.150.44.250: Forward 1388-byte SA to peer

May 2008 DB-1055
Debug Commands
debug ip msdp

Table 146 debug ip msdp Field Descriptions
Field Description
MSDP Protocol being debugged.
224.150.44.254: IP address of the MSDP peer.
Received 1388-byte message MSDP event.
from peer

DB-1056 May 2008
Debug Commands
debug ip nat
debug ip nat
To display information about IP packets translated by the IP Network Address Translation (NAT)
feature, use the debug ip nat command in privileged EXEC mode. To disable debugging output, use the
debug ip nat [access-list | detailed | h323 | ipsec | port | pptp | route | sip | skinny | vrf | wlan-nat]
no debug ip nat [access-list | detailed | h323 | ipsec | port | pptp | route | sip | skinny | vrf |
wlan-nat]
Syntax Description access-list (Optional) Standard IP access list number. If the datagram is not permitted by
the specified access list, suppresses the related debugging output.
detailed (Optional) Displays debugging information in a detailed format.
h323 (Optional) Displays H.225, H.245, and H.323 protocol information.
ipsec (Optional) Displays IP Security (IPSec) packet information.
port (Optional) Displays port information.
pptp (Optional) Displays Point-to-Point Tunneling Protocol (PPTP) information.
route (Optional) Displays route information.
sip (Optional) Displays Session Initiation Protocol (SIP) information.
skinny (Optional) Displays debug information in a concise format.
vrf (Optional) Displays Virtual Private Network (VPN) routing and forwarding
(VRF) traffic-related information.
wlan-nat (Optional) Displays Wireless LAN information.

12.1(5)T The h323 keyword was added.
12.2(8)T The sip keyword was added.
12.2(13)T The ipsec and vrf keywords were added.
12.3(2)XE The wlan-nat keyword was added.
12.3(7)T The wlan-nat keyword was implemented in Cisco IOS Release 12.3(7)T.
12.3(11)T The output in the h323 keyword was expanded to include H.245 tunneling.

May 2008 DB-1057
Debug Commands
debug ip nat
Usage Guidelines The NAT feature reduces the need for unique, registered IP addresses. It can also save private network
administrators from needing to renumber hosts and routers that do not conform to global IP addressing.
Use the debug ip nat command to verify the operation of the NAT feature by displaying information
about each packet that the router translates. The debug ip nat detailed command generates a description
of each packet considered for translation. This command also displays information about certain errors
or exception conditions, such as the failure to allocate a global address. To display messages related to
the processing of H.225 signaling and H.245 messages, use the debug ip nat h323 command. To display
messages related to the processing of SIP messages, use the debug ip nat sip command. To display
messages related to the processing of VRF messages, use the debug ip nat vrf command.
Caution Because the debug ip nat command generates a substantial amount of output, use it only when traffic
on the IP network is low, so other activity on the system is not adversely affected.
Examples The following is sample output from the debug ip nat command. In this example, the first two lines show
the Domain Name System (DNS) request and reply debugging output. The remaining lines show
debugging output from a Telnet connection from a host on the inside of the network to a host on the
outside of the network. All Telnet packets, except for the first packet, were translated in the fast path, as
indicated by the asterisk (*).
Router# debug ip nat
NAT: s=192.168.1.95->172.31.233.209, d=172.31.2.132 [6825]

NAT: s=172.31.2.132, d=172.31.233.209->192.168.1.95 [21852]
NAT: s=192.168.1.95->172.31.233.209, d=172.31.1.161 [6826]
NAT*: s=172.31.1.161, d=172.31.233.209->192.168.1.95 [23311]
NAT*: s=192.168.1.95->172.31.233.209, d=172.31.1.161 [6827]
NAT*: s=192.168.1.95->172.31.233.209, d=172.31.1.161 [6828]
NAT*: s=172.31.1.161, d=172.31.233.209->192.168.1.95 [23313]
NAT*: s=172.31.1.161, d=172.31.233.209->192.168.1.95 [23325]
Table 147 debug ip nat Field Descriptions
Field Description
NAT Indicates that the packet is being translated by the NAT feature.
An asterisk (*) indicates that the translation is occurring in the
fast path. The first packet in a conversation always goes through
the slow path (that is, it is process switched). The remaining
packets go through the fast path if a cache entry exists.
s=192.168.1.95->172.31.233.209 Source address of the packet and how it is being translated.
d=172.31.2.132 Destination address of the packet.
[6825] IP identification number of the packet. Might be useful in the
debugging process to correlate with other packet traces from
protocol analyzers.

DB-1058 May 2008
Debug Commands
debug ip nat
The following is sample output from the debug ip nat detailed command. In this example, the first two
lines show the debugging output produced by a DNS request and reply. The remaining lines show the
debugging output from a Telnet connection from a host on the inside of the network to a host on the
outside of the network. In this example, the inside host 192.168.1.95 was assigned the global address
172.31.233.193.
Router# debug ip nat detailed
NAT: i: udp (192.168.1.95, 1493) -> (172.31.2.132, 53) [22399]

NAT: o: udp (172.31.2.132, 53) -> (172.31.233.193, 1493) [63671]
NAT*: i: tcp (192.168.1.95, 1135) -> (172.31.2.75, 23) [22400]
NAT*: o: tcp (172.31.2.75, 23) -> (172.31.233.193, 1135) [22002]
NAT*: i: tcp (192.168.1.95, 1135) -> (172.31.2.75, 23) [22401]
NAT*: i: tcp (192.168.1.95, 1135) -> (172.31.2.75, 23) [22402]
NAT*: o: tcp (172.31.2.75, 23) -> (172.31.233.193, 1135) [22060]
NAT*: o: tcp (172.31.2.75, 23) -> (172.31.233.193, 1135) [22071]
The following is sample output from the debug ip nat h323 command. In this example, an H.323 call is
established between two hosts, one host on the inside and the other host on the outside. The debugging
output displays the H.323 message names that NAT recognizes and the embedded IP addresses contained
in those messages.
Router# debug ip nat h323
NAT:H225:[0] processing a Setup message

NAT:H225:[0] found Setup sourceCallSignalling
NAT:H225:[0] fix transportAddress addr=192.168.122.50 port=11140
NAT:H225:[0] found Setup fastStart
NAT:H225:[0] Setup fastStart PDU length:18
NAT:H245:[0] processing OpenLogicalChannel message, forward channel
number 1
NAT:H245:[0] found OLC forward mediaControlChannel
NAT:H245:[0] fix TransportAddress addr=192.168.122.50 port=16517
NAT:H225:[0] Setup fastStart PDU length:29
NAT:H245:[0] Processing OpenLogicalChannel message, forward channel
number 1
NAT:H245:[0] found OLC reverse mediaChannel
NAT:H245:[0] fix Transportaddress addr=192.168.122.50 port=16516
NAT:H245:[0] found OLC reverse mediaControlChannel
NAT:H225:[1] processing an Alerting message
NAT:H225:[1] found Alerting fastStart
NAT:H225:[1] Alerting fastStart PDU length:25
number 1
NAT:H323:[0] received pak, payload_len=46
NAT:H323:[0] processed up to new_payload_len 4
NAT:H323:[0] expecting data len=42--payload_len left 42
NAT:H323:[0] try to process tpkt with len 42, payload_len left 42
NAT:H225:processing a Facility message
NAT:H225:pdu_len :31 msg_IE:28
NAT:H323:choice-value:9
NAT:H225:[0] found h245Tunneling
NAT:H225:[0] found h245Control
NAT:H225:[0] h245control PDU length:20
number 2
NAT:H245:[0] found OLC forward mediaControlChannel
NAT:H245:[0] TransportAddress addr changed 192.168.122.50->135.25.30.129
NAT:H245:[0] message changed, encoding back
NAT:H245:exit process tpkt with new_len 20
NAT:H225:message changed, encoding back

May 2008 DB-1059
Debug Commands
debug ip nat
NAT:H323:[0] processed up to new_payload_len 46

NAT:H323:[0] new pak payload len is 46
Table 148 debug ip nat h323 Field Descriptions
Field Description
H.225, H.245, and H.323 Protocol of the packet.
[0] Indicates that the packet is moving from a host outside the network
to one host inside the network.
[1] Indicates that the packet is moving from a host inside the network
to one host outside the network.
The following is sample output from the debug ip nat ipsec command:
Router# debug ip nat ipsec
5d21h:NAT:new IKE going In->Out, source addr 192.168.122.35, destination addr

192.168.22.20, initiator cookie
0x9C42065D
5d21h:NAT:IPSec:created In->Out ESP translation IL=192.168.122.35 SPI=0xAAE32A0A,
IG=192.168.22.40, OL=192.168.22.20,
OG=192.168.22.20
5d21h:NAT:IPSec:created Out->In ESP translation OG=192.168.22.20 SPI=0xA64B5BB6,
OL=192.168.22.20, IG=192.168.22.40,
IL=192.168.122.35
5d21h:NAT:new IKE going In->Out, source addr 192.168.122.20, destination addr

192.168.22.20, initiator cookie
0xC91738FF
5d21h:NAT:IPSec:created In->Out ESP translation IL=192.168.122.20 SPI=0x3E2E1B92,
IG=192.168.22.40, OL=192.168.22.20,
OG=192.168.22.20
5d21h:NAT:IPSec:Inside host (IL=192.168.122.20) trying to open an ESP connection to
Outside host (OG=192.168.22.20),
wait for Out->In reply
5d21h:NAT:IPSec:created Out->In ESP translation OG=192.168.22.20 SPI=0x1B201366,
OL=192.168.22.20, IG=192.168.22.40,
IL=192.168.122.20
The following is sample output from the debug ip nat sip command. In this example, one IP phone
registers with a Cisco SIP proxy and then calls another IP phone. The debugging output displays the SIP
messages that NAT recognizes and the embedded IP addresses contained in those messages.
Router# debug ip nat sip
NAT:SIP:[0] processing REGISTER message

NAT:SIP:[0] translated embedded address
192.168.122.3->2.2.2.2
192.168.122.3->2.2.2.2
NAT:SIP:[0] message body found
NAT:SIP:[0] found address/port in SDP body:192.168.122.20
20332
NAT:SIP:[1] processing SIP/2.0 100 Trying reply message
2.2.2.2->192.168.122.3

DB-1060 May 2008
Debug Commands
debug ip nat
NAT:SIP:[1] processing SIP/2.0 200 OK reply message

2.2.2.2->192.168.122.3
2.2.2.2->192.168.122.3
NAT:SIP:[1] processing INVITE message
2.2.2.2->192.168.122.3
NAT:SIP:[1] message body found
NAT:SIP:[1] found address/port in SDP body:192.168.22.20
Table 149 debug ip nat sip Field Descriptions
Field Description
SIP Protocol of the packet.
[0] Indicates that the packet is moving from a host outside the network
to one host inside the network.
[1] Indicates that the packet is moving from a host inside the network
to one host outside the network.
The following is sample output from the debug ip nat vrf command:
Router# debug ip nat vrf
6d00h:NAT:address not stolen for 192.168.121.113, proto 1 port 7224

6d00h:NAT:creating portlist proto 1 globaladdr 2.2.2.10
6d00h:NAT:Allocated Port for 192.168.121.113 -> 2.2.2.10:wanted 7224 got 7224
6d00h:NAT:i:icmp (192.168.121.113, 7224) -> (168.58.88.2, 7224) [2460]
6d00h:NAT:s=192.168.121.113->2.2.2.10, d=168.58.88.2 [2460] vrf=> shop
6d00h:NAT*:o:icmp (168.58.88.2, 7224) -> (2.2.2.10, 7224) [2460] vrf=> shop

6d00h:NAT*:s=168.58.88.2, d=2.2.2.10->192.168.121.113 [2460] vrf=> shop

6d00h:NAT:i:icmp (192.168.121.113, 7225) -> (168.58.88.2, 7225) [2461]
6d00h:NAT:s=192.168.121.113->2.2.2.10, d=168.58.88.2 [2461] vrf=> shop
6d00h:NAT*:o:icmp (168.58.88.2, 7225) -> (2.2.2.10, 7225) [2461] vrf=> shop
6d00h:NAT*:s=168.58.88.2, d=2.2.2.10->192.168.121.113 [2461] vrf=> shop
6d00h:NAT:i:icmp (192.168.121.113, 7226) -> (168.58.88.2, 7226) [2462]
6d00h:NAT:s=192.168.121.113->2.2.2.10, d=168.58.88.2 [2462] vrf=> shop
Table 150 debug ip nat vrf Field Descriptions
Field Description
s=192.168.121.113->2.2.2.10 Source address of the packet and how it is being translated.

May 2008 DB-1061
Debug Commands
debug ip nat
Table 150 debug ip nat vrf Field Descriptions (continued)
Field Description
d=168.58.88.2 Destination address of the packet.
[2460] IP identification number of the packet.
vrf=> Indicates that NAT is applied to a particular VPN.
The following is sample output from the debug ip nat wlan-nat command:
Router# debug ip nat wlan-nat
WLAN-NAT: Creating secure ARP entry (10.1.1.1,0010.7bc2.9ff6)

WLAN-NAT: Triggered Acct Start for (171.1.1.10,0010.7bc2.9ff6)
WLAN-NAT: Extracting addr:171.1.1.10,input_idb:Ethernet1/2 from pak
WLAN-NAT: Saving address:171.1.1.10,input_idb:Ethernet1/2 in pak
After the WLAN-entry times out, the following debugs will be seen:
Router# debug ip nat wlan-nat
WLAN-NAT: Removing secure arp entry (10.1.1.1,0010.7bc2.9ff6)

WLAN-NAT: triggered Acct Stop for (171.1.1.10,0010.7bc2.9ff6)
Table 151 debug ip nat wlan-nat Field Descriptions
Field Description
WLAN Indicates that a wireless LAN is being translated.
NAT Indicates that the packet is being translated using NAT.

clear ip nat translation Clears dynamic NAT translations from the translation table.
ip nat Designates that traffic originating from or destined for the interface is
subject to NAT.
ip nat inside destination Enables NAT of the inside destination address.
ip nat inside source Enables NAT of the inside source address.
ip nat outside source Enables NAT of the outside source address.
ip nat pool Defines a pool of IP addresses for NAT.
ip nat service Enables a port other than the default port.
show ip nat statistics Displays NAT statistics.
show ip nat translations Displays active NAT translations.

DB-1062 May 2008
Debug Commands
debug ip ospf adj
debug ip ospf adj

To display information on Open Shortest Path First (OSPF)-related adjacency events, such as packets
being dropped due to TTL security check, use the debug ip ospf adj command in privileged EXEC
debug ip ospf adj
no debug ip ospf adj
Examples The following is sample output from the debug ip ospf adj command:
Router# debug ip ospf adj
Jan 31 00:13:05.175: OSPF: Drop packet on Serial2/0 from 2.1.1.1 with TTL: 1
Mar 27 23:15:03.175: OSPF Drop packet on OSPF_VL0 from 210.1.1.100 with TTL: 253
Information in the output includes the day and time the packet was dropped, protocol name, interface on
which packet was dropped, neighbor address and TTL hop count.

debug ip ospf events Displays information on OSPF-related events, such as adjacencies,
flooding information, designated router selection, and shortest path
first (SPF) calculation.

May 2008 DB-1063
Debug Commands
debug ip ospf database-timer rate-limit

To display when link-state advertisement (LSA) rate-limiting timers will expire, use the debug ip ospf
database-timer rate-limit command in privileged EXEC mode.
debug ip ospf database-timer rate-limit [access-list-number]
Syntax Description access-list-number (Optional) Number of the standard or expanded IP access list to apply to
the debug output. Standard IP access lists are in the range 1 to 99.
Expanded IP access lists are in the range 1300 to 1999.

Usage Guidelines Use this command if you need to see when the timers will expire per LSA. Use an access list if you want
to limit the output.
Examples The following is sample output from the debug ip ospf database-timer rate-limit command for an
example configuration that includes the timers throttle lsa all 100 10000 45000 command. Comments
are inserted to explain the preceding output.
Router# debug ip ospf database-timer rate-limit
OSPF rate limit timer events debugging is on

*Mar 12 20:18:20.383:OSPF:Starting rate limit timer for 10.10.24.4
10.10.24.4 1 with 100ms delay
The interface is shut down, which causes OSPF to generate a new router LSA. The system starts a timer
for 100 milliseconds.
*Mar 12 20:18:20.495:OSPF:Rate limit timer is expired for 10.10.24.4
10.10.24.4 1

DB-1064 May 2008
Debug Commands
The rate limit timer is expired after 100 milliseconds (a small delta is added to the timer).
*Mar 12 20:18:20.495:OSPF:For next LSA generation - wait :10000ms next:
20000ms
*Mar 12 20:18:20.495:OSPF:Build router LSA for area 24, router ID
10.10.24.4, seq 0x80000003
The system will generate update a router LSA after the timer expires.

May 2008 DB-1065
Debug Commands
debug ip ospf events

To display information on Open Shortest Path First (OSPF)-related events, such as adjacencies, flooding
information, designated router selection, and shortest path first (SPF) calculation, use the debug ip ospf
command.
no debug ip ospf events
Examples The following is sample output from the debug ip ospf events command:
Router# debug ip ospf events
OSPF:hello with invalid timers on interface Ethernet0

hello interval received 10 configured 10
net mask received 255.255.255.0 configured 255.255.255.0
dead interval received 40 configured 30
The debug ip ospf events output shown might appear if any of the following situations occurs:
The IP subnet masks for routers on the same network do not match.
The OSPF hello interval for the router does not match that configured for a neighbor.
The OSPF dead interval for the router does not match that configured for a neighbor.
If a router configured for OSPF routing is not seeing an OSPF neighbor on an attached network, perform
the following tasks:
Make sure that both routers have been configured with the same IP mask, OSPF hello interval, and
OSPF dead interval.
Make sure that both neighbors are part of the same area type.
In the following example line, the neighbor and this router are not part of a stub area (that is, one is a
part of a transit area and the other is a part of a stub area, as explained in RFC 1247):
OSPF: hello packet with mismatched E bit

debug ip pgm host Displays information about each OSPF packet received.

DB-1066 May 2008
Debug Commands
debug ip ospf mpls traffic-eng advertisements

To print information about traffic engineering advertisements in Open Shortest Path First (OSPF) link
state advertisement (LSA) messages, use the debug ip ospf mpls traffic-eng advertisements command
no debug ip ospf mpls traffic-eng advertisements

12.0(5)ST This command was introduced.
Examples In the following example, information about traffic engineering advertisements is printed in OSPF LSA
messages:
Router# debug ip ospf mpls traffic-eng advertisements
OSPF:IGP delete router node 10.106.0.6 fragment 0 with 0 links

TE Router ID 10.106.0.6
OSPF:IGP update router node 10.110.0.10 fragment 0 with 0 links
TE Router ID 10.110.0.10
OSPF:MPLS announce router node 10.106.0.6 fragment 0 with 1 links
Link connected to Point-to-Point network
Link ID :10.110.0.10
Interface Address :10.1.0.6
Neighbor Address :10.1.0.10
Admin Metric :10
Maximum bandwidth :1250000
Maximum reservable bandwidth :625000
Number of Priority :8
Priority 0 :625000 Priority 1 :625000

May 2008 DB-1067
Debug Commands

Affinity Bit :0x0
Table 152 debug ip ospf mpls traffic-eng advertisements Field Descriptions
Field Description
Link ID Index of the link being described.
Interface Address Address of the interface.
Neighbor Address Address of the neighbor.
Admin Metric Administrative weight associated with this link.
Maximum bandwidth Bandwidth capacity of the link (kbps).
Maximum reservable bandwidth Amount of reservable bandwidth on this link.
Number of Priority Number of priority levels for which bandwidth is advertised.
Priority Bandwidth available at indicated priority level.
Affinity Bit Attribute flags of the link that are being flooded.

DB-1068 May 2008
Debug Commands
debug ip ospf nsf
debug ip ospf nsf

To display debugging messages about Open Shortest Path First (OSPF) during a Cisco nonstop
forwarding (NSF) restart, use the debug ip ospf nsf command in privileged EXEC mode. To disable the
display of debugging output, use the no form of this command.
debug ip ospf nsf [detail]
no debug ip ospf nsf [detail]
Syntax Description detail (Optional) Displays detailed debug messages.

12.2(20)S Support for the Cisco 7304 router was added.
Usage Guidelines Use the debug ip ospf nsf command to diagnose problems with OSPF link-state database (LSDB)
resynchronization and NSF operations.
Examples The following example shows that OSPF NSF events debugging is enabled:
Router# debug ip ospf nsf

nsf (OSPF) Configures NSF operations for OSPF.
show ip ospf Displays general information about OSPF routing processes.
show ip ospf neighbor Displays OSPF-neighbor information on a per-interface basis.

May 2008 DB-1069
Debug Commands
debug ip ospf packet

To display information about each Open Shortest Path First (OSPF) packet received, use the debug ip
ospf packet command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
no debug ip ospf packet
Examples The following is sample output from the debug ip ospf packet command:
Router# debug ip ospf packet
OSPF: rcv. v:2 t:1 l:48 rid:200.0.0.117

aid:0.0.0.0 chk:6AB2 aut:0 auk:
The debug ip ospf packet command produces one set of information for each packet received. The
output varies slightly depending on which authentication is used. The following is sample output from
the debug ip ospf packet command when message digest algorithm 5 (MD5) authentication is used.
Router# debug ip ospf packet
OSPF: rcv. v:2 t:1 l:48 rid:200.0.0.116

aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x0
Table 153 debug ip ospf packet Field Descriptions
Field Description
v: OSPF version.
t: OSPF packet type. Possible packet types follow:
1Hello
2Data description
3Link state request
4Link state update
5Link state acknowledgment
l: OSPF packet length in bytes.
rid: OSPF router ID.
aid: OSPF area ID.
chk: OSPF checksum.

DB-1070 May 2008
Debug Commands
Table 153 debug ip ospf packet Field Descriptions (continued)
Field Description
aut: OSPF authentication type. Possible authentication types follow:
0No authentication
1Simple password
2MD5
keyid: MD5 key ID.
seq: Sequence number.

debug ip http client Displays information on OSPF-related events, such as
adjacencies, flooding information, designated router selection,
and SPF calculation.

May 2008 DB-1071
Debug Commands
debug ip ospf rib
debug ip ospf rib

To display debugging information for Open Shortest Path First (OSPF) Version 2 routes in the global or
local Routing Information Base (RIB), use the debug ip ospf rib command in privileged EXEC mode.
To disable the debugging of OSPF Version 2 routes, use the no form of this command.
debug ip ospf rib [local | [redistribution | global [access-list-number]]] [detail]
no debug ip ospf rib [local | [redistribution | global [access-list-number]]] [detail]
Syntax Description local (Optional) Displays debugging information for OSPF Version 2 routes
in the local RIB.
redistribution (Optional) Displays debugging information about redistributed OSPF
Version 2 routes.
global (Optional) Displays debugging information for OSPF Version 2 routes
in the global RIB.
access-list-number (Optional) Number of an access list. This is a decimal number from 1
to 199 or from 1300 to 2699.
detail (Optional) Displays more detailed debug information.

Usage Guidelines You can use the output from the debug ip ospf rib command to learn about the function of the local RIB
and the interaction between the route redistribution process and the global RIB. For example, you can
learn why the routes that OSPF placed in the global RIB are not the same ones that you anticipated.
A Cisco Technical Assistance Center representative may ask you to turn on debugging using the debug
ip ospf rib command as part of troubleshooting a problem.
To monitor updates from the OSPF database to the OSPF local RIB, use the local keyword, and to
monitor updates from the OSPF database to the OSPF global RIB, use the global keyword.
It is highly recommended that you limit the debugging output to information specific to the IP prefix that
is associated with a specific access list by entering the access-list-number argument.

DB-1072 May 2008
Debug Commands
debug ip ospf rib
Examples The following is sample output from the debug ip ospf rib command with the access-list-number
argument used in order to limit the debugging output to information specific to the IP prefix that is
associated with the specific access list 1:
Router# show running-config | include access-list 1
access-list 112 permit 10.1.1.0 0.0.0.255

! access-list 1 is configured
Router# debug ip ospf rib local detail 1
*May 31 21:28:17.331: OSPF-RIB-LOCAL: Delete intra-area connected

route 192.168.130.2/255.255.255.0, area 1, dist 10, for interface
Ethernet0/0.1
*May 31 21:28:17.331: OSPF-RIB-LOCAL: Local RIB process OSPF-1
Router clear
*May 31 21:28:17.331: OSPF-RIB-LOCAL: Add intra-area connected
route 192.168.130.2/255.255.255.0, area 1, dist 10, for interface
Ethernet0/0.1
.
.
.

May 2008 DB-1073
Debug Commands
debug ip ospf spf statistic

To display statistical information while running the shortest path first (SPF) algorithm, use the debug ip
ospf spf statistic command in privileged EXEC mode. To disable the debugging output, use the no form
of this command.
no debug ip ospf spf statistic

Usage Guidelines The debug ip ospf spf statistic command displays the SPF calculation times in milliseconds, the node
count, and a time stamp.
Examples The following is sample output from the debug ip ospf spf statistic command:
Router# debug ip ospf spf statistic
00:05:59:OSPF:Begin SPF at 359.216ms, process time 60ms

00:05:59:spf_time 00:05:59.216, wait_interval 0s
00:05:59:OSPF:End SPF at 359.216ms, Total elapsed time 0ms
00:05:59:Intra: 0ms, Inter: 0ms, External: 0ms
00:05:59:R: 4, N: 2, Stubs: 1
00:05:59:SN: 1, SA: 0, X5: 1, X7: 0
00:05:59:SPF suspends: 0 intra, 1 total
Table 154 debug ip ospf spf statistic Field Descriptions
Field Description
Begin SPF at Absolute time in milliseconds when SPF is started.
process time Cumulative time since the process has been created.
spf_time Last time SPF was run or an event has happened to run SPF.

DB-1074 May 2008
Debug Commands
Table 154 debug ip ospf spf statistic Field Descriptions (continued)
Field Description
wait_interval Time waited to run SPF.
End SPF at Absolute time in milliseconds when SPF had ended.
Total elapsed time Total time take to run SPF.
Intra: Time taken to process intra-area link-state advertisements (LSAs).
Inter: Time taken to process interarea LSAs.
External: Time taken to process external LSAs.
R: Number of router LSAs.
N: Number of network LSAs.
Stubs: Number of stub links.
SN: Number of summary network LSAs.
SA: Number of summary LSAs describing autonomous system
boundary routers (ASBRs).
X5: Number of external type 5 LSAs.
X7: Number of external type 7 LSAs.
SPF suspends: intra Number of times process is suspended during intra-area SPF run.
total Total number of times process is suspended during SPF run.

May 2008 DB-1075
Debug Commands
debug ip packet
debug ip packet
To display general IP debugging information and IP security option (IPSO) security transactions, use the
debug ip packet command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
debug ip packet [access-list-number] [detail] [dump]
no debug ip packet [access-list-number]
Syntax Description access-list-number (Optional) The IP access list number that you can specify. If the
datagram is not permitted by that access list, the related debugging
output is suppressed. Standard, extended, and expanded access lists
are supported. The range of standard and extended access lists is from
1 to 199. The range of expanded access lists is from 1300 to 2699.
detail (Optional) Displays detailed IP packet debugging information. This
information includes the packet types and codes as well as source and
destination port numbers.
dump (Hidden) Displays IP packet debugging information along with raw
packet data in hexadecimal and ASCII forms. This keyword can be
enabled with individual access lists and also with the detail keyword.
Note The dump keyword is not fully supported and should be used
only in collaboration with Cisco Technical Support. See the
caution notes below, in the usage guidelines, for more
Usage Guidelines If a communication session is closing when it should not be, an end-to-end connection problem can be
the cause. The debug ip packet command is useful for analyzing the messages traveling between the
local and remote hosts. IP packet debugging captures the packets that are process switched including
received, generated and forwarded packets. IP packets that are switched in the fast path are not captured.
IPSO security transactions include messages that describe the cause of failure each time a datagram fails
a security test in the system. This information is also sent to the sending host when the router
configuration allows it.
Caution Because the debug ip packet command generates a substantial amount of output and uses a substantial
amount of system resources, this command should be used with caution in production networks. It
should only be enabled when traffic on the IP network is low, so other activity on the system is not
adversely affected. Enabling the detail and dump keywords use the highest level of system resources of
the available configuration options for this command, so a high level of caution should be applied when
enabling either of these keywords.

DB-1076 May 2008
Debug Commands
debug ip packet
Caution The dump keyword is not fully supported and should be used only in collaboration with Cisco Technical
Support. Because of the risk of using significant CPU utilization, the dump keyword is hidden from the
user and cannot be seen using the ? prompt. The length of the displayed packet information may
exceed the actual packet length and include additional padding bytes that do not belong to the IP packet.
Also note that the beginning of a packet may start at different locations in the dump output depending
on the specific router, interface type, and packet header processing that may have occurred before the
output is displayed.
Examples The following is sample output from the debug ip packet command:
Router# debug ip packet
IP packet debugging is on
IP: s=172.69.13.44 (Fddi0), d=10.125.254.1 (Serial2), g=172.69.16.2, forward

IP: s=172.69.1.57 (Ethernet4), d=10.36.125.2 (Serial2), g=172.69.16.2, forward
IP: s=172.69.1.6 (Ethernet4), d=255.255.255.255, rcvd 2
IP: s=172.69.1.55 (Ethernet4), d=172.69.2.42 (Fddi0), g=172.69.13.6, forward
IP: s=172.69.89.33 (Ethernet2), d=10.130.2.156 (Serial2), g=172.69.16.2, forward
IP: s=172.69.20.32 (Ethernet2), d=255.255.255.255, rcvd 2
IP: s=172.69.1.57 (Ethernet4), d=10.36.125.2 (Serial2), g=172.69.16.2, access denied
The output shows two types of messages that the debug ip packet command can produce; the first line
of output describes an IP packet that the router forwards, and the third line of output describes a packet
that is destined for the router. In the third line of output, rcvd 2 indicates that the router decided to receive
the packet.
Table 155 debug ip packet Field Descriptions
Field Description
IP: Indicates that this is an IP packet.
s=172.69.13.44 (Fddi0) Indicates the source address of the packet and the name of the
interface that received the packet.
d=10.125.254.1 (Serial2) Indicates the destination address of the packet and the name of the
interface (in this case, S2) through which the packet is being sent out
on the network.
g=172.69.16.2 Indicates the address of the next-hop gateway.
forward Indicates that the router is forwarding the packet. If a filter denies a
packet, access denied replaces forward, as shown in the last line
of output.
The following is sample output from the debug ip packet command enabled with the detail keyword:
Router# debug ip packet detail
IP packet debugging is on (detailed)
001556: 19:59:30: CEF: Try to CEF switch 10.4.9.151 from FastEthernet0/0

May 2008 DB-1077
Debug Commands
debug ip packet
001557: 19:59:30: IP: s=10.4.9.6 (FastEthernet0/0), d=10.4.9.151 (FastEthernet03

001558: 19:59:30: TCP src=179, dst=11001, seq=3736598846, ack=2885081910, wH
001561: 20:00:09: TCP src=179, dst=11000, seq=163035693, ack=2948141027, wiH
001564: 20:00:14: ICMP type=8, code=0
001565: 20:00:14: IP: s=10.4.9.151 (local), d=10.4.9.6 (FastEthernet0/0), len 1g
001566: 20:00:14: ICMP type=0, code=0
The format of the output with detail keyword provides additional information, such as the packet type,
code, some field values, and source and destination port numbers.
Table 156 debug ip packet detail Field Descriptions
Field Description
CEF: Indicates that the IP packet is being processed by CEF.
s=10.4.9.6 (FastEthernet0/0) Indicates the source address of the packet and the name of the
d=10.4.9.151 (FastEthernet03) Indicates the destination address of the packet and the name of the
interface through which the packet is being sent out on the network.
TCP src= Indicates the source TCP port number.
dst= Indicates the destination TCP port number.
seq= Value from the TCP packet sequence number field.
ack= Value from the TCP packet acknowledgement field.
ICMP type= Indicates ICMP packet type.
code= Indicates ICMP return code.
The following is sample output from the debug ip packet command enabled with the dump keyword:
Router# debug ip packet dump
IP packet debugging is on (detailed) (dump)
21:02:42: IP: s=10.4.9.6 (FastEthernet0/0), d=10.4.9.4 (FastEthernet0/0), len 13

07003A00: 0005 00509C08 ...P..
07003A10: 0007855B 4DC00800 45000064 001E0000 ...[M@..E..d....
07003A20: FE019669 0A040906 0A040904 0800CF7C ~..i..........O|
07003A30: 0D052678 00000000 0A0B7145 ABCDABCD ..&x......qE+M+M
07003A40: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
07003A70: ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M
21:02:42: IP: s=10.4.9.4 (local), d=10.4.9.6 (FastEthernet0/0), len 100, sending
07003A00: 0005 00509C08 ...P..
07003A10: 0007855B 4DC00800 45000064 001E0000 ...[M@..E..d....
07003A20: FF019569 0A040904 0A040906 0000D77C ...i..........W|
07003A30: 0D052678 00000000 0A0B7145 ABCDABCD ..&x......qE+M+M

DB-1078 May 2008
Debug Commands
debug ip packet
07003A70: ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M

21:02:42: CEF: Try to CEF switch 10.4.9.4 from FastEthernet0/0
21:02:42: IP: s=10.4.9.6 (FastEthernet0/0), d=10.4.9.4 (FastEthernet0/0), len 13
07003380: 0005 00509C08 ...P..
07003390: 0007855B 4DC00800 45000064 001F0000 ...[M@..E..d....
070033A0: FE019668 0A040906 0A040904 0800CF77 ~..h..........Ow
070033B0: 0D062678 00000000 0A0B7149 ABCDABCD ..&x......qI+M+M
070033C0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
070033D0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
070033E0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
070033F0: ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M
Note The dump keyword is not fully supported and should be used only in collaboration with Cisco Technical
Support. See the caution in the usage guidelines section of this command reference page for more
The output from the debug ip packet command, when the dump keyword is enabled, provides raw
packet data in hexadecimal and ASCII forms. This addtional output is displayed in addition to the
standard output. The dump keyword can be used with all of the available configuration options of this
command.
Table 157 debug ip packet dump Field Descriptions
Field Description
s=10.4.9.6 (FastEthernet0/0) Indicates the source address of the packet and the name of the
d=10.4.9.4 (FastEthernet0/0) Indicates destination address and length of the packet and the name
len 13 of the interface through which the packet is being sent out on the
network.
sending Indicates that the router is sending the packet.
The calculation on whether to send a security error message can be somewhat confusing. It depends upon
both the security label in the datagram and the label of the incoming interface. First, the label contained
in the datagram is examined for anything obviously wrong. If nothing is wrong, assume the datagram to
be correct. If something is wrong, the datagram is treated as unclassified genser. Then the label is
compared with the interface range, and the appropriate action is taken, as Table 158 describes.

May 2008 DB-1079
Debug Commands
debug ip packet
Table 158 Security Actions
Classification Authorities Action Taken

Too low Too low No Response
Good No Response
Too high No Response
In range Too low No Response
Good Accept
Too high Send Error
Too high Too low No Response
In range Send Error
Too high Send Error
The security code can only generate a few types of Internet Control Message Protocol (ICMP) error
messages. The only possible error messages and their meanings follow:
ICMP Parameter problem, code 0Error at pointer
ICMP Parameter problem, code 1Missing option
ICMP Parameter problem, code 2See Note that follows
ICMP Unreachable, code 10Administratively prohibited
Note The message ICMP Parameter problem, code 2 identifies a specific error that occurs in the processing
of a datagram. This message indicates that the router received a datagram containing a maximum length
IP header but no security option. After being processed and routed to another interface, it is discovered
that the outgoing interface is marked with add a security label. Because the IP header is already full,
the system cannot add a label and must drop the datagram and return an error message.
When an IP packet is rejected due to an IP security failure, an audit message is sent via Department of
Defense Intelligence Information System Network Security for Information Exchange (DNSIX)
Network Address Translation (NAT). Also, any debug ip packet output is appended to include a
description of the reason for rejection. This description can be any of the following:
No basic
No basic, no response
Reserved class
Reserved class, no response
Class too low, no response
Class too high
Class too high, bad authorities, no response
Unrecognized class
Unrecognized class, no response
Multiple basic

DB-1080 May 2008
Debug Commands
debug ip packet
Multiple basic, no response

Authority too low, no response
Authority too high
Compartment bits not dominated by maximum sensitivity level
Compartment bits do not dominate minimum sensitivity level
Security failure: extended security disallowed
NLESO source appeared twice
ESO source not found
Postroute, failed xfc out
No room to add IPSO

May 2008 DB-1081
Debug Commands
debug ip pgm host
debug ip pgm host

Note Support for the PGM Host feature has been removed. Use of this command is not recommended.
To display debug messages for the Pragmatic General Multicast (PGM) Host feature, use the debug ip
pgm host command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug ip pgm host [data | nak | spm]
no debug ip pgm host [data | nak | spm]
Syntax Description data (Optional) Enables debugging for PGM sent (ODATA) and re-sent
(RDATA) data packets.
nak (Optional) Enables debugging for PGM negative acknowledgment
(NAK) data packets, NAK confirmation (NCF) data packets, and
Null NAK (NNAK) data packets.
spm (Optional) Enables debugging for PGM source path messages
(SPMs).
Defaults Debugging for PGM Host is not enabled. If the debug ip pgm host command is used with no additional
keywords, debugging is enabled for all PGM Host message types.

Examples The following is sample output from the debug ip pgm host command:
Router# debug ip pgm host
Host SPM debugging is on

Host NAK/NCF debugging is on
Host ODATA/RDATA debugging is on
The following is sample output from the debug ip pgm host command when the data keyword is used:
Router# debug ip pgm host data

DB-1082 May 2008
Debug Commands
debug ip pgm host
02:50:23:PGM Host:Received ODATA from 10.0.30.2 to 224.3.3.3 (74 bytes)

02:50:23: ODATA TSI 00000A001E02-0401 data-dport BBBB csum 9317 tlen 74
02:50:23: tsqn 31 dsqn 39
The following example shows output of the debug ip pgm host command when the nak keyword is used.
In the following example, the host sends a NAK to the source for a missing packet and the source returns
an NCF to the host followed by an RDATA data packet.
Router# debug ip pgm host nak
02:50:24:PGM Host:Sending NAK from 10.0.32.2 to 10.0.32.1 (36 bytes)

02:50:24: NAK TSI 00000A001E02-0401 data-dport BBBB csum 04EC tlen 36
02:50:24: dsqn 38 data source 10.0.30.2 group 224.3.3.3
02:50:24:PGM Host:Received NCF from 10.0.30.2 to 224.3.3.3 (36 bytes)

02:50:24: NCF TSI 00000A001E02-0401 data-dport BBBB csum 02EC tlen 36
02:50:24: dsqn 38 data source 10.0.30.2 group 224.3.3.3
02:50:24:PGM Host:Received RDATA from 10.0.30.2 to 224.3.3.3 (74 bytes)

02:50:24: RDATA TSI 00000A001E02-0401 data-dport BBBB csum 9218 tlen 74
02:50:24: tsqn 31 dsqn 38
The following is sample output from the debug ip pgm host command with the spm keyword is used:
Router# debug ip pgm host spm
02:49:39:PGM Host:Received SPM from 10.0.30.2 to 224.3.3.3 (36 bytes)

02:49:39: SPM TSI 00000A001E02-0401 data-dport BBBB csum EA08 tlen 36
02:49:39: dsqn 980 tsqn 31 lsqn 31 NLA 10.0.32.1

clear ip pgm host Resets PGM Host connections to their default values and clears
traffic statistics.
ip pgm host Enables the PGM Host feature.
show ip pgm host defaults Displays the default values for PGM Host traffic.
show ip pgm host sessions Displays open PGM Host traffic sessions.
show ip pgm host traffic Displays PGM Host traffic statistics.

May 2008 DB-1083
Debug Commands
debug ip pgm router
debug ip pgm router

To display debug messages for Pragmatic General Multicast (PGM), use the debug ip pgm router
debug ip pgm router [spm | nak | data]
no debug ip pgm router [spm | nak | data]
Syntax Description spm (Optional) Enables debugging for Source Path Messages (SPMs).
nak (Optional) Enables debugging for negative acknowledgments (NAKs), NAK
confirmations (NCFs), and Null NAKs (NNAKs).
data (Optional) Enables debugging for Retransmissions (RDATA).
Defaults Debugging for PGM is not enabled. If the debug ip pgm router command is used with no additional
keywords, debugging is enabled for all PGM message types.

Examples The following shows sample output from the debug ip pgm router command:
Router# debug ip pgm router
SPM debugging is on
NAK/NNAK/NCF debugging is on
RDATA debugging is on
The following shows sample output from the debug ip pgm router command when the spm keyword is
used:
Router# debug ip pgm router spm
PGM: Received SPM on Ethernet1/0/5 from 10.7.0.200 to 227.7.7.7 (52 bytes)

SPM TSI 0A0700C85555-1000 data-dport 1001 csum CCCC tlen 52
dsqn 3758096779 tsqn 1954 isqn 1979 lsqn 1990
NLA 10.7.0.200
SPM from source/RPF-neighbour 10.7.0.200 for 10.7.0.200 (SPT)
Forwarded SPM from 10.7.0.200 to 227.7.7.7

DB-1084 May 2008
Debug Commands
debug ip pgm router
The following is a debugging message for a selective SPM:

Router# debug ip pgm router spm
PGM: Received SPM on Ethernet1/0/5 from 10.7.0.200 to 234.4.3.2 (52 bytes)

SPM TSI 0A0700C85555-2000 data-dport 2001 csum CCCC tlen 52 Options P N O
dsqn 3758096768 tsqn 1986 isqn 1994 lsqn 2006
NLA 10.7.0.200
SPM from source/RPF-neighbour 10.7.0.200 for 10.7.0.200 (SPT)
Forwarded SPM from 10.7.0.200 to 227.7.7.7
The P N O flags indicate which options are present in this packet:

P indicates that this is a parity packet.
N indicates that options are network significant.
O indicates that options are present.
The following shows sample output from the debug ip pgm router command when the nak keyword is
used:
Router# debug ip pgm router nak
PGM: Received NAK on Ethernet1/0/0 from 10.1.0.4 to 10.1.0.2 (36 bytes)

NAK TSI 0A0700C85555-1000 data-dport 1001 csum CCCC tlen 36
dsqn 1990 data source 10.7.0.200 group 227.7.7.7
NAK unicast routed to RPF neighbour 10.4.0.1
Forwarding NAK from 10.1.0.4 to 10.4.0.1 for 10.7.0.200
PGM: Received NCF on Ethernet1/0/5 from 10.7.0.200 to 227.7.7.7 (36 bytes)
NCF TSI 0A0700C85555-1000 data-dport 1001 csum CACC tlen 36
NAK retx canceled for TSI 0A0700C85555-1000 dsqn 1990
NAK elimination started for TSI 0A0700C85555-1000 dsqn 1990
PGM: Received NCF on Ethernet1/0/5 from 10.7.0.200 to 227.7.7.7 (36 bytes)
NCF TSI 0A0700C85555-1000 data-dport 1001 csum CACC tlen 36
No NAK retx outstanding for TSI 0A0700C85555-1000 dsqn 1991
NAK anticipated for TSI 0A0700C85555-1000 dsqn 1991
The following example shows output of the debug ip pgm router command with the data keyword. The
debugging message is for an RDATA packet for which the router has only anticipated state, sqn 1991.
Because it did not actually get a NAK, this RDATA is not forwarded by the PGM router.
Router# debug ip pgm router data
PGM: Received RDATA on Ethernet1/0/5 from 10.7.0.200 to 227.7.7.7 (70 bytes)

RDATA TSI 0A0700C85555-1000 data-dport 1001 csum CCCC tlen 32
tsqn 1954 dsqn 1990
Marking Ethernet1/0/0 for forwarding
Marking Serial5/0 for skipping
Forwarded RDATA from 10.7.0.200 to 227.7.7.7
Debug message for RDATA packet corresponding to a NAK for sqn

1990. Since the NAK was received on Ethernet1/0/0, RDATA is forwarded
out only that interface and another interface in the multicast olist
Serial5/0 is skipped.
PGM: Received RDATA on Ethernet1/0/5 from 10.7.0.200 to 227.7.7.7 (70 bytes)

RDATA TSI 0A0700C85555-1000 data-dport 1001 csum CCCC tlen 32
tsqn 1954 dsqn 1991
Eliminated RDATA (null oif) from 10.7.0.200 to 227.7.7.7

May 2008 DB-1085
Debug Commands
debug ip pgm router

ip pgm router Enables the PGM Router Assist feature for the interface.
show ip pgm router Displays PGM traffic statistics and TSI state.

DB-1086 May 2008
Debug Commands
debug ip pim atm
debug ip pim atm

To log Protocol Independent Multicast (PIM) ATM signalling activity, use the debug ip pim atm
debug ip pim atm
no debug ip pim atm
Examples The following sample output shows a new group being created and the router toward the rendezvous
point (RP) opening a new virtual circuit (VC). Because there are now two groups on this router, there
are two VCs open, as reflected by the current count.
The following is sample output from the debug ip pim atm command:
Router# debug ip pim atm
Jan 28 19:05:51: PIM-ATM: Max VCs 200, current count 1

Jan 28 19:05:51: PIM-ATM: Send SETUP on ATM2/0 for 239.254.254.253/171.69.214.43
Jan 28 19:05:51: PIM-ATM: Received CONNECT on ATM2/0 for 239.254.254.253, vcd 19
Jan 28 19:06:35: PIM-ATM: Max VCs 200, current count 2
Table 159 debug ip pim atm Field Descriptions
Field Description
Jan 28 19:05:51 Current date and time (in hours:minutes:seconds).
PIM-ATM Indicates what PIM is doing to set up or monitor an ATM connection
(vc).
current count Current number of open virtual circuits.
The resulting show ip mroute output follows:

Router# show ip mroute 239.254.254.253
IP Multicast Routing Table

Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.254.254.253), 00:00:04/00:02:53, RP 171.69.214.50, flags: S

Incoming interface: Ethernet1/1, RPF nbr 171.69.214.50
Outgoing interface list:
ATM2/0, VCD 19, Forward/Sparse-Dense, 00:00:04/00:02:52

May 2008 DB-1087
Debug Commands
debug ip pim auto-rp

To display the contents of each Protocol Independent Multicast (PIM) packet used in the automatic
discovery of group-to-rendezvous point (RP) mapping and the actions taken on the address-to-RP
mapping database, use the debug ip pim auto-rp command in privileged EXEC mode. To disable
debug ip pim auto-rp [vrf vrf-name]
no debug ip pim auto-rp [vrf vrf-name]

Examples The following is sample output from the debug ip pim auto-rp command:
Router# debug ip pim auto-rp
Auto-RP: Received RP-announce, from 172.16.214.66, RP_cnt 1, holdtime 180 secs

Auto-RP: update (192.168.248.0/24, RP:172.16.214.66)
Auto-RP: Build RP-Discovery packet
Auto-RP: Build mapping (192.168.248.0/24, RP:172.16.214.66),
Auto-RP: Build mapping (192.168.250.0/24, RP:172.16.214.26).
Auto-RP: Send RP-discovery packet (3 RP entries)
Auto-RP: Build RP-Announce packet for 172.16.214.2
Auto-RP: Build announce entry for (192.168.254.0/24)
Auto-RP: Send RP-Announce packet, IP source 172.16.214.2, ttl 8

DB-1088 May 2008
Debug Commands
The first two lines show a packet received from 172.16.214.66 announcing that it is the RP for the groups
in 192.168.248.0/24. This announcement contains one RP address and is valid for 180 seconds. The
RP-mapping agent then updates its mapping database to include the new information.
Auto-RP: Received RP-announce, from 172.16.214.66, RP_cnt 1, holdtime 180 secs
Auto-RP: update (192.168.248.0/24, RP:172.16.214.66)
In the next five lines, the router creates an RP-discovery packet containing three RP mapping entries.
The packet is sent to the well-known CISCO-RP-DISCOVERY group address (224.0.1.40).
Auto-RP: Build RP-Discovery packet
Auto-RP: Build mapping (192.168.248.0/24, RP:172.16.214.66),
Auto-RP: Send RP-discovery packet (3 RP entries)
The final three lines show the router announcing that it intends to be an RP for the groups in
192.168.254.0/24. Only routers inside the scope ttl 8 receive the advertisement and use the RP for
these groups.
Auto-RP: Build RP-Announce packet for 172.16.214.2
Auto-RP: Build announce entry for (192.168.254.0/24)
Auto-RP: Send RP-Announce packet, IP source 172.16.214.2, ttl 8
The following is sample output from the debug ip pim auto-rp command when a router receives an
update. In this example, the packet contains three group-to-RP mappings, which are valid for
180 seconds. The RP-mapping agent then updates its mapping database to include the new information.
Router# debug ip pim auto-rp
Auto-RP: Received RP-discovery, from 172.16.214.17, RP_cnt 3, holdtime 180 secs

Auto-RP: update (192.168.248.0/24, RP:172.16.214.66)
Auto-RP: update (192.168.250.0/24, RP:172.16.214.26)
Auto-RP: update (192.168.254.0/24, RP:172.16.214.2

May 2008 DB-1089
Debug Commands
debug ip pim
debug ip pim
To display Protocol Independent Multicast (PIM) packets received and sent, and to display PIM-related
events, use the debug ip pim command in privileged EXEC mode. To disable debugging output, use the
debug ip pim [vrf vrf-name] [group | df [rp-address]] [hello]
no debug ip pim [vrf vrf-name] [group | df [rp-address]] [hello]
Syntax Description vrf (Optional) Supports the multicast Virtual Private Network (VPN) routing
group (Optional) The group name or address to monitor the packet activity of a
single group.
df (Optional) When bidirectional PIM is used, displays all designated
forwarder (DF) election messages.
rp-address (Optional) The rendezvous point IP address.
hello (Optional) Enables you to send PIM hello messages to be sent every few
milliseconds.
Defaults All PIM packets are displayed.

12.1(2)T The df keyword was added.
12.0(22)S The vrf keyword, vrf-name argument, and hello keyword were added.
Usage Guidelines PIM uses Internet Group Management Protocol (IGMP) packets to communicate with routers and
advertise reachability information.
Use this command with the debug ip igmp and debug ip mrouting commands to display additional
multicast routing information.

DB-1090 May 2008
Debug Commands
debug ip pim
Examples The following is sample output from the debug ip pim command:
Router# debug ip pim 224.2.0.1
PIM: Received Join/Prune on Ethernet1 from 172.16.37.33

PIM: Received Join/Prune on Tunnel0 from 10.3.84.1
PIM: Received RP-Reachable on Ethernet1 from 172.16.20.31
PIM: Update RP expiration timer for 224.2.0.1
PIM: Forward RP-reachability packet for 224.2.0.1 on Tunnel0
PIM: Prune-list (10.221.196.51/32, 224.2.0.1)
PIM: Set join delay timer to 2 seconds for (10.221.0.0/16, 224.2.0.1) on Ethernet1
PIM: Received Join/Prune on Tunnel0 from 10.3.84.1
PIM: Join-list: (*, 224.2.0.1) RP 172.16.20.31
PIM: Add Tunnel0 to (*, 224.2.0.1), Forward state
PIM: Join-list: (10.0.0.0/8, 224.2.0.1)
PIM: Add Tunnel0 to (10.0.0.0/8, 224.2.0.1), Forward state
PIM: Join-list: (10.4.0.0/16, 224.2.0.1)
PIM: Prune-list (172.16.84.16/28, 224.2.0.1) RP-bit set RP 172.16.84.16
PIM: Send Prune on Ethernet1 to 172.16.37.6 for (172.16.84.16/28, 224.2.0.1), RP
PIM: For RP, Prune-list: 10.9.0.0/16
PIM: For 10.3.84.1, Join-list: 172.16.84.16/28
PIM: Send periodic Join/Prune to RP via 172.16.37.6 (Ethernet1)
The following lines appear periodically when PIM is running in sparse mode and indicate to this router
the multicast groups and multicast sources in which other routers are interested:
The following lines appear when a rendezvous point (RP) message is received and the RP timer is reset.
The expiration timer sets a checkpoint to make sure the RP still exists. Otherwise, a new RP must be
discovered.
PIM: Received RP-Reachable on Ethernet1 from 172.16.20.31
PIM: Update RP expiration timer for 224.2.0.1
PIM: Forward RP-reachability packet for 224.2.0.1 on Tunnel0
The prune message in the following line states that this router is not interested in the Source-Active (SA)
information. This message tells an upstream router to stop forwarding multicast packets from this
source.
PIM: Prune-list (10.221.196.51/32, 224.2.0.1)
In the following line, a second router on the network wants to override the prune message that the
upstream router just received. The timer is set at a random value so that if additional routers on the
network still want to receive multicast packets for the group, only one will actually send the message.
The other routers will receive the join message and then suppress sending their own message.
PIM: Set join delay timer to 2 seconds for (10.221.0.0/16, 224.2.0.1) on Ethernet1
In the following line, a join message is sent toward the RP for all sources:
PIM: Join-list: (*, 224.2.0.1) RP 172.16.20.31

May 2008 DB-1091
Debug Commands
debug ip pim
In the following lines, the interface is being added to the outgoing interface (OIF) of the (*, G) and
(S, G) multicast route (mroute) table entry so that packets from the source will be forwarded out that
particular interface:
PIM: Add Tunnel0 to (*, 224.2.0.1), Forward state
PIM: Add Tunnel0 to (10.0.0.0/8, 224.2.0.1), Forward state
The following line appears in sparse mode only. There are two trees on which data may be received: the
RP tree and the source tree. In dense mode there is no RP. After the source and the receiver have
discovered one another at the RP, the first-hop router for the receiver will usually join to the source tree
rather than the RP tree.
PIM: Prune-list (172.16.84.16/28, 224.2.0.1) RP-bit set RP 172.16.84.16
The send prune message in the next line shows that a router is sending a message to a second router
saying that the first router should no longer receive multicast packets for the (S, G). The RP at the end
of the message indicates that the router is pruning the RP tree and is most likely joining the source tree,
although the router may not have downstream members for the group or downstream routers with
members of the group. The output shows the specific sources from which this router no longer wants to
receive multicast messages.
PIM: Send Prune on Ethernet1 to 172.16.37.6 for (172.16.84.16/28, 224.2.0.1), RP
The following lines indicate that a prune message is sent toward the RP so that the router can join the
source tree rather than the RP tree:
In the following line, a periodic message is sent toward the RP. The default period is once per minute.
Prune and join messages are sent toward the RP or source rather than directly to the RP or source. It is
the responsibility of the next hop router to take proper action with this message, such as continuing to
forward it to the next router in the tree.
PIM: Send periodic Join/Prune to RP via 172.16.37.6 (Ethernet1)
Table 160 debug ip pim Field Descriptions
Field Description
PIM Protocol Independent Multicast.
10.221.196.51/32 Host route with 32 bits of mask.

debug ip dvmrp Displays information on DVMRP packets received and
sent.
debug ip igmp Displays IGMP packets received and sent, and displays
IGMP host-related events.
debug ip igrp transactions Displays transaction information on IGRP routing
transactions.
debug ip mrouting Displays changes to the IP multicast routing table.

DB-1092 May 2008
Debug Commands
debug ip policy
debug ip policy
To display IP policy routing packet activity, use the debug ip policy command in privileged EXEC
debug ip policy [access-list-name]
no debug ip policy [access-list-name]
Syntax Description access-list-name (Optional) The name of the access list. Displays packets permitted
by the access list that are policy routed in process level, Cisco
Express Forwarding (CEF), and distributed CEF (DCEF) with
NetFlow enabled or disabled.
If no access list is specified, information about all policy-matched
and policy-routed packets is displayed.
Command History Release Command

Usage Guidelines After you configure IP policy routing with the ip policy and route-map commands, use the debug ip
policy command to ensure that the IP policy is configured correctly.
Policy routing looks at various parts of the packet and then routes the packet based on certain
user-defined attributes in the packet.
The debug ip policy command helps you determine what policy routing is following. It displays
information about whether a packet matches the criteria, and if so, the resulting routing information for
the packet.
Caution Because the debug ip policy command generates a substantial amount of output, use it only when traffic
Examples The following is sample output from the debug ip policy command:
Router# debug ip policy 3
IP: s=30.0.0.1 (Ethernet0/0/1), d=40.0.0.7, len 100,FIB flow policy match

IP: s=30.0.0.1 (Ethernet0/0/1), d=40.0.0.7, len 100,FIB PR flow accelerated!
IP: s=30.0.0.1 (Ethernet0/0/1), d=40.0.0.7, g=10.0.0.8, len 100, FIB policy routed

May 2008 DB-1093
Debug Commands
debug ip policy
Table 161 debug ip policy Field Descriptions
Field Description
IP: s= IP source address and interface of the packet being routed.
d= IP destination address of the packet being routed.
len Length of the packet.
g= IP gateway address of the packet being routed.

DB-1094 May 2008
Debug Commands
debug ip rbscp ack-split

To display information about TCP ACK splitting done in conjunction with Rate-Based Satellite Control
Protocol (RBSCP), use the debug ip rbscp ack-split command in privileged EXEC mode. To disable
debug output, use the no form of this command.
no debug ip rbscp ack-split
Defaults RBSCP debugging for TCP ACKs is disabled by default.

Usage Guidelines
Caution Using this command will impact the routers forwarding performance.
Examples The following is sample output from the debug ip rbscp ack-split command when the packets match
the access list applied to RBSCP. The output includes the source and destination IP addresses and port
numbers, the hexadecimal sequence number, and the cumulative ACK that acknowledges bytes up to that
number.
Router# debug ip rbscp ack-split
*May 11 02:17:01.407: RBSCP ACK split: 0x662852D0, input FastEthernet1/0 -> output
FastEthernet1/1
*May 11 02:17:01.407: RBSCP ACK split: rcvd src 1.1.1.1:38481 -> dst 3.3.3.1:21, cumack
2336109115
*May 11 02:17:01.407: RBSCP ACK split: generated 0x65FC0874 cumack 2336109112
*May 11 02:17:01.407: RBSCP ACK split: generated 0x66762A78 cumack 2336109113
*May 11 02:17:01.407: RBSCP ACK split: generated 0x6676442C cumack 2336109114
*May 11 02:17:01.407: RBSCP ACK split: releasing original ACK 2336109115
*May 11 02:17:01.415: RBSCP process: 0x662852D0 passed access list
FastEthernet1/1

May 2008 DB-1095
Debug Commands
*May 11 02:17:01.415: RBSCP ACK split: rcvd src 1.1.1.1:36022 -> dst 3.3.3.1:20240, cumack
4024420742
*May 11 02:17:01.415: RBSCP ACK split: generated 0x65FC1E7C cumack 4024420739
*May 11 02:17:01.415: RBSCP ACK split: releasing original ACK 4024420742
FastEthernet1/1

debug ip rbscp Displays general error messages about access list-based RBSCP.
ip rbscp ack-split Configures the TCP ACK splitting feature of RBSCP on an outgoing
interface for packets that are permitted by a specified access list.

DB-1096 May 2008
Debug Commands
debug ip rbscp
debug ip rbscp
To display general error messages about access list-based Rate-Based Satellite Control Protocol
(RBSCP), use the debug ip rbscp command in privileged EXEC mode. To disable debug output, use the
debug ip rbscp
no debug ip rbscp
Defaults RBSCP debugging is disabled by default.

Usage Guidelines
Caution Using this command will impact the routers forwarding performance.
Examples The following is sample output from the debug ip rbscp command. The hexadecminal number is the
sequence number to keep track of the flow.
Router# debug ip rbscp

debug ip rbscp ack-split Displays information about TCP ACK splitting done in conjunction
with RBSCP.
ip rbscp ack-split Configures the TCP ACK splitting feature of RBSCP on an outgoing
interface for packets that are permitted by a specified access list.

May 2008 DB-1097
Debug Commands
debug ip rgmp
debug ip rgmp
To log debugging messages sent by a Router-Port Group Management Protocol (RGMP)-enabled router,
use the debug ip rgmp command in privileged EXEC mode. To disable debugging outut, use the no form
of this command.
debug ip rgmp [group-name | group-address]
no debug ip rgmp
Syntax Description group-name (Optional) The name of a specific IP multicast group.

group-address (Optional) The IP address of a specific IP multicast group.
Defaults Debugging for RGMP is not enabled. If the debug ip rgmp command is used without arguments,
debugging is enabled for all RGMP message types.

12.1(1)E The command was integrated into Cisco IOS Release 12.1(1)E.
Examples The following shows sample output from the debug ip rgmp command:
Router# debug ip rgmp
RGMP: Sending a Hello packet on Ethernet1/0
RGMP: Sending a Join packet on Ethernet1/0 for group 224.1.2.3
RGMP: Sending a Leave packet on Ethernet1/0 for group 224.1.2.3
RGMP: Sending a Bye packet on Ethernet1/0

ip rgmp Enables the RGMP on IEEE 802.3 Ethernet interfaces.
show ip igmp interface Displays multicast-related information about an interface.

DB-1098 May 2008
Debug Commands
debug ip rip
debug ip rip
To display information on Routing Information Protocol (RIP) routing transactions, use the debug ip rip
debug ip rip
no debug ip rip
Examples The following is sample output from the debug ip rip command:
router# debug ip rip

Updates
received RIP: received update from 10.89.80.28 on Ethernet0
10.89.95.0 in 1 hops
from this 10.89.81.0 in 1 hops
source 10.89.66.0 in 2 hops
address 172.31.0.0 in 16 hops (inaccessible)
0.0.0.0 in 7 hop
Updates RIP: sending update to 255.255.255.255 via Ethernet0 (10.89.64.31)
sent to subnet 10.89.94.0, metric 1
these two 172.31.0.0 in 16 hops (inaccessible)
RIP: sending update to 255.255.255.255 via Serial1 (10.89.94.31)
destination
subnet 10.89.64.0, metric 1
addresses subnet 10.89.66.0, metric 3
S2550
172.31.0.0 in 16 hops (inaccessible)
default 0.0.0.0, metric 8
The output shows that the router being debugged has received updates from one router at source address
160.89.80.28. That router sent information about five destinations in the routing table update. Notice that
the fourth destination address in the update131.108.0.0is inaccessible because it is more than 15
hops away from the router sending the update. The router being debugged also sent updates, in both cases
to broadcast address 255.255.255.255 as the destination.
The second line is an example of a routing table update. It shows how many hops a given Internet address
is from the router.
The entries show that the router is sending updates that are similar, except that the number in parentheses
is the source address encapsulated into the IP header.
Examples of additional output that the debug ip rip command can generate follow.
Entries such as the following appear at startup or when an event occurs such as an interface making a
transition or a user manually clearing the routing table:
RIP: broadcasting general request on Ethernet0
RIP: broadcasting general request on Ethernet1

May 2008 DB-1099
Debug Commands
debug ip rip
An entry such as the following is most likely caused by a malformed packet from the sender:
RIP: bad version 128 from 160.89.80.43

DB-1100 May 2008
Debug Commands
debug ip routing
debug ip routing
To display information on Routing Information Protocol (RIP) routing table updates and route cache
updates, use the debug ip routing command in privileged EXEC mode. To disable debugging output,
debug ip routing
no debug ip routing

12.2(13) T Support for Interior Gateway Routing Protocol (IGRP) was removed.
Examples The following is sample output from the debug ip routing command:
Router# debug ip routing
RT: add 172.25.168.0 255.255.255.0 via 172.24.76.30, igrp metric [100/3020]

RT: metric change to 172.25.168.0 via 172.24.76.30, igrp metric [100/3020]
new metric [100/2930]
IP: cache invalidation from 0x115248 0x1378A, new version 5736
RT: delete route to 172.26.219.0 via 172.24.76.30, igrp metric [100/10816]
RT: no routes to 172.26.219.0, entering holddown
RT: 172.26.219.0 came out of holddown
RT: garbage collecting entry for 172.26.219.0
RT: garbage collecting entry for 172.26.219.0

May 2008 DB-1101
Debug Commands
debug ip routing

In the following lines, a newly created entry has been added to the IP routing table. The metric change
indicates that this entry existed previously, but its metric changed and the change was reported by means
of IGRP. The metric could also be reported via RIP, OSPF, or another IP routing protocol. The numbers
inside the brackets report the administrative distance and the actual metric.
Cache invalidation means that the fast-switching cache was invalidated due to a routing table change.
New version is the version number of the routing table. When the routing table changes, this number
is incriminated. The hexadecimal numbers are internal numbers that vary from version to version and
software load to software load.
In the following output, the holddown and cache invalidation lines are displayed. Most of the
distance vector routing protocols use holddown to avoid typical problems like counting to infinity and
routing loops. If you look at the output of the show ip protocols command you will see the timer values
for holddown and cache invalidation. Cache invalidation corresponds to came out of holddown.
Delete route is triggered when a better path appears. It removes the old inferior path.

DB-1102 May 2008
Debug Commands
debug ip routing static bfd

To enable debugging output on IP static Bidirectional Forwarding Detection (BFD) neighbor events, use
the debug ip routing static bfd command in privileged EXEC mode. To disable debugging output, use
no debug ip routing static bfd

Examples The following is sample output from the debug ip routing static command:
Router# debug ip routing static bfd
*Dec 18 19:01:48.416: IP-ST-BFD(default): queued Config BFD neighbor command: intf

Ethernet1/1, gw 20.1.1.1 *Dec 18 19:01:48.416: IP-ST: Entering ipstatic_bfd_neighbor_add
RtrB(config)#
RtrB(config)#ip route 88.2.0.0 255.255.0.0 Ethernet1/1 20.1.1.1
RtrB(config)# *Dec 18 19:02:06.348: IP-ST: head_gwif: NULL *Dec 18 19:02:06.348: IP-ST:
Inserted to GWIF tree (head): 88.2.0.0/16 Et1/1 20.1.1.1 *Dec 18 19:02:16.852: RT:
updating static 88.2.0.0/16 (0x0) via 20.1.1.1 Et1/1 *Dec 18 19:02:16.856: RT: add
88.2.0.0/16 via 20.1.1.1, static metric [1/0] RtrB(config)#end RtrB#

May 2008 DB-1103
Debug Commands
debug ip rsvp
debug ip rsvp
Caution Use this command with a small number of tunnels or Resource Reservation Protocol (RSVP)
reservations. Too much data can overload the console.
To display debug messages for RSVP categories, use the debug ip rsvp command in privileged EXEC
debug ip rsvp [all | api | authentication | data-pkts | database | detail | dump-messages | errors
| events | fast-reroute | filter | function | handles | hello | messages | msg-mgr | path | policy
| proxy | rate-limit | reliable-msg | resv | routing | sbm | signalling | snmp | summary-refresh
| svc | timeouts | timer | traffic-control | wfq]
no debug ip rsvp
Syntax Description all (Optional) RSVP messages for all categories.

api (Optional) RSVP application programming interface (API) events.
authentication (Optional) RSVP authentication.
data-pkts (Optional) RSVP data processing.
database (Optional) RSVP Database debugging.
detail (Optional) RSVP packet content.
dump-messages (Optional) Dump RSVP message content.
errors (Optional) Informational debugging messages and messages about irregular
events.
events (Optional) RSVP process events.
fast-reroute (Optional) RSVP fast-reroute support for label-switched paths (LSPs).
filter (Optional) RSVP debug message filter.
function (Optional) RSVP function names.
handles (Optional) RSVP database handles event.
hello (Optional) RSVP hello events.
messages (Optional) Brief information about all RSVP messages that are sent and
received via IP debugging.
msg-mgr (Optional) RSVP message-manager events.
path (Optional) RSVP Path messages.
policy (Optional) RSVP policy information.
proxy (Optional) Proxy API trace.
rate-limit (Optional) RSVP rate-limiting events.
reliable-msg (Optional) RSVP reliable messages events.
resv (Optional) RSVP Resv messages.
routing (Optional) RSVP routing messages.
sbm (Optional) RSVP subnet bandwidth manager (SBM) messages.
signalling (Optional) RSVP signalling (Path and Resv) messages.
snmp (Optional) RSVP Simple Network Management Protocol (SNMP) events.

DB-1104 May 2008
Debug Commands
debug ip rsvp
summary-refresh (Optional) RSVP summary refresh and bundle messages events.

svc (Optional) Switched virtual circuit (SVC) events.
timeouts (Optional) RSVP refresh timeouts.
timer (Optional) RSVP timer events.
traffic-control (Optional) RSVP traffic control events.
wfq (Optional) RSVP weighted fair queueing (WFQ) events.
Defaults Disabled.

12.2(13)T The dump-messages, msg-mgr, proxy, rate-limit, reliable-msg, and
summary-refresh keywords were added.
12.0(23)S The timeouts keyword was added.
12.0(24)S The hello keyword was added.
Examples The following commands show how to enable debugging for RSVP categories, signaling, and messages:
Router# debug ip rsvp signalling
RSVP signalling messages (Summary) debugging is on
Router# debug ip rsvp messages
RSVP messages (sent/received via IP) debugging is on
In the following display, RSVP signaling-related events that include sending and receiving Path and
Resv messages, admitting new reservations, establishing sessions, sending and receiving
acknowledgments (ACKs), and sending and receiving summary refresh messages appear:
01:14:56:RSVP 10.20.1.1_19->10.75.1.1_100[10.20.1.1]:Received Path message from 10.20.1.1
(on sender host)
01:14:56:RSVP:new path message passed parsing, continue...
01:14:56:RSVP 10.20.1.1_19->10.75.1.1_100[10.20.1.1]:Refresh Path psb = 61646BB0 refresh
interval = 0mSec
01:14:56:RSVP 10.20.1.1_19->10.75.1.1_100[10.20.1.1]:Sending Path message to 10.4.4.2
01:14:56:RSVP session 10.75.1.1_100[10.20.1.1]:Path sent by IP to 10.4.4.2 length=216
checksum=B1E4 TOS=0xC0 prerouted=YES
router_alert=YES udp=NO (Ethernet1)
01:14:56:RSVP:Resv received from IP layer (IP HDR 10.4.4.2->10.4.4.1)

May 2008 DB-1105
Debug Commands
debug ip rsvp
01:14:56:RSVP session 10.75.1.1_100[10.20.1.1]:Received RESV for 10.75.1.1 (Ethernet1)

from 10.4.4.2
01:14:56:RSVP 10.20.1.1_19->10.75.1.1_100[10.20.1.1]:reservation not found--new one
01:14:56:RSVP-RESV:Admitting new reservation:6165D0E4
01:14:56:RSVP 10.20.1.1_19->10.75.1.1_100[10.20.1.1]:RSVP bandwidth is available
01:14:56:RSVP-RESV:reservation was installed:6165D0E4
01:14:57:RSVP:Sending Unknown message to 10.4.4.2
01:14:57:RSVP:Ack sent by IP to 10.4.4.2 length=20 checksum=34A7 TOS=0x00 prerouted=NO
router_alert=NO udp=NO (Ethernet1)
interval = 937mSec
01:14:58:%LINK-3-UPDOWN:Interface Tunnel100, changed state to up
01:14:59:%LINEPROTO-5-UPDOWN:Line protocol on Interface Tunnel100, changed state to up
interval = 30000mSec
01:15:26:RSVP 10.20.1.1_19->10.75.1.1_100[10.20.1.1]:Sending Path message to 10.4.4.2
01:15:26:RSVP session 10.75.1.1_100[10.20.1.1]:Path sent by IP to 10.4.4.2 length=216
checksum=B1E4 TOS=0xC0 prerouted=YES
router_alert=YES udp=NO (Ethernet1)
01:15:26:RSVP:Resv received from IP layer (IP HDR 10.4.4.2->10.4.4.1)
01:15:26:RSVP session 10.75.1.1_100[10.20.1.1]:Received RESV for 10.75.1.1 (Ethernet1)
from 10.4.4.2
01:15:26:RSVP 10.20.1.1_19->10.75.1.1_100[10.20.1.1]:reservation found--processing
possible change:6165D0E4
01:15:26:RSVP 10.20.1.1_19->10.75.1.1_100[10.20.1.1]:No change in reservation
01:15:27:RSVP:Sending Ack message to 10.4.4.2
01:15:56:RSVP:Sending Srefresh message to 10.4.4.2
01:15:56:RSVP:Srefresh sent by IP to 10.4.4.2 length=32 checksum=CA0D TOS=0x00
prerouted=NO router_alert=NO udp=NO (Ethernet1)
01:15:56:RSVP:Ack received from IP layer (IP HDR 10.4.4.2->10.4.4.1)
01:15:56:RSVP:Srefresh received from IP layer (IP HDR 10.4.4.2->10.4.4.1)
01:15:56:RSVP-RESV:Resv state is being refreshed for 0x91
01:16:26:RSVP:Sending Srefresh message to 10.4.4.2
01:16:26:RSVP:Srefresh sent by IP to 10.4.4.2 length=32 checksum=CA0C TOS=0x00
prerouted=NO router_alert=NO udp=NO (Ethernet1)
01:16:26:RSVP:Ack received from IP layer (IP HDR 10.4.4.2->10.4.4.1)
01:16:26:RSVP:Srefresh received from IP layer (IP HDR 10.4.4.2->10.4.4.1)
01:16:26:RSVP-RESV:Resv state is being refreshed for 0x91

ip rsvp signalling refresh reduction Enables refresh reduction.

DB-1106 May 2008
Debug Commands
debug ip rsvp aggregation

To display debugging output for Resource Reservation Protocol (RSVP) aggregation sessions, use the
debug ip rsvp aggregation command in privileged EXEC mode. To disable debugging output, use the
no debug ip rsvp aggregation

Usage Guidelines This command displays information about RSVP aggregation sessions.
RSVP aggregation maintains a Finite State Machine (FSM) for each aggregate session. The RSVP code
uses the FSM to maintain aggregate states and transition between the states of an aggregate. For example,
after the aggregator sends out the aggregate PATH message, a new state will be entered for the aggregate
session (RESV_WAIT) to reflect that an aggregate RESV message is expected. If an aggregate RESV
message is received, the session enters the ESTABLISHED state. If an aggregate RESV is not received
within a timeout, the aggregate session is cleaned and the process starts again.
Each aggregate reservation can be in one of the following states:
PATH_WAITValid at the deaggregator only. The aggregate reservation at the deaggregator enters
this state after the deaggregator has sent a PATHERROR message requesting a new aggregate
needed.
RESV_WAITValid at the aggregator only. The aggregate reservation at the aggregator enters this
state after the aggregator has sent a PATH message for the aggregate reservation.
RESVCONF_WAITValid at the deaggregator only. The aggregate reservation at the deaggregator
enters this state after the deaggregator has sent a RESV message for the aggregate reservation.
ESTABLISHEDValid at both the aggregator and the deaggregator. The aggregator enters this state
after a RESVCONF message has been sent. The deaggregator enters this state after it receives a
RESVCONF message for the aggregate reservation.
SHUT_DELAYValid at both the aggregator and the deaggregator. The aggregator and the
deaggregator enter this state after the last end-to-end (E2E) reservation has been removed.
There are timers associated with the PATH_WAIT, RESV_WAIT, RESVCONF_WAIT, and
SHUT_DELAY states. For example, if an event that is needed to move the FSM out of the PATH_WAIT,
RESV_WAIT, or RESVCONF_WAIT state does not occur, (that is, an aggregate PATH message is not
received when in the PATH_WAIT state), the timer expires and the aggregate is cleared.

May 2008 DB-1107
Debug Commands
In the successful scenario, the aggregate stays in the ESTABLISHED state as long as some E2E flows
are aggregated. Both the aggregator and the deaggregator stay in the SHUT_DELAY state until the timer
expires or an aggregate RESVTEAR or PATHTEAR message is received.
Examples The following example shows output from the debug ip rsvp aggregation command taken at an
aggregator:
Router# debug ip rsvp aggregation
RSVP aggregation debugging is on
*Jan 25 18:40:03.385: RSVP-AGG-3175: 10.3.3.3->10.4.4.4_46[A][4AB8208]:

event=NEW_AGG_NEEDED, current state=START *Jan 25 18:40:03.385: RSVP-AGG-3175:
10.3.3.3->10.4.4.4_46[A][4AB8208]: triggered Aggregate Path to 10.4.4.4 *Jan 25
18:40:03.385: RSVP-AGG-3175: 10.3.3.3->10.4.4.4_46[A][4AB8208]: new state=RESV_WAIT *Jan
25 18:40:03.441: RSVP-AGG-3175: 10.3.3.3->10.4.4.4_46[A][4AB8208]:
event=AGG_RESV_STATE_CREATED, current state=RESV_WAIT *Jan 25 18:40:03.441: RSVP-AGG-3175:
10.3.3.3->10.4.4.4_46[A][4AB8208]: new state=ESTABLISHED *Jan 25 18:40:03.465:
RSVP-AGG-3175: 10.3.3.3->10.4.4.4_46[A][4AB8208]:
event=E2E_RESV_STATE_CREATED, current state=ESTABLISHED *Jan 25 18:40:03.465:
RSVP-AGG-3175: 10.3.3.3->10.4.4.4_46[A][4AB8208]:
event=E2E_RESV_STATE_ADMITTED, current state=ESTABLISHED

show debugging Displays active debug output.

DB-1108 May 2008
Debug Commands
debug ip rsvp authentication

To display debugging output related to Resource Reservation Protocol (RSVP) authentication, use the
debug ip rsvp authentication command in privileged EXEC mode. To disable debugging output, use
no debug ip rsvp authentication

Usage Guidelines After you enable RSVP authentication, RSVP logs system error events whenever an authentication check
fails. These events are logged instead of just being displayed when debugging is enabled because they
may indicate potential security attacks. The events are generated when:
RSVP receives a message that does not contain the correct cryptographic signature. This could be
due to misconfiguration of the authentication key or algorithm on one or more RSVP neighbors, but
it may also indicate an (unsuccessful) attack.
RSVP receives a message with the correct cryptographic signature, but with a duplicate
authentication sequence number. This may indicate an (unsuccessful) message replay attack.
RSVP receives a message with the correct cryptographic signature, but with an authentication
sequence number that is outside the receive window. This could be due to a reordered burst of valid
RSVP messages, but it may also indicate an (unsuccessful) message replay attack.
Failed challenges result from timeouts or bad challenge responses.
Examples The following example shows output from the debug ip rsvp authentication command in which the
authentication type (digest) and the sequence number have been validated:
Router# debug ip rsvp authentication
RSVP authentication debugging is on

May 2008 DB-1109
Debug Commands
*Jan 30 08:10:46.335:RSVP_AUTH:Resv integrity digest from 192.168.101.2 valid

*Jan 30 08:10:46.335:RSVP_AUTH:Resv integrity sequence number 13971113505298841601 from
192.168.101.2 valid
*Jan 30 08:10:46.335:RSVP_AUTH:Resv from 192.168.101.2 passed all authentication checks
Note Cisco routers using RSVP authentication on Cisco IOS software ideally should have clocks that can be
accurately restored to the correct time when the routers boot. This capability is available on certain Cisco
routers that have clocks with battery backup. For those platforms that do not have battery backup,
consider configuring the router to keep its clock synchronized with a Network Time Protocol (NTP) time
server. Otherwise, if two adjacent routers have been operating with RSVP authentication enabled and
one of them reboots such that its clock goes backward in time, it is possible (but unlikely) the router that
did not reboot will log RSVP authentication sequence number errors.

ip rsvp authentication Activates RSVP cryptographic authentication.
show debugging Displays active debug output.

DB-1110 May 2008
Debug Commands
debug ip rsvp detail

To display detailed information about Resource Reservation Protocol (RSVP)-enabled and Subnetwork
Bandwidth Manager (SBM) message processing, use the debug ip rsvp detail command in privileged
no debug ip rsvp detail
Defaults Disabled.

Examples The following example shows the detailed debug information about RSVP and SBM that is available
when you enable debug mode through the debug ip rsvp detail command:
Router# debug ip rsvp detail
RSVP debugging is on
router2#u
*Dec 31 16:44:29.651: RSVP: send I_AM_DSBM message from 145.2.2.150
*Dec 31 16:44:29.651: RSVP: IP to 224.0.0.17 length=88 checksum=43AF
(Ethernet2)
*Dec 31 16:44:29.651: RSVP: version:1 flags:0000 type:I_AM_DSBM cksum:43AF
ttl:254 reserved:0 length:88
*Dec 31 16:44:29.651: DSBM_IP_ADDR type 1 length 8 : 91020296
*Dec 31 16:44:29.651: HOP_L2 type 1 length 12: 00E01ECE
*Dec 31 16:44:29.651: : 0F760000
*Dec 31 16:44:29.651: SBM_PRIORITY type 1 length 8 : 00000064
*Dec 31 16:44:29.651: DSBM_TIMERS type 1 length 8 : 00000F05
*Dec 31 16:44:29.651: SBM_INFO type 1 length 44: 00000000
*Dec 31 16:44:29.651: : 00240C02 00000007
*Dec 31 16:44:29.651: : 01000006 7F000005
*Dec 31 16:44:29.651: : 00000000 00000000
*Dec 31 16:44:29.655: : 00000000 00000000
*Dec 31 16:44:29.655: : 00000000

May 2008 DB-1111
Debug Commands

debug ip rsvp Displays information about SBM message processing, the DSBM
election process, and RSVP message processing.
debug ip rsvp detail sbm Displays detailed information about the contents of SMB messages
only, and SBM and DSBM state transitions.
ip rsvp dsbm-candidate Configures an interface as a DSBM candidate.
show ip rsvp sbm Displays information about SBM configured for a specific
RSVP-enabled interface or all RSVP-enabled interfaces on the
router.

DB-1112 May 2008
Debug Commands
debug ip rsvp dump-messages

Caution Use this command with a small number of tunnels or Resource Reservation Protocol (RSVP)
reservations. Too much data can overload the console.
To display debugging messages for all RSVP events, use the debug ip rsvp dump-messages command
debug ip rsvp dump-messages [hex | path | resv | sbm | signalling]
no debug ip rsvp dump-messages
Syntax Description hex (Optional) Hex dump of packet contents.

path (Optional) Contents of Path messages.
resv (Optional) Contents of Resv messages.
sbm (Optional) Contents of SBM messages.
signalling (Optional) Contents of all signaling (Path and Resv) messages.

Examples The following command shows how to enable debugging for RSVP events:
Router# debug ip rsvp dump-messages
RSVP message dump debugging is on
In the following display, notice that a Path message is transmitted and an ACK_DESIRED flag is set for
ID: 0x26 Epoch: 0x76798A. In response, a Resv message is sent and an acknowledgment (ACK) is
issued for ID: 0x26 Epoch: 0x76798A indicating the RSVP state is established on the neighboring
router:
00:37:15:RSVP:version:1 flags:0000 type:PROXY_PATH cksum:0000 ttl:255 reserved:0
length:212
00:37:15: Destination 140.75.1.1, TunnelId 100, Source 140.20.1.1, Protocol 0, Flags
0000
00:37:15: HOP type 1 length 12:
00:37:15: Neighbor 140.20.1.1, LIH 0x00000000
00:37:15: TIME_VALUES type 1 length 8 :

May 2008 DB-1113
Debug Commands
00:37:15: Refresh period is 30000 msecs

00:37:15: Source 140.20.1.1, tunnel_id 9
00:37:15: min unit=0 bytes, max pkt size=4294967295 bytes
00:37:15: IS Hops:0
00:37:15: Path MTU:-1
00:37:15: LABEL_REQUEST type 1 length 8 :
00:37:15: Layer 3 protocol ID:2048
00:37:15: EXPLICIT_ROUTE type 1 length 36:
00:37:15: (#1) Strict IPv4 Prefix, 8 bytes, 140.20.1.1/32
00:37:15: SESSION_ATTRIBUTE type 7 length 28:
00:37:15: Session name:tagsw4500-21_t100
00:37:15: Setup priority:7, reservation priority:7
00:37:15: Status:May-Reroute
00:37:15:
00:37:15:RSVP:version:1 flags:0001 type:Path cksum:D61E ttl:255 reserved:0 length:216
00:37:15: MESSAGE_ID type 1 length 12:
00:37:15: ID:0x26 Epoch:0x76798A
00:37:15: Flags:ACK_DESIRED
0000
00:37:15: Neighbor 140.4.4.1, LIH 0x10000401
00:37:15: EXPLICIT_ROUTE type 1 length 28:
00:37:15: LABEL_REQUEST type 1 length 8 :
00:37:15: Layer 3 protocol ID:2048
00:37:15: SESSION_ATTRIBUTE type 7 length 28:
00:37:15: Session name:tagsw4500-21_t100
00:37:15: Setup priority:7, reservation priority:7
00:37:15: Status:May-Reroute
00:37:15: Source 140.20.1.1, tunnel_id 9
00:37:15: min unit=0 bytes, max pkt size=4294967295 bytes
00:37:15: IS Hops:1

DB-1114 May 2008
Debug Commands

00:37:15: Path MTU:1500
00:37:15:
00:37:15:RSVP:version:1 flags:0001 type:Resv cksum:DADF ttl:255 reserved:0 length:132
00:37:15: MESSAGE_ID_ACK type 1 length 12:
00:37:15: Type:ACK
00:37:15: ID:0x26 Epoch:0x76798A
00:37:15: Flags:None
00:37:15: MESSAGE_ID type 1 length 12:
00:37:15: ID:0x43 Epoch:0xE1A1B7
00:37:15: Flags:ACK_DESIRED
0000
00:37:15: Neighbor 140.4.4.2, LIH 0x10000401
00:37:15: STYLE type 1 length 8 :
00:37:15: Shared-Explicit (SE)
00:37:15: FLOWSPEC type 2 length 36:
00:37:15: version = 0 length in words = 7
00:37:15: service id = 5, service length = 6
00:37:15: tspec parameter id = 127, flags = 0, length = 5
00:37:15: average rate = 1250 bytes/sec, burst depth = 1000 bytes
00:37:15: peak rate = 1250 bytes/sec
00:37:15: min unit = 0 bytes, max pkt size = 0 bytes
00:37:15: FILTER_SPEC type 7 length 12:
00:37:15: Source 140.20.1.1, tunnel_id 9
00:37:15: LABEL type 1 length 8 :
00:37:15: Labels:16
00:37:15:
00:37:15:RSVP:version:1 flags:0001 type:Ack cksum:34F5 ttl:255 reserved:0 length:20
00:37:15: MESSAGE_ID_ACK type 1 length 12:
00:37:15: Type:ACK
00:37:15: ID:0x43 Epoch:0xE1A1B7
00:37:15: Flags:None
00:37:15:


May 2008 DB-1115
Debug Commands
debug ip rsvp errors

To display informational debugging messages and messages about irregular events, use the debug ip
rsvp errors command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
no debug ip rsvp errors

Usage Guidelines Use the debug ip rsvp errors command to display informational messages and messages about irregular
events such as an incomplete setup or breakdown of an RSVP session. Informational messages do not
necessarily indicate problems. It is useful to use this command if something has gone wrong, but you do
not know what.
If you enter a different debug command, such as debug ip rsvp signalling, all the signalling errors and
the normal signalling events are displayed. You do not have to also enter the debug ip rsvp errors
command.
If there are many active RSVP sessions, enter the following configuration command to activate ACL
filtering so that you will view only relevant debugging messages.
Router(config)# access-list number permit udp src_ip src_port dst_ip dst_port
Where
numberAccess list number, from 100 to 199
src_ipThe tunnel headend
src_portThe link-state packet (LSP) ID
dst_ipThe tunnel tailend
dst_portThe tunnel ID, where the tunnel ID is the tunnel interface number

DB-1116 May 2008
Debug Commands
Then enter the following command to turn on ACL filtering:

Router# debug ip rsvp filter
In the following example, debugging is allowed only when the session is initiated from 192.168.1.4
toward 192.168.1.8, for Tunnel8 on the headend.
Note This ACL will capture both PATH and RESV messages for the session from 192.168.1.4 to 192.168.1.8,
but not any tunnels originating from 1.8 going to 1.4. You can also specify the LSP ID, but that is less
useful because it changes all the time, and the combination of the head, tail, and tunnel ID is generally
enough to limit the output to what you want.
Router(config)# access-list 101 permit udp host 192.168.1.4 host 192.168.1.8 eq 8

Router# debug ip rsvp filter
Examples The following is sample output from the debug ip rsvp errors command:
Router# debug ip rsvp errors
*May 21 08:54:31.918: RSVP: 5.1.1.1_68->7.1.1.1_3[5.1.1.1]: Problem parsing PATH message:

MISFORMATTED object (13) C-Type (2)

May 2008 DB-1117
Debug Commands
debug ip rsvp hello
debug ip rsvp hello

To verify that a Hello instance has been created, a Hello instance has been deleted, or that
communication with a neighbor has been lost, use the debug ip rsvp hello command in privileged EXEC
debug ip rsvp hello [stats]
no debug ip rsvp hello [stats]
Syntax Description stats (Optional) Indicates whether statistics are enabled or disabled.

12.2(18)SXD1 This command was integrated into Cisco IOS Release 12.2(18)SXD1.
Usage Guidelines When you enter the debug ip rsvp hello command, Resource Reservation Protocol (RSVP) signaling
messages are shown, but RSVP hello messages are excluded because of the large number of hello
messages that are sent.
Examples Following is sample output from the debug ip rsvp hello command. The first portion of the output is for
serial interface 2/0 when Hello is created:
Router# debug ip rsvp hello
00:22:03: RSVP-HELLO: rsvp_hello_inst_init: Initializing ACTIVE hello inst

12.0.0.2->12.0.0.3
00:22:03: RSVP-HELLO: rsvp_hello_create_instance_from_psb: Next hop Se2/0 is adjacent
00:22:03: RSVP-HELLO: rsvp_hello_create_instance_from_psb: Create hello instance for
12.0.0.2->12.0.0.3 on Se2/0 (psb=61BC5F60)
00:22:03: RSVP-HELLO: rsvp_hello_find_instance: psb_cnt=2 for hello inst
12.0.0.2->12.0.0.3
00:22:03: RSVP-HELLO: rsvp_hello_incoming_message: Neighbor 10.0.0.3 state changed to UP
00:22:05: %LINK-3-UPDOWN: Interface Tunnel1, changed state to up
00:22:06: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
rsvp-3640-2(config-if)#
rsvp-3640-2(config-if)# shut

DB-1118 May 2008
Debug Commands
debug ip rsvp hello
rsvp-3640-2(config-if)#
The following output shows that Hello has been deleted:

00:25:19: RSVP-HELLO: rsvp_hello_path_delete: psb for hello inst 10.0.0.2->10.0.0.3 exited
READY state (psb_cnt=1)
00:25:19: RSVP-HELLO: rsvp_hello_path_delete: Last psb deleted, hello inst for
12.0.0.2->12.0.0.3 ACTIVE->PASSIVE
00:25:19: RSVP-HELLO: rsvp_hello_path_delete: Last psb deleted, hello inst for
13.0.0.2->13.0.0.3 ACTIVE->PASSIVE
00:25:21: %LINK-5-CHANGED: Interface Tunnel1, changed state to administratively down
00:25:22: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1,
00:05:51: RSVP-HELLO: Communication lost with 10.0.0.2

00:05:51: RSVP-HELLO: rsvp_hello_communication_lost: Neighbor 10.0.0.2 was reset
(src_inst)
Following is sample output from the debug ip rsvp hello stats command:
Router(config)# ip rsvp signalling hello stats
Router(config)# end
Router#
00:32:28: RSVP-HELLO: rsvp_hello_stats_init: Hello stats is being configured

ip rsvp signalling hello (configuration) Enables Hello globally on the router.
ip rsvp signalling hello dscp Sets the DSCP value that is in the IP header of the Hello
message sent out from an interface.
ip rsvp signalling hello (interface) Enables Hello on an interface where you need Fast
Reroute protection.
ip rsvp signalling hello refresh interval Configures the Hello request interval.
ip rsvp signalling hello refresh misses Specifies how many Hello acknowledgments a node can
miss in a row before the node considers that
communication with its neighbor is down.
ip rsvp signalling hello statistics Enables Hello statistics on the router.

May 2008 DB-1119
Debug Commands
debug ip rsvp high-availability

To display debugging output for Resource Reservation Protocol traffic engineering (RSVP-TE)
high availability (HA) activities that improve the accessibility of network resources, use the debug ip
rsvp high-availability command in privileged EXEC mode. To disable debugging output, use the no
debug ip rsvp high-availability {all | database | errors | events | fsm | issu | messages}
no debug ip rsvp high-availability {all | database | errors | events | fsm | issu | messages}
Syntax Description all Displays debugging output for all RSVP-TE HA categories except for the
dumping of messages.
database Displays information about read and write operations to and from the
checkpointed database during the RSVP-TE HA activities.
errors Displays errors encountered by RSVP-TE during HA activities.
events Displays significant RSVP-TE stateful switchover (SSO) events during
RSVP-TE HA activities, such as:
RSVP-TE process events
RSVP-TE Route Processor (RP) state (active, standby, and recovery)
changes
Recovery period beginning and end
Redundant Facility (RF) events handled by RSVP-TE
fsm Displays significant events for the RSVP-TE checkpointed database finite
state machine (fsm) during the RSVP-TE HA activities.
issu Displays information about RSVP-TE In-Service Software Upgrade (ISSU)
activity.
messages Displays information about Checkpointing Facility (CF) messages sent by
RSVP-TE between the active RP and the standby RP.
Command Default Debugging is not enabled.

12.2(33)SRB Support for ISSU was added.

DB-1120 May 2008
Debug Commands
Usage Guidelines This command displays information about RSVP-TE activities, before and after SSO, that improve the
availability of network resources and services.
Examples The following example is sample output from the debug ip rsvp high-availability all command, which
turns on debugging for IP RSVP-TE HA events, messages, database, errors, fsm, and ISSU:
Router# debug ip rsvp high-availability all
RSVP HA all debugging is on
Router# show debug <---- This command displays the debugging that is enabled.
IP RSVP HA debugging is on for:

events
messages
database
errors
fsm
issu
This sample debugging output is displayed as an SSO recovery begins on the standby router in the
process of the standby router becoming active.
Note The prefix in the debug output is composed of label switched path (LSP) 5-tuples in the following
format: 10.0.0.3_61->10.0.0.9_10[10.0.0.3]. The 10.0.0.3 represents the source address, the 61
represents the LSP ID, the 10.0.0.9 represents the tunnel destination (tunnel tail), the10 represents the
tunnel ID, and the [10.0.0.3] represents the extended tunnel ID.
*May 12 19:46:14.267: RSVP-HA: session

65.39.97.4_18698[0.0.0.0]:rsvp_ha_read_lsp_head_info: Read LSP Head info: tun_id: 10
*May 12 19:46:14.267: RSVP-HA: session 10.0.0.1_10[0.0.0.0]: rsvp_ha_db_entry_find:
lsp_head entry found
*May 12 19:46:14.267: rsvp_ha_read_lsp_head_info: entry found
*May 12 19:46:14.267: RSVP-HA:rsvp_ha_read_lsp_head_info: Read LSP Head info: tun_id: 10
lsp_head entry found
*May 12 19:46:14.267: rsvp_ha_read_lsp_head_info: entry found
*May 12 19:46:15.995: %SYS-5-CONFIG_I: Configured from console by console
*May 12 19:46:20.803: RSVP-HA: 10.0.0.3_61->10.0.0.9_10[10.0.0.3]: rsvp_ha_db_entry_find:
lsp entry found
*May 12 19:46:20.803: rsvp_ha_read_generic_info: lsp entry found
*May 12 19:46:20.807: RSVP-HA: session 10.0.0.9_10[0.0.0.0]:rsvp_ha_write_generic_info:
Writing lsp_head info
lsp_head entry not found
*May 12 19:46:20.807: RSVP-HA: session 10.0.0.9_10[0.0.0.0]:
rsvp_ha_handle_wr_entry_not_found:
entry not found, type =lsp_head, action: Add
*May 12 19:46:20.807: RSVP-HA: session 10.0.0.9_10[0.0.0.0]: rsvp_ha_db_entry_create:
Created lsp_head entry
*May 12 19:46:20.807: RSVP-HA: session 10.0.0.9_10[0.0.0.0]:rsvp_ha_set_entry_state: None
-> Send-Pending
*May 12 19:46:20.807: RSVP-HA: session 10.0.0.9_10[0.0.0.0]: rsvp_ha_db_wavl_entry_insert:
Inserted entry into lsp_head Write DB, Send_Pending tree
*May 12 19:46:20.807: RSVP-HA: session
10.0.0.9_10[0.0.0.0]:rsvp_ha_fsm_wr_event_add_entry: add lsp_head entry to Write DB
*May 12 19:46:20.807: RSVP-HA: 10.0.0.3_61->10.0.0.9_10[10.0.0.3]:
rsvp_ha_write_generic_info: Writing lsp info

May 2008 DB-1121
Debug Commands
*May 12 19:46:20.807: RSVP-HA: 10.0.0.3_61->10.0.0.9_10[10.0.0.3]: rsvp_ha_db_entry_find:

lsp entry not found
*May 12 19:46:20.807: RSVP-HA: 10.0.0.3_61->10.0.0.9_10[10.0.0.3]:
rsvp_ha_handle_wr_entry_not_found: entry not found, type =lsp, action: Add
*May 12 19:46:20.807: RSVP-HA: 10.0.0.3_61->10.0.0.9_10[10.0.0.3]:
rsvp_ha_db_entry_create: Created lsp entry
*May 12 19:46:20.807: RSVP-HA:10.0.0.3_61->10.0.0.9_10[10.0.0.3]:
rsvp_ha_set_entry_state: None -> Send-Pending
*May 12 19:46:20.807: RSVP-HA: 10.0.0.3_61->10.0.0.9_10[10.0.0.3]:
rsvp_ha_db_wavl_entry_insert: Inserted entry into lsp Write DB, Send_Pending tree
*May 12 19:46:20.807: RSVP-HA: 10.0.0.3_61->10.0.0.9_10[10.0.0.3]:
rsvp_ha_fsm_wr_event_add_entry: add lsp entry to Write DB
*May 12 19:46:20.807: rsvp_ha_rd_remove_lsp_head_info: Event RD: remove lsp_head_info
*May 12 19:46:20.807: RSVP-HA: session 10.27.90.140_10[0.0.0.0]:
rsvp_ha_db_entry_find: lsp_head entry found
*May 12 19:46:20.807: RSVP-HA: session 10.0.0.9_10[0.0.0.0]: rsvp_ha_db_wavl_entry_remove:
Removed entry from lsp_head Read DB, Checkpointed tree
*May 12 19:46:20.807: RSVP-HA: session 10.0.0.9_10[0.0.0.0]: rsvp_ha_db_entry_free:
Freeing lsp_head entry
*May 12 19:46:20.807: RSVP-HA: session 10.0.0.9_10[0.0.0.0]:rsvp_ha_set_entry_state:
Checkpointed -> None
.
.
.
The following example shows how to turn debugging off for this command:
Router# no debug ip rsvp high-availability all
RSVP HA all debugging is off

debug ip rsvp sso Displays debugging output for RSVP signalling when the
graceful restart feature is configured.
debug mpls traffic-eng ha sso Displays debugging output for MPLS traffic engineering HA
activities during the graceful switchover from an active RP to a
redundant standby RP.

DB-1122 May 2008
Debug Commands
debug ip rsvp policy

To display debugging messages for Resource Reservation Protocol (RSVP) policy processing, use the
debug ip rsvp policy command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
no debug ip rsvp policy
Defaults Debugging for RSVP policy processing is not enabled.

Usage Guidelines You might find it useful to enable the debug cops command when you are using the debug ip rsvp policy
command. Together, these commands generate a complete record of the policy process.
Examples The following example uses only the debug ip rsvp policy command:
Router-1# debug ip rsvp policy
RSVP_POLICY debugging is on
02:02:14:RSVP-POLICY:Creating outbound policy IDB entry for Ethernet2/0 (61E6AB38)

02:02:14:RSVP-COPS:COPS query for Path message, 10.31.0.1_44->10.33.0.1_44
02:02:14:RSVP-POLICY:Building incoming Path context
02:02:14:RSVP-POLICY:Building outgoing Path context on Ethernet2/0
02:02:14:RSVP-POLICY:Build REQ message of 216 bytes
02:02:14:RSVP-POLICY:Message sent to PDP
02:02:14:RSVP-COPS:COPS engine called us with reason2, handle 6202A658
02:02:14:RSVP-COPS:Received decision message
02:02:14:RSVP-POLICY:Received decision for Path message
02:02:14:RSVP-POLICY:Accept incoming message
02:02:14:RSVP-POLICY:Send outgoing message to Ethernet2/0
02:02:14:RSVP-POLICY:Replacement policy object for path-in context
02:02:14:RSVP-POLICY:Replacement TSPEC object for path-in context

May 2008 DB-1123
Debug Commands
02:02:14:RSVP-COPS:COPS report for Path message, 10.31.0.1_44->10.33.0.1_44

02:02:14:RSVP-POLICY:Report sent to PDP
The following example uses both the debug ip rsvp policy and the debug cops commands:
Router-1# debug ip rsvp policy
RSVP_POLICY debugging is on
Router-1# debug cops
02:15:14:RSVP-POLICY:Creating outbound policy IDB entry for Ethernet2/0 (61E6AB38)

02:15:14:RSVP-COPS:COPS query for Path message, 10.31.0.1_44->10.33.0.1_44
02:15:14:RSVP-POLICY:Building incoming Path context
02:15:14:RSVP-POLICY:Building outgoing Path context on Ethernet2/0
02:15:14:RSVP-POLICY:Build REQ message of 216 bytes
COPS HEADER:Version 1, Flags 0, Opcode 1 (REQ), Client-type:1, Length:216
IN_IF (3/1) object. Length:12. Address:10.1.2.1. If_index:4
OUT_IF (4/1) object. Length:12. Address:10.33.0.1. If_index:3
CLIENT SI (9/1) object. Length:168. CSI data:
02:15:14: Destination 10.33.0.1, Protocol_Id 17, Don't Police , DstPort 44
02:15:14: HOP type 1 length 12:0A010201
02:15:14: :00000000
02:15:14: TIME_VALUES type 1 length 8 :00007530
02:15:14: Source 10.31.0.1, udp_source_port 44
02:15:14: min unit=0 bytes, max unit=1514 bytes
02:15:14: IS Hops:1
02:15:14: Path MTU:1500
02:15:14: Guaranteed Service break bit=0 service length=8
02:15:14: Path Delay (microseconds):192000
02:15:14: Path Jitter (microseconds):1200
02:15:14: Path delay since shaping (microseconds):192000
02:15:14: Path Jitter since shaping (microseconds):1200
02:15:14:RSVP-POLICY:Message sent to PDP
02:15:14:COPS:Message event!
02:15:14:COPS:State of TCP is 4
02:15:14:In read function
02:15:14:COPS:Read block of 96 bytes, num=104 (len=104)
COPS HEADER:Version 1, Flags 1, Opcode 2 (DEC), Client-type:1, Length:104

DB-1124 May 2008
Debug Commands
DECISION (6/3) object. Length:56. REPLACEMENT 00 10 0E 01 61 62 63 64 65 66 67

68 69 6A 6B 6C 00 24 0C 02 00
00 00 07 01 00 00 06 7F 00 00 05 44 9C 40 00 46 1C 40 00 49 98
96 80 00 00 00 C8 00 00 01 C8
02:15:14:Notifying client (callback code 2)

02:15:14:RSVP-COPS:COPS engine called us with reason2, handle 6202A104
02:15:14:RSVP-COPS:Received decision message
02:15:14:RSVP-POLICY:Received decision for Path message
02:15:14:RSVP-POLICY:Accept incoming message
02:15:14:RSVP-POLICY:Send outgoing message to Ethernet2/0
02:15:14:RSVP-POLICY:Replacement policy object for path-in context
02:15:14:RSVP-POLICY:Replacement TSPEC object for path-in context
COPS HEADER:Version 1, Flags 1, Opcode 3 (RPT), Client-type:1, Length:24
REPORT (12/1) object. Length:8. REPORT type COMMIT (1)

02:15:14:RSVP-POLICY:Report sent to PDP
02:15:14:Timer for connection entry is zero

debug cops Displays debugging messages for COPS processing.

May 2008 DB-1125
Debug Commands
debug ip rsvp rate-limit

To display debugging messages for Resource Reservation Protocol (RSVP) rate-limiting events, use the
debug ip rsvp rate-limit command in privileged EXEC mode. To disable debugging output, use the no
no debug ip rsvp rate-limit

Examples The following command shows how to enable debugging for RSVP rate-limiting and message manager
events:
Router# debug ip rsvp rate-limit
RSVP rate-limit debugging is on
Router# debug ip rsvp msg-mgr
RSVP msg-mgr debugging is on
In the following display, RSVP process information including messages, timers, neighbors IP addresses,
and message IDs, appear:
01:00:19:RSVP-RATE-LIMIT:rsvp_msg_pacing_send_message
01:00:19:RSVP-MSG-MGR (140.4.4.2):Starting timer msg-pacing interval 20
01:00:19:RSVP-MSG-MGR (140.4.4.2):Enqueue element 27000405 of type 3 on msg-pacing TAIL
01:00:19:RSVP-RATE-LIMIT:rsvp_msg_pacing_timer - timer expired
01:00:19:RSVP-MSG-MGR (140.4.4.2):Dequeueing element 27000405 of type 3 from msg-pacing
01:00:19:RSVP-RATE-LIMIT:rsvp_msg_pacing_send_qe:sending psb (qe 27000405)

DB-1126 May 2008
Debug Commands


ip rsvp signalling rate-limit Controls the transmission rate for RSVP messages sent to a
neighboring router during a specified interval.

May 2008 DB-1127
Debug Commands
debug ip rsvp reliable-msg

To display debugging messages for Resource Reservation Protocol (RSVP) reliable messages events, use
the debug ip rsvp reliable-msg command in privileged EXEC mode. To disable debugging output, use
no debug ip rsvp reliable-msg

Examples The following command shows how to enable debugging for RSVP reliable messages events:
Router# debug ip rsvp reliable-msg
RSVP reliable-msg debugging is on
In the following display, message IDs, acknowledgments (ACKs), and message processes including
retransmissions, appear:
01:07:37:RSVP-RMSG:Inserted msg id(0x46, 0x48000403) on local msgid db

01:07:37:RSVP-RMSG:rsvp_rmsg_process_acks, Handle:000C1701 neighbor:140.4.4.2
01:07:37:RSVP-RMSG:max_ids:1 q_sz:1 msg_sz:1500 ids_len:1432 num_objs:0 obj_len:0
nbr:140.4.4.2
nbr:140.4.4.2
nbr:140.4.4.2
01:08:37:RSVP-RMSG:rsvp_rmsg_process_immediate_tmb, Handle:2D000404 neighbor:140.4.4.2
01:08:37:RSVP-RMSG:Inserted msg id(0x47, 0x2D000404) on local msgid db
01:08:37:RSVP-RMSG:current queue:immed next_queue:rxmt-1 (qe 2D000404s)

DB-1128 May 2008
Debug Commands

nbr:140.4.4.2
01:08:38:RSVP-RMSG:rsvp_rmsg_process_rxmt_tmb, Handle:2D000404 neighbor:140.4.4.2
01:08:38:RSVP-RMSG:An ack was received for tmb 2D000404 on neighbor 140.4.4.2
nbr:140.4.4.2
01:09:07:RSVP-RMSG:rsvp_rmsg_process_immediate_tmb, Handle:2E000404 neighbor:140.4.4.2
01:09:07:RSVP-RMSG:Inserted msg id(0x48, 0x2E000404) on local msgid db
01:09:07:RSVP-RMSG:current queue:immed next_queue:rxmt-1 (qe 2E000404s)
nbr:140.4.4.2
01:09:08:RSVP-RMSG:rsvp_rmsg_process_rxmt_tmb, Handle:2E000404 neighbor:140.4.4.2
01:09:08:RSVP-RMSG:An ack was received for tmb 2E000404 on neighbor 140.4.4.2
nbr:140.4.4.2
01:09:37:RSVP-RMSG:rsvp_rmsg_process_immediate_tmb, Handle:2F000404 neighbor:140.4.4.2
01:09:37:RSVP-RMSG:Inserted msg id(0x49, 0x2F000404) on local msgid db
01:09:37:RSVP-RMSG:current queue:immed next_queue:rxmt-1 (qe 2F000404s)
nbr:140.4.4.2
01:09:38:RSVP-RMSG:rsvp_rmsg_process_rxmt_tmb, Handle:2F000404 neighbor:140.4.4.2
01:09:38:RSVP-RMSG:An ack was received for tmb 2F000404 on neighbor 140.4.4.2


May 2008 DB-1129
Debug Commands
debug ip rsvp sbm
debug ip rsvp sbm

To display detailed information about Subnetwork Bandwidth Manager (SBM) messages only, and SBM
and Designated Subnetwork Bandwidth Manager (DSBM) state transitions, use the debug ip rsvp sbm
debug ip rsvp sbm
no debug ip rsvp sbm
Defaults Disabled

Usage Guidelines The debug ip rsvp sbm command provides information about messages received, minimal detail about
the content of these messages, and information about state transitions.
Examples The following example shows the detailed debug information about SBM and the SBM and DSBM state
transitions that is available when you enable debug mode through the debug ip rsvp sbm command:
Router# debug ip rsvp sbm
router2#
*Dec 31 16:45:34.659: RSVP: send I_AM_DSBM message from 145.2.2.150
*Dec 31 16:45:34.659: RSVP: IP to 224.0.0.17 length=88 checksum=9385 (Ethernet2)
*Dec 31 16:45:34.659: RSVP: version:1 flags:0000 type:I_AM_DSBM cksum:9385
ttl:254 reserved:0 length:88
*Dec 31 16:45:34.659: DSBM_IP_ADDR type 1 length 8 : 91020296
*Dec 31 16:45:34.659: HOP_L2 type 1 length 12: 00E01ECE
*Dec 31 16:45:34.659: : 0F760000
*Dec 31 16:45:34.659: SBM_PRIORITY type 1 length 8 : 0029B064
*Dec 31 16:45:34.659: DSBM_TIMERS type 1 length 8 : 00000F05
*Dec 31 16:45:34.659: SBM_INFO type 1 length 44: 00000000
*Dec 31 16:45:34.659: : 00240C02 00000007
*Dec 31 16:45:34.659: : 01000006 7F000005
*Dec 31 16:45:34.659: : 00000000 00000000

DB-1130 May 2008
Debug Commands
debug ip rsvp sbm
*Dec 31 16:45:34.663: : 00000000 00000000

*Dec 31 16:45:34.663: : 00000000
*Dec 31 16:45:34.663:

debug ip rsvp Displays information about SBM message processing, the
DSBM election process, and RSVP message processing.
debug ip rsvp authentication Displays detailed information about RSVP and SBM.
ip rsvp dsbm-candidate Configures an interface as a DSBM candidate.

May 2008 DB-1131
Debug Commands
debug ip rsvp sso
debug ip rsvp sso

To display debugging output for Resource Reservation Protocol (RSVP) signaling when the graceful
restart feature is configured, use the debug ip rsvp sso command in privileged EXEC mode. To disable
debug ip rsvp sso
no debug ip rsvp sso

Usage Guidelines This command displays debugging output from RSVP signaling during and after the Route Processor
(RP) stateful switchover when system control and routing protocol execution is transferred from the
active RP to the redundant standby RP. The SSO process occurs when the active router becomes
unavailable, so that no interruption of network services occurs. The command displays information
about the activities that RSVP performs when you configure a graceful restart, such as:
Writing checkpointing information into the write database when a new traffic engineering (TE) label
switched path (LSP) is signaled on the active RP
Recovering the LSP checkpointed information from the read database after SSO
Displaying information about LSPs not recovered
Examples The following is sample output from the debug ip rsvp sso command that was displayed during a
successful SSO on the standby router as it became active:
Router# debug ip rsvp sso
RSVP sso debugging is on
Router#

DB-1132 May 2008
Debug Commands
debug ip rsvp sso
Note The prefix in the debug output is composed of LSP 5-tuples in the following format:
10.0.0.3_61->10.0.0.9_10[10.0.0.3]. The 10.0.0.3 represents the source address, the 61
represents the LSP ID, the 10.0.0.9 represents the tunnel destination (tunnel tail), the10
represents the tunnel ID, and the [10.0.0.3] represents the extended tunnel ID.
*May 12 20:12:38.175: RSVP-HA: begin recovery, send msg to RSVP

*May 12 20:12:38.175: RSVP: 10.0.0.3_61->10.0.0.9_10[10.0.0.3]: event: new Path received
during RSVP or IGP recovery period
*May 12 20:12:38.175: RSVP: 10.0.0.3_61->10.0.0.9_10[10.0.0.3]:
rsvp_ha_sb_event_new_path_received: lsp_info found, attempt to recover lsp
*May 12 20:12:38.175: RSVP: 10.0.0.3_61->10.0.0.9_10[10.0.0.3]: set psb_is_recovering flag
*May 12 20:12:38.179: RSVP: 10.0.0.3_61->10.0.0.9_10[10.0.0.3]:rsvp_ha_sb_set_path_info:
Recovering: Set next_hop and next_idb in psb
*May 12 20:12:38.179: RSVP:
10.0.0.3_61->10.0.0.9_10[10.0.0.3]:rsvp_ha_mark_lsp_if_recoverable: LSP is recoverable
(ERO expansion. not needed)
*May 12 20:12:38.179: RSVP-HA: rsvp_ha_sb_handle_recovery_start: Recovery period start:
set GR recovery time.
*May 12 20:12:38.179: RSVP_HA: checkpoint hello_globals_info
*May 12 20:12:38.179: RSVP-HELLO: rsvp_ha_update_all_gr_hi: Updating all GR HIs with new
src_instance
*May 12 20:12:38.183: RSVP: 10.0.0.3_61->10.0.0.9_10[10.0.0.3]: prevent populating output;
LSP is recovering
*May 12 20:12:38.187: RSVP: 10.0.0.3_61->10.0.0.9_10[10.0.0.3]: prevent populating output;
LSP is recovering
*May 12 20:12:38.939: RSVP: 10.0.0.3_61->10.0.0.9_10[10.0.0.3]:
rsvp_ha_sb_event_new_resv_received: event: Resv for LSP received during recovery period
*May 12 20:12:38.943: RSVP: 10.0.0.3_61->10.0.0.9_10[10.0.0.3]:
rsvp_ha_event_lsp_create_head: psb found
*May 12 20:12:38.943: RSVP: 10.0.0.3_61->10.0.0.9_10[10.0.0.3]:
rsvp_ha_event_lsp_create_head: event: LSP created at head-end, try to checkpoint it
*May 12 20:12:38.943: RSVP: 10.0.0.3_61->10.0.0.9_10[10.0.0.3]: LSP was checkpointed
*May 12 20:12:38.943: RSVP-HA: 10.0.0.3_61->10.0.0.9_10[10.0.0.3]:
rsvp_ha_sb_event_lsp_head_recovered: event: LSP head was recovered
*May 12 20:12:38.943: RSVP-HA: recovery period over, send msg to RSVP
*May 12 20:12:38.947: RSVP-HA: rsvp_ha_sb_handle_recovery_end: Deleting state for LSPs not
recovered
Router#
The following example shows how to turn debugging off for this command:
Router# no debug ip rsvp sso
RSVP sso debugging is off

debug ip rsvp high-availability Displays debugging output for RSVP-TE HA activities that
improve the accessibility of network resources.
debug mpls traffic-eng ha sso Displays debugging output for MPLS traffic engineering HA
activities during the graceful switchover from an active RP to
a redundant standby RP.

May 2008 DB-1133
Debug Commands
debug ip rsvp summary-refresh

To display debugging messages for Resource Reservation Protocol (RSVP) summary-refresh messages
events, use the debug ip rsvp summary-refresh command in privileged EXEC mode. To disable
no debug ip rsvp summary-refresh

Examples The following command shows how to enable debugging for RSVP summary-refresh messages events:
Router# debug ip rsvp summary-refresh
RSVP summary-refresh debugging is on
In the following output, the IP addresses, the interfaces, the types of RSVP messages (Path and Resv),
message IDs, and epoch identifiers (for routers) for which RSVP summary-refresh events occur are
shown:
01:11:00:RSVP-SREFRESH:Incoming message from nbr 140.4.4.2 with epoch:0xE1A1B7 msgid:0x84
on Ethernet1
01:11:00:RSVP-SREFRESH 140.20.1.1_18->140.75.1.1_100[140.20.1.1]:Created msgid 0x84 for
nbr 140.4.4.2
01:11:30:RSVP-SREFRESH:140.20.1.1_18->140.75.1.1_100[140.20.1.1]:Path, ID:0x4C :Start
using Srefresh to 140.4.4.2
on Ethernet1
01:11:31:RSVP-SREFRESH:State exists for nbr:140.4.4.2 epoch:0xE1A1B7 msgid:0x84
01:12:00:RSVP-SREFRESH:Preparing to Send Srefresh(es) to 140.4.4.2, 1 IDs Total
01:12:00:RSVP-SREFRESH:Sending 1 IDs in this Srefresh
01:12:00:RSVP-SREFRESH:140.20.1.1_18->140.75.1.1_100[140.20.1.1]:Path, ID:0x4C

DB-1134 May 2008
Debug Commands

on Ethernet1
01:12:01:RSVP-SREFRESH:Rec'd 1 IDs in Srefresh from 140.4.4.2 (on Ethernet1),
epoch:0xE1A1B7 msgid:0x86
01:12:01:RSVP-SREFRESH:140.20.1.1_18->140.75.1.1_100[140.20.1.1]:Resv, ID:0x84
on Ethernet1
epoch:0xE1A1B7 msgid:0x88
01:13:01:RSVP-SREFRESH:Incoming message from nbr 140.4.4.2 with epoch:0xE1A1B7 msgid:0x8A
on Ethernet1
epoch:0xE1A1B7 msgid:0x8A
Note In the preceding output, notice the message IDs that correspond to Path or Resv state being refreshed.
Because the entire message does not have to be transmitted, there is less data and network performance
is improved.


May 2008 DB-1135
Debug Commands
debug ip rsvp traffic-control

To display debugging messages for compression-related events, use the debug ip rsvp traffic-control
no debug ip rsvp traffic-control

12.2(15)T The command output was modified to include compression-related events.
Usage Guidelines Use the debug ip rsvp traffic-control command to troubleshoot compression-related problems.
Examples The following example from the debug ip rsvp traffic-control command shows that compression was
successfully predicted:
Router# debug ip rsvp traffic-control
00:44:49: RSVP-TC: Attempting to install QoS for rsb 62CC66F0

00:44:49: RSVP-TC: Adding new tcsb 02000406 for rsb 62CC66F0
00:44:49: RSVP-TC: Assigning WFQ QoS (on FR VC 101) to tcsb 02000406
00:44:49: RSVP-TC: Predicted compression for TCSB 2000406:
00:44:49: RSVP-TC: method = rtp
00:44:49: RSVP-TC: context ID = 2
00:44:49: RSVP-TC: factor = 82 percent
00:44:49: RSVP-TC: bytes-saved = 36 bytes

DB-1136 May 2008
Debug Commands
00:44:49: RSVP-TC: Bandwidth check: requested bw=65600 old bw=0

00:44:49: RSVP-TC: RSVP bandwidth is available
00:44:49: RSVP-TC: Consulting policy for tcsb 02000406
00:44:49: RSVP-TC: Policy granted QoS for tcsb 02000406
00:44:49: RSVP-TC: Requesting QoS for tcsb 02000406
00:44:49: RSVP-TC: ( r = 8200 bytes/s M = 164 bytes
00:44:49: RSVP-TC: b = 328 bytes m = 164 bytes )
00:44:49: RSVP-TC: p = 10000 bytes/s Service Level = priority
00:44:49: RSVP-WFQ: Update for tcsb 02000406 on FR PVC dlci 101 on Se3/0
00:44:49: RSVP-WFQ: Admitted 66 kbps of bandwidth
00:44:49: RSVP-WFQ: Allocated PRIORITY queue 24
00:44:49: RSVP-TC: Allocation succeeded for tcsb 02000406
The following example from the debug ip rsvp traffic-control command shows that compression was
unsuccessfully predicted because no compression context IDs were available:
Router# debug ip rsvp traffic-control
00:10:16:RSVP-TC:Attempting to install QoS for rsb 62CED62C

00:10:16:RSVP-TC:Adding new tcsb 01000421 for rsb 62CED62C
00:10:16:RSVP-TC:Assigning WFQ QoS (on FR VC 101) to tcsb 01000421
00:10:16:RSVP-TC:sender's flow is not rtp compressible for TCSB 1000421
00:10:16: reason: no contexts available
00:10:16:RSVP-TC:sender's flow is not udp compressible for TCSB 1000421
00:10:16: reason: no contexts available
00:10:16:RSVP-TC:Bandwidth check:requested bw=80000 old bw=0
00:10:16:RSVP-TC:RSVP bandwidth is available
00:10:16:RSVP-TC:Consulting policy for tcsb 01000421
00:10:16:RSVP-TC:Policy granted QoS for tcsb 01000421
00:10:16:RSVP-TC:Requesting QoS for tcsb 01000421
00:10:16:RSVP-TC: ( r = 10000 bytes/s M = 200 bytes
00:10:16:RSVP-TC: b = 400 bytes m = 200 bytes )
00:10:16:RSVP-TC: p = 10000 bytes/s Service Level = priority
00:10:16:RSVP-WFQ:Update for tcsb 01000421 on FR PVC dlci 101 on Se3/0
00:10:16:RSVP-WFQ:Admitted 80 kbps of bandwidth
00:10:16:RSVP-WFQ:Allocated PRIORITY queue 24
00:10:16:RSVP-TC:Allocation succeeded for tcsb 01000421

show debugging Displays active debugging output.

May 2008 DB-1137
Debug Commands
debug ip rsvp wfq
debug ip rsvp wfq

To display debugging messages for the weighted fair queue (WFQ), use the debug ip rsvp wfq command
debug ip rsvp wfq
no debug ip rsvp wfq

Examples The following is sample output from the debug ip rsvp wfq command:
Router# debug ip rsvp wfq
IP RSVP debugging is on
IP RSVP debugging (Traffic Control events) is on
IP RSVP debugging (WFQ events) is on
Router#
03:03:23:RSVP-TC:Attempting to install QoS for rsb 6268A538
03:03:23:RSVP-TC:Adding new tcsb 00001A01 for rsb 6268A538
03:03:23:RSVP-TC:Assigning WFQ QoS to tcsb 00001A01
03:03:23:RSVP-TC:Consulting policy for tcsb 00001A01
03:03:23:RSVP-TC:Policy granted QoS for tcsb 00001A01
03:03:23:RSVP-TC:Requesting QoS for tcsb 00001A01
03:03:23:RSVP-TC: ( r = 12500 bytes/s M = 1514 bytes
03:03:23:RSVP-TC: b = 1000 bytes m = 0 bytes )
03:03:23:RSVP-TC: p = 12500 bytes/s Service Level = non-priority
03:03:23:RSVP-WFQ:Requesting a RESERVED queue on Et0/1 for tcsb 00001A01

DB-1138 May 2008
Debug Commands
debug ip rsvp wfq
03:03:23:RSVP-WFQ:Queue 265 allocated for tcsb 00001A01

03:03:23:RSVP-TC:Allocation succeeded for tcsb 00001A01
Router#
Router# no debug ip rsvp
RSVP debugging is off

show debug Displays active debugging output.

May 2008 DB-1139
Debug Commands
debug ip rtp header-compression

To display events specific to Real-Time Transport Protocol (RTP) header compression, use the debug ip
rtp header-compression command in privileged EXEC mode. To disable debugging output, use the no
no debug ip rtp header-compression
Examples The following is sample output from the debug ip rtp header-compression command:
Router# debug ip rtp header-compression
RHC BRI0: rcv compressed rtp packet

RHC BRI0: context0: expected sequence 0, received sequence 0
Table 162 debug ip rtp header-compression Field Descriptions
Field Description
context0 Compression state for a connection 0.
expected sequence RTP header compression link sequence (expected).
received sequence RTP header compression link sequence (actually received).

debug ip rtp packets Displays a detailed dump of packets specific to RTP header
compression.

DB-1140 May 2008
Debug Commands
debug ip rtp packets

To display a detailed dump of packets specific to Real-Time Transport Protocol (RTP) header
compression, use the debug ip rtp packets command in privileged EXEC mode. To disable debugging
no debug ip rtp packets
Examples The following is sample output from the debug ip rtp packets command:
Router# debug ip rtp packets
RTP packet dump:

IP: source: 171.68.8.10, destination: 224.2.197.169, id: 0x249B, ttl: 9,
TOS: 0 prot: 17,
UDP: source port: 1034, destination port: 27404, checksum: 0xB429,len: 152
RTP: version: 2, padding: 0, extension: 0, marker: 0,
payload: 3, ssrc 2369713968,
sequence: 2468, timestamp: 85187180, csrc count: 0
Table 163 debug ip rtp packets Field Descriptions
Field Description
id IP identification.
ttl IP time to live (TTL).
len Total UDP length.

debug ip rtp header-compression Displays events specific to RTP header compression.

May 2008 DB-1141
Debug Commands
debug ip scp
debug ip scp
To troubleshoot secure copy (SCP) authentication problems, use the debug ip scp command in
debug ip scp
no debug ip scp

Examples The following example is output from the debug ip scp command. In this example, a copy of the file
scptest.cfg from a UNIX host running configuration of the router was successful.
Router# debug ip scp
4d06h:SCP:[22 -> 10.11.29.252:1018] send <OK>

4d06h:SCP:[22 <- 10.11.29.252:1018] recv C0644 20 scptest.cfg
4d06h:SCP:[22 -> 10.11.29.252:1018] send <OK>
4d06h:SCP:[22 <- 10.11.29.252:1018] recv 20 bytes
4d06h:SCP:[22 <- 10.11.29.252:1018] recv <OK>
4d06h:SCP:[22 -> 10.11.29.252:1018] send <OK>
4d06h:SCP:[22 <- 10.11.29.252:1018] recv <EOF>
The following example is also output from the debug ip scp command, but in this example, the user has
privilege 0 and is therefore denied:
Router# debug ip scp
4d06h:SCP:[22 -> 10.11.29.252:1018] send Privilege denied.

ip scp server enable Enables SCP server-side functionality.

DB-1142 May 2008
Debug Commands
debug ip sctp api
debug ip sctp api

To provide diagnostic information about Stream Control Transmission Protocol (SCTP) application
programming interfaces (APIs), use the debug ip sctp api command in privileged EXEC mode. To
debug ip sctp api
no debug ip sctp api

Usage Guidelines In a live system, the debugging messages for performance, state, signal, and warnings are the most
useful. These show any association or destination address failures and can be used to monitor the
stability of any established associations.
Caution The debug ip sctp api command should not be used in a live system that has any significant amount of
traffic running because it can generate a lot of traffic, which can cause associations to fail.
Examples The following example shows SCTP calls to the API that are being executed and the parameters
associated with these calls:
Router# debug ip sctp api
*Mar 1 00:31:14.211: SCTP: sctp_send: Assoc ID: 1

*Mar 1 00:31:14.211: SCTP: stream num: 10
*Mar 1 00:31:14.211: SCTP: bptr: 62EE332C, dptr: 4F7B598
*Mar 1 00:31:14.211: SCTP: datalen: 100
*Mar 1 00:31:14.211: SCTP: context: 1
*Mar 1 00:31:14.211: SCTP: lifetime: 0
*Mar 1 00:31:14.211: SCTP: unorder flag: FALSE
*Mar 1 00:31:14.211: SCTP: bundle flag: TRUE
*Mar 1 00:31:14.211: SCTP: sctp_send successful return
*Mar 1 00:31:14.211: SCTP: sctp_receive: Assoc ID: 1

May 2008 DB-1143
Debug Commands
debug ip sctp api
*Mar 1 00:31:14.215: SCTP: max data len: 100

*Mar 1 00:31:14.215: SCTP: sctp_receive successful return
*Mar 1 00:31:14.215: SCTP: Process Send Request
*Mar 1 00:31:14.951: SCTP: sctp_receive: Assoc ID: 0
*Mar 1 00:31:14.951: SCTP: max data len: 100
*Mar 1 00:31:14.951: SCTP: sctp_receive successful return
.
.
.
Table 164 debug ip sctp api Field Descriptions
Field Description
Assoc ID Association identifier.
stream num SCTP stream number.
bptr, dptr Address of the buffer that contains the data, and address of the start of the
data.
datalen Length of the data that the application is sending (the datagram).
context A value that is meaningful to the application. Returned with the datagram if
the datagram ever needs to be retrieved.
lifetime Not used.
unorder flag Specifies that the datagram should be sent as unordered data.
bundle flag Indicates whether the application wants the datagram to be delayed slightly,
trying to bundle it with other data being sent.
max data len Maximum length of data that can be receivedthe size of the receive buffer.

clear ip sctp statistics Empties the buffer that holds SCTP statistics.
debug ip sctp congestion Shows a list of all current SCTP associations.
show ip sctp association parameters Shows the parameters configured for the association
defined by the association identifier.
show ip sctp association statistics Shows the current statistics for the association defined by
the association identifier.
show ip sctp errors Shows error counts logged by SCTP.
show ip sctp instances Shows all currently defined SCTP instances.
show ip sctp statistics Shows overall statistics counts for SCTP.
show iua as Shows information about the current condition of an
application server.
show iua asp Shows information about the current condition of an
application server process.

DB-1144 May 2008
Debug Commands
debug ip sctp congestion

To provide diagnostic information about Stream Control Transmission Protocol (SCTP) congestion
parameters, use the debug ip sctp congestion command in privileged EXEC mode. To disable
no debug ip sctp congestion

Debug commands other than those for performance, state, signal, and warnings can generate a great deal
of output and therefore can cause associations to fail. These commands should be used only in test
environments or when there are very low amounts of traffic.
Examples The following example shows parameters used to calculate SCTP congestion:
Router# debug ip sctp congestion
SCTP: Assoc 0: Slow start 10.6.0.4, cwnd 3000

SCTP: Assoc 0: Data chunks rcvd, local rwnd 7800
SCTP: Assoc 0: Free chunks, local rwnd 9000
SCTP: Assoc 0: Add Sack, local a_rwnd 8200
SCTP: Assoc 0: Bundle for 10.5.0.4, rem rwnd 14000, cwnd 19500, outstand 0
SCTP: Assoc 0: Bundled 12 chunks, remote rwnd 12800, outstand 1200
SCTP: Assoc 0: Bundling data, next chunk dataLen (100) > remaining mtu size

May 2008 DB-1145
Debug Commands
SCTP: Assoc 0: No additional chunks waiting.
SCTP: Assoc 0: Chunk A22F3B45 ack'd, dest 10.5.0.4, outstanding 3900
SCTP: Assoc 0: Chunk A22F3B4A ack'd, dest 10.5.0.4, outstanding 3400
SCTP: Assoc 0: Chunk A22F3B4B ack'd, dest 10.5.0.4, outstanding 3300
SCTP: Assoc 0: Chunk A22F3B4C ack'd, dest 10.5.0.4, outstanding 3200
SCTP: Assoc 0: Chunk A22F3B4D ack'd, dest 10.5.0.4, outstanding 3100
SCTP: Assoc 0: Chunk A22F3B4E ack'd, dest 10.5.0.4, outstanding 3000
SCTP: Assoc 0: Chunk A22F3B4F ack'd, dest 10.5.0.4, outstanding 2900
Table 165 debug ip sctp congestion Field Descriptions
Field Description
cwnd Congestion window values for destination address.
rwnd, a_rwnd Receiver window values as defined in RFC 2960.
outstanding Number of bytes outstanding.

show ip sctp association Shows the parameters configured for the association defined by
parameters the association identifier.
show ip sctp association statistics Shows the current statistics for the association defined by the
association identifier.
application server.

DB-1146 May 2008
Debug Commands
debug ip sctp init
debug ip sctp init

To show datagrams and other information related to the initializing of new Stream Control Transmission
Protocol (SCTP) associations, use the debug ip sctp init command in privileged EXEC mode. To disable
debug ip sctp init
no debug ip sctp init

Usage Guidelines All initialization chunks are shown, including the INIT, INIT_ACK, COOKIE_ECHO, and
COOKIE_ACK chunks. This debug command can be used to see the chunks associated with any
initialization sequence but does not display data chunks sent once the association is established.
Therefore, it is safe to use in a live system that has traffic flowing when you have trouble with
associations failing and being reestablished.
Examples The following example shows initialization chunks for SCTP associations:
Router# debug ip sctp init
*Mar 1 00:53:07.279: SCTP Test: Attempting to open assoc to remote port 8787...assoc ID
is 0
*Mar 1 00:53:07.279: SCTP: Process Assoc Request
*Mar 1 00:53:07.279: SCTP: Assoc 0: dest addr list:
*Mar 1 00:53:07.279: SCTP: addr 10.5.0.4
*Mar 1 00:53:07.279: SCTP: addr 10.6.0.4
*Mar 1 00:53:07.279:
...
*Mar 1 00:53:13.279: SCTP: Assoc 0: Send Init
*Mar 1 00:53:13.279: SCTP: INIT_CHUNK, len 42
*Mar 1 00:53:13.279: SCTP: Initiate Tag: B4A10C4D, Initial TSN: B4A10C4D, rwnd
9000
*Mar 1 00:53:13.279: SCTP: Streams Inbound: 13, Outbound: 13
*Mar 1 00:53:13.279: SCTP: IP Addr: 10.1.0.2

May 2008 DB-1147
Debug Commands
debug ip sctp init
*Mar 1 00:53:13.279: SCTP: IP Addr: 10.2.0.2

*Mar 1 00:53:13.279: SCTP: Supported addr types: 5
*Mar 1 00:53:13.307: SCTP: Process Init
*Mar 1 00:53:13.307: SCTP: INIT_CHUNK, len 42
*Mar 1 00:53:13.307: SCTP: Initiate Tag: 3C2D8327, Initial TSN: 3C2D8327, rwnd
18000
*Mar 1 00:53:13.307: SCTP: IP Addr: 10.5.0.4
*Mar 1 00:53:13.307: SCTP: IP Addr: 10.6.0.4
*Mar 1 00:53:13.307: SCTP: Supported addr types: 5
*Mar 1 00:53:13.307: SCTP: Assoc 0: Send InitAck
*Mar 1 00:53:13.307: SCTP: INIT_ACK_CHUNK, len 124
*Mar 1 00:53:13.307: SCTP: Initiate Tag: B4A10C4D, Initial TSN: B4A10C4D, rwnd
9000
*Mar 1 00:53:13.307: SCTP: Responder cookie len 88
*Mar 1 00:53:13.307: SCTP: IP Addr: 10.1.0.2
*Mar 1 00:53:13.307: SCTP: IP Addr: 10.2.0.2
*Mar 1 00:53:13.311: SCTP: Assoc 0: Process Cookie
*Mar 1 00:53:13.311: SCTP: COOKIE_ECHO_CHUNK, len 88
*Mar 1 00:53:13.311: SCTP: Assoc 0: dest addr list:
*Mar 1 00:53:13.311: SCTP: addr 10.5.0.4
*Mar 1 00:53:13.311: SCTP: addr 10.6.0.4
*Mar 1 00:53:13.311:
*Mar 1 00:53:13.311: SCTP: Instance 0 dest addr list:
*Mar 1 00:53:13.311: SCTP: addr 10.5.0.4
*Mar 1 00:53:13.311: SCTP: addr 10.6.0.4
*Mar 1 00:53:13.311:
*Mar 1 00:53:13.311: SCTP: Assoc 0: Send CookieAck
*Mar 1 00:53:13.311: SCTP: COOKIE_ACK_CHUNK
Table 166 debug ip sctp init Field Descriptions
Field Description
Initiate Tag Initiation chunk identifier.
Initial TSN Initial transmission sequence number.
rwnd Receiver window values.

show ip sctp association parameters Shows the parameters configured for the
association defined by the association identifier.
show ip sctp association statistics Shows the current statistics for the association
show iua as Shows information about the current condition of
an application server.
show iua asp Shows information about the current condition of
an application server process.

DB-1148 May 2008
Debug Commands
debug ip sctp init

May 2008 DB-1149
Debug Commands
debug ip sctp multihome

To show the source and destination of datagrams in order to monitor the use of the multihome addresses
for Stream Control Transmission Protocol (SCTP), use the debug ip sctp multihome command in
no debug ip sctp multihome

Usage Guidelines More than one IP address parameter can be included in an initialization (INIT) chunk when the INIT
sender is multihomed. Datagrams should be sent to the primary destination addresses unless the network
is experiencing problems, in which case the datagrams should be sent to secondary addresses.
Caution The debug ip sctp multihome command generates one debug line for each datagram sent or received.
It should be used with extreme caution in a live network.
Examples The following example shows source and destination for multihomed addresses:
Router# debug ip sctp multihome
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 1404

SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 476
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 28
SCTP: Assoc 0: Send Data to dest 10.5.0.4
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 28
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 28
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 1404
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 1404

DB-1150 May 2008
Debug Commands

SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 1404
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 476
SCTP: Assoc 0: Send Data to dest 10.5.0.4
SCTP: Rcvd s=10.6.0.4 8787, d=10.2.0.2 8787, len 44
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 28
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 28
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 1404
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 1404
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 1404
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 476
Table 167 debug ip sctp multihome Field Descriptions
Field Description
s Source address and port.
d Destination address and port.

show ip sctp association statistics Shows the current statistics for the association defined
by the association identifier.
application server.

May 2008 DB-1151
Debug Commands
debug ip sctp performance

To display the average number of Stream Control Transmission Protocol (SCTP) chunks and datagrams
being sent and received per second, use the debug ip sctp performance command in privileged EXEC
no debug ip sctp performance

Once enabled, the debug ip sctp performance command displays the average number of chunks and
datagrams being sent and received per second once every 10 seconds. Note that the averages are
cumulative since the last time the statistics were cleared using the clear ip sctp statistics command and
may not accurately reflect the number of datagrams and chunks currently being sent and received at that
particular moment.
Examples The following example shows a low rate of traffic:

Router# debug ip sctp performance
SCTP Sent: SCTP Dgrams 5, Chunks 28, Data Chunks 29, ULP Dgrams 29
SCTP Rcvd: SCTP Dgrams 7, Chunks 28, Data Chunks 29, ULP Dgrams 29
Chunks Discarded: 0, Retransmitted 0
SCTP Sent: SCTP Dgrams 6, Chunks 29, Data Chunks 30, ULP Dgrams 30
SCTP Rcvd: SCTP Dgrams 7, Chunks 29, Data Chunks 30, ULP Dgrams 30
Chunks Discarded: 0, Retransmitted 0

DB-1152 May 2008
Debug Commands
Table 168 debug ip sctp performance Field Descriptions
Field Description
SCTP Dgrams Datagram sent to or received from the network.
Chunks Includes data chunks and control chunks sent or received.
Data Chunks Data chunks sent or received.
ULP Dgrams Upper-layer protocol (ULP) datagrams, which are datagrams sent to or
received from the ULP or application.

application server.

May 2008 DB-1153
Debug Commands
debug ip sctp rcvchunks

To provide diagnostic information about chunks received with Stream Control Transmission Protocol
(SCTP), use the debug ip sctp rcvchunks command in privileged EXEC mode. To disable debugging
no debug ip sctp rcvchunks

Usage Guidelines The debug ip sctp rcvchunks command shows the following information about received chunks:
Whether the chunk is for a new datagram or is part of a datagram that is being reassembled
Whether the datagram is complete after receiving this chunk
If the datagram is complete, whether the datagram is in sequence within the specified stream and
can be delivered to the upper-layer protocol (ULP)
The selective acknowledgments (SACKs) that are returned to the remote SCTP peer
The cumulative transmission sequence number (Cum TSN) that was acknowledged and the number
of fragments included
Whether the datagram is received by the ULP
Caution The debug ip sctp rcvchunks command generates multiple debug lines for each chunk received. It
should be used with extreme caution in a live network.
Examples In the following example, a segmented datagram is received in two chunks for stream 0 and sequence
number 0. The length of the first chunk is 1452 bytes, and the second is 1 byte. The first chunk indicates
that it is for a new datagram, but the second chunk indicates that it is part of an existing datagram that
is already being reassembled. When the first chunk is processed, it is noted to be in sequence, but is not

DB-1154 May 2008
Debug Commands
complete and so cannot be delivered yet. When the second chunk is received, the datagram is both in
sequence and complete. The application receives the datagram, and a SACK is shown to acknowledge
that both chunks were received with no missing chunks indicated (that is, with no fragments).
Router# debug ip sctp rcvchunks
SCTP: Assoc 0: New chunk (0/0/1452/2C33D822) for new dgram (0)

SCTP: Assoc 0: dgram (0) is in seq
SCTP: Assoc 0: Add Sack Chunk, CumTSN=2C33D822, numFrags=0
SCTP: Assoc 0: New chunk (0/0/1/2C33D823) for existing dgram (0)
SCTP: Assoc 0: dgram (0) is complete
SCTP: Assoc 0: ApplRecv chunk 0/0/1452/2C33D822
SCTP: Assoc 0: ApplRecv chunk 0/0/1/2C33D823
SCTP: Assoc 0: Add Sack Chunk, CumTSN=2C33D823, numFrags=0
Table 169 debug ip sctp rcvchunks Field Descriptions
Field Description
0 / 0 / 1452 / 2C33D822 Stream number / datagram sequence number / chunk length, in bytes /
chunk transmission sequence number.
Sack Chunk Selective acknowledgment chunk.
ApplRecv Application has received the chunk.
CumTSN Cumulative transmission sequence number that is being acknowledged.
numFrags Number of fragments, or missing chunks.

application server.

May 2008 DB-1155
Debug Commands
debug ip sctp rto
debug ip sctp rto

To show adjustments that are made to the retransmission timeout (RTO) value when using Stream
Control Transmission Protocol (SCTP), use the debug ip sctp rto command in privileged EXEC mode.
debug ip sctp rto
no debug ip sctp rto

Usage Guidelines The debug ip sctp rto command shows adjustments that are made to the retransmission timeout value
(shown as retrans in the command output) because of either retransmission of data chunks or
unacknowledged heartbeats.
Caution The debug ip sctp rto command can generate a great deal of output. It should be used with extreme
caution in a live network.
Examples In the following example, there is only one destination address available. Each time the chunk needs to
be retransmitted, the RTO value is doubled.
Router# debug ip sctp rto
SCTP: Assoc 0: destaddr 10.5.0.4, retrans timeout on chunk 942BAC55

SCTP: Assoc 0: destaddr 10.5.0.4, rto backoff 2000 ms

DB-1156 May 2008
Debug Commands
debug ip sctp rto

application server.

May 2008 DB-1157
Debug Commands
debug ip sctp segments

To show short diagnostics for every datagram that is sent or received with Stream Control Transmission
Protocol (SCTP), use the debug ip sctp segments command in privileged EXEC mode. To disable
no debug ip sctp segments

Usage Guidelines The debug ip sctp segments command provides the short form of the output about datagrams. For the
verbose form, use the debug ip sctp segmentv command.
Caution The debug ip sctp segments command generates several lines of output for each datagram sent or
received. It should be used with extreme caution in a live network.
Examples The following output shows an example in which an association is established, a few heartbeats are sent,
the remote endpoint fails, and the association is restarted.
Router# debug ip sctp segments

SCTP: INIT_CHUNK, Tag: 3C72A02A, TSN: 3C72A02A
SCTP: Recv: Assoc 0: s=10.5.0.4 8787, d=10.1.0.2 8787, len 56
SCTP: INIT_CHUNK, Tag: 13E5AD6C, TSN: 13E5AD6C
SCTP: Sent: Assoc NULL: s=10.1.0.2 8787, d=10.5.0.4 8787, len 136
SCTP: INIT_ACK_CHUNK, Tag: 3C72A02A, TSN: 3C72A02A
SCTP: COOKIE_ECHO_CHUNK, len 88
SCTP: COOKIE_ACK_CHUNK
SCTP: HEARTBEAT_CHUNK

DB-1158 May 2008
Debug Commands

SCTP: INIT_CHUNK, Tag: 4F2D8235, TSN: 4F2D8235
SCTP: INIT_ACK_CHUNK, Tag: 7DD7E424, TSN: 7DD7E424
SCTP: SACK_CHUNK, TSN ack: 7DD7E423, rwnd 18000, num frags 0
SCTP: DATA_CHUNK, 4/0/100/4F2D8235
SCTP: SACK_CHUNK, TSN ack: 4F2D8235, rwnd 8900, num frags 0
SCTP: DATA_CHUNK, 4/0/100/7DD7E424
SCTP: HEARTBEAT_ACK_CHUNK
SCTP: SACK_CHUNK, TSN ack: 4F2D8236, rwnd 9000, num frags 0
SCTP: DATA_CHUNK, 7/0/100/7DD7E425
Table 170 debug ip sctp segments Field Descriptions
Field Description
len Length of chunk, in bytes.
Tag The identifier for an initialization chunk.
TSN Transmission sequence number.
rwnd Receiver window value.
num frags Number of fragments received.
7 / 0 / 100 / 4F2D8236 (Data chunks) Stream number / datagram sequence number / chunk length,
in bytes / chunk transmission sequence number.

May 2008 DB-1159
Debug Commands

debug ip sctp segmentv Shows every datagram that is sent or received and the
chunks that are contained in each. This is the verbose form
of the output, and it shows detailed information for each
chunk type.
application server.

DB-1160 May 2008
Debug Commands
debug ip sctp segmentv

To show verbose diagnostics for every datagram that is sent or received with Stream Control
Transmission Protocol (SCTP), use the debug ip sctp segmentv command in privileged EXEC mode.
no debug ip sctp segmentv

Usage Guidelines The debug ip sctp segmentv command provides the verbose form of the output for datagrams. For the
simple form, use the debug ip sctp segments command.
Caution The debug ip sctp segmentv command generates multiple lines of output for each datagram sent and
received. It should be used with extreme caution in a live network.
Examples The following output shows an example in which an association is established, a few heartbeats are sent,
the remote endpoint fails, and the association is restarted:
Router# debug ip sctp segmentv
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 56, ver tag 0
SCTP: INIT_CHUNK, len 42
SCTP: Initiate Tag: B131ED6A, Initial TSN: B131ED6A, rwnd 9000
SCTP: Streams Inbound: 13, Outbound: 13
SCTP: IP Addr: 10.1.0.2
SCTP: Supported addr types: 5
SCTP: Recv: Assoc 0: s=10.5.0.4 8787, d=10.1.0.2 8787, len 56, ver tag 0
SCTP: INIT_CHUNK, len 42
SCTP: Initiate Tag: 5516B2F3, Initial TSN: 5516B2F3, rwnd 18000

May 2008 DB-1161
Debug Commands

SCTP: Supported addr types: 5
SCTP: Sent: Assoc NULL: s=10.1.0.2 8787, d=10.5.0.4 8787, len 136, ver tag 5516B2F3
SCTP: INIT_ACK_CHUNK, len 124
SCTP: Initiate Tag: B131ED6A, Initial TSN: B131ED6A, rwnd 9000
SCTP: Responder cookie len 88
SCTP: Recv: Assoc 0: s=10.5.0.4 8787, d=10.1.0.2 8787, len 100, ver tag B131ED6A
SCTP: Sent: Assoc NULL: s=10.1.0.2 8787, d=10.5.0.4 8787, len 16, ver tag 5516B2F3
SCTP: SACK_CHUNK, len 16
SCTP: TSN ack: (0xB131ED69)
SCTP: Rcv win credit: 18000
SCTP: Num frags: 0
SCTP: DATA_CHUNK, flags 3, chunkLen 116
SCTP: DATA_CHUNK, 0/0/100/5516B2F3
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 28, ver tag 5516B2F3
SCTP: TSN ack: (0x5516B2F3)
SCTP: Rcv win credit: 8900
SCTP: Num frags: 0
SCTP: DATA_CHUNK, flags 3, chunkLen 116
SCTP: DATA_CHUNK, 0/0/100/B131ED6A
SCTP: HEARTBEAT_ACK_CHUNK
Table 171 debug ip sctp segmentv Field Descriptions
Field Description
len Length of chunk, in bytes.
ver tag Verification identifier.
Tag The identifier for an initialization chunk.
TSN Transmission sequence number.
rwnd Receive window value.
Rcv win credit Receive window value. Same as rwnd.
Num frags Number of fragments received.
0/0/100/5516B2F3 (Data chunks) Stream number / datagram sequence number / chunk length,
in bytes / chunk transmission sequence number.

DB-1162 May 2008
Debug Commands

debug ip sctp segments Shows short diagnostics for every datagram that is sent or
received with SCTP.
application server.

May 2008 DB-1163
Debug Commands
debug ip sctp signal

To show signals that are sent from Stream Control Transmission Protocol (SCTP) to the application or
upper-layer protocol (ULP), use the debug ip sctp signal command in privileged EXEC mode. To
no debug ip sctp signal

Usage Guidelines The debug ip sctp signal command can be used to see if the current associations are stable or not.
Because it generates output only on state transitions, it is safe to use in a live environment. It still should
be used with caution, however, depending on the number of associations being handled by the system
and the stability of the network.
The debug ip sctp state command is often used at the same time as the debug ip sctp signal command.
Using the two commands together gives good insight into the stability of associations.
Examples In the following example, a new association is requested and established. The peer then restarts the
association and notes that the association failed and is being reestablished. The local peer then indicates
that the association has failed because it has tried to retransmit the specified chunk more than the
maximum number of times without success. As a result, the association fails (because of communication
loss) and is terminated. The ULP requests that the association be attempted again, and this attempt
succeeds. A shutdown is then received from the remote peer, and the local peer enters the shutdown
acknowledge sent state, which is followed by the association being terminated. Again, another
association attempt is made and succeeds.
Router# debug ip sctp signal
Router# debug ip sctp state
<new assoc attempt>

00:20:08: SCTP: Assoc 0: state CLOSED -> COOKIE_WAIT
00:20:15: SCTP: Assoc 0: state COOKIE_WAIT -> ESTABLISHED

DB-1164 May 2008
Debug Commands
00:20:15: SCTP: Assoc 0: Sent ASSOC_UP signal for CONFIGD_ASSOC

00:21:03: SCTP: Assoc 0: Restart rcvd from peer
00:21:03: SCTP: Assoc 0: Sent ASSOC_RESTART signal
00:21:04: SCTP: Assoc 0: chunk 62EA7F40 retransmitted more than max times, failing assoc
00:21:04: SCTP: Assoc 0: Sent ASSOC_FAILED signal, reason: SCTP_COMM_LOST
00:21:04: SCTP: Assoc 0: Sent ASSOC_TERMINATE signal
00:21:04: SCTP: Assoc 0: state ESTABLISHED -> CLOSED
<new assoc attempt>
00:21:04: SCTP: Assoc 0: state COOKIE_WAIT -> COOKIE_ECHOED
00:21:04: SCTP: Assoc 0: state COOKIE_ECHOED -> ESTABLISHED
00:21:04: SCTP: Assoc 0: Sent TERMINATE_PENDING signal
00:21:04: SCTP: Assoc 0: state ESTABLISHED -> SHUTDOWN_ACKSENT
00:21:04: SCTP: Assoc 0: state SHUTDOWN_ACKSENT -> CLOSED
<new assoc attempt>

debug ip sctp state Shows SCTP state transitions.
application server.

May 2008 DB-1165
Debug Commands
debug ip sctp sndchunks

To show information about chunks that are being sent to remote Stream Control Transmission Protocol
(SCTP) peers, use the debug ip sctp sndchunks command in privileged EXEC mode. To disable
no debug ip sctp sndchunks

Usage Guidelines The debug ip sctp sndchunks command provides the following information:
Application send requests from the local SCTP peer
Chunks being bundled and sent to the remote peer
Processing of the selective acknowledgments (SACKs) from the remote peer, indicating which
chunks were successfully received
Chunks that are marked for retransmission
Caution The debug ip sctp sndchunks command generates large amounts of data if there is any significant
amount of traffic flowing. It should be used with extreme caution in live networks.
Examples The following example shows output for the debug ip sctp sndchunks command for a case in which
data chunks are being sent, with some of them marked for retransmission:
Router# debug ip sctp sndchunks
SCTP: Assoc 0: ApplSend, chunk: 0/10412/100/A23134F8 to 10.5.0.4

SCTP: Assoc 0: ApplSend, chunk: 5/10443/100/A23134F9 to 10.5.0.4
SCTP: Assoc 0: ApplSend, chunk: 5/10448/100/A231355C to 10.5.0.4
SCTP: Assoc 0: Set oldest chunk for dest 10.5.0.4 to TSN A23134F8
SCTP: Assoc 0: Bundling data, added 0/10412/100/A23134F8, outstanding 100

DB-1166 May 2008
Debug Commands
SCTP: Assoc 0: Bundling data, added 5/10443/100/A23134F9, outstanding 200

SCTP: Assoc 0: Bundling data, added 4/10545/100/A23134FA, outstanding 300
SCTP: Assoc 0: Bundling data, added 10/10371/100/A23134FB, outstanding 400
SCTP: Assoc 0: Bundling data, added 11/10382/100/A23134FC, outstanding 500
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A231350F, numFrags=0
SCTP: Assoc 0: Reset oldest chunk on addr 10.5.0.4 to A2313510
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A2313527, numFrags=0
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A231353F, numFrags=0
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A2313557, numFrags=0
SCTP: Assoc 0: ApplSend, chunk: 10/10385/100/A23135BE to 10.5.0.4
SCTP: Assoc 0: ApplSend, chunk: 8/10230/100/A23135BF to 10.5.0.4
SCTP: Assoc 0: ApplSend, chunk: 5/10459/100/A23135C0 to 10.5.0.4
SCTP: Assoc 0: Set oldest chunk for dest 10.5.0.4 to TSN A231355D
SCTP: Assoc 0: Bundling data, added 5/10449/100/A231355D, outstanding 100
SCTP: Assoc 0: Bundling data, added 3/10490/100/A231355E, outstanding 200
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A23135A4, numFrags=0
SCTP: Assoc 0: Reset oldest chunk on addr 10.5.0.4 to A23135A5
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A23135BC, numFrags=0
SCTP: Assoc 0: Reset oldest chunk on addr 10.5.0.4 to A23135BD
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A23135C1, numFrags=0
SCTP: Assoc 0: ApplSend, chunk: 11/10403/100/A2313626 to 10.5.0.4
SCTP: Assoc 0: Set oldest chunk for dest 10.5.0.4 to TSN A23135C2
SCTP: Assoc 0: Bundling data, added 5/10460/100/A23135C2, outstanding 100
SCTP: Assoc 0: Bundled 12 chunk(s) in next dgram to 10.5.0.4
SCTP: Assoc 0: Bundling data, added 1/10418/100/A2313622, outstanding 9700
SCTP: Assoc 0: Mark chunk A23135C2 for retrans
SCTP: Assoc 0: Mark chunk A23135CA for retrans

May 2008 DB-1167
Debug Commands
Table 172 debug ip sctp sndchunks Field Descriptions
Field Description
0 / 10412 / 100 / A23134F8 Stream number / datagram sequence number / chunk length, in
bytes / chunk transmission sequence number.
outstanding Number of bytes outstanding to the specified destination
address.
CumTSN Cumulative transmission sequence number (TSN).
numFrags Number of fragments sent.

application server.

DB-1168 May 2008
Debug Commands
debug ip sctp state
debug ip sctp state

To show state transitions in the Stream Control Transmission Protocol (SCTP), use the debug ip sctp
state command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug ip sctp state
no debug ip sctp state

Usage Guidelines The debug ip sctp state command can be used to see if the current associations are stable or not. Because
it generates output only on state transitions, it is safe to use in a live environment. It still should be used
with caution, however, depending on the number of associations being handled by the system and the
stability of the network.
The debug ip sctp state command is often used at the same time as the debug ip sctp signal command.
Using the two commands together gives good insight into the stability of associations.
Examples In the following example, a new association is requested and established. The peer then restarts the
association and notes that the association failed and is being reestablished. The local peer then indicates
that the association has failed because it has tried to retransmit the specified chunk more than the
maximum number of times without success. As a result, the association fails (because of communication
loss) and is terminated. The upper-layer protocol (ULP) requests that the association be attempted again,
and this attempt succeeds. A shutdown is then received from the remote peer, and the local peer enters
the shutdown acknowledge sent state, which is followed by the association being terminated. Again,
another association attempt is made and succeeds.
Router# debug ip sctp signal
Router# debug ip sctp state
<new assoc attempt>

00:20:15: SCTP: Assoc 0: state COOKIE_WAIT -> ESTABLISHED

May 2008 DB-1169
Debug Commands
debug ip sctp state

00:21:03: SCTP: Assoc 0: Restart rcvd from peer
00:21:03: SCTP: Assoc 0: Sent ASSOC_RESTART signal
00:21:04: SCTP: Assoc 0: chunk 62EA7F40 retransmitted more than max times, failing assoc
00:21:04: SCTP: Assoc 0: Sent ASSOC_FAILED signal, reason: SCTP_COMM_LOST
00:21:04: SCTP: Assoc 0: state ESTABLISHED -> CLOSED
<new assoc attempt>
00:21:04: SCTP: Assoc 0: Sent TERMINATE_PENDING signal
00:21:04: SCTP: Assoc 0: state ESTABLISHED -> SHUTDOWN_ACKSENT
00:21:04: SCTP: Assoc 0: state SHUTDOWN_ACKSENT -> CLOSED
<new assoc attempt>
Table 173 debug ip sctp state Field Descriptions
Field Description
CLOSED -> SCTP endpoint sends initialization chunk and moves to the
COOKIE_WAIT COOKIE_WAIT state to wait for acknowledgment and a state cookie
from the remote endpoint.
COOKIE_WAIT -> SCTP endpoint returns the state cookie to the remote endpoint and
COOKIE_ECHOED enters COOKIE_ECHOED state.
COOKIE_ECHOED -> SCTP endpoint enters ESTABLISHED state after receiving
ESTABLISHED acknowledgment that the state cookie has been received by the remote
endpoint.
ESTABLISHED -> SCTP endpoint enters SHUTDOWN_ACKSENT state after receiving a
SHUTDOWN_ACKSENT shutdown message and sending a shutdown acknowledgment to the
remote endpoint.
SHUTDOWN_ACKSENT SCTP endpoint enters CLOSED state.
-> CLOSED

DB-1170 May 2008
Debug Commands
debug ip sctp state

debug ip sctp signal Shows signals that are sent from SCTP to the application or
ULP.
application server.

May 2008 DB-1171
Debug Commands
debug ip sctp timer
debug ip sctp timer

To provide information about Stream Control Transmission Protocol (SCTP) timers that are started,
stopped, and triggering, use the debug ip sctp timer command in privileged EXEC mode. To disable
debug ip sctp timer
no debug ip sctp timer

Usage Guidelines Many SCTP timers should not be restarted after they have been started once. For these timers, the first
call succeeds in starting the timer, and subsequent calls do nothing until the timer either expires or is
stopped. For example, the retransmission timer is started when the first chunk is sent, but then is not
started again for subsequent chunks when there is outstanding data.
Caution The debug ip sctp timer command generates a significant amount of output. It should be used with
extreme caution in a live network.
Examples The following example shows the starting and stopping of various SCTP timers:
Router# debug ip sctp timer
SCTP: Assoc 0: Starting CUMSACK timer

SCTP: Timer already started, not restarting
SCTP: Assoc 0: Timer BUNDLE triggered
SCTP: Assoc 0: Starting RETRANS timer for destaddr 10.5.0.4

DB-1172 May 2008
Debug Commands
debug ip sctp timer

SCTP: Assoc 0: Stopping RETRANS timer for destaddr 10.5.0.4
SCTP: Assoc 0: Stopping RETRANS timer for destaddr 10.5.0.4
SCTP: Assoc 0: Stopping CUMSACK timer
Table 174 debug ip sctp timer Field Descriptions
Field Description
CUMSACK Cumulative selective acknowledgment.
RETRANS Retransmission.

show ip sctp association parameters Shows the parameters configured for the association defined
show ip sctp association statistics Shows the current statistics for the association defined by the
association identifier.
application server.

May 2008 DB-1173
Debug Commands
debug ip sctp warnings

To display diagnostic information about unusual situations in Stream Control Transmission Protocol
(SCTP), use the debug ip sctp warnings command in privileged EXEC mode. To disable debugging
no debug ip sctp warnings

useful. They show any association or destination address failures and can be used to monitor the stability
of established associations.
The debug ip sctp warnings command displays information on any unusual situation that is
encountered. These situations may or may not indicate problems, depending on the particulars of the
situation.
Examples The following example shows some events and conditions that are flagged as warnings:
Router# debug ip sctp warnings
SCTP: Assoc 0: No cookie in InitAck, discarding

SCTP: Assoc 0: Incoming INIT_ACK: inbound streams reqd 15, allowed 13
SCTP: Assoc 0: Incoming INIT_ACK request: outbound streams req'd 13, allowed 1
SCTP: Assoc 0: Remote verification tag in init ack is zero, discarding
SCTP: Remote verification tag in init is zero, discarding
SCTP: Assoc 0: Rwnd less than min allowed (1500) in incoming INITACK, rcvd 0
SCTP: Assoc 0: Rwnd less than min allowed (1500) in incoming INITACK, rcvd 1499
SCTP: Rwnd in INIT too small (0), discarding
SCTP: Rwnd in INIT too small (1499), discarding
SCTP: Unknown INIT param 16537 (0x4099), length 8
SCTP: Assoc 0: Unknown INITACK param 153 (0x99), length 8

DB-1174 May 2008
Debug Commands
SCTP: Processing INIT, invalid param len 0, discarding...

SCTP: Assoc 0: Processing INITACK, invalid param len 0, discarding...

application server.

May 2008 DB-1175
Debug Commands
debug ip sd
debug ip sd
To display all session directory (SD) announcements received, use the debug ip sd command in
debug ip sd
no debug ip sd
Usage Guidelines This command shows session directory announcements for multicast IP. Use it to observe multicast
activity.
Examples The following is sample output from the debug ip sd command:

Router# debug ip sd
SD: Announcement from 172.16.58.81 on Serial0.1, 146 bytes

s=*cisco: CBONE Audio
i=cisco internal-only audio conference
o=dino@dino-ss20.cisco.com
c=224.0.255.1 16 2891478496 2892688096
m=audio 31372 1700
SD: Announcement from 172.22.246.68 on Serial0.1, 147 bytes
s=IMS: U.S. Senate
i=U.S. Senate at http://town.hall.org/radio/live.html
o=carl@also.radio.com
c=224.2.252.231 95 0 0
m=audio 36572 2642
a=fmt:gsm
Table 175 debug ip sd Field Descriptions
Field Description
SD Session directory event.
Announcement from Address sending the SD announcement.
on Serial0.1 Interface receiving the announcement.
146 bytes Size of the announcement event.
s= Session name being advertised.
i= Information providing a descriptive name for the session.
o= Origin of the session, either an IP address or a name.

DB-1176 May 2008
Debug Commands
debug ip sd
Table 175 debug ip sd Field Descriptions (continued)
Field Description
c= Connect description showing address and number of hops.
m= Media description that includes media type, port number, and ID.

debug ip igmp Displays IGMP packets received and sent, and IGMP host-related
events.
debug ip mbgp dampening Logs route flap dampening activity related to MBGP.
debug ip mrouting Displays changes to the IP multicast routing table.
debug ip pim Displays PIM packets received and sent, and PIM-related events.

May 2008 DB-1177
Debug Commands
debug ip sdee
debug ip sdee
To enable debugging messages for Security Device Event Exchange (SDEE) notification events, use the
debug ip sdee command in privileged EXEC mode. To disable SDEE debugging messages, use the no
debug ip sdee [alerts] [detail] [messages] [requests] [subscriptions]
no debug ip sdee [alerts] [detail] [messages] [requests] [subscriptions]
Syntax Description alerts Displays new alerts that are reported to SDEE from IPS.
detail Displays detailed SDEE messages.
messages Displays error and status messages that are reported to SDEE from IPS.
requests Displays SDEE client requests.
subscriptions Displays SDEE client subscription requests.

Examples The following is sample SDEE debug output. In this example, you can see which messages correspond
to SDEE alerts, requests, and subscriptions.
Router# debug ip sdee alerts requests subscriptions
5d00h:SDEE:got request from client at 10.0.0.2

5d00h:SDEE:reported 13 events for client at 10.0.0.2
5d00h:SDEE:GET request for client 10.0.0.2 subscription IDS1720:0
5d00h:SDEE:reported 50 events for client 10.0.0.2 subscription IDS1720:0
5d00h: SDEE alert:sigid 2004 name ICMP Echo Req from 10.0.0.2 time 1021174067
5d00h:SDEE:missed events for IDS1720:0

ip ips notify Specifies the method of event notification.
ip sdee events Sets the maximum number of SDEE events that can be stored in the event
buffer.
ip sdee subscriptions Sets the maximum number of SDEE subscriptions that can be open
simultaneously.

DB-1178 May 2008
Debug Commands
debug ip security
debug ip security
To display IP security option processing, use the debug ip security command in privileged EXEC mode.
debug ip security
no debug ip security
Usage Guidelines The debug ip security command displays information for both basic and extended IP security options.
For interfaces where ip security is configured, each IP packet processed for that interface results in
debugging output regardless of whether the packet contains IP security options. IP packets processed for
other interfaces that also contain IP security information also trigger debugging output. Some additional
IP security debugging information is also controlled by the debug ip packet command in privileged
EXEC mode.
Caution Because the debug ip security command generates a substantial amount of output for every IP packet
processed, use it only when traffic on the IP network is low, so other activity on the system is not
adversely affected.
Examples The following is sample output from the debug ip security command:
Router# debug ip security
IP Security: src 172.24.72.52 dst 172.24.72.53, number of BSO 1

idb: NULL
pak: insert (0xFF) 0x0
IP Security: BSO postroute: SECINSERT changed to secret (0x5A) 0x10
IP Security: src 172.24.72.53 dst 172.24.72.52, number of BSO 1
idb: secret (0x6) 0x10 to secret (0x6) 0x10, no implicit
def secret (0x6) 0x10
pak: secret (0x5A) 0x10
IP Security: checking BSO 0x10 against [0x10 0x10]
IP Security: classified BSO as secret (0x5A) 0x10

May 2008 DB-1179
Debug Commands
debug ip security
Table 176 describes significant fields shown in the display.
Table 176 debug ip security Field Descriptions
Field Description
number of BSO Indicates the number of basic security options found in the packet.
idb Provides information on the security configuration for the incoming
interface.
pak Provides information on the security classification of the incoming
packet.
src Indicates the source IP address.
dst Indicates the destination IP address.
The following line indicates that the packet was locally generated, and it has been classified with the
internally significant security level insert (0xff) and authority information of 0x0:
idb: NULL
pak: insert (0xff) 0x0
The following line indicates that the packet was received via an interface with dedicated IP security
configured. Specifically, the interface is configured at security level secret and with authority
information of 0x0. The packet itself was classified at level secret (0x5a) and authority information of
0x10.
idb: secret (0x6) 0x10 to secret (0x6) 0x10, no implicit
def secret (0x6) 0x10
pak: secret (0x5A) 0x10

DB-1180 May 2008
Debug Commands
debug ip sla error
debug ip sla error

To enable debugging output of Cisco IOS IP Service Level Agreements (SLAs) operation run-time
errors, use the debug ip sla error command in privileged EXEC mode. To disable debugging output, use
debug ip sla error [operation-number]
no debug ip sla error [operation-number]
Syntax Description operation-number (Optional) Identification number of the operation for which debugging output
is to be enabled.

12.4(4)T This command was introduced. This command replaces the debug ip sla
monitor error command.
12.0(32)SY This command was integrated into Cisco IOS Release 12.0(32)SY.
12.2(33)SRB This command was integrated into Cisco IOS Release 12.2(33)SRB. This
command replaces the debug rtr error command.
Usage Guidelines The debug ip sla error command displays run-time errors. When an operation number other than 0 is
specified, all run-time errors for that operation are displayed when the operation is active. When the
operation number is 0, all run-time errors relating to the IP SLAs scheduler process are displayed. When
no operation number is specified, all run-time errors for all active operations configured on the router
are displayed.
Note Use the debug ip sla error command before using the debug ip sla trace command because the debug
ip sla error command generates a lesser amount of debugging output.
Examples The following is sample output from the debug ip sla error command. The output indicates failure
because the target is not there or because the responder is not enabled on the target. All debugging output
for IP SLAs (including the output from the debug ip sla trace command) has the format shown in
Table 177.
Router# debug ip sla error
May 5 05:00:35.483: control message failure:1


May 2008 DB-1181
Debug Commands
debug ip sla error

Table 177 debug ip sla error Field Descriptions
Field Description
IP SLA Monitor 1 Number of the operation generating the message.
Error Return Code Message identifier indicating the error type (or error itself).
LU0 IP SLA Monitor Probe 1 Name of the process generating the message.
in echoTarget on call luReceive Supplemental messages that pertain to the message identifier.
LuApiReturnCode of
InvalidHandle - invalid host name
or API handle

debug ip sla trace Traces the execution of an IP SLAs operation.

DB-1182 May 2008
Debug Commands
debug ip sla ethernet-monitor
debug ip sla ethernet-monitor

To enable debugging output for a Cisco IOS IP Service Level Agreements (SLAs) Ethernet operation,
use the debug ip sla ethernet-monitor command in privileged EXEC mode. To disable debugging
debug ip sla ethernet-monitor [operation-number]
no debug ip sla ethernet-monitor [operation-number]
Syntax Description operation-number (Optional) Number of the Ethernet operation for which the debugging output
will be displayed.
Command Default Debug is not enabled.

Examples The following is sample output from the debug ip sla ethernet-monitor command:
Router# debug ip sla ethernet-monitor
00:00:15: IP SLAs Auto Ethernet(0):vlan = 2, domain = DOMAIN_OPERATOR_L3_1, mpid = 6322

from CFM
00:00:15: IP SLAs Auto Ethernet(0):saaHandleEventFromCFM::Received Event from CFM
00:00:15: IP SLAs Auto Ethernet(0):Event::ECFM_SAA_EV_MEP_ADD
00:00:15: IP SLAs Auto Ethernet(0):1 auto-probes found for domain = DOMAIN_OPERATOR_L3_1
and vlan = 2
00:00:15: IP SLAs Auto Ethernet(0):autoProbe probe_id = 1
00:00:15: IP SLAs Auto Ethernet(0):0 Probes already running in auto-probe = 1
00:00:15: IP SLAs Auto Ethernet(1):starting probe with freq = 20 sec
00:00:15: IP SLAs Auto Ethernet(1):starting probe 100001

ip sla Begins configuration for an IP SLAs operation and enters IP SLA
configuration mode.
ip sla Begins configuration for an IP SLAs auto Ethernet operation and enters IP
ethernet-monitor SLA Ethernet monitor configuration mode.

May 2008 DB-1183
Debug Commands
debug ip sla monitor error

Note Effective with Cisco IOS Release 12.4(4)T, the debug ip sla monitor error command is replaced by the
debug ip sla error command. See the debug ip sla error command for more information.
To enable debugging output of Cisco IOS IP Service Level Agreements (SLAs) operation run-time
errors, use the debug ip sla monitor error command in privileged EXEC mode. To disable debugging
debug ip sla monitor error [operation-number]
no debug ip sla monitor error [operation-number]
Syntax Description operation-number (Optional) Identification number of the operation for which debugging output
is to be enabled.

12.3(14)T This command was introduced. This command replaces the debug rtr error
command.
12.4(4)T This command was replaced by the debug ip sla error command.
Usage Guidelines The debug ip sla monitor error command displays run-time errors. When an operation number other
than 0 is specified, all run-time errors for that operation are displayed when the operation is active. When
the operation number is 0, all run-time errors relating to the IP SLAs scheduler process are displayed.
When no operation number is specified, all run-time errors for all active operations configured on the
router are displayed.
Note Use the debug ip sla monitor error command before using the debug ip sla monitor trace command
because the debug ip sla monitor error command generates a lesser amount of debugging output.
Examples The following is sample output from the debug ip sla monitor error command. The output indicates
failure because the target is not there or because the responder is not enabled on the target. All debugging
output for IP SLAs (including the output from the debug ip sla monitor trace command) has the format
shown in Table 178.

DB-1184 May 2008
Debug Commands
Router# debug ip sla monitor error

Table 178 debug ip sla monitor error Field Descriptions
Field Description
IP SLA Monitor 1 Number of the operation generating the message.
Error Return Code Message identifier indicating the error type (or error itself).
LU0 IP SLA Monitor Probe 1 Name of the process generating the message.
in echoTarget on call luReceive Supplemental messages that pertain to the message identifier.
LuApiReturnCode of
InvalidHandle - invalid host name
or API handle

debug ip sla monitor trace Traces the execution of an IP SLAs operation.

May 2008 DB-1185
Debug Commands
debug ip sla monitor mpls-lsp-monitor
debug ip sla monitor mpls-lsp-monitor

To enable debugging output for the IP Service Level Agreements (SLAs) label switched path (LSP)
Health Monitor, use the debug ip sla monitor mpls-lsp-monitor command in privileged EXEC mode.
debug ip sla monitor mpls-lsp-monitor [operation-number]
no debug ip sla monitor mpls-lsp-monitor [operation-number]
Syntax Description operation-number (Optional) Number of the LSP Health Monitor operation for which the
debugging output will be displayed.

Examples The following is sample output from the debug ip sla monitor mpls-lsp-monitor command:
Router# debug ip sla monitor mpls-lsp-monitor
IP SLA Monitor MPLSLM debugging for all entries is on

*Aug 19 19:59: IP SLA Monitor MPLSLM(1):Next hop 10.10.10.8 added in AddQ
*Aug 19 19:59: IP SLA Monitor MPLSLM(1):Adding vrf red into tree entry 10.10.10.8
*Aug 19 19:59: IP SLA Monitor MPLSLM(1):Adding Probe 100005
*Aug 19 19:59: IP SLA Monitor MPLSLM(1):Adding ProbeID 100005 to tree entry 10.10.10.8 (1)
*Aug 19 19:59: IP SLA Monitor MPLSLM(1):Adding vrf blue into tree entry 10.10.10.8
*Aug 19 19:59: IP SLA Monitor MPLSLM(1):Duplicate in AddQ 10.10.10.8
*Aug 19 19:59: IP SLA Monitor MPLSLM(1):Adding vrf green into tree entry 10.10.10.8
*Aug 19 19:59: IP SLA Monitor MPLSLM(1):Duplicate in AddQ 10.10.10.8
*Aug 19 19:59: IP SLA Monitor MPLSLM(1):Added Probe(s) 100005 will be scheduled after 26
secs over schedule period 60

auto ip sla Begins configuration for an IP SLAs LSP Health Monitor operation and
mpls-lsp-monitor enters auto IP SLA MPLS configuration mode.

DB-1186 May 2008
Debug Commands
debug ip sla monitor trace

Note Effective with Cisco IOS Release 12.4(4)T, the debug ip sla monitor trace command is replaced by the
debug ip sla trace command. See the debug ip sla trace command for more information.
To trace the execution of a Cisco IOS IP Service Level Agreements (SLAs) operation, use the debug ip
sla monitor trace command in privileged EXEC mode. To disable trace debugging output, use the no
debug ip sla monitor trace [operation-number]
no debug ip sla monitor trace [operation-number]
Syntax Description: operation-number (Optional) Identification number of the operation for which debugging output
is to be enabled.

12.3(14)T This command was introduced. This command replaces the debug
rtr trace command.
12.4(4)T This command was replaced by the debug ip sla trace command.
Usage Guidelines When an operation number other than 0 is specified, execution for that operation is traced. When the
operation number is 0, the IP SLAs scheduler process is traced. When no operation number is specified,
all active operations are traced.
The debug ip sla monitor trace command also enables debug ip sla monitor error command for the
specified operation. However, the no debug ip sla monitor trace command does not disable the debug
ip sla monitor error command. You must manually disable the command by using the no debug ip sla
monitor error command.
All debuggng output (including debug ip sla monitor error command output) has the format shown in
the debug ip sla monitor error command output example.
Note The debug ip sla monitor trace command can generate a large number of debug messages. First use the
debug ip sla monitor error command, and then use the debug ip sla monitor trace on a per-operation
basis.

May 2008 DB-1187
Debug Commands
Examples The following is sample output from the debug ip sla monitor trace command. In this example, an
operation is traced through a single operation attempt: the setup of a connection to the target, and the
attempt at an echo to calculate UDP packet response time.
Router# debug ip sla monitor trace
Router# IP SLA Monitor 1:Starting An Echo Operation - IP SLA Monitor Probe 1
May 5 05:25:08.584:rtt hash insert :3.0.0.3 3383

May 5 05:25:08.584:source=3.0.0.3(3383) dest-ip=5.0.0.1(9)
May 5 05:25:08.588:sending control msg:
May 5 05:25:08.588: Ver:1 ID:51 Len:52
May 5 05:25:08.592:cmd:command:RTT_CMD_UDP_PORT_ENABLE, ip:5.0.0.1, port:9, duration:5000
May 5 05:25:08.607:receiving reply
May 5 05:25:08.607: Ver:1 ID:51 Len:8
May 5 05:25:08.623:local delta:8
May 5 05:25:08.627:delta from responder:1
May 5 05:25:08.627:received <16> bytes and responseTime = 3 (ms)
May 5 05:25:08.631:rtt hash remove:3.0.0.3 3383IP SLA Monitor 1:Starting An Echo
Operation - IP SLA Monitor Probe 1

May 5 05:26:08.108: Ver:1 ID:52 Len:52
May 5 05:26:08.127: Ver:1 ID:52 Len:8

debug ip sla monitor error Enables debugging output of IP SLAs operation run-time
errors.

DB-1188 May 2008
Debug Commands
debug ip sla mpls-lsp-monitor

To enable debugging output for the IP Service Level Agreements (SLAs) label switched path (LSP)
Health Monitor, use the debug ip sla mpls-lsp-monitor command in privileged EXEC mode. To disable
debug ip sla mpls-lsp-monitor [operation-number]
no debug ip sla mpls-lsp-monitor [operation-number]
Syntax Description operation-number (Optional) Number of the LSP Health Monitor operation for which the
debugging output will be displayed.

12.2(33)SRB This command was integrated into Cisco IOS Release 12.2(33)SRB. This
command replaces the debug rtr mpls-lsp-monitor command.
Examples The following is sample output from the debug ip sla mpls-lsp-monitor command:
Router# debug ip sla mpls-lsp-monitor
IP SLAs MPLSLM debugging for all entries is on

*Aug 19 19:59: IP SLAs MPLSLM(1):Next hop 10.10.10.8 added in AddQ
*Aug 19 19:59: IP SLAs MPLSLM(1):Adding vrf red into tree entry 10.10.10.8
*Aug 19 19:59: IP SLAs MPLSLM(1):Adding Probe 100005
*Aug 19 19:59: IP SLAs MPLSLM(1):Adding ProbeID 100005 to tree entry 10.10.10.8 (1)
*Aug 19 19:59: IP SLAs MPLSLM(1):Adding vrf blue into tree entry 10.10.10.8
*Aug 19 19:59: IP SLAs MPLSLM(1):Duplicate in AddQ 10.10.10.8
*Aug 19 19:59: IP SLAs MPLSLM(1):Adding vrf green into tree entry 10.10.10.8
*Aug 19 19:59: IP SLAs MPLSLM(1):Duplicate in AddQ 10.10.10.8
*Aug 19 19:59: IP SLAs MPLSLM(1):Added Probe(s) 100005 will be scheduled after 26 secs
over schedule period 60

May 2008 DB-1189
Debug Commands

auto ip sla Begins configuration for an IP SLAs LSP Health Monitor operation and
mpls-lsp-monitor enters auto IP SLA MPLS configuration mode.

DB-1190 May 2008
Debug Commands
debug ip sla trace
debug ip sla trace

To trace the execution of a Cisco IOS IP Service Level Agreements (SLAs) operation, use the debug ip
sla trace command in privileged EXEC mode. To disable trace debugging output, use the no form of this
command.
debug ip sla trace [operation-number]
no debug ip sla trace [operation-number]
Syntax Description: operation-number (Optional) Identification number of the operation for which debugging output
is to be enabled.

12.4(4)T This command was introduced. This command replaces the debug ip
sla monitor trace command.
This command replaces the debug rtr trace command.
Usage Guidelines When an operation number other than 0 is specified, execution for that operation is traced. When the
operation number is 0, the IP SLAs scheduler process is traced. When no operation number is specified,
all active operations are traced.
The debug ip sla trace command also enables debug ip sla error command for the specified operation.
However, the no debug ip sla trace command does not disable the debug ip sla error command. You
must manually disable the command by using the no debug ip sla error command.
All debuggng output (including debug ip sla error command output) has the format shown in the debug
ip sla error command output example.
Note The debug ip sla trace command can generate a large number of debug messages. First use the debug
ip sla error command, and then use the debug ip sla trace on a per-operation basis.
Examples The following is sample output from the debug ip sla trace command. In this example, an operation is
traced through a single operation attempt: the setup of a connection to the target, and the attempt at an
echo to calculate UDP packet response time.

May 2008 DB-1191
Debug Commands
debug ip sla trace
Router# debug ip sla trace
Router# IP SLA Monitor 1:Starting An Echo Operation - IP SLA Monitor Probe 1

May 5 05:25:08.588: Ver:1 ID:51 Len:52
May 5 05:25:08.607: Ver:1 ID:51 Len:8

May 5 05:26:08.108: Ver:1 ID:52 Len:52
May 5 05:26:08.127: Ver:1 ID:52 Len:8

debug ip sla error Enables debugging output of IP SLAs operation run-time
errors.

DB-1192 May 2008
Debug Commands
debug ip slb
debug ip slb
To display debugging messages for the Cisco IOS Server Load Balancing (SLB) feature, use the debug
ip slb command in user EXEC or privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug ip slb {conns [acl-number] | dfp | firewallfarm | fragments | gtp | icmp | kal-ap | natpool
| probe | reals | replication | route | sessions [gtp | ipmobile | radius] | sticky gtp imsi |
vservers | all}
no debug ip slb {conns [acl-number] | dfp | firewallfarm | fragments | gtp | icmp | kal-ap | natpool
| probe | reals | replication | route | sessions [gtp | ipmobile | radius] | sticky gtp imsi |
vservers | all}
Syntax Description all Displays all debugging messages for Cisco IOS SLB.
conns [acl-number] Displays debugging messages for all connections being handled by
IOS SLB, including Wireless Session Protocol (WSP) events and
states.
The optional acl-number argument references an IP access control
list (ACL). This argument limits the information displayed based on
the client IP address, real server IP address, or virtual server IP
address:
For simple ACLs, IOS SLB checks the client IP address.
For extended ACLs, IOS SLB checks the client real and virtual
IP addresses.
For more information about ACLs, refer to the Configuring IP
Services chapter of the Cisco IOS IP Configuration Guide, Release
12.2.
dfp Displays debugging messages for Dynamic Feedback Protocol
(DFP).
To display debugging messages for the DFP agent subsystem,
use the debug ip dfp agent command.
To display debugging messages for the general packet radio
service (GPRS) DFP weight calculation, use the debug gprs dfp
command.
firewallfarm Displays debugging messages related to firewall load balancing.
fragments Displays debugging messages related to the IOS SLB fragment
database.
gtp Displays all GPRS Tunneling Protocol (GTP)-related packet handler,
gateway GPRS support node (GGSN), serving GPRS support node
(SGSN), and Network Service Access Point Identifier (NSAPI)
debugging messages for IOS SLB.
icmp Displays all Internet Control Message Protocol debugging messages
for IOS SLB.
kal-ap Displays all KeepAlive Application Protocol (KAL-AP) debugging
messages for IOS SLB.

May 2008 DB-1193
Debug Commands
debug ip slb
natpool Displays debugging messages related to the IOS SLB client Network
Address Translation (NAT) pool.
probe Displays debugging messages related to probes.
reals Displays debugging messages for all real servers defined to
IOS SLB.
replication Displays debugging messages related to IOS SLB stateful backup
virtual server.
route Displays debugging messages for all routing handled by the IOS SLB
RADIUS framed-IP sticky database.
sessions [gtp | ipmobile | Displays debugging messages for all sessions being handled by
radius] IOS SLB.
The optional gtp keyword enables users to limit the information
displayed to only GTP sessions.
The optional ipmobile keyword enables users to limit the
information displayed to only Mobile IP sessions.
The optional radius keyword enables users to limit the information
displayed to only RADIUS sessions.
sticky gtp imsi Displays all debugging messages related to the IOS SLB GTP
International Mobile Subscriber ID (IMSI) sticky database.
vservers Displays debugging messages for all virtual servers defined to
IOS SLB.
Command Modes User EXEC or privileged EXEC (#)

12.0(7)XE This command was introduced.
12.2 This command was integrated into Cisco IOS Release 12.2.
12.1(2)E The natpool and replication keywords were added.
12.1(3a)E The firewallfarm keyword was added.
12.1(7)E The vservers keyword was added.
12.1(9)E The sessions keyword was added.
12.1(11b)E The route keyword, the acl-number argument, and the radius option
on the sessions keyword were added.
12.1(13)E3 The gtp keyword and the gtp option on the sessions keyword were
added.
12.2(14)ZA2 The ipmobile keyword was added.
12.2(18)SXE The sticky gtp imsi keywords were added.

DB-1194 May 2008
Debug Commands
debug ip slb
12.2(33)SRC The kal-ap keyword was added.
Usage Guidelines This command displays debugging messages for IOS SLB.
See the following caution before using debug commands:
Examples The following example configures a debugging session to check all IP IOS SLB parameters:
Router# debug ip slb all
SLB All debugging is on

Router#


Router#
The following example configures debugging to check IP IOS SLB replication used with stateful backup
and displays the output from the send or transmit virtual server:
Router# debug ip slb replication
*Mar 2 08:02:38.019: SLB Replicate: (send) update vs: VS1 update_count 42
The following example shows Cisco IOS SLB DFP debug output:
Router# debug ip slb dfp
SLB DFP debugging is on

router#
022048 SLB DFP Queue to main queue - type 2 for Agent 161.44.2.3458229
022048 SLB DFP select_rc = -1 readset = 0
022048 SLB DFP Sleeping ...
022049 SLB DFP readset = 0
022049 SLB DFP Processing Q event for Agent 161.44.2.3458229 - OPEN
022049 SLB DFP Queue to conn_proc_q - type 2 for Agent 161.44.2.3458229
022049 SLB DFP Set SLB_DFP_SIDE_QUEUE
022049 SLB DFP Processing Conn Q event for Agent 161.44.2.3458229 - OPEN
022049 SLB DFP Open to Agent 161.44.2.3458229 succeeded, socket = 0
022049 SLB DFP Agent 161.44.2.3458229 start connect
022049 SLB DFP Connect to Agent 161.44.2.3458229 successful - socket 0
022049 SLB DFP Processing Conn Q unknown MAJOR 80
022049 SLB DFP Reset SLB_DFP_SIDE_QUEUE

May 2008 DB-1195
Debug Commands
debug ip slb

022050 SLB DFP select_rc = 1 readset = 1
022050 SLB DFP Agent 161.44.2.3458229 fd = 0 readset = 1
022050 SLB DFP Message length 44 from Agent 161.44.2.3458229
022050 SLB DFP Agent 161.44.2.3458229 setting Host 17.17.17.17, Bind ID 1 Weight 1
022050 SLB DFP Processing Q event for Agent 161.44.2.3458229 - WAKEUP

022050 SLB DFP select_rc = 1 readset = 1
022050 SLB DFP Agent 161.44.2.3458229 fd = 0 readset = 1
022050 SLB DFP Message length 64 from Agent 161.44.2.3458229
022116 SLB DFP Processing Q event for Agent 161.44.2.3458229 - DELETE
022116 SLB DFP Queue to conn_proc_q - type 5 for Agent 161.44.2.3458229

022116 SLB DFP Processing Conn Q event for Agent 161.44.2.3458229 - DELETE
022116 SLB DFP Connection to Agent 161.44.2.3458229 closed
022116 SLB DFP Agent 161.44.2.3458229 deleted
022116 SLB DFP Processing Conn Q unknown MAJOR 80

DB-1196 May 2008
Debug Commands
debug ip snat
debug ip snat
To display information about IP packets translated by the IP stateful network address translation (SNAT)
feature, use the debug ip snat command in privileged EXEC mode. To disable debugging output, use
debug ip snat [detailed]
no debug ip snat [detailed]
Syntax Description detailed (Optional) Displays debug information in a detailed format.
Defaults Disabled

Usage Guidelines The SNAT feature allows two or more network address translators to function as a translation group. One
member of the translation group handles traffic requiring translation of IP address information. It
informs the backup translator of active flows as they occur. The backup translator can then use
information from the active translator to prepare duplicate translation table entries enabling the backup
translator to become the active translator in the event of a critical failure. Traffic continues to flow
without interruption because the same network address translations are used and the state of those
translations has been previously defined.
Caution Because the debug ip snat command generates a significant amount of output, use it only when traffic
Examples The following is sample output from the debug ip snat command:
Router# debug ip snat detailed
2w6d:SNAT:Establish TCP peers for PRIMARY

2w6d:SNAT (Send):Enqueuing SYNC Message for Router-Id 100
2w6d:SNAT(write2net):192.168.123.2 <---> 192.168.123.3 send message
2w6d:SNAT(write2net):ver 2, id 100, opcode 1, len 68
2w6d:SNAT (Send):Enqueuing DUMP-REQUEST Message for Router-Id 100

May 2008 DB-1197
Debug Commands
debug ip snat
2w6d:SNAT (readfromnet):Enqueuing SYNC Message msg to readQ

2w6d:SNAT (Receive):Processed SYNC Message from Router-Id:0 for Router-Id:200's
entry/entries
2w6d:SNAT (readfromnet):Enqueuing DUMP-REQUEST Message msg to readQ
try/entries
2w6d:SNAT(sense):Send SYNC message
2w6d:SNAT (Send):Enqueuing SYNC Message for Router-Id 100
2w6d:SNAT (readfromnet):Enqueuing SYNC Message msg to readQ
2w6d:SNAT (Receive):Processed SYNC Message from Router-Id:200 for Router-Id:200's
entry/entries
Table 179 debug ip snat Field Descriptions
Field Description
SNAT: Indicates that the packet is being translated by the SNAT feature.
DUMP-REQUEST Message Requests for entries after the SNAT router is active.

DB-1198 May 2008
Debug Commands
debug ip socket
debug ip socket
To display all state change information for all sockets, use the debug ip socket command in privileged
debug ip socket
no debug ip socket
Usage Guidelines Use this command to collect information on the socket interface. To get more complete information on
a socket/TCP port pair, use this command in conjunction with the debug ip tcp transactions command.
Because the socket debugging information is state-change oriented, you will not see the debugging
message on a per-packet basis. However, if the connections normally have very short lives (few packet
exchanges during the life cycle of a connection), then socket debugging could become expensive because
of the state changes involved during connection setup and teardown.
Examples The following is sample output from the debug ip socket output from a server process:
Router# debug ip socket
Added socket 0x60B86228 to process 40

SOCKET: set TCP property TCP_PID, socket 0x60B86228, TCB 0x60B85E38
Accepted new socket fd 1, TCB 0x60B85E38
SOCKET: set TCP property TCP_PID, socket 0x60B86798, TCB 0x60B877C0
SOCKET: set TCP property TCP_BIT_NOTIFY, socket 0x60B86798, TCB 0x60B877C0
SOCKET: created new socket to TCP, fd 2, TCB 0x60B877C0
SOCKET: bound socket fd 2 to TCB 0x60B877C0
SOCKET: set TCP property TCP_WINDOW_SIZE, socket 0x60B86798, TCB 0x60B877C0
SOCKET: listen on socket fd 2, TCB 0x60B877C0
SOCKET: closing socket 0x60B86228, TCB 0x60B85E38
SOCKET: socket event process: socket 0x60B86228, TCB new state --> FINWAIT1
socket state: SS_ISCONNECTED SS_CANTSENDMORE SS_ISDISCONNECTING
SOCKET: Removed socket 0x60B86228 from process 40 socket list
The following is sample output from the debug ip socket command from a client process:
Router# debug ip socket

SOCKET: set TCP property TCP_PID, socket 0x60B70220, TCB 0x60B6CFDC
SOCKET: set TCP property TCP_BIT_NOTIFY, socket 0x60B70220, TCB 0x60B6CFDC
SOCKET: created new socket to TCP, fd 0, TCB 0x60B6CFDC
SOCKET: socket event process: socket 0x60B70220, TCB new state --> SYNSENT
socket state: SS_ISCONNECTING
SOCKET: socket event process: socket 0x60B70220, TCB new state --> ESTAB
socket state: SS_ISCONNECTING
SOCKET: closing socket 0x60B70220, TCB 0x60B6CFDC

May 2008 DB-1199
Debug Commands
debug ip socket
SOCKET: socket event process: socket 0x60B70220, TCB new state --> FINWAIT1
socket state: SS_ISCONNECTED SS_CANTSENDMORE SS_ISDISCONNECTING
SOCKET: Removed socket 0x60B70220 from process 2 socket list
Table 180 debug ip socket Field Descriptions
Field Description
Added socket 0x60B86228 process 40 New socket is opened for process 40.
SOCKET Indicates that this is a SOCKET transaction.
set TCP property TCP_PID Sets the process ID to the TCP associated with the socket.
socket 0x60B86228, TCB 0x60B85E38 Address for the socket/TCP pair.
set TCP property TCP_BIT_NOTIFY Sets the method for how the socket wants to be notified for
an event.
created new socket to TCP, fd 2 Opened a new socket referenced by file descriptor 2 to TCP.
bound socket fd 2 to TCB Bound the socket referenced by file descriptor 2 to TCP.
listen on socket fd 2 Indicates which file descriptor the application is listening to.
closing socket Indicates that the socket is being closed.
socket event process Processed a state change event occurred in the transport
layer.
TCB new state --> FINWAIT1 TCP state machine changed to FINWAIT1. (See the debug ip
tcp transaction command for more information on TCP state
machines.)

DB-1200 May 2008
Debug Commands
debug ip socket
Table 180 debug ip socket Field Descriptions (continued)
Field Description
socket state: SS_ISCONNECTED New SOCKET state flags after the transport event
SS_CANTSENDMORE processing. This socket is still connected, but disconnecting
SS_ISDISCONNECTING is in progress, and it will not send more data to peer.
Possible SOCKET state flags follow:
SS_NOFDREF
No file descriptor reference for this socket.
SS_ISCONNECTING
Socket connecting is in progress.
SS_ISBOUND
Socket is bound to TCP.
SS_ISCONNECTED
Socket is connected to peer.
SS_ISDISCONNECTING
Socket disconnecting is in progress.
SS_CANTSENDMORE
Cant send more data to peer.
SS_CANTRCVMORE
Cant receive more data from peer.
SS_ISDISCONNECTED
Socket is disconnected. Connection is fully closed.
Removed socket 0x60B86228 from Connection is closed, and the socket is removed from the
process 40 socket list process socket list.

debug ip tcp transactions Displays information on significant TCP transactions such as
state changes, retransmissions, and duplicate packets.

May 2008 DB-1201
Debug Commands
debug ip ssh
debug ip ssh
To display debugging messages for Secure Shell (SSH), use the debug ip ssh command in privileged
debug ip ssh
no debug ip ssh
Defaults Debugging for SSH is not enabled.

12.1(1)T This command was integrated into Cisco IOS Release 12.1T.
Usage Guidelines Use the debug ip ssh command to ensure normal operation of the SSH server.
Examples The following example shows the SSH debugging output:

Router# debug ip ssh
00:53:46: SSH0: starting SSH control process

00:53:46: SSH0: Exchanging versions - SSH-1.5-Cisco-1.25
00:53:46: SSH0: client version is - SSH-1.5-1.2.25

00:53:46: SSH0: SSH_SMSG_PUBLIC_KEY message sent
00:53:46: SSH0: SSH_CMSG_SESSION_KEY message received
00:53:47: SSH0: keys exchanged and encryption on
00:53:47: SSH0: authentication request for userid guest
00:53:47: SSH0: authentication successful for jcisco
00:53:47: SSH0: starting exec shell

DB-1202 May 2008
Debug Commands
debug ip subscriber
debug ip subscriber
To enable Intelligent Service Gateway (ISG) IP subscriber session debugging, use the debug ip
subscriber command in privileged EXEC mode. To disable debugging, use the no form of this
command.
debug ip subscriber {all | error | event | fsm | packet}
no debug ip subscriber {all | error | event | fsm | packet}
Syntax Description all Displays all debugging messages related to IP subscriber sessions.
error Displays debugging messages about IP subscriber session errors.
event Displays debugging messages about IP subscriber session events.
fsm Displays debugging messages related to session state changes for IP
subscriber sessions.
packet Displays debugging messages related to IP subscriber session packets.

Examples The following example show sample output for the debug ip subscriber command:
Router# debug ip subscriber packet
Packet debugs:
1d07h: IPSUB_DP: [Et0/0:I:CEF:0000.0000.0002] Rx driver forwarded packet via les, return

code = 0
1d07h: IPSUB_DP: [Et0/0:I:PROC:0000.0000.0002] Packet classified, results = 0x18
1d07h: IPSUB_DP: [ms1:I:PROC:0000.0000.0002] Rx driver forwarded the packet
1d07h: IPSUB_DP: [ms1:I:PROC:0000.0000.0002] Packet classified, results = 0x42
1d07h: IPSUB_DP: [ms1:O:PROC:RED:50.0.0.3] Packet classified, results = 0x14
Router#
1d07h: IPSUB_DP: [ms1:O:PROC:RED:50.0.0.3] Subscriber features executed, return code = 0
1d07h: IPSUB_DP: [ms1:O:PROC:RED:50.0.0.3] Tx driver forwarding the packet
1d07h: IPSUB_DP: [Et0/0:O:PROC:RED:50.0.0.3] Packet classified, results = 0x14

show ip subscriber Displays information about ISG IP subscriber sessions.

May 2008 DB-1203
Debug Commands
debug ip subscriber redundancy

To enable Intelligent Service Gateway (ISG) IP subscriber session debugging on a Cisco 7600 router,
use the debug ip subscriber command in privileged EXEC mode. To disable debugging, use the no form
of this command.
no debug ip subscriber redundancy

Examples The following example shows that the debug ip subscriber redundancy command is turned on:
Router# debug ip subscriber redundancy
IP subscriber redundancy debugging is on.

clear ip subscriber Disconnects and removes all ISG IP subscriber sessions associated with a
interface specific interface on a Cisco 7600 router.
clear ip subscriber slot Disconnects and removes all ISG IP subscriber sessions associated with a
specific hardware slot on a Cisco 7600 router.
show ip subscriber Displays information about an ISG IP subscriber interface on a Cisco 7600
interface router.
show ip subscriber Displays information about ISG IP subscriber sessions on a Cisco 7600
redundancy router.
router.

DB-1204 May 2008
Debug Commands
debug ip tcp driver
debug ip tcp driver

To display information on TCP driver events; for example, connections opening or closing, or packets
being dropped because of full queues, use the debug ip tcp driver command in privileged EXEC mode.
debug ip tcp driver
no debug ip tcp driver
Usage Guidelines The TCP driver is the process that the router software uses to send packet data over a TCP connection.
Remote source-route bridging (RSRB), serial tunneling (STUN), and X.25 switching currently use the
TCP driver.
Using the debug ip tcp driver command together with the debug ip tcp driver-pak command provides
the most verbose debugging output concerning TCP driver activity.
Examples The following is sample output from the debug ip tcp driver command:
Router# debug ip tcp driver
TCPDRV359CD8: Active open 172.21.80.26:0 --> 172.21.80.25:1996 OK, lport 36628

TCPDRV359CD8: enable tcp timeouts
TCPDRV359CD8: 172.21.80.26:36628 --> 172.21.80.25:1996 Abort
TCPDRV359CD8: 172.21.80.26:36628 --> 172.21.80.25:1996 DoClose tcp abort
Table 181 debug ip tcp driver Field Descriptions
Field Description
TCPDRV359CD8: Unique identifier for this instance of TCP driver activity.
Active open 172.21.80.26 Indication that the router at IP address 172.21.80.26 has initiated a
connection to another router.
:0 TCP port number the initiator of the connection uses to indicate that any
port number can be used to set up a connection.
--> 172.21.80.25 IP address of the remote router to which the connection has been
initiated.
:1996 TCP port number that the initiator of the connection is requesting that
the remote router use for the connection. (1996 is a private TCP port
number reserved in this implementation for RSRB.)

May 2008 DB-1205
Debug Commands
debug ip tcp driver
Table 181 debug ip tcp driver Field Descriptions (continued)
Field Description
OK, Indication that the connection has been established. If the connection
has not been established, this field and the following field do not appear
in this line of output.
lport 36628 TCP port number that has actually been assigned for the initiator to use
for this connection.
The following line indicates that the TCP driver user (RSRB, in this case) will allow TCP to drop the
connection if excessive retransmissions occur:
TCPDRV359CD8: enable tcp timeouts
The following line indicates that the TCP driver user (in this case, RSRB) at IP address 172.21.80.26
(and using TCP port number 36628) is requesting that the connection to IP address 172.21.80.25 using
TCP port number 1996 be aborted:
TCPDRV359CD8: 172.21.80.26:36628 --> 172.21.80.25:1996 Abort
The following line indicates that this connection was in fact closed because of an abnormal termination:
TCPDRV359CD8: 172.21.80.26:36628 --> 172.21.80.25:1996 DoClose tcp abort

DB-1206 May 2008
Debug Commands
debug ip tcp driver-pak

To display information on every operation that the TCP driver performs, use the debug ip tcp driver-pak
no debug ip tcp driver-pak
Usage Guidelines This command turns on a verbose debugging by logging at least one debugging message for every packet
sent or received on the TCP driver connection.
The TCP driver is the process that the router software uses to send packet data over a TCP connection.
Remote source-rate bridging (RSRB), serial tunneling (STUN), and X.25 switching currently use the
TCP driver.
To observe the context within which certain debug ip tcp driver-pak messages occur, turn on this
command in conjunction with the debug ip tcp driver command.
Caution Because the debug ip tcp driver-pak command generates so many messages, use it only on lightly
loaded systems. This command not only places a substantial load on the system processor, it also may
change the symptoms of any unexpected behavior that occurs.
Examples The following is sample output from the debug ip tcp driver-pak command:
Router# debug ip tcp driver-pak
TCPDRV359CD8: send 2E8CD8 (len 26) queued

TCPDRV359CD8: output pak 2E8CD8 (len 26) (26)
TCPDRV359CD8: readf 42 bytes (Thresh 16)
TCPDRV359CD8: send 327E40 (len 4502) queued
TCPDRV359CD8: output pak 327E40 (len 4502) (4502)
Table 182 debug ip tcp driver-pak Field Descriptions
Field Description
TCPDRV359CD8 Unique identifier for this instance of TCP driver activity.
send Indicates that this event involves the TCP driver sending data.
2E8CD8 Address in memory of the data the TCP driver is sending.

May 2008 DB-1207
Debug Commands
Table 182 debug ip tcp driver-pak Field Descriptions (continued)
Field Description
(len 26) Length of the data (in bytes).
queued Indicates that the TCP driver user process (in this case, RSRB) has
transferred the data to the TCP driver to send.
The following line indicates that the TCP driver has sent the data that it had received from the TCP driver
user, as shown in the previous line of output. The last field in the line (26) indicates that the 26 bytes of
data were sent out as a single unit.
TCPDRV359CD8: output pak 2E8CD8 (len 26) (26)
The following line indicates that the TCP driver has received 42 bytes of data from the remote IP address.
The TCP driver user (in this case, remote source-route bridging) has established an input threshold of 16
bytes for this connection. (The input threshold instructs the TCP driver to transfer data to the TCP driver
user only when at least 16 bytes are present.)

DB-1208 May 2008
Debug Commands
debug ip tcp ecn
debug ip tcp ecn

To turn on debugging of the TCP Explicit Congestion Notification (ECN) capability, use the debug ip
tcp ecn command in privileged EXEC mode. To turn off the debugging, use the no form of this
command.
debug ip tcp ecn
no debug ip tcp ecn

Examples The following example shows the messages that verify that the end hosts are connected and configured
for ECN:
Router# debug ip tcp ecn
!
TCP ECN debugging is on
!
Router# telnet 10.1.25.31
Trying 10.1.25.31 ...

!
01:43:19: 10.1.25.35:11000 <---> 10.1.25.31:23 out ECN-setup SYN
01:43:21: 10.1.25.35:11000 <---> 10.1.25.31:23 congestion window changes
01:43:21: cwnd from 1460 to 1460, ssthresh from 65535 to 2920
01:43:21: 10.1.25.35:11000 <---> 10.1.25.31:23 in non-ECN-setup SYN-ACK
Before a TCP connection can use ECN, a host sends an ECN-setup SYN (synchronization) packet to a
remote end that contains an ECE and CWR bit set in the header. This indicates to the remote end that the
sending TCP is ECN-capable, rather than an indication of congestion. The remote end sends an
ECN-setup SYN-ACK (acknowledgment) packet to the sending host.
In the example above, the out ECN-setup SYN text means that a SYN packet with the ECE and CWR
bit set was sent to the remote end. The in non-ECN-setup SYN-ACK text means that the remote end
did not favorably acknowledge the ECN request and that therefore the session is ECN capable.
The following debug output shows that ECN capabilities are enabled at both ends. In response to the
ECN-setup SYN, the other end favorably replied with an ECN-setup SYN-ACK message. This
connection is now ECN capable for the rest of the session.

May 2008 DB-1209
Debug Commands
debug ip tcp ecn
Router# telnet 10.10.10.10
Trying 10.10.10.10 ... Open

Password required, but none set
!
1d20h: 10.1.25.34:11003 <---> 10.1.25.35:23 out ECN-setup SYN
1d20h: 10.1.25.34:11003 <---> 10.1.25.35:23 in ECN-setup SYN-ACK
Use the show tcp tcb command to display the end-host connections.

ip tcp ecn Enables TCP ECN.
show tcp tcb Displays the status of local and remote end hosts.

DB-1210 May 2008
Debug Commands
debug ip tcp ha
debug ip tcp ha
To display TCP high availabilty (HA) events or debugging information for TCP stack interactions
between the active Route Processor (RP) and the standby RP, use the debug ip tcp ha command in
debug ip tcp ha {events | transactions} [detail]
no debug ip tcp ha {events | transactions} [detail]
Syntax Description events Displays TCP HA failures.

transactions Displays failed TCP stack interactions between the active RP and standby
RP.
detail (Optional) Displays detailed debugging information about successful TCP
HA operations and useful informational messages or about successful TCP
stack interactions between the active and standby RP.

Usage Guidelines The debug ip tcp ha command is used to display TCP stateful switchover (SSO) events or debugging
information for TCP stack interactions between the active RP and the standby RP. This is command is
useful for troubleshooting SSO-aware TCP connections.
Use the debug ip tcp ha command with the transactions keyword to display failed TCP stack
interactions between the active RP and standby RP. This form of the command displays failed TCP HA
messages, RF redundancy-related client-application transactions, IPC client-application transactions,
and In-Service Software Upgrade (ISSU) transactions.
Use the debug ip tcp ha command with the transactions and detail keywords to display successful TCP
stack interactions between the active and standby RP. This form of the command displays successful
TCP HA messages, RF redundancy-related client-application transactions, IPC client-application
transactions, and ISSU transactions.
Use the debug ip tcp ha command with the events keyword to display TCP HA failures. This form of
the command displays TCP HA failed encode or decode messages, system resources failures (such as
memory allocation failures in the context of TCP HA), failed state changes, and failures that occur when
SSO is enabled or disabled.
Use the debug ip tcp ha command with the events and detail keywords to display successful TCP HA
operations and useful informational messages. This form of the command displays successful TCP
encode or decode messages, state changes, and operations that occur when SSO is enabled or disabled.

May 2008 DB-1211
Debug Commands
debug ip tcp ha
Examples The following is sample output from the debug ip tcp ha command with the transactions and detail
keywords. The following output shows packet flow from the active to the standby RP for an established
TCP SSO connection:
*Feb 19 23:28:23.324: TCPHA: Sending pkt msg, conn_id = 39, seq no = 2727115707
*Feb 19 23:28:24.544: TCPHA: Sending dummy pkt to standby; cid=109, size=19
*Feb 19 23:28:42.976: TCPHA: Recd IPC msg len 24, type 3

*Feb 19 23:28:43.172: TCPHA: Recd IPC msg len 79, type

DB-1212 May 2008
Debug Commands
debug ip tcp intercept

To display TCP intercept statistics, use the debug ip tcp intercept command in privileged EXEC mode.
no debug ip tcp intercept
Examples The following is sample output from the debug ip tcp intercept command:
Router# debug ip tcp intercept
A connection attempt arrives:

INTERCEPT: new connection (172.19.160.17:61774) => (10.1.1.30:23)
INTERCEPT: 172.19.160.17:61774 <- ACK+SYN (10.1.1.30:61774)
A second connection attempt arrives:

The router resends to both apparent clients:

INTERCEPT: retransmit 2 (172.19.160.17:61774) <- (10.1.1.30:23) SYNRCVD
A third connection attempt arrives:

The router sends more retransmissions trying to establish connections with the apparent clients:
The router establishes the connection with the third client and resends to the server:
INTERCEPT: 1st half of connection is established (171.69.232.23:1048) => (10.1.1.30:23)
INTERCEPT: (171.69.232.23:1048) SYN -> 10.1.1.30:23
INTERCEPT: retransmit 2 (171.69.232.23:1048) -> (10.1.1.30:23) SYNSENT
The server responds; the connection is established:

INTERCEPT: 2nd half of connection established (171.69.232.23:1048) => (10.1.1.30:23)
INTERCEPT: (171.69.232.23:1048) ACK -> 10.1.1.30:23

May 2008 DB-1213
Debug Commands
The router resends to the first two apparent clients, times out, and sends resets:
INTERCEPT: retransmitting too long (172.19.160.17:61774) => (10.1.1.30:23) SYNRCVD
INTERCEPT: 172.19.160.17:61774 <- RST (10.1.1.30:23)
INTERCEPT: retransmitting too long (172.19.160.17:62030) => (10.1.1.30:23) SYNRCVD
INTERCEPT: 172.19.160.17:62030 <- RST (10.1.1.30:23)

DB-1214 May 2008
Debug Commands
debug ip tcp transactions

To display information on significant TCP transactions such as state changes, retransmissions, and
duplicate packets, use the debug ip tcp transactions command in privileged EXEC mode. To disable
no debug ip tcp transactions

12.3(7)T The command output was enhanced to account for the following conditions:
TCP entering Fast Recovery mode, duplicate acknowledgments being
received during Fast Recovery mode, and partial acknowledgments being
received.
Usage Guidelines This command is particularly useful for debugging a performance problem on a TCP/IP network that you
have isolated above the data-link layer.
The debug ip tcp transactions command displays output for packets that the router sends and receives,
but does not display output for packets that it forwards.
Examples The following is sample output from the debug ip tcp transactions command:
Router# debug ip tcp transactions
TCP: sending SYN, seq 168108, ack 88655553

TCP0: Connection to 10.9.0.13:22530, advertising MSS 966
TCP0: state was LISTEN -> SYNRCVD [23 -> 10.9.0.13(22530)]
TCP0: state was SYNSENT -> SYNRCVD [23 -> 10.9.0.13(22530)]
TCP0: Connection to 10.9.0.13:22530, received MSS 956
TCP0: restart retransmission in 5996
TCP0: state was SYNRCVD -> ESTAB [23 -> 10.9.0.13(22530)]
TCP2: restart retransmission in 13384 -> 10.0.0.13(16151)]
TCP0: restart retransmission in 5996 [23 -> 10.0.0.13(16151)]

May 2008 DB-1215
Debug Commands
The following line from the debug ip tcp transactions command output shows that TCP has entered
Fast Recovery mode:
fast re-transmit - sndcwnd - 512, snd_last - 33884268765
The following lines from the debug ip tcp transactions command output show that a duplicate
acknowledgment is received when in Fast Recovery mode (first line) and a partial acknowledgment has
been received (second line):
TCP0:ignoring second congestion in same window sndcwn - 512, snd_1st - 33884268765
TCP0:partial ACK received sndcwnd:338842495
Table 183 debug ip tcp transactions Field Descriptions
Field Description
TCP Indicates that this is a TCP transaction.
sending SYN Indicates that a synchronize packet is being sent.
seq 168108 Indicates the sequence number of the data being sent.
ack 88655553 Indicates the sequence number of the data being
acknowledged.
TCP0 Indicates the TTY number (0, in this case) with which this TCP
connection is associated.
Connection to 10.9.0.13:22530 Indicates the remote address with which a connection has been
established.
advertising MSS 966 Indicates the maximum segment size that this side of the TCP
connection is offering to the other side.

DB-1216 May 2008
Debug Commands
Table 183 debug ip tcp transactions Field Descriptions (continued)
Field Description
state was LISTEN -> SYNRCVD Indicates that the TCP state machine changed state from
LISTEN to SYNRCVD. Possible TCP states that can follow
are:
CLOSEDConnection closed.
CLOSEWAITReceived a FIN segment.
CLOSINGReceived a FIN/ACK segment.
ESTABConnection established.
FINWAIT 1Sent a FIN segment to start closing the
connection.
FINWAIT 2Waiting for a FIN segment.
LASTACKSent a FIN segment in response to a received
FIN segment.
LISTENListening for a connection request.
SYNRCVDReceived a SYN segment and responded.
SYNSENTSent a SYN segment to start connection
negotiation.
TIMEWAITWaiting for the network to clear segments
for this connection before the network no longer
recognizes the connection as valid. This must occur before
a new connection can be set up.
[23 -> 10.9.0.13(22530)] The elements within these brackets are as follows:
The first field (23) indicates the local TCP port.
The second field (10.9.0.13) indicates the destination IP
address.
The third field (22530) indicates the destination TCP port.
restart retransmission in 5996 Indicates the number of milliseconds until the next
retransmission takes place.
sndcwnd - 512 Indicates the size of the send congestion window.
snd_last - 33884268765 Indicates the size of the last window.

May 2008 DB-1217
Debug Commands
debug ip traffic-export events

To enable debugging messages for exported IP packet events, use the debug ip traffic-export command
in privileged EXEC mode. To disable debugging messages, use the no form of this command.
no debug ip traffic-export events

Examples The following is sample output from the debug ip traffic-export events command:
Router# debug ip traffic-export events
RITE:exported input packet # 547


ip traffic-export Creates or edits an IP traffic export profile and enables the profile on an
profile ingress interface.

DB-1218 May 2008
Debug Commands
debug ip trigger-authentication
To display information related to automated double authentication, use the debug ip
trigger-authentication command in privileged EXEC mode. To disable debugging output, use the no
debug ip trigger-authentication [verbose]
no debug ip trigger-authentication [verbose]
Syntax Description verbose (Optional) Specifies that the complete debugging output be displayed, including
information about packets that are blocked before authentication is complete.
Usage Guidelines Use this command when troubleshooting automated double authentication.
This command displays information about the remote host table. Whenever entries are added, updated,
or removed, a new debugging message is displayed.
What is the remote host table? Whenever a remote user needs to be user-authenticated in the second stage
of automated double authentication, the local device sends a User Datagram Protocol (UDP) packet to
the host of the remote user. Whenever such a UDP packet is sent, the host IP address of the user is added
to a table. If additional UDP packets are sent to the same remote host, a new table entry is not created;
instead, the existing entry is updated with a new time stamp. This remote host table contains a cumulative
list of host entries; entries are deleted after a timeout period or after you manually clear the table by using
the clear ip trigger-authentication command.
If you include the verbose keyword, the debugging output also includes information about packet
activity.
Examples The following is sample output from the debug ip trigger-authentication command. In this example,
the local device at 172.21.127.186 sends a UDP packet to the remote host at 172.21.127.114. The UDP
packet is sent to request the remote users username and password (or PIN). (The output says New entry
added.)
After a timeout period, the local device has not received a valid response from the remote host, so the
local device sends another UDP packet. (The output says Time stamp updated.)
Then the remote user is authenticated, and after a length of time (the timeout period) the entry is removed
from the remote host table. (The output says remove obsolete entry.)
myfirewall# debug ip trigger-authentication
TRIGGER_AUTH: UDP sent from 172.21.127.186 to 172.21.127.114, qdata=7C2504

New entry added, timestamp=2940514234
TRIGGER_AUTH: UDP sent from 172.21.127.186 to 172.21.127.114, qdata=7C2504
Time stamp updated, timestamp=2940514307
TRIGGER_AUTH: remove obsolete entry, remote host=172.21.127.114

May 2008 DB-1219
Debug Commands
The following is sample output from the debug ip trigger-authentication verbose command. In this
example, messages about packet activity are included because of the use of the verbose keyword.
You can see many packets that are being blocked at the interface because the user has not yet been double
authenticated. These packets will be permitted through the interface only after the user has been double
authenticated. (You can see packets being blocked when the output says packet enqueued and then
packet ignored.)
TRIGGER_AUTH: packet enqueued, qdata=69FEEC
remote host=172.21.127.113, local host=172.21.127.186 (if: 0.0.0.0)
TRIGGER_AUTH: UDP sent from 172.21.127.186 to 172.21.127.113, qdata=69FEEC
Time stamp updated
TRIGGER_AUTH: packet ignored, qdata=69FEEC
TRIGGER_AUTH: UDP sent from 172.21.127.186 to 172.21.127.113, qdata=69FEEC
Time stamp updated

DB-1220 May 2008
Debug Commands
debug ip urd
debug ip urd
To display debugging messages for URL Rendezvous Directory (URD) channel subscription report
processing, use the debug ip urd command in privileged EXEC mode. To disable debugging output,
debug ip urd [hostname | ip-address]
no debug ip urd
Syntax Description hostname (Optional) The domain Name System (DNS) name.
ip-address (Optional) The IP address.
Defaults If no host name or IP address is specified, all URD reports are debugged.

Examples The following is sample output from the debug ip urd command:
Router# debug ip urd
13:36:25 pdt:URD:Data intercepted from 171.71.225.103

13:36:25 pdt:URD:Enqueued string:
'/cgi-bin/error.pl?group=232.16.16.16&port=32620&source=171.69.214.1&li'
13:36:25 pdt:URD:Matched token:group
13:36:25 pdt:URD:Parsed value:232.16.16.16
13:36:25 pdt:URD:Creating IGMP source state for group 232.16.16.16

May 2008 DB-1221
Debug Commands
debug ip urlfilter
debug ip urlfilter
To enable debug information of URL filter subsystems, use the debug ip urlfilter command in privileged
debug ip urlfilter {function-trace | detailed | events}
no debug ip urlfilter {function-trace | detailed | events}
Syntax Description function-trace The system prints a sequence of important functions that are called when
configuring URL filtering.
detailed The system prints detailed information about various activities that occur
during URL filtering.
events The system prints various events such as queue event, timer event, and
socket event.

Examples The following is sample output from the debug ip urlfilter command:
Router# debug ip urlfilter
urlfilter:
Urlfilter Detailed Debugs debugging is on
Router# show ip urlfilter config
N2H2 URL Filtering is ENABLED
Primary N2H2 server configurations

=========================================
N2H2 server IP address:192.168.1.103
N2H2 server port:4005
N2H2 retransmission time out:6 (in seconds)
N2H2 number of retransmission:2
Secondary N2H2 servers configurations

============================================

DB-1222 May 2008
Debug Commands
debug ip urlfilter
Other configurations
=====================
Allow Mode:OFF
System Alert:ENABLED
Audit Trail:ENABLED
Log message on N2H2 server:DISABLED
Maximum number of cache entries:5
Maximum number of packet buffers:20
Maximum outstanding requests:1000
fw1_4#
1d15h:URLF:got a socket read event...
1d15h:URLF:socket recv failed.
1d15h:URLF:Closing the socket for server (192.168.1.103:4005)
1d15h:%URLF-3-SERVER_DOWN:Connection to the URL filter server 192.168.1.103 is down
1d15h:URLF:Opening a socket for server (192.168.1.103:4005)
1d15h:URLF:socket fd 0
1d15h:%URLF-5-SERVER_UP:Connection to an URL filter server(192.168.1.103) is made, the
router is returning from ALLOW MODE
1d15h:URLF:got cache idle timer event...
1d16h:URLF:got cache absolute timer event...
1d16h:URLF:creating uis 0x63A95DB4, pending request 1
1d16h:URLF:domain name not found in the exclusive list
1d16h:URLF:got an cbac queue event...
1d16h:URLF:socket send successful...172.17.192.130:8080) -> 192.168.1.103:1052 seq
3344720064 wnd 24820
1d16h:URLF:holding pak 0x634A8A08 (172.17.192.130:8080) -> 192.168.1.103:1052 seq
3344721524 wnd 24820
1d16h:URLF:holding pak 0x634A98CC (172.17.192.130:8080) -> 192.168.1.103:1052 seq
3344722984 wnd 24820
1d16h:URLF:socket recv (header) successful.
1d16h:URLF:socket recv (data) successful.
1d16h:URLF:n2h2 lookup code = 1
1d16h:URLF:Site/URL Blocked:sis 0x63675DC4, uis 0x63A95DB4
1d16h:%URLF-4-URL_BLOCKED:Access denied URL 'http://www.google.com/', client
192.168.1.103:1052 server 172.17.192.130:8080
1d16h:URLF:(192.168.1.103:1052) RST -> 172.17.192.130:8080 seq 3361738063 wnd 0
1d16h:URLF:(172.17.192.130:8080) FIN -> 192.168.1.103:1052 seq 3344720064 wnd 0
1d16h:URLF:deleting uis 0x63A95DB4, pending requests 0
1d16h:URLF:creating uis 0x63A95DB4, pending request 1
1d16h:URLF:socket send successfull...
1d16h:URLF:holding pak 0x634A812C (172.17.192.130:8080) -> 192.168.1.103:1101 seq
3589711120 wnd 24820
1d16h:URLF:holding pak 0x634A2E7C (172.17.192.130:8080) -> 192.168.1.103:1101 seq
3589712580 wnd 24820
1d16h:URLF:holding pak 0x634A3464 (172.17.192.130:8080) -> 192.168.1.103:1101 seq
3589714040 wnd 24820
1d16h:%URLF-6-URL_ALLOWED:Access allowed for URL 'http://www.alcohol.com/', client
192.168.1.103:1101 server 172.17.192.130:8080
1d16h:URLF:Site/URL allowed:sis 0x6367D0C4, uis 0x63A95DB4
1d16h:URLF:releasing pak 0x634A812C:(172.17.192.130:8080) -> 192.168.1.103:1101 seq
3589711120 wnd 24820
1d16h:URLF:releasing pak 0x634A2E7C:(172.17.192.130:8080) -> 192.168.1.103:1101 seq
3589712580 wnd 24820
1d16h:URLF:releasing pak 0x634A3464:(172.17.192.130:8080) -> 192.168.1.103:1101 seq
3589714040 wnd 24820

May 2008 DB-1223
Debug Commands
debug ip urlfilter
1d16h:URLF:deleting uis 0x63A95DB4, pending requests 0

1d16h:URLF:creating uis 0x63A9777C, pending request 1
1d16h:URLF:socket send successful...
1d16h:URLF:Site/URL Blocked:sis 0x63677ED4, uis 0x63A9777C
1d16h:%URLF-4-URL_BLOCKED:Access denied URL 'http://www.google.com/', client
192.168.1.103:1123 server 172.17.192.130:8080
1d16h:URLF:(192.168.1.103:1123) RST -> 172.17.192.130:8080 seq 3536466275 wnd 0
1d16h:URLF:(172.17.192.130:8080) FIN -> 192.168.1.103:1123 seq 3618929551 wnd 0
1d16h:URLF:deleting uis 0x63A9777C, pending requests 0

DB-1224 May 2008
Debug Commands
debug ip verify mib
debug ip verify mib

To view debug output that displays the operation of unicast reverse path forwarding (URPF) MIB objects
and the helper software, use the debug ip verify mib command in privileged EXEC mode. To disable
debugging for URPF, use the no form of this command.
debug ip verify mib
no debug ip verify mib

Usage Guidelines Debug information for the URPF MIB is collected only when logging is enabled. URPF messages are
stored in the logging buffer, and they are not displayed on the console unless you use the debug ip verify
mib command.
Examples The following example shows sample output of the debug ip verify mib command:
router# debug ip verify mib
01:29:45: cipUrpfScalar_get, searchType 161

01:29:45: ipurpfmib_get_scalars
01:29:45: cipUrpfScalar_get, searchType
161ipurpfmib_get_urpf_entryipurpfmib_get_urpf_entryipurpfmib_get_urpf_entryipurpfmib_get_
urpf_entry
01:29:45: cipUrpfIfMonEntry_get, searchType 161
01:29:45: ipurpfmib_get_urpf_ifmon_entry entry: ST 161, if 1, ip 1

May 2008 DB-1225
Debug Commands
debug ip verify mib

The command output is self-explanatory.

show ip interface Displays the usability status of interfaces configured for IP.

DB-1226 May 2008
Debug Commands
debug ip virtual-reassembly
To enable debugging of the virtual fragment reassembly (VFR) subsystem, use the debug ip
virtual-reassembly command in privileged EXEC mode. To disable VFR debugging, use the no form
of this command.
no debug ip virtual-reassembly

Examples The following sample output from the debug ip virtual-reassembly command allows you to monitor
datagram fragmentation and reassembly statussuch as whether a datagram is incomplete and when
fragments (from the datagram) are created (after a datagram is determined to be complete).
Router# debug ip virtual-reassembly
00:17:35: IP_VFR: fragment (sa:13.0.0.2, da:17.0.0.2, id:11745, offset:0, len:104) in fast

path...
00:17:35: IP_VFR: created frag state for sa:13.0.0.2, da:17.0.0.2, id:11745...
00:17:35: IP_VFR: pak incomplete cpak-offset:0, cpak-len:104, flag: 1
00:17:35: IP_VFR: dgrm incomplete, returning...
00:17:35: IP_VFR: fragment (sa:13.0.0.2, da:17.0.0.2, id:11745, offset:104, len:104) in
fast path...
00:17:35: IP_VFR: cpak-offset:0, cpak-len:104, npak-offset:104
fast path...
fast path...
fast path...

May 2008 DB-1227
Debug Commands

00:17:35: IP_VFR: dgrm complete, switching the frags.
00:17:35: IP_VFR: switching fragment (sa:13.0.0.2, da:17.0.0.2, id:11745, offset:0,
len:104)
len:104)
len:104)
len:104)
len:92)
00:17:35: IP_VFR: all fragments have been switched.
00:17:35: IP_VFR: pak_subblock_free - pak 0x64A3DC30
00:17:35: IP_VFR: pak_subblock_free - pak 0x6430F010
00:17:35: IP_VFR: pak_subblock_free - pak 0x6430F678
00:17:35: IP_VFR: pak_subblock_free - pak 0x643119B4
00:17:35: IP_VFR: deleted frag state for sa:13.0.0.2, da:17.0.0.2, id:11745
00:17:35: IP_VFR: pak_subblock_free - pak 0x64A3D5C8

ip virtual-reassembly Enables VFR on an interface.

DB-1228 May 2008
Debug Commands
debug ip wccp events

To display information about significant Web Cache Control Protocol (WCCP) events, use the debug ip
wccp events command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
no debug ip wccp events
Examples The following shows sample output from the debug ip wccp events command when a Cisco Cache
Engine is added to the list of available Web caches:
Router# debug ip wccp events
WCCP-EVNT: Built I_See_You msg body w/1 usable web caches, change # 0000000A
WCCP-EVNT: Web Cache 192.168.25.3 added
WCCP-EVNT: Built I_See_You msg body w/2 usable web caches, change # 0000000B
WCCP-EVNT: Built I_See_You msg body w/2 usable web caches, change # 0000000C

May 2008 DB-1229
Debug Commands
debug ip wccp packets

To display information about every Web Cache Control Protocol (WCCP) packet received or sent by the
router, use the debug ip wccp packets command in privileged EXEC mode. To disable debugging
no debug ip wccp packets
Examples The following is sample output from the debug ip wccp packets command. The router is sending
keepalive packets to the Cisco Cache Engines at 192.168.25.4 and 192.168.25.3. Each keepalive packet
has an identification number associated with it. When the Cisco Cache Engine receives a keepalive
packet from the router, it sends a reply with the identification number back to the router.
Router# debug ip wccp packets
WCCP-PKT: Received valid Here_I_Am packet from 192.168.25.4 w/rcvd_id 00003532

WCCP-PKT: Sending I_See_You packet to 192.168.25.4 w/ rcvd_id 00003534

DB-1230 May 2008
Debug Commands
debug ipc acks
debug ipc acks

To display debugging messages about interprocess communication (IPC) acknowledgments (ACKs), use
the debug ipc acks command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug ipc acks [rx | tx] [dest destination-port-id] [source source-seat-id] [session session-id]
[header dump]
no debug ipc acks [rx | tx] [dest destination-port-id] [source source-seat-id] [session session-id]
[header dump]
Syntax Description rx (Optional) Displays debugging messages related to the retrieval of IPC ACK
messages.
tx (Optional) Displays debugging messages related to the transmission of IPC
ACK messages.
dest (Optional) Displays debugging messages related to a destination port of IPC
ACK messages. If not specified, information about all destinations is
displayed.
Use the destination-port-id argument to specify a hexadecimal number
that represents a destination port ID. The range is from 0 to FFFFFFFF.
source (Optional) Displays debugging information about messages from an IPC
node. If not specified, information about all nodes is displayed.
Use the source-seat-id argument to specify a hexadecimal number that
represents a source seat ID. The range is from 0 to FFFFFFFF.
session (Optional) Displays debugging messages related to an IPC session. If not
specified, information about all sessions is displayed.
Use the session-id argument to specify a session ID. The range is from
0 to 65535.
header dump (Optional) Displays only the packet header information.

Usage Guidelines Use the debug ipc acks command to troubleshoot IPC ACK issues. To enable debugging for other IPC
activities, use the debug ipc command.

May 2008 DB-1231
Debug Commands
debug ipc acks
Examples The following example shows how to enable the display of packet headers only when debugging IPC
ACK messages. The debugging output varies depending on the type of IPC activity that is specified.
Each entry includes some text explanationthe example below shows that the server received an ACK
HDRfollowed by a series of header or data fields.
Router# debug ipc acks header dump
Aug 19 03:52:36.136:IPC:Server received ACK HDR:442A64E0 src:100000A, dst:406116E8,

index:-1, seq:22045, sz:0, type:65535, flags:2 hi:1F371, lo:0

debug ipc Displays IPC debugging information.

DB-1232 May 2008
Debug Commands
debug ipc errors
debug ipc errors

To display debugging messages about interprocess communication (IPC) errors and warnings, use the
debug ipc errors command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
debug ipc errors [driver] [sequence] [timeout]
no debug ipc errors [driver] [sequence] [timeout]
Syntax Description driver (Optional) Displays debugging messages related to IPC errors at the driver
(transport) medium.
sequence (Optional) Displays information related to IPC messages that have
sequence-related issues, such as duplicate or unexpected messages.
timeout (Optional) Displays only information related to IPC messages that have
timed out.

12.3(11)T The driver, sequence, and timeout keywords were added.
Usage Guidelines Use the debug ipc errors command to troubleshoot IPC error issues. To enable debugging for other IPC
activities, use the debug ipc command. The debugging output varies depending on the type of IPC
activity that is specified.
Examples The following example shows how to enable the display of error debugging information about IPC
messages that have timed out. The debugging output varies depending on the type of IPC activity that is
specified. Each entry includes some text explanationthe example below shows that the message
number 4428D3D0 timed out waiting for an acknowledgment (Ack)followed by a series of header or
data fields.
Router# debug ipc errors timeout
Message Timeouts debugging is on
*Sep 14 14:42:17.103: IPC: Message 4428D3D0 timed out waiting for Ack
*Sep 14 14:42:17.103: IPC: MSG: ptr: 0x4428D3D0, flags: 0x88, retries: 6, seq: 0x1030002,
refcount: 2,

May 2008 DB-1233
Debug Commands
debug ipc errors
retry: 00:00:00, rpc_result = 0x0, data_buffer = 0x4442AB10, header = 0x4442AED4,

data = 0x4442AEF4
HDR: src: 0x10000, dst: 0x103000A, index: 0, seq: 2, sz: 512, type: 0, flags: 0x400
hi: 0x1EC, lo: 0x4442AEF4
DATA: 00 00 00 05 00 00 00 00 00 00 00 3A 00 00 00 00 00 00 00 00


DB-1234 May 2008
Debug Commands
debug ipc events
debug ipc events

To display debugging messages about interprocess communication (IPC) events, use the debug ipc
command.
debug ipc events [flushes] [retries]
no debug ipc events [flushes] [retries]
Syntax Description flushes (Optional) Displays only information related to IPC messages that are
flushed.
retries (Optional) Displays only information related to IPC messages that are
re-sent.

12.3(11)T The flushes and retries keywords were added.\
Usage Guidelines Use the debug ipc events command to troubleshoot IPC events issues. To enable debugging for other
IPC activities, use the debug ipc command.
Examples The following example shows how to enable the display of debugging messages about IPC events:
Router# debug ipc events
Special Events debugging is on
The following example shows how to enable the display of event debugging information about IPC
messages that are re-sent. The debugging output varies depending on the type of IPC activity that is
specified. Each entry includes some text explanationthe example below shows that there was a retry
attempt for a specific messagefollowed by a series of header or data fields.
Router# debug ipc events retries
Message Retries debugging is on
*Sep 14 14:46:44.151: IPC: Retry attempt for MSG: ptr: 0x442AFE74, flags: 0x88,
retries:4, seq: 0x1030003,
refcount: 2, retry: 00:00:00, rpc_result = 0x0, data_buffer = 0x445EBA44,
header =0x445EBE08, data = 0x445EBE28

May 2008 DB-1235
Debug Commands
debug ipc events
HDR: src: 0x10000, dst: 0x103000A, index: 0, seq: 3, sz: 512, type: 0, flags: 0x400
hi:0x201, lo: 0x445EBE28
DATA: 00 00 00 05 00 00 00 00 00 00 00 3A 00 00 00 00 00 00 03 D2


DB-1236 May 2008
Debug Commands
debug ipc fragments
debug ipc fragments

To display debugging messages about interprocess communication (IPC) fragments, use the debug ipc
fragments command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug ipc fragments [rx | tx] [dest destination-port-id] [source source-seat-id] [session
session-id] [type application-type] [flags header-flag] [sequence sequence] [msgidhi
msg-id-high] [msgidlo msg-id-low] [data offset offset-from-header value value-to-match
dump bytes] [size size] [header dump]
no debug ipc fragments [rx | tx] [dest destination-port-id] [source source-seat-id] [session
Syntax Description rx (Optional) Displays debugging messages related to the retrieval of IPC
fragments.
fragments.
fragments. If not specified, information about all destinations is displayed.
0 to 65535.
type (Optional) Displays debugging messages related to a type of IPC fragments.
If not specified, information about all application types is displayed.
Use the application-type argument to specify a hexadecimal number that
represents an application. The range is from 0 to FFFF.
flags (Optional) Displays debugging messages related to an IPC fragments header
flag. If not specified, information about all header flags is displayed.
Use the header-flag argument to specify a hexadecimal number that
represents a header flag value. The range is from 0 to FFFF.
sequence (Optional) Displays debugging messages related to a sequence number of an
IPC fragment. If not specified, information about all sequence numbers is
displayed.
Use the sequence argument to specify a sequence number. The range is
from 0 to 65535.

May 2008 DB-1237
Debug Commands
debug ipc fragments
msgidhi (Optional) Displays debugging messages related to the higher byte of the
unique ID of an IPC fragment.
Use the msg-id-high argument to specify a hexadecimal number that
represents a higher byte of the unique ID. The range is from 0 to
FFFFFFFF.
msgidlo (Optional) Displays debugging messages related to the lower byte of the
unique ID of an IPC fragment.
Use the msg-id-low argument to specify a hexadecimal number that
represents a lower byte of the unique ID. The range is from 0 to
FFFFFFFF.
data (Optional) Displays debugging messages related to the IPC fragment
payload. If not specified, information about all of the IPC fragments
payload is displayed.
offset(Optional) Displays offset IPC data. If this keyword is
configured, the value keyword must also be configured.
Use the offset-from-header argument to specify the offset value
from the start of the IPC data. The range is from 0 to 65535.
Use the value keyword to configure the value expected at the offset
of the IPC data.
Use the value-to-match argument to specify the hexadecimal
number that represents the value expected at the offset of the IPC
data. The range is from 0 to FF.
dump(Optional) Configures the number of data bytes to display.
Use the bytes argument to specify the number of data bytes. The
size (Optional) Displays IPC fragment debugging messages of a specific size. If
not specified, information about messages of any size is displayed.
Use the size argument to specify the message size in rows. The range is
from 0 to 65535.

Usage Guidelines Use the debug ipc fragments command to troubleshoot IPC fragment issues. To enable debugging for
other IPC activities, use the debug ipc command.

DB-1238 May 2008
Debug Commands
debug ipc fragments
Examples The following example shows how to enable the display of debugging information about IPC fragments.
The debugging output varies depending on the type of IPC activity that is specified. Each entry includes
some text explanationthe example below shows that the server received a fragment
messagefollowed by a series of header or data fields.
Router# debug ipc fragments
IPC Fragments debugging is on
01:43:55: IPC: Server received fragment MSG: ptr: 0x503A4348, flags: 0x100, retries: 0,
seq: 0x0,
refcount: 1, retry: never, rpc_result = 0x0, data_buffer = 0x433809E8, header = 0x8626748,
data = 0x8626768
HDR: src: 0x10000, dst: 0x2210015, index: 0, seq: 1, sz: 1468, type: 0, flags: 0x10
hi:0x9AA, lo: 0x7D0
DATA: 00 00 00 01 00 00 00 00 00 00 00 AA 00 00 00 00 00 00 17 E4


May 2008 DB-1239
Debug Commands
debug ipc nacks
debug ipc nacks

To display debugging messages about interprocess communication (IPC) negative acknowledgments
(NACKs), use the debug ipc nacks command in privileged EXEC mode. To disable debugging output,
debug ipc nacks [rx | tx] [dest destination-port-id] [source source-seat-id] [session session-id]
[header dump]
no debug ipc nacks [rx | tx] [dest destination-port-id] [source source-seat-id] [session session-id]
[header dump]
NACK messages.
NACK messages.
NACK messages. If not specified, information about all destinations is
displayed.
0 to 65535.

Usage Guidelines Use the debug ipc nacks command to troubleshoot IPC NACK issues. To enable debugging for other

DB-1240 May 2008
Debug Commands
debug ipc nacks
NACK messages. The debugging output varies depending on the type of IPC activity that is specified.
Each entry includes some text explanationthe example below shows that the server sent a NACK
message and received a NACK headerfollowed by a series of header or data fields.
Router# debug ipc nacks header dump
IPC Nacks debugging is on
01:46:11: IPC: Server sent NACK MSG: ptr: 0x432A7428, flags: 0x100, retries: 0, seq: 0x0,
refcount: 1, retry: never, rpc_result = 0x0, data_buffer = 0x431E4B50, header = 0x855F508,
data = 0x855F528
HDR: src: 0x2210015, dst: 0x10000, index: 1, seq: 3, sz: 0, type: 0, flags: 0x100
hi: 0x4A9, lo: 0x85AA3E8
01:46:11: SP: IPC: Server received NACK HDR: E46A448 src: 2210015, dst: 10000, index: 1,
seq: 3, sz: 0, type: 0, flags: 100 hi: 4A9, lo: 85AA3E8


May 2008 DB-1241
Debug Commands
debug ipc packets
debug ipc packets

To display debugging messages about interprocess communication (IPC) packets, use the debug ipc
packets command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug ipc packets [rx | tx] [dest destination-port-id] [source source-seat-id] [session session-id]
[type application-type] [flags header-flag] [sequence sequence] [msgidhi msg-id-high]
[msgidlo msg-id-low] [data offset offset-from-header value value-to-match dump bytes] [size
size] [header dump]
no debug ipc packets [rx | tx] [dest destination-port-id] [source source-seat-id] [session
packets.
packets.
packets. If not specified, information about all destinations is displayed.
0 to 65535.
type (Optional) Displays debugging messages related to a type of IPC packet. If
not specified, information about all application types is displayed.
flags (Optional) Displays debugging messages related to an IPC packet header
flag. If not specified, information about all header flags is displayed.
IPC packet. If not specified, information about all sequence numbers is
displayed.
from 0 to 65535.

DB-1242 May 2008
Debug Commands
debug ipc packets
unique ID of an IPC packet.
FFFFFFFF.
unique ID of an IPC packet.
FFFFFFFF.
data (Optional) Displays debugging messages related to the IPC packet payload.
If not specified, information about all of the IPC packets payload is
displayed.
of the IPC data.
size (Optional) Displays IPC packet debugging messages of a specific size. If not
specified, information about messages of any size is displayed.
from 0 to 65535.

Usage Guidelines Use the debug ipc packets command to troubleshoot IPC packet issues. To enable debugging for other

May 2008 DB-1243
Debug Commands
debug ipc packets
Caution Use the debug ipc packets command with caution because the volume of output can severely impact
system performance. A confirmation message is displayed. We recommend that you use one of the
optional keywords to focus on a specific IPC activity and to limit the volume of output.
Examples The following example shows how to enable the display of IPC packet debugging messages and includes
some sample output. The debugging output varies depending on the type of IPC activity that is specified.
Each entry includes some text explanationthe example below shows that the IPC server received a
messagefollowed by a series of header or data fields.
Router# debug ipc packets
This may severely impact system performance. Continue?[confirm] Y
Aug 19 030612.297 IPC Server received MSG ptr 0x441BE75C, flags 0x80, retries 0,
seq 0x0, refcount 1, retry never, rpc_result = 0x0, data_buffer = 0x443152A8,
header = 0x4431566C, data = 0x4431568C
HDR src 0x1060000, dst 0x1000C, index 2, seq 0, sz 28, type 770,
flags 0x40 hi 0x1F25B, lo 0x442F0BC0
DATA 00 00 00 06 00 00 00 02 00 00 00 06 00 E7 00 02 00 00 00 00
The following example shows how to enable the display of IPC messages received with a destination
port of 0x1000C in session 1 with a message size of 500 rows.
Router# debug ipc packets rx dest 1000C session 1 size 500


DB-1244 May 2008
Debug Commands
debug ipc rpc
debug ipc rpc

To display debugging messages about interprocess communication (IPC) remote-procedure call (RPC)
packets, use the debug ipc rpc command in privileged EXEC mode. To disable debugging output, use
debug ipc rpc [rx | tx] [query | response] [dest destination-port-id] [source source-seat-id]
[session session-id] [type application-type] [flags header-flag] [sequence sequence] [msgidhi
no debug ipc rpc [rx | tx] [query | response] [dest destination-port-id] [source source-seat-id]
[session session-id] [type application-type] [flags header-flag] [sequence sequence] [msgidhi
Syntax Description rx (Optional) Displays debugging messages related to the retrieval of IPC RPC
packets.
RPC packets.
query (Optional) Displays debugging messages related to IPC RPC queries.
response (Optional) Displays debugging messages related to IPC RPC responses.
RPC packets. If not specified, information about all destinations is
displayed.
0 to 65535.
type (Optional) Displays debugging messages related to a type of IPC RPC
message. If not specified, information about all application types is
displayed.
flags (Optional) Displays debugging messages related to an IPC RPC message
header flag. If not specified, information about all header flags is displayed.

May 2008 DB-1245
Debug Commands
debug ipc rpc

IPC RPC message. If not specified, information about all sequence numbers
is displayed.
from 0 to 65535.
unique ID of an IPC RPC message.
FFFFFFFF.
unique ID of an IPC RPC message.
FFFFFFFF.
data (Optional) Displays debugging messages related to the IPC RPC payload. If
not specified, information about all of the IPC RPCs payload is displayed.
of the IPC data.
size (Optional) Displays IPC RPC debugging messages of a specific size. If not
specified, information about messages of any size is displayed.
from 0 to 65535.


DB-1246 May 2008
Debug Commands
debug ipc rpc
Usage Guidelines Use the debug ipc rpc command to troubleshoot IPC RPC packet issues. To enable debugging for other
IPC activities, use the debug ipc command. The debugging output varies depending on the type of IPC
activity that is specified.
RPC response messages. The debugging output varies depending on the type of IPC activity that is
specified. Each entry includes some text explanationthe example below shows that the server received
an RPC responsefollowed by a series of header or data fields.
Router# debug ipc rpc response header dump source 2210003
RPC debugging is on
01:53:43: SP: IPC: Server received RPC Reply HDR: E450048 src: 2210003, dst: 10000,
index:0, seq: 1716, sz: 4, type: 2914, flags: 208 hi: A07, lo: E264DE8


May 2008 DB-1247
Debug Commands
debug ipc
debug ipc
To display debugging messages about interprocess communication (IPC) activity, use the debug ipc
debug ipc {all | ports | seats | sessions | zones}
no debug ipc {all | ports | seats | sessions | zones}
Syntax Description all Displays all debugging IPC messages. A confirmation message will appear
because enabling this keyword can severely impact performance.
ports Displays debugging messages related to the creation and deletion of IPC
ports.
seats Displays debugging messages related to the creation and deletion of IPC
nodes (seats).
sessions Displays debugging messages related to the creation and deletion of IPC
sessions.
zones Displays debugging messages related to the creation and deletion of IPC
zones.

12.3(11)T The sessions and zones keywords were added.
Usage Guidelines Use the debug ipc command to troubleshoot IPC issues discovered when the show ipc command is run.
The debugging output varies depending on the types of IPC packets that are selected by the different
keywords.
Caution Use the debug ipc all command with caution because it enables the debug ipc packets command and
the volume of output can severely impact system performance. A confirmation message is displayed. We
recommend that you use one of the other keywords to focus on a specific IPC activity and to limit the
volume of output.

DB-1248 May 2008
Debug Commands
debug ipc
Examples The following example shows the confirmation message that appears when the debug ipc all command
is entered:
Router# debug ipc all
This may severely impact system performance. Continue? [confirm]
The following example shows how to enable the display of debugging messages about IPC sessions. The
debugging output varies depending on the type of IPC activity that is specified. Each entry includes some
text explanationthe example below shows that the IPC control session was opened to port 0x1030000,
closed, and then clearedfollowed by a series of header or data fields.
Router# debug ipc sessions
Session level events debugging is on
*Sep 14 13:13:35.435: IPC: Control Session opened to port 0x1030000

*Sep 14 13:13:35.439: -Traceback= 40779898 4077649C 40776A00 40777040 4077554C
*Sep 14 13:13:35.439: IPC: Session 0 to port 0x1030000 closed
*Sep 14 13:13:35.439: -Traceback= 4077A9D4 40776370 4077132C 40771A58 4062EC7C 4028EC8C
40649710 4057F87C
*Sep 14 13:13:35.439: IPC: Session handle of session 0 to port 0x1030000 cleared
*Sep 14 13:13:35.439: -Traceback= 407798EC 4077A9E0 40776370 4077132C 40771A58 4062EC7C
4028EC8C 40649710 4057F87C

debug ipc packets Displays debugging messages about IPC packets.
show ipc Displays IPC information.

May 2008 DB-1249
Debug Commands
debug iphc ipc
debug iphc ipc

To display the IP header compression (IPHC) interprocessor communication (IPC) messages that are
passed between the route processor (RP) and line cards (LCs), use the debug iphc ipc command in
privileged EXEC mode. To disable the display of these messages, use the no form of this command.
debug iphc ipc [events | statistics]
no debug iphc ipc [events | statistics]
Syntax Description events (Optional) Displays IPHC IPC command and control events.
statistics (Optional) Displays IPHC IPC counter updates.
Command Default IPHC IPC messages are not displayed.

12.0(32)SY This command was introduced.
Usage Guidelines If you issue the debug iphc ipc command without keywords, all the IPC messages that are passed
between the RP and the LC are displayed. On routers with many interfaces and distributed systems, the
number of IPC messages becomes unwieldy, because of all the counter updates. To display only the
events that indicate interface state changes, issue the debug iphc ipc events command.
Examples The following example enables the display of all IPHC IPC messages:
Router# debug iphc ipc
IPHC IPC statistics debugging is on

IPHC IPC event debugging is on
The following example disables IPHC IPC statistics debugging:
Router# no debug iphc ipc statistics
IPHC IPC statistics debugging is off
The following example enables the display of IPHC IPC event messages:
Router# debug iphc ipc events

DB-1250 May 2008
Debug Commands
debug iphc ipc
IPHC IPC event debugging is on
The command output shows the event messages as the interface changes from enabled to
administratively down:
%OSPF-5-ADJCHG: Process 1, Nbr 10.10.10.10 on Multilink8 from FULL to DOWN
%LINK-5-CHANGED: Interface Multilink8, changed state to administratively down.
IPHC IPC 2: Set Negotiated mesg (Mu PPP 128 2 0)
IPHC Mu8: Distributed FS disabled
IPHC IPC 2: Send Set Configured mesg (Mu PPP 128 2 0)
IPHC IPC Mu8: i/f state change complete (Up/Down: 0/1)
The following example enables the display of IPHC IPC counter updates:
Router# debug iphc ipc statistics
IPHC IPC statistics debugging is on
The command output shows the interface counter updates:

IPHC IPHC 2: recv Stats msg, count:4
IPHC IPC Mu8: stats update from LC
IPHC IPC Mu6: stats update from LC
IPHC IPC Se2/0/0/3:0: stats update from LC
IPHC IPC Se2/0/0/1:0: stats update from LC

show interfaces Displays statistics for all interfaces.
show ipc Displays IPC statistics.

May 2008 DB-1251
Debug Commands
debug ipv6 cef drop
debug ipv6 cef drop

To display debug messages for Cisco Express Forwarding for IPv6 (CEFv6) and distributed CEFv6
(dCEFv6) dropped packets, use the debug ipv6 cef drop command in privileged EXEC mode. To disable
debug messages for CEFv6 and dCEFv6 dropped packets, use the no form of this command.
debug ipv6 cef drop [rpf]
no debug ipv6 cef drop
Syntax Description rpf (Optional) Displays packets dropped by the IPv6 CEF Unicast
Reverse-Path Forwarding (Unicast RPF) feature.
Command Default Debugging for CEFv6 and dCEFv6 dropped packets is not enabled.

12.2(25)S The rpf keyword was added.
Usage Guidelines The debug ipv6 cef drop command is similar to the debug ip cef drops command, except that it is
IPv6-specific.
console. To redirect debug output, use the logging command options in global configuration mode.
server. For complete information on debug commands and redirecting debug output, refer to the
Release 12.3 Cisco IOS Debug Command Reference.

DB-1252 May 2008
Debug Commands
debug ipv6 cef drop
Examples The following is sample output from the debug ipv6 cef drop command:
Router# debug ipv6 cef drop
*Aug 30 08:20:51.169: IPv6-CEF: received packet on Serial6/0/2

*Aug 30 08:20:51.169: IPv6-CEF: found no adjacency for 2001:0DB8::1 reason 2
*Aug 30 08:20:51.169: IPv6-CEF: packet not switched: code 0x1
Table 184 debug ipv6 cef drop Field Descriptions
Field Description
IPv6-CEF: received packet on Cisco Express Forwarding has received a packet addressed to the
Serial6/0/2 router via serial interface 6/0/2.
IPv6-CEF: found no adjacency Cisco Express Forwarding has found no adjacency for the IPv6
for 2001:0DB8::1 address prefix of 2001:0DB8::1.
IPv6-CEF: packet not switched Cisco Express Forwarding has dropped the packet.

debug ipv6 cef events Displays debug messages for CEFv6 and dCEFv6 general events.
debug ipv6 cef table Displays debug messages for CEFv6 and dCEFv6 table modification events.

May 2008 DB-1253
Debug Commands
debug ipv6 cef events

(dCEFv6) general events, use the debug ipv6 cef events command in privileged EXEC mode. To disable
debug messages for CEFv6 and dCEFv6 general events, use the no form of this command.
no debug ipv6 cef events
Command Default Debugging for CEFv6 and dCEFv6 general events is not enabled.

Usage Guidelines The debug ipv6 cef events command is similar to the debug ip cef events command, except that it is
IPv6-specific.
Release 12 Cisco IOS Debug Command Reference.

DB-1254 May 2008
Debug Commands
Examples The following is sample output from the debug ipv6 cef events command:
Router# debug ipv6 cef events
IPv6 CEF packet events debugging is on

Router#
*Aug 30 08:22:57.809: %LINK-3-UPDOWN: Interface Serial6/0/2, changed state to up
*Aug 30 08:22:58.809: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial6/0/2, changed
state to up
*Aug 30 08:23:00.821: CEFv6-IDB: Serial6/0/2 address 2001:0DB8::248 add download succeeded
Table 185 debug ipv6 cef events Field Descriptions
Field Description
Interface Serial6/0/2, changed Indicates that the interface hardware on serial interface 6/0/2 is
state to up currently active.
Line protocol on Interface Indicates that the software processes that handle the line protocol
Serial6/0/2, changed state to up consider the line usable for serial interface 6/0/2.
Serial6/0/2 address The IPv6 address 2001:0DB8::248 was downloaded successfully.
2001:0DB8::248 add download
succeeded


May 2008 DB-1255
Debug Commands
debug ipv6 cef hash
debug ipv6 cef hash

(dCEFv6) load-sharing hash algorithm events, use the debug ipv6 cef hash command in privileged
EXEC mode. To disable debug messages for CEFv6 and dCEFv6 load-sharing hash algorithm events,
debug ipv6 cef hash
no debug ipv6 cef hash
Command Default Debugging for CEFv6 and dCEFv6 load-sharing hash algorithm events is not enabled.

Usage Guidelines The debug ipv6 cef hash command is similar to the debug ip cef hash command, except that it is
IPv6-specific.
Use this command when changing the load-sharing algorithm to display IPv6 hash table details.

DB-1256 May 2008
Debug Commands
debug ipv6 cef hash


May 2008 DB-1257
Debug Commands
debug ipv6 cef receive

(dCEFv6) packets that are process-switched on the router, use the debug ipv6 cef receive command in
privileged EXEC mode. To disable debug messages for CEFv6 and dCEFv6 packets that are
process-switched on the router, use the no form of this command.
no debug ipv6 cef receive
Command Default Debugging for CEFv6 and dCEFv6 packets that are process-switched on the router is not enabled.

Usage Guidelines The debug ipv6 cef receive command is similar to the debug ip cef receive command, except that it is
IPv6-specific.

DB-1258 May 2008
Debug Commands
Examples The following is sample output from the debug ipv6 cef receive command when another router in the
network pings 2001:0DB8::2 which is a local address on this box:
Router# debug ipv6 cef receive
IPv6 CEF packet receives debugging is on

router#
*Aug 30 08:25:14.869: IPv6CEF-receive: Receive packet for 2001:0DB8::2
Table 186 debug ipv6 cef receive Field Descriptions
Field Description
IPv6CEF-receive: Receive Cisco Express Forwarding has received a packet addressed to the
packet for 2001:0DB8::2 router.


May 2008 DB-1259
Debug Commands
debug ipv6 cef table

(dCEFv6) table modification events, use the debug ipv6 cef table command in privileged EXEC mode.
To disable debug messages for CEFv6 and dCEFv6 table modification events, use the no form of this
command.
debug ipv6 cef table [background]
no debug ipv6 cef table [background]
Syntax Description background (Optional) Sets CEFv6 and dCEFv6 table background updates.
Command Default Debugging for CEFv6 and dCEFv6 table modification events is not enabled.

Usage Guidelines The debug ipv6 cef table command is similar to the debug ip cef table command, except that it is
IPv6-specific.
This command is used to record CEFv6 and dCEFv6 table events related to the Forwarding Information
Base (FIB) tables. Types of events include the following:
Routing updates that populate the FIB tables
Flushing of the FIB tables
Adding or removing of entries to the FIB tables
Table reloading process

DB-1260 May 2008
Debug Commands
Cisco IOS Debug Command Reference.
Examples The following is sample output from the debug ipv6 cef table command when a static route is added:
Router# debug ipv6 cef table
IPv6 CEF table debugging is on
router(config)# ipv6 route 5555::/64 serial 2/0 3000::2

router(config)#
*Feb 24 08:46:09.187: IPv6CEF-Table: Event add, 5555::/64
*Feb 24 08:46:09.187: IPv6 CEF table: Created path_list 01184570
*Feb 24 08:46:09.187: IPv6 CEF table: Adding path 01181A80 to path_list 01184570 old path
count=0
*Feb 24 08:46:09.187: IPv6 CEF table: No matching list for path list 01184570
*Feb 24 08:46:09.187: IPv6 CEF table: Adding fib entry 0117EE80 to path_list 01184570 old
refcount=0
*Feb 24 08:46:09.187: IPv6 CEF table: Added path_list 01184570 to hash 50
*Feb 24 08:46:09.187: IPv6 CEF: Linking path 01181A80 to adjacency 01138E28
*Feb 24 08:46:09.187: IPv6 CEF table: Created 0 loadinfos for path_list 01184570
*Feb 24 08:46:09.187: IPv6CEF-Table: Validated 5555::/64
The following is sample output when the static route is removed:

router(config)# no ipv6 route 5555::/64 serial 2/0 3000::2
router(config)#
*Feb 24 08:46:43.871: IPv6CEF-Table: Event delete, 5555::/64
*Feb 24 08:46:43.871: IPv6CEF-Table: Invalidated 5555::/64
*Feb 24 08:46:43.871: IPv6CEF-Table: Deleted 5555::/64
*Feb 24 08:46:43.871: IPv6 CEF table: Removing fib entry 0117EE80 from path_list 01184570
old refcount=1
*Feb 24 08:46:43.871: IPv6 CEF table: Removed path_list 01184570 from hash 50
*Feb 24 08:46:43.871: IPv6 CEF table: Freeing path_list 01184570 refcount=0
*Feb 24 08:46:43.871: IPv6 CEF table: Freeing all 1 paths in path_list 01184570
*Feb 24 08:46:43.871: IPv6 CEF: deleting path 01181A80


May 2008 DB-1261
Debug Commands
debug ipv6 dhcp database

To enable debugging for the Dynamic Host Configuration Protocol (DHCP) for IPv6 binding database
agent, use the debug ipv6 dhcp database command in privileged EXEC mode. To disable the display
of debug messages for the DHCP for IPv6 binding database agent, use the no form of this command.
no debug ipv6 dhcp database
Command Default Debugging for the DHCP for IPv6 binding database agent is disabled.

Usage Guidelines The debug ipv6 dhcp database command enables debugging for DHCP for IPv6 database processing.
Examples The following example enables debugging for the DHCP for IPv6 binding database agent:
Router# debug ipv6 dhcp database

debug ipv6 dhcp Enables debugging for DHCP for IPv6.

DB-1262 May 2008
Debug Commands
debug ipv6 dhcp relay

To enable the Dynamic Host Configuration Protocol (DHCP) for IPv6 relay agent debugging, use the
debug ipv6 dhcp relay command in user EXEC and privileged EXEC mode. To disable DHCP for IPv6
relay agent debugging, use the no form of this command.
no debug ipv6 dhcp relay

Privileged EXEC

Usage Guidelines The DHCP for IPv6 client, server, and relay functions are mutually exclusive on an interface. When one
of these functions is already enabled and a user tries to configure a different function on the same
interface, one of the following messages is displayed: Interface is in DHCP client mode, Interface is
in DHCP server mode, or Interface is in DHCP relay mode.
Examples The following example enables DHCP for IPv6 relay agent debugging:
Router# debug ipv6 dhcp relay

debug ipv6 dhcp Enables debugging for DHCP for IPv6.

May 2008 DB-1263
Debug Commands
debug ipv6 dhcp
debug ipv6 dhcp

To enable debugging for Dynamic Host Configuration Protocol (DHCP) for IPv6, use the
debug ipv6 dhcp command in privileged EXEC mode. To disable debugging for DHCP for IPv6, use
debug ipv6 dhcp [detail]
no debug ipv6 dhcp [detail]
Syntax Description detail (Optional) Displays detailed information about DHCP for IPv6 message
decoding.
Command Default Debugging for the DHCP for IPv6 is disabled.

Usage Guidelines The detail keyword used with the debug ipv6 dhcp command reports detailed DHCP for IPv6 message
decoding.
Examples The following example enables debugging for the DHCP for IPv6:
Router# debug ipv6 dhcp

debug ipv6 dhcp Enables debugging for the DHCP for IPv6 binding database agent.
database

DB-1264 May 2008
Debug Commands
debug ipv6 eigrp
debug ipv6 eigrp

To display information about the Enhanced Interior Gateway Routing Protocol (EIGRP) for IPv6
protocol, use the debug ipv6 eigrp command in privileged EXEC mode. To disable debugging output,
debug ipv6 eigrp [as-number] [neighbor ipv6-address | notification | summary]
no debug ipv6 eigrp
Syntax Description as-number (Optional) Autonomous system number.

neighbor ipv6-address (Optional) IPv6 address of the neighboring router.
notification (Optional) Displays EIGRP for IPv6 events and notifications in the
console of the router.
summary (Optional) Displays a summary of EIGRP for IPv6 routing
information.

Usage Guidelines Because the debug ipv6 eigrp command generates a substantial amount of output, use it only when
traffic on the network is light.
Examples The following example enables debugging output:

Router# debug ipv6 eigrp

May 2008 DB-1265
Debug Commands
debug ipv6 icmp
debug ipv6 icmp

To display debugging messages for IPv6 Internet Control Message Protocol (ICMP) transactions
(excluding IPv6 ICMP neighbor discovery transactions), use the debug ipv6 icmp command in
debug ipv6 icmp
no debug ipv6 icmp
Command Default Debugging for IPv6 ICMP is not enabled.

Usage Guidelines The debug ipv6 icmp command is similar to the debug ip icmp command, except that it is IPv6-specific.
console. To redirect debugging output, use the logging command options in global configuration mode.
server.
This command helps you determine whether the router is sending or receiving IPv6 ICMP messages. Use
it, for example, when you are troubleshooting an end-to-end connection problem.

DB-1266 May 2008
Debug Commands
debug ipv6 icmp
Note For more information about the fields in debug ipv6 icmp output, refer to RFC 2463, Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6).
Examples The following is sample output from the debug ipv6 icmp command:
Router# debug ipv6 icmp
13:28:40:ICMPv6:Received ICMPv6 packet from 2000:0:0:3::2, type 136

13:28:45:ICMPv6:Received ICMPv6 packet from FE80::203:A0FF:FED6:1400, type 135
Table 187 describes significant fields shown in the first line of the display.
Table 187 debug ipv6 icmp Field Descriptions
Field Description
13:28:40: Indicates the time (hours:minutes:seconds) at which the ICMP
neighbor discovery event occurred.
nwnd: Indicates time (weeks, days) since last reboot of the event occurring.
(not shown in sample output) For example, 1w4d: indicates the time (since the last reboot) of the
event occurring was 1 week and 4 days ago.
ICMPv6: Indication that this message describes an ICMP version 6 packet.

May 2008 DB-1267
Debug Commands
debug ipv6 icmp
Table 187 debug ipv6 icmp Field Descriptions (continued)
Field Description
Received ICMPv6 packet IPv6 address from which the ICMP version 6 packet is received.
from 2000:0:0:3::2
type 136 The number variable indicates one of the following IPv6 ICMP
message types:
1Destination unreachable. The router cannot forward a packet
that was sent or received.
2Packet too big. The router attempts to send a packet that
exceeds the maximum transmission unit (MTU) of a link between
itself and the packet destination.
3Time exceeded. Either the hop limit in transit or the fragment
reassembly time is exceeded.
4Parameter problem. The router attempts to send an IPv6
packet that contains invalid parameters. An example is a packet
containing a next header type unsupported by the router that is
forwarding the packet.
128Echo request. The router received an echo reply.
129Echo reply. The router sent an echo reply.
133Router solicitation messages. Hosts send these messages to
prompt routers on the local link to send router advertisement
messages.
134Router advertisement messages. Routers periodically send
these messages to advertise their link-layer addresses, prefixes for
the link, and other link-specific information. These messages are
also sent in response to router solicitation messages.
135Neighbor solicitation messages. Nodes send these
messages to request the link-layer address of a station on the same
link.
136Neighbor advertisement messages. Nodes send these
messages, containing their link-local addresses, in response to
neighbor solicitation messages.
137Redirect messages. Routers send these messages to hosts
when a host attempts to use a less-than-optimal first hop address
when forwarding packets. These messages contain a better first
hop address that should be used instead.

DB-1268 May 2008
Debug Commands
debug ipv6 icmp
Following are examples of the IPv6 ICMP messages types that can be displayed by the debug ipv6 icmp
command:
ICMP echo request and ICMP echo reply messages. In the following example, an ICMP echo request
is sent to address 2052::50 and an ICMP echo reply is received from address 2052::50.
1w4d:ICMPv6:Sending echo request to 2052::50
1w4d:ICMPv6:Received echo reply from 2052::50
ICMP packet too big messages. In the following example, a router tried to forward a packet to
destination address 2052::50 via the next hop address 2052::52. The size of the packet was greater
than 1280 bytes, which is the MTU of destination address 2052::50. As a result, the router receives
an ICMP packet too big message from the next hop address 2052::52.
1w4d:Received ICMP too big from 2052::52 about 2052::50, MTU=1300
ICMP parameter problem messages. In the following example, an ICMP parameter problem
message is received from address 2052::52.
1w4d:Received ICMP parameter problem from 2052::52
ICMP time exceeded messages. In the following example, an ICMP time exceeded message is
received from address 2052::52.
1w4d:Received ICMP time exceeded from 2052::52
ICMP unreachable messages. In the following example, an ICMP unreachable message with code 1
is received from address 2052::52. Additionally, an ICMP unreachable message with code 1 is sent
to address 2060::20 about address 2062::20.
1w4d:Received ICMP unreachable code 1 from 2052::52
1w4d:Sending ICMP unreachable code 1 to 2060::20 about 2062::20
Table 188 lists the codes for ICMP unreachable messages.
Table 188 ICMP Unreachable MessagesCode Descriptions
Code Description
0 The router has no route to the packet destination.
1 Although the router has a route to the packet destination, communication is
administratively prohibited.
3 The address is unreachable.
4 The port is unreachable.

debug ipv6 nd Displays debugging messages for IPv6 ICMP neighbor discovery
transactions.

May 2008 DB-1269
Debug Commands
debug ipv6 inspect
debug ipv6 inspect

To display messages about Cisco IOS firewall events, use the debug ipv6 inspect command in privileged
debug ipv6 inspect {function-trace | object-creation | object-deletion | events | timers | protocol

| detailed}
no debug ipv6 inspect detailed
Syntax Description function-trace Displays messages about software functions called by the Cisco IOS
firewall.
object-creation Displays messages about software objects being created by the Cisco IOS
firewall. Object creation corresponds to the beginning of Cisco IOS
firewall-inspected sessions.
object-deletion Displays messages about software objects being deleted by the Cisco IOS
firewall. Object deletion corresponds to the closing of Cisco IOS
firewall-inspected sessions.
events Displays messages about Cisco IOS firewall software events, including
information about Cisco IOS firewall packet processing.
timers Displays messages about Cisco IOS firewall timer events such as when a
Cisco IOS firewall idle timeout is reached.
protocol Displays messages about Cisco IOS firewall-inspected protocol events,
including details about the protocol's packets.
detailed Use this form of the command in conjunction with other Cisco IOS firewall
debugging commands. This causes detailed information to be displayed for
all the other enabled Cisco IOS firewall debugging.
Command Default No default behavior or values.

12.2(2)T This command was introduced

DB-1270 May 2008
Debug Commands
debug ipv6 inspect
Examples The following example enables the display of messages about Cisco IOS firewall events:
debug ipv6 inspect

ipv6 inspect audit-trail Turns on CBAC audit trail messages, which are displayed
on the console after each Cisco IOS firewall session closes.
ipv6 inspect name Defines a set of ipv6 inspection rules.
show ipv6 inspect Displays CBAC configuration and session information.

May 2008 DB-1271
Debug Commands
debug ipv6 mfib
debug ipv6 mfib

To enable debugging output on the IPv6 Multicast Forwarding Information Base (MFIB), use the
debug ipv6 mfib command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
debug ipv6 mfib [group-name | group-address] [adjacency | signal | db | init | mrib | pak | ps]
no debug ipv6 mfib
Syntax Description group-name | group-address (Optional) IPv6 address, name, or interface of the multicast
group as defined in the Domain Name System (DNS) hosts table.
adjacency (Optional) Adjacency management activity.
signal (Optional) MFIB data-driven signaling to routing protocols
activity.
dd (Optional) Route database management activity.
init (Optional) Initialization or deinitialization activity.
mrib (Optional) Communication with the MRIB.
pak (Optional) Packet forwarding activity.
ps (Optional) Process-level-only packet forwarding activity.
Syntax Description Release Modification

Usage Guidelines If no keywords are used, all IPbv6 MFIB activity debugging output is displayed.
Examples The following example enables debugging output for adjacency management activity on the IPv6 MFIB:
Router# debug ipv6 mfib adjacency

DB-1272 May 2008
Debug Commands
debug ipv6 mld explicit
debug ipv6 mld explicit

To display information related to the explicit tracking of hosts, use the debug ipv6 mld explicit
command in privileged EXEC mode. To disable debugging, use the no form of this command.
debug ipv6 mld explicit [group-name | group-address]
no debug ipv6 mld explicit [group-name | group-address]
Syntax Description group-name | (Optional) IPv6 address or name of the multicast group.
group-address]
Command Default Debugging for the explicit tracking of hosts is not enabled.

Usage Guidelines When the optional group-name or group-address argument is not used, all debugging information is
displayed.
Examples The following example shows how to enable information to be displayed about the explicit tracking of
hosts. The command output is self-explanatory:
Router# debug ipv6 mld explicit
00:00:56:MLD:ET host FE80::A8BB:CCFF:FE00:800 report for FF05::6 (0 srcs) on Ethernet1/0

00:00:56:MLD:ET host FE80::A8BB:CCFF:FE00:800 switch to exclude for FF05::6 on Ethernet1/0
00:00:56:MLD:ET MRIB modify for (*,FF05::6) on Ethernet1/0 new 100, mdf 100

May 2008 DB-1273
Debug Commands
debug ipv6 mld ssm-map
debug ipv6 mld ssm-map

To display debug messages for Source Specific Multicast (SSM) mapping related to Multicast Listener
Discovery (MLD), use the debug ipv6 mld ssm-map command in privileged EXEC mode. To disable
debug messages for SSM mapping, use the no form of this command.
debug ipv6 mld ssm-map [source-address]
no debug ipv6 mld ssm-map [source-address]
Syntax Description source-address (Optional) Source address associated with an MLD membership for a group
identified by the access list.

Examples The following example allows debugging information for SSM mapping to be displayed:
Router# debug ipv6 mld ssm-map

ipv6 mld ssm-map Enables the SSM mapping feature for groups in the configured SSM range
enable
ipv6 mld ssm-map Enables DNS-based SSM mapping.
query dns
ipv6 mld ssm-map Configures static SSM mappings.
static
show ipv6 mld Displays SSM mapping information.
ssm-map

DB-1274 May 2008
Debug Commands
debug ipv6 mld
debug ipv6 mld

To enable debugging on Multicast Listener Discovery (MLD) protocol activity, use the debug ipv6 mld
command in privileged EXEC mode. To restore the default value, use the no form of this command.
debug ipv6 mld [group-name | group-address | interface-type]
no debug ipv6 mld [group-name | group-address | interface-type]
Cisco IOS Release 12.0(26)S
debug ipv6 mld [group group-name | group-address | interface interface-type]
no debug ipv6 mld [group group-name | group-address | interface interface-type]
group-address or
group group-name |
group-address
interface-type or (Optional) Interface type. For more information, use the question mark (?)
interface online help function.
interface-type

Usage Guidelines This command helps discover whether the MLD protocol activities are working correctly. In general, if
MLD is not working, the router process never discovers that there is a host on the network that is
configured to receive multicast packets.
The messages displayed by the debug ipv6 mld command show query and report activity received from
other routers and hosts. Use this command in conjunction with debug ipv6 pim to display additional
multicast activity, to learn more information about the multicast routing process, or to learn why packets
are forwarded out of particular interfaces.

May 2008 DB-1275
Debug Commands
debug ipv6 mld
Examples The following example enables debugging on MLD protocol activity:

Router# debug ipv6 mld

debug ipv6 pim Enables debugging on PIM protocol activity.

DB-1276 May 2008
Debug Commands
debug ipv6 mobile
debug ipv6 mobile

To enable the display of debugging information for Mobile IPv6, use the debug ipv6 mobile command
in privileged EXEC mode.
debug ipv6 mobile {binding-cache | forwarding | home-agent | registration}
Syntax Description binding-cache Events associated with the binding cache.

forwarding Events associated with forwarding (tunneling) packets for which the router
is acting as home agent.
home-agent Events associated with the home agent, Dynamic Home Address Agent
Discovery (DHAAD), Mobile prefix discovery (MPD), and generic home
agent (HA) debugging and binding acknowledgments.
registration Events associated with binding updates that are registrations.

Usage Guidelines The debug ipv6 mobile command enables the display of selected debugging information. You may use
multiple command lines to enable concurrent debugging of multiple classes of information.
Examples In the following example, debugging information is displayed for binding updates processing:
Router# debug ipv6 mobile registration

binding Configures binding options for the Mobile IPv6 home agent feature in
home-agent configuration mode.
ipv6 mobile Enters home agent configuration mode.
home-agent (global
configuration)

May 2008 DB-1277
Debug Commands
debug ipv6 mobile
Command Description
ipv6 mobile Initializes and start the IPv6 Mobile home agent on a specific interface.
home-agent (interface
configuration)
ipv6 mobile Configures the home agent preference value on the interface.
home-agent
preference

DB-1278 May 2008
Debug Commands
debug ipv6 mrib client

To enable debugging on Multicast Routing Information Base (MRIB) client management activity, use
the debug ipv6 mrib client command in privileged EXEC mode. To disable debugging output, use the
no debug ipv6 mrib client

Usage Guidelines The debug ipv6 mrib client command is used to display the activity in the MRIB associated with clients
such as Protocol Independent Multicast (PIM) and Multicast Listener Discovery (MLD). If you are
having difficulty with your client connections, use this command to display new clients being added and
deleted.
The debug ipv6 mrib client command also displays information on when a new client is added to or
deleted from the MRIB, when a client connection is established or torn down, when a client binds to a
particular MRIB table, and when a client is informed that there are updates to be read.
Examples The following example enables debugging on MRIB client management activity:
Router# debug ipv6 mrib client

debug ipv6 mrib route Displays MRIB routing entry-related activity.

May 2008 DB-1279
Debug Commands
debug ipv6 mrib io
debug ipv6 mrib io

To enable debugging on Multicast Routing Information Base (MRIB) I/O events, use the debug ipv6
mrib io command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug ipv6 mrib io
no debug ipv6 mrib io

Usage Guidelines Use the debug ipv6 mrib io command to display information on when clients open and close MRIB I/O
connections, when MRIB entry and interface updates are received and processed from clients, and when
MRIB entry and interface updates are sent to clients.
Examples The following example enables debugging on MRIB I/O events:

Router# debug ipv6 mrib io

DB-1280 May 2008
Debug Commands
debug ipv6 mrib proxy

To enable debugging on multicast routing information base (MRIB) proxy activity between the route
processor and line cards on distributed router platforms, use the debug ipv6 mrib proxy command in
no debug ipv6 mrib proxy

Usage Guidelines Use the debug ipv6 mrib proxy command to display information on connections that are being opened
and closed and on MRIB transaction messages that are being passed between the route processor and
line cards.
Examples The following example enables debugging on MRIB proxy events:

Router# debug ipv6 mrib proxy

May 2008 DB-1281
Debug Commands
debug ipv6 mrib route
debug ipv6 mrib route

To display information about Multicast Routing Information Base (MRIB) routing entry-related activity,
use the debug ipv6 mrib route command in privileged EXEC mode. To disable debugging output, use
debug ipv6 mrib route [group-name | group-address]
no debug ipv6 mrib route
Syntax Description group-name | (Optional)IPv6 address or name of the multicast group.

group-address

Usage Guidelines This command displays update information related to the route database made by MRIB clients, which
is then redistributed to the clients.
Use this command to monitor MRIB route activity when discontinuity is found between the MRIB and
the client database or between the individual client databases.
Examples The following example enables the display of information about MRIB routing entry-related activity:
Router# debug ipv6 mrib route

show ipv6 mrib client Displays information about the MRIB client management activity.

DB-1282 May 2008
Debug Commands
debug ipv6 mrib table

To enable debugging on Multicast Routing Information Base (MRIB) table management activity, use the
debug ipv6 mrib table command in privileged EXEC mode. To disable debugging output, use the no
no debug ipv6 mrib table

Usage Guidelines Use the debug ipv6 mrib table command to display information on new MRIB tables being added and
deleted.
Examples The following example enables debugging on MRIB table management activity:
Router# debug ipv6 mrib table

May 2008 DB-1283
Debug Commands
debug ipv6 nat
debug ipv6 nat

To display debug messages for Network Address TranslationProtocol Translation (NAT-PT)
translation events, use the debug ipv6 nat command in privileged EXEC mode. To disable debug
messages for NAT-PT translation events, use the no form of this command.
debug ipv6 nat [detailed | port]
no debug ipv6 nat [detailed | port]
Syntax Description detailed (Optional) Displays detailed information about NAT-PT translation events.
port (Optional) Displays port allocation events.
Command Default Debugging for NAT-PT translation events is not enabled.

12.3(2)T The port keyword was added to support Port Address Translation (PAT), or
overload, multiplexing multiple IPv6 addresses to a single IPv4 address or to
an IPv4 address pool.
Usage Guidelines The debug ipv6 nat command can be used to troubleshoot NAT-PT translation issues. If no keywords
are specified, debugging messages for all NAT-PT protocol translation events are displayed.
server.
Caution Because the debug ipv6 nat command generates a substantial amount of output, use it only when traffic
on the IPv6 network is low, so other activity on the system is not adversely affected.
Examples The following example shows output for the debug ipv6 nat command:
Router# debug ipv6 nat

DB-1284 May 2008
Debug Commands
debug ipv6 nat
00:06:06: IPv6 NAT: icmp src (3002::8) -> (192.168.124.8), dst (2001::2) ->
(192.168.123.2)
00:06:06: IPv6 NAT: icmp src (192.168.123.2) -> (2001::2), dst (192.168.124.8) ->
(3002::8)
00:06:06: IPv6 NAT: icmp src (3002::8) -> (192.168.124.8), dst (2001::2) ->
(192.168.123.2)
00:06:06: IPv6 NAT: icmp src (192.168.123.2) -> (2001::2), dst (192.168.124.8) ->
(3002::8)
00:06:06: IPv6 NAT: tcp src (3002::8) -> (192.168.124.8), dst (2001::2) -> (192.168.123.2)
00:06:06: IPv6 NAT: tcp src (192.168.123.2) -> (2001::2), dst (192.168.124.8) -> (3002::8)
00:06:06: IPv6 NAT: tcp src (192.168.123.2) -> (2001::2), dst (192.168.124.8) -> (3002::8)
Table 189 debug ipv6 nat Field Descriptions
Field Description
IPv6 NAT: Indicates that this is a NAT-PT packet.
icmp Protocol of the packet being translated.
src (3000::8) -> (192.168.124.8) The source IPv6 address and the NAT-PT mapped IPv4 address.
Note If mapping IPv4 hosts to IPv6 hosts the first address
would be an IPv4 address, and the second address an IPv6
address.
dst (2001::2) -> (192.168.123.2) The destination IPv6 address and the NAT-PT mapped IPv4
address.
Note If mapping IPv4 hosts to IPv6 hosts the first address
would be an IPv4 address, and the second address an IPv6
address.
The following example shows output for the debug ipv6 nat command with the detailed keyword:
Router# debug ipv6 nat detailed
00:14:12: IPv6 NAT: address allocated 192.168.124.8

00:14:16: IPv6 NAT: deleted a NAT entry after timeout

May 2008 DB-1285
Debug Commands
debug ipv6 nd
debug ipv6 nd
To display debug messages for IPv6 Internet Control Message Protocol (ICMP) neighbor discovery
transactions, use the debug ipv6 nd command in privileged EXEC mode. To disable debug messages for
IPv6 ICMP neighbor discovery transactions, use the no form of this command.
debug ipv6 nd
no debug ipv6 nd
Command Default Debugging for IPv6 ICMP neighbor discovery is not enabled.

12.2(4)T The DAD: <nnnn::nn:> is unique, DAD: duplicate link-local <nnnn::nn:> on
<interface type>, interface stalled, and Received NA for <nnnn::nn:> on
<interface type> from <nnnn::nn:> fields were added to the command
output.
Usage Guidelines This command can help determine whether the router is sending or receiving IPv6 ICMP neighbor
discovery messages.

DB-1286 May 2008
Debug Commands
debug ipv6 nd
Examples The following example shows output for the debug ipv6 nd command:
Router# debug ipv6 nd
13:22:40:ICMPv6-ND:STALE -> DELAY:2000:0:0:3::2

13:22:45:ICMPv6-ND:DELAY -> PROBE:2000:0:0:3::2
13:22:45:ICMPv6-ND:Sending NS for 2000:0:0:3::2 on FastEthernet0/0
13:22:45:ICMPv6-ND:Received NA for 2000:0:0:3::2 on FastEthernet0/0 from 2000:0:0:3::2
13:22:45:ICMPv6-ND:PROBE -> REACH:2000:0:0:3::2
13:22:45:ICMPv6-ND:Received NS for 2000:0:0:3::1 on FastEthernet0/0 from
FE80::203:A0FF:FED6:1400
13:22:45:ICMPv6-ND:Sending NA for 2000:0:0:3::1 on FastEthernet0/0
13:23:15: ICMPv6-ND: Sending NS for FE80::1 on Ethernet0/1

13:23:16: ICMPv6-ND: DAD: FE80::1 is unique.
13:23:16: ICMPv6-ND: Sending NS for 2000::2 on Ethernet0/1
13:23:16: ICMPv6-ND: Sending NS for 3000::3 on Ethernet0/1
13:23:16: ICMPv6-ND: Sending NA for FE80::1 on Ethernet0/1
13:23:17: ICMPv6-ND: DAD: 2000::2 is unique.
13:23:53: ICMPv6-ND: Sending NA for 2000::2 on Ethernet0/1
13:23:53: ICMPv6-ND: DAD: 3000::3 is unique.
13:23:53: ICMPv6-ND: Sending NA for 3000::3 on Ethernet0/1
3d19h: ICMPv6-ND: Sending NS for FE80::2 on Ethernet0/2
3d19h: ICMPv6-ND: Received NA for FE80::2 on Ethernet0/2 from FE80::2
3d19h: ICMPv6-ND: DAD: duplicate link-local FE80::2 on Ethernet0/2,interface stalled
3d19h: %IPV6-4-DUPLICATE: Duplicate address FE80::2 on Ethernet0/2
3d19h: ICMPv6-ND: Sending NS for 3000::4 on Ethernet0/3
3d19h: ICMPv6-ND: Received NA for 3000::4 on Ethernet0/3 from 3000::4
3d19h: %IPV6-4-DUPLICATE: Duplicate address 3000::4 on Ethernet0/3
Table 190 debug ipv6 nd Field Descriptions
Field Description
13:22:40: Indicates the time (hours:minutes:seconds) at which the ICMP
neighbor discovery event occrred.
ICMPv6-ND Indicates that a state change is occurring for an entry in the IPv6
neighbors cache.
STALE Stale state. This state of an neighbor discovery cache entry used to be
reachable, but is now is stale due to the entry not being used. In
order to use this address, the router must go through the neighbor
discovery process in order to confirm reachability.
DELAY Delayed state. Reachability for this ND cache entry is currently being
reconfirmed. While in the delay state, upper-layer protocols may
inform IPv6 that they have confirmed reachability to the entry.
Therefore, there is no need to send a neighbor solicitation for the
entry.
PROBE Probe state. While in the probe state, if no confirmation is received
from the upper-layer protocols about the reachability of the entry, a
neighbor solicitation message is sent. The entry remains in the
probe state until a neighbor advertisement message is received in
response to the neighbor solicitation message.

May 2008 DB-1287
Debug Commands
debug ipv6 nd
Table 190 debug ipv6 nd Field Descriptions (continued)
Field Description
Sending NS for... Sending a neighbor solicitation message. In the example output, a
neighbor solicitation message is sent on Fast Ethernet interface 0/0 to
determine the link-layer address of 2000:0:0:3::2 on Fast Ethernet
interface 0/0.
Received NA for... Received a neighbor advertisement message. In the example output, a
neighbor advertisement message is received from the address
2000:0:0:3::2 (the second address) that includes the link-layer address
of 2000:0:0:3::2 (first address) from Ethernet interface 0/0.
REACH Reachable state. An ND cache entry in this state is considered
reachable, and the corresponding link-layer address can be used
without needing to perform neighbor discovery on the address.
Received NS for... Received neighbor solicitations. In the example output, the address
FE80::203:A0FF:FED6:1400 (on Fast Ethernet interface 0/0) is trying
to determine the link-local address of 2000:0:0:3::1.
Sending NA for... Sending for neighbor advertisements. In the example output, a
neighbor advertisement containing the link-layer address of
2000:0:0:3::1 (an address assigned to the Fast Ethernet interface 0/0
address) was sent.
DAD: FE80::1 is unique. Duplicate address detection processing was performed on the unicast
IPv6 address (a neighbor solicitation message was not received in
response to a neighbor advertisement message that contained the
unicast IPv6 address) and the address is unique.
3d19h: Indicates time (days, hours) since the last reboot of the event
occurring; 3d19h: indicates the time (since the last reboot) of the event
occurring was 3 days and 19 hours ago.
DAD: duplicate link-local Duplicate address detection processing was performed on the
FE80::2 on Ethernet0/2, link-local IPv6 address (the link-local address FE80::2 is used in the
interface stalled example). A neighbor advertisement message was received in
response to a neighbor solicitation message that contained the
link-local IPv6 address. The address is not unique, and the processing
of IPv6 packets is disabled on the interface.
%IPV6-4-DUPLICATE: System error message indicating the duplicate address.
Duplicate address...
Received NA for 3000::4 on Duplicate address detection processing was performed on the global
Ethernet0/3 from 3000::4 IPv6 address (the global address 3000::4 is used in the example). A
neighbor advertisement message was received in response to a
neighbor solicitation message that contained the global IPv6 address.
The address is not unique and is not used.

debug ipv6 icmp Displays debug messages for IPv6 ICMP transactions.
show ipv6 neighbors Displays IPv6 neighbor discovery cache information.

DB-1288 May 2008
Debug Commands
debug ipv6 ospf database-timer rate-limit
debug ipv6 ospf database-timer rate-limit

To display debugging information about the current wait-time used for SPF scheduling, use the debug
ipv6 ospf database-timer rate-limit command in privileged EXEC mode. To disable debugging output,
debug ipv6 ospf database-timer rate-limit [acl-number]
no debug ipv6 ospf database-timer rate-limit
Syntax Description acl-number (Optional) Access list number.

Examples The following example shows how to turn on debugging for SPF scheduling:
Router# debug ipv6 ospf database-timer rate-limit

May 2008 DB-1289
Debug Commands
debug ipv6 ospf events

To display information on Open Shortest Path First (OSPF)-related events, such as designated router
selection and shortest path first (SPF) calculation, use the debug ipv6 ospf events command in
privileged EXEC command. To disable debugging output, use the no form of this command.
no debug ipv6 ospf events

Examples The following example displays information on OSPF-related events:

Router# debug ipv6 ospf events

DB-1290 May 2008
Debug Commands
debug ipv6 ospf lsdb

To display database modifications for Open Shortest Path First (OSPF) for IPv6, use the debug ipv6 ospf
lsdb command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
no debug ipv6 ospf lsdb

Examples The following example displays database modification information for OSPF for IPv6:
Router# debug ipv6 ospf lsdb

May 2008 DB-1291
Debug Commands
debug ipv6 ospf monitor

To display debugging information about the current wait-time used for shortest path first (SPF)
scheduling, use the debug ipv6 ospf monitor command in privileged EXEC mode. To disable debugging
no debug ipv6 ospf monitor

Examples The following example shows debugging information about SPF scheduling:
Router# debug ipv6 ospf monitor
Sep 27 08:29:49.319: OSPFv3: Schedule SPF in area 0

Change in LS ID 0.0.0.0, LSA type P
*Sep 27 08:29:49.327: OSPFv3: reset throttling to 5000ms next wait-interval 10000ms
*Sep 27 08:29:49.327: OSPFv3: schedule SPF: spf_time 00:09:36.032 wait_interval 5000ms
IOU_Topvar#
*Sep 27 08:29:54.331: OSPFv3: Begin SPF at 581.036ms, process time 40ms
*Sep 27 08:29:54.331: spf_time 00:09:36.032, wait_interval 5000ms
*Sep 27 08:29:54.331: OSPFv3: Setting next wait-interval to 10000ms
*Sep 27 08:29:54.331: OSPFv3: End SPF at 581.036ms, Total elapsed time 0ms
*Sep 27 08:29:54.331: Schedule time 00:09:41.036, Next wait_interval 10000ms
*Sep 27 08:29:54.331: Intra: 0ms, Inter: 0ms, External: 0ms
*Sep 27 08:29:54.331: R: 0, N: 0
*Sep 27 08:29:54.331: SN: 0, SA: 0, X5: 0, X7: 0
*Sep 27 08:29:54.331: SPF suspends: 0 intra, 0 total

DB-1292 May 2008
Debug Commands
debug ipv6 ospf packet

To display information about each Open Shortest Path First (OSPF) for IPv6 packet received, use the
debug ipv6 ospf packet command in privileged EXEC mode. To disable debugging output, use the no
no debug ipv6 ospf packet

Examples The following example displays information about each OSPF for IPv6 packet received:
Router# debug ipv6 ospf packet

May 2008 DB-1293
Debug Commands
debug ipv6 ospf spf statistic

To display statistical information while running the shortest path first (SPF) algorithm, use the debug
ipv6 ospf spf statistic command in privileged EXEC mode. To disable the debugging output, use the no
no debug ipv6 ospf spf statistic

Usage Guidelines The debug ipv6 ospf spf statistic command displays the SPF calculation times in milliseconds, the node
count, and a time stamp. Consult Cisco technical support before using this command.
Examples The following example displays statistical information while running the SPF algorithm:
Router# debug ipv6 ospf spf statistics

debug ipv6 ospf Displays debugging information for the OSPFv3 for IPv6 feature.
debug ipv6 ospf events Displays information on OSPFv3-related events.
debug ipv6 ospf packet Displays information about each OSPFv3 packet received.

DB-1294 May 2008
Debug Commands
debug ipv6 ospf
debug ipv6 ospf

To display debugging information for Open Shortest Path First (OSPF) for IPv6, use the debug ipv6 ospf
debug ipv6 ospf [adj | ipsec | database-timer | flood | hello | lsa-generation | retransmission]
no debug ipv6 ospf [adj | ipsec | database-timer | flood | hello | lsa-generation | retransmission]
Syntax Description adj (Optional) Displays adjacency information.

ipsec (Optional) Displays the interaction between OSPF and IPSec in IPv6
networks, including creation and removal of policy definitions.
database-timer (Optional) Displays database-timer information.
flood (Optional) Displays flooding information.
hello (Optional) Displays hello packet information.
lsa-generation (Optional) Displays link-state advertisement (LSA) generation
information for all LSA types.
retransmission (Optional) Displays retransmission information.
Command Default Debugging of OSPF for IPv6 is not enabled.

12.2(18)S This command was integrated in Cisco IOS Release 12.2(18)S.
12.3(4)T The ipsec keyword was added to support OSPF for IPv6 authentication for
IPSec.
Examples The following example displays adjacency information for OSPF for IPv6:

May 2008 DB-1295
Debug Commands
debug ipv6 ospf
Router# debug ipv6 ospf adj

DB-1296 May 2008
Debug Commands
debug ipv6 packet
debug ipv6 packet

To display debug messages for IPv6 packets, use the debug ipv6 packet command in privileged EXEC
mode. To disable debug messages for IPv6 packets, use the no form of this command.
debug ipv6 packet [access-list access-list-name] [detail]
no debug ipv6 packet [access-list access-list-name] [detail]
Syntax Description access-list (Optional) Specifies an IPv6 access list. The access list name cannot contain
access-list-name a space or quotation mark, or begin with a numeric
detail (Optional) May display additional detailed information about the IPv6
packet.
Command Default Debugging for IPv6 packets is not enabled.

12.0(23)S The access-list and detail keywords, and the access-list-name argument,
were added.
12.2(13)T The access-list and detail keywords, and the access-list-name argument,
were added.
Usage Guidelines The debug ipv6 packet command is similar to the debug ip packet command, except that it is
IPv6-specific.

May 2008 DB-1297
Debug Commands
debug ipv6 packet
IPv6 debugging information includes packets received, generated, and forwarded. Fast-switched packets
do not generate messages. When an IPv6 access list is specified by using the access-list keyword and
access-list-name argument, only packets matching the access list permit entries are displayed.
Caution Because the debug ipv6 packet command generates a substantial amount of output, use it only when
traffic on the IPv6 network is low, so other activity on the system is not adversely affected.
Examples The following example shows output for the debug ipv6 packet command:
Router# debug ipv6 packet
13:25:40:IPV6:source 2000:0:0:3::1 (local)

13:25:40: dest 2000:0:0:3::2 (FastEthernet0/0)
13:25:40: traffic class 96, flow 0x0, len 143+195, prot 6, hops 64, originating
13:25:40:IPv6:Sending on FastEthernet0/0
13:25:40:IPV6:source 2000:0:0:3::2 (FastEthernet0/0)
13:25:40: dest 2000:0:0:3::1
13:25:40: traffic class 96, flow 0x0, len 60+14, prot 6, hops 64, forward to ulp
13:25:45:IPV6:source FE80::203:E4FF:FE12:CC1D (local)
13:25:45: dest FF02::9 (Ethernet1/1)
13:25:45:IPv6:Sending on Ethernet1/1
13:25:45:IPV6:source FE80::203:E4FF:FE12:CC00 (local)
13:25:45: dest 2000:0:0:3::2 (FastEthernet0/0)
13:25:45:IPv6:Sending on FastEthernet0/0
13:25:45:IPV6:source 2000:0:0:3::2 (FastEthernet0/0)
13:25:45: dest FE80::203:E4FF:FE12:CC00
13:25:45:IPV6:source FE80::203:A0FF:FED6:1400 (FastEthernet0/0)
13:25:45: dest 2000:0:0:3::1
Table 191 debug ipv6 packet Field Descriptions
Field Description
IPV6: Indicates that this is an IPv6 packet.
source 2000:0:0:3::1 (local) The source address in the IPv6 header of the packet.
dest 2000:0:0:3::2 The destination address in the IPv6 header of the packet.
(FastEthernet0/0)
traffic class 96 The contents of the traffic class field in the IPv6 header.

DB-1298 May 2008
Debug Commands
debug ipv6 packet
Table 191 debug ipv6 packet Field Descriptions (continued)
Field Description
flow 0x0 The contents of the flow field of the IPv6 header. The flow field is
used to label sequences of packets for which special handling is
necessary by IPv6 routers.
len 64+14 The length of the IPv6 packet. The length is expressed as two numbers
with a plus (+) character between the numbers. The first number is the
length of the IPv6 portion (IPv6 header length plus payload length).
The second number is the entire datagram size minus the first number.
prot 6 The protocol field in the IPv6 header. Describes the next layer
protocol that is carried by the IPv6 packet. In the example, the
protocol 58 signifies that the next layer protocol is ICMPv6.
hops 64 The hops field in the IPv6 packet. This field is similar in function to
the IPv4 time-to-live field.
originating The presence of this field indicates that the packet shown was
originated by the router.
Sending on FastEthernet0/0 Specifies the interface on which the packet was sent.
forward to ulp Indicates that the packet was received by the router at the destination
address and was forwarded to an upper-layer protocol (ulp) for
processing.

May 2008 DB-1299
Debug Commands
debug ipv6 pim df-election

To display debug messages for Protocol Independent Multicast (PIM) bidirectional designated forwarder
(DF) election message processing, use the debug ipv6 pim df-election command in privileged EXEC
mode. To disable debug messages for PIM bidirectional DF election message processing, use the no form
of this command.
debug ipv6 pim df-election [interface type number] [rp rp-name | rp-address]
no debug ipv6 pim df-election [interface type number] [rp rp-name | rp-address]
Syntax Description interface (Optional) Specifies that debug messages on a specified interface will be
displayed.
type number (Optional) Interface type and number. For more information, use the
question mark (?) online help function.
rp (Optional) Specifies that debug messages on a specified Route Processor
(RP) will be displayed.
rp-name (Optional) The name of the specified RP.
rp-address (Optional) The IPv6 address of the specified RP.
Command Default Debugging for PIM bidirectional DF election message processing is not enabled.

Usage Guidelines Use the debug ipv6 pim df-election command if traffic is not flowing properly when operating in PIM
bidirectional mode or if the show ipv6 pim df and show ipv6 pim df winner commands do not display
the expected information.
Examples The following example shows how to enable debugging for PIM bidirectional DF election message
processing on Ethernet interface 1/0 and at 200::1:

DB-1300 May 2008
Debug Commands
debug ipv6 pim df-election interface ethernet 1/0 rp 200::1

ipv6 pim rp-address Configures the address of a PIM RP for a particular group range.
show ipv6 pim df Displays the DF-election state of each interface for each RP.
show ipv6 pim df Displays the DF-election winner on each interface for each RP.
winner

May 2008 DB-1301
Debug Commands
debug ipv6 pim
debug ipv6 pim

To enable debugging on Protocol Independent Multicast (PIM) protocol activity, use the
debug ipv6 pim command in privileged EXEC mode. To restore the default value, use the no form of
this command.
debug ipv6 pim [group-name | group-address | interface-type | neighbor | bsr]
no debug ipv6 pim [group-name | group-address | interface-type | neighbor | bsr]
group-address
interface-type (Optional) Interface type. For more information, use the question mark (?)
online help function.
neighbor (Optional) Debug statistics related to hello message processing and neighbor
cache management.
bsr (Optional) Debug statistics specific to bootstrap router (BSR) protocol
operation.

12.0(28)S The bsr keyword was added.
12.2(25)S The bsr keyword was added.
12.3(11)T The bsr keyword was added.
Usage Guidelines This command helps discover whether the PIM protocol activities are working correctly.
The messages displayed by the debug ipv6 pim command show all PIM protocol messages, such as joins
and prunes, received from or sent to other routers. Use this command in conjunction with debug ipv6
mld to display additional multicast activity, to learn more information about the multicast routing
process, or to learn why packets are forwarded out of particular interfaces.

DB-1302 May 2008
Debug Commands
debug ipv6 pim
Examples The following example enables debugging on PIM activity:

Router# debug ipv6 pim

debug ipv6 mld Enables debugging on MLD protocol activity.

May 2008 DB-1303
Debug Commands
debug ipv6 policy
debug ipv6 policy

To display IPv6 policy routing packet activity, use the debug ipv6 policy command in user EXEC or
debug ipv6 policy [access-list-name]
no debug ipv6 policy [access-list-name]
Syntax Description access-list-name (Optional) Name of the IPv6 access list for which to clear the match
counters. Names cannot contain a space or quotation mark, or begin with a
numeric.
Command Default IPv6 policy routing packet activity is not displayed.

Privileged EXEC

Usage Guidelines If no access list is specified using the optional access-list-name argument, information about all
policy-matched and policy-routed packets is displayed.
After you configure IPv6 policy routing, use the debug ipv6 policy command to verify that IPv6
policy-based routing (PBR) is policy-routing packets normally. Policy routing looks at various parts of
the packet and then routes the packet based on certain user-defined attributes in the packet. The debug
ipv6 policy command helps you determine what policy routing is following. It displays information
about whether a packet matches the criteria, and if so, the resulting routing information for the packet.
Do not use the debug ipv6 policy command unless you suspect a problem with IPv6 PBR policy routing.
Examples The following example enables IPv6 policy routing packet activity. The output for this command is
self-explanatory:
Router# debug ipv6 policy
00:02:38:IPv6 PBR:Ethernet0/0, matched src 2003::90 dst 2001:1000::1 protocol 58

00:02:38:IPv6 PBR:set nexthop 2003:1::95, interface Ethernet1/0
00:02:38:IPv6 PBR:policy route via Ethernet1/0/2003:1::95

DB-1304 May 2008
Debug Commands
debug ipv6 pool
debug ipv6 pool

To enable debugging on IPv6 prefix pools, use the debug ipv6 pool command in privileged EXEC mode.
To disable debugging, use the no form of this command.
debug ipv6 pool
no debug ipv6 pool
Command Default No debugging is active.

Examples The following example enables debugging for IPv6 prefix pools:
Router# debug ipv6 pool
2w4d: IPv6 Pool: Deleting route/prefix 2001:0DB8::/29 to Virtual-Access1 for cisco

2w4d: IPv6 Pool: Returning cached entry 2001:0DB8::/29 for cisco on Virtual-Access1 to
pool1
2w4d: IPv6 Pool: Installed route/prefix 2001:0DB8::/29 to Virtual-Access1 for cisco

ipv6 local pool Configures a local IPv6 prefix pool.
show ipv6 interface Displays the usability status of interfaces configured for IPv6.
show ipv6 local pool Displays information about defined IPv6 prefix pools.

May 2008 DB-1305
Debug Commands
debug ipv6 rip
debug ipv6 rip

To display debug messages for IPv6 Routing Information Protocol (RIP) routing transactions, use the
debug ipv6 rip command in privileged EXEC mode. To disable debug messages for IPv6 RIP routing
transactions, use the no form of this command.
debug ipv6 rip [interface-type interface-number]
no debug ipv6 rip [interface-type interface-number]
Syntax Description interface-type (Optional) The interface type about which to display debug messages.
interface-number (Optional) The interface number about which to display debug messages.
Command Default IPv6 RIP debugging is not enabled.

Usage Guidelines The debug ipv6 rip command is similar to the debug ip rip command, except that it is IPv6-specific.
Using this command without arguments enables IPv6 RIP debugging for RIP packets that are sent and
received on all router interfaces. Using this command with arguments enables IPv6 RIP debugging for
RIP packets that are sent and received only on the specified interface.

DB-1306 May 2008
Debug Commands
debug ipv6 rip
Caution Using this command on busy networks seriously degrades the performance of the router.
Examples The following example shows output for the debug ipv6 rip command:
Router# debug ipv6 rip
13:09:10:RIPng:Sending multicast update on Ethernet1/1 for as1_rip

13:09:10: src=FE80::203:E4FF:FE12:CC1D
13:09:10: dst=FF02::9 (Ethernet1/1)
13:09:10: sport=521, dport=521, length=32
13:09:10: command=2, version=1, mbz=0, #rte=1
13:09:10: tag=0, metric=1, prefix=::/0
13:09:28:RIPng:response received from FE80::202:FDFF:FE77:1E42 on Ethernet1/1 for as1_rip
13:09:28: src=FE80::202:FDFF:FE77:1E42 (Ethernet1/1)
13:09:28: dst=FF02::9
13:09:28: sport=521, dport=521, length=32
13:09:28: command=2, version=1, mbz=0, #rte=1
13:09:28: tag=0, metric=1, prefix=2000:0:0:1:1::/80
The example shows two RIP packets; both are updates, known as responses in RIP terminology and
indicated by a command value of 2. The first is an update sent by this router, and the second is an
update received by this router. Multicast update packets are sent to all neighboring IPv6 RIP routers (all
routers that are on the same links as the router sending the update, and that have IPv6 RIP enabled). An
IPv6 RIP router advertises the contents of its routing table to its neighbors by periodically sending
update packets over those interfaces on which IPv6 RIP is configured. An IPv6 router may also send
triggered updates immediately following a routing table change. In this case the updates only includes
the changes to the routing table. An IPv6 RIP router may solicit the contents of the routing table of a
neighboring router by sending a Request (command =1) message to the router. The router will respond
by sending an update (Response, command=2) containing its routing table. In the example, the received
response packet could be a periodic update from the address FE80::202:FDFF:FE77:1E42 or a response
to a RIP request message that was previously sent by the local router.
Table 192 debug ipv6 rip Field Descriptions
Field Description
as1_rip The name of the RIP process that is sending or receiving the update.
src The address from which the update was originated.
dst The destination address for the update.
sport, dport The source and destination ports for the update. (IPv6 RIP uses port
521, as shown in the display.)
command The command field within the RIP packet. A value of 2 indicates that
the RIP packet is a response (update); a value of 1 indicates that the
RIP packet is a request.
version The version of IPv6 RIP being used. The current version is 1.
mbz There must be a 0 (mbz) field within the RIP packet.

May 2008 DB-1307
Debug Commands
debug ipv6 rip
Table 192 debug ipv6 rip Field Descriptions (continued)
Field Description
#rte Indicates the number of routing table entries (RTEs) the RIP packet
contains.
tag The tag, metric, and prefix fields are specific to each RTE contained
in the update.
metric
The tag field is intended to allow for the flagging of IPv6 RIP
prefix
internal and external routes.
The metric field is the distance metric from the router (sending this
update) to the prefix.
The prefix field is the IPv6 prefix of the destination being advertised.

debug ipv6 routing Displays debug messages for IPv6 routing table updates and route cache
updates.

DB-1308 May 2008
Debug Commands
debug ipv6 routing
debug ipv6 routing

To display debug messages for IPv6 routing table updates and route cache updates, use the debug ipv6
routing command in privileged EXEC mode. To disable debug messages for IPv6 routing table updates
and route cache updates, use the no form of this command.
debug ipv6 routing
no debug ipv6 routing
Command Default Debugging for IPv6 routing table updates and route cache updates is not enabled.

Usage Guidelines The debug ipv6 routing command is similar to the debug ip routing command, except that it is
IPv6-specific.

May 2008 DB-1309
Debug Commands
debug ipv6 routing
Examples The following example shows output for the debug ipv6 routing command:
Router# debug ipv6 routing
13:18:43:IPv6RT0:Add 2000:0:0:1:1::/80 to table

13:18:43:IPv6RT0:Better next-hop for 2000:0:0:1:1::/80, [120/2]
13:19:09:IPv6RT0:Add 2000:0:0:2::/64 to table
13:19:09:IPv6RT0:Better next-hop for 2000:0:0:2::/64, [20/1]
13:19:09:IPv6RT0:Better next-hop for 2000:0:0:2:1::/80, [20/1]
The debug ipv6 routing command displays messages whenever the routing table changes. For example,
the following message indicates that a route to the prefix 2000:0:0:1:1::/80 was added to the routing table
at the time specified in the message.
The following message indicates that the prefix 2000:0:0:2::/64 was already in the routing table;
however, a received advertisement provided a lower cost path to the prefix. Therefore, the routing table
was updated with the lower cost path. (The [20/1] in the example is the administrative distance [20] and
metric [1] of the better path.)

debug ipv6 rip Displays debug messages for IPv6 RIP routing transactions.

DB-1310 May 2008
Debug Commands
debug ipx ipxwan
debug ipx ipxwan

To display debugging information for interfaces configured to use IPX wide-area network (IPXWAN),
use the debug ipx ipxwan command in privileged EXEC mode. To disable debugging output, use the no
debug ipx ipxwan
no debug ipx ipxwan
Usage Guidelines The debug ipx ipxwan command is useful for verifying the startup negotiations between two routers
running the IPX protocol through a WAN. This command produces output only during state changes or
startup. During normal operations, no output is produced.
Examples The following is sample output from the debug ipx ipxwan command during link startup:
Router# debug ipx ipxwan

IPXWAN: state (Disconnect -> Sending Timer Requests) [Serial1/6666:200 (IPX line
state brought up)]
IPXWAN: state (Sending Timer Requests -> Disconnect) [Serial1/6666:200 (IPX line
state brought down)]
state brought up)]
IPXWAN: Send TIMER_REQ [seq 0] out Serial1/6666:200

IPXWAN: Rcv TIMER_REQ on Serial1/6666:200, NodeID 1234, Seq 1

IPXWAN: Rcv TIMER_RSP on Serial1/6666:200, NodeID 1234, Seq 1, Del 6
IPXWAN: state (Sending Timer Requests -> Master: Sent RIP/SAP) [Serial1/6666:200
(Received Timer Response as master)]
IPXWAN: Send RIPSAP_INFO_REQ [seq 0] out Serial1/6666:200
IPXWAN: Rcv RIPSAP_INFO_RSP from Serial1/6666:200, NodeID 1234, Seq 0
IPXWAN: state (Master: Sent RIP/SAP -> Master: Connect) [Serial1/6666:200 (Received Router
Info Rsp as Master)]
The following line indicates that the interface has initialized:


May 2008 DB-1311
Debug Commands
debug ipx ipxwan
The following lines indicate that the startup process failed to receive a timer response, brought the link
down, then brought the link up and tried again with a new timer set:
IPXWAN: state (Sending Timer Requests -> Disconnect) [Serial1/6666:200 (IPX line
state brought down)]
state brought up)]
The following lines indicate that the interface is sending timer requests and waiting for a timer response:
The following lines indicate that the interface has received a timer request from the other end of the link
and has sent a timer response. The fourth line shows that the interface has come up as the master on the
link.
IPXWAN: Rcv TIMER_REQ on Serial1/6666:200, NodeID 1234, Seq 1
IPXWAN: Rcv TIMER_RSP on Serial1/6666:200, NodeID 1234, Seq 1, Del 6
IPXWAN: state (Sending Timer Requests -> Master: Sent RIP/SAP) [Serial1/6666:200
(Received Timer Response as master)]
The following lines indicate that the interface is sending RIP/SAP requests:
IPXWAN: Send RIPSAP_INFO_REQ [seq 0] out Serial1/6666:200
IPXWAN: Rcv RIPSAP_INFO_RSP from Serial1/6666:200, NodeID 1234, Seq 0
IPXWAN: state (Master: Sent RIP/SAP -> Master: Connect) [Serial1/6666:200 (Received Router
Info Rsp as Master)]

DB-1312 May 2008
Debug Commands
debug ipx nasi
debug ipx nasi

To display information about NetWare Asynchronous Services Interface (NASI) connections, use the
debug ipx nasi command in Privileged EXEC configuration mode. To disable debugging output, use the
debug ipx nasi {packets | error | activity}
no debug ipx nasi {packets | error | activity}
Syntax Description packets Displays normal operating messages relating to incoming and outgoing
NASI packets. This is the default.
error Displays messages indicating an error or failure in the protocol processing.
activity Displays messages relating to internal NASI processing of NASI
connections. The activity option includes all NASI activity such as traffic
indication, timer events, and state changes.
Command Default Nasi protocol debugging is disabled.

Usage Guidelines Use the debug ipx nasi command to display handshake or negotiation details between Sequenced Packet
Exchange (SPX), NASI protocol, and other protocols or applications. Use the packets option to
determine the NASI traffic flow, and use the error option as a quick check to see why NASI connections
failed.
Examples The following is sample output from the debug ipx nasi command with the packet and error options.
Router# debug ipx nasi packet
Router# debug ipx nasi error
NASI0: 6E6E Check server info

NASI0: 6E6E sending server-info 4F00 Good response: 43 bytes
NASI0: 7A6E Query Port. Find first
NASI0: FFirst: line 0 DE, port: TTY1-__________ASYNC___^, group: ASYNC___^
NASI0: 7A6E sending Qport find-first response: 300 bytes
NASI0: 7B6E port request. setting up port
NASI: Check-login User: c h r i s

May 2008 DB-1313
Debug Commands
debug ipx nasi
NASI: Check-login PW hash: C7 A6 C5 C7 C4 C0 C5 C3 C4 CC C5 CF C4 C8 C5 CB C4 D4 C5 D7 C4

D0 C5 D3 C4
NASI: Check-login PW: l a b
NASI1: 7B6E sending NCS Good server Data Ack in 0 bytes pkt in 13 size pkt
NASI1: 7B6E sending Preq response: 303 bytes Good
NASI1: 7B6E port request. setting up port
NASI1: 7B6E sending Preq response: 303 bytes Good
NASI1: 7B6E Unknown NASI code 4500 Pkt Size: 13
45 0 0 FC 0 2 0 20 0 0 FF 1 0
NASI1: 7B6E Flush Rx Buffers
NASI1: 7B6E sending NASI server TTY data: 1 byte in 14 size pkt
In the following line:

0 in NASI0 is the number of the terminal (TTY) to which this NASI connection is attached.
0 in NASI0 is used by all NASI control connections.
6E6E is the associated SPX connection pointer for this NASI connection.
Check server info is a type of incoming NASI packet.
NASI0: 6E6E Check server info
The following message indicates that the router is sending back a server-info packet with a positive
acknowledgment, and the packet size is 43 bytes:
NASI0: 6E6E sending server-info 4F00 Good response: 43 bytes
The following line is a NASI packet type. Find first and Find next are NASI packet types.
NASI0: 7A6E Query Port. Find first
The following line indicates that the outgoing find first packet for the NASI connection 7A6E has line 0
DE, port name TTY1, and general name ASYNC:
NASI0: FFirst: line 0 DE, port: TTY1-__________ASYNC___^, group: ASYNC___^
The following two lines indicate:

Received NASI packet for NASI connection in line 1. 7B6E is the NASI connection pointer. The
packet code is 4500 and is not recognizable by Cisco.
Hexadecimal dump of the packet in line 2.
NASI1: 7B6E Unknown NASI code 4500 Pkt Size: 13
45 0 0 FC 0 2 0 20 0 0 FF 1 0

debug ipx spx Displays debugging messages related to the SPX protocol.

DB-1314 May 2008
Debug Commands
debug ipx packet
debug ipx packet

To display information about packets received, sent, and forwarded, use the debug ipx packet command
debug ipx packet
no debug ipx packet
Usage Guidelines This command is useful for learning whether Internetwork Packet Exchange (IPX) packets are traveling
over a router.
Note In order to generate debug ipx packet information on all IPX traffic traveling over the router, you must
first configure the router so that fast switching is disabled. Use the no ipx route-cache command on all
interfaces on which you want to observe traffic. If the router is configured for IPX fast switching, only
non fast-switched packets will produce output. When the IPX cache is invalidated or cleared, one packet
for each destination is displayed as the cache is repopulated.
Examples The following is sample output from the debug ipx packet command:
Router# debug ipx packet
IPX: src=160.0260.8c4c.4f22, dst=1.0000.0000.0001, packet received

IPX: src=160.0260.8c4c.4f22, dst=1.0000.0000.0001,gw=183.0000.0c01.5d85,
sending packet
The first line indicates that the router receives a packet from a Novell station (address
160.0260.8c4c.4f22); this trace does not indicate the address of the immediate router sending the packet
to this router. In the second line, the router forwards the packet toward the Novell server (address
1.0000.0000.0001) through an immediate router (183.0000.0c01.5d85).
Table 193 debug ipx packet Field Descriptions
Field Description
IPX Indicates that this is an IPX packet.
src=160.0260.8c4c.4f22 Source address of the IPX packet. The Novell network number is 160.
Its MAC address is 0260.8c4c.4f22.
dst=1.0000.0000.0001 Destination address for the IPX packet. The address 0000.0000.0001
is an internal MAC address, and the network number 1 is the internal
network number of a Novell 3.11 server.

May 2008 DB-1315
Debug Commands
debug ipx packet
Table 193 debug ipx packet Field Descriptions (continued)
Field Description
packet received Router received this packet from a Novell station, possibly through an
intermediate router.
gw=183.0000.0c01.5d85 Router is sending the packet over to the next hop router; its address of
183.0000.0c01.5d85 was learned from the IPX routing table.
sending packet Router is attempting to send this packet.

DB-1316 May 2008
Debug Commands
debug ipx routing
debug ipx routing

To display information on Internetwork Packet Exchange (IPX) routing packets that the router sends and
receives, use the debug ipx routing command in privileged EXEC mode. To disable debugging output,
debug ipx routing {activity | events}
no debug ipx routing {activity | events}
Syntax Description activity Displays messages relating to IPX routing activity.

events Displays messages relating to IPX routing events.
Usage Guidelines Normally, a router or server sends out one routing update per minute. Each routing update packet can
include up to 50 entries. If many networks exist on the internetwork, the router sends out multiple
packets per update. For example, if a router has 120 entries in the routing table, it would send three
routing update packets per update. The first routing update packet would include the first 50 entries, the
second packet would include the next 50 entries, and the last routing update packet would include the
last 20 entries.
Examples The following is sample output from the debug ipx routing command:
Router# debug ipx routing
IPXRIP: update from 9999.0260.8c6a.1733

110801 in 1 hops, delay 2
IPXRIP: sending update to 12FF02:ffff.ffff.ffff via Ethernet 1
network 555, metric 2, delay 3
network 1234, metric 3, delay 4
Table 194 debug ipx routing Field Descriptions
Field Description
IPXRIP IPX RIP packet.
update from Routing update packet from an IPX server at address
9999.0260.8c6a.1733 9999.0260.8c6a.1733.
110801 in 1 hops Network 110801 is one hop away from the router at address
9999.0260.8c6a.1733.
delay 2 Delay is a time measurement (1/18th second) that the NetWare shell
uses to estimate how long to wait for a response from a file server. Also
known as ticks.

May 2008 DB-1317
Debug Commands
debug ipx routing
Table 194 debug ipx routing Field Descriptions (continued)
Field Description
sending update to Router is sending this IPX routing update packet to address
12FF02:ffff.ffff.ffff via 12FF02:ffff.ffff.ffff through Ethernet interface 1.
Ethernet 1
network 555 Packet includes routing update information for network 555.
metric 2 Network 555 is two metrics (or hops) away from the router.
delay 3 Network 555 is a delay of 3 away from the router. Delay is a
measurement that the NetWare shell uses to estimate how long to wait
for a response from a file server. Also known as ticks.

debug ipx sap Displays information about IPX SAP packets.

DB-1318 May 2008
Debug Commands
debug ipx sap
debug ipx sap

To display information about Internetwork Packet Exchange (IPX) Service Advertisement Protocol
(SAP) packets, use the debug ipx sap command in privileged EXEC mode. To disable debugging output,
debug ipx sap [activity | events]
no debug ipx sap [activity | events]
Syntax Description activity (Optional) Provides more detailed output of SAP packets, including
displays of services in SAP packets.
events (Optional) Limits amount of detailed output for SAP packets to those
that contain interesting events.
Usage Guidelines Normally, a router or server sends out one SAP update per minute. Each SAP packet can include up to
seven entries. If many servers are advertising on the network, the router sends out multiple packets per
update. For example, if a router has 20 entries in the SAP table, it would send three SAP packets per
update. The first SAP would include the first seven entries, the second SAP would include the next seven
entries, and the last update would include the last six entries.
Obtain the most meaningful detail by using the debug ipx sap activity and the debug ipx sap events
commands together.
Caution Because the debug ipx sap command can generate a substantial amount of output, use it with caution
on networks that have many interfaces and large service tables.
Examples The following is sample output from the debug ipx sap command:
Router# debug ipx sap
IPXSAP: at 0023F778:
I SAP Response type 0x2 len 160 src:160.0000.0c00.070d dest:160.ffff.ffff.ffff(452)
type 0x4, "Hello2", 199.0002.0004.0006 (451), 2 hops
type 0x4, "Hello1", 199.0002.0004.0008 (451), 2 hops
IPXSAP: sending update to 160
IPXSAP: at 00169080:
O SAP Update type 0x2 len 96 ssoc:0x452 dest:160.ffff.ffff.ffff(452)
IPX: type 0x4, "Magnolia", 42.0000.0000.0001 (451), 2hops
The debug ipx sap command generates multiple lines of output for each SAP packeta packet summary
message and a service detail message.
The first line displays the internal router memory address of the packet. The technical support staff may
use this information in problem debugging.
IPXSAP: at 0023F778:

May 2008 DB-1319
Debug Commands
debug ipx sap
Table 195 debug ipx sap Field Descriptions
Field Description
I Indicates whether the router received the SAP packet as input (I) or is
sending an update as output (O).
SAP Response type 0x2 Packet type. Format is 0xn; possible values for n include:
1General query
2General response
3Get Nearest Server request
4Get Nearest Server response
len 160 Length of this packet (in bytes).
src: 160.000.0c00.070d Source address of the packet.
dest:160.ffff.ffff.ffff IPX network number and broadcast address of the destination IPX
network for which the message is intended.
(452) IPX socket number of the process sending the packet at the source
address. This number is always 452, which is the socket number for the
SAP process.

DB-1320 May 2008
Debug Commands
debug ipx sap
Table 195 debug ipx sap Field Descriptions (continued)
Field Description
type 0x4 Indicates the type of service the server sending the packet provides.
Format is 0xn. Some of the values for n are proprietary to Novell.
Those values for n that have been published include the following
(contact Novell for more information):
0Unknown
1User
2User group
3Print queue
4File server
5Job server
6Gateway
7Print server
8Archive queue
9Archive server
AJob queue
BAdministration
21NAS SNA gateway
24Remote bridge server
2DTime Synchronization VAP
2EDynamic SAP
47Advertising print server
4BBtrieve VAP 5.0
4CSQL VAP
7ATESNetWare for VMS
98NetWare access server
9ANamed Pipes server
9EPortable NetWareUNIX
111Test server
166NetWare management
233NetWare management agent
237NetExplorer NLM
239HMI hub
23ANetWare LANalyzer agent
26ANMS management
FFFFWildcard (any SAP service)
Contact Novell for more information.

May 2008 DB-1321
Debug Commands
debug ipx sap
Table 195 debug ipx sap Field Descriptions (continued)
Field Description
Hello2 Name of the server being advertised.
199.0002.0004.0006 (451) Indicates the network number and address (and socket) of the server
generating the SAP packet.
2 hops Number of hops to the server from the router.
The fifth line of output indicates that the router sent a SAP update to network 160:
IPXSAP: sending update to 160
The format for debug ipx sap output describing a SAP update the router sends is similar to that
describing a SAP update the router receives, except that the ssoc: field replaces the src: field, as the
following line of output indicates:
O SAP Update type 0x2 len 96 ssoc:0x452 dest:160.ffff.ffff.ffff(452)
The ssoc:0x452 field indicates the IPX socket number of the process sending the packet at the source
address. Possible values include the following:
451Network Core Protocol
452Service Advertising Protocol
453Routing Information Protocol
455NetBIOS
456Diagnostics
4000 to 6000Ephemeral sockets used for interaction with file servers and other network
communications

debug ipx routing Displays information on IPX routing packets that the router sends and
receives.

DB-1322 May 2008
Debug Commands
debug ipx spoof
debug ipx spoof

To display information about Sequenced Packet Exchange (SPX) keepalive and Internetwork Packet
Exchange (IPX) watchdog packets when ipx watchdog and ipx spx-spoof are configured on the router,
use the debug ipx spoof command in privileged EXEC mode. To disable debugging output, use the no
debug ipx spoof
no debug ipx spoof
Usage Guidelines Use this command to troubleshoot connections that use SPX spoofing when SPX keepalive spoofing is
enabled.
Examples The following is sample output from the debug ipx spoof command:
Router# debug ipx spoof
IPX: Tu1:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7004 4B8 8 1D

23 (new) (changed:yes) Last Changed 0
IPX: Tu1:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7104 2B8 7 29
2E (new) (changed:yes) Last Changed 0
IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: 80 0 2B8 7104 29 7 7

(early)
IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.da75 ln= 42 tc=02, SPX: 80 0 4B8 7004 1D 8 8
(early)
IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.da75 ln= 32 tc=02, watchdog
IPX: local:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 32 tc=00, watchdog snet
23 (changed:clear) Last Changed 0
IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: C0 0 2B8 7104 29 7 7
(early)
2E (changed:clear) Last Changed 0
(Last Changed 272 sec)
IPX: local:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, spx keepalive sent 80 0
7104 2B8 7 29 2E
The following lines show that SPX packets were seen, but they are not seen for a connection that exists
in the SPX table:
23 (new) (changed:yes) Last Changed 0
2E (new) (changed:yes) Last Changed 0

May 2008 DB-1323
Debug Commands
debug ipx spoof
The following lines show SPX packets for connections that exist in the SPX table but that SPX idle time
has not yet elapsed and spoofing has not started:
IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: 80 0 2B8 7104 29 7 7
(early)
IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.da75 ln= 42 tc=02, SPX: 80 0 4B8 7004 1D 8 8
(early)
The following lines show an IPX watchdog packet and the spoofed reply:
IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.da75 ln= 32 tc=02, watchdog
IPX: local:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 32 tc=00, watchdog sent
The following lines show SPX packets that arrived more than two minutes after spoofing started. This
situation occurs when the other sides of the SPX table are cleared. When the table is cleared, the routing
processes stop spoofing the connection, which allows SPX keepalives from the local side to travel to the
remote side and repopulate the SPX table.
23 (changed:clear) Last Changed 0
(early)
2E (changed:clear) Last Changed 0
The following lines show that an SPX keepalive packet came in and was spoofed:
(Last Changed 272 sec)
IPX: local:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, spx keepalive sent 80 0
7104 2B8 7 29 2E

DB-1324 May 2008
Debug Commands
debug ipx spx
debug ipx spx

To display debugging messages related to the Sequenced Packet Exchange (SPX) protocol, use the
debug ipx spx command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
debug ipx spx
no debug ipx spx
Usage Guidelines Use the debug ipx spx command to display handshaking or negotiating details between the SPX protocol
and the other protocols or applications. SPX debugging messages indicate various states of SPX
connections such as incoming and outgoing traffic information, timer events, and related processing of
SPX connections.
Examples The following is sample output from the debug ipx spx command:
Router# debug ipx spx
SPX: Sent an SPX packet

SPX: I Con Src/Dst 776E/20A0 d-strm 0 con-ctl 80
SPX: I Con Src/Dst 776E/20A0 d-strm FE con-ctl 40
SPX: C847C Connection close requested by peer
SPX: purge timer fired. Cleaning up C847C
SPX: purging spxcon C847C from conQ
SPX: returning inQ buffers
SPX: returning outQ buffers
SPX: returning unackedQ buffers
SPX: returning spxcon
SPX: I Con Src/Dst 786E/FFFF d-strm 0 con-ctl C0
SPX: new connection request for listening socket
SPX: I Con Src/Dst 786E/20B0 d-strm 0 con-ctl 40
SPX: 300 bytes data recvd
The following line indicates an incoming SPX packet that has a source connection ID of 776E and a
destination connection ID of 20A0 (both in hexadecimal). The data stream value in the SPX packet is
indicated by d-strm, and the connection control value in the SPX packet is indicated by con-ctl (both in
hexadecimal). All data packets received are followed by an SPX debugging message indicating the size
of the packet. All control packets received are consumed internally.
SPX: I Con Src/Dst 776E/20A0 d-strm 0 con-ctl 80

May 2008 DB-1325
Debug Commands
debug isdn event
debug isdn event

To display ISDN events occurring on the user side (on the router) of the ISDN interface, use the debug
isdn event command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug isdn event
no debug isdn event

1x.x(x) This command was introduced.
12.4(3rd)T This command was enhanced to display reports about SAPI 0 procedures that
accept X.25 calls on the BRI D channel.
platform hardware.
Usage Guidelines Although the debug isdn event and the debug isdn q931 commands provide similar debug information,
the information is displayed in a different format. If you want to see the information in both formats,
enable both commands at the same time. The displays will be intermingled.
The ISDN events that can be displayed are Q.931 events (call setup and teardown of ISDN network
connections).
Use the show dialer command to retrieve information about the status and configuration of the ISDN
interface on the router.
Use the service timestamps debug datetime msec global configuration command to include the time
with each message.
For more information on ISDN switch types, codes, and values, see Appendix B, ISDN Switch Types,
Codes, and Values.
Examples The following is sample output from the debug isdn event command of call setup events for an outgoing
call:
Router# debug isdn event
ISDN Event: Call to 415555121202

received HOST_PROCEEDING
Channel ID i = 0x0101
-------------------

DB-1326 May 2008
Debug Commands
debug isdn event
Channel ID i = 0x89
received HOST_CONNECT
ISDN Event: Connected to 415555121202 on B1 at 64 Kb/s
The following shows sample debug isdn event output of call setup events for an incoming call. The
values used for internal purposes are unpacked information elements. The values that follow the ISDN
specification are an interpretation of the unpacked information elements.
received HOST_INCOMING_CALL
Bearer Capability i = 0x080010
-------------------
Calling Party Number i = 0x0000, 415555121202
IE out of order or end of private IEs --
Channel ID i = 0x89
ISDN Event: Received a call from 415555121202 on B1 at 64 Kb/s
ISDN Event: Accepting the call
received HOST_CONNECT
ISDN Event: Connected to 415555121202 on B1 at 64 Kb/s
The following is sample output from the debug isdn event command of call teardown events for a call
that has been disconnected by the host side of the connection:
received HOST_DISCONNECT
ISDN Event: Call to 415555121202 was hung up
The following is sample output from the debug isdn event command of a call teardown event for an
outgoing or incoming call that has been disconnected by the ISDN interface on the router side:
ISDN Event: Hangup call to call id 0x8008
Table 196 debug isdn event Field Descriptions
Field Description
Bearer Capability Indicates the requested bearer service to be provided by the network. See
Table B-4 in Appendix B, ISDN Switch Types, Codes, and Values.
i= Indicates the information element identifier. The value depends on the
field it is associated with. Refer to the ITU-T Q.931 specification for
details about the possible values associated with each field for which this
identifier is relevant.

May 2008 DB-1327
Debug Commands
debug isdn event
Table 196 debug isdn event Field Descriptions (continued)
Field Description
Channel ID Channel Identifier. The values and corresponding channels might be
identified in several ways:
Channel ID i=0x0101Channel B1
Channel ID i=0x0102Channel B2
ITU-T Q.931 defines the values and channels as exclusive or preferred:
Channel ID i=0x83Any B channel
Channel ID i=0x89Channel B1 (exclusive)
Channel ID i=0x8AChannel B2 (exclusive)
Channel ID i=0x81B1 (preferred)
Channel ID i=0x82B2 (preferred)
Calling Party Number Identifies the called party. This field is only present in outgoing calls. The
Calling Party Number field uses the IA5 character set. Note that it may be
replaced by the Keypad facility field.
IE out of order or end of Indicates that an information element identifier is out of order or there are
private IEs no more private network information element identifiers to interpret.
Received a call from Identifies the origin of the call. This field is present only in incoming
415555121202 on B1 at calls. Note that the information about the incoming call includes the
64 Kb/s channel and speed. Whether the channel and speed are displayed depends
on the network delivering the calling party number.
The following is sample output from the debug isdn event command of a call teardown event for a call
that has passed call screening and then has been hung up by the ISDN interface on the far end side:
Jan 3 11:29:52.559: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0x81

Jan 3 11:29:52.563: Cause i = 0x8090 - Normal call clearing
The following is sample output from the debug isdn event command of a call teardown event for a call
that has not passed call screening and has been rejected by the ISDN interface on the router side:
Jan 3 11:32:03.263: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0x85

Jan 3 11:32:03.267: Cause i = 0x8095 - Call rejected
The following is sample output from the debug isdn event command of a call teardown event for an
outgoing call that uses a dialer subaddress:
Jan 3 11:41:48.483: ISDN BR0: Event: Call to 61885:1212 at 64 Kb/s

Jan 3 11:41:48.495: ISDN BR0: TX -> SETUP pd = 8 callref = 0x04
Jan 3 11:41:48.495: Bearer Capability i = 0x8890
Jan 3 11:41:48.499: Channel ID i = 0x83
Jan 3 11:41:48.503: Called Party Number i = 0x80, '61885'
Jan 3 11:41:48.507: Called Party SubAddr i = 0x80, 'P1212'
Jan 3 11:41:48.571: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x84
Jan 3 11:41:48.575: Channel ID i = 0x89
Jan 3 11:41:48.587: ISDN BR0: Event: incoming ces value = 1

DB-1328 May 2008
Debug Commands
debug isdn event
Jan 3 11:41:48.587: ISDN BR0: received HOST_PROCEEDING

Jan 3 11:41:48.591: -------------------
Channel ID i = 0x89
Jan 3 11:41:48.731: ISDN BR0: RX <- CONNECT pd = 8 callref = 0x84
Jan 3 11:41:48.743: ISDN BR0: Event: incoming ces value = 1
Jan 3 11:41:48.743: ISDN BR0: received HOST_CONNECT
Jan 3 11:41:48.747: -------------------
%LINK-3-UPDOWN: Interface BRI0:1 changed state to up
Jan 3 11:41:48.771: ISDN BR0: Event: Connected to 61885:1212 on B1 at 64 Kb/s
Jan 3 11:41:48.775: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x04
%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up
%ISDN-6-CONNECT: Interface BRI0:1 is now connected to 61885:1212 goodie
The output is similar to the output of debug isdn q931. Refer to the debug isdn q931 command for
detailed field descriptions.
The following is sample output from the debug isdn event command of call setup events for a successful
callback for legacy DDR:
BRI0:Caller id Callback server starting to spanky 81012345678902

: Callback timer expired
BRI0:beginning callback to spanky 81012345678902
BRI0: Attempting to dial 81012345678902
The following is sample output from the debug isdn event command for a callback that was
unsuccessful because the router had no dialer map for the calling number:
BRI0:Caller id 81012345678902 callback - no matching map
Table 197 debug isdn event Field Descriptions for Caller ID Callback and Legacy DDR
Field Description
BRI0:Caller id Callback server starting to ... Caller ID callback has started, plus host name and
number called. The callback enable timer starts now.
: Callback timer expired Callback timer has expired; callback can proceed.
BRI0:beginning callback to ... Actions proceeding after the callback timer expired,
BRI0: Attempting to dial ... plus host name and number called.
The following is sample output from the debug isdn event command for a callback that was successful
when the dialer profiles DDR feature is configured:
*Mar 1 00:46:51.827: BR0:1:Caller id 81012345678901 matched to profile delorean
*Mar 1 00:46:51.827: Dialer1:Caller id Callback server starting to delorean
81012345678901
*Mar 1 00:46:54.151: : Callback timer expired
*Mar 1 00:46:54.151: Dialer1:beginning callback to delorean 81012345678901
*Mar 1 00:46:54.155: Freeing callback to delorean 81012345678901
*Mar 1 00:46:54.155: BRI0: Dialing cause Callback return call
*Mar 1 00:46:54.155: BRI0: Attempting to dial 81012345678901
*Mar 1 00:46:54.503: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
*Mar 1 00:46:54.523: %DIALER-6-BIND: Interface BRI0:2 bound to profile Dialer1

May 2008 DB-1329
Debug Commands
debug isdn event
*Mar 1 00:46:55.139: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, changed

state to up
*Mar 1 00:46:58.187: %ISDN-6-CONNECT: Interface BRI0:2 is now connected to 81012345678901
delorean
The following example provides information about accepting X.25 calls on the ISDN D channel (for
purpose of example, bold type indicates messages of interest in the following output):
*Sep 28 12:34:29.747: ISDN BR1/1 EVENTd: isdn_host_packet_mode_events: Host packet call

received call id 0xB
Table 198 describes significant fields of call setup events for a successful callback for the sample output
from the debug isdn event command when the dialer profiles DDR feature is configured.
Table 198 debug isdn event Field Descriptions for Caller ID Callback and Dialer Profiles
Field Description
BR0:1:Caller id ... matched to profile ... Interface, channel number, caller ID that are matched,
and the profile to bind to the interface.
: Callback timer expired Callback timer has expired; callback can proceed.
Dialer1:beginning callback to... Callback process is beginning to the specified number.
Freeing callback to... Callback has been started to the specified number, and
the number has been removed from the callback list.
BRI0: Dialing cause Callback return call The reason for the call and the number being dialed.
BRI0: Attempting to dial
%LINK-3-UPDOWN: Interface BRI0:2, Interface status: up.
changed state to up
%DIALER-6-BIND: Interface BRI0:2 bound Profile bound to the interface.
to profile Dialer1
%LINEPROTO-5-UPDOWN: Line protocol Line protocol status: up.
on Interface BRI0:2, changed state to up
%ISDN-6-CONNECT: Interface BRI0:2 is Interface is now connected to the specified host and
now connected to ... number.
isdn_host_packet_mode_events: Host packet Host is accepting incoming X.25 call using ITU Q.931
call received call id 0xB SAPI value 0 procedures.

debug isdn q931 Displays call setup and teardown information of ISDN Layer 3 network
connections.

DB-1330 May 2008
Debug Commands
debug isdn q921
debug isdn q921

To display data link layer (Layer 2) access procedures that are taking place at the router on the D channel
(Link Access Procedure or LAPD) of its ISDN interface, use the debug isdn q921 command in
debug isdn q921 [detail | frame | interface [bri number]]
no debug isdn q921 [detail | frame | interface]
Syntax Description detail (Optional) Displays ISDN Q.921 packet detail.

frame (Optional) Displays ISDN Q.921 frame contents.
interface (Optional) Specifies an interface for debugging.
bri number (Optional) Specifies the BRI interface and selects the interface number.
Valid values are from 0 to 6.

12.2(15)ZJ The detail and frame keywords were added.
Usage Guidelines The ISDN data link layer interface provided by the router conforms to the user interface specification
defined by ITU-T recommendation Q.921. The debug isdn q921 command output is limited to
commands and responses exchanged during peer-to-peer communication carried over the D channel.
This debug information does not include data transmitted over the B channels that are also part of the
router ISDN interface. The peers (data link layer entities and layer management entities on the routers)
communicate with each other with an ISDN switch over the D channel.
Note The ISDN switch provides the network interface defined by Q.921. This debug command does not
display data link layer access procedures taking place within the ISDN network (that is, procedures
taking place on the network side of the ISDN connection). Refer to Appendix B, ISDN Switch Types,
Codes, and Values, in the ISDN Switch Types, Codes, and Values document on Cisco.com for a list
of the supported ISDN switch types.

May 2008 DB-1331
Debug Commands
debug isdn q921
A router can be the calling or called party of the ISDN Q.921 data link layer access procedures. If the
router is the calling party, the command displays information about an outgoing call. If the router is the
called party, the command displays information about an incoming call and the keepalives.
The debug isdn q921 command can be used with the debug isdn event, debug isdn q931, debug isdn
q921 frame, and debug isdn q921 detail commands at the same time. The displays are intermingled.
Use the service timestamps debug datetime msec global configuration command to include the time
with each message.
Examples The following is example output for a single active data link connection (DLC). The debugs turned on
are debug isdn q921, debug isdn q921 frame, and debug isdn q921 detail. In the debugs below,
Q921 followed by a colon (:) indicates that debug isdn q921 has been entered. Q921 followed by
the letter f indicates that debug isdn q921 frame has been entered. Q921 followed by the letter d
indicates that debug isdn q921 detail has been entered.
The following output shows that the L2 frame is received. The first two octets form the address field; the
third octet forms the control field. The address field identifies the originator of a frame and whether it is
a command or a response. The second octet of the address field identifies the DLC with which the frame
is associated. The control field (third octet) contains the frame type code and sequence number
information.
00:12:10:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
00:12:10:ISDN Se1:15 Q921f:PBXb RX <- 0x0E03EF
The following output interprets the octet information. String PBXb indicates that the side receiving
(RX) this frame is acting as a PBXb (as opposed to PBXa, which is the other possibility). This example
also gives information about the type of frame received (SABMR), the associated DLC (1), the frame
type code received from the control field (cntl=SABMR), and the sequence number (indicated by nbit,
which is 0 in this case).
00:12:10:ISDN Se1:15 Q921:PBXb RX <- SABMR dlci=1 cntl=SABMR nbit=0
The following output shows information received from the driver (source_id of x200) showing an L2
frame (event x141). This results from the SABMR frame that was received from the peer PBX (v_bit and
chan do not have any significance in this case).
00:12:10:ISDN Se1:15 Q921d:process_rxdata:Frame sent to L2
00:12:10:ISDN Q921d:isdn_from_driver_process:event_count 3
00:12:10:ISDN Se1:15 Q921d:dpnss_l2_main:source_id x200 event x141 v_bit x0 chan x0
The following output shows that DPNSS L2 for DLC 1 (chan 1) has received an SABMR frame (event
x0) in the IDLE state (s_dpnss_idle):
00:12:10:ISDN Se1:15 Q921d:s_dpnss_idle:event x0 chan 1
The following output shows that for DLC 1 (chan 1 above), a UA frame (event x1) needs to be sent to
the driver (dest x200):
00:12:10:ISDN Se1:15 Q921d:dpnss_l2_mail:dest x200 event x1 v_bit 1 chan 1 out_pkt
x630531A4
The following output shows that for DLC 1, a DL_EST_IND (event x201) needs to be sent to L3 (DUA
in this case because of the backhauling) indicating that this DLC is now up (in RESET COMPLETE
state):
00:12:10:ISDN Se1:15 Q921d:dpnss_l2_mail:dest x300 event x201 v_bit 1 chan 1 out_pkt x0

DB-1332 May 2008
Debug Commands
debug isdn q921
The following output shows that the L2 frame is transmitted (TX):

00:12:10:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
00:12:10:ISDN Se1:15 Q921f:PBXb TX -> 0x0E0363
The following output shows that string PBXb is the side transmitting (TX) and that this frame is acting
as PBX B. This example also gives information about the associated DLC (1), the frame type code
transmitted from the control field (cntl=UA), and the sequence number (indicated by nbit, which is 0 in
this case).
00:12:10:ISDN Se1:15 Q921:PBXb TX -> UA dlci=1 cntl=UA nbit=0
The following is complete debugging output from a DPNSS call:

Jan 8 17:24:43.499:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:24:43.499:ISDN Se2/0:15 Q921f:PBXa TX -> 0x440303
Jan 8 17:24:43.499:ISDN Se2/0:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=0
Jan 8 17:24:43.499:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:24:43.503:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:24:43.503:ISDN Se2/0:15 Q921f:PBXa RX <-
0x44030300102A34232A35302A33333330
Jan 8 17:24:43.503: 30303031233434343030303031
Jan 8 17:24:43.503:ISDN Se2/0:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=0
i=0x00102A34232A35302A3333333030303031233434343030303031
Jan 8 17:24:43.503:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:24:43.503:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:24:43.507:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:24:43.507:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x2
chan 1
Jan 8 17:24:43.507:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x3
v_bit 1 chan 1 out_pkt x63F183D4
0x44030300102A34232A35302A33333330
Jan 8 17:24:43.515: 30303031233434343030303031
i=0x00102A34232A35302A3333333030303031233434343030303031
chan 1
Jan 8 17:24:43.599:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x4 event x240
v_bit x0 chan x2
Jan 8 17:24:43.599:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event
x240 chan 1
v_bit 1 chan 1 out_pkt x63EE5780
Jan 8 17:24:43.599:ISDN Se2/1:15 LIFd:LIF_StartTimer:timer (0x63E569A8),
ticks (500), event (0x1201)
Jan 8 17:24:43.599:ISDN Se2/1:15 Q921f:PBXa TX ->

May 2008 DB-1333
Debug Commands
debug isdn q921
0x46030300102A31232A35302A33333330
Jan 8 17:24:43.599: 30303031233434343030303031
Jan 8 17:24:43.599:ISDN Se2/1:15 Q921:PBXa TX -> UI(C) dlci=1 cntl=UI nbit=0
i=0x00102A31232A35302A3333333030303031233434343030303031
Jan 8 17:24:43.623:ISDN Se2/1:15 Q921f:PBXa RX <- 0x460303
Jan 8 17:24:43.623:ISDN Se2/1:15 Q921:PBXa RX <- UI(R) dlci=1 cntl=UI nbit=0
chan 1
0x440313092A34232A35302A3434343030
Jan 8 17:24:43.719: 303031232A31382A33312A33312A3331
Jan 8 17:24:43.719: 23
i=0x092A34232A35302A3434343030303031232A31382A33312A33312A333123
chan 1
v_bit 1 chan 1 out_pkt x63EE5780
v_bit 1 chan 1 out_pkt x63EE57CC
0x440313092A34232A35302A3434343030
Jan 8 17:24:43.727: 303031232A31382A33312A33312A3331
Jan 8 17:24:43.727: 23
i=0x092A34232A35302A3434343030303031232A31382A33312A33312A333123
chan 1
0x440313092A34232A35302A3434343030
Jan 8 17:24:43.739: 303031232A31382A33312A33312A3331
Jan 8 17:24:43.739: 23
i=0x092A34232A35302A3434343030303031232A31382A33312A33312A333123

DB-1334 May 2008
Debug Commands
debug isdn q921

chan 1
v_bit x0 chan x2
x240 chan 1
v_bit 1 chan 1 out_pkt x636B1B64
Jan 8 17:24:43.787:ISDN Se2/0:15 LIFd:LIF_StartTimer:timer (0x63A4AFBC),
0x460313092A31232A35302A3434343030
Jan 8 17:24:43.791: 30303123
i=0x092A31232A35302A343434303030303123
chan 1
0x440303052A34232A35302A3434343030
Jan 8 17:24:52.107: 303031232A31382A33312A33312A3331
Jan 8 17:24:52.107: 23
i=0x052A34232A35302A3434343030303031232A31382A33312A33312A333123
chan 1
v_bit 1 chan 1 out_pkt x63F19CC8
0x440303052A34232A35302A3434343030
Jan 8 17:24:52.119: 303031232A31382A33312A33312A3331
Jan 8 17:24:52.119: 23
i=0x052A34232A35302A3434343030303031232A31382A33312A33312A333123

May 2008 DB-1335
Debug Commands
debug isdn q921

chan 1
0x440303052A34232A35302A3434343030
Jan 8 17:24:52.127: 303031232A31382A33312A33312A3331
Jan 8 17:24:52.127: 23
i=0x052A34232A35302A3434343030303031232A31382A33312A33312A333123
chan 1
v_bit x0 chan x2
x240 chan 1
0x460303052A35302A3434343030303031
Jan 8 17:24:52.159: 23
i=0x052A35302A343434303030303123
chan 1
i=0x0830
chan 1

DB-1336 May 2008
Debug Commands
debug isdn q921
v_bit 1 chan 1 out_pkt x63F1806C

v_bit 1 chan 1 out_pkt x636710B8
i=0x0830
chan 1
i=0x0830
chan 1
v_bit 1 chan 1 out_pkt x636710B8
v_bit x0 chan x2
x240 chan 1
v_bit 1 chan 1 out_pkt x63F1806C
Jan 8 17:25:31.851:ISDN Se2/1:15 LIFd:LIF_StartTimer:timer (0x63E569A8),
i=0x0830
chan 1
v_bit x0 chan x2

May 2008 DB-1337
Debug Commands
debug isdn q921
x240 chan 1
v_bit 1 chan 1 out_pkt x63EFC5AC
i=0x0830
chan 1
i=0x0830
chan 1
v_bit 1 chan 1 out_pkt x63EFC5AC
v_bit 1 chan 1 out_pkt x6367175C
i=0x0830
chan 1
i=0x0830
chan 1

DB-1338 May 2008
Debug Commands
debug isdn q921

The following output shows details of the preceding debugging events.

The first two octets (0x4403) form the address field, while the third octet (0x03) is the control field. All
the octets starting from the fourth constitute DPNSS L3 information, which needs to be backhauled to
the Cisco PGW2200.
Jan 8 17:24:43.495:ISDN Se2/0:15 Q921f:PBXa RX <- 0x44030300102A34232A35302A33333330
Jan 8 17:24:43.495: 30303031233434343030303031
All of the octets following i= constitute DPNSS L3 information received from the peer:
i=0x00102A34232A35302A3333333030303031233434343030303031
In the INFORMATION TRANSFER state, DLC 1 received a UI(C) frame (event x2) from the peer
carrying DPNSS L3 information:
Jan 8 17:24:43.495:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x2 chan 1
For DLC 1, event information is sent to L3 (IUA BACKHAUL, indicated by dest x300). In this case,
DL_DATA_IND (event x241) indicates that some L3 information has been received from the peer.
Information is sent to the driver (dest x200), which is then sent to the peer): An Unnumbered
InformationResponse [UI(R)] (event x3) acknowledges the received Unnumbered
InformationCommand [UI(C)].
The following is sample output from the debug isdn q921 command for an outgoing call:
Router# debug isdn q921
Jan 3 14:52:24.475: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 5 nr = 2

i = 0x08010705040288901801837006803631383835
Jan 3 14:52:24.503: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 6
Jan 3 14:52:24.527: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 2 nr = 6
i = 0x08018702180189
Jan 3 14:52:24.535: ISDN BR0: TX -> RRr sapi = 0 tei = 64 nr = 3
i = 0x08018707
%LINK-3-UPDOWN: Interface BRI0:1, changed state to up
i = 0x0801070F
%ISDN-6-CONNECT: Interface BRI0:1 is now connected to 61885 goodie
Jan 3 14:52:34.415: ISDN BR0: RX <- RRp sapi = 0 tei = 64 nr = 7
Jan 3 14:52:34.419: ISDN BR0: TX -> RRf sapi = 0 tei = 64 nr = 4

May 2008 DB-1339
Debug Commands
debug isdn q921
In the following lines, the seventh and eighth most significant hexadecimal numbers indicate the type of
message. 0x05 indicates a Call Setup message, 0x02 indicates a Call Proceeding message, 0x07 indicates
a Call Connect message, and 0x0F indicates a Connect Ack message.
i = 0x08010705040288901801837006803631383835
i = 0x08018702180189
i = 0x08018707
i = 0x0801070F
The following is sample output from the debug isdn q921 command for a startup message on a
DMS-100 switch:
Jan 3 14:47:28.455: ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127 0

Jan 3 14:47:30.171: ISDN BR0: TX -> IDREQ ri = 31815 ai = 127
Jan 3 14:47:30.219: ISDN BR0: RX <- IDASSN ri = 31815 ai = 64
Jan 3 14:47:30.223: ISDN BR0: TX -> SABMEp sapi = 0 tei = 64
Jan 3 14:47:30.227: ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127
Jan 3 14:47:30.235: ISDN BR0: TX -> IDCKRP ri = 16568 ai = 64
Jan 3 14:47:30.239: ISDN BR0: RX <- UAf sapi = 0 tei = 64
i = 0x08007B3A03313233
i = 0x08007B3A03313233
Jan 3 14:47:53.819: ISDN BR0: TX -> RRp sapi = 0 tei = 64 nr = 0
The first seven lines of this example indicate a Layer 2 link establishment.
The following lines indicate the message exchanges between the data link layer entity on the local router
(user side) and the assignment source point (ASP) on the network side during the TEI assignment
procedure. This assumes that the link is down and no TEI currently exists.
Jan 3 14:47:30.171: ISDN BR0: TX -> IDREQ ri = 31815 ai = 127
Jan 3 14:47:30.219: ISDN BR0: RX <- IDASSN ri = 31815 ai = 64
At 14:47:30.171, the local router data link layer entity sent an Identity Request message to the network
data link layer entity to request a TEI value that can be used in subsequent communication between the
peer data link layer entities. The request includes a randomly generated reference number (31815) to
differentiate among user devices that request automatic TEI assignment and an action indicator of 127
to indicate that the ASP can assign any TEI value available. The ISDN user interface on the router uses
automatic TEI assignment.
At 14:47:30.219, the network data link entity responds to the Identity Request message with an Identity
Assigned message. The response includes the reference number (31815) previously sent in the request
and TEI value (64) assigned by the ASP.
The following lines indicate the message exchanges between the layer management entity on the
network and the layer management entity on the local router (user side) during the TEI check procedure:
Jan 3 14:47:30.227: ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127
Jan 3 14:47:30.235: ISDN BR0: TX -> IDCKRP ri = 16568 ai = 64

DB-1340 May 2008
Debug Commands
debug isdn q921
At 14:47:30.227, the layer management entity on the network sends the Identity Check Request message
to the layer management entity on the local router to check whether a TEI is in use. The message includes
a reference number that is always 0 and the TEI value to check. In this case, an ai value of 127 indicates
that all TEI values should be checked. At 14:47:30.227, the layer management entity on the local router
responds with an Identity Check Response message indicating that TEI value 64 is currently in use.
The following lines indicate the messages exchanged between the data link layer entity on the local
router (user side) and the data link layer on the network side to place the network side into modulo 128
multiple frame acknowledged operation. Note that the data link layer entity on the network side also can
initiate the exchange.
Jan 3 14:47:30.223: ISDN BR0: TX -> SABMEp sapi = 0 tei = 64
Jan 3 14:47:30.239: ISDN BR0: RX <- UAf sapi = 0 tei = 64
At 14:47:30.223, the data link layer entity on the local router sends the SABME command with a SAPI
of 0 (call control procedure) for TEI 64. At 14:47:30.239, the first opportunity, the data link layer entity
on the network responds with a UA response. This response indicates acceptance of the command. The
data link layer entity sending the SABME command may need to send it more than once before receiving
a UA response.
The following lines indicate the status of the data link layer entities. Both are ready to receive I frames.
These I-frames are typically exchanged every 10 seconds (T203 timer).

The following is sample output from the debug isdn q921 command for an incoming call. It is an
incoming SETUP message that assumes that the Layer 2 link is already established to the other side.

Jan 3 14:49:22.523: ISDN BR0: RX <- RRf sapi = 0 tei = 64 nr = 2
Jan 3 14:49:32.543: ISDN BR0: RX <- RRf sapi = 0 tei = 64 nr = 2
Jan 3 14:49:47.307: ISDN BR0: RX <- UI sapi = 0 tei = 127
i = 0x08011F05040288901801897006C13631383836
%LINK-3-UPDOWN: Interface BRI0:1, changed state to up
i = 0x08019F07180189
i = 0x08011F0F180189

May 2008 DB-1341
Debug Commands
debug isdn q921
Table 199 debug isdn q921 Field Descriptions
Field Description
Jan 3 14:49:47.391 Indicates the date and time at which the frame was sent from or
received by the data link layer entity on the router. The time is
maintained by an internal clock.
TX Indicates that this frame is being sent from the ISDN interface on the
local router (user side).
RX Indicates that this frame is being received by the ISDN interface on the
local router from the peer (network side).
IDREQ Indicates the Identity Request message type sent from the local router
to the network (ASP) during the automatic TEI assignment procedure.
This message is sent in a UI command frame. The SAPI value for this
message type is always 63 (indicating that it is a Layer 2 management
procedure) but it is not displayed. The TEI value for this message type
is 127 (indicating that it is a broadcast operation).
ri = 31815 Indicates the Reference number used to differentiate between user
devices requesting TEI assignment. This value is a randomly generated
number from 0 to 65535. The same ri value sent in the IDREQ message
should be returned in the corresponding IDASSN message. Note that a
Reference number of 0 indicates that the message is sent from the
network side management layer entity and a reference number has not
been generated.
ai = 127 Indicates the Action indicator used to request that the ASP assign any
TEI value. It is always 127 for the broadcast TEI. Note that in some
message types, such as IDREM, a specific TEI value is indicated.
IDREM Indicates the Identity Remove message type sent from the ASP to the
user side layer management entity during the TEI removal procedure.
This message is sent in a UI command frame. The message includes a
reference number that is always 0, because it is not responding to a
request from the local router. The ASP sends the Identity Remove
message twice to avoid message loss.
IDASSN Indicates the Identity Assigned message type sent from the ISDN
service provider on the network to the local router during the automatic
TEI assignment procedure. This message is sent in a UI command
frame. The SAPI value for this message type is always 63 (indicating
that it is a Layer 2 management procedure). The TEI value for this
message type is 127 (indicating it is a broadcast operation).
ai = 64 Indicates the TEI value automatically assigned by the ASP. This TEI
value is used by data link layer entities on the local router in
subsequent communication with the network. The valid values are in
the range from 64 to 126.

DB-1342 May 2008
Debug Commands
debug isdn q921
Table 199 debug isdn q921 Field Descriptions (continued)
Field Description
SABME Indicates the set asynchronous balanced mode extended command.
This command places the recipient into modulo 128 multiple frame
acknowledged operation. This command also indicates that all
exception conditions have been cleared. The SABME command is sent
once a second for N200 times (typically three times) until its
acceptance is confirmed with a UA response. For a list and brief
description of other commands and responses that can be exchanged
between the data link layer entities on the local router and the network,
see ITU-T Recommendation Q.921.
sapi = 0 Identifies the service access point at which the data link layer entity
provides services to Layer 3 or to the management layer. A SAPI with
the value 0 indicates it is a call control procedure. Note that the Layer
2 management procedures such as TEI assignment, TEI removal, and
TEI checking, which are tracked with the debug isdn q921 command,
do not display the corresponding SAPI value; it is implicit. If the SAPI
value were displayed, it would be 63.
tei = 64 Indicates the TEI value automatically assigned by the ASP. This TEI
value will be used by data link layer entities on the local router in
subsequent communication with the network. The valid values are in
the range from 64 to 126.
IDCKRQ Indicates the Identity Check Request message type sent from the ISDN
service provider on the network to the local router during the TEI check
procedure. This message is sent in a UI command frame. The ri field is
always 0. The ai field for this message contains either a specific TEI
value for the local router to check or 127, which indicates that the local
router should check all TEI values. For a list and brief description of
other message types that can be exchanged between the local router
and the ISDN service provider on the network, see Appendix B, ISDN
Switch Types, Codes, and Values.
IDCKRP Indicates the Identity Check Response message type sent from the
local router to the ISDN service provider on the network during the TEI
check procedure. This message is sent in a UI command frame in
response to the IDCKRQ message. The ri field is a randomly generated
number from 0 to 65535. The ai field for this message contains the
specific TEI value that has been checked.
UAf Confirms that the network side has accepted the SABME command
previously sent by the local router. The final bit is set to 1.
INFOc Indicates that this is an Information command. It is used to transfer
sequentially numbered frames containing information fields that are
provided by Layer 3. The information is transferred across a data-link
connection.
INFORMATION pd = 8 Indicates the information fields provided by Layer 3. The information
callref = (null) is sent one frame at a time. If multiple frames need to be sent, several
Information commands are sent. The pd value is the protocol
discriminator. The value 8 indicates it is call control information. The
call reference number is always null for SPID information.

May 2008 DB-1343
Debug Commands
debug isdn q921
Field Description
SPID information i = Indicates the SPID. The local router sends this information to the ISDN
0x343135393033383336363 switch to indicate the services to which it subscribes. SPIDs are
031 assigned by the service provider and are usually 10-digit telephone
numbers followed by optional numbers. Currently, only the DMS-100
switch supports SPIDs, one for each B channel. If SPID information is
sent to a switch type other than DMS-100, an error may be displayed
in the debug information.
ns = 0 Indicates the send sequence number of sent I frames.
nr = 0 Indicates the expected send sequence number of the next received I
frame. At time of transmission, this value should be equal to the value
of ns. The value of nr is used to determine whether frames need to be
re-sent for recovery.
RRr Indicates the Receive Ready response for unacknowledged information
transfer. The RRr is a response to an INFOc.
RRp Indicates the Receive Ready command with the poll bit set. The data
link layer entity on the user side uses the poll bit in the frame to solicit
a response from the peer on the network side.
RRf Indicates the Receive Ready response with the final bit set. The data
link layer entity on the network side uses the final bit in the frame to
indicate a response to the poll.
sapi Indicates the service access point identifier. The SAPI is the point at
which data link services are provided to a network layer or
management entity. Currently, this field can have the value 0 (for call
control procedure) or 63 (for Layer 2 management procedures).
tei Indicates the terminal endpoint identifier (TEI) that has been assigned
automatically by the assignment source point (ASP) (also called the
layer management entity on the network side). The valid range is from
64 to 126. The value 127 indicates a broadcast.

debug isdn event Displays ISDN events occurring on the user side (on
the router) of the ISDN interface.
debug isdn q931 Displays information about call setup and teardown
of ISDN network connections (Layer 3) between the
local router (user side) and the network.
service timestamps debug datetime msec Includes the time with each debug message.

DB-1344 May 2008
Debug Commands
debug isdn q931
debug isdn q931

To display information about call setup and teardown of ISDN network connections (Layer 3) between
the local router (user side) and the network, use the debug isdn q931 command in privileged EXEC
debug isdn q931
no debug isdn q931

10.0 The debug isdn command was introduced.
12.3(11)T This command was enhanced to display the contents of the Facility Information
Element (IE) in textual format.
12.4(6)T This command was enhanced to display reports about SAPI 0 procedures that
accept X.25 calls on the BRI D channel.
platform hardware.
Usage Guidelines The ISDN network layer interface provided by the router conforms to the user interface specification
defined by ITU-T recommendation Q.931, supplemented by other specifications such as for switch type
VN4. The router tracks only activities that occur on the user side, not the network side, of the network
connection. The display information debug isdn q931 command output is limited to commands and
responses exchanged during peer-to-peer communication carried over the D channel. This debug
information does not include data sent over the B channels, which are also part of the routers ISDN
interface. The peers (network layers) communicate with each other via an ISDN switch over the
D channel.
A router can be the calling or the called party of the ISDN Q.931 network connection call setup and
teardown procedures. If the router is the calling party, the command displays information about an
outgoing call. If the router is the called party, the command displays information about an incoming call.
This command decodes parameters of the Facility IE and displays them as text, along with parameter
values as they are applicable and as they are relevant to the operation. In addition, the ASN.1 encoded
Notification structure of the Notification-Indicator IE is also decoded.
You can use the debug isdn q931 command with the debug isdn event and the debug isdn q921
commands at the same time. The displays will be intermingled. Use the service timestamps debug
datetime msec global configuration command to include the time with each message.

May 2008 DB-1345
Debug Commands
debug isdn q931
Examples The following is sample output from the debug isdn q931 command of a call setup procedure for an
outgoing call:
TX -> SETUP pd = 8 callref = 0x04

Channel ID i = 0x83
Called Party Number i = 0x80, 415555121202
RX <- CALL_PROC pd = 8 callref = 0x84
Channel ID i = 0x89
RX <- CONNECT pd = 8 callref = 0x84
TX -> CONNECT_ACK pd = 8 callref = 0x04....
The following is sample output from the debug isdn q931 command of a call setup procedure for an
incoming call:
RX <- SETUP pd = 8 callref = 0x06

Channel ID i = 0x89
TX -> CONNECT pd = 8 callref = 0x86
RX <- CONNECT_ACK pd = 8 callref = 0x06
The following is sample output from the debug isdn q931 command that shows the contents of the
Facility IE. The following example uses the supplementary service Malicious Call Identification
(MCID). In this service, the router sends out the Facility IE.
Sep 20 04:09:38.335 UTC: ISDN Se7/1:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x0007
Cause i = 0x8290 - Normal call clearing
Facility i = 0x91A106020107020103
Protocol Profile = Remote Operations Protocol
0xA106020107020103
Component = Invoke component
Invoke Id = 7 <MCID>
Operation = MCIDRequest
The following is sample output from the debug isdn q931 command of a call teardown procedure from
the network:
RX <- DISCONNECT pd = 8 callref = 0x84

Cause i = 0x8790
Looking Shift to Codeset 6
Codeset 6 IE 0x1 1 0x82 10
TX -> RELEASE pd = 8 callref = 0x04
Cause i = 0x8090
RX <- RELEASE_COMP pd = 8 callref = 0x84
Table 200 describes the significant fields shown in the displays, in alphabetical order.

DB-1346 May 2008
Debug Commands
debug isdn q931
Table 200 debug isdn q931 Field Descriptions
Field Description
Bearer Capability Indicates the requested bearer service to be provided by the network.
CALL_PROC Indicates the CALL PROCEEDING message; the requested call setup has
begun and no more call setup information will be accepted.
Called Party Number Identifies the called party. This field is present only in outgoing SETUP
messages. Note that it can be replaced by the Keypad facility field. This
field uses the IA5 character set.
Calling Party Number Identifies the origin of the call. This field is present only in incoming
SETUP messages. This field uses the IA5 character set.
callref Indicates the call reference number in hexadecimal notation. The value of
this field indicates the number of calls made from either the router
(outgoing calls) or the network (incoming calls). Note that the originator
of the SETUP message sets the high-order bit of the call reference number
to 0. The destination of the connection sets the high-order bit to 1 in
subsequent call control messages, such as the CONNECT message. For
example, callref = 0x04 in the request becomes callref = 0x84 in the
response.
Cause Indicates the cause of the disconnect.
Channel ID Indicates the channel identifier. The value 83 indicates any channel, 89
indicates the B1 channel, and 8A indicates the B2 channel. For more
information about the channel identifier, refer to ITU-T Recommendation
Q.931.
Codeset 6 IE 0x1 i = 0x82, Indicates charging information. This information is specific to the NTT
10 switch type and may not be sent by other switch types.
CONNECT Indicates that the called user has accepted the call.
CONNECT_ACK Indicates that the calling user acknowledges the called users acceptance
of the call.
DISCONNECT Indicates either that the user side has requested the network to clear an
end-to-end connection or that the network has cleared the end-to-end
connection.
i= Indicates the information element identifier. The value depends on the
field it is associated with. Refer to the ITU-T Q.931 specification for
details about the possible values associated with each field for which this
identifier is relevant.
Looking Shift to Codeset 6 Indicates that the next information elements will be interpreted according
to information element identifiers assigned in codeset 6. Codeset 6 means
that the information elements are specific to the local network.
pd Indicates the protocol discriminator. The protocol discriminator
distinguishes messages for call control over the user-network ISDN
interface from other ITU-T-defined messages, including other Q.931
messages. The protocol discriminator is 8 for call control messages such
as SETUP. For basic-1tr6, the protocol discriminator is 65.

May 2008 DB-1347
Debug Commands
debug isdn q931
Field Description
Protocol Profile Remote operations protocol, which contains networking extensions for
other services. This profile determines which protocol should be used to
decode the rest of a Facility IE message.
A Facility IE can contain multiple components. Each component displays
a hexadecimal code followed by the code contents in text. In the example
that included encoded ISDN Facility IE message output,
0xA106020107020103 is the hexadecimal code and represents the
Facility IE Component, Invoke Id, and Operation. The Operation portion
of the IE corresponds to the supplementary service that the component
represents.
RELEASE Indicates that the sending equipment will release the channel and call
reference. The recipient of this message should prepare to release the call
reference and channel.
RELEASE_COMP Indicates that the sending equipment has received a RELEASE message
and has now released the call reference and channel.
RX <- Indicates that this message is being received by the user side of the ISDN
interface from the network side.
SETUP Indicates that the SETUP message type has been sent to initiate call
establishment between peer network layers. This message can be sent
from either the local router or the network.
TX -> Indicates that this message is being sent from the local router (user side)
to the network side of the ISDN interface.
For purpose of example, bold text in the following example indicates the acceptance of an incoming X.25
call on the ISDN D channel, per ITU Q.931 SAPI value 0 procedures:
*Sep 28 12:34:29.739: ISDN BR1/1 Q931: RX <- SETUP pd = 8 callref = 0x5C (re-assembled)
Bearer Capability i = 0x88C0C2E6
Standard = CCITT
Transfer Capability = Unrestricted Digital
Transfer Mode = Packet
Transfer Rate = Packet - not specified
User Info L2 Protocol = Recommendation Q921/I.441
User Info L3 Protocol = Recommendation X.25, Packet Layer
Channel ID i = 0x8C
Exclusive, No B-channel
Information Rate i = 0x8888
Packet Layer Binary Params i = 0x80
Packet Layer Window Size i = 0x8282
Packet Size i = 0x8888
Calling Party Number i = 0x0083, '144014384106'
Plan:Unknown, Type:Unknown
User-User i = 0x02CC000000
The command output is intermingled with information from the debug isdn events command; see the
description for the debug isdn events command to understand significant fields displayed in this report.

DB-1348 May 2008
Debug Commands
debug isdn q931

debug isdn events Displays ISDN events occurring on the router (user side) of the ISDN
interface.
debug isdn q921 Displays Layer 2 access procedures that are taking place at the router on the
D channel of its ISDN interface.
service timestamps Configure a time-stamp on debugging or system logging messages.

May 2008 DB-1349
Debug Commands
debug isdn tgrm
debug isdn tgrm

To view ISDN trunk group resource manager information, use the debug isdn tgrm command in
debug isdn tgrm
no debug isdn tgrm
Defaults Disabled

Usage Guidelines Disable console logging and use buffered logging before using the debug isdn tgrm command. Using
the debug isdn tgrm command generates a large volume of debugs, which can affect router
performance.
Examples Sample output from the debug isdn tgrm command is shown below.
The output shows that the channel used (bchan) is 1, service state is 0 (in-service), call_state is 2 (busy),
false busy is 0, and DSL is 2. The output also shows that the B channel is 1, the channel is available,
and the call state is transitioned from 0 (idle) to 2 (busy).
The last two lines of output shows that bchan is 1, call state is 1 (busy), call type is 2 (voice), and call
direction is 1 (incoming).
00:26:31:ISDN:get_tgrm_avail_state:idb 0x64229380 bchan 1 service_state 0 call_state 2
false busy 0x0 dsl 2
00:26:31:ISDN:update_tgrm_call_status:idb 0x64229380 bchan 1 availability state 1 call
state(prev,new) (0,2), dsl 2
00:26:31:ISDN:Calling TGRM with tgrm_call_isdn_update:idb 0x64229380 bchan 1 call state 1
call type 2 call dir 1
Table 201 provides an alphabetical listing of the fields shown in the debug isdn tgrm command output
and a description of each field.

DB-1350 May 2008
Debug Commands
debug isdn tgrm
Table 201 debug isdn tgrm Field Descriptions
Field Description
availability state Indicates whether the channel is available:
0 = Not available
1 = Available
bchan Bearer channel used for this call.
call dir Direction of the call:
0 = Incoming
1 = Outgoing
call_state State of the call. It has different values depending on whether it is
from ISDN perspective or TGRM perspective.
When printed from get_tgrm_avail_state(), it is the state value
from ISDN perspective:
0 = Idle
1 = Negotiate
2 = Busy
3 = Reserved
4 = Restart pending
5 = Maintenance pend
6 = Reassigned
When printed from tgrm_call_isdn_update(), it is the state value
from TGRM perspective:
0 = Idle
1 = Busy
2 = Pending
3 = Reject
call state (prev, new) Indicates the state transition of the call. The state values are as
shown in call_state from the ISDN perspective.
call type Type of call:
0 = Invalid
1 = Data
2 = Voice
3 = Modem
4 = None
dsl Internal interface identifier.
false busy Bit map of all the channels on the interface indicating their soft
busy status.
idb Address of the interface descriptor block (IDB) for the interface.
service_state Service state:
0 = In-service
1 = Maintenance
2 = Out of service

May 2008 DB-1351
Debug Commands
debug isdn tgrm

show trunk group Displays the configuration of the trunk group.
translation-profile (voice service POTS) Assigns a translation profile to the interface.
trunk-group (interface) Assigns a trunk group to the interface.

DB-1352 May 2008
Debug Commands
debug isdn
debug isdn
To display messages about activity in the structure and operation of ISDN in the Cisco IOS software, use
the debug isdn command in privileged EXEC mode. To disable the ISDN debugging command, use the
debug isdn {all | api name | cc [detail | interface {bri number | serial port/number}] | error
[interface {bri number | serial port/number}] | events | mgmnt [detail | interface {bri number
| serial port/number}] | q921 | q931 | standard [interface {bri number | serial port/number}]
| tgrm}
no debug isdn {all | api name | cc [detail | interface {bri number | serial port/number}] | error
[interface {bri number | serial port/number}] | events | mgmnt [detail | interface {bri number
| serial port/number}] | q921 | q931 | standard [interface {bri number | serial port/number}]
| tgrm}
Syntax Description all Enables all debug isdn commands on all interfaces.
api name Enables application programming interfaces (APIs) contained in ISDN
on all interfaces. The name argument can be any one of the following
APIs. The APIs must be entered one per command-line interface (CLI)
command. To enable all of the APIs, use the all keyword.
acceptISDN call acceptance
allAll ISDN API tracing
bkhlISDN backhaul API tracing
cdapiISDN API tracing
csmISDN Compact Subscriber Module API tracing
l2sockISDN Layer 2 socket API tracing
nfasNon-Facility Associated Signaling
packetISDN packet API tracing
qsigISDN PRI Q Signaling API tracing
rlmRedundant Link Manager API tracing
cc Enables ISDN Call Control debug messages on all interfaces or,
optionally, on a specific interface if you use the interface keyword. Call
Control is a layer of processing within ISDN that is above the Q.931
protocol processing layer, but below the host and API layers.
detail (Optional) Generates more information during the processing of a
specific request.
interface (Optional) Limits the debug isdn capability to one BRI or serial
interface.
bri number (Optional) Identifies a single BRI interface number (BRI 2, for example)
to which the debug isdn command is applied.
serial port/number (Optional) Identifies a single serial port and number (serial 1/0,
for example) to which the debug isdn command is applied. Acceptable
values are 0 through 7.

May 2008 DB-1353
Debug Commands
debug isdn
error Generates error messages for normal exception conditions in the software
on all interfaces or on a specific interface if you use the interface
keyword. The actual significance of the message can be determined only
by a detailed examination of surrounding debug messages.
events Displays ISDN events occurring on the user side of the ISDN interface.
See the debug isdn events command page.
mgmnt Enables ISDN Management Entity messages on all interfaces or,
optionally, on a specific interface. Management Entity controls the
activation and deactivation of Q.921 resources.
q921 Displays data link layer access procedures that are taking place at the
router on the Link Access Protocol D-channel (LAPD) of its ISDN
interface. See the debug isdn q921 command page.
q931 Displays information about call setup and teardown of ISDN network
connections between the local router and the network. See the debug isdn
q931 command page.
standard Enables a selected set of isdn debug command messages on all interfaces
or, optionally, on a specific interface if you use the interface keyword,
that should provide sufficient information to determine why a problem is
occurring.
tgrm Displays ISDN trunk group resource manager information. See the debug
isdn tgrm command page.
Defaults Commands are enabled on all interfaces unless a specific interface is specified.

12.2T This command was enhanced with the all, api, cc, error, mgmnt, and
standard keywords.
12.4(6)T The mgmnt keyword was enhanced to display information about sharing the
terminal endpoint identifier (TEI) when the isdn x25 dchannel
q93-broadcast command is enabled for service access point identifier
(SAPI) procedures that accept X.25 calls on the BRI D channel.
Usage Guidelines Please read the following caution before using this command.

DB-1354 May 2008
Debug Commands
debug isdn
Caution With the exception of the debug isdn events, debug isdn q921, debug isdn q931, and debug isdn tgrm
commands, the commands described on this page are not intended for customer use and can cause ISDN
or the Cisco IOS software to fail. The debug isdn events, debug isdn q921, debug isdn q931, and
debug isdn tgrm commands are described on separate command pages.
Follow all instructions from Cisco technical support personnel when enabling and disabling these
commands.
Examples The general format of the debug isdn command messages is as follows:
date and time: ISDN interface feature: text message
The text message can be used to determine activity in the structure and operation of ISDN in the
Cisco IOS software, ISDN messages, and ISDN signaling procedures. The message must be interpreted
by Cisco technical personnel.
The following example shows a typical message for the debug isdn cc command:
*Mar 1 02:29:27.751: ISDN Se1/0:23 CC: CCPRI_Go: source id 0x300, call id 0x8008, event
0x341 (pre-ccb recovery)
The following example enables a selected set of debug isdn messages that should provide sufficient
information for Cisco technical personnel to determine why a problem is occurring on BRI interface 2:
Router# debug isdn standard interface bri 2
The following report (highlighted in bold for purpose of example) is displayed when the isdn x25
dchannel q931-broadcast command is used to enable sharing the TEI:
Router# debug isdn mgmnt
*Jun 8 22:38:56.535: ISDN BR0 Q921: User TX -> IDREQ ri=29609 ai=127
*Jun 8 22:38:56.595: ISDN BR0 Q921: User RX <- IDASSN ri=29609 ai=86
*Jun 8 22:38:56.595: ISDN BR0 SERROR: L2_Go: at bailout DLCB is NULL
L2: sapi 63 tei 127 ces 0 ev 0x3
*Jun 8 22:38:56.595: ISDN BR0 MGMNT: LM_MDL_UI_DATA_IND: message 2 ri 29609 ai 86 switch
type 9
*Jun 8 22:38:56.595: ISDN BR0 MGMNT: LM_MDL_UI_DATA_IND: OVERLAP REQUEST: ces 9 using lmtr
tei 85 tei 85

May 2008 DB-1355
Debug Commands
debug isis adj packets
debug isis adj packets

To display information on all adjacency-related activity such as hello packets sent and received and
Intermediate System-to-Intermediate System (IS-IS) adjacencies going up and down, use the debug isis
adj packets command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug isis adj packets [interface]
no debug isis adj packets [interface]
Syntax Description interface (Optional) Interface or subinterface name.
Examples The following is sample output from the debug isis adj packets command:
Router# debug isis adj packets
ISIS-Adj: Rec L1 IIH from 0000.0c00.40af (Ethernet0), cir type 3, cir id BBBB.BBBB.BBBB.01
ISIS-Adj: Rec L1 IIH from 0000.0c00.0c36 (Ethernet1), cir type 3, cir id CCCC.CCCC.CCCC.03
ISIS-Adj: Area mismatch, level 1 IIH on Ethernet1
ISIS-Adj: Sending L1 IIH on Ethernet1
ISIS-Adj: Rec L2 IIH from 0000.0c00.0c36 (Ethernet1), cir type 3, cir id BBBB.BBBB.BBBB.03
The following line indicates that the router received an IS-IS hello packet (IIH) on Ethernet interface 0
from the Level 1 router (L1) at MAC address 0000.0c00.40af. The circuit type is the interface type:
1Level 1 only; 2Level 2 only; 3Level 1/2
The circuit ID is what the neighbor interprets as the designated router for the interface.
The following line indicates that the router (configured as a Level 1 router) received on Ethernet
interface 1 is an IS-IS hello packet from a Level 1 router in another area, thereby declaring an area
mismatch:
ISIS-Adj: Area mismatch, level 1 IIH on Ethernet1
The following lines indicates that the router (configured as a Level 1/Level 2 router) sent on Ethernet
interface 1 is a Level 1 IS-IS hello packet, and then a Level 2 IS-IS packet:

DB-1356 May 2008
Debug Commands
debug isis authentication
debug isis authentication

To enable debugging of Intermediate System-to-Intermediate System (IS-IS) authentication, use the
debug isis authentication command in privileged EXEC mode. To disable debugging output, use the no
debug isis authentication information
no debug isis authentication information
Syntax Description information Required keyword that specifies IS-IS authentication information.

Examples The following is sample output from the debug isis authentication command with the information
keyword:
Router# debug isis authentication information
3d03h:ISIS-AuthInfo:No auth TLV found in received packet

3d03h:ISIS-AuthInfo:No auth TLV found in received packet
The sample output indicates that the router has been running for 3 days and 3 hours. Debugging output
is about IS-IS authentication information. The local router is configured for authentication, but it
received a packet that does not contain authentication data; the remote router does not have
authentication configured.

May 2008 DB-1357
Debug Commands
debug isis mpls traffic-eng advertisements

To print information about traffic engineering advertisements in Intermediate System-to-Intermediate
System (IS-IS) link-state advertisement (LSA) messages, use the debug isis mpls traffic-eng
advertisements command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
no debug isis mpls traffic-eng advertisements

Examples In the following example, information about traffic engineering advertisements is printed in IS-IS LSA
messages:
Router# debug isis mpls traffic-eng advertisements
System ID:Router1.00
Router ID:10.106.0.6
Link Count:1
Link[1]
Neighbor System ID:Router2.00 (P2P link)
Interface IP address:10.42.0.6
Neighbor IP Address:10.42.0.10
Admin. Weight:10
Physical BW:155520000 bits/sec
Reservable BW:5000000 bits/sec
BW unreserved[0]:2000000 bits/sec, BW unreserved[1]:100000 bits/sec
Affinity Bits:0x00000000

DB-1358 May 2008
Debug Commands
Table 202 debug isis mpls traffic-eng advertisements Field Descriptions
Field Description
System ID Identification value for the local system in the area.
Router ID Multiprotocol Label Switching traffic engineering router ID.
Link Count Number of links that MPLS traffic engineering advertised.
Neighbor System ID Identification value for the remote system in an area.
Interface IP address IPv4 address of the interface.
Neighbor IP Address IPv4 address of the neighbor.
Admin. Weight Administrative weight associated with this link.
Physical BW Bandwidth capacity of the link (in bits per second).
Reservable BW Amount of reservable bandwidth on this link.
BW unreserved Amount of bandwidth that is available for reservation.
Affinity Bits Attribute flags of the link that are being flooded.

May 2008 DB-1359
Debug Commands
debug isis mpls traffic-eng events

To print information about traffic engineering-related Intermediate System-to-Intermediate System
(IS-IS) events, use the debug isis mpls traffic-eng events command in privileged EXEC mode. To
no debug isis mpls traffic-eng events

Examples In the following example, information is printed about traffic engineering-related IS-IS events:
Router# debug isis mpls traffic-eng events
ISIS-RRR:Send MPLS TE Et4/0/1 Router1.02 adjacency down:address 0.0.0.0

ISIS-RRR:Found interface address 10.1.0.6 Router1.02, building subtlv... 58 bytes
ISIS-RRR:Found interface address 10.42.0.6 Router2.00, building subtlv... 64 bytes
ISIS-RRR:Interface address 0.0.0.0 Router1.00 not found, not building subtlv
ISIS-RRR:LSP Router1.02 changed from 0x606BCD30
ISIS-RRR:Mark LSP Router1.02 changed because TLV contents different, code 16
ISIS-RRR:Received 1 MPLS TE links flood info for system id Router1.00

DB-1360 May 2008
Debug Commands
debug isis nsf
debug isis nsf

To display information about the Intermediate System-to-Intermediate System (IS-IS) state during a
Cisco nonstop forwarding (NSF) restart, use the debug isis nsf command in privileged EXEC mode. To
debug isis nsf [detail]
no debug isis nsf [detail]
Syntax Description detail (Optional) Provides detailed debugging information.

12.2(20)S Support for the Cisco 7304 router was added.
Usage Guidelines Use the debug isis nsf command to display basic information about the IS-IS state during an NSF restart.
Use the debug isis nsf detail command to display additional IS-IS state detail during an NSF restart.
Examples The following example displays IS-IS state information during an NSF restart:
router# debug isis nsf
IS-IS NSF events debugging is on
The following example displays detailed IS-IS state information during an NSF restart:
router# debug isis nsf detail
IS-IS NSF events (detailed) debugging is on

router#
Jan 24 20:04:54.090:%CLNS-5-ADJCHANGE:ISIS:Adjacency to gsr1 (GigabitEthernet2/0/0) Up,
Standby adjacency
Jan 24 20:04:54.090:ISIS-NSF:ADJ:000C.0000.0000 (Gi2/0/0), type 8/1, cnt 0/1, ht 10 (NEW)
Jan 24 20:04:54.142:ISIS-NSF:Rcv LSP - L2 000B.0000.0000.00-00, seq 251, csum B0DC, ht
120, len 123 (local)
Jan 24 20:04:55.510:ISIS-NSF:Rcv LSP - L1 000B.0000.0000.00-00, seq 23E, csum D20D, ht
Jan 24 20:04:56.494:ISIS-NSF:ADJ:000C.0000.0000 (Gi2/0/0), type 8/0, cnt 0/1, ht 30

May 2008 DB-1361
Debug Commands
debug isis nsf
Jan 24 20:04:56.502:ISIS-NSF:Rcv LSP - L1 000B.0000.0000.01-00, seq 21C, csum 413, ht 120,

len 58 (local)
Jan 24 20:04:58.230:ISIS-NSF:Rcv LSP - L2 000C.0000.0000.00-00, seq 11A, csum E197, ht
1194, len 88 (Gi2/0/0)
Jan 24 20:05:00.554:ISIS-NSF:Rcv LSP - L1 000B.0000.0000.00-00, seq 23F, csum 1527, ht

nsf (IS-IS) Configures NSF operations for IS-IS.
nsf interface wait Specifies how long an NSF restart will wait for all interfaces with IS-IS
adjacencies to come up before completing the restart.
nsf interval Specifies the minimum time between NSF restart attempts.
nsf t3 Specifies the methodology used to determine how long IETF NSF will wait
for the LSP database to synchronize before generating overloaded link state
information for itself and flooding that information out to its neighbors.
show clns neighbors Displays both ES and IS neighbors.
show isis nsf Displays current state information regarding IS-IS NSF.

DB-1362 May 2008
Debug Commands
debug isis rib redistribution

To debug the events that update the Intermediate System-to-Intermediate System (IS-IS) redistribution
cache, use the debug isis rib redistribution command in privileged EXEC mode. To turn off debugging,
debug isis rib redistribution [level-1 | level-2] [access-list]
no debug isis rib redistribution [level-1 | level-2] [access-list]
Syntax Description level-1 (Optional) Displays debug information for level 1 redistribution cache.
level-2 (Optional) Displays debug information for level 2 redistribution cache.
access-list (Optional) An access list number from 1 to 199 or from 1300 to 2699.

12.2(18)SXE This command was integrated into Cisco IOS Release 12.2(18)SXE.
Usage Guidelines We recommend that you use this command only when a Cisco Technical Assistance Center
representative requests you to do so to gather information for a troubleshooting purpose.
Examples In the following example, the debug isis rib redistribution command is used to display information
about events that update the IS-IS redistribution cache. The output is self-explanatory.
Router# debug isis rib redistribution level-1 123
IS-IS IPv4 redistribution RIB debugging is on for access list 123 for L1
Router# router isis

Router(config-router)# redistribute connected level-1
Router(config)# access-list 123 permit ip 10.0.0.0 0.255.255.255 any
Router(config)# interface Loopback123
Nov 25 00:33:46.532: ISIS-RR: 10.123.123.3/32: Up event, from 0x607CAF60

Nov 25 00:33:46.532: ISIS-RR: looking at L1 redist RIB
Nov 25 00:33:46.532: ISIS-RR: redistributed to ISIS

May 2008 DB-1363
Debug Commands
Nov 25 00:33:46.532: ISIS-RR: added 10.123.123.3/32 to L1 redist RIB: [Connected/0]

tag 0 external
Nov 25 00:33:47.532: ISIS-RR: Scanning L1 redist RIB
Nov 25 00:33:47.532: ISIS-RR: adv 10.123.123.3/32 as L1 redist route
Nov 25 00:33:47.532: ISIS-RR: End of scanningL1 redist RIB
The following line indicates that the connected route 10.123.123.3/32 was added to the IS-IS level 1
local redistribution cache with cost 0, metric type external, and administrative tag of 0:
Nov 25 00:33:46.532: ISIS-RR: added 10.123.123.3/32 to L1 redist RIB: [Connected/0]
tag 0 external
The following line indicates that the redistributed route 10.123.123.3/32 was advertised in an IS-IS
link-state packet (LSP) as a level 1 redistributed route:
Nov 25 00:33:47.532: ISIS-RR: adv 10.123.123.3/32 as L1 redist rout

clear isis rib Clears some or all prefixes in the local redistribution cache.
redistribution
show isis rib Displays the prefixes in the IS-IS redistribution cache.
redistribution

DB-1364 May 2008
Debug Commands
debug isis rib
debug isis rib

To display debugging information for Integrated Intermediate System-to-Intermediate System (IS-IS) IP
Version 4 routes in the global or local Routing Information Base (RIB), use the debug isis rib command
in privileged EXEC mode. To disable the debugging of IS-IS IP Version 4 routes, use the no form of this
command.
debug isis rib [global | [local [access-list-number | terse]]
no debug isis rib [global | local]
Syntax Description global (Optional) Displays debugging information for IS-IS IP Version 4
routes in the global RIB.
local (Optional) Displays debugging information for IS-IS IP Version 4
routes in the IS-IS local RIB.
access-list-number (Optional) Number of an access list. This is a decimal number from
100 to 199 or from 2000 to 2699.
terse (Optional) Will not display debug information if the IS-IS IP
Version 4 IS-IS local RIB has not changed.
Defaults Debugging of IS-IS IP Version 4 routes is disabled.

12.2(18)SXE This command was integrated into Cisco IOS Release 12.2(18)SXE.
Usage Guidelines Use the debug isis rib command to verify if an IP prefix has been installed or removed. To monitor
updates from the IS-IS database to the IS-IS local RIB, use the local keyword, and to monitor updates
from the IS-IS database to the global RIB, use the global keyword.
It is highly recommended that you limit the debugging output to information specific to the IP prefix that
is associated with a specific access list by entering the accest-list-number argument.

May 2008 DB-1365
Debug Commands
debug isis rib
Examples The following is sample output from the debug isis rib command after the ip route priority high
command was used to give high priority to IS-IS IP prefixes for the configured access list access-list1.
The debug output shows that the route 10.1.1.0/24 has been removed from the IS-IS local RIB.
Router# show running-config| include access-list 1
accest-list 1 permit 10.1.1.0 0.0.0.255

! access-list 1 is configured
Router# debug isis rib local terse 1
00:07:07: ISIS-LR: 10.1.1.0/24 aged out in LSP[10/(7->8)]

! The route 10.1.1.0/24 is removed from the IS-IS local RIB LSP[10/(7->8)].
00:07:07: ISIS-LR: rem path: [115/80/20] via 10.2.2.2(Et2) from 10.22.22.22 tg 0 LSP[10/7]
from active chain (add to deleted chain)
!The remote path [115/80/20] is removed from the active chain.
00:07:07: ISIS-LR: Enqueued to updateQ[2] for 10.1.1.0/24
!Q[2] is marked to be the update
00:07:07: ISIS-LR: rem path: [115/80/20] via 10.2.2.2(Et2) from 10.22.22.22 tg 0 LSP[10/7]
from deleted chain
00:07:07: ISIS-LR: Rem RT 10.1.1.0/24
!The remote route [115/80/20] is removed from the deleted chain
Table 203 debug isis rib Field Descriptions
Field Description
ISIS-LR IS-IS local route debugger.
10.1.1.0/24 IP prefix.
rem path: Indicates the removal or insertion of a routing pathin this
instance, it is a removal.
[115/80/20] Administrative instance/type/metric for the routing path that
has been removed or inserted.
via 10.2.2.2(Et2) IP address of the next hop of the router, in this instance,
Ethernet2.
from 10.22.22.22 IP address to advertise the route path.
tg 0 Priority of the IP prefix. All prefixes have a tag 0 priority
unless otherwise configured.

ip route priority high Assigns a high priority to an IS-IS IP prefix.
show isis rib Displays paths for routes in the IP Version 4 IS-IS local RIB.

DB-1366 May 2008
Debug Commands
debug isis spf statistics

To display statistical information about building routes between intermediate systems (ISs), use the
debug isis spf statistics command in privileged EXEC mode. To disable debugging output, use the no
no debug isis spf statistics
Usage Guidelines The Intermediate System-to-Intermediate System (IS-IS) Interdomain Routing Protocol (IDRP)
provides routing between ISs by flooding the network with link-state information. IS-IS provides routing
at two levels, intra-area (Level 1) and intra-domain (Level 2). Level 1 routing allows Level 1 ISs to
communicate with other Level 1 ISs in the same area. Level 2 routing allows Level 2 ISs to build an
interdomain backbone between Level 1 areas by traversing only Level 2 ISs. Level 1 ISs only need to
know the path to the nearest Level 2 IS in order to take advantage of the interdomain backbone created
by the Level 2 ISs.
The IS-IS protocol uses the shortest-path first (SPF) routing algorithm to build Level 1 and Level 2
routes. The debug isis spf statistics command provides information for determining the time required
to place a Level 1 IS or Level 2 IS on the shortest path tree (SPT) using the IS-IS protocol.
Note The SPF algorithm is also called the Dijkstra algorithm, after the creator of the algorithm.
Examples The following is sample output from the debug isis spf statistics command:
Router# debug isis spf statistics
ISIS-Stats: Compute L1 SPT, Timestamp 2780.328 seconds

ISIS-Stats: Complete L1 SPT, Compute time 0.004, 1 nodes on SPT
Table 204 debug isis spf statistics Field Descriptions
Field Description
Compute L1 SPT Indicates that Level 1 ISs are to be added to a Level 1 area.
Timestamp Indicates the time at which the SPF algorithm was applied. The
time is expressed as the number of seconds elapsed since the
system was up and configured.
Complete L1 SPT Indicates that the algorithm has completed for Level 1 routing.

May 2008 DB-1367
Debug Commands
Table 204 debug isis spf statistics Field Descriptions (continued)
Field Description
Compute time Indicates the time required to place the ISs on the SPT.
nodes on SPT Indicates the number of ISs that have been added.
Compute L2 SPT Indicates that Level 2 ISs are to be added to the domain.
Complete L2 SPT Indicates that the algorithm has completed for Level 2 routing.
The following lines show the statistical information available for Level 1 ISs:
The output indicates that the SPF algorithm was applied 2780.328 seconds after the system was up and
configured. Given the existing intra-area topology, 4 milliseconds were required to place one Level 1 IS
on the SPT.
The following lines show the statistical information available for Level 2 ISs:
This output indicates that the SPF algorithm was applied 2780.3336 seconds after the system was up and
configured. Given the existing intradomain topology, 56 milliseconds were required to place 12 Level 2
ISs on the SPT.

DB-1368 May 2008
Debug Commands
debug isis spf-events

To display a log of significant events during an Intermediate System-to-Intermediate System (IS-IS)
shortest-path first (SPF) computation, use the debug isis spf-events command in privileged EXEC
no debug isis spf-events

12.2(18)S Support for IPv6 was added.
12.0(26)S Support for IPv6 was added.
Usage Guidelines This command displays information about significant events that occur during SPF-related processing.
Examples The following example displays significant events during an IS-IS SPF computation:
Router# debug isis spf-events
ISIS-Spf: Compute L2 IPv6 SPT

ISIS-Spf: Move 0000.0000.1111.00-00 to PATHS, metric 0
ISIS-Spf: Add 0000.0000.2222.01-00 to TENT, metric 10
ISIS-Spf: considering adj to 0000.0000.2222 (Ethernet3/1) metric 10, level 2, circuit 3,
adj 3
ISIS-Spf: (accepted)
ISIS-Spf: Next hop 0000.0000.2222 (Ethernet3/1)

May 2008 DB-1369
Debug Commands


DB-1370 May 2008
Debug Commands
debug isis update-packets

To display various sequence number protocol data units (PDUs) and link-state packets that are detected
by a router, use the debug isis update-packets command in privileged EXEC mode. To disable
no debug isis update-packets
Examples This router has been configured for IS-IS routing. The following is sample output from thee debug isis
update-packets command:
Router# debug isis update-packets
ISIS-Update: Sending L1 CSNP on Ethernet0

ISIS-Update: Updating L2 LSP
ISIS-Update: Delete link 888.8800.0181.00 from L2 LSP 1600.8906.4022.00-00, seq E
ISIS-Update: Add link 8888.8800.0181.00 to L2 LSP 1600.8906.4022.00-00, new seq 10,
len 91
ISIS-Update: Sending L2 LSP 1600.8906.4022.00-00, seq 10, ht 1198 on Tunnel0
ISIS-Update: Sending L2 CSNP on Tunnel0
ISIS-Update: Rate limiting L2 LSP 1600.8906.4022.00-00, seq 11 (Tunnel0)
ISIS-Update: Rec L2 LSP 888.8800.0181.00.00-00 (Tunnel0)
ISIS-Update: PSNP entry 1600.8906.4022.00-00, seq 10, ht 1196
The following lines indicate that the router has sent a periodic Level 1 and Level 2 complete sequence
number PDU on Ethernet interface 0:
The following lines indicate that the network service access point (NSAP) identified as
8888.8800.0181.00 was deleted from the Level 2 LSP 1600.8906.4022.00-00. The sequence number
associated with this LSP is 0xE.
ISIS-Update: Delete link 888.8800.0181.00 from L2 LSP 1600.8906.4022.00-00, seq E
The following lines indicate that the NSAP identified as 8888.8800.0181.00 was added to the Level 2
LSP 1600.8906.4022.00-00. The new sequence number associated with this LSP is 0x10.

May 2008 DB-1371
Debug Commands
ISIS-Update: Add link 8888.8800.0181.00 to L2 LSP 1600.8906.4022.00-00, new seq 10,

len 91
The following line indicates that the router sent Level 2 LSP 1600.8906.4022.00-00 with sequence
number 0x10 on tunnel 0 interface:
ISIS-Update: Sending L2 LSP 1600.8906.4022.00-00, seq 10, ht 1198 on Tunnel0
The following lines indicates that a Level 2 LSP could not be transmitted because it was recently sent:
ISIS-Update: Sending L2 CSNP on Tunnel0
ISIS-Update: Rate limiting L2 LSP 1600.8906.4022.00-00, seq 11 (Tunnel0)
The following lines indicate that a Level 2 partial sequence number PDU (PSNP) has been received on
tunnel 0 interface:
ISIS-Update: Rec L2 PSNP from 8888.8800.0181.00 (Tunnel0)
The following line indicates that a Level 2 PSNP with an entry for Level 2 LSP 1600.8906.4022.00-00
has been received. This output is an acknowledgment that a previously sent LSP was received without
an error.
ISIS-Update: PSNP entry 1600.8906.4022.00-00, seq 10, ht 1196

DB-1372 May 2008
Debug Commands
debug iua as
debug iua as
To display debugging messages for the IDSN User Adaptation Layer (IUA) application server (AS), use
the debug iua as command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
debug iua as {user | state} {all | name as-name}
no debug iua as
Syntax Description user Displays information about the use of application programming interfaces
(APIs) and events between the ISDN layer and IUA.
state Displays information about AS state transitions.
all Enables debug for all the configured ASs.
name as-name Defines the name of the AS.

Cisco 2420, Cisco 2600 series, Cisco 3600 series, and Cisco 3700 series;
and Cisco AS5300, Cisco AS5350, Cisco AS5400, and Cisco AS5850
network access server (NAS) platforms.
Examples The following example shows debugging output when an ISDN backhaul connection is initially
established. The output shows that state debugging is turned on for all ASs and that the AS is active.
Router# debug iua as state all
IUA :state debug turned ON for ALL AS
00:11:52:IUA:AS as1 number of ASPs up is 1

00:11:57:IUA:AS as1 xsition AS-Up --> AS-Active, cause - ASP asp1

debug iua asp Displays debugging messages for the IUA ASP.

May 2008 DB-1373
Debug Commands
debug iua asp
debug iua asp

To display debugging messages for the IDSN User Adaptation Layer (IUA) application server process
(ASP), use the debug iua asp command in privileged EXEC mode. To disable debugging output, use the
debug iua asp {pak | peer-msg | sctp-sig | state} {all | name asp-name}
no debug iua asp
Syntax Description pak Displays information about all packets.

peer-msg Displays information about IUA peer-to-peer messages.
sctp-sig Displays information about the signals being sent by the Stream Control
Transmission Protocol (SCTP) layer.
state Displays information about ASP state transition.
all Enables debugging output for all configured ASPs.
name asp-name Defines the name of the ASP.

Cisco 2420, Cisco 2600 series, Cisco 3600 series, and Cisco 3700 series; and
Cisco AS5300, Cisco AS5350, Cisco AS5400, and Cisco AS5850 network
access server (NAS) platforms.
platform hardware.

DB-1374 May 2008
Debug Commands
debug iua asp
Examples The following example shows debugging output when an ISDN backhaul connection is initially
established. The output shows that peer message debugging is turned on for all ASPs and that the ASP
is active.
Router# debug iua asp peer-msg all
IUA :peer message debug turned ON for ALL ASPs
Router#
00:04:58:IUA :recieved ASP_UP message on ASP asp1
00:04:58:IUA:ASP asp1 xsition ASP-Down --> ASP-Up , cause - rcv peer
msg
ASP-UP
00:04:58:IUA:sending ACK of type 0x304 to asp asp1
00:05:03:IUA:recv ASP_ACTIVE message for ASP asp1
00:05:03:IUA:ASP asp1 xsition ASP-Up --> ASP-Active, cause - rcv peer
msg
ASP-Active

debug iua as Displays debugging messages for the IUA AS.

May 2008 DB-1375
Debug Commands
debug kerberos
debug kerberos
To display information associated with the Kerberos Authentication Subsystem, use the debug kerberos
debug kerberos
no debug kerberos
Usage Guidelines Kerberos is a security system that authenticates users and services without passing a cleartext password
over the network. Cisco supports Kerberos under the authentication, authorization, and accounting
(AAA) security system.
Use the debug aaa authentication command to get a high-level view of login activity. When Kerberos
is used on the router, you can use the debug kerberos command for more detailed debugging
information.
Examples The following is part of the sample output from the debug aaa authentication command for a Kerberos
login attempt that failed. The information indicates that Kerberos is the authentication method used.
Router# debug aaa authentication
AAA/AUTHEN/START (116852612): Method=KRB5

AAA/AUTHEN (116852612): status = GETUSER
AAA/AUTHEN/CONT (116852612): continue_login
AAA/AUTHEN (116852612): status = GETUSER
AAA/AUTHEN (116852612): Method=KRB5
AAA/AUTHEN (116852612): status = GETPASS
AAA/AUTHEN/CONT (116852612): continue_login
AAA/AUTHEN (116852612): status = GETPASS
AAA/AUTHEN (116852612): Method=KRB5
AAA/AUTHEN (116852612): password incorrect
AAA/AUTHEN (116852612): status = FAIL
The following is sample output from the debug kerberos command for a login attempt that was
successful. The information indicates that the router sent a request to the key distribution center (KDC)
and received a valid credential.
Router# debug kerberos
Kerberos: Requesting TGT with expiration date of 820911631

Kerberos: Sent TGT request to KDC
Kerberos: Received TGT reply from KDC
Kerberos: Received valid credential with endtime of 820911631

DB-1376 May 2008
Debug Commands
debug kerberos
The following is sample output from the debug kerberos command for a login attempt that failed. The
information indicates that the router sent a request to the KDC and received a reply, but the reply did not
contain a valid credential.
Kerberos: Requesting TGT with expiration date of 820911731

Kerberos: Sent TGT request to KDC
Kerberos: Received TGT reply from KDC
Kerberos: Received invalid credential.
AAA/AUTHEN (425003829): password incorrect
The following output shows other failure messages you might see that indicate a configuration problem.
The first message indicates that the router failed to find the default Kerberos realm, therefore the process
failed to build a message to send to the KDC. The second message indicates that the router failed to
retrieve its own IP address. The third message indicates that the router failed to retrieve the current time.
The fourth message indicates the router failed to find or create a credentials cache for a user, which is
usually caused by low memory availability.
Kerberos: authentication failed when parsing name

Kerberos: authentication failed while getting my address
Kerberos: authentication failed while getting time of day
Kerberos: authentication failed while allocating credentials cache

debug aaa authentication Displays information on accountable events as they occur.

May 2008 DB-1377
Debug Commands
debug kpml
debug kpml
To enable Keypad Markup Language (KPML) parser and builder debugs, use the debug kpml command to
specify the debug option.
To disable KPML parser and builder debugs, use the no form of this command (you must enter one option).
debug kpml [all | parser | builder | error]
no debug kpml [all | parser | builder | error]
Syntax Description all Enables all kpml debug tracing.

parser Enables kpml parser tracing.
builder Enables kpml builder tracing.
error Enables kpml error tracing.
Command Default no debug kpml all
Command Modes Privileged EXEC mode

Usage Guidelines For incoming dial peers if you configure multiple DTMF negotiation methods, the first configure value
takes precedence, then the second, then the third.
For incoming dial peers, the first out-of-band negotiation method takes precedence over other DTMF
negotiation methods, except when rtp-nte has precedence; in this case, sip-kpml takes precedence over
other out-of-band negotiation methods.
For incoming dial peers, if both sip-kpml and rtp-nte notification mechanisms are enabled and
negotiated, the gateway relies on RFC 2833 notification to receive digits and a SUBSCRIBE for KPML
is not initiated.
SIP KPML support complies to the IEFT draft draft-ietf-sipping-kpml-04.txt with the following
limitations:
The SIP gateway always initiates SUBSCRIBE in the context of an established INVITE dialog. The
gateway supports receiving SUBSCRIBE in the context of an established INVITE dialog, as well as
out-of-call context requests with a leg parameter in the Event header. If the request code does not
match an existing INVITE dialog, the gateway sends a NOTIFY with KPML status-code 481 and
sets Subscription-State to terminated.

DB-1378 May 2008
Debug Commands
debug kpml
The gateway does not support the Globally Routable User Agent (GRUU) requirement. The Contact
header in the INVITE/200 OK message generates locally from the gateways contact information.
The gateway always initiates persistent subscriptions, but it receives and processes persistent and
one-shot subscriptions.
The gateway supports only single-digit reporting. There is no need for inter-digit timer support. The
only regular expressions supported are those which match to a single digit. For example:
<regex>x</regex>Matches to any digit 0 through 9
<regex>1</regex>Matches digit 1
<regex>[x#*ABCD]</regex>Matches to any digit 0 through 9, # (the pound sign), * (an
asterisk), or A, B, C, or D
<regex>[24]</regex>Matches digits 2 or 4
<regex>[2-9]</regex>Matches on any digit 2 through 9
<regex>[^2-9]</regex>Matches digits 0 or 1
The gateway does not support long key presses. Long key presses are detected and reported as a
single digit press.
Digit suppression is not supported (pre tag for suppressing inband digits).
Individual stream selection is not supported. A SUBSCRIBE request for KPML applies to all audio
streams in the dialog (stream element and reverse not supported).
You can configure support only on a SIP VoIP dial peer.
Examples The following is output from the debug kpml command:

SIP call is established. DTMF sip-kpml was negotiated.
...
//-1/xxxxxxxxxxxx/KPML/Parser/kpml_init:
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: encode_data=0x64E25B48
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: chunk_size=2k, max_allowed=16k
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: context=0x6488C0AC,
mp=0x6488B89C
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_request:
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_pattern:
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_regex_list:
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: malloc xml_buf=0x645E910C, length=328
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_request:
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_pattern:
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_regex_list:
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_request: length=289, buffp=0x645E9251
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: rc=0, encoded str=<?xml version="1.0"
encoding="UTF-8"?><kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:kpml-request kpml-request.xsd"
version="1.0"><pattern persist="persist"><regex
tag="dtmf">[x*#ABCD]</regex></pattern></kpml-request>
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_free:
kpml_encode_context_free:mem_mgr_mempool_free: mem_refcnt(6488B89C)=0 - mempool cleanup
/-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SUBSCRIBE sip:8888@172.18.193.250:5060 SIP/2.0
Via: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bKFF36
From: <sip:172.18.193.251>;tag=EA330-F6
To: <sip:8888@172.18.193.250>;tag=39497C-2EA

May 2008 DB-1379
Debug Commands
debug kpml
Call-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251
CSeq: 103 SUBSCRIBE
Max-Forwards: 70
Date: Fri, 01 Mar 2002 00:16:15 GMT
User-Agent: Cisco-SIPGateway/IOS-12.x
Event: kpml
Expires: 7200
Contact: <sip:172.18.193.251:5060>
Content-Type: application/kpml-request+xml
Content-Length: 327
<?xml version="1.0" encoding="UTF-8"?><kpml-request

xmlns="urn:ietf:params:xml:ns:kpml-request"
Received:
SUBSCRIBE sip:172.18.193.251:5060 SIP/2.0
Via: SIP/2.0/UDP 172.18.193.250:5060;branch=z9hG4bK5FE3
From: <sip:8888@172.18.193.250>;tag=39497C-2EA
To: <sip:172.18.193.251>;tag=EA330-F6
CSeq: 101 SUBSCRIBE
Max-Forwards: 70
Date: Fri, 01 Mar 2002 01:02:46 GMT
Event: kpml
Expires: 7200
Contact: <sip:172.18.193.250:5060>
Content-Type: application/kpml-request+xml
Content-Length: 327
<?xml version="1.0" encoding="UTF-8"?><kpml-request

xmlns="urn:ietf:params:xml:ns:kpml-request"
/-1/xxxxxxxxxxxx/KPML/Parser/kpml_init:
//-1/xxxxxxxxxxxx/KPML/Parser/kpml_decode: Parsing <?xml version="1.0"
encoding="UTF-8"?><kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request"
/-1/xxxxxxxxxxxx/KPML/Parser/kpml_request_ptbuild:
//-1/xxxxxxxxxxxx/KPML/Parser/kpml_create_new_node: creating node
par/cur/child=0x00000000/0x645E910C/0x00000000 top/child=0x645E910C/0x00000000
//-1/xxxxxxxxxxxx/KPML/Parser/kpml_pattern_ptbuild:
par/cur/child=0x645E910C/0x645E91E8/0x00000000 top/child=0x645E910C/0x645E91E8
//-1/xxxxxxxxxxxx/KPML/Parser/kpml_regex_ptbuild:
par/cur/child=0x645E91E8/0x645E923C/0x00000000 top/child=0x645E910C/0x645E91E8
//-1/xxxxxxxxxxxx/KPML/Parser/kpml_character_data:
buf=[x*#ABCD]</regex></pattern></kpml-request>
/-1/xxxxxxxxxxxx/KPML/Parser/kpml_regex_char_data_ptbuild: char data=[x*#ABCD]

//-1/xxxxxxxxxxxx/KPML/Parser/kpml_end_element_handler: elem name=regex

DB-1380 May 2008
Debug Commands
debug kpml
//-1/xxxxxxxxxxxx/KPML/Parser/kpml_end_element_handler: elem name=pattern

//-1/xxxxxxxxxxxx/KPML/Parser/kpml_end_element_handler: elem name=kpml-request
//-1/xxxxxxxxxxxx/KPML/Parser/kpml_pattern_ptproc:
//-1/xxxxxxxxxxxx/KPML/Parser/kpml_regex_ptproc:
//-1/xxxxxxxxxxxx/KPML/Parser/kpml_decode_context_free:
kpml_decode_context_free:mem_mgr_mempool_free: mem_refcnt(6488B89C)=0 - mempool cleanup
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bKFF36
From: <sip:172.18.193.251>;tag=EA330-F6
To: <sip:8888@172.18.193.250>;tag=39497C-2EA
Date: Fri, 01 Mar 2002 01:02:51 GMT
CSeq: 103 SUBSCRIBE
Content-Length: 0
Contact: <sip:172.18.193.250:5060>
Expires: 7200
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.250:5060;branch=z9hG4bK5FE3
From: <sip:8888@172.18.193.250>;tag=39497C-2EA
To: <sip:172.18.193.251>;tag=EA330-F6
Date: Fri, 01 Mar 2002 00:16:24 GMT
CSeq: 101 SUBSCRIBE
Content-Length: 0
Contact: <sip:172.18.193.251:5060>
Expires: 7200
Sent:
NOTIFY sip:172.18.193.250:5060 SIP/2.0
Via: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bK101EA4
From: <sip:172.18.193.251>;tag=EA330-F6
To: <sip:8888@172.18.193.250>;tag=39497C-2EA
CSeq: 104 NOTIFY
Max-Forwards: 70
Date: Fri, 01 Mar 2002 00:16:24 GMT
Event: kpml
Subscription-State: active
Contact: <sip:172.18.193.251:5060>
Content-Length: 0
Received:
NOTIFY sip:172.18.193.251:5060 SIP/2.0
Via: SIP/2.0/UDP 172.18.193.250:5060;branch=z9hG4bK6111
From: <sip:8888@172.18.193.250>;tag=39497C-2EA
To: <sip:172.18.193.251>;tag=EA330-F6
CSeq: 102 NOTIFY
Max-Forwards: 70
Date: Fri, 01 Mar 2002 01:02:51 GMT
Event: kpml
Contact: <sip:172.18.193.250:5060>

May 2008 DB-1381
Debug Commands
debug kpml
Content-Length: 0
...
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: encode_data=0x64E25D00
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: context=0x64FADC10,
mp=0x64AFBBE0
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_response:
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_response: length=73, buffp=0x645E917B
encoding="UTF-8"?><kpml-response version="1.0" code="200" text="OK" digits="1"
tag="dtmf"/>
kpml_encode_context_free:mem_mgr_mempool_free: mem_refcnt(64AFBBE0)=0 - mempool cleanup
Sent:
NOTIFY sip:172.18.193.250:5060 SIP/2.0
Via: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bK1117DE
From: <sip:172.18.193.251>;tag=EA330-F6
To: <sip:8888@172.18.193.250>;tag=39497C-2EA
CSeq: 105 NOTIFY
Max-Forwards: 70
Date: Fri, 01 Mar 2002 00:37:33 GMT
Event: kpml
Contact: <sip:172.18.193.251:5060>
Content-Type: application/kpml-response+xml
Content-Length: 113
<?xml version="1.0" encoding="UTF-8"?><kpml-response version="1.0" code="200" text="OK"

digits="1" tag="dtmf"/>
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bK1117DE
From: <sip:172.18.193.251>;tag=EA330-F6
To: <sip:8888@172.18.193.250>;tag=39497C-2EA
Date: Fri, 01 Mar 2002 01:24:08 GMT
CSeq: 105 NOTIFY
Content-Length: 0
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: encode_data=0x64E25D00
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: context=0x651E8084,
mp=0x65501720
tag="dtmf"/>
kpml_encode_context_free:mem_mgr_mempool_free: mem_refcnt(65501720)=0 - mempool cleanup
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: encode_data=0x656F9128

DB-1382 May 2008
Debug Commands
debug kpml
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: context=0x651E8084,
mp=0x6488B6CC
tag="dtmf"/>
kpml_encode_context_free:mem_mgr_mempool_free: mem_refcnt(6488B6CC)=0 - mempool cleanup
Sent:
NOTIFY sip:172.18.193.250:5060 SIP/2.0
From: <sip:172.18.193.251>;tag=EA330-F6
To: <sip:8888@172.18.193.250>;tag=39497C-2EA
CSeq: 106 NOTIFY
Max-Forwards: 70
Date: Fri, 01 Mar 2002 00:37:44 GMT
Event: kpml
Contact: <sip:172.18.193.251:5060
Content-Type: application/kpml-response+xml
Content-Length: 113
<?xml version="1.0" encoding="UTF-8"?><kpml-response version="1.0" code="200" text="OK"

digits="2" tag="dtmf"/>
Received:
SIP/2.0 200 OK
From: <sip:172.18.193.251>;tag=EA330-F6
To: <sip:8888@172.18.193.250>;tag=39497C-2EA
Date: Fri, 01 Mar 2002 01:24:20 GMT
CSeq: 106 NOTIFY
Content-Length: 0
...

show sip-ua calls Verifies that the DTMF method is SIP-KPML.

May 2008 DB-1383
Debug Commands
debug kron
debug kron
To display debugging messages about Command Scheduler policies or occurrences, use the debug kron
debug kron {all | exec-cli | info | major}
no debug kron {all | exec-cli | info | major}
Syntax Description all Displays all debugging output about Command Scheduler policy lists or
occurrences.
exec-cli Displays detailed debugging output about Command Scheduler policy list
command-line interface (CLI) commands.
info Displays debugging output about Command Scheduler policy lists,
occurrence warnings, or progress information.
major Displays debugging output about Command Scheduler policy list or
occurrence failures.
Command Default If no keyword is specified, all debugging messages are displayed.

Usage Guidelines Use the debug kron command to display the output of a scheduled EXEC show command on the
console.
Examples The following example shows debugging messages for the EXEC CLI show version after the CLI was
run at a scheduled interval:
Router# debug kron exec-cli
Kron cli occurrence messages debugging is on

2w6d: Call parse_cmd 'show version'
2w6d: Kron CLI return 0
'
**CLI 'show version':
Cisco Internetwork Operating System Software IOS (tm) C2600 Software (C2600-I-M

DB-1384 May 2008
Debug Commands
debug kron

show kron schedule Displays the status and schedule information for Command Scheduler
occurrences.

May 2008 DB-1385
Debug Commands
debug l2relay events

To start debugging of Layer 2 Relay events, use the debug l2relay events command in privileged EXEC
mode. To disable debugging output, use the no form of this command (SGSN D-node only).
no debug l2relay events

Usage Guidelines The SGSN module uses the proprietary Layer 2 Relay protocol in conjunction with the intra-Serving
GPRS Support Node (iSGSN) protocol for communication between the SGSN-datacom (SGSN-D) and
SGSN-telecom (SGSN-T) units that comprise the SGSN.
For debugging purposes, it might also be useful to trace Layer 2 Relay packets. To display information
about Layer 2 Relay packets, use the debug l2relay packets command.
Normally you will not need to use the debug l2relay events or debug l2relay packets commands. If
problems with the SGSN are encountered, Cisco technical support personnel may request that issue the
command.
Caution Because the debug l2relay events command generates a substantial amount of output, use it only when
Examples The following example enables the display of Layer 2 Relay events:
Router# debug l2relay events

DB-1386 May 2008
Debug Commands

debug 12relay packets Displays Layer 2 Relay packets (SGSN D-node only).

May 2008 DB-1387
Debug Commands
debug l2relay packets

To display information about Layer 2 Relay packets, use the debug l2relay packets command in
privileged EXEC mode. To disable debugging output, use the no form of this command (SGSN D-node
only).
no debug l2relay packets

Usage Guidelines Use the debug l2relay packets command to display information about Layer 2 Relay packets.
The SGSN module uses the proprietary Layer 2 Relay protocol in conjunction with the intra-Serving
GPRS Support Node (iSGSN) protocol for communication between the SGSN-datacom (SGSN-D) and
SGSN-telecom (SGSN-T) units that comprise the SGSN.
For debugging purposes, it might also be useful to trace Layer 2 Relay events. To display information
about Layer 2 Relay events, use the debug l2relay events command.
Normally you will not need to use the debug l2relay packets or debug l2relay events command. If
problems with the SGSN are encountered, Cisco technical support personnel may request that you issue
the command.
Caution Because the debug l2relay packets command generates a significant amount of output, use it only when
Examples The following example enables the display of Layer 2 Relay packets:
Router# debug l2relay packets

DB-1388 May 2008
Debug Commands

debug ip igmp Displays Layer 2 Relay events (SGSN D-node only).

May 2008 DB-1389
Debug Commands
debug lacp
debug lacp
To enable debugging for all Link Aggregation Control Protocol (LACP) debug messages, use the debug
lacp command in privileged EXEC mode. To disable all LACP debug messages, use the no form of this
command.
debug lacp [all | event | fsm | misc | packet]
no debug lacp
Syntax Description all (Optional) Displays all LACP debug information.

event (Optional) Displays all debug information relevant to events that occur
within LACP.
fsm (Optional) Displays changes within the LACP finite state machine.
misc (Optional) Displays various debug information that may be useful for
monitoring the status of LACP.
packet (Optional) Displays the receiving and transmitting LACP control packets.
Command Default LACP debugging activity is disabled.

12.1(13)EW Support for this command was introduced on the Cisco Catalyst 4500
series switch.
12.2(31)SB2 This command was integrated into Cisco IOS Release 12.2(31)SB.
12.2(33)SRB Support for this command on the Cisco 7600 router was integrated into
Cisco IOS Release 12.2(33)SRB.
Usage Guidelines This command is useful for troubleshooting problems with LACP.
Examples The following sample output from the debug lacp all command shows a remote device removing a link:
Router# debug lacp all
Link Aggregation Control Protocol all debugging is on

Router1#
*Aug 20 17:21:51.685: LACP :lacp_bugpak: Receive LACP-PDU packet via Gi5/0/0
*Aug 20 17:21:51.685: LACP : packet size: 124
*Aug 20 17:21:51.685: LACP: pdu: subtype: 1, version: 1

DB-1390 May 2008
Debug Commands
debug lacp
*Aug 20 17:21:51.685: LACP: Act: tlv:1, tlv-len:20, key:0x1, p-pri:0x8000, p:0x14,

p-state:0x3C,
s-pri:0xFFFF, s-mac:0011.2026.7300
*Aug 20 17:21:51.685: LACP: Part: tlv:2, tlv-len:20, key:0x5, p-pri:0x8000, p:0x42,
p-state:0x3D,
s-pri:0x8000, s-mac:0014.a93d.4a00
*Aug 20 17:21:51.685: LACP: col-tlv:3, col-tlv-len:16, col-max-d:0x8000
*Aug 20 17:21:51.685: LACP: term-tlv:0 termr-tlv-len:0
*Aug 20 17:21:51.685: LACP: Gi5/0/0 LACP packet received, processing
*Aug 20 17:21:51.685: lacp_rx Gi5: during state CURRENT, got event 5(recv_lacpdu)
*Aug 20 17:21:59.869: LACP: lacp_p(Gi5/0/0) timer stopped
*Aug 20 17:21:59.869: LACP: lacp_p(Gi5/0/0) expired
*Aug 20 17:21:59.869: lacp_ptx Gi5: during state SLOW_PERIODIC, got event
3(pt_expired)
*Aug 20 17:21:59.869: @@@ lacp_ptx Gi5: SLOW_PERIODIC -> PERIODIC_TX
*Aug 20 17:21:59.869: LACP: Gi5/0/0 lacp_action_ptx_slow_periodic_exit entered
*Aug 20 17:22:00.869: LACP: lacp_t(Gi5/0/0) timer stopped
*Aug 20 17:22:00.869: LACP: lacp_t(Gi5/0/0) expired
*Aug 20 17:22:19.089: LACP :lacp_bugpak: Receive LACP-PDU packet via Gi5/0/0
*Aug 20 17:22:19.089: LACP: pdu: subtype: 1, version: 1
*Aug 20 17:22:19.089: LACP: Act: tlv:1, tlv-len:20, key:0x1, p-pri:0x8000, p:0x14,
p-state:0x4,
s-pri:0xFFFF, s-mac:0011.2026.7300
*Aug 20 17:22:19.089: LACP: Part: tlv:2, tlv-len:20, key:0x5, p-pri:0x8000, p:0x42,
p-state:0x34,
s-pri:0x8000, s-mac:0014.a93d.4a00
*Aug 20 17:22:19.089: LACP: col-tlv:3, col-tlv-len:16, col-max-d:0x8000
*Aug 20 17:22:19.089: LACP: term-tlv:0 termr-tlv-len:0
*Aug 20 17:22:19.089: LACP: Gi5/0/0 LACP packet received, processing
*Aug 20 17:22:19.089: lacp_rx Gi5: during state CURRENT, got event 5(recv_lacpdu)
*Aug 20 17:22:19.989: LACP: timer lacp_t(Gi5/0/0) started with interval 1000.
*Aug 20 17:22:19.989: LACP: lacp_send_lacpdu: (Gi5/0/0) About to send the 110 LACPDU
*Aug 20 17:22:19.989: LACP :lacp_bugpak: Send LACP-PDU packet via Gi5/0/0
*Aug 20 17:22:21.205: %LINK-3-UPDOWN: Interface GigabitEthernet5/0/0, changed state to
down
*Aug 20 17:22:21.205: LACP: lacp_hw_off: Gi5/0/0 is going down
*Aug 20 17:22:21.205: LACP: if_down: Gi5/0/0

*Aug 20 17:22:21.205: lacp_ptx Gi5: during state SLOW_PERIODIC, got event
0(no_periodic)
*Aug 20 17:22:22.089: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel5,
*Aug 20 17:22:22.153: %C10K_ALARM-6-INFO: CLEAR CRITICAL GigE 5/0/0 Physical Port Link
Down
*Aug 20 17:22:23.413: LACP: Gi5/0/0 oper-key: 0x0
*Aug 20 17:22:23.413: LACP: lacp_hw_on: Gi5/0/0 is coming up
*Aug 20 17:22:23.413: lacp_ptx Gi5: during state NO_PERIODIC, got event 0(no_periodic)
*Aug 20 17:22:23.413: @@@ lacp_ptx Gi5: NO_PERIODIC -> NO_PERIODIC
*Aug 20 17:22:23.413: LACP: Gi5/0/0 lacp_action_ptx_no_periodic entered
*Aug 20 17:22:24.153: %LINK-3-UPDOWN: Interface GigabitEthernet5/0/0, changed state to up
*Aug 20 17:22:24.153: LACP: lacp_hw_on: Gi5/0/0 is coming up
*Aug 20 17:22:24.153: lacp_ptx Gi5: during state FAST_PERIODIC, got event

0(no_periodic)
*Aug 20 17:22:24.153: @@@ lacp_ptx Gi5: FAST_PERIODIC -> NO_PERIODIC

May 2008 DB-1391
Debug Commands
debug lacp
*Aug 20 17:22:24.153: LACP: Gi5/0/0 lacp_action_ptx_fast_periodic_exit entered

*Aug 20 17:22:24.153: LACP:
3(pt_expired)
*Aug 20 17:22:25.021: @@@ lacp_ptx Gi5: FAST_PERIODIC -> PERIODIC_TX
3(pt_expired)
*Aug 20 17:22:25.917: @@@ lacp_ptx Gi5: FAST_PERIODIC -> PERIODIC_TX
Router1#

DB-1392 May 2008
Debug Commands
debug lane client
debug lane client

To display information about a LAN Emulation Client (LEC), use the debug lane client command in
debug lane client {all | le-arp | mpoa | packet | signaling | state | topology} [interface interface]
no debug lane client {all | le-arp | mpoa | packet | signaling | state | topology} [interface
interface]
Syntax Description all Displays all debug information related to the LEC.
le-arp Displays debug information related to the LAN Emulation (LANE) Address
Resolution Protocol (ARP) table.
mpoa Displays debug information to track the following:
MPOA specific TLV information in le-arp requests/responses
Elan-id and local segment TLV in lane control frames
When a LANE client is bound to an MPC/MPS
packet Displays debug information about each packet.
signaling Displays debug information related to client switched virtual circuits (SVCs).
state Displays debug information when the state changes.
topology Displays debug information related to the topology of the emulated LAN
(ELAN).
interface interface (Optional) Limits the debugging output to messages that relate to a particular
interface or subinterface. If you enter this command multiple times with different
interfaces, the last interface entered will be the one used to filter the messages.
Defaults If the interface number is not specified, the default will be the number of all the mpoa lane clients.

Usage Guidelines The debug lane client all command can generate a large amount of output. Use a limiting keyword or
specify a subinterface to decrease the amount of output and focus on the information you need.

May 2008 DB-1393
Debug Commands
debug lane client
Examples The following example shows output for debug lane client packet and debug lane client state
commands for an LEC joining an ELAN named elan1:
Router# debug lane client packet
Router# debug lane client state
The LEC listens for signaling calls to its ATM address (Initial State):
LEC ATM2/0.1: sending LISTEN
LEC ATM2/0.1: listen on 39.020304050607080910111213.00000CA05B40.01
LEC ATM2/0.1: received LISTEN
The LEC calls the LAN Emulation Configuration Server (LECS) and attempts to set up the Configure
Direct VC (LECS Connect Phase):
LEC ATM2/0.1: sending SETUP
LEC ATM2/0.1: callid 0x6114D174
LEC ATM2/0.1: called party 39.020304050607080910111213.00000CA05B43.00
LEC ATM2/0.1: calling_party 39.020304050607080910111213.00000CA05B40.01
The LEC receives a CONNECT response from the LECS. The Configure Direct VC is established:
LEC ATM2/0.1: received CONNECT
LEC ATM2/0.1: vcd 148
The LEC sends a CONFIG REQUEST to the LECS on the Configure Direct VC (Configuration Phase):
LEC ATM2/0.1: sending LANE_CONFIG_REQ on VCD 148
LEC ATM2/0.1: SRC MAC address 0000.0ca0.5b40
LEC ATM2/0.1: SRC ATM address 39.020304050607080910111213.00000CA05B40.01
LEC ATM2/0.1: LAN Type 2
LEC ATM2/0.1: Frame size 2
LEC ATM2/0.1: LAN Name elan1
LEC ATM2/0.1: LAN Name size 5
The LEC receives a CONFIG RESPONSE from the LECS on the Configure Direct VC:
LEC ATM2/0.1: received LANE_CONFIG_RSP on VCD 148
The LEC releases the Configure Direct VC:

LEC ATM2/0.1: sending RELEASE
LEC ATM2/0.1: cause code 31
The LEC receives a RELEASE_COMPLETE from the LECS:

LEC ATM2/0.1: received RELEASE_COMPLETE

DB-1394 May 2008
Debug Commands
debug lane client
The LEC calls the LAN Emulation Server (LES) and attempts to set up the Control Direct VC
(Join/Registration Phase):
LEC ATM2/0.1: callid 0x61167110
The LEC receives a CONNECT response from the LES. The Control Direct VC is established:
LEC ATM2/0.1: callid 0x61167110
The LEC sends a JOIN REQUEST to the LES on the Control Direct VC:
LEC ATM2/0.1: sending LANE_JOIN_REQ on VCD 150
LEC ATM2/0.1: Status 0
LEC ATM2/0.1: LECID 0
The LEC receives a SETUP request from the LES to set up the Control Distribute VC:
LEC ATM2/0.1: received SETUP
The LEC responds to the LES call setup with a CONNECT:

LEC ATM2/0.1: sending CONNECT
A CONNECT_ACK is received from the ATM switch. The Control Distribute VC is established:
LEC ATM2/0.1: received CONNECT_ACK
The LEC receives a JOIN response from the LES on the Control Direct VC.
LEC ATM2/0.1: received LANE_JOIN_RSP on VCD 150

LEC ATM2/0.1: Status 0
LEC ATM2/0.1: LECID 1
The LEC sends an LE ARP request to the LES to obtain the broadcast and unknown server (BUS) ATM
NSAP address (BUS connect):
LEC ATM2/0.1: sending LANE_ARP_REQ on VCD 150
LEC ATM2/0.1: TARGET MAC address ffff.ffff.ffff
LEC ATM2/0.1: TARGET ATM address 00.000000000000000000000000.000000000000.00

May 2008 DB-1395
Debug Commands
debug lane client
The LEC receives its own LE ARP request via the LES over the Control Distribute VC:
LEC ATM2/0.1: received LANE_ARP_RSP on VCD 151
LEC ATM2/0.1: TARGET MAC address ffff.ffff.ffff
LEC ATM2/0.1: TARGET ATM address 39.020304050607080910111213.00000CA05B42.01
The LEC calls the BUS and attempts to set up the Multicast Send VC:
The LEC receives a CONNECT response from the BUS. The Multicast Send VC is established:
The LEC receives a SETUP request from the BUS to set up the Multicast Forward VC:
LEC ATM2/0.1: received SETUP
The LEC responds to the BUS call setup with a CONNECT:

LEC ATM2/0.1: sending CONNECT
A CONNECT_ACK is received from the ATM switch. The Multicast Forward VC is established:
LEC ATM2/0.1: received CONNECT_ACK
The LEC moves into the OPERATIONAL state.
%LANE-5-UPDOWN: ATM2/0.1 elan elan1: LE Client changed state to up
The following output is from the show lane client command after the LEC joins the emulated LAN as
shown in the debug lane client output:
Router# show lane client
LE Client ATM2/0.1 ELAN name: elan1 Admin: up State: operational

Client ID: 1 LEC up for 1 minute 2 seconds
Join Attempt: 1
HW Address: 0000.0ca0.5b40 Type: token ring Max Frame Size: 4544
Ring:1 Bridge:1 ELAN Segment ID: 2048
ATM Address: 39.020304050607080910111213.00000CA05B40.01
VCD rxFrames txFrames Type ATM Address
0 0 0 configure 39.020304050607080910111213.00000CA05B43.00
142 1 2 direct 39.020304050607080910111213.00000CA05B41.01
143 1 0 distribute 39.020304050607080910111213.00000CA05B41.01
145 0 0 send 39.020304050607080910111213.00000CA05B42.01
146 1 0 forward 39.020304050607080910111213.00000CA05B42.01

DB-1396 May 2008
Debug Commands
debug lane client
The following example shows debug lane client all command output when an interface with LECS, an
LES/BUS, and an LEC is shut down:
Router# debug lane client all

LEC ATM1/0.2: callid 0x60E8B474
LEC ATM1/0.2: action A_PROCESS_REL_COMP
LEC ATM1/0.2: action A_TEARDOWN_LEC
LEC ATM1/0.2: callid 0x60EB6160
LEC ATM1/0.2: callid 0x60EB9E48
LEC ATM1/0.2: sending CANCEL
LEC ATM1/0.2: ATM address 47.00918100000000613E5A2F01.006070174820.02
LEC ATM1/0.2: state ACTIVE event LEC_SIG_RELEASE_COMP => TERMINATING
LEC ATM1/0.3: callid 0x60E8D108
LEC ATM1/0.3: callid 0x60EB66D4
LEC ATM1/0.3: callid 0x60EB7B8C
LEC ATM1/0.3: callid 0x60EBA3BC
LEC ATM1/0.2: action A_PROCESS_TERM_REL_COMP
LEC ATM1/0.2: state TERMINATING event LEC_SIG_RELEASE_COMP => TERMINATING
LEC ATM1/0.3: callid 0x60EB7B8C
LEC ATM1/0.1: callid 0x60EBC458
LEC ATM1/0.1: callid 0x60EBD30C
LEC ATM1/0.1: callid 0x60EBDD28
LEC ATM1/0.1: callid 0x60EBF174

May 2008 DB-1397
Debug Commands
debug lane client

LEC ATM1/0.1: callid 0x60EBDD28
LEC ATM1/0.3: callid 0x60EB66D4
LEC ATM1/0.2: callid 0x60EB9E48
LEC ATM1/0.2: state TERMINATING event LEC_SIG_RELEASE_COMP => IDLE
LEC ATM1/0.3: callid 0x60EBA3BC
LEC ATM1/0.1: callid 0x60EBD30C
LEC ATM1/0.1: callid 0x60EBF174
LEC ATM1/0.2: received CANCEL
LEC ATM1/0.2: state IDLE event LEC_SIG_CANCEL => IDLE
LEC ATM1/0.1: action A_SHUTDOWN_LEC
LEC ATM1/0.1: state IDLE event LEC_LOCAL_DEACTIVATE => IDLE

DB-1398 May 2008
Debug Commands
debug lane client
The following output is from the debug lane client mpoa command when the lane interface is shut
down:
Router# debug lane client mpoa
Router#conf t
Router(config)#int atm 1/1/0.1
Router(config-subif)#shutdown
Router(config-subif)#
00:23:32:%LANE-5-UPDOWN:ATM1/1/0.1 elan elan2:LE Client changed state to down
00:23:32:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWN
Router(config-subif)#exit
Router(config)#exit
The following output is from the debug lane client mpoa command when the lane interface is started
(not shut down):
Router#conf t
Router(config)#int atm 1/1/0.1
Router(config-subif)#no shutdown
00:23:39:LEC ATM1/1/0.1:lec_process_lane_tlv:msg LANE_CONFIG_RSP, num_tlvs 14
00:23:39:LEC ATM1/1/0.1:elan id from LECS set to 300
00:23:39:LEC ATM1/1/0.1:lec_process_lane_tlv:msg LANE_JOIN_RSP, num_tlvs 1
00:23:39:LEC ATM1/1/0.1:elan id from LES set to 300
00:23:39:LEC ATM1/1/0.1:lec_append_mpoa_dev_tlv:
00:23:39:LEC ATM1/1/0.1:got mpoa client addr 47.0091810000000050E2097801.0050A
29AF42D.00
00:23:39:%LANE-5-UPDOWN:ATM1/1/0.1 elan elan2:LE Client changed state to up
00:23:39:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:UP
00:25:57:LEC ATM1/1/0.1:lec_process_lane_tlv:msg LANE_ARP_REQ, num_tlvs 1
00:25:57:LEC ATM1/1/0.1:lec_process_dev_type_tlv: lec 47.0091810000000050E
2097801.00500B306440.02
type MPS, mpc 00.000000000000000000000000.000000000000.00
mps 47.0091810000000050E2097801.00500B306444.00, num_mps_mac 1, mac 0050.0b3
0.6440
00:25:57:LEC ATM1/1/0.1:create mpoa_lec
00:25:57:LEC ATM1/1/0.1:new mpoa_lec 0x617E3118
00:25:57:LEC ATM1/1/0.1:lec_process_dev_type_tlv:type MPS, num _mps_mac
1
00:2t 5:57:LEC ATM1/1/0.1:lec_add_mps:
remote lec 47.0091810000000050E2097801.00500B306440.02
mps 47.0091810000000050E2097801.00500B306444.00 num_mps_mac 1, mac 0050.0b30
.6440
00:25:57:LEC ATM1/1/0.1:mpoa_device_change:lec_nsap 47.0091810000000050E20978
01.00500B306440.02, appl_type 5
mpoa_nsap 47.0091810000000050E2097801.00500B306444.00, opcode 4
00:25:57:LEC ATM1/1/0.1:lec_add_mps:add mac 0050.0b30.6440, mps_mac 0x617E372
C
00:25:57:LEC ATM1/1/0.1:mpoa_device_change:lec_nsap 47.0091810000000050E20978
01.00500B306440.02, appl_type 5
mpoa_nsap 47.0091810000000050E2097801.00500B306444.00, opcode 5
00:25:57:LEC ATM1/1/0.1: mps_mac 0050.0b30.6440

May 2008 DB-1399
Debug Commands
debug lane client

29AF42D.00
Router(config-subif)#exit
Router(config)#exit
The following output is from the debug lane client mpoa command when the ATM major interface is
shut down:
Router# conf t
Router(config)#int atm 1/1/0
Router(config-if)# shutdown
Router(config-if)#
00:26:28:LANE ATM1/1/0:atm hardware reset
00:26:28:%MPOA-5-UPDOWN:MPC mpc2:state changed to down
00:26:28:LEC ATM1/1/0.1:mpoa_to_lec:appl 6, opcode 0
00:26:30:%LINK-5-CHANGED:Interface ATM1/1/0, changed state to administratively
down
00:26:31:%LINEPROTO-5-UPDOWN:Line protocol on Interface ATM1/1/0, changed stat
e to down
Router(config-if)#

Router(config-if)# exit
The following output is from the debug lane client mpoa command when the ATM major interface is
started:
Router# conf t
Router(config)# int atm 1/1/0
Router(config-if)# no shutdown
00:26:34:%LINK-3-UPDOWN:Interface ATM1/1/0, changed state to down
00:26:41:%LINK-3-UPDOWN:Interface ATM1/1/0, changed state to up
00:26:42:%LINEPROTO-5-UPDOWN:Line protocol on Interface ATM1/1/0, changed stat
e to up
00:27:10:%LANE-6-INFO:ATM1/1/0:ILMI prefix add event received
00:27:10:LANE ATM1/1/0:prefix add event for 470091810000000050E2097801 ptr=0x6
17BFC0C len=13
00:27:10: the current first prefix is now:470091810000000050E2097801
00:27:10:%ATMSSCOP-5-SSCOPINIT:- Intf :ATM1/1/0, Event :Rcv End, State :Act
ive.
00:27:10:%LANE-3-NOREGILMI:ATM1/1/0.1 LEC cannot register 47.0091810000000050E

2097801.0050A29AF428.01 with ILMI
00:27:10:%LANE-6-INFO:ATM1/1/0:ILMI prefix add event received
00:27:10:LANE ATM1/1/0:prefix add event for 470091810000000050E2097801 ptr=0x6
17B8E6C len=13

DB-1400 May 2008
Debug Commands
debug lane client
00:27:10: the current first prefix is now:470091810000000050E2097801

00:27:10:%MPOA-5-UPDOWN:MPC mpc2:state changed to up

00:27:12:LEC ATM1/1/0.1:lec_process_lane_tlv:msg LANE_CONFIG_RSP, num_tlvs 14

00:27:12:LEC ATM1/1/0.1:elan id from LECS set to 300
00:27:12:LEC ATM1/1/0.1:lec_process_lane_tlv:msg LANE_JOIN_RSP, num_tlvs 1
00:27:12:LEC ATM1/1/0.1:elan id from LES set to 300
29AF42D.00
00:27:12:%LANE-5-UPDOWN:ATM1/1/0.1 elan elan2:LE Client changed state to up
00:27:12:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:UP
Router(config-if)#exit
Router(config)#exit

debug modem traffic Displays MPC debug information.
debug mpoa server Displays information about the MPOA server.

May 2008 DB-1401
Debug Commands
debug lane config
debug lane config

To display information about a LAN Emulation (LANE) configuration server, use the debug lane config
debug lane config {all | events | packets}
no debug lane config {all | events | packets}
Syntax Description all Displays all debugging messages related to the LANE configuration
server. The output includes both the events and packets types of
output.
events Displays only messages related to significant LANE configuration
server events.
packets Displays information on each packet sent or received by the LANE
configuration server.
Usage Guidelines The debug lane config output is intended to be used primarily by a Cisco technical support
representative.
Examples The following is sample output from the debug lane config all command when an interface with LECS,
an LES/BUS, and an LEC is shut down:
Router# debug lane config all
LECS EVENT ATM1/0: processing interface down transition

LECS EVENT ATM1/0: placed de-register address 0x60E8A824
(47.00918100000000613E5A2F01.006070174823.00) request with signalling
LECS EVENT ATM1/0: ilmiDeRegisterAddress: sendSetRequestToILMI failure; interface down ?
LECS EVENT ATM1/0: placed de-register address 0x60EC4F28
(47.007900000000000000000000.00A03E000001.00) request with signalling
LECS EVENT ATM1/0: placed de-register address 0x60EC5C08
LECS EVENT ATM1/0: tearing down all connexions
LECS EVENT ATM1/0: elan 'xxx' LES 47.00918100000000613E5A2F01.006070174821.01 callId
0x60CE0F58 deliberately being disconnected
LECS EVENT ATM1/0: sending RELEASE for call 0x60CE0F58 cause 31
LECS EVENT ATM1/0: elan 'yyy' LES 47.00918100000000613E5A2F01.006070174821.02 callId
0x60CE2104 deliberately being disconnected
LECS EVENT ATM1/0: sending RELEASE for call 0x60CE2104 cause 31
LECS EVENT ATM1/0: elan 'zzz' LES 47.00918100000000613E5A2F01.006070174821.03 callId
0x60CE2DC8 deliberately being disconnected
LECS EVENT ATM1/0: sending RELEASE for call 0x60CE2DC8 cause 31
LECS EVENT ATM1/0: All calls to/from LECSs are being released
LECS EVENT ATM1/0: placed de-register address 0x60EC4F28
(47.007900000000000000000000.00A03E000001.00) request with signalling

DB-1402 May 2008
Debug Commands
debug lane config
LECS EVENT ATM1/0: ATM_RELEASE_COMPLETE received: callId 0x60CE0F58 cause 0

LECS EVENT ATM1/0: call 0x60CE0F58 cleaned up
LECS EVENT ATM1/0: ATM_RELEASE_COMPLETE received: callId 0x60CE2104 cause 0
LECS EVENT ATM1/0: call 0x60CE2104 cleaned up
LECS EVENT ATM1/0: ATM_RELEASE_COMPLETE received: callId 0x60CE2DC8 cause 0
LECS EVENT ATM1/0: call 0x60CE2DC8 cleaned up
LECS EVENT ATM1/0: UNKNOWN/UNSET: signalling DE-registered
LECS EVENT: UNKNOWN/UNSET: signalling DE-registered
LECS EVENT ATM1/0: UNKNOWN/UNSET: signalling DE-registered
LECS EVENT ATM1/0: placed de-register address 0x60E8A824
LECS EVENT ATM1/0: placed de-register address 0x60EC5C08
LECS EVENT ATM1/0: tearing down all connexions
LECS EVENT ATM1/0: All calls to/from LECSs are being released
LECS EVENT: config server 56 killed

May 2008 DB-1403
Debug Commands
debug lane finder
debug lane finder

To display information about the finder internal state machine, use the debug lane finder command in
debug lane finder
no debug lane finder
Usage Guidelines The debug lane finder command output is intended to be used primarily by a Cisco technical support
representative.
Examples The following is sample output from the debug lane finder command when an interface with LECS,
LES/BUS, and LEC is shut down:
Router# debug lane finder
LECS FINDER ATM1/0.3: user request 1819 of type GET_MASTER_LECS_ADDRESS queued up

LECS FINDER ATM1/0: finder state machine started
LECS FINDER ATM1/0: time to perform a getNext on the ILMI
LECS FINDER ATM1/0: LECS 47.00918100000000613E5A2F01.006070174823.00 deleted
LECS FINDER ATM1/0: ilmi_client_request failed, answering all users
LECS FINDER ATM1/0: answering all requests now
LECS FINDER ATM1/0: responded to user request 1819
LECS FINDER ATM1/0: number of remaining requests still to be processed: 0

DB-1404 May 2008
Debug Commands
debug lane server
debug lane server

To display information about a LAN Emulation (LANE) server, use the debug lane server command in
debug lane server [interface interface]
no debug lane server [interface interface]
Syntax Description interface interface (Optional) Limits the debugging output to messages relating to a specific
interface or subinterface. If you use this command multiple times with different
interfaces, the last interface entered is the one used to filter debugging
messages.
Usage Guidelines The debug lane server command output is intended to be used primarily by a Cisco technical support
representative. The debug lane server command can generate a substantial amount of output. Specify a
subinterface to decrease the amount of output and focus on the information you need.
Examples The following is sample output from the debug lane server command when an interface with LECS,
Router# debug lane server
LES ATM1/0.1: lsv_lecsAccessSigCB called with callId 0x60CE124C, opcode

ATM_RELEASE_COMPLETE
LES ATM1/0.1: disconnected from the master LECS
LES ATM1/0.1: should have been connected, will reconnect in 3 seconds
LES ATM1/0.2: lsv_lecsAccessSigCB called with callId 0x60CE29E0, opcode
LES ATM1/0.3: lsv_lecsAccessSigCB called with callId 0x60EB1940, opcode
LES ATM1/0.2: elan yyy client 1 lost control distribute
LES ATM1/0.2: elan yyy client 1: lsv_kill_client called
LES ATM1/0.2: elan yyy client 1 state change Oper -> Term
LES ATM1/0.3: elan zzz client 1 lost control distribute
LES ATM1/0.3: elan zzz client 1: lsv_kill_client called
LES ATM1/0.3: elan zzz client 1 state change Oper -> Term
LES ATM1/0.2: elan yyy client 1 lost MC forward
LES ATM1/0.3: elan zzz client 1 lost MC forward
LES ATM1/0.1: elan xxx client 1 lost control distribute
LES ATM1/0.1: elan xxx client 1: lsv_kill_client called
LES ATM1/0.1: elan xxx client 1 state change Oper -> Term
LES ATM1/0.1: elan xxx client 1 lost MC forward

May 2008 DB-1405
Debug Commands
debug lane server
LES ATM1/0.2: elan yyy client 1 released control direct

LES ATM1/0.3: elan zzz client 1 released control direct
LES ATM1/0.2: elan yyy client 1 MC forward released
LES ATM1/0.2: elan yyy client 1: freeing client structures
LES ATM1/0.2: elan yyy client 1 unregistered 0060.7017.4820
LES ATM1/0.2: elan yyy client 1 destroyed
LES ATM1/0.3: elan zzz client 1 MC forward released
LES ATM1/0.3: elan zzz client 1: freeing client structures
LES ATM1/0.3: elan zzz client 1 unregistered 0060.7017.4820
LES ATM1/0.3: elan zzz client 1 destroyed
LES ATM1/0.1: elan xxx client 1 released control direct
LES ATM1/0.1: elan xxx client 1 MC forward released
LES ATM1/0.1: elan xxx client 1: freeing client structures
LES ATM1/0.1: elan xxx client 1 unregistered 0060.7017.4820
LES ATM1/0.1: elan xxx client 1 destroyed
LES ATM1/0.1: elan xxx major interface state change
LES ATM1/0.1: cleanupLecsAccess: discarding all validation requests
LES ATM1/0.1: shutting down
LES ATM1/0.1: elan xxx: lsv_kill_lesbus called
LES ATM1/0.1: elan xxx: LES/BUS state change operational -> terminating
LES ATM1/0.2: elan yyy major interface state change
LES ATM1/0.2: elan yyy: lsv_kill_lesbus called
LES ATM1/0.2: elan yyy: LES/BUS state change operational -> terminating
LES ATM1/0.3: elan zzz major interface state change
LES ATM1/0.3: elan zzz: lsv_kill_lesbus called
LES ATM1/0.3: elan zzz: LES/BUS state change operational -> terminating
LES ATM1/0.1: elan xxx: stopped listening on addresses
LES ATM1/0.1: elan xxx: all clients killed
LES ATM1/0.1: elan xxx: multicast groups killed
LES ATM1/0.1: elan xxx: addresses de-registered from ilmi
LES ATM1/0.1: elan xxx: LES/BUS state change terminating -> down
LES ATM1/0.1: elan xxx: administratively down
LES ATM1/0.2: elan yyy: stopped listening on addresses
LES ATM1/0.2: elan yyy: all clients killed
LES ATM1/0.2: elan yyy: multicast groups killed
LES ATM1/0.2: elan yyy: addresses de-registered from ilmi
LES ATM1/0.2: elan yyy: LES/BUS state change terminating -> down
LES ATM1/0.2: elan yyy: administratively down
LES ATM1/0.3: elan zzz: stopped listening on addresses

DB-1406 May 2008
Debug Commands
debug lane server
LES ATM1/0.3: elan zzz: all clients killed

LES ATM1/0.3: elan zzz: multicast groups killed
LES ATM1/0.3: elan zzz: addresses de-registered from ilmi
LES ATM1/0.3: elan zzz: LES/BUS state change terminating -> down
LES ATM1/0.3: elan zzz: administratively down

May 2008 DB-1407
Debug Commands
debug lane signaling

To display information about LANE Server (LES) and Broadcast and Unknown Server (BUS) switched
virtual circuits (SVCs), use the debug lane signaling command in privileged EXEC mode. To disable
debug lane signaling [interface interface]
no debug lane signaling [interface interface]
Syntax Description interface interface (Optional) Limits the debugging output to messages relating to a
specific interface or subinterface. If you use this command multiple
times with different interfaces, the last interface entered is the one
used to filter debugging messages.
Usage Guidelines The debug lane signaling command output is intended to be used primarily by a Cisco technical support
representative. The debug lane signaling command can generate a substantial amount of output. Specify
a subinterface to decrease the amount of output and focus on the information you need.
Examples The following is sample output from the debug lane signaling command when an interface with LECS,
Router# debug lane signaling
LANE SIG ATM1/0.2: received ATM_RELEASE_COMPLETE callid 0x60EB565C cause 0 lv 0x60E8D348

lvstate LANE_VCC_CONNECTED
LANE SIG ATM1/0.2: lane_sig_mc_release: breaking lv 0x60E8D348 from mcg 0x60E97E84
LANE SIG ATM1/0.2: timer for lv 0x60E8D348 stopped
LANE SIG ATM1/0.2: sent ATM_RELEASE request for lv 0x60E8D468 in state LANE_VCC_CONNECTED
LANE SIG ATM1/0.2: sent ATM_RELEASE request for lv 0x60E8D3D8 in state LANE_VCC_CONNECTED
LANE SIG ATM1/0.2: sent ATM_RELEASE request for lv 0x60E8D2B8 in state LANE_VCC_CONNECTED
LANE SIG ATM1/0.3: received ATM_RELEASE_COMPLETE callid 0x60EB5CA0 cause 0 lv 0x60E8BEF4
LANE SIG ATM1/0.3: lane_sig_mc_release: breaking lv 0x60E8BEF4 from mcg 0x60E9A37C
LANE SIG ATM1/0.3: timer for lv 0x60E8BEF4 stopped
LANE SIG ATM1/0.3: sent ATM_RELEASE request for lv 0x60E8C014 in state LANE_VCC_CONNECTED
LANE SIG ATM1/0.3: sent ATM_RELEASE request for lv 0x60E8BF84 in state LANE_VCC_CONNECTED
LANE SIG ATM1/0.3: sent ATM_RELEASE request for lv 0x60E8BE64 in state LANE_VCC_CONNECTED
LANE SIG ATM1/0.2: received ATM_RELEASE_COMPLETE callid 0x60EB9040 cause 0 lv 0x60E8D468
lvstate LANE_VCC_DROP_SENT
LANE SIG ATM1/0.2: lane_sig_mc_release: breaking lv 0x60E8D468 from mcg 0x60E97EC8
LANE SIG ATM1/0.2: timer for lv 0x60E8D468 stopped
LANE SIG ATM1/0.3: received ATM_RELEASE_COMPLETE callid 0x60EB97D4 cause 0 lv 0x60E8C014
LANE SIG ATM1/0.3: lane_sig_mc_release: breaking lv 0x60E8C014 from mcg 0x60E9A3C0
LANE SIG ATM1/0.3: timer for lv 0x60E8C014 stopped
LANE SIG ATM1/0.1: received ATM_RELEASE_COMPLETE callid 0x60EBCEB8 cause 0 lv 0x60EBBAF0
LANE SIG ATM1/0.1: lane_sig_mc_release: breaking lv 0x60EBBAF0 from mcg 0x60E8F51C
LANE SIG ATM1/0.1: timer for lv 0x60EBBAF0 stopped

DB-1408 May 2008
Debug Commands
LANE SIG ATM1/0.1: sent ATM_RELEASE request for lv 0x60EBBC10 in state LANE_VCC_CONNECTED
LANE SIG ATM1/0.1: sent ATM_RELEASE request for lv 0x60EBBB80 in state LANE_VCC_CONNECTED
LANE SIG ATM1/0.1: sent ATM_RELEASE request for lv 0x60EBBA60 in state LANE_VCC_CONNECTED
LANE SIG ATM1/0.1: received ATM_RELEASE_COMPLETE callid 0x60EBEB00 cause 0 lv 0x60EBBC10
LANE SIG ATM1/0.1: lane_sig_mc_release: breaking lv 0x60EBBC10 from mcg 0x60E8F560
LANE SIG ATM1/0.1: timer for lv 0x60EBBC10 stopped
LANE SIG ATM1/0.2: received ATM_RELEASE_COMPLETE callid 0x60E8B174 cause 0 lv 0x60E8D2B8
lvstate LANE_VCC_RELEASE_SENT
LANE SIG ATM1/0.2: timer for lv 0x60E8D2B8 stopped
LANE SIG ATM1/0.3: received ATM_RELEASE_COMPLETE callid 0x60E8B990 cause 0 lv 0x60E8BE64
LANE SIG ATM1/0.3: timer for lv 0x60E8BE64 stopped
LANE SIG ATM1/0.2: received ATM_RELEASE_COMPLETE callid 0x60EB7FE0 cause 0 lv 0x60E8D3D8
LANE SIG ATM1/0.2: timer for lv 0x60E8D3D8 stopped
LANE SIG ATM1/0.3: received ATM_RELEASE_COMPLETE callid 0x60EB8554 cause 0 lv 0x60E8BF84
LANE SIG ATM1/0.3: timer for lv 0x60E8BF84 stopped
LANE SIG ATM1/0.1: received ATM_RELEASE_COMPLETE callid 0x60EBB6D4 cause 0 lv 0x60EBBA60
LANE SIG ATM1/0.1: timer for lv 0x60EBBA60 stopped
LANE SIG ATM1/0.1: received ATM_RELEASE_COMPLETE callid 0x60EBE24C cause 0 lv 0x60EBBB80
LANE SIG ATM1/0.1: timer for lv 0x60EBBB80 stopped
LANE SIG ATM1/0.1: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTER
LANE SIG ATM1/0.1: received ATM_CANCEL_NSAP for nsap
00.000000000000050000000000.000000000000.00
00.000000000000050000000000.000000000000.00
00.000000000000050000000000.000000000000.00
00.000000000000050000000000.000000000000.00
00.000000000000050000000000.000000000000.00
00.000000000000050000000000.000000000000.00

May 2008 DB-1409
Debug Commands
debug lapb
debug lapb
To display all traffic for interfaces using Link Access Procedure, Balanced (LAPB) encapsulation, use
the debug lapb command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
debug lapb
no debug lapb
Usage Guidelines This command displays information on the X.25 Layer 2 protocol. It is useful to users familiar with the
LAPB protocol.
You can use the debug lapb command to determine why X.25 interfaces or LAPB connections are going
up and down. It is also useful for identifying link problems, as evidenced when the show interfaces
EXEC command displays a high number of rejects or frame errors over the X.25 link.
Caution Because the debug lapb command generates a substantial amount of output, use it when the aggregate
of all LAPB traffic on X.25 and LAPB interfaces is fewer than five frames per second.
Examples The following is sample output from the debug lapb command (the numbers 1 through 7 at the top of
the display have been added in order to aid documentation):
1 2 3 4 5 6 7
Serial0: LAPB I CONNECT (5) IFRAME P 2 1
Serial0: LAPB O REJSENT (2) REJ F 3
Serial0: LAPB O REJSENT (5) IFRAME 0 3
Serial0: LAPB I REJSENT (2) REJ (C) 7
Serial0: LAPB I DISCONNECT (2) SABM P
Serial0: LAPB O CONNECT (2) UA F
Serial0: LAPB O CONNECT (5) IFRAME 0 0
Serial0: LAPB T1 CONNECT 357964 0
Each line of output describes a LAPB event. There are two types of LAPB events: frame events (when
a frame enters or exits the LAPB) and timer events. In the sample output, the last line describes a timer
event; all of the other lines describe frame events. Table 205 describes the first seven fields.

DB-1410 May 2008
Debug Commands
debug lapb
Table 205 debug lapb Field Descriptions
Field Description
First field (1) Interface type and unit number reporting the frame event.
Second field (2) Protocol providing the information.
Third field (3) Frame event type. Possible values are as follows:
IFrame input
OFrame output
T1T1 timer expired
T3Interface outage timer expired
T4Idle link timer expired
Fourth field (4) State of the protocol when the frame event occurred. Possible values
are as follows:
BUSY (RNR frame received)
CONNECT
DISCONNECT
DISCSENT (disconnect sent)
ERROR (FRMR frame sent)
REJSENT (reject frame sent)
SABMSENT (SABM frame sent)
Fifth field (5) In a frame event, this value is the size of the frame (in bytes). In a timer
event, this value is the current timer value (in milliseconds).

May 2008 DB-1411
Debug Commands
debug lapb
Table 205 debug lapb Field Descriptions (continued)
Field Description
Sixth field (6) In a frame event, this value is the frame type name. Possible values for
frame type names are as follows:
DISCDisconnect
DMDisconnect mode
FRMRFrame reject
IFRAMEInformation frame
ILLEGALIllegal LAPB frame
REJReject
RNRReceiver not ready
RRReceiver ready
SABMSet asynchronous balanced mode
SABMESet asynchronous balanced mode, extended
UAUnnumbered acknowledgment
In a T1 timer event, this value is the number of retransmissions already
attempted.
Seventh field (7) This field is only present in frame events. It describes the frame type
identified by the LAPB address and Poll/Final bit. Possible values are
(This field will not print if
as follows:
the frame control field is
required to appear as either a (C)Command frame
command or a response, and
(R)Response frame
that frame type is correct.)
PCommand/Poll frame
FResponse/Final frame
/ERRCommand/Response type is invalid for the control field.
An ?ERR generally means that the data terminal equipment
(DTE)/data communications equipment (DCE) assignments are
not correct for this link.
BAD-ADDRAddress field is neither Command nor Response
A timer event only displays the first six fields of debug lapb command output. For frame events,
however, the seventh field documents the LAPB control information present in the frame. Depending on
the value of the frame type name shown in the sixth field, the seventh field may or may not appear.
After the Poll/Final indicator, depending on the frame type, three different types of LAPB control
information can be printed.
For information frames, the value of the N(S) field and the N(R) field will be printed. The N(S) field of
an information frame is the sequence number of that frame, so this field will rotate between 0 and 7 for
(modulo 8 operation) or 0 and 127 (for modulo 128 operation) for successive outgoing information
frames and (under normal circumstances) also will rotate for incoming information frame streams. The
N(R) field is a piggybacked acknowledgment for the incoming information frame stream; it informs
the other end of the link which sequence number is expected next.

DB-1412 May 2008
Debug Commands
debug lapb
RR, RNR, and REJ frames have an N(R) field, so the value of that field is printed. This field has exactly
the same significance that it does in an information frame.
For the FRMR frame, the error information is decoded to display the rejected control field, V(R) and
V(S) values, the Response/Command flag, and the error flags WXYZ.
In the following example, the output shows an idle link timer action (T4) where the timer expires twice
on an idle link, with the value of T4 set to five seconds:
Serial2: LAPB T4 CONNECT 255748
Serial2: LAPB O CONNECT (2) RR P 5
Serial2: LAPB I CONNECT (2) RR F 5
Serial2: LAPB T4 CONNECT 260748
Serial2: LAPB O CONNECT (2) RR P 5
Serial2: LAPB I CONNECT (2) RR F 5
The next example shows an interface outage timer expiration (T3):

Serial2: LAPB T3 DISCONNECT 273284
The following example output shows an error condition when no DCE to DTE connection exists. Note
that if a frame has only one valid type (for example, a SABM can only be a command frame), a received
frame that has the wrong frame type will be flagged as a receive error (R/ERR in the following output).
This feature makes misconfigured links (DTE-DTE or DCE-DCE) easy to spot. Other, less common
errors will be highlighed too, such as a too-short or too-long frame, or an invalid address (neither
command nor response).
Serial2: LAPB T1 SABMSENT 1026508 1
Serial2: LAPB O SABMSENT (2) SABM P
Serial2: LAPB I SABMSENT (2) SABM (R/ERR)
Serial2: LAPB O SABMSENT (2) SABM P
Serial2: LAPB I SABMSENT (2) SABM (R/ERR)
The output in the next example shows the router is misconfigured and has a standard (modulo 8) interface
connected to an extended (modulo 128) interface. This condition is indicated by the SABM balanced
mode and SABME balanced mode extended messages appearing on the same interface.
Serial2: LAPB O SABMSENT (2) SABME P
Serial2: LAPB I SABMSENT (2) SABM P
Serial2: LAPB O SABMSENT (2) SABME P
Serial2: LAPB I SABMSENT (2) SABM P

May 2008 DB-1413
Debug Commands
debug lapb-ta
debug lapb-ta
To display debugging messages for Link Access Procedure, Balanced-Terminal Adapter (LAPB-TA),
use the debug lapb-ta command in privileged EXEC mode. To disable debugging output, use the no
debug lapb-ta [error | event | traffic]
no debug lapb-ta [error | event | traffic]
Syntax Description error (Optional) Displays LAPB-TA errors.

event (Optional) Displays LAPB-TA normal events.
traffic (Optional) Displays LAPB-TA in/out traffic data.
Defaults Debugging for LAPB-TA is not enabled.

Examples The following is sample output from the debug lapb-ta command with the error, event, and traffic
keywords activated:
Router# debug lapb-ta error
LAPB-TA error debugging is on
Router# debug lapb-ta event
LAPB-TA event debugging is on
Router# debug lapb-ta traffic
LAPB-TA traffic debugging is on
Mar 9 12:11:36.464:LAPB-TA:Autodetect trying to detect LAPB on

BR3/0:1
Mar 9 12:11:36.464: sampled pkt: 2 bytes: 1 3F.. match
Mar 9 12:11:36.468:LAPBTA:get_ll_config:BRI3/0:1
Mar 9 12:11:36.468:LAPBTA:line 130 allocated for BR3/0:1
Mar 9 12:11:36.468:LAPBTA:process 79
Mar 9 12:11:36.468:BR3/0:1:LAPB-TA started

DB-1414 May 2008
Debug Commands
debug lapb-ta
Mar 9 12:11:36.468:LAPBTA:service change:LAPB physical layer up,

context 6183E144 interface up, protocol down
Mar 9 12:11:36.468:LAPBTA:service change:, context 6183E144 up
Mar 9 12:11:36.468:LAPB-TA:BR3/0:1, 44 sent
2d14h:%LINEPROTO-5-UPDOWN:Line protocol on Interface BRI3/0:1, changed state to up
2d14h:%ISDN-6-CONNECT:Interface BRI3/0:1 is now connected to 60213
Mar 9 12:11:44.508:LAPB-TA:BR3/0:1, 1 rcvd

May 2008 DB-1415
Debug Commands
debug lat packet
debug lat packet

To display information on all local-area transport (LAT) events, use the debug lat packet command in
debug lat packet
no debug lat packet
Usage Guidelines For each datagram (packet) received or sent, a message is logged to the console.
Caution This command severely impacts LAT performance and is intended for troubleshooting use only.
Examples The following is sample output from the debug lat packet command:
Router# debug lat packet
LAT: I int=Ethernet0, src=0000.0c01.0509, dst=0900.2b00.000f, type=0, M=0, R=0

LAT: I int=Ethernet0, src=0800.2b11.2d13, dst=0000.0c01.7876, type=A, M=0, R=0
LAT: O dst=0800.2b11.2d13, int=Ethernet0, type= A, M=0, R=0, len= 20, next 0 ref 1
The second line of output describes a packet that is input to the router. Table 206 describes the fields in
this line.
Table 206 debug lat packet Field Descriptions
Field Description
LAT: Indicates that this display shows LAT debugging output.
I Indicates that this line of output describes a packet that is input to the
router (I) or output from the router (O).
int = Ethernet0 Indicates the interface on which the packet event took place.
src = 0800.2b11.2d13 Indicates the source address of the packet.

DB-1416 May 2008
Debug Commands
debug lat packet
Table 206 debug lat packet Field Descriptions (continued)
Field Description
dst=0000.0c01.7876 Indicates the destination address of the packet.
type=A Indicates the message type (in hexadecimal notation). Possible values
are as follows:
0 = Run Circuit
1 = Start Circuit
2 = Stop Circuit
A = Service Announcement
C = Command
D = Status
E = Solicit Information
F = Response Information
The third line of output describes a packet that is output from the router. Table 207 describes the last
three fields in this line.
Table 207 debug lat packet Field Descriptions
Field Description
len= 20 Indicates the length (in hexadecimal notation) of the packet (in bytes).
next 0 Indicates the link on the transmit queue.
ref 1 Indicates the count of packet users.

May 2008 DB-1417
Debug Commands
debug lex rcmd
debug lex rcmd

To debug LAN Extender remote commands, use the debug lex rcmd command in privileged EXEC
debug lex rcmd
no debug lex rcmd
Examples The following is sample output from the debug lex rcmd command:
Router# debug lex rcmd
LEX-RCMD: "shutdown" command received on unbound serial interface- Serial0

LEX-RCMD: Lex0: "inventory" command received
Rcvd rcmd: FF 03 80 41 41 13 00 1A 8A 00 00 16 01 FF 00 00
Rcvd rcmd: 00 02 00 00 07 5B CD 15 00 00 0C 01 15 26
LEX-RCMD: ACK or response received on Serial0 without a corresponding ID
LEX-RCMD: REJ received
LEX-RCMD: illegal CODE field received in header: <number>
LEX-RCMD: illegal length for Lex0: "lex input-type-list"
LEX-RCMD: Lex0 is not bound to a serial interface
LEX-RCMD: encapsulation failure
LEX-RCMD: timeout for Lex0: "lex priority-group" command
LEX-RCMD: re-transmitting Lex0: "lex priority-group command
LEX-RCMD: lex_setup_and_send called with invalid parameter
LEX-RCMD: bind occurred on shutdown LEX interface
LEX-RCMD: Serial0- No free Lex interface found with negotiated MAC address 0000.0c00.d8db
LEX-RCMD: No active Lex interface found for unbind
The following output indicates that a LAN Extender remote command packet was received on a serial
interface that is not bound to a LAN Extender interface:
LEX-RCMD: "shutdown" command received on unbound serial interface- Serial0
This message can occur for any of the LAN Extender remote commands. Possible causes of this message
are as follows:
FLEX state machine software error
Serial line momentarily goes down, which is detected by the host but not by FLEX
The following output indicates that a LAN Extender remote command response has been received. The
hexadecimal values are for internal use only.
LEX-RCMD: Lex0: "inventory" command received
Rcvd rcmd: FF 03 80 41 41 13 00 1A 8A 00 00 16 01 FF 00 00
Rcvd rcmd: 00 02 00 00 07 5B CD 15 00 00 0C 01 15 26

DB-1418 May 2008
Debug Commands
debug lex rcmd
The following output indicates that when the host router originates a LAN Extender remote command
to FLEX, it generates an 8-bit identifier that is used to associate a command with its corresponding
response:
LEX-RCMD: ACK or response received on Serial0 without a corresponding ID
This message could be displayed for any of the following reasons:

FLEX was busy at the time that the command arrived and could not send an immediate response.
The command timed out on the host router and then FLEX finally sent the response.
Transmission error.
Software error.
Possible responses to Config-Request are Config-ACK, Config-NAK, and Config-Rej. The following
output shows that some of the options in the Config-Request are not recognizable or are not acceptable
to FLEX due to transmission errors or software errors:
LEX-RCMD: REJ received
The following output shows that a LAN Extender remote command response was received but that the
CODE field in the header was incorrect:
LEX-RCMD: illegal CODE field received in header: <number>
The following output indicates that a LAN Extender remote command response was received but that it
had an incorrect length field. This message can occur for any of the LAN Extender remote commands.
LEX-RCMD: illegal length for Lex0: "lex input-type-list"
The following output shows that a host router was about to send a remote command when the serial link
went down:
LEX-RCMD: Lex0 is not bound to a serial interface
The following output shows that the serial encapsulation routine of the interface failed to encapsulate
the remote command datagram because the LEX-NCP was not in the OPEN state. Due to the way the
PPP state machine is implemented, it is normal to see a single encapsulation failure for each remote
command that gets sent at bind time.
LEX-RCMD: encapsulation failure
The following output shows that the timer expired for the given remote command without having
received a response from the FLEX device. This message can occur for any of the LAN Extender remote
commands.
LEX-RCMD: timeout for Lex0: "lex priority-group" command
This message could be displayed for any of the following reasons:

FLEX too busy to respond
Transmission failure
Software error
The following output indicates that the host is resending the remote command after a timeout:
LEX-RCMD: re-transmitting Lex0: lex priority-group command
The following output indicates that an illegal parameter was passed to the lex_setup_and_send routine.
This message could be displayed due to a host software error.
LEX-RCMD: lex_setup_and_send called with invalid parameter

May 2008 DB-1419
Debug Commands
debug lex rcmd
The following output is informational and shows when a bind occurs on a shutdown interface:
LEX-RCMD: bind occurred on shutdown LEX interface
The following output shows that the LEX-NCP reached the open state and a bind operation was
attempted with the FLEX's MAC address, but no free LAN Extender interfaces were found that were
configured with that MAC address. This output can occur when the network administrator does not
configure a LAN Extender interface with the correct MAC address.
LEX-RCMD: Serial0- No free Lex interface found with negotiated MAC address 0000.0c00.d8db
The following output shows that the serial line that was bound to the LAN Extender interface went down
and the unbind routine was called, but when the list of active LAN Extender interfaces was searched, the
LAN Extender interface corresponding to the serial interface was not found. This output usually occurs
because of a host software error.
LEX-RCMD: No active Lex interface found for unbind

DB-1420 May 2008
Debug Commands
debug license
debug license
To enable controlled Cisco IOS software license debugging activity on a device, use the debug license
debug license {agent {all | error} | core {all | error | event} | errors | events | ipc}
Syntax Description agent Debugs license agent information.

all Debugs all license core messages when used with the core keyword and all
license agent messages when used with the agent keyword.
error Debugs only license core error messages when used with the core keyword
and only license agent error messages when used with the agent keyword.
core Debugs messages from a license core module.
event Debugs only license core event messages.
errors Debugs license warnings and errors.
events Debugs license event messages.
ipc Debugs license interprocess communication (IPC) messages.
Command Default Debugging activity does not occur.

12.2(35)SE2 This command was introduced.
Usage Guidelines Use this command to help troubleshoot issues with licenses on a device.
Examples The following example shows how to enable debugging for license warnings and errors on a router:
Router# debug license errors
The following example shows how to enable debugging for all license agent information on a switch:
Switch# debug license agent all
license agent app https[0x43FBC7C]: urlhook function

license agent app https[0x43FBC7C]: https action function
LIC_AGENT:Processing XML message
<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://www.w3.org/2003/05/soap-envelope">
<SOAP:Header>

May 2008 DB-1421
Debug Commands
debug license
<clm:Header version="1.0" xmlns:clm="http://www.cisco.com/clm">

<clm:Time>2003-04-23T20:27:19.827Z</clm:Time>
</clm:Header>
</SOAP:Header>
<SOAP:Body>
<lica:request xmlns:lica="http://www.cisco.com/clm">
<lica:installRequest>
<lica:license encoding="BASE64">
PENJU0NPX1dUX0FSVElGQUNUUyB2ZXJzaW9uPSIxLjAiPjxDSVNDT19XVF9MSUNFTlNFIHZlcnNp
b249IjEuMCI+PEZFQVRVUkVfTkFNRT5pcGJhc2U8L0ZFQVRVUkVfTkFNRT48RkVBVFVSRV9WRVJT
SU9OPjEuMDwvRkVBVFVSRV9WRVJTSU9OPjxVREk+PFBJRD5CVUxMU0VZRTI0PC9QSUQ+PFNOPkNB
VDEwMDZSMEU4PC9TTj48L1VEST48U09VUkNFPkNpc2NvIEhRPC9TT1VSQ0U+PENSRUFURV9EQVRF
PjIwMDYtMTEtMjJUMDA6MzM6NTA8L0NSRUFURV9EQVRFPjxMSUNFTlNFX0xJTkVfSEFTSCBoYXNo
QWxnbz0iU0hBMSI+NDJiNFVWWFpOd3pJK0ZNdEV6QlNZSDRWdzFFPTwvTElDRU5TRV9MSU5FX0hB
U0g+PFRZUEU+UkVHVUxBUjwvVFlQRT48TElDRU5TRV9MSU5FPjwhW0NEQVRBWzExIGlwYmFzZSAx
LjAgTE9ORyBOT1JNQUwgU1RBTkRBTE9ORSBFWENMIElORklOSVRFX0tFWVMgSU5GSU5JVEVfS0VZ
UyBORVZFUiBORVZFUiBOaUwgU0xNX0NPREUgQ0xfTkRfTENLIE5pTCAqMVZBUlY5WlJESzREOU5U
NDAwIE5pTCBOaUwgTmlMIDVfTUlOUyA8VURJPjxQSUQ+QlVMTFNFWUUyNDwvUElEPjxTTj5DQVQx
MDA2UjBFODwvU04+PC9VREk+IGUxWW8wS1U2VnJLOnBJZXRib1dJVkEyZlVaVGdieUlEaklHWERR
VXc3dkxOYWlXRzZ0dUJOMG5lTXpKaHpzQ2tMN1l3TWFxS2paem05YW5FbVJHUUVPTHlDdmRVZksw
QmNLN0pPcnZsUkw0VjMyJDxXTEM+QVFFQklRQUIvLy9GbS8vWDkybThNb0NOZkVMSHJiVzRjWDFM
ZGNpdDNMVU5GWlV1OWppT0phcXB5Q2N6TTFpaUlKbVE3NEd5WHJFY3F2UGlBbVdTYUVtVVQ1NnJz
dGs2Z3ZtaitFUUtSZkQ5QTBpbWUxY3pyZEt4ZklMVDBMYVhUNDE2bndtZnA5MlR5YTZ2SVE0Rm5s
QmRxSjFzTXpYZVNxOFBtVmNUVTlBNG85aGlsOXZLdXI4TjlGODg1RDlHVkYwYkpIY2lUNU09PC9X
TEM+XV0+PC9MSUNFTlNFX0xJTkU+PFVTRVJfTU9ESUZJQUJMRV9DT01NRU5UIGZpZWxkUmVzdHJp
Y3Rpb25zPSJNYXggOTkgQVNDSUkgY2hhcmFjdGVycyBpbiBsZW5ndGguIj48L1VTRVJfTU9ESUZJ
QUJMRV9DT01NRU5UPjwvQ0lTQ09fV1RfTElDRU5TRT48L0NJU0NPX1dUX0FSVElGQUNUUz4=
</lica:license>
</lica:installRequest>
</lica:request>
</SOAP:Body>
</SOAP:Envelope>
LIC_AGENT: XML received opcode(1)

LIC_AGENT: License ipbase
%IOS_LICENSE_IMAGE_APPLICATION-6-LICENSE_LEVEL: Next reboot level = ipbase and License =
ipbase
LIC_AGENT: Notification Event type = 1 License Installed
LIC_AGENT: Notification Event type = 13 License Annotate

DB-1422 May 2008
Debug Commands
debug link monitor
debug link monitor

To display the statistics of the executing process, use the debug link monitor command in privileged
debug link monitor
no debug link monitor

Usage Guidelines This command is used to display the statistics, which are used for debugging the status of the various
conditions occurred during execution of the monitoring process.
Examples The following example enables link monitoring statistics:

Router# debug link monitor
%DEBUG-ENABLED Error Rate Link Monitor
The following example disables link monitoring statistics:

Router# no debug link monitor
%DEBUG-DISABLED Error Rate Link Monitor

debug all Enables debugging for link monitoring.
no debug all Disables debugging for link monitoring.
clear counters Clears show interface counters on all interfaces.
show link monitor debug Show link monitor error statistics.

May 2008 DB-1423
Debug Commands
debug list
debug list
To filter debugging information on a per-interface or per-access list basis, use the debug list command
debug list [list] [interface]
no debug list [list] [interface]
Syntax Description list (Optional) An access list number in the range from 1100 to 1199.
interface (Optional) The interface type. Allowed values are the following:
channelIBM Channel interface
ethernetIEEE 802.3
fddiANSI X3T9.5
nullNull interface
serialSerial
tokenringIEEE 802.5
tunnelTunnel interface
Usage Guidelines The debug list command is used with other debug commands for specific protocols and interfaces to
filter the amount of debug information that is displayed. In particular, this command is designed to filter
specific physical unit (PU) output from bridging protocols. The debug list command is supported with
the following commands:
debug arp
debug llc2 errors
debug llc2 packets
debug llc2 state
debug rif
debug sdlc
debug token ring
Note All debug commands that support access list filtering use access lists in the range from 1100 to 1199.
The access list numbers shown in the examples are merely samples of valid numbers.

DB-1424 May 2008
Debug Commands
debug list
Examples To use the debug list command on only the first of several Logical Link Control, type 2 (LLC2)
connections, use the show llc2 command to display the active connections:
Router# show llc2
SdllcVirtualRing2008 DTE: 4000.2222.22c7 4000.1111.111c 04 04 state NORMAL

SdllcVirtualRing2008 DTE: 4000.2222.22c8 4000.1111.1120 04 04 state NORMAL
SdllcVirtualRing2008 DTE: 4000.2222.22c1 4000.1111.1104 04 04 state NORMAL
Next, configure an extended bridging access list, numbered 1103, for the connection you want to filter:
access-list 1103 permit 4000.1111.111c 0000.0000.0000 4000.2222.22c7 0000.0000.0000 0xC 2
eq 0x404
The convention for the LLC debug list command filtering is to use dmac = 6 bytes, smac = 6 bytes,
dsap_offset = 12, and ssap_offset = 13.
Finally, you invoke the following debug commands:
Router# debug llc2 packet
LLC2 Packets debugging is on

for access list: 1103
To use the debug list command for Synchronous Data Link Control (SDLC) connections, with the
exception of address 04, create access list 1102 to deny the specific address and permit all others:
access-list 1102 deny 0000.0000.0000 0000.0000.0000 0000.0000.0000 0000.0000.0000 0xC 1 eq
0x4
access-list 1102 permit 0000.0000.0000 0000.0000.0000 0000.0000.0000 0000.0000.0000
The convention is to use dmac = 0.0.0, smac = 0.0.0, and sdlc_frame_offset = 12.
Invoke the following debug commands:
Router# debug sdlc
SDLC link debugging is on

To enable SDLC debugging (or debugging for any of the other supported protocols) for a specific
interface rather than for all interfaces on a router, use the following commands:
Router# debug list serial 0
Router# debug sdlc
SDLC link debugging is on

for interface: Serial0
To enable Token Ring debugging between two MAC address, 0000.3018.4acd and 0000.30e0.8250,
configure an extended bridging access list 1106:
access-list 1106 permit 0000.3018.4acd 8000.0000.0000 0000.30e0.8250 8000.0000.0000
access-list 1106 permit 0000.30e0.8250 8000.0000.0000 0000.3018.4acd 8000.0000.0000

May 2008 DB-1425
Debug Commands
debug list

Router# debug token ring
Token Ring Interface debugging is on

To enable routing information field (RIF) debugging for a single MAC address, configure an access list
1109:
access-list 1109 permit permit 0000.0000.0000 ffff.ffff.ffff 4000.2222.22c6 0000.0000.0000

Router# debug rif
RIF update debugging is on


debug llc2 errors Displays LLC2 protocol error conditions or unexpected input.
debug llc2 packet Displays all input and output from the LLC2 protocol stack.
debug llc2 state Displays state transitions of the LLC2 protocol.
debug rif Displays information on entries entering and leaving the RIF cache.
debug rtsp Displays information on SDLC frames received and sent by any router serial
interface involved in supporting SDLC end station functions.
debug token ring Displays messages about Token Ring interface activity.

DB-1426 May 2008
Debug Commands
debug llc2 dynwind
debug llc2 dynwind

To display changes to the dynamic window over Frame Relay, use the debug llc2 dynwind command in
debug llc2 dynwind
no debug llc2 dynwind
Examples The following is sample output from the debug llc2 dynwind command:
Router# debug llc2 dynwind
LLC2/DW: BECN received! event REC_I_CMD, Window size reduced to 4

LLC2/DW: 1 consecutive I-frame(s) received without BECN
LLC2/DW: Current working window size is 5
In this example, the router receives a backward explicit congestion notification (BECN) and reduces the
window size to 4. After receiving five consecutive I frames without a BECN, the router increases the
window size to 5.


May 2008 DB-1427
Debug Commands
debug llc2 errors
debug llc2 errors

To display Logical Link Control, type 2 (LLC2) protocol error conditions or unexpected input, use the
debug llc2 errors command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
debug llc2 errors
no debug llc2 errors
Examples The following is sample output from the debug llc2 errors command from a router ignoring an
incorrectly configured device:
Router# debug llc2 errors
LLC: admstate: 4000.1014.0001 0000.0000.0000 04 04 REC_RR_RSP

Each line of output contains the remote MAC address, the local MAC address, the remote service access
point (SAP), and the local SAP. In this example, the router receives unsolicited RR frames marked as
responses.

debug list Filters debugging information on a per-interface or per-access list basis.
debug llc2 dynwind Displays changes to the dynamic window over Frame Relay.

DB-1428 May 2008
Debug Commands
debug llc2 packet
debug llc2 packet

To display all input and output from the Logical Link Control, type 2 (LLC2) protocol stack, use the
debug llc2 packet command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug llc2 packet
no debug llc2 packet
Usage Guidelines This command also displays information about some error conditions as well as internal interactions
between the Common Link Services (CLS) layer and the LLC2 layer.
Examples The following is sample output from the debug llc2 packet command from the router sending ping data
back and forth to another router:
Router# debug llc2 packet
LLC: llc2_input
401E54F0: 10400000 .@..
401E5500: 303A90CF 0006F4E1 2A200404 012B5E 0:.O..ta* ...+
LLC: i REC_RR_CMD N(R)=21 p/f=1
LLC: 0006.f4e1.2a20 0000.303a.90cf 04 04 NORMAL REC_RR_CMD (3)
LLC (rs): 0006.f4e1.2a20 0000.303a.90cf 04 04 REC_RR_CMD N(R)=42
LLC: 0006.f4e1.2a20 0000.303a.90cf 04 04 txmt RR_RSP N(R)=20 p/f=1
LLC: llc_sendframe
401E5610: 0040 0006F4E1 2A200000 .@..ta* ..
401E5620: 303A90CF 04050129 00 N 0:.O...). 2012
LLC: llc_sendframe
4022E3A0: 0040 0006F4E1 .@..ta
4022E3B0: 2A200000 303A90CF 04042A28 2C000202 * ..0:.O..*(,...
4022E3C0: 00050B90 A02E0502 FF0003D1 004006C1 .... ......Q.@.A
4022E3D0: D7C9D5C 0.128
C400130A C1D7D7D5 4BD5F2F0 WIUGD...AWWUKUrp
4022E3E0: F1F30000 011A6071 00010860 D7027000 qs....`q...`W.p.
4022E3F0: 00003B00 1112FF01 03000243 6973636F ..;........Cisco
4022E400: 20494F53 69 IOSi
LLC: 0006.f4e1.2a20 0000.303a.90cf 04 04 txmt I N(S)=21 N(R)=20 p/f=0 size=90
LLC: llc2_input
401E5620: 10400000 303A90CF .@..0:.O
401E5630: 0006F4E1 2A200404 282C2C00 02020004 ..ta* ..(,,.....
401E5640: 03902000 1112FF01 03000243 6973636F .. ........Cisco
401E5650: 20494F53 A0 IOS
LLC: i REC_I_CMD N(R)=22 N(S)=20 V(R)=20 p/f=0
LLC: 0006.f4e1.2a20 0000.303a.90cf 04 04 NORMAL REC_I_CMD (1)
LLC (rs): 0006.f4e1.2a20 0000.303a.90cf 04 04 REC_I_CMD N(S)=20 V(R)=20
LLC (rs): 0006.f4e1.2a20 0000.303a.90cf 04 04 REC_I_CMD N(R)=44
LLC: INFO: 0006.f4e1.2a20 0000.303a.90cf 04 04 v(r) 20

May 2008 DB-1429
Debug Commands
debug llc2 packet
The first three lines indicate that the router has received some input from the link:
LLC: llc2_input
401E54F0: 10400000 .@..
401E5500: 303A90CF 0006F4E1 2A200404 012B5E 0:.O..ta* ...+
The next line indicates that this input was an RR command with the poll bit set. The other router has
received sequence number 21 and is waiting for the final bit.
LLC: i REC_RR_CMD N(R)=21 p/f=1
The next two lines contain the MAC addresses of the sender and receiver, and the state of the router when
it received this frame:
LLC: 0006.f4e1.2a20 0000.303a.90cf 04 04 NORMAL REC_RR_CMD (3)
LLC (rs): 0006.f4e1.2a20 0000.303a.90cf 04 04 REC_RR_CMD N(R)=42
The next four lines indicate that the router is sending a response with the final bit set:
LLC: 0006.f4e1.2a20 0000.303a.90cf 04 04 txmt RR_RSP N(R)=20 p/f=1
LLC: llc_sendframe
401E5610: 0040 0006F4E1 2A200000 .@..ta* ..
401E5620: 303A90CF 04050129 00 N 0:.O...). 2012


DB-1430 May 2008
Debug Commands
debug llc2 state
debug llc2 state

To display state transitions of the Logical Link Control, type 2 (LLC2) protocol, use the debug llc2 state
debug llc2 state
no debug llc2 state
Usage Guidelines Refer to the ISO/IEC standard 8802-2 for definitions and explanations of debug llc2 state command
output.
Examples The following is sample output from the debug llc2 state command when a router disables and enables
an interface:
Router# debug llc2 state
LLC (stsw): 0006.f4e1.2a20 0000.303a.90cf 04 04, NORMAL -> AWAIT (P_TIMER_EXP)

LLC(rs): 0006.f4e1.2a20 0000.303a.90cf 04 04, AWAIT -> D_CONN (P_TIMER_EXP)
LLC: cleanup 0006.f4e1.2a20 0000.303a.90cf 04 04, UNKNOWN (17)
LLC (stsw): 0006.f4e1.2a20 0000.303a.90cf 04 04, ADM -> SETUP (CONN_REQ)
LLC: normalstate: set_local_busy 0006.f4e1.2a20 0000.303a.90cf 04 04
LLC (stsw): 0006.f4e1.2a20 0000.303a.90cf 04 04, NORMAL -> BUSY (SET_LOCAL_BUSY)
LLC: Connection established: 0006.f4e1.2a20 0000.303a.90cf 04 04, success
LLC (stsw): 0006.f4e1.2a20 0000.303a.90cf 04 04, SETUP -> BUSY (SET_LOCAL_BUSY)
LLC: busystate: 0006.f4e1.2a20 0000.303a.90cf 04 04 local busy cleared
LLC (stsw): 0006.f4e1.2a20 0000.303a.90cf 04 04, BUSY -> NORMAL (CLEAR_LOCAL_BUSY)


May 2008 DB-1431
Debug Commands
debug lnm events
debug lnm events

To display any unusual events that occur on a Token Ring network, use the debug lnm events command
debug lnm events
no debug lnm events
Usage Guidelines Unusual events include stations reporting errors or error thresholds being exceeded.
Examples The following is sample output from the debug lnm events command:
Router# debug lnm events
IBMNM3: Adding 0000.3001.1166 to error list

IBMNM3: Station 0000.3001.1166 going into preweight condition
IBMNM3: Station 0000.3001.1166 going into weight condition
IBMNM3: Removing 0000.3001.1166 from error list
LANMGR0: Beaconing is present on the ring
LANMGR0: Ring is no longer beaconing
IBMNM3: Beaconing, Postmortem Started
IBMNM3: Beaconing, heard from 0000.3000.1234
IBMNM3: Beaconing, Postmortem Next Stage
IBMNM3: Beaconing, Postmortem Finished
The following message indicates that station 0000.3001.1166 reported errors and has been added to the
list of stations reporting errors. This station is located on Ring 3.
IBMNM3: Adding 0000.3001.1166 to error list
The following message indicates that station 0000.3001.1166 has passed the early warning threshold
for error counts:
IBMNM3: Station 0000.3001.1166 going into preweight condition
The following message indicates that station 0000.3001.1166 is experiencing a severe number of errors:
IBMNM3: Station 0000.3001.1166 going into weight condition
The following message indicates that the error counts for station 0000.3001.1166 have all decayed to
zero, so this station is being removed from the list of stations that have reported errors:
IBMNM3: Removing 0000.3001.1166 from error list
The following message indicates that Ring 0 has entered failure mode. This ring number is assigned
internally.
LANMGR0: Beaconing is present on the ring

DB-1432 May 2008
Debug Commands
debug lnm events
The following message indicates that Ring 0 is no longer in failure mode. This ring number is assigned
internally.
LANMGR0: Ring is no longer beaconing
The following message indicates that the router is beginning its attempt to determine whether any
stations left the ring during the automatic recovery process for the last beaconing failure. The router
attempts to contact stations that were part of the fault domain to detect whether they are still operating
on the ring.
IBMNM3: Beaconing, Postmortem Started
The following message indicates that the router is attempting to determine whether any stations left the
ring during the automatic recovery process for the last beaconing failure. It received a response from
station 0000.3000.1234, one of the two stations in the fault domain.
IBMNM3: Beaconing, heard from 0000.3000.1234
The following message indicates that the router is attempting to determine whether any stations left the
ring during the automatic recovery process for the last beaconing failure. It is initiating another attempt
to contact the two stations in the fault domain.
IBMNM3: Beaconing, Postmortem Next Stage
The following message indicates that the router has attempted to determine whether any stations left the
ring during the automatic recovery process for the last beaconing failure. It has successfully heard back
from both stations that were part of the fault domain.
IBMNM3: Beaconing, Postmortem Finished
Explanations follow for other messages that the debug lnm events command can generate.
The following message indicates that the router is out of memory:
LANMGR: memory request failed, find_or_build_station()
The following message indicates that Ring 3 is experiencing a large number of errors that cannot be
attributed to any individual station:
IBMNM3: Non-isolating error threshold exceeded
The following message indicates that a station (or stations) on Ring 3 is receiving frames faster than they
can be processed:
IBMNM3: Adapters experiencing congestion
The following message indicates that the beaconing has lasted for over 1 minute and is considered a
permanent error:
IBMNM3: Beaconing, permanent
The following message indicates that the beaconing lasted for less than 1 minute. The router is
attempting to determine whether either station in the fault domain left the ring.
IBMNM: Beaconing, Destination Started
In the preceding line of output, the following can replace Started: Next State, Finished, Timed
out, and Cannot find station n.

May 2008 DB-1433
Debug Commands
debug lnm llc
debug lnm llc

To display all communication between the router/bridge and the LAN Network Managers (LNMs) that
have connections to it, use the debug lnm llc command in privileged EXEC mode. To disable debugging
debug lnm llc
no debug lnm llc
Usage Guidelines One line is displayed for each message sent or received.
Examples The following is sample output from the debug lnm llc command:
Router# debug lnm llc
IBMNM: Received LRM Set Reporting Point frame from 1000.5ade.0d8a.

IBMNM: found bridge: 001-2-00A, addresses: 0000.3040.a630 4000.3040.a630
IBMNM: Opening connection to 1000.5ade.0d8a on TokenRing0
IBMNM: Sending LRM LAN Manager Accepted to 1000.5ade.0d8a on link 0.
IBMNM: sending LRM New Reporting Link Established to 1000.5a79.dbf8 on link 1.
IBMNM: Determining new controlling LNM
IBMNM: Sending Report LAN Manager Control Shift to 1000.5ade.0d8a on link 0.
IBMNM: Sending Report LAN Manager Control Shift to 1000.5a79.dbf8 on link 1.
IBMNM: Bridge 001-2-00A received Request Bridge Status from 1000.5ade.0d8a.

IBMNM: Sending Report Bridge Status to 1000.5ade.0d8a on link 0.
IBMNM: Bridge 001-2-00A received Request REM Status from 1000.5ade.0d8a.
IBMNM: Sending Report REM Status to 1000.5ade.0d8a on link 0.
IBMNM: Bridge 001-2-00A received Set Bridge Parameters from 1000.5ade.0d8a.
IBMNM: Sending Bridge Parameters Set to 1000.5ade.0d8a on link 0.
IBMNM: sending Bridge Params Changed Notification to 1000.5a79.dbf8 on link 1.
IBMNM: Bridge 001-2-00A received Set REM Parameters from 1000.5ade.0d8a.
IBMNM: Sending REM Parameters Set to 1000.5ade.0d8a on link 0.
IBMNM: sending REM Parameters Changed Notification to 1000.5a79.dbf8 on link 1.
IBMNM: Bridge 001-2-00A received Set REM Parameters from 1000.5ade.0d8a.
IBMNM: Sending REM Parameters Set to 1000.5ade.0d8a on link 0.
IBMNM: sending REM Parameters Changed Notification to 1000.5a79.dbf8 on link 1.
IBMNM: Received LRM Set Reporting Point frame from 1000.5ade.0d8a.
IBMNM: found bridge: 001-1-00A, addresses: 0000.3080.2d79 4000.3080.2d7
As the output indicates, the debug lnm llc command output can vary somewhat in format.

DB-1434 May 2008
Debug Commands
debug lnm llc
Table 208 debug lnm llc Field Descriptions
Field Description
IBMNM: Displays LLC-level debugging information.
Received Router received a frame. The other possible value is Sending, to
indicate that the router is sending a frame.
LRM The function of the LLC-level software that is communicating as
follows:
CRSConfiguration Report Server
LBSLAN Bridge Server
LRMLAN Reporting Manager
REMRing Error Monitor
RPSRing Parameter Server
RSRing Station

May 2008 DB-1435
Debug Commands
debug lnm llc
Table 208 debug lnm llc Field Descriptions (continued)
Field Description
Set Reporting Point Name of the specific frame that the router sent or received. Possible
values include the following:
Bridge Counter Report
Bridge Parameters Changed Notification
Bridge Parameters Set
CRS Remove Ring Station
CRS Report NAUN Change
CRS Report Station Information
CRS Request Station Information
CRS Ring Station Removed
LRM LAN Manager Accepted
LRM Set Reporting Point
New Reporting Link Established
REM Forward MAC Frame
REM Parameters Changed Notification
REM Parameters Set
Report Bridge Status
Report LAN Manager Control Shift
Report REM Status
Request Bridge Status
Request REM Status
Set Bridge Parameters
Set REM Parameters
from 1000.5ade.0d8a If the router has received the frame, this address is the source address
of the frame. If the router is sending the frame, this address is the
destination address of the frame.
The following message indicates that the lookup for the bridge with which the LAN Manager was
requesting to communicate was successful:
IBMNM: found bridge: 001-2-00A, addresses: 0000.3040.a630 4000.3040.a630
The following message indicates that the connection is being opened:

IBMNM: Opening connection to 1000.5ade.0d8a on TokenRing0

DB-1436 May 2008
Debug Commands
debug lnm llc
The following message indicates that a LAN Manager has connected or disconnected from an internal
bridge and that the router computes which LAN Manager is allowed to change parameters:
IBMNM: Determining new controlling LNM
The following line of output indicates which bridge in the router is the destination for the frame:
IBMNM: Bridge 001-2-00A received Request Bridge Status from 1000.5ade.0d8a.

May 2008 DB-1437
Debug Commands
debug lnm mac
debug lnm mac

To display all management communication between the router/bridge and all stations on the local Token
Rings, use the debug lnm mac command in privileged EXEC mode. To disable debugging output, use
debug lnm mac
no debug lnm mac
Usage Guidelines One line is displayed for each message sent or received.
Examples The following is sample output from the debug lnm mac command:
Router# debug lnm mac
LANMGR0: RS received request address from 4000.3040.a670.

LANMGR0: RS sending report address to 4000.3040.a670.
LANMGR0: RS received request state from 4000.3040.a670.
LANMGR0: RS sending report state to 4000.3040.a670.
LANMGR0: RS received request attachments from 4000.3040.a670.
LANMGR0: RS sending report attachments to 4000.3040.a670.
LANMGR2: RS received ring purge from 0000.3040.a630.
LANMGR2: CRS received report NAUN change from 0000.3040.a630.
LANMGR2: RS start watching ring poll.
LANMGR0: CRS received report NAUN change from 0000.3040.a630.
LANMGR2: REM received report soft error from 0000.3040.a630.
LANMGR0: REM received report soft error from 0000.3040.a630.
LANMGR2: RS received AMP from 0000.3040.a630.
LANMGR2: RS received SMP from 0000.3080.2d79.
LANMGR2: CRS received report NAUN change from 1000.5ade.0d8a.
LANMGR0: RS received AMP from 0000.3040.a630.
LANMGR0: RS received SMP from 0000.3080.2d79.
LANMGR0: CRS received report NAUN change from 1000.5ade.0d8a.
LANMGR2: RS received SMP from 1000.5ade.0d8a.
LANMGR2: RPS received request initialization from 1000.5ade.0d8a.
LANMGR2: RPS sending initialize station to 1000.5ade.0d8a.

DB-1438 May 2008
Debug Commands
debug lnm mac
Table 209 debug lnm mac Field Descriptions
Field Description
LANMGR0: Indicates that this line of output displays MAC-level debugging
information. 0 indicates the number of the Token Ring interface
associated with this line of debugging output.
RS Indicates which function of the MAC-level software is communicating
as follows:
CRSConfiguration Report Server
REMRing Error Monitor
RPSRing Parameter Server
RSRing Station
received Indicates that the router received a frame. The other possible value is
sending, to indicate that the router is sending a frame.
request address Indicates the name of the specific frame that the router sent or received.
Possible values include the following:
AMP
initialize station
report address
report attachments
report nearest active upstream neighbor (NAUN) change
report soft error
report state
request address
request attachments
request initialization
request state
ring purge
SMP
from 4000.3040.a670 Indicates the source address of the frame, if the router has received the
frame. If the router is sending the frame, this address is the destination
address of the frame.
As the output indicates, all debug lnm mac command messages follow the format described in Table 209
except the following:
LANMGR2: RS start watching ring poll
LANMGR2: RS stop watching ring poll
These messages indicate that the router starts and stops receiving AMP and SMP frames. These frames
are used to build a current picture of which stations are on the ring.

May 2008 DB-1439
Debug Commands
debug local-ack state

To display the new and the old state conditions whenever there is a state change in the local
acknowledgment state machine, use the debug local-ack state command in privileged EXEC mode. To
no debug local-ack state
Examples The following is sample output from the debug local-ack state command:
Router# debug local-ack state
LACK_STATE: 2370300, hashp 2AE628, old state = disconn, new state = awaiting
LLC2 open to finish
LACK_STATE: 2370304, hashp 2AE628, old state = awaiting LLC2 open to finish,
new state = connected
LACK_STATE: 2373816, hashp 2AE628, old state = connected, new state = disconnected
LLC2 open to finish
LACK_STATE: 2490132, hashp 2AE628, old state = connected, new state = awaiting
linkdown response
LACK_STATE: 2490140, hashp 2AE628, old state = awaiting linkdown response,
new state = disconnected
LLC2 open to finish
Table 210 debug local-ack state Field Descriptions
Field Description
LACK_STATE: Indicates that this packet describes a state change in the local
acknowledgment state machine.
2370300 System clock.
hashp 2AE628 Internal control block pointer used by technical support staff for
debugging purposes.

DB-1440 May 2008
Debug Commands
Table 210 debug local-ack state Field Descriptions (continued)
Field Description
old state = disconn Old state condition in the local acknowledgment state machine.
Possible values include the following:
Disconn (disconnected)
awaiting LLC2 open to finish
connected
awaiting linkdown response
new state = awaiting LLC2 New state condition in the local acknowledgment state machine.
open to finish Possible values include the following:
Disconn (disconnected)
awaiting LLC2 open to finish
connected
awaiting linkdown response

May 2008 DB-1441
Debug Commands
debug management event

To monitor the activities of the Event MIB in real time on your routing device, use the debug
management event command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
no debug management event

Usage Guidelines The debug management event command prints messages to the screen whenever the Event MIB
evaluates a specified trigger. These messages are given in real-time, and are intended to be used by
technical support engineers for troubleshooting purposes. Definitions for the OID (object identifier)
fields can be found in the EVENT-MIB.my file, available for download from the Cisco MIB website on
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
Examples The following is sample output from the debug management event command:
Router# debug management event
Event Process Bool: Owner aseem, Trigger 01

Event Bool process: invoke event
Event Bool process: no wildcarding
Event: OID ifEntry.10.3
Event getValue abs: 69847284
Event Bool process: Trigger Fired !
mteSetNotifyObjects:
Event execOnFiring: sending notification
Event add_objects: Owner , Trigger
Event add_objects: Owner aseem, Trigger sethi
Event Found Owner: aseem
Event Found Name: sethi

DB-1442 May 2008
Debug Commands

Event: sending trap with 7 OIDs
Event: OID mteHotTrigger.0
Event: OID mteHotTargetName.0
Event: OID mteHotContextName.0
Event: OID mteHotValue.0
Event mteDoSets: setting oid
Event mteDoSets: non-wildcarded oid
Event: OID ciscoSyslogMIB.1.2.1.0
Event Thresh Process: Owner aseem, Trigger 01
Event Thresh process: invoke rising event
Event Thresh process: invoke falling event
Event Thresh process: no wildcarding
Event Existence Process: Owner aseem, Trigger 01
Event Exist process: invoke event
Event Exist process: no wildcarding
Event Check ExistTrigger for Absent
Event Check ExistTrigger for Changed
Router# no debug management event

show management event Displays the SNMP Event values that have been configured on
your routing device through the use of the Event MIB.

May 2008 DB-1443
Debug Commands
debug mdss
debug mdss
To display the run-time errors and sequence of events for the multicast distributed switching services
(MDSS), use the debug mdss command in privileged EXEC mode. To disable debugging output, use the
debug mdss {all | error | event}
no debug mdss {all | error | event}
Syntax Description all Displays both errors and sequence of events for MDSS.
error Displays the run-time errors for MDSS.
event Displays the run-time sequence of events for MDSS.

Examples The following example shows output using the debug mdss command with the all keyword:
Router# debug mdss all
mdss all debugging is on
Router# clear ip mroute *
Router#
01:31:03: MDSS: got MDFS_CLEARALL
01:31:03: MDSS: --> mdss_flush_all_sc
01:31:03: MDSS: enqueue a FE_GLOBAL_DELETE
01:31:03: MDSS: got MDFS_MROUTE_ADD for (0.0.0.0, 224.0.1.40)
01:31:03: MDSS: --> mdss_free_scmdb_cache
01:31:03: MDSS: got a MDFS_MIDB_ADD for (192.1.21.6, 239.255.158.197,
Vlan21) +Vlan22
01:31:03: MDSS: -- mdss_add_oif
01:31:03: MDSS: enqueue a FE_OIF_ADD (192.1.21.6, 239.255.158.197,
Vlan21) +Vlan22
01:31:03: MDSS: mdb (192.1.21.6, 239.255.158.197) fast_flags |
MCACHE_MTU

DB-1444 May 2008
Debug Commands
debug mdss

Vlan21) +Vlan23
Vlan21) +Vlan23
MCACHE_MTU
Vlan21) +Vlan24
Vlan21) +Vlan24
MCACHE_MTU
Vlan21) +Vlan25
Vlan21) +Vlan25
MCACHE_MTU
Vlan21) +Vlan26

Vlan21) +Vlan26
MCACHE_MTU
01:31:03: MDSS: got a MDFS_MIDB_ADD for (192.1.21.6, 239.255.158.197,u
Vlan21) +Vlan27

debug mls rp ip multicast Displays information about MLSP.

May 2008 DB-1445
Debug Commands
debug media resource provisioning all

To display debugging messages related to all media resource provisioning, use the debug media
resource provisioning all command in privileged EXEC mode. To disable debugging output, use the no
no debug media resource provisioning all

Examples The following is sample output from the debug media resource provisioning all command:
Router# debug media resource provisioning all
.
.
.
Media resource provisioning all debugging is on.
Disabling profile will disconnect active CONFERENCING calls,
do you want to continue ? [yes/no]
*Jul 8 18:46:36: rpm_if_profile_exist ::profile id 10, service TRANSCODING
*Jul 8 18:46:36: rpm_get_rscid_profile_info Profile with profile id :10, service
:TRANSCODING does not exist
*Jul 8 18:46:36: rpm_if_profile_exist ::profile id 10, service CONFERENCING
*Jul 8 18:46:36: rpm_if_profile_exist ::profile id 10, service TRANSCODING
*Jul 8 18:46:36: rpm_get_rscid_profile_info Profile with profile id :10, service
:TRANSCODING does not exist
*Jul 8 18:46:36: rpm_if_profile_exist ::profile id 10, service CONFERENCING
Must be yes or no
Router(config-dspfarm-profile)#
Router(config-dspfarm-profile)# no shutdown
*Jul 8 18:46:42: rpm_user_enable_profile ::profile id 10, service CONFERENCING
*Jul 8 18:46:44:%DSPRM-5-UPDOWN:DSP 10 in slot 1, changed state to up
*Jul 8 18:46:44: rpm_rscprv_update ::provider_id 1 rsc_id 2 rsc_grp_state
4num_channel_delta 0
*Jul 8 18:46:44: rpm_rscprv_update resource update from resource provider 1 is successful
Router(config-dspfarm-profile)# exit

DB-1446 May 2008
Debug Commands

debug media resource provisioning errors Displays debugging messages related to media
resource provisioning errors.
debug media resource provisioning events Displays debugging messages related to media
resource provisioning events.

May 2008 DB-1447
Debug Commands
debug media resource provisioning errors

To display debugging messages related to media resource provisioning errors, use the debug media
resource provisioning errors command in privileged EXEC mode. To disable debugging output, use
no debug media resource provisioning errors

Examples The following is sample output from the debug media resource provisioning errors command:
Router# debug media resource provisioning errors
Media resource provisioning errors debugging is on
Router# no debug media resource provisioning errors
Media resource provisioning errors debugging is off

debug media resource provisioning all Displays debugging messages related to all
media resource provisioning.
debug media resource provisioning events Displays debugging messages related to media
resource provisioning events.

DB-1448 May 2008
Debug Commands
debug media resource provisioning events

To display debugging messages related to media resource provisioning events, use the debug media
resource provisioning events command in privileged EXEC mode. To disable debugging output, use
no debug media resource provisioning events

Examples The following is sample output from the debug media resource provisioning events command:
Router# debug media resource provisioning events
Media resource provisioning events debugging is on
Router# no debug media resource provisioning events
Media resource provisioning events debugging is off

Router#

debug media resource provisioning all Displays debugging messages related to all
media resource provisioning.
debug media resource provisioning errors Displays debugging messages related to media
resource provisioning errors.

May 2008 DB-1449
Debug Commands
debug mediacard
debug mediacard
To display Digital Signal Processor Resource Manager (DSPRM) debugging information, use the debug
mediacard command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug mediacard {all | errors | events | message}
no debug mediacard {all | errors | events | message}
Syntax Description all Debugs DSPRM errors, events, and messages.

errors Debugs DSPRM errors.
events Debugs DSPRM events.
message Debugs DSPRM messages.

12.3(8)XY This command was introduced on the Communication Media Module.
Usage Guidelines Use the debug mediacard errors command to debug active calls. You should use the debug mediacard
all command during minimum traffic periods only; using the debug mediacard all command during
active calls can significantly impact system performance.
Examples The following is sample output from the debug mediacard command:
Router# debug mediacard messages
Media Card service messages debugging is on

*Mar 1 07:45:06.362: > CREATE_CONFERENCE (0x1) , pktLen 56, confId 1, instId 1
7483, seqNo 27983, Payload (24 bytes): confType 3, agcMode 1, spkrUpdateReportMo
de 1, maxActSpkr 3
*Mar 1 07:45:06.362: > CREATE_CHANNEL (0x64) , pktLen 100, confId 1, instId 26
625, seqNo 27984, Payload (68 bytes): rxCodecType 1, suppressRx 1, rxCNG 2, rxPL
C 2, rxVAD 2, rxToneDet 1, rxSpkrPriority 1, rxInactiveTimeOut 7200, rxPacketSiz
e 20, rxRTPPayloadType 0
*Mar 1 07:45:06.362: txCodecType 2, suppressTx 1, txVAD 1, AGC 1, txSSRC 167

DB-1450 May 2008
Debug Commands
debug mediacard
860472, txPacketSize 20, txRTPPayloadType 0

*Mar 1 07:45:06.362: < CREATE_CONFERENCE_ACK (0x4001) , pktLen 116, confId 1,
instId 0, seqNo 27983, Payload (84 bytes): status 0 (Normal Completion), param1
3, param2 0
*Mar 1 07:45:06.362: < CREATE_CHANNEL_ACK (0x4064) , pktLen 116, confId 1, ins
tId 26625, seqNo 27984, Payload (84 bytes): status 0 (Normal Completion), param1
0, param2 0
*Mar 1 07:45:06.362: > CREATE_CONFERENCE (0x1) , pktLen 56, confId 2, instId
MTP#26625, seqNo 27985, Payload (24 bytes): confType 3, agcMode 1, spkrUpdateRep
ortMode 1, maxActSpkr 3
*Mar 1 07:45:06.362: > CREATE_CHANNEL (0x64) , pktLen 100, confId 2, instId 26
626, seqNo 27986, Payload (68 bytes): rxCodecType 2, suppressRx 1, rxCNG 2, rxPL
C 2, rxVAD 2, rxToneDet 1, rxSpkrPriority 1, rxInactiveTimeOut 7200, rxPacketSiz
e 20, rxRTPPayloadType 0
*Mar 1 07:45:06.366: txCodecType 1, suppressTx 1, txVAD 1, AGC 1, txSSRC 167
858296, txPacketSize 20, txRTPPayloadType 0
*Mar 1 07:45:06.366: < CREATE_CONFERENCE_ACK (0x4001) , pktLen 116, confId 2,
instId 0, seqNo 27985, Payload (84 bytes): status 0 (Normal Completion), param1
3, param2 0
Router# debug mediacard events
Media Card service events debugging is on

*Mar 1 07:47:53.926: ms_ac_open_rtp_sockets: loc_ipaddr = 10.1.80.24 loc_mac<00
03.feac.c842> rem_ip<0.0.0.0> rem_port<0>
*Mar 1 07:47:53.926: ms_ac_get_unique_udp_port: rtcp_socket = 6255F490
*Mar 1 07:47:53.926: ms_ac_get_unique_udp_port: SLOT3 Port<3450> is assigned!
*Mar 1 07:47:53.926: ms_ac_open_local_rtp: rtpinfo 64382A3C, local_port =23930
*Mar 1 07:47:53.926: ms_ac_rtp_enq: Sent msg 101 to DSPFARM
*Mar 1 07:47:53.926: ms_ac_open_remote_rtp: rtpinfo 64382A3C, loc_ipaddr = 10.1
.80.24 loc_udp_prt <23930> ,loc_mac<0003.feac.c842>
*Mar 1 07:47:53.926: ms_ac_open_remote_rtp: remote_ipaddr = 10.1.2.15 remote_ud
p_prt <17932>
*Mar 1 07:47:53.926: ms_ac_nexthop_macaddr idb<630BDFCC> nexthop<10.1.80.1>
*Mar 1 07:47:53.926: ms_ac_nexthop_macaddr ptr<6301F5AC> through<GigabitEtherne
t1/0> nexthop<10.1.80.1>
*Mar 1 07:47:53.926: ms_ac_after_found_mac <10.1.2.15>'s mac <00d0.002a.7400> f
ound
*Mar 1 07:47:53.926: ms_ac_check_xcode_rem_ip: rtpinfo <64382A3C> other_rtpinfo
<0>
*Mar 1 07:47:53.942: ms_ac_open_rtp_sockets: loc_ipaddr = 10.1.80.24 loc_mac<00
03.feac.c842> rem_ip<0.0.0.0> rem_port<0>
*Mar 1 07:47:53.942: ms_ac_get_unique_udp_port: rtcp_socket = 6256C9B4
*Mar 1 07:47:53.942: ms_ac_get_unique_udp_port: SLOT3 Port<1778> is assigned!
*Mar 1 07:47:53.942: ms_ac_open_local_rtp: rtpinfo 6438353C, local_port =22258
*Mar 1 07:47:53.942: ac_validate_xcode_params: codeDec<2> codeEnc<1> decDur<20>
encDur<20>
*Mar 1 07:47:53.942: ac_open_xcode_channel: codeDec<1> codeEnc<2> decDur<20> en
cDur<20> VADen<0> prf_id<4>
*Mar 1 07:47:53.942: reserve_xcode_resource: reserve xcode resource:codecDec<1>
codecEnc<2>
*Mar 1 07:47:53.942: al

show mediacard Displays information about the media card.

May 2008 DB-1451
Debug Commands
debug mgcp all
debug mgcp all

To enable all debug traces for Media Gateway Control Protocol (MGCP), use the debug mgcp all
debug mgcp all [tracelevel {critical | moderate | verbose}]
no debug mgcp all
Syntax Description tracelevel (Optional) Sets the priority level for this debug trace.
criticalDisplays only high priority debug information.
moderateDisplays medium and high priority debug information.
verboseDisplays all debug information. This is the default level.
Command Default MGCP debugging is disabled.

12.1(3)T Additional information was displayed for the gateways.
12.1(5)XM, The output was modified to display parameters for the MGCP
12.2(2)T channel-associated signaling (CAS) PBX and ATM adaptation layer 2
(AAL2) permanent virtual circuit (PVC) features.
12.2(11)T The command was implemented on the Cisco AS5350, Cisco AS5400, and
Cisco AS5850.
12.2(13)T Support for this command was implemented in Cisco 7200 series images.
12.4(4)T The tracelevel keyword was added.
Usage Guidelines This command enables the following MGCP debug commands:
debug mgcp endptdb
debug mgcp errors
debug mgcp events
debug mgcp gcfm
debug mgcp inout
debug mgcp media

DB-1452 May 2008
Debug Commands
debug mgcp all
debug mgcp nas

debug mgcp packets
debug mgcp parser
debug mgcp src
debug mgcp state
debug mgcp voipcac
Caution Using the debug mgcp all command may severely impact network performance.
Examples The following is sample output from the debug mgcp all command:
Router# debug mgcp all
This may severely impact network performance. Continue[confirm]

Media Gateway Control Protocol all debugging is on, trace-level Verbose
Router#
*Sep 10 17:20:24.408:
//-1/xxxxxxxxxxxx/MGCP/mgcp_count_active_mgc_msg_stat(240):[lvl=1]MGC stat -
192.168.1.200, total=8, succ=5, failed=1
*Sep 10 17:20:24.408: MGCP Packet received from 192.168.1.200:7979--->
CRCX 6 aaln/S2/SU1/1 MGCP 1.0
M: recvonly
C: 1
<---
*Sep 10 17:20:24.408: //-1/xxxxxxxxxxxx/MGCP/mgcpapp_process_mgcp_msg(3318):[lvl=0] : <NEW

MGCP MSG From CA>
*Sep 10 17:20:24.408: //-1/xxxxxxxxxxxx/MGCP/mgcp_parse_packet(316):[lvl=0]call
mgcp_parse_header
*Sep 10 17:20:24.408: //-1/xxxxxxxxxxxx/MGCP/mgcp_parse_packet(320):[lvl=0]out

mgcp_parse_header
*Sep 10 17:20:24.408: //-1/xxxxxxxxxxxx/MGCP/mgcp_parse_packet(360):[lvl=1]SUCCESS: - MGCP

Header parsing was OK
*Sep 10 17:20:24.408: //-1/xxxxxxxxxxxx/MGCP/mgcp_string_parse(186):[lvl=0]return code=1.

*Sep 10 17:20:24.408: //-1/xxxxxxxxxxxx/MGCP/mgcp_parse_parameter_lines(725):[lvl=1]return
parse function in mgcp_parm_rules_array[6].
*Sep 10 17:20:24.408: //-1/xxxxxxxxxxxx/MGCP/mgcp_parse_conn_mode(4762):[lvl=0](in_ptr:
recvonly)
*Sep 10 17:20:24.408:
//-1/xxxxxxxxxxxx/MGCP/mgcp_parse_conn_mode(4780):[lvl=0]tmp_ptr:(recvonly)
*Sep 10 17:20:24.408:
*Sep 10 17:20:24.408: //-1/xxxxxxxxxxxx/MGCP/mgcp_parse_conn_mode(4822):[lvl=0]match

recvonly recvonly
*Sep 10 17:20:24.408: //-1/xxxxxxxxxxxx/MGCP/mgcp_parse_conn_mode(4830):[lvl=0]case

MODE_RECVONLY

May 2008 DB-1453
Debug Commands
debug mgcp all
*Sep 10 17:20:24.408: //-1/xxxxxxxxxxxx/MGCP/mgcp_parse_conn_mode(4894):[lvl=0]SUCCESS:

Connection Mode parsing is OK

*Sep 10 17:20:24.408: //-1/xxxxxxxxxxxx/MGCP/mgcp_parse_call_id(840):[lvl=0]in_ptr: 1
*Sep 10 17:20:24.408: //-1/xxxxxxxxxxxx/MGCP/mgcp_parse_call_id(883):[lvl=1]SUCCESS: Call

ID string(1) parsing is OK
*Sep 10 17:20:24.408:
//-1/xxxxxxxxxxxx/MGCP/mgcp_val_mandatory_parms(12428):[lvl=0]Entered
*Sep 10 17:20:24.408: //-1/xxxxxxxxxxxx/MGCP/mgcp_val_comp_mp_parms(14923):[lvl=0]Entered
*Sep 10 17:20:24.408: //-1/xxxxxxxxxxxx/MGCP/mgcp_val_comp_mp_parms(14928):[lvl=1] -
lcon_opt_ptr could not be obtained
*Sep 10 17:20:24.412: //-1/xxxxxxxxxxxx/MGCP/mgcp_parse_packet(378):[lvl=2]SUCCESS: END of
Parsing
*Sep 10 17:20:24.412:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_a(1339):[lvl=0]aaln/S2/SU1/1
*Sep 10 17:20:24.412:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_aaln_slot(1632):[lvl=0]2/SU1/1
*Sep 10 17:20:24.412:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_digit(1600):[lvl=0]2/SU1/1
*Sep 10 17:20:24.412: //-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_aaln_slot(1641):[lvl=0]
: ifn 0x665449A8, slot:2
*Sep 10 17:20:24.412:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_aaln_su(1773):[lvl=0]1/1
*Sep 10 17:20:24.412: //-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_digit(1600):[lvl=0]1/1
*Sep 10 17:20:24.412:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_aaln_port(1807):[lvl=0]1
*Sep 10 17:20:24.412: //-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_digit(1600):[lvl=0]1
*Sep 10 17:20:24.412:
//-1/xxxxxxxxxxxx/MGCP/mgcp_endpt_get_endpt_offset(2590):[lvl=0]endpt NULL
*Sep 10 17:20:24.412: //-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_get_by_ifn(1326):[lvl=0]Entered
*Sep 10 17:20:24.412:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_get_tree_link_by_ifn(1145):[lvl=0]Entered
*Sep 10 17:20:24.412: //-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_compute_key(196):[lvl=0]type 2
slot 0002 subunit 0001
*Sep 10 17:20:24.412:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_get_tree_link_by_ifn(1157):[lvl=0]computed key
0x2081FF01

debug mgcp endpoint Enables debug traces for a specific MGCP endpoint.
debug mgcp Sets the trace level globally for all MGCP debug traces.
tracelevel-default
mgcp Starts the MGCP daemon.
mgcp debug-header Enables the display of MGCP module-dependent information in the
debug header.
show debugging Displays the types of debugging that are enabled.
show mgcp Displays MGCP configuration information.
voice call debug Specifies the format of the debug header.

DB-1454 May 2008
Debug Commands
debug mgcp endpoint
debug mgcp endpoint

To enable debug traces for a specific Media Gateway Control Protocol (MGCP) endpoint, use the debug
mgcp endpoint command in privileged EXEC mode. To disable debugging output for the endpoint, use
debug mgcp endpoint endpoint-name {all [tracelevel {critical | moderate | verbose}] | errors |
events [tracelevel {critical | moderate | verbose}] | media [tracelevel {critical | moderate |
verbose}] | packets}
no debug mgcp endpoint endpoint-name {all | errors | events | media | packets}
Syntax Description endpoint-name Name of the MGCP endpoint for which to enable debugging. Must be a fully
specified and supported endpoint.
all Displays MGCP errors, events, media, and packets for the specified
endpoint.
errors Displays MGCP errors for the specified endpoint.
events Displays MGCP events for the specified endpoint.
media Displays MGCP tone and signal events for the specified endpoint.
packets Displays MGCP packets for the specified endpoint.
tracelevel (Optional) Sets the priority level for the all, events, or media debug trace.
criticalDisplays only high-priority debug information.
moderateDisplays medium and high-priority debug information.
Note This keyword is not available for errors or packets debugging.
Command Default Debugging for specific endpoints is not enabled.

Usage Guidelines This command enables debugging for a specific MGCP endpoint. You can enable the same type of
debugging globally for all endpoints by using the debug mgcp all, debug mgcp errors, debug mgcp
events, debug mgcp media, or debug mgcp packets commands.

May 2008 DB-1455
Debug Commands
debug mgcp endpoint
Trace levels allow you to control the amount of debug information that is displayed in the output from
MGCP debug commands. Reducing the amount of output displayed on the console port makes it easier
to locate the correct debug information and limits the impact to network performance.
This command sets the trace level for the specific endpoint. You can set the trace level globally for all
MGCP debug commands and endpoints by using the debug mgcp tracelevel-default command. Setting
the endpoint-specific trace level takes precedence over the global trace-level.
Note Trace levels are not supported for errors or packets debugging because all of the output from those
commands is set to high priority.
Examples The following is sample output from the debug mgcp endpoint command:
Router# debug mgcp endpoint aaln/S2/SU1/1 events tracelevel critical
Media Gateway Control Protocol events debugging for endpoint aaln/S2/SU1/1 is on,
trace-level Critical
Router#
*Sep 10 17:46:13.100:
//-1/xxxxxxxxxxxx/MGCP|aaln/S2/SU1/1|-1|-1/mgcp_idle_crcx(4875):[lvl=2]callp(0x63E313E0),
current state CALL_IDLE, event EV_CREATE_CONN
*Sep 10 17:46:13.100:
//7/9D04EB218005/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_invoke_app_sm(570):[lvl=2]MGCP:FSM
done- callp(63E313E0), new state CALL_CONNECTING, event EV_CREATE_CONN
*Sep 10 17:46:13.104:
//8/9D04EB218005/MGCP|aaln/S2/SU1/1|-1|-1/<VOIP>/mgcp_call_pre_conference(223):[lvl=2]call
p(0x63E311D0), current state CALL_CONNECTING, event EV_CALL_CONNECT
*Sep 10 17:46:13.104:
//8/9D04EB218005/MGCP|aaln/S2/SU1/1|-1|-1/<VOIP>/mgcp_call_connect(7331):[lvl=2]callp(0x63
E311D0), current state CALL_CONNECTING, event EV_CALL_CONNECT
*Sep 10 17:46:13.104:
//8/9D04EB218005/MGCP|aaln/S2/SU1/1|-1|-1/<VOIP>/mgcp_invoke_app_sm(570):[lvl=2]MGCP:FSM
done- callp(63E311D0), new state CALL_CONFERENCING, event EV_CALL_CONNECT
*Sep 10 17:46:13.104:
//7/9D04EB218005/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_call_proceeding(6306):[lvl=2]callp(
0x63E313E0), current state CALL_CONNECTING, event EV_CALL_PROCEED
*Sep 10 17:46:13.104:
//7/9D04EB218005/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_call_connect(7331):[lvl=2]callp(0x6
3E313E0), current state CALL_CONNECTING, event EV_CALL_PROCEED
*Sep 10 17:46:13.104:
done- callp(63E313E0), new state CALL_CONFERENCING, event EV_CALL_PROCEED
*Sep 10 17:46:13.108:
//7/9D04EB218005/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_ignore_ccapi_ev(4316):[lvl=2]callp(
0x63E313E0), current state CALL_CONFERENCING, event EV_CONF_RDY
*Sep 10 17:46:13.108:
done- callp(63E313E0), new state CALL_CONFERENCING, event EV_CONF_RDY
*Sep 10 17:46:13.108:
//7/9D04EB218005/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_call_modified(7710):[lvl=2]callp(0x
63E313E0), current state CALL_CONFERENCING, event EV_MODIFY_DONE
*Sep 10 17:46:13.108:
done- callp(63E313E0), new state CALL_CONFERENCING, event EV_MODIFY_DONE
*Sep 10 17:46:13.108:
//7/9D04EB218005/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_voice_mode_done(7994):[lvl=2]callp(
0x63E313E0), current state CALL_CONFERENCING, event EV_VOICE_MODE_DONE, minor ev(d): 138,
minor ev

DB-1456 May 2008
Debug Commands
debug mgcp endpoint
*Sep 10 17:46:13.112:
done- callp(63E313E0), new state CALL_ACTIVE, event EV_VOICE_MODE_DONE
*Sep 10 17:46:23.104:
done- callp(63E313E0), new state CALL_ACTIVE, event EV_MEDIA_EVT

debug mgcp all Enables all debug traces for MGCP.
debug mgcp errors Enables debug traces for MGCP errors.
debug mgcp events Enables debug traces for MGCP events.
debug mgcp media Enables debug traces for MGCP tone and signal events.
debug mgcp packets Enables debug traces for MGCP packets.
tracelevel-default
debug header.
show debugging Displays the types of debugging that are enabled.

May 2008 DB-1457
Debug Commands
debug mgcp endptdb
debug mgcp endptdb

To enable debug traces for all Media Gateway Control Protocol (MGCP) endpoints, use the debug mgcp
endptdb command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug mgcp endptdb [tracelevel {critical | moderate | verbose}]
no debug mgcp endptdb
Command Default MGCP debugging for endpoints is disabled.

Usage Guidelines This command enables debugging globally for all MGCP endpoints. You can limit debugging to a
specific endpoint by using the debug mgcp endpoint command.
Examples The following is sample output from the debug mgcp endptdb command used with the debug mgcp
packets command:
Router# debug mgcp packets
Media Gateway Control Protocol packets debugging for all endpoints is on
Router# debug mgcp endptdb

DB-1458 May 2008
Debug Commands
debug mgcp endptdb
Media Gateway Control Protocol endpoint database debugging for all endpoints is on,
trace-level Verbose
Router#
M: recvonly
C: 1
<---
*Sep 10 11:39:16.467:
*Sep 10 11:39:16.467:
*Sep 10 11:39:16.467:
*Sep 10 11:39:16.467: //-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_aaln_slot(1641):[lvl=0]
: ifn 0x665449A8, slot:2
*Sep 10 11:39:16.467:
*Sep 10 11:39:16.467:
*Sep 10 11:39:16.467:
*Sep 10 11:39:16.467:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_get_tree_link_by_ifn(1157):[lvl=0]computed key
0x2081FF01
*Sep 10 11:39:16.467: //-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_get_state(3758):[lvl=0]endpt
aaln/S2/SU1/1
*Sep 10 11:39:16.467:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_default_get_state(3779):[lvl=0]endpt aaln/S2/SU1/1
*Sep 10 11:39:16.479: MGCP Packet sent to 192.168.1.200:7979--->
200 27 OK
I: D
v=0
c=IN IP4 192.168.1.79
m=audio 16870 RTP/AVP 0 8 99 101 102 2 15 103 4 104 105 106 107 18 100
a=rtpmap:99 G.729a/8000
a=rtpmap:101 G.726-16/8000
a=rtpmap:102 G.726-24/8000
a=rtpmap:103 G.723.1-H/8000
a=rtpmap:104 G.723.1-L/8000
a=rtpmap:105 G.729b/8000
a=rtpmap:106 G.723.1a-H/8000
a=rtpmap:107 G.723.1a-L/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38
<---

May 2008 DB-1459
Debug Commands
debug mgcp endptdb

tracelevel-default
mgcp debug-header Enables the display of MGCP module-dependent information in the debug
header.

DB-1460 May 2008
Debug Commands
debug mgcp errors
debug mgcp errors

To enable debug traces for Media Gateway Control Protocol (MGCP) errors, use the debug mgcp errors
debug mgcp errors
no debug mgcp errors
Command Default MGCP error debugging is disabled.

12.2(2)XA The endpoint endpoint-name keyword and argument were added.
Cisco AS5850.
12.4(4)T The endpoint endpoint-name keyword and argument were removed and
replaced by the debug mgcp endpoint command.
Usage Guidelines This command enables error debugging globally for all MGCP endpoints. You can limit debugging to a
specific endpoint by using the debug mgcp endpoint command.
Examples The following is sample output from the debug mgcp errors command:
Router# debug mgcp errors
*Oct 16 12:09:05.538: MGC stat - 10.208.237.83, total=1029, succ=998, failed=0-

mgcp_parse_header()- Request Verb FOUND AUEP
- mgcp_parse_request_header()- MGCP_V10, start check for profile
- mgcp_parse_header: mgcp_parse_request_header returns status: 0

May 2008 DB-1461
Debug Commands
debug mgcp errors
*Oct 16 12:09:05.538: MGCP Packet received from 10.208.237.83-

AUEP 9634549 S0/DS1-0/1@AS5300 MGCP 1.0
F: I
*Oct 16 12:09:05.542: -- mgcp_parse_packet() - call mgcp_parse_header

- mgcp_parse_header()- Request Verb FOUND AUEP
- mgcp_parse_request_header()- MGCP_V10, start check for profile
- mgcp_parse_header: mgcp_parse_request_header returns status: 0
- mgcp_parse_packet() - out mgcp_parse_header
- SUCCESS: mgcp_parse_packet()-MGCP Header parsing was OK
- mgcp_parse_parameter_lines(), code_str:: I, code_len:2, str:F: I
- mgcp_parse_parameter_lines(str:F: I) -num_toks: 28
- mgcp_parse_parameter_lines() check NULL str(I), in_ptr(F: I)
- mgcp_parse_parameter_lines() return Parse function in mgcp_parm_rules_array[14]
- mgcp_parse_req_info(I) is called
- mgcp_parse_req_info() - tmp_ptr:(I)
- SUCCESS: Request Info parameter line (F:) parsing OK
- mgcp_val_mandatory_parms()

mgcp debug-header Enables the display of MGCP module-dependent information in the debug
header.

DB-1462 May 2008
Debug Commands
debug mgcp events
debug mgcp events

To enable debug traces for Media Gateway Control Protocol (MGCP) events, use the debug mgcp events
debug mgcp events [tracelevel {critical | moderate | verbose}]
no debug mgcp events
Command Default MGCP events debugging is disabled.

12.2(2)XA The endpoint endpoint-name keyword and argument were added.
Cisco AS5850.
replaced by the debug mgcp endpoint command. The tracelevel keyword
was added.
Usage Guidelines This command enables events debugging globally for all MGCP endpoints. You can limit debugging to
a specific endpoint by using the debug mgcp endpoint command.

May 2008 DB-1463
Debug Commands
debug mgcp events
Examples The following is sample output from the debug mgcp events command:
Router# debug mgcp events
Media Gateway Control Protocol events debugging for all endpoints is on, trace-level
Verbose
Router#
*Sep 10 09:22:41.276: //-1/xxxxxxxxxxxx/MGCP/mgcpapp_stw_call_back(316):[lvl=0]timer type
1
*Sep 10 09:22:41.276: //-1/xxxxxxxxxxxx/MGCP/mgcpapp_process_timers(1431):[lvl=0]timer of
type 1 expired.
*Sep 10 09:22:41.276:
//-1/xxxxxxxxxxxx/MGCP|aaln/S2/SU1/1|-1|-1/mgcp_remove_old_ack(712):[lvl=1]Removing ack:
(trans ID 15) : 250 15 OK
P: PS=0, OS=0, PR=0, OR=0, PL=0, JI=0, LA=0
*Sep 10 09:22:42.300:
*Sep 10 09:22:42.300: //-1/xxxxxxxxxxxx/MGCP/mgcpapp_process_mgcp_msg(3318):[lvl=0] : <NEW
MGCP MSG From CA>
*Sep 10 09:22:42.300:
*Sep 10 09:22:42.300:
//-1/xxxxxxxxxxxx/MGCP|aaln/S2/SU1/1|-1|-1/mgcpapp_setup_per_call_data(2487):[lvl=1]mgcpap
p_setup_per_call_data: callp: 63E313E0, vdbptr: 65822AF8, state: CALL_IDLE
*Sep 10 09:22:42.300:
//-1/xxxxxxxxxxxx/MGCP/mgcp_endpt_get_notified_entity(439):[lvl=0]Entered
*Sep 10 09:22:42.300: //-1/xxxxxxxxxxxx/MGCP/mgcp_endpt_get_notified_entity(458):[lvl=1]ne
callagenthost:7979, ne addr 192.168.1.200:7979
*Sep 10 09:22:42.300: //-1/xxxxxxxxxxxx/MGCP/xlate_mgcp_ev(921):[lvl=1]hdr_type 1
*Sep 10 09:22:42.300:
//-1/xxxxxxxxxxxx/MGCP|aaln/S2/SU1/1|-1|-1/mgcpapp_process_mgcp_event(2615):[lvl=1]Process
ing Incoming Message [CRCX 16]
*Sep 10 09:22:42.300:
//-1/xxxxxxxxxxxx/MGCP|aaln/S2/SU1/1|-1|-1/mgcpapp_invoke_mgcp_sm(2559):[lvl=1]Msg
In-Progress(Active) [INVVERB 0], await_ev=0, queued=0x00000000
*Sep 10 09:22:42.300:
//-1/xxxxxxxxxxxx/MGCP|aaln/S2/SU1/1|-1|-1/mgcp_process_deferred_queue(3362):[lvl=0]Entere
d
*Sep 10 09:22:42.300:
//-1/xxxxxxxxxxxx/MGCP/mgcp_store_endpt_and_ntfy_entity_name(4464):[lvl=0]Entered
*Sep 10 09:22:42.300:
//-1/xxxxxxxxxxxx/MGCP|aaln/S2/SU1/1|-1|-1/mgcp_invoke_app_sm(535):[lvl=0]MGCP:calling
FSM- callp(63E313E0)
*Sep 10 09:22:42.300:
*Sep 10 09:22:42.300:
//-1/xxxxxxxxxxxx/MGCP/mgcp_init_modem_relay_params(103):[lvl=0]modem-relay-enabled=0,
mr-gw-xid=0
*Sep 10 09:22:42.300:
//-1/xxxxxxxxxxxx/MGCP|aaln/S2/SU1/1|-1|-1/mgcp_compute_debugsy_hdr(274):[lvl=0]Building
Debugsy header
*Sep 10 09:22:42.300:
//-1/C537F3F38008/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_compute_debugsy_hdr(383):[lvl=0]GU
ID[C537F3F38008] assigned to call_id[-1], endpt[aaln/S2/SU1/1], mgcp_call_id[n/a],
conn_id[0]
*Sep 10 09:22:42.300:
//-1/C537F3F38008/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_idle_crcx(4961):[lvl=0]calls
mgcp_allocate_if()

DB-1464 May 2008
Debug Commands
debug mgcp events
*Sep 10 09:22:42.300:
//-1/C537F3F38008/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_idle_crcx(5006):[lvl=1]get
capability
*Sep 10 09:22:42.300:
//-1/C537F3F38008/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_compute_debugsy_hdr(274):[lvl=0]Bu
ilding Debugsy header
*Sep 10 09:22:42.304:
//-1/C537F3F38008/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_compute_debugsy_hdr(383):[lvl=0]GU
ID[C537F3F38008] assigned to call_id[-1], endpt[aaln/S2/SU1/1], mgcp_call_id[1],
conn_id[0]
*Sep 10 09:22:42.304:
//-1/C537F3F38008/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_idle_crcx(5093):[lvl=0]Default
aal2 vc = 1 1-pvc,2-svc
*Sep 10 09:22:42.304: //-1/xxxxxxxxxxxx/MGCP/mgcp_init_vox_if_record(6781):[lvl=0]reusing
records. conn_type: 2, vox if_type: 1
*Sep 10 09:22:42.304: //-1/xxxxxxxxxxxx/MGCP/mgcp_compute_debugsy_hdr(274):[lvl=0]Building
Debugsy header

tracelevel-default
debug header.

May 2008 DB-1465
Debug Commands
debug mgcp gcfm
debug mgcp gcfm

To enable generic call filter module (GCFM) debug traces for Media Gateway Control Protocol (MGCP),
use the debug mgcp gcfm command in privileged EXEC mode. To disable debugging output, use the no
debug mgcp gcfm [tracelevel {critical | moderate | verbose}]
no debug mgcp gcfm
Command Default MGCP GCFM debugging is disabled.

Usage Guidelines This command enables GCFM debugging globally for all MGCP endpoints.
Examples The following is sample output from the debug mgcp gcfm command:
Router# debug mgcp gcfm
Media Gateway Control Protocol gcfm debugging for all endpoints is on, trace-level Verbose
Router#
*Sep 10 09:24:52.692:
//-1/12F030978009/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_gcfm_percall_register(315):[lvl=2]
GCFM Inactive
*Sep 10 09:24:52.692:
//-1/12F030978009/MGCP|aaln/S2/SU1/1|-1|-1/<VOIP>/mgcp_gcfm_percall_register(315):[lvl=2]G
CFM Inactive
Router#

DB-1466 May 2008
Debug Commands
debug mgcp gcfm

tracelevel-default
debug header.

May 2008 DB-1467
Debug Commands
debug mgcp inout
debug mgcp inout

To enable debug traces for all Media Gateway Control Protocol (MGCP) entry and exit endpoints, use
the debug mgcp inout command in privileged EXEC mode. To disable debugging output, use the no
debug mgcp inout [tracelevel {critical | moderate | verbose}]
no debug mgcp inout
Command Default Debugging of MGCP entry and exit endpoints is disabled.

Usage Guidelines Trace levels allow you to control the amount of debug information that is displayed in the output from
Examples The following is sample output from the debug mgcp inout command:
Router# debug mgcp inout
Media Gateway Control Protocol inout debugging for all endpoints is on, trace-level
Verbose
Router#
*Sep 10 09:26:37.780:
mgcp_parse_header

DB-1468 May 2008
Debug Commands
debug mgcp inout

recvonly)



*Sep 10 09:26:37.784:
*Sep 10 09:26:37.784:
*Sep 10 09:26:37.784:
*Sep 10 09:26:37.784:
*Sep 10 09:26:37.784:
*Sep 10 09:26:37.784:
*Sep 10 09:26:37.784:
*Sep 10 09:26:37.784:
*Sep 10 09:26:37.784: //-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_get_state(3758):[lvl=0]endpt
aaln/S2/SU1/1
*Sep 10 09:26:37.784:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_default_get_state(3779):[lvl=0]endpt aaln/S2/SU1/1
*Sep 10 09:26:37.784:
//-1/xxxxxxxxxxxx/MGCP/mgcp_endpt_get_notified_entity(439):[lvl=0]Entered
*Sep 10 09:26:37.784: //-1/xxxxxxxxxxxx/MGCP/mgcp_endpt_get_notified_entity(458):[lvl=1]ne
callagenthost:7979, ne addr 192.168.1.200:7979
*Sep 10 09:26:37.784: //-1/xxxxxxxxxxxx/MGCP/xlate_mgcp_ev(921):[lvl=1]hdr_type 1
*Sep 10 09:26:37.784:
//-1/xxxxxxxxxxxx/MGCP|aaln/S2/SU1/1|-1|-1/mgcpapp_invoke_mgcp_sm(2559):[lvl=1]Msg
In-Progress(Active) [INVVERB 0], await_ev=0, queued=0x00000000
*Sep 10 09:26:37.784:
//-1/xxxxxxxxxxxx/MGCP|aaln/S2/SU1/1|-1|-1/mgcp_process_deferred_queue(3362):[lvl=0]Entere
d
*Sep 10 09:26:37.784:
//-1/xxxxxxxxxxxx/MGCP/mgcp_store_endpt_and_ntfy_entity_name(4464):[lvl=0]Entered
*Sep 10 09:26:37.784:
*Sep 10 09:26:37.784:
//-1/xxxxxxxxxxxx/MGCP/mgcp_init_modem_relay_params(103):[lvl=0]modem-relay-enabled=0,
mr-gw-xid=0
*Sep 10 09:26:37.784:
//-1/xxxxxxxxxxxx/MGCP|aaln/S2/SU1/1|-1|-1/mgcp_compute_debugsy_hdr(274):[lvl=0]Building
Debugsy header
*Sep 10 09:26:37.784:
//-1/5193F3E0800A/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_compute_debugsy_hdr(383):[lvl=0]GU
ID[5193F3E0800A] assigned to call_id[-1], endpt[aaln/S2/SU1/1], mgcp_call_id[n/a],
conn_id[0]

May 2008 DB-1469
Debug Commands
debug mgcp inout
*Sep 10 09:26:37.784:
//-1/5193F3E0800A/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_verify_supp_reqdet_ev(10645):[lvl=
0]Entered
*Sep 10 09:26:37.784:
//-1/5193F3E0800A/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_verify_supp_signal_ev(10685):[lvl=
0]Entered
*Sep 10 09:26:37.784:
//-1/5193F3E0800A/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_compute_debugsy_hdr(274):[lvl=0]Bu
ilding Debugsy header

tracelevel-default
debug header.

DB-1470 May 2008
Debug Commands
debug mgcp media
debug mgcp media

To enable debug traces for Media Gateway Control Protocol (MGCP) tone and signal events, use the
debug mgcp media command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug mgcp media [tracelevel {critical | moderate | verbose}]
no debug mgcp media
Command Default MGCP media debugging is disabled.

Cisco AS5850.
replaced by the debug mgcp endpoint command. The tracelevel keyword
was added.
Usage Guidelines This command enables media debugging globally for all MGCP endpoints. You can limit debugging to

May 2008 DB-1471
Debug Commands
debug mgcp media
Examples The following is sample output from the debug mgcp media command:
Router# debug mgcp media
Media Gateway Control Protocol media events debugging for all endpoints is on, trace-level
Verbose
Router#
*Sep 10 09:27:48.928:
//-1/7BFBA9F9800B/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_verify_supp_reqdet_ev(10645):[lvl=
0]Entered
*Sep 10 09:27:48.928:
//-1/7BFBA9F9800B/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_verify_supp_signal_ev(10685):[lvl=
0]Entered
*Sep 10 09:27:48.928:
//-1/7BFBA9F9800B/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/process_request_ev(5800):[lvl=1]callp
63E313E0, voice_if 6663CA38
*Sep 10 09:27:48.928:
//-1/7BFBA9F9800B/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/process_detect_ev(6007):[lvl=0]callp
63E313E0, voice_if 6663CA38
*Sep 10 09:27:48.928:
//-1/7BFBA9F9800B/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/process_signal_ev(5500):[lvl=0]callp
63E313E0, voice_ifp 6663CA38
*Sep 10 09:27:48.928:
//-1/7BFBA9F9800B/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_process_quarantine_mode(6096):[lvl
=0]callp 63E313E0, voice_if 6663CA38
*Sep 10 09:27:48.928:
=0]Q mode not found, Reset default values
*Sep 10 09:27:48.928:
=1]Q mode: process=0, loop=0
*Sep 10 09:27:48.936:
//19/7BFBA9F9800B/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_process_pending_t38_port_switch(16
49):[lvl=1]conn_recp->conn_id: 0x0
*Sep 10 09:27:48.940:
//19/7BFBA9F9800B/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/process_deferred_request_events(5724):[
lvl=0]Entered

tracelevel-default
debug header.

DB-1472 May 2008
Debug Commands
debug mgcp nas
debug mgcp nas

To enable network access server (NAS) (data) events for Media Gateway Control Protocol (MGCP), use
the debug mgcp nas command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug mgcp nas [tracelevel {critical | moderate | verbose}]
no debug mgcp nas
Command Default MGCP NAS event debugging is disabled.

Cisco AS5850.
Examples The following is sample output for the debug mgcp nas command with the debug mgcp packets
command also enabled:
Router# debug mgcp nas
Media Gateway Control Protocol nas pkg events debugging for all endpoints is on,
trace-level Verbose

May 2008 DB-1473
Debug Commands
debug mgcp nas
Router#
X:57
M: nas/data
C:3
L:b:64, nas/bt:modem, nas/cdn:3000, nas/cgn:1000
C: 1
<---
*Sep 10 11:51:41.863: //-1/xxxxxxxxxxxx/MGCP/mgcp_chq_nas_pkg(779):[lvl=0]Full string:

nas/bt:modem
*Sep 10 11:51:41.863: //-1/xxxxxxxxxxxx/MGCP/mgcp_chq_nas_pkg(791):[lvl=1]string past

slash: bt

colon: modem

nas/cdn:3000

slash: cdn

colon: 3000

nas/cgn:1000

slash: cgn

colon: 1000

tracelevel-default
debug header.

DB-1474 May 2008
Debug Commands
debug mgcp packets
debug mgcp packets

To enable debug traces for Media Gateway Control Protocol (MGCP) packets, use the debug mgcp
packets command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug mgcp packets [input-hex]
no debug mgcp packets [input-hex]
Syntax Description input-hex (Optional) Displays MGCP incoming packets in hexadecimal format.
Command Default MGCP packets debugging is disabled.

12.2(2)XA The endpoint endpoint-name keyword and argument and the input-hex
keyword were added.
Cisco AS5850.
replaced by the debug mgcp endpoint command.
Usage Guidelines This command enables packet debugging globally for all MGCP endpoints. You can limit debugging to

May 2008 DB-1475
Debug Commands
debug mgcp packets
Examples The following is sample output from the debug mgcp packets command:
Router#
M: recvonly
C: 1
<---
*Sep 10 11:57:26.795:
//-1/xxxxxxxxxxxx/MGCP|aaln/S2/SU1/1|-1|-1/mgcpapp_invoke_mgcp_sm(2569):[lvl=0]CHECK DATA
CALL for aaln/S2/SU1/1
*Sep 10 11:57:26.807: MGCP Packet sent to 192.168.1.200:7979--->

200 38 OK
I: 10
v=0
c=IN IP4 192.168.1.79
m=audio 18876 RTP/AVP 0 8 99 101 102 2 15 103 4 104 105 106 107 18 100
a=rtpmap:99 G.729a/8000
a=rtpmap:101 G.726-16/8000
a=rtpmap:102 G.726-24/8000
a=rtpmap:103 G.723.1-H/8000
a=rtpmap:104 G.723.1-L/8000
a=rtpmap:105 G.729b/8000
a=rtpmap:106 G.723.1a-H/8000
a=rtpmap:107 G.723.1a-L/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38
<---

tracelevel-default
debug header.

DB-1476 May 2008
Debug Commands
debug mgcp parser
debug mgcp parser

To enable debug traces for the Media Gateway Control Protocol (MGCP) parser and builder, use the
debug mgcp parser command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug mgcp parser [tracelevel {critical | moderate | verbose}]
no debug mgcp parser
Command Default MGCP parser and builder debugging is disabled.

Cisco AS5850.

May 2008 DB-1477
Debug Commands
debug mgcp parser
Examples The following is sample output from the debug mgcp parser command:
Router# debug mgcp parser
Media Gateway Control Protocol parser debugging for all endpoints is on, trace-level
Verbose
Router#
mgcp_parse_header
*Sep 10 11:58:51.283: //-1/xxxxxxxxxxxx/MGCP/mgcp_parse_packet(320):[lvl=0]out

mgcp_parse_header
*Sep 10 11:58:51.283: //-1/xxxxxxxxxxxx/MGCP/mgcp_parse_packet(360):[lvl=1]SUCCESS: - MGCP

Header parsing was OK

recvonly)
*Sep 10 11:58:51.283:
*Sep 10 11:58:51.283:
*Sep 10 11:58:51.283: //-1/xxxxxxxxxxxx/MGCP/mgcp_parse_conn_mode(4822):[lvl=0]match

recvonly recvonly
*Sep 10 11:58:51.283: //-1/xxxxxxxxxxxx/MGCP/mgcp_parse_conn_mode(4830):[lvl=0]case

MODE_RECVONLY



*Sep 10 11:58:51.283:
*Sep 10 11:58:51.283: //-1/xxxxxxxxxxxx/MGCP/mgcp_val_comp_mp_parms(14923):[lvl=0]Entered
*Sep 10 11:58:51.283: //-1/xxxxxxxxxxxx/MGCP/mgcp_val_comp_mp_parms(14928):[lvl=1] -
lcon_opt_ptr could not be obtained
*Sep 10 11:58:51.283: //-1/xxxxxxxxxxxx/MGCP/mgcp_parse_packet(378):[lvl=2]SUCCESS: END of
Parsing
*Sep 10 11:58:51.283:
//-1/95915C328011/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_validate_version_with_call_agent_s
erv_type(8322):[lvl=1]req_msg_version: 5, config_version: 5
*Sep 10 11:58:51.283: //-1/xxxxxxxxxxxx/MGCP/mgcp_validate_net_type(6601):[lvl=1]
lcnw_valid=0, lc_con_valid=0
*Sep 10 11:58:51.287: //-1/xxxxxxxxxxxx/MGCP/mgcp_validate_net_type(6710):[lvl=1]Network
type/conection type valid = 1. connection type = 1 [1->RTP, 2->AAL1_SDT, 4->AAL2]
*Sep 10 11:58:51.287: //-1/xxxxxxxxxxxx/MGCP/mgcp_get_qos(2665):[lvl=1]MGCP msg qos
value=0
*Sep 10 11:58:51.287: //-1/xxxxxxxxxxxx/MGCP/mgcp_init_dyn_payload_types(2899):[lvl=1]used
payload type map = 2F400003

DB-1478 May 2008
Debug Commands
debug mgcp parser
*Sep 10 11:58:51.287: //-1/xxxxxxxxxxxx/MGCP/get_voip_peer_info(7155):[lvl=1]No SDP

connection info
*Sep 10 11:58:51.287:
//-1/95915C328011/MGCP|aaln/S2/SU1/1|-1|-1/<VOIP>/mgcp_select_codec_only(897):[lvl=1]num
supprt codec=14
*Sep 10 11:58:51.287:
//-1/95915C328011/MGCP|aaln/S2/SU1/1|-1|-1/<VOIP>/mgcp_select_codec_only(1061):[lvl=0]glob
codec=1 (syn=1)
*Sep 10 11:58:51.287:
//-1/95915C328011/MGCP|aaln/S2/SU1/1|-1|-1/<VOIP>/mgcp_select_codec_only(1063):[lvl=0]supp
list=
*Sep 10 11:58:51.287:
//-1/95915C328011/MGCP|aaln/S2/SU1/1|-1|-1/<VOIP>/mgcp_select_codec_only(1067):[lvl=0] 1
*Sep 10 11:58:51.287:
//-1/95915C328011/MGCP|aaln/S2/SU1/1|-1|-1/<VOIP>/mgcp_select_codec_only(1067):[lvl=0],2
*Sep 10 11:58:51.287:
//-1/95915C328011/MGCP|aaln/S2/SU1/1|-1|-1/<VOIP>/mgcp_select_codec_only(1067):[lvl=0],7

debug mgcp tracelevel-default Sets the trace level globally for all MGCP debug traces.
debug header.

May 2008 DB-1479
Debug Commands
debug mgcp src
debug mgcp src

To enable debug traces for the System Resource Check (SRC) Call Admission Control (CAC) process
for Media Gateway Control Protocol (MGCP), use the debug mgcp src command in privileged EXEC
debug mgcp src [tracelevel {critical | moderate | verbose}]
no debug mgcp src
Command Default MGCP SRC debugging is disabled.

Cisco AS5850.
Examples The following is sample output from the debug mgcp src command:
Router# debug mgcp src
Media Gateway Control Protocol System Resource Check CAC debugging for all endpoints is
on, trace-level Verbose
Router#

DB-1480 May 2008
Debug Commands
debug mgcp src
*Sep 10 12:01:14.403:
//-1/EADF209C8013/MGCP|aaln/S2/SU1/1|-1|-1/<VOIP>/mgcp_set_call_counter_control(8163):[lvl
=1]Outgoing call with 1 network leg, flag=TRUE
*Sep 10 12:03:01.051:
//35/EADF209C8013/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_reset_call_direction(8184):[lvl=1]
Reseting incoming_call flag=FALSE in voice_if

tracelevel-default
debug header.

May 2008 DB-1481
Debug Commands
debug mgcp state
debug mgcp state

To enable state traces for Media Gateway Control Protocol (MGCP), use the debug mgcp state
debug mgcp state [tracelevel {critical | moderate | verbose}]
no debug mgcp state
Command Default MGCP state debugging is disabled.

Examples The following is sample output from the debug mgcp state command:
Router# debug mgcp state
Media Gateway Control Protocol state transition debugging for all endpoints is on,
trace-level Verbose
Router#
*Sep 10 12:08:02.755:
//39/DE454D0E8015/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_set_call_state(7562):[lvl=2]callp(
0x63E313E0) old state=CALL_IDLE new state=CALL_CONNECTING
*Sep 10 12:08:02.755:
//40/DE454D0E8015/MGCP|aaln/S2/SU1/1|-1|-1/<VOIP>/mgcp_set_call_state(7562):[lvl=2]callp(0
x63E311D0) old state=CALL_IDLE new state=CALL_CONNECTING

DB-1482 May 2008
Debug Commands
debug mgcp state
*Sep 10 12:08:02.755:
0x63E313E0) old state=CALL_CONNECTING new state=CALL_CONNECTING
*Sep 10 12:08:02.759:
x63E311D0) old state=CALL_CONNECTING new state=CALL_CONFERENCING
*Sep 10 12:08:02.759:
0x63E313E0) old state=CALL_CONNECTING new state=CALL_CONFERENCING
*Sep 10 12:08:02.759:
x63E311D0) old state=CALL_CONFERENCING new state=CALL_CONFERENCING
*Sep 10 12:08:02.763:
0x63E313E0) old state=CALL_CONFERENCING new state=CALL_ACTIVE
*Sep 10 12:08:02.763:
x63E311D0) old state=CALL_CONFERENCING new state=CALL_ACTIVE

tracelevel-default
debug header.

May 2008 DB-1483
Debug Commands
debug mgcp tracelevel-default

To set the trace level globally for all Media Gateway Control Protocol (MGCP) debug traces, use the
debug mgcp tracelevel-default command in privileged EXEC mode. To reset the trace level to the
default value, use the no form of this command.
debug mgcp tracelevel-default {critical | moderate | verbose}
no debug mgcp tracelevel-default {critical | moderate | verbose}
Syntax Description critical Only high priority debug information is displayed.

moderate Medium and high priority debug information is displayed.
verbose All debug information is displayed. This is the default value.
Command Default The default trace level for all MGCP debug commands is verbose.

This command sets the trace level globally for all MGCP debug commands and endpoints. You can set
the trace level independently for a specific endpoint by using the debug mgcp endpoint command. The
endpoint-specific trace level takes precedence over the global trace-level set with this command.
Note This command applies only to MGCP debug commands that are issued after the default trace level is set.
For example, if you enable several debug commands and then change the default trace level, the new
trace level does not apply to any previously enabled MGCP debug commands.
Examples The following example sets the default trace level to critical for all MGCP debug traces:
Router# debug mgcp tracelevel-default critical

Media Gateway Control Protocol events debugging for all endpoints is on, trace-level
Critical

DB-1484 May 2008
Debug Commands
Router# debug mgcp state

Media Gateway Control Protocol state transition debugging for all endpoints is on,
trace-level Critical
Notice that if the default trace level is then changed, as in the following example, the new trace level
applies only to any MGCP debug commands that are issued after the default trace level is changed.
Router# debug mgcp tracelevel-default verbose
Router# debug mgcp voipcac

Media Gateway Control Protocol VoIPCAC debugging for all endpoints is on, trace-level
Verbose
Router# show debug
MGCP:
Media Gateway Control Protocol events debugging is on, trace level Critical
Media Gateway Control Protocol VoIPCAC debugging is on, trace level Verbose
Media Gateway Control Protocol state transition debugging is on, trace level Critical

debug header.

May 2008 DB-1485
Debug Commands
debug mgcp voipcac
debug mgcp voipcac

To enable debug traces for the Voice over IP (VoIP) Call Admission Control (CAC) process at the Media
Gateway Control Protocol (MGCP) application layer, use the debug mgcp voipcac command in
debug mgcp voipcac [tracelevel {critical | moderate | verbose}]
no debug mgcp voipcac
Command Default MGCP VoIP CAC debugging is disabled.

Cisco AS5850.
Examples The following is sample output from the debug mgcp voipcac command:
Router# debug mgcp voipcac
Media Gateway Control Protocol VoIPCAC debugging for all endpoints is on, trace-level
Verbose
Router#

DB-1486 May 2008
Debug Commands
debug mgcp voipcac
*Sep 10 12:04:47.747:
//-1/6A09713E8014/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_idle_crcx(5251):[lvl=0]Check for
HP and QOS combination
*Sep 10 12:04:47.751:
//-1/6A09713E8014/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_idle_crcx(5451):[lvl=0]CAC success
*Sep 10 12:04:47.751:
//-1/6A09713E8014/MGCP|aaln/S2/SU1/1|-1|-1/<VOIP>/set_up_voip_call_leg(3918):[lvl=0]get
voice interface
*Sep 10 12:04:47.751:
//-1/6A09713E8014/MGCP|aaln/S2/SU1/1|-1|-1/<VOIP>/set_up_voip_call_leg(4441):[lvl=0]Initia
lize VoIP CAC record stored in
VoIP interface struct
*Sep 10 12:04:47.751:
//38/6A09713E8014/MGCP|aaln/S2/SU1/1|-1|-1/<VOIP>/mgcp_connect_peer_vox_call_leg(1546):[lv
l=0]set_up_voip_call_leg returns OK
*Sep 10 12:04:47.759:
//37/6A09713E8014/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/process_signal_request_list(5608):[lvl=
0]Entered

tracelevel-default
debug header.

May 2008 DB-1487
Debug Commands
debug mgcp
debug mgcp
To enable debug traces for Media Gateway Control Protocol (MGCP) errors, events, media, packets,
parser, and Call Admission Control (CAC), use the debug mgcp command in privileged EXEC mode.
debug mgcp [all | errors [endpoint endpoint-name] | events [endpoint endpoint-name] | media
[endpoint endpoint-name] | nas | packets [endpoint endpoint-name | input-hex] | parser | src
| voipcac]
no debug mgcp [all | errors | events | media | nas | packets | parser | src | voipcac]
Syntax Description all (Optional) Debugs MGCP errors, events, media, packets, parser
and builder, and CAC.
errors (Optional) Debugs MGCP errors.
endpoint endpoint-name (Optional) Debugs MGCP errors, events, media, or packets per
endpoint.
events (Optional) Debugs MGCP events.
media (Optional) Debugs MGCP tone and signal events.
nas (Optional) Debugs MGCP network access server (NAS) (data)
events.
packets (Optional) Debugs MGCP packets.
input-hex (Optional) Debugs MGCP input packets in hexadecimal values.
parser (Optional) Debugs MGCP parser and builder.
src (Optional) Debugs MGCP System Resource Check (SRC) CAC
information.
voipcac (Optional) Turns on debugging messages for the Voice over IP
(VoIP) CAC process at the MGCP application layer.

12.2(2)T channel-associated signaling (CAS) PBX and ATM adaptation
layer 2 (AAL2) permanent virtual circuit (PVC) features.

DB-1488 May 2008
Debug Commands
debug mgcp
12.2(2)XA The media keyword was added. The endpoint endpoint-name
keyword and argument were added as options for the errors,
events, media, and packets keywords. The input-hex keyword
option was added for the packets keyword.
12.2(2)XB The nas keyw ord and the src and voipcac keywords were
added. (Refer to MGCP VoIP Call Admission Control in
Cisco IOS Release 12.2(2)XB.)
Note The nas keyword was not integrated into Cisco IOS
Release 12.2(8)T.
12.2(11)T The command was implemented on the Cisco AS5350,
Cisco AS5400, and Cisco AS5850.
12.2(13)T Support for this command was implemented in Cisco 7200
series images.
Usage Guidelines There is always a performance penalty when using debug commands.
Examples The following is sample output from the debug mgcp errors, debug mgcp events, debug mgcp media,
debug mgcp nas, debug mgcp packets, debug mgcp parser, and debug mgcp src commands and
keywords. The debug mgcp all command and keyword would show a compilation of all this output,
including the debug mgcp voipcac command and keyword output. Note that using the debug mgcp all
command and keyword may severely impact network performance.
The following is sample output from the debug mgcp errors command and keyword:
Router# debug mgcp errors
Unknown network interface type
The following is sample output from the debug mgcp events command and keyword:
Media Gateway Control Protocol events debugging is on

Router#
1w1d: MGC stat - 172.19.184.65, total=44, succ=7, failed=21
1w1d: MGCP msg 1
1w1d: remove_old_under_specified_ack:
1w1d: MGC stat - 172.19.184.65, total=44, succ=8, failed=21
1w1d: updating lport with 2427setup_ipsocket: laddr=172.29.248.193, lport=2427,
faddr=172.19.184.65, fport=2427
1w1d: enqueue_ack: ackqhead=0, ackqtail=0, ackp=1DC1D38, msg=21A037C
The following is sample output from the debug mgcp media command and keyword:
Router# debug mgcp media
Media Gateway Control Protocol media events debugging is on

Router#

May 2008 DB-1489
Debug Commands
debug mgcp
DYNAMIC payload type

DYNAMIC payload type
*Jan 1 03:02:13.159:mgcp_verify_supp_reqdet_ev
*Jan 1 03:02:13.159:mgcp_verify_supp_signal_ev
*Jan 1 03:02:13.159:process_request_ev- callp 635368FC, voice_if 6353C1F8
*Jan 1 03:02:13.159:process_detect_ev- callp 635368FC, voice_if 6353C1F8
*Jan 1 03:02:13.159:process_signal_ev- callp 635368FC, voice_ifp 6353C1F8
*Jan 1 03:02:13.159:mgcp_process_quarantine_mode- callp 635368FC, voice_if 6353C1F8
*Jan 1 03:02:13.159:mgcp_process_quarantine_mode- new q mode:process=0, loop=0
*Jan 1 03:02:13.179:process_deferred_request_events
*Jan 1 03:02:13.479:process_request_ev- callp 6353BCCC, voice_if 638C3094
*Jan 1 03:02:13.479:process_detect_ev- callp 6353BCCC, voice_if 638C3094
*Jan 1 03:02:13.479:process_signal_ev- callp 6353BCCC, voice_ifp 638C3094
*Jan 1 03:02:13.479:mgcp_process_quarantine_mode- callp 6353BCCC, voice_if 638C3094
*Jan 1 03:02:13.827:process_request_ev- callp 635368FC, voice_if 6353C1F8
*Jan 1 03:02:13.827:process_detect_ev- callp 635368FC, voice_if 6353C1F8
*Jan 1 03:02:13.827:process_signal_ev- callp 635368FC, voice_ifp 6353C1F8
*Jan 1 03:02:13.827:mgcp_process_quarantine_mode- callp 635368FC, voice_if 6353C1F8
*Jan 1 03:02:23.163:mgcp_cr_and_init_evt_node:$$$ the node pointer 63520B14
*Jan 1 03:02:23.163:mgcp_insert_node_to_preprocess_q:$$$enq to preprocess,

qhead=63520B14, qtail=63520B14, count 1, evtptr=63520B14
*Jan 1 03:02:23.479:mgcp_cr_and_init_evt_node:$$$ the node pointer 63520BA8
*Jan 1 03:02:23.479:mgcp_insert_node_to_preprocess_q:$$$enq to preprocess,

qhead=63520BA8, qtail=63520BA8, count 1, evtptr=63520BA8
The following is sample output for the debug mgcp nas command and keyword, with the debug mgcp
packets command and keyword enabled as well:
Router# debug mgcp nas
Media Gateway Control Protocol nas pkg events debugging is on
Media Gateway Control Protocol packets debugging is on
Router#
01:49:14:MGCP Packet received -
CRCX 58 S7/DS1-0/23 MGCP 1.0
X:57
M:nas/data
C:3
L:b:64, nas/bt:modem, nas/cdn:3000, nas/cgn:1000
mgcp_parse_conn_mode :string past nas = data

mgcp_chq_nas_pkg:Full string:nas/bt:modem
mgcp_chq_nas_pkg:string past slash:bt
mgcp_chq_nas_pkg:string past colon:modem
mgcp_chq_nas_pkg:Full string:nas/cdn:3000
mgcp_chq_nas_pkg:string past slash:cdn
mgcp_chq_nas_pkg:string past colon:3000
mgcp_chq_nas_pkg:Full string:nas/cgn:1000
c5400#

DB-1490 May 2008
Debug Commands
debug mgcp
mgcp_chq_nas_pkg:string past slash:cgn

mgcp_chq_nas_pkg:string past colon:1000
CHECK DATA CALL for S7/DS1-0/23
mgcpapp_xcsp_get_chan_cb -Found - Channel state Idle
CRCX Recv
mgcpapp_endpt_is_data:endpt S7/DS1-0/23, slot 7, port 0 chan 23
mgcpapp_data_call_hnd:mgcpapp_xcsp_get_chan_cb -Found - Channel state Idle
bw=64, bearer=E1,cdn=3000,cgn=1000
The following is sample output from the debug mgcp packets command and keyword:
Media Gateway Control Protocol packets debugging is on

Router#
1w1d: MGCP Packet received -
DLCX 408631346 * MGCP 0.1
1w1d: send_mgcp_msg, MGCP Packet sent --->
1w1d: 250 408631346
<---
The following is sample output from the debug mgcp parser command and keyword:
Router# debug mgcp parser
Media Gateway Control Protocol parser debugging is on

Router#
1w1d: -- mgcp_parse_packet() - call mgcp_parse_header
- mgcp_parse_header()- Request Verb FOUND DLCX
- mgcp_parse_packet() - out mgcp_parse_header
- SUCCESS: mgcp_parse_packet()- MGCP Header parsing was OK
- mgcp_val_mandatory_parms()
- SUCCESS: mgcp_parse_packet()- END of Parsing
1w1d: -- mgcp_build_packet()-
1w1d: - mgcp_estimate_msg_buf_length() - 87 bytes needed for header
- mgcp_estimate_msg_buf_length() - 87 bytes needed after checking parameter lines
- mgcp_estimate_msg_buf_length() - 87 bytes needed after checking SDP lines
- SUCCESS: MGCP message building OK
- SUCCESS: END of building
The following is sample output from the debug mgcp src command and keyword:
Router# debug mgcp src
Media Gateway Control Protocol System Resource Check CAC debugging is on

Router#
00:14:08: setup_indication: Set incoming_call flag=TRUE in voice_if
00:14:08: send_mgcp_msg, MGCP Packet sent --->
00:14:08: NTFY 11 aaln/S1/1@Router MGCP 0.1

N: emu@[1.4.173.1]:51665
X: 35
O: hd
<---
00:14:08: MGCP Packet received -
200 11 hello

RQNT 42 aaln/S1/1 MGCP 0.1
N: emu@[1.4.173.1]:51665
X: 41
R: D/[0-9*#T](d), hu
S: dl
D: (911|xxxx)

May 2008 DB-1491
Debug Commands
debug mgcp
00:14:08: 200 42 OK
<---
00:14:12: NTFY 12 aaln/S1/1@Router MGCP 0.1

N: emu@[1.4.173.1]:51665
X: 41
O: D/2222
<---
200 12 phone-number ok

CRCX 44 aaln/S1/1 MGCP 0.1
N: emu@[1.4.173.1]:51665
C: 3
X: 43
R: hu(n)
M: recvonly
L: a:G.711u,p:5,e:off,s:off
00:14:12: mgcp_setup_conn_check_system_resource: System resource check successful

00:14:12: mgcp_voice_crcx: System resource is available
00:14:12: mgcp_set_call_counter_control: Incoming call with 1 network leg, flag=FALSE
00:14:12: 200 44
I: 4
v=0
o=- 4 0 IN IP4 1.4.120.1
s=Cisco SDP 0
c=IN IP4 1.4.120.1
t=0 0
<---
MDCX 48 aaln/S1/1 MGCP 0.1
N: emu@[1.4.173.1]:51665
C: 3
I: 4
X: 47
M: recvonly
R: hu
v=0
o=- 4 0 IN IP4 1.4.120.3
s=Cisco SDP 0
c=IN IP4 1.4.120.3
t=0 0
00:14:13: mgcp_modify_conn_check_system_resource: System resource check successful

00:14:13: mgcp_modify_connection: System resource is available
00:14:13: 200 48 OK
<---

DB-1492 May 2008
Debug Commands
debug mgcp
MDCX 52 aaln/S1/1 MGCP 0.1

N: emu@[1.4.173.1]:51665
C: 3
I: 4
X: 51
M: sendrecv
R: hu
00:14:20: mgcp_modify_conn_check_system_resource: System resource check successful

00:14:20: mgcp_modify_connection: System resource is available
00:14:20: 200 52 OK
<---
DLCX 56 aaln/S1/1 MGCP 0.1
X: 55
N: emu@[1.4.173.1]:51665
C: 3
I: 4
R: hu
00:14:34: 250 56
P: PS=1382, OS=110180, PR=1378, OR=109936, PL=63484, JI=520, LA=2
<---
00:14:36: mgcp_reset_call_direction: Reseting incoming_call flag=FALSE in voice_if
00:14:36: NTFY 13 aaln/S1/1@tlkrgw1 MGCP 0.1

N: emu@[1.4.173.1]:51665
X: 55
O: hu
<---

May 2008 DB-1493
Debug Commands
debug mls rp ip multicast

To display information about Multilayer Switching Protocol (MLSP), use the debug mls rp ip multicast
debug mls rp ip multicast {all | error | events | packets}
no debub mls rp ip multicast {all | error | events | packets}
Syntax Description all Displays all multicast MLSP debugging information, including
errors, events, and packets.
error Displays error messages related to multicast MLSP.
events Displays the run-time sequence of events for multicast MLSP.
packets Displays the contents of MLSP packets.

Usage Guidelines Only one of the keywords is required.
Examples The following example shows output from the debug mls rp ip multicast command using the error
keyword:
Router# debug mls rp ip multicast error
mlsm error debugging is on

chtang-7200#
06:06:45: MLSMERR: scb is INACTIVE, free INSTALL_FE
06:06:46: MLSM: --> mlsm_proc_sc_ins_req(10.0.0.1, 224.2.2.3, 10)
The following example shows output from the debug mls rp ip multicast command using the event
keyword:
Router# debug mls rp ip multicast event
mlsm events debugging is on

Router#

DB-1494 May 2008
Debug Commands
3d23h: MSCP: incoming shortcut flow statistic from Fa2/0.11

3d23h: MLSM: Flow_stat: (192.1.10.6, 239.255.158.197), byte :537792
packet:8403
3d23h: MLSM: byte delta:7680 packet delta:120, time delta: 10
packet:8523
3d23h: MLSM: byte delta:7680 packet delta:120, time delta: 10
3d23h: MSCP: Router transmits keepalive_msg on Fa2/0.11
3d23h: MSCP: incoming shortcut keepalive ACK from Fa2/0.11
3d23h: MLSM: Include-list: (192.1.2.1 -> 0.0.0.0)
packet:8643
The following example shows output from the debug mls rp ip multicast command using the packet
keyword:
Router# debug mls rp ip multicast packet
mlsm packets debugging is on

Router#
Router#
Router#
Router#
**23h: MSCP(I): 01 00 0c cc cc cc 00 e0 1e 7c fe 5f 00 30 aa aa
...LLL.`.|~_.0
..23h: MSCP(I): 03 00 00 0c 01 07 01 05 00 28 01 02 0a c7 00 10
.........(...G
..23h: MSCP(I): a6 0b b4 ff 00 00 c0 01 0a 06 ef ff 9e c5 00 00
&.4...@...o..E
3d23h: MSCP(I): 00 00 00 09 42 c0 00 00 00 00 00 00 25 0b
....B@......%.
3d23h:
**23h: MSCP(O): 01 00 0c 00 00 00 aa 00 04 00 01 04 00 00 aa aa
......*.......
LL23h: MSCP(O): 03 00 00 0c 00 16 00 00 00 00 01 00 0c cc cc cc
.............L
..23h: MSCP(O): aa 00 04 00 01 04 00 24 aa aa 03 00 00 0c 01 07
*......$**....
..23h: MSCP(O): 01 06 00 1c c0 01 02 01 aa 00 04 00 01 04 00 00
....@...*.....
3d23h: MSCP(O): 00 0b 00 00 00 00 00 00 01 01 0a 62 ...........b
3d23h:
**23h: MSCP(I): 01 00 0c cc cc cc 00 e0 1e 7c fe 5f 00 24 aa aa
...LLL.`.|~_.$
..23h: MSCP(I): 03 00 00 0c 01 07 01 86 00 1c 01 02 0a c7 00 10
.............G
..23h: MSCP(I): a6 0b b4 ff 00 00 00 0b 00 00 c0 01 02 01 00 00
..4.......@...
3d23h: MSCP(I): 00 00
3d23h:

debug mdss Displays information about MDSS.

May 2008 DB-1495
Debug Commands
debug mls rp
debug mls rp
To display various Internetwork Packet Exchange (IPX) Multilayer Switching (MLS) debugging
elements, use the debug mls rp command in privileged EXEC mode. To disable debugging output, use
debug mls rp {error | events | ipx | locator | packets | all}
no debug mls rp {error | events | ipx | locator | packets | all}
Syntax Description error Displays MLS error messages.

events Displays a run-time sequence of events for the Multilayer Switching
Protocol (MLSP).
ipx Displays IPX-related events for MLS, including route purging and
changes to access lists and flow masks.
locator Identifies which switch is switching a particular flow of MLS explorer
packets.
packets Displays packet contents (in verbose and hexadecimal formats) for
MLSP messages.
all Displays all MLS debugging events.

Examples The following shows sample output from the debug mls rp ipx command:
Router# debug mls rp ipx
IPX MLS debugging is on

Router# conf t
Router(config)# int vlan 22
Router(config-if)# no ipx access-group out
05:44:37:FCP:flowmask changed to destination

DB-1496 May 2008
Debug Commands
debug mls rp

debug dss ipx event Displays debugging messages for route change events that affect IPX
MLS.

May 2008 DB-1497
Debug Commands
debug mmoip aaa
debug mmoip aaa

Note Effective with release 12.3(8)T, the debug mmoip aaa command is replaced by the debug fax mmoip
aaa command. See the debug fax mmoip aaa command for more information.
To display output that relates to authentication, authorization, and accounting (AAA) services with
store-and-forward fax, use the debug mmoip aaa command in privileged EXEC mode. To disable
debug mmoip aaa
no debug mmoip aaa

12.2(4)T This command was implemented on the Cisco 1750 access router.
12.3(8)T This command was replaced by the debug fax mmoip aaa command.
Examples The following output shows how the debug mmoip aaa command provides information about AAA for
the on-ramp or off-ramp gateways:
Router# debug mmoip aaa
5d10h:fax_aaa_begin_authentication:User-Name = mmoip-b.cisco.com
5d10h:fax_aaa_begin_authentication:fax_account_id_origin = GATEWAY_ID
5d10h:fax_aaa_end_authentication_callback:Authentication successful
The following output shows how the debug mmoip aaa command provides information about AAA for
the off-ramp gateway:
5d10h:fax_aaa_start_accounting:User-Name = mmoip-b.cisco.com
5d10h:fax_aaa_start_accounting:Calling-Station-Id = gmercuri@mail-server.cisco.com
5d10h:fax_aaa_start_accounting:Called-Station-Id = fax=571-0839@mmoip-b.cisco.com
5d10h:fax_aaa_start_accounting:fax_account_id_origin = GATEWAY_ID
mmoip-b#ax_aaa_start_accounting:fax_msg_id = <37117AF3.3D98300E@mail-server.cisco.com>
5d10h:fax_aaa_start_accounting:fax_pages = 2

DB-1498 May 2008
Debug Commands
debug mmoip aaa
5d10h:fax_aaa_start_accounting:fax_coverpage_flag = TRUE
5d10h:fax_aaa_start_accounting:fax_connect_speed = 14400bps
5d10h:fax_aaa_start_accounting:fax_recipient_count = 1
5d10h:fax_aaa_start_accounting:fax_auth_status = USER SUCCESS
5d10h:fax_aaa_start_accounting:gateway_id = mmoip-b.cisco.com
5d10h:fax_aaa_start_accounting:call_type = Fax Send
5d10h:fax_aaa_start_accounting:port_used = slot:0 vfc port:0
5d10h:fax_aaa_do_offramp_accounting tty(6), Stopping accounting
5d10h:fax_aaa_stop_accounting:ftdb->cact->generic.callActiveTransmitBytes = 18038
5d10h:fax_aaa_stop_accounting:ftdb->cact->generic.callActiveTransmitPackets = 14
The following output shows how the debug mmoip aaa command provides information about AAA for
the on-ramp gateway:
5d10h:fax_aaa_start_accounting:User-Name = mmoip-b.cisco.com
5d10h:fax_aaa_start_accounting:Calling-Station-Id = FAX=408@mail-from-hostname.com
5d10h:fax_aaa_start_accounting:Called-Station-Id = FAX=5710839@mail-server.cisco.com
5d10h:fax_aaa_start_accounting:fax_account_id_origin = GATEWAY_ID
5d10h:fax_aaa_start_accounting:fax_msg_id = 00391997233216263@mmoip-b.cisco.com
5d10h:fax_aaa_start_accounting:fax_pages = 2
5d10h:fax_aaa_start_accounting:fax_connect_speed = 14400bps
5d10h:fax_aaa_start_accounting:fax_auth_status = USER SUCCESS
5d10h:fax_aaa_start_accounting:email_server_address = 1.14.116.1
5d10h:fax_aaa_start_accounting:email_server_ack_flag = TRUE
5d10h:fax_aaa_start_accounting:gateway_id = mmoip-b.cisco.com
5d10h:fax_aaa_start_accounting:call_type = Fax Receive
5d10h:fax_aaa_start_accounting:port_used = Cisco Powered Fax System slot:1 port:4
5d10h:fax_aaa_do_onramp_accounting tty(5), Stopping accounting
5d10h:fax_aaa_stop_accounting:endb->cact->generic.callActiveTransmitBytes = 26687
5d10h:fax_aaa_stop_accounting:ftdb->cact->generic.callActiveReceiveBytes = 18558
5d10h:fax_aaa_stop_accounting:ftdb->cact->generic.callActiveReceivePackets = 14

May 2008 DB-1499
Debug Commands
debug mmoip send email

To test connectivity between the T.37 on-ramp gateway and the e-mail server by sending a test e-mail to
a specified e-mail address, use the debug mmoip send email command in privileged EXEC mode.
debug mmoip send email string
Syntax Description string E-mail address of the sender; for example, mailuser@mail-server.com.
There is no default.

12.2(4)T This command was introduced on the Cisco 1750 access router.
Examples The debug mmoip send email command is used to test connectivity between the on-ramp gateway and
the e-mail server. Basically, this debug command sends an e-mail message to the recipient specified in
the e-mail address string. There is no specific output associated with the debug mmoip send email
command; to see how the on-ramp gateway and e-mail server interact when processing the test e-mail
message, enable the debug fmail client command.
The following example tests connectivity between the on-ramp gateway and the e-mail server by sending
a test e-mail message to mailuser@mail-server.com:
Router# debug fmail client
Router# debug mmoip send email mailuser@mail-server.com
01:22:59:faxmail_client_send_test:Sending the test message to

ilya@mail-server.com from testing@mmoip-a.cisco.com...
01:22:59:faxmail_client_send_test:Opening client engine.
01:22:59:faxmail_client_send_test:Sending 59 bytes ...
01:22:59:faxmail_client_send_test:Done sending test email.

DB-1500 May 2008
Debug Commands

debug fmail client Displays e-mail parameters (such as Mail from and Envelope to
and Envelope from) and the progress of the SMTP client.

May 2008 DB-1501
Debug Commands
debug mmoip send fax

To send a T.37 off-ramp test fax, use the debug mmoip send fax command in privileged EXEC mode.
debug mmoip send fax string
Syntax Description string E.164 telephone number to be used for sending the test fax. There is no
default.

12.2(13)T This feature was introduced on the Cisco 7200 series routers.
Examples The debug mmoip send fax command is used to test connectivity between the off-ramp gateway and a
recipient fax device. Basically, this debug command sends a test fax transmission to the recipient
specified in the telephone number string. There is no specific output associated with the debug mmoip
send fax command.
The following example sends a test fax message to the telephone number 5550839:
Router# debug mmoip send fax 5550839
The following output shows that the off-ramp gateway is placing a fax call:
01:28:18:ftsp_offramp_match_digits:phone number to translate:5550839
01:28:18: destPat(5......), matched(1), prefix() peer_tag(1)
01:28:18:ftsp_offramp_match_digits:target:710839
01:28:18:fap_offcm:tty(4), Got dial message00:00:00.000:AT&F\Q0S7=255
Class 2 modem tracing begins, including modem initialization.

00:00:00.008:AA
00:00:00.068:TT
00:00:00.128:&F\Q0S7=255
00:00:00.128:
OK
00:00:00.128:E0V1

DB-1502 May 2008
Debug Commands
00:00:00.140:ATE0
OK
00:00:00.140:AT+FCLASS=2
00:00:00.148:
OK
00:00:00.148:+FDCC=..;+FBOR=
00:00:00.168:AT+FLID
00:00:00.180:
OK
00:00:00.180:ATDTW710839
The following output shows that the fax transmission is complete; in this particular
example, there was a transmission error, and the modem timed out.
01:28:25:ftsp_setup_for_oc:tty4, callid=0xA
01:28:25:ftsp_setup_for_oc ctl=0, cas grp=-1, snmp_ix=30
01:28:25:ftsp_off_ramp_active_call_init tty4 callid=0xA, snmp_ix=30
01:29:18:fap_offpmt:tty(4), TxPhaseA:modem timeout
01:29:18:%FTSP-6-FAX_DISCONNECT:Transmission er

May 2008 DB-1503
Debug Commands
debug mmoip transfer
debug mmoip transfer

To send output of the Tag Image File Format (TIFF) writer to a TFTP server, use the debug mmoip
transfer command in privileged EXEC mode.
debug mmoip transfer prefix-filename tftp-server-name
Syntax Description prefix-filename Name of the TIFF file. The format for the TIFF filename is
telephone-number.TIFF.
tftp-server-name TFTP server to which the output from the TIFF writer is sent.
Defaults Sending output of the TIFF writer to a TFTP server is disabled.

Examples The debug mmoip transfer command sends the content of the fax data received to the TFTP server
named by the tftp-server-name variable into the file identified by the prefix-filename variable. Each page
of the fax transmission is a separate file, designated by the letter p, followed by the page number.
For example, the following command transfers the received fax content to a TFTP server named keyer.
The first page of the transmission goes to the file named /tftpboot/test/testp1.tiff, the second page goes
to the file named /tftpboot/test/testp2.tiff and so on.
Router# debug mmoip transfer /tftpboot/test/test keyer
The named files must exist on the TFTP server and be writable in order for the debug operation to be
successful.

DB-1504 May 2008
Debug Commands
debug modem csm
debug modem csm

To debug the Call Switching Module (CSM), used to connect calls on the modem, use the debug modem
csm command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug modem csm [slot/port | group group-number]
no debug modem csm [slot/port | group group-number]
Syntax Description slot/port (Optional) The slot and modem port number.
group group-number (Optional) The modem group.
Usage Guidelines Use the debug modem csm command to troubleshoot call switching problems. With this command, you
can trace the complete sequence of switching incoming and outgoing calls.
Examples The following is sample output from the debug modem csm command. In this example, a call enters the
modem (incoming) on slot 1, port 0:
Router(config)# service timestamps debug uptime
Router(config)# end
Router# debug modem csm
00:04:09: ccpri_ratetoteup bear rate is 10

00:04:09: CSM_MODEM_ALLOCATE: slot 1 and port 0 is allocated.
00:04:09: MODEM_REPORT(0001): DEV_INCALL at slot 1 and port 0
00:04:09: CSM_PROC_IDLE: CSM_EVENT_ISDN_CALL at slot 1, port 0
00:04:11: CSM_RING_INDICATION_PROC: RI is on
00:04:13: CSM_RING_INDICATION_PROC: RI is off
00:04:15: CSM_PROC_IC1_RING: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0
00:04:15: MODEM_REPORT(0001): DEV_CONNECTED at slot 1 and port 0
00:04:15: CSM_PROC_IC2_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1, port 0
The following is sample output from the debug modem csm command when call is dialed from the
modem into the network (outgoing) from slot 1, port 2:
atdt16665202
00:11:21: CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 2
00:11:21: T1_MAIL_FROM_NEAT: DC_READY_RSP: mid = 1, slot = 0, unit = 0
00:11:21: CSM_PROC_OC1_REQUEST_DIGIT: CSM_EVENT_DIGIT_COLLECT_READY at slot 1, port 2
00:11:24: T1_MAIL_FROM_NEAT: DC_FIRST_DIGIT_RSP: mid = 1, slot = 0, unit = 0
00:11:24: CSM_PROC_OC2_COLLECT_1ST_DIGIT: CSM_EVENT_GET_1ST_DIGIT at slot 1, port 2
00:11:27: T1_MAIL_FROM_NEAT: DC_ALL_DIGIT_RSP: mid = 1, slot = 0, unit = 0
00:11:27: CSM_PROC_OC3_COLLECT_ALL_DIGIT: CSM_EVENT_GET_ALL_DIGITS (16665202) at slot 1,
port 2
00:11:27: ccpri_ratetoteup bear rate is 10

May 2008 DB-1505
Debug Commands
debug modem csm
00:11:27: MODEM_REPORT(A000): DEV_CALL_PROC at slot 1 and port 2

00:11:27: CSM_PROC_OC4_DIALING: CSM_EVENT_ISDN_BCHAN_ASSIGNED at slot 1, port 2
00:11:31: MODEM_REPORT(A000): DEV_CONNECTED at slot 1 and port 2
00:11:31: CSM_PROC_OC5_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1, port 2
CONNECT 19200/REL - MNP
The following is sample output from the debug modem csm command for an incoming call:
Router#1.19.36.7 2001
Trying 1.19.36.7, 2001 ... Open
atdt111222333444555666
*Apr 7 12:39:42.475: Mica Modem(1/0): Rcvd Dial String(111222333444555666)
*Apr 7 12:39:42.475: CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0
*Apr 7 12:39:42.479: CSM_RX_CAS_EVENT_FROM_NEAT:(A001): EVENT_CHANNEL_LOCK at slot 1 and
port 0
*Apr 7 12:39:42.479: CSM_PROC_OC4_DIALING: CSM_EVENT_DSX0_BCHAN_ASSIGNED at slot 1, port
0
*Apr 7 12:39:42.479: Mica Modem(1/0): Configure(0x1)
*Apr 7 12:39:42.479: Mica Modem(1/0): Call Setup
*Apr 7 12:39:42.479: neat msg at slot 0: (1/0): Tx LOOP_CLOSURE (ABCD=1101)
*Apr 7 12:39:42.491: neat msg at slot 0: (0/0): Rx LOOP_CLOSURE (ABCD=1101)
*Apr 7 12:39:42.531: VDEV_ALLOCATE: slot 1 and port 3 is allocated.
*Apr 7 12:39:42.531: CSM_RX_CAS_EVENT_FROM_NEAT:(0004): EVENT_CALL_DIAL_IN at slot 1 and
port 3
*Apr 7 12:39:42.531: CSM_PROC_IDLE: CSM_EVENT_DSX0_CALL at slot 1, port 3
*Apr 7 12:39:42.531: Mica Modem(1/3): Call Setup
*Apr 7 12:39:42.595: Mica Modem(1/0): State Transition to Call Setup
*Apr 7 12:39:42.655: Mica Modem(1/3): State Transition to Call Setup
*Apr 7 12:39:42.655: Mica Modem(1/3): Went offhook
*Apr 7 12:39:42.655: CSM_PROC_IC1_RING: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 3
*Apr 7 12:39:42.731: CSM_RX_CAS_EVENT_FROM_NEAT:(A001): EVENT_START_TX_TONE at slot 1
and port 0
*Apr 7 12:39:42.731: CSM_PROC_OC4_DIALING: CSM_EVENT_DSX0_START_TX_TONE at slot 1, port 0
*Apr 7 12:39:42.731: Mica Modem(1/0): Generate digits:called_party_num= len=1
*Apr 7 12:39:42.835: Mica Modem(1/3): Rcvd Digit detected(#)
*Apr 7 12:39:42.835: CSM_PROC_IC2_COLLECT_ADDR_INFO: CSM_EVENT_KP_DIGIT_COLLECTED (DNIS=,
ANI=) at slot 1, port 3
*Apr 7 12:39:42.855: neat msg at slot 0: (0/0): Tx LOOP_OPEN (ABCD=0101)
*Apr 7 12:39:42.871: neat msg at slot 0: (1/0): Rx LOOP_OPEN (ABCD=0101)
*Apr 7 12:39:42.899: Mica Modem(1/0): Rcvd Digits Generated
*Apr 7 12:39:42.911: CSM_RX_CAS_EVENT_FROM_NEAT:(A001): EVENT_END_TX_TONE at slot 1 and
port 0
*Apr 7 12:39:42.911: CSM_PROC_OC4_DIALING: CSM_EVENT_DSX0_END_TX_TONE at slot 1, port 0
*Apr 7 12:39:42.911: Mica Modem(1/0): Generate digits:called_party_num=A len=1
*Apr 7 12:39:43.019: CSM_PROC_OC4_DIALING: CSM_EVENT_TONE_GENERATED at slot 1, port 0
*Apr 7 12:39:43.019: Mica Modem(1/3): Rcvd Digit detected(A)
and port 0
*Apr 7 12:39:43.335: Mica Modem(1/0): Generate digits:called_party_num=111222333444555666
len=19
*Apr 7 12:39:43.439: Mica Modem(1/3): Rcvd Digit detected(1)

DB-1506 May 2008
Debug Commands
debug modem csm

*Apr 7 12:39:45.243: Mica Modem(1/3): Rcvd Digit detected(B)
*Apr 7 12:39:45.243: CSM_PROC_IC2_COLLECT_ADDR_INFO: CSM_EVENT_DNIS_COLLECTED
(DNIS=111222333444555666, ANI=) at slot 1, port 3
and port 0
*Apr 7 12:39:46.175: Mica Modem(1/0): Generate digits:called_party_num= len=3
*Apr 7 12:39:46.267: Mica Modem(1/3): Rcvd Digit detected(#)
*Apr 7 12:39:46.387: Mica Modem(1/3): Rcvd Digit detected(A)
*Apr 7 12:39:46.447: Mica Modem(1/3): Rcvd Digit detected(B)
*Apr 7 12:39:46.447: CSM_PROC_IC2_COLLECT_ADDR_INFO: CSM_EVENT_ADDR_INFO_COLLECTED
(DNIS=111222333444555666, ANI=) at slot 1, port 3
*Apr 7 12:39:46.507: CSM_PROC_OC4_DIALING: CSM_EVENT_ADDR_INFO_COLLECTED at slot 1, port
0
*Apr 7 12:39:47.127: CSM_RX_CAS_EVENT_FROM_NEAT:(0004): EVENT_CHANNEL_CONNECTED at slot
1 and port 3
*Apr 7 12:39:47.127: CSM_PROC_IC4_WAIT_FOR_CARRIER: CSM_EVENT_DSX0_CONNECTED at slot 1,
port 3
*Apr 7 12:39:47.127: Mica Modem(1/3): Link Initiate
*Apr 7 12:39:47.191: CSM_RX_CAS_EVENT_FROM_NEAT:(A001): EVENT_CHANNEL_CONNECTED at slot
1 and port 0
*Apr 7 12:39:47.191: CSM_PROC_OC5_WAIT_FOR_CARRIER: CSM_EVENT_DSX0_CONNECTED at slot 1,
port 0
*Apr 7 12:39:47.191: Mica Modem(1/0): Link Initiate
*Apr 7 12:39:47.227: Mica Modem(1/3): State Transition to Connect
*Apr 7 12:39:47.287: Mica Modem(1/0): State Transition to Connect
*Apr 7 12:39:49.103: Mica Modem(1/0): State Transition to Link
*Apr 7 12:39:52.103: Mica Modem(1/3): State Transition to Link
*Apr 7 12:40:00.927: Mica Modem(1/3): State Transition to Trainup
*Apr 7 12:40:00.991: Mica Modem(1/0): State Transition to Trainup
*Apr 7 12:40:02.615: Mica Modem(1/0): State Transition to EC Negotiating
*Apr 7 12:40:02.615: Mica Modem(1/3): State Transition to EC Negotiating
CONNECT 31200 /V.42/V.42bis
Router>
*Apr 7 12:40:05.983: Mica Modem(1/0): State Transition to Steady State
*Apr 7 12:40:05.983: Mica Modem(1/3): State Transition to Steady State+++
OK
ath
*Apr 7 12:40:09.167: Mica Modem(1/0): State Transition to Steady State Escape
*Apr 7 12:40:10.795: Mica Modem(1/0): State Transition to Terminating
*Apr 7 12:40:11.755: Mica Modem(1/3): State Transition to Idle
*Apr 7 12:40:11.755: Mica Modem(1/3): Went onhook

May 2008 DB-1507
Debug Commands
debug modem csm
*Apr 7 12:40:11.755: CSM_PROC_IC5_OC6_CONNECTED: CSM_EVENT_MODEM_ONHOOK at slot 1, port 3

*Apr 7 12:40:11.755: VDEV_DEALLOCATE: slot 1 and port 3 is deallocated
*Apr 7 12:40:12.111: CSM_RX_CAS_EVENT_FROM_NEAT:(A001): EVENT_CALL_IDLE at slot 1 and
port 0
*Apr 7 12:40:12.111: CSM_PROC_IC5_OC6_CONNECTED: CSM_EVENT_DSX0_DISCONNECTED at slot 1,
port 0
*Apr 7 12:40:12.111: Mica Modem(1/0): Link Terminate(0x6)
*Apr 7 12:40:13.495: Mica Modem(1/0): Went onhook
*Apr 7 12:40:13.495: CSM_PROC_IC6_OC8_DISCONNECTING: CSM_EVENT_MODEM_ONHOOK at slot 1,
port 0
*Apr 7 12:40:13.495: VDEV_DEALLOCATE: slot 1 and port 0 is deallocated
Router#disc
Closing connection to 1.19.36.7 [confirm]
Router#
Router#
The MICA technologies modem goes through the following internal link states when the call comes in:
Call Setup
Off Hook
Connect
Link
Trainup
EC Negotiation
Steady State
The following section describes the CSM activity for an incoming call.
When a voice call comes in, CSM is informed of the incoming call. This allocates the modem and sends
the Call Setup message to the MICA modem. The Call_Proc message is sent through D channel. The
modem sends an offhook message to CSM by sending the state change to Call Setup. The D channel then
sends a CONNECT message. When the CONNECT_ACK message is received, the Link initiate message
is sent to the MICA modem and it negotiates the connection with the remote modem. In the following
debug examples, a modem on slot 1, port 13 is allocated. It goes through its internal states before it is in
Steady State and answers the call.
Modem Management Call Switching Module debugging is on

*May 13 15:01:00.609: MODEM_REPORT:dchan_idb=0x60D437F8, call_id=0xE, ces=0x1
*May 13 15:01:00.609: VDEV_ALLOCATE: slot 1 and port 13 is allocated.
*May 13 15:01:00.609: MODEM_REPORT(000E): DEV_INCALL at slot 1 and port 13
*May 13 15:01:00.609: CSM_PROC_IDLE: CSM_EVENT_ISDN_CALL at slot 1, port 13
*May 13 15:01:00.609: Mica Modem(1/13): Configure(0x0)
*May 13 15:01:00.609: Mica Modem(1/13): Call Setup
*May 13 15:01:00.661: Mica Modem(1/13): State Transition to Call Setup
*May 13 15:01:00.661: Mica Modem(1/13): Went offhook

DB-1508 May 2008
Debug Commands
debug modem csm
*May 13 15:01:00.661: CSM_PROC_IC1_RING: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 13

*May 13 15:01:00.661: MODEM_REPORT:dchan_idb=0x60D437F8, call_id=0xE, ces=0x1
*May 13 15:01:00.661: MODEM_REPORT(000E): DEV_CONNECTED at slot 1 and port 13
*May 13 15:01:00.665: CSM_PROC_IC3_WAIT_FOR_CARRIER:
CSM_EVENT_ISDN_CONNECTED at slot 1, port 13
*May 13 15:01:00.665: Mica Modem(1/13): Link Initiate
*May 13 15:01:00.693: Mica Modem(1/13): State Transition to Connect
*May 13 15:01:01.109: Mica Modem(1/13): State Transition to Link
*May 13 15:01:09.433: Mica Modem(1/13): State Transition to Trainup
*May 13 15:01:11.541: Mica Modem(1/13): State Transition to EC Negotiating
*May 13 15:01:12.501: Mica Modem(1/13): State Transition to Steady State
The following section describes the status of CSM when a call is connected.
The show modem csm x/y command is similar to AS5200 access server. For an active incoming analog
call, the modem_status and csm_status should be VDEV_STATUS_ACTIVE_CALL and
CSM_IC4_CONNECTED, respectively.
Router# show modem csm 1/13
MODEM_INFO: slot 1, port 13, unit 0, modem_mask=0x0000, modem_port_offset=0

tty_hwidb=0x60D0BCE0, modem_tty=0x60B6FE7C, oobp_info=0x00000000,
modem_pool=0x60ADC998
modem_status(0x0002):VDEV_STATUS_ACTIVE_CALL.
csm_state(0x0204)=CSM_IC4_CONNECTED, csm_event_proc=0x600C6968, current
call thru PRI line
invalid_event_count=0, wdt_timeout_count=0
wdt_timestamp_started is not activated
wait_for_dialing:False, wait_for_bchan:False
pri_chnl=TDM_PRI_STREAM(s0, u0, c18), modem_chnl=TDM_MODEM_STREAM(s1, c13)
dchan_idb_start_index=0, dchan_idb_index=0, call_id=0x000E, bchan_num=18
csm_event=CSM_EVENT_ISDN_CONNECTED, cause=0x0000
ring_indicator=0, oh_state=0, oh_int_enable=0, modem_reset_reg=0
ring_no_answer=0, ic_failure=0, ic_complete=1
dial_failure=0, oc_failure=0, oc_complete=0
oc_busy=0, oc_no_dial_tone=0, oc_dial_timeout=0
remote_link_disc=0, stat_busyout=0, stat_modem_reset=0
oobp_failure=0
call_duration_started=1d02h, call_duration_ended=00:00:00,
total_call_duration=00:00:00
The calling party phone number = 4085552400
The called party phone number = 4085551400
total_free_rbs_timeslot = 0, total_busy_rbs_timeslot = 0,
total_dynamic_busy_rbs_timeslot = 0, total_static_busy_rbs_timeslot = 0,
min_free_modem_threshold = 6
The following section describes the CSM activity for an outgoing call.
For MICA modems, the dial tone is not required to initiate an outbound call. Unlike in the AS5200, the
digit collection step is not required. The dialed digit string is sent to the CSM in the outgoing request to
the CSM. CSM signals the D channel to generate an outbound voice call, and the B channel assigned is
connected to the modem and the CSM.
The modem is ordered to connect to the remote side with a CONNECT message, and by sending a link
initiate message, the modem starts to train.

May 2008 DB-1509
Debug Commands
debug modem csm
Modem Management Call Switching Module debugging is on

ISDN Q931 packets debugging is on
*May 15 12:48:42.377: Mica Modem(1/0): Rcvd Dial String(5552400)
*May 15 12:48:42.377: CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0
*May 15 12:48:42.377: CSM_PROC_OC3_COLLECT_ALL_DIGIT:
CSM_EVENT_GET_ALL_DIGITS at slot 1, port 0
*May 15 12:48:42.377: CSM_PROC_OC3_COLLECT_ALL_DIGIT: called party num:
(5552400) at slot 1, port 0
*May 15 12:48:42.381: process_pri_call making a voice_call.
*May 15 12:48:42.381: ISDN Se0:23: TX -> SETUP pd = 8 callref = 0x0011
*May 15 12:48:42.381: Bearer Capability i = 0x8090A2
*May 15 12:48:42.381: Channel ID i = 0xE1808397
*May 15 12:48:42.381: Called Party Number i = 0xA1, '5552400'
*May 15 12:48:42.429: ISDN Se0:23: RX <- CALL_PROC pd = 8 callref = 0x8011
*May 15 12:48:42.429: Channel ID i = 0xA98397
*May 15 12:48:42.429: MODEM_REPORT:dchan_idb=0x60D437F8, call_id=0xA011, ces=0x1
*May 15 12:48:42.429: MODEM_REPORT(A011): DEV_CALL_PROC at slot 1 and port 0
*May 15 12:48:42.429: CSM_PROC_OC4_DIALING: CSM_EVENT_ISDN_BCHAN_ASSIGNED
at slot 1, port 0
*May 15 12:48:42.429: Mica Modem(1/0): Call Setup
*May 15 12:48:42.489: Mica Modem(1/0): State Transition to Call Setup
*May 15 12:48:42.589: ISDN Se0:23: RX <- ALERTING pd = 8 callref = 0x8011
*May 15 12:48:43.337: ISDN Se0:23: RX <- CONNECT pd = 8 callref = 0x8011
*May 15 12:48:43.341: MODEM_REPORT:dchan_idb=0x60D437F8, call_id=0xA011, ces=0x1
*May 15 12:48:43.341: MODEM_REPORT(A011): DEV_CONNECTED at slot 1 and port 0
*May 15 12:48:43.341: CSM_PROC_OC5_WAIT_FOR_CARRIER:
CSM_EVENT_ISDN_CONNECTED at slot 1, port 0
*May 15 12:48:43.341: Mica Modem(1/0): Link Initiate
*May 15 12:48:43.341: ISDN Se0:23: TX -> CONNECT_ACK pd = 8 callref = 0x0011
*May 15 12:48:43.385: Mica Modem(1/0): State Transition to Connect
*May 15 12:48:43.849: Mica Modem(1/0): State Transition to Link
*May 15 12:48:52.665: Mica Modem(1/0): State Transition to Trainup
*May 15 12:48:54.661: Mica Modem(1/0): State Transition to EC Negotiating
*May 15 12:48:54.917: Mica Modem(1/0): State Transition to Steady State

debug modem oob Creates modem startup messages between the network management
software and the modem on the specified OOB port.
debug modem trace Performs a call trace on the specified modem, which allows you to determine
why calls are terminated.

DB-1510 May 2008
Debug Commands
debug modem dsip
debug modem dsip

To display output for modem control messages that are received or sent to the router, use the debug
modem dsip command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug modem dsip {tty-range | group | shelf/slot/port}
no debug modem dsip {tty-range | group | shelf/slot/port}
Syntax Description tty-range Modem tty number or range. You can specify a single TTY line
number or a range from 0 through the number of modems you have in
your Cisco AS5800 access server. Be sure to include a dash (-)
between the range values you specify.
group Modem group information.
shelf/slot/port Location of the modem by shelf/slot/port numbers for internal
modems.

Usage Guidelines The debug modem dsip command displays each Distributed System Interconnect Protocol (DSIP)
message that relates to a modem and is sent from or received at the router shelf. This command can be
applied to a single modem or a group of modems.
Examples The following examples show a display of the available debug modem command options and debug
modem dsip command options:
Router# debug modem ?
dsip Modem DSIP activity

maintenance Modem maintenance activity
oob Modem out of band activity
trace Call Trace Upload
traffic Modem data traffic
<cr>
Router# debug modem dsip ?
<0-935> First Modem TTY Number

May 2008 DB-1511
Debug Commands
debug modem dsip
group Modem group information

x/y/z Shelf/Slot/Port for Internal Modems
<cr>
The following example indicates that a Real Time Server (RTS) status message was received from the
router shelf, and an ACK message was sent back:
Router# debug modem dsip
00:11:02: RSMODEM_SEND-1/2/06: MODEM_RING_INDICATION_MSG cci1 si0 ms0 mm65535,0 dc0

00:11:02: RSMODEM_sRCV-1/2/06:l12,MODEM_CALL_ACK_MSG:
00:11:02: RSMODEM_SEND-1/2/06: MODEM_CALL_ACCEPT_MSG
00:11:11: RSMODEM_sRCV-2:l0,MODEM_POLL_MSG: 0 16 0 7 0 146 0 36 21
00:11:18: RSMODEM_sRCV-1/2/06:l12,MODEM_SET_DCD_STATE_MSG: 1
00:11:19: RSMODEM_SEND-1/2/06: MODEM_RTS_STATUS_MSG 1
00:11:19: RSMODEM_dRCV-2:l1258607996,MODEM_RTS_STATUS_MSG: 0 6 0 23 0 0 0 0 0
00:12:31: RSMODEM_sRCV-1/2/06:l12,MODEM_SET_DCD_STATE_MSG: 0
00:12:31: RSMODEM_SEND-1/2/06: MODEM_CALL_HANGUP_MSG
00:12:31: RSMODEM_sRCV-1/2/06:l12,MODEM_ONHOOK_MSG:
00:12:32: RSMODEM_SEND-1/2/06: MODEM_SET_DTR_STATE_MSG 0
Table 211 debug modem dsip Field Descriptions
Field Description
RSMODEM_SEND-1/2/06 Router shelf modem shelf sends a
MODEM_RING_INDICATION_MSG message.
RSMODEM_sRCV-1/2/06 Router shelf modem received a
MODEM_CALL_ACK_MSG message.
MODEM_CALL_ACCEPT_MSG Router shelf accepts the call.
MODEM_CALL_HANGUP_MSG Router shelf sends a hangup message.
MODEM_RTS_STATUS_MSG Request to send message status.

debug dsip Displays output for DSIP used between the router shelf and the dial shelf.
debug modem traffic Displays output for framed, unframed, and asynchronous data
transmission received from the modem cards.

DB-1512 May 2008
Debug Commands
debug modem oob
debug modem oob

To debug the out-of-band port used to poll modem events on the modem, use the debug modem oob
debug modem oob [slot/modem-port | group group-number]
no debug modem oob [slot/modem-port | group group-number]
Syntax Description slot/modem-port (Optional) The slot and modem port number.
Usage Guidelines The message types and sequence numbers that appear in the debugging output are initiated by the
Modem Out-of-Band Protocol and used by service personnel for debugging purposes.
Caution Entering the debug modem oob command without specifying a slot and modem number debugs all
out-of-band ports, which generates a substantial amount of information.
Examples The following is sample output from the debug modem oob command. This example debugs the
out-of-band port on modem 2/0, which creates modem startup messages between the network
management software and the modem.
Router# debug modem oob 2/0
MODEM(2/0): One message sent --Message type:3, Sequence number:0

MODEM(2/0): Modem DC session data reply
MODEM(2/0): DC session event =
MODEM(2/0): No status changes since last polled
MODEM(2/0): Modem DC session data reply

May 2008 DB-1513
Debug Commands
debug modem relay errors

To view modem relay network errors, use the debug modem relay errors command in privileged EXEC
debug modem relay [call-identifier call-setup-time call-index] errors
no debug modem relay [call-identifier call-setup-time call-index] errors
Syntax Description call-identifier (Optional) Identifies a particular call.

call-setup-time (Optional) Value of the system UpTime when the call associated with this
entry was started. Valid values are 0 through 4294967295.
call-index (Optional) Dial peer identification number used to distinguish between calls
with the same setup time. Valid values are 0 through 10.

12.2(11)T This command was introduced for the Cisco 2600, Cisco 3620, Cisco 3640,
Cisco 3660, and Cisco 7200 series routers and the Cisco AS5300 universal
access server.
Usage Guidelines In a stable modem relay network, the debug modem relay errors command produces little output.
Examples The following is sample output from the debug modem relay errors command. The output shows the
sequence number of the packet, time stamp, direction, layer, and payload bytes, followed by each byte
of the payload in hexadecimal.
Jan 11 05:35:09.119:ModemRelay pkt[0:D:11]. sqn 28 tm 11944 OUT ERR, pb=12, payload: 00 06
00 00 00 00 00 07 00 00 01 DE
*Jan 11 05:35:09.119:ModemRelay pkt[0:D:11]. sqn 29 tm 11944 OUT ERR, pb=12, payload: 00
06 00 00 00 00 00 04 00 00 00 BE
*Jan 11 05:35:09.119:ModemRelay pkt[0:D:11]. sqn 30 tm 11944 OUT ERR, pb=12, payload: 00
06 00 00 00 00 00 05 FF FF FF FD

DB-1514 May 2008
Debug Commands

debug hpi all Displays gateway DSP modem relay termination codes.
debug modem relay events Displays events that may cause failure of the modem relay
network.

May 2008 DB-1515
Debug Commands
debug modem relay events

To view the events that may cause failure of the modem relay network, use the debug modem relay
command.
debug modem relay [call-identifier call-setup-time call-index] events
no debug modem relay [call-identifier call-setup-time call-index] events


Cisco 3660, and Cisco 7200 series routers and the Cisco AS5300 universal
access server.
Usage Guidelines In a stable modem relay network, the debug modem relay events command produces little output.
Examples The following is sample output from the debug modem relay events command. The output shows the
Router# debug modem relay events
Jan 11 05:35:09.119:ModemRelay pkt[0:D:11]. sqn 28 tm 11944 OUT EVNT, pb=12, payload: 00

06 00 00 00 00 00 07 00 00 01 DE
*Jan 11 05:35:09.119:ModemRelay pkt[0:D:11]. sqn 29 tm 11944 OUT EVNT, pb=12, payload: 00
06 00 00 00 00 00 04 00 00 00 BE
*Jan 11 05:35:09.119:ModemRelay pkt[0:D:11]. sqn 30 tm 11944 OUT EVNT, pb=12, payload: 00
06 00 00 00 00 00 05 FF FF FF FD

DB-1516 May 2008
Debug Commands

debug modem relay errors Displays modem relay network errors.

May 2008 DB-1517
Debug Commands
debug modem relay packetizer

To view events occurring in the modem relay packetizer module, use the debug modem relay
packetizer command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug modem relay [call-identifier call-setup-time call-index] packetizer
no debug modem relay [call-identifier call-setup-time call-index] packetizer


Cisco 3660, and Cisco 7200 series routers, and the Cisco AS5300 universal
access server.
Usage Guidelines Disable console logging and use buffered logging before using the debug modem relay packetizer
command. Using the debug modem relay packetizer command generates a large volume of debugs,
which can affect router performance.
Examples The following is sample output from the debug modem relay packetizer command. The output shows
the sequence number of the packet, time stamp, direction, layer, and payload bytes, followed by each
byte of the payload in hexadecimal.
Router# debug modem relay packetizer
Jan 11 05:33:33.715:ModemRelay pkt[0:D:11]. sqn 8 tm 47610 IN PKTZR, pb=7, payload: 82 38

00 18 03 01 87
*Jan 11 05:33:33.727:ModemRelay pkt[0:D:11]. sqn 9 tm 47616 OUT PKTZR, pb=7, payload: 82
20 00 18 03 01 47
*Jan 11 05:33:35.719:ModemRelay pkt[0:D:11]. sqn 10 tm 49614 IN PKTZR, pb=7, payload: 82
39 00 18 03 01 87

DB-1518 May 2008
Debug Commands


May 2008 DB-1519
Debug Commands
debug modem relay physical

To view modem relay physical layer packets, use the debug modem relay physical command in
debug modem relay [call-identifier call-setup-time call-index] physical
no debug modem relay [call-identifier call-setup-time call-index] physical


access server.
Usage Guidelines Disable console logging and use buffered logging before using the debug modem relay physical
command. Using the debug modem relay physical command generates a large volume of debugs, which
can affect router performance.
Examples The following is sample output from the debug modem relay physical command. The output shows the
Jan 11 05:35:09.119:ModemRelay pkt[0:D:11]. sqn 28 tm 11944 OUT PHYS, pb=12, payload: 00
06 00 00 00 00 00 07 00 00 01 DE
*Jan 11 05:35:09.119:ModemRelay pkt[0:D:11]. sqn 29 tm 11944 OUT PHYS, pb=12, payload: 00
06 00 00 00 00 00 04 00 00 00 BE
*Jan 11 05:35:09.119:ModemRelay pkt[0:D:11]. sqn 30 tm 11944 OUT PHYS, pb=12, payload: 00
06 00 00 00 00 00 05 FF FF FF FD

DB-1520 May 2008
Debug Commands


May 2008 DB-1521
Debug Commands
debug modem relay sprt

To view modem relay Simple Packet Relay Transport (SPRT) protocol packets, use the debug modem
relay sprt command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug modem relay [call-identifier call-setup-time call-index] sprt
no debug modem relay [call-identifier call-setup-time call-index] sprt


access server.
Usage Guidelines Disable console logging and use buffered logging before using the debug modem relay sprt command.
Using the debug modem relay sprt command generates a large volume of debugs, which can affect
router performance.
Examples The following is sample output from the debug modem relay sprt command. The output shows the
Jan 11 05:37:16.151:ModemRelay pkt[0:D:11]. sqn 34 tm 7910 OUT SPRT, pb=4, payload: 02 00
03 71
*Jan 11 05:37:16.295:ModemRelay pkt[0:D:11]. sqn 35 tm 8048 IN SPRT, pb=13, payload: 02 00
01 F1 F7 7E FD F5 90 F3 3E 90 55
*Jan 11 05:37:16.303:ModemRelay pkt[0:D:11]. sqn 36 tm 8060 IN SPRT, pb=6, payload: 02 00
01 41 04 00

DB-1522 May 2008
Debug Commands


May 2008 DB-1523
Debug Commands
debug modem relay udp

To view events occurring in the User Datagram Protocol (UDP) stack, use the debug modem relay udp
debug modem relay [call-identifier call-setup-time call-index] udp
no debug modem relay [call-identifier call-setup-time call-index] udp


access server.
Usage Guidelines Disable console logging and use buffered logging before using the debug modem relay udp command.
Using the debug modem relay udp command generates a large volume of debugs, which can affect
router performance.
Examples The following is sample output from the debug modem relay udp command. The output shows three
UDP packets related to modem relay. In the sample output, OUT or IN represent packet direction, and
UDP indicates the specific layer that reported the packet.
Jan 1 03:39:29.407:ModemRelay pkt[0:D (4)]. sqn 61 tm 3060 OUT UDP, pb=6, payload: 80 00
00 00 00 00
*Jan 1 03:39:29.471:ModemRelay pkt[0:D (4)]. sqn 62 tm 3120 IN UDP, pb=6, payload: 40 00
00 00 00 00
*Jan 1 03:39:29.471:ModemRelay pkt[0:D (4)]. sqn 63 tm 3120 IN UDP, pb=6, payload: 80 00
00 00 00 00

DB-1524 May 2008
Debug Commands


May 2008 DB-1525
Debug Commands
debug modem relay v14

To observe events occurring in the V.14 layer, use the debug modem relay v14 command in privileged
debug modem relay [call-identifier call-setup-time call-index] v14
no debug modem relay [call-identifier call-setup-time call-index] v14

Command Default No debugging output is displayed.

12.4(2)T This command was introduced .
Usage Guidelines Use the debug modem relay v14 command to debug V.14 layer modem relay calls. Using this command
generates a large volume of debugs, which can affect router performance; disable console logging and
use buffered logging before using the debug modem relay v14 command. In most instances you will
use this command only at the request of Cisco Technical Assistance Center (TAC).
Examples The following is sample output from the debug modem relay v14 command. The output shows the
sequence number of the packet time stamp, direction, layer, and payload bytes, followed by each byte of
the payload in hexadecimal.
Router# debug modem relay v14
*Aug 10 22:51:37.496: ModemRelay pkt[1/1:1]. sqn 15649 tm 48766 OUT V14, pb=18, payload:
08 BC 4C 51 CE 1A 69 ED D6 65 62 8C 7F D3 9A 82 5A 7A
*Aug 10 22:51:38.216: ModemRelay pkt[1/1:1]. sqn 15650 tm 48778 IN V14, pb=22, payload:
9A 9C 7F 57 2D D7 4C 98 E8 EC FC 73 69 F2 FF A3 E8 B0 A4 58 BB AE
*Aug 10 22:51:38.216: ModemRelay pkt[1/1:1]. sqn 15651 tm 48790 OUT V14, pb=18, payload:
64 F9 73 D3 AB 11 61 ED 1E 5D 51 8D B1 9F CA 49 BF F4
*Aug 10 22:51:38.216: ModemRelay pkt[1/1:1]. sqn 15652 tm 48796 IN V14, pb=21, payload:
C1 77 90 12 F8 37 E8 7A 64 8D 0E 61 58 7E E4 E8 87 E0 B4 83 C7 A4 60 7A 64 8B 09 B9 80 2E
E5 2E 94 65 79 C2 A8 E9 6F D9 6C 3B

DB-1526 May 2008
Debug Commands


May 2008 DB-1527
Debug Commands

To view events occurring in the V.42 layer, use the debug modem relay v42 command in privileged
debug modem relay [call-identifier call-setup-time call-index] v42
no debug modem relay [call-identifier call-setup-time call-index] v42


access server.
Usage Guidelines Disable console logging and use buffered logging before using the debug modem relay v42 command.
Using the debug modem relay v42 command generates a large volume of debugs, which can affect
router performance.
Examples The following is sample output from the debug modem relay v42 command. The output shows the
sequence number of the packet, timestamp, direction, layer, and payload-bytes, followed by each byte of
the payload in hexadecimal.
Jan 11 05:42:08.715:ModemRelay pkt[0:D:13]. sqn 3 tm 10104 OUT V42, pb=43, payload: 03 AF
82 80 00 13 03 03 8A 89 00 05 02 03 E0 06 02 03 E0 07 01 08 08 01 08 F0 00 0F 00 03 56 34
32 01 01 03 02 02 04 00 03 01 20
*Jan 11 05:42:08.847:ModemRelay pkt[0:D:13]. sqn 4 tm 10236 IN V42, pb=2, payload: 03 7F

DB-1528 May 2008
Debug Commands


May 2008 DB-1529
Debug Commands
debug modem trace
debug modem trace

To debug a call trace on the modem to determine why calls are terminated, use the debug modem trace
debug modem trace [normal | abnormal | all] [slot/modem-port | group group-number]
no debug modem trace [normal | abnormal | all] [slot/modem-port | group group-number]
Syntax Description normal (Optional) Uploads the call trace to the syslog server on normal call
termination (for example, a local user hangup or a remote user hangup).
abnormal (Optional) Uploads the call trace to the syslog server on abnormal call
termination (for example, any call termination other than normal
termination, such as a lost carrier or a watchdog timeout).
all (Optional) Uploads the call trace on all call terminations including
normal and abnormal call termination.
slot/modem-port (Optional) The slot and modem port number.
Usage Guidelines The debug modem trace command applies only to manageable modems. For additional information, use
the show modem command.
Examples The following is sample output from the debug modem trace abnormal command:
Router# debug modem trace abnormal 1/14
Modem 1/14 Abnormal End of Connection Trace. Caller 123-4567

Start-up Response: AS5200 Modem, Firmware 1.0
Control Reply: 0x7C01
DC session response: brasil firmware 1.0
RS232 event:
DSR=On, DCD=On, RI=Off, TST=Off
changes: RTS=No change, DTR=No change, CTS=No change
changes: DSR=No change, DCD=No change, RI=No change, TST=No change
Modem State event: Connected
Connection event: Speed = 19200, Modulation = VFC
Direction = Originate, Protocol = reliable/LAPM, Compression = V42bis
DTR event: DTR On
Modem Activity event: Data Active
Modem Analog signal event: TX = -10, RX = -24, Signal to noise = -32
End connection event: Duration = 10:34-11:43,
Number of xmit char = 67, Number of rcvd char = 88, Reason: Watchdog Time-out.

DB-1530 May 2008
Debug Commands
debug modem trace

debug modem csm Debugs the CSM used to connect calls on the modem.
debug modem oob Creates modem startup messages between the network management
software and the modem on the specified OOB port.

May 2008 DB-1531
Debug Commands
debug modem traffic
debug modem traffic

To display output for framed, unframed, and asynchronous data sent received from the modem cards, use
the debug modem traffic command in privileged EXEC mode. To disable debugging output, use the no
debug modem traffic
no debug modem traffic

Usage Guidelines The debug modem traffic command displays output for framed, unframed, and asynchronous data sent
or received by the modem cards.
Examples The following example displays information about unframed or framed data sent to or received from the
modem cards:
Router# debug modem traffic
MODEM-RAW-TX:modem = 6/5/00, length = 1, data = 0x61, 0xFF, 0x7D, 0x23

MODEM-RAW-RX:modem = 6/5/00, length = 1, data = 0x61, 0x0, 0x0, 0x0
The information indicates unframed asynchronous data transmission and reception involving the modem
on shelf 6, slot 5, port 00.
The following example displays framed asynchronous data transmission and reception involving the
modem on shelf 6, slot 5, port 00:
Router# debug modem traffic
MODEM-FRAMED-TX:modem = 6/5/00, length = 8, data = 0xFF, 0x3, 0x82

MODEM-FRAMED-RX:modem = 6/5/00, length = 14, data = 0xFF, 0x3, 0x80

DB-1532 May 2008
Debug Commands
debug modem traffic

debug modem dsip Displays output for modem control messages that are received or sent to the
router.

May 2008 DB-1533
Debug Commands
debug modem
debug modem
To observe modem line activity on an access server, use the debug modem command in privileged
debug modem
no debug modem
Examples The following is sample output from the debug modem command. The output shows when the modem
line changes state.
Router# debug modem

15:25:51: tty4: Modem: IDLE->READY
15:25:51: TTY4: Autoselect started
15:27:51: TTY4: Autoselect failed
15:27:51: TTY4: Line reset
15:27:51: TTY4: Modem: READY->HANGUP
15:27:52: TTY4: dropping DTR, hanging up
15:27:52: tty4: Modem: HANGUP->IDLE
15:27:57: TTY4: restoring DTR

DB-1534 May 2008
Debug Commands
debug mpls adjacency

To display changes to label switching entries in the adjacency database, use the debug mpls adjacency
no debug mpls adjacency
Usage Guidelines This command has no keywords or arguments.

11.1CT This command was introduced.
12.1(3)T This command was modified to reflect new MPLS IETF terminology and
CLI command syntax.
Usage Guidelines Use the debug mpls adjacency command to monitor when entries are updated in or added to the
adjacency database.
Examples The following is sample output from the debug mpls adjacency command:
Router# debug mpls adjacency
TAG ADJ: add 10.10.0.1, Ethernet0/0/0

TAG ADJ: update 10.10.0.1, Ethernet0/0/0
Table 212 describes the significant fields shown in the sample display.
Table 212 debug mpls adjacency Field Description
Field Description
add Adding an entry to the database.
update Updating the MAC address for an existing entry.

May 2008 DB-1535
Debug Commands
Table 212 debug mpls adjacency Field Description (continued)
Field Description
10.10.0.1 Address of neighbor TSR.
Ethernet0/0/0 Connecting interface.

DB-1536 May 2008
Debug Commands
debug mpls atm-cos
debug mpls atm-cos

To display ATM label virtual circuit (VC) bind or request activity that is based on the configuration of
a Quality of Service (QoS) map, use the debug mpls atm-cos command in privileged EXEC mode.
debug mpls atm-cos [bind | request]
Syntax Description bind (Optional) Specifies debug information about bind responses for a VC path.
request (Optional) Specifies debug information about bind requests for a VC path.

12.0(10)ST This command was modified to reflect MPLS IETF syntax and terminology.
12.2(2)T This command was incorporated into Cisco IOS Release 12.2(2)T.
Examples The following command sequence demonstrates how to obtain sample output from the debug mpls
atm-cos command.
First, display the Multiprotocol Label Switching (MPLS) forwarding table to see which prefixes are
associated with a single label VC (LVC), as shown below:
Router# show mpls forwarding
Local Outgoing Prefix Bytes tag Outgoing Next Hop

tag tag or VC or Tunnel Id switched interface
26 28 17.17.17.17/32 0 PO6/0 point2point
27 Pop tag 11.11.11.11/32 1560 PO6/0 point2point
28 27 16.16.16.16/32 0 PO6/0 point2point
29 30 92.0.0.0/8 0 PO6/0 point2point
30 Pop tag 95.0.0.0/8 2600 PO6/0 point2point
31 2/34 10.10.10.10/32 0 AT2/0.1 point2point
32 Pop tag 14.14.14.14/32 0 Fa5/0 91.0.0.1
33 Pop tag 90.0.0.0/8 0 Fa5/0 91.0.0.1
34 Pop tag 96.0.0.0/8 0 Fa5/0 91.0.0.1
2/36 96.0.0.0/8 0 AT2/0.1 point2point
35 35 93.0.0.0/8 0 PO6/0 point2point
36 36 12.12.12.12/32 0 PO6/0 point2point
37 37 15.15.15.15/32 0 PO6/0 point2point
38 37 18.18.18.18/32 0 Fa5/0 91.0.0.1

May 2008 DB-1537
Debug Commands
debug mpls atm-cos
39 39 97.0.0.0/8 540 PO6/0 point2point

40 40 98.0.0.0/8 0 PO6/0 point2point
Second, enable debugging of request and bind events, as shown in the command sequence below:
Router# debug mpls atm-cos ?
bind Bind response for VC path

request Requests for VC binds path
Router# debug mpls atm-cos request
ATM TAGCOS VC requests debugging is on
Router# debug mpls atm-cos bind
ATM TAGCOS Bind response debugging is on
Third, configure an MPLS ATM subinterface for multi-VC mode. The corresponding request and bind
events are displayed, as shown below:
Router# conf terminal

Router(config)# int a2/0.1
Router(config-subif)# mpls atm multi-vc
Router(config-subif)# end
Router#
Router#
19:59:24:TAGCOS-REQ:vc request 10.10.10.10/32, available
19:59:24:TAGCOS-REQ:vc request 10.10.10.10/32, standard
19:59:24:TAGCOS-REQ:vc request 10.10.10.10/32, premium
19:59:24:TAGCOS-REQ:vc request 10.10.10.10/32, control
19:59:24:TAGCOS-REQ:vc request 96.0.0.0/8, available
19:59:24:TAGCOS-REQ:vc request 96.0.0.0/8, standard
19:59:24:TAGCOS-REQ:vc request 96.0.0.0/8, premium
19:59:24:TAGCOS-REQ:vc request 96.0.0.0/8, control
TAGCOS-REQ/TCATM:11.11.11.11/32,len=4352,band=1099528405504,class=0x700
TAGCOS-BIND:binding_ok 10.10.10.10/32,VCD=41 - control 41,41,41,41
TAGCOS-BIND:binding_ok 10.10.10.10/32, Inform TFIB pidx=0, in_tag=31, idx=0x80000000
TAGCOS-BIND:binding_ok 96.0.0.0/8,VCD=42 - control 42,42,42,42
TAGCOS-BIND:binding_ok 96.0.0.0/8, Inform TFIB pidx=1, in_tag=34, idx=0x80000001
TAGCOS-BIND:binding_ok 10.10.10.10/32,VCD=43 - premium 43,43,43,41
TAGCOS-BIND:binding_ok 96.0.0.0/8,VCD=44 - premium 44,44,44,42
TAGCOS-BIND:binding_ok 10.10.10.10/32,VCD=45 - standard 45,45,43,41
TAGCOS-BIND:binding_ok 96.0.0.0/8,VCD=46 - standard 46,46,44,42
TAGCOS-BIND:binding_ok 10.10.10.10/32,VCD=47 - available 47,45,43,41
TAGCOS-BIND:binding_ok 96.0.0.0/8,VCD=48 - available 48,46,44,42

DB-1538 May 2008
Debug Commands
debug mpls atm-ldp api

To display information about the virtual channel identifier (VCI) allocation of label virtual circuits
(LVCs), label-free requests, and cross-connect requests, use the debug mpls atm-ldp api command in
privileged EXEC mode. To disable this feature, use the no form of this command.
no debug mpls atm-ldp api

12.0(10)ST This command was modified to reflect MPLS IETF command syntax and
terminology.
12.1(8a)E This command was integrated into Cisco IOS Release 12.1(8a)E.
Usage Guidelines Use the debug mpls atm-ldp api command in conjunction with the debug mpls atm-ldp routes and
debug mpls atm-ldp states command to display more complete information about an LVC.

May 2008 DB-1539
Debug Commands
Examples The following shows sample output from the debug mpls atm-ldp api command:
Router# debug mpls atm-ldp api
Tailend Router Free label Req 167.50.0.0 on ATM0/0.2 VPI/VCI 1/674

TAGATM_API: received label free request
interface: ATM0/0.2 dir: in vpi: 1 vci: 674
TAGATM_API: completed label free
interface: ATM0/0.2 vpi: 1 vci: 674
result: TAGATM_OK
Table 213 debug mpls atm-ldp api Field Descriptions
Field Description
TAGATM_API Subsystem that displays the message.
interface Interface used by the driver to allocate or free VPI/VCI resources.
dir Direction of the VC:
InInput or receive VC
OutOutput VC
vpi Virtual path identifier.
vci Virtual channel identifier.
result The return error code from the driver API.

debug mpls atm-ldp Displays information about LVC state transitions as they occur.
states

DB-1540 May 2008
Debug Commands
debug mpls atm-ldp failure

To display failure information about the LC-ATM, use the debug mpls atm-ldp failure command in
privileged EXEC mode. To disable this feature, use the no form of the command.
no debug mpls atm-ldp failure

12.0(21)ST This command was integrated into Cisco IOS 12.0(21)ST.
Usage Guidelines Use the debug mpls atm-ldp failure command to display failure information about the LC-ATM. This
command is useful for determining failure cases. This command displays only failure information,
unlike the debug mpls atm-ldp api command, which displays all API events.
Examples This section shows sample output from the debug mpls atm-ldp failure command.
The following failure message displays during a race condition where the LC-ATM attempts to allocate
label virtual circuits (LVCs) on an interface where MPLS has been disabled:
Router# debug mpls atm-ldp failure
TAGATM_API_FAILURE: allocate_tag_req on ATM1/0/0 tagsw not enabled
The following failure message displays when the LC-ATM fails to deallocate the output leg LVC of a
cross connect:

May 2008 DB-1541
Debug Commands
TAGATM_API_FAILURE: connDeAllocateHalfLeg returned false interface: ATM1/0/0

vpi: 1 vci: 48
The following failure message displays when a cross connect cannot be installed on the switching fabric.
The result code is also provided.
TAGATM_API_FAILURE: setup_xconn_req InstallSvcXconn failed result
The following message displays when attempts to establish a cross connect fail. The result describes the
reason for the failure.
TCATM-4-XCONNECT_FAILED: 10.254.13.237/32 for ATM0/1/2 ATM1/0/0

TAGATM_API: x-conn setup request completed
input interface: ATM0/1/2 vpi: 1 vci: 48
output interface: ATM1/0/0 vpi: 2 vci: 2038
result = TAGATM_FAIL
Xconnect setup response for 10.254.13.215: failure, 8
The following message displays when attempts to remove a cross connect fail. The result describes why
the cross connect cannot be removed.
TCATM-4-XCONNECT_REMOVE_FAILED: Remove XConnect API failed for ATM1/0/12 1/894

-> ATM1/0/13 1/528
TAGATM_API: x-conn remove request completed
input interface: ATM1/0/12 vpi: 1 vci: 894
output interface: ATM1/0/13 vpi: 1 vci: 528
result = TAGATM_FAIL

debug mpls atm-ldp api Displays all driver API events.

DB-1542 May 2008
Debug Commands
debug mpls atm-ldp routes

To display information about the state of the routes for which virtual circuit identifier (VCI) requests are
being made, use the debug mpls atm-ldp routes command in privileged EXEC mode. To disable this
feature, use the no form of this command.
no debug mpls atm-ldp routes
Command History Command Modification

terminology.
Usage Guidelines When there are many routes and system activities (that is, shutting down interfaces, learning new routes,
and so forth), the debug mpls atm-ldp routes command displays extensive information that might
interfere with system timing. Most commonly, this interference affects normal label distribution protocol
(LDP) operation. To avoid this problem, you can increase the LDP hold time by means of the mpls ldp
holdtime command.

May 2008 DB-1543
Debug Commands
Examples The following shows sample output from the debug mpls atm-ldp routes command:
Router# debug mpls atm-ldp routes
CleanupRoutes,not deleting route of idb ATM0/0.2,rdbIndex 0

tcatmFindRouteTags,153.7.0.0/16,idb=ATM0/0.2,nh=134.111.102.98,index=0
AddNewRoute,153.7.0.0/16,idb=ATM0/0.2
CleanupRoutes,153.7.0.0/16
Table 214 debug mpls atm-ldp routes Field Descriptions
Field Description
CleanupRoutes Cleans up the routing table after a route has been deleted.
not deleting route of idb The route cleanup event has not removed the specified route.
ATM0/0.2
rdbIndex Index identifying the route.
tcatmFindRouteTags Request a VC for the route.
idb The internal descriptor for an interface.
nh Next hop for the route.
index Identifier for the route.
AddNewRoute Action of adding routes for a prefix or address.

mpls ldp holdtime Changes the time an LDP session is maintained in the absence of LDP
messages from the session peer.

DB-1544 May 2008
Debug Commands
debug mpls atm-ldp states

To display information about label virtual circuit (LVC) state transitions as they occur, use the debug
mpls atm-ldp states command in privileged EXEC mode. To disable this feature, use the no form of this
command.
no debug mpls atm-ldp states

terminology.
Usage Guidelines When there are many routes and system activities (such as shutting down interfaces, learning new routes,
and so forth), the debug mpls atm-ldp states command outputs extensive information that might
interfere with system timing. Most commonly, this interference affects normal label distribution protocol
(LDP) operation. To avoid this problem, you should increase the LDP hold time by means of the mpls
ldp holdtime command.

May 2008 DB-1545
Debug Commands
Examples The following shows sample output from the debug mpls atm-ldp states command:
Router# debug mpls atm-ldp states
Transit Output 166.35.0.0 VPI/VCI 1/67 Active -> XmitRelease NoPath

Transit Input 166.35.0.0 VPI/VCI 1/466 Active -> ApiWaitParentLoss ParentLoss
Transit Input 166.35.0.0 VPI/VCI 1/466 ApiWaitParentLoss -> ParentWait ApiSuccess
Transit Input 166.35.0.0 VPI/VCI 1/466 ParentWait -> XmitWithdraw NoPath
Transit Input 166.35.0.0 VPI/VCI 1/466 XmitWithdraw -> XmitWithdraw Transmit
Transit Input 166.35.0.0 VPI/VCI 1/466 XmitWithdraw -> NonExistent Release
Transit Input 166.35.0.0 VPI/VCI 1/466 NonExistent -> NonExistent ApiSuccess
Table 215 debug mpls atm-ldp states Field Descriptions
Field Description
Transit Output Output side of an LVC.
VPI/VCI VC value.
Transit Input Input side of an LVC.

mpls ldp holdtime Changes the time an LDP session is maintained in the absence of LDP
messages from the session peer.

DB-1546 May 2008
Debug Commands
debug mpls checkpoint label-binding

To display the events for the checkpoint label bindings of Multiprotocol Label Switching (MPLS)
applications running on the router, use the debug mpls checkpoint label-binding command in
privileged EXEC mode. To disable the display of these events, use the no form of this command.
no debug mpls checkpoint label-binding

12.2(28)SB This command was integrated into Cisco IOS Release 12.2(28)SB and implemented
on the Cisco 10000 series router.
platform hardware.
Usage Guidelines Use this command with caution. The command displays the events for every label binding.
Examples The following example shows the output when you issue the command on the standby Route Processor:
Router# debug mpls checkpoint label-binding
MPLS Label Binding Checkpoint debugging is on

3d17h: mpls_lbl_bind_chkpt: client ID 13 up, total client 1
3d17h: mpls_lbl_bind_chkpt: msg rx for 1D, vers 0, type 1
action 56, len 0, state 4, peer 13
3d17h: mpls_lbl_bind_chkpt: post msg type 1
3d17h: mpls_lbl_bind_chkpt: appl_id 13, KEY 000C800018888200
3d17h: mpls_chkpt_db: AVL insert successful, Key 000C800018888200 action Add, label 19

May 2008 DB-1547
Debug Commands

3d17h: Stby RP OR CF peer not ready, don't send msg
3d17h: mpls_lbl_bind_chkpt: client ID 13 down, total client 0
3d17h: mpls_lbl_bind_chkpt: appl_id 13, KEY action NSF unconfig, appl id 13

debug ip bgp vpnv4 Display the events for the VRF checkpointing system between the active and
checkpoint standby Route Processors.

DB-1548 May 2008
Debug Commands
debug mpls events
debug mpls events

To display information about significant Multiprotocol Label Switching (MPLS) events, use the debug
mpls events command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug mpls events
no debug mpls events

Usage Guidelines Use this command to monitor significant MPLS events.
Examples The following is sample output from the debug mpls events command:
Router# debug mpls events
MPLS events debugging is on
TAGSW: Unbound IP address, 155.0.0.55, from Router ID

TAGSW: Bound IP address, 199.44.44.55, to Router ID

May 2008 DB-1549
Debug Commands
debug mpls ip iprm cef

To display debugging information for interactions between Cisco Express Forwarding and the
Multiprotocol Label Switching (MPLS) IP Rewrite Manager (IPRM), use the debug mpls ip iprm cef
command in privileged EXEC mode. To disable the display of these events, use the no form of this
command.
debug mpls ip iprm cef [table {all | table-id} | vrf vrf-name | acl acl-name | prefix-list
prefix-list-name]
no debug mpls ip iprm cef
Syntax Description table (Optional) Displays the debugging information for one or more routing tables.
all Displays debugging information for all routing tables.
table-id The ID of the routing table for which you want to display debugging information.
Table 0 is the default or global routing table.
vrf (Optional) Displays debugging information for the VPN routing and forwarding
(VRF) instance you specify.
vrf-name The name of the VRF instance. You can find VRF names with the show ip vrf
command.
acl (Optional) Displays debugging information for the access control list (ACL) you
specify.
acl-name The name of the ACL. You can find ACL names with the show ip access-list
command.
prefix-list (Optional) Displays debugging information for the prefix list you specify.
prefix-list-name The name of the prefix list. You can find prefix list names with the show ip
prefix-list command.
Defaults Debugging is not enabled. If you do not supply an optional keyword, all the debugging events are
displayed.


DB-1550 May 2008
Debug Commands
Usage Guidelines This command limits the debug output to the IPRM interactions with Cisco Express Forwarding.
Examples In the following example, IPRM events related to Cisco Express Forwarding are displayed.
Cisco 7500 Series Example

Router# debug mpls ip iprm cef
IPRM CEF interaction debugging is on for global routing table

iprm: prefix deleted: 10.0.0.44/32(glbl)
iprm: discover prefix labels: 10.0.0.44/32(glbl); recurs tree change; ctxt 0x38002
iprm: announce prefix local labels: lcatm; trans #94; 10.0.0.44/32(glbl); 0 labels;
flags 0x0
...
flags 0x0
iprm: get path labels: 10.0.0.44/32(glbl); nh 59.0.0.55(glbl), Et4/0/1; trans #97;
recurs tree change
iprm: announce prefix local labels: ldp; trans #97; 10.0.0.44/32(glbl); 1 label; flags
0x0
iprm: lab 21, ltbl 0
iprm: announce path labels: ldp; trans #97; 10.0.0.44/32(glbl); 0 labels; flags 0x0
iprm: path: nh 59.0.0.55(glbl), Et4/0/1

Router# debug mpls ip iprm cef
IPRM CEF interaction debugging is on for global routing table

...
iprm: get path labels: 10.0.0.44/32(glbl); nh 59.0.0.55(glbl), GigabitEthernet4/0/0;

trans #97; recurs tree change
0x0
iprm: path: nh 59.0.0.55(glbl), GigabitEthernet4/0/0
See the field descriptions for the debug mpls ip iprm command for an explanation of the fields
displayed in the output.

debug mpls ip iprm Displays events related to the MPLS IPRM.
events
debug mpls ip iprm Displays debugging information for interactions between the IP LDMs and
ldm the MPLS IPRM.
debug mpls ip iprm Displays debugging information for interactions between the MFI and the
mfi MPLS IPRM.

May 2008 DB-1551
Debug Commands
debug mpls ip iprm events

To display events related to the Multiprotocol Label Switching (MPLS) IP Rewrite Manager (IPRM),
use the debug mpls ip iprm events command in privileged EXEC mode. To disable the display of these
events, use the no form of this command.
no debug mpls ip iprm events

Examples See the command page for debug mpls ip iprm for sample command output. See the command page for
debug mpls ip iprm for an explanation of the fields displayed in the output.

debug mpls ip iprm cef Displays debugging information for interactions between Cisco Express
Forwarding and the IPRM.
debug mpls ip iprm Displays debugging information for interactions between the LDMs and the
ldm MPLS IPRM.
mfi MPLS IPRM.

DB-1552 May 2008
Debug Commands
debug mpls ip iprm ldm

To display debugging information for interactions between the IP Label Distribution Modules (LDMs)
and the Multiprotocol Label Switching (MPLS) IP Rewrite Manager (IPRM), use the debug mpls ip
iprm ldm command in privileged EXEC mode. To disable the display of this information, use the no
debug mpls ip iprm ldm [bgp | lcatm | ldp | vpnv4 | 6pe | table {all | table-id} | vrf vrf-name | acl
acl-name | prefix-list prefix-list-name]
no debug mpls ip iprm ldm
Cisco 10000 Series Routers
debug mpls ip iprm ldm [bgp | ldp | vpnv4 | table {all | table-id} | vrf vrf-name | acl acl-name |
prefix-list prefix-list-name]
no debug mpls ip iprm ldm
Syntax Description bgp (Optional) Displays Border Gateway Protocol (BGP) events.
lcatm (Optional) Displays Label Controlled ATM (LC-ATM) events.
Note Applies to Cisco 7000 series routers only.
ldp (Optional) Displays Label Distribution Protocol (LDP) events.
vpnv4 (Optional) Displays Virtual Private Network (VPNv4) events.
6pe (Optional) Displays IPv6 over MPLS events.
Note Applies to Cisco 7000 series routers only.
table (Optional) Displays debugging information for one or more routing tables.
all (Optional) Displays debugging information for all routing tables.
table-id (Optional) Specifies the routing table for which you want to display
debugging information. Table 0 is the default or global routing table.
vrf (Optional) Displays debugging information for the VPN routing and
forwarding (VRF) instance you specify.
vrf-name (Optional) The name of the VRF instance. You can find VRF names with the
show ip vrf command.
acl (Optional) Displays debugging information for the access control list (ACL)
you specify.
acl-name (Optional) The name of the ACL. You can find ACL names with the show ip
access-list command.
prefix-list-name (Optional) The name of the prefix list. You can find prefix list names with
the show ip prefix-list command.
Defaults Debugging is not enabled. If you do not supply an optional keyword, all the debugging events are
displayed.

May 2008 DB-1553
Debug Commands

Examples See the debug mpls ip iprm command page for sample output and an explanation of the fields displayed
in the output.

debug mpls ip iprm Displays debugging information about events related to the MPLS IPRM.
events
mfi MPLS IPRM.

DB-1554 May 2008
Debug Commands
debug mpls ip iprm mfi

To display debugging information for interactions between the Multiprotocol Label Switching (MPLS)
Forwarding Infrastructure (MFI) and the MPLS IP Rewrite Manager (IPRM), use the debug mpls ip
iprm mfi command in privileged EXEC mode. To disable the display of this information, use the no
debug mpls ip iprm mfi [table {all | table-id} | vrf vrf-name | acl acl-name | prefix-list
prefix-list-name]
no debug mpls ip iprm mfi
Syntax Description table (Optional) Displays debugging information for one or more routing tables.
all (Optional) Displays debugging information for all routing tables.
table-id (Optional) Displays debugging information for the routing table you specify.
Table 0 is the default or global routing table.
vrf (Optional) Displays debugging information for the VPN Routing and
Forwarding (VRF) instance you specify.
vrf-name (Optional) The name of the VRF instance. You can find VRF names with the
show ip vrf command.
acl (Optional) Displays debugging information for the access control list (ACL)
you specify.
acl-name (Optional) The name of the ACL. You can find ACL names with the show ip
access-list command.
prefix-list-name (Optional) The name of the prefix list. You can find prefix list names with
the show ip prefix-list command.
Defaults Debugging is not enabled. If you enable debugging but do not supply an optional keyword, all the
debugging events are displayed.


May 2008 DB-1555
Debug Commands
Examples The command in the following example displays MFI events.

Router# debug mpls ip iprm mfi
IPRM MFI interaction debugging is on for global routing table

iprm: delete mfi rewrite: 10.0.0.44/32(glbl)
.
.
.
iprm: get mfi rewrite 10.0.0.44/32(glbl) obtained: 0 fpis/0 mois
iprm: update mfi rewrite: 10.0.0.44/32(glbl); prefix label info
iprm: omit rewrite create: 10.0.0.44/32(glbl)
.
.
.
iprm: lcl lab 21, ltbl 0, ldp
iprm: path lab -, nh 59.0.0.55(glbl), Et4/0/1; ldp
iprm: create mfi rewrite 10.0.0.44/32(glbl) passed: 2 fpis/1 mois
iprm: fpi[0] IV4, owner IPRM; 10.0.0.44/32; glbl
iprm: fpi[1] LBL, owner LDP; 21, ltbl 0
iprm: moi[0] PKT, flags 0x8; lab label-no-label; nh 59.0.0.55; nh if Et4/0/1 (nsf)

Router# debug mpls ip iprm mfi
IPRM MFI interaction debugging is on for global routing table

.
.
.
.
.
.
iprm: path lab -, nh 59.0.0.55(glbl), GigabitEthernet4/0/0; ldp
iprm: moi[0] PKT, flags 0x8; lab label-no-label; nh 59.0.0.55; nh if
GigabitEthernet4/0/0 (nsf)
See the debug mpls ip iprm command page for an explanation of the fields displayed in the output.

DB-1556 May 2008
Debug Commands

Forwarding and the MPLS IPRM .
events
ldm the MPLS IPRM.

May 2008 DB-1557
Debug Commands
debug mpls ip iprm
debug mpls ip iprm

To display debugging information for the Multiprotocol Label Switching (MPLS) IP Rewrite Manager
(IPRM), use the debug mpls ip iprm command in privileged EXEC mode. To disable the display of this
information, use the no form of this command.
debug mpls ip iprm
no debug mpls ip iprm

Usage Guidelines This command displays all output related to IPRM.
Examples The command in the following examples display all IPRM debugging for the global routing table.

Router# debug mpls ip iprm
IPRM debugging is on for global routing table

...
flags 0x0

DB-1558 May 2008
Debug Commands
debug mpls ip iprm
flags 0x0
iprm: get path labels: 10.0.0.44/32(glbl); nh 59.0.0.55(glbl), Et4/0/1; trans #81;
recurs tree change
iprm: ldm get path labels: 10.0.0.44/32(glbl), ldp; flags 0x8000
0x0
iprm: path: nh 59.0.0.55(glbl), Et4/0/1
iprm: path lab -, nh 59.0.0.55(glbl), Et4/0/1; ldp
iprm: moi[0] PKT, flags 0x8; lab label-no-label; nh 59.0.0.55; nh if Et4/0/1 (nsf)

Router# debug mpls ip iprm
IPRM debugging is on for global routing table

...

iprm: get path labels: 10.0.0.44/32(glbl); nh 59.0.0.55(glbl), GigabitEthernet4/0/0;

trans #81; recurs tree change
iprm: ldm get path labels: 10.0.0.44/32(glbl), ldp; flags 0x8000
0x0
iprm: path: nh 59.0.0.55(glbl), GigabitEthernet4/0/0

iprm: path lab -, nh 59.0.0.55(glbl), GigabitEthernet4/0/0; ldp
iprm: moi[0] PKT, flags 0x8; lab label-no-label; nh 59.0.0.55; nh if
GigabitEthernet4/0/0 (nsf)
Table 216 describes the significant fields shown in the display. The field descriptions also apply to the
output of following debug commands:

May 2008 DB-1559
Debug Commands
debug mpls ip iprm

Table 216 debug mpls ip iprm Field Descriptions
Field Description
discover prefix labels The prefix labels that the IP LDM discovered.
announce prefix local labels IP LDMs pass prefix incoming (local) and outgoing (path) labels
announce path labels to IPRM by announcing the labels.
mfi rewrite The information required by MPLS Forwarding Infrastructure
(MFI) to create forwarding data structures for an MPLS
forwarding equivalence class (FEC). For IP over MPLS a prefix
is an MPLS FEC. An MFI rewrite includes a set of forwarding
path identifier (FPI) and MPLS output information (MOI)
elements.
fpi Forwarding path identifier, which is required to locate MPLS
forwarding information for a FEC. IP over MPLS deals with
several types of FPIs, including IPv4 (IV4), IPv6 (IV6), and label
(LBL) FPIs.
Note The Cisco 10000 series router does not support IPv6.
moi MPLS output information. For IP over MPLS, there is a MOI for
each prefix path. The MOI includes the next hop (nh), outgoing
interface (nh if), and outgoing label. IP over MPLS handles
several types of MOIs, including packet (PKT) and ATM (ATM).
get/create/update MFI rewrite The process IPRM uses to read (get) or update (create/update) an
MFI rewrite.
recurs tree change Recursion tree change. Cisco Express Forwarding notifies IPRM
when the recursion tree (see below) for a prefix changes. IPRM
responds by performing label discovery (see above).
recursion tree A prefix known to Cisco Express Forwarding can have one or
more paths (routes). Each is either a terminal path with a next hop
and an outgoing interface or a recursive path with a next hop and
no outgoing interface. The next hop for a recursive path typically
matches a prefix known to Cisco Express Forwarding. That prefix
also has one or more paths. The IP recursion tree for prefix P is a
tree rooted at P's Cisco Express Forwarding entry with one of
more path descendants. Terminal paths are leaf nodes in P's
recursion tree and recursive paths are nonleaf nodes, each of
which points to the Cisco Express Forwarding entry for its next
hop.
glbl The global (default) routing table.
ctxt Context. Information used by IPRM when it performs label
discovery.
flags Information passed between IPRM and other components.
trans # Transaction number used to identify an ongoing label discovery.

DB-1560 May 2008
Debug Commands
debug mpls ip iprm
Table 216 debug mpls ip iprm Field Descriptions (continued)
Field Description
ltbl Label table.
nsf Nonstop forwarding.

events
debug mpls ip iprm Displays debugging information for interactions between the LDMs and the
ldm MPLS IPRM.
mfi MPLS IPRM.

May 2008 DB-1561
Debug Commands
debug mpls l2transport checkpoint

To enable the display of Any Transport over MPLS (AToM) events when AToM is configured for nonstop
forwarding/stateful switchover (NSF/SSO) and Graceful Restart, use the debug mpls l2transport
checkpoint command in privileged EXEC mode. To disable the display of these messages, use the no
no debug mpls l2transport checkpoint
Defaults Debugging of the AToM NSF/SSO and Graceful Restart feature is disabled.

Usage Guidelines Use debug commands with care. They use a significant amount of CPU time and can affect system
performance.
Examples In the following example, the output shows that NSF/SSO and Graceful Restart synchronize the data
between the active and backup Route Processors after an AToM virtual circuit (VC) is created. (Both the
debug mpls l2transport checkpoint and the debug acircuit checkpoint commands are enabled in this
example.)
The debug mpls l2transport checkpoint command is enabled on the active RP:
Router# debug mpls l2transport checkpoint
Router# debug acircuit checkpoint
Router# show debug
AToM HA:
AToM checkpointing events and errors debugging is on
AC HA:
Attachment Circuit Checkpoint debugging is on
Router(config)# interface Fa5/1/1.2

DB-1562 May 2008
Debug Commands
Router(config-subif)# xconnect 10.55.55.2 1002 pw-class mpls

AToM HA [10.55.55.2, 1002]: Build provision msg, SSM sw/seg 8192/8194 [0x2000/0x2002] PW i
d 9216 [0x2400] local label 21
AC HA: Dynamic Sync. Event:4 Sw:8192[2000] Se:16385[4001]
AToM HA: CF sync send complete
AC HA CF: Sync send complete. Code:0
On the standby Route Processor, the following messages indicate that it receives checkpointing data:
AC HA [10.55.55.2, 1002]: Add to WaitQ. Flags:1
AToM HA [105.55.55.2, 1002]: Received 32-byte provision version 1 CF message
AC HA CF: ClientId:89, Entity:0 Length:40
AToM HA [10.55.55.2, 1002]: Process chkpt msg provision [1], ver 1
AToM HA [10.55.55.2, 1002]: Reserved SSM sw/seg 8192/8194 [0x2000/0x2002] PW id 9216 [0x24
00]
AC HA: Process Msg:35586. Ptr:44CBFD90. Val:0
AC HA: Sync. Event:4 CktType:4 Sw:8192[2000] Se:16385[4001]
AC HA [10.55.55.2, 1002]: Remove from WaitQ. Flags:1[OK][OK]
During a switchover from the active to the backup Route Processor, the debug messages look similar to
the following:
%HA-5-MODE: Operating mode is hsa, configured mode is sso.
AC HA RF: CId:83, Seq:710, Sta:RF_STATUS_OPER_REDUNDANCY_MODE_CHANGE, Opr:5, St:STANDBY HO
T, PSt:ACTIVE
AToM HA: CID 84, Seq 715, Status RF_STATUS_OPER_REDUNDANCY_MODE_CHANGE, Op 5, State STANDB
Y HOT, Peer ACTIVE
AC HA RF: CId:83, Seq:710, Sta:RF_STATUS_PEER_PRESENCE, Opr:0, St:STANDBY HOT, PSt:ACTIVE
AToM HA: CID 84, Seq 715, Status RF_STATUS_PEER_PRESENCE, Op 0, State STANDBY HOT, Peer AC
TIVE
AC HA RF: CId:83, Seq:710, Sta:RF_STATUS_PEER_COMM, Opr:0, St:STANDBY HOT, PSt:DISABLED
AToM HA: CID 84, Seq 715, Status RF_STATUS_PEER_COMM, Op 0, State STANDBY HOT, Peer DISABL
ED
%HA-2-CUTOVER_NOTICE: Cutover initiated. Cease all console activity until system restarts.
%HA-2-CUTOVER_NOTICE: Do not add/remove RSPs or line cards until switchover completes.
%HA-2-CUTOVER_NOTICE: Deinitializing subsystems...
%HA-2-CUTOVER_NOTICE: Reinitializing subsystems...
%HA-2-CUTOVER_NOTICE: System preparing to restart...
%HA-5-NOTICE: Resuming initialization...
AC HA RF: CId:83, Seq:710, Sta:RF_STATUS_REDUNDANCY_MODE_CHANGE, Opr:7, St:STANDBY HOT, PS
t:DISABLED
.
.
.
%LDP-5-GR: LDP restarting gracefully. Preserving forwarding state for 250 seconds.
AC HA RF: CId:83, Seq:710, Sta:RF_PROG_ACTIVE, Opr:0, St:ACTIVE, PSt:DISABLED
AToM HA: CID 84, Seq 715, Event RF_PROG_ACTIVE, Op 0, State ACTIVE, Peer DISABLED
AC HA: Process Msg:35588. Ptr:0. Val:0
AC HA: Switchover: Standby->Active
AC HA RF: Reconciling

debug acircuit checkpoint Enables the display of AToM attachment circuit events when AToM is
configured for NSF/SSO and Graceful Restart.

May 2008 DB-1563
Debug Commands
debug mpls l2transport fast-reroute

To enable the display of Fast Reroute debugging information, use the debug mpls l2transport
fast-reroute command in privileged EXEC mode. To stop the display of these messages, use the no form
of this command.
no debug mpls l2transport fast-reroute
Defaults Debugging of the fast reroute feature is not enabled.

Usage Guidelines This command does not display output on platforms where AToM Fast Reroute is implemented in the
forwarding code. This command does not display output for the Cisco 7500 (both RP and VIP) series
routers, 7200 series routers, and Cisco 12000 series route processor. The command does display output
on Cisco 10720 Internet router line cards and Cisco 12000 series line cards.
Examples In the following example, the primary link is disabled, which causes the backup tunnel (Tu1) to become
the primary path.
Router# execute-on slot 3 debug mpls l2transport fast-reroute
========= Line Card (Slot 3) =========

AToM fast reroute debugging is on
SLOT 3:Sep 16 17:58:56.346: AToM SMGR: Processing TFIB FRR event for 1.4.0.1
SLOT 3:Sep 16 17:58:56.346: AToM SMGR: Finished processing TFIB FRR event for 1.4.0.1
SLOT 3:Sep 16 17:58:56.346: AToM SMGR: Processing TFIB FRR event for Tunnel41
SLOT 3:Sep 16 17:58:56.346: AToM SMGR: Finished processing TFIB FRR event for Tunnel41
Sep 16 17:58:58.342: %LINK-3-UPDOWN: Interface POS0/0, changed state to down
Sep 16 17:58:58.342: %OSPF-5-ADJCHG: Process 1, Nbr 1.0.0.1 on POS0/0 from FULL to DOWN,
Neighbor Down: Interface down or detached
Sep 16 17:58:59.342: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS0/0, changed state
to down

DB-1564 May 2008
Debug Commands

show mpls traffic-eng Displays the contents of the Fast Reroute database.
fast-reroute database

May 2008 DB-1565
Debug Commands
debug mpls l2transport ipc

To display the interprocessor communication (IPC) messages exchanged between distributed platforms,
such as the Cisco 12000 series router and the Cisco 7500 series routers, use the debug mpls l2transport
ipc command in privileged EXEC mode. To disable debugging output, use the no form of this command.
no debug mpls l2transport ipc

Usage Guidelines You can issue this command either from the line card or the route processor to log Any Transport over
MPLS (AToM) updates to or from line cards. This command applies only to platforms that support
distributed mode.
Examples The following is sample output from the debug mpls l2transport ipc command:
Router# debug mpls l2transport ipc
AToM ipc debugging is on

*May 27 23:56:04.699 UTC: AToM SMGR: Repopulating line card 255
*May 27 23:56:04.699 UTC: AToM SMGR [17.17.17.17, 1101]: Sending Imposition update to slot
255
*May 27 23:56:04.699 UTC: AToM SMGR [17.17.17.17, 1101]: Imposition being done on ingress
interface
*May 27 23:56:04.699 UTC: AToM SMGR [17.17.17.17, 1101]: Sending disposition update to
slot 255
*May 27 23:56:04.699 UTC: AToM SMGR [17.17.17.17, 1101]: Distributing disposition info to
all linecards
255
interface
*May 27 23:56:04.699 UTC: AToM SMGR [17.17.17.17, 701]: Sending disposition update to slot
255

DB-1566 May 2008
Debug Commands
all linecards
255
interface
*May 27 23:56:04.699 UTC: AToM SMGR [17.17.17.17, 1201]: Sending disposition update to
slot 255
all linecards

May 2008 DB-1567
Debug Commands
debug mpls l2transport packet

To display information about the status of Any Transport over MPLS (AToM) switched packets, use the
debug mpls l2transport packet command in privileged EXEC mode. To disable debugging output, use
debug mpls l2transport packet {data | error}
no debug mpls l2transport packet {data | error}
Syntax Description data Displays (in hex) the AToM switched packets for imposition and disposition. This can
help validate that packets are flowing between the customer edge (CE) routers. Also, you
can display the packets to check the format of the data or the data itself.
error Displays AToM switching errors, such as the reason that packets cannot be switched. This
can help identify why data is not being transported.

Usage Guidelines Use this command sparingly because the command output can be overwhelming.
For platforms that support distributed switching, the command displays output only for packets switched
by the central route processor module. Packets switched autonomously by the linecards are not
displayed. For example, packets switched by Versatile Interface Processors (VIPs) on the Cisco 7500
router are not displayed.
Examples The following is sample output from the debug mpls l2transport packet commands for a PPP over
MPLS configuration:
Router# debug mpls l2transport packet data
AToM packet data debugging is on
Router# debug mpls l2transport packet error
AToM packet errors debugging is on
Router# show debug

DB-1568 May 2008
Debug Commands
AToM:
AToM packet data debugging is on
AToM packet errors debugging is on
*Mar 24 23:29:30.495: ATOM-PPP Switching: check features failed.

*Mar 24 23:29:30.495: ATOM-PPP Switching (Fast) Imposition Packet data: experimental bits
are 0
*Mar 24 23:29:30.495: 0F 00 88 47 00 01 10 FF 00 01 51 02 00 00 00 00
*Mar 24 23:29:30.495: 00 FD C0 01 01 01 C0 4B 41 73 F4 00 01 00 02 CC
*Mar 24 23:29:30.495: 66 51 88 B4 CE 73 39 00 00 40 00 88 03 02 00 70
*Mar 24 23:29:30.495: 23 30 00 04 3C 61 83 C0 00 06 00 06 94 CC A7 23
*Mar 24 23:29:30.495: 49 84 D8 33 17 8C F2 60 00 11 9E 80 00 50 08 08
*Mar 24 23:29:30.495: 86 69 39 98 CD E2 02 49 B8 E9 9D 0D C6 53 A1 DC
*Mar 24 23:29:30.495: DE 72 35 88 09 E7 0C 60 61 3A 1A 4D C6 71 01 4C
*Mar 24 23:29:30.495: F2 73 CC 06 DC 38 6F 33 66 83 09 C8 CA 20 05 12
*Mar 24 23:29:30.495: 49 E5 31 00 A0 E8 6D 14 88 06 E3 21 80 C3 31 E4
*Mar 24 23:29:30.495: 28 21 E4 21 69 28 A6 2D 26 8A 45 82 02 B6 FC 39
*Mar 24 23:29:30.499: D8 60 A3 62 B1 60 A5 80
*Mar 24 23:29:31.835: ATOM-L2 Switching Disposition Packet data:
*Mar 24 23:29:31.835: FF 03 00 FD C0 04 8A 57 FF FF FF FF FF FF FF FF
*Mar 24 23:29:31.835: FF FF FB 14 B0 00

*Mar 24 23:29:49.423: FF 03 C0 21 01 11 00 0F 03 05 C2 23 05 05 06 5F
*Mar 24 23:29:49.423: 23 35 D4
are 0
*Mar 24 23:29:49.435: 0F 00 88 47 00 01 10 FF 00 01 61 02 00 15 00 00
*Mar 24 23:29:49.435: C0 21 01 2F 00 0F 03 05 C2 23 05 05 06 5F CC 5F
*Mar 24 23:29:49.435: E5
are 0
*Mar 24 23:29:49.435: 0F 00 88 47 00 01 10 FF 00 01 61 02 00 15 00 00
*Mar 24 23:29:49.435: C0 21 02 11 00 0F 03 05 C2 23 05 05 06 5F 23 35
*Mar 24 23:29:49.435: D4
*Mar 24 23:29:49.443: FF 03 C0 21 02 2F 00 0F 03 05 C2 23 05 05 06 5F
*Mar 24 23:29:49.443: CC 5F E5
*Mar 24 23:29:49.447: FF 03 C2 23 01 D0 00 1C 10 45 59 13 1A 92 FD 93
*Mar 24 23:29:49.447: 01 A2 CF B6 FB 3A 04 46 93 63 65 32 2D 67 73 72
are 0
*Mar 24 23:29:49.451: 0F 00 88 47 00 01 10 FF 00 01 61 02 00 22 00 00
*Mar 24 23:29:49.451: C2 23 01 F5 00 1C 10 F1 98 35 3F 79 F2 1A 15 10
*Mar 24 23:29:49.451: B4 C0 73 D7 B1 9F 2A 63 65 31 2D 67 73 72
are 0
*Mar 24 23:29:49.455: 0F 00 88 47 00 01 10 FF 00 01 61 02 00 22 00 00
*Mar 24 23:29:49.455: C2 23 02 D0 00 1C 10 56 4A 32 5B 99 55 D5 CF 44
*Mar 24 23:29:49.455: FC D3 D9 3F CC 8C A8 63 65 31 2D 67 73 72
*Mar 24 23:29:49.463: FF 03 C2 23 02 F5 00 1C 10 45 84 E4 E5 DD C0 5F
*Mar 24 23:29:49.463: FD 2F 37 63 9A 3D 03 7B B9 63 65 32 2D 67 73 72
*Mar 24 23:29:49.463: FF 03 C2 23 03 D0 00 04
are 0

May 2008 DB-1569
Debug Commands
*Mar 24 23:29:49.471: 0F 00 88 47 00 01 10 FF 00 01 61 02 00 0A 00 00
*Mar 24 23:29:49.471: C2 23 03 F5 00 04
are 0
*Mar 24 23:29:49.471: 0F 00 88 47 00 01 10 FF 00 01 61 02 00 10 00 00
*Mar 24 23:29:49.471: 80 21 01 0B 00 0A 03 06 78 01 01 78

DB-1570 May 2008
Debug Commands
debug mpls l2transport signaling

To display information about the Any Transport over MPLS (AToM) signaling protocol, use the debug
mpls l2transport signaling command in privileged EXEC mode. To disable debugging output, use the
debug mpls l2transport signaling {event | message}
no debug mpls l2transport signaling {event | message}
Syntax Description event Displays AToM signaling events.

message Displays AToM signaling status messages.

Examples The following is sample output from the debug mpls l2transport signaling command:
Router# debug mpls l2transport signaling event
AToM LDP event debugging is on
Router# debug mpls l2transport signaling message
AToM LDP message debugging is on
AToM:
AToM LDP event debugging is on
AToM LDP message debugging is on
*Mar 24 23:10:55.611: AToM LDP [9.9.9.9]: Allocate LDP instance

*Mar 24 23:10:55.611: AToM LDP [9.9.9.9]: Opening session, 1 clients
*Mar 24 23:10:56.063: %SYS-5-CONFIG_I: Configured from console by console
*Mar 24 23:10:56.583: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/0, changed
state to up

May 2008 DB-1571
Debug Commands
*Mar 24 23:11:00.539: AToM LDP [9.9.9.9]: Session is up

*Mar 24 23:11:00.539: AToM LDP [9.9.9.9]: Peer address change, add 1.1.1.100
*Mar 24 23:11:00.539: AToM LDP [9.9.9.9]: Sending label mapping msg
vc type 7, cbit 1, vc id 50, group id 6, vc label 21, status 0, mtu 1500
*Mar 24 23:11:00.539: AToM LDP [9.9.9.9]: Received label mapping msg, id 113
vc type 7, cbit 1, vc id 50, group id 6, vc label 21, status 0, mtu 1500

DB-1572 May 2008
Debug Commands
debug mpls l2transport vc

To display information about the status of the Any Transport over MPLS (AToM) virtual circuits (VCs),
use thedebug mpls l2transport vc command in privileged EXEC mode. To disable debugging output,
debug mpls l2transport vc {event | fsm | ldp | sss | status {event | fsm}}
no debug mpls l2transport vc {event | fsm | ldp | sss | status {event | fsm}}
Syntax Description event Displays AToM event messages about the VCs.
fsm Displays debug information related to the finite state machine (FSM).
ldp Displays debug information related to the Label Distribution Protocol (LDP).
sss Displays debug information related to the subscriber service switch (SSS).
status Displays debug information related to the status of the VCs.

12.2(33)SRC The command was updated to include the ldp, sss, and status keywords as
part of the MPLS Pseudowire Status Signaling feature.
Usage Guidelines You can issue this command from the line card or the route processor.
Examples The following is sample output from the debug mpls l2transport vc commands:
Router# debug mpls l2transport vc event
Router# debug mpls l2transport vc fsm

May 2008 DB-1573
Debug Commands
AToM:
*Mar 24 23:17:24.371: AToM MGR [10.9.9.9, 50]: Event provision, state changed from idle to
provisioned
*Mar 24 23:17:24.371: AToM MGR [10.9.9.9, 50]: Provision vc
*Mar 24 23:17:24.371: AToM SMGR [10.9.9.9, 50]: Requesting VC create, vc_handle 61A09930
*Mar 24 23:17:24.371: AToM MGR [10.9.9.9, 50]: Event local up, state changed from
provisioned to local standby
*Mar 24 23:17:24.371: AToM MGR [10.9.9.9, 50]: Update local vc label binding
*Mar 24 23:17:24.371: AToM SMGR [10.9.9.9, 50]: sucessfully processed create request
*Mar 24 23:17:24.875: %SYS-5-CONFIG_I: Configured from console by console
*Mar 24 23:17:25.131: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/0, changed
state to up
*Mar 24 23:17:28.567: AToM MGR [10.9.9.9, 50]: Event ldp up, state changed from local
standby to local ready
*Mar 24 23:17:28.567: AToM MGR [10.9.9.9, 50]: Advertise local vc label binding
*Mar 24 23:17:28.567: AToM MGR [10.9.9.9, 50]: Event remote up, state changed from local
ready to establishing
*Mar 24 23:17:28.567: AToM MGR [10.9.9.9, 50]: Remote end up
*Mar 24 23:17:28.567: AToM MGR [10.9.9.9, 50]: Event remote validated, state changed from
establishing to established
*Mar 24 23:17:28.567: AToM MGR [10.9.9.9, 50]: Validate vc, activating data plane
*Mar 24 23:17:28.567: AToM SMGR [10.9.9.9, 50]: Processing imposition update, vc_handle
61A09930, update_action 3, remote_vc_label 21
*Mar 24 23:17:28.567: AToM SMGR [10.9.9.9, 50]: Imposition Programmed, Output Interface:
PO5/0
*Mar 24 23:17:28.567: AToM SMGR [10.9.9.9, 50]: Processing disposition update, vc_handle
61A09930, update_action 3, local_vc_label 22
*Mar 24 23:17:28.571: AToM SMGR: Processing TFIB event for 10.9.9.9
*Mar 24 23:17:28.571: AToM SMGR [10.9.9.9, 50]: Imposition Programmed, Output Interface:
PO5/0
The following is sample output of MPLS Pseudowire Status Signaling messages from the debug mpls
l2transport vc status event and debug mpls l2transport vc status fsm commands:
Router# debug mpls l2transport vc status event
Router# debug mpls l2transport vc status fsm
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: Receive SSS STATUS(UP)

*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: AC status UP
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: S:Evt local up, LndRru->LnuRru
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: S:Evt local ready, LnuRru->LruRru
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: S:Act send label(UP)
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: Send label(UP)
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: Local AC : UP
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: Dataplane: no fault
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: Overall : no fault
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: Remote label is ready
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: S:Evt remote ready in LruRru
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: S:Evt remote up in LruRru
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: S:Evt dataplane clear fault in LruRru

DB-1574 May 2008
Debug Commands
The status codes in the messages, such as S: and LruRru, indicate the staus of the local and remote
routers. The following list translates the status codes:
Llocal router
Rremote router
r or nready (r) or not ready (n)
u or d up (u) or down (d) status
The output also includes these values:
DDataplane
SLocal shutdown

May 2008 DB-1575
Debug Commands
debug mpls ldp advertisements

To display information about the advertisement of labels and interface addresses to label distribution
protocol (LDP) peers, use the debug mpls ldp advertisements command in privileged EXEC mode. To
disable this feature, use the no form of this command.
debug mpls ldp advertisements [peer-acl acl] [prefix-acl acl]
no debug mpls ldp advertisements [peer-acl acl] [prefix-acl acl]
Syntax Description peer-acl acl (Optional) Limits the displayed advertisements to those for LDP peers
permitted by the access control list (acl).
prefix-acl acl (Optional) Limits the displayed advertisements to those for prefixes
permitted by the access control list (acl).
Defaults Displays information about advertisements to all LDP peers for all prefixes.

terminology.

DB-1576 May 2008
Debug Commands
Usage Guidelines Use this command to monitor the label and address advertisements to LDP peers.
Use the peer-acl or prefix-acl options separately or together to limit the information display to specific
LDP peers and/or specific prefixes.
Note This command monitors advertisement of non-LC-ATM labels (generic labels) only. Use the debug
mpls atm-ldp command to monitor LC-ATM activity.
Examples The following shows sample output from the debug mpls ldp advertisements command:
Router# debug mpls ldp advertisements
tagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 130.77.0.33

tagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 34.0.0.0/8, label 3 (#2)
Table 217 debug mpls ldp advertisements Field Descriptions
Field Description
tagcon: Identifies the source of the message as the label control subsystem.
peer a.b.c.d:e LDP identifier of the peer to which the advertisement was targeted.
(pp 0xnnnnnnnn) Identifier for the data structure used to represent the peer at the label
distribution level. Useful for correlating debug output.
advertise X Identifies what was advertised to the peereither an interface address
(a.b.c.d) or label binding (a.b.c.d/m, label t (#n)).
(#n) For a label binding advertisement, the sequence number of the label
information base (LIB) modification that made it necessary to advertise the
label.

May 2008 DB-1577
Debug Commands

debug mpls ldp Displays information about changes to the LIB used to keep track of label
bindings bindings learned from LDP peers through LDP downstream label
distribution.
show mpls ip binding Displays specified information about label bindings learned by LDP.
show mpls ldp Displays the status of LDP sessions.
neighbor

DB-1578 May 2008
Debug Commands
debug mpls ldp autoconfig

To enable the display of events related to Multiprotocol Label Switching (MPLS) Label Distribution
Protocol (LDP), use the debug mpls ldp autoconfig command in privileged EXEC mode. To disable
this feature, use the no form of this command.
debug mpls ldp autoconfig [interface interface]
no debug mpls ldp autoconfig [interface interface]
Syntax Description interface interface (Optional) Enables the display of autoconfiguration events for the specified
interface.

12.2(28)SB This command was integrated into Cisco IOS Releases 12.2(28)SB.
12.0(32)SY This command was updated to display IS-IS information.
Examples In the following example, the display of events related to MPLS LDP Autoconfiguration are enabled:
Router# debug mpls ldp autoconfig
00:06:06: LDP-AC: OSPF area 1 [flags 0x8, handle 0x1030110]:: Adding record
00:06:06: LDP-AC: OSPF area 1 [flags 0x8, handle 0x1030110]:: Received
enable request for Serial2/0
00:06:06: LDP-AC: OSPF area 1 [flags 0xA, handle 0x1030110]:: Adding record
to Serial2/0
00:06:06: LDP-AC: OSPF area 1 [flags 0xA, handle 0x1030110]:: Enqueued LDP
enable request on Serial2/0
00:06:06: LDP-AC: OSPF area 1 [flags 0x8, handle 0x1030110]:: Received
enable request for Tunnel1
00:06:06: LDP-AC: OSPF area 1 [flags 0xA, handle 0x1030110]:: Adding record
to Tunnel1
00:06:06: LDP-AC: OSPF area 1 [flags 0xA, handle 0x1030110]:: Enqueued LDP
enable request on Tunnel1
00:06:06: LDP-AC: Enabling LDP on interface Serial2/0
00:06:06: LDP-AC: Enabling LDP on interface Tunnel1

May 2008 DB-1579
Debug Commands
The following example shows events associated when an IS-IS instance, ISIS-1, is configured for
autoconfiguration:
Router# debug mpls ldp autoconfig
07:49:02: LDP-AC: ISIS level 1-2 [flags 0x8, handle 0x1AADBE0]:: Adding record
07:49:02: LDP-AC: ISIS level 1-2 [flags 0x8, handle 0x1AADBE0]:: Received enable request
for Et0/0; area/level=1
07:49:02: LDP-AC: ISIS level 1-2 [flags 0xA, handle 0x1AADBE0]:: Adding record to Et0/0
07:49:02: LDP-AC: ISIS level 1-2 [flags 0xA, handle 0x1AADBE0]:: Enqueued LDP enable
request on Et0/0
07:49:02: LDP-AC: Enabling LDP autoconfig on interface Et0/0
Note MPLS LDP Autoconfiguration for IS-IS is supported only in Cisco IOS Release 12.0(32)SY.

mpls ldp autoconfig Enables LDP on all interfaces that belong to an OSPF area.
show mpls ldp discovery Displays information about interfaces configured for LDP.

DB-1580 May 2008
Debug Commands
debug mpls ldp backoff

To display information about the label distribution protocol (LDP) backoff mechanism parameters, use
the debug mpls ldp backoff command in privileged EXEC mode. To disable this feature, use the no
no debug mpls ldp backoff

Usage Guidelines Use this command to monitor backoff parameters configured for LDP sessions.
Examples The following shows sample output from the debug mpls ldp backoff command:
Router# debug mpls ldp backoff
LDP session establishment backoff debugging is on
Router#
Jan 6 22:31:13.012: ldp: Backoff peer ok: 12.12.12.12:0; backing off; threshold/count 8/6

May 2008 DB-1581
Debug Commands
Jan 6 22:31:39.332: ldp: Update backoff rec: 12.12.12.12:0, threshold = 8, tbl ents 2
Jan 6 22:31:39.640: ldp: Update backoff rec: 12.12.12.12:1, threshold = 8, tbl ents 2
Table 218 debug mpls ldp backoff Field Descriptions
Field Description
ldp Identifies the Label Distribution Protocol.
Backoff peer ok: Identifies the LDP peer for which a session is being delayed because of a
a.b.c.d:n failure to establish a session due to incompatible configuration.
backing off; Indicates that a session setup attempt failed and the LSR is delaying its next
attempt (that is, is backing off).
threshold/count x/y Identifies a set threshold (x) and a count (y) that represents the time that has
passed since the last attempt to set up a session with the peer. The count is
incremented every 15 seconds until it reaches the threshold. When the count
equals the threshold, a fresh attempt is made to set up an LDP session with
the peer.
Update backoff rec Indicates that the backoff period is over and that it is time for another attempt
to set up an LDP session.
threshold = x Indicates the backoff time of x*15 seconds, for the next LDP session attempt
with the peer.
tbl ents 2 Indicates unsuccessful attempts to set up an LDP session with two different
LDP peers. In this example, attempts to set up sessions with LDP peers
12.12.12.12:0 and 12.12.12.12:1 are failing.

mpls ldp backoff Configures session setup delay parameters for the LDP backoff mechanism.
show mpls ldp backoff Displays information about the configured session setup backoff parameters
and any potential LDP peers with which session setup attempts are being
throttled.

DB-1582 May 2008
Debug Commands
debug mpls ldp bindings

To display information about addresses and label bindings learned from Label Distribution Protocol
(LDP) peers by means of LDP downstream unsolicited label distribution, use the debug mpls ldp
bindings command in privileged EXEC mode. To disable this feature, use the no form of this command.
debug mpls ldp bindings [filter] [peer-acl acl] [prefix-acl acl]
no debug mpls ldp bindings [filter] [peer-acl acl] [prefix-acl acl]
Syntax Description filter (Optional) Display information about LDP local label allocation filtering.
peer-acl acl (Optional) Limits the displayed binding information to that learned from
LDP peers permitted by the access control list (acl).
prefix-acl acl (Optional) Limits the displayed binding information to that learned for
prefixes permitted by the access control list (acl).
Command Default Displays information about all bindings learned from all LDP peers.

12.0(10)ST This command was modified to correspond to MPLS Internet Engineering
Task Force (IETF) command syntax and terminology.

May 2008 DB-1583
Debug Commands
12.2(33)SRC The filter keyword was added and the output of the command was updated
to display information about LDP local label allocation filtering.
Usage Guidelines Use this command to monitor label bindings and label switch router (LSR) addresses learned from LDP
peers.
Note This command monitors non-LC-ATM labels (generic labels) only. Use the debug mpls atm-ldp states
command to monitor LC-ATM activity.
Examples The following is sample output from the debug mpls ldp bindings command:
Router# debug mpls ldp bindings
tagcon:tibent(10.34.0.0/8):created; find route tags request

tagcon:tibent(10.34.0.0/8):label 3 (#2) assigned
tagcon:Assign peer id; 10.0.0.44:0:id 0
tagcon:10.0.0.44:0:10.0.0.44 added to addr<->ldp ident map
tagcon:tibent(10.0.0.44/32):rem label 3 from 10.0.0.44:0 added
tagcon:tibent(10.34.0.0/8):label 3 from 10.0.0.44:0 added
tagcon:tibent(10.107.0.0/8):created; remote label learned
Table 219 debug mpls ldp bindings Field Descriptions
Field Description
tibent(network/mask) Destination that has a label binding change.
created; reason An LIB entry has been created for the specified destination for the indicated
reason.
rem label ... Describes a change to the label bindings for the specified destination. The
change is for a label binding learned from the specified LDP peer.

DB-1584 May 2008
Debug Commands
Table 219 debug mpls ldp bindings Field Descriptions (continued)
Field Description
lcl label ... Describes a change to a locally assigned (incoming) label for the specified
destination.
(#n) Sequence number of the modification to the LIB corresponding to the local
label change.
a.b.c.d:n: e.f.g.h added The address e.f.g.h has been added to the set of addresses associated with
to addr<->ldp ident map LDP identifier a.b.c.d:n.
The following is output from the debug mpls ldp bindings command when LDP local label allocation
filtering is configured:
Router# debug mpls ldp
Router# debug mpls ldp bindings filter
LDP Local Label Filtering changes debugging is on
Router(config)# mpls ldp label
Router(config-ldp-lbl)# allocate global host-routes
Router(config-ldp-lbl)#
LDP LLAF: Enqueued work item to walk tib for all tables
LDP LLAF: Withdraw local label for 10.10.7.0
LDP LLAF: announce zero local and path labels: 10.10.7.0
Router(config-ldp-lbl)# no allocate global host-routes
LDP LLAF: Enqueued work item to walk tib for all tables
tib: get path labels: 10.1.1.1/32, tableid: 0, Et1/0, nh 10.10.7.2
LDP LLAF: 10.1.1.1 accepted, absence of filtering config
tagcon: announce labels for: 10.1.1.1/32; nh 10.10.7.2, Et1/0, inlabel 17, outlabel
imp-null (from 10.1.1.1:0), get path labels
tagcon: tibent(10.10.7.0/24): label 1 (#20) assigned
tagcon: announce labels for: 10.10.7.0/24; nh 0.0.0.0, Et1/0, inlabel imp-null, outlabel
unknown (from 0.0.0.0:0), get path labels

May 2008 DB-1585
Debug Commands
tagcon: announce labels for: 10.10.8.0/24; nh 0.0.0.0, Et2/0, inlabel imp-null, outlabel
unknown (from 0.0.0.0:0), get path labels
.
.
.
Router(config-ldp-lbl)# no mpls ldp label
Router(config-ldp-lbl)# end
Router# no debug mpls ldp bindings filter
Table 220 debug mpls ldp bindings Field Descriptions with LDP Local Label Allocation Filtering
Field Description
LDP LLAF Indicates that the messages apply to LDP local label allocation filtering.
Withdraw local label for Prefix 10.10.7.0 is not in the global routing table. LDP withdraws the label
10.10.7.0 and does not assign a local labels.
announce zero local and LDP does not announce local and path label for prefix 10.10.7.0.
path labels: 10.10.7.0
tagcon: announce labels The label control subsystem announces the next hop (nh) and labels for the
for: named prefix.
tib: get path labels: LDP LIB searches for the routing and forwarding path for the named prefix.
LDP LLAF: 10.1.1.1 LDP accepts the prefix. The prefix was found in the global table (or accepted
accepted; by the prefix list, if a prefix list was named as a filter).
tibent(network/mask) Destination that has a label binding change.

debug mpls atm-ldp states Displays information about label virtual circuit (lvc) state
transitions as they occur.
show mpls ldp bindings Displays the contents of the LIB.

DB-1586 May 2008
Debug Commands
debug mpls ldp checkpoint

Note Effective with Cisco IOS Release 12.2(33)SRA, the debug mpls ldp checkpoint command is replaced
by the debug mpls vpn ha command. See the debug mpls vpn ha command for more information.
To enable the display of Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP)
checkpoint debugging information, use the debug mpls ldp checkpoint command in privileged EXEC
mode. To disable the display of MPLS LDP checkpoint debugging information, use the no form of this
command.
no debug mpls ldp checkpoint
Defaults Debugging of MPLS LDP checkpointing is not enabled.

12.2(33)SRA This command was replaced by the debug mpls vpn ha command.
Usage Guidelines The following examples show sample output from the debug mpls ldp checkpoint command:
Sample Output on the Active Route Processor or PRE

Router# debug mpls ldp checkpoint
LDP Checkpointing events and errors debugging is on

LDP-CF: 0:3.3.3.3/32,20:: checkpointing local binding
LDP-CF: 0:3.3.3.3/32,20:: changing checkpoint state from none to add-send
LDP-CF: 0:3.3.3.3/32,20:: changing checkpoint state from add-send to add-wait
LDP-CF: received CF send-ack
LDP-CF: 0:3.3.3.3/32,20:: changing checkpoint state from add-wait to added

May 2008 DB-1587
Debug Commands
Sample Output on the Backup Route Processor or PRE

Router# debug mpls ldp checkpoint
LDP-CF: received 16-byte CF message: client 28 [0], ver 1, type 1

LDP-CF: 0:3.3.3.3/32,20:: adding checkpointed local binding
Table 221 describes the significant fields in the sample display shown above.
Table 221 debug mpls ldp checkpoint Command Field Descriptions
Field Description
0:3.3.3.3/32,20:: The table ID, prefix, prefix length, and label of the checkpointed label
binding.

show mpls ldp checkpoint Displays information about the LDP checkpoint system on the active
route processor.

DB-1588 May 2008
Debug Commands
debug mpls ldp graceful-restart

To display debugging information for Multiprotocol (MPLS) Label Distribution Protocol (LDP) Stateful
Switchover (SSO) Nonstop Forwarding (NSF) Support and Graceful Restart, use the debug mpls ldp
graceful-restart command in privileged EXEC mode. To disable the display of this debugging
no debug mpls ldp graceful-restart
Defaults The display of debugging information is not enabled.

Usage Guidelines This command shows events and errors related to LDP Graceful Restart.
Examples The following example shows sample output from the debug mpls ldp graceful-restart command. The
output shows that a session was lost. The status message show the events that happen during recovery of
the bindings.
Router# debug mpls ldp graceful-restart
LDP GR: GR session 10.110.0.10:0:: lost

LDP GR: down nbr 10.110.0.10:0:: created [1 total]
LDP GR: GR session 10.110.0.10:0:: bindings retained
LDP GR: down nbr 10.110.0.10:0:: added all 7 addresses [7 total]
LDP GR: down nbr 10.110.0.10:0:: state change (None -> Reconnect-Wait)
LDP GR: down nbr 10.110.0.10:0:: reconnect timer started [120000 msecs]
LDP GR: down nbr 10.110.0.10:0:: added to bindings task queue [1 entries]

May 2008 DB-1589
Debug Commands
LDP GR: searching for down nbr record (10.110.0.10:0, 10.2.0.10)

LDP GR: search for down nbr record (10.110.0.10:0, 10.2.0.10) returned 10.110.0.10:0
LDP GR: Added FT Sess TLV (Rconn 120000, Rcov 120000) to INIT msg to 10.110.0.10:0
LDP GR: Tagcon querying for up to 12 bindings update tasks
LDP GR: down nbr 10.110.0.10:0:: requesting bindings MARK for {10.110.0.10:0, 1}
LDP GR: down nbr 10.110.0.10:0:: removed from bindings task queue [0 entries]
LDP GR: Requesting 1 bindings update tasks [0 left in queue]
LDP GR: 2.0.0.0/8:: updating binding from 10.110.0.10:0, inst 1:: marking stale;
LDP GR: Received FT Sess TLV from 10.110.0.10:0 (fl 0x1, rs 0x0, rconn 120000, rcov
120000)
LDP GR: GR session 10.110.0.10:0:: allocated instance, 2
LDP GR: GR session 10.110.0.10:0:: established
LDP GR: GR session 10.110.0.10:0:: found down nbr 10.110.0.10:0
LDP GR: down nbr 10.110.0.10:0:: reconnect timer stopped
LDP GR: down nbr 10.110.0.10:0:: state change (Reconnect-Wait -> Recovering)
LDP GR: down nbr 10.110.0.10:0:: recovery timer started [120000 msecs]
%LDP-5-GR: GR session 10.110.0.10:0 (inst. 2): starting graceful recovery
%LDP-5-NBRCHG: LDP Neighbor 10.110.0.10:0 is UP
LDP GR: 2.0.0.0//8:: refreshing stale binding from 10.110.0.10:0, inst 1 -> inst 2
LDP GR: 10.43.0.0//16:: refreshing stale binding from 10.110.0.10:0, inst 1 -> inst 2
LDP GR: down nbr 10.110.0.10:0:: recovery timer expired
%LDP-5-GR: GR session 10.110.0.10:0 (inst. 2): completed graceful recovery
LDP GR: down nbr 10.110.0.10:0:: destroying record [0 left]
LDP GR: down nbr 10.110.0.10:0:: state change (Recovering -> Delete-Wait)
LDP GR: down nbr 10.110.0.10:0:: added to bindings task queue [1 entries]
LDP GR: Tagcon querying for up to 12 bindings update tasks
LDP GR: down nbr 10.110.0.10:0:: requesting bindings DEL for {10.110.0.10:0, 1}
LDP GR: down nbr 10.110.0.10:0:: removed from bindings task queue [0 entries]
LDP GR: Requesting 1 bindings update tasks [0 left in queue]
LDP GR: GR session 10.110.0.10:0:: released instance, 1
The debug output is formatted in three general ways.

LDP GR: GR session 10.110.0.10:0:: found down nbr 10.110.0.10:0
down nbr 10.110.0.10:0:: removed from bindings task queue [0 entries]

DB-1590 May 2008
Debug Commands
Table 222 describes the fields for the debug command output.
:
Table 222 debug mpls ldp graceful-restart Command Field Descriptions
Field Description
LDP GR Identifies LDP Graceful Restart application
GR session ID of the LDP session that is enabled for Graceful Restart.
10.110.0.10:0
found down nbr Describes the event that is happening to that LDP session.
10.110.0.10:0
down nbr Identifies the Down Neighbor record, which logs the state of a recently lost
10.110.0.10:0:: Graceful Restart session.
removed from bindings Describes the event that is happening to the recently lost Graceful Restart
task queue [0 entries] session.
2.0.0.0/8:: Identifies the Forwarding Equivalence Class (FEC) associated with the
remote label binding being modified. The FEC identifies the Label
Information Base (LIB) entry.
updating binding Lists the operation being performed on the remote label binding.
10.110.0.10:0, inst 1:: Identifies the LDP session during which the remote label binding was
marking stale; learned.

show mpls ldp graceful-restart Displays a summary of the LDP Graceful Restart status.

May 2008 DB-1591
Debug Commands
debug mpls ldp igp sync

To enable the display of events related to the Multiprotocol Label Switching (MPLS) Label Distribution
Protocol (LDP)-Interior Gateway Protocol (IGP) Synchronization feature, use the debug mpls ldp igp
sync command in privileged EXEC mode. To disable this feature, use the no form of this command.
debug mpls ldp igp sync [interface interface] [peer acl]
no debug mpls ldp igp sync [interface interface] [peer acl]
Syntax Description interface interface (Optional) Enables the display of LDP-IGP Synchronization events for the
specified interface.
peer acl (Optional) Enables the display of LDP-IGP Synchronization events for the
specified peer access control list (ACL).

12.0(32)S The command output was modified to display events related to the delay
timer on interfaces running Open Shortest Path First (OSPF) processes, if the
delay timer is configured.
12.0(32)SY The command output was modified to display events related to
synchronization on interfaces running Intermediate System-to-Intermediate
System (IS-IS) processes.
Examples The following example shows events related to MPLS LDP-IGP Synchronization on interfaces running
OSPF:
Router# debug mpls ldp igp sync
LDP-SYNC: Et0/0, OSPF 1: notify status (required, not achieved, no delay, holddown
infinite) internal status (achieved, timer running)
LDP-SYNC: E1/0, 10.0.0.1: Adj being deleted, sync_achieved goes down
LDP-SYNC: E1/0, OSPF 1: notify status (required, not achieved, delay, holddown infinite)
LDP-SYNC: Et0/0: Session already up and interface address advertised, sync_achieved comes
up.
LDP-SYNC: Et0/0, OSPF 1: notify status (required, achieved, no delay, holddown infinite)
The following example shows events associated when an IS-IS instance, ISIS-1, is configured for
Synchronization:

DB-1592 May 2008
Debug Commands
07:59:27: LDP-SYNC: Et0/0, OSPF 1: notify status (required, not achieved, no delay,
holddown infinite) internal status (achieved, timer running)
07:59:27: LDP-SYNC: Enqueue request req_type 0 IGP ISIS ISIS-1 interface none.
07:59:27: LDP-SYNC: ISIS ISIS-1: SYNC enabled, added to global tree, informed IGP.
07:59:27: LDP-SYNC: Enqueue request req_type 3 IGP ISIS ISIS-1 interface Et0/0.
07:59:27: LDP-SYNC: Enqueue request req_type 3 IGP ISIS ISIS-1 interface Et0/0.
07:59:27: LDP-SYNC: Et0/0, ISIS ISIS-1: Added to per-interface IGP list.
07:59:27: LDP-SYNC: Et0/0: Enabled for SYNC by IGP
07:59:27: LDP-SYNC: Et0/0, ISIS ISIS-1: notify status (required, not achieved, delay,
holddown infinite)
07:59:27: LDP-SYNC: Et0/0, ISIS ISIS-1: Ignore IGP enable-interface request: already
enabled.
Table 223 debug mpls ldp igp sync Field Descriptions
Field Description
sync_achieved The first line of the output for an interface shows the status of the MPLS
LDP-IGP Synchronization in relation to the status of the interface.
notify status The notify status shows the following MPLS LDP-IGP Synchronization
information for each interface:
If LDP-IGP Synchronization is required.
If LDP-IGP Synchronization has been achieved.
If the IGP should wait for LDP Synchronization to be achieved.
The length of time the IGP should wait for the LDP Synchronization to
be achieved.
internal status The internal status displays LDP internal synchronization status and the state
of the timer. The internal status can be achieved or not achieved. The timer
state can be running or not running.
The following example shows events associated with MPLS LDP-IGP Synchronization on interfaces
running OSPF when you have configured a delay timer:
*Jan 3 04:38:49.571: LDP-SYNC: Et0/0, OSPF 1: notify status (required, not achieved, no
delay, holddown infinite) internal status (achieved, timer running)
!
*Jan 3 04:38:49.571: LDP-SYNC: Et0/0, OSPF 1: Sync disabled by IGP. Stop delay timer
*Jan 3 04:38:49.571: LDP-SYNC: Et0/0, OSPF 1: TAGSW subblock destroyed. Stop delay timer
*Jan 3 04:38:49.571: LDP-SYNC: Et0/0, OSPF 1: Sync down. Stop delay timer
*Jan 3 04:38:49.571: LDP-SYNC: Et0/0, OSPF 1: Delay notifying IGP of sync achieved for 60
seconds
*Jan 3 04:38:49.571: LDP-SYNC: Et0/0, OSPF 1: Delay timer expired, notify IGP of sync
achieved
*Jan 3 04:38:49.571: LDP-SYNC: Et0/0, OSPF 1: Delay timer expired but sync is no longer
required won't notify IGP of sync achieved
*Jan 3 04:38:49.571: LDP-SYNC: Et0/0, OSPF 1: Delay timer expired but sync is down won't
notify IGP of sync achieved

May 2008 DB-1593
Debug Commands

mpls ldp sync Enables LDP-IGP Synchronization on all interfaces that belong to an
OSPF process or IS-IS process.
show mpls ldp igp sync Displays information about interfaces configured for LDP-IGP
Synchronization.

DB-1594 May 2008
Debug Commands
debug mpls ldp messages

To display specific information (such as message type, source, and destination) regarding label
distribution protocol (LDP) messages sent to and received from LDP peers, use the debug mpls ldp
messages command in privileged EXEC mode. To disable this feature, use the no form of this command.
debug mpls ldp messages {sent | received} [all] [peer-acl acl]
no debug mpls ldp messages {sent | received} [all] [peer-acl acl]
Syntax Description sent Displays LDP messages sent to LDP peers permitted by the access control
list (acl).
received Displays LDP messages received from LDP peers permitted by the access
control list (acl).
all (Optional) Displays all LDP messages sent to and received from LDP peers
(including periodic KeepAlive messages) permitted by the access control list
(acl).
peer-acl acl (Optional) Limits the messages displayed for LDP peers in accordance with
the access control list (acl).
Defaults All messages sent (for sent keyword) or received (for received keyword) are displayed except for
periodic KeepAlive messages.

terminology.

May 2008 DB-1595
Debug Commands
Usage Guidelines LDP requires periodic transmission of KeepAlive messages. If you do not specify the all option, periodic
KeepAlive messages are not displayed.
Examples The following shows sample output from the debug mpls ldp messages received command:
Router# debug mpls ldp messages received
Router# debug mpls ldp messages sent
ldp: Rcvd init msg from 144.0.0.44 (pp 0x0)

ldp: Sent init msg to 144.0.0.44:0 (pp 0x0)
ldp: Sent keepalive msg to 144.0.0.44:0 (pp 0x0)
ldp: Rcvd keepalive msg from 144.0.0.44:0 (pp 0x0)
ldp: Sent address msg to 144.0.0.44:0 (pp 0x610F00E0)
ldp: Sent label mapping msg to 144.0.0.44:0 (pp 0x610F00E0)
ldp: Rcvd address msg from 144.0.0.44:0 (pp 0x610F00E0)
ldp: Rcvd label mapping msg from 144.0.0.44:0 (pp 0x610F00E0)
Table 224 debug mpls ldp messages received Field Descriptions
Field Description
ldp: Identifies the source of the displayed information as LDP.
Rcvd xxx msg Type of message received or sent.
Sent xxx msg
from a.b.c.d Host that sent the message. Used in the early stages of the opening of an LDP
session, when the LDP identifier is not yet known.
from a.b.c.d:e LDP identifier of the peer that sent the message or to which the message was
sent.
to a.b.c.d:e
(pp 0xnnnnnnnn) Identifies the data structure used to represent the peer at the label distribution
level. Useful for correlating debug output.

DB-1596 May 2008
Debug Commands

debug mpls ldp session Displays the contents of LDP messages sent to and received from LDP peers.
io

May 2008 DB-1597
Debug Commands
debug mpls ldp peer state-machine

To display information about state transitions for label distribution protocol (LDP) sessions, use the
debug mpls ldp peer state-machine command in privileged EXEC mode. To disable this feature, use
no debug mpls ldp peer state-machine

terminology.
Usage Guidelines LDP manages peer sessions by means of two coupled state machines:
A low-level state machine that deals with session establishment and shutdown
A high-level state machine that deals with setting up and shutting down label advertisement

DB-1598 May 2008
Debug Commands
Use the debug mpls ldp session state-machine command to monitor the lower-level session state
machine.
Use the debug mpls ldp peer state-machine command to monitor the higher-level session state
machine.
Examples The following shows sample output from the debug mpls ldp peer state-machine command:
Router# debug mpls ldp peer state-machine
tagcon: start session TCP timers for 144.0.0.44:0 (pp 0x610EEC84)

tagcon: Enqueue peer up work for 144.0.0.44:0 (pp 0x610EEC84)
tagcon: peer 144.0.0.44:0 (pp 0x610EEC84): Event unsol open
unsol op pdg -> estab
tagcon: Send initial advertisements to peer 144.0.0.44:0
tagcon: Initial address advertisement to peer 144.0.0.44:0
tagcon: Initial label advertisement to peer 144.0.0.44:0
...
tagcon: peer 144.0.0.44:0 (pp 0x610EEC84): Event down
estab -> destroyed
tagcon: peer 144.0.0.44:0 (pp 0x610EEC84): Event cleanup done
destroyed -> non-ex
Table 225 debug mpls ldp peer state-machine Field Descriptions
Field Description
a.b.c.d:e LDP identifier of the peer for the session with the state change.
(pp 0xnnnnnnnn) Address of the data structure used to represent the peer at the label
distribution level. This address is useful for correlating debug output.
Event E Event causing the state change.
s1 -> s2 State of the LDP session has changed from state s1 to state s2.

debug mpls ldp session Displays information about LDP messages sent to or received from LDP
io peers.
show mpls ldp Displays the status of LDP sessions.
neighbor

May 2008 DB-1599
Debug Commands
debug mpls ldp prev-label

To display debug information when a local label binding associated with a prefix is withdrawn and freed,
use the debug mpls ldp prev-label command in privileged EXEC mode. To disable debugging output,
debug mpls ldp prev-label [prefix-acl acl [peer-acl acl]
no debug mpls lad prev-label [prefix-acl acl [peer-acl acl]
Syntax Description prefix-acl acl (Optional) Limits the displayed binding information to that allocated for
prefixes permitted by a prefix access control list (ACL).
peer-acl acl (Optional) Limits the displayed binding withdraw information to those Label
Distribution Protocol (LDP) peers permitted by a peer ACL.
Command Default Debugging of previous local label binding changes is disabled.

Usage Guidelines Use this command to monitor LDP information when a local label binding associated with a prefix is
withdrawn and freed. LDP withdraws a previously advertised label before advertising a new label.
If you enter the debug mpls ldp prev-label command without an optional keyword and argument, the
command displays output for all previous label binding changes. Use the prefix-acl acl or peer-acl acl
keywords and arguments to limit the output to prefixes defined by the respective ACLs.
Examples The following is sample output from the debug mpls ldp prev-label command:
Router# debug mpls ldp prev-label
tagcon: Changing state to WITHDRAWN for prefix=10.0.1.1, label31

tagcon: Creating prev_lbl_info for prefix=10.0.1.1, label31
tagcon: noroute hold timer expired for 10.0.1.1/255.255.255.255, tag withdrawn, seqno 47
tagcon: tibent(10.0.1.1/32): label 32 from 10.0.0.2:0 removed
tagcon: Deleting prev label info for prefix = 10.0.1.1, tag = 31

DB-1600 May 2008
Debug Commands
Table 226 debug mpls ldp prev-label Field Descriptions
Field Description
tagcon: Identifies the source of the message as the label control
subsystem.
Changing state to WITHDRAWN Describes the label binding change; in this case, the label is
to be withdrawn.
for prefix=10.0.1.1 The prefix (10.0.1.1) from which the local label binding is to
be withdrawn and freed.
label31 The local label binding (31) that is to be withdrawn from the
prefix.
tibent(10.0.1.1/32) The hostname, network, and mask for the destination that has
a label binding change.

debug mpls ldp bindings Displays information about addresses and label bindings learned
from LDP peers by means of LDP downstream unsolicited label
distribution.

May 2008 DB-1601
Debug Commands
debug mpls ldp session io

To display the contents of label distribution protocol (LDP) messages sent to and received from LDP
peers, use the debug mpls ldp session io command in privileged EXEC mode. To disable this feature,
debug mpls ldp session io [all] [peer-acl acl]
no debug mpls ldp session io [all] [peer-acl acl]
Syntax Description all (Optional) Includes the contents of periodic KeepAlive messages in the
displayed message output to LDP peers.
peer-acl acl (Optional) Limits the displayed message output to those LDP peers permitted
by the access control list (acl).
Defaults Displays the contents of LDP messages sent and received except for periodic KeepAlive messages.

terminology.
Usage Guidelines Displays the contents of all messages sent and received except for periodic KeepAlive messages.

DB-1602 May 2008
Debug Commands
Examples The following shows sample output from the debug mpls ldp session io command:
Router# debug mpls ldp session io all
ldp: Rcvd init msg from 144.0.0.44 (pp 0x0)

ldp: LDP init msg: PDU hdr: LDP Id: 144.0.0.44:0; Msg Contents:
0x00 0x01 0x00 0x20 0x90 0x00 0x00 0x2C 0x00 0x00 0x02 0x00 0x00 0x16 0x00 0x00
0x10 0x21 0x05 0x00 0x00 0x0E 0x00 0x01 0x00 0xB4 0x00 0x00 0x00 0x00 0x85 0x00
0x00 0x21 0x00 0x00
ldp: Sent init msg to 144.0.0.44:0 (pp 0x0)
ldp: LDP init msg: PDU hdr: LDP Id: 133.0.0.33:0; Msg Contents:
0x00 0x01 0x00 0x20 0x85 0x00 0x00 0x21 0x00 0x00 0x02 0x00 0x00 0x16 0x00 0x00
0x06 0x32 0x05 0x00 0x00 0x0E 0x00 0x01 0x00 0xB4 0x00 0x00 0x00 0x00 0x90 0x00
0x00 0x2C 0x00 0x00
ldp: Sent keepalive msg to 144.0.0.44:0 (pp 0x0)
ldp: LDP keepalive msg: PDU hdr: LDP Id: 133.0.0.33:0; Msg Contents:
0x00 0x01 0x00 0x0E 0x85 0x00 0x00 0x21 0x00 0x00 0x02 0x01 0x00 0x04 0x00 0x00
0x06 0x33
ldp: Rcvd keepalive msg from 144.0.0.44:0 (pp 0x0)
ldp: LDP keepalive msg: PDU hdr: LDP Id: 144.0.0.44:0; Msg Contents:
0x00 0x01 0x00 0x0E 0x90 0x00 0x00 0x2C 0x00 0x00 0x02 0x01 0x00 0x04 0x00 0x00
0x10 0x22
ldp: Sent address msg to 144.0.0.44:0 (pp 0x610ECDD0)
ldp: LDP address msg: PDU hdr: LDP Id: 133.0.0.33:0; Msg Contents:
0x00 0x01 0x00 0x34 0x85 0x00 0x00 0x21 0x00 0x00 0x03 0x00 0x00 0x2A 0x00 0x00
0x06 0x34 0x01 0x01 0x00 0x22 0x00 0x01 0x02 0x00 0x00 0xA3 0x82 0x42 0x00 0x21
0x82 0x4D 0x00 0x21 0x85 0x00 0x00 0x21 0x22 0x00 0x00 0x21 0x67 0x00 0x00 0x21
0x23 0x00 0x00 0x21 0x26 0x00 0x00 0x21
ldp: Sent label mapping msg to 144.0.0.44:0 (pp 0x610ECDD0)
ldp: LDP label mapping msg: PDU hdr: LDP Id: 133.0.0.33:0; Msg Contents:
0x00 0x01 0x00 0x22 0x85 0x00 0x00 0x21 0x00 0x00 0x04 0x00 0x00 0x18 0x00 0x00
0x06 0x36 0x01 0x00 0x00 0x08 0x02 0x00 0x01 0x20 0xCB 0x00 0x07 0x07 0x02 0x00
0x00 0x04 0x00 0x00 0x00 0x18
ldp: Rcvd address msg from 144.0.0.44:0 (pp 0x610ECDD0)
ldp: LDP address msg: PDU hdr: LDP Id: 144.0.0.44:0; Msg Contents:
0x00 0x01 0x00 0x24 0x90 0x00 0x00 0x2C 0x00 0x00 0x03 0x00 0x00 0x1A 0x00 0x00
0x10 0x23 0x01 0x01 0x00 0x12 0x00 0x01 0x90 0x00 0x00 0x2C 0x02 0x00 0x00 0xA4
0x22 0x00 0x00 0x2C 0x2D 0x00 0x00 0x2C
ldp: Rcvd label mapping msg from 144.0.0.44:0 (pp 0x610ECDD0)
ldp: LDP label mapping msg: PDU hdr: LDP Id: 144.0.0.44:0; Msg Contents:
0x00 0x01 0x00 0x22 0x90 0x00 0x00 0x2C 0x00 0x00 0x04 0x00 0x00 0x18 0x00 0x00
0x10 0x24 0x01 0x00 0x00 0x08 0x02 0x00 0x01 0x20 0x90 0x00 0x00 0x2C 0x02 0x00
0x00 0x04 0x00 0x00 0x00 0x03
Table 227 debug mpls ldp session io Field Descriptions
Field Description
ldp: Identifies the source of the message as LDP.
Rcvd xxx msg Indicates that a message of the specified type has been received.
from a.b.c.d Host to which the message has been sent. Used in the early stages of the
opening of an LDP session when the LDP identifier is not yet known.
Sent xxx msg Indicates that a message of the specified type has been sent.
to a.b.c.d Host to which the message has been sent. Used in the early stages of the
opening of an LDP session when the LDP identifier is not yet known.
to a.b.c.d:e LDP identifier of the peer to which the message has been sent.

May 2008 DB-1603
Debug Commands
Table 227 debug mpls ldp session io Field Descriptions (continued)
Field Description
(pp 0xnnnnnnnn) Identifies the data structure used to represent the peer at the label distribution
level. Useful for correlating debug output.
LDP xxx msg Type of message that has been sent.
PDU hdr: LDP Id: LDP identifier of the sender included in the LDP protocol data unit (PDU)
a.b.c.d:e header.
Msg contents: 0xnn ... Contents of the message represented as a sequence of bytes.
0xnn

debug mpls ldp session Displays information about state transitions for LDP sessions.
state-machine

DB-1604 May 2008
Debug Commands
debug mpls ldp session protection
debug mpls ldp session protection

To enable the display of events related to MPLS LDP Session Protection, use the debug mpls ldp session
protection command in privileged EXEC mode. To disable this feature, use the no form of this
command.
debug mpls ldp session protection [peer-acl acl]
no debug mpls ldp session protection [peer-acl acl]
Syntax Description peer-acl acl (Optional) Enables the display of events for the peers whose router IDs are
listed in the access control list.

Examples In the following example, the display of events related to MPLS LDP-IGP Synchronization are enabled:
Router# debug mpls ldp session protection

clear mpls ldp neighbor Forcibly resets an LDP session.
show mpls ldp neighbor Displays the contents of the LDP.

May 2008 DB-1605
Debug Commands
debug mpls ldp session state-machine

To display information about state transitions for label distribution protocol (LDP) sessions, use the
debug mpls ldp session state-machine command in privileged EXEC mode. To disable this feature, use
debug mpls ldp session state-machine [peer-acl acl]
no debug mpls ldp session state-machine [peer-acl acl]
Syntax Description peer-acl acl (Optional) Limits the displayed information to that for LDP peers permitted

terminology.
Usage Guidelines LDP manages peer sessions by means of two coupled-state machines:
A low-level state machine that deals with session establishment and shutdown
A high-level state machine that deals with setting up and shutting down label advertisement

DB-1606 May 2008
Debug Commands
Use the debug mpls ldp session state-machine command to monitor the lower-level session state
machine.
Use the debug mpls ldp peer state-machine command to monitor the higher-level session state
machine.
Examples The following shows sample output from the debug mpls ldp session state-machine command:
Router# debug mpls ldp session state-machine
ldp: ptcl_adj:144.0.0.44(0x610EED30): Non-existent -> Role pasv

ldp: create ptcl_adj: tp = 0x610EED30, ipaddr = 144.0.0.44
ldp: ptcl_adj:144.0.0.44(0x610EED30): Event: Xport opened;
Role pasv -> Role pasv
ldp: ptcl_adj:34.0.0.44(0x610EED30): Event: Rcv Init;
Role pasv -> Init rcvd pasv
ldp: ptcl_adj:34.0.0.44(0x610EED30): Event: Rcv KA;
Init rcvd pasv -> Oper
ldp: ptcl_adj:unknown(0x610EED30): Event: Xport closed;
Oper -> Non-existent
Table 228 debug mpls ldp session state-machine Field Descriptions
Field Description
ptcl_adj:a.b.c.d Identifies the network address of the LDP peer.
(0xnnnnnnnn) Identifies the data structure used to represent the peer at the protocol level.
Useful for correlating debug output.
Event: E Event that caused the state transition.
s1 -> s2 State of the LDP session has changed from state s1 to state s2.

debug mpls ldp peer Displays information about state transitions for LDP sessions.
state-machine

May 2008 DB-1607
Debug Commands
debug mpls ldp targeted-neighbors

To display information about the target neighbor mechanism, use the debug mpls ldp
targeted-neighbors command in privileged EXEC mode. This mechanism establishes label distribution
protocol (LDP) adjacencies to peers that are not directly adjacent, such as peers at either end of a tunnel.
To disable this feature, use the no form of this command.
no debug mpls ldp targeted-neighbors

terminology.
Usage Guidelines Platforms that are not directly connected may engage in LDP label distribution (for example, to support
two-level labeling across an LSP tunnel).

DB-1608 May 2008
Debug Commands
An LDP session between nondirectly connected label switch routers (LSRs) is called a targeted session
and is supported by LDP extended discovery which uses targeted Hello messages sent to specific IP
addresses.
An LSR (Router 1) attempting to initiate an LDP targeted session with another LSR (Router 2) sends
targeted Hello messages sent to a specific IP address of Router 2. If the configuration of Router 2 permits
it to respond to targeted Hello messages from Router 1, it does so, and the LDP session can be
established. In this situation, Router 1 is said to be an active LSR for the targeted session because it
initiated the targeted Hello messages; Router 2 is said to be a passive LSR for the session because it
responded to them.
As with LDP sessions between two directly connected LSRs, it is possible for a targeted session to be
the result of multiple discovery activities which are targeted to different IP addresses for the same LSR.
In addition, it is possible for both LSRs in a targeted session to be active and for both to be passive.
The debug messages enabled by debug mpls ldp targeted-neighbors report activity relating to targeted
sessions.
Examples The following shows sample output from the debug mpls ldp targeted-neighbors command:
Router# debug mpls ldp targeted-neighbors
ldp-trgtnbr: 144.0.0.44 Req active

ldp-trgtnbr: 144.0.0.44 allocated
ldp-trgtnbr: 144.0.0.44 Set peer start; flags 0x0
ldp-trgtnbr: 144.0.0.44 Defer peer cleanup; cleancnt 1
ldp-trgtnbr: 144.0.0.44 Set peer finished; flags 0xF
ldp-trgtnbr: 144.0.0.44 ref count incremented to 1
ldp-trgtnbr: 144.0.0.44 Release active; ref count decremented to 0
ldp-trgtnbr: 144.0.0.44 Clear peer start; flags 0xF
ldp-trgtnbr: 144.0.0.44 Undefer cleanup start; clearcnt 0, flags 0xC
ldp-trgtnbr: 144.0.0.44 Undefer cleanup finish; clearcnt 0, flags 0x8
ldp-trgtnbr: 144.0.0.44 Clear peer finished; flags 0x8
ldp-trgtnbr: 144.0.0.44 freed
Table 229 debug mpls ldp targeted-neighbors Field Descriptions
Field Description
ldp-trgtnbr: Identifies this as an LDP targeted neighbor debug statement.
144.0.0.44 IP address for the targeted neighbor.

show mpls ldp Displays the status of LDP protocol sessions.
neighbor

May 2008 DB-1609
Debug Commands
debug mpls ldp transport connections

To display information about the Transmission Control Protocol (TCP) connections used to support label
distribution protocol (LDP) sessions, use the debug mpls ldp transport connections command in
privileged EXEC mode. To disable this feature, use the no form of this command.
debug mpls ldp transport connections [peer-acl acl] [interface interface]
no debug mpls ldp transport connections [peer-acl acl] [interface interface]
interface interface (Optional) Limits the displayed information to that for the specified
interface.
Defaults Display information about LDP TCP connection activity for all peers and all interfaces.

terminology.

DB-1610 May 2008
Debug Commands
Usage Guidelines Use this command to monitor LDP activity relating to the establishment of the transport (TCP)
connection for LDP sessions.
When two devices establish a TCP connection for an LDP session, the device with the larger transport
address plays an active role and the other plays a passive role. The active device attempts to establish a
TCP connection to the well-known LDP port at the passive device. The passive device waits for the
connection to the well-known port to be established.
Examples The following shows sample output from the debug mpls ldp transport connections command:
Router# debug mpls ldp transport connections
Debug output at active peer:
ldp: Opening listen port 646 for 144.0.0.44, 34.0.0.44

ldp: Open LDP listen TCB 0x60E105BC; lport = 646; fhost = 144.0.0.44
ldp: Add listen TCB to list; tcb 0x60E105BC; addr 144.0.0.44
ldp: Incoming ldp conn 133.0.0.33:646 <-> 144.0.0.44:11042
ldp: create ptcl_adj: tp = 0x610ECD64, ipaddr = 144.0.0.44
Debug output at passive peer:
ldp: Opening ldp conn; adj 0x60BAC33C, 144.0.0.44 <-> 133.0.0.33

ldp: ldp conn is up; adj 0x60BAC33C, 144.0.0.44:11042 <-> 133.0.0.33:646
Table 230 debug mpls ldp transport connections Field Descriptions
Field Description
adj 0xnnnnnnnn Identifies the data structure used to represent the peer at the transport level.
a.b.c.d -> p.q.r.s Indicates a TCP connection between a.b.c.d and p.q.r.s.
a.b.c.d:x -> p.q.r.s:y Indicates a TCP connection between a.b.c.d, port x and p.q.r.s, port y.

debug mpls ldp Prints information about the events related to the LDP peer discovery
transport events mechanism.

May 2008 DB-1611
Debug Commands
debug mpls ldp transport events

To display information about events related to the label distribution protocol (LDP) peer discovery
mechanism, use the debug mpls ldp transport events command in privileged EXEC mode. This
mechanism is used to determine the devices with which you wish to establish LDP sessions. To disable
this feature, use the no form of this command.
debug mpls ldp transport events [peer-acl acl] [interface]
no debug mpls ldp transport events [peer-acl acl] [interface]
interface (Optional) Limits the displayed information to that for the specified
interface.
Defaults Displays information about LDP discovery activity for all peers and all interfaces.

terminology.

DB-1612 May 2008
Debug Commands
Usage Guidelines Use this command to monitor LDP discovery activity.

This command might generate a great deal of output. Use the peer-acl option or interface option, or
both, to limit the output to peers or interfaces of interest.
Note The command includes all of the output generated by the debug mpls ldp transport connection
command.
Examples The following shows sample output from the debug mpls ldp transport events command:
Router# debug mpls ldp transport events
ldp: enabling ldp on Ethernet1/1/1

ldp: Set intf id: intf 0x611D684C, Ethernet1/1/1, not lc-atm, intf_id 0
ldp: Set intf id: intf 0x617C5638, ATM0/0.2, not lc-atm, intf_id 0
ldp: Send ldp hello; ATM3/0.1, src/dst 8.1.1.1/224.0.0.2, inst_id 1, tcatm
ldp: Rcvd ldp hello; ATM3/0.1, from 203.0.7.7 (203.0.7.7:2), intf_id 1, opt 0x8, tcatm
ldp: Send ldp hello; Ethernet1/1/1, src/dst 138.1.0.88/224.0.0.2, inst_id 0
ldp: Rcvd ldp hello; Ethernet1/1/1, from 10.105.0.9 (7.1.1.1:0), intf_id 0, opt 0xC
ldp: ldp Hello from 10.105.0.9 (7.1.1.1:0) to 224.0.0.2, opt 0xC
ldp: New adj 0x617C5EBC from 10.105.0.9 (7.1.1.1:0), Ethernet1/1/1
ldp: Opening ldp conn; adj 0x617C5EBC, 8.1.1.1 <-> 7.1.1.1
ldp: ldp conn is up; adj 0x617C5EBC, 8.1.1.1:11013 <-> 7.1.1.1:646
ldp: Send ldp hello; ATM3/0.1, src/dst 8.1.1.1/224.0.0.2, inst_id 1, tcatm
ldp: Rcvd ldp hello; Ethernet1/1/1, from 10.105.0.9 (7.1.1.1:0), intf_id 0, opt 0xC
...
ldp: Send ldp hello; ATM3/0.1, src/dst 8.1no tag ip
.0.2, inst_id 1, tcatm
ldp: disabling ldp on Ethernet1/1/1
ldp: Hold timer expired for adj 0x617C5EBC, will close conn
ldp: Closing ldp conn 8.1.1.1:11013 <-> 7.1.1.1:646, adj 0x617C5EBC
ldp: Adjacency 0x617C5EBC, 10.105.0.9 timed out
ldp: Adj 0x617C5EBC; state set to closed
ldp: Ignore Hello from 10.105.0.9, Ethernet1/1/1; no intf
Table 231 debug mpls ldp transport events Field Descriptions
Field Description
adj 0xnnnnnnnn Identifies the data structure used to represent the peer at the transport level.
a.b.c.d (p.q.r.s:n) Network address and LDP identifier of the peer.

May 2008 DB-1613
Debug Commands
Table 231 debug mpls ldp transport events Field Descriptions
Field Description
intf_id Interface identifier (non-zero for LC-ATM interfaces; 0 otherwise).
opt 0xn Bits that describe options in the LDP discovery Hello packet:
0x1Targeted Hello option
0x2Send targeted Hello option
0x4Transport address option
0x8LDP Hello message (as opposed to TDP Hello message)

debug mpls ldp Displays information about the TCP connections used to support LDP
transport connections sessions.
show mpls ldp Displays the status of the LDP discovery process.
discovery

DB-1614 May 2008
Debug Commands
debug mpls lfib cef
debug mpls lfib cef

To print detailed information about label rewrites being created, resolved, and deactivated as Cisco
Express Forwarding (CEF) routes are added, changed, or removed, use the debug mpls lfib cef
debug mpls lfib cef
no debug mpls lfib cef

CLI syntax.
Usage Guidelines Several lines of output are produced for each route placed into the label-forwarding information base
(LFIB). If your router has thousands of labeled routes, be careful about issuing this command. When
label switching is first enabled, each of these routes is placed into the LFIB, and several lines of output
are displayed for each route.
Examples The following is sample output from the debug mpls lfib cef command:
Router# debug mpls lfib cef
Cisco Express Forwarding related TFIB services debugging is on
tagcon: tc_ip_rtlookup fail on 10.0.0.0/8:subnet_lookup failed

TFIB: route tag chg 10.7.0.7/32,idx=1,inc=Withdrn,outg=Withdrn,enabled=0x2
TFIB: fib complete delete: prefix=10.7.0.7/32,inc tag=26,delete_info=1
TFIB: deactivate tag rew for 10.7.0.7/32,index=0
TFIB: set fib rew: pfx 10.7.0.7/32,index=0,add=0,tag_rew->adj=Ethernet2/3
TFIB: resolve tag rew,prefix=10.7.0.7/32,no tag_info,no parent
TFIB: fib scanner start:needed:1,unres:0,mac:0,loadinfo:0
TFIB: resolve tag rew,prefix=10.7.0.7/32,no tag_info,no parent
TFIB: fib upd loadinf 10.100.100.100/32,tag=Tun_hd,fib no loadin,tfib no loadin

May 2008 DB-1615
Debug Commands
debug mpls lfib cef
TFIB: fib check cleanup for 10.100.100.100/32,index=0,return_value=0

TFIB: fib_scanner_end
TFIB: create dynamic entry for 10.11.0.11/32
TFIB: call find_route_tags,dist_method=1,next_hop=10.93.0.11,Et2/3
TFIB: route tag chg 10.11.0.11/32,idx=0,inc=26,outg=Unkn,enabled=0x3
TFIB: create tag info 10.11.0.11/32,inc tag=26,has no info
TFIB: resolve tag rew,prefix=10.11.0.11/32,has tag_info,no parent
TFIB: finish fib res 10.11.0.11/32:index 0,parent outg tag no parent
TFIB: fib upd loadinf 10.11.0.11/32,tag=26,fib no loadin,tfib no loadin
tagcon: route_tag_change for: 10.250.0.97/32
intag 33, outtag 28, nexthop tsr 10.11.0.11:0
TFIB: route tag chg 10.250.0.97/32,idx=0,inc=33,outg=28,enabled=0x3
TFIB: create tag info 10.250.0.97/32,inc tag=33,has old info
On VIP:
TFIB: route tag chg 10.13.72.13/32,idx=0,inc=34,outg=Withdrn,enabled=0x3
TFIB: set fib rew: pfx 10.13.72.13/32,index=0,add=0,tag_rew->adj=
TFIB: set fib rew: pfx 10.100.100.100/32,index=0,add=0,tag_rew->adj=
TFIB: fib upd loadinf 10.100.100.100/32,tag=37,fib no loadin,tfib no loadin
Table 232 lists the significant fields shown in the display.

See Table 234 for a description of special labels that appear in the output of this debug command.
Table 232 debug mpls lfib cef Field Descriptions
Field Description
tagcon The name of the subsystem issuing the debug output (Label Control).
LFIB The name of the subsystem issuing the debug output.
tc_ip_rtlookup fail on The destination with IP address and mask shown is not in the routing table.
x.y.w.z/m:
subnet_lookup failed
route tag chg x.y.w.z/m Request to create the LFIB entry for the specified prefix/mask.
idx=-1 The index within the FIB entry of the path whose LFIB entry is being
created. The parameter 1 means all paths for this FIB entry.
inc=s Incoming label of the entry being processed.
outg=s Outgoing label of the entry being processed.
enabled=0xn Bit mask indicating the types of label switching currently enabled:
0x1 = dynamic
0x2 = TSP tunnels
0x3 = both
fib complete delete Indicates that the FIB entry is being deleted.
prefix=x.y.w.z/m A destination prefix.
delete_info=1 Indicates that label_info is also being deleted.

DB-1616 May 2008
Debug Commands
debug mpls lfib cef
Table 232 debug mpls lfib cef Field Descriptions (continued)
Field Description
deactivate tag rew for Indicates that label rewrite for specified prefix is being deleted.
x.y.w.z/m
index=n Index of path in the FIB entry being processed.
set fib rew: pfx Indicates that label rewrite is being installed or deleted from the FIB entry
x.y.w.z/m for the specified destination for label imposition purposes.
add=0 Indicates that label rewrite is being deleted from the FIB (no longer
imposing labels).
tag_rew->adj=s Adjacency of label rewrite for label imposition.
resolve tag Indicates that the FIB route to the specified prefix is being resolved.
rew,prefix=x.y.w.z/m
no tag_info Indicates that there is no label_info for the destination (destination not
labeled).
no parent Indicates that the route is not recursive.
fib scanner start Indicates that the periodic scan of the FIB has started.
needed:1 Indicates that the LFIB needs the FIB to be scanned.
unres:n Indicates the number of unresolved TFIB entries.
mac:n Indicates the number of TFIB entries missing MAC strings.
loadinfo:n Indicates whether the nonrecursive accounting state has changed and
whether the loadinfo information in the LFIB needs to be adjusted.
fib upd loadinf Indicates that a check for nonrecursive accounting is being made and that
x.y.w.z/m the LFIB loadinfo information for the specified prefix is being updated.
tag=s Incoming label of entry.
fib no loadin Indicates that the corresponding FIB entry has no loadinfo.
tfib no loadin Indicates that the LFIB entry has no loadinfo.
fib check cleanup for Indicates that a check is being made on the LFIB entry for the specified
x.y.w.z/m destination to determine if rewrite needs to be removed from the LFIB.
return_value=x If x is 0, indicates that no change has occurred in the LFIB entry. If x is 1,
there was a change.
fib_scanner_end Indicates that the FIB scan has come to an end.
create dynamic entry for Indicates that the LFIB has been enabled and that an LFIB entry is being
x.y.w.z/m created for the specified destination.
call find_route_tags Indicates that the labels for that destination are being requested.
dist_method=n Identifies the label distribution methodTDP, TC-ATM, and so on.
next_hop=x.y.z.w Identifies the next hop for the destination.
interface name Identifies the outgoing interface for the destination.
create tag info Indicates that a label_info data structure is being created for the destination.
has no info Indicates that the destination does not already have label_info.
finish fib re x.y.z.w/m Indicates that the LFIB entry for the specified route is being completed.

May 2008 DB-1617
Debug Commands
debug mpls lfib cef
Table 232 debug mpls lfib cef Field Descriptions (continued)
Field Description
parent outg tag s If recursive, specifies the outgoing label of the route through which it is
recursive (the parent). If not recursive, s = no parent.
tagcon: Indicates that label control is notifying LFIB that labels are available for the
route_tag_change for: specified destination.
x.y.z.w/m
intag s Identifies the incoming label for the destination.
outtag s Identifies the outgoing label for the destination.
nexthop tsr x.y.z.w.i Identifies the TDP ID of the next hop that sent the tag.

debug mpls lfib lsp Prints detailed information about label rewrites being created
and deleted as LSP tunnels are added or removed.
debug mpls lfib state Traces what happens when label switching is enabled or
disabled.
debug mpls lfib struct Traces the allocation and freeing of LFIB-related data
structures, including the LFIB itself, label rewrites, and
label_info data.

DB-1618 May 2008
Debug Commands
debug mpls lfib enc
debug mpls lfib enc

To print detailed information about label encapsulations while label rewrites are created or updated and
placed in the label-forwarding information base (LFIB), use the debug mpls lfib enc command in
debug mpls lfib enc
no debug mpls lfib enc

CLI syntax.
Usage Guidelines Several lines of output are produced for each route placed into the LFIB. If your router has thousands of
labeled routes, issue this command with care. When label switching is first enabled, each of these routes
is placed into the LFIB and a label encapsulation is created. The command output shows you on which
adjacency the label rewrite is being created and the labels assigned.
Examples The following is sample output from the debug mpls lfib enc command. This example shows the
encapsulations for three routes that have been created and placed into the LFIB.
Router# debug mpls lfib enc
TFIB: finish res:inc tag=28,outg=Imp_null,next_hop=10.93.72.13,Ethernet4/0/3

TFIB: update_mac, mac_length = 14,addr=10.93.72.13,idb=Ethernet4/0/3
TFIB: get ip adj: addr=10.93.72.13,is_p2p=0,fibidb=Ethernet4/0/3,linktype=7
TFIB: get tag adj: addr=10.93.72.13,is_p2p=0,fibidb=Ethernet4/0/3,linktype=79
TFIB: encaps:inc=28,outg=Imp_null,idb:Ethernet4/0/3,sizes 14,14,1504,type 0
TFIB: finish res:inc tag=30,outg=27,next_hop=10.93.72.13,Ethernet4/0/3
TFIB: get ip adj: addr=10.93.72.13,is_p2p=0,fibidb=Ethernet4/0/3,linktype=7
TFIB: get tag adj: addr=10.93.72.13,is_p2p=0,fibidb=Ethernet4/0/3,linktype=79
TFIB: encaps:inc=30,outg=27,idb:Ethernet4/0/3,sizes 14,18,1500,type 0
TFIB: finish res:inc tag=30,outg=10,next_hop=0.0.0.0,ATM0/0.1

May 2008 DB-1619
Debug Commands
debug mpls lfib enc
TFIB: get ip adj: addr=0.0.0.0,is_p2p=1,fibidb=ATM0/0.1,linktype=7

TFIB: get tag adj: addr=0.0.0.0,is_p2p=1,fibidb=ATM0/0.1,linktype=79
TFIB: encaps:inc=30,outg=10,idb:ATM0/0,sizes 4,8,4470,type 1
Table 233 debug mpls lfib enc Field Descriptions
Field Description
TFIB Identifies the source of the message as the LFIB subsystem.
finish res Identifies that the LFIB resolution is being finished.
inc tag=x or inc=x An incoming (local) label for the LFIB entry is being created. Labels can be
numbers or special values.
outg=y An outgoing (remote) label for the LFIB entry is being created.
next_hop=a.b.c.d IP address of the next hop for the destination.
interface The outgoing interface through which a packet will be sent.
get ip adj Identifies that the IP adjacency to use in the LFIB entry is being determined.
get tag adj Identifies that the label switching adjacency to use for the LFIB entry is
being determined.
addr = a.b.c.d The IP address of the adjacency.
is_p2p=x If x is 1, this is a point-to-point adjacency. If x is 0, it is not.
fibidb = s Indicates the interface of the adjacency.
linktype = x The link type of the adjacency, as follows:
7 = LINK_IP
79 = LINK_TAG
sizes x,y,z Indicates the following values:
x = length of macstring
y = length of tag encapsulation
z = tag MTU
type = x Tag encapsulation type, as follows:
0 = normal
1 = TCATM
2 = TSP tunnel
idb:s Indicates the outgoing interface.
update_mac Indicates that the macstring of the adjacency is being updated.
Table 234 describes the special labels, which sometimes appear in the debug output, and their meanings.
Table 234 Special Labels Appearing in debug Command Output
Special Label Meaning

UnassnInital value No label assigned yet.
Unused This destination does not have a label (for example, a BGP route).

DB-1620 May 2008
Debug Commands
debug mpls lfib enc
Table 234 Special Labels Appearing in debug Command Output (continued)
Special Label Meaning

Withdrn The label for this destination has been withdrawn.
Unkn This destination should have a label, but it is not yet known.
Get_res A recursive route that will get a label when resolved.
Exp_null Explicit null labelused over TC-ATM.
Imp_null Implicit null labelfor directly connected routes.
Tun_hd Identifies head of TSP tunnel.

debug mpls lfib cef Prints detailed information about label rewrites being created, resolved,
and deactivated as CEF routes are added, changed, or removed.
debug mpls lfib lsp Prints detailed information about label rewrites being created and deleted
as LSP tunnels are added or removed.
debug mpls lfib state Traces what happens when label switching is enabled or disabled.
debug mpls lfib struct Traces the allocation and freeing of LFIB-related data structures,
including the LFIB itself, label rewrites, and label_info data.

May 2008 DB-1621
Debug Commands
debug mpls lfib fast-reroute database

To enable debugging information about changes to the fast reroute database, use the debug mpls lfib
fast-reroute database command in privileged EXEC command. To disable debugging output, use to no
no debug mpls lfib fast-reroute database

Usage Guidelines Because using debug commands can use a great deal of bandwidth on your system, use caution when
enabling the debug mpls lfib fast-reroute database command.
Examples The following example displays debugging output for in Fast Reroute processing:
Router# debug mpls lfib fast-reroute database
LFIB-FRR:Clear headend FRR info for Tunnel1

LFIB-FRR:FRR info for Tunnel1 changed
LFIB-FRR:update headend FRR info for 10.8.0.1/32
LFIB-FRR:item B13D94 [Tu1] (group PO0/0->Tu4000):destroying entry for 10.8.0.1/32... [514
left]
LFIB-FRR:item B13D94 [Tu1]:removed from name tree
LFIB-FRR:item B13D94 [Tu1]:removed from group PO0/0->Tu4000 tree
%LINK-5-CHANGED:Interface Tunnel1, changed state to administratively down
LFIB-FRR:Set headend FRR info for Tunnel1 {main=PO0/0,backup=Tu4000,label=18}
%SYS-5-CONFIG_I:Configured from console by console

DB-1622 May 2008
Debug Commands
LFIB-FRR:item B13D94 [Tu1]:inserted in name tree

LFIB-FRR:item B13D94 [Tu1]:inserted in group PO0/0->Tu4000 tree
LFIB-FRR:item B13D94 [Tu1] (group PO0/0->Tu4000):full entry created for 10.8.0.1/32 [total
515]
LFIB-FRR:item B13D94 [Tu1] (group PO0/0->Tu4000):updating entry for 10.8.0.1/32...
LFIB-FRR:item B13D94 [Tu1] (group PO0/0->Tu4000):... updated
%LINK-3-UPDOWN:Interface Tunnel1, changed state to up
LFIB-FRR:item B04C2C [Tu486]:inserted in name tree
LFIB-FRR:item B04C2C [Tu486]:inserted in group PO0/0->Tu4000 tree
LFIB-FRR:item B04C2C [Tu486] (group PO0/0->Tu4000):full entry created for 10.43.0.0/16
[total 516]
LFIB-FRR:item B04BB4 [Tu481]:inserted in name tree
LFIB-FRR:item B04BB4 [Tu481]:inserted in group PO0/0->Tu4000 tree
LFIB-FRR:item B04BB4 [Tu481] (group PO0/0->Tu4000):full entry created for 10.43.0.0/16
[total 517]
LFIB-FRR:item B04B3C [Tu486]:inserted in name tree
LFIB-FRR:item B04B3C [Tu486]:inserted in group PO0/0->Tu4000 tree
LFIB-FRR:item B04B3C [Tu486] (group PO0/0->Tu4000):full entry created for 10.2.0.0/16
[total 518]
LFIB-FRR:item B04AC4 [Tu481]:inserted in name tree
LFIB-FRR:item B04AC4 [Tu481]:inserted in group PO0/0->Tu4000 tree

debug mpls traffic-eng Displays debugging information about fast reroute events.
tunnels fast-reroute
events
debug mpls traffic-eng Displays debugging information about the rerouting of traffic from
tunnels fast-reroute link-protected interfaces to backup tunnels.
reroutes

May 2008 DB-1623
Debug Commands
debug mpls lfib fast-reroute events

To display debugging information about fast reroute events, use the debug mpls lfib fast-reroute events
command in privileged EXEC command. To disable debugging output, use to no form of this command.
no debug mpls lfib fast-reroute events

enabling the debug mpls lfib fast-reroute events command.
Examples The following example reports on the rerouting of traffic to a backup tunnel because of a change of state
at a link-protected physical interface.
Router# debug mpls lfib fast-reroute events
LFIB-FRR:enqueued interface DOWN event for PO0/0 (Up)

LFIB-FRR:discarded interface DOWN event for PO0/0 (Up)
LFIB-FRR:processing interface DOWN event for PO0/0 (Up)
LFIB-FRR:group PO0/0->Tu4000:output if fixup:Backup(Tu4000) -> Backup(Tu4000)
Note The state given in parentheses reflects what the FRR database currently understands to be the state of
the physical interface. This may or may not be the same as the event state reported earlier on that same
display line.

DB-1624 May 2008
Debug Commands

debug mpls traffic-eng Displays debugging information about changes to the fast reroute database.
database
debug mpls traffic-eng Displays debugging information about the rerouting of traffic from
tunnels fast-reroute link-protected interfaces to backup tunnels.
reroutes

May 2008 DB-1625
Debug Commands
debug mpls lfib fast-reroute reroutes

To enable debugging information about the rerouting of protected Label Forwarding Information Base
(LFIB) entries between the primary and backup outgoing interfaces, use the debug mpls lfib
fast-reroute reroutes command in privileged EXEC command. To disable debugging output, use to no
no debug mpls lfib fast-reroute reroutes

enabling the debug mpls lfib fast-reroute reroutes command. The output of this command increases in
proportion to the number of tunnels that utilize fast reroute.
Examples The following example reports the results of reroute attempts:

Router# debug mpls lfib fast-reroute reroutes
LFIB-FRR:item B0E844 [Tu139]:output if fixup, Main(PO0/0) -> Backup(Tu4000), succeeded

LFIB-FRR:item B0E8BC [Tu138]:output if fixup, Main(PO0/0) -> Backup(Tu4000), succeeded
LFIB-FRR:item B0E934 [Tu387]:output if fixup, Main(PO0/0) -> Backup(Tu4000), succeeded
LFIB-FRR:item B0E9AC [Tu137]:output if fixup, Main(PO0/0) -> Backup(Tu4000), succeeded
LFIB-FRR:item B0EA24 [Tu136]:output if fixup, Main(PO0/0) -> Backup(Tu4000), succeeded
LFIB-FRR:item B0EA9C [Tu135]:output if fixup, Main(PO0/0) -> Backup(Tu4000), succeeded
LFIB-FRR:item B0EB14 [Tu384]:output if fixup, Main(PO0/0) -> Backup(Tu4000), succeeded
LFIB-FRR:item B0EB8C [Tu134]:output if fixup, Main(PO0/0) -> Backup(Tu4000), succeeded
LFIB-FRR:item B0EC04 [Tu133]:output if fixup, Main(PO0/0) -> Backup(Tu4000), succeeded
LFIB-FRR:item B0EC7C [Tu132]:output if fixup, Main(PO0/0) -> Backup(Tu4000), succeeded

DB-1626 May 2008
Debug Commands

debug mpls traffic-eng Displays debugging information about changes to the fast reroute database.
database
debug mpls traffic-eng Displays debugging information about fast reroute events.
events

May 2008 DB-1627
Debug Commands
debug mpls lfib lsp
debug mpls lfib lsp

To print detailed information about label rewrites being created and deleted as label-switched path (LSP)
tunnels are added or removed, use the debug mpls lfib lsp command in privileged EXEC mode. To
debug mpls lfib lsp
no debug mpls lfib lsp

CLI syntax.
Examples The following is sample output from the debug mpls lfib lsp command:
Router# debug mpls lfib lsp
TSP-tunnel related TFIB services debugging is on
TFIB: tagtun,next hop=10.93.72.13,inc=35,outg=1,idb=Et4/0/3

TFIB: tsptunnel:next hop=10.93.72.13,inc=35,outg=Imp_null,if_number=7
TFIB: tsptun update loadinfo:tag=35,loadinfo_reqd=0,no new loadinfo,no old loadinfo
TFIB: tagtun tag chg linec,fiblc=0,in tg=35,o tg=1,if=7,nh=10.93.72.13
TFIB: tagtun_delete, inc = 36
tagtun tag del linec,itag=12
TFIB: tagtun_delete, inc = 35
tagtun tag del linec,itag=12

DB-1628 May 2008
Debug Commands
debug mpls lfib lsp
On VIP:
TFIB: tagtun chg msg,in tg=35,o tg=1,nh=10.93.72.13,if=7
Table 235 describes the significant fields shown in the sample display.
Table 235 debug mpls lfib lsp Field Descriptions
Field Description
tagtun Name of routine entered.
next hop=x.y.z.w Next hop for the tunnel being created.
inc=x Incoming label for this hop of the tunnel being created.
outg=x Outgoing label (1 means Implicit Null label).
idb=s Outgoing interface for the tunnel being created.
if_number=7 Interface number of the outgoing interface.
tsptunnel Name of the routine entered.
tsptun update loadinfo The procedure being performed.
tag=x Incoming label of the LFIB slot whose loadinfo is being updated.
loadinfo_reqd=x Indicates whether a loadinfo is expected for this entry (non-recursive
accounting is on).
no new loadinfo No change required in loadinfo.
no old loadinfo No previous loadinfo available.
tagtun tag chg linec Line card is being informed of the TSP tunnel.
fiblc=x Indicates which line card is being informed (0 means all).
in tg=x Indicates the incoming label of new TSP tunnel.
o tg=x Indicates the outgoing label of new TSP tunnel.
if=x Indicates the outgoing interface number.
nh=x.y.w.z Indicates the next hop IP address.
tagtun_delete Indicates that a procedure is being performed: delete a TSP tunnel.
tagtun tag del linec Informs the line card of the TSP tunnel deletion.
tagtun chg msg Indicates that the line card has received a message to create a TSP tunnel.

May 2008 DB-1629
Debug Commands
debug mpls lfib lsp

debug mpls lfib cef Prints detailed information about label rewrites being
created, resolved, and deactivated as CEF routes are
added, changed, or removed.
debug mpls lfib state Traces what happens when label switching is enabled or
disabled.
debug mpls lfib struct Traces the allocation and freeing of LFIB-related data
structures, including the LFIB itself, label rewrites, and
label_info data.

DB-1630 May 2008
Debug Commands
debug mpls lfib state

To trace what happens when label switching is enabled or disabled, use the debug mpls lfib state
no debug mpls lfib state

CLI syntax.
Usage Guidelines Use this command when you wish to trace what happens to the label-forwarding information base (LFIB)
when you issue the mpls ip or the mpls tsp-tunnel command.
Examples The following is sample output from the debug mpls lfib state command:
Router# debug mpls lfib state
TFIB enable/disable state debugging is on

TFIB: Upd tag sb 6(status:0xC1,tmtu:1500,VPI:1-1 VC=0/32,et:0/0/0),lc 0x0
TFIB: intf status chg: idb=Et4/0/2,status=0xC1,oldstatus=0xC3
TFIB: interface dyntag change,change in state to Ethernet4/0/2
TFIB: enable entered, table exists,enabler type=0x2
TFIB: enable, TFIB already enabled, types now 0x3,returning
TFIB: enable entered, table exists,enabler type=0x1
TFIB: disable entered, table exists,type=0x1
TFIB: cleanup: tfib[32] still non-0
On linecard only:
TFIB: disable lc msg recvd, type=0x1

TFIB: Ethernet4/0/1 fibidb subblock message received

May 2008 DB-1631
Debug Commands
TFIB: enable lc msg recvd, type=0x1

TFIB: Tunnel301 set encapfix to 0x6016A97C
Table 236 debug mpls lfib state Field Descriptions
Field Description
LFIB Identifies the source of the message as the LFIB subsystem.
Upd tag sb x Indicates that the status of the xth label switching sub-block is being
updated, where x is the interface number. There is a label switching
sub-block for each interface on which label switching has been enabled.
(status:0xC1,tmtu:1500, Identifies the values of the fields in the label switching sub-block, as
VPI:1-1VC=0/32, follows:
et:0/0/0),lc 0x0)
status byte
maximum transmission unit (tmtu)
range of ATM VPs
control VP
control VC (if this is a TC-ATM interface)
encapsulation type (et)
encapsulation information
tunnel interface number (lc)
line card number to which the update message is being sent (0 means
all line cards)
intf status chg Indicates that there was an interface status change.
idb=Et4/0/2 Identifies the interface whose status changed.
status=0xC1 Indicates the new status bits in the label switching sub-block of the idb.
oldstatus=0xC3 Indicates the old status bits before the change.
interface dyntag change, Indicates that there was a change in the dynamic label status for the
change in state to particular interface.
Ethernet4/0/2
enable entered Indicates that the code that enables the LFIB was invoked.
TFIB already enabled Indicates that the LFIB was already enabled when this call was made.
table exists Indicates that an LFIB table had already been allocated in a previous call.
cleanup: tfib[x] still Indicates that the LFIB is being deleted, but that slot x is still active.
non-0
disable lc mesg recvd, Indicates that a message to disable label switching type 1 (dynamic) was
type=0x1 received by the line card.
disable entered, table Indicates that a call to disable dynamic label switching was issued.
exists,type=0x1
Ethernet4/0/1 fibidb Indicates that a message giving fibidb status change was received on the
subblock message line card.
received

DB-1632 May 2008
Debug Commands
Table 236 debug mpls lfib state Field Descriptions (continued)
Field Description
enable lc msg Indicates that the line card received a message to enable label switching
recvd,type=0x1 type 1 (dynamic).
Tunnel301 set encapfix Shows that fibidb Tunnel301 on the line card received an encapsulation
to 0x6016A97C fixup.
types now 0x3, returning Shows the value of the bitmask indicating the type of label switching
enabled on the interface, as follows:
0x1means dynamic label switching
0x2means tsp-tunnels
0x3means both

debug mpls lfib cef Prints detailed information about label rewrites being created,
resolved, and deactivated as CEF routes are added, changed, or
removed.
debug mpls lfib lsp Prints detailed information about label rewrites being created and
deleted as LSP tunnels are added or removed.
debug mpls lfib struct Traces the allocation and freeing of LFIB-related data structures,
including the LFIB itself, label rewrites, and label_info data.

May 2008 DB-1633
Debug Commands
debug mpls lfib struct

To trace the allocation and freeing of label-forwarding information base (LFIB)-related data structures,
such as the LFIB itself, label rewrites, and label_info data, use the debug mpls lfib struct command in
no debug mpls lfib struct

CLI syntax.
Examples The following is sample output from the debug mpls lfib struct command:
Router# debug mpls lfib struct
TFIB data structure changes debugging is on
TFIB: delete tag rew, incoming tag 32

TFIB: remove from tfib,inc tag=32
TFIB: set loadinfo,tag=32,no old loadinfo,no new loadinfo
TFIB: TFIB not in use. Checking for entries.
TFIB: cleanup: tfib[0] still non-0
TFIB: remove from tfib,inc tag=Tun_hd
TFIB: set loadinfo,tag=Exp_null,no old loadinfo,no new loadinfo
TFIB: TFIB freed.
TFIB: enable, TFIB allocated, size 4024 bytes, maxtag = 500
TFIB: create tag rewrite: inc Tun_hd,outg Unkn
TFIB: add to tfib at Tun_hd, first in circular list, mac=0,enc=0
TFIB: delete tag rew, incoming tag Tun_hd
TFIB: create tag rewrite: inc Tun_hd,outg Unkn
TFIB: add to tfib at Tun_hd, first in circular list, mac=0,enc=0
TFIB: create tag rewrite: inc 26,outg Unkn

DB-1634 May 2008
Debug Commands
TFIB: add to tfib at 26, first in circular list, mac=0,enc=0

TFIB: add to tfib at 27, added to circular list, mac=0,enc=0
TFIB: delete tag rew, incoming tag Tun_hd
TFIB: add to tfib at 29, added to circular list, mac=4,enc=8
TFIB: delete tag rew, incoming tag 29
TFIB: remove from tfib,inc tag=29
Table 237 debug mpls lfib struct Field Descriptions
Field Description
TFIB The subsystem issuing the message.
delete tag rew A label rewrite is being freed.
remove from tfib A label rewrite is being removed from the LFIB.
inc tag=s The incoming label of the entry being processed.
set loadinfo The loadinfo field in the LFIB entry is being set (used for nonrecursive
accounting).
tag=s The incoming label of the entry being processed.
no old loadinfo The LFIB entry did not have a loadinfo before.
no new loadinfo The LFIB entry should not have a loadinfo now.
TFIB not in use. Label switching has been disabled and the LFIB is being freed up.
Checking for entries.
cleanup: tfib[x] still The LFIB is being checked for any entries in use, and entry x is the lowest
non-0 numbered slot still in use.
TFIB freed The LFIB table has been freed.
enable, TFIB allocated, Label switching has been enabled and an LFIB of x bytes has been allocated.
size x bytes, maxtag = y The largest legal label is y.
create tag rewrite A label rewrite is being created.
inc s The incoming label.
outg s The outgoing label.
add to tfib at s A label rewrite has been placed in the LFIB at slots.
first in circular list This LFIB slot had been empty and this is the first rewrite in the list.
mac=0,enc=0 Length of the MAC string and total encapsulation length, including labels.
added to circular list A label rewrite is being added to an LFIB slot that already had an entry. This
rewrite is being inserted in the circular list.

debug mpls lfib cef Prints detailed information about label rewrites being created, resolved, and
deactivated as CEF routes are added, changed, or removed.
debug mpls lfib lsp Prints detailed information about label rewrites being created and deleted as
LSP tunnels are added or removed.
debug mpls lfib state Traces what happens when label switching is enabled or disabled.

May 2008 DB-1635
Debug Commands
debug mpls lspv
debug mpls lspv

To display information related to the MPLS LSP Ping/Traceroute feature, use the debug mpls lspv
debug mpls lspv [tlv] [error] [event] [ipc] [packet [data | error]] [path-discovery] [multipath]
[all]
no debug mpls lspv
Syntax Description tlv (Optional) Displays Multiprotocol Label Switching (MPLS) echo packet
type, length, values (TLVs) information as it is being coded and decoded.
error (Optional) Displays error conditions encountered during MPLS echo request
and echo reply encoding and decoding. See Table 223.
event (Optional) Displays MPLS echo request and reply send and receive event
information.
ipc (Optional) Interprocess communication. Displays debug information
regarding communication between the Route Processor and line cards.
packet data (Optional) Displays detailed debug information for the MPLS echo packets
sent and received. This output is seen only on the originating router and the
router generating the reply.
packet error (Optional) Displays packet errors for MPLS echo request and reply. No
output is expected for this command.
path-discovery (Optional) Provides information regarding LSP traceroute path discovery
operations.
multipath (Optional) Displays multipath information.
all (Optional) Enables all the command keywords.
Command Default MPLS LSP debugging is disabled.

12.4(6)T The following keywords were added: ipc, path-discovery, multipath, and
all.
12.2(28)SB This command was integrated into Cisco IOS Release 12.28(SB) and

DB-1636 May 2008
Debug Commands
debug mpls lspv
Usage Guidelines Use this command to monitor activity associated with the ping mpls and the trace mpls commands.
Table 238 lists the messages displayed by the debug mpls lspv error command and the reason for each
error message.
Table 238 Messages Displayed by the debug mpls lspv error Command
Message Reason Why Message Is Displayed

Echo reply discarded because not An echo reply message is sent because the IP header indicates that
routable the packet has the Router Alert set and the packet is not routable.
UDP checksum error, packet A packet is received on the port being used by Label Switched
discarded Path Verification (LSPV) and there is a checksum error on the
packet.
Invalid echo message type An MPLS echo packet with an invalid echo message type (neither
a request nor a reply) is received.
Illegal Action The state machine that drives the LSPV software detects an
invalid condition.
Examples The following is sample output from the ping mpls command when LSPV event debugging is enabled:
Router# debug mpls lspv event
LSPV event debugging is on
Router# ping mpls ipv4 10.131.159.252/32 repeat 1
Sending 1, 100-byte MPLS Echos to 10.131.159.252/32,

timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not transmitted,

'.' - timeout, 'U' - unreachable,
'R' - downstream router but not target

!
Router#
*Dec 31 19:31:15.366: LSPV:
waiting for 2 seconds
*Dec 31 19:31:15.366: LSPV: sender_handle: 2000002D, Event Echo Requests Start,
[Idle->Waiting for Echo Reply]
*Dec 31 19:31:15.414: LSPV: sender_handle: 2000002D, Event Echo Reply Received,
[Waiting for Echo Reply->Waiting for Interval]
*Dec 31 19:31:15.466: LSPV: sender_handle: 2000002D, Event Echo Requests Cancel,
[Waiting for Interval->Idle]

May 2008 DB-1637
Debug Commands
debug mpls lspv
Router# undebug all
The following is sample output from the ping mpls command when LSPV TLV debugging is enabled:
Router# debug mpls lspv tlv
LSPV tlv debugging is on
Router# ping mpls ipv4 10.131.159.252/32 repeat 1
Sending 1, 100-byte MPLS Echos to 10.131.159.252/32,

timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not transmitted,

'.' - timeout, 'U' - unreachable,
'R' - downstream router but not target

!
Router#
*Dec 31 19:32:32.566: LSPV: Echo Hdr encode: version 1, msg type 1, reply mode 2
, return_code 0, return_subcode 0, sender handle 9400002E, sequence number 1,
timestamp sent 14:32:32 EST Wed Dec 31 2003, timestamp rcvd 19:00:00 EST Thu Dec 31 1899
*Dec 31 19:32:32.566: LSPV: IPV4 FEC encode: destaddr 10.131.159.252/32
*Dec 31 19:32:32.566: LSPV: Pad TLV encode: type 1, size 18, pattern 0xABCD
*Dec 31 19:32:32.606: LSPV: Echo Hdr decode: version 1, msg type 2, reply mode 2,
return_code 3, return_subcode 0, sender handle 9400002E, sequence number 1,
timestamp sent 14:32:32 EST Wed Dec 31 2003, timestamp rcvd 14:32:32 EST Wed Dec 31 2003
Router# undebug all
The following is sample output from the trace mpls multipath command when LSPV multipath
debugging is on:
Router# debug mpls lspv multipath
multipath information debugging is on
Router# trace mpls multipath ipv4 10.5.5.5/32
Starting LSP Multipath Traceroute for 10.5.5.5/32
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0

LL
*Aug 30 20:39:03.719: LSPV: configuring bitmask multipath, base 0x7F000000, bitmapsize 32,
start 0x7F000000, numbits 32
*Aug 30 20:39:03.719: LSPV: multipath info: info_length 4, bitmapsize 32, multipath_length
8, start 127.0.0.0, base 127.0.0.0, numbits 32

DB-1638 May 2008
Debug Commands
debug mpls lspv

*Aug 30 20:39:03.719: LSPV: getnext bit_cursor 0, index 0, mask 0x80000000
*Aug 30 20:39:03.719: LSPV: next addr 127.0.0.1
*Aug 30 20:39:03.719: LSPV: multipath info: datagramsize 8
*Aug 30 20:39:03.719: 7F 00 00 00 FF FF FF FF
*Aug 30 20:39:04.007: LSPV: multipath info: !
Path 0 found,
output interface Et1/0 source 10.2.3.2 destination 127.0.0.1
Paths (found/broken/unexplored) (1/0/0)

Echo Request (sent/fail) (3/0)
Echo Reply (received/timeout) (3/0)
Total Time Elapsed 924 ms
Router#
*Aug 30 20:39:04.007: 7F 00 00 00 FF FF FF FF
*Aug 30 20:39:04.007: LSPV: ds map convert: rtr_id A030404, mtu 1500 intf_addr 10.3.4.4
hashkey 8, multipath length 8, info 2130706432
*Aug 30 20:39:04.007: LSPV: multipath info: hashkey type 8, base 0x7F000000, bitmapsize
32, info0 0xFFFFFFFF
*Aug 30 20:39:04.007: 7F 00 00 00 FF FF FF FF
*Aug 30 20:39:04.299: 7F 00 00 00 FF FF FF FF
*Aug 30 20:39:04.299: LSPV: ds map convert: rtr_id A040505, mtu 1504 intf_addr 10.4.5.5
hashkey 8, multipath length 8, info 2130706432
*Aug 30 20:39:04.299: LSPV: multipath info: hashkey type 8, base 0x7F000000, bitmapsize
32, info0 0xFFFFFFFF
*Aug 30 20:39:04.299: 7F 00 00 00 FF FF FF FF
Router# undebug all
multipath information debugging is off

ping mpls Checks MPLS LSP connectivity.
trace mpls Discovers MPLS LSP routes that packets will actually take when traveling
to their destinations.

May 2008 DB-1639
Debug Commands
debug mpls netflow
debug mpls netflow

To display debug messages for MPLS egress NetFlow accounting, use the debug mpls netflow
command in user EXEC mode. To disable debugging output, use the no form of this command.
debug mpls netflow
no debug mpls netflow
Command Modes EXEC

Examples Here is sample output from the debug mpls netflow command:
Router#
Router# debug mpls ?
adjacency MPLS adjacency database events
atm-cos MPLS Controlled ATM CoS
atm-ldp MPLS ATM LDP
events MPLS events
ldp Label Distribution Protocol
lfib MPLS Forwarding Information Base services
netflow MPLS Egress NetFlow Accounting
packets MPLS packets
tagcon MPLS/Tag control process
traffic-eng MPLS Traffic Engineering debug
Router# debug mpls netflow

MPLS Egress NetFlow debugging is on
Router#
Router#
Router#
4d00h:Egress flow:entry created, dest 3.3.3.3/32, src 34.0.0.1/8
Router#

DB-1640 May 2008
Debug Commands
debug mpls netflow
Router#
Router# conf t
Router(config)# int eth1/4
Router(config-if)# no mpls netflow egress
Router(config-if)#
4d00h:MPLS output feature change, trigger TFIB scan
4d00h:tfib_scanner_walk, prefix 5.5.5.5/32, rewrite flow flag 0
Router(config-if)#
Router(config-if)# mpls netflow egress
Router(config-if)#
4d00h:Interface refcount with output feature enabled = 2
4d00h:MPLS output feature change, trigger TFIB scan
Router(config-if)#
Router(config-if)# end
Router# show run int eth1/4
Building configuration...
Current configuration:
!
interface Ethernet1/4
ip vrf forwarding vpn1
ip address 180.1.1.1 255.255.255.0
no ip directed-broadcast
mpls netflow egress
end
Router#
Router#
4d00h:%SYS-5-CONFIG_I:Configured from console by console
Router#

May 2008 DB-1641
Debug Commands
debug mpls netflow
Note Flow flag 1 prefixes are reachable through this interface; therefore, MPLS egress NetFlow accounting is
applied to all packets going out the destination prefix. Flow flag 0 prefixes are not reachable through this
interface; therefore, MPLS egress NetFlow accounting is not applied to any packets going out the
destination prefix.


DB-1642 May 2008
Debug Commands
debug mpls packets
debug mpls packets

To display Multiprotocol Label Switching (MPLS) labeled packets switched by the host router, use the
debug mpls packets command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug mpls packets [interface]
no debug mpls packets [interface]
Syntax Description interface (Optional) The interface or subinterface name.
Defaults The debug output displays all labeled packets, regardless of the interface.

12.1(3)T This command was modified for new MPLS terminology and syntax.
12.2(25)S The command ouput was enhanced to display MPLS high availability
information.
Usage Guidelines The optional interface parameter restricts the display to only those packets received or sent on the
indicated interface or subinterface.
Note Use this command with care because it generates output for every packet processed. Furthermore,
enabling this command causes fast and distributed label switching to be disabled for the selected
interfaces. To avoid adversely affecting other system activity, use this command only when traffic on the
network is at a minimum.
Examples The following is sample output from the debug mpls packets command:
Router# debug mpls packets

May 2008 DB-1643
Debug Commands
debug mpls packets
TAG: Hs3/0: recvd: CoS=0, TTL=254, Tag(s)=27

TAG: Hs0/0: xmit: (no tag)
TAG: Hs0/0: recvd: CoS=0, TTL=254, Tag(s)=30

TAG: Hs3/0: xmit: CoS=0, TTL=253, Tag(s)=27
Table 239 debug mpls packets Field Descriptions
Field Description
Hs0/0 The identifier for the interface on which the packet was received or sent.
recvd Packet received.
xmit Packet transmitted.
CoS Class of Service field from the packet label header.
TTL Time to live field from the packet label header.
(no tag) Last label was popped off the packet and sent unlabeled.
Tag(s) A list of labels on the packet, ordered from the top of the stack to the bottom.

The following is sample output from the debug mpls packets command:
Router# debug mpls packets
Gi6/0/0: rx: Len 118 Stack {30 6 255} - ipv4 data

Gi6/1/1: tx: Len 118 Stack {22 6 254} - ipv4 data

show mpls forwarding-table Displays the contents of the MPLS forwarding table.

DB-1644 May 2008
Debug Commands
debug mpls static binding

To display information related to static binding events, use the debug mpls static binding command in
debug mpls static binding [vrf vpn-name]
no debug mpls static binding [vrf vpn-name]
Syntax Description vrf vpn-name Displays information only for the specified VPN routing and forwarding
(Optional) instance (vpn-name).

12.0(26)S This command was incorporated into Cisco IOS Release 12.0(26)S. You can
enable debug only for a VRF.
Usage Guidelines Use the debug mpls static binding command to troubleshoot problems related to MPLS static labels or
VRF aware MPLS static labels. If you specify the vrf keyword, debug is enabled only for a specified
VRF.
Examples The following is sample output from the debug mpls static binding command:
Router# debug mpls static binding vrf vpn100
MPLS Static label bindings debugging is on
00:15:13: mpls: Add remote static binding: 10.0.0.0/8; label 0; nexthop 172.16.0.8:0
00:15:13: mpls: Add static label binding for 10.0.0.0/8
00:15:13: mpls: Add remote static binding: 10.0.0.1/8; label 2607; nexthop 172.17.0.66:0
00:15:18: mpls: Periodic static label adjust
00:15:18: mpls: Static label update: 10.0.0.0/8

May 2008 DB-1645
Debug Commands
00:15:18: Add remote label: nexthop: 172.16.0.8:0; label: 0

00:15:18: Waiting for withdrawal of dynamic local label 55
00:15:18: Add remote label: nexthop: 172.17.0.66:0; label: 2607
00:15:18: Waiting for withdrawal of dynamic local label 17
00:15:28: Local label 55 added to tib
00:15:28: Signal route tag change, in label 55;out label 8388611; nh 192.168.44.77
00:15:28: Local label 17 added to tib
00:15:28: Signal route tag change, in label 17;out label 8388611; nh 192.168.44.66

mpls static binding ipv4 vrf Binds a prefix to a local label.

DB-1646 May 2008
Debug Commands
debug mpls traffic-eng areas

To print information about traffic engineering area configuration change events, use the debug mpls
traffic-eng areas command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
no debug mpls traffic-eng areas

Examples In the following example, information is printed about traffic engineering area configuration change
events:
Router# debug mpls traffic-eng areas
TE-AREAS:isis level-1:up event

TE-PCALC_LSA:isis level-1

May 2008 DB-1647
Debug Commands
debug mpls traffic-eng autoroute

To print information about automatic routing over traffic engineering tunnels, use the debug mpls
traffic-eng autoroute command in privileged EXEC mode. To disable debugging output, use the no
no debug mpls traffic-eng autoroute

Examples In the following example, information is printed about automatic routing over traffic engineering
tunnels:
Router# debug mpls traffic-eng autoroute
TE-Auto:announcement that destination 0001.0000.0003.00 has 1 tunnels

Tunnel1 (traffic share 333, nexthop 10.112.0.12)

DB-1648 May 2008
Debug Commands
debug mpls traffic-eng auto-tunnel backup
debug mpls traffic-eng auto-tunnel backup

To print system information about traffic engineering backup autotunnels, use the debug mpls
traffic-eng auto-tunnel backup command in privileged EXEC mode. To disable debugging output, use
debug mpls traffic-eng auto-tunnel backup [all | events | state]
no debug mpls traffic-eng auto-tunnel backup [all | events | state]
Syntax Description all (Optional) Enables all backup autotunnel debugging output.
events (Optional) Prints backup autotunnel system events.
state (Optional) Prints the system state of backup autotunnels.
Command Default Debugging output for backup autotunnels is disabled.

Examples In the following example, debugging information is printed about the system state of backup
autotunnels:
Router# debug mpls traffic-eng auto-tunnel backup state

debug mpls traffic-eng auto-tunnel Prints system information about traffic engineering
primary primary tunnels.
debug mpls traffic-eng tunnels events Prints information about traffic engineering tunnel
management system events.
mpls traffic-eng auto-tunnel backup Automatically builds NHOP and NNHOP backup tunnels.
show ip explicit-paths Displays the configured IP explicit paths.
show mpls traffic-eng tunnels Shows information about tunnels.

May 2008 DB-1649
Debug Commands
debug mpls traffic-eng auto-tunnel primary

To print system information about traffic engineering primary autotunnels, use the debug mpls
traffic-eng auto-tunnel primary command in privileged EXEC mode. To disable debugging output, use
debug mpls traffic-eng auto-tunnel primary [all | events | state]
no debug mpls traffic-eng auto-tunnel primary [all | events | state]
Syntax Description all (Optional) Enables all primary autotunnel debugging output.
events (Optional) Prints primary autotunnel system events.
state (Optional) Prints the system state of primary autotunnels.
Command Default Debugging output for primary autotunnels is disabled.

Examples In the following example, debugging information is printed about system events of primary autotunnels:
Router# debug mpls traffic-eng auto-tunnel primary events
*Feb 6 18:12:57.871: TE_AUTO_TUN: primary CLI command:

interface tunnel3000
no logging event link-status
ip unnumbered Loopback0
tunnel destination 192.168.1.1
tunnel mode mpls traffic-eng
end
In the following example, debugging information is printed about the system state of primary
autotunnels:
Router# debug mpls traffic-eng auto-tunnel primary state
Samplefor debug mpls traffic-eng auto-tunnel primary state: *Feb 6 18:11:44.363:

TE_AUTO_TUN: Didn't find protected Up Tunnel3000 to router id 192.168.1.1 out POS2/0

DB-1650 May 2008
Debug Commands
Sample for debug mpls traffic-eng auto-tunnel backup events (this is one log that prints
on multiple lines): *Feb 6 18:19:04.303: TE_AUTO_TUN: CLI command:
ip explicit-path name __dynamic_tunnel4000
index 1 next-address 192.168.1.2

debug mpls traffic-eng auto-tunnel Prints system information about traffic engineering backup
backup autotunnels.
debug mpls traffic-eng tunnels events Prints information about traffic engineering tunnel
mpls traffic-eng auto-tunnel primary Enables IP processing without an explicit address.
config
show ip explicit-paths Displays the configured IP explicit paths.
show mpls traffic-eng tunnels Shows information about tunnels.

May 2008 DB-1651
Debug Commands
debug mpls traffic-eng forwarding-adjacency

To display debug messages for traffic engineering (TE) forwarding-adjacency events, use the debug
mpls traffic-eng forwarding-adjacency command in privileged EXEC mode. To disable debugging
no debug mpls traffic-eng forwarding-adjacency

12.2(18)SXD This command was integrated into Cisco IOS Release 12.2(18)SX.
12.2(27)SBC. This command was integrated into Cisco IOS Release 12.2(27)SBC.
Usage Guidelines Use the debug mpls traffic-eng forwarding-adjacency command to troubleshoot any problems that
occur after you configure the tunnel mpls traffic-eng forwarding-adjacency command.
Examples The following is sample output from the debug mpls traffic-eng forwarding-adjacency command:
Router# debug mpls traffic-eng forwarding-adjacency
MPLS traffic-eng debugging is on

DB-1652 May 2008
Debug Commands
With a tunnel configured, the following output appears:

interface Tunnel0
ip unnumbered Loopback0
no ip directed-broadcast
tunnel destination 192.168.1.7
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng forwarding-adjacency
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng path-option 10 dynamic
end
When the tunnel comes up, it generates the following debug output:
*Oct 2 12:27:07.846:TE-Auto:announcement that destination 0168.0001.0007.00 has 1 tunnels

*Oct 2 12:27:07.846: Tunnel0 (traffic share 142857, nexthop 192.168.1.7)
*Oct 2 12:27:07.846: (flags: Forward-Adjacency, holdtime 0)

show mpls traffic-eng Displays TE tunnels being advertised as links in an IGP network.
forwarding-adjacency
tunnel mpls traffic-eng Advertises a TE tunnel as a link in an IGP network.
forwarding-adjacency

May 2008 DB-1653
Debug Commands
debug mpls traffic-eng ha sso

To display debugging output for Multiprotocol Label Switching (MPLS) traffic engineering high
availability (HA) activities during the graceful switchover from an active Route Processor (RP) to a
redundant standby RP, use the debug mpls traffic-eng ha sso command in privileged EXEC mode. To
debug mpls traffic-eng ha sso {auto-tunnel | errors | link-management {events | standby |

recovery | checkpoint} | tunnel {events | standby | recovery}}
no debug mpls traffic-eng ha sso {auto-tunnel | errors | link-management {events | standby |

recovery | checkpoint} | tunnel {events | standby | recovery}}
Syntax Description auto-tunnel Displays information about autotunnel activity during the MPLS traffic
engineering stateful switchover (SSO) process.
errors Displays errors encountered during the MPLS traffic engineering SSO
process.
link-management Displays information about link management activity during the MPLS
traffic engineering SSO process.
events Displays significant events that occur during the MPLS traffic engineering
SSO process.
standby Displays information about the standby behavior during the MPLS traffic
engineering SSO process.
recovery Displays information about recovery activity during the MPLS traffic
checkpoint Display information about checkpointing activities during the MPLS traffic
engineering SSO process. Checkpointing occurs when a message is sent and
acknowledged.
tunnel Displays information about tunnel activity during the MPLS traffic
Command Default Debugging is disabled until you issue this command with one or more keywords.


DB-1654 May 2008
Debug Commands
Usage Guidelines This command displays debugging output about the SSO process for MPLS traffic engineering tunnels,
autotunnels, and link management systems. The SSO process occurs when the active router becomes
unavailable and system control and routing protocol execution is transferred from the now inactive RP
to the redundant standby RP, thus providing uninterrupted network services.
Examples The following is sample output from the debug mpls traffic-eng ha sso command when you enabled
debugging keywords to monitor the SSO process for tunnels and link management systems as the
standby router becomes active:
Router# debug mpls traffic-eng ha sso link-management events
MPLS traffic-eng SSO link management events debugging is on
Router# debug mpls traffic-eng ha sso link-management recovery
MPLS traffic-eng SSO link management recovery debugging is on
Router# debug mpls traffic-eng ha sso link-management standby
MPLS traffic-eng SSO link management standby behavior debugging is on
Router# debug mpls traffic-eng ha sso link-management checkpoint
MPLS traffic-eng SSO link management checkpointed info debugging is on
Router# debug mpls traffic-eng ha sso tunnel standby
MPLS traffic-eng SSO tunnel standby behavior debugging is on
Router# debug mpls traffic-eng ha sso tunnel recovery
MPLS traffic-eng SSO tunnel head recovery debugging is on
Router# debug mpls traffic-eng ha sso tunnel events
MPLS traffic-eng SSO events for tunnel heads debugging is on
Router# debug mpls traffic-eng ha sso errors
MPLS traffic-eng SSO errors debugging is on
Router# show debug <-----This command displays the debugging that is enabled.
MPLS TE:
MPLS traffic-eng SSO link management events debugging is on
MPLS traffic-eng SSO link management recovery debugging is on
MPLS traffic-eng SSO link management standby behavior debugging is on
MPLS traffic-eng SSO link management checkpointed info debugging is on
MPLS traffic-eng SSO tunnel standby behavior debugging is on
MPLS traffic-eng SSO tunnel head recovery debugging is on
MPLS traffic-eng SSO events for tunnel heads debugging is on
MPLS traffic-eng SSO errors debugging is on
Router#
Standby-Router#
Following is the sample debugging output displayed during a successful SSO recovery on the standby
router as it becomes active:
*May 12 20:03:15.303: RRR_HA_STATE: Told to wait for IGP convergence

May 2008 DB-1655
Debug Commands
*May 12 20:03:14.807: %FABRIC-SP-STDBY-5-FABRIC_MODULE_ACTIVE: The Switch Fabric Module in

slot 5 became active.
*May 12 20:03:15.763: RRR_HA_REC: Attempting to recover last flooded info; protocol: OSPF,
area: 0
*May 12 20:03:15.763: RRR_HA_REC: recovered ospf area 0 instance 0x48FFF240
*May 12 20:03:15.763: RRR_HA_REC: recovered system info
*May 12 20:03:15.763: RRR_HA_REC: recovered link[0] info
*May 12 20:03:15.763: RRR_HA: Recovered last flooded info for igp: OSPF, area: 0
*May 12 20:03:15.763: Pre announce tunnel 10
*May 12 20:03:15.763: TSPVIF_HA_EVENT: added Router_t10 to dest list
*May 12 20:03:15.763: TSPVIF_HA_EVENT: Completed announcement of 1 tunnel heads to IGP
*May 12 20:03:15.763: TSPVIF_HA_REC: Attempting to recover Tunnel10 after SSO
*May 12 20:03:15.763: LSP-TUNNEL-REOPT: Tunnel10 [61] set to recover
*May 12 20:03:15.763: TSPVIF_HA_REC: Recovered number hops = 5
*May 12 20:03:15.763: TSPVIF_HA_REC: recovered ospf area 0 instance 0x48FFF240
*May 12 20:03:15.763: TSPVIF_HA_REC: Recovered Hop 0: 10.0.3.1, Id: 10.0.0.3 Router Node
(ospf) flag:0x0
(ospf) flag:0x0
(ospf) flag:0x0
(ospf) flag:0x0
(ospf) flag:0x0
*May 12 20:03:15.763: TSPVIF_HA_REC: signalling recovered setup for Tunnel10: popt 1
[61], weight 2
*May 12 20:03:15.891: TSPVIF_HA_REC: recovered Tu10 forwarding info needed by query
*May 12 20:03:15.891: TSPVIF_HA_REC: output_idb: GigabitEthernet3/2, output_nhop:
180.0.3.2
Standby-Router#
Router#
10.0.3.2
10.0.3.2
*May 12 20:03:35.895: RRR_HA_STATE: IGP flood prevented during IGP recovery
*May 12 20:03:38.079: LSP-TUNNEL-REOPT: Tunnel10 [61] received RESV for recovered setup
*May 12 20:03:38.079: LSP-TUNNEL-REOPT: Tunnel10 [61] removed as recovery
*May 12 20:03:38.079: TSPVIF_HA_EVENT: notifying RSVP HA to add lsp_info using key
10.0.0.3->10.0.0.9 Tu10 [61] 10.0.0.3
*May 12 20:03:38.079: TSPVIF_HA_EVENT: updated 7600-1_t10 state; action = add; result =
success
*May 12 20:03:38.079: TSPVIF_HA_EVENT: 7600-1_t10 fully recovered; rewrite refreshed
*May 12 20:03:38.079: TSPVIF_HA_EVENT: notifying CBTS bundle about Router_t10
*May 12 20:03:38.079: TSPVIF_HA_EVENT: notifying RSVP HA to remove lsp_info using key
10.0.0.3->10.0.0.9 Tu10 [61] 10.0.0.3
*May 12 20:03:38.079: RRR_HA: Received notification recovery has ended. Notify IGP to
flood.
*May 12 20:03:38.079: TSPVIF_HA_EVENT: Received notification recovery has ended
*May 12 20:03:38.079: TSPVIF_HA_STANDBY: prevent verifying setups; IGP has not converged
*May 12 20:03:38.083: TSPVIF_HA_STANDBY: preventing new setups; reason: IGP recovering
*May 12 20:03:38.083: TSPVIF_HA_STANDBY: prevent verifying setups; IGP has not converged
*May 12 20:03:38.083: TSPVIF_HA_STANDBY: preventing new setups; reason: IGP recovering
*May 12 20:03:38.083: RRR_HA_STATE: IGP flood prevented during IGP recovery
7600-1#
*May 12 20:03:47.723: RRR_HA: Received notification that RIB table 0 has converged.
*May 12 20:03:47.723: RRR_HA: Received notification all RIBs have converged. Notify IGP
to flood.
*May 12 20:03:47.723: RRR_HA_STATE: Told not to wait for IGP convergence
*May 12 20:03:47.723: RRR_HA_INFO: update flooded system info; action = add; result =
success

DB-1656 May 2008
Debug Commands
*May 12 20:03:47.723: LM System key::

*May 12 20:03:47.723: Flooding Protocol: ospf
*May 12 20:03:47.723: IGP Area ID: 0
*May 12 20:03:47.723: LM Flood Data::
*May 12 20:03:47.723: LSA Valid flags: 0x0 Node LSA flag: 0x0
*May 12 20:03:47.723: IGP System ID: 10.0.0.3 MPLS TE Router ID: 10.0.0.3
*May 12 20:03:47.723: Flooded links: 1 TLV length: 0 (bytes)
*May 12 20:03:47.723: Fragment id: 0
*May 12 20:03:47.723: rrr_ha_lm_get_link_info_size: link size: 212 bytes; num TLVs: 0
*May 12 20:03:47.723: rrr_ha_sizeof_lm_link_info: link size: 212 bytes; num TLVs: 0
*May 12 20:03:47.723: RRR_HA_INFO: update flooded link[0] info; action = add;
result = success
*May 12 20:03:47.723: RRR HA Checkpoint Info Buffer::
*May 12 20:03:47.723: Info Handle: 0x490BB1C8
*May 12 20:03:47.723: Max Size: 212
*May 12 20:03:47.723: Info Size: 212
*May 12 20:03:47.723: Info Write Pointer: 0x490BB29C
*May 12 20:03:47.723: LM Link key::
*May 12 20:03:47.723: Flooding Protocol: ospf IGP Area ID: 0 Link ID: 0
(GigabitEthernet3/2)
*May 12 20:03:47.723: Ifnumber: 5 Link Valid Flags: 0x193B
*May 12 20:03:47.723 Link Subnet Type: Broadcast
*May 12 20:03:47.723: Local Intfc ID: 0 Neighbor Intf ID: 0
*May 12 20:03:47.723: Link IP Address: 10.0.3.1
*May 12 20:03:47.723: Neighbor IGP System ID: 10.0.3.2 Neighbor IP Address: 10.0.0.0
*May 12 20:03:47.723: IGP Metric: 1 TE Metric: 1
*May 12 20:03:47.723: Physical Bandwidth: 1000000 kbits/sec
*May 12 20:03:47.723: Res. Global BW: 3000 kbits/sec
*May 12 20:03:47.723: Res. Sub BW: 0 kbits/sec
*May 12 20:03:47.723: Upstream::
Router#
*May 12 20:03:47.723: Global Pool Sub Pool
*May 12 20:03:47.723: ----------- ----------
*May 12 20:03:47.723: Reservable Bandwidth[0]: 0 0 kbits/sec
*May 12 20:03:47.723: Downstream::
*May 12 20:03:47.723: Global Pool Sub Pool
*May 12 20:03:47.723: ----------- ----------
*May 12 20:03:47.723: Reservable Bandwidth[0]: 3000 0
kbits/sec
kbits/sec
kbits/sec
kbits/sec
kbits/sec
kbits/sec
kbits/sec
kbits/sec
*May 12 20:03:47.727: Affinity Bits: 0x0
*May 12 20:03:47.727: Protection Type: Capability 0, Working Priority 0
*May 12 20:03:47.727: Number of TLVs: 0
*May 12 20:03:47.727: RRR_HA: Updated flood state for ospf area 0 with 1 links); result =
success
Router#
The following example shows how to turn off debugging:

Router# no debug mpls traffic-eng ha sso link-management events
MPLS traffic-eng SSO link management events debugging is off

May 2008 DB-1657
Debug Commands
Router# no debug mpls traffic-eng ha sso link-management recovery
MPLS traffic-eng SSO link management recovery debugging is off
Router# no debug mpls traffic-eng ha sso link-management standby
MPLS traffic-eng SSO link management standby behavior debugging is off
Router# no debug mpls traffic-eng ha sso link-management checkpoint
MPLS traffic-eng SSO link management checkpointed info debugging is off
Router# no debug mpls traffic-eng ha sso tunnel standby
MPLS traffic-eng SSO tunnel standby behavior debugging is off
Router# no debug mpls traffic-eng ha sso tunnel recovery
MPLS traffic-eng SSO tunnel head recovery debugging is off
Router# no debug mpls traffic-eng ha sso tunnel events
MPLS traffic-eng SSO events for tunnel heads debugging is off
Router# no debug mpls traffic-eng ha errors
MPLS traffic-eng SSO errors debugging is off

debug ip rsvp high-availability Displays debugging output for RSVP HA activities that improve
the accessibility of network resources.
debug ip rsvp sso Displays debugging output for RSVP activities during the
graceful switchover from an active RP to a redundant RP.

DB-1658 May 2008
Debug Commands
debug mpls traffic-eng link-management admission-control
debug mpls traffic-eng link-management admission-control

To print information about traffic engineering label-switched path (LSP) admission control on traffic
engineering interfaces, use the debug mpls traffic-eng link-management admission-control command
debug mpls traffic-eng link-management admission-control [detail] [acl-number]
no debug mpls traffic-eng link-management admission-control [detail]
Syntax Description detail (Optional) Prints detailed debugging information.

acl-number (Optional) Uses the specified access list to filter the debugging information.
Prints information only for those LSPs that match the access list.

12.1(3)T This command was integrated into Cisco IOS Release 12.1(3)T, and the
detail keyword and the acl-number argument were added.
Examples In the following example, information is printed about traffic engineering LSP admission control on
traffic engineering interfaces:
Router# debug mpls traffic-eng link-management admission-control
TE-LM-ADMIT:tunnel 10.106.0.6 1_10002:created [total 4]

TE-LM-ADMIT:tunnel 10.106.0.6 1_10002: None -> New
TE-LM-ADMIT:tunnel 10.106.0.6 1_10002: New -> Admitting 2nd Path Leg
TE-LM-ADMIT:tunnel 10.106.0.6 1_10002: Admitting 2nd Path Leg -> Path Admitted
TE-LM-ADMIT:Admission control has granted Path query for 10.106.0.6 1_10002 (10.112.0.12)
on link Ethernet4/0/1 [reason 0]
TE-LM-ADMIT:tunnel 10.106.0.6 1_10002: Path Admitted -> Admitting 1st Resv Leg
TE-LM-ADMIT:tunnel 10.106.0.6 1_10002: Admitting 1st Resv Leg -> Resv Admitted
TE-LM-ADMIT:Admission control has granted Resv query for 10.106.0.6 1_10002 (10.112.0.12)
on link Ethernet4/0/1 [reason 0]

May 2008 DB-1659
Debug Commands
debug mpls traffic-eng link-management advertisements

To print information about resource advertisements for traffic engineering interfaces, use the debug
mpls traffic-eng link-management advertisements command in privileged EXEC mode. To disable
debug mpls traffic-eng link-management advertisements [detail] [acl-number]
no debug mpls traffic-eng link-management advertisements [detail] [acl-number]


12.1(3)T This command was integrated into Cisco IOS Release 12.1(3)T. The detail
keyword and the acl-number argument were added.
Examples In the following example, detailed debugging information is printed about resource advertisements for
traffic engineering interfaces:
Router# debug mpls traffic-eng link-management advertisements detail
TE-LM-ADV:area isis level-1:IGP announcement:link Et4/0/1:info changed

TE-LM-ADV:area isis level-1:IGP msg:link Et4/0/1:includes subnet type (2), described nbrs
(1)
TE-LM-ADV:area isis level-1:IGP announcement:link Et4/0/1:info changed
TE-LM-ADV:area isis level-1:IGP msg:link Et4/0/1:includes subnet type (2), described nbrs
(1)
TE-LM-ADV:LSA:Flooding manager received message:link information change (Et4/0/1)
TE-LM-ADV:area isis level-1:*** Flooding node information ***
System Information::
Flooding Protocol: ISIS
Header Information::
IGP System ID: 0001.0000.0001.00
MPLS TE Router ID: 10.106.0.6

DB-1660 May 2008
Debug Commands
Flooded Links: 1
Link ID:: 0
Link IP Address: 10.1.0.6
IGP Neighbor: ID 0001.0000.0001.02
Admin. Weight: 10
Physical Bandwidth: 10000 kbits/sec
Max Reservable BW: 5000 kbits/sec
Downstream::
Reservable Bandwidth[0]: 5000 kbits/sec
Attribute Flags: 0x00000000
Table 240 debug mpls traffic-eng link-management advertisements Field Descriptions
Field Description
Flooding Protocol Interior Gateway Protocol (IGB) that is flooding information for
this area.
IGP System ID Identification that IGP flooding uses in this area to identify this
node.
MPLS TE Router ID MPLS traffic engineering router ID.
Flooded Links Number of links that are flooded in this area.
Link ID Index of the link that is being described.
Link IP Address Local IP address of this link.
IGP Neighbor IGP neighbor on this link.
Admin. Weight Administrative weight associated with this link.
Physical Bandwidth Links bandwidth capacity (in kbps).
Max Reservable BW Maximum amount of bandwidth that is currently available for
reservation at this priority.
Reservable Bandwidth Amount of bandwidth that is available for reservation.
Attribute Flags Attribute flags of the link being flooded.

May 2008 DB-1661
Debug Commands
debug mpls traffic-eng link-management bandwidth-allocation

To print detailed information about bandwidth allocation for traffic engineering label-switched paths
(LSPs), use the debug mpls traffic-eng link-management bandwidth-allocation command in
debug mpls traffic-eng link-management bandwidth-allocation [detail] [acl-number]
no debug mpls traffic-eng link-management bandwidth-allocation [detail] [acl-number]

Prints information only for those LSPs that match the access list.

12.1(3)T This command was integrated into Cisco IOS Release 12.1(3)T. The detail
keyword and the acl-number argument were added.
Examples In the following example, information is printed about bandwidth allocation for traffic engineering
LSPs:
Router# debug mpls traffic-eng link-management bandwidth-allocation
TE-LM-BW:tunnel 10.106.0.6 1_10002:requesting Downstream bw hold (3000000 bps [S]) on link

Et4/0/1
TE-LM-BW:tunnel 10.106.0.6 1_10002:Downstream bw hold request succeeded
TE-LM-BW:tunnel 10.106.0.6 1_10002:requesting Downstream bw lock (3000000 bps [S]) on link
Et4/0/1
TE-LM-BW:tunnel 10.106.0.6 1_10002:Downstream bw lock request succeeded_Rs

DB-1662 May 2008
Debug Commands

debug mpls traffic-eng link-management Prints information about traffic engineering
admission-control LSP admission control on traffic engineering
interfaces.
debug mpls traffic-eng link-management errors Prints information about errors encountered
during any traffic engineering link
management procedure.

May 2008 DB-1663
Debug Commands
debug mpls traffic-eng link-management errors

To print information about errors encountered during any traffic engineering link management
procedure, use the debug mpls traffic-eng link-management errors command in privileged EXEC
debug mpls traffic-eng link-management errors [detail]
no debug mpls traffic-eng link-management errors [detail]

Examples In the following example, detailed debugging information is printed about errors encountered during a
traffic engineering link management procedure:
Router# debug mpls traffic-eng link-management errors detail
00:04:48 TE-LM-ROUTING: link Et1/1/1: neighbor 0010.0000.0012.01: add to IP peer db failed

debug mpls traffic-eng link-management Prints information about traffic engineering LSP
admission-control admission control on traffic engineering
interfaces.
debug mpls traffic-eng link-management Prints information about resource advertisements
advertisements for traffic engineering interfaces.
debug mpls traffic-eng link-management Prints information about bandwidth allocation for
bandwidth-allocation traffic engineering LSPs.

DB-1664 May 2008
Debug Commands
Command Description
debug mpls traffic-eng link-management events Prints information about traffic engineering link
debug mpls traffic-eng link-management Prints information about changes to the link
igp-neighbors management databases of IGP neighbors.
debug mpls traffic-eng link-management links Prints information about traffic engineering link
management interface events.

May 2008 DB-1665
Debug Commands
debug mpls traffic-eng link-management events
debug mpls traffic-eng link-management events

To print information about traffic engineering link management system events, use the debug mpls
traffic-eng link-management events command in privileged EXEC mode. To disable debugging
debug mpls traffic-eng link-management events [detail]
no debug mpls traffic-eng link-management events [detail]

12.1(3)T This command was integrated into Cisco IOS Release 12.1(3)T and the
detail keyword was added.
Examples In the following example, detailed debugging information is printed about traffic engineering link
management system events:
Router# debug mpls traffic-eng link-management events detail
TE-LM-EVENTS:stopping MPLS TE Link Management process

TE-LM-EVENTS:MPLS TE Link Management process dying now

DB-1666 May 2008
Debug Commands
debug mpls traffic-eng link-management igp-neighbors
debug mpls traffic-eng link-management igp-neighbors

To print information about changes to the link management database of Interior Gateway Protocol (IGP)
neighbors, use the debug mpls traffic eng link-management igp-neighbors command in privileged
debug mpls traffic-eng link-management igp-neighbors [detail]
no debug mpls traffic-eng link-management igp-neighbors [detail]

Examples In the following example, detailed debugging information is printed about changes to the link
management database of IGP neighbors:
Router# debug mpls traffic-eng link-management igp-neighbors detail
TE-LM-NBR:link AT0/0.2:neighbor 0001.0000.0002.00:created (isis level-1, 10.42.0.10,

Up)[total 2]

debug mpls traffic-eng link-management events Prints information about traffic
engineering-related ISIS events.

May 2008 DB-1667
Debug Commands
debug mpls traffic-eng link-management links
debug mpls traffic-eng link-management links

To print information about traffic engineering link management interface events, use the debug mpls
traffic-eng link-management links command in privileged EXEC mode. To disable debugging output,
debug mpls traffic-eng link-management links [detail]
no debug mpls traffic-eng link-management links [detail]

management interface events:
Router# debug mpls traffic-eng link-management links detail
TE-LM-LINKS:link AT0/0.2:RSVP enabled

TE-LM-LINKS:link AT0/0.2:increasing RSVP bandwidth from 0 to 5000000
TE-LM-LINKS:link AT0/0.2:created [total 2]
TE-LM-LINKS:Binding MPLS TE LM Admission Control as the RSVP Policy Server on ATM0/0.2
TE-LM-LINKS:Bind attempt succeeded
TE-LM-LINKS:link AT0/0.2:LSP tunnels enabled

DB-1668 May 2008
Debug Commands
debug mpls traffic-eng link-management preemption
debug mpls traffic-eng link-management preemption

To print information about traffic engineering label-switched path (LSP) preemption, use the debug
mpls traffic-eng link-management preemption command in privileged EXEC mode. To disable
debug mpls traffic-eng link-management preemption [detail]
no debug mpls traffic-eng link-management preemption [detail]

Examples In the following example, detailed debugging information is printed about traffic engineering LSP
preemption:
Router# debug mpls traffic-eng link-management preemption detail
TE-LM-BW:preempting Downstream bandwidth, 1000000, for tunnel 10.106.0.6 2_2

TE-LM-BW:building preemption list to get bandwidth, 1000000, for tunnel 10.106.0.6 2_2
(priority 0)
TE-LM-BW:added bandwidth, 3000000, from tunnel 10.106.0.6 1_2 (pri 1) to preemption list
TE-LM-BW:preemption list build to get bw, 1000000, succeeded (3000000)
TE-LM-BW:preempting bandwidth, 1000000, using plist with 1 tunnels
TE-LM-BW:tunnel 10.106.0.6 1_2:being preempted on AT0/0.2 by 10.106.0.6 2_2
TE-LM-BW:preemption of Downstream bandwidth, 1000000, succeeded

May 2008 DB-1669
Debug Commands
debug mpls traffic-eng link-management routing
debug mpls traffic-eng link-management routing

To print information about traffic engineering link management routing resolutions that can be
performed to help Resource Reservation Protocol (RSVP) interpret explicit route objects, use the debug
mpls traffic-eng link-management routing command in privileged EXEC mode. To disable debugging
debug mpls traffic-eng link-management routing [detail]
no debug mpls traffic-eng link-management routing [detail]

management routing resolutions that can be performed to help RSVP interpret explicit route objects:
Router# debug mpls traffic-eng link-management routing detail
TE-LM-ROUTING:route options to 10.42.0.10:building list (w/ nhop matching)

TE-LM-ROUTING:route options to 10.42.0.10:adding {AT0/0.2, 10.42.0.10}
TE-LM-ROUTING:route options to 10.42.0.10:completed list has 1 links

debug ip rsvp Prints information about RSVP signalling events.

DB-1670 May 2008
Debug Commands
debug mpls traffic-eng load-balancing

To print information about unequal cost load balancing over traffic engineering tunnels, use the debug
mpls traffic-eng load-balancing command in privileged EXEC mode. To disable debugging output, use
no debug mpls traffic-eng load-balancing

Examples In the following example, information is printed about unequal cost load balancing over traffic
engineering tunnels:
Router# debug mpls traffic-eng load-balancing
TE-Load:10.210.0.0/16, 2 routes, loadbalancing based on MPLS TE bandwidth

TE-Load:10.200.0.0/16, 2 routes, loadbalancing based on MPLS TE bandwidth

May 2008 DB-1671
Debug Commands
debug mpls traffic-eng lsd-client

To display the Application Programming Interface (API) messages sent to the Label Switching Database
(LSD) from the Traffic Engineering (TE) client, use the debug mpls traffic-eng lsd-client command in
privileged EXEC mode. To disable the display of these messages, use the no form of this command.
no debug mpls traffic-eng lsd-client

12.2(28)SB This command was integrated into Cisco IOS Release 12.2(28)SB and implemented
on the Cisco 10000 series routers.
platform hardware.
Examples The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command
and enable TE globally:
00:10:23: TE-LSD-CLIENT: register with LSD OK; conn_id = 23, recov time = 60000 s
00:10:23: TE-LSD-CLIENT: LSD is now up
The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command
and disable TE globally:
00:09:50: TE-LSD-CLIENT: unregister LSD client; result = OK; conn_id 23
and enable TE on specific interfaces on Cisco 7500 series routers:
00:10:23: TE-LSD-CLIENT: enabled TE LSD client on Ethernet1/0; status = OK
00:10:23: TE-LSD-CLIENT: enabled TE LSD client on Serial2/0; status = OK
00:10:23: TE-LSD-CLIENT: enabled TE LSD client on Serial3/0; status = OK
and disable TE on specific interfaces on Cisco 7500 series routers:
00:09:50: TE-LSD-CLIENT: disabled TE LSD client on Ethernet1/0; status = OK

DB-1672 May 2008
Debug Commands
00:09:50: TE-LSD-CLIENT: disabled TE LSD client on Serial2/0; status = OK

00:09:50: TE-LSD-CLIENT: disabled TE LSD client on Serial3/0; status = OK
and enable TE on specific interfaces on Cisco 10000 series routers:
00:10:23: TE-LSD-CLIENT: enabled TE LSD client on GigabitEthernet1/0/0; status = OK
00:10:23: TE-LSD-CLIENT: enabled TE LSD client on Serial2/0/0; status = OK
00:10:23: TE-LSD-CLIENT: enabled TE LSD client on Serial3/0/0; status = OK
and disable TE on specific interfaces on Cisco 10000 series routers:
00:09:50: TE-LSD-CLIENT: disabled TE LSD client on GigabitEthernet1/0/0; status = OK
00:09:50: TE-LSD-CLIENT: disabled TE LSD client on Serial2/0/0; status = OK
00:09:50: TE-LSD-CLIENT: disabled TE LSD client on Serial3/0/0; status = OK
The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command,
allocate labels on tunnel midpoints, and create tunnel midpoint rewrites on Cisco 7500 series routers:
00:14:04: TE-LSD-CLIENT: label alloc OK; label = 16, conn_id = 23
00:14:04: TE-LSD-CLIENT: Create TE mid rewrite for 10.100.100.100 1 [5], Result: OK
00:14:04: In: Serial3/0, 16 Out: Serial2/0, 3
allocate labels on tunnel midpoints, and create tunnel midpoint rewrites on a Cisco 10000 series router:
00:14:04: TE-LSD-CLIENT: label alloc OK; label = 16, conn_id = 23
00:14:04: TE-LSD-CLIENT: Create TE mid rewrite for 10.100.100.100 1 [5], Result: OK
00:14:04: In: Serial3/0/0, 16 Out: Serial2/0/0, 3
free labels on tunnel midpoints, and delete tunnel midpoints on a Cisco 7500 series router:
00:13:13: TE-LSD-CLIENT: Delete TE mid rewrite for iou-100_t1, Result: OK
00:13:13: In: Serial3/0, 16 Out: Serial2/0, 1
00:13:13: TE-LSD-CLIENT: free label 16 result = OK; conn_id = 23
free labels on tunnel midpoints, and delete tunnel midpoints on a Cisco 10000 series router:
00:13:13: TE-LSD-CLIENT: Delete TE mid rewrite for iou-100_t1, Result: OK
00:13:13: In: Serial3/0/0, 16 Out: Serial2/0/0, 1
00:13:13: TE-LSD-CLIENT: free label 16 result = OK; conn_id = 23
and create tunnel headend rewrites on a Cisco 7500 series router:
00:09:10: TE-LSD-CLIENT: Create TE he rewrite for iou-100_t1, Result = OK
00:09:10: tun_inst: 7 Out: Serial3/0, 16 Dest: 10.0.0.2
ps_flags: 0x60003
and create tunnel headend rewrites on a Cisco 10000 series router:
00:09:10: TE-LSD-CLIENT: Create TE he rewrite for iou-100_t1, Result = OK
00:09:10: tun_inst: 7 Out: Serial3/0/0, 16 Dest: 10.0.0.2
ps_flags: 0x60003
and delete tunnel headend rewrites on a Cisco 7500 series router:
00:09:15: TE-LSD-CLIENT: Delete TE he rewrite for iou-100_t1, Result: OK
00:09:15: tun_inst: 7 Out: Serial3/0, 16 ps_flags: 0x60003

May 2008 DB-1673
Debug Commands
and delete tunnel headend rewrites on a Cisco 10000 series router:
00:09:15: TE-LSD-CLIENT: Delete TE he rewrite for iou-100_t1, Result: OK
00:09:15: tun_inst: 7 Out: Serial3/0/0, 16 ps_flags: 0x60003

events
ldm the MPLS IPRM.
mfi MPLS IPRM.

DB-1674 May 2008
Debug Commands
debug mpls traffic-eng path
debug mpls traffic-eng path

To print information about traffic engineering path calculation, use the debug mpls traffic-eng path
debug mpls traffic-eng path {num | lookup | spf | verify}
no debug mpls traffic-eng path {num | lookup | spf | verify}
Syntax Description num Prints path calculation information only for the local tunneling interface
with unit number num.
lookup Prints information for path lookups.
spf Prints information for shortest path first (SPF) calculations.
verify Prints information for path verifications.

Examples In the following example, information is printed about the calculation of the traffic engineering path:
Router# debug mpls traffic-eng path lookup
TE-PCALC:Tunnel1000 Path Setup to 10.110.0.10:FULL_PATH

TE-PCALC:bw 0, min_bw 0, metric:0
TE-PCALC:setup_pri 0, hold_pri 0
TE-PCALC:affinity_bits 0x0, affinity_mask 0xFFFF
TE-PCALC_PATH:create_path_hoplist:ip addr 10.42.0.6 unknown.

May 2008 DB-1675
Debug Commands
debug mpls traffic-eng process-restart

To display information about process restarts for reporting to your technical support representative, use
the debug mpls traffic-eng process-restart command in privileged EXEC mode. To disable debugging
no debug mpls traffic-eng process-restart

12.2(33)SXH This command was introduced.
Usage Guidelines If you report a problem and the show mpls traffic-eng process-restart iprouting displays abnormal
results, your technical support representative might ask you to issue the debug mpls traffic-eng
process-restart command, then perform an IP routing process restart and capture the output for analysis.
Examples The following example shows partial output from an IP routing process restart:
Router# debug mpls traffic-eng process-restart
02:24:22: SM: ---TE ION Process Restart 0x78EF9050: process restart (3)
02:24:22: SM: NORM (1) --> AWAIT-CFG (3)
02:24:22: TE ION Restart timer started, proc_idx:0 delay:120000
02:24:22: SM: ---TE ION Process Restart 0x78EF9050: process cfg replay start (4)
02:24:22: SM: AWAIT-CFG (3) --> CFG (4)
02:24:22: SM: ---TE ION Process Restart 0x78EF9050: reg invoke succeeded (2)
02:24:22: SM: CFG (4) --> CFG (4)
02:24:22: SM: ---TE ION Process Restart 0x78EF9050: process cfg replay done (5)
02:24:22: SM: CFG (4) --> SYNC (5)
The output shows typical process restart information that your technical support representative might
request if you report a problem after an IP process restart. The information displayed can vary, depending
on the conditions that caused the restart.

DB-1676 May 2008
Debug Commands

show mpls traffic-eng Displays the status of IP routing and MPLS traffic engineering
process-restart iprouting synchronization after an IP routing process restarts.

May 2008 DB-1677
Debug Commands
debug mpls traffic-eng topology change

To print information about traffic engineering topology change events, use the debug mpls traffic-eng
topology change command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
no debug mpls traffic-eng topology change

Examples In the following example, information is printed about traffic engineering topology change events:
Router# debug mpls traffic-eng topology change
TE-PCALC_LSA:NODE_CHANGE_UPDATE isis level-1

link flags:LINK_CHANGE_BW
system_id:0001.0000.0001.00, my_ip_address:10.42.0.6
nbr_system_id:0001.0000.0002.00, nbr_ip_address 10.42.0.10

DB-1678 May 2008
Debug Commands
debug mpls traffic-eng topology lsa

To print information about traffic engineering topology link state advertisement (LSA) events, use the
debug mpls traffic-eng topology lsa command in privileged EXEC mode. To disable debugging output,
no debug mpls traffic-eng topology lsa

Examples In the following example, information is printed about traffic engineering topology LSA events:
Router# debug mpls traffic-eng topology lsa
TE-PCALC_LSA:node_lsa_add:Received a LSA:flags 0x1 !
IGP Id:0001.0000.0001.00, MPLS TE Id:10.106.0.6 is VALID has 2 links (frag_id 0)

link[0 ]:Nbr IGP Id:0001.0000.0001.02
frag_id 0, Intf Address:0.0.0.0
admin_weight:10, attribute_flags:0x0
link[1 ]:Nbr IGP Id:0001.0000.0002.00

frag_id 0, Intf Address:10.42.0.6, Nbr Intf Address:10.42.0.10
TE-PCALC_LSA:(isis level-1):Received lsa:

May 2008 DB-1679
Debug Commands
IGP Id:0001.0000.0001.00, MPLS TE Id:10.106.0.6 Router Node id 8

link[0 ]:Nbr IGP Id:0001.0000.0002.00, nbr_node_id:9, gen:114
frag_id 0, Intf Address:10.42.0.6, Nbr Intf Address:10.42.0.10
physical_bw:155520 (kbps), max_reservable_bw:5000 (kbps)
allocated_bw reservable_bw allocated_bw reservable_bw
------------ ------------- ------------ -------------
bw[0]:0 5000 bw[1]:3000 2000
bw[2]:0 2000 bw[3]:0 2000
bw[4]:0 2000 bw[5]:0 2000
bw[6]:0 2000 bw[7]:0 2000

DB-1680 May 2008
Debug Commands
debug mpls traffic-eng tunnels errors
debug mpls traffic-eng tunnels errors

To print information about errors encountered during any traffic engineering tunnel management
procedure, use the debug mpls traffic-eng tunnels errors command in privileged EXEC mode. To
debug mpls traffic-eng tunnels errors [detail]
no debug mpls traffic-eng tunnels errors [detail]

Examples In the following example, detailed debugging information is printed about errors encountered during a
traffic engineering tunnel management procedure:
Router# debug mpls traffic-eng tunnels errors
00:04:14: LSP-TUNNEL-SIG: Tunnel10012[1]: path verification failed (unprotected) [Cant

use link 10.12.4.4 on node 10.0.0.4]

May 2008 DB-1681
Debug Commands
debug mpls traffic-eng tunnels events
debug mpls traffic-eng tunnels events

To print information about traffic engineering tunnel management system events, use the debug mpls
traffic-eng tunnels events command in privileged EXEC mode. To disable debugging output, use the
debug mpls traffic-eng tunnels events [detail]
no debug mpls traffic-eng tunnels events [detail]

Examples In the following example, detailed debugging information is printed about traffic engineering tunnel
management system events:
Router# debug mpls traffic-eng tunnels events detail
LSP-TUNNEL:received event:interface admin. down [Ethernet4/0/1]

LSP-TUNNEL:posting action(s) to all-tunnels:
check static LSPs
LSP-TUNNEL:scheduling pending actions on all-tunnels
LSP-TUNNEL:applying actions to all-tunnels, as follows:
check static LSPs

DB-1682 May 2008
Debug Commands
debug mpls traffic-eng tunnels labels

To print information about Multiprotocol Label Switching (MPLS) label management for traffic
engineering tunnels, use the debug mpls traffic-eng tunnels labels command in privileged EXEC
debug mpls traffic-eng tunnels labels [detail] [acl-number]
no debug mpls traffic-eng tunnels labels [detail] [acl-number]

Prints information only about traffic engineering tunnels that match the
access list.

Examples In the following example, detailed debugging information is printed about MPLS label management for
traffic engineering tunnels:
Router# debug mpls traffic-eng tunnels labels detail
LSP-TUNNEL-LABELS:tunnel 10.106.0.6 1 [2]:fabric PROGRAM request

LSP-TUNNEL-LABELS:tunnel 10.106.0.6 1 [2]:programming label 16 on output interface
ATM0/0.2
LSP-TUNNEL-LABELS:descriptor 71FA64:continuing Program request
LSP-TUNNEL-LABELS:descriptor 71FA64:set Interface Point Out State to, allocated
LSP-TUNNEL-LABELS:# of resource points held for default interfaces:2
LSP-TUNNEL-LABELS:descriptor 71FA64:set Fabric State to, enabled
LSP-TUNNEL-LABELS:descriptor 71FA64:set Fabric Kind to, default (LFIB)
LSP-TUNNEL-LABELS:descriptor 71FA64:set Fabric State to, set
LSP-TUNNEL-LABELS:tunnel 10.106.0.6 1 [2]:fabric PROGRAM reply

May 2008 DB-1683
Debug Commands
To restrict output to information about a single tunnel, you can configure an access list and supply it to
the debug command. Configure the access list as follows:
Router(config-ext-nacl)# permit udp host scr_address host dst_address eq tun intfc
For example, if tunnel 10012 has destination 10.0.0.11 and source 10.0.0.4, as determined by the show
mpls traffic-eng tunnels command, the following access list could be configured and added to the
debug command:
Router(config-ext-nacl)# permit udp host 10.0.0.4 10.0.0.11 eq 10012

DB-1684 May 2008
Debug Commands
debug mpls traffic-eng tunnels reoptimize
debug mpls traffic-eng tunnels reoptimize

To print information about traffic engineering tunnel reoptimizations, use the debug mpls traffic-eng
tunnels reoptimize command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug mpls traffic-eng tunnels reoptimize [detail] [acl-number]
no debug mpls traffic-eng tunnels reoptimize [detail] [acl-number]

Prints information about only those traffic engineering tunnel
reoptimizations that match the access list.

reoptimizations that match access list number 101:
Router# debug mpls traffic-eng tunnels reoptimize detail 101
LSP-TUNNEL-REOPT:Tunnel1 curr option 2 (0x6175CF8C), activate new option 2

LSP-TUNNEL-REOPT:Tunnel1 new path:option 2 [10002], weight 20
LSP-TUNNEL-REOPT:Tunnel1 old path:option 2 [2], weight 110
LSP-TUNNEL-REOPT:Tunnel1 [10002] set as reopt
LSP-TUNNEL-REOPT:Tunnel1 path option 2 [10002] installing as current
LSP-TUNNEL-REOPT:Tunnel1 [2] removed as current
LSP-TUNNEL-REOPT:Tunnel1 [2] set to delayed clean
LSP-TUNNEL-REOPT:Tunnel1 [10002] removed as reopt
LSP-TUNNEL-REOPT:Tunnel1 [10002] set to current

May 2008 DB-1685
Debug Commands
debug mpls traffic-eng tunnels signalling
debug mpls traffic-eng tunnels signalling

To print information about traffic engineering tunnel signalling operations, use the debug mpls
traffic-eng tunnels signalling command in privileged EXEC mode. To disable debugging output, use
debug mpls traffic-eng tunnels signalling [detail] [acl-number]
no debug mpls traffic-eng tunnels signalling [detail] [acl-number]

Prints information about only those traffic engineering tunnel signalling
operations that match the access list.

signalling operations that match access list number 101:
Router# debug mpls traffic-eng tunnels signalling detail 101
LSP-TUNNEL-SIG:tunnel Tunnel1 [2]:RSVP head-end open

LSP-TUNNEL-SIG:tunnel Tunnel1 [2]:received Path NHOP CHANGE
LSP-TUNNEL-SIG:Tunnel1 [2]:first hop change:0.0.0.0 --> 10.1.0.10
LSP-TUNNEL-SIG:received ADD RESV request for tunnel 10.106.0.6 1 [2]
LSP-TUNNEL-SIG:tunnel 10.106.0.6 1 [2]:path next hop is 10.1.0.10 (Et4/0/1)
LSP-TUNNEL-SIG:Tunnel1 [2] notified of new label information
LSP-TUNNEL-SIG:sending ADD RESV reply for tunnel 10.106.0.6 1 [2]

DB-1686 May 2008
Debug Commands
debug mpls traffic-eng tunnels state
debug mpls traffic-eng tunnels state

To print information about state maintenance for traffic engineering tunnels, use the debug mpls
traffic-eng tunnels state command in privileged EXEC mode. To disable debugging output, use the no
debug mpls traffic-eng tunnels state [detail] [acl-number]
no debug mpls traffic-eng tunnels state [detail] [acl-number]

Prints information about state maintenance for traffic engineering tunnels
that match the access list.

Examples In the following example, detailed debugging information is printed about state maintenance for traffic
engineering tunnels that match access list number 99:
Router# debug mpls traffic-eng tunnels state detail 99
LSP-TUNNEL:tunnel 10.106.0.6 1 [2]: Connected -> Disconnected

LSP-TUNNEL:Tunnel1 received event:LSP has gone down
LSP-TUNNEL:tunnel 10.106.0.6 1 [2]: Disconnected -> Dead
LSP-TUNNEL-SIG:Tunnel1:changing state from up to down
LSP-TUNNEL:tunnel 10.106.0.6 1 [2]: Dead -> Connected

May 2008 DB-1687
Debug Commands
debug mpls traffic-eng tunnels timers
debug mpls traffic-eng tunnels timers

To print information about traffic engineering tunnel timer management, use the debug mpls traffic-eng
tunnels timers command in privileged EXEC mode. To disable debugging output, use the no form of
this command.
debug mpls traffic-eng tunnels timers [detail] [acl-number]
no debug mpls traffic-eng tunnels timers [detail] [acl-number]

Prints information about traffic engineering tunnel timer management that
matches the access list.

timer management:
Router# debug mpls traffic-eng tunnels timers detail
LSP-TUNNEL-TIMER:timer fired for Action Scheduler

LSP-TUNNEL-TIMER:timer fired for Tunnel Head Checkup

DB-1688 May 2008
Debug Commands
debug mpls vpn ha
debug mpls vpn ha

To enable the display of Virtual Private Network (VPN) high availability (HA) debugging information,
use the debug mpls vpn ha command in privileged EXEC mode. To disable the display of VPN HA
debugging information, use the no form of this command.
debug mpls vpn ha
no debug mpls vpn ha
Defaults VPN HA debugging is not enabled.

Usage Guidelines The following example shows sample output from the debug mpls vpn ha command:
Router# debug mpls vpn ha
VPN HA debugging is on.

May 2008 DB-1689
Debug Commands
debug mpls xtagatm cross-connect

To display requests and responses for establishing and removing cross-connects on the controlled ATM
switch, use the debug mpls xtagatm cross-connect command in privileged EXEC mode. To disable
no debug mpls xtagatm cross-connect

12.2(4)T This command was updated to reflect the Multiprotocol Label Switching
(MPLS) Internet Engineering Task Force (IETF) terminology.
Usage Guidelines This command monitors requests to establish or remove cross-connects from XmplsATM interfaces to
the Virtual Switch Interface (VSI) master, as well as the VSI master responses to these requests.
Note Use this command with care, because it generates output for each cross-connect operation performed by
the label switch controller (LSC). In a network configuration with many label virtual circuits (LVCs),
the volume of output generated can interfere with system timing and the proper operation of other router
functions. Use this command only in situations in which the LVC setup or teardown rate is low.
Examples The following is sample output from the debug mpls xtagatm cross-connect command:
Router# debug mpls xtagatm cross-connect
XTagATM: cross-conn request; SETUP, userdata 0x17, userbits 0x1, prec 7

0xC0100 (Ctl-If) 1/32 <-> 0xC0200 (XTagATM0) 0/32
XTagATM: cross-conn response; DOWN, userdata 0x60CDCB5C, userbits 0x2, result
OK
0xC0200 1/37 --> 0xC0300 1/37

DB-1690 May 2008
Debug Commands
Table 241 debug mpls xtagatm cross-connect Field Descriptions
Field Description
XTagATM The source of the debugging message as an XmplsATM interface.
cross-conn An indicator that the debugging message pertains to a cross-connect setup
or teardown operation.
request A request from an XmplsATM interface to the VSI master to set up or tear
down a cross-connect.
response Response from the VSI master to an XmplsATM interface that a
cross-connect was set up or removed.
SETUP A request for the setup of a cross-connect.
TEARDOWN A request for the teardown of a cross-connect.
UP The cross-connect is established.
DOWN The cross-connect is not established.
userdata, userbits Values passed with the request that are returned in the corresponding fields
in the matching response.
prec The precedence for the cross-connect.
result The status of the completed request.
0xC0100 (Ctl-If) 1/32 Information about the interface:
One endpoint of the cross-connect is on the interface whose logical
interface number is 0xC0100.
The interface is the VSI control interface.
The virtual path identifier (VPI) value at this endpoint is 1.
The virtual channel identifier (VCI) value at this end of the
cross-connect is 32.
<-> The type of cross-connect (unidirectional or bidirectional).
0xC0200 (XTagATM0) Information about the interface:
0/32
The other endpoint of the cross-connect is on the interface whose
logical interface number is 0xC0200.
The interface is associated with XmplsATM interface 0.
The VPI value at this endpoint is 0.
The VCI value at this end of the cross-connect is 32.
-> The response pertains to a unidirectional cross-connect.

show xtagatm cross-connect Displays information about remotely connected ATM switches.

May 2008 DB-1691
Debug Commands
debug mpls xtagatm errors

To display information about error and abnormal conditions that occur on XmplsATM interfaces, use the
debug mpls xtagatm errors command in privileged EXEC mode. To disable debugging output, use the
no debug mpls xtagatm errors

Usage Guidelines Use the debug mpls xtagatm errors command to display information about abnormal conditions and
events that occur on XmplsATM interfaces.
Examples The following is sample output from the debug mpls xtagatm errors command:
Router# debug mpls xtagatm errors
XTagATM VC: XTagATM0 1707 2/352 (ATM1/0 1769 3/915): Cross-connect setup
failed NO_RESOURCES
This message indicates a failed attempt to set up a cross-connect for a terminating a virtual circuit (VC)
on XmplsATM0. The reason for the failure was a lack of resources on the controlled ATM switch.

DB-1692 May 2008
Debug Commands
debug mpls xtagatm events

To display information about major events that occur on XmplsATM interfaces, not including events for
specific XmplsATM virtual circuits (VCs) and switch cross-connects, use the debug mpls xtagatm
command.
no debug mpls xtagatm events
Command History Command Modification

Usage Guidelines Use the debug mpls xtagatm events command to monitor major events that occur on XmplsATM
interfaces. This command monitors events that pertain only to XmplsATM interfaces as a whole and does
not include any events that pertain to individual XmplsATM VCs or individual switch cross-connects.
The specific events that are monitored when the debug mpls xtagatm events command is in effect
include the following:
Receiving asynchronous notifications that the VSI master sent through the external ATM application
programming interface (ExATM API) to an XmplsATM interface.
Resizing of the table that is used to store switch cross-connect information. This table is resized
automatically as the number of cross-connects increases.
Marking of XmplsATM VCs as stale when an XmplsATM interface shuts down, thereby ensuring
that the stale interfaces are refreshed before new XmplsATM VCs can be created on the interface.
Examples The following is sample output from the debug mpls xtagatm events command:
Router# debug mpls xtagatm events

May 2008 DB-1693
Debug Commands
XTagATM: desired cross-connect table size set to 256

XTagATM: ExATM API intf event Up, port 0xA0100 (None)
XTagATM: ExATM API intf event Down, port 0xA0100 (None)
XTagATM: marking all VCs stale on XTagATM0
Table 242 debug mpls xtagatm events Field Descriptions
Field Description
XTagATM The source of the debugging message.
desired cross-connect The table of cross-connect information has been set to hold 256 entries. A
table size set to 256 single cross-connect table is shared among all XmplsATM interfaces. The
cross-connect table is automatically resized as the number of
cross-connects increases.
ExATM API The information in the debug output pertains to an asynchronous
notification sent by the Virtual Switch Interface (VSI) master to the
XmplsATM driver.
event Up/Down The specific event that was sent by the VSI master to the XmplsATM driver.
port 0xA0100 (None) The event pertains to the VSI interface whose logical interface number is
0xA0100, and that this logical interface is not bound to an XmplsATM
interface.
marking all VCs stale All existing XmplsATM VCs on interface XmplsATM0 are marked as stale,
on XTagATM0 and that XmplsATM0 remains down until all of these VCs are refreshed.

DB-1694 May 2008
Debug Commands
debug mpls xtagatm vc

To display information about events that affect individual XmplsATM terminating virtual circuits (VCs),
use the debug mpls xtagatm vc command in privileged EXEC mode. To disable debugging output, use
no debug mpls xtagatm vc

Usage Guidelines Use the debug mpls xtagatm vc command to display detailed information about all events that affect
individual XmplsATM terminating VCs.
Note Use this command with care, because it results in extensive output when many XmplsATM VCs are set
up or torn down. This output can interfere with system timing and normal operation of other router
functions. Use the debug mpls xtagatm vc command only when a few XmplsATM VCs are created or
removed.
Examples The following is sample output from the debug mpls xtagatm vc command:
Router# debug mpls xtagatm vc
XTagATM VC: XTagATM1 18 0/32 (ATM1/0 0 0/0): Setup, Down --> UpPend
XTagATM VC: XTagATM1 18 0/32 (ATM1/0 88 1/32): Complete, UpPend --> Up
XTagATM VC: XTagATM1 19 1/33 (ATM1/0 0 0/0): Setup, Down --> UpPend
XTagATM VC: XTagATM0 43 0/32 (ATM1/0 67 1/84): Teardown, Up --> DownPend

May 2008 DB-1695
Debug Commands
Table 243 debug mpls xtagatm vc Field Descriptions
Field Description
XTagATM VC The source of the debugging message.
XTagATM <ifnum> The particular XmplsATM interface number for the terminating VC.
vcd vpi/vci The virtual circuit descriptor (VCD) and virtual path identifier/virtual
channel identifier (VPI/VCI) values for the terminating VC.
(ctl-if vcd vpi/vci) The control interface, the VCD, and the VPI and VCI values for the private
VC corresponding to the XmplsATM VC on the control interface.
Setup, Complete, The name of the event that occurred for the indicated VC.
Teardown
oldstate -> newstate The state of the terminating VC before and after the processing of the event.

DB-1696 May 2008
Debug Commands
debug mpoa client
debug mpoa client

To display Multiprotocol over ATM (MPOA) client debug information, use the debug mpoa client
debug mpoa client {all | data | egress | general | ingress | keep-alives | platform-specific}
[name mpc-name]
no debug mpoa client {all | data | egress | general | ingress | keep-alives | platform-specific}
[name mpc-name]
Syntax Description all Displays debugging information for all MPC activity.
data Displays debugging information for data plane activity only. This option applies
only to routers.
egress Displays debugging information for egress functionality only.
general Displays general debugging information only.
ingress Displays debugging information for ingress functionality only.
keep-alives Displays debugging information for keep-alive activity only.
platform-specific Displays debugging information for specific platforms only. This option applies
only to the Catalyst 5000 series ATM module.
name mpc-name (Optional) Specifies the name of the MPC with the specified name.
Defaults Debugging is turned on for all MPOA Clients (MPCs).

Examples The following shows how to turn on debugging for the MPC ip_mpc:
ATM# debug mpoa client all name ip_mpc

debug mpoa server Displays information about the MPOA server.

May 2008 DB-1697
Debug Commands
debug mpoa server
debug mpoa server

To display information about the Multiprotocol over ATM (MPOA) server, use the debug mpoa server
debug mpoa server [name mps-name]
no debug mpoa server [name mps-name]
Syntax Description name mps-name (Optional) Specifies the name of an MPOA server.

Usage Guidelines The debug mpoa server command optionally limits the output only to the specified MPOA Server
(MPS).
Examples The following turns on debugging only for the MPS named ip_mps:
Router# debug mpoa server name ip_mps

DB-1698 May 2008
Debug Commands
debug mrcp
debug mrcp
To display debugging messages for Media Resource Control Protocol (MRCP) operations, use the
debug mrcp command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug mrcp {all | api | detail | error | pmh | session | socket | state}
no debug mrcp {all | api | detail | error | pmh | session | socket | state}
Syntax Description all Displays all MRCP debugging messages.

api Displays messages between the application and the MRCP stack.
detail Displays detailed MRCP version 2 (MRCP v2) debugging messages.
error Displays MRCP error messages.
pmh Displays protocol message handler (PMH) messages.
session Displays messages about active MRCP sessions.
socket Displays MRCP v2 socket debugging messages
state Displays Finite State Machine (FSM) messages.

12.2(11)T This command was introduced on the Cisco 3640, Cisco 3660,
Cisco AS5300, Cisco AS5350, and Cisco AS5400.
12.4(15)T This command was modified to support MRCP v2. The detail and socket
keywords were added.
Examples The following example shows output from the debug mrcp api command:
Router# debug mrcp api
The first four lines show Real Time Streaming Protocol (RTSP) socket commands for Text-To-Speech
(TTS) operations:
*Apr 17 16:31:16.323:mrcp_add_param:param:Kill-On-Barge-In:
*Apr 17 16:31:16.323:mrcp_add_param:param:Speech-Language:
*Apr 17 16:31:16.323:mrcp_add_param:param:Logging-Tag:
*Apr 17 16:31:16.323:mrcp_add_param:param:Content-Base:
*Apr 17 16:31:16.323:mrcp_create_session:same host/port

May 2008 DB-1699
Debug Commands
debug mrcp
*Apr 17 16:31:16.323:mrcp_associate_call 5 10
*Apr 17 16:31:16.323:mrcp_associate_call 5 10
*Apr 17 16:31:16.323:mrcp_synth_speak 5
*Apr 17 16:31:16.323:mrcp_recognizer_define_grammar 5
The following lines show RTSP socket commands for Automatic Speech Recognition (ASR) operations:
*Apr 17 16:31:16.323:mrcp_add_param:param:Confidence-Threshold:
*Apr 17 16:31:16.323:mrcp_add_param:param:Sensitivity-Level:
*Apr 17 16:31:16.323:mrcp_add_param:param:Speed-Vs-Accuracy:
*Apr 17 16:31:16.323:mrcp_add_param:param:Dtmf-Interdigit-Timeout:
*Apr 17 16:31:16.323:mrcp_add_param:param:Dtmf-Term-Timeout:
*Apr 17 16:31:16.323:mrcp_add_param:param:Dtmf-Term-Char:
*Apr 17 16:31:16.323:mrcp_add_param:param:No-Input-Timeout:
*Apr 17 16:31:16.327:mrcp_add_param:param:Recognizer-Start-Timers:
*Apr 17 16:31:16.327:mrcp_recognizer_start 5
*Apr 17 16:31:26.715:mrcp_add_param:param:Kill-On-Barge-In:
*Apr 17 16:31:26.715:mrcp_add_param:param:Speech-Language:
*Apr 17 16:31:26.715:mrcp_synth_speak 5
*Apr 17 16:31:30.451:mrcp_destroy_session 5 type:SYNTHESIZER
*Apr 17 16:31:30.451:mrcp_destroy_session 5 type:RECOGNIZER
The following examples show output from the debug mrcp error command:
Router# debug mrcp error
This output shows an error when the response from the server is incorrect:
*May 9 20:29:09.936:Response from 10.1.2.58:554 failed
*May 9 20:29:09.936:MRCP/1.0 71 422 COMPLETE
This output shows an error when the RTSP connection to the server fails:
*May 9 20:29:09.936:Connecting to 10.1.2.58:554 failed
This output shows an error when the recognize request comes out of sequence:
*May 9 20:29:09.936:act_idle_recognize:ignoring old recognize request
The following example shows output from the debug mrcp pmh command:
Router# debug mrcp pmh
*Apr 17 16:32:51.777:param:Kill-On-Barge-In: true

*Apr 17 16:32:51.777:param:Speech-Language: en-US
*Apr 17 16:32:51.777:param:Logging-Tag: 14:14
*Apr 17 16:32:51.777:param:Content-Base: http://server-asr/
*Apr 17 16:32:51.777:param:Confidence-Threshold: 50
*Apr 17 16:32:51.781:param:Sensitivity-Level: 50
*Apr 17 16:32:51.781:param:Speed-Vs-Accuracy: 50
*Apr 17 16:32:51.781:param:Dtmf-Interdigit-Timeout: 10000
*Apr 17 16:32:51.781:param:Dtmf-Term-Timeout: 10000
*Apr 17 16:32:51.781:param:Dtmf-Term-Char: #
*Apr 17 16:32:51.781:param:No-Input-Timeout: 10000
*Apr 17 16:32:51.781:param:Recognizer-Start-Timers: false
*Apr 17 16:32:51.877:GRAMMAR-CONTENT-HEADER
*Apr 17 16:32:51.877:Content-Type:application/grammar+xml

DB-1700 May 2008
Debug Commands
debug mrcp
Content-Id:field2@field.grammar
Content-Length:356
*Apr 17 16:32:51.885:GRAMMAR-CONTENT-HEADER
*Apr 17 16:32:51.885:Content-Type:text/uri-list
Content-Length:30
*Apr 17 16:32:51.885:Total-Length=365
*Apr 17 16:32:51.885:@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
*Apr 17 16:32:51.885:RECOGNIZE 20 MRCP/1.0
Confidence-Threshold:50
Sensitivity-Level:50
Speed-Vs-Accuracy:50
Dtmf-Interdigit-Timeout:10000
Dtmf-Term-Timeout:10000
Dtmf-Term-Char:#
No-Input-Timeout:10000
Logging-Tag:14:14
Content-Base:http://server-asr/
Recognizer-Start-Timers:false
*Apr 17 16:32:51.885:Content-Type:text/uri-list
Content-Length:30
*Apr 17 16:32:51.885:session:field2@field.grammar
*Apr 17 16:32:51.885:@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
*Apr 17 16:32:51.889:SPEECH-MARKUP-TYPE-HEADER
*Apr 17 16:32:51.889:Content-Type:application/synthesis+ssml
Content-Length:126
*Apr 17 16:32:51.889:Total-Length=313
*Apr 17 16:32:51.889:@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
*Apr 17 16:32:51.889:SPEAK 18 MRCP/1.0
Kill-On-Barge-In:true
Speech-Language:en-US
Logging-Tag:14:14
Content-Length:126
*Apr 17 16:32:51.889:<?xml version="1.0"?><speak> Who do you want speak to?? Joe, Carl,
Alex?. And I am extending the length of the text</speak>
*Apr 17 16:32:51.889:@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
*Apr 17 16:32:51.925:mrcp_pmh_parse_response:Length:28
Apr 17 16:32:51.925:mrcp_pmh_get_request_line:Line:MRCP/1.0 19 200 COMPLETE
*Apr 17 16:32:51.925:Request-tag:19 resp-code:200 Status:COMPLETE
*Apr 17 16:32:51.925:No Of Properties:0
*Apr 17 16:32:51.925:mrcp_process_recog_response:
Apr 17 16:32:51.933:mrcp_pmh_get_request_line:Line:MRCP/1.0 20 200 IN-PROGRESS
*Apr 17 16:32:51.933:Request-tag:20 resp-code:200 Status:IN-PROGRESS
*Apr 17 16:32:51.933:mrcp_process_recog_response:
*Apr 17 16:32:53.413:mrcp_process_synth_response:
Apr 17 16:33:01.689:mrcp_pmh_get_event_line:Line:SPEAK-COMPLETE 18 COMPLETE MRCP/1.0

May 2008 DB-1701
Debug Commands
debug mrcp

*Apr 17 16:33:01.689:mrcp_process_synth_events:
*Apr 17 16:33:01.689: COMPLETION-CAUSE:1
*Apr 17 16:33:01.689:mrcp_send_synth_app_response:
Apr 17 16:33:01.689:mrcp_pmh_get_event_line:Line:START-OF-SPEECH 20 IN-PROGRESS MRCP/1.0
*Apr 17 16:33:01.689:mrcp_process_recog_events:
Apr 17 16:33:02.653:mrcp_pmh_get_event_line:Line:RECOGNITION-COMPLETE 20 COMPLETE
MRCP/1.0
*Apr 17 16:33:02.653:mrcp_process_recog_events:
*Apr 17 16:33:02.653:mrcp_send_recog_app_response:
*Apr 17 16:33:02.661:param:Kill-On-Barge-In: true
*Apr 17 16:33:02.661:param:Speech-Language: en-US
*Apr 17 16:33:02.665:SPEECH-MARKUP-TYPE-HEADER
Content-Length:57
*Apr 17 16:33:02.665:Total-Length=243
*Apr 17 16:33:02.665:@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
*Apr 17 16:33:02.665:SPEAK 22 MRCP/1.0
Kill-On-Barge-In:true
Speech-Language:en-US
Logging-Tag:14:14
Content-Length:57
*Apr 17 16:33:02.665:<?xml version="1.0"?><speak> You have joe mails</speak>

*Apr 17 16:33:02.665:@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
*Apr 17 16:33:02.833:mrcp_process_synth_response:
Apr 17 16:33:06.382:mrcp_pmh_get_event_line:Line:SPEAK-COMPLETE 22 COMPLETE MRCP/1.0
*Apr 17 16:33:06.382:mrcp_process_synth_events:
*Apr 17 16:33:06.382:mrcp_send_synth_app_response:
The following example shows output from the debug mrcp session command:
Router# debug mrcp session
*Apr 17 16:34:07.851:mrcp_create_session:
*Apr 17 16:34:07.851:mrcp_create_session:New SCB creation
*Apr 17 16:34:07.851:mrcp_create_svr_session_url:
*Apr 17 16:34:07.851:mrcp_create_session:
*Apr 17 16:34:07.851:mrcp_create_session:Already an SCB is created for this call
*Apr 17 16:34:07.851:mrcp_process_events:event:LIB_CONNECT SYNTHESIZERCONN-STATUS=0
*Apr 17 16:34:07.855:mrcp_process_events:event:SPEAK SYNTHESIZER

DB-1702 May 2008
Debug Commands
debug mrcp
*Apr 17 16:34:07.855:mrcp_process_events:event:SPEAK defered

*Apr 17 16:34:07.855:mrcp_process_events:event:LIB_CONNECT RECOGNIZERCONN-STATUS=0
*Apr 17 16:34:07.855:mrcp_process_events:event:DEFINE_GRAMMAR RECOGNIZER
*Apr 17 16:34:07.855:mrcp_process_events:event:DEFINE_GRAMMAR defered
*Apr 17 16:34:07.855:mrcp_process_events:event:LIB_CONNECT RECOGNIZERCONN-STATUS=0
*Apr 17 16:34:07.855:mrcp_process_events:event:RECOGNIZE RECOGNIZER
*Apr 17 16:34:07.855:mrcp_process_events:event:RECOGNIZE defered
*Apr 17 16:34:07.855:mrcp_response_handler:status=RTSPLIB_STATUS_SERVER_CONNECTED
*Apr 17 16:34:07.855:mrcp_process_events:event:LIB_CONNECTED SYNTHESIZERCONN-STATUS=4
*Apr 17 16:34:07.947:mrcp_response_handler:status=RTSPLIB_STATUS_RTP_RECORD_SETUP
*Apr 17 16:34:07.947:mrcp_process_events:event:RECOG_RTP_SETUP RECOGNIZER
*Apr 17 16:34:07.947:mrcp_process_defered_events:event:DEFINE_GRAMMAR
*Apr 17 16:34:07.947:mrcp_process_defered_events:event:RECOGNIZECONN-STATUS=2
*Apr 17 16:34:07.971:mrcp_response_handler:status=RTSPLIB_STATUS_RECORD_ASSOCIATED
*Apr 17 16:34:07.971:mrcp_response_handler:status=RTSPLIB_STATUS_RTP_PLAY_SETUP
*Apr 17 16:34:07.975:mrcp_process_events:event:RECOGNIZER_ASSOCIATED RECOGNIZER
*Apr 17 16:34:07.975:mrcp_process_events:event:SYNTH_RTP_SETUP SYNTHESIZER
*Apr 17 16:34:07.975:mrcp_process_defered_events:event:SPEAKCONN-STATUS=1
*Apr 17 16:34:07.975:mrcp_response_handler:status=RTSPLIB_STATUS_PLAY_ASSOCIATED
*Apr 17 16:34:07.975:mrcp_process_events:event:SYNTHESIZER_ASSOCIATED SYNTHESIZER
*Apr 17 16:34:08.007:mrcp_response_handler:status=RTSPLIB_STATUS_RESP_OK
*Apr 17 16:34:17.611:mrcp_process_events:event:SPEECH_COMPLETE SYNTHESIZER
*Apr 17 16:34:17.611:mrcp_process_events:event:START_OF_SPEECH RECOGNIZER
*Apr 17 16:34:18.575:mrcp_process_events:event:RECOGNITION_COMPLETE RECOGNIZER
*Apr 17 16:34:18.583:mrcp_process_events:event:SPEAK SYNTHESIZER
*Apr 17 16:34:18.587:mrcp_response_handler:status=RTSPLIB_STATUS_PLAY_ASSOCIATED
*Apr 17 16:34:18.587:mrcp_process_events:event:SYNTHESIZER_ASSOCIATED SYNTHESIZER
*Apr 17 16:34:22.283:mrcp_process_events:event:SPEECH_COMPLETE SYNTHESIZER
*Apr 17 16:34:22.307:mrcp_process_events:event:LIB_DESTROY SYNTHESIZERCONN-STATUS=12
*Apr 17 16:34:22.311:mrcp_process_events:event:LIB_DESTROY RECOGNIZERCONN-STATUS=12
*Apr 17 16:34:22.311:mrcp_response_handler:status=RTSPLIB_STATUS_CLEANUP
*Apr 17 16:34:22.315:mrcp_free_fsm:
*Apr 17 16:34:22.315:mrcp_free_scb:
*Apr 17 16:34:22.315:mrcp_create_session_history:scb=0x62C712F4
*Apr 17 16:34:22.315:mrcp_insert_session_history_record:current=0x62999544, callID=0x12
*Apr 17 16:34:22.315:mrcp_insert_session_history_record:count = 3
*Apr 17 16:34:22.315:mrcp_insert_session_history_record:starting history record
deletion_timer of 10 minutes
The following example shows output from the debug mrcp state command:
Router# debug mrcp state
*Apr 17 16:35:25.141:mrcp_add_synthesizer_fsm:adding synthesizer fsm

*Apr 17 16:35:25.141:mrcp_add_connection_fsm:adding connection fsm
*Apr 17 16:35:25.141:mrcp_add_rtpsetup_fsm:adding rtpsetup fsm
*Apr 17 16:35:25.145:hash_get: key=7
*Apr 17 16:35:25.145:mrcp_add_recognizer_fsm:adding recognizer fsm
*Apr 17 16:35:25.145:mrcp_add_connection_fsm:adding connection fsm
*Apr 17 16:35:25.145:mrcp_add_rtpsetup_fsm:adding rtpsetup fsm
*Apr 17 16:35:25.145:mrcp_fsm_execute:type=SYNTHESIZER
The following lines show the gateway connecting to the TTS server:
*Apr 17 16:35:25.145: curr[CONNECT_IDLE] ev-id[LIB_CONNECT]
next[CONNECTING] action=610B8FD00
*Apr 17 16:35:25.145:act_idle_libconnect

May 2008 DB-1703
Debug Commands
debug mrcp
*Apr 17 16:35:25.145:mrcp_shortcut_connection_fsm
*Apr 17 16:35:25.149: curr[CONNECTING] ev-id[LIB_CONNECT_PENDING]
next[CONNECTING] action=610B90F80
*Apr 17 16:35:25.149:act_connecting_libpending
*Apr 17 16:35:25.149: curr[CONNECTING] ev-id[LIB_CONNECT]
next[CONNECTING] action=610B8D480
*Apr 17 16:35:25.149:act_connectfsm_error
*Apr 17 16:35:25.149: curr[CONNECTING] ev-id[LIB_CONNECT]
The following lines show the gateway successfully connected to the TTS server:
next[CONNECTING] action=610B8D480
*Apr 17 16:35:25.149:act_connectfsm_error
*Apr 17 16:35:25.149: curr[CONNECTING] ev-id[LIB_CONNECTED]
next[CONNECTED] action=610B913C0
*Apr 17 16:35:25.149:act_connecting_libconnected
*Apr 17 16:35:25.149:act_rtpsetupfsm_libdescribed
*Apr 17 16:35:25.237:mrcp_fsm_execute:type=RESOURCE_NONE
*Apr 17 16:35:25.237: curr[RTP_IDLE] ev-id[RECOG_RTP_SETUP]
next[RTP_RECOG_SETUP_DONE] action=610B94F40
*Apr 17 16:35:25.237:act_idle_recog_rtpsetup
*Apr 17 16:35:25.237:mrcp_fsm_execute:type=RECOGNIZER
*Apr 17 16:35:25.237: curr[RECOG_IDLE] ev-id[DEFINE_GRAMMAR]
next[RECOG_IDLE] action=610B99340
*Apr 17 16:35:25.237:act_idle_define_grammar:
*Apr 17 16:35:25.237:hash_add: key=31
*Apr 17 16:35:25.237: curr[RECOG_IDLE] ev-id[RECOGNIZE]
next[RECOG_ASSOCIATING] action=610B98400
*Apr 17 16:35:25.237:act_idle_recognize:
*Apr 17 16:35:25.245: curr[RECOG_ASSOCIATING] ev-id[RECOGNIZER_ASSOCIATED]
next[RECOGNIZING] action=610B9AB40
*Apr 17 16:35:25.245:act_associating_recognizer_associated:
*Apr 17 16:35:25.249:hash_add: key=32
*Apr 17 16:35:25.249:mrcp_fsm_execute:type=RESOURCE_NONE
*Apr 17 16:35:25.249: curr[RTP_IDLE] ev-id[SYNTH_RTP_SETUP]
next[RTP_SYNTH_SETUP_DONE] action=610B93D40
*Apr 17 16:35:25.249:act_idle_synth_rtpsetup
*Apr 17 16:35:25.249: curr[SYNTH_IDLE] ev-id[SPEAK]
next[SYNTH_ASSOCIATING] action=610BA5540
*Apr 17 16:35:25.249:act_idle_speak
*Apr 17 16:35:25.249: curr[SYNTH_ASSOCIATING] ev-id[SYNTHESIZER_ASSOCIATED]
The following lines show the TTS server performing speech synthesis:
next[SPEAKING] action=610BA7B40
*Apr 17 16:35:25.249:act_associating_speak_associated
*Apr 17 16:35:25.249:hash_add: key=30
*Apr 17 16:35:25.285:hash_get: key=31
*Apr 17 16:35:25.285:hash_delete: key=31
*Apr 17 16:35:25.293:hash_get: key=32
*Apr 17 16:35:25.293:hash_get: key=30
*Apr 17 16:35:32.805:hash_get: key=30
*Apr 17 16:35:32.805: curr[SPEAKING] ev-id[SPEECH_COMPLETE]
next[SYNTH_IDLE] action=610BAA680

DB-1704 May 2008
Debug Commands
debug mrcp
*Apr 17 16:35:32.805:act_speaking_speech_complete
*Apr 17 16:35:32.809:hash_get: key=32
*Apr 17 16:35:32.809: curr[RECOGNIZING] ev-id[START_OF_SPEECH]
next[RECOGNIZING] action=610B9F3C0
*Apr 17 16:35:32.809:act_recognizing_start_of_speech
*Apr 17 16:35:33.781:hash_get: key=32
*Apr 17 16:35:33.781: curr[RECOGNIZING] ev-id[RECOGNITION_COMPLETE]
next[RECOGNIZED] action=610B9D240
*Apr 17 16:35:33.781:act_recognizing_recognition_complete:
*Apr 17 16:35:33.789: curr[SYNTH_IDLE] ev-id[SPEAK]
next[SYNTH_ASSOCIATING] action=610BA5540
*Apr 17 16:35:33.789:act_idle_speak
*Apr 17 16:35:33.793: curr[SYNTH_ASSOCIATING] ev-id[SYNTHESIZER_ASSOCIATED]
next[SPEAKING] action=610BA7B40
*Apr 17 16:35:33.793:act_associating_speak_associated
*Apr 17 16:35:33.793:hash_add: key=34
*Apr 17 16:35:33.949:hash_get: key=34
*Apr 17 16:35:37.221:hash_get: key=34
*Apr 17 16:35:37.221: curr[SPEAKING] ev-id[SPEECH_COMPLETE]
next[SYNTH_IDLE] action=610BAA680
*Apr 17 16:35:37.221:act_speaking_speech_complete
*Apr 17 16:35:37.249: curr[CONNECTED] ev-id[LIB_DESTROY]
next[CONNECTED] action=610B8DD00
*Apr 17 16:35:37.249:act_connected_libdestroy
*Apr 17 16:35:37.249: curr[CONNECTED] ev-id[LIB_DESTROY]
next[CONNECTED] action=610B8DD00
*Apr 17 16:35:37.249:act_connected_libdestroy
The following example shows output from the debug mrcp detail command:
Router# debug mrcp detail
*Sep 1 21:37:53.652: //68//MRCP:/mrcpv2_allocate_scb:

scb=0xC07318C8, root_scb=0x661BDD54
*Sep 1 21:37:53.708: //-1//MRCP:/MRCPV2_ADD_REQUEST_LINE:
IsFinal=FALSE;TotalLength=165
*Sep 1 21:37:53.708: //-1//MRCP:/MRCPV2_ADD_HEADER:
TotalLength=87
IsFinal=TRUE;TotalLength=535:
MRCP/2.0 535 DEFINE-GRAMMAR 1
Channel-Identifier: 0000251844F8ACAD@speechrecog
:
Speech-Language: en-US
Content-Base: http://http-server1/php/
:
Content-Type: application/srgs+xml
Content-Id: field24@field.grammar
Content-Length: 290
:
<?xml version="1.0"?><grammar mode="voice" version="1.0" root="xxx"
xmlns="http://www.w3.org/2001/06/grammar" xml:lang="en-US">
<rule id="xxx" scope="public">
<one-of>

May 2008 DB-1705
Debug Commands
debug mrcp
<item>one</item>
<item>two</item>
</one-of>
</rule>
</grammar>
TotalLength=82
MRCP/2.0 499 RECOGNIZE 2
:
Confidence-Threshold: 0.50
Sensitivity-Level: 0.50
Speed-Vs-Accuracy: 0.50
Dtmf-Interdigit-Timeout: 10000
Dtmf-Term-Timeout: 0
Dtmf-Term-Char: #
No-Input-Timeout: 20000
N-Best-List-Length: 1
Logging-Tag: 68:68
Media-Type: audio/basic
Start-Input-Timers: false
:
Content-Type: text/uri-list
Content-Length: 31
:
session:field24@field.grammar
:
MRCP/2.0 80 1 200 COMPLETE
:
MRCP/2.0 83 2 200 IN-PROGRESS

*Sep 1 21:37:57.404: //-1//MRCP:/MRCPV2_ADD_HEADER_CR:
TotalLength=93
MRCP/2.0 93 START-INPUT-TIMERS 3
:
:
MRCP/2.0 148 START-OF-INPUT 2 IN-PROGRESS
Proxy-Sync-Id: 0F1F813000000148
Input-Type: speech
:
MRCP/2.0 589 RECOGNITION-COMPLETE 2 COMPLETE

DB-1706 May 2008
Debug Commands
debug mrcp
Proxy-Sync-Id: 0F1F813000000148
Completion-Cause: 000 success
Content-Type: application/nlsml+xml
Content-Length: 369

<result grammar="session:field24@field.grammar">
<interpretation grammar="session:field24@field.grammar" confidence="0.646043">
<instance confidence="0.646043">
one
</instance>
<input mode="speech" confidence="0.646043">
one
<input confidence="0.646043">
one
</input>
</input>
</interpretation>
</result>
TotalLength=87
MRCP/2.0 566 DEFINE-GRAMMAR 1
Channel-Identifier: 00001FEC44F8AA93@speechrecog
:
:
Content-Type: application/srgs+xml
Content-Id: field25@field.grammar
Content-Length: 321
:
<?xml version="1.0"?><grammar mode="voice" version="1.0" root="xxx"
xmlns="http://www.w3.org/2001/06/grammar" xml:lang="en-US">
<rule id="xxx" scope="public">
<one-of>
<item>three</item>
<item>four</item>
<item>one</item>
</one-of>
</rule>
</grammar>
TotalLength=82
MRCP/2.0 499 RECOGNIZE 2
:
Confidence-Threshold: 0.50
Sensitivity-Level: 0.50
Speed-Vs-Accuracy: 0.50
Dtmf-Interdigit-Timeout: 10000
Dtmf-Term-Timeout: 0
Dtmf-Term-Char: #
No-Input-Timeout: 10000
N-Best-List-Length: 1

May 2008 DB-1707
Debug Commands
debug mrcp
Logging-Tag: 68:68
Media-Type: audio/basic
Start-Input-Timers: false
:
Content-Type: text/uri-list
Content-Length: 31
:
session:field25@field.grammar
:
:
MRCP/2.0 83 2 200 IN-PROGRESS

*Sep 1 21:38:00.044: //-1//MRCP:/MRCPV2_ADD_HEADER_CR:
TotalLength=93
MRCP/2.0 93 START-INPUT-TIMERS 3
:
:
MRCP/2.0 148 START-OF-INPUT 2 IN-PROGRESS
Proxy-Sync-Id: 0925248800000011
Input-Type: speech
:
MRCP/2.0 589 RECOGNITION-COMPLETE 2 COMPLETE
Proxy-Sync-Id: 0925248800000011
Completion-Cause: 000 success
Content-Type: application/nlsml+xml
Content-Length: 369

<result grammar="session:field25@field.grammar">
<interpretation grammar="session:field25@field.grammar" confidence="0.701971">
<instance confidence="0.701971">
one
</instance>
<input mode="speech" confidence="0.701971">
one
<input confidence="0.701971">
one
</input>
</input>
</interpretation>
</result>
The following example shows output from the debug mrcp socket command:
Router# debug mrcp socket

DB-1708 May 2008
Debug Commands
debug mrcp
*Sep 1 21:52:58.392: //74//MRCP:/mrcpv2_tcp_socket_connect:

Socket=0,Dest=10.1.2.201:51001
*Sep 1 21:52:58.392: //74//MRCP:/mrcpv2_connect_to_server:
SocketConnectStatus[MRCPV2_SOCK_CONNECT_PENDING(2)], SocketId=0,
ServerSession=0xC0732278, Dest=10.1.2.201:51001
*Sep 1 21:52:58.392: //-1//MRCP:/mrcpv2_handle_socket_read:
Before Execute: Socket=0, SocketStatus=MRCPV2_SOCK_CONNECT_PENDING(2)
*Sep 1 21:52:58.392: //-1//MRCP:/mrcpv2_handle_socket_read:
After Execute: Socket=0, SocketStatus=MRCPV2_SOCK_CONNECTED(1)
*Sep 1 21:52:58.392: //74//MRCP:/mrcpv2_partial_socket_send:
(Socket:0 Length:87) 600 bytes of data
Buffer Sent Successfully; fd=0, Sent=87

show mrcp client session active Displays information about active MRCP sessions.
show mrcp client session history Displays information about past MRCP sessions.
show mrcp client statistics hostname Displays statistics about MRCP sessions.

May 2008 DB-1709
Debug Commands
debug mspi receive
debug mspi receive

Note Effective with release 12.3(8)T, the debug mspi receive command is replaced by the debug fax mspi
command. See the debug fax mspi command for more information.
To display debugging messages for the receiving mail Service Provider Interface (MSPI), use the debug
mspi receive command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug mspi receive
no debug mspi receive

12.1(3)XI This command was introduced on the Cisco AS5300 universal access server.
12.3(8)T This command was replaced by the debug fax mspi command.
Examples The following is sample output from the debug mspi receive command:
Router# debug mspi receive
Jan 1 05:09:33.890: mspi_tel_num_trans: from: Radhika,

ph#in: fax=5271714 ph#dial: 5271714
Jan 1 05:09:33.890: incoming destPat(5271714), matched(7), tag(22)
Jan 1 05:09:33.890: out destPat(5......), tag(20), dgt strip enabled
Jan 1 05:09:33.890: mspi_off_new_rcpt: envlp_to [fax=5271714@smith.abccompany.com], 30
Jan 1 05:09:33.890: tel_numb_dial: 5271714, subaddr:[], cover page
Jan 1 05:09:39.122: mspi_offramp_rfc822_header: msgType=0
Jan 1 05:09:39.122: envlp_from: [Radhika], 8
Jan 1 05:09:39.122: mspi_off_put_buff: ignore mime type=1, st=CONNECTING, len=0
Jan 1 05:09:39.122: moff_save_buffer: cid=0x1F, mime=9, len=4
Jan 1 05:09:39.122: offramp disabled receiving!
Dec 31 21:09:44.078: %ISDN-6-CONNECT: Interface Serial0:22 is now connected to 5271714

DB-1710 May 2008
Debug Commands
debug mspi receive
Jan 1 05:09:52.154: mspi_bridge: cid=0x1F, dst cid=0x22, data dir=OFFRAMP, conf dir=DEST
Jan 1 05:09:52.154: mspi_offramp_send_buffer: cid=0x1F, mime=9
Jan 1 05:09:52.154: buffer with only CR/LF - set buff_len=0
Jan 1 05:09:52.154: mspi_offramp_send_buffer: cid=0x1F, mime=9 rx BUFF_END_OF_PART,
offramp rcpt enabled

debug mspi send Displays debugging messages for MSPI send.

May 2008 DB-1711
Debug Commands
debug mspi send
debug mspi send

Note Effective with Cisco IOS Release 12.3(8)T, the debug mspi send command is replaced by the debug fax
mspi command. See the debug fax mspi command for more information.
To display debugging messages for the sending mail Service Provider Interface (MSPI), use the debug
mspi send command in privileged EXEC mode. To disable debugging output, use the no form of this
command.
debug mspi send
no debug mspi send

12.1(3)XI This command was introduced on the Cisco AS5300 universal access
server.
12.2(4)T This command was introduced on the Cisco 1750 access router.
12.3(8)T This command was replaced by the debug fax mspi command.
Examples The following is sample output from the debug mspi send command:
Router# debug mspi send
*Oct 16 08:40:27.515: mspi_bridge: cid=0x21, dst cid=0x26, data dir=OFFRAMP, conf

dir=DEST
*Oct 16 08:40:29.143: mspi_setup_req: for cid=0x27
*Oct 16 08:40:29.147: envelope_from=5??????@fax.cisco.com
*Oct 16 08:40:29.147: envelope_to=ilyau@cisco.com
*Oct 16 08:40:30.147: mspi_chk_connect: cid=0x27, cnt=0,
*Oct 16 08:40:30.147: SMTP connected to the server !
*Oct 16 08:40:30.147: mspi_bridge: cid=0x27, dst cid=0x28, data dir=ONRAMP, conf dir=SRC
*Oct 16 08:40:38.995: mspi_xmit: cid=0x27, st=CONFERENCED, src_cid=0x28, buf cnt=0

DB-1712 May 2008
Debug Commands
debug mspi send

debug mspi receive Displays debugging messages for MSPI receive.

May 2008 DB-1713
Debug Commands
debug mta receive all

Note Effective with release 12.3(8)T, the debug mta receiv all command is replaced by the debug fax mta
command. See the debug fax mta command for more information.
To show output relating to the activity on the Simple Mail Transfer Protocol (SMTP) server, use the
debug mta receive all command in privileged EXEC mode. To disable debugging output, use the no
no debug mta receive all

12.3(8)T This command was replaced by the debug fax mta command.
12.2(33)SRA.
Examples The following example shows the messages exchanged (for example, the handshake) between the e-mail
server and the off-ramp gateway:
Router# debug mta receive all
Jan 1 05:07:41.314: esmtp_server_work: calling helo

Jan 1 05:07:43.354: esmtp_server_work: calling mail
Jan 1 05:07:45.386: esmtp_server_work: calling rcpt
Jan 1 05:07:47.426: esmtp_server_work: calling data

DB-1714 May 2008
Debug Commands
Jan 1 05:07:49.514: (S)R: 'Content-Type: multipart/mixed;

boundary="------------11F7CD9D2EB3E8B8D5627C62"'
Jan 1 05:07:49.514: (S)R: ''
Jan 1 05:07:49.514: esmtp_server_engine_new_part:
Jan 1 05:07:49.514: (S)R: 'Content-Type: text/plain; charset=us-ascii'
Jan 1 05:07:49.514: (S)R: 'Content-Transfer-Encoding: 7bit'
Jan 1 05:07:49.514: (S)R: ''
Jan 1 05:07:49.514: esmtp_server_work: freeing temp header
Jan 1 05:07:49.514: (S)R: 'Content-Type: image/tiff; name="DevTest.8.1610.tif"'
Jan 1 05:07:49.514: (S)R: 'Content-Transfer-Encoding: base64'
Jan 1 05:07:49.514: (S)R: 'Content-Disposition: inline; filename="DevTest.8.1610.tif"'
Jan 1 05:07:49.514: (S)R: ''
Jan 1 05:07:49.514: esmtp_server_engine_update_recipient_status: status=6
Jan 1 05:07:49.518: esmtp_server_work: freeing temp header
Jan 1 05:08:34.906: esmtp_server_engine_getline: Unexpected end of file on socket 1
Jan 1 05:08:34.906: esmtp_server_work: error occurred with ctx=0x61FFF710, socket=1

debug mta send all Displays output for all the on-ramp client connections.

May 2008 DB-1715
Debug Commands
debug mta send all
debug mta send all

Note Effective with release 12.3(8)T, the debug mta send all command is replaced by the debug fax mta
command. See the debug fax mta command for more information.
To display output for all of the on-ramp client connections, use the debug mta send all command in
debug mta send all
no debug mta send all

12.3(8)T This command was replaced by the debug fax mta command.
12.2(33)SRA.
Examples The following example shows the messages exchanged (for example, the handshake) between the e-mail
server and the on-ramp gateway:
Router# debug mta send all
*Oct 16 09:04:13.055: esmtp_client_engine_open: from=5551212@fax.cisco.com,

to=madeup@abccompany.com
*Oct 16 09:04:13.055: esmtp_client_engine_add_headers: from_comment=
*Oct 16 09:04:13.111: esmtp_client_work: socket 0 attempting to connect to IP address
171.71.154.56
*Oct 16 09:04:13.111: esmtp_client_work: socket 0 readable for first time
*Oct 16 09:04:13.135: esmtp_client_work: socket 0 readable for first time

DB-1716 May 2008
Debug Commands
debug mta send all
*Oct 16 09:04:13.135: (C)R: 220 madeup.abccompany.com ESMTP Sendmail 8.8.4-Cisco.1/8.6.5

ready at Wed, 27 Sep 2000 11:45:46 -0700 (PDT)
*Oct 16 09:04:13.135: (C)S: EHLO mmoip-c.cisco.com
*Oct 16 09:04:13.183: (C)R: 250-madeup.abccompany.com Hello [172.22.95.16], pleased to
meet you
*Oct 16 09:04:13.183: (C)R: 250-EXPN
*Oct 16 09:04:13.183: (C)R: 250-VERB

debug mta send rcpt-to Displays output for a specific on-ramp SMTP client connection
during an e-mail transmission.

May 2008 DB-1717
Debug Commands
debug mta send rcpt-to

Note Effective with release 12.3(8)T, the debug mta send rcpt-to command is no longer available in
Cisco IOS.
To display output for a specific on-ramp Simple Mail Transfer Protocol (SMTP) client connection during
an e-mail transmission, use the debug mta send rcpt-to command in privileged EXEC mode. To disable
debug mta send rcpt-to string
no debug mta send rcpt-to string
Syntax Description string E-mail address.

12.3(8)T This command was removed and is no longer available in Cisco IOS
software.
Examples The following example shows debugging information displayed when the debug mta send rcpt-to
command has been enabled and the SMTP client is sending an e-mail message:
Router# debug mta send rcpt-to 5551212
Router# socket 0 attempting to connect to IP address 100.00.00.00

socket 0 readable for first time - let's try to read it
R:220 madeup.abc.com ESMTP Sendmail 8.8.4-abc.1/8.6.5 ready at Tue, 6
Apr 1999 13:35:39 -0700 (PDT)
S:EHLO mmoip-c.abc.com
R:250-quisp.cisco.com Hello [100.00.00.00], pleased to meet you

DB-1718 May 2008
Debug Commands
R:250-EXPN
R:250-VERB
R:250-8BITMIME
R:250-SIZE
R:250-DSN
R:250-ETRN
R:250-XUSR
R:250 HELP
S:MAIL FROM:<testing@> RET=HDRS
R:250 <testing@>... Sender ok
S:RCPT TO:<madeup@abc.com> NOTIFY=SUCCESS ORCPT=rfc822;testing@
R:250 <madeup@abc.com>... Recipient ok
R:354 Enter mail, end with "." on a line by itself
S:Received:(Cisco Powered Fax System) by mmoip-c.cisco.com for
<madeup@abc.com> (with Cisco NetWorks); Fri, 17 Oct 1997 14:54:27 +0800
S:To: <madeup@abc.com>
S:Message-ID:<000F1997145427146@mmoip-c.cisco.com>
S:Date:Fri, 17 Oct 1997 14:54:27 +0800
S:Subject:mmoip-c subject here
S:X-Mailer:IOS (tm) 5300 Software (C5300-IS-M)
S:MIME-Version:1.0
S:Content-Type:multipart/mixed;
S: boundary="yradnuoB=_000E1997145426826.mmoip-ccisco.com"
S:From:"Test User" <testing@>
S:--yradnuoB=_000E1997145426826.mmoip-ccisco.com
S:Content-ID:<00101997145427150@mmoip-c.cisco.com>
S:--yradnuoB=_000E1997145426826.mmoip-ccisco.com--
Sending terminating dot ...(socket=0)
S:.
R:250 NAA09092 Message accepted for delivery
S:QUIT
R:221 madeup@abc.com closing connection
Freeing SMTP ctx at 0x6121D454
returned from work_routine, context freed

debug mta send all Displays output for all the on-ramp client connections.

May 2008 DB-1719
Debug Commands
debug mwi relay errors

To debug message waiting indication (MWI) relay errors, use the debug mwi relay errors command in
no debug mwi relay errors

12.2(2)XT This command was introduced on the following platforms: Cisco 1750,
Cisco 1751, Cisco 2600 series and Cisco 3600 series multiservice routers;
routers.
Usage Guidelines The debug mwi relay errors command provides a debug monitor display of any error messages, when
MWI Relay Server (Cisco IOS Telephony Server) is trying to do MWI Relay to extensions on remote
Cisco IOS Telephony Service (ITS).
Examples The following examples show errors when MWI Relay Server tries to do an MWI Relay to extension
7004, but location of 7004 is not known to the MWI Relay Server:
Router# debug mwi relay errors
mwi-relay error info debugging is on

01:46:48: MWI-APP: mwi_notify_status: No ClientID (7004) registered

DB-1720 May 2008
Debug Commands

debug ephone mwi Sets MWI debugging for the Cisco IOS Telephony
Service router.
debug mwi relay events Sets MWI relay events debugging for the Cisco IOS
Telephony Service router.

May 2008 DB-1721
Debug Commands
debug mwi relay events

To set message waiting indication (MWI) relay events debugging, use the debug mwi relay events
no debug mwi relay events

12.2(2)XT This command was introduced on the following platforms: Cisco 1750,
Cisco 1751, Cisco 2600 series and Cisco 3600 series multiservice routers;
routers.
Usage Guidelines The debug mwi relay events command provides a debug monitor display of events, when MWI Relay
Server (Cisco IOS Telephony Server) is trying to do MWI Relay to extensions on remote Cisco IOS
Telephony Services (ITS).
Examples The following debugging messages are shown when the MWI Relay server tries to send MWI
Information to remote client 7001 and the location of 7001 is known by the MWI Relay Server:
Router# debug mwi relay events
mwi-relay events info debugging is on
01:45:34: mwi_notify_status: Queued event for mwi_app_queue

01:45:34: MWI-APP: mwi_app_process_event:
01:45:34: MWI-APP: mwi_app_process_event: MWI Event for ClientID(7001)@(1.8.17.22)

DB-1722 May 2008
Debug Commands

debug ephone mwi Sets MWI debugging for the Cisco IOS Telephony Service
router.
debug mwi relay errors Sets MWI relay errors debugging for the Cisco IOS Telephony
Service router.

May 2008 DB-1723
Debug Commands
debug ncia circuit
debug ncia circuit

To display circuit-related information between the native client interface architecture (NCIA) server and
client, use the debug ncia circuit command in privileged EXEC mode. To disable debugging output, use
debug ncia circuit [error | event | flow-control | state]
no debug ncia circuit [error | event | flow-control | state]
Syntax Description error (Optional) Displays the error situation for each circuit.
event (Optional) Displays the packets received and sent for each circuit.
flow-control (Optional) Displays the flow control information for each circuit.
state (Optional) Displays the state changes for each circuit.
Usage Guidelines NCIA is an architecture developed by Cisco for accessing Systems Network Architecture (SNA)
applications. This architecture allows native SNA interfaces on hosts and clients to access TCP/IP
backbones.
You cannot enable debugging output for a particular client or particular circuit.
Caution Do not enable the debug ncia circuit command during normal operation because this command
generates a substantial amount of output messages and could slow down the router.
Examples The following is sample output from the debug ncia circuit error command. In this example, the
possible errors are displayed. The first error message indicates that the router is out of memory. The
second message indicates that the router has an invalid circuit control block. The third message indicates
that the router is out of memory. The remaining messages identify errors related to the finite state
machine.
Router# debug ncia circuit error
NCIA: ncia_circuit_create memory allocation fail

NCIA: ncia_send_ndlc: invalid circuit control block
NCIA: send_ndlc: fail to get buffer for ndlc primitive xxx
NCIA: ncia circuit fsm: Invalid input
NCIA: ncia circuit fsm: Illegal state
NCIA: ncia circuit fsm: Illegal input
NCIA: ncia circuit fsm: Unexpected input
NCIA: ncia circuit fsm: Unknown error rtn code
The following is sample output from the debug ncia circuit event command. In this example, a session
startup sequence is displayed.
Router# debug ncia circuit event
NCIA(IN): Ver_Id: 0x81, MsgType: NDLC_START_DL, Len: 24, tmac: 4000.1060.1000,

DB-1724 May 2008
Debug Commands
debug ncia circuit
tsap: 4, csap 8, oid: 8A91E8, tid 0, lfs 16, ws 1

NCIA: create circuit: saddr 4000.1060.1000, ssap 4, daddr 4000.3000.0003, dsap 8 sid:
8B09A8
NCIA: send NDLC_DL_STARTED to client 10.2.20.3 for ckt: 8B09A8
NCIA(OUT): Ver_Id: 0x81, MsgType: NDLC_DL_STARTED, Len: 2,4 tmac: 4000.1060.1000,
tsap: 4, csap 8, oid: 8A91E8, tid 8B09A8, lfs 16, ws 1
NCIA(IN): Ver_Id: 0x81, MsgType: NDLC_XID_FRAME, Len: 12, sid: 8B09A8, FC 0x81
NCIA: send NDLC_XID_FRAME to client 10.2.20.3 for ckt: 8B09A8
NCIA(OUT): Ver_Id: 0x81, MsgType: NDLC_XID_FRAME, Len: 12, sid: 8A91E8, FC 0xC1
NCIA(IN): Ver_Id: 0x81, MsgType: NDLC_XID_FRAME, Len: 18, sid: 8B09A8, FC 0xC1
NCIA: send NDLC_CONTACT_STN to client 10.2.20.3 for ckt: 8B09A8
NCIA(OUT): Ver_Id: 0x81, MsgType: NDLC_CONTACT_STN, Len: 12, sid: 8A91E8, FC 0xC1
NCIA(IN): Ver_Id: 0x81, MsgType: NDLC_STN_CONTACTED, Len: 12, sid: 8B09A8, FC 0xC1
NCIA: send NDLC_INFO_FRAME to client 10.2.20.3 for ckt: 8B09A8
NCIA(OUT): Ver_Id: 0x81, MsgType: NDLC_INFO_FRAME, Len: 30, sid: 8A91E8, FC 0xC1
Table 244 debug ncia circuit event Field Descriptions
Field Description
IN Incoming message from client.
OUT Outgoing message to client.
Ver_Id NDLC version ID.
MsgType NDLC message type.
Len NDLC message length.
tmac Target MAC.
tsap Target SAP.
csap Client SAP.
oid Origin ID.
tid Target ID.
lfs Largest frame size flag.
ws Window size.
saddr Source MAC address.
ssap Source SAP.
daddr Destination MAC address.
dsap Destination SAP.
sid Session ID.
FC Flow control flag.
In the following messages, an NDLC_START_DL messages is received from a client to start a data-link
session:
NCIA(IN): Ver_Id: 0x81, MsgType: NDLC_START_DL, Len: 24, tmac: 4000.1060.1000,
tsap: 4, csap 8, oid: 8A91E8, tid 0, lfs 16, ws 1
NCIA: create circuit: saddr 4000.1060.1000, ssap 4, daddr 4000.3000.0003, dsap 8 sid:
8B09A8
The next two messages indicate that an NDLC_DL_STARTED message is sent to a client. The server
informs the client that a data-the link session is started.

May 2008 DB-1725
Debug Commands
debug ncia circuit
NCIA: send NDLC_DL_STARTED to client 10.2.20.3 for ckt: 8B09A8

NCIA(OUT): Ver_Id: 0x81, MsgType: NDLC_DL_STARTED, Len: 2,4 tmac: 4000.1060.1000,
tsap: 4, csap 8, oid: 8A91E8, tid 8B09A8, lfs 16, ws 1
In the following two messages, an NDLC_XID_FRAME message is received from a client, and the client
starts an XID exchange:
NCIA(IN): Ver_Id: 0x81, MsgType: NDLC_XID_FRAME, Len: 12, sid: 8B09A8, FC 0x81
NCIA: send NDLC_XID_FRAME to client 10.2.20.3 for ckt: 8B09A8
In the following two messages, an NDLC_XID_FRAME message is sent from a client, and an
DLC_XID_FRAME message is received from a client:
NCIA(OUT): Ver_Id: 0x81, MsgType: NDLC_XID_FRAME, Len: 12, sid: 8A91E8, FC 0xC1
NCIA(IN): Ver_Id: 0x81, MsgType: NDLC_XID_FRAME, Len: 18, sid: 8B09A8, FC 0xC1
The next two messages show that an NDLC_CONTACT_STN message is sent to a client:
NCIA: send NDLC_CONTACT_STN to client 10.2.20.3 for ckt: 8B09A8
NCIA(OUT): Ver_Id: 0x81, MsgType: NDLC_CONTACT_STN, Len: 12, sid: 8A91E8, FC 0xC1
In the following message, an NDLC_STN_CONTACTED message is received from a client. The client
informs the server that the station has been contacted.
NCIA(IN): Ver_Id: 0x81, MsgType: NDLC_STN_CONTACTED, Len: 12, sid: 8B09A8, FC 0xC1
In the last two messages, an NDLC_INFO_FRAME is sent to a client, and the server sends data to the
client:
NCIA: send NDLC_INFO_FRAME to client 10.2.20.3 for ckt: 8B09A8
NCIA(OUT): Ver_Id: 0x81, MsgType: NDLC_INFO_FRAME, Len: 30, sid: 8A91E8, FC 0xC1
The following is sample output from the debug ncia circuit flow-control command. In this example,
the flow control in a session startup sequence is displayed:
Router# debug ncia circuit flow-control
NCIA: no flow control in NDLC_DL_STARTED frame

NCIA: receive Increment Window Op for circuit 8ADE00
NCIA: ncia_flow_control_in FC 0x81, IW 1 GP 2 CW 2, Client IW 1 GP 0 CW 1
NCIA: grant client more packet by sending Repeat Window Op
NCIA: ncia_flow_control_out FC: 0xC1, IW 1 GP 2 CW 2, Client IW 1 GP 2 CW 2
NCIA: receive FCA for circuit 8ADE00
NCIA: ncia_flow_control_in FC 0xC1, IW 1 GP 5 CW 3, Client IW 1 GP 2 CW 2
NCIA: ncia_flow_control_in FC 0xC1, IW 1 GP 9 CW 4, Client IW 1 GP 5 CW 3
NCIA: reduce ClientGrantPacket by 1 (Granted: 8)

DB-1726 May 2008
Debug Commands
debug ncia circuit
Table 245 debug ncia circuit flow-control Field Descriptions
Field Description
IW Initial window size.
GP Granted packet number.
CW Current window size.
The following is sample output from the debug ncia circuit state command. In this example, a session
startup sequence is displayed:
Router# debug ncia circuit state
NCIA: pre-server fsm: event CONN_OPENED

NCIA: pre-server fsm: event NDLC_PRIMITIVES
NCIA: server event: WAN - STDL state: CLSOED
NCIA: ncia server fsm action 32
NCIA: circuit state: CLOSED -> START_DL_RCVD
NCIA: server event: DLU - TestStn.Rsp state: START_DL_RCVD
NCIA: circuit state: START_DL_RCVD -> DL_STARTED_SND
NCIA: server event: WAN - XID state: DL_STARTED_SND
NCIA: circuit state: DL_STARTED_SND -> DL_STARTED_SND
NCIA: server event: DLU - ReqOpnStn.Req state: DL_STARTED_SND
NCIA: circuit state: DL_STARTED_SND -> OPENED
NCIA: server event: DLU - Id.Rsp state: OPENED
NCIA: circuit state: OPENED -> OPENED
NCIA: server event: WAN - XID state: OPENED
NCIA: circuit state: OPENED -> OPENED
NCIA: server event: DLU - Connect.Req state: OPENED
NCIA: circuit state: OPENED -> CONNECT_PENDING
NCIA: server event: WAN - CONR state: CONNECT_PENDING
NCIA: ncia server fsm action 33 --> CLS_CONNECT_CNF sets NciaClsBusy
NCIA: circuit state: CONNECT_PENDING -> CONNECTED
NCIA: server event: DLU - Flow.Req (START) state: CONNECTED
NCIA: ncia server fsm action 25 --> unset NciaClsBusy
NCIA: circuit state: CONNECTED -> CONNECTED
NCIA: server event: DLU - Data.Rsp state: CONNECTED
NCIA: circuit state: CONNECTED -> CONNECTED
Table 246 debug ncia circuit state Field Descriptions
Field Description
WAN Event from WAN (client).

May 2008 DB-1727
Debug Commands
debug ncia circuit
Table 246 debug ncia circuit state Field Descriptions (continued)
Field Description
DLU Event from upstream moduledependent logical unit (DLU).
ADMIN Administrative event.
TIMER Timer event.

debug dmsp fax-to-doc Enables debugging of DLSw+.
debug ncia client Displays debug information for all NCIA client processing that
occurs in the router.
debug ncia server Displays debug information for the NCIA server and its upstream
software modules.

DB-1728 May 2008
Debug Commands
debug ncia client
debug ncia client

To display debug information for all native client interface architecture (NCIA) client processing that
occurs in the router, use the debug ncia client command in privileged EXEC mode. To disable
debug ncia client [ip-address | error [ip-address] | event [ip-address] | message [ip-address]]
no debug ncia client [ip-address | error [ip-address] | event [ip-address] | message [ip-address]]
Syntax Description ip-address (Optional) The remote client IP address.

error (Optional) Triggers the recording of messages only when errors occur. The
current state and event of an NCIA client are normally included in the message.
If you do not specify an IP address, the error messages are logged for all active
clients.
event (Optional) Triggers the recording of messages that describe the current state
and eventand sometimes the action that just completedfor the NCIA client.
If you do not specify an IP address, the messages are logged for all active
clients.
message (Optional) Triggers the recording of messages that contain up to the first 32
bytes of data in a TCP packet sent to or received from an NCIA client. If you
do not specify an IP address, the messages are logged for all active clients.
backbones.
Use the debug ncia client error command to see only certain error conditions that occur.
Use the debug ncia client event command to determine the sequences of activities that occur while an
NCIA client is in different processing states.
Use the debug ncia client message command to see only the first 32 bytes of data in a TCP packet sent
to or received from an NCIA client.
The debug ncia client command can be used in conjunction with the debug ncia server and debug ncia
circuit commands to get a complete picture of NCIA activity.
Examples The following is sample output from the debug ncia client command. Following the example is a
description of each sample output message.
Router# debug ncia client
NCIA: Passive open 10.2.20.123(1088) -> 1973

NCIA: index for client hash queue is 27
NCIA: number of element in client hash queue 27 is 1
NCIA: event PASSIVE_OPEN, state NCIA_CLOSED for client 10.2.20.123
NCIA: Rcvd msg type NDLC_CAP_XCHG in tcp packet for client 10.2.20.123

May 2008 DB-1729
Debug Commands
debug ncia client
NCIA: First 17 byte of data rcvd: 811200110000000000000400050104080C

NCIA: Sent msg type NDLC_CAP_XCHG in tcp packet to client 10.2.20.123
NCIA: First 17 byte of data sent: 811200111000000010000400050104080C
NCIA: event CAP_CMD_RCVD, state NCIA_CAP_WAIT, for client 10.2.20.123, cap xchg cmd sent
NCIA: Rcvd msg type NDLC_CAP_XCHG in tcp packet for client 10.2.20.123
NCIA: First 17 byte of data rcvd: 811200111000000010000000050104080C
NCIA: event CAP_RSP_RCVD, state NCIA_CAP_NEG for client 10.2.20.123
NCIA: Rcvd msg type NDLC_PEER_TEST_REQ in tcp packet for client 10.2.20.123
NCIA: First 4 byte of data rcvd: 811D0004
NCIA: event KEEPALIVE_RCVD, state NCIA_OPENED for client 10.2.20.123
NCIA: Sent msg type NDLC_PEER_TEST_RSP in tcp packet to client 10.2.20.123
NCIA: First 4 byte of data sent: 811E0004IA
NCIA: event TIME_OUT, state NCIA_OPENED, for client 10.2.20.123, keepalive_count = 0

NCIA: Sent msg type NDLC_PEER_TEST_REQ, in tcp packet to client 10.2.20.123
NCIA: First 4 byte of data sent: 811D0004
NCIA: Rcvd msg type NDLC_PEER_TEST_RSP in tcp packet for client 10.2.20.123
NCIA: First 4 byte of data rcvd: 811E0004
NCIA: event KEEPALIVE_RSP_RCVD, state NCIA_OPENED for client 10.2.20.123
NCIA: Error, event PASIVE_OPEN, state NCIA_OPENED, for client 10.2.20.123, should not have
occurred.
NCIA: Error, active_open for pre_client_fsm while client 10.2.20.123 is active or not
configured, registered.
Messages in lines 1 through 12 show the events that occur when a client connects to the router (the NCIA
server). These messages show a passive_open process.
Messages in lines 13 to 17 show the events that occur when a TIME_OUT event is detected by a client
PC workstation. The workstation sends an NDLC_PEER_TEST_REQ message to the NCIA server, and
the router responds with an NDLC_PEER_TEST_RSP message.
Messages in lines 18 to 23 show the events that occur when a TIME_OUT event is detected by the router
(the NCIA server). The router sends an NDLC_PEER_TEST_REQ message to the client PC
workstation, and the PC responds with an NDLC_PEER_TEST_RSP message.
When you use the debug ncia client message command, the messages shown on lines 6, 8, 11, 14, 17,
20, and 22 are output in addition to other messages not shown in this example.
When you use the debug ncia client error command, the messages shown on lines 24 and 25 are output
in addition to other messages not shown in this example.

debug ncia circuit Displays debug information for all NCIA client processing that occurs in the
router.
debug ncia server Displays debug information for the NCIA server and its upstream software
modules.

DB-1730 May 2008
Debug Commands
debug ncia server
debug ncia server

To display debug information for the native client interface architecture (NCIA) server and its upstream
software modules, use the debug ncia server command in privileged EXEC mode. To disable debugging
debug ncia server
no debug ncia server
backbones.
The debug ncia server command displays all Cisco Link Services (CLS) messages between the NCIA
server and its upstream modules, such as data-link switching (DLSw) and downstream physical units
(DSPUs). Use this command when a problem exists between the NCIA server and other software
modules within the router.
You cannot enable debugging output for a particular client or particular circuit.
Examples The following is sample output from the debug ncia server command. In this example, a session startup
sequence is displayed. Following the example is a description of each group of sample output messages.
Router# debug ncia server
NCIA: send CLS_TEST_STN_IND to DLU

NCIA: Receive TestStn.Rsp
NCIA: send CLS_ID_STN_IND to DLU
NCIA: Receive ReqOpnStn.Req
NCIA: send CLS_REQ_OPNSTN_CNF to DLU
NCIA: Receive Id.Rsp
NCIA: send CLS_ID_IND to DLU
NCIA: Receive Connect.Req
NCIA: send CLS_CONNECT_CNF to DLU
NCIA: Receive Flow.Req
NCIA: Receive Data.Req
NCIA: send CLS_DATA_IND to DLU
NCIA: send CLS_DISC_IND to DLU
NCIA: Receive Disconnect.Rsp
In the following messages, the client is sending a test message to the host and the test message is received
by the host:
NCIA: send CLS_TEST_STN_IND to DLU
NCIA: Receive TestStn.Rsp

May 2008 DB-1731
Debug Commands
debug ncia server
In the next message, the server is sending an exchange identification (XID) message to the host:
NCIA: send CLS_ID_STN_IND to DLU
In the next two messages, the host opens the station and the server responds:
NCIA: Receive ReqOpnStn.Req
NCIA: send CLS_REQ_OPNSTN_CNF to DLU
In the following two messages, the client is performing an XID exchange with the host:
NCIA: Receive Id.Rsp
NCIA: send CLS_ID_IND to DLU
In the next group of messages, the host attempts to establish a session with the client:
NCIA: Receive Connect.Req
NCIA: send CLS_CONNECT_CNF to DLU
NCIA: Receive Flow.Req
In the next two messages, the host sends data to the client:
NCIA: Receive Data.Req
NCIA: send CLS_DATA_IND to DLU
In the last two messages, the client closes the session:

NCIA: send CLS_DISC_IND to DLU
NCIA: Receive Disconnect.Rsp

debug dmsp fax-to-doc Enables debugging of DLSw+.
debig mcoa circuit Displays circuit-related information between the NCIA server and
client.
debug ncia client Displays debug information for all NCIA client processing that
occurs in the router.

DB-1732 May 2008
Debug Commands
debug netbios error
debug netbios error

To display information about Network Basic Input/Output System (NetBIOS) protocol errors, use the
debug netbios error command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug netbios error
no debug netbios error
Usage Guidelines For complete information on the NetBIOS process, use the debug netbios packet command along with
the debug netbios error command.
Examples The following is sample output from the debug netbios error command. This example shows that an
illegal packet has been received on the asynchronous interface.
Router# debug netbios error
Async1 nbf Bad packet

debug netbios-name-cache Displays name caching activities on a router.
debug netbios packet Displays general information about NetBIOS packets.

May 2008 DB-1733
Debug Commands
debug netbios packet

To display general information about Network Basic Input/Output System (NetBIOS) packets, use the
debug netbios packet command in privileged EXEC mode. To disable debugging output, use the no
no debug netbios packet
Usage Guidelines For complete information on the NetBIOS process, use the debug netbios error command along with
the debug netbios packet command.
Examples The following is sample output from the debug netbios packet and debug netbios error commands.
This example shows the Logical Link Control (LLC) header for an asynchronous interface followed by
the NetBIOS information. For additional information on the NetBIOS fields, refer to IBM LAN Technical
Reference IEEE 802.2.
Router# debug netbios packet
Async1 (i) U-format UI C_R=0x0

(i) NETBIOS_ADD_NAME_QUERY
Resp_correlator= 0x6F 0x0
Src name=CS-NT-1

(i) NETBIOS_ADD_GROUP_QUERY
Src name=COMMSERVER-WG

(i) NETBIOS_ADD_NAME_QUERY
Src name=CS-NT-1
Ethernet0 (i) U-format UI C_R=0x0

(i) NETBIOS_DATAGRAM
Length= 0x2C 0x0
Dest name=COMMSERVER-WG
Src name=CS-NT-3

debug netbios error Displays information about NetBIOS protocol errors.
debug netbios-name-cache Displays name caching activities on a router.

DB-1734 May 2008
Debug Commands
debug netbios-name-cache
To display name caching activities on a router, use the debug netbios-name-cache command in
no debug netbios-name-cache
Usage Guidelines Examine the display to diagnose problems in Network Basic Input/Output System (NetBIOS) name
caching.
Examples The following is sample output from the debug netbios-name-cache command:
Router# debug netbios-name-cache
NETBIOS: L checking name ORINDA, vrn=0

NetBIOS name cache table corrupted at offset 13
NetBIOS name cache table corrupted at later offset, at location 13
NETBIOS: U chk name=ORINDA, addr=1000.4444.5555, idb=TR1, vrn=0, type=1
NETBIOS: U upd name=ORINDA,addr=1000.4444.5555,idb=TR1,vrn=0,type=1
NETBIOS: U add name=ORINDA,addr=1000.4444.5555,idb=TR1,vrn=0,type=1
NETBIOS: U no memory to add cache entry. name=ORINDA,addr=1000.4444.5555
NETBIOS: Invalid structure detected in netbios_name_cache_ager
NETBIOS: flushed name=ORINDA, addr=1000.4444.5555
NETBIOS: expired name=ORINDA, addr=1000.4444.5555
NETBIOS: removing entry. name=ORINDA,addr=1000.4444.5555,idb=TR1,vrn=0
NETBIOS: Tossing ADD_NAME/STATUS/NAME/ADD_GROUP frame
NETBIOS: Lookup Failed -- not in cache
NETBIOS: Lookup Worked, but split horizon failed
NETBIOS: Could not find RIF entry
NETBIOS: Cannot duplicate packet in netbios_name_cache_proxy
Note The sample display is a composite output. Debugging output that you actually see would not necessarily
occur in this sequence.
Table 247 debug netbios-name-cache Field Descriptions
Field Description
NETBIOS NetBIOS name caching debugging output.
L, U L means lookup; U means update.
addr=1000.4444.5555 MAC address of machine being looked up in NetBIOS name cache.

May 2008 DB-1735
Debug Commands
Table 247 debug netbios-name-cache Field Descriptions (continued)
Field Description
idb=TR1 Indicates that the name of machine was learned from Token Ring
interface number 1; idb is into interface data block.
vrn=0 Packet comes from virtual ring number 0. This packet actually comes
from a real Token Ring interface, because virtual ring number 0 is not
valid.
type=1 Indicates the way that the router learned about the specified machine.
The possible values are as follows:
1Learned from traffic
2Learned from a remote peer
4Statically entered via the configuration of the router
With the first line of output, the router declares that it has examined the NetBIOS name cache table for
the machine name ORINDA and that the packet that prompted the lookup came from virtual ring 0. In
this case, this packet comes from a real interfacevirtual ring number 0 is not valid.
NETBIOS: L checking name ORINDA, vrn=0
The following two lines indicate that an invalid NetBIOS entry exists and that the corrupted memory was
detected. The invalid memory will be removed from the table; no action is needed.
NetBIOS name cache table corrupted at offset 13
NetBIOS name cache table corrupted at later offset, at location 13
The following line indicates that the router attempted to check the NetBIOS cache table for the name
ORINDA with MAC address 1000.4444.5555. This name was obtained from Token Ring interface 1. The
type field indicates that the name was learned from traffic.
NETBIOS: U chk name=ORINDA, addr=1000.4444.5555, idb=TR1, vrn=0, type=1
The following line indicates that the NetBIOS name ORINDA is in the name cache table and was
updated to the current value:
NETBIOS: U upd name=ORINDA,addr=1000.4444.5555,idb=TR1,vrn=0,type=1
The following line indicates that the NetBIOS name ORINDA is not in the table and must be added to
the table:
NETBIOS: U add name=ORINDA,addr=1000.4444.5555,idb=TR1,vrn=0,type=1
The following line indicates that there was insufficient cache buffer space when the router tried to add
this name:
NETBIOS: U no memory to add cache entry. name=ORINDA,addr=1000.4444.5555
The following line indicates that the NetBIOS ager detects an invalid memory in the cache. The router
clears the entry; no action is needed.
NETBIOS: Invalid structure detected in netbios_name_cache_ager
The following line indicates that the entry for ORINDA was flushed from the cache table:
NETBIOS: flushed name=ORINDA, addr=1000.4444.5555

DB-1736 May 2008
Debug Commands
The following line indicates that the entry for ORINDA timed out and was flushed from the cache table:
NETBIOS: expired name=ORINDA, addr=1000.4444.5555
The following line indicates that the router removed the ORINDA entry from its cache table:
NETBIOS: removing entry. name=ORINDA,addr=1000.4444.5555,idb=TR1,vrn=0
The following line indicates that the router discarded a NetBIOS packet of type ADD_NAME, STATUS,
NAME_QUERY, or ADD_GROUP. These packets are discarded when multiple copies of one of these
packet types are detected during a certain period of time.
NETBIOS: Tossing ADD_NAME/STATUS/NAME/ADD_GROUP frame
The following line indicates that the system could not find a NetBIOS name in the cache:
NETBIOS: Lookup Failed -- not in cache
The following line indicates that the system found the destination NetBIOS name in the cache, but
located on the same ring from which the packet came. The router will drop this packet because the packet
should not leave this ring.
NETBIOS: Lookup Worked, but split horizon failed
The following line indicates that the system found the NetBIOS name in the cache, but the router could
not find the corresponding RIF. The packet will be sent as a broadcast frame.
NETBIOS: Could not find RIF entry
The following line indicates that no buffer was available to create a NetBIOS name cache proxy. A proxy
will not be created for the packet, which will be forwarded as a broadcast frame.
NETBIOS: Cannot duplicate packet in netbios_name_cache_proxy

debug netbios error Displays information about NetBIOS protocol errors.
debug netbios packet Displays general information about NetBIOS packets.

May 2008 DB-1737
Debug Commands
debug netconf
debug netconf
To enable debugging of network configuration protocol (NETCONF) sessions, use the debug netconf
command in privileged EXEC mode. To turn off NETCONF debugging, use the no form of this
command.
debug netconf {all | error}
no debug netconf {all | error}
Syntax Description all Enables debugging of NETCONF sessions, including NETCONF errors.
error Enables debugging of NETCONF errors.
Command Default NETCONF debugging is not enabled.

Usage Guidelines The debug netconf command issues debug information only when an operational error has happened.
In most situations, the NETCONF notifications sent between the NETCONF Network Manager and the
client are sufficient to diagnose most NETCONF problems.
To view Extensible Markup Language (XML) parsing errors when using NETCONF over SSHv2, you
must also configure the debug cns xml all command.
Examples The following example shows how to enable debugging of all NETCONF sessions:
Router# debug netconf
00:14:03: NETCONF-ERROR: could not find user1

00:14:03: NETCONF-ERROR: could not find tftp://samplelocation/samplefile
00:14:03: NETCONF: locking 1 by session 646B7038
00:14:03: NETCONF-ERROR: invalid session unlock attempt
00:14:03: NETCONF-ERROR: lock already active
00:14:13: NETCONF-ERROR: lock time 1 expired closing session 646B7038

DB-1738 May 2008
Debug Commands
debug netconf
Table 248 debug netconf Field Descriptions
Field Description
NETCONF-ERROR: could not find NETCONF could not find the specified username.
user1
NETCONF-ERROR: could not find NETCONF could not find the specified file path.
tftp://samplelocation/samplefile
NETCONF: locking 1 by session This user is locking NETCONF.
646B7038
NETCONF-ERROR: invalid session Another user is trying to unlock NETCONF without first
unlock attempt acquiring the lock.
NETCONF-ERROR: lock already Another user is trying to lock NETCONF while it is currently
active locked.
NETCONF-ERROR: lock time 1 A locked NETCONF session has been idle longer than the
expired closing session 646B7038 time configured by the netconf lock-time command. The
locked NETCONF session is closed.

clear netconf Clears NETCONF statistics counters, NETCONF sessions, and frees
associated resources and locks.
debug cns xml Turns on debugging messages related to the CNS XML parser.
netconf lock-time Specifies the maximum time a NETCONF configuration lock is in place
without an intermediate operation.
netconf max-sessions Specifies the maximum number of concurrent NETCONF sessions allowed.
netconf ssh Enables NETCONF over SSHv2.
show netconf Displays NETCONF statistics counters and session information.

May 2008 DB-1739
Debug Commands
debug nextport vsmgr detail

To turn on debugging for NextPort voice services, use the debug nextport vsmgr detail command in
no debug nextport vsmgr detail

12.3(14)T T.38 fax relay call statistics were made available to Call Detail Records
(CDRs) through Vendor-Specific Attributes (VSAs) and added to the call
log.
Usage Guidelines This command debugs digital signal processor (DSP) message exchanges between applications and the
DSP.
Examples The following examples turn on debugging for NextPort voice services:
debug nextport vsmgr detail Command on the Originating Gateway

Router# debug nextport vsmgr detail
NextPort Voice Service Manager:

NP Voice Service Manager Detail debugging is on
.
.
.
May 7 21:09:49.135 UTC: vsm(1/2): np_vsmgr_voice_state_change() - state IDLE
May 7 21:09:49.291 UTC: vsm(1/2): np_vsmgr_voice_state_change() - state ACTIVE

DB-1740 May 2008
Debug Commands
May 7 21:09:51.803 UTC: np_vsmgr_dispatch_voice_rsp(1/2): VOICE_LINK_INFO_RSP_NTF

Received
May 7 21:09:51.803 UTC: request_id = 0x01, request_type = 0x0F
May 7 21:09:51.803 UTC: VOICE_TRANSMIT_STATS(1/2): num_voice_packets 4 num_sig_packets 0
num_cn_packets 1 transmit_duration 8FC end_point_detection 0
May 7 21:09:51.803 UTC: VOICE_RECEIVE_STATS(1/2): num_voice_packets 4 num_sig_packets 0
num_cn_packets 1 receive_duration 8FC voice_receive_duration 0 num_pos_packets 0
num_bph_packets 0 num_late_packets 0 num_early_packets 0
May 7 21:09:51.803 UTC: VOICE_PLAYOUT_DELAY_STATS(1/2): curr_playout_delay 0
min_playout_delay 0 max_playout_delay 0 clock offset 0
May 7 21:09:51.803 UTC: VOICE_PLAYOUT_ERROR(1/2): pred_conceal 0x0 inter_conceal 0x0
silence_conceal 0x0 buffer_overflow 0x0 endpt_det_error 0x0
Received
May 7 21:09:53.231 UTC: VOICE_TRANSMIT_STATS(1/2): num_voice_packets 1E num_sig_packets 0
num_cn_packets 1 transmit_duration E92 end_point_detection 0
num_cn_packets 1 receive_duration E92 voice_receive_duration 0 num_pos_packets 0
May 7 21:09:53.231 UTC: VOICE_PLAYOUT_DELAY_STATS(1/2): curr_playout_delay 5A
min_playout_delay 5A max_playout_delay 5A clock offset 19778906
Received
num_cn_packets 2 transmit_duration 19A0 end_point_detection BB8
May 7 21:09:56.055 UTC: VOICE_RECEIVE_STATS(1/2): num_voice_packets 8A num_sig_packets 0
num_cn_packets 1 receive_duration 19A0 voice_receive_duration 0 num_pos_packets 0
May 7 21:09:56.055 UTC: VOICE_PLAYOUT_DELAY_STATS(1/2): curr_playout_delay 3C
min_playout_delay 3C max_playout_delay 64 clock offset 197788E4
May 7 21:09:57.907 UTC: FAX_RELAY_LINK_INFO_RSP_NTF: slot 1 port 2 timestamp 68137565
fr-entered (20ms)
May 7 21:09:57.907 UTC: chan_id [3/1:D] np_vsmgr_fax_relay_link_info_response:
May 7 21:10:15.047 UTC: np_fax_relay_t30_decode : Tx Direction
May 7 21:10:15.067 UTC: FARELAY_INIT_HS_MOD : 0xC
May 7 21:10:51.579 UTC: FAX_RELAY_DATA_PUMP_STATS(1/2) - valid:0x3FFC1F55 state_code:0x0
level:0x18 phase_jitter:0x5 freq_offset:0x0 eqm:0x7FFE jit_depth:0x230 jit_buf_ov:0x0
tx_paks:0x626 rx_pkts:0x5A inv_pkts:0x0 oos_pkts:0x0 hs_mod:0x8 init_hs_mod:0xC tx_pgs:0x1
rx_pgs:0x0 ecm:0x1 nsf_country:0x0 nsf_manuf_len:0x20
nsf_manuf:0031B8EE80C48511DD0D0000DDDD0000DDDD000000000000000022ED00B0A400 encap:0x1
pkt_loss_con:0x0
May 7 21:10:52.463 UTC: vsm(1/2): np_vsmgr_voice_state_change - NULL DSP Interface Handle
debug nextport vsmgr detail Command on the Terminating Gateway

Router# debug nextport vsmgr detail
NextPort Voice Service Manager:

NP Voice Service Manager Detail debugging is on
.
.
Router#

May 2008 DB-1741
Debug Commands

Received
num_cn_packets 0 transmit_duration 0 end_point_detection 0
num_cn_packets 0 receive_duration 0 voice_receive_duration 0 num_pos_packets 0
min_playout_delay 0 max_playout_delay 0 clock offset 0
Received
num_cn_packets 1 transmit_duration 910 end_point_detection 0
May 7 21:09:53.787 UTC: VOICE_RECEIVE_STATS(1/2): num_voice_packets 1F num_sig_packets 0
num_cn_packets 2 receive_duration 910 voice_receive_duration 0 num_pos_packets 0
May 7 21:09:53.787 UTC: VOICE_PLAYOUT_DELAY_STATS(1/2): curr_playout_delay 5A
min_playout_delay 5A max_playout_delay 5A clock offset 68877C4
Received
May 7 21:09:56.571 UTC: VOICE_TRANSMIT_STATS(1/2): num_voice_packets A5 num_sig_packets 0
num_cn_packets 1 transmit_duration 13F6 end_point_detection 0
num_cn_packets 2 receive_duration 13F6 voice_receive_duration 7D0 num_pos_packets 0
min_playout_delay 5A max_playout_delay 64 clock offset 68877D4
May 7 21:09:56.807 UTC: VOICE_DET_STATUS_CHANGE_NTF(1/2): detector mask: 1 timestamp
791687D5
fr-entered (20ms)
May 7 21:09:57.911 UTC: chan_id [3/1:D (6)] np_vsmgr_fax_relay_link_info_response:
May 7 21:10:15.043 UTC: np_fax_relay_t30_decode : Rx Direction
May 7 21:10:15.107 UTC: FARELAY_INIT_HS_MOD : 0x8
May 7 21:10:51.376 UTC: FAX_RELAY_DET_STATUS_CHANGE: slot: 1 port: 2 detector mask 0x2
May 7 21:10:51.404 UTC: FAX_RELAY_DATA_PUMP_STATS(1/2) - valid:0x3FFC1F55 state_code:0x1
level:0x18 phase_jitter:0x0 freq_offset:0x0 eqm:0x7FFE jit_depth:0x39E jit_buf_ov:0x0
tx_paks:0x5A rx_pkts:0x626 inv_pkts:0x0 oos_pkts:0x0 hs_mod:0x8 init_hs_mod:0x8 tx_pgs:0x0
rx_pgs:0x1 ecm:0x1 nsf_country:0x0 nsf_manuf_len:0x20
nsf_manuf:0031B8EE80C48511DD0D0000DDDD0000DDDD000000000000000022ED00B0A400 encap:0x1
pkt_loss_con:0x0
fr-end
Received
May 7 21:10:52.416 UTC: request_id = 0x05, request_type = 0x30
May 7 21:10:52.416 UTC: VOICE_LEVELS_STATS(1/2): tx_power FF7E tx_mean FF7F rx_power FDBD
rx_mean FB48 bnl FD81 erl FD acom 1EA tx_act 1 rx_act 0
May 7 21:10:52.440 UTC: vsm(1/2): np_vsmgr_voice_state_change - NULL DSP Interface Handle

DB-1742 May 2008
Debug Commands

debug dspapi detail Displays details of the DSP API message events with debugging
enabled.
voicecap entry Creates a voicecap on NextPort platforms.
voicecap configure Applies a voicecap on NextPort platforms.

May 2008 DB-1743
Debug Commands
debug nhrp condition
debug nhrp condition

To enable Next Hop Resolution Protocol (NHRP) conditional debugging, use the debug nhrp condition
debug nhrp condition {[peer {nbma | tunnel} ip-address] [interface {tunnel number}] [vrf
vrf-name]}
no debug nhrp condition {[peer {nbma | tunnel} ip-address] [interface {tunnel number}] [vrf
vrf-name]}
Syntax Description peer (Optional) Specifies an NHRP peer.

nbma (Optional) Specifies mapping nonbroadcast access (NBMA).
tunnel (Optional) Specifies a tunnel.
ip-address (Optional) Specifies the IP address for the NHRP peer.
interface (Optional) Displays NHRP information based on a specific interface.
tunnel number (Optional) Specifies tunnel address for NHRP peer.
vrf vrf-name (Optional) Specifies debugging information for sessions related to the
specified virtual routing forwarding (VRF) configuration.
Command Default Conditional NHRP debugging is not enabled.

Examples The following example shows how to enable conditional NHRP debugging for a specific tunnel:
Router# debug nhrp condition peer tunnel 192.0.2.1

debug dmvpn Displays DMVPN session debugging information.
debug nhrp error Displays NHRP error level debugging information.

DB-1744 May 2008
Debug Commands
debug nhrp error
debug nhrp error

To display Next Hop Resolution Protocol (NHRP) error level debugging information, use the
debug nhrp error command in privileged EXEC mode. To disable debugging output, use the no form
of this command.
debug nhrp error
no debug nhrp error
Command Default Error level NHRP debugging is not enabled.

Examples The following example shows how to enable error level debugging for NHRP:
Router# debug nhrp error
NHRP errors debugging is on

debug dmvpn Displays DMVPN session debugging information.
debug nhrp condition Enables NHRP conditional debugging.

May 2008 DB-1745
Debug Commands

To display the extensions portion of a NHRP packet, use the debug nhrp extension privileged EXEC
command. The no form of this command disables debugging output.
no debug nhrp extension
Examples The following is sample output from the debug nhrp extension command:
Router# debug nhrp extension
NHRP extension processing debugging is on

Router#
Forward Transit NHS Record Extension(4):
(C-1) code: no error(0)
prefix: 0, mtu: 9180, hd_time: 7200
addr_len: 20(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0
client NBMA: 47.0091810000000002ba08e101.525354555354.01
client protocol: 135.206.58.54
Reverse Transit NHS Record Extension(5):
Responder Address Extension(3):
(C) code: no error(0)
client NBMA: 47.0091810000000002ba08e101.525354555355.01
client NBMA: 47.0091810000000002ba08e101.525354555354.01
Responder Address Extension(3):

DB-1746 May 2008
Debug Commands
debug nhrp options
debug nhrp options

To display information about NHRP option processing, use the debug nhrp options privileged EXEC
debug nhrp options
no debug nhrp options
Usage Guidelines Use this command to show you whether there are problems or error situations with NHRP option
processing (for example, unknown options).
Examples The following is sample output from the debug nhrp options command:
Router# debug nhrp options
NHRP-OPT: MASK 4
NHRP-OPT-MASK: FFFFFFFF
NHRP-OPT: NETID 4
NHRP-OPT: RESPONDER 4
NHRP-OPT: RECORD 0
NHRP-OPT: RRECORD 0
Table 249 debug nhrp options Field Descriptions
Field Descriptions
NHRP-OPT NHRP options debugging output.
MASK 4 Number of bytes of information in the destination prefix option.
NHRP-OPT-MASK Contents of the destination prefix option.
NETID Number of bytes of information in the subnetwork identifier option.
RESPONDER Number of bytes of information in the responder address option.
RECORD Forward record option.
RRECORD Reverse record option.

debug nhrp Displays information about NHRP activity.
debug nhrp packet Displays a dump of NHRP packets.

May 2008 DB-1747
Debug Commands
debug nhrp packet
debug nhrp packet

To display a dump of NHRP packets, use the debug nhrp packet privileged EXEC command. The no
form of this command disables debugging output.
debug nhrp packet
no debug nhrp packet
Examples The following is sample output from the debug nhrp packet command:
Router# debug nhrp packet
NHRP activity debugging is on

Router#
NHRP: Send Purge Request via ATM3/0.1, packet size: 72
src: 135.206.58.55, dst: 135.206.58.56
(F) afn: NSAP(3), type: IP(800), hop: 255, ver: 1
shtl: 20(NSAP), sstl: 0(NSAP)
(M) flags: "reply required", reqid: 2
src NBMA: 47.0091810000000002ba08e101.525354555355.01
src protocol: 135.206.58.55, dst protocol: 135.206.58.56
NHRP: Receive Purge Reply via ATM3/0.1, packet size: 72
(F) afn: NSAP(3), type: IP(800), hop: 254, ver: 1
shtl: 20(NSAP), sstl: 0(NSAP)
(M) flags: "reply required", reqid: 2
src NBMA: 47.0091810000000002ba08e101.525354555355.01
src protocol: 135.206.58.55, dst protocol: 135.206.58.56

DB-1748 May 2008
Debug Commands
debug nhrp rate
debug nhrp rate

To display information about NHRP traffic rate limits, use the debug nhrp rate privileged EXEC
debug nhrp rate
no debug nhrp rate
Usage Guidelines Use this command to verify that the traffic is consistent with the setting of the NHRP commands (such
as ip nhrp use and ip max-send commands).
Examples The following is sample output from the debug nhrp rate command:
Router# debug nhrp rate
NHRP-RATE: Sending initial request

NHRP-RATE: Retransmitting request (retrans ivl 2)
NHRP-RATE: Retransmitting request (retrans ivl 4)
NHRP-RATE: Ethernet1: Used 3
Table 250 debug nhrp rate Field Descriptions
Field Descriptions
NHRP-RATE NHRP rate debugging output.
Sending initial request First time an attempt was made to send an NHRP packet to a
particular destination.
Retransmitting request Indicates that the NHRP packet was re-sent, and shows the time
interval (in seconds) to wait before the NHRP packet is re-sent again.
Ethernet1: Interface over which the NHRP packet was sent.
Used 3 Number of packets sent out of the default maximum five (in this case,
three were sent).

debug nhrp Displays information about NHRP activity.
debug nhrp options Displays information about NHRP option processing

May 2008 DB-1749
Debug Commands
debug nhrp
debug nhrp
To display information about Next Hop Resolution Protocol (NHRP) activity, use the debug nhrp
privileged EXEC command. The no form of this command disables debugging output.
debug nhrp
no debug nhrp
Usage Guidelines Use this command when some nodes on a TCP/IP or IPX network are not responding. Output from the
command shows whether the router is sending or receiving NHRP packets.
Examples The following is sample output from the debug nhrp command:
Router# debug nhrp
NHRP: Cache update 172.19.145.57 None

NHRP: Sent request src 172.19.145.56 dst 255.255.255.255
NHRP M: id 0 src 172.19.145.56 dst 172.19.145.57
NHRP: Encapsulation succeeded. MAC addr ffff.ffff.ffff.
NHRP: O 86 bytes out Ethernet1 dest 255.255.255.255
NHRP: Recv reply Size 64
NHRP M: id 0 src 172.19.145.56 dst 172.19.145.57
NHRP: Cache update 172.19.145.57 0000.0c14.59d3.
Table 251 debug nhrp Field Descriptions
Field Descriptions
NHRP and NHRP M NHRP debugging output and mandatory header debugging output.
Cache update NHRP cache is being revised.
Sent request src NHRP request packet was sent from the specified source address.
NHRP packet was sent to the specified destination address.
dst
id Sequence number of the packet.
src Sequence number of the source address.
dst Sequence number of the destination address.
Encapsulation succeeded. NHRP packet was encapsulated.
MAC addr Link-layer address used as the destination address for the NHRP
packet.

DB-1750 May 2008
Debug Commands
debug nhrp
Table 251 debug nhrp Field Descriptions (continued)
Field Descriptions
O 86 bytes out Size of the NHRP packet (in this case, the output was
86 bytes). Interface that the packet was sent out on, and the
Ethernet1 dest
network-layer destination address.
Recv reply Size Indicates receipt of an NHRP reply packet and the size of the packet
excluding the link-layer header.

debug nhrp options Displays information about NHRP option processing.
debug nhrp packet Displays a dump of NHRP packets.

May 2008 DB-1751
Debug Commands
debug ntp
debug ntp
To display debugging messages for Network Time Protocol (NTP) features, use the debug ntp
command. To disable debugging output, use the no form of this command.
debug ntp {adjust | authentication | events | loopfilter | packets | params | refclock | select | sync
| validity}
no debug ntp {adjust | authentication | events | loopfilter | packets | params | refclock | select |
sync | validity}
Syntax Description adjust Displays debugging information on NTP clock adjustments.

authentication Displays debugging information on NTP authentication.
events Displays debugging information on NTP events.
loopfilter Displays debugging information on NTP loop filters.
packets Displays debugging information on NTP packets.
params Displays debugging information on NTP clock parameters.
refclock Displays debugging information on NTP reference clocks.
select Displays debugging information on NTP clock selection.
sync Displays debugging information on NTP clock synchronization.
validity Displays debugging information on NTP peer clock validity.

12.02 T This command was introduced in a release prior to Cisco IOS Release 12.1.

ntp refclock Configures an external clock source for use with NTP services.

DB-1752 May 2008
Debug Commands
debug oam
debug oam
To display operation and maintenance (OAM) events, use the debug oam command in privileged EXEC
debug oam
no debug oam
Examples The following is sample output from the debug oam command:
Router# debug oam
4/0(O): VCD:0x0 DM:0x300 *OAM Cell* Length:0x39

0000 0300 0070 007A 0018 0100 0000 05FF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
FFFF FFFF FFFF FFFF FF6A 6A6A 6A6A 6A6A 6A6A 6A6A 6A6A 6A6A 6A00 0000
Table 252 debug oam Field Descriptions
Field Description
0000 Virtual circuit designator (VCD) Special OAM indicator.
0300 Descriptor MODE bits for the ATM Interface Processor (AIP).
0 GFC (4 bits).
07 Virtual path identifier (VPI) (8 bits).
0007 Virtual channel identifier (VCI )(16 bits).
A Payload type field (PTI) (4 bits).
00 Header Error Correction (8 bits).
1 OAM Fault mangement cell (4 bits).
8 OAM LOOPBACK indicator (4 bits).
01 Loopback indicator value, always 1 (8 bits).
00000005 Loopback unique ID, sequence number (32 bits).
FF6A Fs and 6A required in the remaining cell, per UNI3.0.

May 2008 DB-1753
Debug Commands
debug oer api
debug oer api

To display Optimized Edge Routing (OER) application interface debugging information, use the debug
oer api command in privileged EXEC mode. To stop the display of OER application interface debugging
debug oer api [detail]
no debug oer api
Syntax Description detail (Optional) Displays detailed application interface debugging information.
Command Default Detailed OER application interface debugging messages are not displayed.

Usage Guidelines The debug oer api command is used to display messages about any configured OER application
interface providers or host devices. The OER application interface defines the mode of communication
and messaging between applications and the network for the purpose of optimizing the traffic associated
with the applications. A provider is defined as an entity outside the network in which the router
configured as an OER master controller exists, for example, an ISP, or a branch office of the same
company. The provider has one or more host devices running one or more applications that use the OER
application interface to communicate with an OER master controller. A provider must be registered with
an OER master controller before an application on a host device can interface with OER. Use the api
provider command to register the provider, and use the host-address command to configure a host
device. After registration, a host device in the provider network can initiate a session with an OER master
controller. The application interface provides an automated method for networks to be aware of
applications and provides application-aware performance routing.
Caution When the detail keyword is entered, the amount of detailed output to be displayed can utilize a
considerable amount of system resources. Use the detail keyword with caution in a production network.
Examples The following example enables the display of OER application interface debugging messages and the
output shows that an OER policy failed due to a prefix that is not found:
Router# debug oer api

DB-1754 May 2008
Debug Commands
debug oer api
OER api debugging is on
*May 26 01:04:07.278: OER API: Data set id received 5, data set len 9, host ip 10.3.3.3,
session id 1, requies2
*May 26 01:04:07.278: OER API: Received get current policy, session id 1 request id 22
*May 26 01:04:07.278: OER API: Recvd Appl with Prot 256 DSCP 0 SrcPrefix 0.0.0.0/0
SrcMask 0.0.0.0
*May 26 01:04:07.278: OER API: DstPrefix 10.2.0.0/24 DstMask 255.255.255.0 Sport_min 0
Sport_max 0 Dport_mi0
*May 26 01:04:07.278: OER API: get prefix policy failed - prefix not found
*May 26 01:04:07.278: OER API: Get curr policy cmd received. rc 0
*May 26 01:04:07.278: OER API: Received send status response, status 0, session id 1,
request id 22, sequence0
*May 26 01:04:07.278: OER API: rc for data set 0
Table 253 describes the significant fields shown in the display. The content of the debugging messages
depends on the commands that are subsequently entered at the router prompt.
Table 253 debug oer api Field Descriptions
Field Description
OER api debugging is on Shows that application interface debugging is enabled.
OER API Displays an OER application interface message.

api provider Registers an application interface provider with an OER master controller
and enters OER master controller application interface provider
configuration mode.
host-address Configures information about a host device used by an application
interface provider to communicate with an OER master controller.
oer Enables an OER process and configures a router as an OER border router
or as an OER master controller.
show oer api provider Displays information about application interface providers registered with
OER.

May 2008 DB-1755
Debug Commands
debug oer api client
debug oer api client

To display Optimized Edge Routing (OER) application programming interface (API) client debugging
information for master controller and border router communication, use the debug oer api client
command in privileged EXEC mode. To stop the display of OER debugging information, use the no form
of this command.
debug oer api client [detail]
no debug oer api client [detail]
Syntax Description detail (Optional) Displays detailed information.
Command Default No debugging messages are enabled.

Usage Guidelines The debug oer api client command can be entered on a master controller. This command is used to
display messages about a configured OER API client. When the detail keyword is entered, the amount
of detailed output to be displayed can utilize a considerable amount of system resources. Use the detail
keyword with caution in a production network.
Examples The following example enables the display of OER API client debugging messages:
Router# debug oer api client
API Client debugging enabled

oer Enables an OER process and configures a router as an OER border router or
as an OER master controller.

DB-1756 May 2008
Debug Commands
debug oer border active-probe

To display debugging information for active probes configured on the local border router, use the debug
oer border active-probe command in privileged EXEC mode. To stop the display of debug event
no debug oer border active-probe

Usage Guidelines The debug oer border active-probe command is entered on a master controller. This command is used
to display the status and results of active probes that are configured on the local border router.
Examples The following example enables the display of active-probe debug information on a border router:
Router# debug oer border active-probe
*May 4 23:47:45.633: OER BR ACTIVE PROBE: Attempting to retrieve Probe

Statistics.
probeType = echo, probeTarget = 10.1.5.1, probeTargetPort = 0
probeSource = Default, probeSourcePort = 0, probeNextHop = Default
probeIfIndex = 13
*May 4 23:47:45.633: OER BR ACTIVE PROBE: Completed retrieving Probe
Statistics.
probeSource = Default, probeSourcePort = 0, probeNextHop = 10.30.30.2
probeIfIndex = 13, SAA index = 15
*May 4 23:47:45.633: OER BR ACTIVE PROBE: Completions 11, Sum of rtt 172,
Max rtt 36, Min rtt 12
*May 4 23:47:45.693: OER BR ACTIVE PROBE: Attempting to retrieve Probe
Statistics.
probeSource = Default, probeSourcePort = 0, probeNextHop = Default

May 2008 DB-1757
Debug Commands
probeIfIndex = 13
*May 4 23:47:45.693: OER BR ACTIVE PROBE: Completed retrieving Probe
Statistics.
probeSource = Default, probeSourcePort = 0, probeNextHop = 10.30.30.2
probeIfIndex = 13, SAA index = 14
Table 254 debug oer border active-probe Field Descriptions
Field Description
OER BR ACTIVE PROBE: Indicates debugging information for OER active probes on a border
router.
Statistics The heading for OER active probe statistics.
probeType The active probe type. The active probe types that can be displayed
are ICMP, TCP, and UDP.
probeTarget The target IP address of the active probe.
probeTargetPort The target port of the active probe.
probeSource The source IP address of the active probe. Default is displayed for a
locally generated active probe.
probeSourcePort The source port of the active probe.
probeNextHop The next hop for the active probe.
probeIfIndex The active probe source interface index.
SAA index The IP SLAs collection index number.


DB-1758 May 2008
Debug Commands
debug oer border learn

To display debugging information about learned prefixes on the local border router, use the debug oer
border learn command in privileged EXEC mode. To stop the display of debug event information, use
debug oer border learn [top number]
no debug oer border learn [top number]
Syntax Description top number (Optional) Displays debugging information about the top delay or top
throughput prefixes. The number of top delay or throughput prefixes can be
specified. The range of prefixes that can be specified is a number from 1 to
65535.

Usage Guidelines The debug oer border learn command is entered on a border router. This command is used to display
debugging information about prefixes learned on the local border router.
Router# debug oer border learn
*May 4 22:51:31.971: OER BR LEARN: Reporting prefix 1: 10.1.5.0, throughput 201

*May 4 22:51:31.971: OER BR LEARN: Reporting 1 throughput learned prefixes
*May 4 22:51:31.971: OER BR LEARN: State change, new STOPPED, old STARTED, reason Stop
Learn

May 2008 DB-1759
Debug Commands
Table 255 debug oer border learn Field Descriptions
Field Description
OER BR LEARN: Indicates debugging information for the OER border router
learning process.


DB-1760 May 2008
Debug Commands
debug oer border routes

To display debugging information for OER controlled or monitored routes on the local border router, use
the debug oer border routes command in privileged EXEC mode. To stop the display of debug event
debug oer border routes {bgp | static}
no debug oer border routes {bgp | static}
Syntax Description bgp Displays debugging information for only BGP routes.
static Displays debugging information for only static routes.
Command Default No debugging is enabled.

Usage Guidelines The debug oer border routes command is entered on a border router. This command is used to display
the debugging information about OER controlled or monitored routes on the local border router.
Router# debug oer border routes
*May 4 22:35:53.239: OER BGP: Control exact prefix 10.1.5.0/24

*May 4 22:35:53.239: OER BGP: Walking the BGP table for 10.1.5.0/24
*May 4 22:35:53.239: OER BGP: Path for 10.1.5.0/24 is now under OER control
*May 4 22:35:53.239: OER BGP: Setting prefix 10.1.5.0/24 as OER net#

May 2008 DB-1761
Debug Commands
Table 256 debug oer border routes Field Descriptions
Field Description
OER BR BGP: Indicates debugging information for OER controlled BGP
routes.
OER BR STATIC: Indicates debugging information for OER controlled Static
routes. (Not displayed in the example output.)


DB-1762 May 2008
Debug Commands
debug oer border traceroute reporting

To display debugging information for traceroute probes on the local border router, use the debug oer
border traceroute reporting command in privileged EXEC mode. To stop the display of debug event
debug oer border traceroute reporting [detail]
no debug oer border traceroute reporting [detail]
Syntax Description detail (Optional) Displays detailed traceroute debug information.

Usage Guidelines The debug oer border traceroute reporting command is entered on a border router. This command is
used to display the debugging information about traceroute probes sourced on the local border router.
Router# debug oer border traceroute reporting
May 19 03:46:23.807: OER BR TRACE(det): Received start message: msg1 458776,

msg2 1677787648, if index 19, host addr 100.1.2.1, flags 1, max ttl 30,
protocol 17, probe delay 0
May 19 03:46:26.811: OER BR TRACE(det): Result msg1 458776,
msg2 1677787648 num hops 30 sent May 19 03:47:20.919: OER BR TRACE(det):
Received start message: msg1 524312, msg2 1677787648, if index 2,
host addr 100.1.2.1, flags 1, max ttl 30, protocol 17, probe delay 0
May 19 03:47:23.923: OER BR TRACE(det): Result msg1 524312,
msg2 1677787648 num hops 3 sent

May 2008 DB-1763
Debug Commands
Table 257 debug oer border traceroute reporting Field Descriptions
Field Description
OER BR TRACE: Indicates border router debugging information for traceroute probes.


DB-1764 May 2008
Debug Commands
debug oer border
debug oer border

To display general OER border router debugging information, use the debug oer border command in
privileged EXEC mode. To stop the display of OER debugging information, use the no form of this
command.
debug oer border
no debug oer border

Usage Guidelines The debug oer border command is entered on a border router. This command is used to display
debugging information about the OER border process, controlled routes and monitored prefixes.
Examples The following example displays general OER debugging information:

Router# debug oer border
*May 4 22:32:33.695: OER BR: Process Message, msg 4, ptr 33272128, value 140
*May 4 22:32:34.455: OER BR: Timer event, 0
Table 258 debug oer border Field Descriptions
Field Description
OER BR: Indicates debugging information for OER Border process.

May 2008 DB-1765
Debug Commands
debug oer border


DB-1766 May 2008
Debug Commands
debug oer cc
debug oer cc
To display OER communication control debugging information for master controller and border router
communication, use the debug oer cc command in privileged EXEC mode. To stop the display of OER
debugging information, use the no form of this command.
debug oer cc [detail]
no debug oer cc [detail]

Usage Guidelines The debug oer cc command can be entered on a master controller on a border router. This command is
used to display messages exchanged between the master controller and the border router. These
messages include control commands, configuration commands, and monitoring information. Enabling
this command will cause very detailed output to be displayed and can utilize a considerable amount of
system resources. This command should be enabled with caution in a production network.
Examples The following example enables the display of OER communication control debugging messages:
Router# debug oer cc
*May 4 23:03:22.527: OER CC: ipflow prefix reset received: 10.1.5.0/24
Table 259 debug oer cc Field Descriptions
Field Description
OER CC: Indicates debugging information for OER communication
messages.

May 2008 DB-1767
Debug Commands
debug oer cc


DB-1768 May 2008
Debug Commands
debug oer master border

To display debugging information for OER border router events on an OER master controller, use the
debug oer master border command in privileged EXEC mode. To stop border router event debugging,
debug oer master border [ip-address]
no debug oer master border
Syntax Description ip-address (Optional) Specifies the IP address of a border router.

Usage Guidelines The debug oer master border command is entered on a master controller. The output displays
information related to the events or updates from one or more border routers.
Examples The following example shows the status of 2 border routers. Both routers are up and operating normally.
Router# debug oer master border
OER Master Border Router debugging is on

Router#
1d05h: OER MC BR 10.4.9.7: BR I/F update, status UP, line 1 index 1, tx bw 10000
0, rx bw 100000, time, tx ld 0, rx ld 0, rx rate 0 rx bytes 3496553, tx rate 0,
tx bytes 5016033
0, rx bw 100000, time, tx ld 0, rx ld 0, rx rate 0 rx bytes 710149, tx rate 0, t
x bytes 1028907
0, rx bw 100000, time, tx ld 0, rx ld 0, rx rate 0 rx bytes 743298, tx rate 0, t
x bytes 1027912
0, rx bw 100000, time, tx ld 0, rx ld 0, rx rate 0 rx bytes 3491383, tx rate 0,
tx bytes 5013993

May 2008 DB-1769
Debug Commands
Table 260 debug oer master border Field Descriptions
Field Description
OER MC BR ip-address: Indicates debugging information for a border router process.
The ip-address identifies the border router.


DB-1770 May 2008
Debug Commands
debug oer master collector

To display data collection debugging information for OER monitored prefixes, use the debug oer master
collector command in privileged EXEC mode. To disable the display of this debugging information, use
debug oer master collector {active-probes [detail [trace]] | netflow}
no debug oer master collector {active-probes [detail [trace]] | netflow}
Syntax Description active-probes Displays aggregate active probe results for a given prefix on all border
routers that are executing the active probe.
detail (Optional) Displays the active probe results from each target for a given
prefix on all border routers that are executing the active probe.
trace (Optional) Displays aggregate active probe results and historical statistics
for a given prefix on all border routers that are executing the active probe.
netflow Displays information about the passive (NetFlow) measurements received by
the master controller for prefixes monitored from the border router.

Usage Guidelines The debug oer master collector command is entered on a master controller. The output displays data
collection information for monitored prefixes.
Examples debug oer master collector active-probes Example

The following example displays aggregate active probe results for the 10.1.0.0/16 prefix on all border
routers that are configured to execute this active probe:
Router# debug oer master collector active-probes
*May 4 22:34:58.221: OER MC APC: Probe Statistics Gathered for prefix 10.1.0.0/16 on all
exits,notifying the PDP
*May 4 22:34:58.221: OER MC APC: Summary Exit Data (pfx 10.1.0.0/16, bdr 10.2.2.2, if 13,
nxtHop Default):savg delay 13, lavg delay 14, sinits 25, scompletes 25

May 2008 DB-1771
Debug Commands
*May 4 22:34:58.221: OER MC APC: Summary Prefix Data: (pfx 10.1.0.0/16) sloss 0, lloss 0,
sunreach 25, lunreach 25, savg raw delay 15, lavg raw delay 15, sinits 6561, scompletes
6536, linits 6561, lcompletes 6536
*May 4 22:34:58.221: OER MC APC: Active OOP check done
Table 261 debug oer master collector active-probes Field Descriptions
Field Description
OER MC APC: Indicates debugging information for active probes from the r
OER master collector.
debug oer master collector active-probes detail Example

The following example displays aggregate active probe results from each target for the 10.1.0.0/16 prefix
on all border routers that are configured to execute this active probe:
Router# debug oer master collector active-probes detail
*May 4 22:36:21.945: OER MC APC: Rtrv Probe Stats: BR 10.2.2.2, Type echo,
Tgt 10.1.1.1,TgtPt 0, Src Default, SrcPt 0, NxtHp Default, Ndx 13
*May 4 22:36:22.001: OER MC APC: Remote stats received: BR 10.2.2.2, Type
echo, Tgt 10.15.1, TgtPt 0, Src Default, SrcPt 0, NxtHp Default, Ndx 13
*May 4 22:36:22.313: OER MC APC: Perf data point (pfx 10.1.0.0/16, bdr
10.2.2.2, if 13, xtHop Default): avg delay 20, loss 0, unreach 0,
initiations 2, completions 2, delay sum40, ldelay max 20, ldelay min 12
*May 4 22:36:22.313: OER MC APC: Perf data point (pfx 10.1.0.0/16, bdr
10.2.2.2, if 13, xtHop Default): avg delay 20, loss 0, unreach 0,
initiations 2, completions 2, delay sum40, ldelay max 20, ldelay min 12
*May 4 22:36:22.313: OER MC APC: Probe Statistics Gathered for prefix
10.1.0.0/16 on al exits, notifying the PDP
Table 262 debug oer master collector active-probes detail Field Descriptions
Field Description
debug oer master collector active-probes detail trace Example

The following example displays aggregate active probe results and historical statistics from each target
for the 10.1.0.0/16 prefix on all border routers that are configured to execute this active probe:
Router# debug oer master collector active-probes detail trace
*May 4 22:40:33.845: OER MC APC: Rtrv Probe Stats: BR 10.2.2.2, Type echo,
Tgt 10.1.5.1, TgtPt 0, Src Default, SrcPt 0, NxtHp Default, Ndx 13
echo, Tgt 10.1.5.1, TgtPt 0, Src Default, SrcPt 0, NxtHp Default, Ndx 13
echo, Tgt 10.1.2.1, TgtPt 0, Src Default, SrcPt 0, NxtHp Default, Ndx 13
*May 4 22:40:34.197: OER MC APC: Updating Probe (Type echo Tgt 10.1.2.1
TgtPt 0) Total Completes 1306, Total Attempts 1318
*May 4 22:40:34.197: OER MC APC: All stats gathered for pfx 10.1.0.0/16
Accumulating Stats
*May 4 22:40:34.197: OER MC APC: Updating Curr Exit Ref (pfx 10.1.0.0/16,

DB-1772 May 2008
Debug Commands
bdr 10.2.2.2, if 13, nxtHop Default) savg delay 17, lavg delay 14, savg loss
0, lavg loss 0, savg unreach 0, lavg unreach 0
*May 4 22:40:34.197: OER MC APC: Probe Statistics Gathered for prefix
10.1.0.0/16 on all exits, notifying the PDP
Table 263 debug oer master collector active-probes detail trace Field Descriptions
Field Description
debug oer master collector netflow Example

The following example displays passive monitoring results for the 10.1.5.0/24 prefix:
Router# debug oer master collector netflow
*May 4 22:31:45.739: OER MC NFC: Rcvd egress update from BR 10.1.1.2

prefix 10.1.5.0/24 Interval 75688 delay_sum 0 samples 0 bytes 20362 pkts 505 flows
359 pktloss 1 unreach 0
*May 4 22:31:45.739: OER MC NFC: Updating exit_ref; BR 10.1.1.2 i/f Et1/0, s_avg_delay
655, l_avg_delay 655, s_avg_pkt_loss 328, l_avg_pkt_loss 328, s_avg_flow_unreach 513,
l_avg_flow_unreach 513
*May 4 22:32:07.007: OER MC NFC: Rcvd ingress update from BR 10.1.1.3
prefix 10.1.5.0/24 Interval 75172 delay_sum 42328 samples 77 bytes 22040 pkts 551
flows 310 pktloss 0 unreach 0
Table 264 debug oer master collector netflow Field Descriptions
Field Description
OER MC NFC: Indicates debugging information for the OER master
collector from passive monitoring (NetFlow).


May 2008 DB-1773
Debug Commands
debug oer master cost-minimization

To display debugging information for cost-based optimization policies, use the debug oer master
cost-minimization command in privileged EXEC mode. To disable the display of this debugging
debug oer master cost-minimization [detail]
no debug oer master cost-minimization [detail]

Usage Guidelines The debug oer master cost-minimization command is entered on a master controller. The output
displays debugging information for cost-minimization policies.
Examples The following example displays detailed cost optimization policy debug information:
Router# debug oer master cost-minimization detail
OER Master cost-minimization Detail debugging is on

*May 14 00:38:48.839: OER MC COST: Momentary target utilization for exit 10.1.1.2 i/f
Ethernet1/0 nickname ISP1 is 7500 kbps, time_left 52889 secs, cumulative 16 kb, rollup
period 84000 secs, rollup target 6000 kbps, bw_capacity 10000 kbps
*May 14 00:38:48.839: OER MC COST: Cost OOP check for border 10.1.1.2, current util: 0
target util: 7500 kbps
*May 14 00:39:00.199: OER MC COST: ISP1 calc separate rollup ended at 55 ingress Kbps
*May 14 00:39:00.199: OER MC COST: ISP1 calc separate rollup ended at 55 egress bytes
*May 14 00:39:00.199: OER MC COST: Target utilization for nickname ISP1 set to 6000,
rollups elapsed 4, rollups left 24
*May 14 00:39:00.271: OER MC COST: Momentary target utilization for exit 10.1.1.2 i/f
Ethernet1/0 nickname ISP1 is 7500 kbps, time_left 52878 secs, cumulative 0 kb, rollup
period 84000 secs, rollup target 6000 kbps, bw_capacity 10000 kbps
*May 14 00:39:00.271: OER MC COST: Cost OOP check for border 10.1.1.2, current util: 0
target util: 7500 kbps

DB-1774 May 2008
Debug Commands
Table 265 debug oer master cost-minimization detail Field Descriptions
Field Description
OER MC COST: Indicates debugging information for cost-based optimization on the master
controller.

cost-minimization Configures cost-based optimization policies on a master controller.
oer Enables an OER process and configures a router as an OER border router
or as an OER master controller.
show oer master Displays the status of cost-based optimization policies.
cost-minimization

May 2008 DB-1775
Debug Commands
debug oer master exit

To display debug event information for OER managed exits, use the debug oer master exit command
in privileged EXEC mode. To stop the display of debug event information, use the no form of this
command.
debug oer master exit [detail]
no debug oer master exit [detail]
Syntax Description detail Displays detailed OER managed exit information.

Usage Guidelines The debug oer master exit command is entered on a master controller. This command is used to display
debugging information for master controller exit selection processes.
Examples The following example shows output form the debug oer master exit command, entered with the detail
keyword:
Router# debug oer master exit detail
*May 4 11:26:51.539: OER MC EXIT: 10.1.1.1, intf Fa4/0 INPOLICY

*May 4 11:26:52.195: OER MC EXIT: 10.2.2.3, intf Se2/0 INPOLICY
*May 4 11:26:55.515: OER MC EXIT: 10.1.1.2, intf Se5/0 INPOLICY
*May 4 11:29:14.987: OER MC EXIT: 7 kbps should be moved from 10.1.1.1, intf Fa4/0
*May 4 11:29:35.467: OER MC EXIT: 10.1.1.1, intf Fa4/0 in holddown state so skip OOP
check
*May 4 11:29:35.831: OER MC EXIT: 10.2.2.3, intf Se2/0 in holddown state so skip OOP
check
*May 4 11:29:39.455: OER MC EXIT: 10.1.1.2, intf Se5/0 in holddown state so skip OOP
check

DB-1776 May 2008
Debug Commands
Table 266 debug oer master exit detail Field Descriptions
Field Description
OER MC EXIT: Indicates OER master controller exit event.


May 2008 DB-1777
Debug Commands
debug oer master learn

To display debug information for OER master controller learning events, use the debug oer master
learn command in privileged EXEC mode. To stop the display of debug information, use the no form of
this command.
no debug oer master learn

Usage Guidelines The debug oer master learn command is entered on a master controller. This command is used to
display debugging information for master controller learning events.
Examples The following example shows output from the debug oer master learn command. The output an shows
OER Top Talker debug events. The master controller is enabling prefix learning for new border router
process:
Router# debug oer master learn
06:13:43: OER MC LEARN: Enable type 3, state 0

06:13:43: OER MC LEARN: OER TTC: State change, new RETRY, old DISABLED, reason TT start
06:13:43: OER MC LEARN: OER TTC: State change, new RETRY, old DISABLED, reason TT start
request
06:13:43: OER MC LEARN: OER TTC: State change, new RETRY, old DISABLED, reason T
T start request
06:14:13: OER MC LEARN: TTC Retry timer expired
06:14:13: OER MC LEARN: OER TTC: State change, new STARTED, old RETRY, reason At
least one BR started
06:14:13: %OER_MC-5-NOTICE: Prefix Learning STARTED
06:14:13: OER MC LEARN: MC received BR TT status as enabled
06:14:13: OER MC LEARN: MC received BR TT status as enabled
06:19:14: OER MC LEARN: OER TTC: State change, new WRITING DATA, old STARTED, reason
Updating DB

DB-1778 May 2008
Debug Commands
06:19:14: OER MC LEARN: OER TTC: State change, new SLEEP, old WRITING DATA, reason
Sleep state
Table 267 debug oer master learn Field Descriptions
Field Description
OER MC LEARN: Indicates OER master controller learning events.


May 2008 DB-1779
Debug Commands
debug oer master prefix

To display debug events related to prefix processing on an OER master controller, use the debug oer
master prefix command in privileged EXEC mode. To disable the display of debug information, use the
debug oer master prefix [prefix | appl] [detail]
no debug oer master prefix [prefix | appl] [detail]
Syntax Description prefix (Optional) Specifies a single prefix or prefix range. The prefix address and
mask are entered with this argument.
appl (Optional) Displays information about prefixes used by applications
monitored and controlled by an OER master controller.
detail (Optional) Displays detailed OER prefix processing information.

Usage Guidelines The debug oer master prefix command is entered on a master controller. This command displays
debugging information related to prefix monitoring and processing.
Examples The following example shows the master controller searching for the target of an active probe after the
target has become unreachable.
Router# debug oer master prefix
OER Master Prefix debugging is on

06:01:28: OER MC PFX 10.4.9.0/24: APC last target deleted for prefix, no targets
left assigned and running
06:01:38: OER MC PFX 10.4.9.0/24: APC Attempting to probe all exits

DB-1780 May 2008
Debug Commands
Table 268 debug oer master prefix Field Descriptions
Field Description
OER MC PFX ip-address: Indicates debugging information for OER monitored
prefixes. The ip-address identifies the prefix.


May 2008 DB-1781
Debug Commands
debug oer master prefix-list

To display debug events related to prefix-list processing on an OER master controller, use the debug oer
master prefix-list command in privileged EXEC mode. To disable the display of debug information, use
debug oer master prefix-list list-name [detail]
no debug oer master prefix-list list-name
Syntax Description list-name Specifies a single prefix or prefix range. The prefix address and mask are
entered with this argument.
detail (Optional) Displays detailed OER prefix-list processing information.

Usage Guidelines The debug oer master prefix-list command is entered on a master controller. This command displays
debugging information related to prefix-list processing.
Examples The following example shows output from the debug oer master prefix-list command.
Router# debug oer master prefix-list
23:02:16.283: OER MC PFX 10.1.5.0/24: Check PASS REL loss: loss 0, policy 10%, notify TRUE
23:02:16.283: OER MC PFX 10.1.5.0/24: Passive REL loss in-policy
23:02:16.283: OER MC PFX 10.1.5.0/24: Check PASS REL delay: delay 124, policy 50%, notify
TRUE
23:02:16.283: OER MC PFX 10.1.5.0/24: Passive REL delay in policy
23:02:16.283: OER MC PFX 10.1.5.0/24: Prefix not OOP
23:02:16.283: OER MC PFX 10.1.5.0/24: Check PASS REL unreachable: unreachable 0, policy
50%, notify TRUE
23:02:16.283: OER MC PFX 10.1.5.0/24: Passive REL unreachable in-policy
23:02:16.283: OER MC PFX 10.1.5.0/24: Check PASS REL loss: loss 0, policy 10%, notify TRUE
23:02:16.283: OER MC PFX 10.1.5.0/24: Passive REL loss in policy

DB-1782 May 2008
Debug Commands
Table 269 debug oer master prefix-list Field Descriptions
Field Description
OER MC PFX ip-address: Indicates debugging information for OER monitored
prefixes. The ip-address identifies the prefix.


May 2008 DB-1783
Debug Commands
debug oer master process

To display debug information about the OER master controller process, use the debug oer master
process command in privileged EXEC mode. To stop displaying debug information, use the no form of
this command.
no debug oer master process

Usage Guidelines The debug oer master process command is entered on a master controller.
Examples The following sample debug output for a master controller process:
Router# debug oer master process
01:12:00: OER MC PROCESS: Main msg type 15, ptr 0, value 0
Table 270 debug oer master process Field Descriptions
Field Description
OER MC PROCESS: Indicates a master controller master process debugging
message.


DB-1784 May 2008
Debug Commands

May 2008 DB-1785
Debug Commands
debug oer master traceroute reporting

To display debug information about traceroute probes, use the debug oer master traceroute reporting
command in privileged EXEC mode. To stop displaying debug information, use the no form of this
command.
debug oer master traceroute reporting [detail]
no debug oer master traceroute reporting [detail]

Usage Guidelines The debug oer master traceroute reporting command is entered on a master controller. This command
is used to display traceroute events on a master controller.
Examples The following sample debug output for a master controller process:
Router# debug oer master traceroute reporting detail
*May 12 18:55:14.239: OER MC TRACE: sent start message msg1 327704, msg2 167838976, if
index 2, host add 10.1.5.2, flags 1, max ttl 30, protocol 17
*May 12 18:55:16.003: OER MC TRACE: sent start message msg1 393240, msg2 167838976, if
index 2, host add 10.1.5.2, flags 1, max ttl 30, protocol 17
master#
*May 12 18:55:17.303: OER MC TRACE: Received result: msg_id1 327704, prefix 10.1.5.0/24,
hops 4, flags 1
*May 12 18:55:19.059: OER MC TRACE: Received result: msg_id1 393240, prefix 10.1.5.0/24,
hops 4, flags 1

DB-1786 May 2008
Debug Commands
Table 271 debug oer master traceroute reporting detail Field Descriptions
Field Description
OER MC PROCESS: Indicates master controller debugging information for
traceroute probes.


May 2008 DB-1787
Debug Commands
debug packet
debug packet
To display per-packet debugging output, use the debug packet command in privileged EXEC mode. To
debug packet [interface number [vcd vcd-number] | vc vpi/vci | vc-name]
no debug packet [interface number [vcd vcd-number] | vc vpi/vci | vc-name]
Syntax Description interface number (Optional) interface or subinterface number.

vcd vcd-number (Optional) Number of the virtual circuit designator (VCD).
vc vpi/vci (Optional) Virtual path identifier (VPI) and virtual channel identifier
(VCI) numbers of the VC.
vc-name (Optional) Name of the PVC or SVC.
Defaults Debugging for packets is disabled by default.

12.2(13)T Support for Apollo Domain and Banyan VINES was removed.
Usage Guidelines The debug packet command displays all process-level packets for both outbound and inbound packets.
This command is useful for determining whether packets are being received and sent correctly. The
output reports information online when a packet is received or a transmission is attempted.
For sent packets, the information is displayed only after the protocol data unit (PDU) is entirely
encapsulated and a next hop 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 that the packets are properly encapsulated
for transmission.
For received packets, information is displayed for all incoming frames. The display can show whether
the sending 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 switch.
The debug 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.

DB-1788 May 2008
Debug Commands
debug packet
Caution Because the debug packet command generates a substantial 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.
Examples The following is sample output from the debug packet command:
Router# debug packet
2/0.5(I): VCD:0x9 VCI:0x23 Type:0x0 SAP:AAAA CTL:03 OUI:000000 TYPE:0800 Length0x70

4500 002E 0000 0000 0209 92ED 836C A26E FFFF FFFF 1108 006D 0001 0000 0000
A5CC 6CA2 0000 000A 0000 6411 76FF 0100 6C08 00FF FFFF 0003 E805 DCFF 0105
Table 272 debug packet Field Descriptions
Field Description
2/0.5 Indicates the subinterface that generated this packet.
(I) Indicates a receive packet. (O) indicates an output packet.
VCD: 0xn Indicates the virtual circuit associated with this packet, where n is some value.
DM: 0xnnnn Indicates the descriptor mode bits on output only, where nnnn is a
hexadecimal value.
TYPE:n Displays the encapsulation type for this packet.
Length:n Displays the total length of the packet including the headers.
The following two lines of output are the binary data, which are the contents of the protocol data unit
(PDU) before encapsulation:
4500 002E 0000 0000 0209 92ED 836C A26E FFFF FFFF 1108 006D 0001 0000 0000
A5CC 6CA2 0000 000A 0000 6411 76FF 0100 6C08 00FF FFFF 0003 E805 DCFF 0105
The following is sample output from the debug packet command:

Router# debug packet
Ethernet0: Unknown ARPA, src 0000.0c00.6fa4, dst ffff.ffff.ffff, type 0x0a0

data 00000c00f23a00000c00ab45, len 60
Serial3: Unknown HDLC, size 64, type 0xaaaa, flags 0x0F00
Serial2: Unknown PPP, size 128
Serial7: Unknown FRAME-RELAY, size 174, type 0x5865, DLCI 7a
Serial0: compressed TCP/IP packet dropped

May 2008 DB-1789
Debug Commands
debug packet
Table 273 debug packet Field Descriptions
Field Description
Ethernet0 Name of the Ethernet interface that received the packet.
Unknown Network could not classify this packet. Examples include packets with unknown
link types.
ARPA Packet uses ARPA-style encapsulation. Possible encapsulation styles vary
depending on the media command mode (MCM) and encapsulation style.
Ethernet (MCM)Encapsulation Style:
ARP
ETHERTALK
ISO1
ISO3
LLC2
NOVELL-ETHER
SNAP
FDDI (MCM)Encapsulation Style:
ISO1
ISO3
LLC2
SNAP
Frame RelayEncapsulation Style:
BRIDGE
FRAME-RELAY

DB-1790 May 2008
Debug Commands
debug packet
Table 273 debug packet Field Descriptions (continued)
Field Description
ARPA Serial (MCM)Encapsulation Style:
(continued)
BFEX25
BRIDGE
DDN-X25
DDNX25-DCE
ETHERTALK
FRAME-RELAY
HDLC
HDH
LAPB
LAPBDCE
MULTI-LAPB
PPP
SDLC-PRIMARY
SDLC-SECONDARY
SLIP
SMDS
STUN
X25
X25-DCE
Token Ring (MCM)Encapsulation Style:
3COM-TR
ISO1
ISO3
MAC
LLC2
NOVELL-TR
SNAP
VINES-TR
src 0000.0c00.6fa4 MAC address of the node generating the packet.
dst.ffff.ffff.ffff MAC address of the destination node for the packet.
type 0x0a0 Packet type.
data... First 12 bytes of the datagram following the MAC header.
len 60 Length of the message (in bytes) that the interface received from the wire.
size 64 Length of the message (in bytes) that the interface received from the wire.
Equivalent to the len field.

May 2008 DB-1791
Debug Commands
debug packet
Table 273 debug packet Field Descriptions (continued)
Field Description
flags 0x0F00 HDLC or PP flags field.
DLCI 7a The DLCI number on Frame Relay.
compressed TCP/IP TCP header compression is enabled on an interface and the packet is not HDLC
packet dropped or X25.

DB-1792 May 2008
Debug Commands
debug pad
debug pad
To display debugging messages for all packet assembler/disassembler (PAD) connections, use the debug
pad command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug pad
no debug pad

12.0 This command was introduced in a release prior to Cisco IOS Release 12.0.
Examples Use the debug pad command to gather information to forward to the Cisco Technical Assistance Center
(TAC) to assist in troubleshooting a problem that involves PAD connections.
The following example shows output of the debug pad and debug x25 event commands for an incoming
PAD call destined for a terminal line. The incoming PAD call is rejected by the terminal line because the
selected network closed user group (CUG) has not been subscribed to by the caller:
Router# debug pad
Router# debug x25 event
Serial1/1:X.25 I R1 Call (16) 8 lci 8

From (7):2001534 To (9):200261150
Facilities:(2)
Closed User Group (basic):99
Call User Data (4):0x01000000 (pad)
pad_svc_announce:destination matched 1
PAD:incoming call to 200261150 on line 130 CUD length 4
!PAD130:Incoming Call packet, Closed User Group (CUG) service protection, selected network
CUG not subscribed
PAD:CUG service protection Cause:11 Diag:65
Serial1/1:X.25 O R1 Clear (5) 8 lci 8
Cause 0, Diag 65 (DTE originated/Facility code not allowed)
Serial1/1:X.25 I R1 Clear Confirm (3) 8 lci 8

May 2008 DB-1793
Debug Commands
debug pad
The following example shows the output of the debug pad command for an outgoing PAD call initiated
from a terminal line with a subscribed CUG that bars outgoing access:
!PAD130:Outgoing Call packet, Closed User Group - CUG service validation, selected CUG
!bars outgoing access
PAD130:Closing connection to . In 0/0, out 0/0

DB-1794 May 2008
Debug Commands
debug piafs events
debug piafs events

To check the debugging messages for Personal Handyphone Internet Access Forum Standard (PIAFS)
calls, use the debug piafs events command in privileged EXEC mode. To disable debugging output, use
debug piafs events
no debug piafs events

12.2(8)T This command was introduced on Cisco 803, Cisco 804, and Cisco 813
routers.
Usage Guidelines The debug piafs events command provides debugging information for the PIAFS calls on the router,
including the inband negotiation process.
Examples The debug piafs events command was configured to provide the following information for PIAFS calls:
Router# debug piafs events
02:16:39:PIAFS events debugging is on

02:16:167516180371:PIAFS: RX <- CDAPI :cdapi_route_call Request
02:16:167517398148:PIAFS: RX <- CDAPI :CDAPI_MSG_CONNECT_IND
02:16:171798691839:PIAFS: TX -> CDAPI :CDAPI_MSG_SUBTYPE_ALERT_REQ
02:16:167503724545:PIAFS: TX -> CDAPI :CDAPI_MSG_CONNECT_RESP
02:16:167503765504:PIAFS: TX -> CDAPI :CDAPI_MSG_CONN_ACTIVE_REQ
02:16:167503724544:PIAFS: RX <- CDAPI :CDAPI_MSG_CONN_ACTIVE_IND
02:16:171798691839:PIAFS:Network allotted Channel :B1
02:16:167503765504:PIAFS:Enabling QMC in PIAFS mode for B1
02:16:171798691839:PIAFS:piafs_driver_enable_settings()
02:16:167503765504:PIAFS:The speed is :64
02:16:167503724544:PIAFS:Starting 64 kbps PIAFS Incoming
02:16:39:PIAFS:RX <- NEGO_SYNC_REQUEST[GSN:13 RSN:1 CRSN:1 SISN:
255]
02:16:39:PIAFS:Updating conf resp num
02:16:39:PIAFS:TX -> NEGO_SYNC_RECEPTION[GSN:1 RSN:1 CRSN:13 SISN:
255]

May 2008 DB-1795
Debug Commands
debug piafs events

255]
255]
255]
255]
255]
255]
255]
255]
255]
255]
255]
255]
02:16:39:PIAFS:RX <- CONTROL_REQUEST(comm parameter)[Seq No:0]
02:16:39:PIAFS:Rx Parameters:
02:16:39:PIAFS: Data Protocol:Version 1
02:16:39:PIAFS: Control Protocol:Version 1
02:16:39:PIAFS: RTF value:9
02:16:39:PIAFS: Compression:V.42bis
02:16:39:PIAFS: Frame Length:80
02:16:39:PIAFS: Frame Number:63
02:16:39:PIAFS:TX -> CONTROL_RECEPTION[0]
02:16:39:PIAFS:ACKed all the Rx control parameters
02:16:39:PIAFS:Piafs layer up & Main FSM set to DATA
02:16:39:PIAFS:Compression v42bis enabled
02:16:39:PIAFS:V42BIS:v42bis_init()
02:16:39:PIAFS:V42BIS:v42bis_init()
02:16:39:PIAFS:V42BIS:Negotiated Values for P1, P2 are - 4096 , 250
02:16:39:PIAFS:Incoming call invoking ISDN_CALL_CONNECT
02:16:39:%LINK-3-UPDOWN:Interface BRI0:1, changed state to up

DB-1796 May 2008
Debug Commands
debug piafs events

02:16:39:PIAFS:piafs_setmap() tx_map FFFFFFFF
02:16:39:PIAFS:piafs_setmap() rx_map 0
02:16:41:PIAFS:PPP:Autoselect sample 7E
02:16:41:PIAFS:PPP:Autoselect sample 7EFF
02:16:41:PIAFS:PPP:Autoselect sample 7EFF7D
02:16:41:PIAFS:PPP:Autoselect sample 7EFF7D23
02:16:41:PIAFS:piafs_setmap() tx_map FFFFFFFF
02:16:42:PIAFS:piafs_setmap() tx_map A0000

May 2008 DB-1797
Debug Commands
debug piafs events
Table 274 debug piafs events Field Descriptions
Field Description
RX <- CDAPI :cdapi_route_call Request The call distributor application programming
interface (CDAPI) in the router receives an
ISDN call request from the switch.
RX <- CDAPI :CDAPI_MSG_CONNECT_IND The CDAPI in the router receives a connection
indicator message from the switch.
TX -> CDAPI The CDAPI in the router transmits an alert
:CDAPI_MSG_SUBTYPE_ALERT_REQ request to the switch.
TX -> CDAPI :CDAPI_MSG_CONNECT_RESP The CDAPI in the router transmits a connect
response message to the switch.
TX -> CDAPI The CDAPI in the router transmits a connection
:CDAPI_MSG_CONN_ACTIVE_REQ active request to the switch.
RX <-CDAPI:CDAPI_MSG_CONN_ACTIVE_IND The CDAPI in the router receives a connection
active indicator from the switch.
Enabling QMC in PIAFS mode for B1 QMC (global multichannel parameters) are
being enabled in PIAFS mode for the B1
channel.
piafs_driver_enable_settings() The PIAFS driver is enabling the settings.
Starting 64 kbps PIAFS Incoming The speed of the transmission in kbps. In this
case, the speed is 64 kbps.
RX <- NEGO_SYNC_REQUEST[GSN: RSN: The router receives a PIAFS negotiation
CRSN: SISN:] synchronization request frame from the peer
PIAFS device. The frame contains the
following: general sequence number (GSN),
reception sequence number (RSN),
confirmation response sequence number
(CRSN), and synchronization initiation
sequence number (SISN).
Updating conf resp num The confirmation response number is being
updated.
TX -> NEGO_SYNC_RECEPTION[GSN: RSN: The router transmits a PIAFS negotiation
CRSN: SISN: ] synchronization reception message to the peer
PIAFS device. The message includes the GSN,
RSN, CRSN, and SISN.
RX <- CONTROL_REQUEST The router receives a PIAFS control request
frame that includes communication parameters.
Rx Parameters The communication parameters are as follows.
Data Protocol The version of the data protocol.
Control Protocol The version of the control protocol.
RTF value Round-trip frame value.
Compression The compression standard.
Frame Length The length of the frame, in bytes.

DB-1798 May 2008
Debug Commands
debug piafs events
Table 274 debug piafs events Field Descriptions (continued)
Field Description
Frame Number The number of packets per frame.
TX -> CONTROL_RECEPTION The router transmits a PIAFS control reception
frame.
ACKed all the Rx control parameters The control reception frame acknowledges all
the communication parameters that were
received from the peer.
Piafs layer up & Main FSM set to DATA The PIAFS protocol is active on the router. The
router is ready to receive data from the peer
device.
Compression v42bis enabled The compression protocol v42bis is enabled.
V42BIS:v42bis_init() The v42bis compression protocol has been
initiated.
V42BIS:Negotiated Values for P1, P2 are - 4096 , In this example, P1 is the total count of encoded
250 words when v42bis compression is enabled. P2
is the maximum letter line length for the V42bis
compression.
Incoming call invoking ISDN_CALL_CONNECT An incoming ISDN call connection message is
received.
PPP The PPP layer on the router becomes active and
starts to process the PPP frame from the peer
PIAFS device.

May 2008 DB-1799
Debug Commands
debug pots
debug pots
To display information on the telephone interfaces, use the debug pots command in privileged EXEC
debug pots {driver | csm} [1 | 2]
no debug pots {driver | csm} [1 | 2]
Syntax Description driver Displays driver debug information.

csm Displays Content Switching Module (CSM) debug information.
1 (Optional) Displays information for telephone port 1 only.
2 (Optional) Displays information for telephone port 2 only.
Usage Guidelines The debug pots command displays driver and CSM debug information for telephone ports 1 and 2.
Examples The following is sample output from the debug pots driver 1 command. This sample display indicates
that the telephone port driver is not receiving caller ID information from the ISDN line. Therefore, the
analog caller ID device attached to the telephone port does not display caller ID information.
Router# debug pots driver 1
00:01:51:POTS DRIVER port=1 activate ringer: cadence=0 callerId=Unknown

00:01:51:POTS DRIVER port=1 state=Idle drv_event=RING_EVENT
00:01:51:POTS DRIVER port=1 enter_ringing
00:01:51:POTS DRIVER port=1 cmd=19
00:01:51:POTS DRIVER port=1 activate disconnect
00:01:51:POTS DRIVER port=1 state=Ringing drv_event=DISCONNECT_EVENT
00:01:51:POTS DRIVER port=1 cmd=1A
00:01:51:POTS DRIVER port=1 enter_idle
00:01:51:POTS DRIVER port=1 ts connect: 0 0
00:01:51:POTS DRIVER port=1 cmd=D
00:01:51:POTS DRIVER port=1 report onhook
00:01:51:POTS DRIVER port=1 activate tone=SILENCE_TONE
00:01:51:POTS DRIVER port=1 state=Idle drv_event=TONE_EVENT
00:01:53:POTS DRIVER port=1 activate ringer: cadence=0 callerId=Unknown
00:01:53:POTS DRIVER port=1 state=Idle drv_event=RING_EVENT
00:01:53:POTS DRIVER port=1 enter_ringing
00:01:53:POTS DRIVER port=1 cmd=19
00:02:49:POTS DRIVER port=1 state=Ringing drv_event=OFFHOOK_EVENT
00:02:49:POTS DRIVER port=1 enter_suspend
00:02:49:POTS DRIVER port=1 cmd=A
00:02:49:POTS DRIVER port=1 report offhook
00:02:49:POTS DRIVER port=1 activate connect: endpt=1 calltype=TWO_PARTY_CALL
00:02:49:POTS DRIVER port=1 state=Suspend drv_event=CONNECT_EVENT

DB-1800 May 2008
Debug Commands
debug pots
00:02:49:POTS DRIVER port=1 enter_connect: endpt=1 calltype=0

00:02:49:POTS DRIVER port=1 activate connect: endpt=1 calltype=TWO_PARTY_CALL
00:02:49:POTS DRIVER port=1 state=Connect drv_event=CONNECT_EVENT
00:02:49:POTS DRIVER port=1 enter_connect: endpt=1 calltype=0
00:02:55:POTS DRIVER port=1 state=Connect drv_event=ONHOOK_EVENT
00:02:55:POTS DRIVER port=1 enter_idle
00:02:55:POTS DRIVER port=1 cmd=D
00:02:55:POTS DRIVER port=1 report onhook
The following is sample output from the debug pots csm 1 command. This sample display indicates that
a dial peer contains an invalid destination pattern (555-1111).
Router# debug pots csm 1
01:57:28:EVENT_FROM_ISDN:dchanidb=0x66CB38, call_id=0x11, ces=0x2 bchan=0x0, event=0x1,

cause=0x0
01:57:28:Dial peer not found, route call to port 1
01:57:28:CSM_PROC_IDLE:CSM_EVENT_ISDN_CALL, call_id=0x11, port=1
01:57:28:Calling number 5551111
01:57:40:CSM_PROC_RINGING:CSM_EVENT_VDEV_OFFHOOK, call_id=0x11, port=1
01:57:40:EVENT_FROM_ISDN:dchan_idb=0x66CB38, call_id=0x11, ces=0x2 bchan=0x0, event=0x4,
cause=0x0
01:57:40:CSM_PROC_CONNECTING:CSM_EVENT_ISDN_CONNECTED, call_id=0x11, port=1
01:57:47:CSM_PROC_CONNECTING:CSM_EVENT_VDEV_ONHOOK, call_id=0x11, port=1
01:57:201863503872: %ISDN-6-DISCONNECT:Interface BRI0:1 disconnected from unknown, call
lasted 5485 seconds
01:57:47: %ISDN-6-DISCONNECT:Interface BRI0:1 disconnected from unknown, call lasted 5485
seconds
01:57:47:EVENT_FROM_ISDN:dchan _idb=0x66CB38, call_id=0x11, ces=0x2 bchan=0xFFFFFFFF,
event=0x0, cause=0x1
01:57:47:CSM_PROC_NEAR_END_DISCONNECT:CSM_

May 2008 DB-1801
Debug Commands
debug pots csm
debug pots csm

To activate events from which an application can determine and display the status and progress of calls
to and from plain old telephone service (POTS) ports, use the debug pots csm command in privileged
EXEC mode.
debug pots csm

12.1.(2)XF This command was introduced on the Cisco 800 series routers.
Examples To see debugging messages, enter the logging console global configuration mode command as follows:
Router(config)# logging console
Debugging messages are displayed in one of two formats that are relevant to the POTS dial feature:
hh:mm:ss: CSM_STATE: CSM_EVENT, call id = ??, port = ?
or
hh:mm:ss: EVENT_FROM_ISDN:dchan_idb=0x???????, call_id=0x????, ces=? bchan=0x????????,
event=0x?, cause=0x??
Table 275 debug pots csm Field Descriptions
Command Elements Description

hh:mm:ss Timestamp (in hours, minutes, and seconds).
CSM_STATE One of the call CSM states listed in Table 276.
CSM_EVENT One of the CSM events listed in Table 277.
call id Hexadecimal value from 0x00 to 0xFF.
port Telephone port 1 or 2.
EVENT_FROM_ISDN A CSM event. Table 277 shows a list of CSM events.
dchan_idb Internal data structure address.
ces Connection end point suffix used by ISDN.

DB-1802 May 2008
Debug Commands
debug pots csm
Table 275 debug pots csm Field Descriptions (continued)
Command Elements Description

bchan Channel used by the call. A value of 0xFFFFFFFF indicates that a
channel is not assigned.
event A hexadecimal value that is translated into a CSM event. Table 278
shows a list of events and the corresponding CSM events.
cause A hexadecimal value that is given to call-progressing events.
Table 279 shows a list of cause values and definitions.
Table 276 shows the values for CSM states.
Table 276 CSM States
CSM State Description

CSM_IDLE_STATE Telephone on the hook.
CSM_RINGING Telephone ringing.
CSM_SETUP Setup for outgoing call in progress.
CSM_DIALING Dialing number of outgoing call.
CSM_IVR_DIALING Interactive voice response (IVR) for Japanese
telephone dialing.
CSM_CONNECTING Waiting for carrier to connect the call.
CSM_CONNECTED Call connected.
CSM_DISCONNECTING Waiting for carrier to disconnect the call.
CSM_NEAR_END_DISCONNECTING Waiting for carrier to disconnect the call.
CSM_HARD_HOLD Call on hard hold.
CSM_CONSULTATION_HOLD Call on consultation hold.
CSM_WAIT_FOR_HOLD Waiting for carrier to put call on hard hold.
CSM_WAIT_FOR_CONSULTATION_HOLD Waiting for carrier to put call on consultation
hold.
CSM_CONFERENCE Waiting for carrier to complete call conference.
CSM_TRANSFER Waiting for carrier to transfer call.
CSM_APPLIC_DIALING Call initiated from Cisco IOS command-line
interface (CLI).
Table 277 shows the values for CSM events.
Table 277 CSM Events
CSM Events Description

CSM_EVENT_INTER_DIGIT_TIMEOUT Time waiting for dial digits has expired.
CSM_EVENT_TIMEOUT Near- or far-end disconnect timeout.
CSM_EVENT_ISDN_CALL Incoming call.

May 2008 DB-1803
Debug Commands
debug pots csm
Table 277 CSM Events (continued)
CSM Events Description

CSM_EVENT_ISDN_CONNECTED Call connected.
CSM_EVENT_ISDN_DISCONNECT Far end disconnected.
CSM_EVENT_ISDN_DISCONNECTED Call disconnected.
CSM_EVENT_ISDN_SETUP Outgoing call requested.
CSM_EVENT_ISDN_SETUP_ACK Outgoing call accepted.
CSM_EVENT_ISDN_PROC Call proceeding and dialing completed.
CSM_EVENT_ISDN_CALL_PROGRESSING Call being received in band tone.
CSM_EVENT_ISDN_HARD_HOLD Call on hard hold.
CSM_EVENT_ISDN_HARD_HOLD_REJ Hold attempt rejected.
CSM_EVENT_ISDN_CHOLD Call on consultation hold.
CSM_EVENT_ISDN_CHOLD_REJ Consultation hold attempt rejected.
CSM_EVENT_ISDN_RETRIEVED Call retrieved.
CSM_EVENT_ISDN_RETRIEVE_REJ Call retrieval attempt rejected.
CSM_EVENT_ISDN_TRANSFERRED Call transferred.
CSM_EVENT_ISDN_TRANSFER_REJ Call transfer attempt rejected.
CSM_EVENT_ISDN_CONFERENCE Call conference started.
CSM_EVENT_ISDN_CONFERENCE_REJ Call conference attempt rejected.
CSM_EVENT_ISDN_IF_DOWN ISDN interface down.
CSM_EVENT_ISDN_INFORMATION ISDN information element received (used by NTT
IVR application).
CSM_EVENT_VDEV_OFFHOOK Telephone off the hook.
CSM_EVENT_VDEV_ONHOOK Telephone on the hook.
CSM_EVENT_VDEV_FLASHHOOK Telephone hook switch has flashed.
CSM_EVENT_VDEV_DIGIT DTMF digit has been detected.
CSM_EVENT_VDEV_APPLICATION_CALL Call initiated from Cisco IOS CLI.
Table 278 shows the values for events that are translated into CSM events.
Table 278 Event Values
Hexadecimal
Value Event CSM Event
0x0 DEV_IDLE CSM_EVENT_ISDN_DISCONNECTED
0x1 DEV_INCALL CSM_EVENT_ISDN_CALL
0x2 DEV_SETUP_ACK CSM_EVENT_ISDN_SETUP_ACK
0x3 DEV_CALL_PROC CSM_EVENT_ISDN_PROC
0x4 DEV_CONNECTED CSM_EVENT_ISDN_CONNECTED
0x5 DEV_CALL_PROGRESSING CSM_EVENT_ISDN_CALL_PROGRESSING

DB-1804 May 2008
Debug Commands
debug pots csm
Table 278 Event Values (continued)
Hexadecimal
Value Event CSM Event
0x6 DEV_HOLD_ACK CSM_EVENT_ISDN_HARD_HOLD
0x7 DEV_HOLD_REJECT CSM_EVENT_ISDN_HARD_HOLD_REJ
0x8 DEV_CHOLD_ACK CSM_EVENT_ISDN_CHOLD
0x9 DEV_CHOLD_REJECT CSM_EVENT_ISDN_CHOLD_REJ
0xa DEV_RETRIEVE_ACK CSM_EVENT_ISDN_RETRIEVED
0xb DEV_RETRIEVE_REJECT CSM_EVENT_ISDN_RETRIEVE_REJ
0xc DEV_CONFR_ACK CSM_EVENT_ISDN_CONFERENCE
0xd DEV_CONFR_REJECT CSM_EVENT_ISDN_CONFERENCE_REJ
0xe DEV_TRANS_ACK CSM_EVENT_ISDN_TRANSFERRED
0xf DEV_TRANS_REJECT CSM_EVENT_ISDN_TRANSFER_REJ
Table 279 shows cause values that are assigned only to call-progressing events.
Table 279 Cause Values
Hexadecimal Value Cause Definitions

0x01 UNASSIGNED_NUMBER
0x02 NO_ROUTE
0x03 NO_ROUTE_DEST
0x04 NO_PREFIX
0x06 CHANNEL_UNACCEPTABLE
0x07 CALL_AWARDED
0x08 CALL_PROC_OR_ERROR
0x09 PREFIX_DIALED_ERROR
0x0a PREFIX_NOT_DIALED
0x0b EXCESSIVE_DIGITS
0x0d SERVICE_DENIED
0x10 NORMAL_CLEARING
0x11 USER_BUSY
0x12 NO_USER_RESPONDING
0x13 NO_USER_ANSWER
0x15 CALL_REJECTED
0x16 NUMBER_CHANGED
0x1a NON_SELECTED_CLEARING
0x1b DEST_OUT_OF_ORDER
0x1c INVALID_NUMBER_FORMAT
0x1d FACILITY_REJECTED

May 2008 DB-1805
Debug Commands
debug pots csm
Table 279 Cause Values (continued)

0x1e RESP_TO_STAT_ENQ
0x1f UNSPECIFIED_CAUSE
0x22 NO_CIRCUIT_AVAILABLE
0x26 NETWORK_OUT_OF_ORDER
0x29 TEMPORARY_FAILURE
0x2a NETWORK_CONGESTION
0x2b ACCESS_INFO_DISCARDED
0x2c REQ_CHANNEL_NOT_AVAIL
0x2d PRE_EMPTED
0x2f RESOURCES_UNAVAILABLE
0x32 FACILITY_NOT_SUBSCRIBED
0x33 BEARER_CAP_INCOMPAT
0x34 OUTGOING_CALL_BARRED
0x36 INCOMING_CALL_BARRED
0x39 BEARER_CAP_NOT_AUTH
0x3a BEAR_CAP_NOT_AVAIL
0x3b CALL_RESTRICTION
0x3c REJECTED_TERMINAL
0x3e SERVICE_NOT_ALLOWED
0x3f SERVICE_NOT_AVAIL
0x41 CAP_NOT_IMPLEMENTED
0x42 CHAN_NOT_IMPLEMENTED
0x45 FACILITY_NOT_IMPLEMENT
0x46 BEARER_CAP_RESTRICTED
0x4f SERV_OPT_NOT_IMPLEMENT
0x51 INVALID_CALL_REF
0x52 CHAN_DOES_NOT_EXIST
0x53 SUSPENDED_CALL_EXISTS
0x54 NO_CALL_SUSPENDED
0x55 CALL_ID_IN_USE
0x56 CALL_ID_CLEARED
0x58 INCOMPATIBLE_DEST
0x5a SEGMENTATION_ERROR
0x5b INVALID_TRANSIT_NETWORK
0x5c CS_PARAMETER_NOT_VALID
0x5f INVALID_MSG_UNSPEC

DB-1806 May 2008
Debug Commands
debug pots csm
Table 279 Cause Values (continued)

0x60 MANDATORY_IE_MISSING
0x61 NONEXISTENT_MSG
0x62 WRONG_MESSAGE
0x63 BAD_INFO_ELEM
0x64 INVALID_ELEM_CONTENTS
0x65 WRONG_MSG_FOR_STATE
0x66 TIMER_EXPIRY
0x67 MANDATORY_IE_LEN_ERR
0x6f PROTOCOL_ERROR
0x7f INTERWORKING_UNSPEC
Examples This section provides debug output examples for three call scenarios, displaying the sequence of events
that occur during a POTS dial call or POTS disconnect call.
Call Scenario 1
In this example call scenario, port 1 is on the hook, the application dial is set to call 4085552221, and
the far-end successfully connects.
Router# debug pots csm
Router# test pots 1 dial 4085552221#
Router#
The following output shows an event indicating that port 1 is being used by the dial application:
01:58:27: CSM_PROC_IDLE: CSM_EVENT_VDEV_APPLICATION_CALL, call id = 0x0, port = 1
The following output shows events indicating that the CSM is receiving the application digits of the
number to dial:
01:58:27: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_DIGIT, call id = 0x0, port = 1
The following output shows that the telephone connected to port 1 is off the hook:
01:58:39: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_OFFHOOK, call id = 0x0, port = 1
The following output shows a call-proceeding event pair indicating that the router ISDN software has
sent the dialed digits to the ISDN switch:
01:58:40: EVENT_FROM_ISDN:dchan_idb=0x280AF38, call_id=0x8004, ces=0x1 bchan=0x0,

May 2008 DB-1807
Debug Commands
debug pots csm
01:58:40: CSM_PROC_ENBLOC_DIALING: CSM_EVENT_ISDN_PROC, call id =

0x8004, port = 1
The following output shows the call-progressing event pair indicating that the telephone at the far end is
ringing:
01:58:40: EVENT_FROM_ISDN:dchan_idb=0x280AF38, call_id=0x8004, ces=0x1 bchan=0xFFFFFFFF,
01:58:40: CSM_PROC_ENBLOC_DIALING: CSM_EVENT_ISDN_CALL_PROGRESSING, call id = 0x8004, port
= 1
The following output shows a call-connecting event pair indicating that the telephone at the far end has
answered:
01:58:48: CSM_PROC_CONNECTING: CSM_EVENT_ISDN_CONNECTED, call id = 0x8004, port = 1
The following output shows a call-progressing event pair indicating that the telephone at the far end has
hung up and that the calling telephone is receiving an in-band tone from the ISDN switch:
01:58:55: CSM_PROC_CONNECTED: CSM_EVENT_ISDN_CALL_PROGRESSING, call id = 0x8004, port = 1
The following output shows that the telephone connected to port 1 has hung up:
01:58:57: CSM_PROC_CONNECTED: CSM_EVENT_VDEV_ONHOOK, call id = 0x8004, port = 1
The following output shows an event pair indicating that the call has been terminated:
01:58:57: CSM_PROC_NEAR_END_DISCONNECT: CSM_EVENT_ISDN_DISCONNECTED, call id = 0x8004,
port = 1
813_local#
Call Scenario 2
In this example scenario, port 1 is on the hook, the application dial is set to call 4085552221, and the
destination number is busy.
Router# test pots 1 dial 4085552221#
Router#
The following output shows that port 1 is used by the dial application:
01:59:42: CSM_PROC_IDLE: CSM_EVENT_VDEV_APPLICATION_CALL, call id = 0x0, port = 1
The following output shows the events indicating that the CSM is receiving the application digits of the
number to call:

DB-1808 May 2008
Debug Commands
debug pots csm
The following output shows an event indicating that the telephone connected to port 1 is off the hook:
01:59:52: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_OFFHOOK, call id = 0x0, port = 1
The following output shows a call-proceeding event pair indicating that the telephone at the far end is
busy:
01:59:52: EVENT_FROM_ISDN:dchan_idb=0x280AF38, call_id=0x8005, ces=0x1 bchan=0x0,
01:59:52: CSM_PROC_ENBLOC_DIALING: CSM_EVENT_ISDN_PROC, call id = 0x8005, port = 1
The following output shows a call-progressing event pair indicating that the calling telephone is
receiving an in-band busy tone from the ISDN switch:
01:59:58: CSM_PROC_ENBLOC_DIALING: CSM_EVENT_ISDN_CALL_PROGRESSING, call id = 0x8005, port
= 1
The following output shows an event indicating that the calling telephone has hung up:
02:00:05: CSM_PROC_ENBLOC_DIALING: CSM_EVENT_VDEV_ONHOOK, call id = 0x8005, port = 1
The following output shows an event pair indicating that the call has been terminated:
02:00:05: CSM_PROC_NEAR_END_DISCONNECT: CSM_EVENT_ISDN_DISCONNECTED, call id = 0x8005,
port = 1
Call Scenario 3
In this example call scenario, port 1 is on the hook, the application dial is set to call 4086661112, the far
end successfully connects, and the command test pots disconnect terminates the call:
Router# test pots 1 dial 4086661112
Router#
The following output follows the same sequence of events as shown in Call Scenario 1:
1d03h: CSM_PROC_IDLE: CSM_EVENT_VDEV_APPLICATION_CALL, call id = 0x0, port = 1
1d03h: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_DIGIT, call id = 0x0, port = 1
1d03h: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_OFFHOOK, call id = 0x0, port = 1
1d03h: EVENT_FROM_ISDN:dchan_idb=0x2821F38, call_id=0x8039, ces=0x1

1d03h: CSM_PROC_ENBLOC_DIALING: CSM_EVENT_ISDN_PROC, call id = 0x8039, port = 1

May 2008 DB-1809
Debug Commands
debug pots csm
bchan=0xFFFFFFFF, event=0x5, cause=0x0
1d03h: CSM_PROC_ENBLOC_DIALING: CSM_EVENT_ISDN_CALL_PROGRESSING, call id = 0x8039,

port = 1
Router# test pots 1 disconnect
The test pots disconnect command disconnects the call before you physically need to put the telephone
back on the hook:
1d03h: CSM_PROC_CONNECTING: CSM_EVENT_VDEV_APPLICATION_HANGUP_CALL, call id = 0x8039,
port = 1
bchan=0xFFFFFFFF, event=0x0, cause=0x0
1d03h: CSM_PROC_DISCONNECTING: CSM_EVENT_ISDN_DISCONNECTED, call id = 0x8039,

port = 1
1d03h: CSM_PROC_DISCONNECTING: CSM_EVENT_TIMEOUT, call id = 0x8039, port = 1

DB-1810 May 2008
Debug Commands
debug ppp bap
debug ppp bap

To display general Bandwidth Allocation Control Protocol (BACP) transactions, use the debug ppp bap
debug ppp bap [error | event | negotiation]
no debug ppp bap [error | event | negotiation]
Syntax Description error (Optional) Displays local errors.

event (Optional) Displays information about protocol actions and
transitions between action states (pending, waiting, idle) on the link.
negotiation (Optional) Displays successive steps in negotiations between peers.
Usage Guidelines Do not use this command when memory is scarce or in very high traffic situations.
Examples The following types of events generate the debugging messages displayed in the figures in this section:
A dial attempt failed.
A BACP group was created.
A BACP group was removed.
The precedence of the group changed.
Attempting to dial a number.
Received a BACP message.
Discarding a BACP message.
Received an unknown code.
Cannot find the appropriate BACP group on input.
Displaying the response type.
Incomplete mandatory options notification.
Invalid outgoing message type.
Unable to build an output message.
Sending a BACP message.
Details about the sent message (type of message, its identifier, the virtual access interface that sent
it).

May 2008 DB-1811
Debug Commands
debug ppp bap
The following is sample output from the debug ppp bap command:
Router# debug ppp bap
BAP Virtual-Access1: group "laudrup" (2) (multilink) without precedence created
BAP laudrup: sending CallReq, id 2, len 38 on BRI3:1 to remote

BAP Virtual-Access1: received CallRsp, id 2, len 13
BAP laudrup: CallRsp, id 2, ACK
BAP laudrup: attempt1 to dial 19995776677 on BRI3
---> reason BAP - Multilink bundle overloaded
BAP laudrup: sending StatusInd, id 2, len 44 on Virtual-Access1 to remote
BAP Virtual-Access1: received StatusRsp, id 2, len 1
BAP laudrup: StatusRsp, id 2, ACK
Table 280 debug ppp bap Field Descriptions
Field Description
BAP Virtual-Access1: Identifier of the virtual access interface in use.
group laudrup Name of the BACP group.
sending CallReq Action initiated; in this case, sending a call request.
on BRI3:1 to remote Physical interface being used.
BAP laudrup: attempt1 to dial 19995776677 Call initiated, number being dialed, and physical
on BRI3 interface being used.
---> reason BAP - Multilink bundle Reason for initiating the BACP call.
overloaded
BAP laudrup: sending StatusInd, id 2, len 44 Details about the sent message: It was a status
on Virtual-Access1 to remote indication message, had identifier 2, had a BACP
datagram length 44, and was sent on virtual access
interface 1. You can display information about the
virtual access interface by using the show interfaces
virtual-access EXEC command. (The length shown at
the end of each negotiated option includes the 2-byte
type and length header.)
The debug ppp bap event command might show state transitions and protocol actions, in addition to the
basic debug ppp bap command.
The following is sample output from the debug ppp bap event command:
Router# debug ppp bap event
BAP laudrup: Idle --> AddWait

BAP laudrup: AddWait --> AddPending
BAP laudrup: AddPending --> Idle

DB-1812 May 2008
Debug Commands
debug ppp bap
The following is sample output from the debug ppp bap event command:
Router# debug ppp bap event
Peer does not support a message type

No response to a particular request
No response to all request retransmissions
Not configured to initiate link addition
Expected action by peer has not occurred
Exceeded number of retries
No links available to call out
Unable to provide phone numbers for callback
Maximum number of links in the group
Minimum number of links in the group
Unable to process link addition at present
Unable to process link removal at present
Not configured/unable to initiate link removal
Link addition completed notification
Link addition failed notification
Determination of location of the group config
Link with specified discriminator not in group
Link removal failed
Call failure with status
Failed to dial specified number
Discarding retransmission
Unable to find received identifier
Received StatusInd when no call pending
Discarding message with no phone delta
Unable to send message in particular state
Received a zero identifier
Request has precedence
The error messages displayed might be added to the basic output when the debug ppp bap error
command is used. Because the errors are very rare, you might never see these messages.
Router# debug ppp bap error
Unable to find appropriate request for received response

Invalid message type of queue
Received request is not part of the group
Add link attempt failed to locate group
Remove link attempt failed to locate group
Unable to inform peer of link addition
Changing of precedence cannot locate group
Received short header/illegal length/short packet
Invalid configuration information length
Unable to NAK incomplete options
Unable to determine current number of links
No interface list to dial on
Attempt to send invalid data
Local link discriminator is not in group
Received response type is incorrect for identifier

May 2008 DB-1813
Debug Commands
debug ppp bap
The messages displayed might be added to the basic output when the debug ppp bap negotiation
command is used:
Router# debug ppp bap negotiation
BAP laudrup: adding link speed 64 kbps for type 0x1 len 5
BAP laudrup: adding reason "User initiated addition", len 25
BAP laudrup: CallRsp, id 4, ACK
BAP laudrup: link speed 64 kbps for types 0x1, len 5 (ACK)
BAP laudrup: phone number "1: 0 2: ", len 7 (ACK)
BAP laudrup: adding call status 0, action 0 len 4
BAP laudrup: adding 1 phone numbers "1: 0 2: " len 7
BAP laudrup: adding reason "Successfully added link", len 25
BAP laudrup: StatusRsp, id 4, ACK
Additional negotiation messages might also be displayed for the following:

Received BAP message
Sending message
Decode individual options for send/receive
Notification of invalid options
The following shows additional reasons for a particular BAP action that might be displayed in an adding
reason line of the debug ppp bap negotiation command output:
"Outgoing add request has precedence"
"Outgoing remove request has precedence"
"Unable to change request precedence"
"Unable to determine valid phone delta"
"Attempting to add link"
"Link addition is pending"
"Attempting to remove link"
"Link removal is pending"
"Precedence of peer marked CallReq for no action"
"Callback request rejected due to configuration"
"Call request rejected due to configuration"
"No links of specified type(s) available"
"Drop request disallowed due to configuration"
"Discriminator is invalid"
"No response to call requests"
"Successfully added link"
"Attempt to dial destination failed"
"No interfaces present to dial out"
"No dial string present to dial out"
"Mandatory options incomplete"
"Load has not exceeded threshold"
"Load is above threshold"
"Currently attempting to dial destination"
"No response to CallReq from race condition"

DB-1814 May 2008
Debug Commands
debug ppp bap
Table 281 describes the reasons for a BACP Negotiation Action.
Table 281 Explanation of Reasons for BACP Negotiation Action
Reason Explanation
Outgoing add request has Received a CallRequest or CallbackRequest while we were
precedence waiting on a CallResponse or CallbackResponse to a sent
request. We are the favored peer from the initial BACP
negotiation, so we are issuing a NAK to our peer request.
Outgoing remove request has Received a LinkDropQueryRequest while waiting on a
precedence LinkDropQueryResponse to a sent request. We are the favored
peer from the initial BACP negotiation, therefore we are
issuing a NAK to our peer request.
Unable to change request Received a CallRequest, CallbackRequest, or
precedence LinkDropQueryRequest while waiting on a
LinkDropQueryResponse to a sent request. Our peer is deemed
to be the favored peer from the initial BACP negotiation and
we were unable to change the status of our outgoing request in
response to the favored request, so we are issuing a NAK.
(This is an internal error and should never be seen.)
Unable to determine valid phone Received a CallRequest from our peer but are unable to
delta provide the required phone delta for the response, so we are
issuing a NAK. (This is an internal error and should never be
seen.)
Attempting to add link Received a LinkDropQueryRequest while attempting to add a
link; a NAK is issued.
Link addition is pending Received a LinkDropQueryRequest, CallRequest, or
CallbackRequest while attempting to add a link as the result of
a previous operation; a NAK is issued in the response.
Attempting to remove link Received a CallRequest or CallbackRequest while attempting
to remove a link; a NAK is issued.
Link removal is pending Received a CallRequest, CallbackRequest, or
LinkDropQueryRequest while attempting to remove a link as
the result of a previous operation; a NAK is issued in the
response.
Precedence of peer marked CallReq Received an ACK to a previously unfavored CallRequest; we
for no action are issuing a CallStatusIndication to inform our peer that there
will be no further action on our part as per this response.
Callback request rejected due to Received a CallbackRequest but we are configured not to
configuration accept them; a REJect is issued to our peer.
Call request rejected due to Received a CallRequest but we are configured not to accept
configuration them; a REJect is issued to our peer.
No links of specified type(s) We received a CallRequest but no links of the specified type
available and speed are available; a NAK is issued.
Drop request disallowed due to Received a LinkDropQueryRequest but we are configured not
configuration to accept them; a NAK is issued to our peer.

May 2008 DB-1815
Debug Commands
debug ppp bap
Table 281 Explanation of Reasons for BACP Negotiation Action (continued)
Reason Explanation
Discriminator is invalid Received a LinkDropQueryRequest but the local link
discriminator is not contained within the bundle; a NAK is
issued.
No response to call requests After no response to our CallRequest message, a
CallStatusIndication is sent to the peer informing that no more
action will be taken on behalf of this operation.
Successfully added link Sent as part of the CallStatusIndication informing our peer that
we successfully completed the addition of a link to the bundle
as the result of the transmission of a CallRequest or the
reception of a CallbackRequest.
Attempt to dial destination failed Sent as part of the CallStatusIndication informing our peer that
we failed in an attempt to add a link to the bundle as the result
of the transmission of a CallRequest or the reception of a
CallbackRequest. The retry field with the CallStatusIndication
informs the peer of our intentions.
No interfaces present to dial out There are no available interfaces to dial out on to attempt to
add a link to the bundle, and we will not retry the dial attempt.
No dial string present to dial out We do not have a dial string to dial out with to attempt to add
a link to the bundle, and we are not going to retry the dial
attempt. (This is an internal error and should never be seen.)
Mandatory options incomplete Received a CallRequest, CallbackRequest,
LinkDropQueryRequest, or CallStatusIndication and the
mandatory options are not present, so a NAK is issued in the
response. (A CallStatusResponse is an ACK, however).
Load has not exceeded threshold Received a CallRequest or CallbackRequest but we are issuing
a NAK in the response. We are monitoring the load of the
bundle, and so we determine when links should be added to the
bundle.
Load is above threshold Received a LinkDropQueryRequest but we are issuing a NAK
in the response. We are monitoring the load of the bundle, and
so we determine when links should be removed from the
bundle.
Currently attempting to dial Received a CallbackRequest which is a retransmission of one
destination that we previously ACKd and are dialing the number
suggested in the request. We are issuing an ACK because we
did so previously, even though our peer never saw the previous
response.
No response to CallReq from race We issued a CallRequest but failed to receive a response, and
condition we are issuing a CallStatusIndication to inform our peer of our
intention not to proceed with the operation.

DB-1816 May 2008
Debug Commands
debug ppp multilink events

To display information about events affecting multilink groups established for Bandwidth Allocation
Control Protocol (BACP), use the debug ppp multilink events command in privileged EXEC mode. To
no debug ppp multilink events
Usage Guidelines
Caution Do not use this command when memory is scarce or in very high traffic situations.
Examples The following is sample output from the debug ppp multilink events command:
Router# debug ppp multilink events
MLP laudrup: established BAP group 4 on Virtual-Access1, physical BRI3:1

MLP laudrup: removed BAP group 4
Other event messages include the following:

Unable to find bundle for BAP group identifier
Unable to find physical interface to start BAP
Unable to create BAP group
Attempt to start BACP when inactive or running
Attempt to start BACP on non-MLP interface
Link protocol has gone down, removing BAP group
Link protocol has gone down, BAP not running or present
Table 282 debug ppp multilink events Field Descriptions
Field Description
MLP laudrup Name of the multilink group.
established BAP group 4 Internal identifier. The same identifiers are used in the
show ppp bap group command output.
Virtual-Access1 Dynamic access interface number.
physical BRI3:1 Bundle was established from a call on this interface.
removed BAP group 4 When the bundle is removed, the associated BACP
group (with its ID) is also removed.

May 2008 DB-1817
Debug Commands
debug ppp multilink fragments

To display information about individual multilink fragments and important multilink events, use the
debug ppp multilink fragments command in privileged EXEC mode. To disable debugging output, use
no debug ppp multilink fragments
Usage Guidelines
Caution The debug ppp multilink fragments command has some memory overhead and should not be used
when memory is scarce or in very high traffic situations.
Examples The following is sample output from the debug ppp multilink fragments command when used with the
ping EXEC command. The debug output indicates that a multilink PPP packet on interface BRI 0 (on
the B channel) is an input (I) or output (O) packet. The output also identifies the sequence number of the
packet and the size of the fragment.
Router# debug ppp multilink fragments
Router# ping 7.1.1.7

!!!!!
Router#
2:00:28: MLP BRI0: B-Channel 1: O seq 80000000: size 58
2:00:28: MLP BRI0: B-Channel 2: I seq 40000001: size 59

DB-1818 May 2008
Debug Commands


May 2008 DB-1819
Debug Commands
debug ppp multilink negotiation

Note Effective with release 11.3, the debug ppp multilink negotiation command is not available in
Cisco IOS software.
To display information about events affecting multilink groups established controlled by Bandwidth
Allocation Control Protocol (BACP), use the debug ppp multilink negotiation command in privileged
no debug ppp multilink negotiation

11.3 This command was removed and is not available in Cisco IOS software.
Usage Guidelines
Caution Do not use this command when memory is scarce or in very high traffic situations.
Examples The following sample output shows Link Control Protocol (LCP) and Network Control Program (NCP)
messages that might appear in debug ppp multilink negotiation command. These messages show
information about PPP negotiations between the multilink peers.
Router# debug ppp multilink negotiation
ppp: sending CONFREQ, type = 23 (CI_LINK_DISCRIMINATOR), value = 0xF

PPP BRI3:1: received config for type = 23 (LINK_DISCRIMINATOR) value = 0xA acked
Router# debug ppp multilink negotiation
ppp: sending CONFREQ, type = 1 (CI_FAVORED_PEER), value = 0x647BD090

PPP Virtual-Access1: received CONFREQ, type 1, value = 0x382BBF5 (ACK)
PPP Virtual-Access1: BACP returning CONFACK
ppp: config ACK received, type = 1 (CI_FAVORED_PEER), value = 0x647BD090
PPP Virtual-Access1: BACP up

DB-1820 May 2008
Debug Commands
Table 283 debug ppp multilink negotiation Field Descriptions
Field Description
sending CONFREQ, type = 23 Sending a configuration request and the value of the
(CI_LINK_DISCRIMINATOR), value = 0xF link discriminator. Each peer assigns a discriminator
value to identify a specific link. The values are
significant to each peer individually but do not have to
be shared.
PPP BRI3:1: Physical interface being used.
CI_FAVORED_PEER When the PPP NCP negotiation occurs over the first
link in a bundle, the BACP peers use a Magic Number
akin to that used by LCP to determine which peer
should be favored when both implementations send a
request at the same time. The peer that negotiated the
higher number is deemed to be favored. That peer
should issue a negative acknowledgment to its
unfavored peer, which in turn should issue a positive
acknowledgment, if applicable according to other link
considerations.
PPP Virtual-Access1: BACP returning Returning acknowledgment that BACP is configured.
CONFACK
PPP Virtual-Access1: BACP up Indicating that the BACP NCP is open.

May 2008 DB-1821
Debug Commands
debug ppp redundancy
debug ppp redundancy

To debug PPP synchronization on the networking device, use the debug ppp redundancy command in
privileged EXEC mode. To disable the display of debugging output, use the no form of this command.
debug ppp redundancy [detailed | event]
no debug ppp redundancy [detailed | event]
Syntax Description detailed (Optional) Displays detailed debug messages related to specified PPP
redundancy events.
event (Optional) Displays information about protocol actions and transitions
between action states (pending, waiting, idle) on the link.

12.0(22)S This command was introduced on the Cisco 7500, 10000, and 12000 series
Internet routers.
Examples The following example displays detailed debug messages related to specified PPP redundancy events:
Router# debug ppp redundancy detailed

DB-1822 May 2008
Debug Commands
debug ppp
debug ppp
To display information on traffic and exchanges in an internetwork implementing the Point-to-Point
Protocol (PPP), use the debug ppp command in privileged EXEC mode. To disable debugging output,
debug ppp {packet | negotiation | error | authentication | compression | cbcp}
no debug ppp {packet | negotiation | error | authentication | compression | cbcp}
Syntax Description packet Displays PPP packets being sent and received. (This command display

Cisco IOS 12.4 Debug CR

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cisco IOS 12.4 Debug CR

Uploaded by

Copyright:

Available Formats

Cisco IOS Debug Command Reference

Cisco IOS Debug Command Reference

Cisco IOS Debug Command Reference

Cisco IOS Debug Command Reference

Entering debug Commands

debug isdn q931

no debug isdn q931

Cisco IOS Debug Command Reference

Using the debug ? Command

Using the debug all Command

Generating debug Command Output

15:25:51: TTY4: DSR came up

Cisco IOS Debug Command Reference

Redirecting debug and Error Message Output

Enabling Message Logging

The default condition is logging on.

Cisco IOS Debug Command Reference

Setting the Message Logging Levels

Table 1 Message Logging Keywords and Levels

Level Keyword Description Syslog Definition

Limiting the Types of Logging Messages Sent to the Console

logging console level

Cisco IOS Debug Command Reference

Logging Messages to an Internal Buffer

Limiting the Types of Logging Messages Sent to Another Monitor

logging monitor level

Logging Messages to a UNIX Syslog Server

logging host {ip-address | host-name} [xml]

no logging host {ip-address | host-name} [xml]

Cisco IOS Debug Command Reference

Limiting Messages to a Syslog Server

logging trap level

Example of Setting Up a UNIX Syslog Daemon

The local7 keyword specifies the logging facility to be used.

Cisco IOS Debug Command Reference

Cisco IOS Debug Command Reference

Enabling Protocol-Specific Debug Commands

Enabling Conditional Debugging Commands

Displaying Messages for One Interface

Cisco IOS Debug Command Reference

Displaying Messages for Multiple Interfaces

Limiting Messages Based on Conditions

Cisco IOS Debug Command Reference

Specifying Multiple Conditions

Conditionally Triggered Debugging Configuration Examples

Condition 1: interface Se0 (1 flags triggered)

Cisco IOS Debug Command Reference

*Mar 1 00:04:44.283: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1,

Condition 1: interface Se0 (2 flags triggered)

Condition 1: interface Se0 (1 flags triggered)

Cisco IOS Debug Command Reference

Cisco IOS Debug Command Reference

Cisco IOS Debug Command Reference

debug aaa accounting

debug aaa accounting

no debug aaa accounting

Syntax Description This command has no arguments or keywords.

Command Modes Privileged EXEC (#)

16:49:21: AAA/ACCT: EXEC acct start, line 10

Related Commands Command Description

Cisco IOS Debug Command Reference

debug aaa authentication

debug aaa authentication