-
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 189 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 190 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 191 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:
Route# 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 192 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 193 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 194 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 195 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 196 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 197 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 198 describes significant fields of call setup events for a successful callback for the sample output from the debug isdn event command when the dialer profiles DDR feature is configured.
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 199 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 200 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 201 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 202 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 203 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 204 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,
