Table Of Contents

debug ipv6 cef drop

debug ipv6 cef events

debug ipv6 cef hash

debug ipv6 cef receive

debug ipv6 cef table

debug ipv6 icmp

debug ipv6 nat

debug ipv6 nd

debug ipv6 ospf

debug ipv6 ospf events

debug ipv6 ospf lsdb

debug ipv6 ospf packet

debug ipv6 ospf spf statistic

debug ipv6 packet

debug ipv6 pool

debug ipv6 rip

debug ipv6 routing

debug ip wccp events

debug ip wccp packets

debug ipx ipxwan

debug ipx nasi

debug ipx packet

debug ipx routing

debug ipx sap

debug ipx spoof

debug ipx spx

debug isdn

debug isdn event

debug isdn q921

debug isdn q931

debug isdn tgrm

debug isis adj packets

debug isis authentication

debug isis mpls traffic-eng advertisements

debug isis mpls traffic-eng events

debug isis spf-events

debug isis spf statistics

debug isis update-packets

debug iua as

debug iua asp

debug kerberos

debug kron

debug l2relay events

debug l2relay packets

debug ipv6 cef drop

To display debugging messages for Cisco Express Forwarding for IPv6 (CEFv6) and distributed CEFv6 (dCEFv6) dropped packets, use the debug ipv6 cef drop command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug ipv6 cef drop

no debug ipv6 cef drop

Syntax Description

This command has no arguments or keywords.

Defaults

Debugging for CEFv6 and dCEFv6 dropped packets is not enabled.

Command Modes

Privileged EXEC

Command History

Release	Modification
12.0(22)S	This command was introduced.
12.2(13)T	This command was integrated into Cisco IOS Release 12.2(13)T.

Usage Guidelines

The debug ipv6 cef drop command is similar to the debug ip cef drop command, except that it is IPv6-specific.

---

Note By default, the network server sends the output from debug commands and system error messages to the console. To redirect debugging output, use the logging command options in global configuration mode. Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog server.

---

Examples

The following is sample output from the debug ipv6 cef drop command:

Router# debug ipv6 cef drop

*Aug 30 08:20:51.169: IPv6-CEF: received packet on Serial6/0/2

*Aug 30 08:20:51.169: IPv6-CEF: found no adjacency for 6001::1 reason 2

*Aug 30 08:20:51.169: IPv6-CEF: packet not switched: code 0x1

Table 135 describes the significant fields shown in the display.

Table 135 debug ipv6 cef drop Field Descriptions

Field	Description
IPv6-CEF: received packet on Serial6/0/2	CEF has received a packet addressed to the router via serial interface 6/0/2.
IPv6-CEF: found no adjacency for 6001::1	CEF has found no adjacency for the IPv6 address prefix of 6000::1.
IPv6-CEF: packet not switched	CEF has dropped the packet.

Related Commands

Command	Description
debug ipv6 cef events	Displays debugging messages for CEFv6 and dCEFv6 general events.
debug ipv6 cef table	Displays debugging messages for CEFv6 and dCEFv6 table modification events.

debug ipv6 cef events

To display debugging messages for Cisco Express Forwarding for IPv6 (CEFv6) and distributed CEFv6 (dCEFv6) general events, use the debug ipv6 cef events command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug ipv6 cef events

no debug ipv6 cef events

Syntax Description

This command has no arguments or keywords.

Defaults

Debugging for CEFv6 and dCEFv6 general events is not enabled.

Command Modes

Privileged EXEC

Command History

Release	Modification
12.0(22)S	This command was introduced.
12.2(13)T	This command was integrated into Cisco IOS Release 12.2(13)T.

Usage Guidelines

The debug ipv6 cef events command is similar to the debug ip cef events command, except that it is IPv6-specific.

---

Note By default, the network server sends the output from debug commands and system error messages to the console. To redirect debugging output, use the logging command options in global configuration mode. Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog server.

---

Examples

The following is sample output from the debug ipv6 cef events command:

Router# debug ipv6 cef events

IPv6 CEF packet events debugging is on

Router#

*Aug 30 08:22:57.809: %LINK-3-UPDOWN: Interface Serial6/0/2, changed state to up

*Aug 30 08:22:58.809: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial6/0/2, changed

state to up

*Aug 30 08:23:00.821: CEFv6-IDB: Serial6/0/2 address 4000::248 add download succeeded

Table 136 describes the significant fields shown in the display.

Table 136 debug ipv6 cef events Field Descriptions

Field	Description
Interface Serial6/0/2, changed state to up	Indicates that the interface hardware on serial interface 6/0/2 is currently active.
Line protocol on Interface Serial6/0/2, changed state to up	Indicates that the software processes that handle the line protocol consider the line usable for serial interface 6/0/2.
Serial6/0/2 address 4000::248 add download succeeded	The IPv6 address 4000::248 was downloaded successfully.

Related Commands

Command	Description
debug ipv6 cef table	Displays debugging messages for CEFv6 and dCEFv6 table modification events.

debug ipv6 cef hash

To display debugging messages for Cisco Express Forwarding CEF for IPv6 (CEFv6) and distributed CEFv6 (dCEFv6) load-sharing hash algorithm events, use the debug ipv6 cef hash command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug ipv6 cef hash

no debug ipv6 cef hash

Syntax Description

This command has no arguments or keywords.

Defaults

Debugging for CEFv6 and dCEFv6 load-sharing hash algorithm events is not enabled.

Command Modes

Privileged EXEC

Command History

Release	Modification
12.0(22)S	This command was introduced.
12.2(13)T	This command was integrated into Cisco IOS Release 12.2(13)T.

Usage Guidelines

The debug ipv6 cef hash command is similar to the debug ip cef hash command, except that it is IPv6-specific.

Use this command when changing the load-sharing algorithm to display IPv6 hash table details.

---

Note By default, the network server sends the output from debug commands and system error messages to the console. To redirect debugging output, use the logging command options in global configuration mode. Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog server.

---

Related Commands

Command	Description
debug ipv6 cef events	Displays debugging messages for CEFv6 and dCEFv6 general events.
debug ipv6 cef table	Displays debugging messages for CEFv6 and dCEFv6 table modification events.

debug ipv6 cef receive

To display debugging messages for Cisco Express Forwarding CEF for IPv6 (CEFv6) and distributed CEFv6 (dCEFv6) packets that are process-switched on the router, use the debug ipv6 cef receive command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug ipv6 cef receive

no debug ipv6 cef receive

Syntax Description

This command has no arguments or keywords.

Defaults

Debugging for CEFv6 and dCEFv6 packets that are process-switched on the router is not enabled.

Command Modes

Privileged EXEC

Command History

Release	Modification
12.0(22)S	This command was introduced.
12.2(13)T	This command was integrated into Cisco IOS Release 12.2(13)T.

Usage Guidelines

The debug ipv6 cef receive command is similar to the debug ip cef receive command, except that it is IPv6-specific.

---

Note By default, the network server sends the output from debug commands and system error messages to the console. To redirect debugging output, use the logging command options in global configuration mode. Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog server.

---

Examples

The following is sample output from the debug ipv6 cef receive command when another router in the network pings 4000::2, which is a local address on this box:

Router# debug ipv6 cef receive

IPv6 CEF packet receives debugging is on

router#

*Aug 30 08:25:14.869: IPv6CEF-receive: Receive packet for 4000::2

*Aug 30 08:25:14.897: IPv6CEF-receive: Receive packet for 4000::2

*Aug 30 08:25:14.925: IPv6CEF-receive: Receive packet for 4000::2

*Aug 30 08:25:14.953: IPv6CEF-receive: Receive packet for 4000::2

*Aug 30 08:25:14.981: IPv6CEF-receive: Receive packet for 4000::2

Table 137 describes the significant fields shown in the display.

Table 137 debug ipv6 cef receive Field Descriptions

Field	Description
IPv6CEF-receive: Receive packet for 4000::2	CEF has received a packet addressed to the router.

Related Commands

Command	Description
debug ipv6 cef events	Displays debugging messages for CEFv6 and dCEFv6 general events.
debug ipv6 cef table	Displays debugging messages for CEFv6 and dCEFv6 table modification events.

debug ipv6 cef table

To display debugging messages for Cisco Express Forwarding for IPv6 (CEFv6) and distributed CEFv6 (dCEFv6) table modification events, use the debug ipv6 cef table command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug ipv6 cef table [background]

no debug ipv6 cef table [background]

Syntax Description

background

(Optional) Sets CEFv6 and dCEFv6 table background updates.

Defaults

Debugging for CEFv6 and dCEFv6 table modification events is not enabled.

Command Modes

Privileged EXEC

Command History

Release	Modification
12.0(22)S	This command was introduced.
12.2(13)T	This command was integrated into Cisco IOS Release 12.2(13)T.

Usage Guidelines

The debug ipv6 cef table command is similar to the debug ip cef table command, except that it is IPv6-specific.

This command is used to record CEFv6 and dCEFv6 table events related to the Forwarding Information Base (FIB) tables. Types of events include the following:

•Routing updates that populate the FIB tables

•Flushing of the FIB tables

•Adding or removing of entries to the FIB tables

•Table reloading process

---

Note By default, the network server sends the output from debug commands and system error messages to the console. To redirect debugging output, use the logging command options in global configuration mode. Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog server.

---

Related Commands

Command	Description
debug ipv6 cef events	Displays debugging messages for CEFv6 and dCEFv6 general events.

debug ipv6 icmp

To display debugging messages for IPv6 Internet Control Message Protocol (ICMP) transactions (excluding IPv6 ICMP neighbor discovery transactions), use the debug ipv6 icmp command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug ipv6 icmp

no debug ipv6 icmp

Syntax Description

This command has no arguments or keywords.

Defaults

Debugging for IPv6 ICMP is not enabled.

Command Modes

Privileged EXEC

Command History

Release	Modification
12.2(2)T	This command was introduced.
12.0(21)ST	This command was integrated into Cisco IOS Release 12.0(21)ST.
12.0(22)S	This command was integrated into Cisco IOS Release 12.0(22)S.

Usage Guidelines

The debug ipv6 icmp command is similar to the debug ip icmp command, except that it is IPv6-specific.

---

Note By default, the network server sends the output from debug commands and system error messages to the console. To redirect debugging output, use the logging command options in global configuration mode. Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog server.

---

This command helps you determine whether the router is sending or receiving IPv6 ICMP messages. Use it, for example, when you are troubleshooting an end-to-end connection problem.

---

Note For more information about the fields in debug ipv6 icmp output, refer to RFC 2463, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6).

---

Examples

The following example shows output for the debug ipv6 icmp command:

Router# debug ipv6 icmp

13:28:40:ICMPv6:Received ICMPv6 packet from 2000:0:0:3::2, type 136

13:28:45:ICMPv6:Received ICMPv6 packet from FE80::203:A0FF:FED6:1400, type 135

13:28:50:ICMPv6:Received ICMPv6 packet from FE80::203:A0FF:FED6:1400, type 136

13:28:55:ICMPv6:Received ICMPv6 packet from FE80::203:A0FF:FED6:1400, type 135

Table 138 describes significant fields shown in the first line of the display.

Table 138 debug ipv6 icmp Field Descriptions 

Field	Description
13:28:40:	Indicates the time (hours:minutes:seconds) at which the ICMP neighbor discovery event occurred.
nwnd: (not shown in sample output)	Indicates time (weeks, days) since last reboot of the event occurring. For example, 1w4d: indicates the time (since the last reboot) of the event occurring was 1 week and 4 days ago.
ICMPv6:	Indication that this message describes an ICMP version 6 packet.
Received ICMPv6 packet from 2000:0:0:3::2	IPv6 address from which the ICMP version 6 packet is received.
type 136	The number variable indicates one of the following IPv6 ICMP message types: •1—Destination unreachable. The router cannot forward a packet that was sent or received. •2—Packet too big. The router attempts to send a packet that exceeds the maximum transmission unit (MTU) of a link between itself and the packet destination. •3—Time exceeded. Either the hop limit in transit or the fragment reassembly time is exceeded. •4—Parameter problem. The router attempts to send an IPv6 packet that contains invalid parameters. An example is a packet containing a next header type unsupported by the router that is forwarding the packet. •128—Echo request. The router received an echo reply. •129—Echo reply. The router sent an echo reply. •133—Router solicitation messages. Hosts send these messages to prompt routers on the local link to send router advertisement messages. •134—Router advertisement messages. Routers periodically send these messages to advertise their link-layer addresses, prefixes for the link, and other link-specific information. These messages are also sent in response to router solicitation messages. •135—Neighbor solicitation messages. Nodes send these messages to request the link-layer address of a station on the same link. •136—Neighbor advertisement messages. Nodes send these messages, containing their link-local addresses, in response to neighbor solicitation messages. •137—Redirect messages. Routers send these messages to hosts when a host attempts to use a less-than-optimal first hop address when forwarding packets. These messages contain a better first hop address that should be used instead.

Following are examples of the IPv6 ICMP messages types that can be displayed by the debug ipv6 icmp command:

•ICMP echo request and ICMP echo reply messages. In the following example, an ICMP echo request is sent to address 2052::50 and an ICMP echo reply is received from address 2052::50.

1w4d:ICMPv6:Sending echo request to 2052::50

1w4d:ICMPv6:Received echo reply from 2052::50

•ICMP packet too big messages. In the following example, a router tried to forward a packet to destination address 2052::50 via the next hop address 2052::52. The size of the packet was greater than 1280 bytes, which is the MTU of destination address 2052::50. As a result, the router receives an ICMP packet too big message from the next hop address 2052::52.

1w4d:Received ICMP too big from 2052::52 about 2052::50, MTU=1300

•ICMP parameter problem messages. In the following example, an ICMP parameter problem message is received from address 2052::52.

1w4d:Received ICMP parameter problem from 2052::52

•ICMP time exceeded messages. In the following example, an ICMP time exceeded message is received from address 2052::52.

1w4d:Received ICMP time exceeded from 2052::52

•ICMP unreachable messages. In the following example, an ICMP unreachable message with code 1 is received from address 2052::52. Additionally, an ICMP unreachable message with code 1 is sent to address 2060::20 about address 2062::20.

1w4d:Received ICMP unreachable code 1 from 2052::52

1w4d:Sending ICMP unreachable code 1 to 2060::20 about 2062::20

Table 139 lists the codes for ICMP unreachable messages.

Table 139 ICMP Unreachable Messages—Code Descriptions 

Code	Description
0	The router has no route to the packet destination.
1	Although the router has a route to the packet destination, communication is administratively prohibited.
3	The address is unreachable.
4	The port is unreachable.

Related Commands

Command	Description
debug ipv6 nd	Displays debugging messages for IPv6 ICMP neighbor discovery transactions.

debug ipv6 nat

