Documente Academic
Documente Profesional
Documente Cultură
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.
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.
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.
To turn off the debug isdn q931 command, enter the no form of the command at the command line in
privileged EXEC mode:
To display the state of each debugging option, enter the following at the command line in privileged
EXEC mode:
show debugging
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.
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.
The router continues to generate such output until you enter the corresponding no debug command (in
this case, the no debug modem command).
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.
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.
logging on
no logging on
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
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).
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
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.
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.
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
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
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.
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.
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.
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.
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.
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
After a period of time, the show debug condition command displays the revised list of conditions:
Router# show debug condition
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
*Mar 1 00:05:52.443: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed
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
*Mar 1 00:05:57.907: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed
state to down
*Mar 1 00:05:57.907: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1,
changed state to down
The final show debug condition output is the same as the output before the interfaces came up:
Router# show debug condition
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.
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
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
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
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.
Examples The following is sample output from the debug aaa cache filterserver command:
Router# debug aaa cache filterserver
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
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
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.
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
Examples The following example shows output from a successful POD request when using the show debug
command:
Router# debug aaa pod
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
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
==============
Logs on Standby
================
01:21:16: 73 75 6D 61 6E 74 68 00
01:21:16: Client[PPP] Type[41] Subtype[0] Length[4]
01:21:16: 00 00 00 02
01:21:16: Client[PPPoE] Type[1] Subtype[0] Length[54]
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: Client[PPPoE] Type[2] Subtype[0] Length[2]
01:21:16: 00 0A
01:21:16: Client[PPPoE] Type[5] Subtype[0] Length[4]
01:21:16: 00 00 10 09
01:21:16: Client[PPPoE] Type[6] Subtype[0] Length[4]
01:21:16: 00 00 10 12
01:21:16: Client[PPPoE] Type[7] Subtype[0] Length[20]
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: Client[PPPoE] Type[8] Subtype[0] Length[16]
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: Client[AAA] Type[1] Subtype[0] Length[4]
01:21:16: 00 00 00 0B
01:21:16: Client[AAA] Type[2] Subtype[0] Length[2]
01:21:16: 00 00
01:21:16: Client[AAA] Type[3] Subtype[0] Length[4]
01:21:16: 00 00 00 0B
01:21:16: Client[AAA] Type[4] Subtype[0] Length[84]
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: LTERM 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 Protocol-Type = 0 (PPP)
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 AAA-Id = 11 (0000000B)
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]: Updating ID Mgr with the following keys:
aaa-unique-id 11 (0xB)
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 MGR [uid:10]: Handling Need More Keys action
01:21:16: SSS INFO: Element type is Unauth-User = "user1"
01:21:16: SSS INFO: Element type is AccIe-Hdl = 4127195145 (F6000009)
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.
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
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/ENCODE: Best Local IP-Address 192.0.2.130 for Radius-Server 192.0.2.118
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: User-Password [2] 18 *
00:43:40: RADIUS: NAS-Port [5] 6 2
00:43:40: RADIUS: NAS-Port-Type [61] 6 Virtual [5]
00:43:40: RADIUS: Calling-Station-]d [31] 15 "192.0.2.23"
00:43:40: RADIUS: NAS-IP-Address [4] 6 192.0.2.130
00:43:42: RADIUS: Fail-over to (192.0.2,1:1645,1646) for id 21645/14
00:43:42: RADIUS/ENCODE: Best Local IP-Address 192.0.2.130 for Radius-Server 192.0.2.1
00:43:44: RADius: Fail-over to (192.0.2.2:1645,1646) for id 21645/14
00:43:44: RADIUS/ENCODE: Best Local IP-Address 192.0.2.130 for Radius-Server 192.0.2.2
00:43:46: RADIUS: Fail-over to (192.0.2.118:1645,1646) for id 21645/14
00:43:46: RADIUS/ENCODE: Best Local IP-Address 192.0.2.130 for Radius-Server 192.0.2.118
00:43:48: RADIUS: Fail-over to (192.0.2.1:1645,1646) for id 21645/14
00:43:48: RADIUS/ENCODE: Best Local IP-Address 192.0.2.130 for Radius-Server 192.0.2.1
00:43:50: RADIUS: Fail-over to (192.0.2.2:1645,1646) for id 21645/14
00:43:50: RADIUS/ENCODE: Best Local IP-Address 192.0.2.130 for Radius-Server 192.0.2.2
00:43:52: RADIUS: Fail-over to (192.0.2.118:1645,1646) for id 21645/14
00:43:52: RADIUS/ENCODE: Best Local IP-Address 192.0.2.130 for Radius-Server 192.0.2.118
00:43:54: RADIUS: Fail-over to (192.0.2.1:1645,1646) for id 21645/14
00:43:54: RADIUS/ENCODE: Best Local IP-Address 192.0.2.130 for Radius-Server 192.0.2.1
00:43:56: RADIUS: No response from (192.0.2.1:1645,1646) for id 21645/14
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
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.
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.
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 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
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
%OIR-6-REMCARD: Card removed from slot 5, interfaces disabled
%OIR-6-REMCARD: Card removed from slot 9, 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 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
disable debugging output, use the no form of this command.
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
The following is sample output from the debug acircuit event command when you disable an interface:
Router# debug acircuit event
The following example shows output from the debug acircuit command for an xconnect session on an
Ethernet interface:
Router# debug acircuit
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}]
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)SRA This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH This command was integrated into Cisco IOS Release 12.2(33)SXH.
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 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
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
debugging output, use the no form of this command.
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.
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
The following is sample output from the debug alarm-interface 1 data command:
Router# debug alarm-interface 1 data
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]]
Release Modification
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 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
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
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
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: 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: Tx ALC POLL MSG (+ 0 pad bytes) to 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
ALPS ASCU: ALC GO AHD MSG rcvd from ascu 42 on i/f Serial6
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
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: 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: Tx ALC POLL MSG (+ 0 pad bytes) to 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: ALC GO AHD MSG rcvd from ascu 42/2F on i/f Serial6
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
The following output is from the debug alps ascu packet command, showing all packets sent or received
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 ASCU: Tx ALC DATA MSG (14 bytes + CCC + 0 pad bytes) to ascu 42/2F on i/f Serial6
ALPS IPARS Format:
2F3E38 26161C38
26161C18 26141DE4
The following output is from the debug alps ascu packet command, showing all packets sent or received
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 ASCU: Tx ALC DATA MSG (14 bytes + CCC + 0 pad bytes) to ascu 42/2F on i/f Serial6
ALPS Router Format:
022038 26253138
26253139 263511E4
ALPS IPARS Format:
2F3E38 26161C38
26161C18 26141DE4
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.
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 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
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
Defaults If no IP address is specified, then debugging is enabled for every peer connection.
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
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
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
debug appfw
To display debug messages about Cisco IOS Firewall events, use the debug appfw command in
privileged EXEC mode. To disable debugging output, use the no form of this command.
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_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
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
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).
Ether0: AARP: Reply from 4160.26(0000.0c00.0453) for 4160.154(0000.0c00.8ea9)
The following line indicates that the MAC address request is complete:
Ether0: AARP: Resolved waiting request for 4160.26(0000.0c00.0453)
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
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
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).
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
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
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.
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.
Examples The following is sample output from the debug apple events command that describes a nonseed router
coming up in discovery mode:
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.
Ether0: AT: Resetting interface address filters
The following messages indicate that the router is changing to restarting mode:
%AT-5-INTRESTART: Ether0: AppleTalk port restarting; protocol restarted
Ether0: AppleTalk state changed; unknown -> restarting
The following message indicates that the router is probing in the startup range of network numbers
(65280 to 65534) to discover its network number:
Ether0: AppleTalk state changed; restarting -> probing
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.
%AT-6-ADDRUSED: Ether0: AppleTalk node up; using address 65401.148
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:
Ether0: AppleTalk state changed; probing -> acquiring
%AT-6-ACQUIREMODE: Ether0: AT port initializing; acquiring net configuration
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
Ether0: AppleTalk state changed; restarting -> probing
The following message indicates that the router has found an actual network address to use:
%AT-6-ADDRUSED: Ether0: AppleTalk node up; using address 4160.148
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:
Ether0: AppleTalk state changed; probing -> acquiring
%AT-6-ACQUIREMODE: Ether0: AT port initializing; acquiring net configuration
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
The following shows sample debug apple events output that describes a nondiscovery-enabled router
coming up when no other router is on the wire.
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
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:
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.
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
utilization of the router is less than 50 percent.
Examples The following is sample output from the debug apple nbp command:
Router# debug apple nbp
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.
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.
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.
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
utilization of the router is less than 50 percent.
Examples The following is sample output from the debug apple packet command:
Router# debug apple packet
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.
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.
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
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
Table 10 describes the fields in the first line of sample debug apple routing 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.
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:
AT: RTMP from 4160.19 (new 0,old 94,bad 0,ign 0, dwn 0)
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.
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
The first line indicates that the router has received an RTMP update that includes a new network number
and is now requesting zone information:
AT: Sent GetNetInfo request broadcast on Ether0
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
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
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.
Command Description
debug appn ss Displays SS events.
debug appn ss Displays debugging information on APPN TRS component activity.
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
Table 12 describes the significant fields and messages shown in the display.
Field Description
APPN APPN debugging output.
CS CS component output.
Deq CS received a message from another component.
Field Description
FSM LS Link station finite state machine is being referenced.
Sending CS is sending a message to another component.
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
debugging output, use the no form of this command.
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
Field Description
APPN APPN debugging output.
NEWDS DS component output.
search from Locate was received from NETA.PATTY.
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.
Examples The following is sample output from the debug appn hpr command:
Router# debug appn hpr
Field Description
APPN APPN debugging output.
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.
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
debugging output, use the no form of this command.
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
Field Description
APPN Indicates that this is APPN debugging output.
MSP Indicates that this is MS component output.
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
Field Description
APPN APPN debugging output.
NOF NOF component output.
Received Configuration command was entered.
send Message was sent to CS.
waiting Response was expected from CS.
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
Field Description
APPN APPN debugging output.
PC PC component output.
Deq REMOTE Message was received from the network.
mu received Message is an MU.
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.
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
debugging output, use the no form of this command.
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
Field Description
APPN APPN debugging output.
CCA CP Capabilities TP output.
RCA Receive CP Capabilities TP output.
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
Field Description
APPN APPN debugging output.
SCM SCM component output.
debug appn ss
To display session services (SS) events, use the debug appn ss command in privileged EXEC mode. To
disable debugging output, use the no form of this command.
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
Field Description
APPN APPN debugging output.
SS SS component output.
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
Field Description
APPN APPN debugging output.
TRS TRS component output.
debug arap
To display AppleTalk Remote Access Protocol (ARAP) events, use the debug arap command in
privileged EXEC mode. To disable debugging output, use the no form of this command.
debug arap {internal | memory | mnp4 | v42bis} [linenum [aux | console | tty | vty]]
no debug arap {internal | memory | mnp4 | v42bis} [linenum [aux | console | tty | vty]]
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
Examples The following is sample output from the debug archive config timestamp command:
Router# debug archive config timestamp
Router# configure replace disk0:myconfig force
Starting Pass 1
Time to read file system:running-config = 0 msec (0 sec)
Number of lines read:93
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)
Command Default If this command is not entered, there is no debugging or display of the configuration logging persistent
events in the archive.
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#
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 arp
To enable debugging output for Address Resolution Protocol (ARP) transactions, use the debug arp
command in privileged EXEC mode. To disable debugging output, use the no form of this command.
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.
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
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
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.
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.
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
c5300-5#
*May 4 06:26:29.647://5//ASNL:SUB1:/asnl_start_timer:timer (0x63146C44)starts - delay
(5000)
*May 4 06:26:29.647://-1//ASNL:SUB1:/asnl_stop_timer:timer(0x63146C44) stops
*May 4 06:26:29.651://-1//ASNL:SUB1:/asnl_notify_ack:ret=0x0
*May 4 06:26:34.663://5//ASNL:SUB1:/asnl_start_timer:timer (0x63146C44)starts - delay
(5000)
*May 4 06:26:34.663://-1//ASNL:SUB1:/asnl_stop_timer:timer(0x63146C44) stops
*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
*May 4 06:26:34.667://-1//ASNL:SUB1:/asnl_notify_ack:ret=0x0
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
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.
Field Description
Data (n bytes) Type and size of the packet.
F1FF4c42 Alarm panel device address.
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
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.
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
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.
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
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.
Examples The following example provides output for the debug atm bundle error command:
Router# debug atm bundle error
Examples The following example provides output for the debug atm bundle events command:
Router# debug atm bundle events
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.
Examples The following example enables debugging for ATM virtual circuits (VCs) that have been configured with
cell packing:
Router# debug atm cell-packing
The following example enables debugging for permanent virtual paths (PVPs) that have been configured
with cell packing:
Router# debug atm cell-packing
The output indicates that the router received the MNCP information from the remote PE router.
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
aip_love_note(ATM4/0): asr=0x200
aip_setup_vc(ATM4/0): vc:3 vpi:3 vci:3
aip_love_note(ATM4/0): asr=0x200
aip_setup_vc(ATM4/0): vc:4 vpi:4 vci:4
aip_love_note(ATM4/0): asr=0x200
aip_setup_vc(ATM4/0): vc:6 vpi:6 vci:6
aip_love_note(ATM4/0): asr=0x200
aip_setup_vc(ATM4/0): vc:7 vpi:7 vci:7
aip_love_note(ATM4/0): asr=0x200
aip_setup_vc(ATM4/0): vc:11 vpi:11 vci:11
aip_love_note(ATM4/0): asr=0x200
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
The following line indicates that a configuration command has been completed by the AIP:
aip_love_note(ATM4/0): asr=0x201
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.
aip_love_note(ATM4/0): asr=0x4000
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:
aip_setup_vc(ATM4/0): vc:1 vpi:1 vci:1
aip_love_note(ATM4/0): asr=0x200
Defaults Disabled
Examples The following example displays debug messages regarding ATM HA errors on the networking device:
Router# debug atm ha-error
Defaults Disabled.
Examples The following example displays debug messages regarding ATM HA events on the networking device:
Router# debug atm ha-events
Examples The following example displays debug messages regarding the ATM HA state on the networking device:
Router# debug atm ha-state
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:
ATM L2transport Events and Errors debugging is on
The following example shows the events and messages when deleting a PVP.
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
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
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.
Examples The following is sample output for the debug atm native command with the api keyword:
Router# debug atm native 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
Syntax Description interface atm number (Optional) Number of the ATM interface.
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
00:15:09: CC CELL (ATM0) I:VCD#1 VC 1/40 OAM Cell Type:4 OAM Type:1 OAM Func:4
00:15:10: CC CELL (ATM0) O:VCD#1 VC 1/40 OAM Cell Type:4 OAM Type:1 OAM Func:4
00:15:11: CC CELL (ATM0) I:VCD#1 VC 1/40 OAM Cell Type:4 OAM Type:1 OAM Func:4
00:15:12: CC CELL (ATM0) O:VCD#1 VC 1/40 OAM Cell Type:4 OAM Type:1 OAM Func:4
00:15:13: CC CELL (ATM0) I:VCD#1 VC 1/40 OAM Cell Type:4 OAM Type:1 OAM Func:4
00:15:14: CC CELL (ATM0) O:VCD#1 VC 1/40 OAM Cell Type:4 OAM Type:1 OAM Func:4
00:15:15: CC CELL (ATM0) I:VCD#1 VC 1/40 OAM Cell Type:4 OAM Type:1 OAM Func:4
00:15:16: CC CELL (ATM0) O:VCD#1 VC 1/40 OAM Cell Type:4 OAM Type:1 OAM Func:4
00:15:17: CC CELL (ATM0) I:VCD#1 VC 1/40 OAM Cell Type:4 OAM Type:1 OAM Func:4
00:15:18: CC CELL (ATM0) O:VCD#1 VC 1/40 OAM Cell Type:4 OAM Type:1 OAM Func:4
00:15:19: CC CELL (ATM0) I:VCD#1 VC 1/40 OAM Cell Type:4 OAM Type:1 OAM Func:4
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
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.
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.
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
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.
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.
PA debugging is on
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
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
SFP debugging is on
The second example gives the output when the module is inserted in the SFP port.
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: Command Sent:
*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: Command Indication:
*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
*Jun 27 22:15:09.284: ACK received = 200 usecs
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
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.
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
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.
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.
PA debugging is on
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
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
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
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
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:%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:
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
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.339 IST: AUM: get image info: failed to open url
Jun 14 14:23:08.339 IST: AUM: get image info: image size unknown
debug auto-config
To enable debugging for autoconfiguration applications, use the debug auto-config command in
privileged EXEC mode. To disable debugging output, use the no form of this command.
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
.
.
.
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.
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.
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
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
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
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
debug backup
To monitor the transitions of an interface going down then back up, use the debug backup command in
privileged EXEC mode. To disable debugging output, use the no form of this command.
debug backup
no debug backup
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
debug bert
To display information on the bit error rate testing (BERT) feature, use the debug bert command in
privileged EXEC mode. To disable debugging output, use the no form of this command.
debug bert
no debug bert
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.
debug bfd
To display debugging messages about Bidirectional Forwarding Detection (BFD), use the debug bfd
command in privileged EXEC mode. To disable debugging output, use the no form of this command.
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.
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
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
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
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.
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.
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.
Command Default Debugging for IPv6 BGP dampening packets is not enabled.
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.
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
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
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.
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 {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]
Command Default Debugging for IPv6 BGP update packets is not enabled.
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.
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. 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
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
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.
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.
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.
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.
Note By default, the network server sends the output from debug commands and system error messages to the
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
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:
20:07:19: BGP(4): charge penalty for 49.0404 path 65202 65404 with halflife-time 15
reuse/suppress 750/2000
20:07:19: BGP(4): flapped 1 times since 00:00:00. New penalty is 1000
20:08:59: BGP(4): charge penalty for 49.0404 path 65202 65404 with halflife-time 15
reuse/suppress 750/2000
20:08:59: BGP(4): flapped 2 times since 00:01:39. New penalty is 1928
20:10:04: BGP(4): charge penalty for 49.0404 path 65202 65404 with halflife-time 15
reuse/suppress 750/2000
20:10:04: BGP(4): flapped 3 times since 00:02:44. New penalty is 2839
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
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.
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.
Note By default, the network server sends the output from debug commands and system error messages to the
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 updates command:
Router# debug bgp nsap updates
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.
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.
Note By default, the network server sends the output from debug commands and system error messages to the
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 command. The BGP(4) identifies that BGP
version 4 is operational.
Router# debug bgp nsap
Usage Guidelines Use the debug bgp vpnv6 unicast command to help troubleshoot the BGP VPN.
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. 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
debug bri-interface
To display debugging information on ISDN BRI routing activity, use the debug bri-interface command
in privileged EXEC mode. To disable debugging output, use the no form of this 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
The following line indicates that an internal command was written to the interface controller. The subunit
identifies the first interface in the slot.
BRI: write_sid: wrote 1B for subunit 0, slot 1.
The following line indicates that the power-up timer was started for the named unit:
BRI: Starting Power Up timer for unit = 0.
The following lines indicate that the channel or the protocol on the interface changed state:
%LINK-3-UPDOWN: Interface BRI0: B-Channel 1, changed state to up
%LINK-5-CHANGED: Interface BRI0: B-Channel 1, changed state to up.!!!
%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0: B-Channel 1, changed state to down
Lines of output not described are for use by support staff only.
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
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
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
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
Examples The following is sample output from the debug bstun packet command:
Router# debug bstun packet
Usage Guidelines Use this command to enable the display of error information for a bundle, such as reports of inconsistent
mapping in the bundle.
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.
Defaults Disabled
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
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
Defaults Disabled
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
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
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
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
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.
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.
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: RESV CONFIRM message received from 10.19.101.116 for RESV setup from
10.19.101.117
00:03:25: RESERVATIONS ESTABLISHED : CallId: 1Stop timer and notify Session Protocol of
Success (ie. if notification requested)
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:remoteip:10.10.101.117 :remoteport:0
00:03:41: Parameters:localip:10.10.101.116
00:03:41: remoteip:10.10.101.117
Syntax Description module The module argument can be one of the following:
coreTraces the resource information.
detailTraces for detail information.
Defaults Disabled
Examples The following is sample output from the debug call threshold core command:
The following is sample output from the debug call threshold detail command:
Defaults Disabled
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
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
no form of this command.
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
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
output, use the no form of this command.
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
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),
call type CPM_ISDN_ANALOG:
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
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.
call type CPM_ISDN_ANALOG:
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
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.
no debug capf-server
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
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
command in privileged EXEC mode. To disable debugging output, use the no form of this command.
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
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#
CAS debugging is on
The following example shows output for the first outgoing call:
Router# p 1.1.1.2
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
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
*Mar 2 00:18:29.617: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async94, changed
state to down
et2-c3745-1#
*Mar 2 00:18:33.617: %LINK-3-UPDOWN: Interface Async94, changed state to down
Router#
*Mar 2 00:19:08.841: %LINK-3-UPDOWN: Interface Async93, changed state to up
*Mar 2 00:19:08.841: %DIALER-6-BIND: Interface As93 bound to profile Di1
*Mar 2 00:19:10.033: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async93, changed
state to up
Router# p 1.1.1.2
Defaults Debugging for ATM Adaptation Layer type 2 (AAL2) sessions is not enabled.
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
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
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)#
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
*Mar 6 18:04:11.221:ccfrf11_evhandle_call_connect:Entered
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
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
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).
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
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.
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.
Defaults Disabled
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.
Examples The following is sample output from the debug cch323 h225 command:
Router# debug cch323 h225
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.
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:
Router# debug cch323 h245
H245_OLC_NONE
20:58:23:changing from H245_OLC_NONE state to H245_OLC_WAIT state
20:58:23:cch323_h245_receiver:received msg of type
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
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.
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.
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
Usage Guidelines Use this command to enable a debugging trace for the video component in an H.323 network.
debug cch323
To provide debugging output for various components within the H.323 subsystem, use the debug cch323
command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug cch323 {all | error | h225 | h245 | nxe | ras | rawmsg | session}
no 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:
Caution Using the debug cch323 all command could slow your system and flood the TTY if there is significant
call traffic.
Note There is little or no output from this command when there is a stable H.323 network.
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
message to the peer.
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
message to the peer.
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.
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).
CCH323_RAS_EVENT_TIMEOUTMessage timeout.
Caution Using the debug cch323 command with the rawmsg keyword could slow your system and flood the TTY
if there is significant call traffic.
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.
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.
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.
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.
H245_MS_DONE The result is in.
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.
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.
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.
00:33:49:cch323_call_setup:gw_id=1, callID=16
00:33:49:timer(0x81D130D4) stops
00:33:49:timer (0x81D130D4)starts - delay (180000)
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:cch323_ct_main:SOCK 1 Event 0x1
00:33:50: [1]towner_data=0x81D13C88, len=71, msgPtr=0x81F1F2E0
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:cch323_h225_setup_ind
00:23:27:Not using Voice Class Codec
00:23:27:cch323_build_fastStart_cap_response:Retrieved qosCapability of 0
debug ccm-manager
To display debugging information about Cisco CallManager, use the debug ccm-manager command in
privileged EXEC mode. To disable debugging output, use the no form of this command.
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.
Release Modification
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.
12.2(11)T This command was integrated into Cisco IOS Release 12.2(11)T and
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.
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 is sample output from the debug ccm-manager events command:
Router# debug ccm-manager events
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
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 = 400
00:09:07: cmapp_process_tag_oftf: frequency 1 off time = 200
00:09:07: cmapp_process_tag_onts: frequency 2 on time = 400
00:09:07: cmapp_process_tag_ofts: frequency 2 off time = 2000
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_fof3: frequency 1 cadence 3 = 0
00:09:07: cmapp_process_tag_fos3: frequency 2 cadence 3 = 0
00:09:07: cmapp_process_tag_fof4: frequency 1 cadence 4 = 0
00:09:07: cmapp_process_tag_fos4: frequency 2 cadence 4 = 0
00:09:07: cmapp_process_tag_rct1: cadence 1 repeat count = 0
00:09:07: cmapp_process_tag_rct2: cadence 2 repeat count = 0
00:09:07: cmapp_process_tag_rct3: cadence 3 repeat count = 0
00:09:07: cmapp_process_tag_rct4: cadence 4 repeat count = 0
00:09:07:
cmapp_prefix_process_tag_dualtone: TID=[2:CPTONE_CONGESTION]
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 = -200
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 = 400
00:09:07: cmapp_process_tag_oftf: frequency 1 off time = 350
00:09:07: cmapp_process_tag_onts: frequency 2 on time = 225
00:09:07: cmapp_process_tag_ofts: frequency 2 off time = 525
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_fof3: frequency 1 cadence 3 = 0
00:09:07: cmapp_process_tag_fos3: frequency 2 cadence 3 = 0
00:09:07: cmapp_process_tag_fof4: frequency 1 cadence 4 = 0
00:09:07: cmapp_process_tag_fos4: frequency 2 cadence 4 = 0
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
*Jan 9 07:29:14.499: cmapp_xml_tftp_download_file: Unable to read file
tftp:///Router.cisco.com.cnf.xml, rc=-2
*Jan 9 07:29:14.499: cmapp_xml_get_xml_file: Could not read file
tftp:///Router.cisco.com.cnf.xml, len = 0
*Jan 9 07:29:14.499: cmapp_xml_tftp_download_file: Unable to read file
tftp:///Router.cisco.com.cnf.xml, rc=-2
*Jan 9 07:29:14.499: cmapp_xml_get_xml_file: Could not read file
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
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: Endpoint has been set to 1
*Jan 9 09:44:45.579: cmapp_sccp_gw_start_element_handler: Endpoint has been set to 2
*Jan 9 09:44:45.579: cmapp_sccp_gw_start_element_handler: Endpoint has been set to 3
*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: Endpoint has been set to 0
*Jan 9 09:44:45.579: cmapp_sccp_gw_start_element_handler: Endpoint has been set to 1
*Jan 9 09:44:45.579: cmapp_sccp_gw_start_element_handler: Unit has been set to 2
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.
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
Examples The following example displays debug output from one side of the call:
Router# debug ccsip all
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
v=0
o=CiscoSystemsSIP-GW-UserAgent 969 7889 IN IP4 166.34.245.231
s=SIP Call
t=0 0
c=IN IP4 166.34.245.231
m=audio 20038 RTP/AVP 0
v=0
o=CiscoSystemsSIP-GW-UserAgent 969 7889 IN IP4 166.34.245.231
s=SIP Call
t=0 0
c=IN IP4 166.34.245.231
m=audio 20038 RTP/AVP 0
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:50:
*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
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
Call-ID: ABBAE7AF-823100CE-0-1CCAA69C@172.18.192.194
Timestamp: 731427042
Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled
CSeq: 101 INVITE
Content-Length: 0
v=0
o=CiscoSystemsSIP-GW-UserAgent 969 7889 IN IP4 166.34.245.231
s=SIP Call
t=0 0
c=IN IP4 166.34.245.231
m=audio 20038 RTP/AVP 0
v=0
o=CiscoSystemsSIP-GW-UserAgent 969 7889 IN IP4 166.34.245.231
s=SIP Call
t=0 0
c=IN IP4 166.34.245.231
m=audio 20038 RTP/AVP 0
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 8 17:36:47:
*Mar 8 17:36:47: udpsock_close_connect: Socket fd: 1 closed for connid 1 with remote
port: 5060
Usage Guidelines This command traces the SIP call details as they are updated in the SIP call control block.
Examples The following example displays debug output from one side of the call:
Router1# debug ccsip calls
*Mar 6 14:12:40:
The following example displays debug output from the other side of the call:
Router2# debug ccsip calls
*Mar 8 17:38:38:
Usage Guidelines This command traces all error messages generated from errors encountered by the SIP subsystem.
Examples The following example displays debug output from one side of the call:
Router1# debug ccsip error
*Mar 6 14:16:49: udpsock_close_connect: Socket fd: 1 closed for connid 1 with remote
port: 5060
The following example displays debug output from the other side of the call:
Router2# debug ccsip error
*Mar 8 17:42:47: udpsock_close_connect: Socket fd: 1 closed for connid 1 with remote
port: 5060
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.
Examples The following is sample output from the debug ccsip events command for a Cisco 3660:
Router# debug ccsip events
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
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
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
To: <sip:3660210@166.34.245.231;user=phone;phone-context=unknown>
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
User-Agent: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled
CSeq: 101 INVITE
Max-Forwards: 6
Timestamp: 731427554
Contact: <sip:3660110@166.34.245.230:5060;user=phone>
Expires: 180
Content-Type: application/sdp
Content-Length: 138
v=0
o=CiscoSystemsSIP-GW-UserAgent 5596 7982 IN IP4 166.34.245.230
s=SIP Call
t=0 0
c=IN IP4 166.34.245.230
m=audio 20762 RTP/AVP 0
v=0
o=CiscoSystemsSIP-GW-UserAgent 1193 7927 IN IP4 166.34.245.231
s=SIP Call
t=0 0
c=IN IP4 166.34.245.231
m=audio 20224 RTP/AVP 0
Content-Length: 138
v=0
o=CiscoSystemsSIP-GW-UserAgent 1193 7927 IN IP4 166.34.245.231
s=SIP Call
t=0 0
c=IN IP4 166.34.245.231
m=audio 20224 RTP/AVP 0
v=0
o=CiscoSystemsSIP-GW-UserAgent 5596 7982 IN IP4 166.34.245.230
s=SIP Call
t=0 0
c=IN IP4 166.34.245.230
m=audio 20762 RTP/AVP 0
The following example show debug output from the other side of the call:
Router2# debug ccsip messages
v=0
o=CiscoSystemsSIP-GW-UserAgent 5596 7982 IN IP4 166.34.245.230
s=SIP Call
t=0 0
c=IN IP4 166.34.245.230
m=audio 20762 RTP/AVP 0
v=0
o=CiscoSystemsSIP-GW-UserAgent 1193 7927 IN IP4 166.34.245.231
s=SIP Call
t=0 0
c=IN IP4 166.34.245.231
m=audio 20224 RTP/AVP 0
v=0
o=CiscoSystemsSIP-GW-UserAgent 1193 7927 IN IP4 166.34.245.231
s=SIP Call
t=0 0
c=IN IP4 166.34.245.231
m=audio 20224 RTP/AVP 0
v=0
o=CiscoSystemsSIP-GW-UserAgent 5596 7982 IN IP4 166.34.245.230
s=SIP Call
t=0 0
c=IN IP4 166.34.245.230
m=audio 20762 RTP/AVP 0
Examples The following example shows debug output for a single SIP call:
Router# debug ccsip preauth
Jan 23 18:43:17.902:sipSPIGetNodeForPreauth:Preauth_id=86515
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.
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
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
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.
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.
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.
3640_vofr(config-voiceport)#
*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
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:
3640_vofr(config-voiceport)#
*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
3640_vofr(config-voiceport)#
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 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.
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.
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
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.339:CDAPI:cdapi_crea
router#te_msg():CDAPI Pool Count:959, Raw Length = 0
Sep 26 19:12:25.339:CDAPI:cdapi_free_msg():Raw Length = 0, freeRaw = 1, Raw Msg = 0x0
Sep 26 19:12:25.339:CDAPI:cdapi_free_msg():CDAPI Pool Count:960
router#
Sep 26 19:12:33.223:MGCP Packet received from 10.0.44.109:2427-
DLCX 6319 s7/ds1-0/24 MGCP 1.0
The following partial example shows V.120 call debugging output for the debug cdapi detail command:
Router# debug cdapi detail
X:101
The following MGCP packet received example shows V.120 call debugging output for the debug cdapi
events command:
Router# debug cdapi events
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.
Defaults If the command is entered without any optional keywords, all of the types of debug information are
enabled.
Examples The following is sample output from the debug cdma pdsn a10 ahdlc command:
Router# debug cdma pdsn a10 ahdlc errors
debug cdma pdsn a10 gre [errors | events | packets] [tunnel-key key]
Defaults If the command is entered without any optional keywords, all of the types of debug information are
enabled.
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
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
*Mar 1 04:00:59.863:CDMA-GRE:(in) found session 5.0.0.2-4.0.0.1-1
*Mar 1 04:00:59.863:CDMA-GRE:(in) found session 5.0.0.2-4.0.0.1-1
*Mar 1 04:01:01.879:CDMA-GRE:(in) found session 5.0.0.2-4.0.0.1-1
*Mar 1 04:01:01.879:CDMA-GRE:(in) found session 5.0.0.2-4.0.0.1-1
Defaults If the command is entered without any optional keywords, all of the types of debug information are
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
Defaults If the command is entered without any optional keywords, all of the types of debug information are
enabled.
Examples The following is sample output from the debug cdma pdsn a11 commands:
Router# debug cdma pdsn a11 errors
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:CDMA-RP:extension type=38, len=0
*Mar 1 03:15:32.511:CDMA-RP:extension type=38, len=0
*Mar 1 03:15:32.511:CDMA-RP:extension type=32, len=20
*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#
*Mar 1 03:15:54.755:CDMA-RP:len=8, 01-00-00-00-00-00-00-10 convert to 000000000000001 (15
digits), type=IMSI
*Mar 1 03:15:54.755:CDMA-RP:extension type=38, len=0
*Mar 1 03:15:54.755:CDMA-RP:extension type=32, len=20
*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:CDMA-RP:(req) process_rp_req, homeagent=5.0.0.2 coaddr=4.0.0.1
*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
*Mar 1 03:15:54.755:CDMA-RP:(out) rp_reply session=5.0.0.2-4.0.0.1-1, lifetime=0
*Mar 1 03:15:54.755:CDMA-RP:(out) Setup RP out message, ha=5.0.0.2 coa=4.0.0.1 key=1
CDMA:
CDMA PDSN A11 events debugging is on for mnid 000000000000001
Router#
*Mar 1 03:09:34.339:CDMA-RP:len=8, 01-00-00-00-00-00-00-10 convert to 000000000000001 (15
digits), type=IMSI
*Mar 1 03:09:34.339:CDMA-RP:(req) process_rp_req, homeagent=5.0.0.2 coaddr=4.0.0.1
*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:34.339:CDMA-RP:(out) rp_reply session=5.0.0.2-4.0.0.1-1, lifetime=1800
*Mar 1 03:09:34.339:CDMA-RP:(out) Setup RP out message, ha=5.0.0.2 coa=4.0.0.1 key=1
Router#
CDMA:
CDMA PDSN A11 packet debugging is on for mnid 000000000000001
Router#
*Mar 1 03:13:37.803:CDMA-RP:extension type=38, len=0
*Mar 1 03:13:37.803:CDMA-RP:extension type=38, len=0
*Mar 1 03:13:37.803:CDMA-RP:extension type=38, len=0
*Mar 1 03:13:37.803:CDMA-RP:extension type=32, len=20
*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
Examples The following is sample output from the debug cdma pdsn accounting flow command:
Examples The following is sample output from the debug cdma pdsn accounting time-of-day command:
Router# debug cdma pdsn accounting time-of-day
Examples The following is sample output from the debug cdma pdsn accounting command:
Router# debug cdma pdsn accounting
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 ?
Usage Guidelines The following example illustrates the debug cdma pdsn ipv6 command:
Router# debug cdma pdsn ipv6
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
Syntax Description errors Displays Packet Data Service node (PDSN) resource manager errors.
events Displays PDSN resource manager events.
Examples The following is sample output from the debug cdma pds resource-manager command:
Router# debug cdma pdsn resource-manager
Examples The following is sample output from the debug cdma pdsn selection command with the keyword events
specified:
Router# debug cdma pdsn selection events
Examples The following is sample output from the debug cdma pdsn service-selection command:
Router# debug cdma pdsn service-selection
Defaults If the command is entered without any optional keywords, all of the types of debug information are
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
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
debugging output, use the no form of this command.
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
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
debug cdp
To enable debugging of the Cisco Discovery Protocol (CDP), use the debug cdp command in privileged
EXEC mode. To disable debugging output, use the no form of this command.
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
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
no form of this command.
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.
Defaults Debugging information about Cisco Express Forwarding events is not displayed.
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. 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
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.
Syntax Description slot/wic_slot/port Numeric values that indicate the router slot, WAN interface card (WIC) slot,
and port.
Syntax Description slot/wic_slot/port Numeric values that indicate the router slot, WAN interface card (WIC) slot,
and port.
Syntax Description slot/wic_slot/port Numeric values that indicate the router slot, WAN interface card (WIC) slot,
and port.
Syntax Description slot/wic_slot/port Numeric values that indicate the router slot, WAN interface card (WIC) slot,
and port.
Syntax Description slot/wic_slot/port Numeric values that indicate the router slot, WAN interface card (WIC) slot,
and port.
Syntax Description slot/wic_slot/port Numeric values that indicate the router slot, WAN interface card (WIC) slot,
and port.
Syntax Description slot/wic_slot/port Numeric values that indicate the router slot, WAN interface card (WIC) slot,
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 Description
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.
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
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 ces-conn
To display information from circuit emulation service (CES) clients, use the debug ces-conn command
in privileged EXEC mode. To disable debugging output, use the no form of this command.
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.
Examples The following example shows debug output for a CES connection:
Router# debug ces-conn all
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>
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
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
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
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
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)
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
The following line indicates that data was received on the CIP:
Channel3/1: love letter received, bytes 3308
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
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)-in size = 48, vc = 0000, type = 0800, src 172.24.1.58, dst 172.24.15.197
(Channel3/0)-out size = 71, vc = 0000, type = 0800, src 172.24.15.197, dst 172.24.1.58
(Channel3/0)-in size = 44, vc = 0000, type = 0800, src 172.24.1.58, dst 172.24.15.197
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.
Examples The following is sample output from the debug clns esis events command:
Router# debug clns esis events
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
Examples The following is sample output from the debug clns esis packets command:
Router# debug clns esis packets
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.
ES-IS: ISH sent to All ESs (Ethernet0): NET
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
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.
ES-IS: ISH sent to All ESs (Ethernet1): NET
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
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.
ES-IS: ISH sent to All ESs (Tunnel0): NET
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 34
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
Examples The following is sample output from the debug clns events command:
Router# debug clns events
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.
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)
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
Examples The following is sample output from the debug clns igrp packets command:
Router# debug clns igrp packets
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: Originating level 1 periodic update
ISO-IGRP: Advertise dest: 2222.2222.2222
ISO-IGRP: Sending update on interface: Ethernet3
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: Originating level 2 periodic update
ISO-IGRP: Advertise dest: 0001
ISO-IGRP: Sending update on interface: Ethernet3
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.
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
Examples The following is sample output from the debug clns packet command:
Router# debug clns packet
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.
CLNS: Forwarding packet size 157
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)
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
via 1600.8906.4017 (Ethernet0 0000.0c00.bda8)
Examples The following is sample output from the debug clns routing command:
Router# debug clns routing
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
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
(FRAS Daemon:CLS-->DLU):
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
(FRAS Daemon:CLS-->DLU):
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.
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)
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)
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)
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)
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)
VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_XID_RSP_PENDING->VDLC_OPEN
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)
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
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.
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
Syntax Description agent Displays debugging messages related to the event agent.
all Displays all debugging messages.
connection Displays debugging messages related to event connections.
subscriber Displays debugging messages related to subscribers.
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
Syntax Description agent Displays debugging messages related to the exec agent.
all Displays all debugging messages.
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
Syntax Description agent Displays debugging messages related to the image agent.
all Displays all debugging messages.
connection Displays debugging messages related to image agent connections.
error Displays debugging messages related to errors generated by image agent
services.
Usage Guidelines Use the debug cns image command to troubleshoot CNS image agent services.
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
Examples In the following example, debugging messages for the CNS XML parser are enabled:
Router# debug cns xml parser
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
debugging output, use the no form of this command.
Examples In the following example, debugging messages for the CNS XML parser are enabled:
Router# debug cns xml-parser
debug compress
To debug compression, enter the debug compress command in privileged EXEC mode. To disable
debugging output, use the no form of this command.
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
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.
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.
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.
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
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 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.
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
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# configure terminal
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
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.
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
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
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.
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
HSRP debugging is on
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
00:27:42: HSRP: Et0/0 Grp 23 Hello out 10.0.0.1 Active pri 100 vIP 172.16.6.5
00:27:45: HSRP: Et0/0 Grp 23 Hello out 10.0.0.1 Active pri 100 vIP 172.16.6.5
00:27:48: HSRP: Et0/0 Grp 23 Hello out 10.0.0.1 Active pri 100 vIP 172.16.6.5
00:27:51: HSRP: Et0/0 Grp 23 Hello out 10.0.0.1 Active pri 100 vIP 172.16.6.5
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
Condition 2 set
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.
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
The following example sets filter conditions that allow related debug commands to display debug
messages for only the xconnect segment pair specified by the port mode ATM interface number:
debug condition xconnect interface atm 0/0
The following example sets filter conditions that allow related debug commands to display debug
messages for only the xconnect segment pair specified by the VP mode ATM interface number:
debug condition xconnect interface atm 0/0 vp 1
The following example sets filter conditions that allow related debug commands to display debug
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
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.
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
form of this command.
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}
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.
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)
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
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
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
Session2 VTY (User from session2 is trying to enter single user config (exclusive) config
mode)
=================================
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#
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,
use the no form of this command.
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
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
debugging output, use the no form of this command.
debug conn
no debug conn
Router(config-tdm-conn)# exit
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)#
debug control-plane
To display debugging output from the control-plane routines, use the debug control plane command in
privileged EXEC mode. To disable debugging output, use the no form of this command.
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.
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
Field Description
dport UPD destination port.
sport UPD source port.
saddr Source address of the IP packets.
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
output, use the no form of this command.
Syntax Description detail (Optional) Displays additional debug information, including the contents of
COPS and Resource Reservation Protocol (RSVP) messages.
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# configure terminal
Router(config)#
15:13:45:COPS: Opened TCP connection to 2.0.0.1/3288
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:** SENDING MESSAGE **
15:14:00:COPS REQ message, Client-type:1, Length:148. Handle:[ 00 00 05 01]
15:14:00:COPS:** RECEIVED MESSAGE **
15:14:00:COPS DEC message, Client-type:1, Length:64. Handle:[ 00 00 05 01]
15:14:00:COPS:** SENDING MESSAGE **
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:** SENDING MESSAGE **
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:** SENDING MESSAGE **
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
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 debugging is on
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 cot
To display information about the Continuity Test (COT) functionality, use the debug cot command in
privileged EXEC mode. To disable debugging output, use the no form of this command.
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:
Field Description
CDB Internal controller information.
req Type of COT operation requested.
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#
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
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
00:11:27:In cot_callback
00:11:27: returned key 0xFFF1, status = 0
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):
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.
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.
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.
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.
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).
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.
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 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
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.
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.
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 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
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
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.
debug crm
To troubleshoot the Carrier Resource Manager (CRM), use the debug crm command in privileged EXEC
mode. To disable debugging output, use the no form of this command.
debug crm [all | default | detail | error [call [informational] | software [informational]] |
function | inout]
no debug crm
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.
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
01:21:23: //-1/xxxxxxxxxxxx/CRM/crm_call_update:
IncomingVoiceCalls=1
Router#
01:21:48: //-1/xxxxxxxxxxxx/CRM/crm_send_periodic_update:
01:21:48: //-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:22:13: //-1/xxxxxxxxxxxx/CRM/crm_send_periodic_update:
01:22:13: //-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
Router#
01:22:18: //-1/xxxxxxxxxxxx/CRM/crm_call_update:
Decrement the call count
CarrierID=2023, TrunkGroupLabel=2023
Update is for TrunkGroupLabel, Mask=0x00000001
01:22:18: //-1/xxxxxxxxxxxx/CRM/crm_call_update:
IncomingVoiceCalls=0
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.
Examples The following example enables IPSec VPN SPA debugging for a Blade Failure Group:
Router# debug crypto ace b2b
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.
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
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.
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.
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.
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.
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 peer ipv4 10.1.1.2
Router# debug crypto condition peer ipv4 10.1.1.3
Router# debug crypto condition unmatched
! Verify crypto conditional settings.
Router# show crypto debug-condition
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
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
Defaults The logging of commands sent from the VPN module driver to the VPN module hardware is disabled.
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
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.
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.
Router# debug crypto engine
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.
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:
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]
Usage Guidelines Using this command displays various GDOI debugs. For debugging information for cooperative key
servers, use the debug crypto gdoi ks coop command.
Examples The following example shows group member registration debug output:
Router# debug crypto gdoi
enc(config-if)#
00:00:40: GDOI:(0:0:N/A:0):Registration installed 2 new ipsec SA(s) for group diffint.
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:
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
*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
.
.
.
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
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: Current State: SS_OPEN
3d17h: EZVPN: Event: SOCKET_READY
3d17h: EZVPN: No state change
3d17h: EZVPN: Current State: SS_OPEN
3d17h: EZVPN: Event: MTU_CHANGED
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
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
Standby Router
Router# debug crypto ipsec ha
The following example is sample debug output with the detail keyword:
Active Router
Standby Router
Router# debug crypto ipsec ha detail
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
Standby Router
*Sep 29 17:27:28.887:IPSec HA(crypto_ha_ipsec_mgr_recv_update_sa):called
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): ,
(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= AH, transform= ah-sha-hmac ,
lifedur= 120s and 4608000kb,
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
00:24:34: IPSEC(spi_response): getting spi 525075940ld for SA
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),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4
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).
00:24:35: IPSEC(key_engine): got a queue event...
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): ,
(key eng. msg.) dest= 172.21.114.123, src= 172.21.114.67,
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),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 120s and 4608000 kb,
spi= 0x120F043C(302974012), conn_id= 29, keysize= 0, flags= 0x4
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,
(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),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4
IKE does the remaining processing, completing the negotiation and generating keys. It then tells IPSec
about the new SAs.
00:26:15: IPSEC(key_engine): got a queue event...
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
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
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.~.......
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
*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
Standby Router
Router# debug crypto isakmp ha detail
*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
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
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
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): processing ID payload. message ID = 767162845
20:26:59: ISAKMP (8): processing ID 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
Update Example
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
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.
Examples The following example shows IPsec MIB debug message notification being enabled:
Router# debug crypto mib
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
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
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
.
.
.
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
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
.....
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
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
Password:
Re-enter password:
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
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!
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
Syntax Description slot | dspm | dsp | dsp-channel (Optional) Identifies the location of a particular digital signal
processor (DSP) channel.
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
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.
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.
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.
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.
vtsp_cdbContains the address of the VTSP call control block.
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:
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)
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:
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:
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:
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
bchan=0x1E, event=0x4, cause=0x0
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.
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 !!>
Field Description
call_type Type of call: VOICE or MODEM.
dir Direction of the call: INCOMING or OUTGOING.
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
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.
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)
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.
vtsp_cdbContains the address of the VTSP call control 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.
vtsp_cdbContains the address of the VTSP call control block.
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:
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)
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:
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:
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
bchan=0x1E, event=0x3, cause=0x0
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.
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
bchan=0x1E, event=0x4, cause=0x0
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.
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
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
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
the no form of this command.
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
debug custom-queue
To enable custom queueing output, use the debug custom-queue command in privileged EXEC mode.
To disable debugging output, use the no form of this command.
debug custom-queue
no debug custom-queue
debug dampening
To display debug trace information messages for interface dampening, use the debug dampening
command in privileged EXEC mode. To disable debugging output, use the no form of this command.
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
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.
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
Usage Guidelines This command displays PSD-related debugging messages for the GGSN.
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 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
Usage Guidelines This command displays PSD-related debugging messages for the GGSN.
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 flows and fewer users. Debugging during these periods reduces the
effect these commands have on other users on the system.
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.
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
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
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
Examples The following is sample output from the debug dbconn drda command:
Router# debug dbconn drda
Command Description
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.
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
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')
Examples The following is sample output from the debug dbconn tcp command:
Router# debug dbconn tcp
Command Description
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.
show debugging Displays the state of each debugging option.
Examples The following is sample output from the debug decnet adj command:
Router# debug decnet adj
The following line indicates that the router is sending hello messages to all routers on this segment,
which in this case is Ethernet 0:
DNET-ADJ: Sending hellos to all routers on interface Ethernet0, blksize 1498
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
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
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
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.
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.
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)
Examples The following is sample output from the debug decnet packet command:
Router# debug decnet packet
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
Examples The following is sample output from the debug decnet routing command:
Router# debug decnet routing
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
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
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
mode. To disable debugging output, use the no form of this command.
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
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
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
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
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
*Oct 2 06:22:24: DHCP: Adding static route to 1.1.1.1 255.255.255.255 via 68.8.8.1
*Oct 2 06:22:24: DHCP: Adding static route to 67.2.2.2 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.
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.
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
dns hostname and FQDN options by a client.
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.
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
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.
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.
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.
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
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.
Router# ping
Protocol [ip]:
Target IP address:1.1.1.3
Repeat count [5]:1
Datagram size [100]:
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
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
debugging output, use the no form of this command.
debug dialpeer
no debug dialpeer
Defaults Disabled
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
00:22:28: Inside dpMatchCore:
00:22:28: destination pattn:5108880101 expanded string:5108880101
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
debug diameter
To display information about the Diameter Protocol, use the debug diameter command in privileged
EXEC mode. To disable debugging output, use the no form of this command.
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:
(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
debug dlsw
To enable debugging of data-link switching plus (DLSw+), use the debug dlsw command in privileged
EXEC mode. To disable debugging output, use the no form of this command.
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.
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 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
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: action_a() attempting to connect peer 172.20.100.1(2065)
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: action_a() attempting to connect peer 172.20.100.1(2065)
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: action_a() attempting to connect peer 172.20.100.1(2065)
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
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
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.
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 received the I frame from the LAN:
Dec 5 10:48:35: DLSW Received-disp : CLSI Msg : DATA.Ind dlen: 4
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: 0800.5a30.7a9b passes local mac excl. filter
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: 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 = 5
23:45:11: CSM: DLXNR_PEND match found.... drop name query
23:45:11: CSM: Freeing clsi message
23:45:12: CSM: core_to_csm CLSI_MSG_PROC - port_id 5EFBB4
23:45:12: CSM: 0800.5a30.7a9b passes local mac excl. filter
23:45:12: CSM: update local cache for mac 0800.5a30.7a9b, port 5EFBB4
23:45:12: CSM: update local cache for name MARIAN , port 5EFBB4
23:45:12: CSM: Received CLS_UDATA_STN from Core
23:45:12: CSM: Received netbios frame type A
23:45:12: CSM: Processing Name Query
23:45:12: CSM: Netbios Name Query: ws_status = 5
23:45:12: CSM: DLXNR_PEND match found.... drop name query
23:45:12: CSM: Freeing clsi message
23:45:12: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB4
23:45:12: CSM: 0800.5a30.7a9b passes local mac excl. filter
23:45:12: CSM: update local cache for mac 0800.5a30.7a9b, port 658AB4
23:45:12: CSM: update local cache for name MARIAN , port 658AB4
The following messages show that the router named MARIAN is added to the network:
23:45:38: CSM: core_to_csm CLSI_MSG_PROC - port_id 5EFBB4
23:45:38: CSM: 0800.5a30.7a9b passes local mac excl. filter
23:45:38: CSM: update local cache for mac 0800.5a30.7a9b, port 5EFBB4
23:45:38: CSM: update local cache for name MARIAN , port 5EFBB4
23:45:38: CSM: Received CLS_UDATA_STN from Core
23:45:38: CSM: Received netbios frame type 8
23:45:38: CSM: Write to peer 0 ok.
23:45:38: CSM: Freeing clsi message
23:45:38: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB4
23:45:38: CSM: 0800.5a30.7a9b passes local mac excl. filter
23:45:38: CSM: update local cache for mac 0800.5a30.7a9b, port 658AB4
23:45:38: CSM: update local cache for name MARIAN , port 658AB4
23:45:38: CSM: Received CLS_UDATA_STN from Core
23:45:38: CSM: Received netbios frame type 8
23:45:38: CSM: Write to peer 0 ok.
23:45:38: CSM: Freeing clsi message
In the next group of messages, an attempt is made to add the router named GINGER on the Ethernet
interface:
0:07:44: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB4
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
0:07:44: CSM: Received CLS_UDATA_STN from Core
0:07:44: CSM: Received netbios frame type 8
0:07:44: CSM: Write to peer 0 ok.
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
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
the no form of this command.
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.
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.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
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: docmsp_process_rcv_data: call id src=15, dst=18
Jan 1 04:58:42.082: offramp_data_process:
Jan 1 04:58:42.102: docmsp_xmit: call id src=15, dst=18
Jan 1 04:58:42.106: docmsp_process_rcv_data: call id src=15, dst=18
Jan 1 04:58:42.106: offramp_data_process:
Jan 1 04:58:42.122: docmsp_xmit: call id src=15, dst=18
Jan 1 04:58:42.126: docmsp_process_rcv_data: call id src=15, dst=18
Jan 1 04:58:42.126: offramp_data_process:
Jan 1 04:58:42.142: docmsp_xmit: call id src=15, dst=18
Jan 1 04:58:42.146: docmsp_xmit: call id src=15, dst=18
To display debugging messages for doc MSP (docMSP) fax-to-doc, use the debug dmsp fax-to-doc
command in privileged EXEC mode. To disable debugging output, use the no form of this command.
Syntax Description tiff-writer (Optional) Displays debug messages that occur while the DocMSP
Component is receiving T4 fax data and producing TIFF packets.
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_bridge(): ramp data dir=OFFRAMP, conf dir=SRC, encode out=2
*Oct 16 08:29:54.487: docmsp_bridge cfid=16, srccid=22, dstcid=17
*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:
debug dmvpn
To debug Dynamic Multipoint VPN (DMVPN) sessions, use the debug dmvpn command in privileged
EXEC mode. To disable debugging output, use the no form of this command.
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.
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.
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:
The following example shows how to disable conditional debugging for a specific tunnel interface,
tunnel1:
Router# no debug dmvpn condition interface tunnel1
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.
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
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
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
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
Examples This example shows how to activate wireless IDS debugging for authentication events:
SOAP-AP# debug dot11 ids eap
Examples This example shows how to debug the MFP detectors on the access point:
ap(config)# debug dot11 ids mfp ap detectors
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.
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 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
Usage Guidelines The undebug dot1x command is the same as the no debug dot1x command.
debug dot1x
To display 802.1X debugging information, use the debug dot1x command in privileged EXEC mode. To
disable debugging output, use the no form of this command.
debug dot1x [all | errors | events | feature | packets | redundancy | registry | state-machine]
no debug dot1x [all | errors | events | feature | packets | redundancy | registry | state-machine]
Examples The following is sample output for the debug dot1x command:
Router# debug dot1x
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 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
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
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.
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 .
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
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
the no form of this command.
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.
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
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.
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).
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 dspfarm
To display digital signal processor (DSP) farm service debugging information, use the debug dspfarm
command in privileged EXEC mode. To disable debugging output, use the no form of this command.
no debug dspfarm
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
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
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
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
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.
Syntax Description name (Optional) The host or physical unit (PU) name designation.
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
Field Description
DSPU Downstream PU debug message.
LS Link station (LS) event triggered the message.
PU PU event triggered the message.
LU LU 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
Syntax Description name (Optional) The host or physical unit (PU) name designation.
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
Field Description
7:23:57 Time stamp.
DSPU Downstream PU debug message.
LS Link station (LS) event triggered the message.
PU A PU event triggered the message.
LU LU 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
Examples The following is sample output from the debug dss ipx event command:
Router# debug dss ipx event
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
debug eap
To display information about Extensible Authentication Protocol (EAP), use the debug eap command
in privileged EXEC mode. To disable debugging output, use the no form of this 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.
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
*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
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
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
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: Find FS for dest 192.168.4.0 255.255.255.0. FD is 2249216, RD is 2249216
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
Examples The following is sample output from the debug eigrp neighbor command:
Router# debug eigrp neighbor static
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)#
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!
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
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.
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
debug eigrp packet [SIAquery | SIAreply | ack | hello | ipxsap | probe | query | reply | request |
retry | stub | terse | update | verbose]
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.
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.
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
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 describes the significant fields shown in the display.
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.
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.
Examples The following is sample output from the debug eigrp transmit command:
Router# debug eigrp transmit
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
the no form of this command.
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.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
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
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.
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.
Examples The following example shows a SkinnyStation alarm message that is sent before the Cisco IP phone
registers:
Router# debug ephone alarm
Syntax Description mac-address mac-address (Optional) Specifies the MAC address of a specific IP phone.
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
Syntax Description mac-address mac-address (Optional) Specifies the MAC address of a Cisco IP phone for
debugging.
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
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.
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
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.
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
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]:KeypadButtonMessage 0
.
.
1d04h: ephone-1[1]:KeypadButtonMessage 0
.
.
1d04h: ephone-1[1]:KeypadButtonMessage 2
.
.
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: ephone-1[1]:SetLineLamp 1 to ON
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
.
.
1d04h: ephone-1[1]:SetLineLamp 3 to ON
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]:SetCallState line 1 DN 1 TsOnHook
.
.
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]:SpeakerPhoneOnHook
1d04h: ephone-1[1]:ONHOOK NO activeline
.
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
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.
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
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.
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
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.
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.
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.
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
Syntax Description mac-address mac-address (Optional) Specifies the MAC address of a Cisco IP phone
for debugging.
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.
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 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
.
.
.
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
.
When extension 1514 answers the call, the following debug output is displayed:
.
.
.
Mar 7 00:57:32.158:SkinnyDnToneLoopback DN 42 state ALERTING to DN 43 state RINGING
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:SetDnCodec Loopback DN 43 codec 4:G711Ulaw64k vad 0 size 160
Mar 7 00:57:32.158:SkinnyUpdateLoopbackState DN 42 state CALL_START calledDn 14
Mar 7 00:57:32.158:Loopback DN 43 state RINGING
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:Loopback DN 43 state RINGING
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:SetDnCodec Loopback DN 42 codec 4:G711Ulaw64k vad 0 size 160
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.162:Loopback DN 42 state CONNECTED
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:Loopback DN 43 state CONNECTED
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
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.
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
Syntax Description mac-address mac-address (Optional) Specifies the MAC address of a Cisco IP phone
for debugging.
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.825: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
Mar 7 00:52:33.825: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
Mar 7 00:52:33.825: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
Mar 7 00:52:33.825: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
Mar 7 00:52:33.825: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
Mar 7 00:52:33.825: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
Mar 7 00:52:33.825: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
Mar 7 00:52:33.825: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
Mar 7 00:52:33.825: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
Mar 7 00:52:33.825: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
Mar 7 00:52:33.825: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
Mar 7 00:52:33.825: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
Mar 7 00:52:33.825: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
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
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.
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
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.
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
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.
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
Command Description
debug ephone statistics Sets statistics debugging for the Cisco IP phone.
show debugging Displays information about the types of debugging that are
enabled for your router.
Syntax Description mac-address mac-address (Optional) Specifies the MAC address of a Cisco IP phone
for debugging.
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.
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]:Signal Level to phone 3408 (-15 dB) peak 3516 (-15 dB)
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.
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.
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
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.
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
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.
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
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.
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
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
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.
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
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.
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
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]: Jane calling
1d06h: ephone-1[1]: Jill
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]: Jane calling
1d06h: ephone-1[1]: Jill
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]:SetCallState line 3 DN 2 TsOnHook
1d06h: ephone-1[1]:SetCallState line 1 DN 1 TsOnHook
1d06h: ephone-1[1]:SpeakerPhoneOnHook
1d06h: ephone-1[1]:ONHOOK
1d06h: ephone-1[1]:SpeakerPhoneOnHook
1d06h: SkinnyReportDnState DN 1 ONHOOK
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.
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
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.
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
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
Syntax Description mac-address mac-address (Optional) Specifies the MAC address of a Cisco IP phone for
debugging.
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
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.
debug errors
To display errors, use the debug errors command in privileged EXEC mode. To disable debugging
output, use the no form of this command.
debug errors
no debug errors
Examples The following is sample output from the debug errors command:
Router# debug errors
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.
debug eswilp
To enable debugging of Ethernet switch network module features, use the debug eswilp command in
privileged EXEC mode. To disable debugging output, use the no form of this command.
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.
Usage Guidelines The undebug eswilp command is the same as the no debug eswilp command.
Examples The following example shows debugging messages for the IGMP snooping services on the Ethernet
switch network module being displayed:
Router# debug eswilp igmp
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]
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
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: 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
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: 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
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
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
10:48:56: CFM-ERR: Lifetime timer fired for level 6, svlan 2 mac aabb.cc00.0300, mpid 21
10:48:57: CFM-ERR: Lifetime timer fired for level 5, svlan 5 mac aabb.cc00.0602, mpid 60
Command Description
debug ethernet cfm events Enables debugging of Ethernet CFM events.
debug ethernet cfm packets Enables debugging of Ethernet CFM mesage packets.
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]
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
Combination of maintenance domain and VLAN
Combination of maintenance level and VLAN
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 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
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]
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
Combination of maintenance domain and VLAN
Combination of maintenance level and VLAN
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 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
debug ethernet lmi {all | errors | events | packets} [interface type number]
no debug ethernet lmi {all | errors | events | packets} [interface type number]
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.
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
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
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.
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.
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
*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
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}
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
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.
all Displays all debugging 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.
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.
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
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.
debug events
To display events, use the debug events command in privileged EXEC mode. To disable debugging
output, use the no form of this command.
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
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:
aip_love_note(4/0): asr=0x201
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.
aip_love_note(4/0): asr=0x4000
The following line of output indicates that the AIP enable function is restarting all permanent virtual
circuits (PVCs) automatically:
The following lines of output indicate that PVC 1 was set up and a successful completion code was
returned:
aip_setup_vc(4/0): vc:1 vpi:1 vci:1
aip_love_note(4/0): asr=0x200
debug fax dmsp [all | default | detail | error [call [informational] | software [informational]] |
event | function | inout]
Syntax Description all (Optional) Displays all fax DMSP debugging messages.
default (Optional) Displays fax DMSP error and inout information. This option also
runs if no keywords are added.
detail (Optional) Displays fax DMSP background messages.
error (Optional) Displays fax DMSP 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.
event (Optional) Displays fax DMSP events.
function (Optional) Displays fax DMSP functions.
inout (Optional) Displays fax DMSP in/out functions.
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),
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.
debug fax fmsp [all | default | detail | error [call [informational] | software [informational]] |
event | function | inout | receive | send]
Syntax Description all (Optional) Displays all fax FMSP debugging messages.
default (Optional) Displays fax FMSP error and inout information. This option also
runs if no keywords are added.
detail (Optional) Displays fax FMSP background messages.
error (Optional) Displays fax FMSP 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.
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.
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:
Field Description
//76/90A52CB88014/FMSP/ The format of this message is
faxmsp_call_setup_request: //callid/GUID/FMSP/function name
CallEntry ID is 76. This indicates a unique call leg.
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.
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.
debug fax foip [all | default | detail | error [call [informational] | software [informational]] |
event | function | inout]
Syntax Description all (Optional) Displays all fax mail debugging messages.
default (Optional) Displays fax mail error and inout information. This option also
runs if no keywords are added.
detail (Optional) Displays fax mail background messages.
error (Optional) Displays fax mail 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.
event (Optional) Displays fax mail events.
function (Optional) Displays fax mail functions.
inout (Optional) Displays fax mail in/out functions.
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
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
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_setup_mspi:
Envelope From=FAX=7771111@cisco.com
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_setup_mspi:
Envelope To=jdoe@server.cisco.com
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_setup_mspi:
RFC822 To Comment=dileung
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_setup_mspi:
Faxmail Subject=hagar-c5300-bw12 subject line here
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_setup_mspi:
Disposition Notification=
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_setup_mspi:
Originator TSI=RFC822 From Comment=
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_setup_mspi:
Auth/Account ID: `0'
2d07h: //35/67E715B7800A/FOIP_ON/lapp_on_setup_mspi:
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
Field Description
//35/67E715B7800A/FOIP_ON/ The format of this message is
lapp_on_call_handoff: //callid/GUID/FOIP_ON/function name:
CallEntry ID is 35. This indicates a unique call leg.
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.
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.
debug fax mmoip aaa [all | default | error [call [informational] | software [informational]] |
inout]
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.
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.
inout (Optional) Displays MMoIP AAA in/out functions.
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
16:22:04: //3/D9242FD08002/MMOIP_AAA_ON/mmoip_aaa_accounting_onramp:
fax_account_id_origin=NONE_ID
16:22:04: //3/D9242FD08002/MMOIP_AAA_ON/mmoip_aaa_accounting_onramp:
fax_msg_id=00012003151904623@Router.cisco.com, Length=39
16:22:04: //3/D9242FD08002/MMOIP_AAA_ON/mmoip_aaa_accounting_onramp:
fax_pages=0
16:22:04: //3/D9242FD08002/MMOIP_AAA_ON/mmoip_aaa_accounting_onramp:
fax_connect_speed=disable bps
16:22:04: //3/D9242FD08002/MMOIP_AAA_ON/mmoip_aaa_accounting_onramp:
fax_mdn_flag=FALSE
16:22:04: //3/D9242FD08002/MMOIP_AAA_ON/mmoip_aaa_accounting_onramp:
fax_auth_status=USER NOT AUTHENTICATED
16:22:04: //3/D9242FD08002/MMOIP_AAA_ON/mmoip_aaa_accounting_onramp:
email_server_address=172.19.140.112
16:22:04: //3/D9242FD08002/MMOIP_AAA_ON/mmoip_aaa_accounting_onramp:
email_server_ack_flag=TRUE
16:22:04: //3/D9242FD08002/MMOIP_AAA_ON/mmoip_aaa_accounting_onramp:
gateway_id=Router.cisco.com
16:22:04: //3/D9242FD08002/MMOIP_AAA_ON/mmoip_aaa_accounting_onramp:
call_type=Fax Receive
16:22:04: //3/D9242FD08002/MMOIP_AAA_ON/mmoip_aaa_accounting_onramp:
abort_cause=10
Field Description
//3/D9242FD08002/ The format of this message is
MMOIP_AAA_ON/ //callid/GUID/module name/function name:
mmoip_aaa_accounting_onramp
CallEntry ID is 3. This indicates a unique call leg.
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.
debug fax mspi [all | default | detail | error [call [informational] | software [informational]] |
event | function | inout]
Syntax Description all (Optional) Displays all fax MSPI debugging messages.
default (Optional) Displays fax MSPI error and inout information. This option also
runs if no keywords are added.
detail (Optional) Displays fax MSPI background messages.
error (Optional) Displays fax MSPI 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.
event (Optional) Displays fax MSPI events.
function (Optional) Displays fax MSPI functions.
inout (Optional) Displays fax MSPI in/out functions.
Examples The following is sample output from the debug fax mspi all command:
Router# debug fax mspi all
Router#
2d07h: %ISDN-6-CONNECT: Interface Serial2:30 is now connected to unknown
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
Field Description
/41/ACF704FA800B/MSPI_ON/mspi_ The format of this message is
call_setup_request: //callid/GUID/module name/function name:
CallEntry ID is 41. This indicates a unique call leg.
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.
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.
debug fax mta [all | default | detail | error [call [informational] | software [informational]] |
event | function | inout]
Syntax Description all (Optional) Displays all fax MTA debugging messages.
default (Optional) Displays fax MTA error and inout information. This option also
runs if no keywords are added.
detail (Optional) Displays fax MTA background messages.
error (Optional) Displays fax MTA 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.
event (Optional) Displays fax MTA events.
function (Optional) Displays fax MTA functions.
inout (Optional) Displays fax MTA in/out functions.
Examples The following is sample output from the debug fax mta all command:
Router# debug fax mta all
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
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_getln:
(C)R: 250-vip2-das.cisco.com Hello [172.19.140.108], pleased to meet you
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_getln:
(C)R: 250-EXPN
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_getln:
(C)R: 250-VERB
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_getln:
(C)R: 250-8BITMIME
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_getln:
(C)R: 250-SIZE
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_getln:
(C)R: 250-DSN
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_getln:
(C)R: 250-ONEX
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_getln:
(C)R: 250-ETRN
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_getln:
(C)R: 250-XUSR
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_getln:
(C)R: 250 HELP
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_writeln:
(C)S: MAIL FROM:<FAX=7771111@cisco.com>
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_write:
return code=0
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_getln:
(C)R: 250 <FAX=7771111@cisco.com>... Sender ok
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_writeln:
(C)S: RCPT TO:<jdoe@server.cisco.com>
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_write:
return code=0
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_getln:
(C)R: 250 <jdoe@server.cisco.com>... Recipient ok
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_write:
return code=0
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_getln:
(C)R: 354 Enter mail, end with "." on a line by itself
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_writeln:
(C)S: Received: by Router.cisco.com for <jdoe@server.cisco.com> (with Cisco NetWorks);
Thu, 05 Jun 2003 23:11:09 +0000
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_write:
return code=0
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_writeln:
(C)S: To: "jdoe" <jdoe@server.cisco.com>
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_write:
return code=0
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_writeln:
(C)S: Message-ID: <00222003231109198@Router.cisco.com>
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_write:
return code=0
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_writeln:
(C)S: Date: Thu, 05 Jun 2003 23:11:09 +0000
2d07h: //-1/CEB9FA0B800E/SMTPC/esmtp_client_engine_write:
return code=0
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.
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.
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
The following command enables debugging for any calls received to a number starting with 555-1212:
Router# debug fax relay t30 called-number 4155551212
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
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.
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.
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.
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
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
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
ATA_read_sector:dev = 0
ATA_data_xfer:1:dev = 0, command = 32, nsecs = 1, sector = 15, cyl_low = 0,
cyl_high = 0, head = 163
ATA_read_sector:dev = 0, retval = 0
ATA_read_sector:dev = 0
ATA_data_xfer:1:dev = 0, command = 32, nsecs = 128, sector = 35, cyl_low = 0,
cyl_high = 0, head = 171
ATA_read_sector:dev = 0, retval = 0
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
DFSLIB_read:reading file.. fd = 0, byte_count = 52
DFSLIB_read:read from.. fd = 0, byte_count = 52, retval = 52
DFSLIB_read:reading file.. fd = 0, byte_count = 40
DFSLIB_read:read from.. fd = 0, byte_count = 40, retval = 40
.
.
.
DFSLIB_read:reading file.. fd = 0, byte_count = 40
DFSLIB_read:read from.. fd = 0, byte_count = 40, retval = 40
DFSLIB_read:reading file.. fd = 0, byte_count = 19539160
ATA_read_sector:dev = 0
ATA_data_xfer:1:dev = 0, command = 32, nsecs = 1, sector = 15, cyl_low = 0,
cyl_high = 0, head = 163
ATA_read_sector:dev = 0, retval = 0
ATA_read_sector:dev = 0
.
.
.
ATA_read_sector:dev = 0
ATA_data_xfer:1:dev = 0, command = 32, nsecs = 19, sector = 1, cyl_low = 38,
cyl_high = 0, head = 169
ATA_read_sector:dev = 0, retval = 0
DFSLIB_read:read from.. fd = 0, byte_count = 19539160, retval = 19539160
Self decompressing the image
:#####################################################################
##########################################################################################
##########
############################################################### [OK]
Router# no debug filesystem disk0
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.
Field Description
head = The head number.
retval = The status of the operation being executed.
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
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.
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
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.
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
Usage Guidelines You must have already enabled traffic monitoring with Flexible NetFlow before you can use the
debug flow record command.
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.
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.
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).
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. 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:
The following is sample output from the debug flow-sampler match command:
Router# debug flow-sampler match
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).
debug fm private-hosts
To enable debug messages for the Private Hosts feature manager, use the debug fm private-hosts
command in privileged EXEC mode.
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.
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.
Examples The following is sample output from the debug fmsp receive command:
Router# debug fmsp receive
To display debugging messages for Fax Media Services Provider (FMSP) send, use the debug fmsp send
command in privileged EXEC mode. To disable debugging output, use the no form of this command.
Examples The following is sample output from the debug fmsp send command:
Router# debug fmsp send
To display debugging messages for off-ramp fax mail, use the debug foip off-ramp command in
privileged EXEC mode. To disable debugging output, use the no form of this command.
Examples The following is sample output from the debug foip off-ramp command:
Router# debug foip off-ramp
To display debugging messages for on-ramp fax mail, use the debug foip on-ramp command in
privileged EXEC mode. To disable debugging output, use the no form of this command.
Examples The following is sample output from the debug foip on-ramp command:
Router# 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
Examples The following sample output is from the debug fpm event command:
Router# debug fpm event
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.
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.
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
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
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.
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)
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
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
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
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface hssi2/0
Router(config-if)# shut
This example shows the messages that are displayed when you enable the core-facing interface on a PE
router:
Router(config-if)# no shut
This example shows the messages that are displayed when you shut the edge-facing interface on a PE
router:
Router(config)# interface pos4/0
Router(config-if)# shut
This example shows the messages that are displayed when you enable the edge-facing interface on a PE
router:
Router(config)# interface pos4/0
Router(config-if)# no shut
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
04:43:20: FRoMPLS [12.12.12.12, 100]: PW pvc_status set ACTIVE
04:43:20: FRoMPLS [12.12.12.12, 100]: Setting pw segment UP
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
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.
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.
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
Serial0/0(i): dlci 109, rx-seq-num 126, exp_seq-num 126, BE bits set, frag_hdr 04 C0 7E
The following is sample output from the debug frame-relay fragment event command:
Router# debug frame-relay fragment event
Frame-relay reassembled packet is greater than MTU size, packet dropped on serial 0/0
dlci 109
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.
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
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# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
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: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.
00:27:08: Serial4/1- Setting up interface for legacy QOS. <--- Indicates that legacy QoS
is being installed on the interface.
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# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface serial4/1
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.
00:29:02: Serial4/1- Setting up interface for legacy QOS. <--- Indicates that legacy QoS
has been installed on the interface.
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
Defaults Disabled
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).
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
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:
Router# debug frame-relay ip tcp header-compression
The following is sample output from the debug frame-relay ip tcp header-compression command
when FRF .20 IPHC and RTP are configured in the IPHC profile:
Router# debug frame-relay ip tcp header-compression
The following is sample output from the debug frame-relay ip tcp header-compression command
when FRF .20 IPHC and ECRTP are configured in the IPHC profile:
Router# debug frame-relay ip tcp header-compression
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.
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.
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.
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
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
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:
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
RT IE 1, length 1, type 1
KA IE 3, length 2, yourseq 140, myseq 207
Serial1(out): clock 20232760, myseq 208, mineseen 207, yourseen 140, line up
RT IE 1, length 1, type 1
KA IE 3, length 2, yourseq 142, myseq 208
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
KA IE 3, length 2, yourseq 146, myseq 210
message PVC IE 0x7, length 0x6, dlci 400, status 0, bw 56000
S2546
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.
Table 101 describes the significant fields shown in the first line of the display.
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).
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.
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.
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
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.
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
Table 105 describes the significant states and events shown in the display.
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:
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.
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
Serial0(o):DLCI 100 type 809B size 104
The following lines describe a Frame Relay packet that went out on two different DLCIs, because two
Frame Relay map entries were found:
Serial0: broadcast search
Serial0(o):DLCI 300 type 809B size 24
Serial0(o):DLCI 400 type 809B size 24
The following lines do not appear. They describe a Frame Relay packet sent to a true broadcast address.
Serial1: broadcast search
Serial1(o):DLCI 400 type 800 size 288
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
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.
Router# debug frame-relay ppp
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.
Router# debug frame-relay ppp
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
Router(config-if)# no shutdown
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.
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
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.
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.
Examples The following is sample output from the debug frame-relay switching command:
Router# debug frame-relay switching interface s2/1 1000 interval 2
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
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
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
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
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
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.
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).
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
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
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
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
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 describes the significant fields shown in the display.
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.
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
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
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.
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.
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
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.
debug ftpserver
To display information about the FTP server process, use the debug ftpserver command in privileged
EXEC mode. To disable debugging output, use the no form of this command.
debug ftpserver
no debug ftpserver
Examples The following is sample output from the debug ftpserver command:
Router# debug ftpserver
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:(REPLY) 550
Mar 3 10:29:14: FTPSRV_DEBUG:Access denied to 'disk0:'
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.
Examples The following example shows how to enable a packet dump of all GUP announcement messages:
Router# debug gatekeeper gup asn1
announcementInterval 30
endpointCapacity 100000
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
gatekeeperIdentifier {"cyclone-gk"}
altGKIdentifier {"tornado-gk"}
totalBandwidth 0
interzoneBandwidth 0
remoteBandwidth 0
u all
All possible debugging has been turned off
Syntax Description events Displays a message whenever a load-balancing message is sent or received.
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#
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
Gatekeeper:
Gatekeeper Server Messages debugging is on
To turn the Gatekeeper server debugging message off, see the following examples:
Router# no debug all
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#
Examples The following is sample output from the debug glbp errors command:
Router# debug glbp errors
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.
Examples The following is sample output from the debug glbp events command when the terse keyword is
specified:
Router# debug glbp events terse
The following is sample output from the debug glbp events command on an active RP displaying an
interface shutdown event:
Router# debug glbp events
The following is sample output from the debug glbp events command on a standby RP
displaying an interface shutdown event:
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.
Examples The following is sample output from the debug glbp events command when the terse keyword is
specified:
Router# debug glbp events terse
The following is sample output from the debug glbp events command on an active RP displaying an
interface shutdown event:
Router# debug glbp events
The following is sample output from the debug glbp events command on a standby RP
displaying an interface shutdown event:
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
Examples The following is sample output from the debug glbp terse command:
Router# debug glbp terse
GLBP:
GLBP Errors debugging is on
GLBP Events debugging is on
(protocol, redundancy, track)
GLBP Packets debugging is on
(Request, Reply)
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.
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
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#
Router#
Jun 2 03:05:07.743: GPRS:1234050000000010:GPRS:DCCA: 3GPP-IMSI : 214350000000000
Jun 2 03:05:07.743: GPRS:1234050000000010:GPRS:DCCA: 3GPP-Charging-Id : 613053181
Jun 2 03:05:07.743: GPRS:1234050000000010:GPRS:DCCA: 3GPP-PDP-Type : 0
PDP deleted
Router#
Jun 2 03:05:28.459: GPRS:1234050000000010:GPRS:DCCA: 3GPP-IMSI : 214350000000000
Jun 2 03:05:28.459: GPRS:1234050000000010:GPRS:DCCA: 3GPP-Charging-Id : 613053181
Jun 2 03:05:28.459: GPRS:1234050000000010:GPRS:DCCA: 3GPP-PDP-Type : 0
Jun 2 03:05:28.459: GPRS:1234050000000010:GPRS:DCCA: 3GPP-CG-Address : 20.1.1.1
Jun 2 03:05:28.459: GPRS:1234050000000010:GPRS:DCCA: 3GPP-QoS-Profile :
99-0911012964FFFF1100FFFF
Jun 2 03:05:28.459: GPRS:1234050000000010:GPRS:DCCA: 3GPP-SGSN-Address : 11.20.1.1
Jun 2 03:05:28.459: GPRS:1234050000000010:GPRS:DCCA: 3GPP-GGSN-Address : 10.20.61.1
Jun 2 03:05:28.459: GPRS:1234050000000010:GPRS:DCCA: 3GPP-IMSI-MCC-MNC : 21435
Jun 2 03:05:28.459: GPRS:1234050000000010:GPRS:DCCA: 3GPP-GGSN-MCC-MNC : 001002
Jun 2 03:05:28.459: GPRS:1234050000000010:GPRS:DCCA: 3GPP-NSAPI : 1
Jun 2 03:05:28.459: GPRS:1234050000000010:GPRS:DCCA: 3GPP-Selection-Mode : 0
Jun 2 03:05:28.459: GPRS:1234050000000010:3GPP-Charging-Char : 0100
Jun 2 03:05:28.463: GPRS:1234050000000010:GPRS DCCA: Stopping Tx timer
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.463: GPRS:1234050000000010:GPRS DCCA: Stopping Tx timer
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#
Usage Guidelines See the following caution before using debug commands:
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 flows and fewer users. Debugging during these periods reduces the
effect these commands have on other users on the system.
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.
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#
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
traffic on the GPRS network is low, so other activity on the system is not adversely affected.
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
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
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
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.
Usage Guidelines This command is useful for system operators and development engineers if problems are encountered
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
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 PDP type on the GGSN. The examples show output while both debug events and
details are enabled on the GGSN.
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:GTP-PPP: pdp_entry 0x62F442A4, recv ppp data pak
3d23h: GPRS:GTP-PPP Vi2: proc_udp_input pak's linktype = 30
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: GPRS:GTP-PPP: pdp_entry 0x62F442A4, recv ppp data pak
3d23h: GPRS:GTP-PPP Vi2: proc_udp_input pak's linktype = 30
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:GTP-PPP: pdp_entry 0x62F442A4, recv ppp data pak
3d23h: GPRS:GTP-PPP Vi2: proc_udp_input pak's linktype = 30
3d23h: GPRS:GTP-PPP: pdp_entry 0x62F442A4, recv ppp data pak
3d23h: GPRS:GTP-PPP Vi2: proc_udp_input pak's linktype = 30
3d23h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to
up
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: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: 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:GTP-PPP: pdp_entry 0x62F442A4, recv ppp data pak
3d23h: GPRS:GTP-PPP Vi2: proc_udp_input pak's linktype = 30
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:
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.
Usage Guidelines This command is useful for system operators and development engineers if problems are encountered
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.
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: PPP-REGEN state counters: pending counter is 1
06:24:02: State[IDLE] counter is 1
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: PPP-REGEN state counters: pending counter is 1
06:24:02: State[IDLE] counter is 0
06:24:02: State[AUTHORIZING] counter is 1
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: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: PPP-REGEN state counters: pending counter is 1
06:24:02: State[IDLE] counter is 0
06:24:02: State[AUTHORIZING] counter is 0
06:24:02: State[VPDN CONNECTING] counter is 1
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: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: PPP-REGEN state counters: pending counter is 1
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 1
06:24:02: State[PPP CONNECTED] counter is 0
06:24:02: State[PPP TERMINATING] counter is 0
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
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: 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 1
06:24:02: State[PPP TERMINATING] counter is 0
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
06:24:03: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state
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: PPP-REGEN state counters: pending counter is 0
06:28:05: State[IDLE] counter is 0
06:28:05: State[AUTHORIZING] counter is 0
06:28:05: State[VPDN CONNECTING] counter is 0
06:28:05: State[PPP NEGOTIATING] counter is 0
06:28:05: State[PPP CONNECTED] counter is 1
06:28:05: State[PPP TERMINATING] counter is 0
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: PPP-REGEN state counters: pending counter is 1
06:28:05: State[IDLE] counter is 0
06:28:05: State[AUTHORIZING] counter is 0
06:28:05: State[VPDN CONNECTING] counter is 0
06:28:05: State[PPP NEGOTIATING] counter is 0
06:28:05: State[PPP CONNECTED] counter is 0
06:28:05: State[PPP TERMINATING] counter is 1
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: PPP-REGEN state counters: pending counter is 1
06:28:05: State[IDLE] counter is 0
06:28:05: State[AUTHORIZING] counter is 0
06:28:05: State[VPDN CONNECTING] counter is 0
06:28:05: State[PPP NEGOTIATING] counter is 0
06:28:05: State[PPP CONNECTED] counter is 0
06:28:05: State[PPP TERMINATING] counter is 1
06:28:05: GPRS:1011111111500001:PPP down
06:28:05: GPRS:1011111111500001:got event [PPP FAILED] in state [PPP TERMINATING]
06:28:05: PPP-REGEN state counters: pending counter is 1
06:28:05: State[IDLE] counter is 1
06:28:05: State[AUTHORIZING] counter is 0
06:28:05: State[VPDN CONNECTING] counter is 0
06:28:05: State[PPP NEGOTIATING] counter is 0
06:28:05: State[PPP CONNECTED] counter is 0
06:28:05: State[PPP TERMINATING] counter is 0
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.
Usage Guidelines This command is useful for system operators and development engineers if problems are encountered
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
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:
Router# debug gprs gtp ppp events
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
Router# debug gprs gtp ppp events
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
*Mar 1 00:04:50.091: %LINK-3-UPDOWN: Interface Virtual-Access4, changed state to down
*Mar 1 00:04:51.083: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access4,
changed state to down
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
*Mar 1 00:05:21.087: PPP-REGEN state counters: pending counter is 1
*Mar 1 00:05:21.087: State[IDLE] counter is 1
*Mar 1 00:05:21.087: State[AUTHORIZING] counter is 0
Example 5
*Mar 1 00:05:52.399: PPP-REGEN state counters: pending counter is 0
*Mar 1 00:05:52.399: State[IDLE] counter is 0
*Mar 1 00:05:52.399: State[AUTHORIZING] counter is 0
*Mar 1 00:05:52.399: State[VPDN CONNECTING] counter is 0
*Mar 1 00:05:52.399: State[PPP NEGOTIATING] counter is 0
*Mar 1 00:05:52.399: State[PPP CONNECTED] counter is 1
*Mar 1 00:05:52.399: State[PPP TERMINATING] counter is 0
*Mar 1 00:05:52.399: GPRS:1111110000000000:PPP regen current state PPP CONNECTED
*Mar 1 00:05:52.399: GPRS:1111110000000000:GTP disconnecting the PPP regen session
*Mar 1 00:05:52.399: GPRS:1111110000000000:Processing Disconnect PPP regen from reqQ
*Mar 1 00:05:52.399: GPRS:1111110000000000:got event [CANCEL REGEN'ED PPP] in state [PPP
CONNECTED]
*Mar 1 00:05:52.399: PPP-REGEN state counters: pending counter is 1
*Mar 1 00:05:52.399: State[IDLE] counter is 0
*Mar 1 00:05:52.399: State[AUTHORIZING] counter is 0
*Mar 1 00:05:52.399: State[VPDN CONNECTING] counter is 0
*Mar 1 00:05:52.399: State[PPP NEGOTIATING] counter is 0
*Mar 1 00:05:52.399: State[PPP CONNECTED] counter is 0
*Mar 1 00:05:52.399: State[PPP TERMINATING] counter is 1
*Mar 1 00:05:52.399: GPRS:1111110000000000:state [PPP CONNECTED->PPP TERMINATING] on
event [CANCEL REGEN'ED PPP]
*Mar 1 00:05:52.399: GPRS:1111110000000000:Cancel request after VPND tunnel is up
*Mar 1 00:05:52.403: GPRS:1111110000000000:PPP down
*Mar 1 00:05:52.403: GPRS:1111110000000000:got event [PPP FAILED] in state [PPP
TERMINATING]
*Mar 1 00:05:52.407: PPP-REGEN state counters: pending counter is 1
*Mar 1 00:05:52.407: State[IDLE] counter is 1
*Mar 1 00:05:52.407: State[AUTHORIZING] counter is 0
*Mar 1 00:05:52.407: State[VPDN CONNECTING] counter is 0
*Mar 1 00:05:52.407: State[PPP NEGOTIATING] counter is 0
*Mar 1 00:05:52.407: State[PPP CONNECTED] counter is 0
*Mar 1 00:05:52.407: State[PPP TERMINATING] counter is 0
*Mar 1 00:05:52.407: GPRS:1111110000000000:state [PPP TERMINATING->IDLE] on event [PPP
FAILED]
*Mar 1 00:05:52.407: GPRS:1111110000000000:PPP failed negotiation
*Mar 1 00:05:52.407: GPRS:1111110000000000:got event [CLEANUP CONTEXT] in state [IDLE]
*Mar 1 00:05:52.407: GPRS:1111110000000000:VPDN to inform PPP regen: DISCONNECTED
*Mar 1 00:05:52.407: GPRS:1111110000000000:got event [VPDN DISCONNECTED] in state [IDLE]
*Mar 1 00:05:52.407: GPRS:1111110000000000:state [IDLE->IDLE] on event [CLEANUP CONTEXT]
*Mar 1 00:05:52.407: GPRS:1111110000000000:Freeing context structure
*Mar 1 00:05:52.407: GPRS:1111110000000000:Session timer stopped
*Mar 1 00:05:52.407: PPP-REGEN state counters: pending counter is 0
*Mar 1 00:05:52.407: State[IDLE] counter is 0
*Mar 1 00:05:52.407: State[AUTHORIZING] counter is 0
*Mar 1 00:05:52.407: State[VPDN CONNECTING] counter is 0
*Mar 1 00:05:52.407: State[PPP NEGOTIATING] counter is 0
*Mar 1 00:05:52.407: State[PPP CONNECTED] counter is 0
*Mar 1 00:05:52.407: State[PPP TERMINATING] counter is 0
*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
*Mar 1 00:05:52.407: %LINK-3-UPDOWN: Interface Virtual-Access5, changed state to down
Usage Guidelines This command is useful for system operators and development engineers if problems are encountered
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
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 related to RADIUS processing on the
GGSN:
Router# debug gprs radius
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
CheckPointed-From-Active Statistics
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: 000086: Jun 1 2006 18:19:00.979 EDT: GTP-SR: Removing element from state-list
Initialized, final count 1
MWAM 10/2: 000087: Jun 1 2006 18:19:00.979 EDT: GTP-SR: adding element in state-list Bulk
Synch Ready, final count 3
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
MWAM 10/2: 000095: Jun 1 2006 18:19:00.987 EDT: %HSRP-6-STATECHANGE:
GigabitEthernet0/0.301 Grp 51 state Standby -> Active
MWAM 10/2: 000096: Jun 1 2006 18:19:00.987 EDT: GTP-SR:
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
MWAM 10/2: 000100: Jun 1 2006 18:19:01.107 EDT: %HSRP-6-STATECHANGE:
GigabitEthernet0/0.1151 Grp 51 state Standby -> Active
MWAM 10/2: 000101: Jun 1 2006 18:19:01.155 EDT: %HSRP-6-STATECHANGE:
GigabitEthernet0/0.250 Grp 51 state Standby -> Active
MWAM 10/2: 000102: Jun 1 2006 18:19:01.295 EDT: %HSRP-6-STATECHANGE:
GigabitEthernet0/0.1101 Grp 51 state Standby -> Active
MWAM 10/2: 000103: Jun 1 2006 18:19:01.355 EDT: %HSRP-6-STATECHANGE:
GigabitEthernet0/0.1251 Grp 51 state Standby -> Active
MWAM 10/2: 000104: Jun 1 2006 18:19:01.451 EDT: %HSRP-6-STATECHANGE:
GigabitEthernet0/0.1201 Grp 51 state Standby -> Active
MWAM 10/2: 000105: Jun 1 2006 18:19:01.459 EDT: %HSRP-6-STATECHANGE:
GigabitEthernet0/0.220 Grp 51 state Standby -> Active
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
MWAM 10/2: 000108: Jun 1 2006 18:20:25.947 EDT: GTP-SR:
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
MWAM 10/2: 000110: Jun 1 2006 18:20:25.947 EDT: GTP-SR:
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
MWAM 10/2: 000112: Jun 1 2006 18:20:53.899 EDT: GTP-SR:
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
MWAM 10/2: 000114: Jun 1 2006 18:20:53.899 EDT: GTP-SR:
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
CheckPointed-To-Standby Statistics
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
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#show gprs redundancy
GPRS redundancy is enabled and Unit-Status is Active
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
Initialized, final count 2
MWAM 10/2: 000076: Aug 24 2000 23:18:55.963 EDT: GTP-SR: Need to allocate redundancy
context
MWAM 10/2: 000077: Aug 24 2000 23:18:55.963 EDT: GTP-SR: adding element in state-list
Initialized, final count 3
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
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
Initialized, final count 2
MWAM 10/2: 000082: Aug 24 2000 23:18:55.963 EDT: GTP-SR: adding element in state-list
Dynamic Sync Ready, final count 1
MWAM 10/2: 000083: Aug 24 2000 23:18:55.963 EDT: GTP-SR: Need to allocate redundancy
context
MWAM 10/2: 000084: Aug 24 2000 23:18:55.963 EDT: GTP-SR: adding element in state-list
Initialized, final count 3
MWAM 10/2: 000085: 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
MWAM 10/2: 000086: Aug 24 2000 23:18:55.963 EDT: GTP-SR:State of Redundancy Context is
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: 000088: Aug 24 2000 23:18:55.963 EDT: GTP-SR: Removing element from state-list
Initialized, final count 2
MWAM 10/2: 000089: Aug 24 2000 23:18:55.963 EDT: GTP-SR: adding element in state-list
Dynamic Sync Ready, final count 2
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: 000098: Aug 24 2000 23:18:55.963 EDT: GTP-SR: Removing element from state-list
Dynamic Sync Ready, final count 1
MWAM 10/2: 000099: Aug 24 2000 23:18:55.963 EDT: GTP-SR: adding element in state-list
Synched, final count 4
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
MWAM 10/2: 000105: Aug 24 2000 23:18:55.967 EDT: GTP-SR:packing
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: 000107: Aug 24 2000 23:18:55.967 EDT: GTP-SR: Ckpt Message was sucessfully sent
MWAM 10/2: 000108: Aug 24 2000 23:18:55.967 EDT: GTP-SR: Removing element from state-list
Dynamic Sync Ready, final count 0
MWAM 10/2: 000109: Aug 24 2000 23:18:55.967 EDT: GTP-SR: adding element in state-list
Synched, final count 5
MWAM 10/2: 000110: Aug 24 2000 23:18:55.967 EDT: GTP-SR: Empty list to sync
MWAM 10/2: 000111: 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
MWAM 10/2: 000113: Aug 24 2000 23:19:01.583 EDT: GTP-SR: Need to allocate redundancy
context
MWAM 10/2: 000114: Aug 24 2000 23:19:01.583 EDT: GTP-SR: adding element in state-list
Initialized, final count 3
MWAM 10/2: 000115: Aug 24 2000 23:19:01.583 EDT: GTP-SR: Removing element from state-list
Initialized, final count 2
MWAM 10/2: 000116: Aug 24 2000 23:19:01.583 EDT: GTP-SR: adding element in state-list
Synched, final count 6
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
MWAM 10/2: 000120: Aug 24 2000 23:19:01.591 EDT: GTP-SR:State of Redundancy Context is
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: 000122: Aug 24 2000 23:19:01.591 EDT: GTP-SR: Removing element from state-list
Initialized, final count 1
MWAM 10/2: 000123: Aug 24 2000 23:19:01.591 EDT: GTP-SR: adding element in state-list
Dynamic Sync Ready, final count 1
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
MWAM 10/2: 000139: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing
pdpmcb->pdpaddr.static_addr_allocated 0
MWAM 10/2: 000140: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing
pdpmcb->pdpaddr.dynamic_addr_allocated 1
MWAM 10/2: 000141: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing
pdpmcb->pdpaddr.dynamic_addr_requested 1
MWAM 10/2: 000142: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing
pdpmcb->pdpaddr.addr_source 3
MWAM 10/2: 000143: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing
pdpmcb->pdpaddr.allocated_prefix_len 16
MWAM 10/2: 000144: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing
pdpmcb->pdpaddr.aggregate_prefix_len 16
MWAM 10/2: 000145: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing
pdpmcb->pdpaddr.pdp_type_org 1
MWAM 10/2: 000146: Aug 24 2000 23:19:01.591 EDT: GTP-SR:packing
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
MWAM 10/2: 000201: Aug 24 2000 23:19:01.595 EDT: GTP-SR: Removing element from state-list
Dynamic Sync Ready, final count 0
MWAM 10/2: 000202: Aug 24 2000 23:19:01.595 EDT: GTP-SR: adding element in state-list
Synched, final count 7
MWAM 10/2: 000203: Aug 24 2000 23:19:01.595 EDT: GTP-SR: Empty list to sync
MWAM 10/2: 000204: Aug 24 2000 23:19:03.939 EDT: GTP-SR:Context Type PDP, Handler Sync,
Context Event Context Setup, Context Sub Event No Sub Event
MWAM 10/2: 000205: Aug 24 2000 23:19:03.939 EDT: GTP-SR:State of Redundancy Context is
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
MWAM 10/2: 000209: Aug 24 2000 23:19:04.463 EDT: GTP-SR:State of Redundancy Context is
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: 000226: Aug 24 2000 23:19:04.463 EDT: GTP-SR: Ckpt Message was sucessfully sent
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
MWAM 10/2: 000229: Aug 24 2000 23:19:04.467 EDT: GTP-SR:State of Redundancy Context is
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
MWAM 10/2: 000233: Aug 24 2000 23:19:04.467 EDT: GTP-SR:State of Redundancy Context is
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
MWAM 10/2: 000236: Aug 24 2000 23:19:04.467 EDT: GTP-SR: Ckpt Message was sucessfully sent
MWAM 10/2: 000237: Aug 24 2000 23:19:04.467 EDT: GTP-SR: Removing element from state-list
Synched, final count 6
MWAM 10/2: 000238: Aug 24 2000 23:19:04.467 EDT: GTP-SR: adding element in state-list
Delete, final count 1
MWAM 10/2: 000239: Aug 24 2000 23:19:04.467 EDT: GTP-SR: Removing element from state-list
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
MWAM 10/2: 000241: Aug 24 2000 23:19:04.471 EDT: GTP-SR: Removing element from state-list
Synched, final count 5
Router-a#
Router-a#
Standby GGSN:
Router-b#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-b#sh gprs redun
GPRS redundancy is enabled and Unit-Status is Standby
CheckPointed-From-Active Statistics
Router-b#
MWAM 10/2: 000065: Jun 1 2006 18:28:06.591 EDT: GTP-SR: Redundancy RF Event Received is
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: 000068: Jun 1 2006 18:28:06.591 EDT: GTP-SR: adding element in state-list
Initialized, final count 4
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
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,
Context Event Path Setup, Context Sub Event No Sub Event
MWAM 10/2: 000081: Jun 1 2006 18:28:06.595 EDT: GTP-SR:State of Redundancy Context is
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: 000083: Jun 1 2006 18:28:06.595 EDT: GTP-SR: Removing element from state-list
Initialized, final count 3
MWAM 10/2: 000084: Jun 1 2006 18:28:06.595 EDT: GTP-SR: adding element in state-list Bulk
Synch Ready, final count 2
MWAM 10/2: 000085: Jun 1 2006 18:28:06.595 EDT: GTP-SR: Redundancy RF Event Received is
Create Redundancy Context
MWAM 10/2: 000086: Jun 1 2006 18:28:06.595 EDT: GTP-SR: Redundancy Event is Path Setup
MWAM 10/2: 000087: Jun 1 2006 18:28:06.595 EDT: GTP-SR: Need to allocate redundancy
context
MWAM 10/2: 000088: Jun 1 2006 18:28:06.595 EDT: GTP-SR: adding element in state-list
Initialized, final count 4
MWAM 10/2: 000089: Jun 1 2006 18:28:06.595 EDT: GTP-SR Packet Dump: Len for dump:
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,
Context Event Path Setup, Context Sub Event No Sub Event
MWAM 10/2: 000101: Jun 1 2006 18:28:06.595 EDT: GTP-SR:State of Redundancy Context is
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: 000103: Jun 1 2006 18:28:06.595 EDT: GTP-SR: Removing element from state-list
Initialized, final count 3
MWAM 10/2: 000104: Jun 1 2006 18:28:06.595 EDT: GTP-SR: adding element in state-list Bulk
Synch Ready, final count 3
MWAM 10/2: 000105: Jun 1 2006 18:28:12.223 EDT: GTP-SR: Redundancy RF Event Received is
Create Redundancy Context
MWAM 10/2: 000106: Jun 1 2006 18:28:12.223 EDT: GTP-SR: Redundancy Event is Context Setup
MWAM 10/2: 000107: Jun 1 2006 18:28:12.223 EDT: GTP-SR: Need to allocate redundancy
context
MWAM 10/2: 000108: Jun 1 2006 18:28:12.223 EDT: GTP-SR: adding element in state-list
Initialized, final count 4
MWAM 10/2: 000109: Jun 1 2006 18:28:12.223 EDT: GTP-SR Packet Dump: Len for dump:
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
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
MWAM 10/2: 000127: Jun 1 2006 18:28:12.235 EDT: GTP-SR: un-packing
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
MWAM 10/2: 000132: Jun 1 2006 18:28:12.235 EDT: GTP-SR: un-packing
pdpmcb->pdpaddr.pdp_addr 11.1.0.1
MWAM 10/2: 000133: Jun 1 2006 18:28:12.235 EDT: GTP-SR: un-packing
pdpmcb->pdpaddr.static_addr_allocated 0
MWAM 10/2: 000134: Jun 1 2006 18:28:12.235 EDT: GTP-SR: un-packing
pdpmcb->pdpaddr.dynamic_addr_allocated 1
MWAM 10/2: 000135: Jun 1 2006 18:28:12.235 EDT: GTP-SR: un-packing
pdpmcb->pdpaddr.dynamic_addr_requested 1
MWAM 10/2: 000136: Jun 1 2006 18:28:12.235 EDT: GTP-SR: un-packing
pdpmcb->pdpaddr.addr_source 3
MWAM 10/2: 000137: Jun 1 2006 18:28:12.235 EDT: GTP-SR: un-packing
pdpmcb->pdpaddr.allocated_prefix_len 16
MWAM 10/2: 000138: Jun 1 2006 18:28:12.235 EDT: GTP-SR: un-packing
pdpmcb->pdpaddr.aggregate_prefix_len 16
MWAM 10/2: 000139: Jun 1 2006 18:28:12.235 EDT: GTP-SR: un-packing
pdpmcb->pdpaddr.pdp_type_org 1
MWAM 10/2: 000140: Jun 1 2006 18:28:12.235 EDT: GTP-SR: un-packing
pdpmcb->pdpaddr.pdp_type_num 33
MWAM 10/2: 000141: Jun 1 2006 18:28:12.235 EDT: GTP-SR: un-packing
pdpmcb->pdpaddr.addrlen 6
MWAM 10/2: 000142: Jun 1 2006 18:28:12.235 EDT: GTP-SR: un-packing
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
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
MWAM 10/2: 000187: Jun 1 2006 18:28:12.255 EDT: GTP-SR: Need to allocate redundancy
context
MWAM 10/2: 000188: Jun 1 2006 18:28:12.255 EDT: GTP-SR: adding element in state-list
Initialized, final count 5
MWAM 10/2: 000189: Jun 1 2006 18:28:12.255 EDT: GTP-SR: Removing element from state-list
Initialized, final count 4
MWAM 10/2: 000190: Jun 1 2006 18:28:12.255 EDT: GTP-SR: adding element in state-list
Synched, final count 1
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,
Context Event Context Setup, Context Sub Event No Sub Event
MWAM 10/2: 000207: Jun 1 2006 18:28:12.259 EDT: GTP-SR:State of Redundancy Context is
Initialized
MWAM 10/2: 000208: Jun 1 2006 18:28:12.259 EDT: GTP-SR: Event Context Setup, Sub Event No
Sub Event
MWAM 10/2: 000209: Jun 1 2006 18:28:12.259 EDT: GTP-SR: Removing element from state-list
Initialized, final count 3
MWAM 10/2: 000210: Jun 1 2006 18:28:12.259 EDT: GTP-SR: adding element in state-list Bulk
Synch Ready, final count 4
MWAM 10/2: 000211: Jun 1 2006 18:28:15.091 EDT: GTP-SR: Redundancy RF Event Received is
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)
MWAM 10/2: 000214: Jun 1 2006 18:28:15.091 EDT: GTP-SR Packet Dump: Len for dump:
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
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
MWAM 10/2: 000241: Jun 1 2006 18:28:15.095 EDT: GTP-SR: Redundancy RF Event Received is
Redundancy Context Delete
MWAM 10/2: 000242: Jun 1 2006 18:28:15.095 EDT: GTP-SR: Redundancy Event is Context
Remove
MWAM 10/2: 000243: Jun 1 2006 18:28:15.095 EDT: GTP-SR Packet Dump: Len for dump:
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: 000250: Jun 1 2006 18:28:15.095 EDT: GTP-SR: Removing element from state-list
Synched, final count 0
MWAM 10/2: 000251: Jun 1 2006 18:28:15.095 EDT: GTP-SR: Removing element from state-list
Bulk Synch Ready, final count 3
MWAM 10/2: 000252: Jun 1 2006 18:29:15.103 EDT: GTP-SR: Redundancy RF Event Received is
Redundancy Context Delete
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
MWAM 10/2: 000255: Jun 1 2006 18:29:15.103 EDT: GTP-SR:State of Redundancy Context is
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: 000257: Jun 1 2006 18:29:15.103 EDT: GTP-SR: Removing element from state-list
Bulk Synch Ready, final count 2
MWAM 10/2: 000258: Jun 1 2006 18:29:15.103 EDT: GTP-SR: Redundancy RF Event Received is
Redundancy Context Delete
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
MWAM 10/2: 000261: Jun 1 2006 18:29:15.103 EDT: GTP-SR:State of Redundancy Context is
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
MWAM 10/2: 000263: Jun 1 2006 18:29:15.103 EDT: GTP-SR: Removing element from state-list
Bulk Synch Ready, final count 1
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.
no debug gvrp
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
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
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
value RasMessage ::= admissionRequest :
{
requestSeqNum 30,
callType pointToPoint : NULL,
endpointIdentifier "0068A96000000002",
destinationInfo
{
h323-ID : "ptel23@zone2.com"
},
srcInfo
{
h323-ID : "ptel213"
},
bandWidth 640,
callReferenceValue 1,
conferenceID '5FC8490FB4B9D111BFAF0060B000E945'H,
activeMC FALSE,
answerCall TRUE
}
value ACFnonStandardInfo ::=
{
srcTerminalAlias
{
e164 : "7777",
h323-ID : "ptel213"
},
dstTerminalAlias
{
h323-ID : "ptel23@zone2.com"
},
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
},
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# 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
value RasMessage ::= admissionConfirm :
{
requestSeqNum 30,
bandWidth 7680,
callModel direct : NULL,
destCallSignalAddress ipAddress :
{
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
{
h323-ID : "ptel23@zone2.com"
},
dstProxyAlias
{
h323-ID : "px2"
},
dstProxySignalAddress
{
ip '66000001'H,
port 1720
}
}
value RasMessage ::= admissionRequest :
{
requestSeqNum 31,
callType pointToPoint : NULL,
endpointIdentifier "0068A96000000002",
destinationInfo
{
h323-ID : "ptel23@zone2.com"
},
destCallSignalAddress ipAddress :
{
ip '66000001'H,
port 1720
},
srcInfo
{
e164 : "7777",
h323-ID : "ptel213"
},
bandWidth 7680,
callReferenceValue 67,
conferenceID '5FC8490FB4B9D111BFAF0060B000E945'H,
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
value RasMessage ::= admissionConfirm :
{
requestSeqNum 31,
bandWidth 7680,
callModel direct : NULL,
destCallSignalAddress ipAddress :
{
ip '66000001'H,
port 1720
},
irrFrequency 30
}
value H323-UserInformation ::=
{
h323-uu-pdu
{
h323-message-body callProceeding :
{
protocolIdentifier { 0 0 8 2250 0 1 },
destinationInfo
{
gateway
{
protocol
{
h323 :
{
}
}
},
mc FALSE,
undefinedNode FALSE
}
}
}
}
01000600 08914A00 01088001 2800
value H323-UserInformation ::=
{
h323-uu-pdu
{
h323-message-body setup :
{
protocolIdentifier { 0 0 8 2250 0 1 },
sourceAddress
{
h323-ID : "ptel213"
},
sourceInfo
{
vendor
{
vendor
{
t35CountryCode 181,
t35Extension 0,
manufacturerCode 18
}
},
gateway
{
protocol
{
h323 :
{
}
}
},
mc FALSE,
undefinedNode FALSE
},
destinationAddress
{
h323-ID : "ptel23@zone2.com"
},
destCallSignalAddress ipAddress :
{
ip '66000001'H,
port 1720
},
activeMC FALSE,
conferenceID '5FC8490FB4B9D111BFAF0060B000E945'H,
conferenceGoal create : NULL,
callType pointToPoint : 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
value H323-UserInformation ::=
{
h323-uu-pdu
{
h323-message-body callProceeding :
{
protocolIdentifier { 0 0 8 2250 0 1 },
destinationInfo
{
gateway
{
protocol
{
h323 :
{
}
}
},
mc FALSE,
undefinedNode FALSE
}
}
}
}
value H323-UserInformation ::=
{
h323-uu-pdu
{
h323-message-body alerting :
{
protocolIdentifier { 0 0 8 2250 0 1 },
destinationInfo
{
mc FALSE,
undefinedNode FALSE
}
}
}
}
value H323-UserInformation ::=
{
h323-uu-pdu
{
h323-message-body alerting :
{
protocolIdentifier { 0 0 8 2250 0 1 },
destinationInfo
{
mc FALSE,
undefinedNode FALSE
}
}
}
}
03000600 08914A00 010000
value H323-UserInformation ::=
{
h323-uu-pdu
{
h323-message-body connect :
{
protocolIdentifier { 0 0 8 2250 0 1 },
h245Address ipAddress :
{
ip '66000001'H,
port 11011
},
destinationInfo
{
gateway
{
protocol
{
h323 :
{
}
}
},
mc FALSE,
undefinedNode FALSE
},
conferenceID '5FC8490FB4B9D111BFAF0060B000E945'H
}
}
}
value H323-UserInformation ::=
{
h323-uu-pdu
{
h323-message-body connect :
{
protocolIdentifier { 0 0 8 2250 0 1 },
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
6007000740065006C0032003100332800B50000124001280001400F007000740065006C00320
0330040007A006F006E00650032002E0063006F006D006600000106B8003DC8490FB4B9D111B
FAF0060B000E945000E07006500000106B822400F007000740065006C003200330040007A006
F006E00650032002E0063006F006D
H225Lib::h225RecvData: Q.931 SETUP received from socket [2]
H225Lib::h225RecvData: State changed to [Call Present].
RASlib::ras_sendto: msg length 119 sent to 102.0.0.1
RASLib::RASSendARQ: ARQ sent to 102.0.0.1
RASLib::RASRecvData: successfully rcvd message of length 119 from 102.0.0.1:24999
RASLib::RASRecvData: ARQ rcvd from [102.0.0.1:24999] on sock [0x68FC74]
RASlib::ras_sendto: msg length 16 sent to 70.0.0.31
RASLib::RASSendACF: ACF sent to 70.0.0.31
RASLib::RASRecvData: successfully rcvd message of length 16 from 102.0.0.1:1719
RASLib::RASRecvData: ACF rcvd from [102.0.0.1:1719] on sock [0x67E6A4]
RASlib::ras_sendto: msg length 119 sent to 102.0.0.1
RASLib::RASSendARQ: ARQ sent to 102.0.0.1
RASLib::RASRecvData: successfully rcvd message of length 119 from 102.0.0.1:24999
RASLib::RASRecvData: ARQ rcvd from [102.0.0.1:24999] on sock [0x68FC74]
RASlib::ras_sendto: msg length 16 sent to 70.0.0.31
RASLib::RASSendACF: ACF sent to 70.0.0.31
RASLib::RASRecvData: successfully rcvd message of length 16 from 102.0.0.1:1719
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].
RASLib::RASRecvData: successfully rcvd message of length 123 from 90.0.0.13:1700
RASLib::RASRecvData: ARQ rcvd from [90.0.0.13:1700] on sock [0x68FC74]
RASlib::ras_sendto: msg length 16 sent to 90.0.0.13
RASLib::RASSendACF: ACF sent to 90.0.0.13
Hex representation of the received TPKT
0300001808028080027E000C050100060008914A00010200
H225Lib::h225RecvData: Q.931 CALL PROCEEDING received from socket [4]
Hex representation of the received TPKT
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].
Hex representation of the received TPKT
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::ras_sendto: msg length 108 sent to 102.0.0.1
RASLib::RASSendIRR: IRR sent to 102.0.0.1
RASLib::RASRecvData: successfully rcvd message of length 108 from 102.0.0.1:24999
Examples The following are sample output from the debug h225 events command.
Example 1
The following output shows two proxy call scenarios. A trace is collected on the source proxy with
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].
Hex representation of the received TPKT
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].
Hex representation of the received TPKT
0300001B08028084027E000F050100060008914A00010880012800
Example 2
The following output shows two proxy call scenarios. A trace is collected on the source proxy with
H.225 turned on. The call is being torn down.
Router# debug h225 events
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
debugging output, use the no form of this command.
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.
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# debug h225 events
Router#
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.
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# debug h225 asn1
Router#
Usage Guidelines
Caution This command slows the system down considerably. Connections may time out.
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
SY3725_1#
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 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
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_services=0x0,
crypto_suite=0x0,
master_key_len=0x0,
master_salt_len=0x0,
master_key=0xxxxxxxxxxxxxxxxx,
master_salt=0xxxxxxxxxxxxxxx
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
000084: Mar 16 16:46:38.241: //4/CCB23DEA8003/H323/cch323_dump_srtp_caps:
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.
000085: Mar 16 16:46:38.241: //4/CCB23DEA8003/H323/cch323_dump_srtp_media_params:
ssrc_sel=0x0,
srtp_ssrc=0x0,
crypto_services=0x0,
crypto_suite=0x0,
master_key_len=0x0,
master_salt_len=0x0,
master_key=0xxxxxxxxxxxxxxxxx,
master_salt=0xxxxxxxxxxxxxxx
000086: 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
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
000090: Mar 16 16:46:38.245: //4/CCB23DEA8003/H323/cch323_dump_srtp_caps:
crypto_bm=0x1,
codec_bm=0xB.
000091: Mar 16 16:46:38.245: //4/CCB23DEA8003/H323/cch323_dump_srtp_media_params:
ssrc_sel=0x0,
srtp_ssrc=0x0,
crypto_services=0x3,
crypto_suite=0x1,
master_key_len=0x10,
master_salt_len=0xE,
master_key=0xxxxxxxxxxxxxxxxx,
master_salt=0xxxxxxxxxxxxxxx
000092: Mar 16 16:46:38.245: //4/CCB23DEA8003/H323/cch323_dump_srtp_sess_params:
lifetime=0x0,
mki=0x,
mki_length=0x0,
kdr=0x18,
encryptedsrtp=0x1,
encryptedsrtcp=0x1,
fecorder=0x0,
windowsizehint=0x40
000093: 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:86: Exit
000094: Mar 16 16:46:38.249: //4/CCB23DEA8003/H323/cch323_generate_srtp_info:
../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
000096: Mar 16 16:46:38.249: //4/CCB23DEA8003/H323/cch323_dump_srtp_caps:
crypto_bm=0x0,
codec_bm=0x0.
000097: Mar 16 16:46:38.249: //4/CCB23DEA8003/H323/cch323_dump_srtp_media_params:
ssrc_sel=0x0,
srtp_ssrc=0x0,
crypto_services=0x3,
crypto_suite=0x0,
master_key_len=0x10,
master_salt_len=0xE,
master_key=0xxxxxxxxxxxxxxxxx,
master_salt=0xxxxxxxxxxxxxxx
000098: Mar 16 16:46:38.249: //4/CCB23DEA8003/H323/cch323_dump_srtp_sess_params:
lifetime=0x0,
mki=0x,
mki_length=0x0,
kdr=0x18,
encryptedsrtp=0x1,
encryptedsrtcp=0x1,
fecorder=0x0,
windowsizehint=0x40
000099: Mar 16 16:46:38.249: //4/CCB23DEA8003/H323/cch323_generate_srtp_info:
../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
The following lines show the outgoing gateway sending SRTP capabilities:
The following lines show that the gateway has received SRTP capabilities from the remote end:
ssrc_sel=0x0,
srtp_ssrc=0x0,
crypto_services=0x3,
crypto_suite=0x1,
master_key_len=0x10,
master_salt_len=0xE,
master_key=0xxxxxxxxxxxxxxxxx,
master_salt=0xxxxxxxxxxxxxxx
000116: 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:448: RX [Remote] SRTP
Info .
fecorder=0x0,
windowsizehint=0x40
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.
no debug h323-annexg
Examples The following is sample output from the debug h323-annexg events command:
Router# debug h323-annexg events
Syntax Description if-config (Optional) Displays debugging messages showing the timing of the
reconfiguration of cable interfaces during HCCP redundancy operations.
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
The following example shows typical output for the debug hccp timing if-config command:
Router# debug hccp events
Router# debug hccp timing if-config
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.
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
privileged EXEC mode. To disable debugging output, use the no form of this command.
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.
Release Modification
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.
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 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
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
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.
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.
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.
Examples The following is sample output from the debug http client api command:
Router# debug http client api
The following is sample output from the debug http client cache command:
Router# debug http client cache
The following is sample output from the debug http client main command:
Router# debug http client main
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
The following is sample output from the debug http client socket command:
Router# debug http client socket
The following is sample output from the debug http client error command:
Router# debug http client error
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)
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.
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.
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 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.
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
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}
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.
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.
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 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.
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
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# int fast 4/0/0
Router(config-if)# shut
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)# no shut
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
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.
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 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.
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
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.
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 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.
Examples The following example enables error 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 errors
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.
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 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.
Examples The following example enables control plane event 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 events
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.
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 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.
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
Usage Guidelines The debug hw-module subslot commands are intended for use by Cisco Systems technical support
personnel.
The debug hw-module subslot ipcshim command is only supported by certain shared port adapters
(SPAs).
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 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.
Examples The following example enables IPC SHIM application debug messages for all supported modules in the
router:
Router# debug hw-module subslot all ipcshim
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.
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 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.
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.
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.
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 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.
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
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.
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
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
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
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
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
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.
Command Default If an option is not selected, all debug messages are displayed.
IP Admission Consent:
IP Admission Consent Errors debugging is on
IP Admission Consent Events debugging is on
IP Admission Consent Messages debugging is on
Examples The following sample output from the debug ip admission eapoudp command shows information about
network admission control using EAPoUDP. In the command output, the term posture refers to the
credentials (for example, antivirus state or version of Cisco IOS software) of the host system.
Router# debug ip admission eapoudp
Posture validation session created for client mac= 0001.027c.f364 ip= 10.0.0.1
Total Posture sessions= 1 Total Posture Init sessions= 1
*Apr 9 19:39:45.684: %AP-6-POSTURE_START_VALIDATION: IP=10.0.0.1|
Interface=FastEthernet0/0.420
*Apr 9 19:40:42.292: %AP-6-POSTURE_STATE_CHANGE: IP=10.0.0.1| STATE=POSTURE ESTAB
*Apr 9 19:40:42.292: auth_proxy_posture_parse_aaa_attributes:
CiscoDefined-ACL name= #ACSACL#-IP-HealthyACL-40921e54
Apr 9 19:40:42.957: %AP-6-POSTURE_POLICY: Apply access control list
(xACSACLx-IP-HealthyACL-40921e54) policy for host (10.0.0.1)
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.
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.
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.
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
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
The following example is sample output with the detailed keyword enabled:
00:37:50:AUTH-PROXY:proto_flag=5, dstport_index=1
00:37:50: SYN SEQ 245972 LEN 0
00:37:50:dst_addr 192.168.127.2 src_addr 192.168.27.1 dst_port 21 src_port 4347
00:37:50:AUTH-PROXY:auth_proxy_half_open_count++ 1
00:37:50:AUTH-PROXY:proto_flag=5, dstport_index=1
00:37:50: ACK 1820245643 SEQ 245973 LEN 0
00:37:50:dst_addr 192.168.127.2 src_addr 192.168.27.1 dst_port 21 src_port 4347
00:37:50:clientport 4347 state 0
00:37:50:AUTH-PROXY:incremented proxy_proc_count=1
00:37:50:AUTH-PROXY:proto_flag=5, dstport_index=1
00:37:50: ACK 1820245674 SEQ 245973 LEN 0
00:37:50:dst_addr 192.168.127.2 src_addr 192.168.27.1 dst_port 21 src_port 4347
00:37:50:clientport 4347 state 0
00:37:57:AUTH-PROXY:proto_flag=5, dstport_index=1
00:37:57: PSH ACK 1820245674 SEQ 245973 LEN 16
00:37:57:dst_addr 192.168.127.2 src_addr 192.168.27.1 dst_port 21 src_port 4347
00:37:57:clientport 4347 state 0
00:37:57:AUTH-PROXY:proto_flag=5, dstport_index=1
00:37:57: ACK 1820245699 SEQ 245989 LEN 0
00:37:57:dst_addr 192.168.127.2 src_addr 192.168.27.1 dst_port 21 src_port 4347
00:37:57:clientport 4347 state 0
00:38:01:AUTH-PROXY:proto_flag=5, dstport_index=1
00:38:01: PSH ACK 1820245699 SEQ 245989 LEN 16
00:38:01:dst_addr 192.168.127.2 src_addr 192.168.27.1 dst_port 21 src_port 4347
00:38:01:clientport 4347 state 0
00:38:01:AUTH-PROXY:Authenticating user ryan
00:38:01:AUTH-PROXY:Session state is INIT.Not updating stats
00:38:01:AUTH-PROXY:Session state is INIT.Not updating stats
00:38:01:AUTH-PROXY:Sent AAA request successfully
00:38:01:AUTH-PROXY:Sent password successfully
00:38:01:AUTH-PROXY:processing authorization data
00:38:01:AUTH-PROXY:Sending accounting start.unique-id 2
00:38:01:AUTH-PROXY:Session state is INIT.Not updating stats
00:38:01:AUTH-PROXY:Session state is INIT.Not updating stats
00:38:01:AUTH-PROXY:wait complete on watched boolean stat=0
00:38:01:AUTH-PROXY:src ip addr is 192.168.127.2, dstaddr=192.168.27.1
00:38:01: SYN ACK 2072458992 SEQ 4051022445 LEN 0
00:38:01:AUTH-PROXY:src ip addr is 192.168.127.2, dstaddr=192.168.27.1
00:38:01: PSH ACK 2072458992 SEQ 4051022446 LEN 49
00:38:02:AUTH-PROXY:src ip addr is 192.168.127.2, dstaddr=192.168.27.1
00:38:02: ACK 2072459003 SEQ 4051022495 LEN 0
00:38:02:AUTH-PROXY:src ip addr is 192.168.127.2, dstaddr=192.168.27.1
00:38:02: PSH ACK 2072459003 SEQ 4051022495 LEN 33
00:38:02:AUTH-PROXY:src ip addr is 192.168.127.2, dstaddr=192.168.27.1
00:38:02: ACK 2072459014 SEQ 4051022528 LEN 0
00:38:02:AUTH-PROXY:src ip addr is 192.168.127.2, dstaddr=192.168.27.1
00:38:02: PSH ACK 2072459014 SEQ 4051022528 LEN 26
00:38:03:AUTH-PROXY:proto_flag=5, dstport_index=1
00:38:03: ACK 1820245725 SEQ 246005 LEN 0
00:38:03:dst_addr 192.168.127.2 src_addr 192.168.27.1 dst_port 21 src_port 4347
00:38:03:clientport 4347 state 3
7200b#
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
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]
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]
Release Modification
12.0(23)S This command was integrated into Cisco IOS Release 12.0(23)S.
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(24)S This command was integrated into Cisco IOS Release 12.0(24)S.
12.2(14)S This command was integrated into Cisco IOS Release 12.2(14)S.
12.2(17b)SXA This command was integrated into Cisco IOS Release 12.2(17b)SXA.
12.0(27)S The command output was modified to show explicit-null label information.
12.2(28)SB This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(31)SB This command was integrated into Cisco IOS Release 12.2(31)SB.
12.2(33)SRA This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH This command was integrated into Cisco IOS Release 12.2(33)SXH.
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 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:bgp_vpnv4_bnetinit:100:2:10.0.0.0/8
03:47:14:vpn:bnettable add:100:2:10.0.0.0/8
03:47:14:vpn:bestpath_hook route_tag_change for vpn2:10.0.0.0/255.0.0.0(ok)
03:47:14:vpn:bgp_vpnv4_bnetinit:100:2:10.0.0.0/8
03:47:14:vpn:bnettable add:100:2:10.0.0.0/8
03:47:14:vpn:bestpath_hook route_tag_chacle ip bgp *nge for vpn2:10.0.0.0/255.0.0.0(ok)
The following example shows sample output, including the explicit-null label, from the debug ip bgp
updates and the debug ip bgp mpls commands:
Router# debug ip bgp updates
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
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.
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.
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
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.
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
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.
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.
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
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
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.
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
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
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
In the following sample, the output shows that the local router is sending updates with the cost
community:
Router# debug ip bgp updates out
In the following sample, the output shows that the local router is receiving updates with the cost
community:
Router# debug ip bgp updates in
Examples The following example shows command output on the active route processor:
Router# debug ip bgp vpnv4 checkpoint
Examples The following example shows the command output on the active Route Processor:
Router# debug ip bgp vpnv4 nsf
The following example shows the command output on the standby Route Processor:
Router# debug ip bgp vpnv4 nsf
Examples The following is sample output from the debug ip casa affinities command:
Router# debug ip casa affinities
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.
Examples The following is sample output from the debug ip casa packets command:
Router# debug ip casa packets
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.
Examples The following is sample output from the debug ip casa wildcards command:
Router# debug ip casa wildcards
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.
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
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.
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
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.
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
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
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.
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
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 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}]
Usage Guidelines This command is used to record Cisco Express Forwarding subblock messages and events.
Examples The following is sample output from the debug ip cef subblock command:
Router# debug ip cef subblock
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.
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
Examples The following is sample output from the debug ip cef table command:
Router# debug ip cef table
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.
debug ip cef
To troubleshoot various Cisco Express Forwarding events, use the debug ip cef command in privileged
EXEC mode. To disable debugging output, use the no form of this command.
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}
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]}
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.
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
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
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
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
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
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
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.
!DHCP Client Configuration
ip dhcp-client update dns server none
interface Ethernet1
ip ddns update testing
ip address dhcp
end
Sample Configuration for the Client to Update 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 explicitly specifies the server to
update. The DHCP client is configured to include an FQDN DHCP option that instructs the DHCP server
not to update either A or PTR RRs. The configuration is performed using the ip dhcp client update dns
command. The DHCP server is configured to override the client request and update both A and PTR RR
anyway.
!DHCP Client Configuration
ip dhcp client update dns server none
interface Ethernet1
ip dhcp client update dns server none
ip ddns update testing
ip address dhcp
end
Sample Configuration for the Client to Update 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 the DHCP server to update neither. The DHCP client is configured to include an FQDN
DHCP option which instructs the DHCP server not to update either A or PTR RRs. The DHCP server is
configured to allow the client to update whatever RR it chooses.
!DHCP Client Configuration
ip dhcp client update dns server non
interface Ethernet1
ip dhcp client update dns server none
ip ddns update testing host 172.19.192.32
ip address dhcp
end
interface ethernet0/0
ip ddns update test hostname test2
ip addr dhcp
Using the show hosts command displays the newly added host table entry.
Router# show hosts
*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
interface ethernet1
ip ddns update hostname test.dyndns.org
ip ddns update dyndns host members.dyndns.org
ip addr dhcp
!Debugging Enabled
Router# debug ip ddns update
00: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
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.
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
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 flows and fewer users. Debugging during these periods reduces the
effect these commands have on other users on the system.
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
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.
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
The following example shows the debug output when the configured pattern does not match:
Router# debug ip dhcp server class
The following example shows the debug output when you unconfigure a DHCP pattern in a DHCP class
and then configure the pattern in the DHCP class:
Router# debug ip dhcp server class
The following example shows the debug output when the configured pattern does match:
Router# debug ip dhcp server class
The following example shows the debug output when static mappings are configured:
Router# debug ip dhcp server
Examples The following example shows how to enable debugging and display DHCP server SNMP debugging
events:
Router# debug ip dhcp server snmp
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.
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
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
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
.
Router# show debugging
debug ip drp
To display Director Response Protocol (DRP) information, use the debug ip drp command in privileged
EXEC mode. To disable debugging output, use the no form of this command.
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
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.
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,
use the no form of this command.
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
The following lines show that the router received DVMRP routing information and placed it in the
mroute table:
DVMRP: Received Report on Ethernet0 from 172.19.244.10
DVMRP: Received Report on Ethernet0 from 172.19.244.11
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.
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.
DVMRP: Sending IGMP Reports for known groups on Ethernet0
The following is sample output from the debug ip dvmrp detail command:
Router# debug ip dvmrp detail
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.
DVMRP: Advertise group 224.2.224.2 on Ethernet0
The metric is the number of hops the route has covered, and the distance is the administrative distance.
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
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
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.
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.
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.
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.
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
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 describes the significant fields shown in the display.
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
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.
Table 132 describes the significant fields shown in the display.
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
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 describes the significant fields shown in the display.
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.
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
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000
Examples The following is sample output from the debug ip flow export command:
Router# debug ip flow export
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.
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
Examples For sample output and field descriptions of this command, see the documentation of the commands listed
in the Usage Guidelines section.
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
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
Command Description
debug ip http all Displays authentication processes for all HTTP server
processes on the system.
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.
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: http_client_request:
2w4d: httpc_setup_request:
2w4d: http_client_process_request:
2w4d: http_transaction_free:
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
2w4d: http_transaction_free:
2w4d: http_client_abort_request:
2w4d: http_client_abort_request:Bad Transaction Id
Router#
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
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).
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
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
Defaults Disabled.
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:
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 secure-state
Examples The following is sample output from the debug ip http ssi command:
Router# debug ip http ssi
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
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
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
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
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
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.
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
Command Description
debug ip http token Displays individual tokens parsed by the HTTP server.
debug ip http transaction Displays HTTP server transaction processing.
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
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
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.
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
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
Examples The following example shows debugging messages for the IGMP snooping services being displayed:
Router# debug ip igmp snooping
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,
use the no form of this command.
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.
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.
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
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
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:
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:
IGRP: Total routes in update: 69
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:
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
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.
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
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(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)# 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
debug ip inspect
To display messages about Cisco IOS Firewall events, use the debug ip inspect command in privileged
EXEC mode. To disable debugging output, use the no form of this command.
no debug ip inspect
Table 140 Protocol Keywords for the debug ip inspect Command (continued)
Release Modification
11.2 P This command was introduced.
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.
Examples The following is sample output from the debug ip inspect function-trace command:
Router# debug ip inspect function-trace
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:
Router# debug ip inspect object-creation
Router# debug ip inspect object-deletion
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 object-creation
Router# debug ip inspect object-deletion
Router# debug ip inspect events
The following is sample output from the debug ip inspect timers command:
Router# debug ip inspect timers
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)
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* sis 25A3604 ftp L7 inspect result: PROCESS-SWITCH packet
*Mar 2 01:20:58: CBAC* sis 25A3604 ftp L7 inspect result: PROCESS-SWITCH packet
*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
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.
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.
Examples The following example shows how to enable debugging messages for the Cisco IOS IPS:
Router# debug ip ips
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.
Examples The following is sample output from the debug ip mbgp dampening command:
Router# debug ip mbgp dampening
Defaults Logging for multiprotocol BGP-related information in BGP update messages is not enabled.
Examples The following is sample output from the debug ip mbgp updates command:
Router# debug ip mbgp updates
BGP: 171.69.233.19 computing updates, neighbor version 267099, table version 267100,
starting at 0.0.0.0
BGP: NEXT_HOP part 1 net 172.19.0.0/16, neigh 171.69.233.19, next 171.69.233.49
BGP: 171.69.233.19 send UPDATE 172.19.0.0/16, next 171.69.233.49, metric 0, path 33 49
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
debug ip mcache
To display IP multicast fast-switching events, use the debug ip mcache command in privileged EXEC
mode. To disable debugging output, use the no form of this command.
Syntax Description vrf (Optional) Supports the Multicast Virtual Private Network (VPN) routing
and forwarding (VRF) instance.
vrf-name (Optional) Name assigned to the VRF.
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
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.
Examples The following is sample output from the debug ip mds ipc packet command:
Router# debug ip mds ipc packet
The following is sample output from the debug ip mds ipc event command:
Router# debug ip mds ipc event
Examples The following is sample output from the debug ip mds mevent command:
Router# debug ip mds mevent
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
debug ip mhbeat
To monitor the action of the heartbeat trap, use the debug ip mhbeat command in privileged EXEC
mode. To disable debugging output, use the no form of this command.
debug ip mhbeat
no debug ip mhbeat
Examples The following is sample output from the debug ip mhbeat command.
Router# debug ip mhbeat
!
Router(config)# ip multicast heartbeat intervals-of 10
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:34:41.136: MHBEAT: timer ticked, t=2,i=2,c=0
Dec 23 13:34:51.136: MHBEAT: timer ticked, t=3,i=3,c=0
Dec 23 13:35:01.136: MHBEAT: timer ticked, t=4,i=4,c=0
Dec 23 13:35:11.136: MHBEAT: timer ticked, t=5,i=0,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
ciscoIpMRouteHeartBeat.4.0 = 5
ciscoIpMRouteHeartBeat.5.0 = 0
ciscoIpMRouteHeartBeat.6.0 = 3
Examples The following is sample output from the debug ip mobile advertise command. Table 142 describes
significant fields shown in the display.
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.
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.
Examples The following is sample output from the debug ip mobile host command:
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
! For mobile router configuration, host configuration must have been done already
MIPMIB: MN <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 the mobile network has already been configured for another group
nMIPMIB: Mobile network already configured for MR
! 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
Examples The following is sample output from the debug ip mobile redundancy command:
Syntax Description detail (Optional) Displays detailed mobile router debug messages.
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
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
To display IP mobility activities, use the debug ip mobile command in privileged EXEC mode.
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.
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
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
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
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 skipping 12 to next
Dec 31 12:34:25.715: MobileIP: ParseRegExt type MHAE(32) addr 20010B36 end 20010B6A
Dec 31 12:34:25.715: MobileIP: ParseRegExt skipping 10 to next
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 skipping 6 to next
Dec 31 12:34:25.715: MobileIP: ParseRegExt type FHAE(34) addr 20010B54 end 20010B6A
Dec 31 12:34:25.715: MobileIP: ParseRegExt skipping 20 to next
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: Authentication algorithm MD5 and 16 byte key
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
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 skipping 20 to next
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 skipping 6 to next
Dec 31 12:34:26.167: MobileIP: ParseRegExt type FHAE(34) addr 2001E76A end 2001E780
Dec 31 12:34:26.167: MobileIP: ParseRegExt skipping 20 to next
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 16 byte key
Dec 31 12:34:26.167: MobileIP: Authentication algorithm MD5 and truncated key
Dec 31 12:34:26.167: MobileIP: Authentication algorithm MD5 and 16 byte 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: Authentication algorithm MD5 and 16 byte key
Dec 31 12:34:26.167: MobileIP: Authentication algorithm MD5 and truncated key
Dec 31 12:34:26.167: MobileIP: Authentication algorithm MD5 and 16 byte key
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: Authentication algorithm MD5 and 16 byte key
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: Authentication algorithm MD5 and 16 byte key
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: Authentication algorithm MD5 and 16 byte key
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 skipping 8 to next
Dec 31 12:34:26.175: MobileIP: ParseRegExt type HHAE(35) addr 20001298 end 200012AE
Dec 31 12:34:26.175: MobileIP: ParseRegExt skipping 20 to next
debug ip mpacket
To display IP multicast packets received and sent, use the debug ip mpacket command in privileged
EXEC mode. To disable debugging output, use the no form of this command.
Syntax Description vrf (Optional) Supports the Multicast Virtual Private Network (VPN) routing
and forwarding (VRF) instance.
vrf-name (Optional) Name assigned to the VRF.
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.
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.
Examples The following is sample output from the debug ip mpacket command:
Router# debug ip mpacket 224.2.0.1
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 mrm
To display Multicast Routing Monitor (MRM) control packet activity, use the debug ip mrm command
in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip mrm
no debug ip mrm
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
debug ip mrouting
To display information about activity in the multicast route (mroute) table, use the debug ip mrouting
command in privileged EXEC mode. To disable debugging output, use the no form of this command.
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.
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
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.
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.
MRT: Create (10.9.0.0/16, 224.2.0.1), if_input Ethernet1, RPF nbr 224.0.0.0
MRT: Create (10.16.0.0/16, 224.2.0.1), if_input Ethernet1, RPF nbr 224.0.0.0
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 describes the significant fields shown in the display.
Field Description
MRT Multicast route table.
RPF Reverse Path Forwarding.
nbr Neighbor.
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
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)
Syntax Description vrf (Optional) Supports the Multicast Virtual Private Network (VPN) routing
and forwarding (VRF) instance.
vrf-name (Optional) Name assigned to the VRF.
debug ip msdp
To debug Multicast Source Discovery Protocol (MSDP) activity, use the debug ip msdp command in
privileged EXEC mode. To disable debugging output, use the no form of this command.
Syntax Description vrf (Optional) Supports the Multicast Virtual Private Network (VPN) routing
and forwarding (VRF) instance.
vrf-name (Optional) Name assigned to the VRF.
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
MSDP: 224.150.44.254: Received 1028-byte message from peer
MSDP: 224.150.44.254: SA TLV, len: 1028, ec: 85, 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 1028-byte SA to peer
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.111
MSDP: 224.150.44.254: Peer RPF check passed for 172.31.3.111, used EMBGP peer
MSDP: 224.150.44.250: Forward 1388-byte SA to peer
Field Description
MSDP Protocol being debugged.
224.150.44.254: IP address of the MSDP peer.
Received 1388-byte message MSDP event.
from peer
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
no form of this command.
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.
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
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.
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
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
Field Description
NAT Indicates that the packet is being translated by the NAT feature.
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
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
Field Description
NAT Indicates that the packet is being translated by the NAT feature.
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
Field Description
NAT Indicates that the packet is being translated by the NAT feature.
s=192.168.121.113->2.2.2.10 Source address of the packet and how it is being translated.
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
After the WLAN-entry times out, the following debugs will be seen:
Router# debug ip nat wlan-nat
Field Description
WLAN Indicates that a wireless LAN is being translated.
NAT Indicates that the packet is being translated using NAT.
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.
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
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
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.
Examples The following is sample output from the debug ip ospf events command:
Router# debug ip ospf events
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
Examples In the following example, information about traffic engineering advertisements is printed in OSPF LSA
messages:
Router# debug ip ospf mpls traffic-eng advertisements
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.
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
Examples The following is sample output from the debug ip ospf packet command:
Router# debug ip ospf packet
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
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.
Field Description
aut: OSPF authentication type. Possible authentication types follow:
0No authentication
1Simple password
2MD5
keyid: MD5 key ID.
seq: Sequence number.
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.
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
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
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.
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.
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.
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
specific information.
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.
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
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 describes the significant fields shown in the display.
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
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 describes the significant fields shown in the display.
Field Description
CEF: Indicates that the IP packet is being processed by CEF.
IP: Indicates that this is an IP packet.
s=10.4.9.6 (FastEthernet0/0) Indicates the source address of the packet and the name of the
interface that received the packet.
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
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 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 describes the significant fields shown in the display.
Field Description
IP: Indicates that this is an IP packet.
s=10.4.9.6 (FastEthernet0/0) Indicates the source address of the packet and the name of the
interface that received the packet.
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.
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
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.
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
The following is sample output from the debug ip pgm host command when the data keyword is used:
Router# debug ip pgm host data
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
The following is sample output from the debug ip pgm host command with the spm keyword is used:
Router# debug ip pgm host spm
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
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
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
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.
Syntax Description vrf (Optional) Supports the Multicast Virtual Private Network (VPN) routing
and forwarding (VRF) instance.
vrf-name (Optional) Name assigned to the VRF.
Examples The following is sample output from the debug ip pim auto-rp command:
Router# debug ip pim auto-rp
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: Build mapping (192.168.250.0/24, RP:172.16.214.26).
Auto-RP: Build mapping (192.168.254.0/24, RP:172.16.214.2).
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
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
no form of this command.
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 (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.
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.
Examples The following is sample output from the debug ip pim command:
Router# debug ip pim 224.2.0.1
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:
PIM: Received Join/Prune on Ethernet1 from 172.16.37.33
PIM: Received Join/Prune on Ethernet1 from 172.16.37.33
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
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:
PIM: For RP, Prune-list: 10.9.0.0/16
PIM: For RP, Prune-list: 10.16.0.0/16
PIM: For RP, Prune-list: 10.49.0.0/16
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)
Field Description
PIM Protocol Independent Multicast.
10.221.196.51/32 Host route with 32 bits of mask.
debug ip policy
To display IP policy routing packet activity, use the debug ip policy command in privileged EXEC
mode. To disable debugging output, use the no form of this command.
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.
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
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 policy command:
Router# debug ip policy 3
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.
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
*May 11 02:17:01.415: RBSCP ACK split: 0x662852D0, input FastEthernet1/0 -> output
FastEthernet1/1
*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: generated 0x65FC2980 cumack 4024420740
*May 11 02:17:01.415: RBSCP ACK split: generated 0x65FC3484 cumack 4024420741
*May 11 02:17:01.415: RBSCP ACK split: releasing original ACK 4024420742
*May 11 02:17:01.419: RBSCP process: 0x662852D0 passed access list
*May 11 02:17:01.419: RBSCP ACK split: 0x662852D0, input FastEthernet1/0 -> output
FastEthernet1/1
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
no form of this command.
debug ip rbscp
no debug ip rbscp
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 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.
no debug ip rgmp
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.
Examples The following shows sample output from the debug ip rgmp command:
Router# debug ip rgmp
debug ip rip
To display information on Routing Information Protocol (RIP) routing transactions, use the debug ip rip
command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip rip
no debug ip rip
Examples The following is sample output from the debug ip rip command:
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
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
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,
use the no form of this command.
debug ip routing
no debug ip routing
Examples The following is sample output from the debug ip routing command:
Router# 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.
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
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.
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
IP: cache invalidation from 0x115248 0x1378A, new version 5737
RT: 172.26.219.0 came out of holddown
Examples The following is sample output from the debug ip routing static command:
Router# debug ip routing static bfd
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
mode. To disable debugging output, use the no form of this command.
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
Defaults Disabled.
Examples The following commands show how to enable debugging for RSVP categories, signaling, and messages:
Router# debug ip rsvp signalling
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)
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.
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
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
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.
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
To display debugging messages for all RSVP events, use the debug ip rsvp dump-messages command
in privileged EXEC mode. To disable debugging output, use the no form of this command.
Examples The following command shows how to enable debugging for RSVP events:
Router# debug ip rsvp dump-messages
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: SESSION type 7 length 16:
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 :
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
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.
Examples The following is sample output from the debug ip rsvp errors command:
Router# debug ip rsvp errors
Syntax Description stats (Optional) Indicates whether statistics are enabled or disabled.
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
rsvp-3640-2(config-if)#
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
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.
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
Router# show debug <---- This command displays the debugging that is enabled.
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.
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
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
COPS debugging is on
Examples The following command shows how to enable debugging for RSVP rate-limiting and message manager
events:
Router# debug ip rsvp rate-limit
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)
01:00:21:%LINK-3-UPDOWN:Interface Tunnel100, changed state to up
01:00:22:%LINEPROTO-5-UPDOWN:Line protocol on Interface Tunnel100, changed state to up
01:01:03:RSVP-RATE-LIMIT:rsvp_msg_pacing_send_message
01:01:03:RSVP-MSG-MGR (140.4.4.2):Starting timer msg-pacing interval 20
01:01:03:RSVP-MSG-MGR (140.4.4.2):Enqueue element 27000405 of type 3 on msg-pacing TAIL
Examples The following command shows how to enable debugging for RSVP reliable messages events:
Router# debug ip rsvp reliable-msg
In the following display, message IDs, acknowledgments (ACKs), and message processes including
retransmissions, appear:
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
RSVP debugging is on
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
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
Router#
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.
The following example shows how to turn debugging off for this command:
Router# no debug ip rsvp sso
Examples The following command shows how to enable debugging for RSVP summary-refresh messages events:
Router# debug ip rsvp summary-refresh
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:02:%LINK-3-UPDOWN:Interface Tunnel100, changed state to up
01:11:03:%LINEPROTO-5-UPDOWN:Line protocol on Interface Tunnel100, changed state to up
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
01:11:31:RSVP-SREFRESH:Incoming message from nbr 140.4.4.2 with epoch:0xE1A1B7 msgid:0x84
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
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.
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
RSVP debugging is on
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
RSVP debugging is on
Examples The following is sample output from the debug ip rsvp wfq command:
Router# debug ip rsvp wfq
RSVP debugging is on
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
Examples The following is sample output from the debug ip rtp header-compression command:
Router# debug ip rtp header-compression
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).
Examples The following is sample output from the debug ip rtp packets command:
Router# debug ip rtp packets
Field Description
id IP identification.
ttl IP time to live (TTL).
len Total UDP length.
debug ip scp
To troubleshoot secure copy (SCP) authentication problems, use the debug ip scp command in
privileged EXEC mode. To disable debugging output, use the no form of this command.
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
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
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
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.
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.
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: Bundle for 10.5.0.4, rem rwnd 12800, cwnd 19500, outstand 1200
SCTP: Assoc 0: Bundled 12 chunks, remote rwnd 11600, outstand 2400
SCTP: Assoc 0: Bundling data, next chunk dataLen (100) > remaining mtu size
SCTP: Assoc 0: Bundle for 10.5.0.4, rem rwnd 11600, cwnd 19500, outstand 2400
SCTP: Assoc 0: Bundled 12 chunks, remote rwnd 10400, outstand 3600
SCTP: Assoc 0: Bundling data, next chunk dataLen (100) > remaining mtu size
SCTP: Assoc 0: Bundle for 10.5.0.4, rem rwnd 10400, cwnd 19500, outstand 3600
SCTP: Assoc 0: Bundled 4 chunks, remote rwnd 10000, outstand 4000
SCTP: Assoc 0: No additional chunks waiting.
SCTP: Assoc 0: Data chunks rcvd, local rwnd 7800
SCTP: Assoc 0: Data chunks rcvd, local rwnd 7000
SCTP: Assoc 0: Add Sack, local a_rwnd 7000
SCTP: Assoc 0: Chunk A22F3B45 ack'd, dest 10.5.0.4, outstanding 3900
SCTP: Assoc 0: Chunk A22F3B46 ack'd, dest 10.5.0.4, outstanding 3800
SCTP: Assoc 0: Chunk A22F3B47 ack'd, dest 10.5.0.4, outstanding 3700
SCTP: Assoc 0: Chunk A22F3B48 ack'd, dest 10.5.0.4, outstanding 3600
SCTP: Assoc 0: Chunk A22F3B49 ack'd, dest 10.5.0.4, outstanding 3500
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
SCTP: Assoc 0: Chunk A22F3B50 ack'd, dest 10.5.0.4, outstanding 2800
SCTP: Assoc 0: Chunk A22F3B51 ack'd, dest 10.5.0.4, outstanding 2700
SCTP: Assoc 0: Chunk A22F3B52 ack'd, dest 10.5.0.4, outstanding 2600
SCTP: Assoc 0: Chunk A22F3B53 ack'd, dest 10.5.0.4, outstanding 2500
SCTP: Assoc 0: Chunk A22F3B54 ack'd, dest 10.5.0.4, outstanding 2400
SCTP: Assoc 0: Chunk A22F3B55 ack'd, dest 10.5.0.4, outstanding 2300
SCTP: Assoc 0: Chunk A22F3B56 ack'd, dest 10.5.0.4, outstanding 2200
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.
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
Field Description
Initiate Tag Initiation chunk identifier.
Initial TSN Initial transmission sequence number.
rwnd Receiver window values.
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
Field Description
s Source address and port.
d Destination address and port.
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.
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.
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
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.
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
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
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.
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
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
Field Description
s Source address and port.
d Destination address and port.
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.
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: IP Addr: 10.2.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
SCTP: Streams Inbound: 13, Outbound: 13
SCTP: IP Addr: 10.5.0.4
Field Description
s Source address and port.
d Destination address and port.
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.
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
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
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.
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
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
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
Field Description
CUMSACK Cumulative selective acknowledgment.
RETRANS Retransmission.
Usage Guidelines In a live system, the debugging messages for performance, state, signal, and warnings are the most
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
debug ip sd
To display all session directory (SD) announcements received, use the debug ip sd command in
privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sd
no debug ip sd
Usage Guidelines This command shows session directory announcements for multicast IP. Use it to observe multicast
activity.
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.
Field Description
c= Connect description showing address and number of hops.
m= Media description that includes media type, port number, and ID.
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
form of this command.
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
debug ip security
To display IP security option processing, use the debug ip security command in privileged EXEC mode.
To disable debugging output, use the no form of this command.
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
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
Syntax Description operation-number (Optional) Identification number of the operation for which debugging output
is to be enabled.
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
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
Syntax Description operation-number (Optional) Number of the Ethernet operation for which the debugging output
will be displayed.
Examples The following is sample output from the debug ip sla ethernet-monitor command:
Router# debug ip sla ethernet-monitor
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
output, use the no form of this command.
Syntax Description operation-number (Optional) Identification number of the operation for which debugging output
is to be enabled.
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.
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
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
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
form of this command.
Syntax Description: operation-number (Optional) Identification number of the operation for which debugging output
is to be enabled.
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.
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
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 mpls-lsp-monitor command:
Router# debug ip sla mpls-lsp-monitor
Syntax Description: operation-number (Optional) Identification number of the operation for which debugging output
is to be enabled.
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.
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.
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.
Release Modification
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:
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 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 all IP IOS SLB parameters:
Router# debug ip slb all
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
022049 SLB DFP Queue to main queue - type 6 for Agent 161.44.2.3458229
022049 SLB DFP Processing Conn Q unknown MAJOR 80
022049 SLB DFP Reset SLB_DFP_SIDE_QUEUE
022049 SLB DFP select_rc = -1 readset = 0
022115 SLB DFP Queue to main queue - type 5 for Agent 161.44.2.3458229
022115 SLB DFP select_rc = -1 readset = 0
022115 SLB DFP Sleeping ...
022116 SLB DFP readset = 1
022116 SLB DFP select_rc = -1 readset = 0
022116 SLB DFP Processing Q event for Agent 161.44.2.3458229 - DELETE
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
the no form of this command.
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
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 snat command:
Router# debug ip snat detailed
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.
debug ip socket
To display all state change information for all sockets, use the debug ip socket command in privileged
EXEC mode. To disable debugging output, use the no form of this command.
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
The following is sample output from the debug ip socket command from a client process:
Router# 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
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.)
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 ssh
To display debugging messages for Secure Shell (SSH), use the debug ip ssh command in privileged
EXEC mode. To disable debugging output, use the no form of this command.
debug ip ssh
no debug ip ssh
Usage Guidelines Use the debug ip ssh command to ensure normal operation of the SSH server.
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.
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:
Examples The following example shows that the debug ip subscriber redundancy command is turned on:
Router# debug ip subscriber redundancy
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
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.)
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
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
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.
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.)
TCPDRV359CD8: readf 42 bytes (Thresh 16)
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
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.
Use the show tcp tcb command to display the end-host connections.
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
privileged EXEC mode. To disable debugging output, use the no form of this command.
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.
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:23.324: TCPHA: Sending pkt msg, conn_id = 396, seq no = 2959469308
*Feb 19 23:28:23.324: TCPHA: Sending pkt msg, conn_id = 41, seq no = 1270243395
*Feb 19 23:28:23.932: TCPHA: Sending pkt msg, conn_id = 42, seq no = 974255741
*Feb 19 23:28:23.932: TCPHA: Sending pkt msg, conn_id = 475, seq no = 3059612402
*Feb 19 23:28:24.544: TCPHA: Sending dummy pkt to standby; cid=109, size=19
Examples The following is sample output from the debug ip tcp intercept command:
Router# debug ip tcp intercept
The router sends more retransmissions trying to establish connections with the apparent clients:
INTERCEPT: retransmit 4 (172.19.160.17:61774) <- (10.1.1.30:23) SYNRCVD
INTERCEPT: retransmit 4 (172.19.160.17:62030) <- (10.1.1.30:23) SYNRCVD
INTERCEPT: retransmit 2 (171.69.232.23:1048) <- (10.1.1.30:23) SYNRCVD
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 router resends to the first two apparent clients, times out, and sends resets:
INTERCEPT: retransmit 8 (172.19.160.17:61774) <- (10.1.1.30:23) SYNRCVD
INTERCEPT: retransmit 8 (172.19.160.17:62030) <- (10.1.1.30:23) SYNRCVD
INTERCEPT: retransmit 16 (172.19.160.17:61774) <- (10.1.1.30:23) SYNRCVD
INTERCEPT: retransmit 16 (172.19.160.17:62030) <- (10.1.1.30:23) SYNRCVD
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)
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
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
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.
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.
Examples The following is sample output from the debug ip traffic-export events command:
Router# debug ip traffic-export events
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
form of this command.
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
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 enqueued, qdata=69FEEC
remote host=172.21.127.113, local host=172.21.127.186 (if: 0.0.0.0)
TRIGGER_AUTH: packet ignored, qdata=69FEEC
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: packet ignored, qdata=69FEEC
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 enqueued, qdata=69FEEC
remote host=172.21.127.113, local host=172.21.127.186 (if: 0.0.0.0)
TRIGGER_AUTH: packet ignored, qdata=69FEEC
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: packet ignored, qdata=69FEEC
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,
use the no form of this command.
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
debug ip urlfilter
To enable debug information of URL filter subsystems, use the debug ip urlfilter command in privileged
EXEC mode. To disable debugging output, use the no form of this command.
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
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:got cache idle 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:got a socket read event...
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:got cache idle 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 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:got a socket read event...
1d16h:URLF:socket recv (header) successful.
1d16h:URLF:socket recv (data) successful.
1d16h:URLF:n2h2 lookup code = 0
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
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
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.
debug ip virtual-reassembly
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
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
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
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.
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
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.
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
*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,
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.
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
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
*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
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
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
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]
Syntax Description rx (Optional) Displays debugging messages related to the retrieval of IPC
fragments.
tx (Optional) Displays debugging messages related to the transmission of IPC
fragments.
dest (Optional) Displays debugging messages related to a destination port of IPC
fragments. 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.
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.
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
range is from 0 to 65535.
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.
header dump (Optional) Displays only the packet header information.
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.
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
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
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]
Syntax Description rx (Optional) Displays debugging messages related to the retrieval of IPC
NACK messages.
tx (Optional) Displays debugging messages related to the transmission of IPC
NACK messages.
dest (Optional) Displays debugging messages related to a destination port of IPC
NACK 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 nacks command to troubleshoot IPC NACK issues. To enable debugging for other
IPC activities, use the debug ipc command.
Examples The following example shows how to enable the display of packet headers only when debugging IPC
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
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
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
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]
Syntax Description rx (Optional) Displays debugging messages related to the retrieval of IPC
packets.
tx (Optional) Displays debugging messages related to the transmission of IPC
packets.
dest (Optional) Displays debugging messages related to a destination port of IPC
packets. 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.
type (Optional) Displays debugging messages related to a type of IPC packet. 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 packet 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 packet. 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.
msgidhi (Optional) Displays debugging messages related to the higher byte of the
unique ID of an IPC packet.
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 packet.
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 packet payload.
If not specified, information about all of the IPC packets 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
range is from 0 to 65535.
size (Optional) Displays IPC packet 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.
header dump (Optional) Displays only the packet header information.
Usage Guidelines Use the debug ipc packets command to troubleshoot IPC packet issues. To enable debugging for other
IPC activities, use the debug ipc command.
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
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
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
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 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
msg-id-high] [msgidlo msg-id-low] [data offset offset-from-header value value-to-match
dump bytes] [size size] [header dump]
Syntax Description rx (Optional) Displays debugging messages related to the retrieval of IPC RPC
packets.
tx (Optional) Displays debugging messages related to the transmission of IPC
RPC packets.
query (Optional) Displays debugging messages related to IPC RPC queries.
response (Optional) Displays debugging messages related to IPC RPC responses.
dest (Optional) Displays debugging messages related to a destination port of IPC
RPC packets. 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.
type (Optional) Displays debugging messages related to a type of IPC RPC
message. 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 RPC message
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.
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.
Examples The following example shows how to enable the display of packet headers only when debugging IPC
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
debug ipc
To display debugging messages about interprocess communication (IPC) activity, use the debug ipc
command in privileged EXEC mode. To disable debugging output, use the no form of this command.
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.
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.
Examples The following example shows the confirmation message that appears when the debug ipc all command
is entered:
Router# debug ipc all
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
Syntax Description events (Optional) Displays IPHC IPC command and control events.
statistics (Optional) Displays IPHC IPC counter updates.
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
The following example enables the display of IPHC IPC event messages:
Router# debug iphc ipc events
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
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.
Usage Guidelines The debug ipv6 cef drop command is similar to the debug ip cef drops command, except that it is
IPv6-specific.
Note By default, the network server sends the output from debug commands and system error messages to the
console. To redirect debug output, use the logging command options in global configuration mode.
Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog
server. For complete information on debug commands and redirecting debug output, refer to the
Release 12.3 Cisco IOS Debug Command Reference.
Examples The following is sample output from the debug ipv6 cef drop command:
Router# debug ipv6 cef drop
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.
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.
Note By default, the network server sends the output from debug commands and system error messages to the
console. To redirect debug output, use the logging command options in global configuration mode.
Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog
server. For complete information on debug commands and redirecting debug output, refer to the
Release 12 Cisco IOS Debug Command Reference.
Examples The following is sample output from the debug ipv6 cef events command:
Router# debug ipv6 cef events
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
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.
Note By default, the network server sends the output from debug commands and system error messages to the
console. To redirect debug output, use the logging command options in global configuration mode.
Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog
server. For complete information on debug commands and redirecting debug output, refer to the
Release 12 Cisco IOS Debug Command Reference.
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.
Note By default, the network server sends the output from debug commands and system error messages to the
console. To redirect debug output, use the logging command options in global configuration mode.
Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog
server. For complete information on debug commands and redirecting debug output, refer to the
Release 12 Cisco IOS Debug Command Reference.
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
Field Description
IPv6CEF-receive: Receive Cisco Express Forwarding has received a packet addressed to the
packet for 2001:0DB8::2 router.
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
Note By default, the network server sends the output from debug commands and system error messages to the
console. To redirect debug output, use the logging command options in global configuration mode.
Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog
server. For complete information on debug commands and redirecting debug output, refer to the
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
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
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
Syntax Description detail (Optional) Displays detailed information about DHCP for IPv6 message
decoding.
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
Usage Guidelines Because the debug ipv6 eigrp command generates a substantial amount of output, use it only when
traffic on the network is light.
Usage Guidelines The debug ipv6 icmp command is similar to the debug ip icmp command, except that it is IPv6-specific.
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 in global configuration mode.
Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog
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.
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
Table 187 describes significant fields shown in the first line of the display.
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.
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.
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
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.
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.
Examples The following example enables the display of messages about Cisco IOS firewall events:
debug ipv6 inspect
debug ipv6 mfib [group-name | group-address] [adjacency | signal | db | init | mrib | pak | ps]
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.
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
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
Syntax Description source-address (Optional) Source address associated with an MLD membership for a group
identified by the access list.
Usage Guidelines Consult Cisco technical support before using this command.
Examples The following example allows debugging information for SSM mapping to be displayed:
Router# debug ipv6 mld ssm-map
Syntax Description group-name | (Optional) IPv6 address or name of the multicast group.
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.
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
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
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
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.
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.
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
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
Syntax Description detailed (Optional) Displays detailed information about NAT-PT translation events.
port (Optional) Displays port allocation events.
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.
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.
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
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 (3002::8) -> (192.168.124.8), dst (2001::2) -> (192.168.123.2)
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 (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)
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
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.
Usage Guidelines This command can help determine whether the router is sending or receiving IPv6 ICMP neighbor
discovery messages.
Note By default, the network server sends the output from debug commands and system error messages to the
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. For complete information on debug commands and redirecting debug output, refer to the
Cisco IOS Debug Command Reference.
Examples The following example shows output for the debug ipv6 nd command:
Router# debug ipv6 nd
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.
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.
Usage Guidelines Consult Cisco technical support before using this command.
Examples The following example shows how to turn on debugging for SPF scheduling:
Router# debug ipv6 ospf database-timer rate-limit
Usage Guidelines Consult Cisco technical support before using this command.
Usage Guidelines Consult Cisco technical support before using this command.
Examples The following example displays database modification information for OSPF for IPv6:
Router# debug ipv6 ospf lsdb
Usage Guidelines Consult Cisco technical support before using this command.
Examples The following example shows debugging information about SPF scheduling:
Router# debug ipv6 ospf monitor
Usage Guidelines Consult Cisco technical support before using this command.
Examples The following example displays information about each OSPF for IPv6 packet received:
Router# debug ipv6 ospf packet
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 [adj | ipsec | database-timer | flood | hello | lsa-generation | retransmission]
no debug ipv6 ospf [adj | ipsec | database-timer | flood | hello | lsa-generation | retransmission]
Usage Guidelines Consult Cisco technical support before using this command.
Examples The following example displays adjacency information for OSPF for IPv6:
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.
Usage Guidelines The debug ipv6 packet command is similar to the debug ip packet command, except that it is
IPv6-specific.
Note By default, the network server sends the output from debug commands and system error messages to the
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. For complete information on debug commands and redirecting debug output, refer to the
Cisco IOS Debug Command Reference.
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
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.
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.
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:
Syntax Description group-name | (Optional) IPv6 address or name of the multicast group.
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.
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.
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.
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
Examples The following example enables debugging for IPv6 prefix pools:
Router# debug ipv6 pool
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.
Usage Guidelines The debug ipv6 rip command is similar to the debug ip rip command, except that it is IPv6-specific.
Note By default, the network server sends the output from debug commands and system error messages to the
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. For complete information on debug commands and redirecting debug output, refer to the
Cisco IOS Debug Command Reference.
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.
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
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 describes the significant fields shown in the display.
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.
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.
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.
Note By default, the network server sends the output from debug commands and system error messages to the
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. For complete information on debug commands and redirecting debug output, refer to the
Cisco IOS Debug Command Reference.
Examples The following example shows output for the debug ipv6 routing command:
Router# debug ipv6 routing
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.
13:18:43:IPv6RT0:Add 2000:0:0:1:1::/80 to table
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.)
13:19:09:IPv6RT0:Better next-hop for 2000:0:0:2::/64, [20/1]
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
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)]
IPXWAN: state (Disconnect -> Sending Timer Requests) [Serial1/6666:200 (IPX line
state brought up)]
The following lines indicate that the interface is sending timer requests and waiting for a timer response:
IPXWAN: Send TIMER_REQ [seq 0] out Serial1/6666:200
IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200
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: Send TIMER_REQ [seq 1] out Serial1/6666:200
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)]
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.
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
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___^
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
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 describes the significant fields shown in the display.
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.
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.
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
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.
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.
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:
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.
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.
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
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
The following lines show that SPX packets were seen, but they are not seen for a connection that exists
in the SPX table:
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
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.
IPX: Tu1:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7004 4B8 8 1D
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)
IPX: Tu1:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7104 2B8 7 29
2E (changed:clear) Last Changed 0
The following lines show that an SPX keepalive packet came in and was spoofed:
IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: C0 0 2B8 7104 29 7 7
(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
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
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
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
Channel ID i = 0x89
received HOST_CONNECT
Channel ID i = 0x0101
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.
Router# debug isdn event
received HOST_INCOMING_CALL
Bearer Capability i = 0x080010
-------------------
Channel ID i = 0x0101
Calling Party Number i = 0x0000, 415555121202
IE out of order or end of private IEs --
Bearer Capability i = 0x8890
Channel ID i = 0x89
Calling Party Number i = 0x0083, 415555121202
ISDN Event: Received a call from 415555121202 on B1 at 64 Kb/s
ISDN Event: Accepting the call
received HOST_CONNECT
Channel ID i = 0x0101
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:
Router# debug isdn event
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:
Router# debug isdn event
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.
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:
Router# debug isdn event
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:
Router# debug isdn event
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:
Router# debug isdn event
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:
Router# debug isdn event
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:
Router# debug isdn event
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
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):
Router# debug isdn event
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.
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.
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
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
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.599:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:24:43.623:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
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
Jan 8 17:24:43.623:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:24:43.623:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:24:43.627:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:24:43.627:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x3
chan 1
Jan 8 17:24:43.719:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:24:43.719:ISDN Se2/1:15 Q921f:PBXa RX <-
0x440313092A34232A35302A3434343030
Jan 8 17:24:43.719: 303031232A31382A33312A33312A3331
Jan 8 17:24:43.719: 23
Jan 8 17:24:43.719:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1
i=0x092A34232A35302A3434343030303031232A31382A33312A33312A333123
Jan 8 17:24:43.719:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:24:43.719:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:24:43.719:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:24:43.719:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2
chan 1
Jan 8 17:24:43.719:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x300 event x241
v_bit 1 chan 1 out_pkt x63EE5780
Jan 8 17:24:43.719:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3
v_bit 1 chan 1 out_pkt x63EE57CC
Jan 8 17:24:43.723:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:24:43.723:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313
Jan 8 17:24:43.723:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1
Jan 8 17:24:43.723:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:24:43.727:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:24:43.727:ISDN Se2/1:15 Q921f:PBXa RX <-
0x440313092A34232A35302A3434343030
Jan 8 17:24:43.727: 303031232A31382A33312A33312A3331
Jan 8 17:24:43.727: 23
Jan 8 17:24:43.727:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1
i=0x092A34232A35302A3434343030303031232A31382A33312A33312A333123
Jan 8 17:24:43.727:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:24:43.727:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:24:43.731:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:24:43.731:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2
chan 1
Jan 8 17:24:43.731:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3
v_bit 1 chan 1 out_pkt x63EE57CC
Jan 8 17:24:43.731:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:24:43.731:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313
Jan 8 17:24:43.731:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1
Jan 8 17:24:43.731:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:24:43.739:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:24:43.739:ISDN Se2/1:15 Q921f:PBXa RX <-
0x440313092A34232A35302A3434343030
Jan 8 17:24:43.739: 303031232A31382A33312A33312A3331
Jan 8 17:24:43.739: 23
Jan 8 17:24:43.739:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1
i=0x092A34232A35302A3434343030303031232A31382A33312A33312A333123
Jan 8 17:24:43.739:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:24:43.739:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:24:43.739:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 event
x240 chan 1
Jan 8 17:25:31.879:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x2
v_bit 1 chan 1 out_pkt x63EFC5AC
Jan 8 17:25:31.879:ISDN Se2/0:15 LIFd:LIF_StartTimer:timer (0x63A4AFBC),
ticks (500), event (0x1201)
Jan 8 17:25:31.879:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:25:31.879:ISDN Se2/0:15 Q921f:PBXa TX -> 0x4603130830
Jan 8 17:25:31.879:ISDN Se2/0:15 Q921:PBXa TX -> UI(C) dlci=1 cntl=UI nbit=1
i=0x0830
Jan 8 17:25:31.883:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:25:31.899:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:25:31.899:ISDN Se2/0:15 Q921f:PBXa RX <- 0x460313
Jan 8 17:25:31.899:ISDN Se2/0:15 Q921:PBXa RX <- UI(R) dlci=1 cntl=UI nbit=1
Jan 8 17:25:31.899:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:25:31.899:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:25:31.903:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:25:31.903:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x3
chan 1
Jan 8 17:25:32.063:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:25:32.063:ISDN Se2/1:15 Q921f:PBXa RX <- 0x4403130830
Jan 8 17:25:32.063:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1
i=0x0830
Jan 8 17:25:32.063:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:25:32.063:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:25:32.067:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:25:32.067:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2
chan 1
Jan 8 17:25:32.067:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x300 event x241
v_bit 1 chan 1 out_pkt x63EFC5AC
Jan 8 17:25:32.067:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3
v_bit 1 chan 1 out_pkt x6367175C
Jan 8 17:25:32.067:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:25:32.067:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313
Jan 8 17:25:32.067:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1
Jan 8 17:25:32.067:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:25:32.075:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:25:32.075:ISDN Se2/1:15 Q921f:PBXa RX <- 0x4403130830
Jan 8 17:25:32.075:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1
i=0x0830
Jan 8 17:25:32.075:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:25:32.075:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:25:32.075:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:25:32.075:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2
chan 1
Jan 8 17:25:32.075:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3
v_bit 1 chan 1 out_pkt x6367175C
Jan 8 17:25:32.075:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:25:32.075:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313
Jan 8 17:25:32.079:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1
Jan 8 17:25:32.079:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:25:32.083:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:25:32.083:ISDN Se2/1:15 Q921f:PBXa RX <- 0x4403130830
Jan 8 17:25:32.083:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1
i=0x0830
Jan 8 17:25:32.083:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:25:32.083:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:25:32.087:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:25:32.087:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2
chan 1
Jan 8 17:25:32.087:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3
All of the octets following i= constitute DPNSS L3 information received from the peer:
Jan 8 17:24:43.495:ISDN Se2/0:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=0
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:process_rxdata:Frame sent to L2
Jan 8 17:24:43.495:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:24:43.495:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
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.
Jan 8 17:24:43.495:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x300 event x241
v_bit 1 chan 1 out_pkt x6367175C
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)].
Jan 8 17:24:43.495:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x3
v_bit 1 chan 1 out_pkt x63F183D4
The following is sample output from the debug isdn q921 command for an outgoing call:
Router# 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.
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.527: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 2 nr = 6
i = 0x08018702180189
Jan 3 14:52:24.643: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 3 nr = 6
i = 0x08018707
Jan 3 14:52:24.683: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 6 nr = 4
i = 0x0801070F
The following is sample output from the debug isdn q921 command for a startup message on a
DMS-100 switch:
Router# debug isdn q921
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
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.
Jan 3 14:47:43.815: ISDN BR0: RX <- RRp sapi = 0 tei = 64 nr = 2
Jan 3 14:47:43.819: ISDN BR0: TX -> RRf sapi = 0 tei = 64 nr = 0
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.
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.
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.
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.
Examples The following is sample output from the debug isdn q931 command of a call setup procedure for an
outgoing call:
Router# debug isdn q931
The following is sample output from the debug isdn q931 command of a call setup procedure for an
incoming call:
Router# debug isdn q931
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.
Router# debug isdn q931
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:
Router# debug isdn q931
Table 200 describes the significant fields shown in the displays, in alphabetical order.
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.
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:
Router# debug isdn q931
*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.
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.
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
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
no form of this command.
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.
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.
Usage Guidelines Please read the following caution before using this command.
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:
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
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 L2 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: Sending L2 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.
ISIS-Adj: Rec L1 IIH from 0000.0c00.40af (Ethernet0), cir type 3, cir id BBBB.BBBB.BBBB.01
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:
ISIS-Adj: Sending L1 IIH on Ethernet1
ISIS-Adj: Sending L2 IIH on Ethernet1
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
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.
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
BW unreserved[2]:100000 bits/sec, BW unreserved[3]:100000 bits/sec
BW unreserved[4]:100000 bits/sec, BW unreserved[5]:100000 bits/sec
BW unreserved[6]:100000 bits/sec, BW unreserved[7]:0 bits/sec
Affinity Bits:0x00000000
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.
Examples In the following example, information is printed about traffic engineering-related IS-IS events:
Router# debug isis mpls traffic-eng events
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
The following example displays detailed IS-IS state information during an NSF restart:
router# debug isis nsf detail
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.
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
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
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.
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.
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
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.
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
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.
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:
ISIS-Stats: Compute L1 SPT, Timestamp 2780.328 seconds
ISIS-Stats: Complete L1 SPT, Compute time 0.004, 1 nodes on SPT
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:
ISIS-Stats: Compute L2 SPT, Timestamp 2780.3336 seconds
ISIS-Stats: Complete L2 SPT, Compute time 0.056, 12 nodes on SPT
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.
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
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
The following lines indicate that the router has sent a periodic Level 1 and Level 2 complete sequence
number PDU on Ethernet interface 0:
ISIS-Update: Sending L1 CSNP on Ethernet0
ISIS-Update: Sending L2 CSNP on Ethernet0
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: Updating L2 LSP
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.
ISIS-Update: Updating L1 LSP
ISIS-Update: Sending L1 CSNP on Ethernet0
ISIS-Update: Sending L2 CSNP on Ethernet0
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: Updating L2 LSP
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: Updating L1 LSP
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
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.
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.
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
debug iua asp {pak | peer-msg | sctp-sig | state} {all | name asp-name}
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
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 kerberos
To display information associated with the Kerberos Authentication Subsystem, use the debug kerberos
command in privileged EXEC mode. To disable debugging output, use the no form of this command.
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
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
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.
Router# debug kerberos
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.
Router# debug kerberos
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).
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.
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.
/-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
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
/-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
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
Call-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251
CSeq: 101 SUBSCRIBE
Max-Forwards: 70
Date: Fri, 01 Mar 2002 01:02:46 GMT
User-Agent: Cisco-SIPGateway/IOS-12.x
Event: kpml
Expires: 7200
Contact: <sip:172.18.193.250:5060>
Content-Type: application/kpml-request+xml
Content-Length: 327
/-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"
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/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:
//-1/xxxxxxxxxxxx/KPML/Parser/kpml_create_new_node: creating node
par/cur/child=0x645E910C/0x645E91E8/0x00000000 top/child=0x645E910C/0x645E91E8
//-1/xxxxxxxxxxxx/KPML/Parser/kpml_regex_ptbuild:
//-1/xxxxxxxxxxxx/KPML/Parser/kpml_create_new_node: creating node
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/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
Call-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251
CSeq: 103 SUBSCRIBE
Content-Length: 0
Contact: <sip:172.18.193.250:5060>
Expires: 7200
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
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
Call-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251
CSeq: 101 SUBSCRIBE
Content-Length: 0
Contact: <sip:172.18.193.251:5060>
Expires: 7200
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
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
Call-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251
CSeq: 104 NOTIFY
Max-Forwards: 70
Date: Fri, 01 Mar 2002 00:16:24 GMT
User-Agent: Cisco-SIPGateway/IOS-12.x
Event: kpml
Subscription-State: active
Contact: <sip:172.18.193.251:5060>
Content-Length: 0
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
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
Call-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251
CSeq: 102 NOTIFY
Max-Forwards: 70
Date: Fri, 01 Mar 2002 01:02:51 GMT
User-Agent: Cisco-SIPGateway/IOS-12.x
Event: kpml
Subscription-State: active
Contact: <sip:172.18.193.250:5060>
Content-Length: 0
...
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: encode_data=0x64E25D00
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: chunk_size=2k, max_allowed=16k
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: context=0x64FADC10,
mp=0x64AFBBE0
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_response:
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: malloc xml_buf=0x645E910C, length=112
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_response:
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_response: length=73, buffp=0x645E917B
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: rc=0, encoded str=<?xml version="1.0"
encoding="UTF-8"?><kpml-response version="1.0" code="200" text="OK" digits="1"
tag="dtmf"/>
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_free:
kpml_encode_context_free:mem_mgr_mempool_free: mem_refcnt(64AFBBE0)=0 - mempool cleanup
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
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
Call-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251
CSeq: 105 NOTIFY
Max-Forwards: 70
Date: Fri, 01 Mar 2002 00:37:33 GMT
User-Agent: Cisco-SIPGateway/IOS-12.x
Event: kpml
Subscription-State: active
Contact: <sip:172.18.193.251:5060>
Content-Type: application/kpml-response+xml
Content-Length: 113
/-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
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
Call-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251
CSeq: 105 NOTIFY
Content-Length: 0
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: encode_data=0x64E25D00
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: chunk_size=2k, max_allowed=16k
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: context=0x651E8084,
mp=0x65501720
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_response:
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: malloc xml_buf=0x645E910C, length=112
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_response:
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_response: length=73, buffp=0x645E917B
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: rc=0, encoded str=<?xml version="1.0"
encoding="UTF-8"?><kpml-response version="1.0" code="200" text="OK" digits="2"
tag="dtmf"/>
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_free:
kpml_encode_context_free:mem_mgr_mempool_free: mem_refcnt(65501720)=0 - mempool cleanup
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: encode_data=0x656F9128
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: chunk_size=2k, max_allowed=16k
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: context=0x651E8084,
mp=0x6488B6CC
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_response:
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: malloc xml_buf=0x645E910C, length=112
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_response:
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_response: length=73, buffp=0x645E917B
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: rc=0, encoded str=<?xml version="1.0"
encoding="UTF-8"?><kpml-response version="1.0" code="200" text="OK" digits="3"
tag="dtmf"/>
//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_free:
kpml_encode_context_free:mem_mgr_mempool_free: mem_refcnt(6488B6CC)=0 - mempool cleanup
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
NOTIFY sip:172.18.193.250:5060 SIP/2.0
Via: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bK12339
From: <sip:172.18.193.251>;tag=EA330-F6
To: <sip:8888@172.18.193.250>;tag=39497C-2EA
Call-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251
CSeq: 106 NOTIFY
Max-Forwards: 70
Date: Fri, 01 Mar 2002 00:37:44 GMT
User-Agent: Cisco-SIPGateway/IOS-12.x
Event: kpml
Subscription-State: active
Contact: <sip:172.18.193.251:5060
Content-Type: application/kpml-response+xml
Content-Length: 113
/-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bK12339
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
Call-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251
CSeq: 106 NOTIFY
Content-Length: 0
...
debug kron
To display debugging messages about Command Scheduler policies or occurrences, use the debug kron
command in privileged EXEC mode. To disable debugging output, use the no form of this command.
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.
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
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
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 Layer 2 Relay events:
Router# debug l2relay events
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
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 Layer 2 Relay packets:
Router# debug l2relay packets
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.
no debug lacp
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
*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:23.413: LACP: lacp_p(Gi5/0/0) timer stopped
*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
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.
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
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: callid 0x6114D174
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
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 calls the LAN Emulation Server (LES) and attempts to set up the Control Direct VC
(Join/Registration Phase):
LEC ATM2/0.1: sending SETUP
LEC ATM2/0.1: callid 0x61167110
LEC ATM2/0.1: called party 39.020304050607080910111213.00000CA05B41.01
LEC ATM2/0.1: calling_party 39.020304050607080910111213.00000CA05B40.01
The LEC receives a CONNECT response from the LES. The Control Direct VC is established:
LEC ATM2/0.1: received CONNECT
LEC ATM2/0.1: callid 0x61167110
LEC ATM2/0.1: vcd 150
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
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 SETUP request from the LES to set up the Control Distribute VC:
LEC ATM2/0.1: received SETUP
LEC ATM2/0.1: callid 0x6114D174
LEC ATM2/0.1: called party 39.020304050607080910111213.00000CA05B40.01
LEC ATM2/0.1: calling_party 39.020304050607080910111213.00000CA05B41.01
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.
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: SRC MAC address 0000.0ca0.5b40
LEC ATM2/0.1: SRC ATM address 39.020304050607080910111213.00000CA05B40.01
LEC ATM2/0.1: TARGET MAC address ffff.ffff.ffff
LEC ATM2/0.1: TARGET ATM address 00.000000000000000000000000.000000000000.00
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: SRC MAC address 0000.0ca0.5b40
LEC ATM2/0.1: SRC ATM address 39.020304050607080910111213.00000CA05B40.01
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:
LEC ATM2/0.1: sending SETUP
LEC ATM2/0.1: callid 0x6114D354
LEC ATM2/0.1: called party 39.020304050607080910111213.00000CA05B42.01
LEC ATM2/0.1: calling_party 39.020304050607080910111213.00000CA05B40.01
The LEC receives a CONNECT response from the BUS. The Multicast Send VC is established:
LEC ATM2/0.1: received CONNECT
LEC ATM2/0.1: callid 0x6114D354
LEC ATM2/0.1: vcd 153
The LEC receives a SETUP request from the BUS to set up the Multicast Forward VC:
LEC ATM2/0.1: received SETUP
LEC ATM2/0.1: callid 0x610D4230
LEC ATM2/0.1: called party 39.020304050607080910111213.00000CA05B40.01
LEC ATM2/0.1: calling_party 39.020304050607080910111213.00000CA05B42.01
A CONNECT_ACK is received from the ATM switch. The Multicast Forward VC is established:
LEC ATM2/0.1: received CONNECT_ACK
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
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
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
Enter configuration commands, one per line. End with CNTL/Z.
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
00:23:32:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWN
Router(config-subif)#
Router(config-subif)#
Router(config-subif)#
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# debug lane client mpoa
Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#int atm 1/1/0.1
Router(config-subif)#
Router(config-subif)#
Router(config-subif)#no shutdown
Router(config-subif)#
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
00:25:57:LEC ATM1/1/0.1:lec_append_mpoa_dev_tlv:
The following output is from the debug lane client mpoa command when the ATM major interface is
shut down:
Router# debug lane client mpoa
Router# conf t
Enter configuration commands, one per line. End with CNTL/Z.
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:%LANE-5-UPDOWN:ATM1/1/0.1 elan elan2:LE Client changed state to down
00:26:28:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWN
00:26:28:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWN
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:30:LANE ATM1/1/0:atm hardware reset
00:26:31:%LINEPROTO-5-UPDOWN:Line protocol on Interface ATM1/1/0, changed stat
e to down
Router(config-if)#
00:26:31:LEC ATM1/1/0.1:mpoa_to_lec:appl 6, opcode 0
The following output is from the debug lane client mpoa command when the ATM major interface is
started:
Router# debug lane client mpoa
Router# conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# int atm 1/1/0
Router(config-if)# no shutdown
00:26:32:LANE ATM1/1/0:atm hardware reset
00:26:32:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWN
00:26:34:%LINK-3-UPDOWN:Interface ATM1/1/0, changed state to down
00:26:34:LANE ATM1/1/0:atm hardware reset
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:LEC ATM1/1/0.1:mpoa_to_lec:appl 6, opcode 0
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
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
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,
LES/BUS, and LEC is shut down:
Router# debug lane server
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,
LES/BUS, and LEC is shut down:
Router# debug lane signaling
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
lvstate LANE_VCC_DROP_SENT
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
lvstate LANE_VCC_RELEASE_SENT
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
lvstate LANE_VCC_RELEASE_SENT
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
lvstate LANE_VCC_RELEASE_SENT
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
lvstate LANE_VCC_RELEASE_SENT
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
lvstate LANE_VCC_RELEASE_SENT
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: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTER
LANE SIG ATM1/0.2: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTER
LANE SIG ATM1/0.2: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTER
LANE SIG ATM1/0.3: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTER
LANE SIG ATM1/0.3: 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
LANE SIG ATM1/0.1: received ATM_CANCEL_NSAP for nsap
00.000000000000050000000000.000000000000.00
LANE SIG ATM1/0.2: received ATM_CANCEL_NSAP for nsap
00.000000000000050000000000.000000000000.00
LANE SIG ATM1/0.2: received ATM_CANCEL_NSAP for nsap
00.000000000000050000000000.000000000000.00
LANE SIG ATM1/0.3: received ATM_CANCEL_NSAP for nsap
00.000000000000050000000000.000000000000.00
LANE SIG ATM1/0.3: received ATM_CANCEL_NSAP for nsap
00.000000000000050000000000.000000000000.00
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.
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).
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.
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 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 T1 SABMSENT 1029508 2
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 T1 SABMSENT 1428720 0
Serial2: LAPB O SABMSENT (2) SABME P
Serial2: LAPB I SABMSENT (2) SABM P
Serial2: LAPB T1 SABMSENT 1431720 1
Serial2: LAPB O SABMSENT (2) SABME P
Serial2: LAPB I SABMSENT (2) SABM P
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
form of this command.
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
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
The second line of output describes a packet that is input to the router. Table 206 describes the fields in
this line.
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.
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.
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.
Examples The following is sample output from the debug lex rcmd command:
Router# debug lex rcmd
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
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
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
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
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
debug license
To enable controlled Cisco IOS software license debugging activity on a device, use the debug license
command in privileged EXEC mode.
debug license {agent {all | error} | core {all | error | event} | errors | events | ipc}
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
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.
debug list
To filter debugging information on a per-interface or per-access list basis, use the debug list command
in privileged EXEC mode. To disable debugging output, use the no form of this command.
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.
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
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 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 list 1102
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
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
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
Examples The following is sample output from the debug llc2 dynwind command:
Router# debug llc2 dynwind
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.
Examples The following is sample output from the debug llc2 errors command from a router ignoring an
incorrectly configured device:
Router# debug llc2 errors
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.
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
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
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
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
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
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.
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
As the output indicates, the debug lnm llc command output can vary somewhat in format.
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
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 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.
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
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.
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
LACK_STATE: 2489548, hashp 2AE628, old state = disconn, new state = awaiting
LLC2 open to finish
LACK_STATE: 2489548, hashp 2AE628, old state = awaiting LLC2 open to finish,
new state = connected
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
LACK_STATE: 2497640, hashp 2AE628, old state = disconn, new state = awaiting
LLC2 open to finish
LACK_STATE: 2497644, hashp 2AE628, old state = awaiting LLC2 open to finish,
new state = connected
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.
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
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
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
no form of this command.
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
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 MDFS_MROUTE_ADD for (0.0.0.0, 239.255.158.197)
01:31:03: MDSS: got MDFS_MROUTE_ADD for (192.1.21.6, 239.255.158.197)
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
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)#
Router(config-dspfarm-profile)#
Router(config-dspfarm-profile)# no shutdown
Router(config-dspfarm-profile)#
*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)#
Router(config-dspfarm-profile)# exit
Router(config)# exit
Examples The following is sample output from the debug media resource provisioning errors command:
Router# debug media resource provisioning errors
Examples The following is sample output from the debug media resource provisioning events command:
Router# debug media resource provisioning events
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.
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
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.
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
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
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/mgcp_parse_conn_mode(4780):[lvl=0]tmp_ptr:(recvonly)
*Sep 10 17:20:24.408:
//-1/xxxxxxxxxxxx/MGCP/mgcp_parse_conn_mode(4816):[lvl=0]tmp_ptr:(recvonly)
*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 endpoint-name {all [tracelevel {critical | moderate | verbose}] | errors |
events [tracelevel {critical | moderate | verbose}] | media [tracelevel {critical | moderate |
verbose}] | 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.
verboseDisplays all debug information. This is the default level.
Note This keyword is not available for errors or packets debugging.
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.
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:
//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_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:
//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_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:
//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_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
*Sep 10 17:46:13.112:
//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_ACTIVE, event EV_VOICE_MODE_DONE
*Sep 10 17:46:23.104:
//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_ACTIVE, event EV_MEDIA_EVT
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.
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.
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.
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 endpoint database debugging for all endpoints is on,
trace-level Verbose
Router#
*Sep 10 11:39:16.467: MGCP Packet received from 192.168.1.200:7979--->
CRCX 27 aaln/S2/SU1/1 MGCP 1.0
M: recvonly
C: 1
<---
*Sep 10 11:39:16.467:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_a(1339):[lvl=0]aaln/S2/SU1/1
*Sep 10 11:39:16.467:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_aaln_slot(1632):[lvl=0]2/SU1/1
*Sep 10 11:39:16.467:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_digit(1600):[lvl=0]2/SU1/1
*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:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_aaln_su(1773):[lvl=0]1/1
*Sep 10 11:39:16.467: //-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_digit(1600):[lvl=0]1/1
*Sep 10 11:39:16.467:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_aaln_port(1807):[lvl=0]1
*Sep 10 11:39:16.467: //-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_digit(1600):[lvl=0]1
*Sep 10 11:39:16.467: //-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_get_by_ifn(1326):[lvl=0]Entered
*Sep 10 11:39:16.467:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_get_tree_link_by_ifn(1145):[lvl=0]Entered
*Sep 10 11:39:16.467: //-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_compute_key(196):[lvl=0]type 2
slot 0002 subunit 0001
*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
<---
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
F: I
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.
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.
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.
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:
//-1/xxxxxxxxxxxx/MGCP/mgcp_count_active_mgc_msg_stat(240):[lvl=1]MGC stat -
192.168.1.200, total=18, succ=14, failed=2
*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:
//-1/xxxxxxxxxxxx/MGCP/mgcp_endpt_get_endpt_offset(2590):[lvl=0]endpt NULL
*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:
//-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 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()
*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
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.
Usage Guidelines This command enables GCFM debugging globally for all MGCP endpoints.
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.
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#
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.
Usage Guidelines 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.
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:
//-1/xxxxxxxxxxxx/MGCP/mgcp_count_active_mgc_msg_stat(240):[lvl=1]MGC stat -
192.168.1.200, total=22, succ=18, failed=2
*Sep 10 09:26:37.780: //-1/xxxxxxxxxxxx/MGCP/mgcp_parse_packet(316):[lvl=0]call
mgcp_parse_header
*Sep 10 09:26:37.784:
//-1/xxxxxxxxxxxx/MGCP/mgcp_val_mandatory_parms(12428):[lvl=0]Entered
*Sep 10 09:26:37.784:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_a(1339):[lvl=0]aaln/S2/SU1/1
*Sep 10 09:26:37.784:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_aaln_slot(1632):[lvl=0]2/SU1/1
*Sep 10 09:26:37.784:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_digit(1600):[lvl=0]2/SU1/1
*Sep 10 09:26:37.784:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_aaln_su(1773):[lvl=0]1/1
*Sep 10 09:26:37.784: //-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_digit(1600):[lvl=0]1/1
*Sep 10 09:26:37.784:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_aaln_port(1807):[lvl=0]1
*Sep 10 09:26:37.784: //-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_name_parse_digit(1600):[lvl=0]1
*Sep 10 09:26:37.784:
//-1/xxxxxxxxxxxx/MGCP/mgcp_endpt_get_endpt_offset(2590):[lvl=0]endpt NULL
*Sep 10 09:26:37.784: //-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_get_by_ifn(1326):[lvl=0]Entered
*Sep 10 09:26:37.784:
//-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_get_tree_link_by_ifn(1145):[lvl=0]Entered
*Sep 10 09:26:37.784: //-1/xxxxxxxxxxxx/MGCP/xgcp_endpt_compute_key(196):[lvl=0]type 2
slot 0002 subunit 0001
*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:
//-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 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]
*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
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.
Usage Guidelines This command enables media debugging globally for all MGCP endpoints. You can limit debugging to
a specific endpoint by using the debug mgcp endpoint command.
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.
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:
//-1/7BFBA9F9800B/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_process_quarantine_mode(6149):[lvl
=0]Q mode not found, Reset default values
*Sep 10 09:27:48.928:
//-1/7BFBA9F9800B/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_process_quarantine_mode(6168):[lvl
=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
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.
Usage Guidelines 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.
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
Router#
*Sep 10 11:51:41.863: MGCP Packet received from 192.168.1.200:7979--->
CRCX 34 aaln/S2/SU1/1 MGCP 1.0
X:57
M: nas/data
C:3
L:b:64, nas/bt:modem, nas/cdn:3000, nas/cgn:1000
C: 1
<---
Syntax Description input-hex (Optional) Displays MGCP incoming packets in hexadecimal format.
Usage Guidelines This command enables packet debugging globally for all MGCP endpoints. You can limit debugging to
a specific endpoint by using the debug mgcp endpoint command.
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.
Examples The following is sample output from the debug mgcp packets command:
Router# debug mgcp packets
Router#
*Sep 10 11:57:26.795: MGCP Packet received from 192.168.1.200:7979--->
CRCX 38 aaln/S2/SU1/1 MGCP 1.0
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
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
<---
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.
Usage Guidelines 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.
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#
*Sep 10 11:58:51.283: //-1/xxxxxxxxxxxx/MGCP/mgcp_parse_packet(316):[lvl=0]call
mgcp_parse_header
*Sep 10 11:58:51.283:
//-1/xxxxxxxxxxxx/MGCP/mgcp_parse_conn_mode(4780):[lvl=0]tmp_ptr:(recvonly)
*Sep 10 11:58:51.283:
//-1/xxxxxxxxxxxx/MGCP/mgcp_parse_conn_mode(4816):[lvl=0]tmp_ptr:(recvonly)
*Sep 10 11:58:51.283:
//-1/xxxxxxxxxxxx/MGCP/mgcp_val_mandatory_parms(12428):[lvl=0]Entered
*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
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.
Usage Guidelines 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.
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#
*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
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.
Usage Guidelines 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.
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
*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_CONNECTING new state=CALL_CONNECTING
*Sep 10 12:08:02.759:
//40/DE454D0E8015/MGCP|aaln/S2/SU1/1|-1|-1/<VOIP>/mgcp_set_call_state(7562):[lvl=2]callp(0
x63E311D0) old state=CALL_CONNECTING new state=CALL_CONFERENCING
*Sep 10 12:08:02.759:
//39/DE454D0E8015/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_set_call_state(7562):[lvl=2]callp(
0x63E313E0) old state=CALL_CONNECTING new state=CALL_CONFERENCING
*Sep 10 12:08:02.759:
//40/DE454D0E8015/MGCP|aaln/S2/SU1/1|-1|-1/<VOIP>/mgcp_set_call_state(7562):[lvl=2]callp(0
x63E311D0) old state=CALL_CONFERENCING new state=CALL_CONFERENCING
*Sep 10 12:08:02.763:
//39/DE454D0E8015/MGCP|aaln/S2/SU1/1|-1|-1/<VOICE>/mgcp_set_call_state(7562):[lvl=2]callp(
0x63E313E0) old state=CALL_CONFERENCING new state=CALL_ACTIVE
*Sep 10 12:08:02.763:
//40/DE454D0E8015/MGCP|aaln/S2/SU1/1|-1|-1/<VOIP>/mgcp_set_call_state(7562):[lvl=2]callp(0
x63E311D0) old state=CALL_CONFERENCING new state=CALL_ACTIVE
Command Default The default trace level for all MGCP debug commands is verbose.
Usage Guidelines 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 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
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
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
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.
Usage Guidelines 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.
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#
*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
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.
To disable debugging output, use the no form of this command.
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.
Release Modification
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.)
12.2(8)T This command was integrated into Cisco IOS Release 12.2(8)T.
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.
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 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
The following is sample output from the debug mgcp events command and keyword:
Router# debug mgcp events
The following is sample output from the debug mgcp media command and keyword:
Router# debug mgcp media
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
Router#
01:49:14:MGCP Packet received -
CRCX 58 S7/DS1-0/23 MGCP 1.0
X:57
M:nas/data
C:3
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:
Router# debug mgcp packets
The following is sample output from the debug mgcp parser command and keyword:
Router# debug mgcp parser
The following is sample output from the debug mgcp src command and keyword:
Router# debug mgcp src
00:14:08: 200 42 OK
<---
00:14:12: send_mgcp_msg, MGCP Packet sent --->
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
m=audio 16404 RTP/AVP 0
<---
00:14:13: MGCP Packet received -
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
L: a:G.711u,p:5,e:off,s:off
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
m=audio 16384 RTP/AVP 0
00:14:13: 200 48 OK
<---
00:14:20: MGCP Packet received -
00:14:20: 200 52 OK
<---
00:14:34: MGCP Packet received -
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: send_mgcp_msg, MGCP Packet sent --->
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.
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
The following example shows output from the debug mls rp ip multicast command using the event
keyword:
Router# debug mls rp ip multicast event
The following example shows output from the debug mls rp ip multicast command using the packet
keyword:
Router# debug mls rp ip multicast packet
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 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
the no form of this command.
Examples The following shows sample output from the debug mls rp ipx command:
Router# debug mls rp ipx
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
debugging output, use the no form of this 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:
Router# debug mmoip aaa
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
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:
Router# debug mmoip aaa
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
Syntax Description string E-mail address of the sender; for example, mailuser@mail-server.com.
There is no default.
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
Syntax Description string E.164 telephone number to be used for sending the test fax. There is no
default.
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
00:00:00.128:E0V1
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
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.
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.
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
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:
Router# debug modem csm
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
The following is sample output from the debug modem csm command for an incoming call:
Router# debug modem csm
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): Configure(0x5)
*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): Configure(0x0)
*Apr 7 12:39:42.531: Mica Modem(1/3): Configure(0x5)
*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.671: neat msg at slot 0: (0/0): Tx LOOP_CLOSURE (ABCD=1101)
*Apr 7 12:39:42.691: neat msg at slot 0: (1/0): Rx LOOP_CLOSURE (ABCD=1101)
*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: Mica Modem(1/0): Rcvd Digits Generated
*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)
*Apr 7 12:39:43.335: CSM_RX_CAS_EVENT_FROM_NEAT:(A001): EVENT_START_TX_TONE at slot 1
and port 0
*Apr 7 12:39:43.335: CSM_PROC_OC4_DIALING: CSM_EVENT_DSX0_START_TX_TONE at slot 1, 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)
*Apr 7 12:39:43.559: Mica Modem(1/3): Rcvd Digit detected(1)
*Apr 7 12:39:43.619: Mica Modem(1/3): Rcvd Digit detected(1)
*Apr 7 12:39:43.743: Mica Modem(1/3): Rcvd Digit detected(2)
*Apr 7 12:39:43.859: Mica Modem(1/3): Rcvd Digit detected(2)
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.
Router# debug modem csm
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
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.
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 ?
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.
Syntax Description slot/modem-port (Optional) The slot and modem port number.
group group-number (Optional) The modem group.
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
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
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
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 events
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
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
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 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
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
sequence number of the packet, time stamp, direction, layer, and payload bytes, followed by each byte
of the payload in hexadecimal.
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
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
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
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
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.
group group-number (Optional) The modem group.
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
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
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
debug modem
To observe modem line activity on an access server, use the debug modem command in privileged
EXEC mode. To disable debugging output, use the no form of this command.
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
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
Table 212 describes the significant fields shown in the sample display.
Field Description
add Adding an entry to the database.
update Updating the MAC address for an existing entry.
Field Description
10.10.0.1 Address of neighbor TSR.
Ethernet0/0/0 Connecting interface.
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.
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
Second, enable debugging of request and bind events, as shown in the command sequence below:
Router# debug mpls atm-cos ?
Third, configure an MPLS ATM subinterface for multi-VC mode. The corresponding request and bind
events are displayed, as shown below:
Router# conf terminal
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.
Examples The following shows sample output from the debug mpls atm-ldp api command:
Router# debug mpls atm-ldp api
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.
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
The following failure message displays when the LC-ATM fails to deallocate the output leg LVC of a
cross connect:
Router# debug mpls atm-ldp failure
The following failure message displays when a cross connect cannot be installed on the switching fabric.
The result code is also provided.
Router# debug mpls atm-ldp failure
The following message displays when attempts to establish a cross connect fail. The result describes the
reason for the failure.
Router# debug mpls atm-ldp failure
The following message displays when attempts to remove a cross connect fail. The result describes why
the cross connect cannot be removed.
Router# debug mpls atm-ldp failure
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.
Examples The following shows sample output from the debug mpls atm-ldp routes command:
Router# debug mpls atm-ldp routes
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.
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.
Examples The following shows sample output from the debug mpls atm-ldp states command:
Router# debug mpls atm-ldp states
Field Description
Transit Output Output side of an LVC.
VPI/VCI VC value.
Transit Input Input side of an LVC.
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
Examples The following is sample output from the debug mpls events command:
Router# debug mpls events
debug mpls ip iprm cef [table {all | table-id} | vrf vrf-name | acl acl-name | prefix-list
prefix-list-name]
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.
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.
...
iprm: discover prefix labels: 10.0.0.44/32(glbl); recurs tree change; ctxt 0x38000
See the field descriptions for the debug mpls ip iprm command for an explanation of the fields
displayed in the output.
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 ldm [bgp | lcatm | ldp | vpnv4 | 6pe | table {all | table-id} | vrf vrf-name | acl
acl-name | prefix-list prefix-list-name]
debug mpls ip iprm ldm [bgp | ldp | vpnv4 | table {all | table-id} | vrf vrf-name | acl acl-name |
prefix-list prefix-list-name]
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 (Optional) Displays debugging information for the prefix list you specify.
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.
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 mfi [table {all | table-id} | vrf vrf-name | acl acl-name | prefix-list
prefix-list-name]
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 (Optional) Displays debugging information for the prefix list you specify.
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.
See the debug mpls ip iprm command page for an explanation of the fields displayed in the output.
Examples The command in the following examples display all IPRM debugging for the global routing table.
iprm: discover prefix labels: 10.0.0.44/32(glbl); recurs tree change; ctxt 0x38000
iprm: get mfi rewrite 10.0.0.44/32(glbl) obtained: 0 fpis/0 mois
iprm: announce prefix local labels: lcatm; trans #81; 10.0.0.44/32(glbl); 0 labels;
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
iprm: announce prefix local labels: ldp; trans #81; 10.0.0.44/32(glbl); 1 label; flags
0x0
iprm: lab 21, ltbl 0
iprm: announce path labels: ldp; trans #81; 10.0.0.44/32(glbl); 0 labels; flags 0x0
iprm: path: nh 59.0.0.55(glbl), Et4/0/1
iprm: update mfi rewrite: 10.0.0.44/32(glbl); prefix label info
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)
Table 216 describes the significant fields shown in the display. The field descriptions also apply to the
output of following debug commands:
debug mpls ip iprm cef
debug mpls ip iprm events
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.
Field Description
ltbl Label table.
nsf Nonstop forwarding.
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# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface Fa5/1/1.2
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...
%OIR-6-REMCARD: Card removed from slot 4, interfaces disabled
%OIR-6-REMCARD: Card removed from slot 5, interfaces disabled
%OIR-6-REMCARD: Card removed from slot 9, 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
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
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
*May 27 23:56:04.699 UTC: AToM SMGR [17.17.17.17, 701]: Distributing disposition info to
all linecards
*May 27 23:56:04.699 UTC: AToM SMGR [17.17.17.17, 1201]: Sending Imposition update to slot
255
*May 27 23:56:04.699 UTC: AToM SMGR [17.17.17.17, 1201]: Imposition being done on ingress
interface
*May 27 23:56:04.699 UTC: AToM SMGR [17.17.17.17, 1201]: Sending disposition update to
slot 255
*May 27 23:56:04.699 UTC: AToM SMGR [17.17.17.17, 1201]: Distributing disposition info to
all linecards
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:
AToM packet data debugging is on
AToM packet errors debugging is on
*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
*Mar 24 23:29:49.471: ATOM-PPP Switching: check features failed.
*Mar 24 23:29:49.471: ATOM-PPP Switching (Fast) Imposition Packet data: experimental bits
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
*Mar 24 23:29:49.475: ATOM-PPP Switching: check features failed.
Examples The following is sample output from the debug mpls l2transport signaling command:
Router# debug mpls l2transport signaling event
AToM:
AToM LDP event debugging is on
AToM LDP message debugging is on
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.
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
AToM:
AToM vc event debugging is on
AToM vc fsm debugging is on
*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
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
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.
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
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.
Syntax Description interface interface (Optional) Enables the display of autoconfiguration events for the specified
interface.
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
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: 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 0x8, handle 0x1AADBE0]:: Received enable request
for Et0/0; area/level=2
07:49:02: LDP-AC: ISIS level 1-2 [flags 0x8, handle 0x1AADBE0]:: Received enable request
for Et0/0; area/level=2
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.
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
Router#
Jan 6 22:31:13.012: ldp: Backoff peer ok: 12.12.12.12:0; backing off; threshold/count 8/6
Jan 6 22:31:13.824: ldp: Backoff peer ok: 12.12.12.12:1; backing off; threshold/count 8/6
Jan 6 22:31:17.848: ldp: Backoff peer ok: 12.12.12.12:0; backing off; threshold/count 8/6
Jan 6 22:31:18.220: ldp: Backoff peer ok: 12.12.12.12:1; backing off; threshold/count 8/6
Jan 6 22:31:21.908: ldp: Backoff peer ok: 12.12.12.12:0; backing off; threshold/count 8/6
Jan 6 22:31:22.980: ldp: Backoff peer ok: 12.12.12.12:1; backing off; threshold/count 8/6
Jan 6 22:31:25.724: ldp: Backoff peer ok: 12.12.12.12:0; backing off; threshold/count 8/7
Jan 6 22:31:26.944: ldp: Backoff peer ok: 12.12.12.12:1; backing off; threshold/count 8/7
Jan 6 22:31:30.140: ldp: Backoff peer ok: 12.12.12.12:0; backing off; threshold/count 8/7
Jan 6 22:31:31.932: ldp: Backoff peer ok: 12.12.12.12:1; backing off; threshold/count 8/7
Jan 6 22:31:35.028: ldp: Backoff peer ok: 12.12.12.12:0; backing off; threshold/count 8/7
Jan 6 22:31:35.788: ldp: Backoff peer ok: 12.12.12.12:1; backing off; threshold/count 8/7
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
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.
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.
Release Modification
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.
12.2(33)SB This command was integrated into Cisco IOS Release 12.2(33)SB.
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
Field Description
tagcon: Identifies the source of the message as the label control subsystem.
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.
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(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: Withdraw local label for 10.10.8.0
LDP LLAF: Withdraw local label for 10.10.9.0
Router(config-ldp-lbl)#
LDP LLAF: announce zero local and path labels: 10.10.7.0
LDP LLAF: announce zero local and path labels: 10.10.8.0
LDP LLAF: announce zero local and path labels: 10.10.9.0
Router(config-ldp-lbl)#
Router(config-ldp-lbl)# no allocate global host-routes
Router(config-ldp-lbl)#
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
tib: get path labels: 10.2.2.2/32, tableid: 0, Et2/0, nh 10.10.8.2
LDP LLAF: 10.2.2.2 accepted, absence of filtering config
tagcon: announce labels for: 10.2.2.2/32; nh 10.10.8.2, Et2/0, inlabel 16, outlabel
imp-null (from 10.2.2.2:0), get path labels
tib: get path labels: 10.10.7.0/24, tableid: 0, Et1/0, nh 0.0.0.0
LDP LLAF: 10.10.7.0 accepted, absence of filtering config
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
tib: get path labels: 10.10.8.0/24, tableid: 0, Et2/0, nh 0.0.0.0
LDP LLAF: 10.10.8.0 accepted, absence of filtering config
tagcon: tibent(10.10.8.0/24): label 1 (#21) assigned
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
tib: get path labels: 10.10.9.0/24, tableid: 0, Et1/0, nh 10.10.7.2
LDP LLAF: 10.10.9.0 accepted, absence of filtering config
tagcon: tibent(10.10.9.0/24): label 22 (#22) assigned
tagcon: announce labels for: 10.10.9.0/24; nh 10.10.7.2, Et1/0, inlabel 22, outlabel
imp-null (from 10.1.1.1:0), get path labels
.
.
.
Router(config-ldp-lbl)# no mpls ldp label
Router(config-ldp-lbl)# end
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.
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.
Usage Guidelines The following examples show sample output from the debug mpls ldp checkpoint command:
Table 221 describes the significant fields in the sample display shown above.
Field Description
0:3.3.3.3/32,20:: The table ID, prefix, prefix length, and label of the checkpointed label
binding.
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
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.
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).
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:
Router# debug mpls ldp igp sync
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.
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:
Router# debug mpls ldp igp sync
*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
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.
Release Modification
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 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
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.
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
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
Field Description
tagcon: Identifies the source of the message as the label control subsystem.
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.
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.
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
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.
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.
Usage Guidelines Displays the contents of all messages sent and received except for periodic KeepAlive messages.
Examples The following shows sample output from the debug mpls ldp session io command:
Router# debug mpls ldp session io all
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.
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
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
Syntax Description peer-acl acl (Optional) Limits the displayed information to that for LDP peers permitted
by the access control list (acl).
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
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
Field Description
ldp: Identifies the source of the message as LDP.
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.
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).
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
Field Description
ldp-trgtnbr: Identifies this as an LDP targeted neighbor debug statement.
144.0.0.44 IP address for the targeted neighbor.
Syntax Description peer-acl acl (Optional) Limits the displayed information to that for LDP peers permitted
by the access control list (acl).
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.
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
Field Description
ldp: Identifies the source of the message as LDP.
adj 0xnnnnnnnn Identifies the data structure used to represent the peer at the transport level.
Useful for correlating debug output.
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.
Syntax Description peer-acl acl (Optional) Limits the displayed information to that for LDP peers permitted
by the access control list (acl).
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.
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
Field Description
ldp: Identifies the source of the message as LDP.
adj 0xnnnnnnnn Identifies the data structure used to represent the peer at the transport level.
Useful for correlating debug output.
a.b.c.d (p.q.r.s:n) Network address and LDP identifier of the peer.
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)
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
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.
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.
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.
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
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.
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
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 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
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.
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 reroutes command. The output of this command increases in
proportion to the number of tunnels that utilize fast reroute.
Examples The following is sample output from the debug mpls lfib lsp command:
Router# debug mpls lfib lsp
On VIP:
TFIB: tagtun chg msg,in tg=35,o tg=1,nh=10.93.72.13,if=7
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 chg msg,in tg=36,o tg=1,nh=10.92.0.7,if=6
TFIB: tsptunnel:next hop=10.92.0.7,inc=36,outg=Imp_null,if_number=6
TFIB: tsptun update loadinfo:tag=36,loadinfo_reqd=0,no new loadinfo,no old loadinfo
TFIB: tagtun chg msg,in tg=35,o tg=1,nh=10.93.72.13,if=7
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 chg msg,in tg=36,o tg=1,nh=10.92.0.7,if=6
TFIB: tsptunnel:next hop=10.92.0.7,inc=36,outg=Imp_null,if_number=6
TFIB: tsptun update loadinfo:tag=36,loadinfo_reqd=0,no new loadinfo,no old loadinfo
TFIB: tagtun chg msg,in tg=35,o tg=1,nh=10.92.0.7,if=6
TFIB: tsptunnel:next hop=10.92.0.7,inc=35,outg=Imp_null,if_number=6
TFIB: tsptun update loadinfo:tag=35,loadinfo_reqd=0,no new loadinfo,no old loadinfo
Table 235 describes the significant fields shown in the sample display.
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.
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
On linecard only:
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
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
Examples The following is sample output from the debug mpls lfib struct command:
Router# debug mpls lfib struct
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 lspv [tlv] [error] [event] [ipc] [packet [data | error]] [path-discovery] [multipath]
[all]
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.
Release Modification
12.2(33)SXH This command was integrated into Cisco IOS Release 12.2(33)SXH.
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 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
Examples The following is sample output from the ping mpls command when LSPV event debugging is enabled:
Router# debug mpls lspv event
The following is sample output from the ping mpls command when LSPV TLV debugging is enabled:
Router# debug mpls lspv tlv
The following is sample output from the trace mpls multipath command when LSPV multipath
debugging is on:
Router# debug mpls lspv multipath
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#
4d00h:Egress flow:entry created, dest 3.3.3.3/32, src 42.42.42.42/32
Router# conf t
Enter configuration commands, one per line. End with CNTL/Z.
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
4d00h:tfib_scanner_walk, prefix 2.0.0.0/8, rewrite flow flag 0
4d00h:tfib_scanner_walk, prefix 3.3.3.3/32, rewrite flow flag 0
4d00h:tfib_scanner_walk, prefix 40.40.40.40/32, rewrite flow flag 0
4d00h:tfib_scanner_walk, prefix 50.50.50.50/32, rewrite flow flag 0
4d00h:tfib_scanner_walk, prefix 100.100.100.100/32, rewrite flow flag 0
4d00h:tfib_scanner_walk, prefix 180.1.1.0/24, rewrite flow flag 0
4d00h:tfib_scanner_walk, prefix 190.1.1.0/24, rewrite flow flag 1
4d00h:tfib_scanner_walk, prefix 2.0.0.0/8, rewrite flow flag 1
4d00h:tfib_scanner_walk, prefix 4.4.4.4/32, rewrite flow flag 1
4d00h:tfib_scanner_walk, prefix 40.40.40.40/32, rewrite flow flag 0
4d00h:tfib_scanner_walk, prefix 50.50.50.50/32, rewrite flow flag 0
4d00h:tfib_scanner_walk, prefix 177.1.1.0/24, rewrite flow flag 1
4d00h:tfib_scanner_walk, prefix 180.1.1.0/24, rewrite flow flag 0
4d00h:tfib_scanner_walk, prefix 190.1.1.0/24, rewrite flow flag 1
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
4d00h:tfib_scanner_walk, prefix 5.5.5.5/32, rewrite flow flag 0
4d00h:tfib_scanner_walk, prefix 2.0.0.0/8, rewrite flow flag 1
4d00h:tfib_scanner_walk, prefix 3.3.3.3/32, rewrite flow flag 1
4d00h:tfib_scanner_walk, prefix 40.40.40.40/32, rewrite flow flag 0
4d00h:tfib_scanner_walk, prefix 50.50.50.50/32, rewrite flow flag 0
4d00h:tfib_scanner_walk, prefix 100.100.100.100/32, rewrite flow flag 1
4d00h:tfib_scanner_walk, prefix 180.1.1.0/24, rewrite flow flag 1
4d00h:tfib_scanner_walk, prefix 190.1.1.0/24, rewrite flow flag 1
4d00h:tfib_scanner_walk, prefix 2.0.0.0/8, rewrite flow flag 1
4d00h:tfib_scanner_walk, prefix 4.4.4.4/32, rewrite flow flag 1
4d00h:tfib_scanner_walk, prefix 40.40.40.40/32, rewrite flow flag 0
4d00h:tfib_scanner_walk, prefix 50.50.50.50/32, rewrite flow flag 0
4d00h:tfib_scanner_walk, prefix 177.1.1.0/24, rewrite flow flag 1
4d00h:tfib_scanner_walk, prefix 180.1.1.0/24, rewrite flow flag 1
4d00h:tfib_scanner_walk, prefix 190.1.1.0/24, rewrite flow flag 1
4d00h:Egress flow:entry created, dest 3.3.3.3/32, src 42.42.42.42/32
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#
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.
Defaults The debug output displays all labeled packets, regardless of the interface.
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
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.
Syntax Description vrf vpn-name Displays information only for the specified VPN routing and forwarding
(Optional) instance (vpn-name).
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
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 static label binding for 10.0.0.1/8
00:15:13: mpls: Add remote static binding: 10.0.0.1/8; label 2607; nexthop 172.17.0.66:0
00:15:13: mpls: Add static label binding for 172.18.0.0/16
00:15:18: mpls: Periodic static label adjust
00:15:18: mpls: Static label update: 10.0.0.0/8
Examples In the following example, information is printed about traffic engineering area configuration change
events:
Router# debug mpls traffic-eng areas
Examples In the following example, information is printed about automatic routing over traffic engineering
tunnels:
Router# debug mpls traffic-eng autoroute
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.
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
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.
Examples In the following example, debugging information is printed about system events of primary autotunnels:
Router# debug mpls traffic-eng auto-tunnel primary events
In the following example, debugging information is printed about the system state of primary
autotunnels:
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
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
When the tunnel comes up, it generates the following debug output:
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
engineering SSO process.
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
engineering SSO process.
Command Default Debugging is disabled until you issue this command with one or more keywords.
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
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
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
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
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
Reservable Bandwidth[1]: 2000 kbits/sec
Reservable Bandwidth[2]: 2000 kbits/sec
Reservable Bandwidth[3]: 2000 kbits/sec
Reservable Bandwidth[4]: 2000 kbits/sec
Reservable Bandwidth[5]: 2000 kbits/sec
Reservable Bandwidth[6]: 2000 kbits/sec
Attribute Flags: 0x00000000
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.
Examples In the following example, information is printed about bandwidth allocation for traffic engineering
LSPs:
Router# debug mpls traffic-eng link-management bandwidth-allocation
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
Command Description
debug mpls traffic-eng link-management events Prints information about traffic engineering link
management system events.
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.
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
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
Examples In the following example, detailed debugging information is printed about traffic engineering link
management interface events:
Router# debug mpls traffic-eng link-management links 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
Examples In the following example, detailed debugging information is printed about traffic engineering link
management routing resolutions that can be performed to help RSVP interpret explicit route objects:
Router# debug mpls traffic-eng link-management routing detail
Examples In the following example, information is printed about unequal cost load balancing over traffic
engineering tunnels:
Router# debug mpls traffic-eng load-balancing
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
The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command
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
The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command
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
The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command
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
The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command
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
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 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
The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command,
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
The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command,
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
The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command
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
The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command
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
The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command
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
The following messages are displayed when you issue the debug mpls traffic-eng lsd-client command
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
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
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: TE ION Restart timer started, proc_idx:0 delay:300000
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)
02:24:22: TE ION Restart timer started, proc_idx:0 delay:900000
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.
Examples In the following example, information is printed about traffic engineering topology change events:
Router# debug mpls traffic-eng topology change
Examples In the following example, information is printed about traffic engineering topology LSA events:
Router# debug mpls traffic-eng topology lsa
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
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
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
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
Examples In the following example, detailed debugging information is printed about traffic engineering tunnel
reoptimizations that match access list number 101:
Router# debug mpls traffic-eng tunnels reoptimize detail 101
Examples In the following example, detailed debugging information is printed about traffic engineering tunnel
signalling operations that match access list number 101:
Router# debug mpls traffic-eng tunnels signalling detail 101
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
Examples In the following example, detailed debugging information is printed about traffic engineering tunnel
timer management:
Router# debug mpls traffic-eng tunnels timers detail
Usage Guidelines The following example shows sample output from the debug mpls vpn ha command:
Router# debug mpls vpn ha
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
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.
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.
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
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.
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
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.
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.
Examples The following shows how to turn on debugging for the MPC ip_mpc:
ATM# debug mpoa client all name ip_mpc
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
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}
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_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_add_param:param:Content-Base:
*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.323:mrcp_add_param:param:Logging-Tag:
*Apr 17 16:31:16.327:mrcp_add_param:param:Content-Base:
*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_add_param:param:Logging-Tag:
*Apr 17 16:31:26.715:mrcp_add_param:param:Content-Base:
*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
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-Base:http://server-asr/
*Apr 17 16:32:51.889:Content-Type:application/synthesis+ssml
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_parse_response:Length:31
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:No Of Properties:0
*Apr 17 16:32:51.933:mrcp_process_recog_response:
*Apr 17 16:32:53.413:mrcp_pmh_parse_response:Length:31
Apr 17 16:32:53.413:mrcp_pmh_get_request_line:Line:MRCP/1.0 18 200 IN-PROGRESS
*Apr 17 16:32:53.413:Request-tag:18 resp-code:200 Status:IN-PROGRESS
*Apr 17 16:32:53.413:No Of Properties:0
*Apr 17 16:32:53.413:mrcp_process_synth_response:
*Apr 17 16:33:01.685:mrcp_pmh_parse_response:Length:100
Apr 17 16:33:01.689:mrcp_pmh_get_event_line:Line:SPEAK-COMPLETE 18 COMPLETE MRCP/1.0
*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-Base:http://server-asr/
*Apr 17 16:33:02.665:Content-Type:application/synthesis+ssml
Content-Length:57
*Apr 17 16:33:02.833:mrcp_pmh_parse_response:Length:31
Apr 17 16:33:02.833:mrcp_pmh_get_request_line:Line:MRCP/1.0 22 200 IN-PROGRESS
*Apr 17 16:33:02.833:Request-tag:22 resp-code:200 Status:IN-PROGRESS
*Apr 17 16:33:02.833:No Of Properties:0
*Apr 17 16:33:02.833:mrcp_process_synth_response:
*Apr 17 16:33:06.382:mrcp_pmh_parse_response:Length:98
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:Request-tag:22 resp-code:200 Status:COMPLETE
*Apr 17 16:33:06.382:No Of Properties:2
*Apr 17 16:33:06.382:mrcp_process_synth_events:
*Apr 17 16:33:06.382: COMPLETION-CAUSE:0
*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
The following example shows output from the debug mrcp state command:
Router# debug mrcp state
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
*Apr 17 16:35:25.145:mrcp_shortcut_connection_fsm
*Apr 17 16:35:25.149:mrcp_fsm_execute:type=SYNTHESIZER
*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:mrcp_fsm_execute:type=SYNTHESIZER
*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:mrcp_fsm_execute:type=SYNTHESIZER
*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:mrcp_fsm_execute:type=SYNTHESIZER
*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:mrcp_fsm_execute:type=RECOGNIZER
*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:mrcp_fsm_execute:type=RECOGNIZER
*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:mrcp_fsm_execute:type=SYNTHESIZER
*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:mrcp_fsm_execute:type=SYNTHESIZER
*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:hash_delete: key=30
*Apr 17 16:35:32.805:mrcp_fsm_execute:type=SYNTHESIZER
*Apr 17 16:35:32.805: curr[SPEAKING] ev-id[SPEECH_COMPLETE]
next[SYNTH_IDLE] action=610BAA680
*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:mrcp_fsm_execute:type=RECOGNIZER
*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:hash_delete: key=32
*Apr 17 16:35:33.781:mrcp_fsm_execute:type=RECOGNIZER
*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:mrcp_fsm_execute:type=SYNTHESIZER
*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:mrcp_fsm_execute:type=SYNTHESIZER
*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:hash_delete: key=34
*Apr 17 16:35:37.221:mrcp_fsm_execute:type=SYNTHESIZER
*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.245:mrcp_fsm_execute:type=SYNTHESIZER
*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:mrcp_fsm_execute:type=SYNTHESIZER
*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
:
<?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>one</item>
<item>two</item>
</one-of>
</rule>
</grammar>
*Sep 1 21:37:53.708: //-1//MRCP:/MRCPV2_ADD_REQUEST_LINE:
IsFinal=FALSE;TotalLength=160
*Sep 1 21:37:53.708: //-1//MRCP:/MRCPV2_ADD_HEADER:
TotalLength=82
*Sep 1 21:37:53.708: //-1//MRCP:/MRCPV2_ADD_REQUEST_LINE:
IsFinal=TRUE;TotalLength=499:
MRCP/2.0 499 RECOGNIZE 2
Channel-Identifier: 0000251844F8ACAD@speechrecog
:
Speech-Language: en-US
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
Content-Base: http://http-server1/php/
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
Channel-Identifier: 0000251844F8ACAD@speechrecog
:
MRCP/2.0 83 2 200 IN-PROGRESS
Channel-Identifier: 0000251844F8ACAD@speechrecog
:
MRCP/2.0 80 3 200 COMPLETE
Channel-Identifier: 0000251844F8ACAD@speechrecog
:
MRCP/2.0 148 START-OF-INPUT 2 IN-PROGRESS
Channel-Identifier: 0000251844F8ACAD@speechrecog
Proxy-Sync-Id: 0F1F813000000148
Input-Type: speech
:
MRCP/2.0 589 RECOGNITION-COMPLETE 2 COMPLETE
Channel-Identifier: 0000251844F8ACAD@speechrecog
Proxy-Sync-Id: 0F1F813000000148
Completion-Cause: 000 success
Content-Type: application/nlsml+xml
Content-Length: 369
:
<?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>
*Sep 1 21:37:59.588: //-1//MRCP:/MRCPV2_ADD_REQUEST_LINE:
IsFinal=FALSE;TotalLength=160
*Sep 1 21:37:59.588: //-1//MRCP:/MRCPV2_ADD_HEADER:
TotalLength=82
*Sep 1 21:37:59.588: //-1//MRCP:/MRCPV2_ADD_REQUEST_LINE:
IsFinal=TRUE;TotalLength=499:
MRCP/2.0 499 RECOGNIZE 2
Channel-Identifier: 00001FEC44F8AA93@speechrecog
:
Speech-Language: en-US
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
Logging-Tag: 68:68
Content-Base: http://http-server1/php/
Media-Type: audio/basic
Start-Input-Timers: false
:
Content-Type: text/uri-list
Content-Length: 31
:
session:field25@field.grammar
:
MRCP/2.0 80 1 200 COMPLETE
Channel-Identifier: 00001FEC44F8AA93@speechrecog
:
MRCP/2.0 83 2 200 IN-PROGRESS
Channel-Identifier: 00001FEC44F8AA93@speechrecog
:
MRCP/2.0 80 3 200 COMPLETE
Channel-Identifier: 00001FEC44F8AA93@speechrecog
:
MRCP/2.0 148 START-OF-INPUT 2 IN-PROGRESS
Channel-Identifier: 00001FEC44F8AA93@speechrecog
Proxy-Sync-Id: 0925248800000011
Input-Type: speech
:
MRCP/2.0 589 RECOGNITION-COMPLETE 2 COMPLETE
Channel-Identifier: 00001FEC44F8AA93@speechrecog
Proxy-Sync-Id: 0925248800000011
Completion-Cause: 000 success
Content-Type: application/nlsml+xml
Content-Length: 369
The following example shows output from the debug mrcp socket command:
Router# debug mrcp socket
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.
Examples The following is sample output from the debug mspi receive command:
Router# 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
Jan 1 05:09:54.126: mspi_offramp_send_buffer: cid=0x1F, mime=11
Jan 1 05:09:54.134: mspi_offramp_send_buffer: cid=0x1F, mime=11
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.
Examples The following is sample output from the debug mspi send command:
Router# debug mspi send
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
form of this command.
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
To display output for all of the on-ramp client connections, use the debug mta send all command in
privileged EXEC mode. To disable debugging output, use the no form of this command.
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
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
debugging output, use the no form of this command.
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
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
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
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
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
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
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.
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
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
Field Description
WAN Event from WAN (client).
Field Description
DLU Event from upstream moduledependent logical unit (DLU).
ADMIN Administrative event.
TIMER Timer event.
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]]
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.
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: 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: 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.
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.
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
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
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
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
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
debug netbios-name-cache
To display name caching activities on a router, use the debug netbios-name-cache command in
privileged EXEC mode. To disable debugging output, use the no form of this command.
debug netbios-name-cache
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
Note The sample display is a composite output. Debugging output that you actually see would not necessarily
occur in this sequence.
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.
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
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 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.
Syntax Description all Enables debugging of NETCONF sessions, including NETCONF errors.
error Enables debugging of NETCONF errors.
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
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.
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 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]}
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
Examples The following example shows how to enable error level debugging for NHRP:
Router# debug nhrp error
NHRP errors debugging is on
Examples The following is sample output from the debug nhrp extension command:
Router# debug nhrp extension
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
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.
Examples The following is sample output from the debug nhrp packet command:
Router# debug nhrp packet
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
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
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
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.
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 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}
debug oam
To display operation and maintenance (OAM) events, use the debug oam command in privileged EXEC
mode. To disable debugging output, use the no form of this command.
debug oam
no debug oam
Examples The following is sample output from the debug oam command:
Router# debug oam
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.
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
*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.
Field Description
OER api debugging is on Shows that application interface debugging is enabled.
OER API Displays an OER application interface message.
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
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
probeIfIndex = 13
*May 4 23:47:45.693: OER BR ACTIVE PROBE: Completed retrieving Probe
Statistics.
probeType = echo, probeTarget = 10.1.4.1, probeTargetPort = 0
probeSource = Default, probeSourcePort = 0, probeNextHop = 10.30.30.2
probeIfIndex = 13, SAA index = 14
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.
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.
Examples The following example enables the display of active-probe debug information on a border router:
Router# debug oer border learn
Field Description
OER BR LEARN: Indicates debugging information for the OER border router
learning process.
Syntax Description bgp Displays debugging information for only BGP routes.
static Displays debugging information for only static routes.
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.
Examples The following example enables the display of active-probe debug information on a border router:
Router# debug oer border routes
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.)
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.
Examples The following example enables the display of active-probe debug information on a border router:
Router# debug oer border traceroute reporting
Field Description
OER BR TRACE: Indicates border router debugging information for traceroute probes.
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.
*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
Field Description
OER BR: Indicates debugging information for OER Border process.
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.
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
Field Description
OER CC: Indicates debugging information for OER communication
messages.
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
Field Description
OER MC BR ip-address: Indicates debugging information for a border router process.
The ip-address identifies the border router.
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.
*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 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
Field Description
OER MC APC: Indicates debugging information for active probes from the r
OER master collector.
*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
*May 4 22:36:22.313: OER MC APC: Active OOP check done
Table 262 debug oer master collector active-probes detail Field Descriptions
Field Description
OER MC APC: Indicates debugging information for active probes from the r
OER master collector.
*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
*May 4 22:40:33.885: OER MC APC: Remote stats received: BR 10.2.2.2, Type
echo, Tgt 10.1.5.1, TgtPt 0, Src Default, SrcPt 0, NxtHp Default, Ndx 13
*May 4 22:40:34.197: OER MC APC: Remote stats received: BR 10.2.2.2, Type
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,
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
*May 4 22:40:34.197: OER MC APC: Active OOP check done
Table 263 debug oer master collector active-probes detail trace Field Descriptions
Field Description
OER MC APC: Indicates debugging information for active probes from the r
OER master collector.
Field Description
OER MC NFC: Indicates debugging information for the OER master
collector from passive monitoring (NetFlow).
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
Field Description
OER MC COST: Indicates debugging information for cost-based optimization on the master
controller.
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
Field Description
OER MC EXIT: Indicates OER master controller exit event.
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:19:14: OER MC LEARN: OER TTC: State change, new SLEEP, old WRITING DATA, reason
Sleep state
Field Description
OER MC LEARN: Indicates OER master controller learning events.
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
06:05:59: OER MC PFX 10.4.9.0/24: APC last target deleted for prefix, no targets
left assigned and running
06:06:09: OER MC PFX 10.4.9.0/24: APC Attempting to probe all exits
Field Description
OER MC PFX ip-address: Indicates debugging information for OER monitored
prefixes. The ip-address identifies the prefix.
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
Field Description
OER MC PFX ip-address: Indicates debugging information for OER monitored
prefixes. The ip-address identifies the prefix.
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
Field Description
OER MC PROCESS: Indicates a master controller master process debugging
message.
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
Table 271 debug oer master traceroute reporting detail Field Descriptions
Field Description
OER MC PROCESS: Indicates master controller debugging information for
traceroute probes.
debug packet
To display per-packet debugging output, use the debug packet command in privileged EXEC mode. To
disable debugging output, use the no form of this command.
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.
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
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
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
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.
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.
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
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
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
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
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.
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.
debug pots
To display information on the telephone interfaces, use the debug pots command in privileged EXEC
mode. To disable debugging output, use the no form of this command.
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
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
Examples To see debugging messages, enter the logging console global configuration mode command as follows:
Router(config)# logging console
Router(config)# exit
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 278 shows the values for events that are translated into CSM events.
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
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.
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#
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
01:58:27: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_DIGIT, call id = 0x0, port = 1
01:58:27: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_DIGIT, call id = 0x0, port = 1
01:58:27: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_DIGIT, call id = 0x0, port = 1
01:58:27: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_DIGIT, call id = 0x0, port = 1
01:58:27: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_DIGIT, call id = 0x0, port = 1
01:58:27: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_DIGIT, call id = 0x0, port = 1
01:58:27: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_DIGIT, call id = 0x0, port = 1
01:58:27: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_DIGIT, call id = 0x0, port = 1
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,
event=0x3, cause=0x0
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,
event=0x5, cause=0x0
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: EVENT_FROM_ISDN:dchan_idb=0x280AF38, call_id=0x8004, ces=0x1 bchan=0xFFFFFFFF,
event=0x4, cause=0x0
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: EVENT_FROM_ISDN:dchan_idb=0x280AF38, call_id=0x8004, ces=0x1 bchan=0xFFFFFFFF,
event=0x5, cause=0x10
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: EVENT_FROM_ISDN:dchan_idb=0x280AF38, call_id=0x8004, ces=0x1 bchan=0xFFFFFFFF,
event=0x0, cause=0x0
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# debug pots csm
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:
01:59:42: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_DIGIT, call id = 0x0, port = 1
01:59:42: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_DIGIT, call id = 0x0, port = 1
01:59:42: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_DIGIT, call id = 0x0, port = 1
01:59:42: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_DIGIT, call id = 0x0, port = 1
01:59:42: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_DIGIT, call id = 0x0, port = 1
01:59:42: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_DIGIT, call id = 0x0, port = 1
01:59:42: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_DIGIT, call id = 0x0, port = 1
01:59:42: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_DIGIT, call id = 0x0, port = 1
01:59:42: CSM_PROC_APPLIC_DIALING: CSM_EVENT_VDEV_DIGIT, call id = 0x0, port = 1
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,
event=0x3, cause=0x11
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: EVENT_FROM_ISDN:dchan_idb=0x280AF38, call_id=0x8005, ces=0x1 bchan=0xFFFFFFFF,
event=0x5, cause=0x0
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: EVENT_FROM_ISDN:dchan_idb=0x280AF38, call_id=0x8005, ces=0x1 bchan=0xFFFFFFFF,
event=0x0, cause=0x0
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# debug pots csm
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_DIGIT, 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_DIGIT, 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_DIGIT, 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_DIGIT, 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_DIGIT, call id = 0x0, port = 1
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
1d03h: EVENT_FROM_ISDN:dchan_idb=0x2821F38, call_id=0x8039, ces=0x1
bchan=0xFFFFFFFF, event=0x0, cause=0x0
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).
The following is sample output from the debug ppp bap command:
Router# debug ppp bap
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
The following is sample output from the debug ppp bap event command:
Router# debug ppp bap event
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
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
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"
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.
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.
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
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.
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
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
EXEC mode. To disable debugging output, use the no form of this command.
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
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.
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.
Examples The following example displays detailed debug messages related to specified PPP redundancy events:
Router# debug ppp redundancy detailed
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,
use the no form of this command.
Syntax Description packet Displays PPP packets being sent and received. (This command display