|
|
Table Of Contents
debug isis mpls traffic-eng advertisements
debug isis mpls traffic-eng events
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
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 0x1Table 182 describes the significant fields shown in the display.
Related Commands
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
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
Examples
The following is sample output from the debug ipv6 cef events command:
Router# debug ipv6 cef eventsIPv6 CEF packet events debugging is onRouter#*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 succeededTable 183 describes the significant fields shown in the display.
Related Commands
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
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
Related Commands
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
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
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 receiveIPv6 CEF packet receives debugging is onrouter#*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::2Table 184 describes the significant fields shown in the display.
Table 184 debug ipv6 cef receive Field Descriptions
IPv6CEF-receive: Receive packet for 4000::2
CEF has received a packet addressed to the router.
Related Commands
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
Defaults
Debugging for CEFv6 and dCEFv6 table modification events is not enabled.
Command Modes
Privileged EXEC
Command History
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:
•
•
•
•
Note
Related Commands
debug ipv6 cef events
Displays debugging messages for CEFv6 and dCEFv6 general events.
debug ipv6 dhcp
To enable debugging for the Dynamic Host Configuration Protocol (DHCP) for IPv6, use the debug ipv6 dhcp command in privileged EXEC mode. To disable debugging output, use the no form of the command.
debug ipv6 dhcp [detail]
no debug ipv6 dhcp [detail]
Syntax Description
Defaults
Debugging for the DHCP for IPv6 is disabled.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The detail keyword used with the debug ipv6 dhcp command reports detailed DHCP for IPv6 message decoding.
Examples
The following example enables debugging for the DHCP for IPv6:
Router# debug ipv6 dhcpRelated Commands
debug ipv6 dhcp database
Enables debugging for the DHCP for IPv6 binding database.
debug ipv6 dhcp database
To enable debugging for the Dynamic Host Configuration Protocol (DHCP) for IPv6 binding database, use the debug ipv6 dhcp database command in privileged EXEC mode. To disable debugging output, use the no form of the command.
debug ipv6 dhcp database
no debug ipv6 dhcp database
Syntax Description
This command has no arguments or keywords.
Defaults
Debugging for the DHCP for IPv6 binding database is not enabled.
Command Modes
Privileged EXEC
Command History
Examples
The following example enables debugging for the DHCP for IPv6 binding database:
Router# debug ipv6 dhcp databasedebug ipv6 dhcp databaseRelated Commands
debug ipv6 dhcp relay
To enable the Dynamic Host Configuration Protocol (DHCP) for IPv6 relay agent debugging, use the debug ipv6 dhcp relay command in user EXEC and privileged EXEC mode. To disable DHCP for IPv6 relay agent debugging, use the no form of this command.
debug ipv6 dhcp relay
no debug ipv6 dhcp relay
Syntax Description
This command has no keywords or arguments.
Defaults
No default behavior or values
Command Modes
User EXEC
Privileged EXECCommand History
Usage Guidelines
The DHCP for IPv6 client, server, and relay functions are mutually exclusive on an interface. When one of these functions is already enabled and a user tries to configure a different function on the same interface, one of the following messages is displayed: "Interface is in DHCP client mode," "Interface is in DHCP server mode," or "Interface is in DHCP relay mode."
Examples
The following example enables DHCP for IPv6 relay agent debugging:
Router# debug ipv6 dhcp relayRelated Commands
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
Usage Guidelines
The debug ipv6 icmp command is similar to the debug ip icmp command, except that it is IPv6-specific.
Note
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
Examples
The following is sample output from the debug ipv6 icmp command:
Router# debug ipv6 icmp13:28:40:ICMPv6:Received ICMPv6 packet from 2000:0:0:3::2, type 13613:28:45:ICMPv6:Received ICMPv6 packet from FE80::203:A0FF:FED6:1400, type 13513:28:50:ICMPv6:Received ICMPv6 packet from FE80::203:A0FF:FED6:1400, type 13613:28:55:ICMPv6:Received ICMPv6 packet from FE80::203:A0FF:FED6:1400, type 135Table 185 describes significant fields shown in the first line of the display.
Following are examples of the IPv6 ICMP messages types that can be displayed by the debug ipv6 icmp command:
•
1w4d:ICMPv6:Sending echo request to 2052::501w4d:ICMPv6:Received echo reply from 2052::50•
1w4d:Received ICMP too big from 2052::52 about 2052::50, MTU=1300•
1w4d:Received ICMP parameter problem from 2052::52•
1w4d:Received ICMP time exceeded from 2052::52•
1w4d:Received ICMP unreachable code 1 from 2052::521w4d:Sending ICMP unreachable code 1 to 2060::20 about 2062::20Table 186 lists the codes for ICMP unreachable messages.
Related Commands
debug ipv6 nd
Displays debugging messages for IPv6 ICMP neighbor discovery transactions.
debug ipv6 inspect
To display messages about Cisco IOS firewall events, use the debug ipv6 inspect command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 inspect {function-trace | object-creation | object-deletion | events | timers | protocol | detailed}
no debug ipv6 inspect detailed
Syntax Description
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Related Commands
debug ipv6 mfib
To enable debugging output on the IPv6 Multicast Forwarding Information Base (MFIB), use the debug ipv6 mfib command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 mfib [group-name | group-address] [ adjacency | signal | db | init | mrib | pak | ps ]
no debug ipv6 mfib
Syntax Description
Command Modes
Privileged EXEC
Syntax Description
Usage Guidelines
If no keywords are used, all IPbv6 MFIB activity debugging output is displayed.
Examples
The following example enables debugging output for adjacency management activity on the IPv6 MFIB:
Router# debug ipv6 mfib adjacencydebug ipv6 mld
To enable debugging on Multicast Listener Discovery (MLD) protocol activity, use the debug ipv6 mld command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 mld [group-name | group-address | interface]
no debug ipv6 mld [group-name | group-address | interface]
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command helps discover whether the MLD protocol activities are working correctly. In general, if MLD is not working, the router process never discovers that there is another host on the network that is configured to receive multicast packets. In sparse mode, the packets are undeliverable.
The messages displayed by the debug ipv6 mld command show query and report activity received from other routers and multicast group addresses. Use this command in conjunction with the debug ipv6 pim command to observe additional multicast activity and to see what is happening to the multicast routing process, or why packets are forwarded from particular interfaces.
Examples
The following example enables debugging on MLD protocol activity:
Router# debug ipv6 mldRelated Commands
debug ipv6 mld explicit
To display information related to the explicit tracking of hosts, use the debug ipv6 mld explicit command in privileged EXEC mode. To disable debugging, use the no form of this command.
debug ipv6 mld explicit [group-name | group-address]
no debug ipv6 mld explicit [group-name | group-address]
Syntax Description
Defaults
Debugging for the explicit tracking of hosts is not enabled.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
When the optional group-name or group-address arguments are not used, all debugging information is displayed.
Examples
The following example enables information to be displayed about the explicit tracking of hosts. The command output is self-explanatory:
Router# debug ipv6 mld explicit00:00:56:MLD:ET host FE80::A8BB:CCFF:FE00:800 report for FF05::6 (0 srcs) on Ethernet1/000:00:56:MLD:ET host FE80::A8BB:CCFF:FE00:800 switch to exclude for FF05::6 on Ethernet1/000:00:56:MLD:ET MRIB modify for (*,FF05::6) on Ethernet1/0 new 100, mdf 100debug ipv6 mobile
To enable the display of debugging information for Mobile IPv6, use the debug ipv6 mobile command in privileged EXEC mode.
debug ipv6 mobile {binding-cache | forwarding | home-agent | registration}
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The debug ipv6 mobile command enables the display of selected debugging information. You may use multiple command lines to enable concurrent debugging of multiple classes of information.
Examples
In the following example, debugging information is displayed for binding updates processing:
Router# debug ipv6 mobile registrationRelated Commands
debug ipv6 mrib client
To enable debugging on Multicast Routing Information Base (MRIB) client management activity, use the debug ipv6 mrib client command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 mrib client
no debug ipv6 mrib client
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command is used to display the activity in the MRIB associated with Protocol Independent Multicast (PIM) and Multicast Listener Discovery (MLD) clients. If you are having difficulty with your client connections, use this command to display new clients being added and deleted.
Examples
The following example enables debugging on MRIB client management activity:
Router# debug ipv6 mrib clientRelated Commands
debug ipv6 mrib io
To enable debugging on Multicast Routing Information Base (MRIB) I/O events, use the debug ipv6 mrib io command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 mrib io
no debug ipv6 mrib io
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the debug ipv6 mrib io command to view information on connections that are being opened and closed and on MRIB I/O event updates being sent and received.
Examples
The following example enables debugging on MRIB I/O events:
Router# debug ipv6 mrib iodebug ipv6 mrib proxy
To enable debugging on multicast routing information base (MRIB) proxy activity between the route processor and line cards on distributed router platforms, use the debug ipv6 mrib proxy command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 mrib proxy
no debug ipv6 mrib proxy
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the debug ipv6 mrib proxy command to display information on connections that are being opened and closed and on MRIB transaction messages that are being passed between the route processor and line cards.
Examples
The following example enables debugging on MRIB proxy events:
Router# debug ipv6 mrib proxydebug ipv6 mrib route
To display information about Multicast Routing Information Base (MRIB) routing entry-related activity, use the debug ipv6 mrib route command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 mrib route [group-name | group-address]
no debug ipv6 mrib route
Syntax Description
group-name | group-address
(Optional) IPv6 address, name, or interface of the multicast group as defined in the Domain Name System (DNS) hosts table.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command displays update information related to the route database made by MRIB clients, which is then redistributed to the clients.
Use this command to monitor MRIB route activity when there is discontinuity found between the MRIB and the client database or between the individual client databases.
Examples
The following example enables the display of information about MRIB routing entry-related activity:
Router# debug ipv6 mrib routeRelated Commands
show ipv6 mrib client
Displays information about the MRIB client management activity.
debug ipv6 mrib table
To enable debugging on Multicast Routing Information Base (MRIB) table management activity, use the debug ipv6 mrib table command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 mrib table
no debug ipv6 mrib table
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the debug ipv6 mrib table command to view information on new MRIB tables being added and deleted.
Examples
The following example enables debugging on MRIB table management activity:
Router# debug ipv6 mrib tabledebug ipv6 nat
To display 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
Defaults
Debugging for NAT-PT translation events is not enabled.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The debug ipv6 nat command can be used to troubleshoot NAT-PT translation issues. If no keywords are specified, debugging messages for all NAT-PT protocol translation events are displayed.
Note
Caution
Examples
The following example shows output for the debug ipv6 nat command:
Router# debug ipv6 nat00:06:06: IPv6 NAT: icmp src (3002::8) -> (192.168.124.8), dst (2001::2) -> (192.168.123.2)00:06:06: IPv6 NAT: icmp src (192.168.123.2) -> (2001::2), dst (192.168.124.8) -> (3002::8)00:06:06: IPv6 NAT: icmp src (3002::8) -> (192.168.124.8), dst (2001::2) -> (192.168.123.2)00:06:06: IPv6 NAT: icmp src (192.168.123.2) -> (2001::2), dst (192.168.124.8) -> (3002::8)00:06:06: IPv6 NAT: tcp src (3002::8) -> (192.168.124.8), dst (2001::2) -> (192.168.123.2)00:06:06: IPv6 NAT: tcp src (192.168.123.2) -> (2001::2), dst (192.168.124.8) -> (3002::8)00:06:06: IPv6 NAT: tcp src (3002::8) -> (192.168.124.8), dst (2001::2) -> (192.168.123.2)00:06:06: IPv6 NAT: tcp src (3002::8) -> (192.168.124.8), dst (2001::2) -> (192.168.123.2)00:06:06: IPv6 NAT: tcp src (3002::8) -> (192.168.124.8), dst (2001::2) -> (192.168.123.2)00:06:06: IPv6 NAT: tcp src (192.168.123.2) -> (2001::2), dst (192.168.124.8) -> (3002::8)Table 187 describes the significant fields shown in the display.
The following example shows output for the debug ipv6 nat command with the detailed keyword:
Router# debug ipv6 nat detailed00:14:12: IPv6 NAT: address allocated 192.168.124.800:14:16: IPv6 NAT: deleted a NAT entry after timeoutdebug ipv6 nd
To display 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
Usage Guidelines
This command can help determine whether the router is sending or receiving IPv6 ICMP neighbor discovery messages.
Note
Examples
The following shows sample output from the debug ipv6 nd command:
Router# debug ipv6 nd13:22:40:ICMPv6-ND:STALE -> DELAY:2000:0:0:3::213:22:45:ICMPv6-ND:DELAY -> PROBE:2000:0:0:3::213:22:45:ICMPv6-ND:Sending NS for 2000:0:0:3::2 on FastEthernet0/013:22:45:ICMPv6-ND:Received NA for 2000:0:0:3::2 on FastEthernet0/0 from 2000:0:0:3::213:22:45:ICMPv6-ND:PROBE -> REACH:2000:0:0:3::213:22:45:ICMPv6-ND:Received NS for 2000:0:0:3::1 on FastEthernet0/0 from FE80::203:A0FF:FED6:140013:22:45:ICMPv6-ND:Sending NA for 2000:0:0:3::1 on FastEthernet0/013:23:15: ICMPv6-ND: Sending NS for FE80::1 on Ethernet0/113:23:16: ICMPv6-ND: DAD: FE80::1 is unique.13:23:16: ICMPv6-ND: Sending NS for 2000::2 on Ethernet0/113:23:16: ICMPv6-ND: Sending NS for 3000::3 on Ethernet0/113:23:16: ICMPv6-ND: Sending NA for FE80::1 on Ethernet0/113:23:17: ICMPv6-ND: DAD: 2000::2 is unique.13:23:53: ICMPv6-ND: Sending NA for 2000::2 on Ethernet0/113:23:53: ICMPv6-ND: DAD: 3000::3 is unique.13:23:53: ICMPv6-ND: Sending NA for 3000::3 on Ethernet0/13d19h: ICMPv6-ND: Sending NS for FE80::2 on Ethernet0/23d19h: ICMPv6-ND: Received NA for FE80::2 on Ethernet0/2 from FE80::23d19h: ICMPv6-ND: DAD: duplicate link-local FE80::2 on Ethernet0/2,interface stalled3d19h: %IPV6-4-DUPLICATE: Duplicate address FE80::2 on Ethernet0/23d19h: ICMPv6-ND: Sending NS for 3000::4 on Ethernet0/33d19h: ICMPv6-ND: Received NA for 3000::4 on Ethernet0/3 from 3000::43d19h: %IPV6-4-DUPLICATE: Duplicate address 3000::4 on Ethernet0/3Table 188 describes the significant fields shown in the display.
Related Commands
debug ipv6 icmp
Displays debug messages for IPv6 ICMP transactions.
show ipv6 neighbors
Displays IPv6 neighbor discovery cache information.
debug ipv6 ospf
To display debugging information for Open Shortest Path First (OSPF) for IPv6, use the debug ipv6 ospf command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 ospf [adj | database-timer | flood | hello | lsa-generation | retransmission]
no debug ipv6 ospf [adj | database-timer | flood | hello | lsa-generation | retransmission]
Syntax Description
Command Modes
Privileged EXEC
Command History
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 adjdebug 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
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 eventsdebug ipv6 ospf lsdb
To display database modifications for Open Shortest Path First (OSPF) for IPv6, use the debug ipv6 ospf lsdb command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 ospf lsdb
no debug ipv6 ospf lsdb
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
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 lsdbdebug 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
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 packetdebug ipv6 ospf spf statistic
To display statistical information while running the shortest path first (SPF) algorithm, use the debug ipv6 ospf spf statistic command in privileged EXEC mode. To disable 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
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 statisticsRelated Commands
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
Defaults
Debugging for IPv6 packets is not enabled.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The debug ipv6 packet command is similar to the debug ip packet command, except that it is IPv6-specific.
Note
IPv6 debugging information includes packets received, generated, and forwarded. Fast-switched packets do not generate messages. When an IPv6 access list is specified by using the access-list keyword and access-list-name argument, only packets matching the access list permit entries are displayed.
Caution
Examples
The following shows sample output from the debug ipv6 packet command:
Router# debug ipv6 packet13:25:40:IPV6:source 2000:0:0:3::1 (local)13:25:40: dest 2000:0:0:3::2 (FastEthernet0/0)13:25:40: traffic class 96, flow 0x0, len 143+195, prot 6, hops 64, originating13:25:40:IPv6:Sending on FastEthernet0/013:25:40:IPV6:source 2000:0:0:3::2 (FastEthernet0/0)13:25:40: dest 2000:0:0:3::113:25:40: traffic class 96, flow 0x0, len 60+14, prot 6, hops 64, forward to ulp13:25:45:IPV6:source FE80::203:E4FF:FE12:CC1D (local)13:25:45: dest FF02::9 (Ethernet1/1)13:25:45: traffic class 112, flow 0x0, len 72+1428, prot 17, hops 255, originating13:25:45:IPv6:Sending on Ethernet1/113:25:45:IPV6:source FE80::203:E4FF:FE12:CC00 (local)13:25:45: dest 2000:0:0:3::2 (FastEthernet0/0)13:25:45: traffic class 112, flow 0x0, len 72+8, prot 58, hops 255, originating13:25:45:IPv6:Sending on FastEthernet0/013:25:45:IPV6:source 2000:0:0:3::2 (FastEthernet0/0)13:25:45: dest FE80::203:E4FF:FE12:CC0013:25:45: traffic class 112, flow 0x0, len 64+14, prot 58, hops 255, forward to ulp13:25:45:IPV6:source FE80::203:A0FF:FED6:1400 (FastEthernet0/0)13:25:45: dest 2000:0:0:3::113:25:45: traffic class 112, flow 0x0, len 72+14, prot 58, hops 255, forward to ulpTable 189 describes the significant fields shown in the display.
debug ipv6 pim
To enable debugging on Protocol Independent Multicast (PIM) protocol activity, use the debug ipv6 pim command in privileged EXEC mode. To restore the default value, use the no form of this command.
debug ipv6 pim [group-name | group-address | interface-type | neighbor]
no debug ipv6 pim [group-name | group-address | interface-type | neighbor]
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command helps discover whether the PIM protocol activities are working correctly.
The messages displayed by the debug ipv6 pim command show query and report activity received from other routers and multicast group addresses. Use this command in conjunction with debug ipv6 mld to observe additional multicast activity and to learn what is happening to the multicast routing process, or why packets are forwarded out of particular interfaces.
Examples
The following example enables debugging on PIM activity:
Router# debug ipv6 pimRelated Commands
debug ipv6 pim df-election
To display debug messages for protocol independent multicast (PIM) bidirectional designated forwarder (DF) election message processing, use the debug ipv6 pim df-election command in privileged EXEC mode. To disable debugging, use the no form of this command.
debug ipv6 pim df-election [interface interface-type interface-number] [rp rp-name | rp-address]
no debug ipv6 pim df-election [interface interface-type interface-number] [rp rp-name | rp-address]
Syntax Description
Defaults
Debugging for PIM bidirectional DF election message processing is not enabled.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the debug ipv6 pim df-election command if traffic is not flowing properly when operating in PIM bidirectional mode or if the show ipv6 pim df and show ipv6 pim df winner commands do not display the expected information.
Examples
The following example enables debugging for PIM bidirectional DF election message processing on Ethernet 1/0 and at 200::1:
debug ipv6 pim df-election interface ethernet 1/0 rp 200::1Related Commands
debug ipv6 policy
To display IPv6 policy routing packet activity, use the debug ipv6 policy command in user EXEC or privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 policy [access-list-name]
no debug ipv6 policy [access-list-name]
Syntax Description
access-list-name
(Optional) Name of the IPv6 access list for which to clear the match counters. Names cannot contain a space or quotation mark, or begin with a numeric.
Defaults
IPv6 policy routing packet activity is not displayed.
Command Modes
User EXEC
Privileged EXECCommand History
Usage Guidelines
If no access list is specified using the optional access-list-name argument, information about all policy-matched and policy-routed packets is displayed.
After you configure IPv6 policy routing, use the debug ipv6 policy command to verify that IPv6 policy based routing (PBR) is policy-routing packets normally. Policy routing looks at various parts of the packet and then routes the packet based on certain user-defined attributes in the packet. The debug ipv6 policy command helps you determine what policy routing is following. It displays information about whether a packet matches the criteria, and if so, the resulting routing information for the packet.
Do not use the debug ipv6 policy command unless you suspect a problem with IPv6 PBR policy routing.
Examples
The following example enables IPv6 policy routing packet activity. The output for this command is self-explanatory:
Router# debug ipv6 policy00:02:38:IPv6 PBR:Ethernet0/0, matched src 2003::90 dst 2001:1000::1 protocol 5800:02:38:IPv6 PBR:set nexthop 2003:1::95, interface Ethernet1/000:02:38:IPv6 PBR:policy route via Ethernet1/0/2003:1::95debug ipv6 pool
To enable debugging on IPv6 prefix pools, use the debug ipv6 pool command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipv6 pool
no debug ipv6 pool
Syntax Description
This command has no arguments or keywords.
Defaults
No debugging is active.
Command History
Examples
The following example enables debugging for IPv6 prefix pools:
Router# debug ipv6 pool2w4d: IPv6 Pool: Deleting route/prefix 2001:0DB8::/29 to Virtual-Access1 for cisco2w4d: IPv6 Pool: Returning cached entry 2001:0DB8::/29 for cisco on Virtual-Access1 topool12w4d: IPv6 Pool: Installed route/prefix 2001:0DB8::/29 to Virtual-Access1 for ciscoRelated Commands
debug ipv6 rip
To display 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
Usage Guidelines
The debug ipv6 rip command is similar to the debug ip rip command, except that it is IPv6-specific.
Note
Using this command without arguments enables IPv6 RIP debugging for RIP packets that are sent and received on all router interfaces. Using this command with arguments enables IPv6 RIP debugging for RIP packets that are sent and received only on the specified interface.
Caution
Examples
The following shows sample output from the debug ipv6 rip command:
Router# debug ipv6 rip13:09:10:RIPng:Sending multicast update on Ethernet1/1 for as1_rip13:09:10: src=FE80::203:E4FF:FE12:CC1D13:09:10: dst=FF02::9 (Ethernet1/1)13:09:10: sport=521, dport=521, length=3213:09:10: command=2, version=1, mbz=0, #rte=113:09:10: tag=0, metric=1, prefix=::/013:09:28:RIPng:response received from FE80::202:FDFF:FE77:1E42 on Ethernet1/1 for as1_rip13:09:28: src=FE80::202:FDFF:FE77:1E42 (Ethernet1/1)13:09:28: dst=FF02::913:09:28: sport=521, dport=521, length=3213:09:28: command=2, version=1, mbz=0, #rte=113:09:28: tag=0, metric=1, prefix=2000:0:0:1:1::/80The example shows two RIP packets; both are updates, known as "responses" in RIP terminology and indicated by a "command" value of 2. The first is an update sent by this router, and the second is an update received by this router. Multicast update packets are sent to all neighboring IPv6 RIP routers (all routers that are on the same links as the router sending the update, and that have IPv6 RIP enabled). An IPv6 RIP router advertises the contents of its routing table to its neighbors by periodically sending update packets over those interfaces on which IPv6 RIP is configured. An IPv6 router may also send "triggered" updates immediately following a routing table change. In this case the updates only 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 190 describes the significant fields shown in the display. The tag, metric, and prefix fields are specific to each RTE contained in the update.
Related Commands
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
Usage Guidelines
The debug ipv6 routing command is similar to the debug ip routing command, except that it is IPv6-specific.
Note
Examples
The following shows sample output from the debug ipv6 routing command:
Router# debug ipv6 routing13:18:43:IPv6RT0:Add 2000:0:0:1:1::/80 to table13:18:43:IPv6RT0:Better next-hop for 2000:0:0:1:1::/80, [120/2]13:19:09:IPv6RT0:Add 2000:0:0:2::/64 to table13:19:09:IPv6RT0:Better next-hop for 2000:0:0:2::/64, [20/1]13:19:09:IPv6RT0:Add 2000:0:0:2:1::/80 to table13:19:09:IPv6RT0:Better next-hop for 2000:0:0:2:1::/80, [20/1]13:19:09:IPv6RT0:Add 2000:0:0:4::/64 to table13:19:09:IPv6RT0:Better next-hop for 2000:0:0:4::/64, [20/1]13:19:37:IPv6RT0:Add 2000:0:0:6::/64 to table13:19:37:IPv6RT0:Better next-hop for 2000:0:0:6::/64, [20/2]The debug ipv6 routing command displays messages whenever the routing table changes. For example, the following message indicates that a route to the prefix 2000:0:0:1:1::/80 was added to the routing table at the time specified in the message.
13:18:43:IPv6RT0:Add 2000:0:0:1:1::/80 to tableThe following message indicates that the prefix 2000:0:0:2::/64 was already in the routing table; however, a received advertisement provided a lower cost path to the prefix. Therefore, the routing table was updated with the lower cost path. (The [20/1] in the example is the administrative distance [20] and metric [1] of the better path.)
13:19:09:IPv6RT0:Better next-hop for 2000:0:0:2::/64, [20/1]Related Commands
debug 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 shows sample output from the debug ip wccp events command when a Cisco Cache Engine is added to the list of available Web caches:
Router# debug ip wccp eventsWCCP-EVNT: Built I_See_You msg body w/1 usable web caches, change # 0000000AWCCP-EVNT: Web Cache 192.168.25.3 addedWCCP-EVNT: Built I_See_You msg body w/2 usable web caches, change # 0000000BWCCP-EVNT: Built I_See_You msg body w/2 usable web caches, change # 0000000Cdebug 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 packetsWCCP-PKT: Received valid Here_I_Am packet from 192.168.25.4 w/rcvd_id 00003532WCCP-PKT: Sending I_See_You packet to 192.168.25.4 w/ rcvd_id 00003534WCCP-PKT: Received valid Here_I_Am packet from 192.168.25.3 w/rcvd_id 00003533WCCP-PKT: Sending I_See_You packet to 192.168.25.3 w/ rcvd_id 00003535WCCP-PKT: Received valid Here_I_Am packet from 192.168.25.4 w/rcvd_id 00003534WCCP-PKT: Sending I_See_You packet to 192.168.25.4 w/ rcvd_id 00003536WCCP-PKT: Received valid Here_I_Am packet from 192.168.25.3 w/rcvd_id 00003535WCCP-PKT: Sending I_See_You packet to 192.168.25.3 w/ rcvd_id 00003537WCCP-PKT: Received valid Here_I_Am packet from 192.168.25.4 w/rcvd_id 00003536WCCP-PKT: Sending I_See_You packet to 192.168.25.4 w/ rcvd_id 00003538WCCP-PKT: Received valid Here_I_Am packet from 192.168.25.3 w/rcvd_id 00003537WCCP-PKT: Sending I_See_You packet to 192.168.25.3 w/ rcvd_id 00003539debug ipx ipxwan
To display debugging information for interfaces configured to use IPX wide-area network (IPXWAN), use the debug ipx ipxwan command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipx ipxwan
no debug ipx ipxwan
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
The debug ipx ipxwan command is useful for verifying the startup negotiations between two routers running the IPX protocol through a WAN. This command produces output only during state changes or startup. During normal operations, no output is produced.
Examples
The following is sample output from the debug ipx ipxwan command during link startup:
Router# debug ipx ipxwan%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to upIPXWAN: state (Disconnect -> Sending Timer Requests) [Serial1/6666:200 (IPX linestate brought up)]IPXWAN: state (Sending Timer Requests -> Disconnect) [Serial1/6666:200 (IPX linestate brought down)]IPXWAN: state (Disconnect -> Sending Timer Requests) [Serial1/6666:200 (IPX linestate brought up)]IPXWAN: Send TIMER_REQ [seq 0] out Serial1/6666:200IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200IPXWAN: Send TIMER_REQ [seq 2] out Serial1/6666:200IPXWAN: Send TIMER_REQ [seq 0] out Serial1/6666:200IPXWAN: Rcv TIMER_REQ on Serial1/6666:200, NodeID 1234, Seq 1IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200IPXWAN: Rcv TIMER_RSP on Serial1/6666:200, NodeID 1234, Seq 1, Del 6IPXWAN: state (Sending Timer Requests -> Master: Sent RIP/SAP) [Serial1/6666:200(Received Timer Response as master)]IPXWAN: Send RIPSAP_INFO_REQ [seq 0] out Serial1/6666:200IPXWAN: Rcv RIPSAP_INFO_RSP from Serial1/6666:200, NodeID 1234, Seq 0IPXWAN: state (Master: Sent RIP/SAP -> Master: Connect) [Serial1/6666:200 (Received Router Info Rsp as Master)]The following line indicates that the interface has initialized:
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to upThe following lines indicate that the startup process failed to receive a timer response, brought the link down, then brought the link up and tried again with a new timer set:
IPXWAN: state (Sending Timer Requests -> Disconnect) [Serial1/6666:200 (IPX linestate brought down)]IPXWAN: state (Disconnect -> Sending Timer Requests) [Serial1/6666:200 (IPX linestate brought up)]The following lines indicate that the interface is sending timer requests and waiting for a timer response:
IPXWAN: Send TIMER_REQ [seq 0] out Serial1/6666:200IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200The following lines indicate that the interface has received a timer request from the other end of the link and has sent a timer response. The fourth line shows that the interface has come up as the master on the link.
IPXWAN: Rcv TIMER_REQ on Serial1/6666:200, NodeID 1234, Seq 1IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200IPXWAN: Rcv TIMER_RSP on Serial1/6666:200, NodeID 1234, Seq 1, Del 6IPXWAN: state (Sending Timer Requests -> Master: Sent RIP/SAP) [Serial1/6666:200(Received Timer Response as master)]The following lines indicate that the interface is sending RIP/SAP requests:
IPXWAN: Send RIPSAP_INFO_REQ [seq 0] out Serial1/6666:200IPXWAN: Rcv RIPSAP_INFO_RSP from Serial1/6666:200, NodeID 1234, Seq 0IPXWAN: state (Master: Sent RIP/SAP -> Master: Connect) [Serial1/6666:200 (Received Router Info Rsp as Master)]debug ipx nasi
To display information about 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
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 packetsRouter# debug ipx nasi errorNASI0: 6E6E Check server infoNASI0: 6E6E sending server-info 4F00 Good response: 43 bytesNASI0: 7A6E Query Port. Find firstNASI0: FFirst: line 0 DE, port: TTY1-__________ASYNC___^, group: ASYNC___^NASI0: 7A6E sending Qport find-first response: 300 bytesNASI0: 7B6E port request. setting up portNASI: Check-login User: c h r i sNASI: Check-login PW hash: C7 A6 C5 C7 C4 C0 C5 C3 C4 CC C5 CF C4 C8 C5 CB C4 D4 C5 D7 C4 D0 C5 D3 C4NASI: Check-login PW: l a bNASI1: 7B6E sending NCS Good server Data Ack in 0 bytes pkt in 13 size pktNASI1: 7B6E sending Preq response: 303 bytes GoodNASI1: 7B6E port request. setting up portNASI1: 7B6E sending NCS Good server Data Ack in 0 bytes pkt in 13 size pktNASI1: 7B6E sending Preq response: 303 bytes GoodNASI1: 7B6E Unknown NASI code 4500 Pkt Size: 1345 0 0 FC 0 2 0 20 0 0 FF 1 0NASI1: 7B6E Flush Rx BuffersNASI1: 7B6E sending NASI server TTY data: 1 byte in 14 size pktNASI1: 7B6E sending NCS Good server Data Ack in 1 bytes pkt in 13 size pktIn the following line, 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 infoThe following message indicates that the router is sending back a "server-info" packet with a positive acknowledgment, and the packet size is 43 bytes:
NASI0: 6E6E sending server-info 4F00 Good response: 43 bytesThe following line is a NASI packet type. "Find first" and "find next" are NASI packet types.
NASI0: 7A6E Query Port. Find firstThe following line indicates that the outgoing find first packet for the NASI connection 7A6E has line 0 DE, port name TTY1, and general name ASYNC:
NASI0: FFirst: line 0 DE, port: TTY1-__________ASYNC___^, group: ASYNC___^The following two lines indicate 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: 1345 0 0 FC 0 2 0 20 0 0 FF 1 0Related Commands
debug ipx packet
To display information about packets received, sent, and forwarded, use the debug ipx packet command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipx packet
no debug ipx packet
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
This command is useful for learning whether Internetwork Packet Exchange (IPX) packets are traveling over a router.
Note
Examples
The following is sample output from the debug ipx packet command:
Router# debug ipx packetIPX: src=160.0260.8c4c.4f22, dst=1.0000.0000.0001, packet receivedIPX: src=160.0260.8c4c.4f22, dst=1.0000.0000.0001,gw=183.0000.0c01.5d85,sending packetThe first line indicates that the router receives a packet from a Novell station (address 160.0260.8c4c.4f22); this trace does not indicate the address of the immediate router sending the packet to this router. In the second line, the router forwards the packet toward the Novell server (address 1.0000.0000.0001) through an immediate router (183.0000.0c01.5d85).
Table 191 describes the significant fields shown in the display.
debug ipx routing
To display information on Internetwork Packet Exchange (IPX) routing packets that the router sends and receives, use the debug ipx routing command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipx routing {activity | events}
no debug ipx routing {activity | events}
Syntax Description
activity
Displays messages relating to IPX routing activity.
events
Displays messages relating to IPX routing events.
Command Modes
Privileged EXEC
Usage Guidelines
Normally, a router or server sends out one routing update per minute. Each routing update packet can include up to 50 entries. If many networks exist on the internetwork, the router sends out multiple packets per update. For example, if a router has 120 entries in the routing table, it would send three routing update packets per update. The first routing update packet would include the first 50 entries, the second packet would include the next 50 entries, and the last routing update packet would include the last 20 entries.
Examples
The following is sample output from the debug ipx routing command:
Router# debug ipx routingIPXRIP: update from 9999.0260.8c6a.1733110801 in 1 hops, delay 2IPXRIP: sending update to 12FF02:ffff.ffff.ffff via Ethernet 1network 555, metric 2, delay 3network 1234, metric 3, delay 4Table 192 describes the significant fields shown in the display.
Related Commands
debug ipx sap
To display information about Internetwork Packet Exchange (IPX) Service Advertisement Protocol (SAP) packets, use the debug ipx sap command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipx sap [activity | events]
no debug ipx sap [activity | events]
Syntax Description
Command Modes
Privileged EXEC
Usage Guidelines
Normally, a router or server sends out one SAP update per minute. Each SAP packet can include up to seven entries. If many servers are advertising on the network, the router sends out multiple packets per update. For example, if a router has 20 entries in the SAP table, it would send three SAP packets per update. The first SAP would include the first seven entries, the second SAP would include the next seven entries, and the last update would include the last six entries.
Obtain the most meaningful detail by using the debug ipx sap activity and the debug ipx sap events commands together.
Caution
Examples
The following is sample output from the debug ipx sap command:
Router# debug ipx sapIPXSAP: at 0023F778:I SAP Response type 0x2 len 160 src:160.0000.0c00.070d dest:160.ffff.ffff.ffff(452)type 0x4, "Hello2", 199.0002.0004.0006 (451), 2 hopstype 0x4, "Hello1", 199.0002.0004.0008 (451), 2 hopsIPXSAP: sending update to 160IPXSAP: at 00169080:O SAP Update type 0x2 len 96 ssoc:0x452 dest:160.ffff.ffff.ffff(452)IPX: type 0x4, "Magnolia", 42.0000.0000.0001 (451), 2hopsThe debug ipx sap command generates multiple lines of output for each SAP packet—a packet summary message and a service detail message.
The first line displays the internal router memory address of the packet. The technical support staff may use this information in problem debugging.
IPXSAP: at 0023F778:Table 193 describes the significant fields shown in the display.
The fifth line of output indicates that the router sent a SAP update to network 160:
IPXSAP: sending update to 160The format for debug ipx sap output describing a SAP update the router sends is similar to that describing a SAP update the router receives, except that the ssoc: field replaces the src: field, as the following line of output indicates:
O SAP Update type 0x2 len 96 ssoc:0x452 dest:160.ffff.ffff.ffff(452)
The ssoc:0x452 field indicates the IPX socket number of the process sending the packet at the source address. Possible values include the following:
451—Network Core Protocol
452—Service Advertising Protocol
453—Routing Information Protocol
455—NetBIOS
456—Diagnostics
4000 to 6000—Ephemeral sockets used for interaction with file servers and other network communications
Related Commands
debug ipx routing
Displays information on IPX routing packets that the router sends and receives.
debug ipx spoof
To display information about Sequenced Packet Exchange (SPX) keepalive and Internetwork Packet Exchange (IPX) watchdog packets when ipx watchdog and ipx spx-spoof are configured on the router, use the debug ipx spoof command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipx spoof
no debug ipx spoof
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
Use this command to troubleshoot connections that use SPX spoofing when SPX keepalive spoofing is enabled.
Examples
The following is sample output from the debug ipx spoof command:
Router# debug ipx spoofIPX: Tu1:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7004 4B8 8 1D 23 (new) (changed:yes) Last Changed 0IPX: Tu1:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7104 2B8 7 29 2E (new) (changed:yes) Last Changed 0IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: 80 0 2B8 7104 29 7 7 (early)IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.da75 ln= 42 tc=02, SPX: 80 0 4B8 7004 1D 8 8 (early)IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.da75 ln= 32 tc=02, watchdogIPX: local:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 32 tc=00, watchdog snetIPX: Tu1:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7004 4B8 8 1D 23 (changed:clear) Last Changed 0IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: C0 0 2B8 7104 29 7 7 (early)IPX: Tu1:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7104 2B8 7 29 2E (changed:clear) Last Changed 0IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: C0 0 2B8 7104 29 7 7 (Last Changed 272 sec)IPX: local:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, spx keepalive sent 80 0 7104 2B8 7 29 2EThe following lines show that SPX packets were seen, but they are not seen for a connection that exists in the SPX table:
IPX: Tu1:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7004 4B8 8 1D 23 (new) (changed:yes) Last Changed 0IPX: Tu1:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7104 2B8 7 29 2E (new) (changed:yes) Last Changed 0The following lines show SPX packets for connections that exist in the SPX table but that SPX idle time has not yet elapsed and spoofing has not started:
IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: 80 0 2B8 7104 29 7 7 (early)IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.da75 ln= 42 tc=02, SPX: 80 0 4B8 7004 1D 8 8 (early)The following lines show an IPX watchdog packet and the spoofed reply:
IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.da75 ln= 32 tc=02, watchdogIPX: local:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 32 tc=00, watchdog sentThe following lines show SPX packets that arrived more than two minutes after spoofing started. This situation occurs when the other sides of the SPX table are cleared. When the table is cleared, the routing processes stop spoofing the connection, which allows SPX keepalives from the local side to travel to the remote side and repopulate the SPX table.
IPX: Tu1:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7004 4B8 8 1D 23 (changed:clear) Last Changed 0IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: C0 0 2B8 7104 29 7 7 (early)IPX: Tu1:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7104 2B8 7 29 2E (changed:clear) Last Changed 0The following lines show that an SPX keepalive packet came in and was spoofed:
IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: C0 0 2B8 7104 29 7 7 (Last Changed 272 sec)IPX: local:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, spx keepalive sent 80 0 7104 2B8 7 29 2Edebug ipx spx
To display debugging messages related to the Sequenced Packet Exchange (SPX) protocol, use the debug ipx spx command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipx spx
no debug ipx spx
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
Use the debug ipx spx command to display handshaking or negotiating details between the SPX protocol and the other protocols or applications. SPX debugging messages indicate various states of SPX connections such as incoming and outgoing traffic information, timer events, and related processing of SPX connections.
Examples
The following is sample output from the debug ipx spx command:
Router# debug ipx spxSPX: Sent an SPX packetSPX: I Con Src/Dst 776E/20A0 d-strm 0 con-ctl 80SPX: I Con Src/Dst 776E/20A0 d-strm FE con-ctl 40SPX: C847C Connection close requested by peerSPX: Sent an SPX packetSPX: purge timer fired. Cleaning up C847CSPX: purging spxcon C847C from conQSPX: returning inQ buffersSPX: returning outQ buffersSPX: returning unackedQ buffersSPX: returning spxconSPX: I Con Src/Dst 786E/FFFF d-strm 0 con-ctl C0SPX: new connection request for listening socketSPX: Sent an SPX packetSPX: I Con Src/Dst 786E/20B0 d-strm 0 con-ctl 40SPX: 300 bytes data recvdSPX: Sent an SPX packetThe following line indicates an incoming SPX packet that has a source connection ID of 776E and a destination connection ID of 20A0 (both in hexadecimal). The data stream value in the SPX packet is indicated by d-strm, and the connection control value in the SPX packet is indicated by con-ctl (both in hexadecimal). All data packets received are followed by an SPX debugging message indicating the size of the packet. All control packets received are consumed internally.
SPX: I Con Src/Dst 776E/20A0 d-strm 0 con-ctl 80debug isdn
To display messages about 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}] | events | 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}] | events | mgmnt [{detail | interface bri number | serial port:number}] | q921 | q931 | standard [{interface bri number | serial port:number}] | tgrm}
Note
Syntax Description
Defaults
Commands are enabled on all interfaces unless a specific interface is specified.
Command Modes
Privileged EXEC
Command History
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 2The following report (highlighted in bold for purpose of example) is displayed when the isdn x25 dchannel q931-broadcast command is enabled to enable sharing the TEI:
Router# debug isdn events mgmnt*Jun 8 22:38:56.535: ISDN BR0 Q921: User TX -> IDREQ ri=29609 ai=127*Jun 8 22:38:56.595: ISDN BR0 Q921: User RX <- IDASSN ri=29609 ai=86*Jun 8 22:38:56.595: ISDN BR0 SERROR: L2_Go: at bailout DLCB is NULLL2: sapi 63 tei 127 ces 0 ev 0x3*Jun 8 22:38:56.595: ISDN BR0 MGMNT: LM_MDL_UI_DATA_IND: message 2 ri 29609 ai 86 switch type 9*Jun 8 22:38:56.595: ISDN BR0 MGMNT: LM_MDL_UI_DATA_IND: OVERLAP REQUEST: ces 9 using lmtr tei 85 tei 85debug isdn event
To display ISDN events occurring on the user side (on the router) of the ISDN interface, use the debug isdn event command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isdn event
no debug isdn event
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
10.0
This command was introduced.
12.4(6)T
This command was enhanced to display reports about SAPI 0 procedures that accept X.25 calls on the BRI D channel.
Usage Guidelines
Although the debug isdn event and the debug isdn q931 commands provide similar debug information, the information is displayed in a different format. If you want to see the information in both formats, enable both commands at the same time. The displays will be intermingled.
The ISDN events that can be displayed are Q.931 events (call setup and teardown of ISDN network connections).
Use the show dialer command to retrieve information about the status and configuration of the ISDN interface on the router.
Use the service timestamps debug datetime msec global configuration command to include the time with each message.
For more information on ISDN switch types, codes, and values, see Appendix B, "ISDN Switch Types, Codes, and Values."
Examples
The following is sample output from the debug isdn event command of call setup events for an outgoing call:
Router# debug isdn eventISDN Event: Call to 415555121202received HOST_PROCEEDINGChannel ID i = 0x0101-------------------Channel ID i = 0x89received HOST_CONNECTChannel ID i = 0x0101ISDN Event: Connected to 415555121202 on B1 at 64 Kb/sThe following shows sample debug isdn event output of call setup events for an incoming call. The values used for internal purposes are unpacked information elements. The values that follow the ISDN specification are an interpretation of the unpacked information elements.
Router# debug isdn eventreceived HOST_INCOMING_CALLBearer Capability i = 0x080010-------------------Channel ID i = 0x0101Calling Party Number i = 0x0000, `415555121202'IE out of order or end of `private' IEs --Bearer Capability i = 0x8890Channel ID i = 0x89Calling Party Number i = 0x0083, `415555121202'ISDN Event: Received a call from 415555121202 on B1 at 64 Kb/sISDN Event: Accepting the callreceived HOST_CONNECTChannel ID i = 0x0101ISDN Event: Connected to 415555121202 on B1 at 64 Kb/sThe following is sample output from the debug isdn event command of call teardown events for a call that has been disconnected by the host side of the connection:
Router# debug isdn eventreceived HOST_DISCONNECTISDN Event: Call to 415555121202 was hung upThe following is sample output from the debug isdn event command of a call teardown event for an outgoing or incoming call that has been disconnected by the ISDN interface on the router side:
Router# debug isdn eventISDN Event: Hangup call to call id 0x8008Table 194 describes the significant fields shown in the display.
The following is sample output from the debug isdn event command of a call teardown event for a call that has passed call screening and then has been hung up by the ISDN interface on the far end side:
Router# debug isdn eventJan 3 11:29:52.559: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0x81Jan 3 11:29:52.563: Cause i = 0x8090 - Normal call clearingThe following is sample output from the debug isdn event command of a call teardown event for a call that has not passed call screening and has been rejected by the ISDN interface on the router side:
Router# debug isdn eventJan 3 11:32:03.263: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0x85Jan 3 11:32:03.267: Cause i = 0x8095 - Call rejectedThe following is sample output from the debug isdn event command of a call teardown event for an outgoing call that uses a dialer subaddress:
Router# debug isdn eventJan 3 11:41:48.483: ISDN BR0: Event: Call to 61885:1212 at 64 Kb/sJan 3 11:41:48.495: ISDN BR0: TX -> SETUP pd = 8 callref = 0x04Jan 3 11:41:48.495: Bearer Capability i = 0x8890Jan 3 11:41:48.499: Channel ID i = 0x83Jan 3 11:41:48.503: Called Party Number i = 0x80, '61885'Jan 3 11:41:48.507: Called Party SubAddr i = 0x80, 'P1212'Jan 3 11:41:48.571: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x84Jan 3 11:41:48.575: Channel ID i = 0x89Jan 3 11:41:48.587: ISDN BR0: Event: incoming ces value = 1Jan 3 11:41:48.587: ISDN BR0: received HOST_PROCEEDINGChannel ID i = 0x0101Jan 3 11:41:48.591: -------------------Channel ID i = 0x89Jan 3 11:41:48.731: ISDN BR0: RX <- CONNECT pd = 8 callref = 0x84Jan 3 11:41:48.743: ISDN BR0: Event: incoming ces value = 1Jan 3 11:41:48.743: ISDN BR0: received HOST_CONNECTChannel ID i = 0x0101Jan 3 11:41:48.747: -------------------%LINK-3-UPDOWN: Interface BRI0:1 changed state to upJan 3 11:41:48.771: ISDN BR0: Event: Connected to 61885:1212 on B1 at 64 Kb/sJan 3 11:41:48.775: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x04%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up%ISDN-6-CONNECT: Interface BRI0:1 is now connected to 61885:1212 goodieThe output is similar to the output of debug isdn q931. Refer to the debug isdn q931 command for detailed field descriptions.
The following is sample output from the debug isdn event command of call setup events for a successful callback for legacy DDR:
Router# debug isdn eventBRI0:Caller id Callback server starting to spanky 81012345678902: Callback timer expiredBRI0:beginning callback to spanky 81012345678902BRI0: Attempting to dial 81012345678902The following is sample output from the debug isdn event command for a callback that was unsuccessful because the router had no dialer map for the calling number:
Router# debug isdn eventBRI0:Caller id 81012345678902 callback - no matching mapTable 195 describes the significant fields shown in the display.
The following is sample output from the debug isdn event command for a callback that was successful when the dialer profiles DDR feature is configured:
*Mar 1 00:46:51.827: BR0:1:Caller id 81012345678901 matched to profile delorean*Mar 1 00:46:51.827: Dialer1:Caller id Callback server starting to delorean 81012345678901*Mar 1 00:46:54.151: : Callback timer expired*Mar 1 00:46:54.151: Dialer1:beginning callback to delorean 81012345678901*Mar 1 00:46:54.155: Freeing callback to delorean 81012345678901*Mar 1 00:46:54.155: BRI0: Dialing cause Callback return call*Mar 1 00:46:54.155: BRI0: Attempting to dial 81012345678901*Mar 1 00:46:54.503: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up*Mar 1 00:46:54.523: %DIALER-6-BIND: Interface BRI0:2 bound to profile Dialer1*Mar 1 00:46:55.139: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, changed state to up*Mar 1 00:46:58.187: %ISDN-6-CONNECT: Interface BRI0:2 is now connected to 81012345678901 deloreanThe following example provides information about accepting X.25 calls on the ISDN D channel (for purpose of example, bold type indicates messages of interest in the following output):
Router# debug isdn event*Sep 28 12:34:29.747: ISDN BR1/1 EVENTd: isdn_host_packet_mode_events: Host packet call received call id 0xBTable 196 describes the significant fields of call setup events for a successful callback for the sample output from the debug isdn event command when the dialer profiles DDR feature is configured.
Related Commands
debug isdn q921
To display data link layer (Layer 2) access procedures that are taking place at the router on the D channel (Link Access Procedure or LAPD) of its ISDN interface, use the debug isdn q921 command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isdn q921 [detail | frame | interface [bri number]]
no debug isdn q921 [detail | frame | interface]
Syntax Description
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
12.0
This command was introduced.
12.2(15)ZJ
The detail and frame keywords were added.
12.3(4)T
This command was integrated into Cisco IOS Release 12.3(4)T.
Usage Guidelines
The ISDN data link layer interface provided by the router conforms to the user interface specification defined by ITU-T recommendation Q.921. The debug isdn q921 command output is limited to commands and responses exchanged during peer-to-peer communication carried over the D channel. This debug information does not include data transmitted over the B channels that are also part of the router ISDN interface. The peers (data link layer entities and layer management entities on the routers) communicate with each other with an ISDN switch over the D channel.
Note
A router can be the calling or called party of the ISDN Q.921 data link layer access procedures. If the router is the calling party, the command displays information about an outgoing call. If the router is the called party, the command displays information about an incoming call and the keepalives.
The debug isdn q921 command can be used with the debug isdn event, debug isdn q931, debug isdn q921 frame, and debug isdn q921 detail commands at the same time. The displays are intermingled.
Use the service timestamps debug datetime msec global configuration command to include the time with each message.
Examples
The following is example output for a single active data link connection (DLC). The debugs turned on are debug isdn q921, debug isdn q921 frame, and debug isdn q921 detail. In the debugs below, "Q921" followed by a colon (:) indicates that debug isdn q921 has been entered. "Q921" followed by the letter "f" indicates that debug isdn q921 frame has been entered. "Q921" followed by the letter "d" indicates that debug isdn q921 detail has been entered.
The following output shows that the L2 frame is received. The first two octets form the address field; the third octet forms the control field. The address field identifies the originator of a frame and whether it is a command or a response. The second octet of the address field identifies the DLC with which the frame is associated. The control field (third octet) contains the frame type code and sequence number information.
00:12:10:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT00:12:10:ISDN Se1:15 Q921f:PBXb RX <- 0x0E03EFThe following output interprets the octet information. String "PBXb" indicates that the side receiving (RX) this frame is acting as a PBXb (as opposed to PBXa, which is the other possibility). This example also gives information about the type of frame received (SABMR), the associated DLC (1), the frame type code received from the control field (cntl=SABMR), and the sequence number (indicated by nbit, which is 0 in this case).
00:12:10:ISDN Se1:15 Q921:PBXb RX <- SABMR dlci=1 cntl=SABMR nbit=0The following output shows information received from the driver (source_id of x200) showing an L2 frame (event x141). This results from the SABMR frame that was received from the peer PBX (v_bit and chan do not have any significance in this case).
00:12:10:ISDN Se1:15 Q921d:process_rxdata:Frame sent to L200:12:10:ISDN Q921d:isdn_from_driver_process:event_count 300:12:10:ISDN Se1:15 Q921d:dpnss_l2_main:source_id x200 event x141 v_bit x0 chan x0The following output shows that DPNSS L2 for DLC 1 (chan 1) has received an SABMR frame (event x0) in the IDLE state (s_dpnss_idle):
00:12:10:ISDN Se1:15 Q921d:s_dpnss_idle:event x0 chan 1The following output shows that for DLC 1 (chan 1 above), a UA frame (event x1) needs to be sent to the driver (dest x200):
00:12:10:ISDN Se1:15 Q921d:dpnss_l2_mail:dest x200 event x1 v_bit 1 chan 1 out_pkt x630531A4The following output shows that for DLC 1, a DL_EST_IND (event x201) needs to be sent to L3 (DUA in this case because of the backhauling) indicating that this DLC is now up (in RESET COMPLETE state):
00:12:10:ISDN Se1:15 Q921d:dpnss_l2_mail:dest x300 event x201 v_bit 1 chan 1 out_pkt x0The following output shows that the L2 frame is transmitted (TX):
00:12:10:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT00:12:10:ISDN Se1:15 Q921f:PBXb TX -> 0x0E0363The following output shows that string "PBXb" is the side transmitting (TX) and that this frame is acting as PBX B. This example also gives information about the associated DLC (1), the frame type code transmitted from the control field (cntl=UA), and the sequence number (indicated by nbit, which is 0 in this case).
00:12:10:ISDN Se1:15 Q921:PBXb TX -> UA dlci=1 cntl=UA nbit=0The following is complete debugging output from a DPNSS call:
Jan 8 17:24:43.499:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:43.499:ISDN Se2/0:15 Q921f:PBXa TX -> 0x440303Jan 8 17:24:43.499:ISDN Se2/0:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=0Jan 8 17:24:43.499:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:43.503:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:43.503:ISDN Se2/0:15 Q921f:PBXa RX <-0x44030300102A34232A35302A33333330Jan 8 17:24:43.503: 30303031233434343030303031Jan 8 17:24:43.503:ISDN Se2/0:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=0i=0x00102A34232A35302A3333333030303031233434343030303031Jan 8 17:24:43.503:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:43.503:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:43.507:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:43.507:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:24:43.507:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x63F183D4Jan 8 17:24:43.507:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:43.507:ISDN Se2/0:15 Q921f:PBXa TX -> 0x440303Jan 8 17:24:43.507:ISDN Se2/0:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=0Jan 8 17:24:43.507:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:43.515:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:43.515:ISDN Se2/0:15 Q921f:PBXa RX <-0x44030300102A34232A35302A33333330Jan 8 17:24:43.515: 30303031233434343030303031Jan 8 17:24:43.515:ISDN Se2/0:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=0i=0x00102A34232A35302A3333333030303031233434343030303031Jan 8 17:24:43.515:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:43.515:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:43.515:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:43.515:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:24:43.515:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x63F183D4Jan 8 17:24:43.515:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:43.519:ISDN Se2/0:15 Q921f:PBXa TX -> 0x440303Jan 8 17:24:43.519:ISDN Se2/0:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=0Jan 8 17:24:43.519:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:43.599:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x4 event x240v_bit x0 chan x2Jan 8 17:24:43.599:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:eventx240 chan 1Jan 8 17:24:43.599:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x2v_bit 1 chan 1 out_pkt x63EE5780Jan 8 17:24:43.599:ISDN Se2/1:15 LIFd:LIF_StartTimer:timer (0x63E569A8),ticks (500), event (0x1201)Jan 8 17:24:43.599:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:43.599:ISDN Se2/1:15 Q921f:PBXa TX ->0x46030300102A31232A35302A33333330Jan 8 17:24:43.599: 30303031233434343030303031Jan 8 17:24:43.599:ISDN Se2/1:15 Q921:PBXa TX -> UI(C) dlci=1 cntl=UI nbit=0i=0x00102A31232A35302A3333333030303031233434343030303031Jan 8 17:24:43.599:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:43.623:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:43.623:ISDN Se2/1:15 Q921f:PBXa RX <- 0x460303Jan 8 17:24:43.623:ISDN Se2/1:15 Q921:PBXa RX <- UI(R) dlci=1 cntl=UI nbit=0Jan 8 17:24:43.623:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:43.623:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:43.627:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:43.627:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x3chan 1Jan 8 17:24:43.719:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:43.719:ISDN Se2/1:15 Q921f:PBXa RX <-0x440313092A34232A35302A3434343030Jan 8 17:24:43.719: 303031232A31382A33312A33312A3331Jan 8 17:24:43.719: 23Jan 8 17:24:43.719:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1i=0x092A34232A35302A3434343030303031232A31382A33312A33312A333123Jan 8 17:24:43.719:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:43.719:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:43.719:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:43.719:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:24:43.719:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x300 event x241v_bit 1 chan 1 out_pkt x63EE5780Jan 8 17:24:43.719:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x63EE57CCJan 8 17:24:43.723:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:43.723:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313Jan 8 17:24:43.723:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:24:43.723:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:43.727:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:43.727:ISDN Se2/1:15 Q921f:PBXa RX <-0x440313092A34232A35302A3434343030Jan 8 17:24:43.727: 303031232A31382A33312A33312A3331Jan 8 17:24:43.727: 23Jan 8 17:24:43.727:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1i=0x092A34232A35302A3434343030303031232A31382A33312A33312A333123Jan 8 17:24:43.727:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:43.727:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:43.731:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:43.731:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:24:43.731:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x63EE57CCJan 8 17:24:43.731:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:43.731:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313Jan 8 17:24:43.731:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:24:43.731:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:43.739:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:43.739:ISDN Se2/1:15 Q921f:PBXa RX <-0x440313092A34232A35302A3434343030Jan 8 17:24:43.739: 303031232A31382A33312A33312A3331Jan 8 17:24:43.739: 23Jan 8 17:24:43.739:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1i=0x092A34232A35302A3434343030303031232A31382A33312A33312A333123Jan 8 17:24:43.739:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:43.739:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:43.739:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:43.739:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:24:43.739:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x63EE57CCJan 8 17:24:43.739:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:43.743:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313Jan 8 17:24:43.743:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:24:43.743:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:43.787:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x4 event x240v_bit x0 chan x2Jan 8 17:24:43.787:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:eventx240 chan 1Jan 8 17:24:43.787:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x2v_bit 1 chan 1 out_pkt x636B1B64Jan 8 17:24:43.787:ISDN Se2/0:15 LIFd:LIF_StartTimer:timer (0x63A4AFBC),ticks (500), event (0x1201)Jan 8 17:24:43.791:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:43.791:ISDN Se2/0:15 Q921f:PBXa TX ->0x460313092A31232A35302A3434343030Jan 8 17:24:43.791: 30303123Jan 8 17:24:43.791:ISDN Se2/0:15 Q921:PBXa TX -> UI(C) dlci=1 cntl=UI nbit=1i=0x092A31232A35302A343434303030303123Jan 8 17:24:43.791:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:43.811:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:43.811:ISDN Se2/0:15 Q921f:PBXa RX <- 0x460313Jan 8 17:24:43.811:ISDN Se2/0:15 Q921:PBXa RX <- UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:24:43.811:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:43.811:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:43.811:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:43.811:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x3chan 1Jan 8 17:24:52.107:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:52.107:ISDN Se2/1:15 Q921f:PBXa RX <-0x440303052A34232A35302A3434343030Jan 8 17:24:52.107: 303031232A31382A33312A33312A3331Jan 8 17:24:52.107: 23Jan 8 17:24:52.107:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=0i=0x052A34232A35302A3434343030303031232A31382A33312A33312A333123Jan 8 17:24:52.107:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:52.107:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:52.111:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:52.111:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:24:52.111:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x300 event x241v_bit 1 chan 1 out_pkt x63F19CC8Jan 8 17:24:52.111:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x63F19D14Jan 8 17:24:52.111:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:52.111:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440303Jan 8 17:24:52.111:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=0Jan 8 17:24:52.111:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:52.119:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:52.119:ISDN Se2/1:15 Q921f:PBXa RX <-0x440303052A34232A35302A3434343030Jan 8 17:24:52.119: 303031232A31382A33312A33312A3331Jan 8 17:24:52.119: 23Jan 8 17:24:52.119:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=0i=0x052A34232A35302A3434343030303031232A31382A33312A33312A333123Jan 8 17:24:52.119:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:52.119:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:52.119:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0x141 v_bit x0 chan x0Jan 8 17:24:52.119:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:24:52.119:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x63F19D14Jan 8 17:24:52.119:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:52.123:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440303Jan 8 17:24:52.123:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=0Jan 8 17:24:52.123:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:52.127:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:52.127:ISDN Se2/1:15 Q921f:PBXa RX <-0x440303052A34232A35302A3434343030Jan 8 17:24:52.127: 303031232A31382A33312A33312A3331Jan 8 17:24:52.127: 23Jan 8 17:24:52.127:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=0i=0x052A34232A35302A3434343030303031232A31382A33312A33312A333123Jan 8 17:24:52.127:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:52.127:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:52.131:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:52.131:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:24:52.131:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x63F19D14Jan 8 17:24:52.131:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:52.131:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440303Jan 8 17:24:52.131:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=0Jan 8 17:24:52.131:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:52.159:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x4 event x240v_bit x0 chan x2Jan 8 17:24:52.159:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:eventx240 chan 1Jan 8 17:24:52.159:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x2v_bit 1 chan 1 out_pkt x63F19CC8Jan 8 17:24:52.159:ISDN Se2/0:15 LIFd:LIF_StartTimer:timer (0x63A4AFBC),ticks (500), event (0x1201)Jan 8 17:24:52.159:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:24:52.159:ISDN Se2/0:15 Q921f:PBXa TX ->0x460303052A35302A3434343030303031Jan 8 17:24:52.159: 23Jan 8 17:24:52.159:ISDN Se2/0:15 Q921:PBXa TX -> UI(C) dlci=1 cntl=UI nbit=0i=0x052A35302A343434303030303123Jan 8 17:24:52.159:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:24:52.179:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:52.179:ISDN Se2/0:15 Q921f:PBXa RX <- 0x460303Jan 8 17:24:52.179:ISDN Se2/0:15 Q921:PBXa RX <- UI(R) dlci=1 cntl=UI nbit=0Jan 8 17:24:52.179:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:52.183:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:52.183:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:52.183:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x3chan 1Jan 8 17:25:31.811:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:25:31.811:ISDN Se2/0:15 Q921f:PBXa RX <- 0x4403130830Jan 8 17:25:31.811:ISDN Se2/0:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1i=0x0830Jan 8 17:25:31.811:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:25:31.811:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:25:31.811:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:25:31.811:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:25:31.811:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x300 event x241v_bit 1 chan 1 out_pkt x63F1806CJan 8 17:25:31.811:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x636710B8Jan 8 17:25:31.815:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:25:31.815:ISDN Se2/0:15 Q921f:PBXa TX -> 0x440313Jan 8 17:25:31.815:ISDN Se2/0:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:25:31.815:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:25:31.819:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:25:31.819:ISDN Se2/0:15 Q921f:PBXa RX <- 0x4403130830Jan 8 17:25:31.819:ISDN Se2/0:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1i=0x0830Jan 8 17:25:31.819:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:25:31.819:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:25:31.823:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:25:31.823:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:25:31.823:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x63F19CC8Jan 8 17:25:31.823:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:25:31.823:ISDN Se2/0:15 Q921f:PBXa TX -> 0x440313Jan 8 17:25:31.823:ISDN Se2/0:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:25:31.823:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:25:31.831:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:25:31.831:ISDN Se2/0:15 Q921f:PBXa RX <- 0x4403130830Jan 8 17:25:31.831:ISDN Se2/0:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1i=0x0830Jan 8 17:25:31.831:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:25:31.831:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:25:31.831:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:25:31.831:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:25:31.831:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x636710B8Jan 8 17:25:31.835:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:25:31.835:ISDN Se2/0:15 Q921f:PBXa TX -> 0x440313Jan 8 17:25:31.835:ISDN Se2/0:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:25:31.835:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:25:31.851:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x4 event x240v_bit x0 chan x2Jan 8 17:25:31.851:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:eventx240 chan 1Jan 8 17:25:31.851:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x2v_bit 1 chan 1 out_pkt x63F1806CJan 8 17:25:31.851:ISDN Se2/1:15 LIFd:LIF_StartTimer:timer (0x63E569A8),ticks (500), event (0x1201)Jan 8 17:25:31.851:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:25:31.855:ISDN Se2/1:15 Q921f:PBXa TX -> 0x4603130830Jan 8 17:25:31.855:ISDN Se2/1:15 Q921:PBXa TX -> UI(C) dlci=1 cntl=UI nbit=1i=0x0830Jan 8 17:25:31.855:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:25:31.875:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:25:31.875:ISDN Se2/1:15 Q921f:PBXa RX <- 0x460313Jan 8 17:25:31.875:ISDN Se2/1:15 Q921:PBXa RX <- UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:25:31.875:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:25:31.875:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:25:31.875:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:25:31.875:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x3chan 1Jan 8 17:25:31.879:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x4 event x240v_bit x0 chan x2Jan 8 17:25:31.879:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:eventx240 chan 1Jan 8 17:25:31.879:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x2v_bit 1 chan 1 out_pkt x63EFC5ACJan 8 17:25:31.879:ISDN Se2/0:15 LIFd:LIF_StartTimer:timer (0x63A4AFBC),ticks (500), event (0x1201)Jan 8 17:25:31.879:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:25:31.879:ISDN Se2/0:15 Q921f:PBXa TX -> 0x4603130830Jan 8 17:25:31.879:ISDN Se2/0:15 Q921:PBXa TX -> UI(C) dlci=1 cntl=UI nbit=1i=0x0830Jan 8 17:25:31.883:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:25:31.899:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:25:31.899:ISDN Se2/0:15 Q921f:PBXa RX <- 0x460313Jan 8 17:25:31.899:ISDN Se2/0:15 Q921:PBXa RX <- UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:25:31.899:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:25:31.899:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:25:31.903:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:25:31.903:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x3chan 1Jan 8 17:25:32.063:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:25:32.063:ISDN Se2/1:15 Q921f:PBXa RX <- 0x4403130830Jan 8 17:25:32.063:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1i=0x0830Jan 8 17:25:32.063:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:25:32.063:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:25:32.067:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:25:32.067:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:25:32.067:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x300 event x241v_bit 1 chan 1 out_pkt x63EFC5ACJan 8 17:25:32.067:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x6367175CJan 8 17:25:32.067:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:25:32.067:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313Jan 8 17:25:32.067:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:25:32.067:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:25:32.075:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:25:32.075:ISDN Se2/1:15 Q921f:PBXa RX <- 0x4403130830Jan 8 17:25:32.075:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1i=0x0830Jan 8 17:25:32.075:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:25:32.075:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:25:32.075:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:25:32.075:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:25:32.075:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x6367175CJan 8 17:25:32.075:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:25:32.075:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313Jan 8 17:25:32.079:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:25:32.079:ISDN Q921d:isdn_l2d_srq_process:event_count 1Jan 8 17:25:32.083:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:25:32.083:ISDN Se2/1:15 Q921f:PBXa RX <- 0x4403130830Jan 8 17:25:32.083:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1i=0x0830Jan 8 17:25:32.083:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:25:32.083:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:25:32.087:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:25:32.087:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2chan 1Jan 8 17:25:32.087:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x6367175CJan 8 17:25:32.087:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENTJan 8 17:25:32.087:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313Jan 8 17:25:32.087:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1Jan 8 17:25:32.087:ISDN Q921d:isdn_l2d_srq_process:event_count 1The following output shows details of the preceding debugging events.
The first two octets (0x4403) form the address field, while the third octet (0x03) is the control field. All the octets starting from the fourth constitute DPNSS L3 information, which needs to be backhauled to the Cisco PGW2200.
Jan 8 17:24:43.495:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENTJan 8 17:24:43.495:ISDN Se2/0:15 Q921f:PBXa RX <- 0x44030300102A34232A35302A33333330Jan 8 17:24:43.495: 30303031233434343030303031All of the octets following "i=" constitute DPNSS L3 information received from the peer:
Jan 8 17:24:43.495:ISDN Se2/0:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=0i=0x00102A34232A35302A3333333030303031233434343030303031In the INFORMATION TRANSFER state, DLC 1 received a UI(C) frame (event x2) from the peer carrying DPNSS L3 information:
Jan 8 17:24:43.495:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2Jan 8 17:24:43.495:ISDN Q921d:isdn_from_driver_process:event_count 1Jan 8 17:24:43.495:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 eventx141 v_bit x0 chan x0Jan 8 17:24:43.495:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x2 chan 1For DLC 1, event information is sent to L3 (IUA BACKHAUL, indicated by dest x300). In this case, DL_DATA_IND (event x241) indicates that some L3 information has been received from the peer.
Jan 8 17:24:43.495:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x300 event x241v_bit 1 chan 1 out_pkt x6367175CInformation is sent to the driver (dest x200), which is then sent to the peer): An Unnumbered Information—Response [UI(R)] (event x3) acknowledges the received Unnumbered Information—Command [UI(C)].
Jan 8 17:24:43.495:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x3v_bit 1 chan 1 out_pkt x63F183D4The following is sample output from the debug isdn q921 command for an outgoing call:
Router# debug isdn q921Jan 3 14:52:24.475: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 5 nr = 2i = 0x08010705040288901801837006803631383835Jan 3 14:52:24.503: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 6Jan 3 14:52:24.527: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 2 nr = 6i = 0x08018702180189Jan 3 14:52:24.535: ISDN BR0: TX -> RRr sapi = 0 tei = 64 nr = 3Jan 3 14:52:24.643: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 3 nr = 6i = 0x08018707Jan 3 14:52:24.655: ISDN BR0: TX -> RRr sapi = 0 tei = 64 nr = 4%LINK-3-UPDOWN: Interface BRI0:1, changed state to upJan 3 14:52:24.683: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 6 nr = 4i = 0x0801070FJan 3 14:52:24.699: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 7%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up%ISDN-6-CONNECT: Interface BRI0:1 is now connected to 61885 goodieJan 3 14:52:34.415: ISDN BR0: RX <- RRp sapi = 0 tei = 64 nr = 7Jan 3 14:52:34.419: ISDN BR0: TX -> RRf sapi = 0 tei = 64 nr = 4In the following lines, the seventh and eighth most significant hexadecimal numbers indicate the type of message. 0x05 indicates a Call Setup message, 0x02 indicates a Call Proceeding message, 0x07 indicates a Call Connect message, and 0x0F indicates a Connect Ack message.
Jan 3 14:52:24.475: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 5 nr = 2i = 0x08010705040288901801837006803631383835Jan 3 14:52:24.527: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 2 nr = 6i = 0x08018702180189Jan 3 14:52:24.643: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 3 nr = 6i = 0x08018707Jan 3 14:52:24.683: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 6 nr = 4i = 0x0801070FThe following is sample output from the debug isdn q921 command for a startup message on a DMS-100 switch:
Router# debug isdn q921Jan 3 14:47:28.455: ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127 0Jan 3 14:47:30.171: ISDN BR0: TX -> IDREQ ri = 31815 ai = 127Jan 3 14:47:30.219: ISDN BR0: RX <- IDASSN ri = 31815 ai = 64Jan 3 14:47:30.223: ISDN BR0: TX -> SABMEp sapi = 0 tei = 64Jan 3 14:47:30.227: ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127Jan 3 14:47:30.235: ISDN BR0: TX -> IDCKRP ri = 16568 ai = 64Jan 3 14:47:30.239: ISDN BR0: RX <- UAf sapi = 0 tei = 64Jan 3 14:47:30.247: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 0 nr = 0i = 0x08007B3A03313233Jan 3 14:47:30.267: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 1Jan 3 14:47:34.243: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 1 nr = 0i = 0x08007B3A03313233Jan 3 14:47:34.267: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 2Jan 3 14:47:43.815: ISDN BR0: RX <- RRp sapi = 0 tei = 64 nr = 2Jan 3 14:47:43.819: ISDN BR0: TX -> RRf sapi = 0 tei = 64 nr = 0Jan 3 14:47:53.819: ISDN BR0: TX -> RRp sapi = 0 tei = 64 nr = 0The first seven lines of this example indicate a Layer 2 link establishment.
The following lines indicate the message exchanges between the data link layer entity on the local router (user side) and the assignment source point (ASP) on the network side during the TEI assignment procedure. This assumes that the link is down and no TEI currently exists.
Jan 3 14:47:30.171: ISDN BR0: TX -> IDREQ ri = 31815 ai = 127Jan 3 14:47:30.219: ISDN BR0: RX <- IDASSN ri = 31815 ai = 64At 14:47:30.171, the local router data link layer entity sent an Identity Request message to the network data link layer entity to request a TEI value that can be used in subsequent communication between the peer data link layer entities. The request includes a randomly generated reference number (31815) to differentiate among user devices that request automatic TEI assignment and an action indicator of 127 to indicate that the ASP can assign any TEI value available. The ISDN user interface on the router uses automatic TEI assignment.
At 14:47:30.219, the network data link entity responds to the Identity Request message with an Identity Assigned message. The response includes the reference number (31815) previously sent in the request and TEI value (64) assigned by the ASP.
The following lines indicate the message exchanges between the layer management entity on the network and the layer management entity on the local router (user side) during the TEI check procedure:
Jan 3 14:47:30.227: ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127Jan 3 14:47:30.235: ISDN BR0: TX -> IDCKRP ri = 16568 ai = 64At 14:47:30.227, the layer management entity on the network sends the Identity Check Request message to the layer management entity on the local router to check whether a TEI is in use. The message includes a reference number that is always 0 and the TEI value to check. In this case, an ai value of 127 indicates that all TEI values should be checked. At 14:47:30.227, the layer management entity on the local router responds with an Identity Check Response message indicating that TEI value 64 is currently in use.
The following lines indicate the messages exchanged between the data link layer entity on the local router (user side) and the data link layer on the network side to place the network side into modulo 128 multiple frame acknowledged operation. Note that the data link layer entity on the network side also can initiate the exchange.
Jan 3 14:47:30.223: ISDN BR0: TX -> SABMEp sapi = 0 tei = 64Jan 3 14:47:30.239: ISDN BR0: RX <- UAf sapi = 0 tei = 64At 14:47:30.223, the data link layer entity on the local router sends the SABME command with a SAPI of 0 (call control procedure) for TEI 64. At 14:47:30.239, the first opportunity, the data link layer entity on the network responds with a UA response. This response indicates acceptance of the command. The data link layer entity sending the SABME command may need to send it more than once before receiving a UA response.
The following lines indicate the status of the data link layer entities. Both are ready to receive I frames.
Jan 3 14:47:43.815: ISDN BR0: RX <- RRp sapi = 0 tei = 64 nr = 2Jan 3 14:47:43.819: ISDN BR0: TX -> RRf sapi = 0 tei = 64 nr = 0These I-frames are typically exchanged every 10 seconds (T203 timer).
The following is sample output from the debug isdn q921 command for an incoming call. It is an incoming SETUP message that assumes that the Layer 2 link is already established to the other side.
Router# debug isdn q921Jan 3 14:49:22.507: ISDN BR0: TX -> RRp sapi = 0 tei = 64 nr = 0Jan 3 14:49:22.523: ISDN BR0: RX <- RRf sapi = 0 tei = 64 nr = 2Jan 3 14:49:32.527: ISDN BR0: TX -> RRp sapi = 0 tei = 64 nr = 0Jan 3 14:49:32.543: ISDN BR0: RX <- RRf sapi = 0 tei = 64 nr = 2Jan 3 14:49:42.067: ISDN BR0: RX <- RRp sapi = 0 tei = 64 nr = 2Jan 3 14:49:42.071: ISDN BR0: TX -> RRf sapi = 0 tei = 64 nr = 0Jan 3 14:49:47.307: ISDN BR0: RX <- UI sapi = 0 tei = 127i = 0x08011F05040288901801897006C13631383836%LINK-3-UPDOWN: Interface BRI0:1, changed state to upJan 3 14:49:47.347: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 2 nr = 0i = 0x08019F07180189Jan 3 14:49:47.367: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 3Jan 3 14:49:47.383: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 0 nr = 3i = 0x08011F0F180189Jan 3 14:49:47.391: ISDN BR0: TX -> RRr sapi = 0 tei = 64 nr = 1%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to upTable 197 describes the significant fields shown in the display.
Related Commands
debug isdn q931
To display information about call setup and teardown of ISDN network connections (Layer 3) between the local router (user side) and the network, use the debug isdn q931 command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isdn q931
no debug isdn q931
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The ISDN network layer interface provided by the router conforms to the user interface specification defined by ITU-T recommendation Q.931, supplemented by other specifications such as for switch type VN4. The router tracks only activities that occur on the user side, not the network side, of the network connection. The display information debug isdn q931 command output is limited to commands and responses exchanged during peer-to-peer communication carried over the D channel. This debug information does not include data sent over the B channels, which are also part of the router's ISDN interface. The peers (network layers) communicate with each other via an ISDN switch over the D channel.
A router can be the calling or the called party of the ISDN Q.931 network connection call setup and teardown procedures. If the router is the calling party, the command displays information about an outgoing call. If the router is the called party, the command displays information about an incoming call.
This command decodes parameters of the Facility IE and displays them as text, along with parameter values as they are applicable and as they are relevant to the operation. In addition, the ASN.1 encoded Notification structure of the Notification-Indicator IE is decoded.
You can use the debug isdn q931 command with the debug isdn event and the debug isdn q921 commands at the same time. The displays will be intermingled. Use the service timestamps debug datetime msec global configuration command to include the time with each message.
Examples
The following is sample output from the debug isdn q931 command of a call setup procedure for an outgoing call:
Router# debug isdn q931TX -> SETUP pd = 8 callref = 0x04Bearer Capability i = 0x8890Channel ID i = 0x83Called Party Number i = 0x80, `415555121202'RX <- CALL_PROC pd = 8 callref = 0x84Channel ID i = 0x89RX <- CONNECT pd = 8 callref = 0x84TX -> CONNECT_ACK pd = 8 callref = 0x04....Success rate is 0 percent (0/5)The following is sample output from the debug isdn q931 command of a call setup procedure for an incoming call:
Router# debug isdn q931RX <- SETUP pd = 8 callref = 0x06Bearer Capability i = 0x8890Channel ID i = 0x89Calling Party Number i = 0x0083, `81012345678902'TX -> CONNECT pd = 8 callref = 0x86RX <- CONNECT_ACK pd = 8 callref = 0x06The following is sample output from the debug isdn q931 command that shows the contents of the Facility IE. The following example uses the supplementary service Malicious Call Identification (MCID). In this service, the router sends out the Facility IE.
Router# debug isdn q931Sep 20 04:09:38.335 UTC: ISDN Se7/1:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x0007Cause i = 0x8290 - Normal call clearingFacility i = 0x91A106020107020103Protocol Profile = Remote Operations Protocol0xA106020107020103Component = Invoke componentInvoke Id = 7 <MCID>Operation = MCIDRequestThe following is sample output from the debug isdn q931 command of a call teardown procedure from the network:
Router# debug isdn q931RX <- DISCONNECT pd = 8 callref = 0x84Cause i = 0x8790Looking Shift to Codeset 6Codeset 6 IE 0x1 1 0x82 `10'TX -> RELEASE pd = 8 callref = 0x04Cause i = 0x8090RX <- RELEASE_COMP pd = 8 callref = 0x84Table 198 describes the significant fields shown in the displays, in alphabetical order.
For purpose of example, bold text in the following example indicates the acceptance of an incoming X.25 call on the ISDN D channel, per ITU Q.931 SAPI value 0 procedures:
Router# debug isdn q931*Sep 28 12:34:29.739: ISDN BR1/1 Q931: RX <- SETUP pd = 8 callref = 0x5C (re-assembled)Bearer Capability i = 0x88C0C2E6Standard = CCITTTransfer Capability = Unrestricted DigitalTransfer Mode = PacketTransfer Rate = Packet - not specifiedUser Info L2 Protocol = Recommendation Q921/I.441User Info L3 Protocol = Recommendation X.25, Packet LayerChannel ID i = 0x8CExclusive, No B-channelInformation Rate i = 0x8888Packet Layer Binary Params i = 0x80Packet Layer Window Size i = 0x8282Packet Size i = 0x8888Calling Party Number i = 0x0083, '144014384106'Plan:Unknown, Type:UnknownUser-User i = 0x02CC000000The command output is intermingled with information from the debug isdn events command; see the description for the debug isdn events command to understand significant fields displayed in this report
Related Commands
debug isdn tgrm
To view ISDN trunk group resource manager information, use the debug isdn tgrm command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isdn tgrm
no debug isdn tgrm
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Disable console logging and use buffered logging before using the debug isdn tgrm command. Using the debug isdn tgrm command generates a large volume of debugs, which can affect router performance.
Examples
Sample output from the debug isdn tgrm command is shown below.
The output shows that the channel used (bchan) is 1, service state is 0 (in-service), call_state is 2 (busy), "false busy" is 0, and DSL is 2. The output also shows that the B channel is 1, the channel is available, and the call state is transitioned from 0 (idle) to 2 (busy).
The last two lines of output shows that bchan is 1, call state is 1 (busy), call type is 2 (voice), and call direction is 1 (incoming).
00:26:31:ISDN:get_tgrm_avail_state:idb 0x64229380 bchan 1 service_state 0 call_state 2 false busy 0x0 dsl 200:26:31:ISDN:update_tgrm_call_status:idb 0x64229380 bchan 1 availability state 1 call state(prev,new) (0,2), dsl 200:26:31:ISDN:Calling TGRM with tgrm_call_isdn_update:idb 0x64229380 bchan 1 call state 1 call type 2 call dir 1Table 199 provides an alphabetical listing of the fields shown in the debug isdn tgrm command output and a description of each field.
Related Commands
debug isis adj packets
To display information on all adjacency-related activity such as hello packets sent and received and Intermediate System-to-Intermediate System (IS-IS) adjacencies going up and down, use the debug isis adj packets command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isis adj packets [interface]
no debug isis adj packets [interface]
Syntax Description
Command Modes
Privileged EXEC
Examples
The following is sample output from the debug isis adj packets command:
Router# debug isis adj packetsISIS-Adj: Rec L1 IIH from 0000.0c00.40af (Ethernet0), cir type 3, cir id BBBB.BBBB.BBBB.01ISIS-Adj: Rec L2 IIH from 0000.0c00.40af (Ethernet0), cir type 3, cir id BBBB.BBBB.BBBB.01ISIS-Adj: Rec L1 IIH from 0000.0c00.0c36 (Ethernet1), cir type 3, cir id CCCC.CCCC.CCCC.03ISIS-Adj: Area mismatch, level 1 IIH on Ethernet1ISIS-Adj: Sending L1 IIH on Ethernet1ISIS-Adj: Sending L2 IIH on Ethernet1ISIS-Adj: Rec L2 IIH from 0000.0c00.0c36 (Ethernet1), cir type 3, cir id BBBB.BBBB.BBBB.03The following line indicates that the router received an IS-IS hello packet (IIH) on Ethernet interface 0 from the Level 1 router (L1) at MAC address 0000.0c00.40af. The circuit type is the interface type:
1—Level 1 only; 2—Level 2 only; 3—Level 1/2The circuit ID is what the neighbor interprets as the designated router for the interface.
ISIS-Adj: Rec L1 IIH from 0000.0c00.40af (Ethernet0), cir type 3, cir id BBBB.BBBB.BBBB.01The following line indicates that the router (configured as a Level 1 router) received on Ethernet interface 1 is an IS-IS hello packet from a Level 1 router in another area, thereby declaring an area mismatch:
ISIS-Adj: Area mismatch, level 1 IIH on Ethernet1The following lines indicates that the router (configured as a Level 1/Level 2 router) sent on Ethernet interface 1 is a Level 1 IS-IS hello packet, and then a Level 2 IS-IS packet:
ISIS-Adj: Sending L1 IIH on Ethernet1ISIS-Adj: Sending L2 IIH on Ethernet1debug isis authentication
To enable debugging of Intermediate System-to-Intermediate System (IS-IS) authentication, use the debug isis authentication command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isis authentication information
no debug isis authentication information
Syntax Description
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
12.0(21)ST
This command was introduced.
12.2(13)T
This command was integrated into Cisco IOS Release 12.2(13)T.
Examples
The following is sample output from the debug isis authentication command with the information keyword:
Router# debug isis authentication information3d03h:ISIS-AuthInfo:No auth TLV found in received packet3d03h:ISIS-AuthInfo:No auth TLV found in received packetThe sample output indicates that the router has been running for 3 days and 3 hours. Debugging output is about IS-IS authentication information. The local router is configured for authentication, but it received a packet that does not contain authentication data; the remote router does not have authentication configured.
debug isis mpls traffic-eng advertisements
To print information about traffic engineering advertisements in Intermediate System-to-Intermediate System (IS-IS) link-state advertisement (LSA) messages, use the debug isis mpls traffic-eng advertisements command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isis mpls traffic-eng advertisements
no debug isis mpls traffic-eng advertisements
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Examples
In the following example, information about traffic engineering advertisements is printed in IS-IS LSA messages:
Router# debug isis mpls traffic-eng advertisementsSystem ID:Router1.00Router ID:10.106.0.6Link Count:1Link[1]Neighbor System ID:Router2.00 (P2P link)Interface IP address:10.42.0.6Neighbor IP Address:10.42.0.10Admin. Weight:10Physical BW:155520000 bits/secReservable BW:5000000 bits/secBW unreserved[0]:2000000 bits/sec, BW unreserved[1]:100000 bits/secBW unreserved[2]:100000 bits/sec, BW unreserved[3]:100000 bits/secBW unreserved[4]:100000 bits/sec, BW unreserved[5]:100000 bits/secBW unreserved[6]:100000 bits/sec, BW unreserved[7]:0 bits/secAffinity Bits:0x00000000Table 200 describes the significant fields shown in the display.
debug isis mpls traffic-eng events
To print information about traffic engineering-related Intermediate System-to-Intermediate System (IS-IS) events, use the debug isis mpls traffic-eng events command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isis mpls traffic-eng events
no debug isis mpls traffic-eng events
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Examples
In the following example, information is printed about traffic engineering-related IS-IS events:
Router# debug isis mpls traffic-eng eventsISIS-RRR:Send MPLS TE Et4/0/1 Router1.02 adjacency down:address 0.0.0.0ISIS-RRR:Found interface address 10.1.0.6 Router1.02, building subtlv... 58 bytesISIS-RRR:Found interface address 10.42.0.6 Router2.00, building subtlv... 64 bytesISIS-RRR:Interface address 0.0.0.0 Router1.00 not found, not building subtlvISIS-RRR:LSP Router1.02 changed from 0x606BCD30ISIS-RRR:Mark LSP Router1.02 changed because TLV contents different, code 16ISIS-RRR:Received 1 MPLS TE links flood info for system id Router1.00debug isis rib
To display debugging information for Integrated Intermediate System-to-Intermediate System (IS-IS) IP Version 4 routes in the global or local Routing Information Base (RIB), use the debug isis rib command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isis rib [global | local [access-list-number | terse]]
no debug isis rib [global | local]
Syntax Description
Defaults
Debugging of IS-IS IP Version 4 routes is disabled.
Command Modes
Privileged EXEC
Command History
12.0(26)S
This command was introduced.
12.3(4)T
This command was integrated into Cisco IOS Release 12.3(4)T.
Usage Guidelines
Use the debug isis rib command to verify if an IP prefix has been installed or removed. To monitor updates from the IS-IS database to the IS-IS local RIB, use the local keyword, and to monitor updates from the IS-IS database to the global RIB, use the global keyword.
It is highly recommended that you limit the debugging output to information specific to the IP prefix that is associated with a specific access list by entering the access-list-number argument.
Examples
The following is sample output from the debug isis rib command after the ip route priority high command was used to give high priority to IS-IS IP prefixes for the configured access list access-list1. The debug output shows that the route 10.1.1.0/24 has been removed from the IS-IS local RIB.
Router# show run | include access-list 1accept-list 1 permit 10.1.1.0 0.0.0.255! access-list 1 is configuredRouter# debug isis rib local terse 100:07:07: ISIS-LR: 10.1.1.0/24 aged out in LSP[10/(7->8)]! The route 10.1.1.0/24 is removed from the IS-IS local RIB LSP[10/(7->8)]00:07:07: ISIS-LR: rem path: [115/80/20] via 10.2.2.2(Et2) from 10.22.22.22 tg 0 LSP[10/7] from active chain (add to deleted chain)!The remote path [115/80/20] is removed from the active chain00:07:07: ISIS-LR: Enqueued to updateQ[2] for 10.1.1.0/24!Q[2] is marked to be the update00:07:07: ISIS-LR: rem path: [115/80/20] via 10.2.2.2(Et2) from 10.22.22.22 tg 0 LSP[10/7] from deleted chain00:07:07: ISIS-LR: Rem RT 10.1.1.0/24!The remote route [115/80/20] is removed from the deleted chainTable 201 describes the significant fields shown in the display.
Related Commands
ip route priority high
Assigns a high priority to an IS-IS IP prefix.
show isis rib
Displays paths for routes in the IP Version 4 IS-IS local RIB.
debug isis rib redistribution
To debug the events that update the Intermediate System-to-Intermediate System (IS-IS) redistribution cache, use the debug isis rib redistribution command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isis rib redistribution [level-1 | level-2] [access-list]
no debug isis rib redistribution [level-1 | level-2] [access-list]
Syntax Description
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
12.0(27)S
This command was introduced.
12.3(7)T
This command was integrated into Cisco IOS Release 12.3(7)T.
Usage Guidelines
We recommend that you use this command only when a Cisco Technical Assistance Center representative requests you to do so to gather information for a troubleshooting purpose.
Examples
The following example displays information about events that update the IS-IS redistribution cache. The output is self-explanatory.
Router# debug isis rib redistribution level-1 123IS-IS IPv4 redistribution RIB debugging is on for access list 123 for L1Router# router isisRouter(config-router)# redistribute connected level-1Router(config)# access-list 123 permit ip 10.0.0.0 0.255.255.255 anyRouter(config)# interface Loopback123Router(config-if)# ip address 10.123.123.3 255.255.255.255Nov 25 00:33:46.532: ISIS-RR: 10.123.123.3/32: Up event, from 0x607CAF60Nov 25 00:33:46.532: ISIS-RR: looking at L1 redist RIBNov 25 00:33:46.532: ISIS-RR: redistributed to ISISNov 25 00:33:46.532: ISIS-RR: added 10.123.123.3/32 to L1 redist RIB: [Connected/0] tag 0 externalNov 25 00:33:47.532: ISIS-RR: Scanning L1 redist RIBNov 25 00:33:47.532: ISIS-RR: adv 10.123.123.3/32 as L1 redist routeNov 25 00:33:47.532: ISIS-RR: End of scanningL1 redist RIBThe following line indicates that the connected route 10.123.123.3/32 was added to the IS-IS level 1 local redistribution cache with cost 0, metric type external, and administrative tag of 0:
Nov 25 00:33:46.532: ISIS-RR: added 10.123.123.3/32 to L1 redist RIB: [Connected/0] tag 0 externalThe following line indicates that the redistributed route 10.123.123.3/32 was advertised in an IS-IS link-state packet (LSP) as a level 1 redistributed route:
Nov 25 00:33:47.532: ISIS-RR: adv 10.123.123.3/32 as L1 redist routRelated Commands
clear isis rib redistribution
Clears some or all prefixes in the local redistribution cache.
show isis rib redistribution
Displays the prefixes in the IS-IS redistribution cache.
debug isis spf-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
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-eventsISIS-Spf: Compute L2 IPv6 SPTISIS-Spf: Move 0000.0000.1111.00-00 to PATHS, metric 0ISIS-Spf: Add 0000.0000.2222.01-00 to TENT, metric 10ISIS-Spf: Move 0000.0000.2222.01-00 to PATHS, metric 10ISIS-Spf: considering adj to 0000.0000.2222 (Ethernet3/1) metric 10, level 2, circuit 3, adj 3ISIS-Spf: (accepted)ISIS-Spf: Add 0000.0000.2222.00-00 to TENT, metric 10ISIS-Spf: Next hop 0000.0000.2222 (Ethernet3/1)ISIS-Spf: Move 0000.0000.2222.00-00 to PATHS, metric 10ISIS-Spf: Add 0000.0000.2222.02-00 to TENT, metric 20ISIS-Spf: Next hop 0000.0000.2222 (Ethernet3/1)ISIS-Spf: Move 0000.0000.2222.02-00 to PATHS, metric 20ISIS-Spf: Add 0000.0000.3333.00-00 to TENT, metric 20ISIS-Spf: Next hop 0000.0000.2222 (Ethernet3/1)ISIS-Spf: Move 0000.0000.3333.00-00 to PATHS, metric 20debug isis spf statistics
To display statistical information about building routes between intermediate systems (ISs), use the debug isis spf statistics command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isis spf statistics
no debug isis spf statistics
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
The Intermediate System-to-Intermediate System (IS-IS) Interdomain Routing Protocol (IDRP) provides routing between ISs by flooding the network with link-state information. IS-IS provides routing at two levels, intra-area (Level 1) and intra-domain (Level 2). Level 1 routing allows Level 1 ISs to communicate with other Level 1 ISs in the same area. Level 2 routing allows Level 2 ISs to build an interdomain backbone between Level 1 areas by traversing only Level 2 ISs. Level 1 ISs only need to know the path to the nearest Level 2 IS in order to take advantage of the interdomain backbone created by the Level 2 ISs.
The IS-IS protocol uses the shortest-path first (SPF) routing algorithm to build Level 1 and Level 2 routes. The debug isis spf statistics command provides information for determining the time required to place a Level 1 IS or Level 2 IS on the shortest path tree (SPT) using the IS-IS protocol.
Note
Examples
The following is sample output from the debug isis spf statistics command:
Router# debug isis spf statisticsISIS-Stats: Compute L1 SPT, Timestamp 2780.328 secondsISIS-Stats: Complete L1 SPT, Compute time 0.004, 1 nodes on SPTISIS-Stats: Compute L2 SPT, Timestamp 2780.3336 secondsISIS-Stats: Complete L2 SPT, Compute time 0.056, 12 nodes on SPTTable 202 describes the significant fields shown in the display.
The following lines show the statistical information available for Level 1 ISs:
ISIS-Stats: Compute L1 SPT, Timestamp 2780.328 secondsISIS-Stats: Complete L1 SPT, Compute time 0.004, 1 nodes on SPTThe output indicates that the SPF algorithm was applied 2780.328 seconds after the system was up and configured. Given the existing intra-area topology, 4 milliseconds were required to place one Level 1 IS on the SPT.
The following lines show the statistical information available for Level 2 ISs:
ISIS-Stats: Compute L2 SPT, Timestamp 2780.3336 secondsISIS-Stats: Complete L2 SPT, Compute time 0.056, 12 nodes on SPTThis output indicates that the SPF algorithm was applied 2780.3336 seconds after the system was up and configured. Given the existing intradomain topology, 56 milliseconds were required to place 12 Level 2 ISs on the SPT.
debug isis update-packets
To display various sequence number protocol data units (PDUs) and link-state packets that are detected by a router, use the debug isis update-packets command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug isis update-packets
no debug isis update-packets
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Examples
This router has been configured for IS-IS routing. The following is sample output from thee debug isis update-packets command:
Router# debug isis update-packetsISIS-Update: Sending L1 CSNP on Ethernet0ISIS-Update: Sending L2 CSNP on Ethernet0ISIS-Update: Updating L2 LSPISIS-Update: Delete link 888.8800.0181.00 from L2 LSP 1600.8906.4022.00-00, seq EISIS-Update: Updating L1 LSPISIS-Update: Sending L1 CSNP on Ethernet0ISIS-Update: Sending L2 CSNP on Ethernet0ISIS-Update: Add link 8888.8800.0181.00 to L2 LSP 1600.8906.4022.00-00, new seq 10,len 91ISIS-Update: Sending L2 LSP 1600.8906.4022.00-00, seq 10, ht 1198 on Tunnel0ISIS-Update: Sending L2 CSNP on Tunnel0ISIS-Update: Updating L2 LSPISIS-Update: Rate limiting L2 LSP 1600.8906.4022.00-00, seq 11 (Tunnel0)ISIS-Update: Updating L1 LSPISIS-Update: Rec L2 LSP 888.8800.0181.00.00-00 (Tunnel0)ISIS-Update: PSNP entry 1600.8906.4022.00-00, seq 10, ht 1196The following lines indicate that the router has sent a periodic Level 1 and Level 2 complete sequence number PDU on Ethernet interface 0:
ISIS-Update: Sending L1 CSNP on Ethernet0ISIS-Update: Sending L2 CSNP on Ethernet0The following lines indicate that the network service access point (NSAP) identified as 8888.8800.0181.00 was deleted from the Level 2 LSP 1600.8906.4022.00-00. The sequence number associated with this LSP is 0xE.
ISIS-Update: Updating L2 LSPISIS-Update: Delete link 888.8800.0181.00 from L2 LSP 1600.8906.4022.00-00, seq EThe following lines indicate that the NSAP identified as 8888.8800.0181.00 was added to the Level 2 LSP 1600.8906.4022.00-00. The new sequence number associated with this LSP is 0x10.
ISIS-Update: Updating L1 LSPISIS-Update: Sending L1 CSNP on Ethernet0ISIS-Update: Sending L2 CSNP on Ethernet0ISIS-Update: Add link 8888.8800.0181.00 to L2 LSP 1600.8906.4022.00-00, new seq 10,len 91The following line indicates that the router sent Level 2 LSP 1600.8906.4022.00-00 with sequence number 0x10 on tunnel 0 interface:
ISIS-Update: Sending L2 LSP 1600.8906.4022.00-00, seq 10, ht 1198 on Tunnel0The following lines indicates that a Level 2 LSP could not be transmitted because it was recently sent:
ISIS-Update: Sending L2 CSNP on Tunnel0ISIS-Update: Updating L2 LSPISIS-Update: Rate limiting L2 LSP 1600.8906.4022.00-00, seq 11 (Tunnel0)The following lines indicate that a Level 2 partial sequence number PDU (PSNP) has been received on tunnel 0 interface:
ISIS-Update: Updating L1 LSPISIS-Update: Rec L2 PSNP from 8888.8800.0181.00 (Tunnel0)The following line indicates that a Level 2 PSNP with an entry for Level 2 LSP 1600.8906.4022.00-00 has been received. This output is an acknowledgment that a previously sent LSP was received without an error.
ISIS-Update: PSNP entry 1600.8906.4022.00-00, seq 10, ht 1196debug iua as
To display debugging messages for the IDSN User Adaptation Layer (IUA) application server (AS), use the debug iua as command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug iua as {user | state} {all | name as-name}
no debug iua as
Syntax Description
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Examples
The following example shows debugging output when an ISDN backhaul connection is initially established. The output shows that state debugging is turned on for all ASs and that the AS is active.
Router# debug iua as state allIUA :state debug turned ON for ALL AS00:11:52:IUA:AS as1 number of ASPs up is 100:11:57:IUA:AS as1 xsition AS-Up --> AS-Active, cause - ASP asp1Related CommandsActive
debug iua asp
To display debugging messages for the IDSN User Adaptation Layer (IUA) application server process (ASP), use the debug iua asp command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug iua asp {pak | peer-msg | sctp-sig | state} {all | name asp-name}
no debug iua asp
Syntax Description
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Examples
The following example shows debugging output when an ISDN backhaul connection is initially established. The output shows that peer message debugging is turned on for all ASPs and that the ASP is active.
Router# debug iua asp peer-msg allIUA :peer message debug turned ON for ALL ASPsRouter#00:04:58:IUA :recieved ASP_UP message on ASP asp100:04:58:IUA:ASP asp1 xsition ASP-Down --> ASP-Up , cause - rcv peermsgASP-UP00:04:58:IUA:sending ACK of type 0x304 to asp asp100:05:03:IUA:recv ASP_ACTIVE message for ASP asp100:05:03:IUA:ASP asp1 xsition ASP-Up --> ASP-Active, cause - rcv peermsgASP-ActiveRelated Commands
debug kerberos
To display information associated with the Kerberos Authentication Subsystem, use the debug kerberos command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug kerberos
no debug kerberos
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
Kerberos is a security system that authenticates users and services without passing a cleartext password over the network. Cisco supports Kerberos under the authentication, authorization, and accounting (AAA) security system.
Use the debug aaa authentication command to get a high-level view of login activity. When Kerberos is used on the router, you can use the debug kerberos command for more detailed debugging information.
Examples
The following is part of the sample output from the debug aaa authentication command for a Kerberos login attempt that failed. The information indicates that Kerberos is the authentication method used.
Router# debug aaa authenticationAAA/AUTHEN/START (116852612): Method=KRB5AAA/AUTHEN (116852612): status = GETUSERAAA/AUTHEN/CONT (116852612): continue_loginAAA/AUTHEN (116852612): status = GETUSERAAA/AUTHEN (116852612): Method=KRB5AAA/AUTHEN (116852612): status = GETPASSAAA/AUTHEN/CONT (116852612): continue_loginAAA/AUTHEN (116852612): status = GETPASSAAA/AUTHEN (116852612): Method=KRB5AAA/AUTHEN (116852612): password incorrectAAA/AUTHEN (116852612): status = FAILThe following is sample output from the debug kerberos command for a login attempt that was successful. The information indicates that the router sent a request to the key distribution center (KDC) and received a valid credential.
Router# debug kerberosKerberos: Requesting TGT with expiration date of 820911631Kerberos: Sent TGT request to KDCKerberos: Received TGT reply from KDCKerberos: Received valid credential with endtime of 820911631The following is sample output from the debug kerberos command for a login attempt that failed. The information indicates that the router sent a request to the KDC and received a reply, but the reply did not contain a valid credential.
Router# debug kerberosKerberos: Requesting TGT with expiration date of 820911731Kerberos: Sent TGT request to KDCKerberos: Received TGT reply from KDCKerberos: Received invalid credential.AAA/AUTHEN (425003829): password incorrectThe following output shows other failure messages you might see that indicate a configuration problem. The first message indicates that the router failed to find the default Kerberos realm, therefore the process failed to build a message to send to the KDC. The second message indicates that the router failed to retrieve its own IP address. The third message indicates that the router failed to retrieve the current time. The fourth message indicates the router failed to find or create a credentials cache for a user, which is usually caused by low memory availability.
Router# debug kerberosKerberos: authentication failed when parsing nameKerberos: authentication failed while getting my addressKerberos: authentication failed while getting time of dayKerberos: authentication failed while allocating credentials cacheRelated Commands
debug aaa authentication
Displays information on accountable events as they occur.
debug kpml (SIP)
To enable Keypad Markup Language (KPML) parser and builder debugs, use the debug kpml command to specify the debug option.
To disable KPML parser and builder debugs, use the no form of this command (you must enter one option).
debug kpml [all | parser | builder | error]
no debug kpml [all | parser | builder | error]
Syntax Description
all
Enables all kpml debug tracing.
parser
Enables kpml parser tracing.
builder
Enables kpml builder tracing.
error
Enables kpml error tracing.
Command Default
no debug kpml all
Command Modes
Privileged EXEC mode
Command History
Usage Guidelines
For incoming dial peers if you configure multiple DTMF negotiation methods, the first configure value takes precedence, then the second, then the third.
For incoming dial peers, the first out-of-band negotiation method takes precedence over other DTMF negotiation methods, except when rtp-nte has precedence; in this case, sip-kpml takes precedence over other out-of-band negotiation methods.
For incoming dial peers, if both sip-kpml and rtp-nte notification mechanisms are enabled and negotiated, the gateway relies on RFC 2833 notification to receive digits and a SUBSCRIBE for KPML is not initiated.
SIP KPML support complies to the IEFT draft "draft-ietf-sipping-kpml-04.txt" with the following limitations:
•
•
•
•
–
–
–
–
–
–
•
•
•
You can configure support only on a SIP VoIP dial peer.
Examples
The following is output from the debug kpml command:
SIP call is established. DTMF sip-kpml was negotiated....//-1/xxxxxxxxxxxx/KPML/Parser/kpml_init://-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: encode_data=0x64E25B48//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: chunk_size=2k, max_allowed=16k//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: context=0x6488C0AC, mp=0x6488B89C//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_request://-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_pattern://-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_regex_list://-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: malloc xml_buf=0x645E910C, length=328//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_request://-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_pattern://-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_regex_list://-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_request: length=289, buffp=0x645E9251//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: rc=0, encoded str=<?xml version="1.0" encoding="UTF-8"?><kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0"><pattern persist="persist"><regex tag="dtmf">[x*#ABCD]</regex></pattern></kpml-request>//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_free:kpml_encode_context_free:mem_mgr_mempool_free: mem_refcnt(6488B89C)=0 - mempool cleanup/-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:Sent:SUBSCRIBE sip:8888@172.18.193.250:5060 SIP/2.0Via: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bKFF36From: <sip:172.18.193.251>;tag=EA330-F6To: <sip:8888@172.18.193.250>;tag=39497C-2EACall-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251CSeq: 103 SUBSCRIBEMax-Forwards: 70Date: Fri, 01 Mar 2002 00:16:15 GMTUser-Agent: Cisco-SIPGateway/IOS-12.xEvent: kpmlExpires: 7200Contact: <sip:172.18.193.251:5060>Content-Type: application/kpml-request+xmlContent-Length: 327<?xml version="1.0" encoding="UTF-8"?><kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0"><pattern persist="persist"><regex tag="dtmf">[x*#ABCD]</regex></pattern></kpml-request>/-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:Received:SUBSCRIBE sip:172.18.193.251:5060 SIP/2.0Via: SIP/2.0/UDP 172.18.193.250:5060;branch=z9hG4bK5FE3From: <sip:8888@172.18.193.250>;tag=39497C-2EATo: <sip:172.18.193.251>;tag=EA330-F6Call-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251CSeq: 101 SUBSCRIBEMax-Forwards: 70Date: Fri, 01 Mar 2002 01:02:46 GMTUser-Agent: Cisco-SIPGateway/IOS-12.xEvent: kpmlExpires: 7200Contact: <sip:172.18.193.250:5060>Content-Type: application/kpml-request+xmlContent-Length: 327<?xml version="1.0" encoding="UTF-8"?><kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0"><pattern persist="persist"><regex tag="dtmf">[x*#ABCD]</regex></pattern></kpml-request>/-1/xxxxxxxxxxxx/KPML/Parser/kpml_init://-1/xxxxxxxxxxxx/KPML/Parser/kpml_decode: Parsing <?xml version="1.0" encoding="UTF-8"?><kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0"><pattern persist="persist"><regex tag="dtmf">[x*#ABCD]</regex></pattern></kpml-request>/-1/xxxxxxxxxxxx/KPML/Parser/kpml_request_ptbuild://-1/xxxxxxxxxxxx/KPML/Parser/kpml_create_new_node: creating node par/cur/child=0x00000000/0x645E910C/0x00000000 top/child=0x645E910C/0x00000000//-1/xxxxxxxxxxxx/KPML/Parser/kpml_pattern_ptbuild://-1/xxxxxxxxxxxx/KPML/Parser/kpml_create_new_node: creating node par/cur/child=0x645E910C/0x645E91E8/0x00000000 top/child=0x645E910C/0x645E91E8//-1/xxxxxxxxxxxx/KPML/Parser/kpml_regex_ptbuild://-1/xxxxxxxxxxxx/KPML/Parser/kpml_create_new_node: creating node par/cur/child=0x645E91E8/0x645E923C/0x00000000 top/child=0x645E910C/0x645E91E8//-1/xxxxxxxxxxxx/KPML/Parser/kpml_character_data: buf=[x*#ABCD]</regex></pattern></kpml-request>/-1/xxxxxxxxxxxx/KPML/Parser/kpml_regex_char_data_ptbuild: char data=[x*#ABCD]//-1/xxxxxxxxxxxx/KPML/Parser/kpml_end_element_handler: elem name=regex//-1/xxxxxxxxxxxx/KPML/Parser/kpml_end_element_handler: elem name=pattern//-1/xxxxxxxxxxxx/KPML/Parser/kpml_end_element_handler: elem name=kpml-request//-1/xxxxxxxxxxxx/KPML/Parser/kpml_pattern_ptproc://-1/xxxxxxxxxxxx/KPML/Parser/kpml_regex_ptproc://-1/xxxxxxxxxxxx/KPML/Parser/kpml_decode_context_free:kpml_decode_context_free:mem_mgr_mempool_free: mem_refcnt(6488B89C)=0 - mempool cleanup//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:Received:SIP/2.0 200 OKVia: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bKFF36From: <sip:172.18.193.251>;tag=EA330-F6To: <sip:8888@172.18.193.250>;tag=39497C-2EADate: Fri, 01 Mar 2002 01:02:51 GMTCall-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251CSeq: 103 SUBSCRIBEContent-Length: 0Contact: <sip:172.18.193.250:5060>Expires: 7200//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:Sent:SIP/2.0 200 OKVia: SIP/2.0/UDP 172.18.193.250:5060;branch=z9hG4bK5FE3From: <sip:8888@172.18.193.250>;tag=39497C-2EATo: <sip:172.18.193.251>;tag=EA330-F6Date: Fri, 01 Mar 2002 00:16:24 GMTCall-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251CSeq: 101 SUBSCRIBEContent-Length: 0Contact: <sip:172.18.193.251:5060>Expires: 7200//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:Sent:NOTIFY sip:172.18.193.250:5060 SIP/2.0Via: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bK101EA4From: <sip:172.18.193.251>;tag=EA330-F6To: <sip:8888@172.18.193.250>;tag=39497C-2EACall-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251CSeq: 104 NOTIFYMax-Forwards: 70Date: Fri, 01 Mar 2002 00:16:24 GMTUser-Agent: Cisco-SIPGateway/IOS-12.xEvent: kpmlSubscription-State: activeContact: <sip:172.18.193.251:5060>Content-Length: 0//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:Received:NOTIFY sip:172.18.193.251:5060 SIP/2.0Via: SIP/2.0/UDP 172.18.193.250:5060;branch=z9hG4bK6111From: <sip:8888@172.18.193.250>;tag=39497C-2EATo: <sip:172.18.193.251>;tag=EA330-F6Call-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251CSeq: 102 NOTIFYMax-Forwards: 70Date: Fri, 01 Mar 2002 01:02:51 GMTUser-Agent: Cisco-SIPGateway/IOS-12.xEvent: kpmlSubscription-State: activeContact: <sip:172.18.193.250:5060>Content-Length: 0...//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: encode_data=0x64E25D00//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: chunk_size=2k, max_allowed=16k//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: context=0x64FADC10, mp=0x64AFBBE0//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_response://-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: malloc xml_buf=0x645E910C, length=112//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_response://-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_response: length=73, buffp=0x645E917B//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: rc=0, encoded str=<?xml version="1.0" encoding="UTF-8"?><kpml-response version="1.0" code="200" text="OK" digits="1" tag="dtmf"/>//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_free:kpml_encode_context_free:mem_mgr_mempool_free: mem_refcnt(64AFBBE0)=0 - mempool cleanup//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:Sent:NOTIFY sip:172.18.193.250:5060 SIP/2.0Via: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bK1117DEFrom: <sip:172.18.193.251>;tag=EA330-F6To: <sip:8888@172.18.193.250>;tag=39497C-2EACall-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251CSeq: 105 NOTIFYMax-Forwards: 70Date: Fri, 01 Mar 2002 00:37:33 GMTUser-Agent: Cisco-SIPGateway/IOS-12.xEvent: kpmlSubscription-State: activeContact: <sip:172.18.193.251:5060>Content-Type: application/kpml-response+xmlContent-Length: 113<?xml version="1.0" encoding="UTF-8"?><kpml-response version="1.0" code="200" text="OK" digits="1" tag="dtmf"/>/-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:Received:SIP/2.0 200 OKVia: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bK1117DEFrom: <sip:172.18.193.251>;tag=EA330-F6To: <sip:8888@172.18.193.250>;tag=39497C-2EADate: Fri, 01 Mar 2002 01:24:08 GMTCall-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251CSeq: 105 NOTIFYContent-Length: 0//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: encode_data=0x64E25D00//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: chunk_size=2k, max_allowed=16k//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: context=0x651E8084, mp=0x65501720//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_response://-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: malloc xml_buf=0x645E910C, length=112//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_response://-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_response: length=73, buffp=0x645E917B//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: rc=0, encoded str=<?xml version="1.0" encoding="UTF-8"?><kpml-response version="1.0" code="200" text="OK" digits="2" tag="dtmf"/>//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_free:kpml_encode_context_free:mem_mgr_mempool_free: mem_refcnt(65501720)=0 - mempool cleanup//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: encode_data=0x656F9128//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: chunk_size=2k, max_allowed=16k//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_create: context=0x651E8084, mp=0x6488B6CC//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_response://-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: malloc xml_buf=0x645E910C, length=112//-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_response://-1/xxxxxxxxxxxx/KPML/Builder/kpml_build_response: length=73, buffp=0x645E917B//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode: rc=0, encoded str=<?xml version="1.0" encoding="UTF-8"?><kpml-response version="1.0" code="200" text="OK" digits="3" tag="dtmf"/>//-1/xxxxxxxxxxxx/KPML/Builder/kpml_encode_context_free:kpml_encode_context_free:mem_mgr_mempool_free: mem_refcnt(6488B6CC)=0 - mempool cleanup//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:Sent:NOTIFY sip:172.18.193.250:5060 SIP/2.0Via: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bK12339From: <sip:172.18.193.251>;tag=EA330-F6To: <sip:8888@172.18.193.250>;tag=39497C-2EACall-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251CSeq: 106 NOTIFYMax-Forwards: 70Date: Fri, 01 Mar 2002 00:37:44 GMTUser-Agent: Cisco-SIPGateway/IOS-12.xEvent: kpmlSubscription-State: activeContact: <sip:172.18.193.251:5060Content-Type: application/kpml-response+xmlContent-Length: 113<?xml version="1.0" encoding="UTF-8"?><kpml-response version="1.0" code="200" text="OK" digits="2" tag="dtmf"/>/-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:Received:SIP/2.0 200 OKVia: SIP/2.0/UDP 172.18.193.251:5060;branch=z9hG4bK12339From: <sip:172.18.193.251>;tag=EA330-F6To: <sip:8888@172.18.193.250>;tag=39497C-2EADate: Fri, 01 Mar 2002 01:24:20 GMTCall-ID: 57633F68-2BE011D6-8013D46B-B4F9B5F6@172.18.193.251CSeq: 106 NOTIFYContent-Length: 0...Related Commands
show sip-ua calls
Verifies that the DTMF method is SIP-KPML.
debug kpml
Enables parser and builder debugs for KPML.
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
Defaults
If no keyword is specified, all debugging messages are displayed.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the debug kron command to display the output of a scheduled EXEC show command on the console.
Examples
The following example shows debugging messages for the EXEC CLI show version after the CLI was run at a scheduled interval:
Router# debug kron exec-cliKron cli occurrence messages debugging is on2w6d: Call parse_cmd 'show version'2w6d: Kron CLI return 0'**CLI 'show version':Cisco Internetwork Operating System Software IOS (tm) C2600 Software (C2600-I-MRelated Commands
show kron schedule
Displays the status and schedule information for Command Scheduler occurrences.
debug 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
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
Examples
The following example enables the display of Layer 2 Relay events:
Router# debug l2relay eventsRelated Commands
debug l2relay packets
To display information about Layer 2 Relay packets, use the debug l2relay packets command in privileged EXEC mode. To disable debugging output, use the no form of this command (SGSN D-node only).
debug l2relay packets
no debug l2relay packets
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
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
Examples
The following example enables the display of Layer 2 Relay packets:
Router# debug l2relay packetsRelated Commands
Posted: Mon Jul 2 06:47:00 PDT 2007
All contents are Copyright © 1992--2007 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