To display debugging messages for Network Address Translation - Protocol Translation (NAT-PT) translation events, use the debug ipv6 nat command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug ipv6 nat [detailed]

no debug ipv6 nat [detailed]

Syntax Description

detailed

(Optional) Displays detailed information about NAT-PT translation events.

Defaults

Debugging for NAT-PT translation events is not enabled.

Command Modes

Privileged EXEC

Command History

Release	Modification
12.2(13)T	This command was introduced.

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 in global configuration mode. Destinations are the console, virtual terminals, internal buffer, and UNIX hosts running a syslog server.

---

---

Caution Because the debug ipv6 nat command generates a substantial amount of output, use it only when traffic on the IPv6 network is low, so other activity on the system is not adversely affected.

---

Examples

The following example shows output for the debug ipv6 nat command:

Router# debug ipv6 nat

00:06:06: IPv6 NAT: icmp src (3002::8) -> (192.168.124.8), dst (2001::2) ->

(192.168.123.2) 

00:06:06: IPv6 NAT: icmp src (192.168.123.2) -> (2001::2), dst (192.168.124.8) ->

(3002::8) 

00:06:06: IPv6 NAT: icmp src (3002::8) -> (192.168.124.8), dst (2001::2) ->

(192.168.123.2) 

00:06:06: IPv6 NAT: icmp src (192.168.123.2) -> (2001::2), dst (192.168.124.8) ->

(3002::8) 

00:06:06: IPv6 NAT: tcp src (3002::8) -> (192.168.124.8), dst (2001::2) -> (192.168.123.2) 

00:06:06: IPv6 NAT: tcp src (192.168.123.2) -> (2001::2), dst (192.168.124.8) -> (3002::8) 

00:06:06: IPv6 NAT: tcp src (3002::8) -> (192.168.124.8), dst (2001::2) -> (192.168.123.2) 

00:06:06: IPv6 NAT: tcp src (3002::8) -> (192.168.124.8), dst (2001::2) -> (192.168.123.2) 

00:06:06: IPv6 NAT: tcp src (3002::8) -> (192.168.124.8), dst (2001::2) -> (192.168.123.2) 

00:06:06: IPv6 NAT: tcp src (192.168.123.2) -> (2001::2), dst (192.168.124.8) -> (3002::8)

Table 140 describes the significant fields shown in the display.

Table 140 debug ipv6 nat Field Descriptions 

Field	Description
IPv6 NAT:	Indicates that this is a NAT-PT packet.
icmp	Protocol of the port identifying the packet.
src (3000::8) -> (192.168.124.8)	The source IPv6 address and the NAT-PT mapped IPv4 address. Note If you are mapping IPv4 hosts to IPv6 hosts, the first address would be an IPv4 address and the second address an IPv6 address.
dst (2001::2) -> (192.168.123.2)	The destination IPv6 address and the NAT-PT mapped IPv4 address. Note If you are mapping IPv4 hosts to IPv6 hosts, the first address would be an IPv4 address and the second address an IPv6 address.

The following example shows output for the debug ipv6 nat command with the detailed keyword:

Router# debug ipv6 nat detailed

00:14:12: IPv6 NAT: address allocated 192.168.124.8 

00:14:16: IPv6 NAT: deleted a NAT entry after timeout

debug ipv6 nd

To display debugging messages for IPv6 Internet Control Message Protocol (ICMP) neighbor discovery transactions, use the debug ipv6 nd command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug ipv6 nd

no debug ipv6 nd

Syntax Description

This command has no arguments or keywords.

Defaults

Debugging for IPv6 ICMP neighbor discovery is not enabled.

Command Modes

Privileged EXEC

Command History

Release	Modification
12.2(2)T	This command was introduced.
12.2(4)T	The DAD: <nnnn::nn:> is unique, DAD: duplicate link-local <nnnn::nn:> on <interface type>, interface stalled, and Received NA for <nnnn::nn:> on <interface type> from <nnnn::nn:> fields were added to the command output.
12.0(21)ST	This command was integrated into Cisco IOS Release 12.0(21)ST.
12.0(22)S	This command was integrated into Cisco IOS Release 12.0(22)S.

Usage Guidelines

This command can help determine whether the router is sending or receiving IPv6 ICMP neighbor discovery messages.

---

Note By default, the network server sends the output from debug commands and system error messages to the console. To redirect debugging output, use the logging command options in global configuration mode. Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog server.

---

Examples

The following example shows output for the debug ipv6 nd command:

Router# debug ipv6 nd

13:22:40:ICMPv6-ND:STALE -> DELAY:2000:0:0:3::2

13:22:45:ICMPv6-ND:DELAY -> PROBE:2000:0:0:3::2

13:22:45:ICMPv6-ND:Sending NS for 2000:0:0:3::2 on FastEthernet0/0

13:22:45:ICMPv6-ND:Received NA for 2000:0:0:3::2 on FastEthernet0/0 from 2000:0:0:3::2

13:22:45:ICMPv6-ND:PROBE -> REACH:2000:0:0:3::2

13:22:45:ICMPv6-ND:Received NS for 2000:0:0:3::1 on FastEthernet0/0 from

FE80::203:A0FF:FED6:1400

13:22:45:ICMPv6-ND:Sending NA for 2000:0:0:3::1 on FastEthernet0/0

13:23:15: ICMPv6-ND: Sending NS for FE80::1 on Ethernet0/1

13:23:16: ICMPv6-ND: DAD: FE80::1 is unique.

13:23:16: ICMPv6-ND: Sending NS for 2000::2 on Ethernet0/1

13:23:16: ICMPv6-ND: Sending NS for 3000::3 on Ethernet0/1

13:23:16: ICMPv6-ND: Sending NA for FE80::1 on Ethernet0/1

13:23:17: ICMPv6-ND: DAD: 2000::2 is unique.

13:23:53: ICMPv6-ND: Sending NA for 2000::2 on Ethernet0/1

13:23:53: ICMPv6-ND: DAD: 3000::3 is unique.

13:23:53: ICMPv6-ND: Sending NA for 3000::3 on Ethernet0/1

3d19h: ICMPv6-ND: Sending NS for FE80::2 on Ethernet0/2

3d19h: ICMPv6-ND: Received NA for FE80::2 on Ethernet0/2 from FE80::2

3d19h: ICMPv6-ND: DAD: duplicate link-local FE80::2 on Ethernet0/2,interface stalled

3d19h: %IPV6-4-DUPLICATE: Duplicate address FE80::2 on Ethernet0/2

3d19h: ICMPv6-ND: Sending NS for 3000::4 on Ethernet0/3

3d19h: ICMPv6-ND: Received NA for 3000::4 on Ethernet0/3 from 3000::4

3d19h: %IPV6-4-DUPLICATE: Duplicate address 3000::4 on Ethernet0/3

Table 141 describes the significant fields shown in the display.

Table 141 debug ipv6 nd Field Descriptions 

Field	Description
13:22:40:	Indicates the time (hours:minutes:seconds) at which the ICMP neighbor discovery event occurred.
ICMPv6-ND	Indicates that a state change is occurring for an entry in the IPv6 neighbors cache.
STALE	Stale state. This state of an neighbor discovery cache entry used to be "reachable," but now is "stale" because the entry is not being used. In order to use this address, the router must go through the neighbor discovery process in order to confirm reachability.
DELAY	Delayed state. Reachability for this ND cache entry is currently being reconfirmed. While in the delay state, upper-layer protocols may inform IPv6 that they have confirmed reachability to the entry. Therefore, there is no need to send a neighbor solicitation for the entry.
PROBE	Probe state. While in the probe state, if no confirmation is received from the upper-layer protocols about the reachability of the entry, a neighbor solicitation message is sent. The entry remains in the "probe" state until a neighbor advertisement message is received in response to the neighbor solicitation message.
Sending NS for...	Sending a neighbor solicitation message. In the example output, a neighbor solicitation message is sent on Fast Ethernet interface 0/0 to determine the link-layer address of 2000:0:0:3::2 on Fast Ethernet interface 0/0.
Received NA for...	Received a neighbor advertisement message. In the example output, a neighbor advertisement message is received from the address 2000:0:0:3::2 (the second address) that includes the link-layer address of 2000:0:0:3::2 (first address) from Ethernet interface 0/0.
REACH	Reachable state. An ND cache entry in this state is considered reachable, and the corresponding link-layer address can be used without needing to perform neighbor discovery on the address.
Received NS for...	Received neighbor solicitations. In the example output, the address FE80::203:A0FF:FED6:1400 (on Fast Ethernet interface 0/0) is trying to determine the link-local address of 2000:0:0:3::1.
Sending NA for...	Sending for neighbor advertisements. In the example output, a neighbor advertisement containing the link-layer address of 2000:0:0:3::1 (an address assigned to the Fast Ethernet interface 0/0 address) was sent.
DAD: FE80::1 is unique.	Duplicate address detection processing was performed on the unicast IPv6 address (a neighbor solicitation message was not received in response to a neighbor advertisement message that contained the unicast IPv6 address) and the address is unique.
3d19h:	Indicates time (days, hours) since the last reboot of the event occurring; 3d19h: indicates the time (since the last reboot) of the event occurring was 3 days and 19 hours ago.
DAD: duplicate link-local FE80::2 on Ethernet0/2, interface stalled	Duplicate address detection processing was performed on the link-local IPv6 address (the link-local address FE80::2 is used in the example). A neighbor advertisement message was received in response to a neighbor solicitation message that contained the link-local IPv6 address. The address is not unique, and the processing of IPv6 packets is disabled on the interface.
%IPV6-4-DUPLICATE: Duplicate address...	System error message indicating the duplicate address.
Received NA for 3000::4 on Ethernet0/3 from 3000::4	Duplicate address detection processing was performed on the global IPv6 address (the global address 3000::4 is used in the example). A neighbor advertisement message was received in response to a neighbor solicitation message that contained the global IPv6 address. The address is not unique and is not used.

Related Commands

Command	Description
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 | database-timer | flood | hello | lsa-generation | retransmission]

no debug ipv6 ospf [adj | database-timer | flood | hello | lsa-generation | retransmission]

Syntax Description

adj	(Optional) Displays adjacency information.
database-timer	(Optional) Displays database-timer information.
flood	(Optional) Displays flooding information.
hello	(Optional) Displays hello packet information.
lsa-generation	(Optional) Displays link-state advertisement (LSA) generation information for all LSA types.
retransmission	(Optional) Displays retransmission information.

Command Modes

Privileged EXEC

Command History

Release	Modification
12.0(24)S	This command was introduced.
12.2(15)T	This command was integrated into Cisco IOS Release 12.2(15)T.

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 adj

debug ipv6 ospf events

To display information on Open Shortest Path First (OSPF)-related events, such as designated router selection and shortest path first (SPF) calculation, use the debug ipv6 ospf events command in privileged EXEC mode. 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

Release	Modification
12.0(24)S	This command was introduced.
12.2(15)T	This command was integrated into Cisco IOS Release 12.2(15)T.

Usage Guidelines

Consult Cisco technical support before using this command.

Examples

The following example displays information on OSPF-related events:

Router# debug ipv6 ospf events

debug ipv6 ospf lsdb

To display database modifications for Open Shortest Path First (OSPF) for IPv6, use the debug ipv6 ospf lsdb command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug ipv6 ospf lsdb

no debug ipv6 ospf lsdb

Syntax Description

This command has no arguments or keywords.

Command Modes

Privileged EXEC

Command History

Release	Modification
12.0(24)S	This command was introduced.
12.2(15)T	This command was integrated into Cisco IOS Release 12.2(15)T.

Usage Guidelines

Consult Cisco technical support before using this command.

Examples

The following example displays database modification information for OSPF for IPv6:

Router# debug ipv6 ospf lsdb 

debug ipv6 ospf packet

To display information about each Open Shortest Path First (OSPF) for IPv6 packet received, use the debug ipv6 ospf packet command in privileged EXEC mode. To disable debugging output, use the no 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

Release	Modification
12.0(24)S	This command was introduced.
12.2(15)T	This command was integrated into Cisco IOS Release 12.2(15)T.

Usage Guidelines

Consult Cisco technical support before using this command.

Examples

The following example displays information about each OSPF for IPv6 packet received:

Router# debug ipv6 ospf packet

debug ipv6 ospf spf statistic

To display statistical information while running the shortest path first (SPF) algorithm, use the debug ipv6 ospf spf statistic command in privileged EXEC mode. To disable 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

Release	Modification
12.0(24)S	This command was introduced.
12.2(15)T	This command was integrated into Cisco IOS Release 12.2(15)T.

Usage Guidelines

The debug ipv6 ospf spf statistic command displays the SPF calculation times in milliseconds, the node count, and a time stamp. Consult Cisco technical support before using this command.

Examples

The following example displays statistical information while running the SPF algorithm:

Router# debug ipv6 ospf spf statistics

Related Commands

Command	Description
debug ipv6 ospf	Displays debugging information for the OSPF for IPv6 feature.
debug ipv6 ospf events	Displays information on OSPF-related events.
debug ipv6 ospf packet	Displays information about each OSPF packet received.

debug ipv6 packet

To display debugging messages for IPv6 packets, use the debug ipv6 packet command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug ipv6 packet [access-list access-list-name] [detail]

no debug ipv6 packet [access-list access-list-name] [detail]

Syntax Description

access-list access-list-name	(Optional) Specifies an IPv6 access list. The access list name cannot contain a space or quotation mark, or begin with a numeric.
detail	(Optional) Displays detailed information about a specified IPv6 access list.

Defaults

Debugging for IPv6 packets is not enabled.

Command Modes

Privileged EXEC

Command History

Release	Modification
12.2(2)T	This command was introduced.
12.0(21)ST	This command was integrated into Cisco IOS Release 12.0(21)ST.
12.0(22)S	This command was integrated into Cisco IOS Release 12.0(22)S.
12.0(23)S	The access-list and detail keywords, and the access-list-name argument, were added.

Usage Guidelines

The debug ipv6 packet command is similar to the debug ip packet command, except that it is IPv6-specific.

---

Note By default, the network server sends the output from debug commands and system error messages to the console. To redirect debugging output, use the logging command options in global configuration mode. Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog server.

---

IPv6 debugging information includes packets received, generated, and forwarded. Fast-switched packets do not generate messages. When an IPv6 access list is specified by using the access-list keyword and access-list-name argument, only packets matching the access list permit entries are displayed.

---

Caution Because the debug ipv6 packet command generates a substantial amount of output, use it only when traffic on the IPv6 network is low, so other activity on the system is not adversely affected.

---

Examples

The following example shows output for the debug ipv6 packet command:

Router# debug ipv6 packet

13:25:40:IPV6:source 2000:0:0:3::1 (local)

13:25:40:      dest 2000:0:0:3::2 (FastEthernet0/0)

