-
Cisco IOS Debug Command Reference
-
Introduction
-
Using Debug Commands
-
Conditionally Triggered Debugging
-
debug aaa accounting through debug auto-config
-
debug backhaul-session-manager session through debug channel packets
-
debug clns esis events through debug dbconn tcp
-
debug decnet adj through debug events
-
debug fax dmsp through debug gvrp
-
debug h225 asn1 through debug ip ftp
-
debug ip http all through debug ip rsvp
-
debug ip rtp header-compression through debug ipv6 icmp
-
debug ipv6 inspect through debug local-ack state
-
debug management event through debug mpls ldp bindings
-
debug mpls ldp checkpoint through debug mwi relay events
-
debug ncia circuit through debug pxf tbridge
-
debug qllc error through debug snmp sync
-
debug sntp adjust through debug tag-switching xtagatm vc
-
debug tag-template event through debug voip application vxml
-
debug voip avlist through debug vpm signaling
-
debug vpm spi through voice call debug
-
X.25 Cause and Diagnostic Codes
-
ISDN Switch Types, Codes, and Values
-
Table Of Contents
debug ipv6 ospf database-timer rate-limit
debug isis mpls traffic-eng advertisements
debug isis mpls traffic-eng events
debug ipv6 inspect
To display messages about Cisco IOS firewall events, use the debug ipv6 inspect command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 inspect {function-trace | object-creation | object-deletion | events | timers | protocol | detailed}
no debug ipv6 inspect detailed
Syntax Description
Command Default
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
The following example enables the display of messages about Cisco IOS firewall events:
debug ipv6 inspectRelated Commands
debug ipv6 mfib
To enable debugging output on the IPv6 Multicast Forwarding Information Base (MFIB), use the debug ipv6 mfib command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 mfib [group-name | group-address] [adjacency | signal | db | init | mrib | pak | ps]
no debug ipv6 mfib
Syntax Description
Command Modes
Privileged EXEC
Syntax Description
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 adjacencydebug ipv6 mld
To enable debugging on Multicast Listener Discovery (MLD) protocol activity, use the debug ipv6 mld command in privileged EXEC mode. To restore the default value, use the no form of this command.
debug ipv6 mld [group-name | group-address | interface-type]
no debug ipv6 mld [group-name | group-address | interface-type]
Cisco IOS Release 12.0(26)S
debug ipv6 mld [group group-name | group-address | interface interface-type]
no debug ipv6 mld [group group-name | group-address | interface interface-type]
Syntax Description
Command Modes
Privileged EXEC
Command History
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.
Examples
The following example enables debugging on MLD protocol activity:
Router# debug ipv6 mldRelated Commands
debug ipv6 mld explicit
To display information related to the explicit tracking of hosts, use the debug ipv6 mld explicit command in privileged EXEC mode. To disable debugging, use the no form of this command.
debug ipv6 mld explicit [group-name | group-address]
no debug ipv6 mld explicit [group-name | group-address]
Syntax Description
Command Default
Debugging for the explicit tracking of hosts is not enabled.
Command Modes
Privileged EXEC (#)
Command History
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 explicit00:00:56:MLD:ET host FE80::A8BB:CCFF:FE00:800 report for FF05::6 (0 srcs) on Ethernet1/000:00:56:MLD:ET host FE80::A8BB:CCFF:FE00:800 switch to exclude for FF05::6 on Ethernet1/000:00:56:MLD:ET MRIB modify for (*,FF05::6) on Ethernet1/0 new 100, mdf 100debug ipv6 mld ssm-map
To display debug messages for Source Specific Multicast (SSM) mapping related to Multicast Listener Discovery (MLD), use the debug ipv6 mld ssm-map command in privileged EXEC mode. To disable debug messages for SSM mapping, use the no form of this command.
debug ipv6 mld ssm-map [source-address]
no debug ipv6 mld ssm-map [source-address]
Syntax Description
source-address
(Optional) Source address associated with an MLD membership for a group identified by the access list.
Command Modes
Privileged EXEC
Command History
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-mapRelated Commands
debug ipv6 mobile
To enable the display of debugging information for Mobile IPv6, use the debug ipv6 mobile command in privileged EXEC mode.
debug ipv6 mobile {binding-cache | forwarding | home-agent | registration}
Syntax Description
Command Modes
Privileged EXEC
Command History
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 registrationRelated Commands
debug ipv6 mrib client
To enable debugging on Multicast Routing Information Base (MRIB) client management activity, use the debug ipv6 mrib client command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 mrib client
no debug ipv6 mrib client
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
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 clientRelated Commands
debug ipv6 mrib io
To enable debugging on Multicast Routing Information Base (MRIB) I/O events, use the debug ipv6 mrib io command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 mrib io
no debug ipv6 mrib io
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the debug ipv6 mrib io command to display information on when clients open and close MRIB I/O connections, when MRIB entry and interface updates are received and processed from clients, and when MRIB entry and interface updates are sent to clients.
Examples
The following example enables debugging on MRIB I/O events:
Router# debug ipv6 mrib iodebug ipv6 mrib proxy
To enable debugging on multicast routing information base (MRIB) proxy activity between the route processor and line cards on distributed router platforms, use the debug ipv6 mrib proxy command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 mrib proxy
no debug ipv6 mrib proxy
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the debug ipv6 mrib proxy command to display information on connections that are being opened and closed and on MRIB transaction messages that are being passed between the route processor and line cards.
Examples
The following example enables debugging on MRIB proxy events:
Router# debug ipv6 mrib proxydebug ipv6 mrib route
To display information about Multicast Routing Information Base (MRIB) routing entry-related activity, use the debug ipv6 mrib route command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 mrib route [group-name | group-address]
no debug ipv6 mrib route
Syntax Description
Command Modes
Privileged EXEC
Command History
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 routeRelated Commands
show ipv6 mrib client
Displays information about the MRIB client management activity.
debug ipv6 mrib table
To enable debugging on Multicast Routing Information Base (MRIB) table management activity, use the debug ipv6 mrib table command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 mrib table
no debug ipv6 mrib table
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
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 tabledebug ipv6 nat
To display debug messages for Network Address Translation—Protocol Translation (NAT-PT) translation events, use the debug ipv6 nat command in privileged EXEC mode. To disable debug messages for NAT-PT translation events, use the no form of this command.
debug ipv6 nat [detailed | port]
no debug ipv6 nat [detailed | port]
Syntax Description
detailed
(Optional) Displays detailed information about NAT-PT translation events.
port
(Optional) Displays port allocation events.
Command Default
Debugging for NAT-PT translation events is not enabled.
Command Modes
Privileged EXEC
Command History
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
Examples
The following example shows output for the debug ipv6 nat command:
Router# debug ipv6 nat00: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)Table 191 describes the significant fields shown in the display.
The following example shows output for the debug ipv6 nat command with the detailed keyword:
Router# debug ipv6 nat detailed00:14:12: IPv6 NAT: address allocated 192.168.124.800:14:16: IPv6 NAT: deleted a NAT entry after timeoutdebug 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
Syntax Description
This command has no arguments or keywords.
Command Default
Debugging for IPv6 ICMP neighbor discovery is not enabled.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command can help determine whether the router is sending or receiving IPv6 ICMP neighbor discovery messages.
Note
Examples
The following example shows output for the debug ipv6 nd command:
Router# debug ipv6 nd13:22:40:ICMPv6-ND:STALE -> DELAY:2000:0:0:3::213:22:45:ICMPv6-ND:DELAY -> PROBE:2000:0:0:3::213:22:45:ICMPv6-ND:Sending NS for 2000:0:0:3::2 on FastEthernet0/013:22:45:ICMPv6-ND:Received NA for 2000:0:0:3::2 on FastEthernet0/0 from 2000:0:0:3::213:22:45:ICMPv6-ND:PROBE -> REACH:2000:0:0:3::213:22:45:ICMPv6-ND:Received NS for 2000:0:0:3::1 on FastEthernet0/0 from FE80::203:A0FF:FED6:140013:22:45:ICMPv6-ND:Sending NA for 2000:0:0:3::1 on FastEthernet0/013:23:15: ICMPv6-ND: Sending NS for FE80::1 on Ethernet0/113:23:16: ICMPv6-ND: DAD: FE80::1 is unique.13:23:16: ICMPv6-ND: Sending NS for 2000::2 on Ethernet0/113:23:16: ICMPv6-ND: Sending NS for 3000::3 on Ethernet0/113:23:16: ICMPv6-ND: Sending NA for FE80::1 on Ethernet0/113:23:17: ICMPv6-ND: DAD: 2000::2 is unique.13:23:53: ICMPv6-ND: Sending NA for 2000::2 on Ethernet0/113:23:53: ICMPv6-ND: DAD: 3000::3 is unique.13:23:53: ICMPv6-ND: Sending NA for 3000::3 on Ethernet0/13d19h: ICMPv6-ND: Sending NS for FE80::2 on Ethernet0/23d19h: ICMPv6-ND: Received NA for FE80::2 on Ethernet0/2 from FE80::23d19h: ICMPv6-ND: DAD: duplicate link-local FE80::2 on Ethernet0/2,interface stalled3d19h: %IPV6-4-DUPLICATE: Duplicate address FE80::2 on Ethernet0/23d19h: ICMPv6-ND: Sending NS for 3000::4 on Ethernet0/33d19h: ICMPv6-ND: Received NA for 3000::4 on Ethernet0/3 from 3000::43d19h: %IPV6-4-DUPLICATE: Duplicate address 3000::4 on Ethernet0/3Table 192 describes the significant fields shown in the display.
Related Commands
debug ipv6 icmp
Displays debug messages for IPv6 ICMP transactions.
show ipv6 neighbors
Displays IPv6 neighbor discovery cache information.
debug ipv6 ospf
To display debugging information for Open Shortest Path First (OSPF) for IPv6, use the debug ipv6 ospf command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 ospf [adj | ipsec | database-timer | flood | hello | lsa-generation | retransmission]
no debug ipv6 ospf [adj | ipsec | database-timer | flood | hello | lsa-generation | retransmission]
Syntax Description
Command Default
Debugging of OSPF for IPv6 is not enabled.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Consult Cisco technical support before using this command.
Examples
The following example displays adjacency information for OSPF for IPv6:
Router# debug ipv6 ospf adjdebug ipv6 ospf database-timer rate-limit
To display debugging information about the current wait-time used for SPF scheduling, use the debug ipv6 ospf database-timer rate-limit command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 ospf database-timer rate-limit [acl-number]
no debug ipv6 ospf database-timer rate-limit
Syntax Description
Command Modes
Privileged EXEC (#)
Command History
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-limitdebug ipv6 ospf events
To display information on Open Shortest Path First (OSPF)-related events, such as designated router selection and shortest path first (SPF) calculation, use the debug ipv6 ospf events command in privileged EXEC command. To disable debugging output, use the no form of this command.
debug ipv6 ospf events
no debug ipv6 ospf events
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Consult Cisco technical support before using this command.
Examples
The following example displays information on OSPF-related events:
Router# debug ipv6 ospf eventsdebug ipv6 ospf lsdb
To display database modifications for Open Shortest Path First (OSPF) for IPv6, use the debug ipv6 ospf lsdb command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 ospf lsdb
no debug ipv6 ospf lsdb
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
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 lsdbdebug ipv6 ospf monitor
To display debugging information about the current wait-time used for shortest path first (SPF) scheduling, use the debug ipv6 ospf monitor command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 ospf monitor
no debug ipv6 ospf monitor
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC (#)
Command History
Usage Guidelines
Consult Cisco technical support before using this command.
Examples
The following example shows debugging information about SPF scheduling:
Router# debug ipv6 ospf monitorSep 27 08:29:49.319: OSPFv3: Schedule SPF in area 0Change in LS ID 0.0.0.0, LSA type P*Sep 27 08:29:49.327: OSPFv3: reset throttling to 5000ms next wait-interval 10000ms*Sep 27 08:29:49.327: OSPFv3: schedule SPF: spf_time 00:09:36.032 wait_interval 5000msIOU_Topvar#*Sep 27 08:29:54.331: OSPFv3: Begin SPF at 581.036ms, process time 40ms*Sep 27 08:29:54.331: spf_time 00:09:36.032, wait_interval 5000ms*Sep 27 08:29:54.331: OSPFv3: Setting next wait-interval to 10000ms*Sep 27 08:29:54.331: OSPFv3: End SPF at 581.036ms, Total elapsed time 0ms*Sep 27 08:29:54.331: Schedule time 00:09:41.036, Next wait_interval 10000ms*Sep 27 08:29:54.331: Intra: 0ms, Inter: 0ms, External: 0ms*Sep 27 08:29:54.331: R: 0, N: 0*Sep 27 08:29:54.331: SN: 0, SA: 0, X5: 0, X7: 0*Sep 27 08:29:54.331: SPF suspends: 0 intra, 0 totaldebug ipv6 ospf packet
To display information about each Open Shortest Path First (OSPF) for IPv6 packet received, use the debug ipv6 ospf packet command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 ospf packet
no debug ipv6 ospf packet
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
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 packetdebug ipv6 ospf spf statistic
To display statistical information while running the shortest path first (SPF) algorithm, use the debug ipv6 ospf spf statistic command in privileged EXEC mode. To disable the debugging output, use the no form of this command.
debug ipv6 ospf spf statistic
no debug ipv6 ospf spf statistic
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
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 statisticsRelated Commands
debug ipv6 packet
To display debug messages for IPv6 packets, use the debug ipv6 packet command in privileged EXEC mode. To disable debug messages for IPv6 packets, use the no form of this command.
debug ipv6 packet [access-list access-list-name] [detail]
no debug ipv6 packet [access-list access-list-name] [detail]
Syntax Description
Command Default
Debugging for IPv6 packets is not enabled.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The debug ipv6 packet command is similar to the debug ip packet command, except that it is IPv6-specific.
Note
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
Examples
The following example shows output for the debug ipv6 packet command:
Router# debug ipv6 packet13:25:40:IPV6:source 2000:0:0:3::1 (local)13:25:40: dest 2000:0:0:3::2 (FastEthernet0/0)13:25:40: traffic class 96, flow 0x0, len 143+195, prot 6, hops 64, originating13:25:40:IPv6:Sending on FastEthernet0/013:25:40:IPV6:source 2000:0:0:3::2 (FastEthernet0/0)13:25:40: dest 2000:0:0:3::113:25:40: traffic class 96, flow 0x0, len 60+14, prot 6, hops 64, forward to ulp13:25:45:IPV6:source FE80::203:E4FF:FE12:CC1D (local)13:25:45: dest FF02::9 (Ethernet1/1)13:25:45: traffic class 112, flow 0x0, len 72+1428, prot 17, hops 255, originating13:25:45:IPv6:Sending on Ethernet1/113:25:45:IPV6:source FE80::203:E4FF:FE12:CC00 (local)13:25:45: dest 2000:0:0:3::2 (FastEthernet0/0)13:25:45: traffic class 112, flow 0x0, len 72+8, prot 58, hops 255, originating13:25:45:IPv6:Sending on FastEthernet0/013:25:45:IPV6:source 2000:0:0:3::2 (FastEthernet0/0)13:25:45: dest FE80::203:E4FF:FE12:CC0013:25:45: traffic class 112, flow 0x0, len 64+14, prot 58, hops 255, forward to ulp13:25:45:IPV6:source FE80::203:A0FF:FED6:1400 (FastEthernet0/0)13:25:45: dest 2000:0:0:3::113:25:45: traffic class 112, flow 0x0, len 72+14, prot 58, hops 255, forward to ulpTable 193 describes the significant fields shown in the display.
debug ipv6 pim
To enable debugging on Protocol Independent Multicast (PIM) protocol activity, use the debug ipv6 pim command in privileged EXEC mode. To restore the default value, use the no form of this command.
debug ipv6 pim [group-name | group-address | interface-type | neighbor | bsr]
no debug ipv6 pim [group-name | group-address | interface-type | neighbor | bsr]
Syntax Description
Command Modes
Privileged EXEC
Command History
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.
Examples
The following example enables debugging on PIM activity:
Router# debug ipv6 pimRelated Commands
debug ipv6 pim df-election
To display debug messages for Protocol Independent Multicast (PIM) bidirectional designated forwarder (DF) election message processing, use the debug ipv6 pim df-election command in privileged EXEC mode. To disable debug messages for PIM bidirectional DF election message processing, use the no form of this command.
debug ipv6 pim df-election [interface type number] [rp rp-name | rp-address]
no debug ipv6 pim df-election [interface type number] [rp rp-name | rp-address]
Syntax Description
Command Default
Debugging for PIM bidirectional DF election message processing is not enabled.
Command Modes
Privileged EXEC (#)
Command History
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:
Router# debug ipv6 pim df-election interface ethernet 1/0 rp 200::1Related Commands
debug ipv6 policy
To display IPv6 policy routing packet activity, use the debug ipv6 policy command in user EXEC or privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 policy [access-list-name]
no debug ipv6 policy [access-list-name]
Syntax Description
access-list-name
(Optional) Name of the IPv6 access list for which to clear the match counters. Names cannot contain a space or quotation mark, or begin with a numeric.
Command Default
IPv6 policy routing packet activity is not displayed.
Command Modes
User EXEC
Privileged EXECCommand History
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 policy00:02:38:IPv6 PBR:Ethernet0/0, matched src 2003::90 dst 2001:1000::1 protocol 5800:02:38:IPv6 PBR:set nexthop 2003:1::95, interface Ethernet1/000:02:38:IPv6 PBR:policy route via Ethernet1/0/2003:1::95debug ipv6 pool
To enable debugging on IPv6 prefix pools, use the debug ipv6 pool command in privileged EXEC mode. To disable debugging, use the no form of this command.
debug ipv6 pool
no debug ipv6 pool
Syntax Description
This command has no keywords or arguments.
Command Default
No debugging is active.
Command Modes
Privileged EXEC
Command History
Examples
The following example enables debugging for IPv6 prefix pools:
Router# debug ipv6 pool2w4d: IPv6 Pool: Deleting route/prefix 2001:0DB8::/29 to Virtual-Access1 for cisco2w4d: IPv6 Pool: Returning cached entry 2001:0DB8::/29 for cisco on Virtual-Access1 topool12w4d: IPv6 Pool: Installed route/prefix 2001:0DB8::/29 to Virtual-Access1 for ciscoRelated Commands
debug ipv6 rip
To display debug messages for IPv6 Routing Information Protocol (RIP) routing transactions, use the debug ipv6 rip command in privileged EXEC mode. To disable debug messages for IPv6 RIP routing transactions, use the no form of this command.
debug ipv6 rip [interface-type interface-number]
no debug ipv6 rip [interface-type interface-number]
Syntax Description
interface-type
(Optional) The interface type about which to display debug messages.
interface-number
(Optional) The interface number about which to display debug messages.
Command Default
IPv6 RIP debugging is not enabled.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The debug ipv6 rip command is similar to the debug ip rip command, except that it is IPv6-specific.
Note
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
Examples
The following example shows output for the debug ipv6 rip command:
Router# debug ipv6 rip13:09:10:RIPng:Sending multicast update on Ethernet1/1 for as1_rip13:09:10: src=FE80::203:E4FF:FE12:CC1D13:09:10: dst=FF02::9 (Ethernet1/1)13:09:10: sport=521, dport=521, length=3213:09:10: command=2, version=1, mbz=0, #rte=113:09:10: tag=0, metric=1, prefix=::/013:09:28:RIPng:response received from FE80::202:FDFF:FE77:1E42 on Ethernet1/1 for as1_rip13:09:28: src=FE80::202:FDFF:FE77:1E42 (Ethernet1/1)13:09:28: dst=FF02::913:09:28: sport=521, dport=521, length=3213:09:28: command=2, version=1, mbz=0, #rte=113:09:28: tag=0, metric=1, prefix=2000:0:0:1:1::/80The 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 194 describes the significant fields shown in the display.
Related Commands
debug ipv6 routing
Displays debug messages for IPv6 routing table updates and route cache updates.
debug ipv6 routing
To display debug messages for IPv6 routing table updates and route cache updates, use the debug ipv6 routing command in privileged EXEC mode. To disable debug messages for IPv6 routing table updates and route cache updates, use the no form of this command.
debug ipv6 routing
no debug ipv6 routing
Syntax Description
This command has no arguments or keywords.
Command Default
Debugging for IPv6 routing table updates and route cache updates is not enabled.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The debug ipv6 routing command is similar to the debug ip routing command, except that it is IPv6-specific.
Note
Examples
The following example shows output for the debug ipv6 routing command:
Router# debug ipv6 routing13:18:43:IPv6RT0:Add 2000:0:0:1:1::/80 to table13:18:43:IPv6RT0:Better next-hop for 2000:0:0:1:1::/80, [120/2]13:19:09:IPv6RT0:Add 2000:0:0:2::/64 to table13:19:09:IPv6RT0:Better next-hop for 2000:0:0:2::/64, [20/1]13:19:09:IPv6RT0:Add 2000:0:0:2:1::/80 to table13:19:09:IPv6RT0:Better next-hop for 2000:0:0:2:1::/80, [20/1]13:19:09:IPv6RT0:Add 2000:0:0:4::/64 to table13:19:09:IPv6RT0:Better next-hop for 2000:0:0:4::/64, [20/1]13:19:37:IPv6RT0:Add 2000:0:0:6::/64 to table13:19:37:IPv6RT0:Better next-hop for 2000:0:0:6::/64, [20/2]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 tableThe 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]Related Commands
debug ipx ipxwan
To display debugging information for interfaces configured to use IPX wide-area network (IPXWAN), use the debug ipx ipxwan command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipx ipxwan
no debug ipx ipxwan
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
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%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to upIPXWAN: state (Disconnect -> Sending Timer Requests) [Serial1/6666:200 (IPX linestate brought up)]IPXWAN: state (Sending Timer Requests -> Disconnect) [Serial1/6666:200 (IPX linestate brought down)]IPXWAN: state (Disconnect -> Sending Timer Requests) [Serial1/6666:200 (IPX linestate brought up)]IPXWAN: Send TIMER_REQ [seq 0] out Serial1/6666:200IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200IPXWAN: Send TIMER_REQ [seq 2] out Serial1/6666:200IPXWAN: Send TIMER_REQ [seq 0] out Serial1/6666:200IPXWAN: Rcv TIMER_REQ on Serial1/6666:200, NodeID 1234, Seq 1IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200IPXWAN: Rcv TIMER_RSP on Serial1/6666:200, NodeID 1234, Seq 1, Del 6IPXWAN: state (Sending Timer Requests -> Master: Sent RIP/SAP) [Serial1/6666:200(Received Timer Response as master)]IPXWAN: Send RIPSAP_INFO_REQ [seq 0] out Serial1/6666:200IPXWAN: Rcv RIPSAP_INFO_RSP from Serial1/6666:200, NodeID 1234, Seq 0IPXWAN: state (Master: Sent RIP/SAP -> Master: Connect) [Serial1/6666:200 (Received Router Info Rsp as Master)]The following line indicates that the interface has initialized:
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to upThe 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 linestate brought down)]IPXWAN: state (Disconnect -> Sending Timer Requests) [Serial1/6666:200 (IPX linestate 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:200IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200The 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 1IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200IPXWAN: Rcv TIMER_RSP on Serial1/6666:200, NodeID 1234, Seq 1, Del 6IPXWAN: 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:200IPXWAN: Rcv RIPSAP_INFO_RSP from Serial1/6666:200, NodeID 1234, Seq 0IPXWAN: state (Master: Sent RIP/SAP -> Master: Connect) [Serial1/6666:200 (Received Router Info Rsp as Master)]debug ipx nasi
To display information about NetWare Asynchronous Services Interface (NASI) connections, use the debug ipx nasi command in Privileged EXEC configuration mode. To disable debugging output, use the no form of this command.
debug ipx nasi {packets | error | activity}
no debug ipx nasi {packets | error | activity}
Syntax Description
Command Default
Nasi protocol debugging is disabled.
Command Modes
Privileged EXEC
Command History
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 packetRouter# debug ipx nasi errorNASI0: 6E6E Check server infoNASI0: 6E6E sending server-info 4F00 Good response: 43 bytesNASI0: 7A6E Query Port. Find firstNASI0: FFirst: line 0 DE, port: TTY1-__________ASYNC___^, group: ASYNC___^NASI0: 7A6E sending Qport find-first response: 300 bytesNASI0: 7B6E port request. setting up portNASI: Check-login User: c h r i sNASI: Check-login PW hash: C7 A6 C5 C7 C4 C0 C5 C3 C4 CC C5 CF C4 C8 C5 CB C4 D4 C5 D7 C4 D0 C5 D3 C4NASI: Check-login PW: l a bNASI1: 7B6E sending NCS Good server Data Ack in 0 bytes pkt in 13 size pktNASI1: 7B6E sending Preq response: 303 bytes GoodNASI1: 7B6E port request. setting up portNASI1: 7B6E sending NCS Good server Data Ack in 0 bytes pkt in 13 size pktNASI1: 7B6E sending Preq response: 303 bytes GoodNASI1: 7B6E Unknown NASI code 4500 Pkt Size: 1345 0 0 FC 0 2 0 20 0 0 FF 1 0NASI1: 7B6E Flush Rx BuffersNASI1: 7B6E sending NASI server TTY data: 1 byte in 14 size pktNASI1: 7B6E sending NCS Good server Data Ack in 1 bytes pkt in 13 size pktIn the following line:
•
•
•
•
NASI0: 6E6E Check server infoThe 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 bytesThe following line is a NASI packet type. Find first and Find next are NASI packet types.
NASI0: 7A6E Query Port. Find firstThe following line indicates that the outgoing find first packet for the NASI connection 7A6E has line 0 DE, port name TTY1, and general name ASYNC:
NASI0: FFirst: line 0 DE, port: TTY1-__________ASYNC___^, group: ASYNC___^The following two lines indicate:
•
•
NASI1: 7B6E Unknown NASI code 4500 Pkt Size: 1345 0 0 FC 0 2 0 20 0 0 FF 1 0Related Commands
debug ipx packet
To display information about packets received, sent, and forwarded, use the debug ipx packet command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipx packet
no debug ipx packet
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
This command is useful for learning whether Internetwork Packet Exchange (IPX) packets are traveling over a router.
Note
Examples
The following is sample output from the debug ipx packet command:
Router# debug ipx packetIPX: src=160.0260.8c4c.4f22, dst=1.0000.0000.0001, packet receivedIPX: src=160.0260.8c4c.4f22, dst=1.0000.0000.0001,gw=183.0000.0c01.5d85,sending packetThe 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 195 describes the significant fields shown in the display.
debug ipx routing
To display information on Internetwork Packet Exchange (IPX) routing packets that the router sends and receives, use the debug ipx routing command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipx routing {activity | events}
no debug ipx routing {activity | events}
Syntax Description
activity
Displays messages relating to IPX routing activity.
events
Displays messages relating to IPX routing events.
Command Modes
Privileged EXEC
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 routingIPXRIP: update from 9999.0260.8c6a.1733110801 in 1 hops, delay 2IPXRIP: sending update to 12FF02:ffff.ffff.ffff via Ethernet 1network 555, metric 2, delay 3network 1234, metric 3, delay 4Table 196 describes the significant fields shown in the display.
Related Commands
debug ipx sap
To display information about Internetwork Packet Exchange (IPX) Service Advertisement Protocol (SAP) packets, use the debug ipx sap command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipx sap [activity | events]
no debug ipx sap [activity | events]
Syntax Description
Command Modes
Privileged EXEC
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
Examples
The following is sample output from the debug ipx sap command:
Router# debug ipx sapIPXSAP: 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 hopstype 0x4, "Hello1", 199.0002.0004.0008 (451), 2 hopsIPXSAP: sending update to 160IPXSAP: 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), 2hopsThe debug ipx sap command generates multiple lines of output for each SAP packet—a 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:Table 197 describes the significant fields shown in the display.
The fifth line of output indicates that the router sent a SAP update to network 160:
IPXSAP: sending update to 160The 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:
451—Network Core Protocol
452—Service Advertising Protocol
453—Routing Information Protocol
455—NetBIOS
456—Diagnostics
4000 to 6000—Ephemeral sockets used for interaction with file servers and other network communications
Related Commands
debug ipx routing
Displays information on IPX routing packets that the router sends and receives.
debug ipx spoof
To display information about Sequenced Packet Exchange (SPX) keepalive and Internetwork Packet Exchange (IPX) watchdog packets when ipx watchdog and ipx spx-spoof are configured on the router, use the debug ipx spoof command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipx spoof
no debug ipx spoof
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
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 spoofIPX: 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 0IPX: 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 0IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: 80 0 2B8 7104 29 7 7 (early)IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.da75 ln= 42 tc=02, SPX: 80 0 4B8 7004 1D 8 8 (early)IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.da75 ln= 32 tc=02, watchdogIPX: local:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 32 tc=00, watchdog snetIPX: 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 0IPX: 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 0IPX: 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 2EThe 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 0IPX: 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 0The 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, watchdogIPX: local:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 32 tc=00, watchdog sentThe 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 0IPX: 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 0The 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 2Edebug ipx spx
To display debugging messages related to the Sequenced Packet Exchange (SPX) protocol, use the debug ipx spx command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipx spx
no debug ipx spx
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
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 spxSPX: Sent an SPX packetSPX: I Con Src/Dst 776E/20A0 d-strm 0 con-ctl 80SPX: I Con Src/Dst 776E/20A0 d-strm FE con-ctl 40SPX: C847C Connection close requested by peerSPX: Sent an SPX packetSPX: purge timer fired. Cleaning up C847CSPX: purging spxcon C847C from conQSPX: returning inQ buffersSPX: returning outQ buffersSPX: returning unackedQ buffersSPX: returning spxconSPX: I Con Src/Dst 786E/FFFF d-strm 0 con-ctl C0SPX: new connection request for listening socketSPX: Sent an SPX packetSPX: I Con Src/Dst 786E/20B0 d-strm 0 con-ctl 40SPX: 300 bytes data recvdSPX: Sent an SPX packetThe 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 80debug 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
Defaults
Commands are enabled on all interfaces unless a specific interface is specified.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Please read the following caution before using this command.
Caution
Follow all instructions from Cisco technical support personnel when enabling and disabling these commands.
Examples
The general format of the debug isdn command messages is as follows:
date and time: ISDN interface feature: text message
The text message can be used to determine activity in the structure and operation of ISDN in the Cisco IOS software, ISDN messages, and ISDN signaling procedures. The message must be interpreted by Cisco technical personnel.
The following example shows a typical message for the debug isdn cc command:
*Mar 1 02:29:27.751: ISDN Se1/0:23 CC: CCPRI_Go: source id 0x300, call id 0x8008, event 0x341 (pre-ccb recovery)The following example enables a selected set of debug isdn messages that should provide sufficient information for Cisco technical personnel to determine why a problem is occurring on BRI interface 2:
Router# debug isdn standard interface bri 2The 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 NULLL2: 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 85debug isdn event
To display ISDN events occurring on the user side (on the router) of the ISDN interface, use the debug isdn event command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isdn event
no debug isdn event
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
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 eventISDN Event: Call to 415555121202received HOST_PROCEEDINGChannel ID i = 0x0101-------------------Channel ID i = 0x89received HOST_CONNECTChannel ID i = 0x0101ISDN Event: Connected to 415555121202 on B1 at 64 Kb/sThe 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 eventreceived HOST_INCOMING_CALLBearer Capability i = 0x080010-------------------Channel ID i = 0x0101Calling Party Number i = 0x0000, `415555121202'IE out of order or end of `private' IEs --Bearer Capability i = 0x8890Channel ID i = 0x89Calling Party Number i = 0x0083, `415555121202'ISDN Event: Received a call from 415555121202 on B1 at 64 Kb/sISDN Event: Accepting the callreceived HOST_CONNECTChannel ID i = 0x0101ISDN Event: Connected to 415555121202 on B1 at 64 Kb/sThe 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 eventreceived HOST_DISCONNECTISDN Event: Call to 415555121202 was hung upThe 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 eventISDN Event: Hangup call to call id 0x8008Table 198 describes the significant fields shown in the display.
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 eventJan 3 11:29:52.559: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0x81Jan 3 11:29:52.563: Cause i = 0x8090 - Normal call clearingThe 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 eventJan 3 11:32:03.263: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0x85Jan 3 11:32:03.267: Cause i = 0x8095 - Call rejectedThe 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 eventJan 3 11:41:48.483: ISDN BR0: Event: Call to 61885:1212 at 64 Kb/sJan 3 11:41:48.495: ISDN BR0: TX -> SETUP pd = 8 callref = 0x04Jan 3 11:41:48.495: Bearer Capability i = 0x8890Jan 3 11:41:48.499: Channel ID i = 0x83Jan 3 11:41:48.503: Called Party Number i = 0x80, '61885'Jan 3 11:41:48.507: Called Party SubAddr i = 0x80, 'P1212'Jan 3 11:41:48.571: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x84Jan 3 11:41:48.575: Channel ID i = 0x89Jan 3 11:41:48.587: ISDN BR0: Event: incoming ces value = 1Jan 3 11:41:48.587: ISDN BR0: received HOST_PROCEEDINGChannel ID i = 0x0101Jan 3 11:41:48.591: -------------------Channel ID i = 0x89Jan 3 11:41:48.731: ISDN BR0: RX <- CONNECT pd = 8 callref = 0x84Jan 3 11:41:48.743: ISDN BR0: Event: incoming ces value = 1Jan 3 11:41:48.743: ISDN BR0: received HOST_CONNECTChannel ID i = 0x0101Jan 3 11:41:48.747: -------------------%LINK-3-UPDOWN: Interface BRI0:1 changed state to upJan 3 11:41:48.771: ISDN BR0: Event: Connected to 61885:1212 on B1 at 64 Kb/sJan 3 11:41:48.775: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x04%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up%ISDN-6-CONNECT: Interface BRI0:1 is now connected to 61885:1212 goodieThe 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 eventBRI0:Caller id Callback server starting to spanky 81012345678902: Callback timer expiredBRI0:beginning callback to spanky 81012345678902BRI0: Attempting to dial 81012345678902The 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 eventBRI0:Caller id 81012345678902 callback - no matching mapTable 199 describes the significant fields shown in the display.
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*Mar 1 00:46:55.139: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, changed state to up*Mar 1 00:46:58.187: %ISDN-6-CONNECT: Interface BRI0:2 is now connected to 81012345678901 deloreanThe 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*Sep 28 12:34:29.747: ISDN BR1/1 EVENTd: isdn_host_packet_mode_events: Host packet call received call id 0xBTable 200 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.
Related Commands
debug isdn q931
Displays call setup and teardown information of ISDN Layer 3 network connections.
debug isdn q921
To display data link layer (Layer 2) access procedures that are taking place at the router on the D channel (Link Access Procedure or LAPD) of its ISDN interface, use the debug isdn q921 command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isdn q921 [detail | frame | interface [bri number]]
no debug isdn q921 [detail | frame | interface]
Syntax Description
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
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
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_EVENT00:12:10:ISDN Se1:15 Q921f:PBXb RX <- 0x0E03EFThe 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=0The 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 L200:12:10:ISDN Q921d:isdn_from_driver_process:event_count 300:12:10:ISDN Se1:15 Q921d:dpnss_l2_main:source_id x200 event x141 v_bit x0 chan x0The 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 1The 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 x630531A4The 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 x0The following output shows that the L2 frame is transmitted (TX):
00:12:10:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT00:12:10:ISDN Se1:15 Q921f:PBXb TX -> 0x0E0363The 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=0The following is complete debugging output from a DPNSS call:
Jan 8 17:24:43.499:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:43.499:ISDN Se2/0:15 Q921f:PBXa TX -> 0x440303Jan 8 17:24:43.499:ISDN Se2/0:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=0Jan 8 17:24:43.499:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:43.503:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:43.503:ISDN Se2/0:15 Q921f:PBXa RX <-0x44030300102A34232A35302A33333330Jan 8 17:24:43.503: 30303031233434343030303031Jan 8 17:24:43.503:ISDN Se2/0:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=0i=0x00102A34232A35302A3333333030303031233434343030303031Jan 8 17:24:43.503:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:43.503:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:43.507:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:43.507:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:24:43.507:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x63F183D4Jan 8 17:24:43.507:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:43.507:ISDN Se2/0:15 Q921f:PBXa TX -> 0x440303Jan 8 17:24:43.507:ISDN Se2/0:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=0Jan 8 17:24:43.507:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:43.515:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:43.515:ISDN Se2/0:15 Q921f:PBXa RX <-0x44030300102A34232A35302A33333330Jan 8 17:24:43.515: 30303031233434343030303031Jan 8 17:24:43.515:ISDN Se2/0:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=0i=0x00102A34232A35302A3333333030303031233434343030303031Jan 8 17:24:43.515:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:43.515:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:43.515:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:43.515:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:24:43.515:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x63F183D4Jan 8 17:24:43.515:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:43.519:ISDN Se2/0:15 Q921f:PBXa TX -> 0x440303Jan 8 17:24:43.519:ISDN Se2/0:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=0Jan 8 17:24:43.519:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:43.599:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x4 event x240v_bit x0 chan x2Jan 8 17:24:43.599:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:eventx240 chan 1Jan 8 17:24:43.599:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x2v_bit 1 chan 1 out_pkt x63EE5780Jan 8 17:24:43.599:ISDN Se2/1:15 LIFd:LIF_StartTimer:timer (0x63E569A8),ticks (500), event (0x1201)Jan 8 17:24:43.599:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:43.599:ISDN Se2/1:15 Q921f:PBXa TX ->0x46030300102A31232A35302A33333330Jan 8 17:24:43.599: 30303031233434343030303031Jan 8 17:24:43.599:ISDN Se2/1:15 Q921:PBXa TX -> UI(C) dlci=1 cntl=UI nbit=0i=0x00102A31232A35302A3333333030303031233434343030303031Jan 8 17:24:43.599:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:43.623:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:43.623:ISDN Se2/1:15 Q921f:PBXa RX <- 0x460303Jan 8 17:24:43.623:ISDN Se2/1:15 Q921:PBXa RX <- UI(R) dlci=1 cntl=UI nbit=0Jan 8 17:24:43.623:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:43.623:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:43.627:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:43.627:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x3chan 1Jan 8 17:24:43.719:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:43.719:ISDN Se2/1:15 Q921f:PBXa RX <-0x440313092A34232A35302A3434343030Jan 8 17:24:43.719: 303031232A31382A33312A33312A3331Jan 8 17:24:43.719: 23Jan 8 17:24:43.719:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1i=0x092A34232A35302A3434343030303031232A31382A33312A33312A333123Jan 8 17:24:43.719:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:43.719:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:43.719:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:43.719:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:24:43.719:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x300 event x241v_bit 1 chan 1 out_pkt x63EE5780Jan 8 17:24:43.719:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x63EE57CCJan 8 17:24:43.723:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:43.723:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313Jan 8 17:24:43.723:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:24:43.723:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:43.727:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:43.727:ISDN Se2/1:15 Q921f:PBXa RX <-0x440313092A34232A35302A3434343030Jan 8 17:24:43.727: 303031232A31382A33312A33312A3331Jan 8 17:24:43.727: 23Jan 8 17:24:43.727:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1i=0x092A34232A35302A3434343030303031232A31382A33312A33312A333123Jan 8 17:24:43.727:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:43.727:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:43.731:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:43.731:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:24:43.731:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x63EE57CCJan 8 17:24:43.731:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:43.731:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313Jan 8 17:24:43.731:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:24:43.731:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:43.739:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:43.739:ISDN Se2/1:15 Q921f:PBXa RX <-0x440313092A34232A35302A3434343030Jan 8 17:24:43.739: 303031232A31382A33312A33312A3331Jan 8 17:24:43.739: 23Jan 8 17:24:43.739:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1i=0x092A34232A35302A3434343030303031232A31382A33312A33312A333123Jan 8 17:24:43.739:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:43.739:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:43.739:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:43.739:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:24:43.739:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x63EE57CCJan 8 17:24:43.739:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:43.743:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313Jan 8 17:24:43.743:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:24:43.743:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:43.787:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x4 event x240v_bit x0 chan x2Jan 8 17:24:43.787:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:eventx240 chan 1Jan 8 17:24:43.787:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x2v_bit 1 chan 1 out_pkt x636B1B64Jan 8 17:24:43.787:ISDN Se2/0:15 LIFd:LIF_StartTimer:timer (0x63A4AFBC),ticks (500), event (0x1201)Jan 8 17:24:43.791:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:43.791:ISDN Se2/0:15 Q921f:PBXa TX ->0x460313092A31232A35302A3434343030Jan 8 17:24:43.791: 30303123Jan 8 17:24:43.791:ISDN Se2/0:15 Q921:PBXa TX -> UI(C) dlci=1 cntl=UI nbit=1i=0x092A31232A35302A343434303030303123Jan 8 17:24:43.791:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:43.811:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:43.811:ISDN Se2/0:15 Q921f:PBXa RX <- 0x460313Jan 8 17:24:43.811:ISDN Se2/0:15 Q921:PBXa RX <- UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:24:43.811:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:43.811:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:43.811:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:43.811:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x3chan 1Jan 8 17:24:52.107:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:52.107:ISDN Se2/1:15 Q921f:PBXa RX <-0x440303052A34232A35302A3434343030Jan 8 17:24:52.107: 303031232A31382A33312A33312A3331Jan 8 17:24:52.107: 23Jan 8 17:24:52.107:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=0i=0x052A34232A35302A3434343030303031232A31382A33312A33312A333123Jan 8 17:24:52.107:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:52.107:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:52.111:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:52.111:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:24:52.111:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x300 event x241v_bit 1 chan 1 out_pkt x63F19CC8Jan 8 17:24:52.111:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x63F19D14Jan 8 17:24:52.111:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:52.111:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440303Jan 8 17:24:52.111:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=0Jan 8 17:24:52.111:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:52.119:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:52.119:ISDN Se2/1:15 Q921f:PBXa RX <-0x440303052A34232A35302A3434343030Jan 8 17:24:52.119: 303031232A31382A33312A33312A3331Jan 8 17:24:52.119: 23Jan 8 17:24:52.119:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=0i=0x052A34232A35302A3434343030303031232A31382A33312A33312A333123Jan 8 17:24:52.119:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:52.119:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:52.119:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0x141 v_bit x0 chan x0Jan 8 17:24:52.119:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:24:52.119:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x63F19D14Jan 8 17:24:52.119:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:52.123:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440303Jan 8 17:24:52.123:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=0Jan 8 17:24:52.123:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:52.127:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:52.127:ISDN Se2/1:15 Q921f:PBXa RX <-0x440303052A34232A35302A3434343030Jan 8 17:24:52.127: 303031232A31382A33312A33312A3331Jan 8 17:24:52.127: 23Jan 8 17:24:52.127:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=0i=0x052A34232A35302A3434343030303031232A31382A33312A33312A333123Jan 8 17:24:52.127:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:52.127:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:52.131:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:52.131:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:24:52.131:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x63F19D14Jan 8 17:24:52.131:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:52.131:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440303Jan 8 17:24:52.131:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=0Jan 8 17:24:52.131:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:52.159:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x4 event x240v_bit x0 chan x2Jan 8 17:24:52.159:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:eventx240 chan 1Jan 8 17:24:52.159:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x2v_bit 1 chan 1 out_pkt x63F19CC8Jan 8 17:24:52.159:ISDN Se2/0:15 LIFd:LIF_StartTimer:timer (0x63A4AFBC),ticks (500), event (0x1201)Jan 8 17:24:52.159:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:52.159:ISDN Se2/0:15 Q921f:PBXa TX ->0x460303052A35302A3434343030303031Jan 8 17:24:52.159: 23Jan 8 17:24:52.159:ISDN Se2/0:15 Q921:PBXa TX -> UI(C) dlci=1 cntl=UI nbit=0i=0x052A35302A343434303030303123Jan 8 17:24:52.159:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:52.179:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:52.179:ISDN Se2/0:15 Q921f:PBXa RX <- 0x460303Jan 8 17:24:52.179:ISDN Se2/0:15 Q921:PBXa RX <- UI(R) dlci=1 cntl=UI nbit=0Jan 8 17:24:52.179:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:52.183:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:52.183:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:52.183:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x3chan 1Jan 8 17:25:31.811:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:25:31.811:ISDN Se2/0:15 Q921f:PBXa RX <- 0x4403130830Jan 8 17:25:31.811:ISDN Se2/0:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1i=0x0830Jan 8 17:25:31.811:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:25:31.811:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:25:31.811:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:25:31.811:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:25:31.811:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x300 event x241v_bit 1 chan 1 out_pkt x63F1806CJan 8 17:25:31.811:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x636710B8Jan 8 17:25:31.815:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:25:31.815:ISDN Se2/0:15 Q921f:PBXa TX -> 0x440313Jan 8 17:25:31.815:ISDN Se2/0:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:25:31.815:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:25:31.819:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:25:31.819:ISDN Se2/0:15 Q921f:PBXa RX <- 0x4403130830Jan 8 17:25:31.819:ISDN Se2/0:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1i=0x0830Jan 8 17:25:31.819:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:25:31.819:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:25:31.823:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:25:31.823:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:25:31.823:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x63F19CC8Jan 8 17:25:31.823:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:25:31.823:ISDN Se2/0:15 Q921f:PBXa TX -> 0x440313Jan 8 17:25:31.823:ISDN Se2/0:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:25:31.823:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:25:31.831:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:25:31.831:ISDN Se2/0:15 Q921f:PBXa RX <- 0x4403130830Jan 8 17:25:31.831:ISDN Se2/0:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1i=0x0830Jan 8 17:25:31.831:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:25:31.831:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:25:31.831:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:25:31.831:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:25:31.831:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x636710B8Jan 8 17:25:31.835:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:25:31.835:ISDN Se2/0:15 Q921f:PBXa TX -> 0x440313Jan 8 17:25:31.835:ISDN Se2/0:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:25:31.835:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:25:31.851:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x4 event x240v_bit x0 chan x2Jan 8 17:25:31.851:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:eventx240 chan 1Jan 8 17:25:31.851:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x2v_bit 1 chan 1 out_pkt x63F1806CJan 8 17:25:31.851:ISDN Se2/1:15 LIFd:LIF_StartTimer:timer (0x63E569A8),ticks (500), event (0x1201)Jan 8 17:25:31.851:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:25:31.855:ISDN Se2/1:15 Q921f:PBXa TX -> 0x4603130830Jan 8 17:25:31.855:ISDN Se2/1:15 Q921:PBXa TX -> UI(C) dlci=1 cntl=UI nbit=1i=0x0830Jan 8 17:25:31.855:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:25:31.875:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:25:31.875:ISDN Se2/1:15 Q921f:PBXa RX <- 0x460313Jan 8 17:25:31.875:ISDN Se2/1:15 Q921:PBXa RX <- UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:25:31.875:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:25:31.875:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:25:31.875:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:25:31.875:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x3chan 1Jan 8 17:25:31.879:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x4 event x240v_bit x0 chan x2Jan 8 17:25:31.879:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:eventx240 chan 1Jan 8 17:25:31.879:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x2v_bit 1 chan 1 out_pkt x63EFC5ACJan 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_EVENTJan 8 17:25:31.879:ISDN Se2/0:15 Q921f:PBXa TX -> 0x4603130830Jan 8 17:25:31.879:ISDN Se2/0:15 Q921:PBXa TX -> UI(C) dlci=1 cntl=UI nbit=1i=0x0830Jan 8 17:25:31.883:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:25:31.899:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:25:31.899:ISDN Se2/0:15 Q921f:PBXa RX <- 0x460313Jan 8 17:25:31.899:ISDN Se2/0:15 Q921:PBXa RX <- UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:25:31.899:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:25:31.899:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:25:31.903:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:25:31.903:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x3chan 1Jan 8 17:25:32.063:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:25:32.063:ISDN Se2/1:15 Q921f:PBXa RX <- 0x4403130830Jan 8 17:25:32.063:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1i=0x0830Jan 8 17:25:32.063:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:25:32.063:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:25:32.067:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:25:32.067:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:25:32.067:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x300 event x241v_bit 1 chan 1 out_pkt x63EFC5ACJan 8 17:25:32.067:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x6367175CJan 8 17:25:32.067:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:25:32.067:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313Jan 8 17:25:32.067:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:25:32.067:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:25:32.075:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:25:32.075:ISDN Se2/1:15 Q921f:PBXa RX <- 0x4403130830Jan 8 17:25:32.075:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1i=0x0830Jan 8 17:25:32.075:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:25:32.075:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:25:32.075:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:25:32.075:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:25:32.075:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x6367175CJan 8 17:25:32.075:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:25:32.075:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313Jan 8 17:25:32.079:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:25:32.079:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:25:32.083:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:25:32.083:ISDN Se2/1:15 Q921f:PBXa RX <- 0x4403130830Jan 8 17:25:32.083:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1i=0x0830Jan 8 17:25:32.083:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:25:32.083:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:25:32.087:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:25:32.087:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:25:32.087:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x6367175CJan 8 17:25:32.087:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:25:32.087:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313Jan 8 17:25:32.087:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:25:32.087:ISDN Q921d:isdn_l2d_srq_process:event_count 1The following output shows details of the preceding debugging events.
The first two octets (0x4403) form the address field, while the third octet (0x03) is the control field. All the octets starting from the fourth constitute DPNSS L3 information, which needs to be backhauled to the Cisco PGW2200.
Jan 8 17:24:43.495:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:43.495:ISDN Se2/0:15 Q921f:PBXa RX <- 0x44030300102A34232A35302A33333330Jan 8 17:24:43.495: 30303031233434343030303031All 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=0i=0x00102A34232A35302A3333333030303031233434343030303031In 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 L2Jan 8 17:24:43.495:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:43.495:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:43.495:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x2 chan 1For 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 x241v_bit 1 chan 1 out_pkt x6367175CInformation is sent to the driver (dest x200), which is then sent to the peer): An Unnumbered Information—Response [UI(R)] (event x3) acknowledges the received Unnumbered Information—Command [UI(C)].
Jan 8 17:24:43.495:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x63F183D4The following is sample output from the debug isdn q921 command for an outgoing call:
Router# debug isdn q921Jan 3 14:52:24.475: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 5 nr = 2i = 0x08010705040288901801837006803631383835Jan 3 14:52:24.503: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 6Jan 3 14:52:24.527: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 2 nr = 6i = 0x08018702180189Jan 3 14:52:24.535: ISDN BR0: TX -> RRr sapi = 0 tei = 64 nr = 3Jan 3 14:52:24.643: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 3 nr = 6i = 0x08018707Jan 3 14:52:24.655: ISDN BR0: TX -> RRr sapi = 0 tei = 64 nr = 4%LINK-3-UPDOWN: Interface BRI0:1, changed state to upJan 3 14:52:24.683: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 6 nr = 4i = 0x0801070FJan 3 14:52:24.699: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 7%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up%ISDN-6-CONNECT: Interface BRI0:1 is now connected to 61885 goodieJan 3 14:52:34.415: ISDN BR0: RX <- RRp sapi = 0 tei = 64 nr = 7Jan 3 14:52:34.419: ISDN BR0: TX -> RRf sapi = 0 tei = 64 nr = 4In 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 = 2i = 0x08010705040288901801837006803631383835Jan 3 14:52:24.527: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 2 nr = 6i = 0x08018702180189Jan 3 14:52:24.643: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 3 nr = 6i = 0x08018707Jan 3 14:52:24.683: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 6 nr = 4i = 0x0801070FThe following is sample output from the debug isdn q921 command for a startup message on a DMS-100 switch:
Router# debug isdn q921Jan 3 14:47:28.455: ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127 0Jan 3 14:47:30.171: ISDN BR0: TX -> IDREQ ri = 31815 ai = 127Jan 3 14:47:30.219: ISDN BR0: RX <- IDASSN ri = 31815 ai = 64Jan 3 14:47:30.223: ISDN BR0: TX -> SABMEp sapi = 0 tei = 64Jan 3 14:47:30.227: ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127Jan 3 14:47:30.235: ISDN BR0: TX -> IDCKRP ri = 16568 ai = 64Jan 3 14:47:30.239: ISDN BR0: RX <- UAf sapi = 0 tei = 64Jan 3 14:47:30.247: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 0 nr = 0i = 0x08007B3A03313233Jan 3 14:47:30.267: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 1Jan 3 14:47:34.243: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 1 nr = 0i = 0x08007B3A03313233Jan 3 14:47:34.267: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 2Jan 3 14:47:43.815: ISDN BR0: RX <- RRp sapi = 0 tei = 64 nr = 2Jan 3 14:47:43.819: ISDN BR0: TX -> RRf sapi = 0 tei = 64 nr = 0Jan 3 14:47:53.819: ISDN BR0: TX -> RRp sapi = 0 tei = 64 nr = 0The 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 = 127Jan 3 14:47:30.219: ISDN BR0: RX <- IDASSN ri = 31815 ai = 64At 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 = 127Jan 3 14:47:30.235: ISDN BR0: TX -> IDCKRP ri = 16568 ai = 64At 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 = 64Jan 3 14:47:30.239: ISDN BR0: RX <- UAf sapi = 0 tei = 64At 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 = 2Jan 3 14:47:43.819: ISDN BR0: TX -> RRf sapi = 0 tei = 64 nr = 0These I-frames are typically exchanged every 10 seconds (T203 timer).
The following is sample output from the debug isdn q921 command for an incoming call. It is an incoming SETUP message that assumes that the Layer 2 link is already established to the other side.
Router# debug isdn q921Jan 3 14:49:22.507: ISDN BR0: TX -> RRp sapi = 0 tei = 64 nr = 0Jan 3 14:49:22.523: ISDN BR0: RX <- RRf sapi = 0 tei = 64 nr = 2Jan 3 14:49:32.527: ISDN BR0: TX -> RRp sapi = 0 tei = 64 nr = 0Jan 3 14:49:32.543: ISDN BR0: RX <- RRf sapi = 0 tei = 64 nr = 2Jan 3 14:49:42.067: ISDN BR0: RX <- RRp sapi = 0 tei = 64 nr = 2Jan 3 14:49:42.071: ISDN BR0: TX -> RRf sapi = 0 tei = 64 nr = 0Jan 3 14:49:47.307: ISDN BR0: RX <- UI sapi = 0 tei = 127i = 0x08011F05040288901801897006C13631383836%LINK-3-UPDOWN: Interface BRI0:1, changed state to upJan 3 14:49:47.347: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 2 nr = 0i = 0x08019F07180189Jan 3 14:49:47.367: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 3Jan 3 14:49:47.383: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 0 nr = 3i = 0x08011F0F180189Jan 3 14:49:47.391: ISDN BR0: TX -> RRr sapi = 0 tei = 64 nr = 1%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to upTable 201 describes the significant fields shown in the display.
Related Commands
debug isdn q931
To display information about call setup and teardown of ISDN network connections (Layer 3) between the local router (user side) and the network, use the debug isdn q931 command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isdn q931
no debug isdn q931
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
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 router's 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 q931TX -> SETUP pd = 8 callref = 0x04Bearer Capability i = 0x8890Channel ID i = 0x83Called Party Number i = 0x80, `415555121202'RX <- CALL_PROC pd = 8 callref = 0x84Channel ID i = 0x89RX <- CONNECT pd = 8 callref = 0x84TX -> CONNECT_ACK pd = 8 callref = 0x04....Success rate is 0 percent (0/5)The following is sample output from the debug isdn q931 command of a call setup procedure for an incoming call:
Router# debug isdn q931RX <- SETUP pd = 8 callref = 0x06Bearer Capability i = 0x8890Channel ID i = 0x89Calling Party Number i = 0x0083, `81012345678902'TX -> CONNECT pd = 8 callref = 0x86RX <- CONNECT_ACK pd = 8 callref = 0x06The 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 q931Sep 20 04:09:38.335 UTC: ISDN Se7/1:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x0007Cause i = 0x8290 - Normal call clearingFacility i = 0x91A106020107020103Protocol Profile = Remote Operations Protocol0xA106020107020103Component = Invoke componentInvoke Id = 7 <MCID>Operation = MCIDRequestThe following is sample output from the debug isdn q931 command of a call teardown procedure from the network:
Router# debug isdn q931RX <- DISCONNECT pd = 8 callref = 0x84Cause i = 0x8790Looking Shift to Codeset 6Codeset 6 IE 0x1 1 0x82 `10'TX -> RELEASE pd = 8 callref = 0x04Cause i = 0x8090RX <- RELEASE_COMP pd = 8 callref = 0x84Table 202 describes the significant fields shown in the displays, in alphabetical order.
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 = 0x88C0C2E6Standard = CCITTTransfer Capability = Unrestricted DigitalTransfer Mode = PacketTransfer Rate = Packet - not specifiedUser Info L2 Protocol = Recommendation Q921/I.441User Info L3 Protocol = Recommendation X.25, Packet LayerChannel ID i = 0x8CExclusive, No B-channelInformation Rate i = 0x8888Packet Layer Binary Params i = 0x80Packet Layer Window Size i = 0x8282Packet Size i = 0x8888Calling Party Number i = 0x0083, '144014384106'Plan:Unknown, Type:UnknownUser-User i = 0x02CC000000The 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.
Related Commands
debug isdn tgrm
To view ISDN trunk group resource manager information, use the debug isdn tgrm command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isdn tgrm
no debug isdn tgrm
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
Privileged EXEC
Command History
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 200:26:31:ISDN:update_tgrm_call_status:idb 0x64229380 bchan 1 availability state 1 call state(prev,new) (0,2), dsl 200:26:31:ISDN:Calling TGRM with tgrm_call_isdn_update:idb 0x64229380 bchan 1 call state 1 call type 2 call dir 1Table 203 provides an alphabetical listing of the fields shown in the debug isdn tgrm command output and a description of each field.
Related Commands
debug isis adj packets
To display information on all adjacency-related activity such as hello packets sent and received and Intermediate System-to-Intermediate System (IS-IS) adjacencies going up and down, use the debug isis adj packets command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isis adj packets [interface]
no debug isis adj packets [interface]
Syntax Description
Command Modes
Privileged EXEC
Examples
The following is sample output from the debug isis adj packets command:
Router# debug isis adj packetsISIS-Adj: Rec L1 IIH from 0000.0c00.40af (Ethernet0), cir type 3, cir id BBBB.BBBB.BBBB.01ISIS-Adj: Rec L2 IIH from 0000.0c00.40af (Ethernet0), cir type 3, cir id BBBB.BBBB.BBBB.01ISIS-Adj: Rec L1 IIH from 0000.0c00.0c36 (Ethernet1), cir type 3, cir id CCCC.CCCC.CCCC.03ISIS-Adj: Area mismatch, level 1 IIH on Ethernet1ISIS-Adj: Sending L1 IIH on Ethernet1ISIS-Adj: Sending L2 IIH on Ethernet1ISIS-Adj: Rec L2 IIH from 0000.0c00.0c36 (Ethernet1), cir type 3, cir id BBBB.BBBB.BBBB.03The 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:
1—Level 1 only; 2—Level 2 only; 3—Level 1/2The 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.01The 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 Ethernet1The 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 Ethernet1ISIS-Adj: Sending L2 IIH on Ethernet1debug isis authentication
To enable debugging of Intermediate System-to-Intermediate System (IS-IS) authentication, use the debug isis authentication command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isis authentication information
no debug isis authentication information
Syntax Description
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the debug isis authentication command with the information keyword:
Router# debug isis authentication information3d03h:ISIS-AuthInfo:No auth TLV found in received packet3d03h:ISIS-AuthInfo:No auth TLV found in received packetThe 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.
debug isis mpls traffic-eng advertisements
To print information about traffic engineering advertisements in Intermediate System-to-Intermediate System (IS-IS) link-state advertisement (LSA) messages, use the debug isis mpls traffic-eng advertisements command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isis mpls traffic-eng advertisements
no debug isis mpls traffic-eng advertisements
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
In the following example, information about traffic engineering advertisements is printed in IS-IS LSA messages:
Router# debug isis mpls traffic-eng advertisementsSystem ID:Router1.00Router ID:10.106.0.6Link Count:1Link[1]Neighbor System ID:Router2.00 (P2P link)Interface IP address:10.42.0.6Neighbor IP Address:10.42.0.10Admin. Weight:10Physical BW:155520000 bits/secReservable BW:5000000 bits/secBW unreserved[0]:2000000 bits/sec, BW unreserved[1]:100000 bits/secBW unreserved[2]:100000 bits/sec, BW unreserved[3]:100000 bits/secBW unreserved[4]:100000 bits/sec, BW unreserved[5]:100000 bits/secBW unreserved[6]:100000 bits/sec, BW unreserved[7]:0 bits/secAffinity Bits:0x00000000Table 204 describes the significant fields shown in the display.
debug isis mpls traffic-eng events
To print information about traffic engineering-related Intermediate System-to-Intermediate System (IS-IS) events, use the debug isis mpls traffic-eng events command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isis mpls traffic-eng events
no debug isis mpls traffic-eng events
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
In the following example, information is printed about traffic engineering-related IS-IS events:
Router# debug isis mpls traffic-eng eventsISIS-RRR:Send MPLS TE Et4/0/1 Router1.02 adjacency down:address 0.0.0.0ISIS-RRR:Found interface address 10.1.0.6 Router1.02, building subtlv... 58 bytesISIS-RRR:Found interface address 10.42.0.6 Router2.00, building subtlv... 64 bytesISIS-RRR:Interface address 0.0.0.0 Router1.00 not found, not building subtlvISIS-RRR:LSP Router1.02 changed from 0x606BCD30ISIS-RRR:Mark LSP Router1.02 changed because TLV contents different, code 16ISIS-RRR:Received 1 MPLS TE links flood info for system id Router1.00debug isis nsf
To display information about the Intermediate System-to-Intermediate System (IS-IS) state during a Cisco nonstop forwarding (NSF) restart, use the debug isis nsf command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isis nsf [detail]
no debug isis nsf [detail]
Syntax Description
Command Modes
Privileged EXEC
Command History
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 nsfIS-IS NSF events debugging is onThe following example displays detailed IS-IS state information during an NSF restart:
router# debug isis nsf detailIS-IS NSF events (detailed) debugging is onrouter#Jan 24 20:04:54.090:%CLNS-5-ADJCHANGE:ISIS:Adjacency to gsr1 (GigabitEthernet2/0/0) Up, Standby adjacencyJan 24 20:04:54.090:ISIS-NSF:ADJ:000C.0000.0000 (Gi2/0/0), type 8/1, cnt 0/1, ht 10 (NEW)Jan 24 20:04:54.142:ISIS-NSF:Rcv LSP - L2 000B.0000.0000.00-00, seq 251, csum B0DC, ht 120, len 123 (local)Jan 24 20:04:55.510:ISIS-NSF:Rcv LSP - L1 000B.0000.0000.00-00, seq 23E, csum D20D, ht 120, len 100 (local)Jan 24 20:04:56.494:ISIS-NSF:ADJ:000C.0000.0000 (Gi2/0/0), type 8/0, cnt 0/1, ht 30Jan 24 20:04:56.502:ISIS-NSF:Rcv LSP - L1 000B.0000.0000.01-00, seq 21C, csum 413, ht 120, len 58 (local)Jan 24 20:04:58.230:ISIS-NSF:Rcv LSP - L2 000C.0000.0000.00-00, seq 11A, csum E197, ht 1194, len 88 (Gi2/0/0)Jan 24 20:05:00.554:ISIS-NSF:Rcv LSP - L1 000B.0000.0000.00-00, seq 23F, csum 1527, ht 120, len 111 (local)Related Commands
debug isis rib
To display debugging information for Integrated Intermediate System-to-Intermediate System (IS-IS) IP Version 4 routes in the global or local Routing Information Base (RIB), use the debug isis rib command in privileged EXEC mode. To disable the debugging of IS-IS IP Version 4 routes, use the no form of this command.
debug isis rib [global | [local [access-list-number | terse]]
no debug isis rib [global | local]
Syntax Description
Defaults
Debugging of IS-IS IP Version 4 routes is disabled.
Command Modes
Privileged EXEC
Command History
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 1accest-list 1 permit 10.1.1.0 0.0.0.255! access-list 1 is configuredRouter# debug isis rib local terse 100:07:07: ISIS-LR: 10.1.1.0/24 aged out in LSP[10/(7->8)]! The route 10.1.1.0/24 is removed from the IS-IS local RIB LSP[10/(7->8)].00:07:07: ISIS-LR: rem path: [115/80/20] via 10.2.2.2(Et2) from 10.22.22.22 tg 0 LSP[10/7] from active chain (add to deleted chain)!The remote path [115/80/20] is removed from the active chain.00:07:07: ISIS-LR: Enqueued to updateQ[2] for 10.1.1.0/24!Q[2] is marked to be the update00:07:07: ISIS-LR: rem path: [115/80/20] via 10.2.2.2(Et2) from 10.22.22.22 tg 0 LSP[10/7] from deleted chain00:07:07: ISIS-LR: Rem RT 10.1.1.0/24!The remote route [115/80/20] is removed from the deleted chainTable 205 describes the significant fields shown in the display.
Related Commands
ip route priority high
Assigns a high priority to an IS-IS IP prefix.
show isis rib
Displays paths for routes in the IP Version 4 IS-IS local RIB.
debug isis rib redistribution
To debug the events that update the Intermediate System-to-Intermediate System (IS-IS) redistribution cache, use the debug isis rib redistribution command in privileged EXEC mode. To turn off debugging, use the no form of this command.
debug isis rib redistribution [level-1 | level-2] [access-list]
no debug isis rib redistribution [level-1 | level-2] [access-list]
Syntax Description
Command Modes
Privileged EXEC
Command History
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 123IS-IS IPv4 redistribution RIB debugging is on for access list 123 for L1Router# router isisRouter(config-router)# redistribute connected level-1Router(config)# access-list 123 permit ip 10.0.0.0 0.255.255.255 anyRouter(config)# interface Loopback123Router(config-if)# ip address 10.123.123.3 255.255.255.255Nov 25 00:33:46.532: ISIS-RR: 10.123.123.3/32: Up event, from 0x607CAF60Nov 25 00:33:46.532: ISIS-RR: looking at L1 redist RIBNov 25 00:33:46.532: ISIS-RR: redistributed to ISISNov 25 00:33:46.532: ISIS-RR: added 10.123.123.3/32 to L1 redist RIB: [Connected/0] tag 0 externalNov 25 00:33:47.532: ISIS-RR: Scanning L1 redist RIBNov 25 00:33:47.532: ISIS-RR: adv 10.123.123.3/32 as L1 redist routeNov 25 00:33:47.532: ISIS-RR: End of scanningL1 redist RIBThe 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 externalThe 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 routRelated Commands
clear isis rib redistribution
Clears some or all prefixes in the local redistribution cache.
show isis rib redistribution
Displays the prefixes in the IS-IS redistribution cache.
debug isis spf statistics
To display statistical information about building routes between intermediate systems (ISs), use the debug isis spf statistics command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isis spf statistics
no debug isis spf statistics
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
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
Examples
The following is sample output from the debug isis spf statistics command:
Router# debug isis spf statisticsISIS-Stats: Compute L1 SPT, Timestamp 2780.328 secondsISIS-Stats: Complete L1 SPT, Compute time 0.004, 1 nodes on SPTISIS-Stats: Compute L2 SPT, Timestamp 2780.3336 secondsISIS-Stats: Complete L2 SPT, Compute time 0.056, 12 nodes on SPTTable 206 describes the significant fields shown in the display.
The following lines show the statistical information available for Level 1 ISs:
ISIS-Stats: Compute L1 SPT, Timestamp 2780.328 secondsISIS-Stats: Complete L1 SPT, Compute time 0.004, 1 nodes on SPTThe 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 secondsISIS-Stats: Complete L2 SPT, Compute time 0.056, 12 nodes on SPTThis 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.
debug isis spf-events
To display a log of significant events during an Intermediate System-to-Intermediate System (IS-IS) shortest-path first (SPF) computation, use the debug isis spf-events command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isis spf-events
no debug isis spf-events
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
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-eventsISIS-Spf: Compute L2 IPv6 SPTISIS-Spf: Move 0000.0000.1111.00-00 to PATHS, metric 0ISIS-Spf: Add 0000.0000.2222.01-00 to TENT, metric 10ISIS-Spf: Move 0000.0000.2222.01-00 to PATHS, metric 10ISIS-Spf: considering adj to 0000.0000.2222 (Ethernet3/1) metric 10, level 2, circuit 3, adj 3ISIS-Spf: (accepted)ISIS-Spf: Add 0000.0000.2222.00-00 to TENT, metric 10ISIS-Spf: Next hop 0000.0000.2222 (Ethernet3/1)ISIS-Spf: Move 0000.0000.2222.00-00 to PATHS, metric 10ISIS-Spf: Add 0000.0000.2222.02-00 to TENT, metric 20ISIS-Spf: Next hop 0000.0000.2222 (Ethernet3/1)ISIS-Spf: Move 0000.0000.2222.02-00 to PATHS, metric 20ISIS-Spf: Add 0000.0000.3333.00-00 to TENT, metric 20ISIS-Spf: Next hop 0000.0000.2222 (Ethernet3/1)ISIS-Spf: Move 0000.0000.3333.00-00 to PATHS, metric 20debug isis update-packets
To display various sequence number protocol data units (PDUs) and link-state packets that are detected by a router, use the debug isis update-packets command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isis update-packets
no debug isis update-packets
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
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-packetsISIS-Update: Sending L1 CSNP on Ethernet0ISIS-Update: Sending L2 CSNP on Ethernet0ISIS-Update: Updating L2 LSPISIS-Update: Delete link 888.8800.0181.00 from L2 LSP 1600.8906.4022.00-00, seq EISIS-Update: Updating L1 LSPISIS-Update: Sending L1 CSNP on Ethernet0ISIS-Update: Sending L2 CSNP on Ethernet0ISIS-Update: Add link 8888.8800.0181.00 to L2 LSP 1600.8906.4022.00-00, new seq 10,len 91ISIS-Update: Sending L2 LSP 1600.8906.4022.00-00, seq 10, ht 1198 on Tunnel0ISIS-Update: Sending L2 CSNP on Tunnel0ISIS-Update: Updating L2 LSPISIS-Update: Rate limiting L2 LSP 1600.8906.4022.00-00, seq 11 (Tunnel0)ISIS-Update: Updating L1 LSPISIS-Update: Rec L2 LSP 888.8800.0181.00.00-00 (Tunnel0)ISIS-Update: PSNP entry 1600.8906.4022.00-00, seq 10, ht 1196The 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 Ethernet0ISIS-Update: Sending L2 CSNP on Ethernet0The 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 LSPISIS-Update: Delete link 888.8800.0181.00 from L2 LSP 1600.8906.4022.00-00, seq EThe 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 LSPISIS-Update: Sending L1 CSNP on Ethernet0ISIS-Update: Sending L2 CSNP on Ethernet0ISIS-Update: Add link 8888.8800.0181.00 to L2 LSP 1600.8906.4022.00-00, new seq 10,len 91The 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 Tunnel0The following lines indicates that a Level 2 LSP could not be transmitted because it was recently sent:
ISIS-Update: Sending L2 CSNP on Tunnel0ISIS-Update: Updating L2 LSPISIS-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 LSPISIS-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 1196debug iua as
To display debugging messages for the IDSN User Adaptation Layer (IUA) application server (AS), use the debug iua as command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug iua as {user | state} {all | name as-name}
no debug iua as
Syntax Description
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
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 allIUA :state debug turned ON for ALL AS00:11:52:IUA:AS as1 number of ASPs up is 100:11:57:IUA:AS as1 xsition AS-Up --> AS-Active, cause - ASP asp1Related CommandsActive
debug iua asp
To display debugging messages for the IDSN User Adaptation Layer (IUA) application server process (ASP), use the debug iua asp command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug iua asp {pak | peer-msg | sctp-sig | state} {all | name asp-name}
no debug iua asp
Syntax Description
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
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 allIUA :peer message debug turned ON for ALL ASPsRouter#00:04:58:IUA :recieved ASP_UP message on ASP asp100:04:58:IUA:ASP asp1 xsition ASP-Down --> ASP-Up , cause - rcv peermsgASP-UP00:04:58:IUA:sending ACK of type 0x304 to asp asp100:05:03:IUA:recv ASP_ACTIVE message for ASP asp100:05:03:IUA:ASP asp1 xsition ASP-Up --> ASP-Active, cause - rcv peermsgASP-ActiveRelated Commands
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
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
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 authenticationAAA/AUTHEN/START (116852612): Method=KRB5AAA/AUTHEN (116852612): status = GETUSERAAA/AUTHEN/CONT (116852612): continue_loginAAA/AUTHEN (116852612): status = GETUSERAAA/AUTHEN (116852612): Method=KRB5AAA/AUTHEN (116852612): status = GETPASSAAA/AUTHEN/CONT (116852612): continue_loginAAA/AUTHEN (116852612): status = GETPASSAAA/AUTHEN (116852612): Method=KRB5AAA/AUTHEN (116852612): password incorrectAAA/AUTHEN (116852612): status = FAILThe 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 kerberosKerberos: Requesting TGT with expiration date of 820911631Kerberos: Sent TGT request to KDCKerberos: Received TGT reply from KDCKerberos: Received valid credential with endtime of 820911631The 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 kerberosKerberos: Requesting TGT with expiration date of 820911731Kerberos: Sent TGT request to KDCKerberos: Received TGT reply from KDCKerberos: Received invalid credential.AAA/AUTHEN (425003829): password incorrectThe 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 kerberosKerberos: authentication failed when parsing nameKerberos: authentication failed while getting my addressKerberos: authentication failed while getting time of dayKerberos: authentication failed while allocating credentials cacheRelated Commands
debug aaa authentication
Displays information on accountable events as they occur.
debug kpml
To enable Keypad Markup Language (KPML) parser and builder debugs, use the debug kpml command to specify the debug option.
To disable KPML parser and builder debugs, use the no form of this command (you must enter one option).
debug kpml [all | parser | builder | error]
no debug kpml [all | parser | builder | error]
Syntax Description
all
Enables all kpml debug tracing.
parser
Enables kpml parser tracing.
builder
Enables kpml builder tracing.
error
Enables kpml error tracing.
Command Default
no debug kpml all
Command Modes
Privileged EXEC mode
Command History
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:
•
•
•
•
–
–
–
–
–
–
•
•
•
You can configure support only on a SIP VoIP dial peer.
Examples
The following is output from the debug kpml command:
SIP call is established. DTMF sip-kpml was negotiated....//-1/xxxxxxxxxxxx/KPML/Parser/kpml_init://-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: encode_data=0x64E25B48//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: chunk_size=2k, max_allowed=16k//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: context=0x6488C0AC, mp=0x6488B89C//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_request://-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_pattern://-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_regex_list://-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: malloc xml_buf=0x645E910C, length=328//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_request://-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_pattern://-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_regex_list://-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_request: length=289, buffp=0x645E9251//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: rc=0, encoded str=<?xml version="1.0" encoding="UTF-8"?><kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0"><pattern persist="persist"><regex tag="dtmf">[x*#ABCD]</regex></pattern></kpml-request>//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_free:kpml_encode_context_free:mem_mgr_mempool_free: mem_refcnt(6488B89C)=0 - mempool cleanup/-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:Sent:SUBSCRIBE sip:8888@172.18.193.250:5060 SIP/2.0Via: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bKFF36From: <sip:172.18.193.251>;tag=EA330-F6To: <sip:8888@172.18.193.250>;tag=39497C-2EACall-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251CSeq: 103 SUBSCRIBEMax-Forwards: 70Date: Fri, 01 Mar 2002 00:16:15 GMTUser-Agent: Cisco-SIPGateway/IOS-12.xEvent: kpmlExpires: 7200Contact: <sip:172.18.193.251:5060>Content-Type: application/kpml-request+xmlContent-Length: 327<?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/SIP/Msg/ccsipDisplayMsg:Received:SUBSCRIBE sip:172.18.193.251:5060 SIP/2.0Via: SIP/2.0/UDP 172.18.193.250:5060;branch=z9hG4bK5FE3From: <sip:8888@172.18.193.250>;tag=39497C-2EATo: <sip:172.18.193.251>;tag=EA330-F6Call-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251CSeq: 101 SUBSCRIBEMax-Forwards: 70Date: Fri, 01 Mar 2002 01:02:46 GMTUser-Agent: Cisco-SIPGateway/IOS-12.xEvent: kpmlExpires: 7200Contact: <sip:172.18.193.250:5060>Content-Type: application/kpml-request+xmlContent-Length: 327<?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_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/KPML/Parser/kpml_regex_char_data_ptbuild: char data=[x*#ABCD]//-1/xxxxxxxxxxxx/KPML/Parser/kpml_end_element_handler: elem name=regex//-1/xxxxxxxxxxxx/KPML/Parser/kpml_end_element_handler: elem name=pattern//-1/xxxxxxxxxxxx/KPML/Parser/kpml_end_element_handler: elem name=kpml-request//-1/xxxxxxxxxxxx/KPML/Parser/kpml_pattern_ptproc://-1/xxxxxxxxxxxx/KPML/Parser/kpml_regex_ptproc://-1/xxxxxxxxxxxx/KPML/Parser/kpml_decode_context_free:kpml_decode_context_free:mem_mgr_mempool_free: mem_refcnt(6488B89C)=0 - mempool cleanup//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:Received:SIP/2.0 200 OKVia: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bKFF36From: <sip:172.18.193.251>;tag=EA330-F6To: <sip:8888@172.18.193.250>;tag=39497C-2EADate: Fri, 01 Mar 2002 01:02:51 GMTCall-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251CSeq: 103 SUBSCRIBEContent-Length: 0Contact: <sip:172.18.193.250:5060>Expires: 7200//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:Sent:SIP/2.0 200 OKVia: SIP/2.0/UDP 172.18.193.250:5060;branch=z9hG4bK5FE3From: <sip:8888@172.18.193.250>;tag=39497C-2EATo: <sip:172.18.193.251>;tag=EA330-F6Date: Fri, 01 Mar 2002 00:16:24 GMTCall-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251CSeq: 101 SUBSCRIBEContent-Length: 0Contact: <sip:172.18.193.251:5060>Expires: 7200//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:Sent:NOTIFY sip:172.18.193.250:5060 SIP/2.0Via: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bK101EA4From: <sip:172.18.193.251>;tag=EA330-F6To: <sip:8888@172.18.193.250>;tag=39497C-2EACall-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251CSeq: 104 NOTIFYMax-Forwards: 70Date: Fri, 01 Mar 2002 00:16:24 GMTUser-Agent: Cisco-SIPGateway/IOS-12.xEvent: kpmlSubscription-State: activeContact: <sip:172.18.193.251:5060>Content-Length: 0//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:Received:NOTIFY sip:172.18.193.251:5060 SIP/2.0Via: SIP/2.0/UDP 172.18.193.250:5060;branch=z9hG4bK6111From: <sip:8888@172.18.193.250>;tag=39497C-2EATo: <sip:172.18.193.251>;tag=EA330-F6Call-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251CSeq: 102 NOTIFYMax-Forwards: 70Date: Fri, 01 Mar 2002 01:02:51 GMTUser-Agent: Cisco-SIPGateway/IOS-12.xEvent: kpmlSubscription-State: activeContact: <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.0Via: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bK1117DEFrom: <sip:172.18.193.251>;tag=EA330-F6To: <sip:8888@172.18.193.250>;tag=39497C-2EACall-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251CSeq: 105 NOTIFYMax-Forwards: 70Date: Fri, 01 Mar 2002 00:37:33 GMTUser-Agent: Cisco-SIPGateway/IOS-12.xEvent: kpmlSubscription-State: activeContact: <sip:172.18.193.251:5060>Content-Type: application/kpml-response+xmlContent-Length: 113<?xml version="1.0" encoding="UTF-8"?><kpml-response version="1.0" code="200" text="OK" digits="1" tag="dtmf"/>/-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:Received:SIP/2.0 200 OKVia: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bK1117DEFrom: <sip:172.18.193.251>;tag=EA330-F6To: <sip:8888@172.18.193.250>;tag=39497C-2EADate: Fri, 01 Mar 2002 01:24:08 GMTCall-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251CSeq: 105 NOTIFYContent-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.0Via: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bK12339From: <sip:172.18.193.251>;tag=EA330-F6To: <sip:8888@172.18.193.250>;tag=39497C-2EACall-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251CSeq: 106 NOTIFYMax-Forwards: 70Date: Fri, 01 Mar 2002 00:37:44 GMTUser-Agent: Cisco-SIPGateway/IOS-12.xEvent: kpmlSubscription-State: activeContact: <sip:172.18.193.251:5060Content-Type: application/kpml-response+xmlContent-Length: 113<?xml version="1.0" encoding="UTF-8"?><kpml-response version="1.0" code="200" text="OK" digits="2" tag="dtmf"/>/-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:Received:SIP/2.0 200 OKVia: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bK12339From: <sip:172.18.193.251>;tag=EA330-F6To: <sip:8888@172.18.193.250>;tag=39497C-2EADate: Fri, 01 Mar 2002 01:24:20 GMTCall-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251CSeq: 106 NOTIFYContent-Length: 0...Related Commands
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.
debug kron {all | exec-cli | info | major}
no debug kron {all | exec-cli | info | major}
Syntax Description
Command Default
If no keyword is specified, all debugging messages are displayed.
Command Modes
Privileged EXEC (#)
Command History
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-cliKron cli occurrence messages debugging is on2w6d: Call parse_cmd 'show version'2w6d: Kron CLI return 0'**CLI 'show version':Cisco Internetwork Operating System Software IOS (tm) C2600 Software (C2600-I-MRelated Commands
show kron schedule
Displays the status and schedule information for Command Scheduler occurrences.
debug l2ctrl
To enable debugging for Layer 2 Control (L2CTRL), use the debug l2ctrl command in privileged EXEC mode. To disable debugging for L2CTRL, use the no form of this command.
debug l2ctrl {all | evc | pm | registry}
no debug l2ctrl {all | evc | pm | registry}
Syntax Description
all
Displays all L2CTRL debugging messages.
evc
Displays Ethernet virtual circuit (EVC) and L2CTRL messages.
pm
Displays switch PM and L2CTRL messages.
registry
Displays L2CTRL registries.
Command Modes
Privileged EXEC (#)
Command History
Examples
The following example shows how to enable debugging of all L2CTRL related events:
Router# debug l2ctrl allRelated Commands
debug l2relay events
To start debugging of Layer 2 Relay events, use the debug l2relay events command in privileged EXEC mode. To disable debugging output, use the no form of this command (SGSN D-node only).
debug l2relay events
no debug l2relay events
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
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
Examples
The following example enables the display of Layer 2 Relay events:
Router# debug l2relay eventsRelated Commands
debug l2relay packets
To display information about Layer 2 Relay packets, use the debug l2relay packets command in privileged EXEC mode. To disable debugging output, use the no form of this command (SGSN D-node only).
debug l2relay packets
no debug l2relay packets
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
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
Examples
The following example enables the display of Layer 2 Relay packets:
Router# debug l2relay packetsRelated Commands
debug l2tp
To enable debugging of Layer 2 Tunneling Protocol (L2TP) information, use the debug l2tp command in privileged EXEC mode. To disable L2TP debugging, use the no form of this command.
debug l2tp {all | application | brief | db {error | event | lookup} | error | event | export | l2tun | packet {brief | detail | error | event} | route | seq [brief] | snmp | timer}
no debug l2tp {all | application | brief | db {error | event | lookup} | error | event | export | l2tun | packet {brief | detail | error | event} | route | seq [brief] | snmp | timer}
Syntax Description
Command Modes
Privileged EXEC (#)
Command History
Usage Guidelines
Use the debug l2tp command to troubleshoot L2TP operations.
Examples
The following example shows how to enable L2TP debugging:
Router> enableRouter# debug l2tp allL2TP most commonly used debugs debugging is onRouter# debug l2tp applicationL2TP application debugs debugging is onRouter# debug l2tp briefL2TP brief, one line debugs debugging is onRouter# debug l2tp db lookupL2TP database lookups debugging is onRouter# debug l2tp errorL2TP errors debugging is onRouter# debug l2tp seqL2TP sequencing debugging is onRouter# debug l2tp snmpL2TP SNMP events debugging is onThe following sample output of the show debugging command displays the debugs enabled for L2TP. The field descriptions are self-explanatory.
Router# show debuggingL2TP:L2TP packet events debugging is onL2TP packet errors debugging is onL2TP packet detail debugging is onL2TP errors debugging is onL2TP events debugging is onL2TP L2TUN socket API debugging is onL2TP sequencing debugging is onL2TP export data to applications and cli debugging is onL2TP route watch debugging is onL2TP timers debugging is onL2TP brief, one line debugs debugging is onL2TP application debugs debugging is onL2TP database lookups debugging is onL2TP SNMP events debugging is onRelated Commands
show debugging
Displays information about the types of debugging that are enabled for your router.
debug l2tp redundancy
To enable the display of information on Layer 2 Tunneling Protocol (L2TP) sessions that contain redundancy status, use the debug l2tp redundancy command in user or privileged EXEC mode. To disable this debugging, use the no form of this command.
debug l2tp redundancy {cf | detail | error | event | fsm | resync | rf}
no debug l2tp redundancy
Syntax Description
Command Modes
User EXEC (>)
Privileged EXEC (#)Command History
Cisco IOS XE Release 2.2.
This command was introduced in Cisco IOS XE Release 2.2.
Usage Guidelines
Use the debug l2tp redundancy command in privileged EXEC mode to display a list of redundancy events and errors.
Use the show l2tp redundancy command in privileged EXEC mode to display information on the state of the Layer 2 Tunneling Protocol (L2TP) or a specific L2TP session redundancy data.
Examples
The following example shows how to display a debug of redundancy events during the setup and termination of an L2TP High Availability (HA) tunnel for a L2TP Network Server (LNS) active Route Processor (RP):
LNS1> debug enableLNS1# debug l2tp redundancy cfL2TP redundancy cf debugging is onLNS1# debug l2tp redundancy detailL2TP redundancy details debugging is onLNS1# debug l2tp redundancy errorL2TP redundancy errors debugging is onLNS1# debug l2tp redundancy eventL2TP redundancy events debugging is onLNS1# debug l2tp redundancy fsmL2TP redundancy fsm debugging is onLNS1# debug l2tp redundancy resyncL2TP redundancy resync debugging is onLNS1# debug l2tp redundancy rfL2TP redundancy rf debugging is onLNS1#*Aug 26 18:00:00.467: %SYS-5-CONFIG_I: Configured from console by consoleLNS1#*Aug 26 18:00:45.631: L2TP tnl 01000:________: CCM initialized CCM session*Aug 26 18:00:45.631: : L2TP HA:CC playback chkpt skipped, CC not doing HA*Aug 26 18:00:45.711: : L2TP HA FSM:Receive proto FSM event 19*Aug 26 18:00:45.711: : L2TP HA FSM:Receive RxSCCRQ*Aug 26 18:00:45.711: : L2TP HA:lcm_cc alloc: l2tp_cc 070B45B8, lcm_cc 02FE55E8*Aug 26 18:00:45.711: : L2TP HA FSM:FSM-CC ev Rx-SCCRQ*Aug 26 18:00:45.711: : L2TP HA FSM:FSM-CC Idle->Wt-ChkptSidRmt*Aug 26 18:00:45.711: : L2TP HA FSM:FSM-CC do Block-Tx-AckSCCRQ*Aug 26 18:00:45.711: : L2TP HA FSM:Checkpoint Two Cc IDs*Aug 26 18:00:45.711: L2TP HA CF: Chkpt send: s/c id 0/52631, BothCcId, seq 0, ns/nr 0/0, rid 51583, len 52; flush = 1, ctr 1*Aug 26 18:00:45.711: 01000:0000CD97: L2TP HA:Enqueue peer Ns 0 to ns_q, seq 1 (q sz 0)*Aug 26 18:00:45.711: L2TP tnl 01000:0000CD97: Encoding SCCRQ-IN CHKPT*Aug 26 18:00:45.711: L2TP tnl 01000:0000CD97: Tx CHKPT*Aug 26 18:00:45.739: L2TP tnl 01000:0000CD97: Encoding SCCRP-OUT CHKPT*Aug 26 18:00:45.739: L2TP tnl 01000:0000CD97: Tx CHKPT*Aug 26 18:00:45.739: : L2TP HA:Adjust local window size to 10*Aug 26 18:00:45.739: 01000:0000CD97: L2TP HA FSM:Receive proto TxCM event SCCRP*Aug 26 18:00:45.739: : L2TP HA FSM:Receive TxSCCRPLNS1#*Aug 26 18:00:45.739: : L2TP HA FSM:FSM-CC ev Tx-SCCRP*Aug 26 18:00:45.739: : L2TP HA FSM:FSM-CC Wt-ChkptSidRmt->WtCcIdRmt2*Aug 26 18:00:45.739: : L2TP HA FSM:FSM-CC do Block-Tx-SCCRP*Aug 26 18:00:45.739: 01000:0000CD97: L2TP HA FSM:Found blocked RxSCCRQ, seq_num 1*Aug 26 18:00:45.739: 01000:0000CD97: L2TP HA FSM:Queued SCCRP to CC hold_q*Aug 26 18:00:46.863: : L2TP HA FSM:CHKPT status callback: status 0, len 56*Aug 26 18:00:46.863: : L2TP HA FSM:Context s/c id 0/52631, BothCcId, seq 1, ns/nr 0/0, rid 51583, len 52*Aug 26 18:00:46.863: L2TP HA CF: Rcvd status s/c id 0/52631, BothCcId, seq 1, ns/nr 0/0, rid 51583, len 52*Aug 26 18:00:46.863: L2TP HA CF: Rcvd status 0: len 56*Aug 26 18:00:46.863: L2TP HA CF: Status content s/c id 0/52631, BothCcId, seq 1, ns/nr 0/0, rid 51583, len 52*Aug 26 18:00:46.863: 01000:0000CD97: L2TP HA FSM:Recv chkpt ack: s/c id 0/52631, BothCcId, seq 1, ns/nr 0/0, rid 51583, len 52*Aug 26 18:00:46.863: : L2TP HA FSM:Receive CC-ChkptAck*Aug 26 18:00:46.863: : L2TP HA FSM:FSM-CC ev Rx-CkpACK-CcID-Rmt*Aug 26 18:00:46.863: : L2TP HA FSM:FSM-CC WtCcIdRmt2->Wt-RxSccn*Aug 26 18:00:46.863: : L2TP HA FSM:FSM-CC do Allow-Tx-SCCRP2*Aug 26 18:00:46.863: : L2TP HA FSM:Received Chkpt of local + remote CC ID*Aug 26 18:00:46.863: 01000:0000CD97: L2TP HA:Try to remove from CC's ns_q: seq num 1 (current Ns 1)*Aug 26 18:00:46.863: 01000:0000CD97: L2TP HA:Ns entry to remove: found (current Ns 1)*Aug 26 18:00:46.863: 01000:0000CD97: L2TP HA:Advance peer Nr to 1 (ns_q sz 0)*Aug 26 18:00:46.863: 01000:0000CD97: L2TP HA:CC send all unblocked if canLNS1#*Aug 26 18:00:46.863: 01000:0000CD97: L2TP HA:CC send one blocked CM (SCCRP): ns 0 (0), nr 1*Aug 26 18:00:46.863: L2TP HA CF: O SCCRP 51583/0 ns/nr 0/1*Aug 26 18:00:47.867: 01000:0000CD97: L2TP HA FSM:Receive Cm-Ack*Aug 26 18:00:47.867: 01000:0000CD97: L2TP HA FSM:Receive CC Cm-Ack*Aug 26 18:00:47.867: : L2TP HA FSM:FSM-CC ev Rx-CmACK*Aug 26 18:00:47.867: : L2TP HA FSM:FSM-CC in Wt-RxSccn*Aug 26 18:00:47.867: : L2TP HA FSM:FSM-CC do Ignore*Aug 26 18:00:47.867: 01000:0000CD97: L2TP HA FSM:Ignore event*Aug 26 18:00:47.867: 01000:0000CD97: L2TP HA FSM:Check for Ns/Nr update 1, peer 1*Aug 26 18:00:47.867: 01000:0000CD97: L2TP HA FSM:Receive peer Ns/Nr update (1,0/1,1, int 1, rx 1, 1) (ns_q sz 0)*Aug 26 18:00:47.867: 01000:0000CD97: L2TP HA FSM:Peer Ns 1 (1), Nr 1 (ns_q sz 0)*Aug 26 18:00:48.087: 01000:0000CD97: L2TP HA FSM:Check for Ns/Nr update 1, peer 1*Aug 26 18:00:48.087: 01000:0000CD97: L2TP HA FSM:Receive peer Ns/Nr update (1,0/1,1, int 1, rx 1, 1) (ns_q sz 0)*Aug 26 18:00:48.087: 01000:0000CD97: L2TP HA FSM:Peer Ns 1 (2), Nr 1 (ns_q sz 0)*Aug 26 18:00:48.087: : L2TP HA FSM:Receive proto FSM event 21*Aug 26 18:00:48.087: 01000:0000CD97: L2TP HA FSM:Receive RxSCCCN*Aug 26 18:00:48.087: : L2TP HA FSM:FSM-CC ev Rx-SCCCN*Aug 26 18:00:48.087: : L2TP HA FSM:FSM-CC Wt-RxSccn->WtCcsUp*Aug 26 18:00:48.087: : L2TP HA FSM:FSM-CC do Allow-Tx-AckSCCCN*Aug 26 18:00:48.087: 01000:0000CD97: L2TP HA FSM:Allow TxSCCCN-ACK*Aug 26 18:00:48.087: 01000:0000CD97: L2TP HA FSM:Receive CcUp*Aug 26 18:00:48.087: : L2TP HA FSM:FSM-CC ev Proto CcUp*Aug 26 18:00:48.087: : L2TP HA FSM:FSM-CC WtCcsUp->Wt-CkptCcUp*Aug 26 18:00:48.087: : L2TP HA FSM:FSM-CC do Chkpt-CcUp2*Aug 26 18:00:48.087: : L2TP HA FSM:Checkpoint CcUp*Aug 26 18:00:48.087: L2TP HA CF: Chkpt send: s/c id 0/52631, CcUp, seq 0, ns/nr 1/1, rid 0, len 52; flush = 1, ctr 2*Aug 26 18:00:48.091: L2TP tnl 01000:0000CD97: CCM added sync data*Aug 26 18:00:48.095: 01000:0000CD97: L2TP HA FSM:Check for Ns/Nr update 2, peer 1*Aug 26 18:00:48.095: 01000:0000CD97: L2TP HA FSM:Receive peer Ns/Nr update (2,1/1,1, int 2, rx 1, 2) (ns_q sz 0)*Aug 26 18:00:48.095: 01000:0000CD97: L2TP HA FSM:Peer Ns 2 (3), Nr 1 (ns_q sz 0)*Aug 26 18:00:48.095: L2TP _____:01000:000036F8: Encoding ICRQ-IN CHKPT*Aug 26 18:00:48.095: L2TP _____:01000:000036F8: Tx CHKPT*Aug 26 18:00:48.095: : L2TP HA FSM:Receive proto FSM event 3*Aug 26 18:00:48.095: : L2TP HA FSM:Receive RxICRQ*Aug 26 18:00:48.095: _____:01000:000036F8: L2TP HA FSM: Using ICRQ FSM*Aug 26 18:00:48.095: _____:01000:000036F8: L2TP HA FSM:FSM-Sn ev created*Aug 26 18:00:48.095: _____:01000:000036F8: L2TP HA FSM:FSM-Sn Init->Idle*Aug 26 18:00:48.095: _____:01000:000036F8: L2TP HA FSM:FSM-Sn do none*Aug 26 18:00:48.095: _____:01000:000036F8: L2TP HA FSM:FSM-Sn ev Rx-xCRQ*Aug 26 18:00:48.095: _____:01000:000036F8: L2TP HA FSM:FSM-Sn Idle->Wt-ChkptSidRmt*Aug 26 18:00:48.095: _____:01000:000036F8: L2TP HA FSM:FSM-Sn do Block-Tx-AckXCRQ*Aug 26 18:00:48.095: _____:01000:000036F8: L2TP HA FSM:Checkpoint TwoSessionIDs*Aug 26 18:00:48.095: L2TP HA CF: Chkpt send: s/c id 14072/52631, BothSesId, seq 0, ns/nr 1/2, rid 40276, len 52; flush = 1, ctr 3*Aug 26 18:00:48.095: _____:01000:000036F8: L2TP HA:Enqueue peer Ns 2 to ns_q, seq 3 (q sz 0)*Aug 26 18:00:48.131: : L2TP HA:Try to buffer sock msg type 19*Aug 26 18:00:48.131: : L2TP HA:Buffering skipped*Aug 26 18:00:48.131: L2TP _____:01000:000036F8: Encoding ICRP-OUT CHKPT*Aug 26 18:00:48.131: L2TP _____:01000:000036F8: Tx CHKPT*Aug 26 18:00:48.131: 01000:0000CD97: L2TP HA FSM:Receive proto TxCM event ICRP*Aug 26 18:00:48.131: _____:_____:000036F8: L2TP HA FSM:Receive TxICRP*Aug 26 18:00:48.131: _____:01000:000036F8: L2TP HA FSM:FSM-Sn ev Tx-xCRP*Aug 26 18:00:48.131: _____:01000:000036F8: L2TP HA FSM:FSM-Sn Wt-ChkptSidRmt->Wt-SesIdRmt2*Aug 26 18:00:48.131: _____:01000:000036F8: L2TP HA FSM:FSM-Sn do Block-Tx-xCRP*Aug 26 18:00:48.131: _____:01000:000036F8: L2TP HA FSM:Found blocked RxICRQ, seq_num 3LNS1#*Aug 26 18:00:48.131: _____:01000:000036F8: L2TP HA FSM:Queued xCRP to session hold_q*Aug 26 18:00:48.131: : L2TP HA:Try to buffer sock msg type 23*Aug 26 18:00:48.131: : L2TP HA:CC not in resync state, buffering skipped*Aug 26 18:00:49.115: 01000:0000CD97: L2TP HA FSM:Check for Ns/Nr update 2, peer 1*Aug 26 18:00:49.115: 01000:0000CD97: L2TP HA FSM:Receive peer Ns/Nr update (2,2/1,1, int 3, rx 1, 3) (ns_q sz 1)*Aug 26 18:00:49.211: : L2TP HA FSM:CHKPT status callback: status 0, len 56*Aug 26 18:00:49.211: : L2TP HA FSM:Context s/c id 0/52631, CcUp, seq 2, ns/nr 1/1, rid 0, len 52*Aug 26 18:00:49.211: : L2TP HA FSM:CHKPT status callback: status 0, len 56*Aug 26 18:00:49.211: : L2TP HA FSM:Context s/c id 14072/52631, BothSesId, seq 3, ns/nr 1/2, rid 40276, len 52*Aug 26 18:00:49.211: L2TP HA CF: Rcvd status s/c id 0/52631, CcUp, seq 2, ns/nr 1/1, rid 0, len 52*Aug 26 18:00:49.211: L2TP HA CF: Rcvd status 0: len 56*Aug 26 18:00:49.211: L2TP HA CF: Status content s/c id 0/52631, CcUp, seq 2, ns/nr 1/1, rid 0, len 52*Aug 26 18:00:49.211: 01000:0000CD97: L2TP HA FSM:Recv chkpt ack: s/c id 0/52631, CcUp, seq 2, ns/nr 1/1, rid 0, len 52*Aug 26 18:00:49.211: : L2TP HA FSM:Receive CC-ChkptAck*Aug 26 18:00:49.211: : L2TP HA FSM:FSM-CC ev Rx-CkpACK-CcUp*Aug 26 18:00:49.211: : L2TP HA FSM:FSM-CC Wt-CkptCcUp->ProcCcsUp*Aug 26 18:00:49.211: : L2TP HA FSM:FSM-CC do Proc-ChpACK-CcUp2*Aug 26 18:00:49.211: : L2TP HA FSM:Received chkpt ACK of CcUp*Aug 26 18:00:49.211: L2TP HA CF: Rcvd status s/c id 14072/52631, BothSesId, seq 3, ns/nr 1/2, rid 40276, len 52*Aug 26 18:00:49.211: L2TP HA CF: Rcvd status 0: len 56*Aug 26 18:00:49.211: L2TP HA CF: Status content s/c id 14072/52631, BothSesId, seq 3, ns/nr 1/2, rid 40276, len 52*Aug 26 18:00:49.211: 01000:0000CD97: L2TP HA FSM:Recv chkpt ack: s/c id 14072/52631, BothSesId, seq 3, ns/nr 1/2, rid 40276, len 52*Aug 26 18:00:49.211: _____:_____:000036F8: L2TP HA FSM:Receive Session-ChkptAck*Aug 26 18:00:49.211: _____:01000:000036F8: L2TP HA FSM:FSM-Sn ev Rx-CktACK-SesID-Rmt*Aug 26 18:00:49.211: _____:01000:000036F8: L2TP HA FSM:FSM-Sn Wt-SesIdRmt2->Wt-RxXccn*Aug 26 18:00:49.211: _____:01000:000036F8: L2TP HA FSM:FSM-Sn do Allow-Tx-xCRP*Aug 26 18:00:49.211: 01000:0000CD97: L2TP HA:Try to remove from CC's ns_q: seq num 3 (current Ns 3)*Aug 26 18:00:49.211: _____:01000:000036F8: L2TP HA:Ns entry to remove: found (current Ns 3)*Aug 26 18:00:49.211: _____:01000:000036F8: L2TP HA:Advance peer Nr to 3 (ns_q sz 0)*Aug 26 18:00:49.211: _____:01000:000036F8: L2TP HA:Session send all unblocked*Aug 26 18:00:49.211: 01000:0000CD97: L2TP HA:CC send if can (ICRP): ns 1 (1, 1), nr 3 (3)*Aug 26 18:00:49.211: L2TP HA CF: O ICRP 51583/40276 ns/nr 1/3*Aug 26 18:00:49.231: 01000:0000CD97: L2TP HA FSM:Receive Cm-Ack*Aug 26 18:00:49.231: _____:_____:000036F8: L2TP HA FSM:Receive session Cm-AckLNS1#*Aug 26 18:00:49.231: _____:01000:000036F8: L2TP HA FSM:FSM-Sn ev Rx-CmACK*Aug 26 18:00:49.231: _____:01000:000036F8: L2TP HA FSM:FSM-Sn in Wt-RxXccn*Aug 26 18:00:49.231: _____:01000:000036F8: L2TP HA FSM:FSM-Sn do Ignore*Aug 26 18:00:49.231: _____:01000:000036F8: L2TP HA FSM:Ignore event*Aug 26 18:00:49.231: 01000:0000CD97: L2TP HA FSM:Check for Ns/Nr update 3, peer 2*Aug 26 18:00:49.231: 01000:0000CD97: L2TP HA FSM:Receive peer Ns/Nr update (3,2/2,2, int 3, rx 2, 3) (ns_q sz 0)*Aug 26 18:00:49.231: 01000:0000CD97: L2TP HA FSM:Peer Ns 3 (3), Nr 2 (ns_q sz 0)LNS1#*Aug 26 18:00:50.407: 01000:0000CD97: L2TP HA FSM:Check for Ns/Nr update 3, peer 2*Aug 26 18:00:50.407: 01000:0000CD97: L2TP HA FSM:Receive peer Ns/Nr update (3,2/2,2, int 3, rx 2, 3) (ns_q sz 0)*Aug 26 18:00:50.407: 01000:0000CD97: L2TP HA FSM:Peer Ns 3 (4), Nr 2 (ns_q sz 0)*Aug 26 18:00:50.407: : L2TP HA FSM:Receive proto FSM event 5*Aug 26 18:00:50.407: _____:_____:000036F8: L2TP HA FSM:Receive RxICCN*Aug 26 18:00:50.407: _____:01000:000036F8: L2TP HA FSM:FSM-Sn ev Rx-xCCN*Aug 26 18:00:50.407: _____:01000:000036F8: L2TP HA FSM:FSM-Sn Wt-RxXccn->Wt-SessUp*Aug 26 18:00:50.407: _____:01000:000036F8: L2TP HA FSM:FSM-Sn do Allow-Tx-AckXCCN*Aug 26 18:00:50.407: _____:01000:000036F8: L2TP HA FSM:Allow TxICCN-ACK*Aug 26 18:00:50.407: L2TP _____:01000:000036F8: Encoding ICCN-IN CHKPT*Aug 26 18:00:50.407: L2TP _____:01000:000036F8: Tx CHKPT*Aug 26 18:00:50.407: _____:_____:000036F8: L2TP HA FSM:Receive SessionUp*Aug 26 18:00:50.407: _____:01000:000036F8: L2TP HA FSM:FSM-Sn ev Proto SessUp*Aug 26 18:00:50.407: _____:01000:000036F8: L2TP HA FSM:FSM-Sn Wt-SessUp->Wt-CkptSesUp*Aug 26 18:00:50.407: _____:01000:000036F8: L2TP HA FSM:FSM-Sn do Chkpt-SesUp2*Aug 26 18:00:50.407: _____:01000:000036F8: L2TP HA FSM:Checkpoint SessionUP*Aug 26 18:00:50.407: L2TP HA CF: Chkpt send: s/c id 14072/52631, SesUp, seq 0, ns/nr 2/3, rid 0, len 52; flush = 1, ctr 4*Aug 26 18:00:51.055: : L2TP HA FSM:CHKPT status callback: status 0, len 56*Aug 26 18:00:51.055: : L2TP HA FSM:Context s/c id 14072/52631, SesUp, seq 4, ns/nr 2/3, rid 0, len 52*Aug 26 18:00:51.055: L2TP HA CF: Rcvd status s/c id 14072/52631, SesUp, seq 4, ns/nr 2/3, rid 0, len 52*Aug 26 18:00:51.055: L2TP HA CF: Rcvd status 0: len 56*Aug 26 18:00:51.055: L2TP HA CF: Status content s/c id 14072/52631, SesUp, seq 4, ns/nr 2/3, rid 0, len 52*Aug 26 18:00:51.055: 01000:0000CD97: L2TP HA FSM:Recv chkpt ack: s/c id 14072/52631, SesUp, seq 4, ns/nr 2/3, rid 0, len 52*Aug 26 18:00:51.055: _____:_____:000036F8: L2TP HA FSM:Receive Session-ChkptAck*Aug 26 18:00:51.055: _____:01000:000036F8: L2TP HA FSM:FSM-Sn ev Rx-CktACK-SesUp*Aug 26 18:00:51.055: _____:01000:000036F8: L2TP HA FSM:FSM-Sn Wt-CkptSesUp->Proc-SessUp*Aug 26 18:00:51.055: _____:01000:000036F8: L2TP HA FSM:FSM-Sn do Proc-ChpACK-SesUp*Aug 26 18:00:51.055: _____:01000:000036F8: L2TP HA FSM:Received chkpt ACK of SessionUP*Aug 26 18:00:51.347: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to upLNS1#*Aug 26 18:00:51.635: : L2TP HA:Try to buffer sock msg type 26*Aug 26 18:00:51.635: : L2TP HA:CC not in resync state, buffering skipped*Aug 26 18:00:51.659: : L2TP HA:Try to buffer sock msg type 26*Aug 26 18:00:51.659: : L2TP HA:CC not in resync state, buffering skippedLNS1#*Aug 26 18:00:52.363: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to upLNS1#LNS1# clear l2tp allProceed with clearing all tunnels? [confirm]LNS1#*Aug 26 18:01:21.271: 00001:_____:000036F8: L2TP HA FSM:Receive Session-CC-Rm*Aug 26 18:01:21.271: 00001:_____:000036F8: L2TP HA FSM:Receive SessionRm*Aug 26 18:01:21.271: 01000:0000CD97: L2TP HA FSM:Receive proto TxCM event StopCCN*Aug 26 18:01:21.271: 01000:0000CD97: L2TP HA FSM:Receive TxSTOPCCN*Aug 26 18:01:21.271: : L2TP HA FSM:FSM-CC ev Tx-STOPCCN*Aug 26 18:01:21.271: : L2TP HA FSM:FSM-CC ProcCcsUp->Wt-CkptCcDn*Aug 26 18:01:21.271: : L2TP HA FSM:FSM-CC do Chkpt-CcDwn*Aug 26 18:01:21.271: 01000:0000CD97: L2TP HA FSM:Receive TxSTOPCCN while CC up*Aug 26 18:01:21.271: 01000:0000CD97: L2TP HA:CC ns_q cleanup: overall head Ns old/new = 4/4 (Q sz 0)LNS1#*Aug 26 18:01:21.271: : L2TP HA FSM:Checkpoint CCDown*Aug 26 18:01:21.271: L2TP HA CF: Chkpt send: s/c id 0/52631, CcDwn, seq 0, ns/nr 2/3, rid 0, len 52; flush = 1, ctr 5*Aug 26 18:01:21.271: 01000:0000CD97: L2TP HA FSM:Queued STOPCCN to cc hold_q*Aug 26 18:01:21.295: : L2TP HA:Try to buffer sock msg type 22*Aug 26 18:01:21.295: : L2TP HA:Buffering skipped*Aug 26 18:01:22.423: : L2TP HA FSM:CHKPT status callback: status 0, len 56*Aug 26 18:01:22.423: : L2TP HA FSM:Context s/c id 0/52631, CcDwn, seq 5, ns/nr 2/3, rid 0, len 52*Aug 26 18:01:22.423: L2TP HA CF: Rcvd status s/c id 0/52631, CcDwn, seq 5, ns/nr 2/3, rid 0, len 52*Aug 26 18:01:22.423: L2TP HA CF: Rcvd status 0: len 56*Aug 26 18:01:22.423: L2TP HA CF: Status content s/c id 0/52631, CcDwn, seq 5, ns/nr 2/3, rid 0, len 52*Aug 26 18:01:22.423: 01000:0000CD97: L2TP HA FSM:Recv chkpt ack: s/c id 0/52631, CcDwn, seq 5, ns/nr 2/3, rid 0, len 52*Aug 26 18:01:22.423: : L2TP HA FSM:Receive CC-ChkptAck*Aug 26 18:01:22.423: : L2TP HA FSM:FSM-CC ev Rx-CkpACK-CcDwn*Aug 26 18:01:22.423: : L2TP HA FSM:FSM-CC Wt-CkptCcDn->Wt-RxStopAck*Aug 26 18:01:22.423: : L2TP HA FSM:FSM-CC do Allow-Tx-STOPCCN4*Aug 26 18:01:22.423: : L2TP HA FSM:Received Chkpt of CC removal*Aug 26 18:01:22.423: 01000:0000CD97: L2TP HA:Try to remove from CC's ns_q: seq num 5 (current Ns 4)*Aug 26 18:01:22.423: 01000:0000CD97: L2TP HA:Ns entry to remove: not found (current Ns 4)*Aug 26 18:01:22.423: 01000:0000CD97: L2TP HA:CC send all unblocked if can*Aug 26 18:01:22.423: 01000:0000CD97: L2TP HA:CC send one blocked CM (SCCRP): ns 2 (2), nr 4*Aug 26 18:01:22.451: 01000:0000CD97: L2TP HA FSM:Receive Cm-Ack*Aug 26 18:01:22.451: 01000:0000CD97: L2TP HA FSM:Receive CC Cm-Ack*Aug 26 18:01:22.451: : L2TP HA FSM:FSM-CC ev Rx-CmACK*Aug 26 18:01:22.451: : L2TP HA FSM:FSM-CC Wt-RxStopAck->Wt-CkptCcRm*Aug 26 18:01:22.451: : L2TP HA FSM:FSM-CC do ChkptCcRm3*Aug 26 18:01:22.451: : L2TP HA FSM:Received STOPCCN-ACK while waiting for it, checkpoint CCRm and remove cc*Aug 26 18:01:22.451: 01000:0000CD97: L2TP HA:CC ns_q cleanup: overall head Ns old/new = 4/4 (Q sz 0)*Aug 26 18:01:22.451: 01000:0000CD97: L2TP HA FSM:Checkpoint CcRm*Aug 26 18:01:22.451: L2TP HA CF: Chkpt send: s/c id 0/52631, CcRm, seq 0, ns/nr 3/3, rid 0, len 52; flush = 1, ctr 6*Aug 26 18:01:22.451: 01000:0000CD97: L2TP HA FSM:Check for Ns/Nr update 4, peer 3*Aug 26 18:01:22.451: 01000:0000CD97: L2TP HA FSM:Receive peer Ns/Nr update (4,3/3,3, int 4, rx 3, 4) (ns_q sz 0)*Aug 26 18:01:22.451: 01000:0000CD97: L2TP HA FSM:Peer Ns 4 (4), Nr 3 (ns_q sz 0)*Aug 26 18:01:22.451: 01000:0000CD97: L2TP HA FSM:Receive CC-Rm*Aug 26 18:01:22.451: : L2TP HA FSM:FSM-CC ev Proto CcRm*Aug 26 18:01:22.451: : L2TP HA FSM:FSM-CC Wt-CkptCcRm->End*Aug 26 18:01:22.451: : L2TP HA FSM:FSM-CC do RmCc3*Aug 26 18:01:22.451: 01000:0000CD97: L2TP HA FSM:CC destruction after Tx/Rx StopCCNLNS1#*Aug 26 18:01:22.451: 01000:0000CD97: L2TP HA:CC ns_q cleanup: overall head Ns old/new = 4/4 (Q sz 0)*Aug 26 18:01:22.451: : L2TP HA FSM:Checkpoint CCRm*Aug 26 18:01:22.451: L2TP HA CF: Chkpt send: s/c id 0/52631, CcRm, seq 0, ns/nr 3/3, rid 0, len 52; flush = 1, ctr 7*Aug 26 18:01:22.451: : L2TP HA:lcm_cc free: l2tp_cc 070B45B8, lcm_cc 02FE55E8*Aug 26 18:01:22.451: L2TP tnl _____:________: CCM setting state to DOWN*Aug 26 18:01:23.571: : L2TP HA FSM:CHKPT status callback: status 0, len 56*Aug 26 18:01:23.571: : L2TP HA FSM:Context s/c id 0/52631, CcRm, seq 6, ns/nr 3/3, rid 0, len 52*Aug 26 18:01:23.571: : L2TP HA FSM:CHKPT status callback: status 0, len 56*Aug 26 18:01:23.571: : L2TP HA FSM:Context s/c id 0/52631, CcRm, seq 7, ns/nr 3/3, rid 0, len 52*Aug 26 18:01:23.571: L2TP HA CF: Rcvd status s/c id 0/52631, CcRm, seq 6, ns/nr 3/3, rid 0, len 52*Aug 26 18:01:23.571: L2TP HA CF: Rcvd status 0: len 56*Aug 26 18:01:23.571: L2TP HA CF: Status content s/c id 0/52631, CcRm, seq 6, ns/nr 3/3, rid 0, len 52*Aug 26 18:01:23.571: : L2TP HA FSM:Ignore chkpt ACK: CC not found.LNS1#*Aug 26 18:01:23.571: L2TP HA CF: Rcvd status s/c id 0/52631, CcRm, seq 7, ns/nr 3/3, rid 0, len 52*Aug 26 18:01:23.571: L2TP HA CF: Rcvd status 0: len 56*Aug 26 18:01:23.571: L2TP HA CF: Status content s/c id 0/52631, CcRm, seq 7, ns/nr 3/3, rid 0, len 52*Aug 26 18:01:23.571: : L2TP HA FSM:Ignore chkpt ACK: CC not found.LNS1#*Aug 26 18:01:35.771: %REDUNDANCY-3-STANDBY_LOST: Standby processor fault (PEER_DOWN_INTERRUPT)Table 207 describes the significant fields shown in the debug l2tp redundancy command output.
Table 207 debug l2tp redundancy Command Field Descriptions
Related Commands
debug lacp
To enable debugging of all Link Aggregation Control Protocol (LACP) activity, use the debug lacp command in privileged EXEC mode. To disable LACP debugging, use the no form of this command.
debug lacp [all | event | fsm | misc | multi-chassis [all | database | lacp-mgr | redundancy-group | user-interface] | packet]
no debug lacp [all | event | fsm | misc | multi-chassis [all | database | lacp-mgr | redundancy-group | user-interface] | packet]
Syntax Description
Command Default
LACP debugging activity is disabled.
Command Modes
Privileged EXEC (#)
Command History
Usage Guidelines
This command is useful for troubleshooting problems with LACP.
Examples
The following sample output from the debug lacp all command shows LACP activity on a port-channel member link Gigabit Ethernet 5/0/0:
Router# debug lacp allLink Aggregation Control Protocol all debugging is onRouter1#*Aug 20 17:21:51.685: LACP :lacp_bugpak: Receive LACP-PDU packet via Gi5/0/0*Aug 20 17:21:51.685: LACP : packet size: 124*Aug 20 17:21:51.685: LACP: pdu: subtype: 1, version: 1*Aug 20 17:21:51.685: LACP: Act: tlv:1, tlv-len:20, key:0x1, p-pri:0x8000, p:0x14, p-state:0x3C,s-pri:0xFFFF, s-mac:0011.2026.7300*Aug 20 17:21:51.685: LACP: Part: tlv:2, tlv-len:20, key:0x5, p-pri:0x8000, p:0x42, p-state:0x3D,s-pri:0x8000, s-mac:0014.a93d.4a00*Aug 20 17:21:51.685: LACP: col-tlv:3, col-tlv-len:16, col-max-d:0x8000*Aug 20 17:21:51.685: LACP: term-tlv:0 termr-tlv-len:0*Aug 20 17:21:51.685: LACP: Gi5/0/0 LACP packet received, processing*Aug 20 17:21:51.685: lacp_rx Gi5: during state CURRENT, got event 5(recv_lacpdu)*Aug 20 17:21:59.869: LACP: lacp_p(Gi5/0/0) timer stopped*Aug 20 17:21:59.869: LACP: lacp_p(Gi5/0/0) expired*Aug 20 17:21:59.869: lacp_ptx Gi5: during state SLOW_PERIODIC, got event 3(pt_expired)*Aug 20 17:21:59.869: @@@ lacp_ptx Gi5: SLOW_PERIODIC -> PERIODIC_TX*Aug 20 17:21:59.869: LACP: Gi5/0/0 lacp_action_ptx_slow_periodic_exit entered*Aug 20 17:21:59.869: LACP: lacp_p(Gi5/0/0) timer stopped*Aug 20 17:22:00.869: LACP: lacp_t(Gi5/0/0) timer stopped*Aug 20 17:22:00.869: LACP: lacp_t(Gi5/0/0) expired*Aug 20 17:22:19.089: LACP :lacp_bugpak: Receive LACP-PDU packet via Gi5/0/0*Aug 20 17:22:19.089: LACP : packet size: 124*Aug 20 17:22:19.089: LACP: pdu: subtype: 1, version: 1*Aug 20 17:22:19.089: LACP: Act: tlv:1, tlv-len:20, key:0x1, p-pri:0x8000, p:0x14, p-state:0x4,s-pri:0xFFFF, s-mac:0011.2026.7300*Aug 20 17:22:19.089: LACP: Part: tlv:2, tlv-len:20, key:0x5, p-pri:0x8000, p:0x42, p-state:0x34,s-pri:0x8000, s-mac:0014.a93d.4a00*Aug 20 17:22:19.089: LACP: col-tlv:3, col-tlv-len:16, col-max-d:0x8000*Aug 20 17:22:19.089: LACP: term-tlv:0 termr-tlv-len:0*Aug 20 17:22:19.089: LACP: Gi5/0/0 LACP packet received, processing*Aug 20 17:22:19.089: lacp_rx Gi5: during state CURRENT, got event 5(recv_lacpdu)*Aug 20 17:22:19.989: LACP: lacp_t(Gi5/0/0) timer stopped*Aug 20 17:22:19.989: LACP: lacp_t(Gi5/0/0) expired*Aug 20 17:22:19.989: LACP: timer lacp_t(Gi5/0/0) started with interval 1000.*Aug 20 17:22:19.989: LACP: lacp_send_lacpdu: (Gi5/0/0) About to send the 110 LACPDU*Aug 20 17:22:19.989: LACP :lacp_bugpak: Send LACP-PDU packet via Gi5/0/0*Aug 20 17:22:19.989: LACP : packet size: 124*Aug 20 17:22:20.957: LACP: lacp_t(Gi5/0/0) timer stopped*Aug 20 17:22:20.957: LACP: lacp_t(Gi5/0/0) expired*Aug 20 17:22:21.205: %LINK-3-UPDOWN: Interface GigabitEthernet5/0/0, changed state to down*Aug 20 17:22:21.205: LACP: lacp_hw_off: Gi5/0/0 is going down*Aug 20 17:22:21.205: LACP: if_down: Gi5/0/0*Aug 20 17:22:21.205: lacp_ptx Gi5: during state SLOW_PERIODIC, got event 0(no_periodic)*Aug 20 17:22:22.089: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel5, changed state to down*Aug 20 17:22:22.153: %C10K_ALARM-6-INFO: CLEAR CRITICAL GigE 5/0/0 Physical Port Link Down*Aug 20 17:22:23.413: LACP: Gi5/0/0 oper-key: 0x0*Aug 20 17:22:23.413: LACP: lacp_hw_on: Gi5/0/0 is coming up*Aug 20 17:22:23.413: lacp_ptx Gi5: during state NO_PERIODIC, got event 0(no_periodic)*Aug 20 17:22:23.413: @@@ lacp_ptx Gi5: NO_PERIODIC -> NO_PERIODIC*Aug 20 17:22:23.413: LACP: Gi5/0/0 lacp_action_ptx_no_periodic entered*Aug 20 17:22: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*Aug 20 17:22:24.153: lacp_ptx Gi5: during state FAST_PERIODIC, got event 0(no_periodic)*Aug 20 17:22:24.153: @@@ lacp_ptx Gi5: FAST_PERIODIC -> NO_PERIODIC*Aug 20 17:22:24.153: LACP: Gi5/0/0 lacp_action_ptx_fast_periodic_exit entered*Aug 20 17:22:24.153: LACP: lacp_p(Gi5/0/0) timer stopped*Aug 20 17:22:24.153: LACP:*Aug 20 17:22:25.021: LACP: lacp_p(Gi5/0/0) timer stopped*Aug 20 17:22:25.021: LACP: lacp_p(Gi5/0/0) expired*Aug 20 17:22:25.021: lacp_ptx Gi5: during state FAST_PERIODIC, got event 3(pt_expired)*Aug 20 17:22:25.021: @@@ lacp_ptx Gi5: FAST_PERIODIC -> PERIODIC_TX*Aug 20 17:22:25.021: LACP: Gi5/0/0 lacp_action_ptx_fast_periodic_exit entered*Aug 20 17:22:25.021: LACP: lacp_p(Gi5/0/0) timer stopped*Aug 20 17:22:25.917: LACP: lacp_p(Gi5/0/0) timer stopped*Aug 20 17:22:25.917: LACP: lacp_p(Gi5/0/0) expired*Aug 20 17:22:25.917: lacp_ptx Gi5: during state FAST_PERIODIC, got event 3(pt_expired)*Aug 20 17:22:25.917: @@@ lacp_ptx Gi5: FAST_PERIODIC -> PERIODIC_TX*Aug 20 17:22:25.917: LACP: Gi5/0/0 lacp_action_ptx_fast_periodic_exit entered*Aug 20 17:22:25.917: LACP: lacp_p(Gi5/0/0) timer stoppedRouter1#debug ldap
To enable debugging for Lightweight Directory Access Protocol (LDAP) configuration, use the debug ldap command in privileged EXEC mode. To disable debugging, use the no form of this command.
debug ldap {all | error | event | legacy | packet}
no debug ldap {all | error | event | legacy | packet}
Syntax Description
Command Modes
Privileged EXEC (#)
Command History
Examples
The following is sample output from the debug ldap legacy command:
Router# debug ldap legacyput_filter "(&(objectclass=*)(cn=firewall_user))"put_filter: ANDput_filter_list "(objectclass=*)(cn=firewall_user)"put_filter "(objectclass=*)"put_filter: simpleput_filter "(cn=firewall_user)"put_filter: simpleDoing socket writeldap_resultwait4msg (timeout 0 sec, 1 usec)ldap_select_fd_wait (select)ldap_read_activity lc 0x6804D354Doing socket readLDAP-TCP:Bytes read = 1478ldap_match_request succeeded for msgid 2 h 0ldap_get_dnldap_get_dnldap_msgfreeldap_resultwait4msg (timeout 0 sec, 1 usec)ldap_read_activity lc 0x6804D354ldap_match_request succeeded for msgid 2 h 0changing lr 0x6774F8D4 to COMPLETE as no continuationsremoving request 0x6774F8D4 from list as lm 0x681C9B78 all 0ldap_msgfreeldap_msgfreeldap_parse_resultldap_parse_resultldap_req_encodeDoing socket writeldap_msgfreeldap_resultwait4msg (timeout 0 sec, 1 usec)ldap_select_fd_wait (select)ldap_resultwait4msg (timeout 0 sec, 1 usec)ldap_select_fd_wait (select)ldap_read_activity lc 0x6804D354Doing socket readLDAP-TCP:Bytes read = 22ldap_match_request succeeded for msgid 3 h 0changing lr 0x6774F8D4 to COMPLETE as no continuationsremoving request 0x6774F8D4 from list as lm 0x681C9B78 all 0ldap_msgfreeldap_msgfreeldap_parse_resultldap_parse_resultldap_msgfreeldap_resultwait4msg (timeout 0 sec, 1 usec)ldap_select_fd_wait (select)Related Commands
debug lane client
To display information about a LAN Emulation Client (LEC), use the debug lane client command in privileged EXEC mode. To disable debugging output, use the no form of this command.
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
Defaults
If the interface number is not specified, the default will be the number of all the mpoa lane clients.
Command Modes
Privileged EXEC
Command History
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 packetRouter# debug lane client stateThe LEC listens for signaling calls to its ATM address (Initial State):
LEC ATM2/0.1: sending LISTENLEC ATM2/0.1: listen on 39.020304050607080910111213.00000CA05B40.01LEC ATM2/0.1: received LISTENThe 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 SETUPLEC ATM2/0.1: callid 0x6114D174LEC ATM2/0.1: called party 39.020304050607080910111213.00000CA05B43.00LEC ATM2/0.1: calling_party 39.020304050607080910111213.00000CA05B40.01The LEC receives a CONNECT response from the LECS. The Configure Direct VC is established:
LEC ATM2/0.1: received CONNECTLEC ATM2/0.1: callid 0x6114D174LEC ATM2/0.1: vcd 148The 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 148LEC ATM2/0.1: SRC MAC address 0000.0ca0.5b40LEC ATM2/0.1: SRC ATM address 39.020304050607080910111213.00000CA05B40.01LEC ATM2/0.1: LAN Type 2LEC ATM2/0.1: Frame size 2LEC ATM2/0.1: LAN Name elan1LEC ATM2/0.1: LAN Name size 5The LEC receives a CONFIG RESPONSE from the LECS on the Configure Direct VC:
LEC ATM2/0.1: received LANE_CONFIG_RSP on VCD 148LEC ATM2/0.1: SRC MAC address 0000.0ca0.5b40LEC ATM2/0.1: SRC ATM address 39.020304050607080910111213.00000CA05B40.01LEC ATM2/0.1: LAN Type 2LEC ATM2/0.1: Frame size 2LEC ATM2/0.1: LAN Name elan1LEC ATM2/0.1: LAN Name size 5The LEC releases the Configure Direct VC:
LEC ATM2/0.1: sending RELEASELEC ATM2/0.1: callid 0x6114D174LEC ATM2/0.1: cause code 31The LEC receives a RELEASE_COMPLETE from the LECS:
LEC ATM2/0.1: received RELEASE_COMPLETELEC ATM2/0.1: callid 0x6114D174LEC ATM2/0.1: cause code 16The LEC calls the LAN Emulation Server (LES) and attempts to set up the Control Direct VC (Join/Registration Phase):
LEC ATM2/0.1: sending SETUPLEC ATM2/0.1: callid 0x61167110LEC ATM2/0.1: called party 39.020304050607080910111213.00000CA05B41.01LEC ATM2/0.1: calling_party 39.020304050607080910111213.00000CA05B40.01The LEC receives a CONNECT response from the LES. The Control Direct VC is established:
LEC ATM2/0.1: received CONNECTLEC ATM2/0.1: callid 0x61167110LEC ATM2/0.1: vcd 150The LEC sends a JOIN REQUEST to the LES on the Control Direct VC:
LEC ATM2/0.1: sending LANE_JOIN_REQ on VCD 150LEC ATM2/0.1: Status 0LEC ATM2/0.1: LECID 0LEC ATM2/0.1: SRC MAC address 0000.0ca0.5b40LEC ATM2/0.1: SRC ATM address 39.020304050607080910111213.00000CA05B40.01LEC ATM2/0.1: LAN Type 2LEC ATM2/0.1: Frame size 2LEC ATM2/0.1: LAN Name elan1LEC ATM2/0.1: LAN Name size 5The LEC receives a SETUP request from the LES to set up the Control Distribute VC:
LEC ATM2/0.1: received SETUPLEC ATM2/0.1: callid 0x6114D174LEC ATM2/0.1: called party 39.020304050607080910111213.00000CA05B40.01LEC ATM2/0.1: calling_party 39.020304050607080910111213.00000CA05B41.01The LEC responds to the LES call setup with a CONNECT:
LEC ATM2/0.1: sending CONNECTLEC ATM2/0.1: callid 0x6114D174LEC ATM2/0.1: vcd 151A CONNECT_ACK is received from the ATM switch. The Control Distribute VC is established:
LEC ATM2/0.1: received CONNECT_ACKThe LEC receives a JOIN response from the LES on the Control Direct VC.LEC ATM2/0.1: received LANE_JOIN_RSP on VCD 150LEC ATM2/0.1: Status 0LEC ATM2/0.1: LECID 1LEC ATM2/0.1: SRC MAC address 0000.0ca0.5b40LEC ATM2/0.1: SRC ATM address 39.020304050607080910111213.00000CA05B40.01LEC ATM2/0.1: LAN Type 2LEC ATM2/0.1: Frame size 2LEC ATM2/0.1: LAN Name elan1LEC ATM2/0.1: LAN Name size 5The 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 150LEC ATM2/0.1: SRC MAC address 0000.0ca0.5b40LEC ATM2/0.1: SRC ATM address 39.020304050607080910111213.00000CA05B40.01LEC ATM2/0.1: TARGET MAC address ffff.ffff.ffffLEC ATM2/0.1: TARGET ATM address 00.000000000000000000000000.000000000000.00The 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 151LEC ATM2/0.1: SRC MAC address 0000.0ca0.5b40LEC ATM2/0.1: SRC ATM address 39.020304050607080910111213.00000CA05B40.01LEC ATM2/0.1: TARGET MAC address ffff.ffff.ffffLEC ATM2/0.1: TARGET ATM address 39.020304050607080910111213.00000CA05B42.01The LEC calls the BUS and attempts to set up the Multicast Send VC:
LEC ATM2/0.1: sending SETUPLEC ATM2/0.1: callid 0x6114D354LEC ATM2/0.1: called party 39.020304050607080910111213.00000CA05B42.01LEC ATM2/0.1: calling_party 39.020304050607080910111213.00000CA05B40.01The LEC receives a CONNECT response from the BUS. The Multicast Send VC is established:
LEC ATM2/0.1: received CONNECTLEC ATM2/0.1: callid 0x6114D354LEC ATM2/0.1: vcd 153The LEC receives a SETUP request from the BUS to set up the Multicast Forward VC:
LEC ATM2/0.1: received SETUPLEC ATM2/0.1: callid 0x610D4230LEC ATM2/0.1: called party 39.020304050607080910111213.00000CA05B40.01LEC ATM2/0.1: calling_party 39.020304050607080910111213.00000CA05B42.01The LEC responds to the BUS call setup with a CONNECT:
LEC ATM2/0.1: sending CONNECTLEC ATM2/0.1: callid 0x610D4230LEC ATM2/0.1: vcd 154A CONNECT_ACK is received from the ATM switch. The Multicast Forward VC is established:
LEC ATM2/0.1: received CONNECT_ACKThe LEC moves into the OPERATIONAL state.%LANE-5-UPDOWN: ATM2/0.1 elan elan1: LE Client changed state to upThe 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 clientLE Client ATM2/0.1 ELAN name: elan1 Admin: up State: operationalClient ID: 1 LEC up for 1 minute 2 secondsJoin Attempt: 1HW Address: 0000.0ca0.5b40 Type: token ring Max Frame Size: 4544Ring:1 Bridge:1 ELAN Segment ID: 2048ATM Address: 39.020304050607080910111213.00000CA05B40.01VCD rxFrames txFrames Type ATM Address0 0 0 configure 39.020304050607080910111213.00000CA05B43.00142 1 2 direct 39.020304050607080910111213.00000CA05B41.01143 1 0 distribute 39.020304050607080910111213.00000CA05B41.01145 0 0 send 39.020304050607080910111213.00000CA05B42.01146 1 0 forward 39.020304050607080910111213.00000CA05B42.01The 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 allLEC ATM1/0.2: received RELEASE_COMPLETELEC ATM1/0.2: callid 0x60E8B474LEC ATM1/0.2: cause code 0LEC ATM1/0.2: action A_PROCESS_REL_COMPLEC ATM1/0.2: action A_TEARDOWN_LECLEC ATM1/0.2: sending RELEASELEC ATM1/0.2: callid 0x60EB6160LEC ATM1/0.2: cause code 31LEC ATM1/0.2: sending RELEASELEC ATM1/0.2: callid 0x60EB7548LEC ATM1/0.2: cause code 31LEC ATM1/0.2: sending RELEASELEC ATM1/0.2: callid 0x60EB9E48LEC ATM1/0.2: cause code 31LEC ATM1/0.2: sending CANCELLEC ATM1/0.2: ATM address 47.00918100000000613E5A2F01.006070174820.02LEC ATM1/0.2: state ACTIVE event LEC_SIG_RELEASE_COMP => TERMINATINGLEC ATM1/0.3: received RELEASE_COMPLETELEC ATM1/0.3: callid 0x60E8D108LEC ATM1/0.3: cause code 0LEC ATM1/0.3: action A_PROCESS_REL_COMPLEC ATM1/0.3: action A_TEARDOWN_LECLEC ATM1/0.3: sending RELEASELEC ATM1/0.3: callid 0x60EB66D4LEC ATM1/0.3: cause code 31LEC ATM1/0.3: sending RELEASELEC ATM1/0.3: callid 0x60EB7B8CLEC ATM1/0.3: cause code 31LEC ATM1/0.3: sending RELEASELEC ATM1/0.3: callid 0x60EBA3BCLEC ATM1/0.3: cause code 31LEC ATM1/0.3: sending CANCELLEC ATM1/0.3: ATM address 47.00918100000000613E5A2F01.006070174820.03LEC ATM1/0.3: state ACTIVE event LEC_SIG_RELEASE_COMP => TERMINATINGLEC ATM1/0.2: received RELEASE_COMPLETELEC ATM1/0.2: callid 0x60EB7548LEC ATM1/0.2: cause code 0LEC ATM1/0.2: action A_PROCESS_TERM_REL_COMPLEC ATM1/0.2: state TERMINATING event LEC_SIG_RELEASE_COMP => TERMINATINGLEC ATM1/0.3: received RELEASE_COMPLETELEC ATM1/0.3: callid 0x60EB7B8CLEC ATM1/0.3: cause code 0LEC ATM1/0.3: action A_PROCESS_TERM_REL_COMPLEC ATM1/0.3: state TERMINATING event LEC_SIG_RELEASE_COMP => TERMINATINGLEC ATM1/0.1: received RELEASE_COMPLETELEC ATM1/0.1: callid 0x60EBC458LEC ATM1/0.1: cause code 0LEC ATM1/0.1: action A_PROCESS_REL_COMPLEC ATM1/0.1: action A_TEARDOWN_LECLEC ATM1/0.1: sending RELEASELEC ATM1/0.1: callid 0x60EBD30CLEC ATM1/0.1: cause code 31LEC ATM1/0.1: sending RELEASELEC ATM1/0.1: callid 0x60EBDD28LEC ATM1/0.1: cause code 31LEC ATM1/0.1: sending RELEASELEC ATM1/0.1: callid 0x60EBF174LEC ATM1/0.1: cause code 31LEC ATM1/0.1: sending CANCELLEC ATM1/0.1: ATM address 47.00918100000000613E5A2F01.006070174820.01LEC ATM1/0.1: state ACTIVE event LEC_SIG_RELEASE_COMP => TERMINATINGLEC ATM1/0.1: received RELEASE_COMPLETELEC ATM1/0.1: callid 0x60EBDD28LEC ATM1/0.1: cause code 0LEC ATM1/0.1: action A_PROCESS_TERM_REL_COMPLEC ATM1/0.1: state TERMINATING event LEC_SIG_RELEASE_COMP => TERMINATINGLEC ATM1/0.2: received RELEASE_COMPLETELEC ATM1/0.2: callid 0x60EB6160LEC ATM1/0.2: cause code 0LEC ATM1/0.2: action A_PROCESS_TERM_REL_COMPLEC ATM1/0.2: state TERMINATING event LEC_SIG_RELEASE_COMP => TERMINATINGLEC ATM1/0.3: received RELEASE_COMPLETELEC ATM1/0.3: callid 0x60EB66D4LEC ATM1/0.3: cause code 0LEC ATM1/0.3: action A_PROCESS_TERM_REL_COMPLEC ATM1/0.3: state TERMINATING event LEC_SIG_RELEASE_COMP => TERMINATINGLEC ATM1/0.2: received RELEASE_COMPLETELEC ATM1/0.2: callid 0x60EB9E48LEC ATM1/0.2: cause code 0LEC ATM1/0.2: action A_PROCESS_TERM_REL_COMPLEC ATM1/0.2: state TERMINATING event LEC_SIG_RELEASE_COMP => IDLELEC ATM1/0.3: received RELEASE_COMPLETELEC ATM1/0.3: callid 0x60EBA3BCLEC ATM1/0.3: cause code 0LEC ATM1/0.3: action A_PROCESS_TERM_REL_COMPLEC ATM1/0.3: state TERMINATING event LEC_SIG_RELEASE_COMP => IDLELEC ATM1/0.1: received RELEASE_COMPLETELEC ATM1/0.1: callid 0x60EBD30CLEC ATM1/0.1: cause code 0LEC ATM1/0.1: action A_PROCESS_TERM_REL_COMPLEC ATM1/0.1: state TERMINATING event LEC_SIG_RELEASE_COMP => TERMINATINGLEC ATM1/0.1: received RELEASE_COMPLETELEC ATM1/0.1: callid 0x60EBF174LEC ATM1/0.1: cause code 0LEC ATM1/0.1: action A_PROCESS_TERM_REL_COMPLEC ATM1/0.1: state TERMINATING event LEC_SIG_RELEASE_COMP => IDLELEC ATM1/0.2: received CANCELLEC ATM1/0.2: state IDLE event LEC_SIG_CANCEL => IDLELEC ATM1/0.3: received CANCELLEC ATM1/0.3: state IDLE event LEC_SIG_CANCEL => IDLELEC ATM1/0.1: received CANCELLEC ATM1/0.1: state IDLE event LEC_SIG_CANCEL => IDLELEC ATM1/0.1: action A_SHUTDOWN_LECLEC ATM1/0.1: sending CANCELLEC ATM1/0.1: ATM address 47.00918100000000613E5A2F01.006070174820.01LEC ATM1/0.1: state IDLE event LEC_LOCAL_DEACTIVATE => IDLELEC ATM1/0.2: action A_SHUTDOWN_LECLEC ATM1/0.2: sending CANCELLEC ATM1/0.2: ATM address 47.00918100000000613E5A2F01.006070174820.02LEC ATM1/0.2: state IDLE event LEC_LOCAL_DEACTIVATE => IDLELEC ATM1/0.3: action A_SHUTDOWN_LECLEC ATM1/0.3: sending CANCELLEC ATM1/0.3: ATM address 47.00918100000000613E5A2F01.006070174820.03LEC ATM1/0.3: state IDLE event LEC_LOCAL_DEACTIVATE => IDLEThe following output is from the debug lane client mpoa command when the lane interface is shut down:
Router# debug lane client mpoaRouter#conf tEnter configuration commands, one per line. End with CNTL/Z.Router(config)#int atm 1/1/0.1Router(config-subif)#shutdownRouter(config-subif)#00:23:32:%LANE-5-UPDOWN:ATM1/1/0.1 elan elan2:LE Client changed state to down00:23:32:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWN00:23:32:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWNRouter(config-subif)#Router(config-subif)#Router(config-subif)#Router(config-subif)#exitRouter(config)#exitThe following output is from the debug lane client mpoa command when the lane interface is started (not shut down):
Router# debug lane client mpoaRouter#conf tEnter configuration commands, one per line. End with CNTL/Z.Router(config)#int atm 1/1/0.1Router(config-subif)#Router(config-subif)#Router(config-subif)#no shutdownRouter(config-subif)#00:23:39:LEC ATM1/1/0.1:lec_process_lane_tlv:msg LANE_CONFIG_RSP, num_tlvs 1400:23:39:LEC ATM1/1/0.1:elan id from LECS set to 30000:23:39:LEC ATM1/1/0.1:lec_process_lane_tlv:msg LANE_JOIN_RSP, num_tlvs 100:23:39:LEC ATM1/1/0.1:elan id from LES set to 30000: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.0050A29AF42D.0000:23:39:%LANE-5-UPDOWN:ATM1/1/0.1 elan elan2:LE Client changed state to up00:23:39:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:UP00:25:57:LEC ATM1/1/0.1:lec_process_lane_tlv:msg LANE_ARP_REQ, num_tlvs 100:25:57:LEC ATM1/1/0.1:lec_process_dev_type_tlv: lec 47.0091810000000050E2097801.00500B306440.02type MPS, mpc 00.000000000000000000000000.000000000000.00mps 47.0091810000000050E2097801.00500B306444.00, num_mps_mac 1, mac 0050.0b30.644000:25:57:LEC ATM1/1/0.1:create mpoa_lec00:25:57:LEC ATM1/1/0.1:new mpoa_lec 0x617E311800:25:57:LEC ATM1/1/0.1:lec_process_dev_type_tlv:type MPS, num _mps_mac100:2t 5:57:LEC ATM1/1/0.1:lec_add_mps:remote lec 47.0091810000000050E2097801.00500B306440.02mps 47.0091810000000050E2097801.00500B306444.00 num_mps_mac 1, mac 0050.0b30.644000:25:57:LEC ATM1/1/0.1:mpoa_device_change:lec_nsap 47.0091810000000050E2097801.00500B306440.02, appl_type 5mpoa_nsap 47.0091810000000050E2097801.00500B306444.00, opcode 400:25:57:LEC ATM1/1/0.1:lec_add_mps:add mac 0050.0b30.6440, mps_mac 0x617E372C00:25:57:LEC ATM1/1/0.1:mpoa_device_change:lec_nsap 47.0091810000000050E2097801.00500B306440.02, appl_type 5mpoa_nsap 47.0091810000000050E2097801.00500B306444.00, opcode 500:25:57:LEC ATM1/1/0.1: mps_mac 0050.0b30.644000:25:57:LEC ATM1/1/0.1:lec_append_mpoa_dev_tlv:00:25:57:LEC ATM1/1/0.1:got mpoa client addr 47.0091810000000050E2097801.0050A29AF42D.00Router(config-subif)#exitRouter(config)#exitThe following output is from the debug lane client mpoa command when the ATM major interface is shut down:
Router# debug lane client mpoaRouter# conf tEnter configuration commands, one per line. End with CNTL/Z.Router(config)#int atm 1/1/0Router(config-if)# shutdownRouter(config-if)#00:26:28:LANE ATM1/1/0:atm hardware reset00:26:28:%LANE-5-UPDOWN:ATM1/1/0.1 elan elan2:LE Client changed state to down00:26:28:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWN00:26:28:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWN00:26:28:%MPOA-5-UPDOWN:MPC mpc2:state changed to down00:26:28:LEC ATM1/1/0.1:mpoa_to_lec:appl 6, opcode 000:26:30:%LINK-5-CHANGED:Interface ATM1/1/0, changed state to administrativelydown00:26:30:LANE ATM1/1/0:atm hardware reset00:26:31:%LINEPROTO-5-UPDOWN:Line protocol on Interface ATM1/1/0, changed state to downRouter(config-if)#00:26:31:LEC ATM1/1/0.1:mpoa_to_lec:appl 6, opcode 000:26:32:LANE ATM1/1/0:atm hardware reset00:26:32:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWN00:26:34:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWNRouter(config-if)# exitRouter(config)# exitThe following output is from the debug lane client mpoa command when the ATM major interface is started:
Router# debug lane client mpoaRouter# conf tEnter configuration commands, one per line. End with CNTL/Z.Router(config)# int atm 1/1/0Router(config-if)# no shutdown00:26:32:LANE ATM1/1/0:atm hardware reset00:26:32:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWN00:26:34:%LINK-3-UPDOWN:Interface ATM1/1/0, changed state to down00:26:34:LANE ATM1/1/0:atm hardware reset00:26:41:%LINK-3-UPDOWN:Interface ATM1/1/0, changed state to up00:26:42:%LINEPROTO-5-UPDOWN:Line protocol on Interface ATM1/1/0, changed state to up00:27:10:%LANE-6-INFO:ATM1/1/0:ILMI prefix add event received00:27:10:LANE ATM1/1/0:prefix add event for 470091810000000050E2097801 ptr=0x617BFC0C len=1300:27:10: the current first prefix is now:470091810000000050E209780100:27:10:%ATMSSCOP-5-SSCOPINIT:- Intf :ATM1/1/0, Event :Rcv End, State :Active.00:27:10:LEC ATM1/1/0.1:mpoa_to_lec:appl 6, opcode 000:27:10:%LANE-3-NOREGILMI:ATM1/1/0.1 LEC cannot register 47.0091810000000050E2097801.0050A29AF428.01 with ILMI00:27:10:%LANE-6-INFO:ATM1/1/0:ILMI prefix add event received00:27:10:LANE ATM1/1/0:prefix add event for 470091810000000050E2097801 ptr=0x617B8E6C len=1300:27:10: the current first prefix is now:470091810000000050E209780100:27:10:%LANE-5-UPDOWN:ATM1/1/0.1 elan elan2:LE Client changed state to down00:27:10:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWN00:27:10:LEC ATM1/1/0.1:mpoa_to_lec:appl 6, opcode 000:27:10:%MPOA-5-UPDOWN:MPC mpc2:state changed to up00:27:10:LEC ATM1/1/0.1:mpoa_to_lec:appl 6, opcode 100:27:12:LEC ATM1/1/0.1:lec_process_lane_tlv:msg LANE_CONFIG_RSP, num_tlvs 1400:27:12:LEC ATM1/1/0.1:elan id from LECS set to 30000:27:12:LEC ATM1/1/0.1:lec_process_lane_tlv:msg LANE_JOIN_RSP, num_tlvs 100:27:12:LEC ATM1/1/0.1:elan id from LES set to 30000:27:12:LEC ATM1/1/0.1:lec_append_mpoa_dev_tlv:00:27:12:LEC ATM1/1/0.1:got mpoa client addr 47.0091810000000050E2097801.0050A29AF42D.0000:27:12:%LANE-5-UPDOWN:ATM1/1/0.1 elan elan2:LE Client changed state to up00:27:12:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:UPRouter(config-if)#exitRouter(config)#exitRelated Commands
debug modem traffic
Displays MPC debug information.
debug mpoa server
Displays information about the MPOA server.
debug lane config
To display information about a LAN Emulation (LANE) configuration server, use the debug lane config command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug lane config {all | events | packets}
no debug lane config {all | events | packets}
Syntax Description
Command Modes
Privileged EXEC
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 allLECS EVENT ATM1/0: processing interface down transitionLECS EVENT ATM1/0: placed de-register address 0x60E8A824 (47.00918100000000613E5A2F01.006070174823.00) request with signallingLECS EVENT ATM1/0: ilmiDeRegisterAddress: sendSetRequestToILMI failure; interface down ?LECS EVENT ATM1/0: placed de-register address 0x60EC4F28 (47.007900000000000000000000.00A03E000001.00) request with signallingLECS EVENT ATM1/0: ilmiDeRegisterAddress: sendSetRequestToILMI failure; interface down ?LECS EVENT ATM1/0: placed de-register address 0x60EC5C08 (47.00918100000000613E5A2F01.006070174823.99) request with signallingLECS EVENT ATM1/0: ilmiDeRegisterAddress: sendSetRequestToILMI failure; interface down ?LECS EVENT ATM1/0: tearing down all connexionsLECS EVENT ATM1/0: elan 'xxx' LES 47.00918100000000613E5A2F01.006070174821.01 callId 0x60CE0F58 deliberately being disconnectedLECS EVENT ATM1/0: sending RELEASE for call 0x60CE0F58 cause 31LECS EVENT ATM1/0: elan 'yyy' LES 47.00918100000000613E5A2F01.006070174821.02 callId 0x60CE2104 deliberately being disconnectedLECS EVENT ATM1/0: sending RELEASE for call 0x60CE2104 cause 31LECS EVENT ATM1/0: elan 'zzz' LES 47.00918100000000613E5A2F01.006070174821.03 callId 0x60CE2DC8 deliberately being disconnectedLECS EVENT ATM1/0: sending RELEASE for call 0x60CE2DC8 cause 31LECS EVENT ATM1/0: All calls to/from LECSs are being releasedLECS EVENT ATM1/0: placed de-register address 0x60EC4F28 (47.007900000000000000000000.00A03E000001.00) request with signallingLECS EVENT ATM1/0: ilmiDeRegisterAddress: sendSetRequestToILMI failure; interface down ?LECS EVENT ATM1/0: ATM_RELEASE_COMPLETE received: callId 0x60CE0F58 cause 0LECS EVENT ATM1/0: call 0x60CE0F58 cleaned upLECS EVENT ATM1/0: ATM_RELEASE_COMPLETE received: callId 0x60CE2104 cause 0LECS EVENT ATM1/0: call 0x60CE2104 cleaned upLECS EVENT ATM1/0: ATM_RELEASE_COMPLETE received: callId 0x60CE2DC8 cause 0LECS EVENT ATM1/0: call 0x60CE2DC8 cleaned upLECS EVENT ATM1/0: UNKNOWN/UNSET: signalling DE-registeredLECS EVENT: UNKNOWN/UNSET: signalling DE-registeredLECS EVENT ATM1/0: UNKNOWN/UNSET: signalling DE-registeredLECS EVENT ATM1/0: placed de-register address 0x60E8A824 (47.00918100000000613E5A2F01.006070174823.00) request with signallingLECS EVENT ATM1/0: ilmiDeRegisterAddress: sendSetRequestToILMI failure; interface down ?LECS EVENT ATM1/0: placed de-register address 0x60EC5C08 (47.00918100000000613E5A2F01.006070174823.99) request with signallingLECS EVENT ATM1/0: ilmiDeRegisterAddress: sendSetRequestToILMI failure; interface down ?LECS EVENT ATM1/0: tearing down all connexionsLECS EVENT ATM1/0: All calls to/from LECSs are being releasedLECS EVENT: config server 56 killeddebug lane finder
To display information about the finder internal state machine, use the debug lane finder command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug lane finder
no debug lane finder
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
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 finderLECS FINDER ATM1/0.3: user request 1819 of type GET_MASTER_LECS_ADDRESS queued upLECS FINDER ATM1/0: finder state machine startedLECS FINDER ATM1/0: time to perform a getNext on the ILMILECS FINDER ATM1/0: LECS 47.00918100000000613E5A2F01.006070174823.00 deletedLECS FINDER ATM1/0: ilmi_client_request failed, answering all usersLECS FINDER ATM1/0: answering all requests nowLECS FINDER ATM1/0: responded to user request 1819LECS FINDER ATM1/0: number of remaining requests still to be processed: 0LECS FINDER ATM1/0.2: user request 1820 of type GET_MASTER_LECS_ADDRESS queued upLECS FINDER ATM1/0: finder state machine startedLECS FINDER ATM1/0: time to perform a getNext on the ILMILECS FINDER ATM1/0: ilmi_client_request failed, answering all usersLECS FINDER ATM1/0: answering all requests nowLECS FINDER ATM1/0: responded to user request 1820LECS FINDER ATM1/0: number of remaining requests still to be processed: 0LECS FINDER ATM1/0.1: user request 1821 of type GET_MASTER_LECS_ADDRESS queued upLECS FINDER ATM1/0: finder state machine startedLECS FINDER ATM1/0: time to perform a getNext on the ILMILECS FINDER ATM1/0: ilmi_client_request failed, answering all usersLECS FINDER ATM1/0: answering all requests nowLECS FINDER ATM1/0: responded to user request 1821LECS FINDER ATM1/0: number of remaining requests still to be processed: 0debug lane server
To display information about a LAN Emulation (LANE) server, use the debug lane server command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug lane server [interface interface]
no debug lane server [interface interface]
Syntax Description
Command Modes
Privileged EXEC
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 serverLES ATM1/0.1: lsv_lecsAccessSigCB called with callId 0x60CE124C, opcode ATM_RELEASE_COMPLETELES ATM1/0.1: disconnected from the master LECSLES ATM1/0.1: should have been connected, will reconnect in 3 secondsLES ATM1/0.2: lsv_lecsAccessSigCB called with callId 0x60CE29E0, opcode ATM_RELEASE_COMPLETELES ATM1/0.2: disconnected from the master LECSLES ATM1/0.2: should have been connected, will reconnect in 3 secondsLES ATM1/0.3: lsv_lecsAccessSigCB called with callId 0x60EB1940, opcode ATM_RELEASE_COMPLETELES ATM1/0.3: disconnected from the master LECSLES ATM1/0.3: should have been connected, will reconnect in 3 secondsLES ATM1/0.2: elan yyy client 1 lost control distributeLES ATM1/0.2: elan yyy client 1: lsv_kill_client calledLES ATM1/0.2: elan yyy client 1 state change Oper -> TermLES ATM1/0.3: elan zzz client 1 lost control distributeLES ATM1/0.3: elan zzz client 1: lsv_kill_client calledLES ATM1/0.3: elan zzz client 1 state change Oper -> TermLES ATM1/0.2: elan yyy client 1 lost MC forwardLES ATM1/0.2: elan yyy client 1: lsv_kill_client calledLES ATM1/0.3: elan zzz client 1 lost MC forwardLES ATM1/0.3: elan zzz client 1: lsv_kill_client calledLES ATM1/0.1: elan xxx client 1 lost control distributeLES ATM1/0.1: elan xxx client 1: lsv_kill_client calledLES ATM1/0.1: elan xxx client 1 state change Oper -> TermLES ATM1/0.1: elan xxx client 1 lost MC forwardLES ATM1/0.1: elan xxx client 1: lsv_kill_client calledLES ATM1/0.2: elan yyy client 1 released control directLES ATM1/0.2: elan yyy client 1: lsv_kill_client calledLES ATM1/0.3: elan zzz client 1 released control directLES ATM1/0.3: elan zzz client 1: lsv_kill_client calledLES ATM1/0.2: elan yyy client 1 MC forward releasedLES ATM1/0.2: elan yyy client 1: lsv_kill_client calledLES ATM1/0.2: elan yyy client 1: freeing client structuresLES ATM1/0.2: elan yyy client 1 unregistered 0060.7017.4820LES ATM1/0.2: elan yyy client 1 destroyedLES ATM1/0.3: elan zzz client 1 MC forward releasedLES ATM1/0.3: elan zzz client 1: lsv_kill_client calledLES ATM1/0.3: elan zzz client 1: freeing client structuresLES ATM1/0.3: elan zzz client 1 unregistered 0060.7017.4820LES ATM1/0.3: elan zzz client 1 destroyedLES ATM1/0.1: elan xxx client 1 released control directLES ATM1/0.1: elan xxx client 1: lsv_kill_client calledLES ATM1/0.1: elan xxx client 1 MC forward releasedLES ATM1/0.1: elan xxx client 1: lsv_kill_client calledLES ATM1/0.1: elan xxx client 1: freeing client structuresLES ATM1/0.1: elan xxx client 1 unregistered 0060.7017.4820LES ATM1/0.1: elan xxx client 1 destroyedLES ATM1/0.1: elan xxx major interface state changeLES ATM1/0.1: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.1: shutting downLES ATM1/0.1: elan xxx: lsv_kill_lesbus calledLES ATM1/0.1: elan xxx: LES/BUS state change operational -> terminatingLES ATM1/0.1: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.2: elan yyy major interface state changeLES ATM1/0.2: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.2: shutting downLES ATM1/0.2: elan yyy: lsv_kill_lesbus calledLES ATM1/0.2: elan yyy: LES/BUS state change operational -> terminatingLES ATM1/0.2: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.3: elan zzz major interface state changeLES ATM1/0.3: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.3: shutting downLES ATM1/0.3: elan zzz: lsv_kill_lesbus calledLES ATM1/0.3: elan zzz: LES/BUS state change operational -> terminatingLES ATM1/0.3: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.1: elan xxx: lsv_kill_lesbus calledLES ATM1/0.1: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.1: elan xxx: lsv_kill_lesbus calledLES ATM1/0.1: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.1: elan xxx: stopped listening on addressesLES ATM1/0.1: elan xxx: all clients killedLES ATM1/0.1: elan xxx: multicast groups killedLES ATM1/0.1: elan xxx: addresses de-registered from ilmiLES ATM1/0.1: elan xxx: LES/BUS state change terminating -> downLES ATM1/0.1: elan xxx: administratively downLES ATM1/0.2: elan yyy: lsv_kill_lesbus calledLES ATM1/0.2: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.2: elan yyy: lsv_kill_lesbus calledLES ATM1/0.2: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.2: elan yyy: stopped listening on addressesLES ATM1/0.2: elan yyy: all clients killedLES ATM1/0.2: elan yyy: multicast groups killedLES ATM1/0.2: elan yyy: addresses de-registered from ilmiLES ATM1/0.2: elan yyy: LES/BUS state change terminating -> downLES ATM1/0.2: elan yyy: administratively downLES ATM1/0.3: elan zzz: lsv_kill_lesbus calledLES ATM1/0.3: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.3: elan zzz: lsv_kill_lesbus calledLES ATM1/0.3: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.3: elan zzz: stopped listening on addressesLES ATM1/0.3: elan zzz: all clients killedLES ATM1/0.3: elan zzz: multicast groups killedLES ATM1/0.3: elan zzz: addresses de-registered from ilmiLES ATM1/0.3: elan zzz: LES/BUS state change terminating -> downLES ATM1/0.3: elan zzz: administratively downLES ATM1/0.3: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.2: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.1: cleanupLecsAccess: discarding all validation requestsdebug lane signaling
To display information about LANE Server (LES) and Broadcast and Unknown Server (BUS) switched virtual circuits (SVCs), use the debug lane signaling command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug lane signaling [interface interface]
no debug lane signaling [interface interface]
Syntax Description
Command Modes
Privileged EXEC
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 signalingLANE SIG ATM1/0.2: received ATM_RELEASE_COMPLETE callid 0x60EB565C cause 0 lv 0x60E8D348 lvstate LANE_VCC_CONNECTEDLANE SIG ATM1/0.2: lane_sig_mc_release: breaking lv 0x60E8D348 from mcg 0x60E97E84LANE SIG ATM1/0.2: timer for lv 0x60E8D348 stoppedLANE SIG ATM1/0.2: sent ATM_RELEASE request for lv 0x60E8D468 in state LANE_VCC_CONNECTEDLANE SIG ATM1/0.2: sent ATM_RELEASE request for lv 0x60E8D3D8 in state LANE_VCC_CONNECTEDLANE SIG ATM1/0.2: sent ATM_RELEASE request for lv 0x60E8D2B8 in state LANE_VCC_CONNECTEDLANE SIG ATM1/0.3: received ATM_RELEASE_COMPLETE callid 0x60EB5CA0 cause 0 lv 0x60E8BEF4 lvstate LANE_VCC_CONNECTEDLANE SIG ATM1/0.3: lane_sig_mc_release: breaking lv 0x60E8BEF4 from mcg 0x60E9A37CLANE SIG ATM1/0.3: timer for lv 0x60E8BEF4 stoppedLANE SIG ATM1/0.3: sent ATM_RELEASE request for lv 0x60E8C014 in state LANE_VCC_CONNECTEDLANE SIG ATM1/0.3: sent ATM_RELEASE request for lv 0x60E8BF84 in state LANE_VCC_CONNECTEDLANE SIG ATM1/0.3: sent ATM_RELEASE request for lv 0x60E8BE64 in state LANE_VCC_CONNECTEDLANE SIG ATM1/0.2: received ATM_RELEASE_COMPLETE callid 0x60EB9040 cause 0 lv 0x60E8D468 lvstate LANE_VCC_DROP_SENTLANE SIG ATM1/0.2: lane_sig_mc_release: breaking lv 0x60E8D468 from mcg 0x60E97EC8LANE SIG ATM1/0.2: timer for lv 0x60E8D468 stoppedLANE SIG ATM1/0.3: received ATM_RELEASE_COMPLETE callid 0x60EB97D4 cause 0 lv 0x60E8C014 lvstate LANE_VCC_DROP_SENTLANE SIG ATM1/0.3: lane_sig_mc_release: breaking lv 0x60E8C014 from mcg 0x60E9A3C0LANE SIG ATM1/0.3: timer for lv 0x60E8C014 stoppedLANE SIG ATM1/0.1: received ATM_RELEASE_COMPLETE callid 0x60EBCEB8 cause 0 lv 0x60EBBAF0 lvstate LANE_VCC_CONNECTEDLANE SIG ATM1/0.1: lane_sig_mc_release: breaking lv 0x60EBBAF0 from mcg 0x60E8F51CLANE SIG ATM1/0.1: timer for lv 0x60EBBAF0 stoppedLANE SIG ATM1/0.1: sent ATM_RELEASE request for lv 0x60EBBC10 in state LANE_VCC_CONNECTEDLANE SIG ATM1/0.1: sent ATM_RELEASE request for lv 0x60EBBB80 in state LANE_VCC_CONNECTEDLANE SIG ATM1/0.1: sent ATM_RELEASE request for lv 0x60EBBA60 in state LANE_VCC_CONNECTEDLANE SIG ATM1/0.1: received ATM_RELEASE_COMPLETE callid 0x60EBEB00 cause 0 lv 0x60EBBC10 lvstate LANE_VCC_DROP_SENTLANE SIG ATM1/0.1: lane_sig_mc_release: breaking lv 0x60EBBC10 from mcg 0x60E8F560LANE SIG ATM1/0.1: timer for lv 0x60EBBC10 stoppedLANE SIG ATM1/0.2: received ATM_RELEASE_COMPLETE callid 0x60E8B174 cause 0 lv 0x60E8D2B8 lvstate LANE_VCC_RELEASE_SENTLANE SIG ATM1/0.2: timer for lv 0x60E8D2B8 stoppedLANE SIG ATM1/0.3: received ATM_RELEASE_COMPLETE callid 0x60E8B990 cause 0 lv 0x60E8BE64 lvstate LANE_VCC_RELEASE_SENTLANE SIG ATM1/0.3: timer for lv 0x60E8BE64 stoppedLANE SIG ATM1/0.2: received ATM_RELEASE_COMPLETE callid 0x60EB7FE0 cause 0 lv 0x60E8D3D8 lvstate LANE_VCC_RELEASE_SENTLANE SIG ATM1/0.2: timer for lv 0x60E8D3D8 stoppedLANE SIG ATM1/0.3: received ATM_RELEASE_COMPLETE callid 0x60EB8554 cause 0 lv 0x60E8BF84 lvstate LANE_VCC_RELEASE_SENTLANE SIG ATM1/0.3: timer for lv 0x60E8BF84 stoppedLANE SIG ATM1/0.1: received ATM_RELEASE_COMPLETE callid 0x60EBB6D4 cause 0 lv 0x60EBBA60 lvstate LANE_VCC_RELEASE_SENTLANE SIG ATM1/0.1: timer for lv 0x60EBBA60 stoppedLANE SIG ATM1/0.1: received ATM_RELEASE_COMPLETE callid 0x60EBE24C cause 0 lv 0x60EBBB80 lvstate LANE_VCC_RELEASE_SENTLANE SIG ATM1/0.1: timer for lv 0x60EBBB80 stoppedLANE SIG ATM1/0.1: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTERLANE SIG ATM1/0.1: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTERLANE SIG ATM1/0.2: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTERLANE SIG ATM1/0.2: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTERLANE SIG ATM1/0.3: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTERLANE SIG ATM1/0.3: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTERLANE SIG ATM1/0.1: received ATM_CANCEL_NSAP for nsap 00.000000000000050000000000.000000000000.00LANE SIG ATM1/0.1: received ATM_CANCEL_NSAP for nsap 00.000000000000050000000000.000000000000.00LANE SIG ATM1/0.2: received ATM_CANCEL_NSAP for nsap 00.000000000000050000000000.000000000000.00LANE SIG ATM1/0.2: received ATM_CANCEL_NSAP for nsap 00.000000000000050000000000.000000000000.00LANE SIG ATM1/0.3: received ATM_CANCEL_NSAP for nsap 00.000000000000050000000000.000000000000.00LANE SIG ATM1/0.3: received ATM_CANCEL_NSAP for nsap 00.000000000000050000000000.000000000000.00debug 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
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC (#)
Command History
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.
The debug lapb command can generate debugging messages of LAPB on all interfaces configured with the encapsulation lapb command or when X.25 traffic is present on interfaces configured with the encapsulation x25 command. LAPB debugging produces a substantial amount of data and makes debugging very tedious. The problem becomes more severe if the network contains a large number of X.25 interfaces. Therefore the LAPB debugs are set to be available for individual interface.
Caution
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 7Serial0: LAPB I CONNECT (5) IFRAME P 2 1Serial0: LAPB O REJSENT (2) REJ F 3Serial0: LAPB O REJSENT (5) IFRAME 0 3Serial0: LAPB I REJSENT (2) REJ (C) 7Serial0: LAPB I DISCONNECT (2) SABM PSerial0: LAPB O CONNECT (2) UA FSerial0: LAPB O CONNECT (5) IFRAME 0 0Serial0: LAPB T1 CONNECT 357964 0Each 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 208 describes the first seven fields.
A timer event displays only 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 255748Serial2: LAPB O CONNECT (2) RR P 5Serial2: LAPB I CONNECT (2) RR F 5Serial2: LAPB T4 CONNECT 260748Serial2: LAPB O CONNECT (2) RR P 5Serial2: LAPB I CONNECT (2) RR F 5The next example shows an interface outage timer expiration (T3):
Serial2: LAPB T3 DISCONNECT 273284The 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 also be highlighted, such as a too-short or too-long frame or an invalid address (neither command nor response).
Serial2: LAPB T1 SABMSENT 1026508 1Serial2: LAPB O SABMSENT (2) SABM PSerial2: LAPB I SABMSENT (2) SABM (R/ERR)Serial2: LAPB T1 SABMSENT 1029508 2Serial2: LAPB O SABMSENT (2) SABM PSerial2: LAPB I SABMSENT (2) SABM (R/ERR)The output in the next example shows tha 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 0Serial2: LAPB O SABMSENT (2) SABME PSerial2: LAPB I SABMSENT (2) SABM PSerial2: LAPB T1 SABMSENT 1431720 1Serial2: LAPB O SABMSENT (2) SABME PSerial2: LAPB I SABMSENT (2) SABM PThe output in the next example shows that the debug lapb command is set for a single interface; that is, interface 0/0.
Serial0/0: LAPB O CONNECT (17) IFRAME 1 7Serial0/0: LAPB I CONNECT (5) IFRAME 7 2Serial0/0: LAPB I CONNECT (6) IFRAME 0 2Serial0/0: LAPB O CONNECT (2) RR (R) 1Serial0/0: LAPB O CONNECT (50) IFRAME 2 1Serial0/0: LAPB I CONNECT (15) IFRAME 1 2Serial0/0: LAPB O CONNECT (5) IFRAME 3 2debug 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.
debug lapb-ta [error | event | traffic]
no debug lapb-ta [error | event | traffic]
Syntax Description
error
(Optional) Displays LAPB-TA errors.
event
(Optional) Displays LAPB-TA normal events.
traffic
(Optional) Displays LAPB-TA in/out traffic data.
Defaults
Debugging for LAPB-TA is not enabled.
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the debug lapb-ta command with the error, event, and traffic keywords activated:
Router# debug lapb-ta errorLAPB-TA error debugging is onRouter# debug lapb-ta eventLAPB-TA event debugging is onRouter# debug lapb-ta trafficLAPB-TA traffic debugging is onMar 9 12:11:36.464:LAPB-TA:Autodetect trying to detect LAPB onBR3/0:1Mar 9 12:11:36.464: sampled pkt: 2 bytes: 1 3F.. matchMar 9 12:11:36.468:LAPBTA:get_ll_config:BRI3/0:1Mar 9 12:11:36.468:LAPBTA:line 130 allocated for BR3/0:1Mar 9 12:11:36.468:LAPBTA:process 79Mar 9 12:11:36.468:BR3/0:1:LAPB-TA startedMar 9 12:11:36.468:LAPBTA:service change:LAPB physical layer up,context 6183E144 interface up, protocol downMar 9 12:11:36.468:LAPBTA:service change:, context 6183E144 upMar 9 12:11:36.468:LAPB-TA:BR3/0:1, 44 sent2d14h:%LINEPROTO-5-UPDOWN:Line protocol on Interface BRI3/0:1, changed state to up2d14h:%ISDN-6-CONNECT:Interface BRI3/0:1 is now connected to 60213Mar 9 12:11:44.508:LAPB-TA:BR3/0:1, 1 rcvdMar 9 12:11:44.508:LAPB-TA:BR3/0:1, 3 sentMar 9 12:11:44.700:LAPB-TA:BR3/0:1, 1 rcvdMar 9 12:11:44.700:LAPB-TA:BR3/0:1, 3 sentMar 9 12:11:44.840:LAPB-TA:BR3/0:1, 1 rcvdMar 9 12:11:44.840:LAPB-TA:BR3/0:1, 14 sentMar 9 12:11:45.852:LAPB-TA:BR3/0:1, 1 rcvdMar 9 12:11:46.160:LAPB-TA:BR3/0:1, 2 rcvdMar 9 12:11:47.016:LAPB-TA:BR3/0:1, 1 rcvdMar 9 12:11:47.016:LAPB-TA:BR3/0:1, 10 sentdebug lat packet
To display information on all local-area transport (LAT) events, use the debug lat packet command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug lat packet
no debug lat packet
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
For each datagram (packet) received or sent, a message is logged to the console.
Caution
Examples
The following is sample output from the debug lat packet command:
Router# debug lat packetLAT: I int=Ethernet0, src=0000.0c01.0509, dst=0900.2b00.000f, type=0, M=0, R=0LAT: I int=Ethernet0, src=0800.2b11.2d13, dst=0000.0c01.7876, type=A, M=0, R=0LAT: O dst=0800.2b11.2d13, int=Ethernet0, type= A, M=0, R=0, len= 20, next 0 ref 1The second line of output describes a packet that is input to the router. Table 209 describes the fields in this line.
The third line of output describes a packet that is output from the router. Table 210 describes the last three fields in this line.
debug lex rcmd
To debug LAN Extender remote commands, use the debug lex rcmd command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug lex rcmd
no debug lex rcmd
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Examples
The following is sample output from the debug lex rcmd command:
Router# debug lex rcmdLEX-RCMD: "shutdown" command received on unbound serial interface- Serial0LEX-RCMD: Lex0: "inventory" command receivedRcvd rcmd: FF 03 80 41 41 13 00 1A 8A 00 00 16 01 FF 00 00Rcvd rcmd: 00 02 00 00 07 5B CD 15 00 00 0C 01 15 26LEX-RCMD: ACK or response received on Serial0 without a corresponding IDLEX-RCMD: REJ receivedLEX-RCMD: illegal CODE field received in header: <number>LEX-RCMD: illegal length for Lex0: "lex input-type-list"LEX-RCMD: Lex0 is not bound to a serial interfaceLEX-RCMD: encapsulation failureLEX-RCMD: timeout for Lex0: "lex priority-group" commandLEX-RCMD: re-transmitting Lex0: "lex priority-group" commandLEX-RCMD: lex_setup_and_send called with invalid parameterLEX-RCMD: bind occurred on shutdown LEX interfaceLEX-RCMD: Serial0- No free Lex interface found with negotiated MAC address 0000.0c00.d8dbLEX-RCMD: No active Lex interface found for unbindThe 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- Serial0This message can occur for any of the LAN Extender remote commands. Possible causes of this message are as follows:
•
•
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 receivedRcvd rcmd: FF 03 80 41 41 13 00 1A 8A 00 00 16 01 FF 00 00Rcvd rcmd: 00 02 00 00 07 5B CD 15 00 00 0C 01 15 26The 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 IDThis message could be displayed for any of the following reasons:
•
•
•
Possible responses to Config-Request are Config-ACK, Config-NAK, and Config-Rej. The following output shows that some of the options in the Config-Request are not recognizable or are not acceptable to FLEX due to transmission errors or software errors:
LEX-RCMD: REJ receivedThe 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 interfaceThe 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 failureThe 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" commandThis message could be displayed for any of the following reasons:
•
•
•
The following output indicates that the host is resending the remote command after a timeout:
LEX-RCMD: re-transmitting Lex0: "lex priority-group" commandThe 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 parameterThe following output is informational and shows when a bind occurs on a shutdown interface:
LEX-RCMD: bind occurred on shutdown LEX interfaceThe 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.d8dbThe 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 unbinddebug license
To enable controlled Cisco IOS software license debugging activity on a device, use the debug license command in privileged EXEC mode. To disable debugging, use the no form of this command.
debug license {agent {all | error} | core {all | error | event} | errors | events | ipc}
no debug license {agent {all | error} | core {all | error | event} | errors | events | ipc}
Syntax Description
Command Default
Debugging is disabled.
Command Modes
Privileged EXEC (#)
Command History
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 errorsThe following example shows how to enable debugging for all license agent information on a switch:
Switch# debug license agent alllicense agent app https[0x43FBC7C]: urlhook functionlicense agent app https[0x43FBC7C]: https action functionLIC_AGENT:Processing XML message<?xml version="1.0" encoding="UTF-8"?><SOAP:Envelope xmlns:SOAP="http://www.w3.org/2003/05/soap-envelope"><SOAP:Header><clm:Header version="1.0" xmlns:clm="http://www.cisco.com/clm"><clm:Time>2003-04-23T20:27:19.827Z</clm:Time></clm:Header></SOAP:Header><SOAP:Body><lica:request xmlns:lica="http://www.cisco.com/clm"><lica:installRequest><lica:license encoding="BASE64">PENJU0NPX1dUX0FSVElGQUNUUyB2ZXJzaW9uPSIxLjAiPjxDSVNDT19XVF9MSUNFTlNFIHZlcnNpb249IjEuMCI+PEZFQVRVUkVfTkFNRT5pcGJhc2U8L0ZFQVRVUkVfTkFNRT48RkVBVFVSRV9WRVJTSU9OPjEuMDwvRkVBVFVSRV9WRVJTSU9OPjxVREk+PFBJRD5CVUxMU0VZRTI0PC9QSUQ+PFNOPkNBVDEwMDZSMEU4PC9TTj48L1VEST48U09VUkNFPkNpc2NvIEhRPC9TT1VSQ0U+PENSRUFURV9EQVRFPjIwMDYtMTEtMjJUMDA6MzM6NTA8L0NSRUFURV9EQVRFPjxMSUNFTlNFX0xJTkVfSEFTSCBoYXNoQWxnbz0iU0hBMSI+NDJiNFVWWFpOd3pJK0ZNdEV6QlNZSDRWdzFFPTwvTElDRU5TRV9MSU5FX0hBU0g+PFRZUEU+UkVHVUxBUjwvVFlQRT48TElDRU5TRV9MSU5FPjwhW0NEQVRBWzExIGlwYmFzZSAxLjAgTE9ORyBOT1JNQUwgU1RBTkRBTE9ORSBFWENMIElORklOSVRFX0tFWVMgSU5GSU5JVEVfS0VZUyBORVZFUiBORVZFUiBOaUwgU0xNX0NPREUgQ0xfTkRfTENLIE5pTCAqMVZBUlY5WlJESzREOU5UNDAwIE5pTCBOaUwgTmlMIDVfTUlOUyA8VURJPjxQSUQ+QlVMTFNFWUUyNDwvUElEPjxTTj5DQVQxMDA2UjBFODwvU04+PC9VREk+IGUxWW8wS1U2VnJLOnBJZXRib1dJVkEyZlVaVGdieUlEaklHWERRVXc3dkxOYWlXRzZ0dUJOMG5lTXpKaHpzQ2tMN1l3TWFxS2paem05YW5FbVJHUUVPTHlDdmRVZkswQmNLN0pPcnZsUkw0VjMyJDxXTEM+QVFFQklRQUIvLy9GbS8vWDkybThNb0NOZkVMSHJiVzRjWDFMZGNpdDNMVU5GWlV1OWppT0phcXB5Q2N6TTFpaUlKbVE3NEd5WHJFY3F2UGlBbVdTYUVtVVQ1NnJzdGs2Z3ZtaitFUUtSZkQ5QTBpbWUxY3pyZEt4ZklMVDBMYVhUNDE2bndtZnA5MlR5YTZ2SVE0Rm5sQmRxSjFzTXpYZVNxOFBtVmNUVTlBNG85aGlsOXZLdXI4TjlGODg1RDlHVkYwYkpIY2lUNU09PC9XTEM+XV0+PC9MSUNFTlNFX0xJTkU+PFVTRVJfTU9ESUZJQUJMRV9DT01NRU5UIGZpZWxkUmVzdHJpY3Rpb25zPSJNYXggOTkgQVNDSUkgY2hhcmFjdGVycyBpbiBsZW5ndGguIj48L1VTRVJfTU9ESUZJQUJMRV9DT01NRU5UPjwvQ0lTQ09fV1RfTElDRU5TRT48L0NJU0NPX1dUX0FSVElGQUNUUz4=</lica:license></lica:installRequest></lica:request></SOAP:Body></SOAP:Envelope>LIC_AGENT: XML received opcode(1)LIC_AGENT: License ipbase%IOS_LICENSE_IMAGE_APPLICATION-6-LICENSE_LEVEL: Next reboot level = ipbase and License = ipbaseLIC_AGENT: Notification Event type = 1 License InstalledLIC_AGENT: Notification Event type = 13 License Annotate
debug link monitor
To display the statistics of the executing process, use the debug link monitor command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug link monitor
no debug link monitor
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command is used to display the statistics, which are used for debugging the status of the various conditions occurred during execution of the monitoring process.
Examples
The following example enables link monitoring statistics:
Router# debug link monitor%DEBUG-ENABLED Error Rate Link MonitorThe following example disables link monitoring statistics:
Router# no debug link monitor%DEBUG-DISABLED Error Rate Link MonitorRelated Commands
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.
debug list [list] [interface]
no debug list [list] [interface]
Syntax Description
Command Modes
Privileged EXEC
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:
•
•
•
•
•
•
•
Note
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 llc2SdllcVirtualRing2008 DTE: 4000.2222.22c7 4000.1111.111c 04 04 state NORMALSdllcVirtualRing2008 DTE: 4000.2222.22c8 4000.1111.1120 04 04 state NORMALSdllcVirtualRing2008 DTE: 4000.2222.22c1 4000.1111.1104 04 04 state NORMALNext, 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 0x404The 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 1103Router# debug llc2 packetLLC2 Packets debugging is onfor access list: 1103To 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 0x4access-list 1102 permit 0000.0000.0000 0000.0000.0000 0000.0000.0000 0000.0000.0000The 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 1102Router# debug sdlcSDLC link debugging is onfor access list: 1102To 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 0Router# debug sdlcSDLC link debugging is onfor interface: Serial0To 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.0000access-list 1106 permit 0000.30e0.8250 8000.0000.0000 0000.3018.4acd 8000.0000.0000Invoke the following debug commands:
Router# debug list 1106Router# debug token ringToken Ring Interface debugging is onfor access list: 1106To 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.0000Invoke the following debug commands:
Router# debug list 1109Router# debug rifRIF update debugging is onfor access list: 1109Related Commands
debug llc2 dynwind
To display changes to the dynamic window over Frame Relay, use the debug llc2 dynwind command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug llc2 dynwind
no debug llc2 dynwind
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Examples
The following is sample output from the debug llc2 dynwind command:
Router# debug llc2 dynwindLLC2/DW: BECN received! event REC_I_CMD, Window size reduced to 4LLC2/DW: 1 consecutive I-frame(s) received without BECNLLC2/DW: 2 consecutive I-frame(s) received without BECNLLC2/DW: 3 consecutive I-frame(s) received without BECNLLC2/DW: 4 consecutive I-frame(s) received without BECNLLC2/DW: 5 consecutive I-frame(s) received without BECNLLC2/DW: Current working window size is 5In 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.
Related Commands
debug llc2 errors
To display Logical Link Control, type 2 (LLC2) protocol error conditions or unexpected input, use the debug llc2 errors command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug llc2 errors
no debug llc2 errors
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Examples
The following is sample output from the debug llc2 errors command from a router ignoring an incorrectly configured device:
Router# debug llc2 errorsLLC: admstate: 4000.1014.0001 0000.0000.0000 04 04 REC_RR_RSPLLC: admstate: 4000.1014.0001 0000.0000.0000 04 04 REC_RR_RSPLLC: admstate: 4000.1014.0001 0000.0000.0000 04 04 REC_RR_RSPLLC: admstate: 4000.1014.0001 0000.0000.0000 04 04 REC_RR_RSPLLC: admstate: 4000.1014.0001 0000.0000.0000 04 04 REC_RR_RSPLLC: admstate: 4000.1014.0001 0000.0000.0000 04 04 REC_RR_RSPEach 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.
Related Commands
debug llc2 packet
To display all input and output from the Logical Link Control, type 2 (LLC2) protocol stack, use the debug llc2 packet command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug llc2 packet
no debug llc2 packet
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
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 packetLLC: llc2_input401E54F0: 10400000 .@..401E5500: 303A90CF 0006F4E1 2A200404 012B5E 0:.O..ta* ...+LLC: i REC_RR_CMD N(R)=21 p/f=1LLC: 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)=42LLC: 0006.f4e1.2a20 0000.303a.90cf 04 04 txmt RR_RSP N(R)=20 p/f=1LLC: llc_sendframe401E5610: 0040 0006F4E1 2A200000 .@..ta* ..401E5620: 303A90CF 04050129 00 N 0:.O...). 2012LLC: llc_sendframe4022E3A0: 0040 0006F4E1 .@..ta4022E3B0: 2A200000 303A90CF 04042A28 2C000202 * ..0:.O..*(,...4022E3C0: 00050B90 A02E0502 FF0003D1 004006C1 .... ......Q.@.A4022E3D0: D7C9D5C 0.128C400130A C1D7D7D5 4BD5F2F0 WIUGD...AWWUKUrp4022E3E0: F1F30000 011A6071 00010860 D7027000 qs....`q...`W.p.4022E3F0: 00003B00 1112FF01 03000243 6973636F ..;........Cisco4022E400: 20494F53 69 IOSiLLC: 0006.f4e1.2a20 0000.303a.90cf 04 04 txmt I N(S)=21 N(R)=20 p/f=0 size=90LLC: llc2_input401E5620: 10400000 303A90CF .@..0:.O401E5630: 0006F4E1 2A200404 282C2C00 02020004 ..ta* ..(,,.....401E5640: 03902000 1112FF01 03000243 6973636F .. ........Cisco401E5650: 20494F53 A0 IOSLLC: i REC_I_CMD N(R)=22 N(S)=20 V(R)=20 p/f=0LLC: 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)=20LLC (rs): 0006.f4e1.2a20 0000.303a.90cf 04 04 REC_I_CMD N(R)=44LLC: INFO: 0006.f4e1.2a20 0000.303a.90cf 04 04 v(r) 20The first three lines indicate that the router has received some input from the link:
LLC: llc2_input401E54F0: 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=1The 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)=42The 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=1LLC: llc_sendframe401E5610: 0040 0006F4E1 2A200000 .@..ta* ..401E5620: 303A90CF 04050129 00 N 0:.O...). 2012Related Commands
debug llc2 state
To display state transitions of the Logical Link Control, type 2 (LLC2) protocol, use the debug llc2 state command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug llc2 state
no debug llc2 state
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
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 stateLLC (stsw): 0006.f4e1.2a20 0000.303a.90cf 04 04, NORMAL -> AWAIT (P_TIMER_EXP)LLC(rs): 0006.f4e1.2a20 0000.303a.90cf 04 04, AWAIT -> D_CONN (P_TIMER_EXP)LLC: cleanup 0006.f4e1.2a20 0000.303a.90cf 04 04, UNKNOWN (17)LLC (stsw): 0006.f4e1.2a20 0000.303a.90cf 04 04, ADM -> SETUP (CONN_REQ)LLC: normalstate: set_local_busy 0006.f4e1.2a20 0000.303a.90cf 04 04LLC (stsw): 0006.f4e1.2a20 0000.303a.90cf 04 04, NORMAL -> BUSY (SET_LOCAL_BUSY)LLC: Connection established: 0006.f4e1.2a20 0000.303a.90cf 04 04, successLLC (stsw): 0006.f4e1.2a20 0000.303a.90cf 04 04, SETUP -> BUSY (SET_LOCAL_BUSY)LLC: busystate: 0006.f4e1.2a20 0000.303a.90cf 04 04 local busy clearedLLC (stsw): 0006.f4e1.2a20 0000.303a.90cf 04 04, BUSY -> NORMAL (CLEAR_LOCAL_BUSY)Related Commands
debug lnm events
To display any unusual events that occur on a Token Ring network, use the debug lnm events command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug lnm events
no debug lnm events
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
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 eventsIBMNM3: Adding 0000.3001.1166 to error listIBMNM3: Station 0000.3001.1166 going into preweight conditionIBMNM3: Station 0000.3001.1166 going into weight conditionIBMNM3: Removing 0000.3001.1166 from error listLANMGR0: Beaconing is present on the ringLANMGR0: Ring is no longer beaconingIBMNM3: Beaconing, Postmortem StartedIBMNM3: Beaconing, heard from 0000.3000.1234IBMNM3: Beaconing, Postmortem Next StageIBMNM3: Beaconing, Postmortem FinishedThe 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 listThe 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 conditionThe following message indicates that station 0000.3001.1166 is experiencing a severe number of errors:
IBMNM3: Station 0000.3001.1166 going into weight conditionThe 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 listThe following message indicates that Ring 0 has entered failure mode. This ring number is assigned internally.
LANMGR0: Beaconing is present on the ringThe following message indicates that Ring 0 is no longer in failure mode. This ring number is assigned internally.
LANMGR0: Ring is no longer beaconingThe 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 StartedThe 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.1234The 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 StageThe 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 FinishedExplanations 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 exceededThe following message indicates that a station (or stations) on Ring 3 is receiving frames faster than they can be processed:
IBMNM3: Adapters experiencing congestionThe following message indicates that the beaconing has lasted for over 1 minute and is considered a "permanent" error:
IBMNM3: Beaconing, permanentThe 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 StartedIn the preceding line of output, the following can replace "Started": "Next State," "Finished," "Timed out," and "Cannot find station n."
debug lnm llc
To display all communication between the router/bridge and the LAN Network Managers (LNMs) that have connections to it, use the debug lnm llc command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug lnm llc
no debug lnm llc
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
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 llcIBMNM: Received LRM Set Reporting Point frame from 1000.5ade.0d8a.IBMNM: found bridge: 001-2-00A, addresses: 0000.3040.a630 4000.3040.a630IBMNM: Opening connection to 1000.5ade.0d8a on TokenRing0IBMNM: Sending LRM LAN Manager Accepted to 1000.5ade.0d8a on link 0.IBMNM: sending LRM New Reporting Link Established to 1000.5a79.dbf8 on link 1.IBMNM: Determining new controlling LNMIBMNM: Sending Report LAN Manager Control Shift to 1000.5ade.0d8a on link 0.IBMNM: Sending Report LAN Manager Control Shift to 1000.5a79.dbf8 on link 1.IBMNM: Bridge 001-2-00A received Request Bridge Status from 1000.5ade.0d8a.IBMNM: Sending Report Bridge Status to 1000.5ade.0d8a on link 0.IBMNM: Bridge 001-2-00A received Request REM Status from 1000.5ade.0d8a.IBMNM: Sending Report REM Status to 1000.5ade.0d8a on link 0.IBMNM: Bridge 001-2-00A received Set Bridge Parameters from 1000.5ade.0d8a.IBMNM: Sending Bridge Parameters Set to 1000.5ade.0d8a on link 0.IBMNM: sending Bridge Params Changed Notification to 1000.5a79.dbf8 on link 1.IBMNM: Bridge 001-2-00A received Set REM Parameters from 1000.5ade.0d8a.IBMNM: Sending REM Parameters Set to 1000.5ade.0d8a on link 0.IBMNM: sending REM Parameters Changed Notification to 1000.5a79.dbf8 on link 1.IBMNM: Bridge 001-2-00A received Set REM Parameters from 1000.5ade.0d8a.IBMNM: Sending REM Parameters Set to 1000.5ade.0d8a on link 0.IBMNM: sending REM Parameters Changed Notification to 1000.5a79.dbf8 on link 1.IBMNM: Received LRM Set Reporting Point frame from 1000.5ade.0d8a.IBMNM: found bridge: 001-1-00A, addresses: 0000.3080.2d79 4000.3080.2d7As the output indicates, the debug lnm llc command output can vary somewhat in format.
Table 211 describes the significant fields shown in the display.
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.a630The following message indicates that the connection is being opened:
IBMNM: Opening connection to 1000.5ade.0d8a on TokenRing0The 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 LNMThe 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.debug lnm mac
To display all management communication between the router/bridge and all stations on the local Token Rings, use the debug lnm mac command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug lnm mac
no debug lnm mac
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
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 macLANMGR0: RS received request address from 4000.3040.a670.LANMGR0: RS sending report address to 4000.3040.a670.LANMGR0: RS received request state from 4000.3040.a670.LANMGR0: RS sending report state to 4000.3040.a670.LANMGR0: RS received request attachments from 4000.3040.a670.LANMGR0: RS sending report attachments to 4000.3040.a670.LANMGR2: RS received ring purge from 0000.3040.a630.LANMGR2: CRS received report NAUN change from 0000.3040.a630.LANMGR2: RS start watching ring poll.LANMGR0: CRS received report NAUN change from 0000.3040.a630.LANMGR0: RS start watching ring poll.LANMGR2: REM received report soft error from 0000.3040.a630.LANMGR0: REM received report soft error from 0000.3040.a630.LANMGR2: RS received ring purge from 0000.3040.a630.LANMGR2: RS received AMP from 0000.3040.a630.LANMGR2: RS received SMP from 0000.3080.2d79.LANMGR2: CRS received report NAUN change from 1000.5ade.0d8a.LANMGR2: RS start watching ring poll.LANMGR0: RS received ring purge from 0000.3040.a630.LANMGR0: RS received AMP from 0000.3040.a630.LANMGR0: RS received SMP from 0000.3080.2d79.LANMGR0: CRS received report NAUN change from 1000.5ade.0d8a.LANMGR0: RS start watching ring poll.LANMGR2: RS received SMP from 1000.5ade.0d8a.LANMGR2: RPS received request initialization from 1000.5ade.0d8a.LANMGR2: RPS sending initialize station to 1000.5ade.0d8a.Table 212 describes the significant fields shown in the display.
As the output indicates, all debug lnm mac command messages follow the format described in Table 212 except the following:
LANMGR2: RS start watching ring pollLANMGR2: RS stop watching ring pollThese 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.
debug local-ack state
To display the new and the old state conditions whenever there is a state change in the local acknowledgment state machine, use the debug local-ack state command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug local-ack state
no debug local-ack state
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Examples
The following is sample output from the debug local-ack state command:
Router# debug local-ack stateLACK_STATE: 2370300, hashp 2AE628, old state = disconn, new state = awaitingLLC2 open to finishLACK_STATE: 2370304, hashp 2AE628, old state = awaiting LLC2 open to finish,new state = connectedLACK_STATE: 2373816, hashp 2AE628, old state = connected, new state = disconnectedLACK_STATE: 2489548, hashp 2AE628, old state = disconn, new state = awaitingLLC2 open to finishLACK_STATE: 2489548, hashp 2AE628, old state = awaiting LLC2 open to finish,new state = connectedLACK_STATE: 2490132, hashp 2AE628, old state = connected, new state = awaitinglinkdown responseLACK_STATE: 2490140, hashp 2AE628, old state = awaiting linkdown response,new state = disconnectedLACK_STATE: 2497640, hashp 2AE628, old state = disconn, new state = awaitingLLC2 open to finishLACK_STATE: 2497644, hashp 2AE628, old state = awaiting LLC2 open to finish,new state = connectedTable 213 describes the significant fields shown in the display.