13:25:40:      traffic class 96, flow 0x0, len 143+195, prot 6, hops 64, originating

13:25:40:IPv6:Sending on FastEthernet0/0

13:25:40:IPV6:source 2000:0:0:3::2 (FastEthernet0/0)

13:25:40:      dest 2000:0:0:3::1

13:25:40:      traffic class 96, flow 0x0, len 60+14, prot 6, hops 64, forward to ulp

13:25:45:IPV6:source FE80::203:E4FF:FE12:CC1D (local)

13:25:45:      dest FF02::9 (Ethernet1/1)

13:25:45:      traffic class 112, flow 0x0, len 72+1428, prot 17, hops 255, originating

13:25:45:IPv6:Sending on Ethernet1/1

13:25:45:IPV6:source FE80::203:E4FF:FE12:CC00 (local)

13:25:45:      dest 2000:0:0:3::2 (FastEthernet0/0)

13:25:45:      traffic class 112, flow 0x0, len 72+8, prot 58, hops 255, originating

13:25:45:IPv6:Sending on FastEthernet0/0

13:25:45:IPV6:source 2000:0:0:3::2 (FastEthernet0/0)

13:25:45:      dest FE80::203:E4FF:FE12:CC00

13:25:45:      traffic class 112, flow 0x0, len 64+14, prot 58, hops 255, forward to ulp

13:25:45:IPV6:source FE80::203:A0FF:FED6:1400 (FastEthernet0/0)

13:25:45:      dest 2000:0:0:3::1

13:25:45:      traffic class 112, flow 0x0, len 72+14, prot 58, hops 255, forward to ulp

Table 142 describes the significant fields shown in the display.

Table 142 debug ipv6 packet Field Descriptions 

Field	Description
IPV6:	Indicates that this is an IPv6 packet.
source 2000:0:0:3::1 (local)	The source address in the IPv6 header of the packet.
dest 2000:0:0:3::2 (FastEthernet0/0)	The destination address in the IPv6 header of the packet.
traffic class 96	The contents of the traffic class field in the IPv6 header.
flow 0x0	The contents of the flow field of the IPv6 header. The flow field is used to label sequences of packets for which special handling is necessary by IPv6 routers.
len 143+195	The length field of the IPv6 packet. The length is expressed as two numbers with a plus (+) character between the numbers. The second number is the length of the IPv6 portion (payload length plus IPv6 header length). The first number is the entire datagram size minus the second number.
prot 6	The protocol field in the IPv6 header. Describes the next layer protocol that is carried by the IPv6 packet. In the example, the protocol 58 signifies that the next layer protocol is ICMPv6.
hops 64	The hops field in the IPv6 packet. This field is similar in function to the IPv4 time-to-live field.
originating	The presence of this field indicates that the packet shown was originated by the router.
Sending on FastEthernet0/0	Specifies the interface on which the packet was sent.
forward to ulp	Indicates that the packet was received by the router at the destination address and was forwarded to an upper-layer address (ulp) for processing.

debug ipv6 pool

To enable debugging on IPv6 prefix pools, use the debug ipv6 pool command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug ipv6 pool

no debug ipv6 pool

Syntax Description

This command has no keywords or arguments.

Defaults

No debugging is active.

Command History

Release	Modification
12.2(13)T	This command was introduced.

Examples

The following example enables debugging for IPv6 prefix pools:

Router# debug ipv6 pool

2w4d: IPv6 Pool: Deleting route/prefix 2001:0DB8::/29 to Virtual-Access1 for cisco

2w4d: IPv6 Pool: Returning cached entry 2001:0DB8::/29 for cisco on Virtual-Access1 to 

pool1

2w4d: IPv6 Pool: Installed route/prefix 2001:0DB8::/29 to Virtual-Access1 for cisco

Related Commands

Command	Description
ipv6 local pool	Configures an IPv6 address and enables IPv6 processing on an interface using an EUI-64 interface ID in the low-order 64 bits of the address.
show ipv6 interface	Displays the usability status of interfaces configured for IPv6.
show ipv6 local pool	Displays information about defined IPv6 prefix pools.

debug ipv6 rip

To display debugging messages for IPv6 Routing Information Protocol (RIP) routing transactions, use the debug ipv6 rip command in privileged EXEC mode. To disable debugging output, 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 debugging messages.
interface-number	(Optional) The interface number about which to display debugging messages.

Defaults

IPv6 RIP debugging is not enabled.

Command Modes

Privileged EXEC

Command History

Release	Modification
12.2(2)T	This command was introduced.
12.0(21)ST	This command was integrated into Cisco IOS Release 12.0(21)ST.
12.0(22)S	This command was integrated into Cisco IOS Release 12.0(22)S.

Usage Guidelines

The debug ipv6 rip command is similar to the debug ip rip command, except that it is IPv6-specific.

---

Note By default, the network server sends the output from debug commands and system error messages to the console. To redirect debugging output, use the logging command options in global configuration mode. Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog server.

---

Using this command without arguments enables IPv6 RIP debugging for RIP packets that are sent and received on all router interfaces. Using this command with arguments enables IPv6 RIP debugging for RIP packets that are sent and received only on the specified interface.

---

Caution Using this command on busy networks seriously degrades the performance of the router.

---

Examples

The following example shows output for the debug ipv6 rip command:

Router# debug ipv6 rip

13:09:10:RIPng:Sending multicast update on Ethernet1/1 for as1_rip

13:09:10:       zrc=FE80::203:E4FF:FE12:CC1D

13:09:10:       dst=FF02::9 (Ethernet1/1)

13:09:10:       sport=521, dport=521, length=32

13:09:10:       command=2, version=1, mbz=0, #rte=1

13:09:10:       tag=0, metric=1, prefix=::/0

13:09:28:RIPng:response received from FE80::202:FDFF:FE77:1E42 on Ethernet1/1 for as1_rip

13:09:28:       zrc=FE80::202:FDFF:FE77:1E42 (Ethernet1/1)

13:09:28:       dst=FF02::9

13:09:28:       sport=521, dport=521, length=32

13:09:28:       command=2, version=1, mbz=0, #rte=1

13:09:28:       tag=0, metric=1, prefix=2000:0:0:1:1::/80

The example shows two RIP packets; both are updates, known as "responses" in RIP terminology and indicated by a "command" value of 2. The first is an update sent by this router, and the second is an update received by this router. Multicast update packets are sent to all neighboring IPv6 RIP routers (all routers that are on the same links as the router sending the update, and that have IPv6 RIP enabled). An IPv6 RIP router advertises the contents of its routing table to its neighbors by periodically sending update packets over those interfaces on which IPv6 RIP is configured. An IPv6 router may also send "triggered" updates immediately following a routing table change. In this case the updates only include 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 143 describes the significant fields shown in the display. The tag, metric, and prefix fields are specific to each RTE contained in the update.

Table 143 debug ipv6 rip Field Descriptions 

Field	Description
as1_rip	The name of the RIP process that is sending or receiving the update.
src	The address from which the update was originated.
dst	The destination address for the update.
sport, dport	The source and destination ports for the update. (IPv6 RIP uses port 521, as shown in the display.)
command	The command field within the RIP packet. A value of 2 indicates that the RIP packet is a response (update); a value of 1 indicates that the RIP packet is a request.
version	The version of IPv6 RIP being used. The current version is 1.
mbz	There must be a 0 (mbz) field within the RIP packet.
#rte	Indicates the number of routing table entries (RTEs) the RIP packet contains.
tag	Allows for the flagging of IPv6 RIP "internal" and "external" routes.
metric	The distance metric from the router (sending this update) to the prefix.
prefix	The tag, metric, and prefix fields are specific to each RTE contained in the update. The IPv6 prefix of the destination being advertised.

Related Commands

Command	Description
debug ipv6 routing	Displays debugging messages for IPv6 routing table updates and route cache updates.

debug ipv6 routing

To display debugging messages for IPv6 routing table updates and route cache updates, use the debug ipv6 routing command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug ipv6 routing

no debug ipv6 routing

Syntax Description

This command has no arguments or keywords.

Defaults

Debugging for IPv6 routing table updates and route cache updates is not enabled.

Command Modes

Privileged EXEC

Command History

Release	Modification
12.2(2)T	This command was introduced.
12.0(21)ST	This command was integrated into Cisco IOS Release 12.0(21)ST.
12.0(22)S	This command was integrated into Cisco IOS Release 12.0(22)S.

Usage Guidelines

The debug ipv6 routing command is similar to the debug ip routing command, except that it is IPv6-specific.

---

Note By default, the network server sends the output from debug commands and system error messages to the console. To redirect debugging output, use the logging command options in global configuration mode. Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog server.

---

Examples

The following example shows output for the debug ipv6 routing command:

Router# debug ipv6 routing

13:18:43:IPv6RT0:Add 2000:0:0:1:1::/80 to table

13:18:43:IPv6RT0:Better next-hop for 2000:0:0:1:1::/80, [120/2]

13:19:09:IPv6RT0:Add 2000:0:0:2::/64 to table

13:19:09:IPv6RT0:Better next-hop for 2000:0:0:2::/64, [20/1]

13:19:09:IPv6RT0:Add 2000:0:0:2:1::/80 to table

13: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 table

13: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 table

13: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 table

The following message indicates that the prefix 2000:0:0:2::/64 was already in the routing table; however, a received advertisement provided a lower cost path to the prefix. Therefore, the routing table was updated with the lower cost path. (The [20/1] in the example is the administrative distance [20] and metric [1] of the better path.)

13:19:09:IPv6RT0:Better next-hop for 2000:0:0:2::/64, [20/1]

Related Commands

Command	Description
debug ipv6 rip	Displays debugging messages for IPv6 RIP routing transactions.

debug ip wccp events

To display information about significant Web Cache Control Protocol (WCCP) events, use the debug ip wccp events command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug ip wccp events

no debug ip wccp events

Syntax Description

This command has no arguments or keywords.

Command Modes

Privileged EXEC

Examples

The following is sample output from the debug ip wccp events command when a Cisco Cache Engine is added to the list of available Web caches:

Router# debug ip wccp events

WCCP-EVNT: Built I_See_You msg body w/1 usable web caches, change # 0000000A

WCCP-EVNT: Web Cache 192.168.25.3 added

WCCP-EVNT: Built I_See_You msg body w/2 usable web caches, change # 0000000B

WCCP-EVNT: Built I_See_You msg body w/2 usable web caches, change # 0000000C

debug ip wccp packets

To display information about every Web Cache Control Protocol (WCCP) packet received or sent by the router, use the debug ip wccp packets command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug ip wccp packets

no debug ip wccp packets

Syntax Description

This command has no arguments or keywords.

Command Modes

Privileged EXEC

Examples

The following is sample output from the debug ip wccp packets command. The router is sending keepalive packets to the Cisco Cache Engines at 192.168.25.4 and 192.168.25.3. Each keepalive packet has an identification number associated with it. When the Cisco Cache Engine receives a keepalive packet from the router, it sends a reply with the identification number back to the router.

Router# debug ip wccp packets

WCCP-PKT: Received valid Here_I_Am packet from 192.168.25.4 w/rcvd_id 00003532

WCCP-PKT: Sending I_See_You packet to 192.168.25.4 w/ rcvd_id 00003534

WCCP-PKT: Received valid Here_I_Am packet from 192.168.25.3 w/rcvd_id 00003533

WCCP-PKT: Sending I_See_You packet to 192.168.25.3 w/ rcvd_id 00003535

WCCP-PKT: Received valid Here_I_Am packet from 192.168.25.4 w/rcvd_id 00003534

WCCP-PKT: Sending I_See_You packet to 192.168.25.4 w/ rcvd_id 00003536

WCCP-PKT: Received valid Here_I_Am packet from 192.168.25.3 w/rcvd_id 00003535

WCCP-PKT: Sending I_See_You packet to 192.168.25.3 w/ rcvd_id 00003537

WCCP-PKT: Received valid Here_I_Am packet from 192.168.25.4 w/rcvd_id 00003536

WCCP-PKT: Sending I_See_You packet to 192.168.25.4 w/ rcvd_id 00003538

WCCP-PKT: Received valid Here_I_Am packet from 192.168.25.3 w/rcvd_id 00003537

WCCP-PKT: Sending I_See_You packet to 192.168.25.3 w/ rcvd_id 00003539

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 up

IPXWAN: state (Disconnect -> Sending Timer Requests) [Serial1/6666:200 (IPX line

 state brought up)]

IPXWAN: state (Sending Timer Requests -> Disconnect) [Serial1/6666:200 (IPX line

 state brought down)]

IPXWAN: state (Disconnect -> Sending Timer Requests) [Serial1/6666:200 (IPX line

 state brought up)]

IPXWAN: Send TIMER_REQ [seq 0] out Serial1/6666:200

IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200

IPXWAN: Send TIMER_REQ [seq 2] out Serial1/6666:200

IPXWAN: Send TIMER_REQ [seq 0] out Serial1/6666:200

IPXWAN: Rcv TIMER_REQ on Serial1/6666:200, NodeID 1234, Seq 1

IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200

IPXWAN: Rcv TIMER_RSP on Serial1/6666:200, NodeID 1234, Seq 1, Del 6

IPXWAN: state (Sending Timer Requests -> Master: Sent RIP/SAP) [Serial1/6666:200

 (Received Timer Response as master)]

IPXWAN: Send RIPSAP_INFO_REQ [seq 0] out Serial1/6666:200

IPXWAN: Rcv RIPSAP_INFO_RSP from Serial1/6666:200, NodeID 1234, Seq 0

IPXWAN: state (Master: Sent RIP/SAP -> Master: Connect) [Serial1/6666:200 (Received Router

Info Rsp as Master)]

The following line indicates that the interface has initialized:

%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up

The following lines indicate that the startup process failed to receive a timer response, brought the link down, then brought the link up and tried again with a new timer set:

IPXWAN: state (Sending Timer Requests -> Disconnect) [Serial1/6666:200 (IPX line

 state brought down)]

IPXWAN: state (Disconnect -> Sending Timer Requests) [Serial1/6666:200 (IPX line

 state brought up)]

The following lines indicate that the interface is sending timer requests and waiting for a timer response:

IPXWAN: Send TIMER_REQ [seq 0] out Serial1/6666:200

IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200

The following lines indicate that the interface has received a timer request from the other end of the link and has sent a timer response. The fourth line shows that the interface has come up as the master on the link.

IPXWAN: Rcv TIMER_REQ on Serial1/6666:200, NodeID 1234, Seq 1

IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200

IPXWAN: Rcv TIMER_RSP on Serial1/6666:200, NodeID 1234, Seq 1, Del 6

IPXWAN: state (Sending Timer Requests -> Master: Sent RIP/SAP) [Serial1/6666:200

 (Received Timer Response as master)]

The following lines indicate that the interface is sending RIP/SAP requests:

IPXWAN: Send RIPSAP_INFO_REQ [seq 0] out Serial1/6666:200

IPXWAN: Rcv RIPSAP_INFO_RSP from Serial1/6666:200, NodeID 1234, Seq 0

IPXWAN: state (Master: Sent RIP/SAP -> Master: Connect) [Serial1/6666:200 (Received Router 
Info Rsp as Master)]

debug ipx nasi

To display information about the NetWare Asynchronous Services Interface (NASI) connections, use the debug ipx nasi command in privileged EXEC 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

packets	Displays normal operating messages relating to incoming and outgoing NASI packets. This is the default.
error	Displays messages indicating an error or failure in the protocol processing.
activity	Displays messages relating to internal NASI processing of NASI connections. The activity option includes all NASI activity such as traffic indication, timer events, and state changes.

Command Modes

Privileged EXEC

Usage Guidelines

Use the debug ipx nasi command to display handshaking or negotiating details between the protocol (SPX or NASI) and the other protocols or applications. Use the packets option to determine the NASI traffic flow, and use the error option as a quick check of failure reasons in NASI connections.

Examples

The following is sample output from the debug ipx nasi command using the packets and error keywords:

Router# debug ipx nasi packets

Router# debug ipx nasi error

NASI0: 6E6E Check server info

NASI0: 6E6E sending server-info 4F00   Good response: 43 bytes

NASI0: 7A6E Query Port. Find first

NASI0: FFirst: line 0 DE, port: TTY1-__________ASYNC___^, group: ASYNC___^

NASI0: 7A6E sending Qport find-first response: 300 bytes

NASI0: 7B6E port request. setting up port

NASI: Check-login User: c h r i s            

NASI: Check-login PW hash: C7 A6 C5 C7 C4 C0 C5 C3 C4 CC C5 CF C4 C8 C5 CB C4 D4 C5 D7 C4

D0 C5 D3 C4 

NASI: Check-login PW: l a b                       

NASI1: 7B6E sending NCS Good server Data Ack in 0 bytes pkt in 13 size pkt

NASI1: 7B6E sending Preq response: 303 bytes Good

NASI1: 7B6E port request. setting up port

NASI1: 7B6E sending NCS Good server Data Ack in 0 bytes pkt in 13 size pkt

NASI1: 7B6E sending Preq response: 303 bytes Good

NASI1: 7B6E Unknown NASI code 4500 Pkt Size: 13

 45 0 0 FC 0 2 0 20 0 0 FF 1 0

NASI1: 7B6E Flush Rx Buffers

NASI1: 7B6E sending NASI server TTY data: 1 byte in 14 size pkt

NASI1: 7B6E sending NCS Good server Data Ack in 1 bytes pkt in 13 size pkt

In the following line, the 0 is the number of the tty to which this NASI connection is attached. TTY 0 is used by all NASI control connections. 6E6E is the associated SPX connection pointer for this NASI connection. "Check server info" is a type of NASI packet that indicates an incoming NASI packet of this type.

NASI0: 6E6E Check server info

The following message indicates that the router is sending back a "server-info" packet with a positive acknowledgment, and the packet size is 43 bytes:

NASI0: 6E6E sending server-info 4F00   Good response: 43 bytes

The following line is a NASI packet type. "Find first" and "find next" are NASI packet types.

NASI0: 7A6E Query Port. Find first

The following line indicates that the outgoing find first packet for the NASI connection 7A6E has line 0 DE, port name TTY1, and general name ASYNC:

NASI0: FFirst: line 0 DE, port: TTY1-__________ASYNC___^, group: ASYNC___^

The following two lines indicate a received NASI packet for NASI connection on line 1. 7B6E is the NASI connection pointer. The packet code is 4500 and is not recognizable by Cisco devices. The second line is a hexadecimal dump of the packet.

NASI1: 7B6E Unknown NASI code 4500 Pkt Size: 13

 45 0 0 FC 0 2 0 20 0 0 FF 1 0

Related Commands

Command	Description
debug ipx spx	Displays debugging messages related to the SPX protocol.

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 In order to generate debug ipx packet information on all IPX traffic traveling over the router, you must first configure the router so that fast switching is disabled. Use the no ipx route-cache command on all interfaces on which you want to observe traffic. If the router is configured for IPX fast switching, only non fast-switched packets will produce output. When the IPX cache is invalidated or cleared, one packet for each destination is displayed as the cache is repopulated.

---

Examples

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

Router# debug ipx packet

IPX: zrc=160.0260.8c4c.4f22, dst=1.0000.0000.0001, packet received

IPX: zrc=160.0260.8c4c.4f22, dst=1.0000.0000.0001,gw=183.0000.0c01.5d85, 

sending packet

The first line indicates that the router receives a packet from a Novell station (address 160.0260.8c4c.4f22); this trace does not indicate the address of the immediate router sending the packet to this router. In the second line, the router forwards the packet toward the Novell server (address 1.0000.0000.0001) through an immediate router (183.0000.0c01.5d85).

Table 144 describes the significant fields shown in the display.

Table 144 debug ipx packet Field Descriptions 

Field	Description
IPX	Indicates that this is an IPX packet.
zrc=160.0260.8c4c.4f22	Source address of the IPX packet. The Novell network number is 160. Its MAC address is 0260.8c4c.4f22. Note The field "zrc" will appear as "src" in the output field.
dst=1.0000.0000.0001	Destination address for the IPX packet. The address 0000.0000.0001 is an internal MAC address, and the network number 1 is the internal network number of a Novell 3.11 server.
packet received	Router received this packet from a Novell station, possibly through an intermediate router.
gw=183.0000.0c01.5d85	Router is sending the packet over to the next hop router; its address of 183.0000.0c01.5d85 was learned from the IPX routing table.
sending packet	Router is attempting to send this packet.

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 routing

IPXRIP: update from 9999.0260.8c6a.1733

           110801 in 1 hops, delay 2

IPXRIP: sending update to 12FF02:ffff.ffff.ffff via Ethernet 1

           network 555, metric 2, delay 3

           network 1234, metric 3, delay 4

Table 145 describes the significant fields shown in the display.

Table 145 debug ipx routing Field Descriptions 

Field	Description
IPXRIP	IPX RIP packet.
update from 9999.0260.8c6a.1733	Routing update packet from an IPX server at address 9999.0260.8c6a.1733.
110801 in 1 hops	Network 110801 is one hop away from the router at address 9999.0260.8c6a.1733.
delay 2	Delay is a time measurement (1/18th second) that the NetWare shell uses to estimate how long to wait for a response from a file server. Also known as ticks.
sending update to 12FF02:ffff.ffff.ffff via Ethernet 1	Router is sending this IPX routing update packet to address 12FF02:ffff.ffff.ffff through Ethernet interface 1.
network 555	Packet includes routing update information for network 555.
metric 2	Network 555 is two metrics (or hops) away from the router.
delay 3	Network 555 is a delay of 3 away from the router. Delay is a measurement that the NetWare shell uses to estimate how long to wait for a response from a file server. Also known as ticks.

Related Commands

Command	Description
debug ipx sap	Displays information about IPX SAP packets.

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

activity	(Optional) Provides more detailed output of SAP packets, including displays of services in SAP packets.
events	(Optional) Limits amount of detailed output for SAP packets to those that contain interesting events.

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 Because the debug ipx sap command can generate a substantial amount of output, use it with caution on networks that have many interfaces and large service tables.

---

Examples

The following is sample output from the debug ipx sap command:

Router# debug ipx sap

IPXSAP: at 0023F778:

I SAP Response type 0x2 len 160 src:160.0000.0c00.070d dest:160.ffff.ffff.ffff(452)

 type 0x4, "Hello2", 199.0002.0004.0006 (451), 2 hops

 type 0x4, "Hello1", 199.0002.0004.0008 (451), 2 hops

IPXSAP: sending update to 160

IPXSAP: at 00169080:

 O SAP Update type 0x2 len 96 ssoc:0x452 dest:160.ffff.ffff.ffff(452)

IPX: type 0x4, "Magnolia", 42.0000.0000.0001 (451), 2hops

The debug ipx sap command generates multiple lines of output for each SAP 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 146 describes the significant fields shown in the display.

Table 146 debug ipx sap Field Descriptions 

Field	Description
I	Indicates whether the router received the SAP packet as input (I) or is sending an update as output (O).
SAP Response type 0x2	Packet type. Format is 0xn; possible values for n include: •1—General query •2—General response •3—Get Nearest Server request •4—Get Nearest Server response
len 160	Length of this packet (in bytes).
src: 160.000.0c00.070d	Source address of the packet.
dest:160.ffff.ffff.ffff	IPX network number and broadcast address of the destination IPX network for which the message is intended.
(452)	IPX socket number of the process sending the packet at the source address. This number is always 452, which is the socket number for the SAP process.
type 0x4	Indicates the type of service the server sending the packet provides. Format is 0xn. Some of the values for n are proprietary to Novell. Those values for n that have been published include the following (contact Novell for more information): •0—Unknown •1—User •2—User group •3—Print queue •4—File server •5—Job server •6—Gateway •7—Print server •8—Archive queue •9—Archive server •A—Job queue •B—Administration •21—NAS SNA gateway •24—Remote bridge server •2D—Time Synchronization VAP •2E—Dynamic SAP •47—Advertising print server •4B—Btrieve VAP 5.0 •4C—SQL VAP •7A—TES—NetWare for VMS •98—NetWare access server •9A—Named Pipes server •9E—Portable NetWare—UNIX •111—Test server •166—NetWare management •233—NetWare management agent •237—NetExplorer NLM •239—HMI hub •23A—NetWare LANalyzer agent •26A—NMS management •FFFF—Wildcard (any SAP service) Contact Novell for more information.
"Hello2"	Name of the server being advertised.
199.0002.0004.0006 (451)	Indicates the network number and address (and socket) of the server generating the SAP packet.
2 hops	Number of hops to the server from the router.

The fifth line of output indicates that the router sent a SAP update to network 160:

IPXSAP: sending update to 160

The format for debug ipx sap output describing a SAP update the router sends is similar to that describing a SAP update the router receives, except that the ssoc: field replaces the src: field, as the following line of output indicates:

	O SAP Update type 0x2 len 96 ssoc:0x452 dest:160.ffff.ffff.ffff(452)

The ssoc:0x452 field indicates the IPX socket number of the process sending the packet at the source address. Possible values include the following:

•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

Command	Description
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 spoof 

IPX: Tu1:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7004 4B8 8 1D

23 (new) (changed:yes) Last Changed 0

IPX: Tu1:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7104 2B8 7 29

2E (new) (changed:yes) Last Changed 0

IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: 80 0 2B8 7104 29 7 7

(early)

IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.da75 ln= 42 tc=02, SPX: 80 0 4B8 7004 1D 8 8

(early)

IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.da75 ln= 32 tc=02, watchdog

IPX: local:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 32 tc=00, watchdog snet

IPX: Tu1:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7004 4B8 8 1D

23 (changed:clear) Last Changed 0

IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: C0 0 2B8 7104 29 7 7

(early)

IPX: Tu1:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7104 2B8 7 29

2E (changed:clear) Last Changed 0

IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: C0 0 2B8 7104 29 7 7

(Last Changed 272 sec)

IPX: local:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, spx keepalive sent 80 0

7104 2B8 7 29 2E

The following lines show that SPX packets were seen, but they are not seen for a connection that exists in the SPX table:

IPX: Tu1:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7004 4B8 8 1D

23 (new) (changed:yes) Last Changed 0

IPX: Tu1:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7104 2B8 7 29

2E (new) (changed:yes) Last Changed 0

The following lines show SPX packets for connections that exist in the SPX table but that SPX idle time has not yet elapsed and spoofing has not started:

IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: 80 0 2B8 7104 29 7 7

(early)

IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.da75 ln= 42 tc=02, SPX: 80 0 4B8 7004 1D 8 8

(early)

The following lines show an IPX watchdog packet and the spoofed reply:

IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.da75 ln= 32 tc=02, watchdog

IPX: local:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 32 tc=00, watchdog sent

The following lines show SPX packets that arrived more than two minutes after spoofing started. This situation occurs when the other sides of the SPX table are cleared. When the table is cleared, the routing processes stop spoofing the connection, which allows SPX keepalives from the local side to travel to the remote side and repopulate the SPX table.

IPX: Tu1:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7004 4B8 8 1D

23 (changed:clear) Last Changed 0

IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: C0 0 2B8 7104 29 7 7

(early)

IPX: Tu1:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7104 2B8 7 29

2E (changed:clear) Last Changed 0

The following lines show that an SPX keepalive packet came in and was spoofed:

IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: C0 0 2B8 7104 29 7 7

(Last Changed 272 sec)

IPX: local:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, spx keepalive sent 80 0

7104 2B8 7 29 2E

debug ipx spx

To display debugging messages related to the Sequenced Packet Exchange (SPX) protocol, use the debug ipx spx command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug ipx spx

no debug ipx spx

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 spx

SPX: Sent an SPX packet

SPX: I Con Src/Dst 776E/20A0 d-strm 0 con-ctl 80

SPX: I Con Src/Dst 776E/20A0 d-strm FE con-ctl 40

SPX: C847C Connection close requested by peer

SPX: Sent an SPX packet

SPX: purge timer fired. Cleaning up C847C

SPX: purging spxcon C847C from conQ

SPX: returning inQ buffers

SPX: returning outQ buffers

SPX: returning unackedQ buffers

SPX: returning spxcon

SPX: I Con Src/Dst 786E/FFFF d-strm 0 con-ctl C0

SPX: new connection request for listening socket

SPX: Sent an SPX packet

SPX: I Con Src/Dst 786E/20B0 d-strm 0 con-ctl 40

SPX: 300 bytes data recvd

SPX: Sent an SPX packet

The following line indicates an incoming SPX packet that has a source connection ID of 776E and a destination connection ID of 20A0 (both in hexadecimal). The data stream value in the SPX packet is indicated by d-strm, and the connection control value in the SPX packet is indicated by con-ctl (both in hexadecimal). All data packets received are followed by an SPX debugging message indicating the size of the packet. All control packets received are consumed internally.

SPX: I Con Src/Dst 776E/20A0 d-strm 0 con-ctl 80

The following lines indicate that SPX is attempting to remove an SPX connection that has the address C847C from its list of connections:

SPX: purge timer fired. Cleaning up C847C

SPX: purging spxcon C847C from conQ

Related Commands

Command	Description
debug ipx nasi	Displays information about the NASI connections.

debug isdn

To display messages about what is occurring in the structure and operation of ISDN in the Cisco IOS software, use the debug isdn commands in privileged EXEC mode. To disable the ISDN debugging commands, use the no form of this command.

debug isdn {all [interface bri number | serial port:number] | api [interface bri number | serial port:number] | cc [{detail | interface bri number | serial port:number}] | error [{interface bri number | serial port:number}] | event | mgmnt [{detail | interface bri number | serial port:number}] | q921 | q931 | standard [{interface bri number | serial port:number}] | tgrm}

no debug isdn {all [interface bri number | serial port:number] | api [interface bri number | serial port:number] | cc [{detail | interface bri number | serial port:number}] | error [{interface bri number | serial port:number}] | event | mgmnt [{detail | interface bri number | serial port:number}] | q921 | q931 | standard [{interface bri number | serial port:number}] | tgrm}

---

Note With the exception of the debug isdn event, debug isdn q921, debug isdn q931, and debug isdn tgrm commands, the commands described on this page are not intended for customer use and can cause ISDN or the Cisco IOS software to fail. The debug isdn event, debug isdn q921, debug isdn q931, and debug isdn tgrm commands are described on separate command pages.

---

Syntax Description

interface bri number	(Optional) BRI interface number (BRI 2, for example).
serial port:number	(Optional) Serial port and number (serial 1/0, for example).
detail	(Optional) Generates more information during the processing of a specific request.
all	Enables all debug isdn commands on all interfaces or, optionally, on a specific interface.
api	Selectively enables the following application program interfaces (APIs) contained in ISDN, on all interfaces or, optionally, on a specific interface: •accept—ISDN call acceptance •all—All ISDN API tracing •bkhl—ISDN backhaul API tracing •cdapi—ISDN Call Distributor Application Programming Interface API tracing •csm—ISDN Compact Subscriber Module API tracing •l2sock—ISDN Layer 2 socket API tracing •nfas—Non-Facility Associated Signaling •packet—ISDN packet API tracing •qsig—ISDN PRI Q Signaling API tracing •rlm—Redundant Link Manager API tracing
cc	Enables ISDN Call Control debug messages on all interfaces or, optionally, on a specific interface. Call Control is a layer of processing within ISDN that is above the Q.931 protocol processing layer, but below the host and API layers.
error	Generates error messages for normal exception conditions in the software on all interfaces or, optionally, on a specific interface. The actual significance of the message can be determined only by a detailed examination of surrounding debug messages.
event	Displays ISDN events occurring on the user side of the ISDN interface. See the debug isdn event command page.
mgmnt	Enables ISDN Management Entity messages on all interfaces or, optionally, on a specific interface. Management Entity controls the activation and deactivation of Q.921 resources.
q921	Displays data link layer access procedures that are taking place at the router on the D channel LAPD of its ISDN interface. See the debug isdn q921 command page.
q931	Displays information about call setup and teardown of ISDN network connections between the local router and the network. See the debug isdn q931 command page.
standard	Enables a selected set of isdn debug messages on all interfaces or, optionally, on a specific interface, that should provide sufficient information to determine why a problem is occurring.
tgrm	Displays ISDN trunk group resource manager information. See the command page for debug isdn tgrm.

Defaults

Commands are enabled on all interfaces unless a specific interface is specified.

Command Modes

Privileged EXEC

Command History

Release	Modification
10.0	This command was introduced.
12.2 T	This command was enhanced with the all, api, cc, error, mgmnt, and standard keywords.

Usage Guidelines

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 what is occurring in the structure and operation of ISDN in the Cisco IOS software, ISDN messages, and ISDN signaling procedures. The message must be interpreted by Cisco technical personnel.

The following example shows a typical message for the debug isdn cc command:

*Mar  1 02:29:27.751: ISDN Se1/0:23 CC: CCPRI_Go: source id 0x300, call id 0x8008, event 
0x341 (pre-ccb recovery)

The following example enables a selected set of debug isdn messages that should provide sufficient information for Cisco technical personnel to determine why a problem is occurring on BRI interface 2:

Router# debug isdn standard interface bri 2

debug isdn event

To display ISDN events occurring on the user side (on the router) of the ISDN interface, use the debug isdn event command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug isdn event

no debug isdn event

Syntax Description

This command has no arguments or keywords.

Command Modes

Privileged EXEC

Usage Guidelines

Although the debug isdn event and the debug isdn q931 commands provide similar debug information, the information is displayed in a different format. If you want to see the information in both formats, enable both commands at the same time. The displays will be intermingled.

The ISDN events that can be displayed are Q.931 events (call setup and teardown of ISDN network connections).

Use the show dialer command to retrieve information about the status and configuration of the ISDN interface on the router.

Use the service timestamps debug datetime msec global configuration command to include the time with each message.

For more information on ISDN switch types, codes, and values, see Appendix B, "ISDN Switch Types, Codes, and Values."

Examples

The following is sample output from the debug isdn event command of call setup events for an outgoing call:

Router# debug isdn event

ISDN Event: Call to 415555121202

received HOST_PROCEEDING

 Channel ID i = 0x0101

 -------------------

 Channel ID i = 0x89

received HOST_CONNECT

 Channel ID i = 0x0101

ISDN Event: Connected to 415555121202 on B1 at 64 Kb/s

The following shows sample debug isdn event output of call setup events for an incoming call. The values used for internal purposes are unpacked information elements. The values that follow the ISDN specification are an interpretation of the unpacked information elements.

Router# debug isdn event

received HOST_INCOMING_CALL

 Bearer Capability i = 0x080010

 -------------------

 Channel ID i = 0x0101

 Calling Party Number i = 0x0000, `415555121202'

 IE out of order or end of `private' IEs --

 Bearer Capability i = 0x8890

 Channel ID i = 0x89

 Calling Party Number i = 0x0083, `415555121202'

ISDN Event: Received a call from 415555121202 on B1 at 64 Kb/s

ISDN Event: Accepting the call

received HOST_CONNECT

 Channel ID i = 0x0101

ISDN Event: Connected to 415555121202 on B1 at 64 Kb/s

The following is sample output from the debug isdn event command of call teardown events for a call that has been disconnected by the host side of the connection:

Router# debug isdn event

received HOST_DISCONNECT

ISDN Event: Call to 415555121202 was hung up

The following is sample output from the debug isdn event command of a call teardown event for an outgoing or incoming call that has been disconnected by the ISDN interface on the router side:

Router# debug isdn event

ISDN Event: Hangup call to call id 0x8008

Table 147 describes the significant fields shown in the display.

Table 147 debug isdn event Field Descriptions 

Field	Description
Bearer Capability	Indicates the requested bearer service to be provided by the network. See Table B-4 in Appendix B, "ISDN Switch Types, Codes, and Values."
i=	Indicates the information element identifier. The value depends on the field it is associated with. Refer to the ITU-T Q.931 specification for details about the possible values associated with each field for which this identifier is relevant.
Channel ID	Channel Identifier. The values and corresponding channels might be identified in several ways: •Channel ID i=0x0101—Channel B1 •Channel ID i=0x0102—Channel B2 ITU-T Q.931 defines the values and channels as exclusive or preferred: •Channel ID i=0x83—Any B channel •Channel ID i=0x89—Channel B1 (exclusive) •Channel ID i=0x8A—Channel B2 (exclusive) •Channel ID i=0x81—B1 (preferred) •Channel ID i=0x82—B2 (preferred)
Calling Party Number	Identifies the called party. This field is only present in outgoing calls. The Calling Party Number field uses the IA5 character set. Note that it may be replaced by the Keypad facility field.
IE out of order or end of `private' IEs	Indicates that an information element identifier is out of order or there are no more private network information element identifiers to interpret.
Received a call from 415555121202 on B1 at 64 Kb/s	Identifies the origin of the call. This field is present only in incoming calls. Note that the information about the incoming call includes the channel and speed. Whether the channel and speed are displayed depends on the network delivering the calling party number.

The following is sample output from the debug isdn event command of a call teardown event for a call that has passed call screening and then has been hung up by the ISDN interface on the far end side:

Router# debug isdn event

Jan  3 11:29:52.559: ISDN BR0: RX <-  DISCONNECT pd = 8  callref = 0x81

Jan  3 11:29:52.563:         Cause i = 0x8090 - Normal call clearing 

The following is sample output from the debug isdn event command of a call teardown event for a call that has not passed call screening and has been rejected by the ISDN interface on the router side:

Router# debug isdn event

Jan  3 11:32:03.263: ISDN BR0: RX <-  DISCONNECT pd = 8  callref = 0x85

Jan  3 11:32:03.267:         Cause i = 0x8095 - Call rejected

The following is sample output from the debug isdn event command of a call teardown event for an outgoing call that uses a dialer subaddress:

Router# debug isdn event

Jan  3 11:41:48.483: ISDN BR0: Event: Call to 61885:1212 at 64 Kb/s

Jan  3 11:41:48.495: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x04

Jan  3 11:41:48.495:         Bearer Capability i = 0x8890

Jan  3 11:41:48.499:         Channel ID i = 0x83

Jan  3 11:41:48.503:         Called Party Number i = 0x80, '61885'

Jan  3 11:41:48.507:         Called Party SubAddr i = 0x80, 'P1212'

Jan  3 11:41:48.571: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x84

Jan  3 11:41:48.575:         Channel ID i = 0x89

Jan  3 11:41:48.587: ISDN BR0: Event: incoming ces value = 1

Jan  3 11:41:48.587: ISDN BR0: received HOST_PROCEEDING

                        Channel ID i = 0x0101

Jan  3 11:41:48.591:    -------------------

                        Channel ID i = 0x89

Jan  3 11:41:48.731: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x84

Jan  3 11:41:48.743: ISDN BR0: Event: incoming ces value = 1

Jan  3 11:41:48.743: ISDN BR0: received HOST_CONNECT

                        Channel ID i = 0x0101

Jan  3 11:41:48.747:    -------------------

%LINK-3-UPDOWN: Interface BRI0:1 changed state to up

Jan  3 11:41:48.771: ISDN BR0: Event: Connected to 61885:1212 on B1 at 64 Kb/s

Jan  3 11:41:48.775: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x04

%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up

%ISDN-6-CONNECT: Interface BRI0:1 is now connected to 61885:1212 goodie

The output is similar to the output of debug isdn q931. Refer to the debug isdn q931 command for detailed field descriptions.

The following is sample output from the debug isdn event command of call setup events for a successful callback for legacy DDR:

Router# debug isdn event

BRI0:Caller id Callback server starting to spanky 81012345678902

: Callback timer expired

BRI0:beginning callback to spanky 81012345678902

BRI0: Attempting to dial 81012345678902

The following is sample output from the debug isdn event command for a callback that was unsuccessful because the router had no dialer map for the calling number:

Router# debug isdn event

BRI0:Caller id 81012345678902 callback - no matching map

Table 148 describes the significant fields shown in the display.

Table 148 debug isdn event Field Descriptions for Caller ID Callback and Legacy DDR

Field	Description
BRI0:Caller id Callback server starting to ...	Caller ID callback has started, plus host name and number called. The callback enable timer starts now.
: Callback timer expired	Callback timer has expired; callback can proceed.
BRI0:beginning callback to ... BRI0: Attempting to dial ...	Actions proceeding after the callback timer expired, plus host name and number called.

The following is sample output from the debug isdn event command for a callback that was successful when the dialer profiles DDR feature is configured:

*Mar  1 00:46:51.827: BR0:1:Caller id 81012345678901 matched to profile delorean

*Mar  1 00:46:51.827: Dialer1:Caller id Callback server starting to delorean 
81012345678901

*Mar  1 00:46:54.151: : Callback timer expired

*Mar  1 00:46:54.151: Dialer1:beginning callback to delorean 81012345678901

*Mar  1 00:46:54.155: Freeing callback to delorean 81012345678901

*Mar  1 00:46:54.155: BRI0: Dialing cause Callback return call

*Mar  1 00:46:54.155: BRI0: Attempting to dial 81012345678901

*Mar  1 00:46:54.503: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up

*Mar  1 00:46:54.523: %DIALER-6-BIND: Interface BRI0:2 bound to profile Dialer1

*Mar  1 00:46:55.139: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, changed 
state to up

*Mar  1 00:46:58.187: %ISDN-6-CONNECT: Interface BRI0:2 is now connected to 81012345678901 
delorean

Table 149 describes significant fields of call setup events for a successful callback for the sample output from the debug isdn event command when the dialer profiles DDR feature is configured.

Table 149 debug isdn event Field Descriptions for Caller ID Callback and Dialer Profiles 

Field	Description
BR0:1:Caller id ... matched to profile ...	Interface, channel number, caller ID that are matched, and the profile to bind to the interface.
: Callback timer expired	Callback timer has expired; callback can proceed.
Dialer1:beginning callback to...	Callback process is beginning to the specified number.
Freeing callback to...	Callback has been started to the specified number, and the number has been removed from the callback list.
BRI0: Dialing cause Callback return call BRI0: Attempting to dial	The reason for the call and the number being dialed.
%LINK-3-UPDOWN: Interface BRI0:2, changed state to up	Interface status: up.
%DIALER-6-BIND: Interface BRI0:2 bound to profile Dialer1	Profile bound to the interface.
%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, changed state to up	Line protocol status: up.
%ISDN-6-CONNECT: Interface BRI0:2 is now connected to ...	Interface is now connected to the specified host and number.

debug isdn q921

To display data link layer (Layer 2) access procedures that are taking place at the router on the D channel (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

no debug isdn q921

Syntax Description

This command has no arguments or keywords.

Command Modes

Privileged EXEC

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 sent over the B channels that is also part of the router's ISDN interface. The peers (data link layer entities and layer management entities on the routers) communicate with each other via an ISDN switch over the D channel.

---

Note The ISDN switch provides the network interface defined by Q.921. This debug command does not display data link layer access procedures taking place within the ISDN network (that is, procedures taking place on the network side of the ISDN connection). See Appendix B, "ISDN Switch Types, Codes, and Values," for a list of the supported ISDN switch types.

---

A router can be the calling or called party of the ISDN Q.921 data link layer access procedures. If the router is the calling party, the command displays information about an outgoing call. If the router is the called party, the command displays information about an incoming call and the keepalives.

The debug isdn q921 command can be used with the debug isdn event and the debug isdn q931 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 q921 command for an outgoing call:

Router# debug isdn q921

Jan  3 14:52:24.475: ISDN BR0: TX ->  INFOc sapi = 0  tei = 64  ns = 5  nr = 2

                              i = 0x08010705040288901801837006803631383835

Jan  3 14:52:24.503: ISDN BR0: RX <-  RRr sapi = 0  tei = 64  nr = 6

Jan  3 14:52:24.527: ISDN BR0: RX <-  INFOc sapi = 0  tei = 64  ns = 2  nr = 6

                              i = 0x08018702180189

Jan  3 14:52:24.535: ISDN BR0: TX ->  RRr sapi = 0  tei = 64  nr = 3

Jan  3 14:52:24.643: ISDN BR0: RX <-  INFOc sapi = 0  tei = 64  ns = 3  nr = 6

                              i = 0x08018707

Jan  3 14:52:24.655: ISDN BR0: TX ->  RRr sapi = 0  tei = 64  nr = 4

%LINK-3-UPDOWN: Interface BRI0:1, changed state to up

Jan  3 14:52:24.683: ISDN BR0: TX ->  INFOc sapi = 0  tei = 64  ns = 6  nr = 4

                              i = 0x0801070F

Jan  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 goodie

Jan  3 14:52:34.415: ISDN BR0: RX <-  RRp sapi = 0  tei = 64 nr = 7 

Jan  3 14:52:34.419: ISDN BR0: TX ->  RRf sapi = 0  tei = 64  nr = 4

In the following lines, the seventh and eighth most significant hexadecimal numbers indicate the type of message. 0x05 indicates a Call Setup message, 0x02 indicates a Call Proceeding message, 0x07 indicates a Call Connect message, and 0x0F indicates a Connect Ack message.

Jan  3 14:52:24.475: ISDN BR0: TX ->  INFOc sapi = 0  tei = 64  ns = 5  nr = 2

                              i = 0x08010705040288901801837006803631383835

Jan  3 14:52:24.527: ISDN BR0: RX <-  INFOc sapi = 0  tei = 64  ns = 2  nr = 6

                              i = 0x08018702180189

Jan  3 14:52:24.643: ISDN BR0: RX <-  INFOc sapi = 0  tei = 64  ns = 3  nr = 6

                              i = 0x08018707

Jan  3 14:52:24.683: ISDN BR0: TX ->  INFOc sapi = 0  tei = 64  ns = 6  nr = 4

                              i = 0x0801070F

The following is sample output from the debug isdn q921 command for a startup message on a DMS-100 switch:

Router# debug isdn q921

Jan  3 14:47:28.455: ISDN BR0: RX <-  IDCKRQ  ri = 0  ai = 127 0

Jan  3 14:47:30.171: ISDN BR0: TX ->  IDREQ  ri = 31815  ai = 127 

Jan  3 14:47:30.219: ISDN BR0: RX <-  IDASSN  ri = 31815  ai = 64 

Jan  3 14:47:30.223: ISDN BR0: TX ->  SABMEp sapi = 0  tei = 64

Jan  3 14:47:30.227: ISDN BR0: RX <-  IDCKRQ  ri = 0  ai = 127 

Jan  3 14:47:30.235: ISDN BR0: TX ->  IDCKRP  ri = 16568  ai = 64 

Jan  3 14:47:30.239: ISDN BR0: RX <-  UAf sapi = 0  tei = 64

Jan  3 14:47:30.247: ISDN BR0: TX ->  INFOc sapi = 0  tei = 64  ns = 0  nr = 0

                              i = 0x08007B3A03313233

Jan  3 14:47:30.267: ISDN BR0: RX <-  RRr sapi = 0  tei = 64  nr = 1

Jan  3 14:47:34.243: ISDN BR0: TX ->  INFOc sapi = 0  tei = 64  ns = 1  nr = 0

                              i = 0x08007B3A03313233

Jan  3 14:47:34.267: ISDN BR0: RX <-  RRr sapi = 0  tei = 64  nr = 2

Jan  3 14:47:43.815: ISDN BR0: RX <-  RRp sapi = 0  tei = 64 nr = 2 

Jan  3 14:47:43.819: ISDN BR0: TX ->  RRf sapi = 0  tei = 64  nr = 0

Jan  3 14:47:53.819: ISDN BR0: TX ->  RRp sapi = 0  tei = 64 nr = 0 

The first seven lines of this example indicate a Layer 2 link establishment.

The following lines indicate the message exchanges between the data link layer entity on the local router (user side) and the assignment source point (ASP) on the network side during the TEI assignment procedure. This assumes that the link is down and no TEI currently exists.

Jan  3 14:47:30.171: ISDN BR0: TX ->  IDREQ  ri = 31815  ai = 127 

Jan  3 14:47:30.219: ISDN BR0: RX <-  IDASSN  ri = 31815  ai = 64 

At 14:47:30.171, the local router data link layer entity sent an Identity Request message to the network data link layer entity to request a TEI value that can be used in subsequent communication between the peer data link layer entities. The request includes a randomly generated reference number (31815) to differentiate among user devices that request automatic TEI assignment and an action indicator of 127 to indicate that the ASP can assign any TEI value available. The ISDN user interface on the router uses automatic TEI assignment.

At 14:47:30.219, the network data link entity responds to the Identity Request message with an Identity Assigned message. The response includes the reference number (31815) previously sent in the request and TEI value (64) assigned by the ASP.

The following lines indicate the message exchanges between the layer management entity on the network and the layer management entity on the local router (user side) during the TEI check procedure:

Jan  3 14:47:30.227: ISDN BR0: RX <-  IDCKRQ  ri = 0  ai = 127 

Jan  3 14:47:30.235: ISDN BR0: TX ->  IDCKRP  ri = 16568  ai = 64 

At 14:47:30.227, the layer management entity on the network sends the Identity Check Request message to the layer management entity on the local router to check whether a TEI is in use. The message includes a reference number that is always 0 and the TEI value to check. In this case, an ai value of 127 indicates that all TEI values should be checked. At 14:47:30.227, the layer management entity on the local router responds with an Identity Check Response message indicating that TEI value 64 is currently in use.

The following lines indicate the messages exchanged between the data link layer entity on the local router (user side) and the data link layer on the network side to place the network side into modulo 128 multiple frame acknowledged operation. Note that the data link layer entity on the network side also can initiate the exchange.

Jan  3 14:47:30.223: ISDN BR0: TX ->  SABMEp sapi = 0  tei = 64

Jan  3 14:47:30.239: ISDN BR0: RX <-  UAf sapi = 0  tei = 64

At 14:47:30.223, the data link layer entity on the local router sends the SABME command with a SAPI of 0 (call control procedure) for TEI 64. At 14:47:30.239, the first opportunity, the data link layer entity on the network responds with a UA response. This response indicates acceptance of the command. The data link layer entity sending the SABME command may need to send it more than once before receiving a UA response.

The following lines indicate the status of the data link layer entities. Both are ready to receive I frames.

Jan  3 14:47:43.815: ISDN BR0: RX <-  RRp sapi = 0  tei = 64 nr = 2 

Jan  3 14:47:43.819: ISDN BR0: TX ->  RRf sapi = 0  tei = 64  nr = 0

These I-frames are typically exchanged every 10 seconds (T203 timer).

The following is sample output from the debug isdn q921 command for an incoming call. It is an incoming SETUP message that assumes that the Layer 2 link is already established to the other side.

Router# debug isdn q921

Jan  3 14:49:22.507: ISDN BR0: TX ->  RRp sapi = 0  tei = 64 nr = 0 

Jan  3 14:49:22.523: ISDN BR0: RX <-  RRf sapi = 0  tei = 64  nr = 2

Jan  3 14:49:32.527: ISDN BR0: TX ->  RRp sapi = 0  tei = 64 nr = 0 

Jan  3 14:49:32.543: ISDN BR0: RX <-  RRf sapi = 0  tei = 64  nr = 2

Jan  3 14:49:42.067: ISDN BR0: RX <-  RRp sapi = 0  tei = 64 nr = 2 

Jan  3 14:49:42.071: ISDN BR0: TX ->  RRf sapi = 0  tei = 64  nr = 0

Jan  3 14:49:47.307: ISDN BR0: RX <-  UI sapi = 0  tei = 127

                              i = 0x08011F05040288901801897006C13631383836

%LINK-3-UPDOWN: Interface BRI0:1, changed state to up

Jan  3 14:49:47.347: ISDN BR0: TX ->  INFOc sapi = 0  tei = 64  ns = 2  nr = 0

                              i = 0x08019F07180189

Jan  3 14:49:47.367: ISDN BR0: RX <-  RRr sapi = 0  tei = 64  nr = 3

Jan  3 14:49:47.383: ISDN BR0: RX <-  INFOc sapi = 0  tei = 64  ns = 0  nr = 3

                              i = 0x08011F0F180189

Jan  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 up

Table 150 describes the significant fields shown in the display.

Table 150 debug isdn q921 Field Descriptions 

Field	Description
Jan 3 14:49:47.391	Indicates the date and time at which the frame was sent from or received by the data link layer entity on the router. The time is maintained by an internal clock.
TX	Indicates that this frame is being sent from the ISDN interface on the local router (user side).
RX	Indicates that this frame is being received by the ISDN interface on the local router from the peer (network side).
IDREQ	Indicates the Identity Request message type sent from the local router to the network (ASP) during the automatic TEI assignment procedure. This message is sent in a UI command frame. The SAPI value for this message type is always 63 (indicating that it is a Layer 2 management procedure) but it is not displayed. The TEI value for this message type is 127 (indicating that it is a broadcast operation).
ri = 31815	Indicates the Reference number used to differentiate between user devices requesting TEI assignment. This value is a randomly generated number from 0 to 65535. The same ri value sent in the IDREQ message should be returned in the corresponding IDASSN message. Note that a Reference number of 0 indicates that the message is sent from the network side management layer entity and a reference number has not been generated.
ai = 127	Indicates the Action indicator used to request that the ASP assign any TEI value. It is always 127 for the broadcast TEI. Note that in some message types, such as IDREM, a specific TEI value is indicated.
IDREM	Indicates the Identity Remove message type sent from the ASP to the user side layer management entity during the TEI removal procedure. This message is sent in a UI command frame. The message includes a reference number that is always 0, because it is not responding to a request from the local router. The ASP sends the Identity Remove message twice to avoid message loss.
IDASSN	Indicates the Identity Assigned message type sent from the ISDN service provider on the network to the local router during the automatic TEI assignment procedure. This message is sent in a UI command frame. The SAPI value for this message type is always 63 (indicating that it is a Layer 2 management procedure). The TEI value for this message type is 127 (indicating it is a broadcast operation).
ai = 64	Indicates the TEI value automatically assigned by the ASP. This TEI value is used by data link layer entities on the local router in subsequent communication with the network. The valid values are in the range from 64 to 126.
SABME	Indicates the set asynchronous balanced mode extended command. This command places the recipient into modulo 128 multiple frame acknowledged operation. This command also indicates that all exception conditions have been cleared. The SABME command is sent once a second for N200 times (typically three times) until its acceptance is confirmed with a UA response. For a list and brief description of other commands and responses that can be exchanged between the data link layer entities on the local router and the network, see ITU-T Recommendation Q.921.
sapi = 0	Identifies the service access point at which the data link layer entity provides services to Layer 3 or to the management layer. A SAPI with the value 0 indicates it is a call control procedure. Note that the Layer 2 management procedures such as TEI assignment, TEI removal, and TEI checking, which are tracked with the debug isdn q921 command, do not display the corresponding SAPI value; it is implicit. If the SAPI value were displayed, it would be 63.
tei = 64	Indicates the TEI value automatically assigned by the ASP. This TEI value will be used by data link layer entities on the local router in subsequent communication with the network. The valid values are in the range from 64 to 126.
IDCKRQ	Indicates the Identity Check Request message type sent from the ISDN service provider on the network to the local router during the TEI check procedure. This message is sent in a UI command frame. The ri field is always 0. The ai field for this message contains either a specific TEI value for the local router to check or 127, which indicates that the local router should check all TEI values. For a list and brief description of other message types that can be exchanged between the local router and the ISDN service provider on the network, see Appendix B, "ISDN Switch Types, Codes, and Values."
IDCKRP	Indicates the Identity Check Response message type sent from the local router to the ISDN service provider on the network during the TEI check procedure. This message is sent in a UI command frame in response to the IDCKRQ message. The ri field is a randomly generated number from 0 to 65535. The ai field for this message contains the specific TEI value that has been checked.
UAf	Confirms that the network side has accepted the SABME command previously sent by the local router. The final bit is set to 1.
INFOc	Indicates that this is an Information command. It is used to transfer sequentially numbered frames containing information fields that are provided by Layer 3. The information is transferred across a data-link connection.
INFORMATION pd = 8 callref = (null)	Indicates the information fields provided by Layer 3. The information is sent one frame at a time. If multiple frames need to be sent, several Information commands are sent. The pd value is the protocol discriminator. The value 8 indicates it is call control information. The call reference number is always null for SPID information.
SPID information i = 0x343135393033383336363031	Indicates the SPID. The local router sends this information to the ISDN switch to indicate the services to which it subscribes. SPIDs are assigned by the service provider and are usually 10-digit telephone numbers followed by optional numbers. Currently, only the DMS-100 switch supports SPIDs, one for each B channel. If SPID information is sent to a switch type other than DMS-100, an error may be displayed in the debug information.
ns = 0	Indicates the send sequence number of sent I frames.
nr = 0	Indicates the expected send sequence number of the next received I frame. At time of transmission, this value should be equal to the value of ns. The value of nr is used to determine whether frames need to be re-sent for recovery.
RRr	Indicates the Receive Ready response for unacknowledged information transfer. The RRr is a response to an INFOc.
RRp	Indicates the Receive Ready command with the poll bit set. The data link layer entity on the user side uses the poll bit in the frame to solicit a response from the peer on the network side.
RRf	Indicates the Receive Ready response with the final bit set. The data link layer entity on the network side uses the final bit in the frame to indicate a response to the poll.
sapi	Indicates the service access point identifier. The SAPI is the point at which data link services are provided to a network layer or management entity. Currently, this field can have the value 0 (for call control procedure) or 63 (for Layer 2 management procedures).
tei	Indicates the terminal endpoint identifier (TEI) that has been assigned automatically by the assignment source point (ASP) (also called the layer management entity on the network side). The valid range is from 64 to 126. The value 127 indicates a broadcast.

debug isdn 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

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 called party of the ISDN Q.931 network connection call setup and tear- down 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.

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.

For more information on ISDN switch types, codes, and values, refer to Appendix B, "ISDN Switch Types, Codes, and Values."

Examples

The following is sample output from the debug isdn q931 command of a call setup procedure for an outgoing call:

Router# debug isdn q931

TX -> SETUP pd = 8 callref = 0x04

 Bearer Capability i = 0x8890

 Channel ID i = 0x83

 Called Party Number i = 0x80, `415555121202'

RX <- CALL_PROC pd = 8 callref = 0x84

 Channel ID i = 0x89

RX <- CONNECT pd = 8 callref = 0x84

TX -> CONNECT_ACK pd = 8 callref = 0x04....

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 q931

RX <- SETUP pd = 8 callref = 0x06

 Bearer Capability i = 0x8890

 Channel ID i = 0x89

 Calling Party Number i = 0x0083, `81012345678902'

TX -> CONNECT pd = 8 callref = 0x86

RX <- CONNECT_ACK pd = 8 callref = 0x06

The following is sample output from the debug isdn q931 command of a call teardown procedure from the network:

Router# debug isdn q931

RX <- DISCONNECT pd = 8 callref = 0x84

 Cause i = 0x8790

 Looking Shift to Codeset 6

 Codeset 6 IE 0x1 1 0x82 `10'

TX -> RELEASE pd = 8 callref = 0x04

 Cause i = 0x8090

RX <- RELEASE_COMP pd = 8 callref = 0x84

The following is sample output from the debug isdn q931 command of a call teardown procedure from the router:

Router# debug isdn q931

TX -> DISCONNECT pd = 8 callref = 0x05

 Cause i = 0x879081

RX <- RELEASE pd = 8 callref = 0x85

 Looking Shift to Codeset 6

 Codeset 6 IE 0x1 1 0x82 `10'

TX <- RELEASE_COMP pd = 8 callref = 0x05

Table 151 describes the significant fields shown in the display.

Table 151 debug isdn q931 Field Descriptions 

Field	Description
TX ->	Indicates that this message is being sent from the local router (user side) to the network side of the ISDN interface.
RX <-	Indicates that this message is being received by the user side of the ISDN interface from the network side.
SETUP	Indicates that the SETUP message type has been sent to initiate call establishment between peer network layers. This message can be sent from either the local router or the network.
pd	Indicates the protocol discriminator. The protocol discriminator distinguishes messages for call control over the user-network ISDN interface from other ITU-T-defined messages, including other Q.931 messages. The protocol discriminator is 8 for call control messages such as SETUP. For basic-1tr6, the protocol discriminator is 65.
callref	Indicates the call reference number in hexadecimal notation. The value of this field indicates the number of calls made from either the router (outgoing calls) or the network (incoming calls). Note that the originator of the SETUP message sets the high-order bit of the call reference number to 0. The destination of the connection sets the high-order bit to 1 in subsequent call control messages, such as the CONNECT message. For example, callref = 0x04 in the request becomes callref = 0x84 in the response.
Bearer Capability	Indicates the requested bearer service to be provided by the network. Refer to Table B-4 in Appendix B, "ISDN Switch Types, Codes, and Values," for detailed information about bearer capability values.
i =	Indicates the information element identifier. The value depends on the field it is associated with. Refer to the ITU-T Q.931 specification for details about the possible values associated with each field for which this identifier is relevant.
Channel ID	Indicates the channel identifier. The value 83 indicates any channel, 89 indicates the B1 channel, and 8A indicates the B2 channel. For more information about the Channel Identifier, refer to ITU-T Recommendation Q.931.
Called Party Number	Identifies the called party. This field is only present in outgoing SETUP messages. Note that it can be replaced by the Keypad facility field. This field uses the IA5 character set.
Calling Party Number	Identifies the origin of the call. This field is present only in incoming SETUP messages. This field uses the IA5 character set.
CALL_PROC	Indicates the CALL PROCEEDING message; the requested call setup has begun and no more call setup information will be accepted.
CONNECT	Indicates that the called user has accepted the call.
CONNECT_ACK	Indicates that the calling user acknowledges the called user's acceptance of the call.
DISCONNECT	Indicates either that the user side has requested the network to clear an end-to-end connection or that the network has cleared the end-to-end connection.
Cause	Indicates the cause of the disconnect. Refer to Table B-2 and Table B-3 in Appendix B, "ISDN Switch Types, Codes, and Values," for detailed information about DISCONNECT cause codes and RELEASE cause codes.
Looking Shift to Codeset 6	Indicates that the next information elements will be interpreted according to information element identifiers assigned in codeset 6. Codeset 6 means that the information elements are specific to the local network.
Codeset 6 IE 0x1 i = 0x82, `10'	Indicates charging information. This information is specific to the NTT switch type and may not be sent by other switch types.
RELEASE	Indicates that the sending equipment will release the channel and call reference. The recipient of this message should prepare to release the call reference and channel.
RELEASE_COMP	Indicates that the sending equipment has received a RELEASE message and has now released the call reference and channel.

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

This command is disabled by default.

Command Modes

Privileged EXEC

Command History

Release	Modification
12.2(11)T	This command was introduced.

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

A sample output of the debug isdn tgrm command is shown below.

The output shows that the channel used (bchan) is 1, service state is 0 (in-service), call_state is 2 (busy), "false busy" is 0, and DSL is 2. The output also shows that the B channel is 1, the channel is available, and the call state is transitioned from 0 (idle) to 2 (busy).

The last two lines of output shows that bchan is 1, call state is 1 (busy), call type is 2 (voice), and call direction is 1 (incoming).

00:26:31:ISDN:get_tgrm_avail_state:idb 0x64229380 bchan 1 service_state 0 call_state 2 
false busy 0x0 dsl 2

00:26:31:ISDN:update_tgrm_call_status:idb 0x64229380 bchan 1 availability state 1 call 
state(prev,new) (0,2), dsl 2

00:26:31:ISDN:Calling TGRM with tgrm_call_isdn_update:idb 0x64229380 bchan 1 call state 1 
call type 2 call dir 1

Table 152 provides an alphabetical listing of the fields shown in the debug isdn tgrm command output and a description of each field.

Table 152 debug isdn tgrm Field Descriptions 

Field	Description
availability state	Indicates whether the channel is available: 0 = Not available 1 = Available
bchan	Bearer channel used for this call.
call dir	Direction of the call: 0 = Incoming 1 = Outgoing
call_state	State of the call. It has different values depending on whether it is from ISDN perspective or TGRM perspective. When printed from get_tgrm_avail_state(), it is the state value from ISDN perspective: 0 = Idle 1 = Negotiate 2 = Busy 3 = Reserved 4 = Restart pending 5 = Maintenance pend 6 = Reassigned When printed from tgrm_call_isdn_update(), it is the state value from TGRM perspective: 0 = Idle 1 = Busy 2 = Pending 3 = Reject
call state (prev, new)	Indicates the state transition of the call. The state values are as shown in call_state from the ISDN perspective.
call type	Type of call: 0 = Invalid 1 = Data 2 = Voice 3 = Modem 4 = None
dsl	Internal interface identifier.
false busy	Bit map of all the channels on the interface indicating their soft busy status.
idb	Address of the interface descriptor block (IDB) for the interface.
service_state	Service state: 0 = In-service 1 = Maintenance 2 = Out of service

Related Commands

Command	Description
show trunk group	Displays the configuration of the trunk group.
translation-profile (voice service POTS)	Assigns a translation profile to the interface.
trunk-group (interface)	Assigns a trunk group to the interface.

debug isis adj packets

To display information on all adjacency-related activity such as hello packets sent and received and Intermediate System-to-Intermediate System (IS-IS) adjacencies going up and down, use the debug isis adj packets command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug isis adj packets [interface]

no debug isis adj packets [interface]

Syntax Description

interface

(Optional) Interface or subinterface name.

Command Modes

Privileged EXEC

Examples

The following is sample output from the debug isis adj packets command:

Router# debug isis adj packets

ISIS-Adj: Rec L1 IIH from 0000.0c00.40af (Ethernet0), cir type 3, cir id BBBB.BBBB.BBBB.01

ISIS-Adj: Rec L2 IIH from 0000.0c00.40af (Ethernet0), cir type 3, cir id BBBB.BBBB.BBBB.01

ISIS-Adj: Rec L1 IIH from 0000.0c00.0c36 (Ethernet1), cir type 3, cir id CCCC.CCCC.CCCC.03

ISIS-Adj: Area mismatch, level 1 IIH on Ethernet1

ISIS-Adj: Sending L1 IIH on Ethernet1

ISIS-Adj: Sending L2 IIH on Ethernet1

ISIS-Adj: Rec L2 IIH from 0000.0c00.0c36 (Ethernet1), cir type 3, cir id BBBB.BBBB.BBBB.03

The following line indicates that the router received an IS-IS hello packet (IIH) on Ethernet interface 0 from the Level 1 router (L1) at MAC address 0000.0c00.40af. The circuit type is the interface type: 1—Level 1 only; 2—Level 2 only; 3—Level 1/2.

The circuit ID is what the neighbor interprets as the designated router for the interface.

ISIS-Adj: Rec L1 IIH from 0000.0c00.40af (Ethernet0), cir type 3, cir id BBBB.BBBB.BBBB.01

The following line indicates that the router (configured as a Level 1 router) received on Ethernet interface 1 is an IS-IS hello packet from a Level 1 router in another area, thereby declaring an area mismatch:

ISIS-Adj: Area mismatch, level 1 IIH on Ethernet1

The following lines indicates that the router (configured as a Level 1/Level 2 router) sent on Ethernet interface 1 is a Level 1 IS-IS hello packet, and then a Level 2 IS-IS packet:

ISIS-Adj: Sending L1 IIH on Ethernet1

ISIS-Adj: Sending L2 IIH on Ethernet1

debug isis authentication

To enable debugging of Intermediate System-to-Intermediate System (IS-IS) authentication, use the debug isis authentication command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug isis authentication information

no debug isis authentication information

Syntax Description

information

Required keyword that specifies IS-IS authentication information.

Defaults

No default behavior or values.

Command Modes

Privileged EXEC

Command History

Release	Modification
12.0(21)ST	This command was introduced.
12.2(13)T	This command was implemented on Cisco IOS Release 12.2(13)T.

Examples

The following example displays output from the debug isis authentication command with the information keyword:

Router# debug isis authentication information

3d03h:ISIS-AuthInfo:No auth TLV found in received packet

3d03h:ISIS-AuthInfo:No auth TLV found in received packet

The sample output indicates that the router has been running for 3 days and 3 hours. Debugging output is about IS-IS authentication information. The local router is configured for authentication, but it received a packet that does not contain authentication data; the remote router does not have authentication configured.

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

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

Examples

In the following example, information about traffic engineering advertisements is printed in IS-IS LSA messages:

Router# debug isis mpls traffic-eng advertisements

System ID:Router1.00

  Router ID:10.106.0.6

  Link Count:1

    Link[1]

      Neighbor System ID:Router2.00 (P2P link)

      Interface IP address:10.42.0.6

      Neighbor IP Address:10.42.0.10

      Admin. Weight:10

      Physical BW:155520000 bits/sec

      Reservable BW:5000000 bits/sec

      BW unreserved[0]:2000000 bits/sec, BW unreserved[1]:100000 bits/sec

      BW unreserved[2]:100000 bits/sec, BW unreserved[3]:100000 bits/sec

      BW unreserved[4]:100000 bits/sec, BW unreserved[5]:100000 bits/sec

      BW unreserved[6]:100000 bits/sec, BW unreserved[7]:0 bits/sec

      Affinity Bits:0x00000000

Table 153 describes the significant fields shown in the display.

Table 153 debug isis mpls traffic-eng advertisements Field Descriptions 

Field	Description
System ID	Identification value for the local system in the area.
Router ID	Multiprotocol Label Switching traffic engineering router ID.
Link Count	Number of links that MPLS traffic engineering advertised.
Neighbor System ID	Identification value for the remote system in an area.
Interface IP address	IPv4 address of the interface.
Neighbor IP Address	IPv4 address of the neighbor.
Admin. Weight	Administrative weight associated with this link.
Physical BW	Bandwidth capacity of the link (in bits per second).
Reservable BW	Amount of reservable bandwidth on this link.
BW unreserved	Amount of bandwidth that is available for reservation.
Affinity Bits	Attribute flags of the link that are being flooded.

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

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

Examples

In the following example, information is printed about traffic engineering-related IS-IS events:

Router# debug isis mpls traffic-eng events

ISIS-RRR:Send MPLS TE Et4/0/1 Router1.02 adjacency down:address 0.0.0.0

ISIS-RRR:Found interface address 10.1.0.6 Router1.02, building subtlv... 58 bytes

ISIS-RRR:Found interface address 10.42.0.6 Router2.00, building subtlv... 64 bytes

ISIS-RRR:Interface address 0.0.0.0 Router1.00 not found, not building subtlv

ISIS-RRR:LSP Router1.02 changed from 0x606BCD30

ISIS-RRR:Mark LSP Router1.02 changed because TLV contents different, code 16

ISIS-RRR:Received 1 MPLS TE links flood info for system id Router1.00

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

Release	Modification
12.0	This command was introduced.
12.2(15)T	This command was integrated into Cisco IOS Release 12.2(15)T. Support for IPv6 was added.

Usage Guidelines

This command displays information about significant events that occur during SPF-related processing.

Examples

The following example displays significant events during an IS-IS SPF computation:

Router# debug isis spf-events

ISIS-Spf:  Compute L2 IPv6 SPT

ISIS-Spf: Move 0000.0000.1111.00-00 to PATHS, metric 0

ISIS-Spf: Add 0000.0000.2222.01-00 to TENT, metric 10

ISIS-Spf: Move 0000.0000.2222.01-00 to PATHS, metric 10

ISIS-Spf: considering adj to 0000.0000.2222 (Ethernet3/1) metric 10, level 2, circuit 3, 
adj 3 

ISIS-Spf:   (accepted)

ISIS-Spf: Add 0000.0000.2222.00-00 to TENT, metric 10

ISIS-Spf:   Next hop 0000.0000.2222 (Ethernet3/1)

ISIS-Spf: Move 0000.0000.2222.00-00 to PATHS, metric 10

ISIS-Spf: Add 0000.0000.2222.02-00 to TENT, metric 20

ISIS-Spf:   Next hop 0000.0000.2222 (Ethernet3/1)

ISIS-Spf: Move 0000.0000.2222.02-00 to PATHS, metric 20

ISIS-Spf: Add 0000.0000.3333.00-00 to TENT, metric 20

ISIS-Spf:   Next hop 0000.0000.2222 (Ethernet3/1)

ISIS-Spf: Move 0000.0000.3333.00-00 to PATHS, metric 20

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 The SPF algorithm is also called the Dijkstra algorithm, after the creator of the algorithm.

---

Examples

The following is sample output from the debug isis spf statistics command:

Router# debug isis spf statistics

ISIS-Stats: Compute L1 SPT, Timestamp 2780.328 seconds

ISIS-Stats: Complete L1 SPT, Compute time 0.004, 1 nodes on SPT

ISIS-Stats: Compute L2 SPT, Timestamp 2780.3336 seconds

ISIS-Stats: Complete L2 SPT, Compute time 0.056, 12 nodes on SPT

Table 154 describes the significant fields shown in the display.

Table 154 debug isis spf statistics Field Descriptions 

Field	Description
Compute L1 SPT	Indicates that Level 1 ISs are to be added to a Level 1 area.
Timestamp	Indicates the time at which the SPF algorithm was applied. The time is expressed as the number of seconds elapsed since the system was up and configured.
Complete L1 SPT	Indicates that the algorithm has completed for Level 1 routing.
Compute time	Indicates the time required to place the ISs on the SPT.
nodes on SPT	Indicates the number of ISs that have been added.
Compute L2 SPT	Indicates that Level 2 ISs are to be added to the domain.
Complete L2 SPT	Indicates that the algorithm has completed for Level 2 routing.

The following lines show the statistical information available for Level 1 ISs:

ISIS-Stats: Compute L1 SPT, Timestamp 2780.328 seconds

ISIS-Stats: Complete L1 SPT, Compute time 0.004, 1 nodes on SPT

The output indicates that the SPF algorithm was applied 2780.328 seconds after the system was up and configured. Given the existing intra-area topology, 4 milliseconds were required to place one Level 1 IS on the SPT.

The following lines show the statistical information available for Level 2 ISs:

ISIS-Stats: Compute L2 SPT, Timestamp 2780.3336 seconds

ISIS-Stats: Complete L2 SPT, Compute time 0.056, 12 nodes on SPT

This output indicates that the SPF algorithm was applied 2780.3336 seconds after the system was up and configured. Given the existing intradomain topology, 56 milliseconds were required to place 12 Level 2 ISs on the SPT.

debug isis update-packets

To display various sequence number protocol data units (PDUs) and link-state packets that are detected by a router, use the debug isis update-packets command in privileged EXEC mode. To disable 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-packets

ISIS-Update: Sending L1 CSNP on Ethernet0

ISIS-Update: Sending L2 CSNP on Ethernet0

ISIS-Update: Updating L2 LSP

ISIS-Update: Delete link 888.8800.0181.00 from L2 LSP 1600.8906.4022.00-00, seq E

ISIS-Update: Updating L1 LSP

ISIS-Update: Sending L1 CSNP on Ethernet0

ISIS-Update: Sending L2 CSNP on Ethernet0

ISIS-Update: Add link 8888.8800.0181.00 to L2 LSP 1600.8906.4022.00-00, new seq 10,

 len 91

ISIS-Update: Sending L2 LSP 1600.8906.4022.00-00, seq 10, ht 1198 on Tunnel0

ISIS-Update: Sending L2 CSNP on Tunnel0

ISIS-Update: Updating L2 LSP

ISIS-Update: Rate limiting L2 LSP 1600.8906.4022.00-00, seq 11 (Tunnel0)

ISIS-Update: Updating L1 LSP

ISIS-Update: Rec L2 LSP 888.8800.0181.00.00-00 (Tunnel0)

ISIS-Update: PSNP entry 1600.8906.4022.00-00, seq 10, ht 1196

The following lines indicate that the router has sent a periodic Level 1 and Level 2 complete sequence number PDU on Ethernet interface 0:

ISIS-Update: Sending L1 CSNP on Ethernet0

ISIS-Update: Sending L2 CSNP on Ethernet0

The following lines indicate that the network service access point (NSAP) identified as 8888.8800.0181.00 was deleted from the Level 2 LSP 1600.8906.4022.00-00. The sequence number associated with this LSP is 0xE.

ISIS-Update: Updating L2 LSP

ISIS-Update: Delete link 888.8800.0181.00 from L2 LSP 1600.8906.4022.00-00, seq E

The following lines indicate that the NSAP identified as 8888.8800.0181.00 was added to the Level 2 LSP 1600.8906.4022.00-00. The new sequence number associated with this LSP is 0x10.

ISIS-Update: Updating L1 LSP

ISIS-Update: Sending L1 CSNP on Ethernet0

ISIS-Update: Sending L2 CSNP on Ethernet0

ISIS-Update: Add link 8888.8800.0181.00 to L2 LSP 1600.8906.4022.00-00, new seq 10,

 len 91

The following line indicates that the router sent Level 2 LSP 1600.8906.4022.00-00 with sequence number 0x10 on tunnel 0 interface:

ISIS-Update: Sending L2 LSP 1600.8906.4022.00-00, seq 10, ht 1198 on Tunnel0

The following lines indicates that a Level 2 LSP could not be transmitted because it was recently sent:

ISIS-Update: Sending L2 CSNP on Tunnel0

ISIS-Update: Updating L2 LSP

ISIS-Update: Rate limiting L2 LSP 1600.8906.4022.00-00, seq 11 (Tunnel0)

The following lines indicate that a Level 2 partial sequence number PDU (PSNP) has been received on tunnel 0 interface:

ISIS-Update: Updating L1 LSP

ISIS-Update: Rec L2 PSNP from 8888.8800.0181.00 (Tunnel0)

The following line indicates that a Level 2 PSNP with an entry for Level 2 LSP 1600.8906.4022.00-00 has been received. This output is an acknowledgment that a previously sent LSP was received without an error.

ISIS-Update: PSNP entry 1600.8906.4022.00-00, seq 10, ht 1196

debug iua as

To display debugging messages for the IDSN User Adaptation Layer (IUA) application server (AS), use the debug iua as command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug iua as {user | state} {all | name as-name}

no debug iua as

Syntax Description

user	Displays information about the use of application programming interfaces (APIs) and events between the ISDN layer and IUA.
state	Displays information about AS state transitions.
all	Enables debug for all the configured ASs.
name as-name	Defines the name of the AS.

Defaults

No default behavior or values

Command Modes

Privileged EXEC

Command History

Release	Modification
12.2(4)T	This command was introduced.
12.2(15)T	This command was integrated into Cisco IOS Release 12.2(15)T on the Cisco 2420, Cisco 2600 series, Cisco 3600 series, and Cisco 3700 series; and Cisco AS5300, Cisco AS5350, Cisco AS5400, and Cisco AS5850 network access server (NAS) platforms.

Examples

The following example shows debugging output when an ISDN backhaul connection is initially established. The output shows that state debugging is turned on for all ASs and that the AS is active.

Router# debug iua as state all 

IUA :state debug turned ON for ALL AS 

00:11:52:IUA:AS as1 number of ASPs up is 1 

00:11:57:IUA:AS as1 xsition AS-Up -->  AS-Active, cause - ASP asp1

Related CommandsActive

Command	Description
debug iua asp	Displays debugging messages for the IUA ASP.

debug iua asp

To display debugging messages for the IDSN User Adaptation Layer (IUA) application server process (ASP), use the debug iua asp command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug iua asp {pak | peer-msg | sctp-sig | state} {all | name asp-name}

no debug iua asp

Syntax Description

pak	Displays information about all packets.
peer-msg	Displays information about IUA peer-to-peer messages.
sctp-sig	Displays information about the signals being sent by the Stream Control Transmission Protocol (SCTP) layer.
state	Displays information about ASP state transition.
all	Enables debugging output for all configured ASPs.
name asp-name	Defines the name of the ASP.

Defaults

No default behavior or values

Command Modes

Privileged EXEC

Command History

Release	Modification
12.2(4)T	This command was introduced.
12.2(15)T	This command was integrated into Cisco IOS Release 12.2(15)T on the Cisco 2420, Cisco 2600 series, Cisco 3600 series, and Cisco 3700 series; and Cisco AS5300, Cisco AS5350, Cisco AS5400, and Cisco AS5850 network access server (NAS) platforms.

Examples

The following example shows debugging output when an ISDN backhaul connection is initially established. The output shows that peer message debugging is turned on for all ASPs and that the ASP is active.

Router# debug iua asp peer-msg all

IUA :peer message debug turned ON for ALL ASPs 

Router#

00:04:58:IUA :recieved ASP_UP message on ASP asp1 

00:04:58:IUA:ASP asp1 xsition ASP-Down -->  ASP-Up , cause -  rcv peer

msg

ASP-UP

00:04:58:IUA:sending ACK of type 0x304 to asp asp1 

00:05:03:IUA:recv ASP_ACTIVE message for ASP asp1 

00:05:03:IUA:ASP asp1 xsition ASP-Up -->  ASP-Active, cause - rcv peer

msg

ASP-Active

Related Commands

Command	Description
debug iua as	Displays debugging messages for the IUA AS.

debug kerberos

To display information associated with the Kerberos Authentication Subsystem, use the debug kerberos command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug kerberos

no debug kerberos

Syntax Description

This command has no arguments or keywords.

Command Modes

Privileged EXEC

Usage Guidelines

Kerberos is a security system that authenticates users and services without passing a cleartext password over the network. Cisco supports Kerberos under the authentication, authorization, and accounting (AAA) security system.

Use the debug aaa authentication command to get a high-level view of login activity. When Kerberos is used on the router, you can use the debug kerberos command for more detailed debugging information.

Examples

The following is part of the sample output from the debug aaa authentication command for a Kerberos login attempt that failed. The information indicates that Kerberos is the authentication method used.

Router# debug aaa authentication

AAA/AUTHEN/START (116852612): Method=KRB5

AAA/AUTHEN (116852612): status = GETUSER

AAA/AUTHEN/CONT (116852612): continue_login

AAA/AUTHEN (116852612): status = GETUSER

AAA/AUTHEN (116852612): Method=KRB5

AAA/AUTHEN (116852612): status = GETPASS

AAA/AUTHEN/CONT (116852612): continue_login

AAA/AUTHEN (116852612): status = GETPASS

AAA/AUTHEN (116852612): Method=KRB5

AAA/AUTHEN (116852612): password incorrect

AAA/AUTHEN (116852612): status = FAIL

The following is sample output from the debug kerberos command for a login attempt that was successful. The information indicates that the router sent a request to the key distribution center (KDC) and received a valid credential.

Router# debug kerberos

Kerberos: Requesting TGT with expiration date of 820911631

Kerberos: Sent TGT request to KDC

Kerberos: Received TGT reply from KDC

Kerberos: Received valid credential with endtime of 820911631

The following is sample output from the debug kerberos command for a login attempt that failed. The information indicates that the router sent a request to the KDC and received a reply, but the reply did not contain a valid credential.

Router# debug kerberos

Kerberos: Requesting TGT with expiration date of 820911731

Kerberos: Sent TGT request to KDC

Kerberos: Received TGT reply from KDC

Kerberos: Received invalid credential.

AAA/AUTHEN (425003829): password incorrect

The following output shows other failure messages you might see that indicate a configuration problem. The first message indicates that the router failed to find the default Kerberos realm, therefore the process failed to build a message to send to the KDC. The second message indicates that the router failed to retrieve its own IP address. The third message indicates that the router failed to retrieve the current time. The fourth message indicates the router failed to find or create a credentials cache for a user, which is usually caused by low memory availability.

Router# debug kerberos

Kerberos: authentication failed when parsing name

Kerberos: authentication failed while getting my address

Kerberos: authentication failed while getting time of day

Kerberos: authentication failed while allocating credentials cache

Related Commands

Command	Description
debug aaa authentication	Displays information on accountable events as they occur.

debug kron

To display debugging messages about Command Scheduler policies or occurrences, use the debug kron command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug kron {all | exec-cli | info | major}

no debug kron {all | exec-cli | info | major}

Syntax Description

all	Displays all debugging output about Command Scheduler policy lists or occurrences.
exec-cli	Displays detailed debugging output about Command Scheduler policy list command-line interface (CLI) commands.
info	Displays debugging output about Command Scheduler policy lists, occurrence warnings, or progress information.
major	Displays debugging output about Command Scheduler policy list or occurrence failures.

Defaults

If no keyword is specified, all debugging messages are displayed.

Command Modes

Privileged EXEC

Command History

Release	Modification
12.3(1)	This command was introduced.

Usage Guidelines

Use the debug kron command to display the output of a scheduled EXEC show command on the console.

Examples

The following example shows debugging messages for the EXEC CLI show version after the CLI was run at a scheduled interval:

Router# debug kron exec-cli

Kron cli occurrence messages debugging is on

2w6d: Call parse_cmd 'show version'

2w6d: Kron CLI return 0

'

**CLI 'show version': 

Cisco Internetwork Operating System Software IOS (tm) C2600 Software (C2600-I-M

Related Commands

Command	Description
show kron schedule	Displays the status and schedule information for Command Scheduler occurrences.

debug l2relay events

To start debugging of Layer 2 Relay events, use the debug l2relay events command in privileged EXEC mode. To disable debugging output, use the no form of this command (SGSN D-node only).

debug l2relay events

no debug l2relay events

Syntax Description

This command has no arguments or keywords.

Defaults

No default behavior or values.

Command Modes

Privileged EXEC

Command History

Release	Modification
12.1(1)GA	This command was introduced.
12.1(3)T	This command was integrated into Cisco IOS Release 12.1(3)T.

Usage Guidelines

The SGSN module uses the proprietary Layer 2 Relay protocol in conjunction with the intra-Serving GPRS Support Node (iSGSN) protocol for communication between the SGSN-datacom (SGSN-D) and SGSN-telecom (SGSN-T) units that comprise the SGSN.

For debugging purposes, it might also be useful to trace Layer 2 Relay packets. To display information about Layer 2 Relay packets, use the debug l2relay packets command.

Normally you will not need to use the debug l2relay events or debug l2relay packets commands. If problems with the SGSN are encountered, Cisco technical support personnel may request that issue the command.

---

Caution Because the debug l2relay events command generates a substantial amount of output, use it only when traffic on the GPRS network is low, so other activity on the system is not adversely affected.

---

Examples

The following example enables the display of Layer 2 Relay events:

Router# debug l2relay events

Related Commands

Command	Description
debug l2relay packets	Displays Layer 2 Relay packets (SGSN D-node only).

debug l2relay packets

To display information about Layer 2 Relay packets, use the debug l2relay packets command in privileged EXEC mode. To disable debugging output, use the no form of this command (SGSN D-node only).

debug l2relay packets

no debug l2relay packets

Syntax Description

This command has no arguments or keywords.

Defaults

No default behavior or values.

Command Modes

Privileged EXEC

Command History

Release	Modification
12.1(1)GA	This command was introduced.
12.1(3)T	This command was integrated into Cisco IOS Release 12.1(3)T.

Usage Guidelines

Use the debug l2relay packets command to display information about Layer 2 Relay packets.

The SGSN module uses the proprietary Layer 2 Relay protocol in conjunction with the intra-Serving GPRS Support Node (iSGSN) protocol for communication between the SGSN-datacom (SGSN-D) and SGSN-telecom (SGSN-T) units that comprise the SGSN.

For debugging purposes, it might also be useful to trace Layer 2 Relay events. To display information about Layer 2 Relay events, use the debug l2relay events command.

Normally you will not need to use the debug l2relay packets or debug l2relay events command. If problems with the SGSN are encountered, Cisco technical support personnel may request that you issue the command.

---

Caution Because the debug l2relay packets command generates a significant amount of output, use it only when traffic on the GPRS network is low, so other activity on the system is not adversely affected.

---

Examples

The following example enables the display of Layer 2 Relay packets:

Router# debug l2relay packets

Related Commands

Command	Description
debug ip igmp	Displays Layer 2 Relay events (SGSN D-node only).