To display messages about Cisco IOS firewall events, use the debugipv6inspect command in privileged EXEC mode. To disable debugging output, use the no form of this command.
Displays messages about software functions called by the Cisco IOS firewall.
object-creation
Displays messages about software objects being created by the Cisco IOS firewall. Object creation corresponds to the beginning of Cisco IOS firewall-inspected sessions.
object-deletion
Displays messages about software objects being deleted by the Cisco IOS firewall. Object deletion corresponds to the closing of Cisco IOS firewall-inspected sessions.
events
Displays messages about Cisco IOS firewall software events, including information about Cisco IOS firewall packet processing.
timers
Displays messages about Cisco IOS firewall timer events such as when a Cisco IOS firewall idle timeout is reached.
protocol
Displays messages about Cisco IOS firewall-inspected protocol events, including details about the protocol's packets.
detailed
Use this form of the command in conjunction with other Cisco IOS firewall debugging commands. This causes detailed information to be displayed for all the other enabled Cisco IOS firewall debugging.
Command Default
None
Command Modes
Privileged EXEC
Command History
Release
Modification
12.2(2)T
This command was introduced
12.0(22)S
This command was integrated into Cisco IOS Release 12.0(22)S.
12.2(14)S
This command was integrated into Cisco IOS Release 12.2(14)S.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
Command History
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
Examples
The following example enables the display of messages about Cisco IOS firewall events:
debug ipv6 inspect
Related Commands
Command
Description
ipv6inspectaudit-trail
Turns on CBAC audit trail messages, which are displayed on the console after each Cisco IOS firewall session closes.
ipv6inspectname
Defines a set of ipv6 inspection rules.
showipv6inspect
Displays CBAC configuration and session information.
debug ipv6 mfib
To enable debugging output on the IPv6 Multicast Forwarding Information Base (MFIB), use the debugipv6mfibcommand in privileged EXEC mode. To disable debugging output, use the no form of this command.
(Optional) Specifies a virtual routing and forwarding (VRF) configuration.
group-name | group-address
(Optional) IPv6 address, name, or interface of the multicast group as defined in the Domain Name System (DNS) hosts table.
adjacency
(Optional) Enables debugging output for adjacency management activity.
db
(Optional) Enables debugging output for route database management activity.
fs
(Optional) Enables debugging output for fast switching activity.
init
(Optional) Enables debugging output for initialization or deinitialization activity.
interface
(Optional) Enables debugging output for IPv6 MFIB interfaces.
mrib
(Optional) Enables debugging output for communication with the MRIB.
detail
(Optional) Enables detailed debugging output regarding the MRIB.
nat
(Optional) Enables debugging output for Network Address Translation (NAT) events associated with all tables.
pak
(Optional) Enables debugging output for packet forwarding activity.
platform
(Optional) Enables debugging output related to the hardware platform use of application program interfaces (APIs).
ppr
(Optional) Enables debugging output for packet preservation events.
ps
(Optional) Enables debugging output for process-level-only packet forwarding activity.
signal
(Optional) Enables debugging output for activity regarding MFIB data-driven signaling to routing protocols.
table
(Optional) Enables debugging output for IPv6 MFIB table activity.
Command Modes
Privileged EXEC
Release
Modification
12.3(2)T
This command was introduced.
12.2(18)S
This command was integrated into Cisco IOS Release 12.2(18)S.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
Cisco IOS XE Release 2.1
This command was introduced on Cisco ASR 1000 series routers.
12.2(33)SRE
The detail keyword was added.
15.1(1)T
The detail keyword was added.
15.1(4)M
The vrfvrf-name keyword and argument were added.
Usage Guidelines
If no keywords are used, all IPbv6 MFIB activity debugging output is displayed.
Examples
The following example enables debugging output for adjacency management activity on the IPv6 MFIB:
Router# debug ipv6 mfib adjacency
debug ipv6 mld
To enable debugging on Multicast Listener Discovery (MLD) protocol activity, use the debugipv6mldcommand in privileged EXEC mode. To restore the default value, use the no form of this command.
(Optional) IPv6 address or name of the multicast group.
interface-type or interfaceinterface-type
(Optional) Interface type. For more information, use the question mark (?) online help function.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.3(2)T
This command was introduced.
12.2(18)S
This command was integrated into Cisco IOS Release 12.2(18)S.
12.0(26)S
This command was integrated into Cisco IOS Release 12.0(26)S.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(25)SG
This command was integrated into Cisco IOS Release 12.2(25)SG.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
Cisco IOS XE Release 2.1
This command was introduced on Cisco ASR 1000 Series Routers.
Usage Guidelines
This command helps discover whether the MLD protocol activities are working correctly. In general, if MLD is not working, the router process never discovers that there is a host on the network that is configured to receive multicast packets.
The messages displayed by the debugipv6mldcommand show query and report activity received from other routers and hosts. Use this command in conjunction with debugipv6pim to display additional multicast activity, to learn more information about the multicast routing process, or to learn why packets are forwarded out of particular interfaces.
Examples
The following example enables debugging on MLD protocol activity:
Router# debug ipv6 mld
Related Commands
Command
Description
debugipv6pim
Enables debugging on PIM protocol activity.
debug ipv6 mld explicit
To display information related to the explicit tracking of hosts, use the debugipv6mldexplicitcommand in privileged EXEC mode. To disable debugging, use the no form of this command.
(Optional) IPv6 address or name of the multicast group.
Command Default
Debugging for the explicit tracking of hosts is not enabled.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
12.3(7)T
This command was introduced.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(25)SG
This command was integrated into Cisco IOS Release 12.2(25)SG.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
Cisco IOS XE Release 2.1
This command was introduced on Cisco ASR 1000 Series Routers.
Usage Guidelines
When the optional group-name
or group-address
argument is not used, all debugging information is displayed.
Examples
The following example shows how to enable information to be displayed about the explicit tracking of hosts. The command output is self-explanatory:
Router# debug ipv6 mld explicit
00:00:56:MLD:ET host FE80::A8BB:CCFF:FE00:800 report for FF05::6 (0 srcs) on Ethernet1/0
00:00:56:MLD:ET host FE80::A8BB:CCFF:FE00:800 switch to exclude for FF05::6 on Ethernet1/0
00:00:56:MLD:ET MRIB modify for (*,FF05::6) on Ethernet1/0 new 100, mdf 100
debug ipv6 mld ssm-map
To display debug messages for Source Specific Multicast (SSM) mapping related to Multicast Listener Discovery (MLD), use the debugipv6mldssm-mapcommand in privileged EXEC mode. To disable debug messages for SSM mapping, use the no form of this command.
debugipv6mldssm-map [source-address]
nodebugipv6mldssm-map [source-address]
Syntax Description
source-address
(Optional) Source address associated with an MLD membership for a group identified by the access list.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.2(18)SXE
This command was introduced.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
Usage Guidelines
Consult Cisco technical support before using this command.
Examples
The following example allows debugging information for SSM mapping to be displayed:
Router# debug ipv6 mld ssm-map
Related Commands
Command
Description
ipv6mldssm-mapenable
Enables the SSM mapping feature for groups in the configured SSM range
ipv6mldssm-mapquerydns
Enables DNS-based SSM mapping.
ipv6mldssm-mapstatic
Configures static SSM mappings.
showipv6mldssm-map
Displays SSM mapping information.
debug ipv6 mobile
To enable the display of debugging information for Mobile IPv6, use the debugipv6mobilecommand in privileged EXEC mode.
Events associated with forwarding (tunneling) packets for which the router is acting as home agent.
home-agent
Events associated with the home agent, Dynamic Home Address Agent Discovery (DHAAD), Mobile prefix discovery (MPD), and generic home agent (HA) debugging and binding acknowledgments.
registration
Events associated with binding updates that are registrations.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.3(14)T
This command was introduced.
Usage Guidelines
The debugipv6mobile command enables the display of selected debugging information. You may use multiple command lines to enable concurrent debugging of multiple classes of information.
Examples
In the following example, debugging information is displayed for binding updates processing:
Router# debug ipv6 mobile registration
Related Commands
Command
Description
binding
Configures binding options for the Mobile IPv6 home agent feature in home-agent configuration mode.
ipv6mobilehome-agent(globalconfiguration)
Enters home agent configuration mode.
ipv6mobilehome-agent(interfaceconfiguration)
Initializes and start the IPv6 Mobile home agent on a specific interface.
ipv6mobilehome-agentpreference
Configures the home agent preference value on the interface.
debug ipv6 mobile mag
To debug the Mobile Access Gateway (MAG) application programming interface (API), information, or events, use the
debugipv6mobilemag command in privileged EXEC mode. To disable display of the debugging output, use the
no form of this command.
debugipv6mobilemag
{ api | events | info }
nodebugipv6mobilemag
{ api | events | info }
Syntax Description
api
Enables API-specific debug events.
events
Enables all events occurring within the Local Mobility Anchor (LMA) and the MAG.
info
Provides debug information within the Proxy Mobile IPv6 (PMIPV6) module.
Command Default
Debugging is not enabled.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
Cisco IOS XE Release 3.4S
This command was introduced.
15.2(4)M
This command was integrated into Cisco IOS Release 15.2(4)M.
Usage Guidelines
Use the debugipv6mobilemagevents command to enable events occurring within the LMA and MAG. The following table lists the
common causes for Proxy Binding Update (PBU) rejections:
PBU Reject Status
Description
PMIPV6_BA_ACCEPTED
The PBU is accepted.
GRE_KEY_OPTION_NOT_REQUIRED
The PBU is processed successfully but the GRE encapsulation and GRE keys are not required.
PMIPV6_BA_UNSPEC_FAIL
The PBU is rejected for an unspecified
reason.
PMIPV6_BA_ADMIN_FAIL
The PBU is rejected due to administrative reasons.
PMIPV6_BA_RESOURCE_FAIL
The PBU is rejected due to insufficient
resources.
PMIPV6_BA_HM_REG_FAIL
The PBU is rejected because it has an unsupported
home registration.
PMIPV6_BA_HM_SUBNET_FAIL
The PBU is rejected because the current subnet is
not the home subnet.
PMIPV6_BA_BAD_SEQ_FAIL
The PBU is rejected because the sequence number is out of the specified range.
PMIPV6_BA_CHANGE_FAIL
The PBU is rejected because the registration type has changed.
PMIPV6_BA_AUTH_FAIL
The PBU is rejected because the authorization has failed.
PROXY_REG_NOT_ENABLED
The PBU is rejected because the registration of the proxy is not enabled for the mobile node.
NOT_LMA_FOR_THIS_MOBILE_NODE
The PBU is rejected because the current Local Mobility Anchor (LMA) is not the appropriate LMA for the mobile node.
MAG_NOT_AUTHORIZED_FOR_
PROXY_REG
The PBU is rejected because the Mobile Access Gateway (MAG) is not authorized to send PBUs.
NOT_AUTHORIZED_FOR_HNP
The PBU is rejected because it is not authorized for the Home Network Prefix (HNP).
TIMESTAMP_MISMATCH
The PBU is rejected because it has an invalid timestamp value.
TIMESTAMP_LOWER_THAN_
PREV_ACCEPTED
This PBU is rejected because the timestamp value is lower than the previously accepted value.
MISSING_HNP_OPTION
The PBU is rejected because it is the Home Network Prefix (HNP) option.
BCE_PBU_PREFIX_SET_DO
_NOT_MATCH
The PBU is rejected because the Home Network Prefixes (HNPs) that are received in the PBU do not match with the Binding Cache Entry (BCE).
MISSING_MN_IDENTIFIER_OPTION
The PBU is rejected because the mobile node identifier option is missing.
MISSING_HANDOFF_INDICATOR_
OPTION
The PBU is rejected because the Handoff Indicator is missing.
Examples
The following is sample output from the
debugipv6mobilemagapi command displays the APIs that are called during the call setup flow:
Device# debug ipv6 mobile mag api
07:52:08.051: MIP_PDL_API: pmipv6_pdl_get_att API Called
07:52:08.051: [PMIPV6_BINDING_API]: pmipv6_get_binding API called
07:52:08.051: [PMIPV6_BINDING_API]: pmipv6_get_binding API called
07:52:08.051: [PMIPV6_MAG_API]: mag_bul_do_state_transition API called
07:52:08.051: [PMIPV6_MAG_API]: pmipv6_mag_bul_null_state_hndlr API called
07:52:08.051: [PMIPV6_MAG_API]: pmipv6_mag_bul_null_state_exit API called
07:52:08.051: [PMIPV6_MAG_API]: pmipv6_mag_bul_init_state_entry API called
07:52:08.051: [PMIPV6_BINDING_API]: pmipv6_add_binding_entry API called
07:52:08.051: MIP_PDL_API: pmipv6_pdl_get_timestamp API Called
07:52:08.053: [PMIPV6_MAG_API]: pmipv6_mag_should_handle_pkt called
07:52:08.053: [PMIPV6_MAG_API]: pmipv6_mag_message_handler called
07:52:08.053: [PMIPV6_BINDING_API]: pmipv6_get_binding API called
07:52:08.053: [PMIPV6_BINDING_API]: pmipv6_get_binding API called
07:52:08.053: [PMIPV6_MAG_API]: mag_bul_do_state_transition API called
07:52:08.053: [PMIPV6_MAG_API]: pmipv6_mag_bul_init_state_hndlr API called
07:52:08.053: [PMIPV6_MAG_API]: pmipv6_mag_bul_init_state_exit API called
07:52:08.053: MIP_PDL_API: pmipv6_pdl_create_vintf API Called
16 07:52:08.054: MIP_PDL_API: pmipv6_pdl_set_ip4address API Called
16 07:52:08.054: MIP_PDL_API: pmipv6_pdl_set_macaddr API Called
16 07:52:08.054: MIP_PDL_API: mip_pdl_setupv4_route API Called
07:52:08.054: MIP_PDL_API: mip_pdl_setupv6_tunnel API Called
07:52:08.054: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
07:52:08.054: MIP_PDL_API: mip_pdl_get_handle_for_tunnel API Called
07:52:08.054: MIP_PDL_API: mip_pdl_populate_rtunnel API Called
07:52:08.054: MIP_PDL_API: mip_pdl_get_handle_for_tunnel API Called
07:52:08.055: [PMIPV6_BINDING_API]: pmipv6_update_binding_key API called
07:52:08.055: [PMIPV6_MAG_API]: pmipv6_mag_bul_active_state_entry API called
The following is sample output from the
debugipv6mobilemagevents command:
Device# debug ipv6 mobile mag events
PMIPv6 MAG Event debug is turned on
The following line shows that the DHCP Discover trigger is received from the mobile node (MN):
07:48:31.638: [PMIPV6_MAG_EVENT]: Trigger request received (DHCP Discover trigger) from (example3@example.com)
The following line shows the MAG machine state change. A new MN attaches to the MAG and the state changes from NULL to INIT:
07:48:31.638: [PMIPV6_MAG_EVENT]: Event received New MN intf attached in state: NULL, new state: INIT
The following line shows that the Proxy Binding Update (PBU) message is sent from a MAG to an MN:
07:48:31.638: [PMIPV6_MAG_EVENT]: PBU message sent
The following lines show that the Proxy Binding Acknowledgment (PBA) is received from the LMA for the MN. The incoming parameters are link layer identifier (lli) length, value, and access technology type (att). The status 0 indicates success.
The following line shows that the refresh timer has started:
07:48:31.639: [PMIPV6_MAG_EVENT]: Starting Refresh timer, period (300000)
The following lines show that a v4 route is added to the MN, which has a new address assigned. A new v6 tunnel is created and a reverse tunnel entry is added for the MN.
The following is sample out from
debugipv6mobilemaginfo command:
Device# debug ipv6 mobile mag info
PMIPv6 MAG INFO debug is turned on
The following lines show that the new binding is created and added to the AV tree:
07:50:31.714: [PMIPV6_PDB_INFO]: MN entry example3@example.com found in hashset
07:50:31.714: [PMIPV6_BINDING_INFO]: binding added New NAI AVL node created
The following line provides more information about the PBUs that are sent:
The following line shows that a binding for the MN using the Network Access Identifier (NAI) example3@example.com is found:
07:50:31.717: [PMIPV6_BINDING_INFO_KEY]: Keytype as NAI. NAI: example3@example.com
07:50:31.717: [PMIPV6_BINDING_INFO]: binding found on NAI tree
The following line shows that a virtual interface is created in the MAG and assigned the MAC address aaaa.aaaa.aaaa:
07:50:31.717: [PMIPV6_MAG_EVENT]: Creating virtual interface handle (IFNAME_PMIP_VIF4)
07:50:31.717: [PMIPV6_MAG_INFO]: Setting Mac Address (aaaa.aaaa.aaaa) on (IFNAME_PMIP_VIF4)
The following line shows that a route for the MN is added in the MAG:
07:50:31.717: MIP_PDL_INFO: Successfully added route 10.10.1.4/24 to GigabitEthernet0/0/0
07:50:31.717: MIP_PDL_INFO: Route via: GigabitEthernet0/1/0 (IPv6)
The following line shows that a tunnel is created with a source address and a destination address:
07:50:31.718: MIP_PDL_INFO: Tunnel0 (IPv6) created with src 2000::4 dst 2001::2
07:50:31.718: MIP_PDL_INFO: Rev. Tunnel acl entry added for subnet (10.10.0.0)
Related Commands
Command
Description
ipv6mobilepmipv6-mag
Configures the MAG for the PMIPV6 domain.
debug ipv6 mobile networks
To display debugging messages for IPv6 mobile networks, use the debugipv6mobilenetworkscommand in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugipv6mobilenetworks
nodebugipv6mobilenetworks
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
12.4(20)T
This command was introduced.
Usage Guidelines
The debugipv6mobilenetworkscommand enables the display of selected debugging information.
Examples
The following example shows how to enable the display of debugging messages for IPv6 mobile networks:
Router# debug ipv6 mobile networks
Related Commands
Command
Description
ipv6mobilerouter
Enables IPv6 NEMO functionality on a router and places the router in IPv6 mobile router configuration mode.
debug ipv6 mobile packets
To debug the proxy mobile IPv4 or IPv6 packets, use the
debugipv6mobilepackets command in privileged EXEC mode. To disable the debugging output, use the
no form of this command.
debugipv6mobilepackets
nodebugipv6mobilepackets
Syntax Description
This command has no arguments or keywords.
Command Default
Debugging is not enabled.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
Cisco IOS XE Release 3.4S
This command was introduced.
15.2(4)M
This command was integrated into Cisco IOS Releases 15.2(4)M.
Examples
The following is sample output from the
debugipv6mobilepackets command:
Device# debug ipv6 mobile packets
PMIPv6 PKT debug is turned on
The following lines show the newly allocated packet size and the inner packet details:
The following lines shows the mobility options, the value, and the length:
07:51:17.693: [PMIPV6_MM] NAI option included len 14
!
2A986107E0: 4D 4E334063 6973636F example3@example
2A986107F0: 2E636F6D 1702 .com..
07:51:17.693:
07:51:17.693: [PMIPV6_MM] HI option included len 2 val 4
07:51:17.694: [PMIPV6_MM] ATT option included len 2 val 3
07:51:17.694: [PMIPV6_MM] TIMESTAMP option included len 8 value 3517199477
07:51:17.694: [PMIPV6_MM] LLI option included len 16
!
2A98610810: 61616262 2E636330 302E6365 30300100 aabb.cc00.ce00..
2A98610820: 24 $
07:51:17.694:
07:51:17.694: [PMIPV6_MM] V4HOAREQ option included len 6 val 0.0.0.0
07:51:17.694: [PMIPV6_MM] V4DFT_RTR option included len 6 val 0.0.0.0
07:51:17.694: **** Dumping the TLVs ****
!
2A986107E0: 01020000 080E014D 4E334063 6973636F .......example3@example
2A986107F0: 2E636F6D 17020004 18020003 01001B08 .com............
2A98610800: 00000000 D1A43475 01020000 19100000 ....Q$4u........
2A98610810: 61616262 2E636330 302E6365 30300100 aabb.cc00.ce00..
2A98610820: 24060000 00000000 26060000 00000000 $.......&.......
2A98610830: 01020000 ....
07:51:17.694:
07:51:17.695: [PMIPV6_MM] NAI option received len 14
!
2A97DBE560: 4D 4E334063 6973636F 2E636F6D example3@example.com
2A97DBE570: 0017 ..
07:51:17.696:
07:51:17.696: [PMIPV6_MM] HI option received len 2 val 4
07:51:17.696: [PMIPV6_MM] ATT option received len 2 val 3
07:51:17.696: [PMIPV6_MM] TIMESTAMP option received len 8 value 3517199477
07:51:17.696: [PMIPV6_MM] LLI option received len 16
!
2A97DBE580: 61616262 aabb
2A97DBE590: 2E636330 302E6365 30300100 00 .cc00.ce00...
07:51:17.696:
07:51:17.696: [PMIPV6_MM] V4HOAREPLY option received len 6 val 10.10.1.5
07:51:17.696: [PMIPV6_MM] V4DFT_RTR option received len 6 val 10.10.1.1
The following lines show the dump of the packet with all the Type Length Values (TLVs):
To display debugging messages for the IPv6 mobile router, use the debugipv6mobilerouter command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugipv6mobilerouter [detail]
nodebugipv6mobilerouter
Syntax Description
detail
(Optional) Displays detailed mobile router debug messages.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
12.4(20)T
This command was introduced.
Usage Guidelines
The IPv6 mobile router operations can be debugged. The following conditions trigger debugging messages:
Agent discovery
Registration
Mobile router state change
Routes and tunnels created or deleted
Roaming information
Debugging messages are prefixed with "MobRtr," and detail messages are prefixed with "MobRtrX."
Examples
The following example shows how to enable the display of debugging messages for the IPv6 mobile router:
Router# debug ipv6 mobile router
Related Commands
Command
Description
ipv6mobilerouter
Enables IPv6 NEMO functionality on a router and places the router in IPv6 mobile router configuration mode.
debug ipv6 mrib client
To enable debugging on Multicast Routing Information Base (MRIB) client management activity, use the debugipv6mribclientcommand in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugipv6mrib
[ vrfvrf-name ]
client
nodebugipv6mribclient
Syntax Description
vrfvrf-name
(Optional) Specifies a virtual routing and forwarding (VRF) configuration.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.3(2)T
This command was introduced.
12.2(18)S
This command was integrated into Cisco IOS Release 12.2(18)S.
12.0(26)S
This command was integrated into Cisco IOS Release 12.0(26)S.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(25)SG
This command was integrated into Cisco IOS Release 12.2(25)SG.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
Cisco IOS XE Release 2.1
This command was introduced on Cisco ASR 1000 Series Routers.
15.1(4)M
The vrfvrf-name keyword and argument were added.
Usage Guidelines
The debugipv6mribclient command is used to display the activity in the MRIB associated with clients such as Protocol Independent Multicast (PIM) and Multicast Listener Discovery (MLD). If you are having difficulty with your client connections, use this command to display new clients being added and deleted.
The debugipv6mribclient command also displays information on when a new client is added to or deleted from the MRIB, when a client connection is established or torn down, when a client binds to a particular MRIB table, and when a client is informed that there are updates to be read.
Examples
The following example enables debugging on MRIB client management activity:
Router# debug ipv6 mrib client
Related Commands
Command
Description
debugipv6mribroute
Displays MRIB routing entry-related activity.
debug ipv6 mrib io
To enable debugging on Multicast Routing Information Base (MRIB) I/O events, use the debugipv6mribiocommand in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugipv6mrib
[ vrfvrf-name ]
io
nodebugipv6mribio
Syntax Description
vrfvrf-name
(Optional) Specifies a virtual routing and forwarding (VRF) configuration.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.3(2)T
This command was introduced.
12.2(18)S
This command was integrated into Cisco IOS Release 12.2(18)S.
12.0(26)S
This command was integrated into Cisco IOS Release 12.0(26)S.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(25)SG
This command was integrated into Cisco IOS Release 12.2(25)SG.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
Cisco IOS XE Release 2.1
This command was introduced on Cisco ASR 1000 Series Routers.
15.1(4)M
The vrfvrf-name keyword and argument were added.
Usage Guidelines
Use the debugipv6mribio command to display information on when clients open and close MRIB I/O connections, when MRIB entry and interface updates are received and processed from clients, and when MRIB entry and interface updates are sent to clients.
Examples
The following example enables debugging on MRIB I/O events:
Router# debug ipv6 mrib io
debug 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 debugipv6mribproxycommand in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugipv6mribproxy
nodebugipv6mribproxy
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(26)S
This command was introduced.
12.3(4)T
This command was integrated into Cisco IOS Release 12.3(4)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
12.2(25)SG
This command was integrated into Cisco IOS Release 12.2(25)SG.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
Cisco IOS XE Release 2.1
This command was introduced on Cisco ASR 1000 Series Routers.
Usage Guidelines
Use the debugipv6mribproxy 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 proxy
debug ipv6 mrib route
To display information about Multicast Routing Information Base (MRIB) routing entry-related activity, use the debugipv6mribroutecommand in privileged EXEC mode. To disable debugging output, use the no form of this command.
(Optional) Specifies a virtual routing and forwarding (VRF) configuration.
group-name | group-address
(Optional) IPv6 address or name of the multicast group.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.3(2)T
This command was introduced.
12.2(18)S
This command was integrated into Cisco IOS Release 12.2(18)S.
12.0(26)S
This command was integrated into Cisco IOS Release 12.0(26)S.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(25)SG
This command was integrated into Cisco IOS Release 12.2(25)SG.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
Cisco IOS XE Release 2.1
This command was introduced on Cisco ASR 1000 Series Routers.
15.1(4)M
The vrfvrf-name keyword and argument were added.
Usage Guidelines
This command displays update information related to the route database made by MRIB clients, which is then redistributed to the clients.
Use this command to monitor MRIB route activity when discontinuity is found between the MRIB and the client database or between the individual client databases.
Examples
The following example enables the display of information about MRIB routing entry-related activity:
Router# debug ipv6 mrib route
Related Commands
Command
Description
showipv6mribclient
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 debugipv6mribtablecommand in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugipv6mrib
[ vrfvrf-name ]
table
nodebugipv6mribtable
Syntax Description
vrfvrf-name
(Optional) Specifies a virtual routing and forwarding (VRF) configuration.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.3(2)T
This command was introduced.
12.2(18)S
This command was integrated into Cisco IOS Release 12.2(18)S.
12.0(26)S
This command was integrated into Cisco IOS Release 12.0(26)S.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(25)SG
This command was integrated into Cisco IOS Release 12.2(25)SG.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
Cisco IOS XE Release 2.1
This command was introduced on Cisco ASR 1000 Series Routers.
15.1(4)M
The vrfvrf-name keyword and argument were added.
Usage Guidelines
Use the debugipv6mribtable command to display information on new MRIB tables being added and deleted.
Examples
The following example enables debugging on MRIB table management activity:
Router# debug ipv6 mrib table
debug ipv6 multicast aaa
To enable debugging of authentication, authorization, and accounting (AAA) events related to IPv6 multicast routing, use the debugipv6multicastaaa command in privileged EXEC mode. To disable debugging of events, use the no form of this command.
You must configure multicast routing in an IPv6
environment. Use the ipv6multicast-routing command in global configuration mode to enable IPv6 multicast routing. The ipv6multicast-routing command applies on all IPv6-enabled interfaces on a device, which are then
automatically enabled for Protocol-Independent Multicast version 6 (PIMv6). PIM is used between devices so
that the devices can track which multicast packets to forward to each
other and to the devices that are on the directly connected LANs.
Examples
The following example shows how to enable debugging of IPv6 multicast AAA information:
Device# debug ipv6 multicast aaa detail
AAA details debugging is on
Device# debug ipv6 multicast aaa error
AAA errors debugging is on
Device# debug ipv6 multicast aaa verbose
AAA verbose debugging is on
Related Commands
Related Commands
Command
Description
ipv6multicast-routing
Enables multicast routing using MLD on all IPv6-enabled
interfaces of the device and enables multicast forwarding.
debug ipv6 multicast rpf
To enable debugging of Reverse Path Forwarding (RPF) events related to IPv6 multicast routing, use the debugipv6multicastrpf command in privileged EXEC mode. To disable debugging of events, use the no form of this command.
debug ipv6 multicast rpf
no debug ipv6 multicast rpf
Syntax Description
rpf
Enables debugging of IPv6 multicast RPF events.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
15.3(1)S
This command was introduced.
Usage Guidelines
You must configure multicast routing in an IPv6
environment. Use the ipv6multicast-routing command in global configuration mode to enable IPv6 multicast routing. The ipv6multicast-routing command applies on all IPv6-enabled interfaces on a device, which are then
automatically enabled for Protocol-Independent Multicast version 6 (PIMv6). PIM is used between devices so
that the devices can track which multicast packets to forward to each
other and to the devices that are on the directly connected LANs.
Examples
The following example shows how to enable debugging of IPv6 multicast RPF events:
Device# debug ipv6 multicast rpf
IPv6 Multicast RPF debugging is on
Related Commands
Related Commands
Command
Description
ipv6multicast-routing
Enables multicast routing using MLD on all IPv6-enabled
interfaces of the device and enables multicast forwarding.
debug ipv6 multicast rwatch
To enable debugging of route watch tracking events related to IPv6 multicast routing, use the debugipv6multicast rwatch command in privileged EXEC mode. To disable debugging of events, use the no form of this command.
debug ipv6 multicast rwatch
no debug ipv6 multicast rwatch
Syntax Description
rwatch
Enables debugging of IPv6 multicast route watch tracking events.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
15.3(1)S
This command was introduced.
Usage Guidelines
You must configure multicast routing in an IPv6
environment. Use the ipv6multicast-routing command in global configuration mode to enable IPv6 multicast routing. The ipv6multicast-routing command applies on all IPv6-enabled interfaces on a device, which are then
automatically enabled for Protocol-Independent Multicast version 6 (PIMv6). PIM is used between devices so
that the devices can track which multicast packets to forward to each
other and to the devices that are on the directly connected LANs.
Examples
The following example shows how to enable debugging of IPv6 multicast route watch tracking events:
Device# debug ipv6 multicast rwatch
IPv6 Route-watch debugging is on
Related Commands
Related Commands
Command
Description
ipv6multicast-routing
Enables multicast routing using MLD on all IPv6-enabled
interfaces of the device and enables multicast forwarding.
debug ipv6 nat
To display debug messages for Network Address Translation--Protocol Translation (NAT-PT) translation events, use the
debugipv6natcommand in privileged EXEC mode. To disable debug messages for NAT-PT translation events, use the
no form of this command.
debugipv6nat
[ detailed | port ]
nodebugipv6nat
[ detailed | port ]
Syntax Description
detailed
(Optional) Displays detailed information about NAT-PT translation events.
port
(Optional) Displays port allocation events.
Command Default
Debugging for NAT-PT translation events is not enabled.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.2(13)T
This command was introduced.
12.3(2)T
The
port keyword was added to support Port Address Translation (PAT), or overload, multiplexing multiple IPv6 addresses to a single IPv4 address or to an IPv4 address pool.
Usage Guidelines
The
debugipv6natcommand can be used to troubleshoot NAT-PT translation issues. If no keywords are specified, debugging messages for all NAT-PT protocol translation events are displayed.
Note
By default, the network server sends the output fromdebug commands and system error messages to the console. To redirect debugging output, use the logging command options within global configuration mode. Destinations are the console, virtual terminals, internal buffer, and UNIX hosts running a syslog server.
Caution
Because the
debugipv6nat command generates a substantial amount of output, use it only when traffic on the IPv6 network is low, so other activity on the system is not adversely affected.
Examples
The following example shows output for the
debugipv6natcommand:
The table below describes the significant fields shown in the display.
Table 1 debug ipv6 nat Field Descriptions
Field
Description
IPv6 NAT:
Indicates that this is a NAT-PT packet.
icmp
Protocol of the packet being translated.
src (3000::8) -> (192.168.124.8)
The source IPv6 address and the NAT-PT mapped IPv4 address.
Note
If mapping IPv4 hosts to IPv6 hosts the first address would be an IPv4 address, and the second address an IPv6 address.
dst (2001::2) -> (192.168.123.2)
The destination IPv6 address and the NAT-PT mapped IPv4 address.
Note
If mapping IPv4 hosts to IPv6 hosts the first address would be an IPv4 address, and the second address an IPv6 address.
The following example shows output for the
debugipv6natcommand with the
detailed keyword:
Router# debug ipv6 nat detailed
00:14:12: IPv6 NAT: address allocated 192.168.124.8
00:14:16: IPv6 NAT: deleted a NAT entry after timeout
debug ipv6 nd
To display debug messages for IPv6 Internet Control Message Protocol (ICMP ) neighbor discovery transactions, use the
debugipv6ndcommand in privileged EXEC mode. To disable debug messages for IPv6 ICMP neighbor discovery transactions, use the
no form of this command.
debugipv6nd
nodebugipv6nd
Syntax Description
This command has no arguments or keywords.
Command Default
Debugging for IPv6 ICMP neighbor discovery is not enabled.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.2(2)T
This command was introduced.
12.2(4)T
The DAD:
<nnnn ::nn :> is unique, DAD: duplicate link-local
<nnnn ::nn :> on
<interface type >, interface stalled, and Received NA for
<nnnn ::nn :> on
<interface type > from
<nnnn ::nn :> fields were added to the command output.
12.0(21)ST
This command was integrated into Cisco IOS Release 12.0(21)ST.
12.0(22)S
This command was integrated into Cisco IOS Release 12.0(22)S.
12.2(14)S
This command was integrated into Cisco IOS Release 12.2(14)S.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(25)SG
This command was integrated into Cisco IOS Release 12.2(25)SG.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
Usage Guidelines
This command can help determine whether the router is sending or receiving IPv6 ICMP neighbor discovery messages.
Note
By default, the network server sends the output from debug commands and system error messages to the console. To redirect debug output, use the logging command options within global configuration mode. Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog server. For complete information on debug commands and redirecting debug output, refer to the
Cisco IOS Debug Command Reference .
Examples
The following example shows output for the
debugipv6ndcommand:
Router# debug ipv6 nd
13:22:40:ICMPv6-ND:STALE -> DELAY:2000:0:0:3::2
13:22:45:ICMPv6-ND:DELAY -> PROBE:2000:0:0:3::2
13:22:45:ICMPv6-ND:Sending NS for 2000:0:0:3::2 on FastEthernet0/0
13:22:45:ICMPv6-ND:Received NA for 2000:0:0:3::2 on FastEthernet0/0 from 2000:0:0:3::2
13:22:45:ICMPv6-ND:PROBE -> REACH:2000:0:0:3::2
13:22:45:ICMPv6-ND:Received NS for 2000:0:0:3::1 on FastEthernet0/0 from FE80::203:A0FF:FED6:1400
13:22:45:ICMPv6-ND:Sending NA for 2000:0:0:3::1 on FastEthernet0/0
13:23:15: ICMPv6-ND: Sending NS for FE80::1 on Ethernet0/1
13:23:16: ICMPv6-ND: DAD: FE80::1 is unique.
13:23:16: ICMPv6-ND: Sending NS for 2000::2 on Ethernet0/1
13:23:16: ICMPv6-ND: Sending NS for 3000::3 on Ethernet0/1
13:23:16: ICMPv6-ND: Sending NA for FE80::1 on Ethernet0/1
13:23:17: ICMPv6-ND: DAD: 2000::2 is unique.
13:23:53: ICMPv6-ND: Sending NA for 2000::2 on Ethernet0/1
13:23:53: ICMPv6-ND: DAD: 3000::3 is unique.
13:23:53: ICMPv6-ND: Sending NA for 3000::3 on Ethernet0/1
3d19h: ICMPv6-ND: Sending NS for FE80::2 on Ethernet0/2
3d19h: ICMPv6-ND: Received NA for FE80::2 on Ethernet0/2 from FE80::2
3d19h: ICMPv6-ND: DAD: duplicate link-local FE80::2 on Ethernet0/2,interface stalled
3d19h: %IPV6-4-DUPLICATE: Duplicate address FE80::2 on Ethernet0/2
3d19h: ICMPv6-ND: Sending NS for 3000::4 on Ethernet0/3
3d19h: ICMPv6-ND: Received NA for 3000::4 on Ethernet0/3 from 3000::4
3d19h: %IPV6-4-DUPLICATE: Duplicate address 3000::4 on Ethernet0/3
The table below describes the significant fields shown in the display.
Table 2 debug ipv6 nd Field Descriptions
Field
Description
13:22:40:
Indicates the time (hours:minutes:seconds) at which the ICMP neighbor discovery event occrred.
ICMPv6-ND
Indicates that a state change is occurring for an entry in the IPv6 neighbors cache.
STALE
Stale state. This state of an neighbor discovery cache entry used to be "reachable," but is now is "stale" due to the entry not being used. In order to use this address, the router must go through the neighbor discovery process in order to confirm reachability.
DELAY
Delayed state. Reachability for this ND cache entry is currently being reconfirmed. While in the delay state, upper-layer protocols may inform IPv6 that they have confirmed reachability to the entry. Therefore, there is no need to send a neighbor solicitation for the entry.
PROBE
Probe state. While in the probe state, if no confirmation is received from the upper-layer protocols about the reachability of the entry, a neighbor solicitation message is sent. The entry remains in the "probe" state until a neighbor advertisement message is received in response to the neighbor solicitation message.
Sending NS for...
Sending a neighbor solicitation message. In the example output, a neighbor solicitation message is sent on Fast Ethernet interface 0/0 to determine the link-layer address of 2000:0:0:3::2 on Fast Ethernet interface 0/0.
Received NA for...
Received a neighbor advertisement message. In the example output, a neighbor advertisement message is received from the address 2000:0:0:3::2 (the second address) that includes the link-layer address of 2000:0:0:3::2 (first address) from Ethernet interface 0/0.
REACH
Reachable state. An ND cache entry in this state is considered reachable, and the corresponding link-layer address can be used without needing to perform neighbor discovery on the address.
Received NS for...
Received neighbor solicitations. In the example output, the address FE80::203:A0FF:FED6:1400 (on Fast Ethernet interface 0/0) is trying to determine the link-local address of 2000:0:0:3::1.
Sending NA for...
Sending for neighbor advertisements. In the example output, a neighbor advertisement containing the link-layer address of 2000:0:0:3::1 (an address assigned to the Fast Ethernet interface 0/0 address) was sent.
DAD: FE80::1 is unique.
Duplicate address detection processing was performed on the unicast IPv6 address (a neighbor solicitation message was not received in response to a neighbor advertisement message that contained the unicast IPv6 address) and the address is unique.
3d19h:
Indicates time (days, hours) since the last reboot of the event occurring; 3d19h: indicates the time (since the last reboot) of the event occurring was 3 days and 19 hours ago.
DAD: duplicate link-local FE80::2 on Ethernet0/2, interface stalled
Duplicate address detection processing was performed on the link-local IPv6 address (the link-local address FE80::2 is used in the example). A neighbor advertisement message was received in response to a neighbor solicitation message that contained the link-local IPv6 address. The address is not unique, and the processing of IPv6 packets is disabled on the interface.
%IPV6-4-DUPLICATE: Duplicate address...
System error message indicating the duplicate address.
Received NA for 3000::4 on Ethernet0/3 from 3000::4
Duplicate address detection processing was performed on the global IPv6 address (the global address 3000::4 is used in the example). A neighbor advertisement message was received in response to a neighbor solicitation message that contained the global IPv6 address. The address is not unique and is not used.
Related Commands
Command
Description
debugipv6icmp
Displays debug messages for IPv6 ICMP transactions.
To display debugging information for Open Shortest Path First (OSPF) for IPv6, use the debugipv6ospf command in privileged EXEC mode. To disable debugging output, use the no form of this command.
(Optional) Displays the interaction between OSPF and IPSec in IPv6 networks, including creation and removal of policy definitions.
database-timer
(Optional) Displays database-timer information.
flood
(Optional) Displays flooding information.
hello
(Optional) Displays hello packet information.
l2api
(Optional) Enables layer 2 and layer 3 application program interface (API) debugging.
lsa-generation
(Optional) Displays link-state advertisement (LSA) generation information for all LSA types.
retransmission
(Optional) Displays retransmission information.
Command Default
Debugging of OSPF for IPv6 is not enabled.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(24)S
This command was introduced.
12.2(15)T
This command was integrated in Cisco IOS Release 12.2(15)T.
12.2(18)S
This command was integrated in Cisco IOS Release 12.2(18)S.
12.3(4)T
The ipsec keyword was added to support OSPF for IPv6 authentication for IPSec.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
12.4(25)T
The l2api keyword was added.
Usage Guidelines
Consult Cisco technical support before using this command.
Examples
The following example displays adjacency information for OSPF for IPv6:
Router# debug ipv6 ospf adj
debug ipv6 ospf database-timer rate-limit
To display debugging information about the current wait-time used for SPF scheduling, use the debugipv6ospfdatabase-timerrate-limitcommand in privileged EXEC mode. To disable debugging output, use the no form of this command.
This command was integrated into Cisco IOS Release 12.2(33)SB.
Usage Guidelines
Consult Cisco technical support before using this command.
Examples
The following example shows how to turn on debugging for SPF scheduling:
Router# debug ipv6 ospf database-timer rate-limit
debug ipv6 ospf events
To display information on Open Shortest Path First (OSPF)-related events, such as designated router selection and shortest path first (SPF) calculation, use the debugipv6ospfevents command in privileged EXEC com
mand. To disable debugging output, use the no form of this command.
debugipv6ospfevents
nodebugipv6ospfevents
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(24)S
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
12.2(18)S
This command was integrated into Cisco IOS Release 12.2(18)S.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
Command History
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
12.2(33)XNE
This command was modified. It was integrated into Cisco IOS Release 12.2(33)XNE.
Usage Guidelines
Consult Cisco technical support before using this command.
Examples
The following example displays information on OSPF-related events:
Router#
debug ipv6 ospf events
debug ipv6 ospf graceful-restart
To enable debugging for IPv6 graceful-restart-related events, use the debugipv6ospfgraceful-restartcommand in privileged EXEC mode.
debugipv6ospfgraceful-restart
Syntax Description
This command has no arguments or keywords.
Command Default
Debugging is not enabled.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
Cisco IOS XE Release 2.1
This command was introduced.
15.0(1)M
This command was integrated into Cisco IOS Release 15.0(1)M.
12.2(33)SRE
This command was modified. It was integrated into Cisco IOS Release 12.2(33)SRE.
Usage Guidelines
The debugipv6ospfgraceful-restart command helps troubleshoot graceful-restart-related events on both graceful-restart-capable and graceful-restart-aware routers.
Examples
The following example enables debugging for graceful-restart-related events:
Router# debug ipv6 ospf graceful-restart
00:03:41: OSPFv3: GR timer started for ospf process 1 for 120 secs,
00:03:43: OSPFv3: GR Build Grace LSA for interface Ethernet0/0
00:03:43: OSPFv3: GR Flood grace lsa on Ethernet0/0
00:03:43: OSPFv3: GR complete check for area 0 process 1
00:03:43: OSPFv3: GR wait, Ethernet0/0 in area 0 not yet complete
00:03:45: OSPFv3: GR Re-flood Grace LSA on Ethernet0/0
00:04:01: OSPFv3: GR initial wait expired
00:04:01: OSPFv3: GR complete check for area 0 process 1
00:04:01: OSPFv3: GR wait, Ethernet0/0 in area 0 not yet complete
00:04:07: OSPFv3: GR complete check for area 0 process 1
00:04:07: OSPFv3: GR re-sync completed in area 0, process 1
00:04:07: OSPFv3: GR complete check for process 1
00:04:07: OSPFv3: process 1: GR re-sync completed for all neighbors
00:04:07: OSPFv3: scheduling rtr lsa for area 0 process 1
00:04:07: OSPFv3: Post GR, flood maxaged grace-LSA on Ethernet0/0
Related Commands
Command
Description
graceful-restart
Enables the OSPFv3 graceful restart feature on a graceful-restart-capable router.
graceful-restarthelper
Enables the OSPFv3 graceful restart feature on a graceful-restart-aware router.
showipv6ospfgraceful-restart
Displays OSPFv3 graceful restart information.
debug ipv6 ospf lsdb
To display database modifications for Open Shortest Path First (OSPF) for IPv6, use the debugipv6ospflsdbcommand in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugipv6ospflsdb
nodebugipv6ospflsdb
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(24)S
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
12.2(18)S
This command was integrated into Cisco IOS Release 12.2(18)S.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
Usage Guidelines
Consult Cisco technical support before using this command.
Examples
The following example displays database modification information for OSPF for IPv6:
Router# debug ipv6 ospf lsdb
debug ipv6 ospf monitor
To display debugging information about the current wait-time used for shortest path first (SPF) scheduling, use the debugipv6ospfmonitor command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugipv6ospfmonitor
nodebugipv6ospfmonitor
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
12.2(33)SRC
This command was introduced.
Command History
12.2(33)SB
This command was integrated into Cisco IOS Release 12.2(33)SB.
Usage Guidelines
Consult Cisco technical support before using this command.
Examples
The following example shows debugging information about SPF scheduling:
Router# debug ipv6 ospf monitor
Sep 27 08:29:49.319: OSPFv3: Schedule SPF in area 0
Change in LS ID 0.0.0.0, LSA type P
*Sep 27 08:29:49.327: OSPFv3: reset throttling to 5000ms next wait-interval 10000ms
*Sep 27 08:29:49.327: OSPFv3: schedule SPF: spf_time 00:09:36.032 wait_interval 5000ms
IOU_Topvar#
*Sep 27 08:29:54.331: OSPFv3: Begin SPF at 581.036ms, process time 40ms
*Sep 27 08:29:54.331: spf_time 00:09:36.032, wait_interval 5000ms
*Sep 27 08:29:54.331: OSPFv3: Setting next wait-interval to 10000ms
*Sep 27 08:29:54.331: OSPFv3: End SPF at 581.036ms, Total elapsed time 0ms
*Sep 27 08:29:54.331: Schedule time 00:09:41.036, Next wait_interval 10000ms
*Sep 27 08:29:54.331: Intra: 0ms, Inter: 0ms, External: 0ms
*Sep 27 08:29:54.331: R: 0, N: 0
*Sep 27 08:29:54.331: SN: 0, SA: 0, X5: 0, X7: 0
*Sep 27 08:29:54.331: SPF suspends: 0 intra, 0 total
debug ipv6 ospf packet
To display information about each Open Shortest Path First (OSPF) for IPv6 packet received, use the debugipv6ospfpacket command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugipv6ospfpacket
nodebugipv6ospfpacket
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(24)S
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
12.2(18)S
This command was integrated into Cisco IOS Release 12.2(18)S.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
Usage Guidelines
Consult Cisco technical support before using this command.
Examples
The following example displays information about each OSPF for IPv6 packet received:
Router# debug ipv6 ospf packet
debug ipv6 ospf spf statistic
To display statistical information while running the shortest path first (SPF) algorithm, use thedebugipv6ospfspfstatisticcommand in privileged EXEC mode. To disable the debugging output, use the no form of this command.
debugipv6ospfspfstatistic
nodebugipv6ospfspfstatistic
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(24)S
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
12.2(18)S
This command was integrated into Cisco IOS Release 12.2(18)S.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
Usage Guidelines
The debugipv6ospfspfstatistic command displays the SPF calculation times in milliseconds, the node count, and a time stamp. Consult Cisco technical support before using this command.
Examples
The following example displays statistical information while running the SPF algorithm:
Router# debug ipv6 ospf spf statistics
Related Commands
Command
Description
debugipv6ospf
Displays debugging information for the OSPFv3 for IPv6 feature.
debugipv6ospfevents
Displays information on OSPFv3-related events.
debugipv6ospfpacket
Displays information about each OSPFv3 packet received.
debug ipv6 packet
To display debug messages for IPv6 packets, use the
debugipv6packetcommand in privileged EXEC mode. To disable debug messages for IPv6 packets, use the
no form of this command.
(Optional) Specifies an IPv6 access list. The access list name cannot contain a space or quotation mark, or begin with a numeric
detail
(Optional) May display additional detailed information about the IPv6 packet.
Command Default
Debugging for IPv6 packets is not enabled.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.2(2)T
This command was introduced.
12.0(21)ST
This command was integrated into Cisco IOS Release 12.0(21)ST.
12.0(22)S
This command was integrated into Cisco IOS Release 12.0(22)S.
12.0(23)S
The
access-list and
detail keywords, and the
access-list-nameargument, were added.
12.2(13)T
The
access-list and
detail keywords, and the
access-list-nameargument, were added.
12.2(14)S
This command was integrated into Cisco IOS Release 12.2(14)S.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(25)SG
This command was integrated into Cisco IOS Release 12.2(25)SG.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
Usage Guidelines
The
debugipv6packetcommand is similar to the
debugippacketcommand, except that it is IPv6-specific.
Note
By default, the network server sends the output from debug commands and system error messages to the console. To redirect debug output, use the logging command options within global configuration mode. Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog server. For complete information on debug commands and redirecting debug output, refer to the
Cisco IOS Debug Command Reference .
IPv6 debugging information includes packets received, generated, and forwarded. Fast-switched packets do not generate messages. When an IPv6 access list is specified by using the
access-listkeyword and
access-list-nameargument, only packets matching the access list permit entries are displayed.
Caution
Because the
debugipv6packet command generates a substantial amount of output, use it only when traffic on the IPv6 network is low, so other activity on the system is not adversely affected.
Examples
The following example shows output for the
debugipv6packetcommand:
Router# debug ipv6 packet
13:25:40:IPV6:source 2000:0:0:3::1 (local)
13:25:40: dest 2000:0:0:3::2 (FastEthernet0/0)
13:25:40: traffic class 96, flow 0x0, len 143+195, prot 6, hops 64, originating
13:25:40:IPv6:Sending on FastEthernet0/0
13:25:40:IPV6:source 2000:0:0:3::2 (FastEthernet0/0)
13:25:40: dest 2000:0:0:3::1
13:25:40: traffic class 96, flow 0x0, len 60+14, prot 6, hops 64, forward to ulp
13:25:45:IPV6:source FE80::203:E4FF:FE12:CC1D (local)
13:25:45: dest FF02::9 (Ethernet1/1)
13:25:45: traffic class 112, flow 0x0, len 72+1428, prot 17, hops 255, originating
13:25:45:IPv6:Sending on Ethernet1/1
13:25:45:IPV6:source FE80::203:E4FF:FE12:CC00 (local)
13:25:45: dest 2000:0:0:3::2 (FastEthernet0/0)
13:25:45: traffic class 112, flow 0x0, len 72+8, prot 58, hops 255, originating
13:25:45:IPv6:Sending on FastEthernet0/0
13:25:45:IPV6:source 2000:0:0:3::2 (FastEthernet0/0)
13:25:45: dest FE80::203:E4FF:FE12:CC00
13:25:45: traffic class 112, flow 0x0, len 64+14, prot 58, hops 255, forward to ulp
13:25:45:IPV6:source FE80::203:A0FF:FED6:1400 (FastEthernet0/0)
13:25:45: dest 2000:0:0:3::1
13:25:45: traffic class 112, flow 0x0, len 72+14, prot 58, hops 255, forward to ulp
The table below describes the significant fields shown in the display.
Table 3 debug ipv6 packet Field Descriptions
Field
Description
IPV6:
Indicates that this is an IPv6 packet.
source 2000:0:0:3::1 (local)
The source address in the IPv6 header of the packet.
dest 2000:0:0:3::2 (FastEthernet0/0)
The destination address in the IPv6 header of the packet.
traffic class 96
The contents of the traffic class field in the IPv6 header.
flow 0x0
The contents of the flow field of the IPv6 header. The flow field is used to label sequences of packets for which special handling is necessary by IPv6 routers.
len 64+14
The length of the IPv6 packet. The length is expressed as two numbers with a plus (+) character between the numbers. The first number is the length of the IPv6 portion (IPv6 header length plus payload length). The second number is the entire datagram size minus the first number.
prot 6
The protocol field in the IPv6 header. Describes the next layer protocol that is carried by the IPv6 packet. In the example, the protocol 58 signifies that the next layer protocol is ICMPv6.
hops 64
The hops field in the IPv6 packet. This field is similar in function to the IPv4 time-to-live field.
originating
The presence of this field indicates that the packet shown was originated by the router.
Sending on FastEthernet0/0
Specifies the interface on which the packet was sent.
forward to ulp
Indicates that the packet was received by the router at the destination address and was forwarded to an upper-layer protocol (ulp) for processing.
debug ipv6 pim
To enable debugging on Protocol Independent Multicast (PIM) protocol activity, use the debugipv6pimcommand in privileged EXEC mode. To restore the default value, use the no form of this command.
(Optional) IPv6 address or name of the multicast group.
interfaceinterface-type
(Optional) Displays debugging statistics about a specific interface type.
bsr
(Optional) Displays debugging statistics specific to bootstrap router (BSR) protocol operation.
group
(Optional) Displays debugging information about group-related activity.
neighbor
(Optional) Displays debugging statistics related to hello message processing and neighbor cache management.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.3(2)T
This command was introduced.
12.2(18)S
This command was integrated into Cisco IOS Release 12.2(18)S.
12.0(26)S
This command was integrated into Cisco IOS Release 12.0(26)S.
12.0(28)S
The bsr keyword was added.
12.2(25)S
The bsr keyword was added.
12.3(11)T
The bsr keyword was added.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(25)SG
This command was integrated into Cisco IOS Release 12.2(25)SG.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
Cisco IOS XE Release 2.1
This command was introduced on Cisco ASR 1000 Series Routers.
Usage Guidelines
This command helps discover whether the PIM protocol activities are working correctly.
The messages displayed by the debugipv6pimcommand show all PIM protocol messages, such as joins and prunes, received from or sent to other routers. Use this command in conjunction with debugipv6mldto display additional multicast activity, to learn more information about the multicast routing process, or to learn why packets are forwarded out of particular interfaces.
Examples
The following example enables debugging on PIM activity:
Router# debug ipv6 pim
Related Commands
Command
Description
debugipv6mld
Enables debugging on MLD protocol activity.
debug ipv6 pim df-election
To display debug messages for
Protocol Independent Multicast (
PIM) bidirectional designated forwarder (DF) election message processing, use the debugipv6pimdf-electioncommand in privileged EXEC mode. To disable debug messages for PIM bidirectional DF election message processing, use the no form of this command.
(Optional) Specifies that debug messages on a specified interface will be displayed.
typenumber
(Optional) Interface type and number. For more information, use the question mark (?) online help function.
rp
(Optional) Specifies that debug messages on a specified Route Processor (RP) will be displayed.
rp-name
(Optional) The name of the specified RP.
rp-address
(Optional) The IPv6 address of the specified RP.
Command Default
Debugging for PIM bidirectional DF election message processing is not enabled.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
12.3(7)T
This command was introduced.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
Usage Guidelines
Use the debugipv6pimdf-electioncommand if traffic is not flowing properly when operating in PIM bidirectional mode or if the showipv6pimdf and showipv6pimdfwinnercommandsdo not display the expected information.
Examples
The following example shows how to enable debugging for PIM bidirectional DF election message processing on Ethernet interface 1/0 and at 200::1:
Route# debug ipv6 pim df-election interface ethernet 1/0 rp 200::1
Related Commands
Command
Description
ipv6pimrp-address
Configures the address of a PIM RP for a particular group range.
showipv6pimdf
Displays the DF-election state of each interface for each RP.
showipv6pimdfwinner
Displays the DF-election winner on each interface for each RP.
debug ipv6 pim limit
To enable debugging for Protocol Independent Multicast (PIM) interface limits, use the debugipv6pimlimit command in privileged EXEC mode. To restore the default value, use the no form of this command.
debugipv6pimlimit [group]
nodebugipv6pimlimit
Syntax Description
group
(Optional) Specific group to be debugged.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
12.2(33)SRE
This command was introduced.
Usage Guidelines
Use the debugipv6pimlimit command to display debugging information for interface limits and costs. Use the optional group argument to specify a particular group to debug.
Examples
The following example enables PIM interface limit debugging:
Router# debug ipv6 pim limit
Related Commands
Command
Description
ipv6multicastlimit
Configures per-interface mroute state limiters in IPv6.
ipv6multicastlimitcost
Applies a cost to mroutes that match per interface mroute state limiters in IPv6.
debug ipv6 policy
To enable debugging of IPv6 policy routing packet activity, use the
debugipv6policy command in user EXEC or privileged EXEC mode. To disable debugging, use the
no form of this command.
debugipv6policy [access-list-name]
nodebugipv6policy [access-list-name]
Syntax Description
access-list-name
(Optional) Name of the IPv6 access list. Names cannot contain a space or quotation mark or begin with a numeric.
Command Default
If no access list is specified using the optional
access-list-name argument, information about all policy-matched and policy-routed packets is displayed.
Command Modes
User EXEC (>)
Privileged EXEC (#)
Command History
Release
Modification
12.3(7)T
This command was introduced.
12.2(30)S
This command was integrated into Cisco IOS Release 12.2(30)S.
12.2(33)SXI4
This command was integrated into Cisco IOS Release 12.2(33)SXI4.
Cisco IOS XE Release 3.2S
This command was integrated into Cisco IOS XE Release 3.2S.
15.1(1)SY
This command was integrated into Cisco IOS Release 15.1(1)SY.
Usage Guidelines
After you configure IPv6 policy routing, use the
debugipv6policy command to verify that IPv6 policy-based routing (PBR) is policy-routing packets normally. Policy routing analyzes various parts of the packet and then routes the packet based on certain user-defined attributes in the packet. The
debugipv6policy command helps you determine what policy is followed during routing. It displays information about whether a packet matches the given criteria, and if yes, the resulting routing information for the packet.
Do not use the
debugipv6policy command unless you suspect a problem with IPv6 PBR policy routing.
Examples
The following example shows how to enable debugging of IPv6 policy routing packet activity. The output of this command is self-explanatory:
To enable debugging on IPv6 prefix pools, use the debug ipv6 pool command in privileged EXEC mode. To disable debugging, use the no form of this command.
debugipv6pool
nodebugipv6pool
Syntax Description
This command has no keywords or arguments.
Command Default
No debugging is active.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.2(13)T
This command was introduced.
Examples
The following example enables debugging for IPv6 prefix pools:
Router# debug ipv6 pool
2w4d: IPv6 Pool: Deleting route/prefix 2001:0DB8::/29 to Virtual-Access1 for cisco
2w4d: IPv6 Pool: Returning cached entry 2001:0DB8::/29 for cisco on Virtual-Access1 to
pool1
2w4d: IPv6 Pool: Installed route/prefix 2001:0DB8::/29 to Virtual-Access1 for cisco
Related Commands
Command
Description
ipv6localpool
Configures a local IPv6 prefix pool.
showipv6interface
Displays the usability status of interfaces configured for IPv6.
showipv6localpool
Displays information about defined IPv6 prefix pools.
debug ipv6 rip
To display debug messages for IPv6 Routing Information Protocol (RIP) transactions, use the
debugipv6rip command in privileged EXEC mode. To disable debug messages for IPv6 RIP routing transactions, use the
no form of this command.
Cisco IOS XE Release 3.9S, Cisco IOS Release 15.3(2)S, and Later Releases
(Optional) Interface type for which to display the debug messages.
interface-number
(Optional) Interface number for which to display the debug messages.
vrf vrf-name
(Optional) Displays information about the specified virtual routing and forwarding (VRF) instance.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
12.2(2)T
This command was introduced.
12.0(21)ST
This command was integrated into Cisco IOS Release 12.0(21)ST.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(25)SG
This command was integrated into Cisco IOS Release 12.2(25)SG.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
Cisco IOS XE Release 2.1
This command was implemented on Cisco 1000 Series Aggregation Services Routers.
Cisco IOS XE Release 3.9S
This command was modified. The vrf vrf-name keyword-argument pair was added.
15.3(2)S
This command was integrated into Cisco IOS Release 15.3(2)S.
15.3(3)M
This command was integrated into Cisco IOS Release 15.3(3)M.
Usage Guidelines
The
debugipv6rip command is similar to the
debugiprip command, except that it is IPv6-specific.
Note
By default, the network server sends the output from debug commands and system error messages to the console. To redirect debug output, use the logging command in global configuration mode. Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog server. For complete information on debug commands and redirecting debug output, refer to the
Cisco IOS Debug Command Reference.
Use the debug ipv6 rip command to enable IPv6 RIP debugging for RIP packets that are sent and received on all device interfaces. Use the debug ipv6 ripinterface-typeinterface-number command to enable IPv6 RIP debugging for RIP packets that are sent and received only on the specified interface.
Use the debug ipv6 rip vrfvrf-name command to troubleshoot issues in the IPv6 RIP functionality when the VRF has already been enabled using a vrf definitionvrf-name command. Ensure that the specified VRF name has already been defined. If a VRF name has not been defined, the following message is displayed:
% VRF <undefined VRF name> does not exist or does not have a RD.
Examples
The following is sample output from the debugipv6rip command:
Device# debug ipv6 rip
13:09:10:RIPng:Sending multicast update on Ethernet1/1 for as1_rip
13:09:10: src=2001:DB8::1
13:09:10: dst=2001:DB8:0:ABCD::1 (Ethernet1/1)
13:09:10: sport=521, dport=521, length=32
13:09:10: command=2, version=1, mbz=0, #rte=1
13:09:10: tag=0, metric=1, prefix=::/0
13:09:28:RIPng:response received from 2001:DB8:0:0:E000::F on Ethernet1/1 for as1_rip
13:09:28: src=FE80::202:FDFF:FE77:1E42 (Ethernet1/1)
13:09:28: dst=FF02::9
13:09:28: sport=521, dport=521, length=32
13:09:28: command=2, version=1, mbz=0, #rte=1
13:09:28: tag=0, metric=1, prefix=2000:0:0:1:1::/80
The above example shows two RIP packets; both are known as “responses” in RIP terminology and indicated by a “command” value of 2. The first is an update sent by the device, and the second is an update received by the device. Multicast update packets are sent to all neighboring IPv6 RIP devices (all devices that are on the same links as the device sending the update and have IPv6 RIP enabled). An IPv6 RIP device 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 device may also send “triggered” updates immediately following a routing table change. In this case, the updates include only the changes to the routing table. An IPv6 RIP device may solicit the contents of the routing table of a neighboring device by sending a Request (command =1) message to the device. The device responds 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 2001:DB8:0:0:E000::F or a response to a RIP request message that was previously sent by the local device.
The following is sample output from the debugipv6ripvrf command:
Device# debug ipv6 rip vrf blue
RIP Routing Protocol debugging is on for vrf blue
Sending:
*Mar 15 11:23:08.508: RIPng: Sending multicast update on Ethernet0/0 for vrf for vrf blue
*Mar 15 11:23:08.508: src=2001:DB8:0:1:FFFF:1234::5
*Mar 15 11:23:08.508: dst=2001:DB8:0:1::1 (Ethernet0/0)
*Mar 15 11:23:08.508: sport=521, dport=521, length=52
*Mar 15 11:23:08.508: command=2, version=1, mbz=0, #rte=2
*Mar 15 11:23:08.508: tag=0, metric=1, prefix=6000::/64
*Mar 15 11:23:08.508: tag=0, metric=1, prefix=2000::/64
*Mar 15 11:23:08.508: RIPng: Packet waiting
*Mar 15 11:23:08.508: RIPng: Process vrf received own response on Loopback1
Receiving
*Mar 15 11:23:20.316: RIPng: Packet waiting
*Mar 15 11:23:20.316: RIPng: response received from FE80::A8BB:CCFF:FE00:7C00 on Ethernet0/0 for vrf
*Mar 15 11:23:20.316: src=2001:DB8:0:1:FFFF:1234::4 (Ethernet0/0)
*Mar 15 11:23:20.316: dst=2001:DB8::1
*Mar 15 11:23:20.316: sport=521, dport=521, length=32
*Mar 15 11:23:20.316: command=2, version=1, mbz=0, #rte=1
*Mar 15 11:23:20.316: tag=0, metric=1, prefix=AAAA::/64
The table below describes the significant fields shown in the display.
Table 4 debug ipv6 rip vrf Field Descriptions
Field
Description
src
The address from which the update was originated.
dst
The destination address for the update.
sport, dport, length
The source, destination ports and the length for the update. (IPv6 RIP uses port 521, as shown in the display.)
command
The command field within the RIP packet. A value of 2 indicates that the RIP packet is a response (update); a value of 1 indicates that the RIP packet is a request.
version
The version of IPv6 RIP being used. The current version is 1.
mbz
There must be a 0 (mbz) field within the RIP packet.
#rte
Indicates the number of routing table entries (RTEs) that the RIP packet contains.
tag
metric
prefix
The tag, metric, and prefix fields are specific to each RTE contained in the update.
The tag field is intended to allow for the flagging of IPv6 RIP “internal” and “external” routes.
The metric field is the distance metric from the device (sending this update) to the prefix.
The prefix field is the IPv6 prefix of the destination being advertised.
Related Commands
Command
Description
clearipv6rip
Deletes routes from the IPv6 RIP routing table.
ipv6ripvrf-modeenable
Enables VRF support for IPv6 RIP.
showipv6rip
Displays information about current IPv6 RIP processes.
vrfdefinition
Configures a VRF routing table instance.
debug ipv6 routing
To display debug messages for IPv6 routing table updates and route cache updates, use the debugipv6routingcommand in privileged EXEC mode. To disable debug messages for IPv6 routing table updates and route cache updates, use the no form of this command.
debugipv6routing
nodebugipv6routing
Syntax Description
This command has no arguments or keywords.
Command Default
Debugging for IPv6 routing table updates and route cache updates is not enabled.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.2(2)T
This command was introduced.
12.0(21)ST
This command was integrated into Cisco IOS Release 12.0(21)ST.
12.0(22)S
This command was integrated into Cisco IOS Release 12.0(22)S.
12.2(14)S
This command was integrated into Cisco IOS Release 12.2(14)S.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(25)SG
This command was integrated into Cisco IOS Release 12.2(25)SG.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
Usage Guidelines
The debugipv6routingcommand is similar to the debugiproutingcommand, except that it is IPv6-specific.
Note
By default, the network server sends the output from debug commands and system error messages to the console. To redirect debug output, use the logging command options within global configuration mode. Destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog server. For complete information on debug commands and redirecting debug output, refer to the Cisco IOS Debug Command Reference
.
Examples
The following example shows output for the debugipv6routingcommand:
Router# debug ipv6 routing
13:18:43:IPv6RT0:Add 2000:0:0:1:1::/80 to table
13:18:43:IPv6RT0:Better next-hop for 2000:0:0:1:1::/80, [120/2]
13:19:09:IPv6RT0:Add 2000:0:0:2::/64 to table
13:19:09:IPv6RT0:Better next-hop for 2000:0:0:2::/64, [20/1]
13:19:09:IPv6RT0:Add 2000:0:0:2:1::/80 to table
13:19:09:IPv6RT0:Better next-hop for 2000:0:0:2:1::/80, [20/1]
13:19:09:IPv6RT0:Add 2000:0:0:4::/64 to table
13:19:09:IPv6RT0:Better next-hop for 2000:0:0:4::/64, [20/1]
13:19:37:IPv6RT0:Add 2000:0:0:6::/64 to table
13:19:37:IPv6RT0:Better next-hop for 2000:0:0:6::/64, [20/2]
The debugipv6routing command displays messages whenever the routing table changes. For example, the following message indicates that a route to the prefix 2000:0:0:1:1::/80 was added to the routing table at the time specified in the message.
13:18:43:IPv6RT0:Add 2000:0:0:1:1::/80 to table
The following message indicates that the prefix 2000:0:0:2::/64 was already in the routing table; however, a received advertisement provided a lower cost path to the prefix. Therefore, the routing table was updated with the lower cost path. (The [20/1] in the example is the administrative distance [20] and metric [1] of the better path.)
13:19:09:IPv6RT0:Better next-hop for 2000:0:0:2::/64, [20/1]
Related Commands
Command
Description
debugipv6rip
Displays debug messages for IPv6 RIP routing transactions.
debug ipv6 snooping
To enable debugging for security snooping information in IPv6, use the debugipv6snoopingcommand in privileged EXEC mode.
(Optional) Displays information about the neighbor binding table.
classifier
(Optional) Displays information about the classifier.
errors
(Optional) Displays information about snooping security errors.
feature-manager
(Optional) Displays feature manager information.
filteracl
(Optional) Allows users to configure an access list to filter debugged traffic.
ha
(Optional) Displays information about high availability (HA) and stateful switchover (SSO).
hw-api
(Optional) Displays information about the hardware API.
interfaceinterface
(Optional) Provides debugging information on a specified interface.
memory
(Optional) Displays information about security snooping memory.
ndp-inspection
(Optional) Displays information about Neighbor Discovery inspection.
policy
(Optional)
switcher
(Optional) Displays packets handled by the switcher.
vlan-id
(Optional) Provides debugging information about a specified VLAN ID.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
12.2(50)SY
This command was introduced.
Usage Guidelines
The debugipv6snooping command provides debugging output for IPv6 snooping information.
Because debugging output is assigned high priority in the CPU process, you should use debug commands only to troubleshoot specific problems or during troubleshooting sessions with Cisco technical support staff.
Examples
The following example enables debugging for all IPv6 snooping information:
Router# debug ipv6 snooping
debug ipv6 snooping raguard
To enable debugging for security snooping information in the IPv6 router advertisement (RA) guard feature, use the
debugipv6snoopingraguard command in privileged EXEC mode.
(Optional) Allows users to configure an access list to filter debugged traffic.
interface
(Optional) Provides debugging information about a specified interface configured with the IPv6 RA guard feature.
vlanid
(Optional) Provides debugging information about a specified VLAN ID configured with the IPv6 RA guard feature.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
12.2(54)SG
This command was introduced.
12.2(50)SY
This command was integrated into Cisco IOS Release 12.2(50)SY.
15.2(4)S
This command was integrated into Cisco IOS Release 15.2(4)S.
Usage Guidelines
The
debugipv6snoopingraguard command provides debugging output for IPv6 RA guard events and errors that may occur.
Because debugging output is assigned high priority in the CPU process, you should use debug commands only to troubleshoot specific problems or during troubleshooting sessions with Cisco technical support staff. Also, you should use debug commands during periods of lower network traffic and fewer users. Debugging during these periods decreases the likelihood that increased debug command processing overhead will affect system use.
Examples
The following example shows the command enabling debugging for the IPv6 RA guard feature:
Router# debug ipv6 snooping raguard
Related Commands
Command
Description
ipv6ndraguard
Applies the IPv6 RA guard feature.
debug ipv6 spd
To enable debugging output for the most recent Selective Packet Discard (SPD) state transition, use the debugipv6spdcommand in privileged EXEC mode.
debugipv6spd
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
15.1(3)T
This command was introduced.
Usage Guidelines
The debugipv6spd command enables debugging information to be reviewed for the most recent SPD state transition and any trend historical data.
Examples
The following example shows how to enable debugging for the most recent SPD state transition:
Router# debug ipv6 spd
debug ipv6 static
To enable Bidirectional Forwarding Detection for IPv6 (BFDv6) debugging, use the
debugipv6staticcommand in privileged EXEC mode.
debugipv6static
Command Default
Debugging is not enabled.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
Cisco IOS XE Release 2.1.0
This command was introduced.
15.1(2)T
This command was modified. It was integrated into Cisco IOS Release 15.1(2)T.
15.1(1)SG
This command was integrated into Cisco IOS Release 15.1(1)SG.
15.1(1)SY
This command was modified. Support for IPv6 was added to Cisco IOS Release 15.1(1)SY.
Usage Guidelines
Use the
debugipv6staticcommand to monitor BFDv6 operation.
Examples
The following example enables BFDv6 debugging:
Router# debug ipv6 static
Related Commands
Command
Description
monitor event ipv6 static
Monitors the operation of the IPv6 static and IPv6 static BFDv6 neighbors using event trace.
showipv6static
Displays the current contents of the IPv6 routing table.
debug ipv6 wccp
To display information about IPv6 Web Cache Communication Protocol (WCCP) services, use the
debugipv6wccp command in privileged EXEC mode. To disable debugging output, use the
no form of this command.
Specifies a virtual routing and forwarding (VRF) instance to associate with a service group.
events
Displays information about significant WCCP events.
packets
Displays information about every WCCP packet received or sent by the router.
control
(Optional) Displays information about WCCP control packets.
bypass
(Optional) Displays information about WCCP bypass packets.
redirect
(Optional) Displays information about WCCP redirect packets.
platform
Displays information about the WCCP platform application programming interface (API).
subblocks
Displays information about WCCP subblocks.
Command Default
Debug information is not displayed.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
15.2(3)T
This command was introduced.
15.1(1)SY1
This command was integrated into Cisco IOS Release 15.1(1)SY1.
Usage Guidelines
When the
vrf keyword is not used, the command displays debug information about all WCCP services on the router. The
default keyword is used to specify default WCCP services.
Examples
The following is sample output from thedebugipv6wccpeventscommand when a Cisco Cache Engine is added to the list of available Web caches:
Router# debug ipv6 wccp events
WCCP-EVNT: Built I_See_You msg body w/1 usable web caches, change # 0000000A
WCCP-EVNT: Web Cache 2001:DB8:1::1 added
WCCP-EVNT: Built I_See_You msg body w/2 usable web caches, change # 0000000B
WCCP-EVNT: Built I_See_You msg body w/2 usable web caches, change # 0000000C
The following is sample output from the
debugipv6wccppackets command. The router is sending keepalive packets to the Cisco Cache Engines at 2001:DB8:1::2 and 2001:DB8:1::1. 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 ipv6 wccp packets
WCCP-PKT: Received valid Here_I_Am packet from 2001:DB8:1::2 w/rcvd_id 00003532
WCCP-PKT: Sending I_See_You packet to 2001:DB8:1::2 w/ rcvd_id 00003534
WCCP-PKT: Received valid Here_I_Am packet from 2001:DB8:1::1 w/rcvd_id 00003533
WCCP-PKT: Sending I_See_You packet to 2001:DB8:1::1 w/ rcvd_id 00003535
WCCP-PKT: Received valid Here_I_Am packet from 2001:DB8:1::2 w/rcvd_id 00003534
WCCP-PKT: Sending I_See_You packet to 2001:DB8:1::2 w/ rcvd_id 00003536
WCCP-PKT: Received valid Here_I_Am packet from 2001:DB8:1::1 w/rcvd_id 00003535
WCCP-PKT: Sending I_See_You packet to 2001:DB8:1::1 w/ rcvd_id 00003537
WCCP-PKT: Received valid Here_I_Am packet from 2001:DB8:1::2 w/rcvd_id 00003536
WCCP-PKT: Sending I_See_You packet to 2001:DB8:1::2 w/ rcvd_id 00003538
WCCP-PKT: Received valid Here_I_Am packet from 2001:DB8:1::1 w/rcvd_id 00003537
WCCP-PKT: Sending I_See_You packet to 2001:DB8:1::1 w/ rcvd_id 00003539
Related Commands
Command
Description
clearipv6wccp
Clears the counter for packets redirected using WCCP.
ipv6wccp
Enables support of the specified WCCP service for participation in a service group.
ipv6wccpredirect
Enables packet redirection on an outbound or inbound interface using WCCP.
showipv6interface
Lists a summary of the IP information and status of an interface.
debug ipx ipxwan
To display debugging information for interfaces configured to use IPX wide-area network (IPXWAN), use the debugipxipxwancommand in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugipxipxwan
nodebugipxipxwan
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
The debugipxipxwan 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 debugipxipxwan command during link startup:
Router# debug ipx ipxwan
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
IPXWAN: state (Disconnect -> Sending Timer Requests) [Serial1/6666:200 (IPX line
state brought up)]
IPXWAN: state (Sending Timer Requests -> Disconnect) [Serial1/6666:200 (IPX line
state brought down)]
IPXWAN: state (Disconnect -> Sending Timer Requests) [Serial1/6666:200 (IPX line
state brought up)]
IPXWAN: Send TIMER_REQ [seq 0] out Serial1/6666:200
IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200
IPXWAN: Send TIMER_REQ [seq 2] out Serial1/6666:200
IPXWAN: Send TIMER_REQ [seq 0] out Serial1/6666:200
IPXWAN: Rcv TIMER_REQ on Serial1/6666:200, NodeID 1234, Seq 1
IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200
IPXWAN: Rcv TIMER_RSP on Serial1/6666:200, NodeID 1234, Seq 1, Del 6
IPXWAN: state (Sending Timer Requests -> Master: Sent RIP/SAP) [Serial1/6666:200
(Received Timer Response as master)]
IPXWAN: Send RIPSAP_INFO_REQ [seq 0] out Serial1/6666:200
IPXWAN: Rcv RIPSAP_INFO_RSP from Serial1/6666:200, NodeID 1234, Seq 0
IPXWAN: state (Master: Sent RIP/SAP -> Master: Connect) [Serial1/6666:200 (Received Router Info Rsp as Master)]
The following line indicates that the interface has initialized:
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
The following lines indicate that the startup process failed to receive a timer response, brought the link down, then brought the link up and tried again with a new timer set:
IPXWAN: state (Sending Timer Requests -> Disconnect) [Serial1/6666:200 (IPX line
state brought down)]
IPXWAN: state (Disconnect -> Sending Timer Requests) [Serial1/6666:200 (IPX line
state brought up)]
The following lines indicate that the interface is sending timer requests and waiting for a timer response:
IPXWAN: Send TIMER_REQ [seq 0] out Serial1/6666:200
IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200
The following lines indicate that the interface has received a timer request from the other end of the link and has sent a timer response. The fourth line shows that the interface has come up as the master on the link.
IPXWAN: Rcv TIMER_REQ on Serial1/6666:200, NodeID 1234, Seq 1
IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200
IPXWAN: Rcv TIMER_RSP on Serial1/6666:200, NodeID 1234, Seq 1, Del 6
IPXWAN: state (Sending Timer Requests -> Master: Sent RIP/SAP) [Serial1/6666:200
(Received Timer Response as master)]
The following lines indicate that the interface is sending RIP/SAP requests:
IPXWAN: Send RIPSAP_INFO_REQ [seq 0] out Serial1/6666:200
IPXWAN: Rcv RIPSAP_INFO_RSP from Serial1/6666:200, NodeID 1234, Seq 0
IPXWAN: state (Master: Sent RIP/SAP -> Master: Connect) [Serial1/6666:200 (Received Router Info Rsp as Master)]
debug ipx nasi
To display information about NetWare Asynchronous Services Interface (NASI) connections, use the
debugipxnasi command in Privileged EXEC configuration mode. To disable debugging output, use the
no form of this command.
debugipxnasi
{ packets | error | activity }
nodebugipxnasi
{ packets | error | activity }
Syntax Description
packets
Displays normal operating messages relating to incoming and outgoing NASI packets. This is the default.
error
Displays messages indicating an error or failure in the protocol processing.
activity
Displays messages relating to internal NASI processing of NASI connections. The activity option includes all NASI activity such as traffic indication, timer events, and state changes.
Command Default
Nasi protocol debugging is disabled.
Command Modes
Privileged EXEC
Command History
Release
Modification
11.1
This command was introduced.
Usage Guidelines
Use the
debugipxnasicommand to display handshake or negotiation details between Sequenced Packet Exchange (SPX), NASI protocol, and other protocols or applications. Use the
packets option to determine the NASI traffic flow, and use the
error option as a quick check to see why NASI connections failed.
Examples
The following is sample output from the
debugipxnasicommand with the
packet and
erroroptions.
Router# debug ipx nasi packet
Router# debug ipx nasi error
NASI0: 6E6E Check server info
NASI0: 6E6E sending server-info 4F00 Good response: 43 bytes
NASI0: 7A6E Query Port. Find first
NASI0: FFirst: line 0 DE, port: TTY1-__________ASYNC___^, group: ASYNC___^
NASI0: 7A6E sending Qport find-first response: 300 bytes
NASI0: 7B6E port request. setting up port
NASI: Check-login User: c h r i s
NASI: Check-login PW hash: C7 A6 C5 C7 C4 C0 C5 C3 C4 CC C5 CF C4 C8 C5 CB C4 D4 C5 D7 C4 D0 C5 D3 C4
NASI: Check-login PW: l a b
NASI1: 7B6E sending NCS Good server Data Ack in 0 bytes pkt in 13 size pkt
NASI1: 7B6E sending Preq response: 303 bytes Good
NASI1: 7B6E port request. setting up port
NASI1: 7B6E sending NCS Good server Data Ack in 0 bytes pkt in 13 size pkt
NASI1: 7B6E sending Preq response: 303 bytes Good
NASI1: 7B6E Unknown NASI code 4500 Pkt Size: 13
45 0 0 FC 0 2 0 20 0 0 FF 1 0
NASI1: 7B6E Flush Rx Buffers
NASI1: 7B6E sending NASI server TTY data: 1 byte in 14 size pkt
NASI1: 7B6E sending NCS Good server Data Ack in 1 bytes pkt in 13 size pkt
In the following line:
0 in NASI0 is the number of the terminal (TTY) to which this NASI connection is attached.
0 in NASI0 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 incoming NASI packet.
NASI0: 6E6E Check server info
The following message indicates that the router is sending back a server-info packet with a positive acknowledgment, and the packet size is 43 bytes:
NASI0: 6E6E sending server-info 4F00 Good response: 43 bytes
The following line is a NASI packet type. Find first and Find next are NASI packet types.
NASI0: 7A6E Query Port. Find first
The following line indicates that the outgoing find first packet for the NASI connection 7A6E has line 0 DE, port name TTY1, and general name ASYNC:
NASI0: FFirst: line 0 DE, port: TTY1-__________ASYNC___^, group: ASYNC___^
The following two lines indicate:
Received NASI packet for NASI connection in line 1. 7B6E is the NASI connection pointer. The packet code is 4500 and is not recognizable by Cisco.
Displays debugging messages related to the SPX protocol.
debug ipx packet
To display information about packets received, sent, and forwarded, use the
debugipxpacket command in privileged EXEC mode. To disable debugging output, use the
no form of this command.
debugipxpacket
nodebugipxpacket
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
This command is useful for learning whether Internetwork Packet Exchange (IPX) packets are traveling over a router.
Note
In order to generate
debugipxpacket information on all IPX traffic traveling over the router, you must first configure the router so that fast switching is disabled. Use the
noipxroute-cache command on all interfaces on which you want to observe traffic. If the router is configured for IPX fast switching, only non fast-switched packets will produce output. When the IPX cache is invalidated or cleared, one packet for each destination is displayed as the cache is repopulated.
Examples
The following is sample output from the
debugipxpacket command:
The first line indicates that the router receives a packet from a Novell station (address 160.0260.8c4c.4f22); this trace does not indicate the address of the immediate router sending the packet to this router. In the second line, the router forwards the packet toward the Novell server (address 1.0000.0000.0001) through an immediate router (183.0000.0c01.5d85).
The table below describes the significant fields shown in the display.
Table 5 debug ipx packet Field Descriptions
Field
Description
IPX
Indicates that this is an IPX packet.
src=160.0260.8c4c.4f22
Source address of the IPX packet. The Novell network number is 160. Its MAC address is 0260.8c4c.4f22.
dst=1.0000.0000.0001
Destination address for the IPX packet. The address 0000.0000.0001 is an internal MAC address, and the network number 1 is the internal network number of a Novell 3.11 server.
packet received
Router received this packet from a Novell station, possibly through an intermediate router.
gw=183.0000.0c01.5d85
Router is sending the packet over to the next hop router; its address of 183.0000.0c01.5d85 was learned from the IPX routing table.
sending packet
Router is attempting to send this packet.
debug ipx routing
To display information on Internetwork Packet Exchange (IPX) routing packets that the router sends and receives, use the
debugipxrouting command in privileged EXEC mode. To disable debugging output, use the
no form of this command.
debugipxrouting
{ activity | events }
nodebugipxrouting
{ 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
debugipxroutingcommand:
Router# debug ipx routing
IPXRIP: update from 9999.0260.8c6a.1733
110801 in 1 hops, delay 2
IPXRIP: sending update to 12FF02:ffff.ffff.ffff via Ethernet 1
network 555, metric 2, delay 3
network 1234, metric 3, delay 4
The table below describes the significant fields shown in the display.
Table 6 debug ipx routing Field Descriptions
Field
Description
IPXRIP
IPX RIP packet.
update from 9999.0260.8c6a.1733
Routing update packet from an IPX server at address 9999.0260.8c6a.1733.
110801 in 1 hops
Network 110801 is one hop away from the router at address 9999.0260.8c6a.1733.
delay 2
Delay is a time measurement (1/18th second) that the NetWare shell uses to estimate how long to wait for a response from a file server. Also known as ticks.
sending update to 12FF02:ffff.ffff.ffff via Ethernet 1
Router is sending this IPX routing update packet to address 12FF02:ffff.ffff.ffff through Ethernet interface 1.
network 555
Packet includes routing update information for network 555.
metric 2
Network 555 is two metrics (or hops) away from the router.
delay 3
Network 555 is a delay of 3 away from the router. Delay is a measurement that the NetWare shell uses to estimate how long to wait for a response from a file server. Also known as ticks.
Related Commands
Command
Description
debugipxsap
Displays information about IPX SAP packets.
debug ipx sap
To display information about Internetwork Packet Exchange (IPX) S ervice Advertisement Protocol ( SAP) packets, use the
debugipxsap command in privileged EXEC mode. To disable debugging output, use the
no form of this command.
debugipxsap
[ activity | events ]
nodebugipxsap
[ activity | events ]
Syntax Description
activity
(Optional) Provides more detailed output of SAP packets, including displays of services in SAP packets.
events
(Optional) Limits amount of detailed output for SAP packets to those that contain interesting events.
Command Modes
Privileged EXEC
Usage Guidelines
Normally, a router or server sends out one SAP update per minute. Each SAP packet can include up to seven entries. If many servers are advertising on the network, the router sends out multiple packets per update. For example, if a router has 20 entries in the SAP table, it would send three SAP packets per update. The first SAP would include the first seven entries, the second SAP would include the next seven entries, and the last update would include the last six entries.
Obtain the most meaningful detail by using the
debugipxsapactivity and the
debugipxsapevents commands together.
Caution
Because the
debugipxsapcommand can generate a substantial amount of output, use it with caution on networks that have many interfaces and large service tables.
Examples
The following is sample output from the
debugipxsap command:
Router# debug ipx sap
IPXSAP: at 0023F778:
I SAP Response type 0x2 len 160 src:160.0000.0c00.070d dest:160.ffff.ffff.ffff(452)
type 0x4, "Hello2", 199.0002.0004.0006 (451), 2 hops
type 0x4, "Hello1", 199.0002.0004.0008 (451), 2 hops
IPXSAP: sending update to 160
IPXSAP: at 00169080:
O SAP Update type 0x2 len 96 ssoc:0x452 dest:160.ffff.ffff.ffff(452)
IPX: type 0x4, "Magnolia", 42.0000.0000.0001 (451), 2hops
The
debugipxsap 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:
The table below describes the significant fields shown in the display.
Table 7 debug ipx sap Field Descriptions
Field
Description
I
Indicates whether the router received the SAP packet as input (I) or is sending an update as output (O).
SAP Response type 0x2
Packet type. Format is 0xn; possible values for
n include:
1--General query
2--General response
3--Get Nearest Server request
4--Get Nearest Server response
len 160
Length of this packet (in bytes).
src: 160.000.0c00.070d
Source address of the packet.
dest:160.ffff.ffff.ffff
IPX network number and broadcast address of the destination IPX network for which the message is intended.
(452)
I PX socket number of the process sending the packet at the source address. This number is always 452, which is the socket number for the SAP process.
type 0x4
Indicates the type of service the server sending the packet provides. Format is 0xn. Some of the values for
n are proprietary to Novell. Those values for
nthat have been published include the following (contact Novell for more information):
0--Unknown
1--User
2--User group
3--Print queue
4--File server
5--Job server
6--Gateway
7--Print server
8--Archive queue
9--Archive server
A--Job queue
B--Administration
21--NAS SNA gateway
24--Remote bridge server
2D--Time Synchronization VAP
2E--Dynamic SAP
47--Advertising print server
4B--Btrieve VAP 5.0
4C--SQL VAP
7A--TES--NetWare for VMS
98--NetWare access server
9A--Named Pipes server
9E--Portable NetWare--UNIX
111--Test server
166--NetWare management
233--NetWare management agent
237--NetExplorer NLM
239--HMI hub
23A--NetWare LANalyzer agent
26A--NMS management
FFFF--Wildcard (any SAP service)
Contact Novell for more information.
“Hello2”
Name of the server being advertised.
199.0002.0004.0006 (451)
Indicates the network number and address (and socket) of the server generating the SAP packet.
2 hops
Number of hops to the server from the router.
The fifth line of output indicates that the router sent a SAP update to network 160:
IPXSAP: sending update to 160
The format for
debugipxsap output describing a SAP update the router sends is similar to that describing a SAP update the router receives, except that the ssoc: field replaces the src: field, as the following line of output indicates:
O SAP Update type 0x2 len 96 ssoc:0x452 dest:160.ffff.ffff.ffff(452)
The ssoc:0x452 field indicates the IPX socket number of the process sending the packet at the source address. Possible values include the following:
451--Network Core Protocol
452--Service Advertising Protocol
453--Routing Information Protocol
455--NetBIOS
456--Diagnostics
4000 to 6000--Ephemeral sockets used for interaction with file servers and other network communications
Related Commands
Command
Description
debugipxrouting
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 ipxwatchdog and ipxspx-spoof are configured on the router, use the debugipxspoofcommand in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugipxspoof
nodebugipxspoof
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 debugipxspoof command:
The following lines show SPX packets for connections that exist in the SPX table but that SPX idle time has not yet elapsed and spoofing has not started:
The following lines show SPX packets that arrived more than two minutes after spoofing started. This situation occurs when the other sides of the SPX table are cleared. When the table is cleared, the routing processes stop spoofing the connection, which allows SPX keepalives from the local side to travel to the remote side and repopulate the SPX table.
To display debugging messages related to the Sequenced Packet Exchange (SPX) protocol, use the debugipxspxcommand in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugipxspx
nodebugipxspx
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
Use the debugipxspx 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 debugipxspxcommand:
Router# debug ipx spx
SPX: Sent an SPX packet
SPX: I Con Src/Dst 776E/20A0 d-strm 0 con-ctl 80
SPX: I Con Src/Dst 776E/20A0 d-strm FE con-ctl 40
SPX: C847C Connection close requested by peer
SPX: Sent an SPX packet
SPX: purge timer fired. Cleaning up C847C
SPX: purging spxcon C847C from conQ
SPX: returning inQ buffers
SPX: returning outQ buffers
SPX: returning unackedQ buffers
SPX: returning spxcon
SPX: I Con Src/Dst 786E/FFFF d-strm 0 con-ctl C0
SPX: new connection request for listening socket
SPX: Sent an SPX packet
SPX: I Con Src/Dst 786E/20B0 d-strm 0 con-ctl 40
SPX: 300 bytes data recvd
SPX: Sent an SPX packet
The following line indicates an incoming SPX packet that has a source connection ID of 776E and a destination connection ID of 20A0 (both in hexadecimal). The data stream value in the SPX packet is indicated by d-strm, and the connection control value in the SPX packet is indicated by con-ctl (both in hexadecimal). All data packets received are followed by an SPX debugging message indicating the size of the packet. All control packets received are consumed internally.
SPX: I Con Src/Dst 776E/20A0 d-strm 0 con-ctl 80
debug isdn
To display messages about activity in the structure and operation of
ISDN in the Cisco IOS software, use the
debugisdn command in privileged EXEC mode. To disable
the ISDN debugging command, use the
no form of this command.
Enables application programming interfaces (APIs) contained
in ISDN on all interfaces. The
name argument can be any one of the
following APIs. The APIs must be entered one per command-line interface (CLI)
command. To enable all of the APIs, use the
all keyword.
accept--ISDN call acceptance
all--All ISDN API tracing
bkhl--ISDN backhaul API tracing
cdapi--ISDN API tracing
csm--ISDN Compact Subscriber
Module API tracing
l2sock--ISDN Layer 2 socket API
tracing
nfas--Non-Facility Associated
Signaling
packet--ISDN packet API tracing
qsig--ISDN PRI Q Signaling API
tracing
rlm--Redundant Link Manager API
tracing
cc
Enables ISDN Call Control debug messages on all interfaces
or, optionally, on a specific interface if you use the
interface keyword. Call Control is
a layer of processing within ISDN that is above the Q.931 protocol processing
layer, but below the host and API layers.
detail
(Optional) Generates more information during the processing
of a specific request.
interface
(Optional) Limits the
debugisdn capability to one BRI or serial
interface.
brinumber
(Optional) Identifies a single BRI interface number (BRI 2,
for example) to which the
debugisdn command is applied.
serialport/number
(Optional) Identifies a single serial port and number
(serial 1/0, for example) to which the
debugisdn command is applied. Acceptable
values are 0 through 7.
error
Generates error messages for normal exception conditions in
the software on all interfaces or on a specific interface if you use the
interface keyword. The actual
significance of the message can be determined only by a detailed examination of
surrounding debug messages.
events
Displays ISDN events occurring on the user side of the ISDN
interface. See the
debugisdneventscommand page.
mgmnt
Enables ISDN Management Entity messages on all interfaces
or, optionally, on a specific interface. Management Entity controls the
activation and deactivation of Q.921 resources.
q921
Displays data link layer access procedures that are taking
place at the router on the Link Access Protocol D-channel (LAPD) of its ISDN
interface. See the
debugisdnq921command page.
q931
Displays information about call setup and teardown of ISDN
network connections between the local router and the network. See the
debugisdnq931command page.
standard
Enables a selected set of
isdndebug command messages on all interfaces
or, optionally, on a specific interface if you use the
interface keyword, that should
provide sufficient information to determine why a problem is occurring.
tgrm
Displays ISDN trunk group resource manager information. See
the
debugisdntgrmcommand page.
Command Default
Commands are enabled on all interfaces unless a specific interface is
specified.
Command Modes
Privileged EXEC
Command History
Release
Modification
10.0
This command was introduced.
12.2T
This command was enhanced with the
allapiccerrormgmnt, and
standard keywords.
12.4(6)T
The
mgmnt keyword was enhanced to
display information about sharing the terminal endpoint identifier (TEI) when
the
isdnx25dchannelq93-broadcast command is enabled for
service access point identifier (SAPI) procedures that accept X.25 calls on the
BRI D channel.
12.2(33)SRA
This command was integrated into Cisco IOS Release
12.2(33)SRA.
Usage Guidelines
Please read the following caution before using this command.
Caution
With the exception of the
debugisdnevents,
debugisdnq921,
debugisdnq931, and
debugisdntgrm commands, the commands described on this
page are not intended for customer use and can cause ISDN or the Cisco IOS
software to fail. The
debugisdnevents,
debugisdnq921,
debugisdnq931, and
debugisdntgrm commands are described on separate command
pages.
Follow all instructions from Cisco technical support personnel when
enabling and disabling these commands.
Examples
The general format of the
debugisdn command messages is as follows:
date and time: ISDN interface feature: text message
The text message can be used to determine activity in the structure
and operation of ISDN in the Cisco IOS software, ISDN messages, and ISDN
signaling procedures. The message must be interpreted by Cisco technical
personnel.
The following example shows a typical message for the
debugisdncc 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
debugisdnmessages that should provide sufficient information for Cisco
technical personnel to determine why a problem is occurring on BRI interface 2:
Router# debug isdn standard interface bri 2
The following report (highlighted in bold for purpose of example) is
displayed when the isdn x25 dchannel q931-broadcast command is used to enable
sharing the TEI:
Router# debug isdn mgmnt
*Jun 8 22:38:56.535: ISDN BR0 Q921: User TX -> IDREQ ri=29609 ai=127
*Jun 8 22:38:56.595: ISDN BR0 Q921: User RX <- IDASSN ri=29609 ai=86
*Jun 8 22:38:56.595: ISDN BR0 SERROR: L2_Go: at bailout DLCB is NULL
L2: sapi 63 tei 127 ces 0 ev 0x3
*Jun 8 22:38:56.595: ISDN BR0 MGMNT: LM_MDL_UI_DATA_IND: message 2 ri 29609 ai 86 switch type 9
*Jun 8 22:38:56.595: ISDN BR0 MGMNT: LM_MDL_UI_DATA_IND: OVERLAP REQUEST: ces 9 using lmtr tei 85 tei 85
debug isdn event
To display ISDN events occurring on the user side (on the router) of the ISDN interface, use thedebugisdnevent command in privileged EXEC mode. To disable debugging output, use the
no form of this command.
debugisdnevent
nodebugisdnevent
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Release
Modification
1x.x(x)
This command was introduced.
12.4(3rd)T
This command was enhanced to display reports about SAPI 0 procedures that accept X.25 calls on the BRI D channel.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
Usage Guidelines
Although the
debugisdnevent and the
debugisdnq931 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
showdialer command to retrieve information about the status and configuration of the ISDN interface on the router.
Use the
servicetimestampsdebugdatetimemsec 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
debugisdnevent command of call setup events for an outgoing call:
Router# debug isdn event
ISDN Event: Call to 415555121202
received HOST_PROCEEDING
Channel ID i = 0x0101
-------------------
Channel ID i = 0x89
received HOST_CONNECT
Channel ID i = 0x0101
ISDN Event: Connected to 415555121202 on B1 at 64 Kb/s
The following shows sample
debugisdnevent output of call setup events for an incoming call. The values used for internal purposes are unpacked information elements. The values that follow the ISDN specification are an interpretation of the unpacked information elements.
Router# debug isdn event
received HOST_INCOMING_CALL
Bearer Capability i = 0x080010
-------------------
Channel ID i = 0x0101
Calling Party Number i = 0x0000, ‘415555121202’
IE out of order or end of ‘private’ IEs --
Bearer Capability i = 0x8890
Channel ID i = 0x89
Calling Party Number i = 0x0083, ‘415555121202’
ISDN Event: Received a call from 415555121202 on B1 at 64 Kb/s
ISDN Event: Accepting the call
received HOST_CONNECT
Channel ID i = 0x0101
ISDN Event: Connected to 415555121202 on B1 at 64 Kb/s
The following is sample output from the
debugisdnevent command of call teardown events for a call that has been disconnected by the host side of the connection:
Router# debug isdn event
received HOST_DISCONNECT
ISDN Event: Call to 415555121202 was hung up
The following is sample output from the
debugisdneventcommand of a call teardown event for an outgoing or incoming call that has been disconnected by the ISDN interface on the router side:
Router# debug isdn event
ISDN Event: Hangup call to call id 0x8008
The table below describes the significant fields shown in the display.
Table 8 debug isdn event Field Descriptions
Field
Description
Bearer Capability
Indicates the requested bearer service to be provided by the network. See Table B-4 in Appendix B, “ISDN Switch Types, Codes, and Values.”
i=
Indicates the information element identifier. The value depends on the field it is associated with. Refer to the ITU-T Q.931 specification for details about the possible values associated with each field for which this identifier is relevant.
Channel ID
Channel Identifier. The values and corresponding channels might be identified in several ways:
Channel ID i=0x0101--Channel B1
Channel ID i=0x0102--Channel B2
ITU-T Q.931 defines the values and channels as exclusive or preferred:
Channel ID i=0x83--Any B channel
Channel ID i=0x89--Channel B1 (exclusive)
Channel ID i=0x8A--Channel B2 (exclusive)
Channel ID i=0x81--B1 (preferred)
Channel ID i=0x82--B2 (preferred)
Calling Party Number
Identifies the called party. This field is only present in outgoing calls. The Calling Party Number field uses the IA5 character set. Note that it may be replaced by the Keypad facility field.
IE out of order or end of ‘private’ IEs
Indicates that an information element identifier is out of order or there are no more private network information element identifiers to interpret.
Received a call from 415555121202 on B1 at 64 Kb/s
Identifies the origin of the call. This field is present only in incoming calls. Note that the information about the incoming call includes the channel and speed. Whether the channel and speed are displayed depends on the network delivering the calling party number.
The following is sample output from the
debugisdnevent command of a call teardown event for a call that has passed call screening and then has been hung up by the ISDN interface on the far end side:
Router# debug isdn event
Jan 3 11:29:52.559: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0x81
Jan 3 11:29:52.563: Cause i = 0x8090 - Normal call clearing
The following is sample output from the
debugisdnevent command of a call teardown event for a call that has not passed call screening and has been rejected by the ISDN interface on the router side:
Router# debug isdn event
Jan 3 11:32:03.263: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0x85
Jan 3 11:32:03.267: Cause i = 0x8095 - Call rejected
The following is sample output from thedebugisdnevent command of a call teardown event for an outgoing call that uses a dialer subaddress:
Router# debug isdn event
Jan 3 11:41:48.483: ISDN BR0: Event: Call to 61885:1212 at 64 Kb/s
Jan 3 11:41:48.495: ISDN BR0: TX -> SETUP pd = 8 callref = 0x04
Jan 3 11:41:48.495: Bearer Capability i = 0x8890
Jan 3 11:41:48.499: Channel ID i = 0x83
Jan 3 11:41:48.503: Called Party Number i = 0x80, '61885'
Jan 3 11:41:48.507: Called Party SubAddr i = 0x80, 'P1212'
Jan 3 11:41:48.571: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x84
Jan 3 11:41:48.575: Channel ID i = 0x89
Jan 3 11:41:48.587: ISDN BR0: Event: incoming ces value = 1
Jan 3 11:41:48.587: ISDN BR0: received HOST_PROCEEDING
Channel ID i = 0x0101
Jan 3 11:41:48.591: -------------------
Channel ID i = 0x89
Jan 3 11:41:48.731: ISDN BR0: RX <- CONNECT pd = 8 callref = 0x84
Jan 3 11:41:48.743: ISDN BR0: Event: incoming ces value = 1
Jan 3 11:41:48.743: ISDN BR0: received HOST_CONNECT
Channel ID i = 0x0101
Jan 3 11:41:48.747: -------------------
%LINK-3-UPDOWN: Interface BRI0:1 changed state to up
Jan 3 11:41:48.771: ISDN BR0: Event: Connected to 61885:1212 on B1 at 64 Kb/s
Jan 3 11:41:48.775: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x04
%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up
%ISDN-6-CONNECT: Interface BRI0:1 is now connected to 61885:1212 goodie
The output is similar to the output of
debugisdnq931. Refer to the
debugisdnq931command for detailed field descriptions.
The following is sample output from thedebugisdnevent command of call setup events for a successful callback for legacy DDR:
Router# debug isdn event
BRI0:Caller id Callback server starting to spanky 81012345678902
: Callback timer expired
BRI0:beginning callback to spanky 81012345678902
BRI0: Attempting to dial 81012345678902
The following is sample output from the
debugisdnevent command for a callback that was unsuccessful because the router had no dialer map for the calling number:
Router# debug isdn event
BRI0:Caller id 81012345678902 callback - no matching map
The table below describes the significant fields shown in the display.
Table 9 debug isdn event Field Descriptions for Caller ID Callback and Legacy DDR
Field
Description
BRI0:Caller id Callback server starting to ...
Caller ID callback has started, plus host name and number called. The callback enable timer starts now.
: Callback timer expired
Callback timer has expired; callback can proceed.
BRI0:beginning callback to ... BRI0: Attempting to dial ...
Actions proceeding after the callback timer expired, plus host name and number called.
The following is sample output from the
debugisdnevent command for a callback that was successful when the dialer profiles DDR feature is configured:
*Mar 1 00:46:51.827: BR0:1:Caller id 81012345678901 matched to profile delorean
*Mar 1 00:46:51.827: Dialer1:Caller id Callback server starting to delorean 81012345678901
*Mar 1 00:46:54.151: : Callback timer expired
*Mar 1 00:46:54.151: Dialer1:beginning callback to delorean 81012345678901
*Mar 1 00:46:54.155: Freeing callback to delorean 81012345678901
*Mar 1 00:46:54.155: BRI0: Dialing cause Callback return call
*Mar 1 00:46:54.155: BRI0: Attempting to dial 81012345678901
*Mar 1 00:46:54.503: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
*Mar 1 00:46:54.523: %DIALER-6-BIND: Interface BRI0:2 bound to profile Dialer1
*Mar 1 00:46:55.139: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, changed state to up
*Mar 1 00:46:58.187: %ISDN-6-CONNECT: Interface BRI0:2 is now connected to 81012345678901 delorean
The following example provides information about accepting X.25 calls on the ISDN D channel (for purpose of example, bold type indicates messages of interest in the following output):
Router# debug isdn event
*Sep 28 12:34:29.747: ISDN BR1/1 EVENTd: isdn_host_packet_mode_events: Host packet call received call id 0xB
The table below describes significant fields of call setup events for a successful callback for the sample output from the
debugisdnevent command when the dialer profiles DDR feature is configured.
Table 10 debug isdn event Field Descriptions for Caller ID Callback and Dialer Profiles
Field
Description
BR0:1:Caller id ... matched to profile ...
Interface, channel number, caller ID that are matched, and the profile to bind to the interface.
: Callback timer expired
Callback timer has expired; callback can proceed.
Dialer1:beginning callback to...
Callback process is beginning to the specified number.
Freeing callback to...
Callback has been started to the specified number, and the number has been removed from the callback list.
BRI0: Dialing cause Callback return call BRI0: Attempting to dial
The reason for the call and the number being dialed.
%LINK-3-UPDOWN: Interface BRI0:2, changed state to up
Interface status: up.
%DIALER-6-BIND: Interface BRI0:2 bound to profile Dialer1
Profile bound to the interface.
%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, changed state to up
Line protocol status: up.
%ISDN-6-CONNECT: Interface BRI0:2 is now connected to ...
Interface is now connected to the specified host and number.
isdn_host_packet_mode_events: Host packet call received call id 0xB
Host is accepting incoming X.25 call using ITU Q.931 SAPI value 0 procedures.
Related Commands
Command
Description
debugisdnq931
Displays call setup and teardown information of ISDN Layer 3 network connections.
debug isdn q921
To display data link layer (Layer 2) access procedures that are taking place at the router on the D channel (Link Access Procedure or LAPD) of its ISDN interface, use the
debugisdnq921command in privileged EXEC mode. To disable debugging output, use the
no form of this command.
(Optional) Specifies the BRI interface and selects the interface number. Valid values are from 0 to 6.
Command Default
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0
This command was introduced.
12.2(15)ZJ
The
detail and
framekeywords were added.
12.3(4)T
This command was integrated into Cisco IOS Release 12.3(4)T.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
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
debugisdnq921 command output is limited to commands and responses exchanged during peer-to-peer communication carried over the D channel. This debug information does not include data transmitted over the B channels that are also part of the router ISDN interface. The peers (data link layer entities and layer management entities on the routers) communicate with each other with an ISDN switch over the D channel.
Note
The ISDN switch provides the network interface defined by Q.921. This debug command does not display data link layer access procedures taking place within the ISDN network (that is, procedures taking place on the network side of the ISDN connection). Refer to Appendix B, “ISDN Switch Types, Codes, and Values ,” in the
ISDN Switch Types, Codes, and Values document on Cisco.com for a list of the supported ISDN switch types.
A router can be the calling or called party of the ISDN Q.921 data link layer access procedures. If the router is the calling party, the command displays information about an outgoing call. If the router is the called party, the command displays information about an incoming call and the keepalives.
The
debugisdnq921 command can be used with thedebugisdnevent,
debugisdnq931,
debugisdnq921frame, and
debugisdnq921detailcommands at the same time. The displays are intermingled.
Use the
servicetimestampsdebugdatetimemsec 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
debugisdnq921,
debugisdnq921frame, and
debugisdnq921detail. In the debugs below, “Q921” followed by a colon (:) indicates that
debugisdnq921 has been entered. “Q921” followed by the letter “f” indicates that
debugisdnq921frame has been entered. “Q921” followed by the letter “d” indicates that
debugisdnq921detail 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.
The following output interprets the octet information. String “PBXb” indicates that the side receiving (RX) this frame is acting as a PBXb (as opposed to PBXa, which is the other possibility). This example also gives information about the type of frame received (SABMR), the associated DLC (1), the frame type code received from the control field (cntl=SABMR), and the sequence number (indicated by nbit, which is 0 in this case).
The following output shows information received from the driver (source_id of x200) showing an L2 frame (event x141). This results from the SABMR frame that was received from the peer PBX (v_bit and chan do not have any significance in this case).
00:12:10:ISDN Se1:15 Q921d:process_rxdata:Frame sent to L2
00:12:10:ISDN Q921d:isdn_from_driver_process:event_count 3
00:12:10:ISDN Se1:15 Q921d:dpnss_l2_main:source_id x200 event x141 v_bit x0 chan x0
The following output shows that DPNSS L2 for DLC 1 (chan 1) has received an SABMR frame (event x0) in the IDLE state (s_dpnss_idle):
The following output shows that for DLC 1, a DL_EST_IND (event x201) needs to be sent to L3 (DUA in this case because of the backhauling) indicating that this DLC is now up (in RESET COMPLETE state):
The following output shows that string “PBXb” is the side transmitting (TX) and that this frame is acting as PBX B. This example also gives information about the associated DLC (1), the frame type code transmitted from the control field (cntl=UA), and the sequence number (indicated by nbit, which is 0 in this case).
00:12:10:ISDN Se1:15 Q921:PBXb TX -> UA dlci=1 cntl=UA nbit=0
The following is complete debugging output from a DPNSS call:
Jan 8 17:24:43.499:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:24:43.499:ISDN Se2/0:15 Q921f:PBXa TX -> 0x440303
Jan 8 17:24:43.499:ISDN Se2/0:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=0
Jan 8 17:24:43.499:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:24:43.503:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:24:43.503:ISDN Se2/0:15 Q921f:PBXa RX <-
0x44030300102A34232A35302A33333330
Jan 8 17:24:43.503: 30303031233434343030303031
Jan 8 17:24:43.503:ISDN Se2/0:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=0
i=0x00102A34232A35302A3333333030303031233434343030303031
Jan 8 17:24:43.503:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:24:43.503:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:24:43.507:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:24:43.507:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x2
chan 1
Jan 8 17:24:43.507:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x3
v_bit 1 chan 1 out_pkt x63F183D4
Jan 8 17:24:43.507:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:24:43.507:ISDN Se2/0:15 Q921f:PBXa TX -> 0x440303
Jan 8 17:24:43.507:ISDN Se2/0:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=0
Jan 8 17:24:43.507:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:24:43.515:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:24:43.515:ISDN Se2/0:15 Q921f:PBXa RX <-
0x44030300102A34232A35302A33333330
Jan 8 17:24:43.515: 30303031233434343030303031
Jan 8 17:24:43.515:ISDN Se2/0:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=0
i=0x00102A34232A35302A3333333030303031233434343030303031
Jan 8 17:24:43.515:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:24:43.515:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:24:43.515:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:24:43.515:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x2
chan 1
Jan 8 17:24:43.515:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x3
v_bit 1 chan 1 out_pkt x63F183D4
Jan 8 17:24:43.515:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:24:43.519:ISDN Se2/0:15 Q921f:PBXa TX -> 0x440303
Jan 8 17:24:43.519:ISDN Se2/0:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=0
Jan 8 17:24:43.519:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:24:43.599:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x4 event x240
v_bit x0 chan x2
Jan 8 17:24:43.599:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event
x240 chan 1
Jan 8 17:24:43.599:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x2
v_bit 1 chan 1 out_pkt x63EE5780
Jan 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_EVENT
Jan 8 17:24:43.599:ISDN Se2/1:15 Q921f:PBXa TX ->
0x46030300102A31232A35302A33333330
Jan 8 17:24:43.599: 30303031233434343030303031
Jan 8 17:24:43.599:ISDN Se2/1:15 Q921:PBXa TX -> UI(C) dlci=1 cntl=UI nbit=0
i=0x00102A31232A35302A3333333030303031233434343030303031
Jan 8 17:24:43.599:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:24:43.623:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:24:43.623:ISDN Se2/1:15 Q921f:PBXa RX <- 0x460303
Jan 8 17:24:43.623:ISDN Se2/1:15 Q921:PBXa RX <- UI(R) dlci=1 cntl=UI nbit=0
Jan 8 17:24:43.623:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:24:43.623:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:24:43.627:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:24:43.627:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x3
chan 1
Jan 8 17:24:43.719:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:24:43.719:ISDN Se2/1:15 Q921f:PBXa RX <-
0x440313092A34232A35302A3434343030
Jan 8 17:24:43.719: 303031232A31382A33312A33312A3331
Jan 8 17:24:43.719: 23
Jan 8 17:24:43.719:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1
i=0x092A34232A35302A3434343030303031232A31382A33312A33312A333123
Jan 8 17:24:43.719:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:24:43.719:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:24:43.719:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:24:43.719:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2
chan 1
Jan 8 17:24:43.719:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x300 event x241
v_bit 1 chan 1 out_pkt x63EE5780
Jan 8 17:24:43.719:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3
v_bit 1 chan 1 out_pkt x63EE57CC
Jan 8 17:24:43.723:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:24:43.723:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313
Jan 8 17:24:43.723:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1
Jan 8 17:24:43.723:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:24:43.727:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:24:43.727:ISDN Se2/1:15 Q921f:PBXa RX <-
0x440313092A34232A35302A3434343030
Jan 8 17:24:43.727: 303031232A31382A33312A33312A3331
Jan 8 17:24:43.727: 23
Jan 8 17:24:43.727:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1
i=0x092A34232A35302A3434343030303031232A31382A33312A33312A333123
Jan 8 17:24:43.727:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:24:43.727:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:24:43.731:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:24:43.731:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2
chan 1
Jan 8 17:24:43.731:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3
v_bit 1 chan 1 out_pkt x63EE57CC
Jan 8 17:24:43.731:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:24:43.731:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313
Jan 8 17:24:43.731:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1
Jan 8 17:24:43.731:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:24:43.739:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:24:43.739:ISDN Se2/1:15 Q921f:PBXa RX <-
0x440313092A34232A35302A3434343030
Jan 8 17:24:43.739: 303031232A31382A33312A33312A3331
Jan 8 17:24:43.739: 23
Jan 8 17:24:43.739:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1
i=0x092A34232A35302A3434343030303031232A31382A33312A33312A333123
Jan 8 17:24:43.739:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:24:43.739:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:24:43.739:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:24:43.739:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2
chan 1
Jan 8 17:24:43.739:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3
v_bit 1 chan 1 out_pkt x63EE57CC
Jan 8 17:24:43.739:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:24:43.743:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313
Jan 8 17:24:43.743:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1
Jan 8 17:24:43.743:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:24:43.787:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x4 event x240
v_bit x0 chan x2
Jan 8 17:24:43.787:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event
x240 chan 1
Jan 8 17:24:43.787:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x2
v_bit 1 chan 1 out_pkt x636B1B64
Jan 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_EVENT
Jan 8 17:24:43.791:ISDN Se2/0:15 Q921f:PBXa TX ->
0x460313092A31232A35302A3434343030
Jan 8 17:24:43.791: 30303123
Jan 8 17:24:43.791:ISDN Se2/0:15 Q921:PBXa TX -> UI(C) dlci=1 cntl=UI nbit=1
i=0x092A31232A35302A343434303030303123
Jan 8 17:24:43.791:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:24:43.811:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:24:43.811:ISDN Se2/0:15 Q921f:PBXa RX <- 0x460313
Jan 8 17:24:43.811:ISDN Se2/0:15 Q921:PBXa RX <- UI(R) dlci=1 cntl=UI nbit=1
Jan 8 17:24:43.811:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:24:43.811:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:24:43.811:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:24:43.811:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x3
chan 1
Jan 8 17:24:52.107:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:24:52.107:ISDN Se2/1:15 Q921f:PBXa RX <-
0x440303052A34232A35302A3434343030
Jan 8 17:24:52.107: 303031232A31382A33312A33312A3331
Jan 8 17:24:52.107: 23
Jan 8 17:24:52.107:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=0
i=0x052A34232A35302A3434343030303031232A31382A33312A33312A333123
Jan 8 17:24:52.107:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:24:52.107:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:24:52.111:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:24:52.111:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2
chan 1
Jan 8 17:24:52.111:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x300 event x241
v_bit 1 chan 1 out_pkt x63F19CC8
Jan 8 17:24:52.111:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3
v_bit 1 chan 1 out_pkt x63F19D14
Jan 8 17:24:52.111:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:24:52.111:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440303
Jan 8 17:24:52.111:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=0
Jan 8 17:24:52.111:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:24:52.119:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:24:52.119:ISDN Se2/1:15 Q921f:PBXa RX <-
0x440303052A34232A35302A3434343030
Jan 8 17:24:52.119: 303031232A31382A33312A33312A3331
Jan 8 17:24:52.119: 23
Jan 8 17:24:52.119:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=0
i=0x052A34232A35302A3434343030303031232A31382A33312A33312A333123
Jan 8 17:24:52.119:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:24:52.119:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:24:52.119:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
x141 v_bit x0 chan x0
Jan 8 17:24:52.119:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2
chan 1
Jan 8 17:24:52.119:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3
v_bit 1 chan 1 out_pkt x63F19D14
Jan 8 17:24:52.119:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:24:52.123:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440303
Jan 8 17:24:52.123:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=0
Jan 8 17:24:52.123:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:24:52.127:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:24:52.127:ISDN Se2/1:15 Q921f:PBXa RX <-
0x440303052A34232A35302A3434343030
Jan 8 17:24:52.127: 303031232A31382A33312A33312A3331
Jan 8 17:24:52.127: 23
Jan 8 17:24:52.127:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=0
i=0x052A34232A35302A3434343030303031232A31382A33312A33312A333123
Jan 8 17:24:52.127:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:24:52.127:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:24:52.131:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:24:52.131:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2
chan 1
Jan 8 17:24:52.131:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3
v_bit 1 chan 1 out_pkt x63F19D14
Jan 8 17:24:52.131:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:24:52.131:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440303
Jan 8 17:24:52.131:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=0
Jan 8 17:24:52.131:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:24:52.159:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x4 event x240
v_bit x0 chan x2
Jan 8 17:24:52.159:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event
x240 chan 1
Jan 8 17:24:52.159:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x2
v_bit 1 chan 1 out_pkt x63F19CC8
Jan 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_EVENT
Jan 8 17:24:52.159:ISDN Se2/0:15 Q921f:PBXa TX ->
0x460303052A35302A3434343030303031
Jan 8 17:24:52.159: 23
Jan 8 17:24:52.159:ISDN Se2/0:15 Q921:PBXa TX -> UI(C) dlci=1 cntl=UI nbit=0
i=0x052A35302A343434303030303123
Jan 8 17:24:52.159:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:24:52.179:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:24:52.179:ISDN Se2/0:15 Q921f:PBXa RX <- 0x460303
Jan 8 17:24:52.179:ISDN Se2/0:15 Q921:PBXa RX <- UI(R) dlci=1 cntl=UI nbit=0
Jan 8 17:24:52.179:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:24:52.183:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:24:52.183:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:24:52.183:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x3
chan 1
Jan 8 17:25:31.811:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:25:31.811:ISDN Se2/0:15 Q921f:PBXa RX <- 0x4403130830
Jan 8 17:25:31.811:ISDN Se2/0:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1
i=0x0830
Jan 8 17:25:31.811:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:25:31.811:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:25:31.811:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:25:31.811:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x2
chan 1
Jan 8 17:25:31.811:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x300 event x241
v_bit 1 chan 1 out_pkt x63F1806C
Jan 8 17:25:31.811:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x3
v_bit 1 chan 1 out_pkt x636710B8
Jan 8 17:25:31.815:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:25:31.815:ISDN Se2/0:15 Q921f:PBXa TX -> 0x440313
Jan 8 17:25:31.815:ISDN Se2/0:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1
Jan 8 17:25:31.815:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:25:31.819:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:25:31.819:ISDN Se2/0:15 Q921f:PBXa RX <- 0x4403130830
Jan 8 17:25:31.819:ISDN Se2/0:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1
i=0x0830
Jan 8 17:25:31.819:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:25:31.819:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:25:31.823:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:25:31.823:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x2
chan 1
Jan 8 17:25:31.823:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x3
v_bit 1 chan 1 out_pkt x63F19CC8
Jan 8 17:25:31.823:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:25:31.823:ISDN Se2/0:15 Q921f:PBXa TX -> 0x440313
Jan 8 17:25:31.823:ISDN Se2/0:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1
Jan 8 17:25:31.823:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:25:31.831:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:25:31.831:ISDN Se2/0:15 Q921f:PBXa RX <- 0x4403130830
Jan 8 17:25:31.831:ISDN Se2/0:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1
i=0x0830
Jan 8 17:25:31.831:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:25:31.831:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:25:31.831:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:25:31.831:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x2
chan 1
Jan 8 17:25:31.831:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x3
v_bit 1 chan 1 out_pkt x636710B8
Jan 8 17:25:31.835:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:25:31.835:ISDN Se2/0:15 Q921f:PBXa TX -> 0x440313
Jan 8 17:25:31.835:ISDN Se2/0:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1
Jan 8 17:25:31.835:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:25:31.851:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x4 event x240
v_bit x0 chan x2
Jan 8 17:25:31.851:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event
x240 chan 1
Jan 8 17:25:31.851:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x2
v_bit 1 chan 1 out_pkt x63F1806C
Jan 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_EVENT
Jan 8 17:25:31.855:ISDN Se2/1:15 Q921f:PBXa TX -> 0x4603130830
Jan 8 17:25:31.855:ISDN Se2/1:15 Q921:PBXa TX -> UI(C) dlci=1 cntl=UI nbit=1
i=0x0830
Jan 8 17:25:31.855:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:25:31.875:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:25:31.875:ISDN Se2/1:15 Q921f:PBXa RX <- 0x460313
Jan 8 17:25:31.875:ISDN Se2/1:15 Q921:PBXa RX <- UI(R) dlci=1 cntl=UI nbit=1
Jan 8 17:25:31.875:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:25:31.875:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:25:31.875:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:25:31.875:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x3
chan 1
Jan 8 17:25:31.879:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x4 event x240
v_bit x0 chan x2
Jan 8 17:25:31.879:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event
x240 chan 1
Jan 8 17:25:31.879:ISDN Se2/0:15 Q921d:dpnss_l2_mail:dest x200 event x2
v_bit 1 chan 1 out_pkt x63EFC5AC
Jan 8 17:25:31.879:ISDN Se2/0:15 LIFd:LIF_StartTimer:timer (0x63A4AFBC),
ticks (500), event (0x1201)
Jan 8 17:25:31.879:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:25:31.879:ISDN Se2/0:15 Q921f:PBXa TX -> 0x4603130830
Jan 8 17:25:31.879:ISDN Se2/0:15 Q921:PBXa TX -> UI(C) dlci=1 cntl=UI nbit=1
i=0x0830
Jan 8 17:25:31.883:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:25:31.899:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:25:31.899:ISDN Se2/0:15 Q921f:PBXa RX <- 0x460313
Jan 8 17:25:31.899:ISDN Se2/0:15 Q921:PBXa RX <- UI(R) dlci=1 cntl=UI nbit=1
Jan 8 17:25:31.899:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:25:31.899:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:25:31.903:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:25:31.903:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x3
chan 1
Jan 8 17:25:32.063:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:25:32.063:ISDN Se2/1:15 Q921f:PBXa RX <- 0x4403130830
Jan 8 17:25:32.063:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1
i=0x0830
Jan 8 17:25:32.063:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:25:32.063:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:25:32.067:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:25:32.067:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2
chan 1
Jan 8 17:25:32.067:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x300 event x241
v_bit 1 chan 1 out_pkt x63EFC5AC
Jan 8 17:25:32.067:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3
v_bit 1 chan 1 out_pkt x6367175C
Jan 8 17:25:32.067:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:25:32.067:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313
Jan 8 17:25:32.067:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1
Jan 8 17:25:32.067:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:25:32.075:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:25:32.075:ISDN Se2/1:15 Q921f:PBXa RX <- 0x4403130830
Jan 8 17:25:32.075:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1
i=0x0830
Jan 8 17:25:32.075:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:25:32.075:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:25:32.075:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:25:32.075:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2
chan 1
Jan 8 17:25:32.075:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3
v_bit 1 chan 1 out_pkt x6367175C
Jan 8 17:25:32.075:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:25:32.075:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313
Jan 8 17:25:32.079:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1
Jan 8 17:25:32.079:ISDN Q921d:isdn_l2d_srq_process:event_count 1
Jan 8 17:25:32.083:ISDN Q921d:isdn_from_driver_process:QUEUE_EVENT
Jan 8 17:25:32.083:ISDN Se2/1:15 Q921f:PBXa RX <- 0x4403130830
Jan 8 17:25:32.083:ISDN Se2/1:15 Q921:PBXa RX <- UI(C) dlci=1 cntl=UI nbit=1
i=0x0830
Jan 8 17:25:32.083:ISDN Se2/1:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:25:32.083:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:25:32.087:ISDN Se2/1:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:25:32.087:ISDN Se2/1:15 Q921d:s_dpnss_information_transfer:event x2
chan 1
Jan 8 17:25:32.087:ISDN Se2/1:15 Q921d:dpnss_l2_mail:dest x200 event x3
v_bit 1 chan 1 out_pkt x6367175C
Jan 8 17:25:32.087:ISDN Q921d:isdn_l2d_srq_process:QUEUE_EVENT
Jan 8 17:25:32.087:ISDN Se2/1:15 Q921f:PBXa TX -> 0x440313
Jan 8 17:25:32.087:ISDN Se2/1:15 Q921:PBXa TX -> UI(R) dlci=1 cntl=UI nbit=1
Jan 8 17:25:32.087:ISDN Q921d:isdn_l2d_srq_process:event_count 1
The 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_EVENT
Jan 8 17:24:43.495:ISDN Se2/0:15 Q921f:PBXa RX <- 0x44030300102A34232A35302A33333330
Jan 8 17:24:43.495: 30303031233434343030303031
All of the octets following “i=” constitute DPNSS L3 information received from the peer:
In the INFORMATION TRANSFER state, DLC 1 received a UI(C) frame (event x2) from the peer carrying DPNSS L3 information:
Jan 8 17:24:43.495:ISDN Se2/0:15 Q921d:process_rxdata:Frame sent to L2
Jan 8 17:24:43.495:ISDN Q921d:isdn_from_driver_process:event_count 1
Jan 8 17:24:43.495:ISDN Se2/0:15 Q921d:dpnss_l2_main:source_id x200 event
x141 v_bit x0 chan x0
Jan 8 17:24:43.495:ISDN Se2/0:15 Q921d:s_dpnss_information_transfer:event x2 chan 1
For DLC 1, event information is sent to L3 (IUA BACKHAUL, indicated by dest x300). In this case, DL_DATA_IND (event x241) indicates that some L3 information has been received from the peer.
Information 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)].
The following is sample output from the
debugisdnq921 command for an outgoing call:
Router# debug isdn q921
Jan 3 14:52:24.475: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 5 nr = 2
i = 0x08010705040288901801837006803631383835
Jan 3 14:52:24.503: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 6
Jan 3 14:52:24.527: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 2 nr = 6
i = 0x08018702180189
Jan 3 14:52:24.535: ISDN BR0: TX -> RRr sapi = 0 tei = 64 nr = 3
Jan 3 14:52:24.643: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 3 nr = 6
i = 0x08018707
Jan 3 14:52:24.655: ISDN BR0: TX -> RRr sapi = 0 tei = 64 nr = 4
%LINK-3-UPDOWN: Interface BRI0:1, changed state to up
Jan 3 14:52:24.683: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 6 nr = 4
i = 0x0801070F
Jan 3 14:52:24.699: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 7
%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up
%ISDN-6-CONNECT: Interface BRI0:1 is now connected to 61885 goodie
Jan 3 14:52:34.415: ISDN BR0: RX <- RRp sapi = 0 tei = 64 nr = 7
Jan 3 14:52:34.419: ISDN BR0: TX -> RRf sapi = 0 tei = 64 nr = 4
In the following lines, the seventh and eighth most significant hexadecimal numbers indicate the type of message. 0x05 indicates a Call Setup message, 0x02 indicates a Call Proceeding message, 0x07 indicates a Call Connect message, and 0x0F indicates a Connect Ack message.
Jan 3 14:52:24.475: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 5 nr = 2
i = 0x08010705040288901801837006803631383835
Jan 3 14:52:24.527: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 2 nr = 6
i = 0x08018702180189
Jan 3 14:52:24.643: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 3 nr = 6
i = 0x08018707
Jan 3 14:52:24.683: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 6 nr = 4
i = 0x0801070F
The following is sample output from the
debugisdnq921 command for a startup message on a DMS-100 switch:
Router# debug isdn q921
Jan 3 14:47:28.455: ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127 0
Jan 3 14:47:30.171: ISDN BR0: TX -> IDREQ ri = 31815 ai = 127
Jan 3 14:47:30.219: ISDN BR0: RX <- IDASSN ri = 31815 ai = 64
Jan 3 14:47:30.223: ISDN BR0: TX -> SABMEp sapi = 0 tei = 64
Jan 3 14:47:30.227: ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127
Jan 3 14:47:30.235: ISDN BR0: TX -> IDCKRP ri = 16568 ai = 64
Jan 3 14:47:30.239: ISDN BR0: RX <- UAf sapi = 0 tei = 64
Jan 3 14:47:30.247: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 0 nr = 0
i = 0x08007B3A03313233
Jan 3 14:47:30.267: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 1
Jan 3 14:47:34.243: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 1 nr = 0
i = 0x08007B3A03313233
Jan 3 14:47:34.267: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 2
Jan 3 14:47:43.815: ISDN BR0: RX <- RRp sapi = 0 tei = 64 nr = 2
Jan 3 14:47:43.819: ISDN BR0: TX -> RRf sapi = 0 tei = 64 nr = 0
Jan 3 14:47:53.819: ISDN BR0: TX -> RRp sapi = 0 tei = 64 nr = 0
The first seven lines of this example indicate a Layer 2 link establishment.
The following lines indicate the message exchanges between the data link layer entity on the local router (user side) and the assignment source point (ASP) on the network side during the TEI assignment procedure. This assumes that the link is down and no TEI currently exists.
Jan 3 14:47:30.171: ISDN BR0: TX -> IDREQ ri = 31815 ai = 127
Jan 3 14:47:30.219: ISDN BR0: RX <- IDASSN ri = 31815 ai = 64
At 14:47:30.171, the local router data link layer entity sent an Identity Request message to the network data link layer entity to request a TEI value that can be used in subsequent communication between the peer data link layer entities. The request includes a randomly generated reference number (31815) to differentiate among user devices that request automatic TEI assignment and an action indicator of 127 to indicate that the ASP can assign any TEI value available. The ISDN user interface on the router uses automatic TEI assignment.
At 14:47:30.219, the network data link entity responds to the Identity Request message with an Identity Assigned message. The response includes the reference number (31815) previously sent in the request and TEI value (64) assigned by the ASP.
The following lines indicate the message exchanges between the layer management entity on the network and the layer management entity on the local router (user side) during the TEI check procedure:
Jan 3 14:47:30.227: ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127
Jan 3 14:47:30.235: ISDN BR0: TX -> IDCKRP ri = 16568 ai = 64
At 14:47:30.227, the layer management entity on the network sends the Identity Check Request message to the layer management entity on the local router to check whether a TEI is in use. The message includes a reference number that is always 0 and the TEI value to check. In this case, an ai value of 127 indicates that all TEI values should be checked. At 14:47:30.227, the layer management entity on the local router responds with an Identity Check Response message indicating that TEI value 64 is currently in use.
The following lines indicate the messages exchanged between the data link layer entity on the local router (user side) and the data link layer on the network side to place the network side into modulo 128 multiple frame acknowledged operation. Note that the data link layer entity on the network side also can initiate the exchange.
At 14:47:30.223, the data link layer entity on the local router sends the SABME command with a SAPI of 0 (call control procedure) for TEI 64. At 14:47:30.239, the first opportunity, the data link layer entity on the network responds with a UA response. This response indicates acceptance of the command. The data link layer entity sending the SABME command may need to send it more than once before receiving a UA response.
The following lines indicate the status of the data link layer entities. Both are ready to receive I frames.
Jan 3 14:47:43.815: ISDN BR0: RX <- RRp sapi = 0 tei = 64 nr = 2
Jan 3 14:47:43.819: ISDN BR0: TX -> RRf sapi = 0 tei = 64 nr = 0
These I-frames are typically exchanged every 10 seconds (T203 timer).
The following is sample output from the
debugisdnq921 command for an incoming call. It is an incoming SETUP message that assumes that the Layer 2 link is already established to the other side.
Router# debug isdn q921
Jan 3 14:49:22.507: ISDN BR0: TX -> RRp sapi = 0 tei = 64 nr = 0
Jan 3 14:49:22.523: ISDN BR0: RX <- RRf sapi = 0 tei = 64 nr = 2
Jan 3 14:49:32.527: ISDN BR0: TX -> RRp sapi = 0 tei = 64 nr = 0
Jan 3 14:49:32.543: ISDN BR0: RX <- RRf sapi = 0 tei = 64 nr = 2
Jan 3 14:49:42.067: ISDN BR0: RX <- RRp sapi = 0 tei = 64 nr = 2
Jan 3 14:49:42.071: ISDN BR0: TX -> RRf sapi = 0 tei = 64 nr = 0
Jan 3 14:49:47.307: ISDN BR0: RX <- UI sapi = 0 tei = 127
i = 0x08011F05040288901801897006C13631383836
%LINK-3-UPDOWN: Interface BRI0:1, changed state to up
Jan 3 14:49:47.347: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 2 nr = 0
i = 0x08019F07180189
Jan 3 14:49:47.367: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 3
Jan 3 14:49:47.383: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 0 nr = 3
i = 0x08011F0F180189
Jan 3 14:49:47.391: ISDN BR0: TX -> RRr sapi = 0 tei = 64 nr = 1
%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up
The table below describes the significant fields shown in the display.
Table 11 debug isdn q921 Field Descriptions
Field
Description
Jan 3 14:49:47.391
Indicates the date and time at which the frame was sent from or received by the data link layer entity on the router. The time is maintained by an internal clock.
TX
Indicates that this frame is being sent from the ISDN interface on the local router (user side).
RX
Indicates that this frame is being received by the ISDN interface on the local router from the peer (network side).
IDREQ
Indicates the Identity Request message type sent from the local router to the network (ASP) during the automatic TEI assignment procedure. This message is sent in a UI command frame. The SAPI value for this message type is always 63 (indicating that it is a Layer 2 management procedure) but it is not displayed. The TEI value for this message type is 127 (indicating that it is a broadcast operation).
ri = 31815
Indicates the Reference number used to differentiate between user devices requesting TEI assignment. This value is a randomly generated number from 0 to 65535. The same ri value sent in the IDREQ message should be returned in the corresponding IDASSN message. Note that a Reference number of 0 indicates that the message is sent from the network side management layer entity and a reference number has not been generated.
ai = 127
Indicates the Action indicator used to request that the ASP assign any TEI value. It is always 127 for the broadcast TEI. Note that in some message types, such as IDREM, a specific TEI value is indicated.
IDREM
Indicates the Identity Remove message type sent from the ASP to the user side layer management entity during the TEI removal procedure. This message is sent in a UI command frame. The message includes a reference number that is always 0, because it is not responding to a request from the local router. The ASP sends the Identity Remove message twice to avoid message loss.
IDASSN
Indicates the Identity Assigned message type sent from the ISDN service provider on the network to the local router during the automatic TEI assignment procedure. This message is sent in a UI command frame. The SAPI value for this message type is always 63 (indicating that it is a Layer 2 management procedure). The TEI value for this message type is 127 (indicating it is a broadcast operation).
ai = 64
Indicates the TEI value automatically assigned by the ASP. This TEI value is used by data link layer entities on the local router in subsequent communication with the network. The valid values are in the range from 64 to 126.
SABME
Indicates the set asynchronous balanced mode extended command. This command places the recipient into modulo 128 multiple frame acknowledged operation. This command also indicates that all exception conditions have been cleared. The SABME command is sent once a second for N200 times (typically three times) until its acceptance is confirmed with a UA response. For a list and brief description of other commands and responses that can be exchanged between the data link layer entities on the local router and the network, see ITU-T Recommendation Q.921.
sapi = 0
Identifies the service access point at which the data link layer entity provides services to Layer 3 or to the management layer. A SAPI with the value 0 indicates it is a call control procedure. Note that the Layer 2 management procedures such as TEI assignment, TEI removal, and TEI checking, which are tracked with the
debugisdnq921command, do not display the corresponding SAPI value; it is implicit. If the SAPI value were displayed, it would be 63.
tei = 64
Indicates the TEI value automatically assigned by the ASP. This TEI value will be used by data link layer entities on the local router in subsequent communication with the network. The valid values are in the range from 64 to 126.
IDCKRQ
Indicates the Identity Check Request message type sent from the ISDN service provider on the network to the local router during the TEI check procedure. This message is sent in a UI command frame. The ri field is always 0. The ai field for this message contains either a specific TEI value for the local router to check or 127, which indicates that the local router should check all TEI values. For a list and brief description of other message types that can be exchanged between the local router and the ISDN service provider on the network, see Appendix B, “ISDN Switch Types, Codes, and Values.”
IDCKRP
Indicates the Identity Check Response message type sent from the local router to the ISDN service provider on the network during the TEI check procedure. This message is sent in a UI command frame in response to the IDCKRQ message. The ri field is a randomly generated number from 0 to 65535. The ai field for this message contains the specific TEI value that has been checked.
UAf
Confirms that the network side has accepted the SABME command previously sent by the local router. The final bit is set to 1.
INFOc
Indicates that this is an Information command. It is used to transfer sequentially numbered frames containing information fields that are provided by Layer 3. The information is transferred across a data-link connection.
INFORMATION pd = 8 callref = (null)
Indicates the information fields provided by Layer 3. The information is sent one frame at a time. If multiple frames need to be sent, several Information commands are sent. The pd value is the protocol discriminator. The value 8 indicates it is call control information. The call reference number is always null for SPID information.
SPID information i = 0x343135393033383336363031
Indicates the SPID. The local router sends this information to the ISDN switch to indicate the services to which it subscribes. SPIDs are assigned by the service provider and are usually 10-digit telephone numbers followed by optional numbers. Currently, only the DMS-100 switch supports SPIDs, one for each B channel. If SPID information is sent to a switch type other than DMS-100, an error may be displayed in the debug information.
ns = 0
Indicates the send sequence number of sent I frames.
nr = 0
Indicates the expected send sequence number of the next received I frame. At time of transmission, this value should be equal to the value of ns. The value of nr is used to determine whether frames need to be re-sent for recovery.
RRr
Indicates the Receive Ready response for unacknowledged information transfer. The RRr is a response to an INFOc.
RRp
Indicates the Receive Ready command with the poll bit set. The data link layer entity on the user side uses the poll bit in the frame to solicit a response from the peer on the network side.
RRf
Indicates the Receive Ready response with the final bit set. The data link layer entity on the network side uses the final bit in the frame to indicate a response to the poll.
sapi
Indicates the service access point identifier. The SAPI is the point at which data link services are provided to a network layer or management entity. Currently, this field can have the value 0 (for call control procedure) or 63 (for Layer 2 management procedures).
tei
Indicates the terminal endpoint identifier (TEI) that has been assigned automatically by the assignment source point (ASP) (also called the layer management entity on the network side). The valid range is from 64 to 126. The value 127 indicates a broadcast.
Related Commands
Command
Description
debugisdnevent
Displays ISDN events occurring on the user side (on the router) of the ISDN interface.
debugisdnq931
Displays information about call setup and teardown of ISDN network connections (Layer 3) between the local router (user side) and the network.
servicetimestampsdebugdatetimemsec
Includes the time with each debug message.
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 thedebugisdnq931 command in privileged EXEC mode. To disable debugging output, use the
no form of this command.
(Optional) Displays ISDN Q.931 Abstract Syntax Notation number one (ASN.1) details.
detail
(Optional) Displays ISDN Q.931 packet details.
interface
(Optional) Specifies an interface for debugging.
brinumber
(Optional) Specifies the BRI interface and selects the interface number. Valid values are from 0 to 6.
Command Modes
Privileged EXEC
Command History
Release
Modification
10.0
The
debugisdn command was introduced.
12.3(11)T
This command was enhanced to display the contents of the Facility Information Element (IE) in textual format.
12.3(14)T
The
asn1,
detail,
interface, and
brinumber keywords and argument were added.
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.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
Usage Guidelines
The ISDN network layer interface provided by the router conforms to the user interface specification defined by ITU-T recommendation Q.931 and to other specifications (for example, switch type VN4). The router only tracks activities that occur on the user side, not on the network side, of the network connection. The
debugisdnq931 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 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, with parameter values as they are applicable and relevant to the operation. In addition, the ASN.1 encoded Notification structure of the Notification-Indicator IE is also decoded.
You can use the
debugisdnq931 command with the
debugisdnevent and the
debugisdnq921 commands at the same time. The displays will be intermingled. Use the
servicetimestampsdebugdatetimemsecglobal configuration command to include the time with each message.
Examples
The following is sample output from the
debugisdnq931 command of a call setup procedure for an outgoing call:
Router# debug isdn q931
TX -> SETUP pd = 8 callref = 0x04
Bearer Capability i = 0x8890
Channel ID i = 0x83
Called Party Number i = 0x80, ‘415555121202’
RX <- CALL_PROC pd = 8 callref = 0x84
Channel ID i = 0x89
RX <- CONNECT pd = 8 callref = 0x84
TX -> CONNECT_ACK pd = 8 callref = 0x04....
Success rate is 0 percent (0/5)
The following is sample output from the
debugisdnq931 command of a call setup procedure for an incoming call:
Router# debug isdn q931
RX <- SETUP pd = 8 callref = 0x06
Bearer Capability i = 0x8890
Channel ID i = 0x89
Calling Party Number i = 0x0083, ‘81012345678902’
TX -> CONNECT pd = 8 callref = 0x86
RX <- CONNECT_ACK pd = 8 callref = 0x06
The following is sample output from the
debugisdnq931 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.
The following example shows how to turn on the
debugisdnq931asn1 capability and how to use the
showdebug command to display the results of the debug:
Router# debug isdn q931 asn1
debug isdn asn1 is ON.
Router# show debug
The following ISDN debugs are enabled on all DSLs:
debug isdn error is ON.
debug isdn event is ON.
debug isdn q931 is ON.
debug isdn asn1 is ON.
DEBUGS with ASN1 enabled:
ice call = 0x1
00:08:49: Sub Msg = CDAPI_MSG_SUBTYPE_TBCT_REQ
00:08:49: Call Type = VOICE
00:08:49: B Channel = 0
00:08:49: Cause = 0
00:08:49: ISDN ASN1: isdnAsn1Component
00:08:49: ISDN ASN1: isdnAsn1Invoke
00:08:49: ISDN ASN1: isdnAsn1InvTBCT
00:08:49: ISDN ASN1: op Invoke TBCT
00:08:49: ISDN Se0:23 Q931: TX -> FACILITY pd = 8 callref = 0x8001
Facility i = 0x91A11102010506072A8648CE1500083003020101
*Jun 15 06:27:51.547: %ISDN-6-CONNECT: Interface Serial0:0 is now connected to 1 11111
00:08:51: ISDN Se0:23 Q931: RX <- FACILITY pd = 8 callref = 0x01
Facility i = 0x91A203020105A11302010180010506072A8648CE15000A81020164
00:08:51: ISDN ASN1: isdnAsn1Component
00:08:51: ISDN ASN1: isdnAsn1Res
00:08:51: ISDN ASN1: isdnAsn1ResTbct
The table below describes the significant fields shown in the displays, in alphabetical order.
Table 12 debug isdn q931 Field Descriptions
Field
Description
Bearer Capability
Indicates the requested bearer service to be provided by the network.
CALL_PROC
Indicates the CALL PROCEEDING message; the requested call setup has begun, and no more call setup information will be accepted.
Called Party Number
Identifies the called party. This field is present only in outgoing SETUP messages. Note that this field can be replaced by the Keypad facility field. This field uses the IA5 character set.
Calling Party Number
Identifies the origin of the call. This field is present only in incoming SETUP messages. This field uses the IA5 character set.
callref
Indicates the call reference number in hexadecimal notation. The value of this field indicates the number of calls made from either the router (outgoing calls) or the network (incoming calls).
Note that the originator of the SETUP message sets the high-order bit of the call reference number to 0.
The destination of the connection sets the high-order bit to 1 in subsequent call control messages, such as the CONNECT message.
For example, callref = 0x04 in the request becomes callref = 0x84 in the response.
Cause
Indicates the cause of the disconnect.
Channel ID
Indicates the channel identifier. The value 83 indicates any channel, 89 indicates the B1 channel, and 8A indicates the B2 channel. For more information about the channel identifier, see ITU-T Recommendation Q.931.
Codeset 6 IE 0x1 i = 0x82, ‘10’
Indicates charging information. This information is specific to the NTT switch type and may not be sent by other switch types.
CONNECT
Indicates that the called user has accepted the call.
CONNECT_ACK
Indicates that the calling user acknowledges the called user’s acceptance of the call.
DISCONNECT
Indicates either that the user side has requested the network to clear an end-to-end connection or that the network has cleared the end-to-end connection.
i =
Indicates the information element identifier. The value depends on the field with which the identifier is associated. See the ITU-T Q.931 specification for details about the possible values associated with each field for which this identifier is relevant.
Looking Shift to Codeset 6
Indicates that the next information elements will be interpreted according to information element identifiers assigned in codeset 6. Codeset 6 means that the information elements are specific to the local network.
pd
Indicates the protocol discriminator that distinguishes messages for call control over the user-network ISDN interface from other ITU-T-defined messages, including other Q.931 messages. The protocol discriminator is 8 for call control messages, such as SETUP. For basic-1tr6, the protocol discriminator is 65.
Protocol Profile
Remote operations protocol, which contains networking extensions for other services. This profile determines which protocol should be used to decode the rest of a Facility IE message.
A Facility IE can contain multiple components. Each component displays a hexadecimal code followed by the code contents in text.
In the example that included encoded ISDN Facility IE message output, 0xA106020107020103 is the hexadecimal code and represents the Facility IE Component, Invoke Id, and Operation. The Operation portion of the IE corresponds to the supplementary service that the component represents.
RELEASE
Indicates that the sending equipment will release the channel and call reference. The recipient of this message should prepare to release the call reference and channel.
RELEASE_COMP
Indicates that the sending equipment has received a RELEASE message and has now released the call reference and channel.
RX <-
Indicates that this message is being received by the user side of the ISDN interface from the network side.
SETUP
Indicates that the SETUP message type has been sent to initiate call establishment between peer network layers. This message can be sent from either the local router or the network.
TX ->
Indicates that this message is being sent from the local router (user side) to the network side of the ISDN interface.
Text in bold in the following example indicates the acceptance of an incoming X.25 call on the ISDN D channel, per ITU Q.931 SAPI value 0 procedures:
Router# debug isdn q931
*Sep 28 12:34:29.739: ISDN BR1/1 Q931: RX <- SETUP pd = 8 callref = 0x5C (re-assembled)
Bearer Capability i = 0x88C0C2E6
Standard = CCITT
Transfer Capability = Unrestricted Digital
Transfer Mode = Packet
Transfer Rate = Packet - not specified
User Info L2 Protocol = Recommendation Q921/I.441User Info L3 Protocol = Recommendation X.25, Packet Layer
Channel ID i = 0x8C
Exclusive, No B-channel
Information Rate i = 0x8888
Packet Layer Binary Params i = 0x80
Packet Layer Window Size i = 0x8282
Packet Size i = 0x8888
Calling Party Number i = 0x0083, '144014384106'
Plan:Unknown, Type:Unknown
User-User i = 0x02CC000000
The command output is intermingled with information from the
debugisdnevents command; see the description for the
debugisdnevents command to understand significant fields displayed in this report.
Related Commands
Command
Description
debugisdnevents
Displays ISDN events occurring on the router (user side) of the ISDN interface.
debugisdnq921
Displays Layer 2 access procedures that are taking place at the router on the D channel of the ISDN interface.
servicetimestamps
Configure a time stamp on debugging or system logging messages.
debug isdn tgrm
To view ISDN trunk group resource manager information, use the
debugisdntgrmcommand in privileged EXEC mode. To disable debugging output, use the
no form of this command.
debugisdntgrm
nodebugisdntgrm
Syntax Description
This command has no arguments or keywords.
Command Default
Disabled
Command Modes
Privileged EXEC
Command History
Release
Modification
12.2(11)T
This command was introduced.
Usage Guidelines
Disable console logging and use buffered logging before using the
debugisdntgrm command. Using the
debugisdntgrm command generates a large volume of debugs, which can affect router performance.
Examples
Sample output from the
debugisdntgrm command is shown below.
The output shows that the channel used (bchan) is 1, service state is 0 (in-service), call_state is 2 (busy), “false busy” is 0, and DSL is 2. The output also shows that the B channel is 1, the channel is available, and the call state is transitioned from 0 (idle) to 2 (busy).
The last two lines of output shows that bchan is 1, call state is 1 (busy), call type is 2 (voice), and call direction is 1 (incoming).
00:26:31:ISDN:get_tgrm_avail_state:idb 0x64229380 bchan 1 service_state 0 call_state 2 false busy 0x0 dsl 2
00:26:31:ISDN:update_tgrm_call_status:idb 0x64229380 bchan 1 availability state 1 call state(prev,new) (0,2), dsl 2
00:26:31:ISDN:Calling TGRM with tgrm_call_isdn_update:idb 0x64229380 bchan 1 call state 1 call type 2 call dir 1
The table below provides an alphabetical listing of the fields shown in the
debugisdntgrmcommand output and a description of each field.
Table 13 debug isdn tgrm Field Descriptions
Field
Description
availability state
Indicates whether the channel is available:
0 = Not available 1 = Available
bchan
Bearer channel used for this call.
call dir
Direction of the call:
0 = Incoming 1 = Outgoing
call_state
State of the call. It has different values depending on whether it is from ISDN perspective or TGRM perspective.
When printed from get_tgrm_avail_state(), it is the state value from ISDN perspective:
When printed from tgrm_call_isdn_update(), it is the state value from TGRM perspective:
0 = Idle 1 = Busy 2 = Pending 3 = Reject
call state (prev, new)
Indicates the state transition of the call. The state values are as shown in call_state from the ISDN perspective.
call type
Type of call:
0 = Invalid 1 = Data 2 = Voice 3 = Modem 4 = None
dsl
Internal interface identifier.
false busy
Bit map of all the channels on the interface indicating their soft busy status.
idb
Address of the interface descriptor block (IDB) for the interface.
service_state
Service state:
0 = In-service 1 = Maintenance 2 = Out of service
Related Commands
Command
Description
showtrunkgroup
Displays the configuration of the trunk group.
translation-profile(voiceservicePOTS)
Assigns a translation profile to the interface.
trunk-group(interface)
Assigns a trunk group to the interface.
debug isis adj packets
To display information on all a
djacency-related activity such as hello packets sent and received and Intermediate System-to-Intermediate System (
IS-IS) adjacencies going up and down, use the debugisisadjpackets
command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugisisadjpackets [interface]
nodebugisisadjpackets [interface]
Syntax Description
interface
(Optional) Interface or subinterface name.
Command Modes
Privileged EXEC
Examples
The following is sample output from the debugisisadjpackets command:
Router# debug isis adj packets
ISIS-Adj: Rec L1 IIH from 0000.0c00.40af (Ethernet0), cir type 3, cir id BBBB.BBBB.BBBB.01
ISIS-Adj: Rec L2 IIH from 0000.0c00.40af (Ethernet0), cir type 3, cir id BBBB.BBBB.BBBB.01
ISIS-Adj: Rec L1 IIH from 0000.0c00.0c36 (Ethernet1), cir type 3, cir id CCCC.CCCC.CCCC.03
ISIS-Adj: Area mismatch, level 1 IIH on Ethernet1
ISIS-Adj: Sending L1 IIH on Ethernet1
ISIS-Adj: Sending L2 IIH on Ethernet1
ISIS-Adj: Rec L2 IIH from 0000.0c00.0c36 (Ethernet1), cir type 3, cir id BBBB.BBBB.BBBB.03
The following line indicates that the router received an
IS-IS
hello
packet (IIH) on Ethernet interface 0 from the Level 1 router (L1) at MAC address 0000.0c00.40af. The circuit type is the interface type:
1--Level 1 only; 2--Level 2 only; 3--Level 1/2
The circuit ID is what the neighbor interprets as the designated router for the interface.
ISIS-Adj: Rec L1 IIH from 0000.0c00.40af (Ethernet0), cir type 3, cir id BBBB.BBBB.BBBB.01
The following line indicates that the router (configured as a Level 1 router) received on Ethernet interface 1 is an IS-IS hello packet from a Level 1 router in another area, thereby declaring an area mismatch:
ISIS-Adj: Area mismatch, level 1 IIH on Ethernet1
The following lines indicates that the router (configured as a Level 1/Level 2 router) sent on Ethernet interface 1 is a Level 1 IS-IS hello packet, and then a Level 2 IS-IS packet:
ISIS-Adj: Sending L1 IIH on Ethernet1
ISIS-Adj: Sending L2 IIH on Ethernet1
debug isis authentication
To enable debugging of
Intermediate System-to-Intermediate System (IS-IS) authentication, use the debugisisauthenticationcommand in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugisisauthenticationinformation
nodebugisisauthenticationinformation
Syntax Description
information
Required keyword that specifies IS-IS authentication information.
Command Default
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(21)ST
This command was introduced.
12.2(13)T
This command was integrated into Cisco IOS Release 12.2(13)T.
12.2(14)S
This command was integrated into Cisco IOS Release 12.2(14)S.
Examples
The following is sample output from the debugisisauthenticationcommand with the information keyword:
Router# debug isis authentication information
3d03h:ISIS-AuthInfo:No auth TLV found in received packet
3d03h:ISIS-AuthInfo:No auth TLV found in received packet
The sample output indicates that the router has been running for 3 days and 3 hours. Debugging output is about IS-IS authentication information. The local router is configured for authentication, but it received a packet that does not contain authentication data; the remote router does not have authentication configured.
debug isis ipv6 rib
To display debugging information for Integrated Intermediate System-to-Intermediate System (IS-IS) IPv6 Version 6 routes in the global or local Routing Information Base (RIB), use the
debugisisribcommand in privileged EXEC mode. To disable the debugging of IS-IS IPv6 routes, use the
no form of this command.
debugisis ipv6rib
[ global | local
[ access-list-number | terse ] ]
nodebugisis ipv6rib
[ global | local ]
Syntax Description
global
(Optional) Displays debugging information for IS-IS IP Version 4 routes in the global RIB.
local
(Optional) Displays debugging information for IS-IS IP Version 4 routes in the IS-IS local RIB.
access-list-number
(Optional) Number of an access list. This is a decimal number from 100 to 199 or from 2000 to 2699.
terse
(Optional) Will not display debug information if the IS-IS IP Version 4 IS-IS local RIB has not changed.
Command Default
Debugging of IS-IS IPv6 routes is disabled.
Command Modes
Privileged EXEC
Command History
Release
Modification
Cisco IOS XE Release 3.6S
This command was introduced.
Usage Guidelines
Examples
The following is sample output from the
debugisis ipv6ribcommand shows shows an IPv6 prefix tag.
The table below describes the significant fields shown in the display.
Table 14 debug isis ipv6 rib Field Descriptions
Field
Description
Related Commands
Command
Description
isis ipv6 tag
Configures an administrative tag value to be associated with an IPv6 address prefix.
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
debugisismplstraffic-engadvertisements command in privileged EXEC mode. To disable debugging output, use the
no form of this command.
debugisismplstraffic-engadvertisements
nodebugisismplstraffic-engadvertisements
Syntax Description
This command has no arguments or keywords.
Command Default
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(5)ST
This command was introduced.
12.1(3)T
This command was integrated into Cisco IOS Release 12.1(3)T.
12.0(22)S
This command was integrated into Cisco IOS Release 12.0(22)S.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
Examples
In the following example, information about traffic engineering advertisements is printed in IS-IS LSA messages:
Number of links that MPLS traffic engineering advertised.
Neighbor System ID
Identification value for the remote system in an area.
Interface IP address
IPv4 address of the interface.
Neighbor IP Address
IPv4 address of the neighbor.
Admin. Weight
Administrative weight associated with this link.
Physical BW
Bandwidth capacity of the link (in bits per second).
Reservable BW
Amount of reservable bandwidth on this link.
BW unreserved
Amount of bandwidth that is available for reservation.
Affinity Bits
Attribute flags of the link that are being flooded.
debug isis mpls traffic-eng events
To print information about traffic engineering-related Intermediate System-to-Intermediate System (IS-IS) events, use thedebugisismplstraffic-engevents command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugisismplstraffic-engevents
nodebugisismplstraffic-engevents
Syntax Description
This command has no arguments or keywords.
Command Default
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(5)ST
This command was introduced.
12.1(3)T
This command was integrated into Cisco IOS Release 12.1(3)T.
12.0(22)S
This command was integrated into Cisco IOS Release 12.0(22)S.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
Examples
In the following example, information is printed about traffic engineering-related IS-IS events:
Router# debug isis mpls traffic-eng events
ISIS-RRR:Send MPLS TE Et4/0/1 Router1.02 adjacency down:address 0.0.0.0
ISIS-RRR:Found interface address 10.1.0.6 Router1.02, building subtlv... 58 bytes
ISIS-RRR:Found interface address 10.42.0.6 Router2.00, building subtlv... 64 bytes
ISIS-RRR:Interface address 0.0.0.0 Router1.00 not found, not building subtlv
ISIS-RRR:LSP Router1.02 changed from 0x606BCD30
ISIS-RRR:Mark LSP Router1.02 changed because TLV contents different, code 16
ISIS-RRR:Received 1 MPLS TE links flood info for system id Router1.00
debug isis nsf
To display information about the Intermediate System-to-Intermediate System (IS-IS) state during a Cisco nonstop forwarding (NSF) restart, use the debugisisnsf command in privileged EXEC mode. To disable debugging output, use the no form of this command.
This command was integrated into Cisco IOS Release 12.2(18)S.
12.2(20)S
Support for the Cisco 7304 router was added.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
Usage Guidelines
Use the debugisisnsfcommand to display basic information about the IS-IS state during an NSF restart. Use thedebugisisnsfdetailcommand to display additional IS-IS state detail during an NSF restart.
Examples
The following example displays IS-IS state information during an NSF restart:
router# debug isis nsf
IS-IS NSF events debugging is on
The following example displays detailed IS-IS state information during an NSF restart:
router# debug isis nsf detail
IS-IS NSF events (detailed) debugging is on
router#
Jan 24 20:04:54.090:%CLNS-5-ADJCHANGE:ISIS:Adjacency to gsr1 (GigabitEthernet2/0/0) Up, Standby adjacency
Jan 24 20:04:54.090:ISIS-NSF:ADJ:000C.0000.0000 (Gi2/0/0), type 8/1, cnt 0/1, ht 10 (NEW)
Jan 24 20:04:54.142:ISIS-NSF:Rcv LSP - L2 000B.0000.0000.00-00, seq 251, csum B0DC, ht 120, len 123 (local)
Jan 24 20:04:55.510:ISIS-NSF:Rcv LSP - L1 000B.0000.0000.00-00, seq 23E, csum D20D, ht 120, len 100 (local)
Jan 24 20:04:56.494:ISIS-NSF:ADJ:000C.0000.0000 (Gi2/0/0), type 8/0, cnt 0/1, ht 30
Jan 24 20:04:56.502:ISIS-NSF:Rcv LSP - L1 000B.0000.0000.01-00, seq 21C, csum 413, ht 120, len 58 (local)
Jan 24 20:04:58.230:ISIS-NSF:Rcv LSP - L2 000C.0000.0000.00-00, seq 11A, csum E197, ht 1194, len 88 (Gi2/0/0)
Jan 24 20:05:00.554:ISIS-NSF:Rcv LSP - L1 000B.0000.0000.00-00, seq 23F, csum 1527, ht 120, len 111 (local)
Related Commands
Command
Description
nsf(IS-IS)
Configures NSF operations for IS-IS.
nsfinterfacewait
Specifies how long an NSF restart will wait for all interfaces with IS-IS adjacencies to come up before completing the restart.
nsfinterval
Specifies the minimum time between NSF restart attempts.
nsft3
Specifies the methodology used to determine how long IETF NSF will wait for the LSP database to synchronize before generating overloaded link state information for itself and flooding that information out to its neighbors.
showclnsneighbors
Displays both ES and IS neighbors.
showisisnsf
Displays current state information regarding IS-IS NSF.
debug isis rib
To display debugging information for Integrated Intermediate System-to-Intermediate System (IS-IS) IP Version 4 routes in the global or local Routing Information Base (RIB), use the
debugisisribcommand in privileged EXEC mode. To disable the debugging of IS-IS IP Version 4 routes, use the
no form of this command.
debugisisrib
[ global | local
[ access-list-number | terse ] ]
nodebugisisrib
[ global | local ]
Syntax Description
global
(Optional) Displays debugging information for IS-IS IP Version 4 routes in the global RIB.
local
(Optional) Displays debugging information for IS-IS IP Version 4 routes in the IS-IS local RIB.
access-list-number
(Optional) Number of an access list. This is a decimal number from 100 to 199 or from 2000 to 2699.
terse
(Optional) Will not display debug information if the IS-IS IP Version 4 IS-IS local RIB has not changed.
Command Default
Debugging of IS-IS IP Version 4 routes is disabled.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(26)S
This command was introduced.
12.3(4)T
This command was integrated into Cisco IOS Release 12.3(4)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
12.2(18)SXE
This command was integrated into Cisco IOS Release 12.2(18)SXE.
12.2(27)SBC
This command was integrated into Cisco IOS Release 12.2(27)SBC.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
Usage Guidelines
Use the
debugisisrib command to verify if an IP prefix has been installed or removed. To monitor updates from the IS-IS database to the IS-IS local RIB, use the
local keyword, and to monitor updates from the IS-IS database to the global RIB, use the
global keyword.
It is highly recommended that you limit the debugging output to information specific to the IP prefix that is associated with a specific access list by entering the
accest-list-number argument.
Examples
The following is sample output from the
debugisisribcommand after the
iproutepriorityhighcommand was used to give high priority to IS-IS IP prefixes for the configured access list access-list1. The debug output shows that the route 10.1.1.0/24 has been removed from the IS-IS local RIB.
Router# show running-config| include access-list 1
accest-list 1 permit 10.1.1.0 0.0.0.255
! access-list 1 is configured
Router# debug isis rib local terse 1
00:07:07: ISIS-LR: 10.1.1.0/24 aged out in LSP[10/(7->8)]
! The route 10.1.1.0/24 is removed from the IS-IS local RIB LSP[10/(7->8)].
00:07:07: ISIS-LR: rem path: [115/80/20] via 10.2.2.2(Et2) from 10.22.22.22 tg 0 LSP[10/7] from active chain (add to deleted chain)
!The remote path [115/80/20] is removed from the active chain.
00:07:07: ISIS-LR: Enqueued to updateQ[2] for 10.1.1.0/24
!Q[2] is marked to be the update
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 deleted chain
00:07:07: ISIS-LR: Rem RT 10.1.1.0/24
!The remote route [115/80/20] is removed from the deleted chain
The table below describes the significant fields shown in the display.
Table 16 debug isis rib Field Descriptions
Field
Description
ISIS-LR
IS-IS local route debugger.
10.1.1.0/24
IP prefix.
rem path:
Indicates the removal or insertion of a routing path--in this instance, it is a removal.
[115/80/20]
Administrative instance/type/metric for the routing path that has been removed or inserted.
via 10.2.2.2(Et2)
IP address of the next hop of the router, in this instance, Ethernet2.
from 10.22.22.22
IP address to advertise the route path.
tg 0
Priority of the IP prefix. All prefixes have a tag 0 priority unless otherwise configured.
Related Commands
Command
Description
iproutepriorityhigh
Assigns a high priority to an IS-IS IP prefix.
showisisrib
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 debugisisribredistributioncommand in privileged EXEC mode. To turn off debugging, use the no form of this command.
(Optional) Displays debug information for level 1 redistribution cache.
level-2
(Optional) Displays debug information for level 2 redistribution cache.
access-list
(Optional) An access list number from 1 to 199 or from 1300 to 2699.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(27)S
This command was introduced.
12.3(7)T
This command was integrated into Cisco IOS Release 12.3(7)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
12.2(18)SXE
This command was integrated into Cisco IOS Release 12.2(18)SXE.
12.2(27)SBC
This command was integrated into Cisco IOS Release 12.2(27)SBC.
Usage Guidelines
We recommend that you use this command only when a Cisco Technical Assistance Center representative requests you to do so to gather information for a troubleshooting purpose.
Examples
In the following example, the debugisisribredistribution command is used to display information about events that update the IS-IS redistribution cache. The output is self-explanatory.
Router# debug isis rib redistribution level-1 123
IS-IS IPv4 redistribution RIB debugging is on for access list 123 for L1
Router# router isis
Router(config-router)# redistribute connected level-1
Router(config)# access-list 123 permit ip 10.0.0.0 0.255.255.255 any
Router(config)# interface Loopback123
Router(config-if)# ip address 10.123.123.3 255.255.255.255
Nov 25 00:33:46.532: ISIS-RR: 10.123.123.3/32: Up event, from 0x607CAF60
Nov 25 00:33:46.532: ISIS-RR: looking at L1 redist RIB
Nov 25 00:33:46.532: ISIS-RR: redistributed to ISIS
Nov 25 00:33:46.532: ISIS-RR: added 10.123.123.3/32 to L1 redist RIB: [Connected/0] tag 0 external
Nov 25 00:33:47.532: ISIS-RR: Scanning L1 redist RIB
Nov 25 00:33:47.532: ISIS-RR: adv 10.123.123.3/32 as L1 redist route
Nov 25 00:33:47.532: ISIS-RR: End of scanningL1 redist RIB
The following line indicates that the connected route 10.123.123.3/32 was added to the IS-IS level 1 local redistribution cache with cost 0, metric type external, and administrative tag of 0:
Nov 25 00:33:46.532: ISIS-RR: added 10.123.123.3/32 to L1 redist RIB: [Connected/0] tag 0 external
The following line indicates that the redistributed route 10.123.123.3/32 was advertised in an IS-IS link-state packet (LSP) as a level 1 redistributed route:
Nov 25 00:33:47.532: ISIS-RR: adv 10.123.123.3/32 as L1 redist rout
Related Commands
Command
Description
clearisisribredistribution
Clears some or all prefixes in the local redistribution cache.
showisisribredistribution
Displays the prefixes in the IS-IS redistribution cache.
debug isis spf statistics
To display statistical information about building routes between intermediate systems (ISs), use the
debugisisspfstatistics command in privileged EXEC mode. To disable debugging output, use the
no form of this command.
debugisisspfstatistics
nodebugisisspfstatistics
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
debugisisspfstatistics command provides information for determining the time required to place a Level 1 IS or Level 2 IS on the shortest path tree (SPT) using the IS-IS protocol.
Note
The SPF algorithm is also called the Dijkstra algorithm, after the creator of the algorithm.
Examples
The following is sample output from the
debugisisspfstatistics command:
The table below describes the significant fields shown in the display.
Table 17 debug isis spf statistics Field Descriptions
Field
Description
Compute L1 SPT
Indicates that Level 1 ISs are to be added to a Level 1 area.
Timestamp
Indicates the time at which the SPF algorithm was applied. The time is expressed as the number of seconds elapsed since the system was up and configured.
Complete L1 SPT
Indicates that the algorithm has completed for Level 1 routing.
Compute time
Indicates the time required to place the ISs on the SPT.
nodes on SPT
Indicates the number of ISs that have been added.
Compute L2 SPT
Indicates that Level 2 ISs are to be added to the domain.
Complete L2 SPT
Indicates that the algorithm has completed for Level 2 routing.
The following lines show the statistical information available for Level 1 ISs:
ISIS-Stats: Compute L1 SPT, Timestamp 2780.328 seconds
ISIS-Stats: Complete L1 SPT, Compute time 0.004, 1 nodes on SPT
The output indicates that the SPF algorithm was applied 2780.328 seconds after the system was up and configured. Given the existing intra-area topology, 4 milliseconds were required to place one Level 1 IS on the SPT.
The following lines show the statistical information available for Level 2 ISs:
ISIS-Stats: Compute L2 SPT, Timestamp 2780.3336 seconds
ISIS-Stats: Complete L2 SPT, Compute time 0.056, 12 nodes on SPT
This output indicates that the SPF algorithm was applied 2780.3336 seconds after the system was up and configured. Given the existing intradomain topology, 56 milliseconds were required to place 12 Level 2 ISs on the SPT.
debug isis 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 debugisisspf-eventscommand in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugisisspf-events
nodebugisisspf-events
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0
This command was introduced.
12.2(15)T
Support for IPv6 was added.
12.2(18)S
Support for IPv6 was added.
12.0(26)S
Support for IPv6 was added.
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
Cisco IOS XE Release 2.6
This command was introduced on Cisco ASR 1000 series routers.
Usage Guidelines
This command displays information about significant events that occur during SPF-related processing.
Examples
The following example displays significant events during an IS-IS SPF computation:
Router# debug isis spf-events
ISIS-Spf: Compute L2 IPv6 SPT
ISIS-Spf: Move 0000.0000.1111.00-00 to PATHS, metric 0
ISIS-Spf: Add 0000.0000.2222.01-00 to TENT, metric 10
ISIS-Spf: Move 0000.0000.2222.01-00 to PATHS, metric 10
ISIS-Spf: considering adj to 0000.0000.2222 (Ethernet3/1) metric 10, level 2, circuit 3, adj 3
ISIS-Spf: (accepted)
ISIS-Spf: Add 0000.0000.2222.00-00 to TENT, metric 10
ISIS-Spf: Next hop 0000.0000.2222 (Ethernet3/1)
ISIS-Spf: Move 0000.0000.2222.00-00 to PATHS, metric 10
ISIS-Spf: Add 0000.0000.2222.02-00 to TENT, metric 20
ISIS-Spf: Next hop 0000.0000.2222 (Ethernet3/1)
ISIS-Spf: Move 0000.0000.2222.02-00 to PATHS, metric 20
ISIS-Spf: Add 0000.0000.3333.00-00 to TENT, metric 20
ISIS-Spf: Next hop 0000.0000.2222 (Ethernet3/1)
ISIS-Spf: Move 0000.0000.3333.00-00 to PATHS, metric 20
debug isis update-packets
To display
various
sequence number protocol data units (PDUs) and
link-state
packets that are detected by a router, use the debugisisupdate-packets
command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugisisupdate-packets
nodebugisisupdate-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 debugisisupdate-packets command:
Router# debug isis update-packets
ISIS-Update: Sending L1 CSNP on Ethernet0
ISIS-Update: Sending L2 CSNP on Ethernet0
ISIS-Update: Updating L2 LSP
ISIS-Update: Delete link 888.8800.0181.00 from L2 LSP 1600.8906.4022.00-00, seq E
ISIS-Update: Updating L1 LSP
ISIS-Update: Sending L1 CSNP on Ethernet0
ISIS-Update: Sending L2 CSNP on Ethernet0
ISIS-Update: Add link 8888.8800.0181.00 to L2 LSP 1600.8906.4022.00-00, new seq 10,
len 91
ISIS-Update: Sending L2 LSP 1600.8906.4022.00-00, seq 10, ht 1198 on Tunnel0
ISIS-Update: Sending L2 CSNP on Tunnel0
ISIS-Update: Updating L2 LSP
ISIS-Update: Rate limiting L2 LSP 1600.8906.4022.00-00, seq 11 (Tunnel0)
ISIS-Update: Updating L1 LSP
ISIS-Update: Rec L2 LSP 888.8800.0181.00.00-00 (Tunnel0)
ISIS-Update: PSNP entry 1600.8906.4022.00-00, seq 10, ht 1196
The following lines indicate that the router has sent a periodic Level 1 and Level 2 complete sequence number PDU on Ethernet interface 0:
ISIS-Update: Sending L1 CSNP on Ethernet0
ISIS-Update: Sending L2 CSNP on Ethernet0
The following lines indicate that the network service access point (
NSAP)
identified as 8888.8800.0181.00 was deleted from the Level 2 LSP 1600.8906.4022.00-00. The sequence number associated with this LSP is 0xE.
ISIS-Update: Updating L2 LSP
ISIS-Update: Delete link 888.8800.0181.00 from L2 LSP 1600.8906.4022.00-00, seq E
The following lines indicate that the NSAP identified as 8888.8800.0181.00 was added to the Level 2 LSP 1600.8906.4022.00-00. The new sequence number associated with this LSP is 0x10.
ISIS-Update: Updating L1 LSP
ISIS-Update: Sending L1 CSNP on Ethernet0
ISIS-Update: Sending L2 CSNP on Ethernet0
ISIS-Update: Add link 8888.8800.0181.00 to L2 LSP 1600.8906.4022.00-00, new seq 10,
len 91
The following line indicates that the router sent Level 2 LSP 1600.8906.4022.00-00 with sequence number 0x10 on tunnel 0 interface:
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.
To display debugging messages for the IDSN User Adaptation Layer (IUA) application server (AS), use the debugiuaas command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugiuaas
{ user | state }
{ all | nameas-name }
nodebugiuaas
Syntax Description
user
Displays information about the use of application programming interfaces (APIs) and events between the ISDN layer and IUA.
state
Displays information about AS state transitions.
all
Enables debug for all the configured ASs.
nameas-name
Defines the name of the AS.
Command Default
No default behavior or values
Command Modes
Privileged EXEC
Command History
Release
Modification
12.2(4)T
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T on the Cisco 2420, Cisco 2600 series, Cisco 3600 series, and Cisco 3700 series; and Cisco AS5300, Cisco AS5350, Cisco AS5400, and Cisco AS5850 network access server (NAS) platforms.
Examples
The following example shows debugging output when an ISDN backhaul connection is initially established. The output shows that state debugging is turned on for all ASs and that the AS is active.
Router# debug iua as state all
IUA :state debug turned ON for ALL AS
00:11:52:IUA:AS as1 number of ASPs up is 1
00:11:57:IUA:AS as1 xsition AS-Up --> AS-Active, cause - ASP asp1
Related Commands
Command
Description
debugiuaasp
Displays debugging messages for the IUA ASP.
debug iua asp
To display debugging messages for the IDSN User Adaptation Layer (IUA) application server process (ASP), use the debugiuaasp command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugiuaasp
{ pak | peer-msg | sctp-sig | state }
{ all | nameasp-name }
nodebugiuaasp
Syntax Description
pak
Displays information about all packets.
peer-msg
Displays information about IUA peer-to-peer messages.
sctp-sig
Displays information about the signals being sent by the Stream Control Transmission Protocol (SCTP) layer.
state
Displays information about ASP state transition.
all
Enables debugging output for all configured ASPs.
nameasp-name
Defines the name of the ASP.
Command Default
No default behavior or values
Command Modes
Privileged EXEC
Command History
Release
Modification
12.2(4)T
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T on the Cisco 2420, Cisco 2600 series, Cisco 3600 series, and Cisco 3700 series; and Cisco AS5300, Cisco AS5350, Cisco AS5400, and Cisco AS5850 network access server (NAS) platforms.
Examples
The following example shows debugging output when an ISDN backhaul connection is initially established. The output shows that peer message debugging is turned on for all ASPs and that the ASP is active.
Router# debug iua asp peer-msg all
IUA :peer message debug turned ON for ALL ASPs
Router#
00:04:58:IUA :recieved ASP_UP message on ASP asp1
00:04:58:IUA:ASP asp1 xsition ASP-Down --> ASP-Up , cause - rcv peer
msg
ASP-UP
00:04:58:IUA:sending ACK of type 0x304 to asp asp1
00:05:03:IUA:recv ASP_ACTIVE message for ASP asp1
00:05:03:IUA:ASP asp1 xsition ASP-Up --> ASP-Active, cause - rcv peer
msg
ASP-Active
Related Commands
Command
Description
debugiuaas
Displays debugging messages for the IUA AS.
debug kerberos
To display
information associated with the Kerberos Authentication Subsystem, use the debugkerberoscommand in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugkerberos
nodebugkerberos
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 debugaaaauthentication command to get a high-level view of login activity. When Kerberos is used on the router, you can use the debugkerberoscommand for more detailed debugging information.
Examples
The following is part of the sample output from the debugaaaauthentication command for a Kerberos login attempt that failed. The information indicates that Kerberos is the authentication method used.
Router# debug aaa authentication
AAA/AUTHEN/START (116852612): Method=KRB5
AAA/AUTHEN (116852612): status = GETUSER
AAA/AUTHEN/CONT (116852612): continue_login
AAA/AUTHEN (116852612): status = GETUSER
AAA/AUTHEN (116852612): Method=KRB5
AAA/AUTHEN (116852612): status = GETPASS
AAA/AUTHEN/CONT (116852612): continue_login
AAA/AUTHEN (116852612): status = GETPASS
AAA/AUTHEN (116852612): Method=KRB5
AAA/AUTHEN (116852612): password incorrect
AAA/AUTHEN (116852612): status = FAIL
The following is sample output from the debugkerberos command for a login attempt that was successful. The information indicates that the router sent a request to the key distribution center (KDC) and received a valid credential.
Router# debug kerberos
Kerberos: Requesting TGT with expiration date of 820911631
Kerberos: Sent TGT request to KDC
Kerberos: Received TGT reply from KDC
Kerberos: Received valid credential with endtime of 820911631
The following is sample output from the debugkerberos command for a login attempt that failed. The information indicates that the router sent a request to the KDC and received a reply, but the reply did not contain a valid credential.
Router# debug kerberos
Kerberos: Requesting TGT with expiration date of 820911731
Kerberos: Sent TGT request to KDC
Kerberos: Received TGT reply from KDC
Kerberos: Received invalid credential.
AAA/AUTHEN (425003829): password incorrect
The following output shows other failure messages you might see that indicate a configuration problem. The first message indicates that the router failed to find the default Kerberos realm, therefore the process failed to build a message to send to the KDC. The second message indicates that the router failed to retrieve its own IP address. The third message indicates that the router failed to retrieve the current time. The fourth message indicates the router failed to find or create a credentials cache for a user, which is usually caused by low memory availability.
Router# debug kerberos
Kerberos: authentication failed when parsing name
Kerberos: authentication failed while getting my address
Kerberos: authentication failed while getting time of day
Kerberos: authentication failed while allocating credentials cache
Related Commands
Command
Description
debugaaaauthentication
Displays information on accountable events as they occur.
debug kpml
To enable Keypad Markup Language (KPML) parser and builder debugs, use the debugkpml 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).
debugkpml
[ all | parser | builder | error ]
nodebugkpml
[ 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
nodebugkpmlall
Command Modes
Privileged EXEC mode
Command History
Release
Modification
12.4(9)T
This command was introduced.
Usage Guidelines
For incoming dial peers if you configure multiple DTMF negotiation methods, the first configure value takes precedence, then the second, then the third.
For incoming dial peers, the first out-of-band negotiation method takes precedence over other DTMF negotiation methods, except when rtp-nte has precedence; in this case, sip-kpml takes precedence over other out-of-band negotiation methods.
For incoming dial peers, if both sip-kpml and rtp-nte notification mechanisms are enabled and negotiated, the gateway relies on RFC 2833 notification to receive digits and a SUBSCRIBE for KPML is not initiated.
SIP KPML support complies to the IEFT draft “draft-ietf-sipping-kpml-04.txt” with the following limitations:
The SIP gateway always initiates SUBSCRIBE in the context of an established INVITE dialog. The gateway supports receiving SUBSCRIBE in the context of an established INVITE dialog, as well as out-of-call context requests with a leg parameter in the Event header. If the request code does not match an existing INVITE dialog, the gateway sends a NOTIFY with KPML status-code 481 and sets Subscription-State to terminated.
The gateway does not support the Globally Routable User Agent (GRUU) requirement. The Contact header in the INVITE/200 OK message generates locally from the gateway’s contact information.
The gateway always initiates persistent subscriptions, but it receives and processes persistent and one-shot subscriptions.
The gateway supports only single-digit reporting. There is no need for inter-digit timer support. The only regular expressions supported are those which match to a single digit. For example:
<regex>x</regex>--Matches to any digit 0 through 9
<regex>1</regex>--Matches digit 1
<regex>[x#*ABCD]</regex>--Matches to any digit 0 through 9, # (the pound sign), * (an asterisk), or A, B, C, or D
<regex>[24]</regex>--Matches digits 2 or 4
<regex>[2-9]</regex>--Matches on any digit 2 through 9
<regex>[^2-9]</regex>--Matches digits 0 or 1
The gateway does not support long key presses. Long key presses are detected and reported as a single digit press.
Digit suppression is not supported (pre
tag for suppressing inband digits).
Individual stream selection is not supported. A SUBSCRIBE request for KPML applies to all audio streams in the dialog (stream
element and reverse
not supported).
You can configure support only on a SIP VoIP dial peer.
Examples
The following is output from the debugkpml command:
To display debugging messages about Command Scheduler policies or occurrences, use the debugkron command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugkron
{ all | exec-cli | info | major }
nodebugkron
{ all | exec-cli | info | major }
Syntax Description
all
Displays all debugging output about Command Scheduler policy lists or occurrences.
exec-cli
Displays detailed debugging output about Command Scheduler policy list command-line interface (CLI) commands.
info
Displays debugging output about Command Scheduler policy lists, occurrence warnings, or progress information.
major
Displays debugging output about Command Scheduler policy list or occurrence failures.
Command Default
If no keyword is specified, all debugging messages are displayed.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
12.3(1)
This command was introduced.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SRC
This command was integrated into Cisco IOS Release 12.2(33)SRC.
12.2(33)SB
This command was integrated into Cisco IOS Release 12.2(33)SB.
12.2(33)SXI
This command was integrated into Cisco IOS Release 12.2(33)SXI.
Usage Guidelines
Use the debugkron 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 showversion after the CLI was run at a scheduled interval:
Displays the status and schedule information for Command Scheduler occurrences.
debug l2ctrl
To enable debugging for Layer 2 Control (L2CTRL), use the debugl2ctrl command in privileged EXEC mode. To disable debugging for L2CTRL, use the no form of this command.
debugl2ctrl
{ all | evc | pm | registry }
nodebugl2ctrl
{ all | evc | pm | registry }
Syntax Description
all
Displays all L2CTRL debugging messages.
evc
Displays Ethernet virtual circuit (EVC) and L2CTRL messages.
pm
Displays switch PM and L2CTRL messages.
registry
Displays L2CTRL registries.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
12.2(33)SRD
This command was introduced.
Examples
The following example shows how to enable debugging of all L2CTRL related events:
Router# debug l2ctrl all
Related Commands
Command
Description
debugethernetl2ctrl
Enables Ethernet L2CTRL debugging messages.
debug l2fib
To enable the logging of Layer 2 Forwarding Information Base (L2FIB) debug messages, use the
debug l2fib command in privileged EXEC mode. To disable the debugging, use the
no form of this command.
Enables logging of unicast or multicast object-specific debug messages.
unicast
(Optional) Enables logging of unicast object-specific debug messages.
multicast
(Optional) Enables logging of multicast object-specific debug messages.
all
Enables logging of all L2FIB debug messages.
bridge-domain
Enables logging of bridge-domain object-specific debug messages.
port
Enables logging of bridge-domain port object-specific debug messages.
event
Enables logging of event debug messages.
error
Enables logging of the error debug messages.
ha
Enables logging of high availability (HA) events.
l2port
Enables logging of Layer 2 port object-specific debug messages.
mlrib
Enables logging of Multilayer Routing Information Base (MLRIB) interactions.
olist
Enables logging of output list object-specific debug messages.
otv tunnel
Enables logging of Overlay Transport Virtualization (OTV) tunnel object-specific debug messages.
decap
Enables logging of OTV tunnel decap object-specific debug messages.
encap
Enables logging of OTV tunnel encap object-specific debug messages.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
Cisco IOS XE Release 3.5S
This command was introduced.
Examples
The following is sample output from the
debug l2fib all command:
Router# debug l2fib all
[11/11/11 19:57:17.256 169DFD 276] L2FIB-MCAST-DEBUG: l2fib_mcast_obj_handle_nh_list: Received next hop 70.1.1.2, Intf Ov47, owner 0x400, opcode 0x0, flags 0x2, for source 120.0.7.51, group 225.1.8.51, bd 1864
[11/11/11 19:57:17.256 169DFE 276] L2FIB-MCAST-DEBUG: l2fib_mcast_obj_add_oif: Added OIF ED 70.1.1.2, Intf Ov47, to src 120.0.7.51, grp 225.1.8.51 BD 1864.
[11/11/11 19:57:17.256 169DFF 276] L2FIB-MCAST-DEBUG: l2fib_mcast_obj_add_oif: Found existing Otv DG mapping 232.1.47.2, map count 2 for source 120.0.7.51, group 225.1.8.51, bridge domain 1864, OIF 70.1.1.2, Intf Ov47.
[11/11/11 19:57:17.256 169E00 276] L2FIB-HA-DEBUG: l2fib_ha_encode_mcast_nh_tlv: Encode Otv ED receiver port 70.1.1.2, Intf Ov47
[11/11/11 19:57:17.256 169E01 276] L2FIB-HA-DEBUG: l2fib_mcast_obj_chkp: Sync multicast with src 120.0.7.51, grp 225.1.8.51 BD 1864, rcvrs 1, Otv DG map 1, oper 0x4.
[11/11/11 19:57:17.256 169E02 276] L2FIB-HA-DEBUG: l2fib_ha_enqueue_message: Enqueued message to hold queue 0
[11/11/11 19:57:17.256 169E03 276] L2FIB-MCAST-DEBUG: l2fib_mcast_obj_handle_s_g: Received source 120.0.7.53, group 225.1.8.53, bridge domain 1866, next hop count 1.
[11/11/11 19:57:17.256 169E04 276] L2FIB-MCAST-DEBUG: l2fib_mcast_obj_handle_nh_list: Received next hop 70.1.1.2, Intf Ov47, owner 0x400, opcode 0x0, flags 0x2, for source 120.0.7.53, group 225.1.8.53, bd 1866
[11/11/11 19:57:17.256 169E05 276] L2FIB-MCAST-DEBUG: l2fib_mcast_obj_add_oif: Added OIF ED 70.1.1.2, Intf Ov47, to src 120.0.7.53, grp 225.1.8.53 BD 1866.
[11/11/11 19:57:17.256 169E06 276] L2FIB-MCAST-DEBUG: l2fib_mcast_obj_add_oif: Found existing Otv DG mapping 232.1.47.4, map count 2 for source 120.0.7.53, group 225.1.8.53, bridge domain 1866, OIF 70.1.1.2, Intf Ov47.
[11/11/11 19:57:17.256 169E07 276] L2FIB-HA-DEBUG: l2fib_ha_encode_mcast_nh_tlv: Encode Otv ED receiver port 70.1.1.2, Intf Ov47
[11/11/11 19:57:17.256 169E08 276] L2FIB-HA-DEBUG: l2fib_mcast_obj_chkp: Sync multicast with src 120.0.7.53, grp 225.1.8.53 BD 1866, rcvrs 1, Otv DG map 1, oper 0x4.
[11/11/11 19:57:17.256 169E09 276] L2FIB-HA-DEBUG: l2fib_ha_enqueue_message: Enqueued message to hold queue 0
[11/11/11 19:57:17.256 169E0A 276] L2FIB-MCAST-DEBUG: l2fib_mcast_obj_handle_s_g: Received source 120.0.7.58, group 225.1.8.58, bridge domain 1871, next hop count 1.
Related Commands
Command
Description
show l2fib
Displays information about L2FIB.
debug l2relay events
To start debugging of Layer 2 Relay events, use the debugl2relayevents command in privileged EXEC mode. To disable debugging output, use the noform of this command (SGSN D-node only).
debugl2relayevents
nodebugl2relayevents
Syntax Description
This command has no arguments or keywords.
Command Default
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.1(1)GA
This command was introduced.
12.1(3)T
This command was integrated into Cisco IOS Release 12.1(3)T.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
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 debugl2relaypackets command.
Normally you will not need to use the debugl2relayevents or debugl2relaypackets commands. If problems with the SGSN are encountered, Cisco technical support personnel may request that issue the command.
Caution
Because the debugl2relayeventscommand generates a substantial amount of output, use it only when traffic on the GPRS network is low, so other activity on the system is not adversely affected.
Examples
The following example enables the display of Layer 2 Relay events:
To display information about Layer 2 Relay packets, use the debugl2relaypackets command in privileged EXEC mode. To disable debugging output, use the noform of this command (SGSN D-node only).
debugl2relaypackets
nodebugl2relaypackets
Syntax Description
This command has no arguments or keywords.
Command Default
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.1(1)GA
This command was introduced.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.1(3)T
This command was integrated into Cisco IOS Release 12.1(3)T.
Usage Guidelines
Use the debugl2relaypackets 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 debugl2relayevents command.
Normally you will not need to use the debugl2relaypacketsor debugl2relayevents command. If problems with the SGSN are encountered, Cisco technical support personnel may request that you issue the command.
Caution
Because the debugl2relaypacketscommand generates a significant amount of output, use it only when traffic on the GPRS network is low, so other activity on the system is not adversely affected.
Examples
The following example enables the display of Layer 2 Relay packets:
Router# debug l2relay packets
Related Commands
Command
Description
debugipigmp
Displays Layer 2 Relay events (SGSN D-node only).
debug l2tp
To enable debugging of Layer 2 Tunneling Protocol (L2TP) information, use the debugl2tpcommand in privileged EXEC mode. To disable L2TP debugging, use the no form of this command.
This command was integrated into Cisco IOS Release 12.2(33)SRB.
12.2(33)SB
This command was integrated into Cisco IOS Release 12.2(33)SB.
15.0(1)M
This command was modified. The application and brief keywords were added.
15.0(1)S
This command was modified. The snmp and route keywords were added.
Usage Guidelines
Use the debugl2tp command to troubleshoot L2TP operations.
Examples
The following example shows how to enable L2TP debugging:
Router> enable
Router# debug l2tp all
L2TP most commonly used debugs debugging is on
Router# debug l2tp application
L2TP application debugs debugging is on
Router# debug l2tp brief
L2TP brief, one line debugs debugging is on
Router# debug l2tp db lookup
L2TP database lookups debugging is on
Router# debug l2tp error
L2TP errors debugging is on
Router# debug l2tp seq
L2TP sequencing debugging is on
Router# debug l2tp snmp
L2TP SNMP events debugging is on
The following sample output of the showdebugging command displays the debugs enabled for L2TP. The field descriptions are self-explanatory.
Router# show debugging
L2TP:
L2TP packet events debugging is on
L2TP packet errors debugging is on
L2TP packet detail debugging is on
L2TP errors debugging is on
L2TP events debugging is on
L2TP L2TUN socket API debugging is on
L2TP sequencing debugging is on
L2TP export data to applications and cli debugging is on
L2TP route watch debugging is on
L2TP timers debugging is on
L2TP brief, one line debugs debugging is on
L2TP application debugs debugging is on
L2TP database lookups debugging is on
L2TP SNMP events debugging is on
Related Commands
Command
Description
showdebugging
Displays information about the types of debugging that are enabled for your router.
debug l2tp redundancy
To enable the display of information on Layer 2 Tunneling Protocol (L2TP) sessions that contain redundancy status, use the
debugl2tpredundancycommand in user or privileged EXEC mode. To disable this debugging, use the
no form of this command.
This command was introduced in Cisco IOS XE Release 2.2.
Usage Guidelines
Use the
debugl2tpredundancycommand in privileged EXEC mode to display a list of redundancy events and errors.
Use the
showl2tpredundancycommand in privileged EXEC mode to display information on the state of the Layer 2 Tunneling Protocol (L2TP) or a specific L2TP session redundancy data.
Examples
The following example shows how to display a debug of redundancy events during the setup and termination of an L2TP High Availability (HA) tunnel for a L2TP Network Server (LNS) active Route Processor (RP):
LNS1> debugenable
LNS1# debugl2tpredundancycf
L2TP redundancy cf debugging is on
LNS1# debugl2tpredundancydetail
L2TP redundancy details debugging is on
LNS1# debugl2tpredundancyerror
L2TP redundancy errors debugging is on
LNS1# debugl2tpredundancyevent
L2TP redundancy events debugging is on
LNS1# debugl2tpredundancyfsm
L2TP redundancy fsm debugging is on
LNS1# debugl2tpredundancyresync
L2TP redundancy resync debugging is on
LNS1# debugl2tpredundancyrf
L2TP redundancy rf debugging is on
LNS1#
*Aug 26 18:00:00.467: %SYS-5-CONFIG_I: Configured from console by console
LNS1#
*Aug 26 18:00:45.631: L2TP tnl 01000:________: CCM initialized CCM session
*Aug 26 18:00:45.631: : L2TP HA:CC playback chkpt skipped, CC not doing HA
*Aug 26 18:00:45.711: : L2TP HA FSM:Receive proto FSM event 19
*Aug 26 18:00:45.711: : L2TP HA FSM:Receive RxSCCRQ
*Aug 26 18:00:45.711: : L2TP HA:lcm_cc alloc: l2tp_cc 070B45B8, lcm_cc 02FE55E8
*Aug 26 18:00:45.711: : L2TP HA FSM:FSM-CC ev Rx-SCCRQ
*Aug 26 18:00:45.711: : L2TP HA FSM:FSM-CC Idle->Wt-ChkptSidRmt
*Aug 26 18:00:45.711: : L2TP HA FSM:FSM-CC do Block-Tx-AckSCCRQ
*Aug 26 18:00:45.711: : L2TP HA FSM:Checkpoint Two Cc IDs
*Aug 26 18:00:45.711: L2TP HA CF: Chkpt send: s/c id 0/52631, BothCcId, seq 0, ns/nr 0/0, rid 51583, len 52; flush = 1, ctr 1
*Aug 26 18:00:45.711: 01000:0000CD97: L2TP HA:Enqueue peer Ns 0 to ns_q, seq 1 (q sz 0)
*Aug 26 18:00:45.711: L2TP tnl 01000:0000CD97: Encoding SCCRQ-IN CHKPT
*Aug 26 18:00:45.711: L2TP tnl 01000:0000CD97: Tx CHKPT
*Aug 26 18:00:45.739: L2TP tnl 01000:0000CD97: Encoding SCCRP-OUT CHKPT
*Aug 26 18:00:45.739: L2TP tnl 01000:0000CD97: Tx CHKPT
*Aug 26 18:00:45.739: : L2TP HA:Adjust local window size to 10
*Aug 26 18:00:45.739: 01000:0000CD97: L2TP HA FSM:Receive proto TxCM event SCCRP
*Aug 26 18:00:45.739: : L2TP HA FSM:Receive TxSCCRP
LNS1#
*Aug 26 18:00:45.739: : L2TP HA FSM:FSM-CC ev Tx-SCCRP
*Aug 26 18:00:45.739: : L2TP HA FSM:FSM-CC Wt-ChkptSidRmt->WtCcIdRmt2
*Aug 26 18:00:45.739: : L2TP HA FSM:FSM-CC do Block-Tx-SCCRP
*Aug 26 18:00:45.739: 01000:0000CD97: L2TP HA FSM:Found blocked RxSCCRQ, seq_num 1
*Aug 26 18:00:45.739: 01000:0000CD97: L2TP HA FSM:Queued SCCRP to CC hold_q
*Aug 26 18:00:46.863: : L2TP HA FSM:CHKPT status callback: status 0, len 56
*Aug 26 18:00:46.863: : L2TP HA FSM:Context s/c id 0/52631, BothCcId, seq 1, ns/nr 0/0, rid 51583, len 52
*Aug 26 18:00:46.863: L2TP HA CF: Rcvd status s/c id 0/52631, BothCcId, seq 1, ns/nr 0/0, rid 51583, len 52
*Aug 26 18:00:46.863: L2TP HA CF: Rcvd status 0: len 56
*Aug 26 18:00:46.863: L2TP HA CF: Status content s/c id 0/52631, BothCcId, seq 1, ns/nr 0/0, rid 51583, len 52
*Aug 26 18:00:46.863: 01000:0000CD97: L2TP HA FSM:Recv chkpt ack: s/c id 0/52631, BothCcId, seq 1, ns/nr 0/0, rid 51583, len 52
*Aug 26 18:00:46.863: : L2TP HA FSM:Receive CC-ChkptAck
*Aug 26 18:00:46.863: : L2TP HA FSM:FSM-CC ev Rx-CkpACK-CcID-Rmt
*Aug 26 18:00:46.863: : L2TP HA FSM:FSM-CC WtCcIdRmt2->Wt-RxSccn
*Aug 26 18:00:46.863: : L2TP HA FSM:FSM-CC do Allow-Tx-SCCRP2
*Aug 26 18:00:46.863: : L2TP HA FSM:Received Chkpt of local + remote CC ID
*Aug 26 18:00:46.863: 01000:0000CD97: L2TP HA:Try to remove from CC's ns_q: seq num 1 (current Ns 1)
*Aug 26 18:00:46.863: 01000:0000CD97: L2TP HA:Ns entry to remove: found (current Ns 1)
*Aug 26 18:00:46.863: 01000:0000CD97: L2TP HA:Advance peer Nr to 1 (ns_q sz 0)
*Aug 26 18:00:46.863: 01000:0000CD97: L2TP HA:CC send all unblocked if can
LNS1#
*Aug 26 18:00:46.863: 01000:0000CD97: L2TP HA:CC send one blocked CM (SCCRP): ns 0 (0), nr 1
*Aug 26 18:00:46.863: L2TP HA CF: O SCCRP 51583/0 ns/nr 0/1
*Aug 26 18:00:47.867: 01000:0000CD97: L2TP HA FSM:Receive Cm-Ack
*Aug 26 18:00:47.867: 01000:0000CD97: L2TP HA FSM:Receive CC Cm-Ack
*Aug 26 18:00:47.867: : L2TP HA FSM:FSM-CC ev Rx-CmACK
*Aug 26 18:00:47.867: : L2TP HA FSM:FSM-CC in Wt-RxSccn
*Aug 26 18:00:47.867: : L2TP HA FSM:FSM-CC do Ignore
*Aug 26 18:00:47.867: 01000:0000CD97: L2TP HA FSM:Ignore event
*Aug 26 18:00:47.867: 01000:0000CD97: L2TP HA FSM:Check for Ns/Nr update 1, peer 1
*Aug 26 18:00:47.867: 01000:0000CD97: L2TP HA FSM:Receive peer Ns/Nr update (1,0/1,1, int 1, rx 1, 1) (ns_q sz 0)
*Aug 26 18:00:47.867: 01000:0000CD97: L2TP HA FSM:Peer Ns 1 (1), Nr 1 (ns_q sz 0)
*Aug 26 18:00:48.087: 01000:0000CD97: L2TP HA FSM:Check for Ns/Nr update 1, peer 1
*Aug 26 18:00:48.087: 01000:0000CD97: L2TP HA FSM:Receive peer Ns/Nr update (1,0/1,1, int 1, rx 1, 1) (ns_q sz 0)
*Aug 26 18:00:48.087: 01000:0000CD97: L2TP HA FSM:Peer Ns 1 (2), Nr 1 (ns_q sz 0)
*Aug 26 18:00:48.087: : L2TP HA FSM:Receive proto FSM event 21
*Aug 26 18:00:48.087: 01000:0000CD97: L2TP HA FSM:Receive RxSCCCN
*Aug 26 18:00:48.087: : L2TP HA FSM:FSM-CC ev Rx-SCCCN
*Aug 26 18:00:48.087: : L2TP HA FSM:FSM-CC Wt-RxSccn->WtCcsUp
*Aug 26 18:00:48.087: : L2TP HA FSM:FSM-CC do Allow-Tx-AckSCCCN
*Aug 26 18:00:48.087: 01000:0000CD97: L2TP HA FSM:Allow TxSCCCN-ACK
*Aug 26 18:00:48.087: 01000:0000CD97: L2TP HA FSM:Receive CcUp
*Aug 26 18:00:48.087: : L2TP HA FSM:FSM-CC ev Proto CcUp
*Aug 26 18:00:48.087: : L2TP HA FSM:FSM-CC WtCcsUp->Wt-CkptCcUp
*Aug 26 18:00:48.087: : L2TP HA FSM:FSM-CC do Chkpt-CcUp2
*Aug 26 18:00:48.087: : L2TP HA FSM:Checkpoint CcUp
*Aug 26 18:00:48.087: L2TP HA CF: Chkpt send: s/c id 0/52631, CcUp, seq 0, ns/nr 1/1, rid 0, len 52; flush = 1, ctr 2
*Aug 26 18:00:48.091: L2TP tnl 01000:0000CD97: CCM added sync data
*Aug 26 18:00:48.095: 01000:0000CD97: L2TP HA FSM:Check for Ns/Nr update 2, peer 1
*Aug 26 18:00:48.095: 01000:0000CD97: L2TP HA FSM:Receive peer Ns/Nr update (2,1/1,1, int 2, rx 1, 2) (ns_q sz 0)
*Aug 26 18:00:48.095: 01000:0000CD97: L2TP HA FSM:Peer Ns 2 (3), Nr 1 (ns_q sz 0)
*Aug 26 18:00:48.095: L2TP _____:01000:000036F8: Encoding ICRQ-IN CHKPT
*Aug 26 18:00:48.095: L2TP _____:01000:000036F8: Tx CHKPT
*Aug 26 18:00:48.095: : L2TP HA FSM:Receive proto FSM event 3
*Aug 26 18:00:48.095: : L2TP HA FSM:Receive RxICRQ
*Aug 26 18:00:48.095: _____:01000:000036F8: L2TP HA FSM: Using ICRQ FSM
*Aug 26 18:00:48.095: _____:01000:000036F8: L2TP HA FSM:FSM-Sn ev created
*Aug 26 18:00:48.095: _____:01000:000036F8: L2TP HA FSM:FSM-Sn Init->Idle
*Aug 26 18:00:48.095: _____:01000:000036F8: L2TP HA FSM:FSM-Sn do none
*Aug 26 18:00:48.095: _____:01000:000036F8: L2TP HA FSM:FSM-Sn ev Rx-xCRQ
*Aug 26 18:00:48.095: _____:01000:000036F8: L2TP HA FSM:FSM-Sn Idle->Wt-ChkptSidRmt
*Aug 26 18:00:48.095: _____:01000:000036F8: L2TP HA FSM:FSM-Sn do Block-Tx-AckXCRQ
*Aug 26 18:00:48.095: _____:01000:000036F8: L2TP HA FSM:Checkpoint TwoSessionIDs
*Aug 26 18:00:48.095: L2TP HA CF: Chkpt send: s/c id 14072/52631, BothSesId, seq 0, ns/nr 1/2, rid 40276, len 52; flush = 1, ctr 3
*Aug 26 18:00:48.095: _____:01000:000036F8: L2TP HA:Enqueue peer Ns 2 to ns_q, seq 3 (q sz 0)
*Aug 26 18:00:48.131: : L2TP HA:Try to buffer sock msg type 19
*Aug 26 18:00:48.131: : L2TP HA:Buffering skipped
*Aug 26 18:00:48.131: L2TP _____:01000:000036F8: Encoding ICRP-OUT CHKPT
*Aug 26 18:00:48.131: L2TP _____:01000:000036F8: Tx CHKPT
*Aug 26 18:00:48.131: 01000:0000CD97: L2TP HA FSM:Receive proto TxCM event ICRP
*Aug 26 18:00:48.131: _____:_____:000036F8: L2TP HA FSM:Receive TxICRP
*Aug 26 18:00:48.131: _____:01000:000036F8: L2TP HA FSM:FSM-Sn ev Tx-xCRP
*Aug 26 18:00:48.131: _____:01000:000036F8: L2TP HA FSM:FSM-Sn Wt-ChkptSidRmt->Wt-SesIdRmt2
*Aug 26 18:00:48.131: _____:01000:000036F8: L2TP HA FSM:FSM-Sn do Block-Tx-xCRP
*Aug 26 18:00:48.131: _____:01000:000036F8: L2TP HA FSM:Found blocked RxICRQ, seq_num 3
LNS1#
*Aug 26 18:00:48.131: _____:01000:000036F8: L2TP HA FSM:Queued xCRP to session hold_q
*Aug 26 18:00:48.131: : L2TP HA:Try to buffer sock msg type 23
*Aug 26 18:00:48.131: : L2TP HA:CC not in resync state, buffering skipped
*Aug 26 18:00:49.115: 01000:0000CD97: L2TP HA FSM:Check for Ns/Nr update 2, peer 1
*Aug 26 18:00:49.115: 01000:0000CD97: L2TP HA FSM:Receive peer Ns/Nr update (2,2/1,1, int 3, rx 1, 3) (ns_q sz 1)
*Aug 26 18:00:49.211: : L2TP HA FSM:CHKPT status callback: status 0, len 56
*Aug 26 18:00:49.211: : L2TP HA FSM:Context s/c id 0/52631, CcUp, seq 2, ns/nr 1/1, rid 0, len 52
*Aug 26 18:00:49.211: : L2TP HA FSM:CHKPT status callback: status 0, len 56
*Aug 26 18:00:49.211: : L2TP HA FSM:Context s/c id 14072/52631, BothSesId, seq 3, ns/nr 1/2, rid 40276, len 52
*Aug 26 18:00:49.211: L2TP HA CF: Rcvd status s/c id 0/52631, CcUp, seq 2, ns/nr 1/1, rid 0, len 52
*Aug 26 18:00:49.211: L2TP HA CF: Rcvd status 0: len 56
*Aug 26 18:00:49.211: L2TP HA CF: Status content s/c id 0/52631, CcUp, seq 2, ns/nr 1/1, rid 0, len 52
*Aug 26 18:00:49.211: 01000:0000CD97: L2TP HA FSM:Recv chkpt ack: s/c id 0/52631, CcUp, seq 2, ns/nr 1/1, rid 0, len 52
*Aug 26 18:00:49.211: : L2TP HA FSM:Receive CC-ChkptAck
*Aug 26 18:00:49.211: : L2TP HA FSM:FSM-CC ev Rx-CkpACK-CcUp
*Aug 26 18:00:49.211: : L2TP HA FSM:FSM-CC Wt-CkptCcUp->ProcCcsUp
*Aug 26 18:00:49.211: : L2TP HA FSM:FSM-CC do Proc-ChpACK-CcUp2
*Aug 26 18:00:49.211: : L2TP HA FSM:Received chkpt ACK of CcUp
*Aug 26 18:00:49.211: L2TP HA CF: Rcvd status s/c id 14072/52631, BothSesId, seq 3, ns/nr 1/2, rid 40276, len 52
*Aug 26 18:00:49.211: L2TP HA CF: Rcvd status 0: len 56
*Aug 26 18:00:49.211: L2TP HA CF: Status content s/c id 14072/52631, BothSesId, seq 3, ns/nr 1/2, rid 40276, len 52
*Aug 26 18:00:49.211: 01000:0000CD97: L2TP HA FSM:Recv chkpt ack: s/c id 14072/52631, BothSesId, seq 3, ns/nr 1/2, rid 40276, len 52
*Aug 26 18:00:49.211: _____:_____:000036F8: L2TP HA FSM:Receive Session-ChkptAck
*Aug 26 18:00:49.211: _____:01000:000036F8: L2TP HA FSM:FSM-Sn ev Rx-CktACK-SesID-Rmt
*Aug 26 18:00:49.211: _____:01000:000036F8: L2TP HA FSM:FSM-Sn Wt-SesIdRmt2->Wt-RxXccn
*Aug 26 18:00:49.211: _____:01000:000036F8: L2TP HA FSM:FSM-Sn do Allow-Tx-xCRP
*Aug 26 18:00:49.211: 01000:0000CD97: L2TP HA:Try to remove from CC's ns_q: seq num 3 (current Ns 3)
*Aug 26 18:00:49.211: _____:01000:000036F8: L2TP HA:Ns entry to remove: found (current Ns 3)
*Aug 26 18:00:49.211: _____:01000:000036F8: L2TP HA:Advance peer Nr to 3 (ns_q sz 0)
*Aug 26 18:00:49.211: _____:01000:000036F8: L2TP HA:Session send all unblocked
*Aug 26 18:00:49.211: 01000:0000CD97: L2TP HA:CC send if can (ICRP): ns 1 (1, 1), nr 3 (3)
*Aug 26 18:00:49.211: L2TP HA CF: O ICRP 51583/40276 ns/nr 1/3
*Aug 26 18:00:49.231: 01000:0000CD97: L2TP HA FSM:Receive Cm-Ack
*Aug 26 18:00:49.231: _____:_____:000036F8: L2TP HA FSM:Receive session Cm-Ack
LNS1#
*Aug 26 18:00:49.231: _____:01000:000036F8: L2TP HA FSM:FSM-Sn ev Rx-CmACK
*Aug 26 18:00:49.231: _____:01000:000036F8: L2TP HA FSM:FSM-Sn in Wt-RxXccn
*Aug 26 18:00:49.231: _____:01000:000036F8: L2TP HA FSM:FSM-Sn do Ignore
*Aug 26 18:00:49.231: _____:01000:000036F8: L2TP HA FSM:Ignore event
*Aug 26 18:00:49.231: 01000:0000CD97: L2TP HA FSM:Check for Ns/Nr update 3, peer 2
*Aug 26 18:00:49.231: 01000:0000CD97: L2TP HA FSM:Receive peer Ns/Nr update (3,2/2,2, int 3, rx 2, 3) (ns_q sz 0)
*Aug 26 18:00:49.231: 01000:0000CD97: L2TP HA FSM:Peer Ns 3 (3), Nr 2 (ns_q sz 0)
LNS1#
*Aug 26 18:00:50.407: 01000:0000CD97: L2TP HA FSM:Check for Ns/Nr update 3, peer 2
*Aug 26 18:00:50.407: 01000:0000CD97: L2TP HA FSM:Receive peer Ns/Nr update (3,2/2,2, int 3, rx 2, 3) (ns_q sz 0)
*Aug 26 18:00:50.407: 01000:0000CD97: L2TP HA FSM:Peer Ns 3 (4), Nr 2 (ns_q sz 0)
*Aug 26 18:00:50.407: : L2TP HA FSM:Receive proto FSM event 5
*Aug 26 18:00:50.407: _____:_____:000036F8: L2TP HA FSM:Receive RxICCN
*Aug 26 18:00:50.407: _____:01000:000036F8: L2TP HA FSM:FSM-Sn ev Rx-xCCN
*Aug 26 18:00:50.407: _____:01000:000036F8: L2TP HA FSM:FSM-Sn Wt-RxXccn->Wt-SessUp
*Aug 26 18:00:50.407: _____:01000:000036F8: L2TP HA FSM:FSM-Sn do Allow-Tx-AckXCCN
*Aug 26 18:00:50.407: _____:01000:000036F8: L2TP HA FSM:Allow TxICCN-ACK
*Aug 26 18:00:50.407: L2TP _____:01000:000036F8: Encoding ICCN-IN CHKPT
*Aug 26 18:00:50.407: L2TP _____:01000:000036F8: Tx CHKPT
*Aug 26 18:00:50.407: _____:_____:000036F8: L2TP HA FSM:Receive SessionUp
*Aug 26 18:00:50.407: _____:01000:000036F8: L2TP HA FSM:FSM-Sn ev Proto SessUp
*Aug 26 18:00:50.407: _____:01000:000036F8: L2TP HA FSM:FSM-Sn Wt-SessUp->Wt-CkptSesUp
*Aug 26 18:00:50.407: _____:01000:000036F8: L2TP HA FSM:FSM-Sn do Chkpt-SesUp2
*Aug 26 18:00:50.407: _____:01000:000036F8: L2TP HA FSM:Checkpoint SessionUP
*Aug 26 18:00:50.407: L2TP HA CF: Chkpt send: s/c id 14072/52631, SesUp, seq 0, ns/nr 2/3, rid 0, len 52; flush = 1, ctr 4
*Aug 26 18:00:51.055: : L2TP HA FSM:CHKPT status callback: status 0, len 56
*Aug 26 18:00:51.055: : L2TP HA FSM:Context s/c id 14072/52631, SesUp, seq 4, ns/nr 2/3, rid 0, len 52
*Aug 26 18:00:51.055: L2TP HA CF: Rcvd status s/c id 14072/52631, SesUp, seq 4, ns/nr 2/3, rid 0, len 52
*Aug 26 18:00:51.055: L2TP HA CF: Rcvd status 0: len 56
*Aug 26 18:00:51.055: L2TP HA CF: Status content s/c id 14072/52631, SesUp, seq 4, ns/nr 2/3, rid 0, len 52
*Aug 26 18:00:51.055: 01000:0000CD97: L2TP HA FSM:Recv chkpt ack: s/c id 14072/52631, SesUp, seq 4, ns/nr 2/3, rid 0, len 52
*Aug 26 18:00:51.055: _____:_____:000036F8: L2TP HA FSM:Receive Session-ChkptAck
*Aug 26 18:00:51.055: _____:01000:000036F8: L2TP HA FSM:FSM-Sn ev Rx-CktACK-SesUp
*Aug 26 18:00:51.055: _____:01000:000036F8: L2TP HA FSM:FSM-Sn Wt-CkptSesUp->Proc-SessUp
*Aug 26 18:00:51.055: _____:01000:000036F8: L2TP HA FSM:FSM-Sn do Proc-ChpACK-SesUp
*Aug 26 18:00:51.055: _____:01000:000036F8: L2TP HA FSM:Received chkpt ACK of SessionUP
*Aug 26 18:00:51.347: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up
LNS1#
*Aug 26 18:00:51.635: : L2TP HA:Try to buffer sock msg type 26
*Aug 26 18:00:51.635: : L2TP HA:CC not in resync state, buffering skipped
*Aug 26 18:00:51.659: : L2TP HA:Try to buffer sock msg type 26
*Aug 26 18:00:51.659: : L2TP HA:CC not in resync state, buffering skipped
LNS1#
*Aug 26 18:00:52.363: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up
LNS1#
LNS1# clearl2tpall
Proceed with clearing all tunnels? [confirm]
LNS1#
*Aug 26 18:01:21.271: 00001:_____:000036F8: L2TP HA FSM:Receive Session-CC-Rm
*Aug 26 18:01:21.271: 00001:_____:000036F8: L2TP HA FSM:Receive SessionRm
*Aug 26 18:01:21.271: 01000:0000CD97: L2TP HA FSM:Receive proto TxCM event StopCCN
*Aug 26 18:01:21.271: 01000:0000CD97: L2TP HA FSM:Receive TxSTOPCCN
*Aug 26 18:01:21.271: : L2TP HA FSM:FSM-CC ev Tx-STOPCCN
*Aug 26 18:01:21.271: : L2TP HA FSM:FSM-CC ProcCcsUp->Wt-CkptCcDn
*Aug 26 18:01:21.271: : L2TP HA FSM:FSM-CC do Chkpt-CcDwn
*Aug 26 18:01:21.271: 01000:0000CD97: L2TP HA FSM:Receive TxSTOPCCN while CC up
*Aug 26 18:01:21.271: 01000:0000CD97: L2TP HA:CC ns_q cleanup: overall head Ns old/new = 4/4 (Q sz 0)
LNS1#
*Aug 26 18:01:21.271: : L2TP HA FSM:Checkpoint CCDown
*Aug 26 18:01:21.271: L2TP HA CF: Chkpt send: s/c id 0/52631, CcDwn, seq 0, ns/nr 2/3, rid 0, len 52; flush = 1, ctr 5
*Aug 26 18:01:21.271: 01000:0000CD97: L2TP HA FSM:Queued STOPCCN to cc hold_q
*Aug 26 18:01:21.295: : L2TP HA:Try to buffer sock msg type 22
*Aug 26 18:01:21.295: : L2TP HA:Buffering skipped
*Aug 26 18:01:22.423: : L2TP HA FSM:CHKPT status callback: status 0, len 56
*Aug 26 18:01:22.423: : L2TP HA FSM:Context s/c id 0/52631, CcDwn, seq 5, ns/nr 2/3, rid 0, len 52
*Aug 26 18:01:22.423: L2TP HA CF: Rcvd status s/c id 0/52631, CcDwn, seq 5, ns/nr 2/3, rid 0, len 52
*Aug 26 18:01:22.423: L2TP HA CF: Rcvd status 0: len 56
*Aug 26 18:01:22.423: L2TP HA CF: Status content s/c id 0/52631, CcDwn, seq 5, ns/nr 2/3, rid 0, len 52
*Aug 26 18:01:22.423: 01000:0000CD97: L2TP HA FSM:Recv chkpt ack: s/c id 0/52631, CcDwn, seq 5, ns/nr 2/3, rid 0, len 52
*Aug 26 18:01:22.423: : L2TP HA FSM:Receive CC-ChkptAck
*Aug 26 18:01:22.423: : L2TP HA FSM:FSM-CC ev Rx-CkpACK-CcDwn
*Aug 26 18:01:22.423: : L2TP HA FSM:FSM-CC Wt-CkptCcDn->Wt-RxStopAck
*Aug 26 18:01:22.423: : L2TP HA FSM:FSM-CC do Allow-Tx-STOPCCN4
*Aug 26 18:01:22.423: : L2TP HA FSM:Received Chkpt of CC removal
*Aug 26 18:01:22.423: 01000:0000CD97: L2TP HA:Try to remove from CC's ns_q: seq num 5 (current Ns 4)
*Aug 26 18:01:22.423: 01000:0000CD97: L2TP HA:Ns entry to remove: not found (current Ns 4)
*Aug 26 18:01:22.423: 01000:0000CD97: L2TP HA:CC send all unblocked if can
*Aug 26 18:01:22.423: 01000:0000CD97: L2TP HA:CC send one blocked CM (SCCRP): ns 2 (2), nr 4
*Aug 26 18:01:22.451: 01000:0000CD97: L2TP HA FSM:Receive Cm-Ack
*Aug 26 18:01:22.451: 01000:0000CD97: L2TP HA FSM:Receive CC Cm-Ack
*Aug 26 18:01:22.451: : L2TP HA FSM:FSM-CC ev Rx-CmACK
*Aug 26 18:01:22.451: : L2TP HA FSM:FSM-CC Wt-RxStopAck->Wt-CkptCcRm
*Aug 26 18:01:22.451: : L2TP HA FSM:FSM-CC do ChkptCcRm3
*Aug 26 18:01:22.451: : L2TP HA FSM:Received STOPCCN-ACK while waiting for it, checkpoint CCRm and remove cc
*Aug 26 18:01:22.451: 01000:0000CD97: L2TP HA:CC ns_q cleanup: overall head Ns old/new = 4/4 (Q sz 0)
*Aug 26 18:01:22.451: 01000:0000CD97: L2TP HA FSM:Checkpoint CcRm
*Aug 26 18:01:22.451: L2TP HA CF: Chkpt send: s/c id 0/52631, CcRm, seq 0, ns/nr 3/3, rid 0, len 52; flush = 1, ctr 6
*Aug 26 18:01:22.451: 01000:0000CD97: L2TP HA FSM:Check for Ns/Nr update 4, peer 3
*Aug 26 18:01:22.451: 01000:0000CD97: L2TP HA FSM:Receive peer Ns/Nr update (4,3/3,3, int 4, rx 3, 4) (ns_q sz 0)
*Aug 26 18:01:22.451: 01000:0000CD97: L2TP HA FSM:Peer Ns 4 (4), Nr 3 (ns_q sz 0)
*Aug 26 18:01:22.451: 01000:0000CD97: L2TP HA FSM:Receive CC-Rm
*Aug 26 18:01:22.451: : L2TP HA FSM:FSM-CC ev Proto CcRm
*Aug 26 18:01:22.451: : L2TP HA FSM:FSM-CC Wt-CkptCcRm->End
*Aug 26 18:01:22.451: : L2TP HA FSM:FSM-CC do RmCc3
*Aug 26 18:01:22.451: 01000:0000CD97: L2TP HA FSM:CC destruction after Tx/Rx StopCCN
LNS1#
*Aug 26 18:01:22.451: 01000:0000CD97: L2TP HA:CC ns_q cleanup: overall head Ns old/new = 4/4 (Q sz 0)
*Aug 26 18:01:22.451: : L2TP HA FSM:Checkpoint CCRm
*Aug 26 18:01:22.451: L2TP HA CF: Chkpt send: s/c id 0/52631, CcRm, seq 0, ns/nr 3/3, rid 0, len 52; flush = 1, ctr 7
*Aug 26 18:01:22.451: : L2TP HA:lcm_cc free: l2tp_cc 070B45B8, lcm_cc 02FE55E8
*Aug 26 18:01:22.451: L2TP tnl _____:________: CCM setting state to DOWN
*Aug 26 18:01:23.571: : L2TP HA FSM:CHKPT status callback: status 0, len 56
*Aug 26 18:01:23.571: : L2TP HA FSM:Context s/c id 0/52631, CcRm, seq 6, ns/nr 3/3, rid 0, len 52
*Aug 26 18:01:23.571: : L2TP HA FSM:CHKPT status callback: status 0, len 56
*Aug 26 18:01:23.571: : L2TP HA FSM:Context s/c id 0/52631, CcRm, seq 7, ns/nr 3/3, rid 0, len 52
*Aug 26 18:01:23.571: L2TP HA CF: Rcvd status s/c id 0/52631, CcRm, seq 6, ns/nr 3/3, rid 0, len 52
*Aug 26 18:01:23.571: L2TP HA CF: Rcvd status 0: len 56
*Aug 26 18:01:23.571: L2TP HA CF: Status content s/c id 0/52631, CcRm, seq 6, ns/nr 3/3, rid 0, len 52
*Aug 26 18:01:23.571: : L2TP HA FSM:Ignore chkpt ACK: CC not found.
LNS1#
*Aug 26 18:01:23.571: L2TP HA CF: Rcvd status s/c id 0/52631, CcRm, seq 7, ns/nr 3/3, rid 0, len 52
*Aug 26 18:01:23.571: L2TP HA CF: Rcvd status 0: len 56
*Aug 26 18:01:23.571: L2TP HA CF: Status content s/c id 0/52631, CcRm, seq 7, ns/nr 3/3, rid 0, len 52
*Aug 26 18:01:23.571: : L2TP HA FSM:Ignore chkpt ACK: CC not found.
LNS1#
*Aug 26 18:01:35.771: %REDUNDANCY-3-STANDBY_LOST: Standby processor fault (PEER_DOWN_INTERRUPT)
The table below describes the significant fields shown in the
debugl2tpredundancy command output.
Table 18 debug l2tp redundancy Command Field Descriptions
Field
Description
cf
Number of L2TP checkpointing-facility events (cf-events).
error
Number of L2TP checkpointing errors.
event
Number of L2TP checkpointing events.
fsm
Number of L2TP checkpointing fsm events.
resync
Number of L2TP checkpointing resynchronized events.
rf
Number of L2TP checkpointing redundancy-facility events (rf-events).
Related Commands
Command
Description
debugvpdnredundancy
Displays information about VPDN sessions that have redundancy events and errors.
l2tp sso enable
Enables L2TP HA.
l2tp tunnel resync
Specifies the number of packets sent before waiting for an acknowledgment message.
To debug errors and events that occur on the Layer 2 VPN (L2VPN) attachment circuits (the circuits between the provider edge [PE] and customer edge [CE] devices), use the
debugl2vpn acircuit command in privileged EXEC mode. To disable debugging, use the
no form of this command.
Displays errors that occur in attachment circuits.
event
Displays events that occur in attachment circuits.
event-trace
Displays event trace logs.
number
Number of event trace logs to be stored per context.
preserve
Specifies that the event trace logs should not be removed.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
Cisco IOS XE Release 3.7S
This command was introduced as part of the Multiprotocol Label Switching (MPLS)-based L2VPN command modifications for cross-OS support. This command will replace the
debug acircuit command in future releases.
15.3(1)S
This command was integrated in Cisco IOS Release 15.3(1)S.
Usage Guidelines
Use the
debugl2vpn acircuit command to identify provisioning events, setup failures, circuit up and down events, and configuration failures on attachment circuits.
An attachment circuit connects a PE device to a CE device. A device can have many attachment circuits. The attachment circuit manager controls all attachment circuits from one central location. Therefore, when you enable debug messages for an attachment circuit, you receive information about all attachment circuits.
Examples
The following is sample output from the
debugacircuitevent command when an interface is enabled:
Device# debug l2vpn acircuit event
*Jan 28 15:19:03.070: ACLIB: ac_cstate() Handling circuit UP for interface Se2/0
*Jan 28 15:19:03.070: ACLIB [10.0.1.1, 200]: pthru_intf_handle_circuit_up() calling
acmgr_circuit_up
*Jan 28 15:19:03.070: ACLIB [10.0.1.1, 200]: Setting new AC state to Ac-Connecting
*Jan 28 15:19:03.070: ACMGR: Receive <Circuit Up> msg
*Jan 28 15:19:03.070: Se2/0 ACMGR: circuit up event, SIP state chg down to connecting,
action is service request
*Jan 28 15:19:03.070: Se2/0 ACMGR: Sent a sip service request
*Jan 28 15:19:03.070: ACLIB [10.0.1.1, 200]: AC updating switch context.
*Jan 28 15:19:03.070: Se2/0 ACMGR: Rcv SIP msg: resp connect forwarded, hdl 9500001D,
l2ss_hdl 700001E
*Jan 28 15:19:03.070: Se2/0 ACMGR: service connected event, SIP state chg connecting to
connected, action is respond forwarded
*Jan 28 15:19:03.070: ACLIB: pthru_intf_response hdl is 9500001D, response is 1
*Jan 28 15:19:03.070: ACLIB [10.0.1.1, 200]: Setting new AC state to Ac-Connected
The following is sample output from the
debugl2vpn acircuitevent command when an interface is disabled:
Device# debug l2vpn acircuit event
*Jan 28 15:25:57.014: ACLIB: SW AC interface INTF-DOWN for interface Se2/0
*Jan 28 15:25:57.014: ACLIB [10.0.1.1, 200]: Setting new AC state to Ac-Idle
*Jan 28 15:25:57.014: ACLIB: SW AC interface INTF-DOWN for interface Se2/0
*Jan 28 15:25:57.014: Se2/0 ACMGR: Receive <Circuit Down> msg
*Jan 28 15:25:57.014: Se2/0 ACMGR: circuit down event, SIP state chg connected to end,
action is service disconnect
*Jan 28 15:25:57.014: Se2/0 ACMGR: Sent a sip service disconnect
*Jan 28 15:25:57.014: ACLIB [10.0.1.1, 200]: AC deleting switch context.
*Jan 28 15:25:59.014: %LINK-5-CHANGED: Interface Serial2/0, changed state to
administratively down
*Jan 28 15:25:59.014: ACLIB: ac_cstate() Handling circuit DOWN for interface Se2/0
*Jan 28 15:26:00.014:%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/0, changed state to down
The following example shows output from the
debug l2vpn acircuit command for an xconnect session on a GigabitEthernet interface:
Device# debug l2vpn acircuit
23:28:35: ACLIB [10.0.3.201, 5]: SW AC interface UP for GigabitEthernet interface GE2/1/1
23:28:35: ACLIB [10.0.3.201, 5]: pthru_intf_handle_circuit_up() calling acmgr_circuit_up
23:28:35: ACLIB [10.0.3.201, 5]: Setting new AC state to Ac-Connecting
23:28:35: ACLIB [10.0.3.201, 5]: SW AC interface UP for GigabitEthernet interface GE2/1/1
23:28:35: ACLIB [10.0.3.201, 5]: pthru_intf_handle_circuit_up() ignoring up event. Already connected or connecting.
23:28:35: ACMGR: Receive <Circuit Up> msg
23:28:35: GE2/1/1 ACMGR: circuit up event, SIP state chg down to connecting, action is service request
23:28:35: GE2/1/1 ACMGR: Sent a sip service request
23:28:37: %LINK-3-UPDOWN: Interface GigabitEthernet2/1/1, changed state to up
23:28:38: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/1/1, changed state to up
23:28:53: GE2/1/1 ACMGR: Rcv SIP msg: resp connect forwarded, hdl D6000002, sss_hdl 9E00000F
23:28:53: GE2/1/1 ACMGR: service connected event, SIP state chg connecting to connected, action is respond forwarded
23:28:53: ACLIB: pthru_intf_response hdl is D6000002, response is 1
23:28:53: ACLIB [10.0.3.201, 5]: Setting new AC state to Ac-Connected
The command output is self-explanatory.
Related Commands
Command
Description
debug acircuit
Debugs errors and events that occur on the attachment circuits.
debugvpdn
Debugs errors and events relating to L2TP configuration and the surrounding Layer 2 tunneling infrastructure.
debugxconnect
Debugs errors and events related to an xconnect configuration.
debug l2vpn atom checkpoint
To enable the debugging of Any Transport over MPLS (AToM) events when AToM is configured for nonstop forwarding/stateful switchover (NSF/SSO) and graceful restart, use the
debug l2vpn atom checkpoint
command in privileged EXEC mode. To disable the debugging of these messages, use the
no form of this command.
debugl2vpnatomcheckpoint
nodebugl2vpnatomcheckpoint
Syntax Description
This command has no arguments or keywords.
Command Default
Debugging of the AToM NSF/SSO and graceful restart is disabled.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
Cisco IOS XE Release 3.7S
This command was introduced as part of the Multiprotocol Label Switching (MPLS)-based Layer 2 VPN (L2VPN) command modifications for cross-OS support. This command will replace the
debug mpls l2transport checkpoint command in future releases.
15.3(1)S
This command was integrated in Cisco IOS Release 15.3(1)S.
Usage Guidelines
Debug commands use a significant amount of CPU time and can affect system performance.
Examples
In the following example, the output shows that NSF/SSO and graceful restart synchronize the data between the active and backup Route Processors (RP) after an AToM virtual circuit (VC) is created. (Both
debug l2vpn atom checkpoint and
debugl2vpnacircuitcheckpoint commands are enabled in this example.)
The
debug l2vpn atom checkpoint command is enabled on the active RP:
Device# debug l2vpn atom checkpoint
Device# debug l2vpn acircuit checkpoint
AToM HA:
AToM checkpointing events and errors debugging is on
AC HA:
Attachment Circuit Checkpoint debugging is on
AToM HA [10.55.55.2, 1002]: Build provision msg, SSM sw/seg 8192/8194 [0x2000/0x2002] PW id 9216 [0x2400] local label 21
AC HA: Dynamic Sync. Event:4 Sw:8192[2000] Se:16385[4001]
AToM HA: CF sync send complete
AC HA CF: Sync send complete. Code:0
On the standby RP, the following messages indicate that it receives checkpointing data:
AC HA [10.55.55.2, 1002]: Add to WaitQ. Flags:1
AToM HA [105.55.55.2, 1002]: Received 32-byte provision version 1 CF message
AC HA CF: ClientId:89, Entity:0 Length:40
AToM HA [10.55.55.2, 1002]: Process chkpt msg provision [1], ver 1
AToM HA [10.55.55.2, 1002]: Reserved SSM sw/seg 8192/8194 [0x2000/0x2002] PW id 9216 [0x2400]
AC HA: Process Msg:35586. Ptr:44CBFD90. Val:0
AC HA: Sync. Event:4 CktType:4 Sw:8192[2000] Se:16385[4001]
AC HA [10.55.55.2, 1002]: Remove from WaitQ. Flags:1[OK][OK]
During a switchover from the active to the backup RP, the following debug messages are displayed:
%HA-5-MODE: Operating mode is hsa, configured mode is sso.
AC HA RF: CId:83, Seq:710, Sta:RF_STATUS_OPER_REDUNDANCY_MODE_CHANGE, Opr:5, St:STANDBY HOT, PSt:ACTIVE
AToM HA: CID 84, Seq 715, Status RF_STATUS_OPER_REDUNDANCY_MODE_CHANGE, Op 5, State STANDBY HOT, Peer ACTIVE
AC HA RF: CId:83, Seq:710, Sta:RF_STATUS_PEER_PRESENCE, Opr:0, St:STANDBY HOT, PSt:ACTIVE
AToM HA: CID 84, Seq 715, Status RF_STATUS_PEER_PRESENCE, Op 0, State STANDBY HOT, Peer ACTIVE
AC HA RF: CId:83, Seq:710, Sta:RF_STATUS_PEER_COMM, Opr:0, St:STANDBY HOT, PSt:DISABLED
AToM HA: CID 84, Seq 715, Status RF_STATUS_PEER_COMM, Op 0, State STANDBY HOT, Peer DISABLED
%HA-2-CUTOVER_NOTICE: Cutover initiated. Cease all console activity until system restarts.
%HA-2-CUTOVER_NOTICE: Do not add/remove RSPs or line cards until switchover completes.
%HA-2-CUTOVER_NOTICE: Deinitializing subsystems...
%OIR-6-REMCARD: Card removed from slot 4, interfaces disabled
%OIR-6-REMCARD: Card removed from slot 5, interfaces disabled
%OIR-6-REMCARD: Card removed from slot 9, interfaces disabled
%HA-2-CUTOVER_NOTICE: Reinitializing subsystems...
%HA-2-CUTOVER_NOTICE: System preparing to restart...
%HA-5-NOTICE: Resuming initialization...
AC HA RF: CId:83, Seq:710, Sta:RF_STATUS_REDUNDANCY_MODE_CHANGE, Opr:7, St:STANDBY HOT, PSt:DISABLED
.
.
.
%LDP-5-GR: LDP restarting gracefully. Preserving forwarding state for 250 seconds.
AC HA RF: CId:83, Seq:710, Sta:RF_PROG_ACTIVE, Opr:0, St:ACTIVE, PSt:DISABLED
AToM HA: CID 84, Seq 715, Event RF_PROG_ACTIVE, Op 0, State ACTIVE, Peer DISABLED
AC HA: Process Msg:35588. Ptr:0. Val:0
AC HA: Switchover: Standby->Active
AC HA RF: Reconciling
Related Commands
Command
Description
debugl2vpn acircuitcheckpoint
Enables the debugging of AToM attachment circuit events when AToM is configured for NSF/SSO and graceful restart.
debugmpls l2transportcheckpoint
Enables the debugging of AToM events when AToM is configured for NSF/SSO and graceful restart.
debug l2vpn atom event-trace
To enable debugging of event trace information for Layer 2 VPN (L2VPN) Any Transport over MPLS (AToM), use the
debugl2vpn atom event-trace command in privileged EXEC mode. To disable debugging output, use the
no form of this command.
debugl2vpn atom
{ event-tracenumber
[ preserve ] }
nodebugl2vpn atom
{ event-tracenumber
[ preserve ] }
Syntax Description
number
Number of event trace logs to be stored per context.
preserve
(Optional) Specifies that the event trace logs should not be removed.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
Cisco IOS XE Release 3.7S
This command was introduced as part of the Multiprotocol Label Switching (MPLS)-based L2VPN command modifications for cross-OS support. This command will replace the
debug mpls l2transport event-trace
command in future releases.
15.3(1)S
This command was integrated in Cisco IOS Release 15.3(1)S.
Usage Guidelines
The
debug l2vpn atom event-trace command does not produce any output of its own. Instead, it affects the size of the event-trace buffer for Any Transport over MPLS (AToM) events.
Examples
The following is sample output from the
debugl2vpn atomevent-trace command:
Device# debug l2vpn atom event-trace
AToM LDP event-trace debugging is on
Related Commands
Command
Description
debug mpls l2transport event-trace
Enables debugging of event trace information for MPLS Layer 2 transport events.
debug l2vpn atom fast-failure-detect
To enable the debugging of Layer 2 VPN (L2VPN) Any Transport over MPLS (AToM) fast failure detection, use the
debug l2vpn atom fast-failure-detect command in privileged EXEC mode. To disable the debugging, use the
no form of this command.
debugl2vpnatomfast-failure-detect
nodebugl2vpnatomfast-failure-detect
Syntax Description
This command has no arguments or keywords.
Command Default
Debugging of L2VPN fast failure detection is disabled.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
Cisco IOS XE Release 3.7S
This command was introduced as part of the Multiprotocol Label Switching (MPLS)-based L2VPN command modifications for cross-OS support. This command will replace the
debug mpls l2transport fast-failure-detect command in future releases.
15.3(1)S
This command was integrated in Cisco IOS Release 15.3(1)S.
Examples
The following example shows how to enable L2VPN AToM fast failure detection:
Device# debug l2vpn atom fast-failure-detect
========= Line Card (Slot 3) =========
AToM fast failure detect debugging is on
00:03:28: AToM FFD[10.1.1.2]: Sending type: BFD, adjacency: DOWN, local: 10.1.1.1
00:03:28: AToM FFD[10.1.1.2]: ADJ_DOWN, local: 10.1.1.1
00:03:28: AToM FFD[10.1.1.2, 100]: ADJ_DOWN
Related Commands
Command
Description
debug mpls l2transport fast-failure-detection
Enables the debugging of fast failure detection.
debug l2vpn atom signaling
To enable debugging of Layer 2 VPN (L2VPN) Any Transport over MPLS (AToM) signaling protocol information, use the
debug l2vpn atom signaling command in privileged EXEC mode. To disable debugging, use the
no form of this command.
This command was introduced as part of the Multiprotocol Label Switching (MPLS)-based L2VPN command modifications for cross-OS support. This command will replace the
debug mpls l2transport signaling command in future releases.
15.3(1)S
This command was integrated in Cisco IOS Release 15.3(1)S.
Examples
The following is sample output from the
debug l2vpn atom signaling command:
Device# debug l2vpn atom signaling event
AToM LDP event debugging is on
Device# debug l2vpn atom signaling message
AToM LDP message debugging is on
AToM:
AToM LDP event debugging is on
AToM LDP message debugging is on
*Mar 24 23:10:55.611: AToM LDP [10.9.9.9]: Allocate LDP instance
*Mar 24 23:10:55.611: AToM LDP [10.9.9.9]: Opening session, 1 clients
*Mar 24 23:10:56.063: %SYS-5-CONFIG_I: Configured from console by console
*Mar 24 23:10:56.583: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/0, changed state to up
*Mar 24 23:11:00.539: AToM LDP [10.9.9.9]: Session is up
*Mar 24 23:11:00.539: AToM LDP [10.9.9.9]: Peer address change, add 10.1.1.100
*Mar 24 23:11:00.539: AToM LDP [10.9.9.9]: Peer address change, add 10.1.1.6
*Mar 24 23:11:00.539: AToM LDP [10.9.9.9]: Peer address change, add 10.9.9.9
*Mar 24 23:11:00.539: AToM LDP [10.9.9.9]: Peer address change, add 10.1.1.6
*Mar 24 23:11:00.539: AToM LDP [10.9.9.9]: Sending label mapping msg
vc type 7, cbit 1, vc id 50, group id 6, vc label 21, status 0, mtu 1500
*Mar 24 23:11:00.539: AToM LDP [10.9.9.9]: Received label mapping msg, id 113
vc type 7, cbit 1, vc id 50, group id 6, vc label 21, status 0, mtu 1500
Related Commands
Command
Description
debug mpls l2transport signaling
Displays information about the AToM signaling protocol.
debug l2vpn atom static-oam
To enable the debugging of messages related to static operations administrative and management (OAM), use the
debug l2vpn atom static-oam command in privileged EXEC mode. To disable the debugging of these messages, use the
no form of this command.
Displays logging messages for static pseudowire OAM.
error
Displays error messages for static pseudowire OAM.
event
Displays event messages for static pseudowire OAM.
fsm
Displays finite state machine (FSM) messages for static pseudowire OAM.
Command Default
Display of static pseudowire messages is not disabled.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
Cisco IOS XE Release 3.7S
This command was introduced as part of the Multiprotocol Label Switching (MPLS)-based Layer 2 VPN (L2VPN) command modifications for cross-OS support. This command will replace the
debug mpls l2transport static-oam command in future releases.
15.3(1)S
This command was integrated in Cisco IOS Release 15.3(1)S.
Usage Guidelines
The
debug l2vpn atom static-oam error does not produce any output of its own. Instead, it affects the size of the event-trace buffer for Any Transport over MPLS (AToM) events.
Examples
The following example enables the display of error messages for static pseudowire OAM:
Device# debug l2vpn atom static-oam error
Static PW OAM events debugging is on
Related Commands
Command
Description
debug mpls l2transport static-oam
Enables the debugging of messages related to static pseudowire operations OAM.
showl2vpnatomstatic-oam
Displays the status of static pseudowires.
debug l2vpn atom vc
To enable debugging of status of the Layer 2 VPN (L2VPN) Any Transport over MPLS (AToM) virtual circuits (VCs), use the
debug l2vpn atom vc command in privileged EXEC mode. To disable debugging, use the
no form of this command.
Displays debug information related to the finite state machine (FSM).
ldp
Displays debug information related to the Label Distribution Protocol (LDP).
subscriber
Displays debug information related to the L2VPN subscriber.
status
Displays debug information related to the status of VCs.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
Cisco IOS XE Release 3.7S
This command was introduced as part of the Multiprotocol Label Switching (MPLS)-based L2VPN command modifications for cross-OS support. This command will replace the
debug mpls l2transport vc command in future releases.
15.3(1)S
This command was integrated in Cisco IOS Release 15.3(1)S.
Usage Guidelines
You can issue this command from the line card or the Route Processor (RP).
Examples
The following is sample output from the
debug l2vpn atom vc event and
debug l2vpn atom vc fsm commands:
Device# debug l2vpn atom vc event
AToM vc event debugging is on
Device# debug l2vpn atom vc fsm
AToM vc fsm debugging is on
AToM:
AToM vc event debugging is on
AToM vc fsm debugging is on
*Mar 24 23:17:24.371: AToM MGR [10.9.9.9, 50]: Event provision, state changed from idle to provisioned
*Mar 24 23:17:24.371: AToM MGR [10.9.9.9, 50]: Provision vc
*Mar 24 23:17:24.371: AToM SMGR [10.9.9.9, 50]: Requesting VC create, vc_handle 61A09930
*Mar 24 23:17:24.371: AToM MGR [10.9.9.9, 50]: Event local up, state changed from provisioned to local standby
*Mar 24 23:17:24.371: AToM MGR [10.9.9.9, 50]: Update local vc label binding
*Mar 24 23:17:24.371: AToM SMGR [10.9.9.9, 50]: successfully processed create request
*Mar 24 23:17:24.875: %SYS-5-CONFIG_I: Configured from console by console
*Mar 24 23:17:25.131: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/0, changed state to up
*Mar 24 23:17:28.567: AToM MGR [10.9.9.9, 50]: Event ldp up, state changed from local standby to local ready
*Mar 24 23:17:28.567: AToM MGR [10.9.9.9, 50]: Advertise local vc label binding
*Mar 24 23:17:28.567: AToM MGR [10.9.9.9, 50]: Event remote up, state changed from local ready to establishing
*Mar 24 23:17:28.567: AToM MGR [10.9.9.9, 50]: Remote end up
*Mar 24 23:17:28.567: AToM MGR [10.9.9.9, 50]: Event remote validated, state changed from establishing to established
*Mar 24 23:17:28.567: AToM MGR [10.9.9.9, 50]: Validate vc, activating data plane
*Mar 24 23:17:28.567: AToM SMGR [10.9.9.9, 50]: Processing imposition update, vc_handle 61A09930, update_action 3, remote_vc_label 21
*Mar 24 23:17:28.567: AToM SMGR [10.9.9.9, 50]: Imposition Programmed, Output Interface: PO5/0
*Mar 24 23:17:28.567: AToM SMGR [10.9.9.9, 50]: Processing disposition update, vc_handle 61A09930, update_action 3, local_vc_label 22
*Mar 24 23:17:28.571: AToM SMGR: Processing TFIB event for 10.9.9.9
*Mar 24 23:17:28.571: AToM SMGR [10.9.9.9, 50]: Imposition Programmed, Output Interface: PO5/0
The following is sample output of MPLS pseudowire status signaling messages from the
debugl2vpnatomvcstatusevent and
debugl2vpnatomvcstatusfsm commands:
Device# debug l2vpn atom vc status event
Device# debug l2vpn atom vc status fsm
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: Receive SSS STATUS(UP)
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: AC status UP
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: S:Evt local up, LndRru->LnuRru
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: S:Evt local ready, LnuRru->LruRru
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: S:Act send label(UP)
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: Send label(UP)
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: Local AC : UP
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: Dataplane: no fault
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: Overall : no fault
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: Remote label is ready
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: S:Evt remote ready in LruRru
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: S:Evt remote up in LruRru
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: S:Evt dataplane clear fault in LruRru
*Feb 26 14:03:42.543: AToM MGR [10.9.9.9, 100]: S:Evt dataplane clear fault in LruRru
*Feb 26 14:03:42.551: AToM MGR [10.9.9.9, 100]: S:Evt dataplane clear fault in LruRru
The status codes in the messages, such as S and LruRru, indicate the status of the local and remote devices. The following is the list status codes displayed in the output:
L—local router
R—remote router
r or n—ready (r) or not ready (n)
u or d—up (u) or down (d) status
The output also includes the following values:
D—Dataplane
S—Local shutdown
Related Commands
Command
Description
debug mpls l2transport vc
Enables debugging of the AToM VCs.
debug l2vpn atom vc vccv
To enable Layer 2 VPN (L2VPN) Any Transport over MPLS (AToM) Virtual Circuit Connection Verification (VCCV) debugging, use the
debug l2vpn atom vc vccv command in privileged EXEC mode. To disable debugging, use the
no form of this command.
debug l2vpn atom vc vccv [bfd] event
nodebug l2vpn atom vc vccv [bfd] event
Syntax Description
bfd
(Optional) Displays event messages when Bidirectional Forwarding Detection (BFD) sessions are created, when BFD sends dataplane fault notifications to L2VPN, and when L2VPN sends the attachment circuit (AC) signaling status to BFD.
event
Displays AToM event messages about the VCCV.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
Cisco IOS XE Release 3.7S
This command was introduced as part of the Multiprotocol Label Switching (MPLS)-based L2VPN command modifications for cross-OS support. This command will replace the
debug mpls l2transport vc vccv command in future releases.
15.3(1)S
This command was integrated in Cisco IOS Release 15.3(1)S.
Usage Guidelines
Use this command to enable L2VPN AToM VCCV events and AToM VCCV BFD events debugging.
Examples
The following example shows how to enable MPLS L2VPN virtual circuit (VC) VCCV BFD event debugging:
Device# debug l2vpn atom vc vccv bfd event
AToM VCCV BFD events debugging is on
Aug 10 16:55:41.492: AToM VCCV BFD[10.1.1.2, 1234000]: ......... context not found
*Aug 10 16:55:41.492: AToM VCCV BFD[10.1.1.2, 1234000]: ......... context not found
*Aug 10 16:55:41.492: AToM VCCV BFD[10.1.1.2, 1234000]: ............ context not found
*Aug 10 16:55:41.492: AToM VCCV BFD[10.1.1.2, 1234000]: ....... context not found
*Aug 10 16:55:41.493: AToM VCCV BFD[10.1.1.2, 1234000]: .. Session create
*Aug 10 16:55:41.493: AToM VCCV BFD[10.1.1.2, 1234000]: .. next-hop 2.1.1.2:1
*Aug 10 16:55:41.493: AToM VCCV BFD[10.1.1.2, 1234000]: .. cc_type 1
*Aug 10 16:55:41.493: AToM VCCV BFD[10.1.1.2, 1234000]: .. cv_type 5
*Aug 10 16:55:41.493: AToM VCCV BFD[10.1.1.2, 1234000]: .. CC control word enabled
*Aug 10 16:55:41.493: AToM VCCV BFD[10.1.1.2, 1234000]: .. CV Fault Detection and Signaling without IP/UDP headers
*Aug 10 16:55:41.500: AToM VCCV BFD[10.1.1.2, 1234000]: .. create 00000001/2A98A72F40
*Aug 10 16:55:41.500: AToM VCCV BFD[10.1.1.2, 1234000]: .. lookup added 00000001
*Aug 10 16:55:42.315: AToM VCCV BFD[10.1.1.2, 1234000]: session 00000001 ADJ UP
*Aug 10 16:55:42.315: AToM VCCV BFD[10.1.1.2, 1234000]: inform BFD, status UP, event 1
*Aug 10 16:55:42.315: AToM VCCV BFD[10.1.1.2, 1234000]: Start VCCV BFD status timer
*Aug 10 16:55:45.374: AToM VCCV BFD[10.1.1.2, 1234000]: VCCV BFD status timer expired
*Aug 10 16:55:45.374: AToM VCCV BFD[10.1.1.2, 1234000]: session 00000001 BFD STATUS UP
Related Commands
Command
Description
debug mpls l2transport vc vccv
Enables AToM VCCV debugging
showmplsl2transportvc
Displays information about the status of the AToM VCs.
debug l2vpn pseudowire
To enable debugging information for Layer 2 VPN (L2VPN) pseudowire configuration, use the
debugl2vpnpseudowire command in privileged EXEC mode. To disable debugging output, use the
no form of this command.
debugl2vpnpseudowire
{ event | error }
nodebugl2vpnpseudowire
{ event | error }
Syntax Description
event
Displays debugging information for L2VPN pseudowire events.
error
Displays debugging information for L2VPN pseudowire errors.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
Cisco IOS XE Release 3.7S
This command was introduced as part of the Multiprotocol Label Switching (MPLS)-based L2VPN command modifications for cross-OS support.
15.3(1)S
This command was integrated into Cisco IOS release 15.3(1)S.
Examples
The following is sample output from the
debug l2vpn pseudowire event command:
Device# debug l2vpn pseudowire event
L2VPN pseudowire events debugging is on.
*Aug 10 17:52:22.896: Pseudowire[ps1]: PW interface not yet in a L2VPN service, ignore [no]shutdown
*Aug 10 17:52:25.851: Pseudowire[pw1]: Pseudowire interface: peer id 10.0.0.0 not configured
*Aug 10 17:52:25.851: Pseudowire[pw1]: Pseudowire interface config still incomplete, skip update to xconnect db
*Aug 10 17:52:33.727: PWCFG WAVL Event: Updating pwid: 10002 peer: 10.1.1.2 vcid: 1234000
*Aug 10 17:52:33.727: PWCFG WAVL Event: pwid: 10002 alloc peer 10.1.1.2 vcid: 1234000
*Aug 10 17:52:33.727: Pseudowire[pw1]: Pseudowire interface not yet associated with a L2VPN service
debug l2vpn vfi
To enable debugging layer 2 VPN (L2VPN) virtual forwarding instance (VFI) events and errors, use the
debugl2vpn
vfi command in privileged EXEC mode. To disable debugging of VFI events and errors, use the
no form of this command.
debugl2vpnvfi
[ fsm ]
{ error | event }
nodebugl2vpnvfi
[ fsm ]
{ error | event }
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
Cisco IOS XE Release 3.7S
This command was introduced. This command will replace the
debug vfi command in future releases.
15.3(1)S
This command was integrated in Cisco IOS Release 15.3(1)S.
Examples
The following is sample output from the
debugl2vpn vfi command:
Device# debug l2vpn vfi
Related Commands
Command
Description
debug vfi
Enables debugging VFI events and errors.
debug l2vpn xconnect
To enable the debugging information about a Layer 2 VPN (L2VPN) xconnect configuration, use the
debugl2vpn xconnect
command in privileged EXEC mode. To disable debugging, use the
no form of this command.
Displays errors related to an xconnect configuration.
event
Displays events related to an xconnect configuration.
detail
(Optional) Displays the xconnect detailed debugging information.
initialization
Displays information about xconnect initialization events.
internal
Displays information about xconnect internal events.
monitor
Displays debugging information about xconnect peer monitoring debugs.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
Cisco IOS XE Release 3.7S
This command was introduced as part of the Multiprotocol Label Switching (MPLS)-based L2VPN command modifications for cross-OS support. This command will replace the
debug xconnect command in future releases.
15.3(1)S
This command was integrated in Cisco IOS Release 15.3(1)S.
Examples
The following is sample output from the
debugl2vpn xconnect command for an xconnect session on a Gigabit Ethernet interface:
Device# debug l2vpn xconnect event
00:01:16: XC AUTH [Gi2/1/1, 5]: Event: start xconnect authorization, state changed from IDLE to AUTHORIZING
00:01:16: XC AUTH [Gi2/1/1, 5]: Event: found xconnect authorization, state changed from AUTHORIZING to DONE
00:01:16: XC AUTH [Gi2/1/1, 5]: Event: free xconnect authorization request, state changed from DONE to END
Related Commands
Command
Description
debugxconnect
Enables the debugging information for an xconnect configuration.
debug l3-mgr tunnel
To enable debugging for interface, tunnel, or VLAN events for the Layer 3 manager infrastructure on RP of Cisco 7600 routers, use the debug l3-mgr tunnel command. To disable the debugging, use the no form of the command.
debugl3-mgrtunnel
nodebugl3-mgrtunnel
Syntax Description
l3-mgr
Displays debugging output for the Layer 3 manager infrastructure on Cisco 7600 routers.
tunnel
Displays all tunnel related reserved VLAN events.
Command Default
None
Command Modes
Privileged EXEC
Command History
Release
Modification
15.3(2)S
This command was introduced on Cisco 7600 series routers.
Usage Guidelines
Use the debug command only to troubleshoot specific problems, or during troubleshooting sessions with Cisco technical support staff.
Examples
The following shows sample output for the debug l3-mgr tunnel command:
To enable troubleshooting for Layer 4 Forwarding (L4F) flows, use the debugl4f command in privileged EXEC mode. To disable the troubleshooting, use the no form of this command.
Use this command to enable debugging for Layer 4 forwarding flows.
Examples
The following example shows how to enable debugging for L4F packets:
Router# debug l4f packet all
Related Commands
Command
Description
showl4f
Displays the flow database for L4F.
debug lacp
To enable debugging of all Link Aggregation Control Protocol (LACP) activity, use the debuglacpcommand in privileged EXEC mode. To disable LACP debugging, use the no form of this command.
Effective with Cisco IOS Release 15.1M, the debuglaneclient command is not available in Cisco IOS software.
To display information about a LAN Emulation Client (LEC), use the debuglaneclient command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debuglaneclient
{ all | le-arp | mpoa | packet | signaling | state | topology }
[ interfaceinterface ]
nodebuglaneclient
{ all | le-arp | mpoa | packet | signaling | state | topology }
[ interfaceinterface ]
Syntax Description
all
Displays all debug information related to the LEC.
le-arp
Displays debug information related to the LAN Emulation (LANE) Address Resolution Protocol (ARP) table.
mpoa
Displays debug information to track the following:
MPOA specific TLV information in le-arp requests/responses
Elan-id and local segment TLV in lane control frames
When a LANE client is bound to an MPC/MPS
packet
Displays debug information about each packet.
signaling
Displays debug information related to client switched virtual circuits (SVCs).
state
Displays debug information when the state changes.
topology
Displays debug information related to the topology of the emulated LAN (ELAN).
interfaceinterface
(Optional) Limits the debugging output to messages that relate to a particular interface or subinterface. If you enter this command multiple times with different interfaces, the last interface entered will be the one used to filter the messages.
Command Default
If the interface number is not specified, the default will be the number of all the mpoalane clients.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.0(1)T
This command was introduced.
15.1M
This command was removed.
Usage Guidelines
The debuglaneclientall command can generate a large amount of output. Use a limiting keyword or specify a subinterface to decrease the amount of output and focus on the information you need.
Examples
The following example shows output for debuglaneclientpacket and debuglaneclientstate commands for an LEC joining an ELAN named elan1:
Router# debug lane client packet
Router# debug lane client state
The LEC listens for signaling calls to its ATM address (Initial State):
LEC ATM2/0.1: sending LISTEN
LEC ATM2/0.1: listen on 39.020304050607080910111213.00000CA05B40.01
LEC ATM2/0.1: received LISTEN
The LEC calls the LAN Emulation Configuration Server (LECS) and attempts to set up the Configure Direct VC (LECS Connect Phase):
LEC ATM2/0.1: sending SETUP
LEC ATM2/0.1: callid 0x6114D174
LEC ATM2/0.1: called party 39.020304050607080910111213.00000CA05B43.00
LEC ATM2/0.1: calling_party 39.020304050607080910111213.00000CA05B40.01
The LEC receives a CONNECT response from the LECS. The Configure Direct VC is established:
The LEC sends a CONFIG REQUEST to the LECS on the Configure Direct VC (Configuration Phase):
LEC ATM2/0.1: sending LANE_CONFIG_REQ on VCD 148
LEC ATM2/0.1: SRC MAC address 0000.0ca0.5b40
LEC ATM2/0.1: SRC ATM address 39.020304050607080910111213.00000CA05B40.01
LEC ATM2/0.1: LAN Type 2
LEC ATM2/0.1: Frame size 2
LEC ATM2/0.1: LAN Name elan1
LEC ATM2/0.1: LAN Name size 5
The LEC receives a CONFIG RESPONSE from the LECS on the Configure Direct VC:
LEC ATM2/0.1: received LANE_CONFIG_RSP on VCD 148
LEC ATM2/0.1: SRC MAC address 0000.0ca0.5b40
LEC ATM2/0.1: SRC ATM address 39.020304050607080910111213.00000CA05B40.01
LEC ATM2/0.1: LAN Type 2
LEC ATM2/0.1: Frame size 2
LEC ATM2/0.1: LAN Name elan1
LEC ATM2/0.1: LAN Name size 5
A CONNECT_ACK is received from the ATM switch. The Control Distribute VC is established:
LEC ATM2/0.1: received CONNECT_ACK
The LEC receives a JOIN response from the LES on the Control Direct VC.
LEC ATM2/0.1: received LANE_JOIN_RSP on VCD 150
LEC ATM2/0.1: Status 0
LEC ATM2/0.1: LECID 1
LEC ATM2/0.1: SRC MAC address 0000.0ca0.5b40
LEC ATM2/0.1: SRC ATM address 39.020304050607080910111213.00000CA05B40.01
LEC ATM2/0.1: LAN Type 2
LEC ATM2/0.1: Frame size 2
LEC ATM2/0.1: LAN Name elan1
LEC ATM2/0.1: LAN Name size 5
The LEC sends an LE ARP request to the LES to obtain the broadcast and unknown server (BUS) ATM NSAP address (BUS connect):
A CONNECT_ACK is received from the ATM switch. The Multicast Forward VC is established:
LEC ATM2/0.1: received CONNECT_ACK
The LEC moves into the OPERATIONAL state.
%LANE-5-UPDOWN: ATM2/0.1 elan elan1: LE Client changed state to up
The following output is from the showlaneclient command after the LEC joins the emulated LAN as shown in the debuglaneclient output:
Router# show lane client
LE Client ATM2/0.1 ELAN name: elan1 Admin: up State: operational
Client ID: 1 LEC up for 1 minute 2 seconds
Join Attempt: 1
HW Address: 0000.0ca0.5b40 Type: token ring Max Frame Size: 4544
Ring:1 Bridge:1 ELAN Segment ID: 2048
ATM Address: 39.020304050607080910111213.00000CA05B40.01
VCD rxFrames txFrames Type ATM Address
0 0 0 configure 39.020304050607080910111213.00000CA05B43.00
142 1 2 direct 39.020304050607080910111213.00000CA05B41.01
143 1 0 distribute 39.020304050607080910111213.00000CA05B41.01
145 0 0 send 39.020304050607080910111213.00000CA05B42.01
146 1 0 forward 39.020304050607080910111213.00000CA05B42.01
The following example shows debuglaneclient all command output when an interface with LECS, an LES/BUS, and an LEC is shut down:
Router# debug lane client all
LEC ATM1/0.2: received RELEASE_COMPLETE
LEC ATM1/0.2: callid 0x60E8B474
LEC ATM1/0.2: cause code 0
LEC ATM1/0.2: action A_PROCESS_REL_COMP
LEC ATM1/0.2: action A_TEARDOWN_LEC
LEC ATM1/0.2: sending RELEASE
LEC ATM1/0.2: callid 0x60EB6160
LEC ATM1/0.2: cause code 31
LEC ATM1/0.2: sending RELEASE
LEC ATM1/0.2: callid 0x60EB7548
LEC ATM1/0.2: cause code 31
LEC ATM1/0.2: sending RELEASE
LEC ATM1/0.2: callid 0x60EB9E48
LEC ATM1/0.2: cause code 31
LEC ATM1/0.2: sending CANCEL
LEC ATM1/0.2: ATM address 47.00918100000000613E5A2F01.006070174820.02
LEC ATM1/0.2: state ACTIVE event LEC_SIG_RELEASE_COMP => TERMINATING
LEC ATM1/0.3: received RELEASE_COMPLETE
LEC ATM1/0.3: callid 0x60E8D108
LEC ATM1/0.3: cause code 0
LEC ATM1/0.3: action A_PROCESS_REL_COMP
LEC ATM1/0.3: action A_TEARDOWN_LEC
LEC ATM1/0.3: sending RELEASE
LEC ATM1/0.3: callid 0x60EB66D4
LEC ATM1/0.3: cause code 31
LEC ATM1/0.3: sending RELEASE
LEC ATM1/0.3: callid 0x60EB7B8C
LEC ATM1/0.3: cause code 31
LEC ATM1/0.3: sending RELEASE
LEC ATM1/0.3: callid 0x60EBA3BC
LEC ATM1/0.3: cause code 31
LEC ATM1/0.3: sending CANCEL
LEC ATM1/0.3: ATM address 47.00918100000000613E5A2F01.006070174820.03
LEC ATM1/0.3: state ACTIVE event LEC_SIG_RELEASE_COMP => TERMINATING
LEC ATM1/0.2: received RELEASE_COMPLETE
LEC ATM1/0.2: callid 0x60EB7548
LEC ATM1/0.2: cause code 0
LEC ATM1/0.2: action A_PROCESS_TERM_REL_COMP
LEC ATM1/0.2: state TERMINATING event LEC_SIG_RELEASE_COMP => TERMINATING
LEC ATM1/0.3: received RELEASE_COMPLETE
LEC ATM1/0.3: callid 0x60EB7B8C
LEC ATM1/0.3: cause code 0
LEC ATM1/0.3: action A_PROCESS_TERM_REL_COMP
LEC ATM1/0.3: state TERMINATING event LEC_SIG_RELEASE_COMP => TERMINATING
LEC ATM1/0.1: received RELEASE_COMPLETE
LEC ATM1/0.1: callid 0x60EBC458
LEC ATM1/0.1: cause code 0
LEC ATM1/0.1: action A_PROCESS_REL_COMP
LEC ATM1/0.1: action A_TEARDOWN_LEC
LEC ATM1/0.1: sending RELEASE
LEC ATM1/0.1: callid 0x60EBD30C
LEC ATM1/0.1: cause code 31
LEC ATM1/0.1: sending RELEASE
LEC ATM1/0.1: callid 0x60EBDD28
LEC ATM1/0.1: cause code 31
LEC ATM1/0.1: sending RELEASE
LEC ATM1/0.1: callid 0x60EBF174
LEC ATM1/0.1: cause code 31
LEC ATM1/0.1: sending CANCEL
LEC ATM1/0.1: ATM address 47.00918100000000613E5A2F01.006070174820.01
LEC ATM1/0.1: state ACTIVE event LEC_SIG_RELEASE_COMP => TERMINATING
LEC ATM1/0.1: received RELEASE_COMPLETE
LEC ATM1/0.1: callid 0x60EBDD28
LEC ATM1/0.1: cause code 0
LEC ATM1/0.1: action A_PROCESS_TERM_REL_COMP
LEC ATM1/0.1: state TERMINATING event LEC_SIG_RELEASE_COMP => TERMINATING
LEC ATM1/0.2: received RELEASE_COMPLETE
LEC ATM1/0.2: callid 0x60EB6160
LEC ATM1/0.2: cause code 0
LEC ATM1/0.2: action A_PROCESS_TERM_REL_COMP
LEC ATM1/0.2: state TERMINATING event LEC_SIG_RELEASE_COMP => TERMINATING
LEC ATM1/0.3: received RELEASE_COMPLETE
LEC ATM1/0.3: callid 0x60EB66D4
LEC ATM1/0.3: cause code 0
LEC ATM1/0.3: action A_PROCESS_TERM_REL_COMP
LEC ATM1/0.3: state TERMINATING event LEC_SIG_RELEASE_COMP => TERMINATING
LEC ATM1/0.2: received RELEASE_COMPLETE
LEC ATM1/0.2: callid 0x60EB9E48
LEC ATM1/0.2: cause code 0
LEC ATM1/0.2: action A_PROCESS_TERM_REL_COMP
LEC ATM1/0.2: state TERMINATING event LEC_SIG_RELEASE_COMP => IDLE
LEC ATM1/0.3: received RELEASE_COMPLETE
LEC ATM1/0.3: callid 0x60EBA3BC
LEC ATM1/0.3: cause code 0
LEC ATM1/0.3: action A_PROCESS_TERM_REL_COMP
LEC ATM1/0.3: state TERMINATING event LEC_SIG_RELEASE_COMP => IDLE
LEC ATM1/0.1: received RELEASE_COMPLETE
LEC ATM1/0.1: callid 0x60EBD30C
LEC ATM1/0.1: cause code 0
LEC ATM1/0.1: action A_PROCESS_TERM_REL_COMP
LEC ATM1/0.1: state TERMINATING event LEC_SIG_RELEASE_COMP => TERMINATING
LEC ATM1/0.1: received RELEASE_COMPLETE
LEC ATM1/0.1: callid 0x60EBF174
LEC ATM1/0.1: cause code 0
LEC ATM1/0.1: action A_PROCESS_TERM_REL_COMP
LEC ATM1/0.1: state TERMINATING event LEC_SIG_RELEASE_COMP => IDLE
LEC ATM1/0.2: received CANCEL
LEC ATM1/0.2: state IDLE event LEC_SIG_CANCEL => IDLE
LEC ATM1/0.3: received CANCEL
LEC ATM1/0.3: state IDLE event LEC_SIG_CANCEL => IDLE
LEC ATM1/0.1: received CANCEL
LEC ATM1/0.1: state IDLE event LEC_SIG_CANCEL => IDLE
LEC ATM1/0.1: action A_SHUTDOWN_LEC
LEC ATM1/0.1: sending CANCEL
LEC ATM1/0.1: ATM address 47.00918100000000613E5A2F01.006070174820.01
LEC ATM1/0.1: state IDLE event LEC_LOCAL_DEACTIVATE => IDLE
LEC ATM1/0.2: action A_SHUTDOWN_LEC
LEC ATM1/0.2: sending CANCEL
LEC ATM1/0.2: ATM address 47.00918100000000613E5A2F01.006070174820.02
LEC ATM1/0.2: state IDLE event LEC_LOCAL_DEACTIVATE => IDLE
LEC ATM1/0.3: action A_SHUTDOWN_LEC
LEC ATM1/0.3: sending CANCEL
LEC ATM1/0.3: ATM address 47.00918100000000613E5A2F01.006070174820.03
LEC ATM1/0.3: state IDLE event LEC_LOCAL_DEACTIVATE => IDLE
The following output is from the debuglaneclientmpoa command when the lane interface is shut down:
Router# debug lane client mpoa
Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#int atm 1/1/0.1
Router(config-subif)#shutdown
Router(config-subif)#
00:23:32:%LANE-5-UPDOWN:ATM1/1/0.1 elan elan2:LE Client changed state to down
00:23:32:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWN
00:23:32:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWN
Router(config-subif)#
Router(config-subif)#
Router(config-subif)#
Router(config-subif)#exit
Router(config)#exit
The following output is from the debuglaneclientmpoa command when the lane interface is started (not shut down):
Router# debug lane client mpoa
Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#int atm 1/1/0.1
Router(config-subif)#
Router(config-subif)#
Router(config-subif)#no shutdown
Router(config-subif)#
00:23:39:LEC ATM1/1/0.1:lec_process_lane_tlv:msg LANE_CONFIG_RSP, num_tlvs 14
00:23:39:LEC ATM1/1/0.1:elan id from LECS set to 300
00:23:39:LEC ATM1/1/0.1:lec_process_lane_tlv:msg LANE_JOIN_RSP, num_tlvs 1
00:23:39:LEC ATM1/1/0.1:elan id from LES set to 300
00:23:39:LEC ATM1/1/0.1:lec_append_mpoa_dev_tlv:
00:23:39:LEC ATM1/1/0.1:got mpoa client addr 47.0091810000000050E2097801.0050A
29AF42D.00
00:23:39:%LANE-5-UPDOWN:ATM1/1/0.1 elan elan2:LE Client changed state to up
00:23:39:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:UP
00:25:57:LEC ATM1/1/0.1:lec_process_lane_tlv:msg LANE_ARP_REQ, num_tlvs 1
00:25:57:LEC ATM1/1/0.1:lec_process_dev_type_tlv: lec 47.0091810000000050E
2097801.00500B306440.02
type MPS, mpc 00.000000000000000000000000.000000000000.00
mps 47.0091810000000050E2097801.00500B306444.00, num_mps_mac 1, mac 0050.0b3
0.6440
00:25:57:LEC ATM1/1/0.1:create mpoa_lec
00:25:57:LEC ATM1/1/0.1:new mpoa_lec 0x617E3118
00:25:57:LEC ATM1/1/0.1:lec_process_dev_type_tlv:type MPS, num _mps_mac
1
00:2t 5:57:LEC ATM1/1/0.1:lec_add_mps:
remote lec 47.0091810000000050E2097801.00500B306440.02
mps 47.0091810000000050E2097801.00500B306444.00 num_mps_mac 1, mac 0050.0b30
.6440
00:25:57:LEC ATM1/1/0.1:mpoa_device_change:lec_nsap 47.0091810000000050E20978
01.00500B306440.02, appl_type 5
mpoa_nsap 47.0091810000000050E2097801.00500B306444.00, opcode 4
00:25:57:LEC ATM1/1/0.1:lec_add_mps:add mac 0050.0b30.6440, mps_mac 0x617E372
C
00:25:57:LEC ATM1/1/0.1:mpoa_device_change:lec_nsap 47.0091810000000050E20978
01.00500B306440.02, appl_type 5
mpoa_nsap 47.0091810000000050E2097801.00500B306444.00, opcode 5
00:25:57:LEC ATM1/1/0.1: mps_mac 0050.0b30.6440
00:25:57:LEC ATM1/1/0.1:lec_append_mpoa_dev_tlv:
00:25:57:LEC ATM1/1/0.1:got mpoa client addr 47.0091810000000050E2097801.0050A
29AF42D.00
Router(config-subif)#exit
Router(config)#exit
The following output is from the debuglaneclientmpoa command when the ATM major interface is shut down:
Router# debug lane client mpoa
Router#
conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#int atm 1/1/0
Router(config-if)# shutdown
Router(config-if)#
00:26:28:LANE ATM1/1/0:atm hardware reset
00:26:28:%LANE-5-UPDOWN:ATM1/1/0.1 elan elan2:LE Client changed state to down
00:26:28:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWN
00:26:28:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWN
00:26:28:%MPOA-5-UPDOWN:MPC mpc2:state changed to down
00:26:28:LEC ATM1/1/0.1:mpoa_to_lec:appl 6, opcode 0
00:26:30:%LINK-5-CHANGED:Interface ATM1/1/0, changed state to administratively
down
00:26:30:LANE ATM1/1/0:atm hardware reset
00:26:31:%LINEPROTO-5-UPDOWN:Line protocol on Interface ATM1/1/0, changed stat
e to down
Router(config-if)#
00:26:31:LEC ATM1/1/0.1:mpoa_to_lec:appl 6, opcode 0
00:26:32:LANE ATM1/1/0:atm hardware reset
00:26:32:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWN
00:26:34:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWN
Router(config-if)# exit
Router(config)#
exit
The following output is from the debuglaneclientmpoa command when the ATM major interface is started:
Router# debug lane client mpoa
Router#
conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# int atm 1/1/0
Router(config-if)# no shutdown
00:26:32:LANE ATM1/1/0:atm hardware reset
00:26:32:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWN
00:26:34:%LINK-3-UPDOWN:Interface ATM1/1/0, changed state to down
00:26:34:LANE ATM1/1/0:atm hardware reset
00:26:41:%LINK-3-UPDOWN:Interface ATM1/1/0, changed state to up
00:26:42:%LINEPROTO-5-UPDOWN:Line protocol on Interface ATM1/1/0, changed stat
e to up
00:27:10:%LANE-6-INFO:ATM1/1/0:ILMI prefix add event received
00:27:10:LANE ATM1/1/0:prefix add event for 470091810000000050E2097801 ptr=0x6
17BFC0C len=13
00:27:10: the current first prefix is now:470091810000000050E2097801
00:27:10:%ATMSSCOP-5-SSCOPINIT:- Intf :ATM1/1/0, Event :Rcv End, State :Act
ive.
00:27:10:LEC ATM1/1/0.1:mpoa_to_lec:appl 6, opcode 0
00:27:10:%LANE-3-NOREGILMI:ATM1/1/0.1 LEC cannot register 47.0091810000000050E
2097801.0050A29AF428.01 with ILMI
00:27:10:%LANE-6-INFO:ATM1/1/0:ILMI prefix add event received
00:27:10:LANE ATM1/1/0:prefix add event for 470091810000000050E2097801 ptr=0x6
17B8E6C len=13
00:27:10: the current first prefix is now:470091810000000050E2097801
00:27:10:%LANE-5-UPDOWN:ATM1/1/0.1 elan elan2:LE Client changed state to down
00:27:10:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:DOWN
00:27:10:LEC ATM1/1/0.1:mpoa_to_lec:appl 6, opcode 0
00:27:10:%MPOA-5-UPDOWN:MPC mpc2:state changed to up
00:27:10:LEC ATM1/1/0.1:mpoa_to_lec:appl 6, opcode 1
00:27:12:LEC ATM1/1/0.1:lec_process_lane_tlv:msg LANE_CONFIG_RSP, num_tlvs 14
00:27:12:LEC ATM1/1/0.1:elan id from LECS set to 300
00:27:12:LEC ATM1/1/0.1:lec_process_lane_tlv:msg LANE_JOIN_RSP, num_tlvs 1
00:27:12:LEC ATM1/1/0.1:elan id from LES set to 300
00:27:12:LEC ATM1/1/0.1:lec_append_mpoa_dev_tlv:
00:27:12:LEC ATM1/1/0.1:got mpoa client addr 47.0091810000000050E2097801.0050A
29AF42D.00
00:27:12:%LANE-5-UPDOWN:ATM1/1/0.1 elan elan2:LE Client changed state to up
00:27:12:LEC ATM1/1/0.1:lec_inform_mpoa_state_chg:UP
Router(config-if)#exit
Router(config)#exit
Related Commands
Command
Description
debugmodemtraffic
Displays MPC debug information.
debugmpoaserver
Displays information about the MPOA server.
debug lane config
Note
Effective with Cisco IOS Release 15.1M, the debuglaneconfig command is not available in Cisco IOS software.
To display information about a LAN Emulation (LANE) configuration server, use the debuglaneconfig command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debuglaneconfig
{ all | events | packets }
nodebuglaneconfig
{ all | events | packets }
Syntax Description
all
Displays all debugging messages related to the LANE configuration server. The output includes both the events and packets types of output.
events
Displays only messages related to significant LANE configuration server events.
packets
Displays information on each packet sent or received by the LANE configuration server.
Command Modes
Privileged EXEC
Command History
Release
Modification
15.1M
This command was removed.
Usage Guidelines
Thedebuglaneconfig output is intended to be used primarily by a Cisco technical support representative.
Examples
The following is sample output from the debuglaneconfigallcommand when an interface with LECS, an LES/BUS, and an LEC is shut down:
Router# debug lane config all
LECS EVENT ATM1/0: processing interface down transition
LECS EVENT ATM1/0: placed de-register address 0x60E8A824 (47.00918100000000613E5A2F01.006070174823.00) request with signalling
LECS EVENT ATM1/0: ilmiDeRegisterAddress: sendSetRequestToILMI failure; interface down ?
LECS EVENT ATM1/0: placed de-register address 0x60EC4F28 (47.007900000000000000000000.00A03E000001.00) request with signalling
LECS EVENT ATM1/0: ilmiDeRegisterAddress: sendSetRequestToILMI failure; interface down ?
LECS EVENT ATM1/0: placed de-register address 0x60EC5C08 (47.00918100000000613E5A2F01.006070174823.99) request with signalling
LECS EVENT ATM1/0: ilmiDeRegisterAddress: sendSetRequestToILMI failure; interface down ?
LECS EVENT ATM1/0: tearing down all connexions
LECS EVENT ATM1/0: elan 'xxx' LES 47.00918100000000613E5A2F01.006070174821.01 callId 0x60CE0F58 deliberately being disconnected
LECS EVENT ATM1/0: sending RELEASE for call 0x60CE0F58 cause 31
LECS EVENT ATM1/0: elan 'yyy' LES 47.00918100000000613E5A2F01.006070174821.02 callId 0x60CE2104 deliberately being disconnected
LECS EVENT ATM1/0: sending RELEASE for call 0x60CE2104 cause 31
LECS EVENT ATM1/0: elan 'zzz' LES 47.00918100000000613E5A2F01.006070174821.03 callId 0x60CE2DC8 deliberately being disconnected
LECS EVENT ATM1/0: sending RELEASE for call 0x60CE2DC8 cause 31
LECS EVENT ATM1/0: All calls to/from LECSs are being released
LECS EVENT ATM1/0: placed de-register address 0x60EC4F28 (47.007900000000000000000000.00A03E000001.00) request with signalling
LECS EVENT ATM1/0: ilmiDeRegisterAddress: sendSetRequestToILMI failure; interface down ?
LECS EVENT ATM1/0: ATM_RELEASE_COMPLETE received: callId 0x60CE0F58 cause 0
LECS EVENT ATM1/0: call 0x60CE0F58 cleaned up
LECS EVENT ATM1/0: ATM_RELEASE_COMPLETE received: callId 0x60CE2104 cause 0
LECS EVENT ATM1/0: call 0x60CE2104 cleaned up
LECS EVENT ATM1/0: ATM_RELEASE_COMPLETE received: callId 0x60CE2DC8 cause 0
LECS EVENT ATM1/0: call 0x60CE2DC8 cleaned up
LECS EVENT ATM1/0: UNKNOWN/UNSET: signalling DE-registered
LECS EVENT: UNKNOWN/UNSET: signalling DE-registered
LECS EVENT ATM1/0: UNKNOWN/UNSET: signalling DE-registered
LECS EVENT ATM1/0: placed de-register address 0x60E8A824 (47.00918100000000613E5A2F01.006070174823.00) request with signalling
LECS EVENT ATM1/0: ilmiDeRegisterAddress: sendSetRequestToILMI failure; interface down ?
LECS EVENT ATM1/0: placed de-register address 0x60EC5C08 (47.00918100000000613E5A2F01.006070174823.99) request with signalling
LECS EVENT ATM1/0: ilmiDeRegisterAddress: sendSetRequestToILMI failure; interface down ?
LECS EVENT ATM1/0: tearing down all connexions
LECS EVENT ATM1/0: All calls to/from LECSs are being released
LECS EVENT: config server 56 killed
debug lane finder
Note
Effective with Cisco IOS Release 15.1M, the debuglanefindercommand is not available in Cisco IOS software.
To display information about the finder internal state machine, use the debuglanefinder command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debuglanefinder
nodebuglanefinder
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Release
Modification
15.1M
This command was removed.
Usage Guidelines
Thedebuglanefinder command output is intended to be used primarily by a Cisco technical support representative.
Examples
The following is sample output from the debuglanefinder command when an interface with LECS, LES/BUS, and LEC is shut down:
Router# debug lane finder
LECS FINDER ATM1/0.3: user request 1819 of type GET_MASTER_LECS_ADDRESS queued up
LECS FINDER ATM1/0: finder state machine started
LECS FINDER ATM1/0: time to perform a getNext on the ILMI
LECS FINDER ATM1/0: LECS 47.00918100000000613E5A2F01.006070174823.00 deleted
LECS FINDER ATM1/0: ilmi_client_request failed, answering all users
LECS FINDER ATM1/0: answering all requests now
LECS FINDER ATM1/0: responded to user request 1819
LECS FINDER ATM1/0: number of remaining requests still to be processed: 0
LECS FINDER ATM1/0.2: user request 1820 of type GET_MASTER_LECS_ADDRESS queued up
LECS FINDER ATM1/0: finder state machine started
LECS FINDER ATM1/0: time to perform a getNext on the ILMI
LECS FINDER ATM1/0: ilmi_client_request failed, answering all users
LECS FINDER ATM1/0: answering all requests now
LECS FINDER ATM1/0: responded to user request 1820
LECS FINDER ATM1/0: number of remaining requests still to be processed: 0
LECS FINDER ATM1/0.1: user request 1821 of type GET_MASTER_LECS_ADDRESS queued up
LECS FINDER ATM1/0: finder state machine started
LECS FINDER ATM1/0: time to perform a getNext on the ILMI
LECS FINDER ATM1/0: ilmi_client_request failed, answering all users
LECS FINDER ATM1/0: answering all requests now
LECS FINDER ATM1/0: responded to user request 1821
LECS FINDER ATM1/0: number of remaining requests still to be processed: 0
debug lane server
Note
Effective with Cisco IOS Release 15.1M, the debuglaneservercommand is not available in Cisco IOS software.
To display information about a LAN Emulation (LANE) server, use the debuglaneserver command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debuglaneserver
[ interfaceinterface ]
nodebuglaneserver
[ interfaceinterface ]
Syntax Description
interfaceinterface
(Optional) Limits the debugging output to messages relating to a specific interface or subinterface. If you use this command multiple times with different interfaces, the last interface entered is the one used to filter debugging messages.
Command Modes
Privileged EXEC
Command History
Release
Modification
15.1M
This command was removed.
Usage Guidelines
Thedebuglaneserver command output is intended to be used primarily by a Cisco technical support representative. The debuglaneserver command can generate a substantial amount of output. Specify a subinterface to decrease the amount of output and focus on the information you need.
Examples
The following is sample output from the debuglaneserver command when an interface with LECS, LES/BUS, and LEC is shut down:
Router# debug lane server
LES ATM1/0.1: lsv_lecsAccessSigCB called with callId 0x60CE124C, opcode ATM_RELEASE_COMPLETE
LES ATM1/0.1: disconnected from the master LECS
LES ATM1/0.1: should have been connected, will reconnect in 3 seconds
LES ATM1/0.2: lsv_lecsAccessSigCB called with callId 0x60CE29E0, opcode ATM_RELEASE_COMPLETE
LES ATM1/0.2: disconnected from the master LECS
LES ATM1/0.2: should have been connected, will reconnect in 3 seconds
LES ATM1/0.3: lsv_lecsAccessSigCB called with callId 0x60EB1940, opcode ATM_RELEASE_COMPLETE
LES ATM1/0.3: disconnected from the master LECS
LES ATM1/0.3: should have been connected, will reconnect in 3 seconds
LES ATM1/0.2: elan yyy client 1 lost control distribute
LES ATM1/0.2: elan yyy client 1: lsv_kill_client called
LES ATM1/0.2: elan yyy client 1 state change Oper -> Term
LES ATM1/0.3: elan zzz client 1 lost control distribute
LES ATM1/0.3: elan zzz client 1: lsv_kill_client called
LES ATM1/0.3: elan zzz client 1 state change Oper -> Term
LES ATM1/0.2: elan yyy client 1 lost MC forward
LES ATM1/0.2: elan yyy client 1: lsv_kill_client called
LES ATM1/0.3: elan zzz client 1 lost MC forward
LES ATM1/0.3: elan zzz client 1: lsv_kill_client called
LES ATM1/0.1: elan xxx client 1 lost control distribute
LES ATM1/0.1: elan xxx client 1: lsv_kill_client called
LES ATM1/0.1: elan xxx client 1 state change Oper -> Term
LES ATM1/0.1: elan xxx client 1 lost MC forward
LES ATM1/0.1: elan xxx client 1: lsv_kill_client called
LES ATM1/0.2: elan yyy client 1 released control direct
LES ATM1/0.2: elan yyy client 1: lsv_kill_client called
LES ATM1/0.3: elan zzz client 1 released control direct
LES ATM1/0.3: elan zzz client 1: lsv_kill_client called
LES ATM1/0.2: elan yyy client 1 MC forward released
LES ATM1/0.2: elan yyy client 1: lsv_kill_client called
LES ATM1/0.2: elan yyy client 1: freeing client structures
LES ATM1/0.2: elan yyy client 1 unregistered 0060.7017.4820
LES ATM1/0.2: elan yyy client 1 destroyed
LES ATM1/0.3: elan zzz client 1 MC forward released
LES ATM1/0.3: elan zzz client 1: lsv_kill_client called
LES ATM1/0.3: elan zzz client 1: freeing client structures
LES ATM1/0.3: elan zzz client 1 unregistered 0060.7017.4820
LES ATM1/0.3: elan zzz client 1 destroyed
LES ATM1/0.1: elan xxx client 1 released control direct
LES ATM1/0.1: elan xxx client 1: lsv_kill_client called
LES ATM1/0.1: elan xxx client 1 MC forward released
LES ATM1/0.1: elan xxx client 1: lsv_kill_client called
LES ATM1/0.1: elan xxx client 1: freeing client structures
LES ATM1/0.1: elan xxx client 1 unregistered 0060.7017.4820
LES ATM1/0.1: elan xxx client 1 destroyed
LES ATM1/0.1: elan xxx major interface state change
LES ATM1/0.1: cleanupLecsAccess: discarding all validation requests
LES ATM1/0.1: shutting down
LES ATM1/0.1: elan xxx: lsv_kill_lesbus called
LES ATM1/0.1: elan xxx: LES/BUS state change operational -> terminating
LES ATM1/0.1: cleanupLecsAccess: discarding all validation requests
LES ATM1/0.2: elan yyy major interface state change
LES ATM1/0.2: cleanupLecsAccess: discarding all validation requests
LES ATM1/0.2: shutting down
LES ATM1/0.2: elan yyy: lsv_kill_lesbus called
LES ATM1/0.2: elan yyy: LES/BUS state change operational -> terminating
LES ATM1/0.2: cleanupLecsAccess: discarding all validation requests
LES ATM1/0.3: elan zzz major interface state change
LES ATM1/0.3: cleanupLecsAccess: discarding all validation requests
LES ATM1/0.3: shutting down
LES ATM1/0.3: elan zzz: lsv_kill_lesbus called
LES ATM1/0.3: elan zzz: LES/BUS state change operational -> terminating
LES ATM1/0.3: cleanupLecsAccess: discarding all validation requests
LES ATM1/0.1: elan xxx: lsv_kill_lesbus called
LES ATM1/0.1: cleanupLecsAccess: discarding all validation requests
LES ATM1/0.1: elan xxx: lsv_kill_lesbus called
LES ATM1/0.1: cleanupLecsAccess: discarding all validation requests
LES ATM1/0.1: elan xxx: stopped listening on addresses
LES ATM1/0.1: elan xxx: all clients killed
LES ATM1/0.1: elan xxx: multicast groups killed
LES ATM1/0.1: elan xxx: addresses de-registered from ilmi
LES ATM1/0.1: elan xxx: LES/BUS state change terminating -> down
LES ATM1/0.1: elan xxx: administratively down
LES ATM1/0.2: elan yyy: lsv_kill_lesbus called
LES ATM1/0.2: cleanupLecsAccess: discarding all validation requests
LES ATM1/0.2: elan yyy: lsv_kill_lesbus called
LES ATM1/0.2: cleanupLecsAccess: discarding all validation requests
LES ATM1/0.2: elan yyy: stopped listening on addresses
LES ATM1/0.2: elan yyy: all clients killed
LES ATM1/0.2: elan yyy: multicast groups killed
LES ATM1/0.2: elan yyy: addresses de-registered from ilmi
LES ATM1/0.2: elan yyy: LES/BUS state change terminating -> down
LES ATM1/0.2: elan yyy: administratively down
LES ATM1/0.3: elan zzz: lsv_kill_lesbus called
LES ATM1/0.3: cleanupLecsAccess: discarding all validation requests
LES ATM1/0.3: elan zzz: lsv_kill_lesbus called
LES ATM1/0.3: cleanupLecsAccess: discarding all validation requests
LES ATM1/0.3: elan zzz: stopped listening on addresses
LES ATM1/0.3: elan zzz: all clients killed
LES ATM1/0.3: elan zzz: multicast groups killed
LES ATM1/0.3: elan zzz: addresses de-registered from ilmi
LES ATM1/0.3: elan zzz: LES/BUS state change terminating -> down
LES ATM1/0.3: elan zzz: administratively down
LES ATM1/0.3: cleanupLecsAccess: discarding all validation requests
LES ATM1/0.2: cleanupLecsAccess: discarding all validation requests
LES ATM1/0.1: cleanupLecsAccess: discarding all validation requests
debug lane signaling
Note
Effective with Cisco IOS Release 15.1M, the debuglanesignalingcommand is not available in Cisco IOS software.
To display information about LANE Server (LES) and Broadcast and Unknown Server (BUS) switched virtual circuits (SVCs), use thedebuglanesignaling command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debuglanesignaling
[ interfaceinterface ]
nodebuglanesignaling
[ interfaceinterface ]
Syntax Description
interfaceinterface
(Optional) Limits the debugging output to messages relating to a specific interface or subinterface. If you use this command multiple times with different interfaces, the last interface entered is the one used to filter debugging messages.
Command Modes
Privileged EXEC
Command History
Release
Modification
15.1M
This command was removed.
Usage Guidelines
Thedebuglanesignaling command output is intended to be used primarily by a Cisco technical support representative. The debuglanesignaling command can generate a substantial amount of output. Specify a subinterface to decrease the amount of output and focus on the information you need.
Examples
The following is sample output from the debuglanesignaling command when an interface with LECS, LES/BUS, and LEC is shut down:
Router# debug lane signaling
LANE SIG ATM1/0.2: received ATM_RELEASE_COMPLETE callid 0x60EB565C cause 0 lv 0x60E8D348 lvstate LANE_VCC_CONNECTED
LANE SIG ATM1/0.2: lane_sig_mc_release: breaking lv 0x60E8D348 from mcg 0x60E97E84
LANE SIG ATM1/0.2: timer for lv 0x60E8D348 stopped
LANE SIG ATM1/0.2: sent ATM_RELEASE request for lv 0x60E8D468 in state LANE_VCC_CONNECTED
LANE SIG ATM1/0.2: sent ATM_RELEASE request for lv 0x60E8D3D8 in state LANE_VCC_CONNECTED
LANE SIG ATM1/0.2: sent ATM_RELEASE request for lv 0x60E8D2B8 in state LANE_VCC_CONNECTED
LANE SIG ATM1/0.3: received ATM_RELEASE_COMPLETE callid 0x60EB5CA0 cause 0 lv 0x60E8BEF4 lvstate LANE_VCC_CONNECTED
LANE SIG ATM1/0.3: lane_sig_mc_release: breaking lv 0x60E8BEF4 from mcg 0x60E9A37C
LANE SIG ATM1/0.3: timer for lv 0x60E8BEF4 stopped
LANE SIG ATM1/0.3: sent ATM_RELEASE request for lv 0x60E8C014 in state LANE_VCC_CONNECTED
LANE SIG ATM1/0.3: sent ATM_RELEASE request for lv 0x60E8BF84 in state LANE_VCC_CONNECTED
LANE SIG ATM1/0.3: sent ATM_RELEASE request for lv 0x60E8BE64 in state LANE_VCC_CONNECTED
LANE SIG ATM1/0.2: received ATM_RELEASE_COMPLETE callid 0x60EB9040 cause 0 lv 0x60E8D468 lvstate LANE_VCC_DROP_SENT
LANE SIG ATM1/0.2: lane_sig_mc_release: breaking lv 0x60E8D468 from mcg 0x60E97EC8
LANE SIG ATM1/0.2: timer for lv 0x60E8D468 stopped
LANE SIG ATM1/0.3: received ATM_RELEASE_COMPLETE callid 0x60EB97D4 cause 0 lv 0x60E8C014 lvstate LANE_VCC_DROP_SENT
LANE SIG ATM1/0.3: lane_sig_mc_release: breaking lv 0x60E8C014 from mcg 0x60E9A3C0
LANE SIG ATM1/0.3: timer for lv 0x60E8C014 stopped
LANE SIG ATM1/0.1: received ATM_RELEASE_COMPLETE callid 0x60EBCEB8 cause 0 lv 0x60EBBAF0 lvstate LANE_VCC_CONNECTED
LANE SIG ATM1/0.1: lane_sig_mc_release: breaking lv 0x60EBBAF0 from mcg 0x60E8F51C
LANE SIG ATM1/0.1: timer for lv 0x60EBBAF0 stopped
LANE SIG ATM1/0.1: sent ATM_RELEASE request for lv 0x60EBBC10 in state LANE_VCC_CONNECTED
LANE SIG ATM1/0.1: sent ATM_RELEASE request for lv 0x60EBBB80 in state LANE_VCC_CONNECTED
LANE SIG ATM1/0.1: sent ATM_RELEASE request for lv 0x60EBBA60 in state LANE_VCC_CONNECTED
LANE SIG ATM1/0.1: received ATM_RELEASE_COMPLETE callid 0x60EBEB00 cause 0 lv 0x60EBBC10 lvstate LANE_VCC_DROP_SENT
LANE SIG ATM1/0.1: lane_sig_mc_release: breaking lv 0x60EBBC10 from mcg 0x60E8F560
LANE SIG ATM1/0.1: timer for lv 0x60EBBC10 stopped
LANE SIG ATM1/0.2: received ATM_RELEASE_COMPLETE callid 0x60E8B174 cause 0 lv 0x60E8D2B8 lvstate LANE_VCC_RELEASE_SENT
LANE SIG ATM1/0.2: timer for lv 0x60E8D2B8 stopped
LANE SIG ATM1/0.3: received ATM_RELEASE_COMPLETE callid 0x60E8B990 cause 0 lv 0x60E8BE64 lvstate LANE_VCC_RELEASE_SENT
LANE SIG ATM1/0.3: timer for lv 0x60E8BE64 stopped
LANE SIG ATM1/0.2: received ATM_RELEASE_COMPLETE callid 0x60EB7FE0 cause 0 lv 0x60E8D3D8 lvstate LANE_VCC_RELEASE_SENT
LANE SIG ATM1/0.2: timer for lv 0x60E8D3D8 stopped
LANE SIG ATM1/0.3: received ATM_RELEASE_COMPLETE callid 0x60EB8554 cause 0 lv 0x60E8BF84 lvstate LANE_VCC_RELEASE_SENT
LANE SIG ATM1/0.3: timer for lv 0x60E8BF84 stopped
LANE SIG ATM1/0.1: received ATM_RELEASE_COMPLETE callid 0x60EBB6D4 cause 0 lv 0x60EBBA60 lvstate LANE_VCC_RELEASE_SENT
LANE SIG ATM1/0.1: timer for lv 0x60EBBA60 stopped
LANE SIG ATM1/0.1: received ATM_RELEASE_COMPLETE callid 0x60EBE24C cause 0 lv 0x60EBBB80 lvstate LANE_VCC_RELEASE_SENT
LANE SIG ATM1/0.1: timer for lv 0x60EBBB80 stopped
LANE SIG ATM1/0.1: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTER
LANE SIG ATM1/0.1: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTER
LANE SIG ATM1/0.2: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTER
LANE SIG ATM1/0.2: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTER
LANE SIG ATM1/0.3: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTER
LANE SIG ATM1/0.3: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTER
LANE SIG ATM1/0.1: received ATM_CANCEL_NSAP for nsap 00.000000000000050000000000.000000000000.00
LANE SIG ATM1/0.1: received ATM_CANCEL_NSAP for nsap 00.000000000000050000000000.000000000000.00
LANE SIG ATM1/0.2: received ATM_CANCEL_NSAP for nsap 00.000000000000050000000000.000000000000.00
LANE SIG ATM1/0.2: received ATM_CANCEL_NSAP for nsap 00.000000000000050000000000.000000000000.00
LANE SIG ATM1/0.3: received ATM_CANCEL_NSAP for nsap 00.000000000000050000000000.000000000000.00
LANE SIG ATM1/0.3: received ATM_CANCEL_NSAP for nsap 00.000000000000050000000000.000000000000.00
debug lapb
To display all traffic for interfaces using Link Access Procedure, Balanced (LAPB) encapsulation, use thedebuglapbcommand in privileged EXEC mode. To disable debugging output, use the
no form of this command.
debuglapb
nodebuglapb
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
11.0
This command was introduced prior to this release.
Usage Guidelines
This command displays information on the X.25 Layer 2 protocol. It is useful to users familiar with the LAPB protocol.
You can use the
debuglapb command to determine why X.25 interfaces or LAPB connections are going up and down. It is also useful for identifying link problems, as evidenced when the
showinterfaces EXEC command displays a high number of rejects or frame errors over the X.25 link.
The
debuglapb command can generate debugging messages of LAPB on all interfaces configured with the
encapsulationlapb command or when X.25 traffic is present on interfaces configured with the
encapsulationx25command. LAPB debugging produces a substantial amount of data and makes debugging very tedious. The problem becomes more severe if the network contains a large number of X.25 interfaces. Therefore the LAPB debugs are set to be available for individual interface.
Caution
Because the
debuglapb command generates a substantial amount of output, use it when the aggregate of all LAPB traffic on X.25 and LAPB interfaces is fewer than five frames per second.
Examples
The following is sample output from the
debuglapbcommand (the numbers 1 through 7 at the top of the display have been added in order to aid documentation):
1 2 3 4 5 6 7
Serial0: LAPB I CONNECT (5) IFRAME P 2 1
Serial0: LAPB O REJSENT (2) REJ F 3
Serial0: LAPB O REJSENT (5) IFRAME 0 3
Serial0: LAPB I REJSENT (2) REJ (C) 7
Serial0: LAPB I DISCONNECT (2) SABM P
Serial0: LAPB O CONNECT (2) UA F
Serial0: LAPB O CONNECT (5) IFRAME 0 0
Serial0: LAPB T1 CONNECT 357964 0
Each line of output describes a LAPB event. There are two types of LAPB events: frame events (when a frame enters or exits the LAPB) and timer events. In the sample output, the last line describes a timer event; all of the other lines describe frame events. The table below describes the first seven fields.
Table 19 debug lapb Field Descriptions
Field
Description
First field (1)
Interface type and unit number reporting the frame event.
Second field (2)
Protocol providing the information.
Third field (3)
Frame event type. Possible values are as follows:
I--Frame input
O--Frame output
T1--T1 timer expired
T3--Interface outage timer expired
T4--Idle link timer expired
Fourth field (4)
State of the protocol when the frame event occurred. Possible values are as follows:
BUSY (RNR frame received)
CONNECT
DISCONNECT
DISCSENT (disconnect sent)
ERROR (FRMR frame sent)
REJSENT (reject frame sent)
SABMSENT (SABM frame sent)
Fifth field (5)
In a frame event, this value is the size of the frame (in bytes). In a timer event, this value is the current timer value (in milliseconds).
Sixth field (6)
In a frame event, this value is the frame type name. Possible values for f rame type names are as follows:
DISC--Disconnect
DM--Disconnect mode
FRMR--Frame reject
IFRAME--Information frame
ILLEGAL--Illegal LAPB frame
REJ--Reject
RNR--Receiver not ready
RR--Receiver ready
SABM--Set asynchronous balanced mode
SABME--Set asynchronous balanced mode, extended
UA--Unnumbered acknowledgment
In a T1 timer event, this value is the number of retransmissions already attempted.
Seventh field (7)
(This field will not print if the frame control field is required to appear as either a command or a response, and that frame type is correct.)
This field is present only in frame events. It describes the frame type identified by the LAPB address and Poll/Final bit. Possible values are as follows:
(C)--Command frame
(R)--Response frame
P--Command/Poll frame
F--Response/Final frame
/ERR--Command/Response type is invalid for the control field. An ?ERR generally means that the data terminal equipment (DTE)/data communications equipment (DCE) assignments are not correct for this link.
BAD-ADDR--Address field is neither Command nor Response
A timer event displays only the first six fields of
debuglapb command output. For frame events, however, the seventh field documents the LAPB control information present in the frame. Depending on the value of the frame type name shown in the sixth field, the seventh field may or may not appear.
After the Poll/Final indicator, depending on the frame type, three different types of LAPB control information can be printed.
For information frames, the value of the N(S) field and the N(R) field will be printed. The N(S) field of an information frame is the sequence number of that frame, so this field will rotate between 0 and 7 for (modulo 8 operation) or 0 and 127 (for modulo 128 operation) for successive outgoing information frames and (under normal circumstances) also will rotate for incoming information frame streams. The N(R) field is a “piggybacked” acknowledgment for the incoming information frame stream; it informs the other end of the link which sequence number is expected next.
RR, RNR, and REJ frames have an N(R) field, so the value of that field is printed. This field has exactly the same significance that it does in an information frame.
For the FRMR frame, the error information is decoded to display the rejected control field, V(R) and V(S) values, the Response/Command flag, and the error flags WXYZ.
In the following example, the output shows an idle link timer action (T4) where the timer expires twice on an idle link, with the value of T4 set to five seconds:
Serial2: LAPB T4 CONNECT 255748
Serial2: LAPB O CONNECT (2) RR P 5
Serial2: LAPB I CONNECT (2) RR F 5
Serial2: LAPB T4 CONNECT 260748
Serial2: LAPB O CONNECT (2) RR P 5
Serial2: LAPB I CONNECT (2) RR F 5
The next example shows an interface outage timer expiration (T3):
Serial2: LAPB T3 DISCONNECT 273284
The following example output shows an error condition when no DCE to DTE connection exists. Note that if a frame has only one valid type (for example, a SABM can only be a command frame), a received frame that has the wrong frame type will be flagged as a receive error (R/ERR in the following output). This feature makes misconfigured links (DTE-DTE or DCE-DCE) easy to spot. Other less common errors will also be highlighted, such as a too-short or too-long frame or an invalid address (neither command nor response).
Serial2: LAPB T1 SABMSENT 1026508 1
Serial2: LAPB O SABMSENT (2) SABM P
Serial2: LAPB I SABMSENT (2) SABM (R/ERR)
Serial2: LAPB T1 SABMSENT 1029508 2
Serial2: LAPB O SABMSENT (2) SABM P
Serial2: LAPB I SABMSENT (2) SABM (R/ERR)
The output in the next example shows tha the router is misconfigured and has a standard (modulo 8) interface connected to an extended (modulo 128) interface. This condition is indicated by the SABM balanced mode and SABME balanced mode extended messages appearing on the same interface.
Serial2: LAPB T1 SABMSENT 1428720 0
Serial2: LAPB O SABMSENT (2) SABME P
Serial2: LAPB I SABMSENT (2) SABM P
Serial2: LAPB T1 SABMSENT 1431720 1
Serial2: LAPB O SABMSENT (2) SABME P
Serial2: LAPB I SABMSENT (2) SABM P
The output in the next example shows that the
debuglapbcommand is set for a single interface; that is, interface 0/0.
Serial0/0: LAPB O CONNECT (17) IFRAME 1 7
Serial0/0: LAPB I CONNECT (5) IFRAME 7 2
Serial0/0: LAPB I CONNECT (6) IFRAME 0 2
Serial0/0: LAPB O CONNECT (2) RR (R) 1
Serial0/0: LAPB O CONNECT (50) IFRAME 2 1
Serial0/0: LAPB I CONNECT (15) IFRAME 1 2
Serial0/0: LAPB O CONNECT (5) IFRAME 3 2
debug lapb-ta
To display debugging messages for Link Access Procedure, Balanced-Terminal Adapter (LAPB-TA), use the debuglapb-ta command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debuglapb-ta
[ error | event | traffic ]
nodebuglapb-ta
[ error | event | traffic ]
Syntax Description
error
(Optional) Displays LAPB-TA errors.
event
(Optional) Displays LAPB-TA normal events.
traffic
(Optional) Displays LAPB-TA in/out traffic data.
Command Default
Debugging for LAPB-TA is not enabled.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(4)T
This command was introduced.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
Examples
The following is sample output from the debuglapb-ta command with the error, event, and traffic keywords activated:
Router# debug lapb-ta error
LAPB-TA error debugging is on
Router# debug lapb-ta event
LAPB-TA event debugging is on
Router# debug lapb-ta traffic
LAPB-TA traffic debugging is on
Mar 9 12:11:36.464:LAPB-TA:Autodetect trying to detect LAPB on
BR3/0:1
Mar 9 12:11:36.464: sampled pkt: 2 bytes: 1 3F.. match
Mar 9 12:11:36.468:LAPBTA:get_ll_config:BRI3/0:1
Mar 9 12:11:36.468:LAPBTA:line 130 allocated for BR3/0:1
Mar 9 12:11:36.468:LAPBTA:process 79
Mar 9 12:11:36.468:BR3/0:1:LAPB-TA started
Mar 9 12:11:36.468:LAPBTA:service change:LAPB physical layer up,
context 6183E144 interface up, protocol down
Mar 9 12:11:36.468:LAPBTA:service change:, context 6183E144 up
Mar 9 12:11:36.468:LAPB-TA:BR3/0:1, 44 sent
2d14h:%LINEPROTO-5-UPDOWN:Line protocol on Interface BRI3/0:1, changed state to up
2d14h:%ISDN-6-CONNECT:Interface BRI3/0:1 is now connected to 60213
Mar 9 12:11:44.508:LAPB-TA:BR3/0:1, 1 rcvd
Mar 9 12:11:44.508:LAPB-TA:BR3/0:1, 3 sent
Mar 9 12:11:44.700:LAPB-TA:BR3/0:1, 1 rcvd
Mar 9 12:11:44.700:LAPB-TA:BR3/0:1, 3 sent
Mar 9 12:11:44.840:LAPB-TA:BR3/0:1, 1 rcvd
Mar 9 12:11:44.840:LAPB-TA:BR3/0:1, 14 sent
Mar 9 12:11:45.852:LAPB-TA:BR3/0:1, 1 rcvd
Mar 9 12:11:46.160:LAPB-TA:BR3/0:1, 2 rcvd
Mar 9 12:11:47.016:LAPB-TA:BR3/0:1, 1 rcvd
Mar 9 12:11:47.016:LAPB-TA:BR3/0:1, 10 sent
debug lat packet
To display information on all local-area transport (LAT) events, use thedebuglatpacket command in privileged EXEC mode. To disable debugging output, use the
no form of this command.
debuglatpacket
nodebuglatpacket
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
For each datagram (packet) received or sent, a message is logged to the console.
Caution
This command severely impacts LAT performance and is intended for troubleshooting use only.
Examples
The following is sample output from the
debuglatpacketcommand:
Router# debug lat packet
LAT: I int=Ethernet0, src=0000.0c01.0509, dst=0900.2b00.000f, type=0, M=0, R=0
LAT: I int=Ethernet0, src=0800.2b11.2d13, dst=0000.0c01.7876, type=A, M=0, R=0
LAT: O dst=0800.2b11.2d13, int=Ethernet0, type= A, M=0, R=0, len= 20, next 0 ref 1
The second line of output describes a packet that is input to the router. The table below describes the fields in this line.
Table 20 debug lat packet Field Descriptions
Field
Description
LAT:
Indicates that this display shows LAT debugging output.
I
Indicates that this line of output describes a packet that is input to the router (I) or output from the router (O).
int = Ethernet0
Indicates the interface on which the packet event took place.
src = 0800.2b11.2d13
Indicates the source address of the packet.
dst=0000.0c01.7876
Indicates the destination address of the packet.
type=A
Indicates the message type (in hexadecimal notation). Possible values are as follows:
0 = Run Circuit
1 = Start Circuit
2 = Stop Circuit
A = Service Announcement
C = Command
D = Status
E = Solicit Information
F = Response Information
The third line of output describes a packet that is output from the router. The table below describes the last three fields in this line.
Table 21 debug lat packet Field Descriptions
Field
Description
len= 20
Indicates the length (in hexadecimal notation) of the packet (in bytes).
next 0
Indicates the link on the transmit queue.
ref 1
Indicates the count of packet users.
debug ldap
To enable debugging for Lightweight Directory Access Protocol (LDAP) configuration, use the debugldap command in privileged EXEC mode. To disable debugging, use the no form of this command.
Displays all event, legacy, and packet related messages.
error
Displays error messages about the local authentication server.
event
Displays debug messages related to LDAP proxy events.
legacy
Displays legacy messages.
packet
Displays the content of the RADIUS packets that are sent and received.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
15.1(1)T
This command was introduced.
Examples
The following is sample output from the debugldaplegacy command:
Router# debug ldap legacy
put_filter "(&(objectclass=*)(cn=firewall_user))"
put_filter: AND
put_filter_list "(objectclass=*)(cn=firewall_user)"
put_filter "(objectclass=*)"
put_filter: simple
put_filter "(cn=firewall_user)"
put_filter: simple
Doing socket writeldap_result
wait4msg (timeout 0 sec, 1 usec)
ldap_select_fd_wait (select)
ldap_read_activity lc 0x6804D354
Doing socket read
LDAP-TCP:Bytes read = 1478
ldap_match_request succeeded for msgid 2 h 0
ldap_get_dn
ldap_get_dn
ldap_msgfree
ldap_result
wait4msg (timeout 0 sec, 1 usec)
ldap_read_activity lc 0x6804D354
ldap_match_request succeeded for msgid 2 h 0
changing lr 0x6774F8D4 to COMPLETE as no continuations
removing request 0x6774F8D4 from list as lm 0x681C9B78 all 0
ldap_msgfree
ldap_msgfree
ldap_parse_result
ldap_parse_result
ldap_req_encode
Doing socket writeldap_msgfree
ldap_result
wait4msg (timeout 0 sec, 1 usec)
ldap_select_fd_wait (select)
ldap_result
wait4msg (timeout 0 sec, 1 usec)
ldap_select_fd_wait (select)
ldap_read_activity lc 0x6804D354
Doing socket read
LDAP-TCP:Bytes read = 22
ldap_match_request succeeded for msgid 3 h 0
changing lr 0x6774F8D4 to COMPLETE as no continuations
removing request 0x6774F8D4 from list as lm 0x681C9B78 all 0
ldap_msgfree
ldap_msgfree
ldap_parse_result
ldap_parse_result
ldap_msgfree
ldap_result
wait4msg (timeout 0 sec, 1 usec)
ldap_select_fd_wait (select)
Related Commands
Command
Description
ipv4(ldap)
Creates an IPv4 address within an LDAP server address pool
ldapserver
Defines an LDAP server and enters LDAP server configuration mode.
transportport(ldap)
Configures the transport protocol for establishing a connection with the LDAP server.
debug lex rcmd
To debug
LAN Extender remote commands, use the debuglexrcmd
command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debuglexrcmd
nodebuglexrcmd
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Examples
The following is sample output from the debuglexrcmd command:
Router# debug lex rcmd
LEX-RCMD: "shutdown" command received on unbound serial interface- Serial0
LEX-RCMD: Lex0: "inventory" command received
Rcvd rcmd: FF 03 80 41 41 13 00 1A 8A 00 00 16 01 FF 00 00
Rcvd rcmd: 00 02 00 00 07 5B CD 15 00 00 0C 01 15 26
LEX-RCMD: ACK or response received on Serial0 without a corresponding ID
LEX-RCMD: REJ received
LEX-RCMD: illegal CODE field received in header: <number>
LEX-RCMD: illegal length for Lex0: "lex input-type-list"
LEX-RCMD: Lex0 is not bound to a serial interface
LEX-RCMD: encapsulation failure
LEX-RCMD: timeout for Lex0: "lex priority-group" command
LEX-RCMD: re-transmitting Lex0: "lex priority-group” command
LEX-RCMD: lex_setup_and_send called with invalid parameter
LEX-RCMD: bind occurred on shutdown LEX interface
LEX-RCMD: Serial0- No free Lex interface found with negotiated MAC address 0000.0c00.d8db
LEX-RCMD: No active Lex interface found for unbind
The following output indicates that a
LAN Extender remote command packet was received on a serial interface that is not bound to a
LAN Extender interface:
LEX-RCMD: "shutdown" command received on unbound serial interface- Serial0
This message can occur for any of the LAN Extender remote commands. Possible causes of this message are as follows:
FLEX state machine software error
Serial line momentarily goes down, which is detected by the host but not by FLEX
The following output indicates that a LAN Extender remote command response has been received. The hexadecimal values are for internal use only.
The following output indicates that when the host router originates a LAN Extender remote command to FLEX, it generates an 8-bit identifier that is used to associate a command with its corresponding response:
LEX-RCMD: ACK or response received on Serial0 without a corresponding ID
This message could be displayed for any of the following reasons:
FLEX was busy at the time that the command arrived and could not send an immediate response. The command timed out on the host router and then FLEX finally sent the response.
Transmission error.
Software error.
Possible responses to Config-Request are Config-ACK, Config-NAK, and Config-Rej. The following output shows that some of the options in the Config-Request are not recognizable or are not acceptable to FLEX due to transmission errors or software errors:
LEX-RCMD: REJ received
The following output shows that a LAN Extender remote command response was received but that the CODE field in the header was incorrect:
LEX-RCMD: illegal CODE field received in header: <number>
The following output indicates that a LAN Extender remote command response was received but that it had an incorrect length field. This message can occur for any of the LAN Extender remote commands.
LEX-RCMD: illegal length for Lex0: "lex input-type-list"
The following output shows that a host router was about to send a remote command when the serial link went down:
LEX-RCMD: Lex0 is not bound to a serial interface
The following output shows that the serial encapsulation routine of the interface failed to encapsulate the remote command datagram because the LEX-NCP was not in the OPEN state. Due to the way the PPP state machine is implemented, it is normal to see a single encapsulation failure for each remote command that gets sent at bind time.
LEX-RCMD: encapsulation failure
The following output shows that the timer expired for the given remote command without having received a response from the FLEX device. This message can occur for any of the LAN Extender remote commands.
LEX-RCMD: timeout for Lex0: "lex priority-group" command
This message could be displayed for any of the following reasons:
FLEX too busy to respond
Transmission failure
Software error
The following output indicates that the host is resending the remote command after a timeout:
The following output indicates that an illegal parameter was passed to the lex_setup_and_send routine. This message could be displayed due to a host software error.
LEX-RCMD: lex_setup_and_send called with invalid parameter
The following output is informational and shows when a bind occurs on a shutdown interface:
LEX-RCMD: bind occurred on shutdown LEX interface
The following output shows that the LEX-NCP reached the open state and a bind operation was attempted with the FLEX's MAC address, but no free LAN Extender interfaces were found that were configured with that MAC address. This output can occur when the network administrator does not configure a LAN Extender interface with the correct MAC address.
LEX-RCMD: Serial0- No free Lex interface found with negotiated MAC address 0000.0c00.d8db
The following output shows that the serial line that was bound to the LAN Extender interface went down and the unbind routine was called, but when the list of active LAN Extender interfaces was searched, the LAN Extender interface corresponding to the serial interface was not found. This output usually occurs because of a host software error.
LEX-RCMD: No active Lex interface found for unbind
debug license
To enable controlled Cisco IOS software license debugging activity on a device, use the debuglicense command in privileged EXEC mode. To disable debugging, use the no form of this command.
Debugs license interprocess communication (IPC) messages.
Command Default
Debugging is disabled.
Command Modes
Privileged EXEC (#)
Command History
Release
Modification
12.2(35)SE2
This command was introduced.
12.4(15)XZ
This command was integrated into Cisco IOS Release 12.4(15)XZ.
12.4(20)T
This command was integrated into Cisco IOS Release 12.4(20)T.
Cisco IOS XE Release 3.2S
This command was implemented on the Cisco ASR 1001 router.
Usage Guidelines
Use this command to help troubleshoot issues with licenses on a device.
On the Cisco ASR 1001 router, the output from the debuglicense command is not in standard IOS format. You must execute the requestplatformsoftwaretracerotateall privileged EXEC command to make the output in the log files in the bootflash:tracelogs directory.
Examples
The following example shows how to enable debugging for license warnings and errors on a router:
Router# debug license errors
The following example shows how to enable debugging for all license agent information on a switch:
Switch# debug license agent all
license agent app https[0x43FBC7C]: urlhook function
license agent app https[0x43FBC7C]: https action function
LIC_AGENT:Processing XML message
<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://www.w3.org/2003/05/soap-envelope">
<SOAP:Header>
<clm:Header version="1.0" xmlns:clm="http://www.cisco.com/clm">
<clm:Time>2003-04-23T20:27:19.827Z</clm:Time>
</clm:Header>
</SOAP:Header>
<SOAP:Body>
<lica:request xmlns:lica="http://www.cisco.com/clm">
<lica:installRequest>
<lica:license encoding="BASE64">
PENJU0NPX1dUX0FSVElGQUNUUyB2ZXJzaW9uPSIxLjAiPjxDSVNDT19XVF9MSUNFTlNFIHZlcnNp
b249IjEuMCI+PEZFQVRVUkVfTkFNRT5pcGJhc2U8L0ZFQVRVUkVfTkFNRT48RkVBVFVSRV9WRVJT
SU9OPjEuMDwvRkVBVFVSRV9WRVJTSU9OPjxVREk+PFBJRD5CVUxMU0VZRTI0PC9QSUQ+PFNOPkNB
VDEwMDZSMEU4PC9TTj48L1VEST48U09VUkNFPkNpc2NvIEhRPC9TT1VSQ0U+PENSRUFURV9EQVRF
PjIwMDYtMTEtMjJUMDA6MzM6NTA8L0NSRUFURV9EQVRFPjxMSUNFTlNFX0xJTkVfSEFTSCBoYXNo
QWxnbz0iU0hBMSI+NDJiNFVWWFpOd3pJK0ZNdEV6QlNZSDRWdzFFPTwvTElDRU5TRV9MSU5FX0hB
U0g+PFRZUEU+UkVHVUxBUjwvVFlQRT48TElDRU5TRV9MSU5FPjwhW0NEQVRBWzExIGlwYmFzZSAx
LjAgTE9ORyBOT1JNQUwgU1RBTkRBTE9ORSBFWENMIElORklOSVRFX0tFWVMgSU5GSU5JVEVfS0VZ
UyBORVZFUiBORVZFUiBOaUwgU0xNX0NPREUgQ0xfTkRfTENLIE5pTCAqMVZBUlY5WlJESzREOU5U
NDAwIE5pTCBOaUwgTmlMIDVfTUlOUyA8VURJPjxQSUQ+QlVMTFNFWUUyNDwvUElEPjxTTj5DQVQx
MDA2UjBFODwvU04+PC9VREk+IGUxWW8wS1U2VnJLOnBJZXRib1dJVkEyZlVaVGdieUlEaklHWERR
VXc3dkxOYWlXRzZ0dUJOMG5lTXpKaHpzQ2tMN1l3TWFxS2paem05YW5FbVJHUUVPTHlDdmRVZksw
QmNLN0pPcnZsUkw0VjMyJDxXTEM+QVFFQklRQUIvLy9GbS8vWDkybThNb0NOZkVMSHJiVzRjWDFM
ZGNpdDNMVU5GWlV1OWppT0phcXB5Q2N6TTFpaUlKbVE3NEd5WHJFY3F2UGlBbVdTYUVtVVQ1NnJz
dGs2Z3ZtaitFUUtSZkQ5QTBpbWUxY3pyZEt4ZklMVDBMYVhUNDE2bndtZnA5MlR5YTZ2SVE0Rm5s
QmRxSjFzTXpYZVNxOFBtVmNUVTlBNG85aGlsOXZLdXI4TjlGODg1RDlHVkYwYkpIY2lUNU09PC9X
TEM+XV0+PC9MSUNFTlNFX0xJTkU+PFVTRVJfTU9ESUZJQUJMRV9DT01NRU5UIGZpZWxkUmVzdHJp
Y3Rpb25zPSJNYXggOTkgQVNDSUkgY2hhcmFjdGVycyBpbiBsZW5ndGguIj48L1VTRVJfTU9ESUZJ
QUJMRV9DT01NRU5UPjwvQ0lTQ09fV1RfTElDRU5TRT48L0NJU0NPX1dUX0FSVElGQUNUUz4=
</lica:license>
</lica:installRequest>
</lica:request>
</SOAP:Body>
</SOAP:Envelope>
LIC_AGENT: XML received opcode(1)
LIC_AGENT: License ipbase
%IOS_LICENSE_IMAGE_APPLICATION-6-LICENSE_LEVEL: Next reboot level = ipbase and License = ipbase
LIC_AGENT: Notification Event type = 1 License Installed
LIC_AGENT: Notification Event type = 13 License Annotate
debug link monitor
To display the statistics of the executing process, use the debuglinkmonitor command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debuglinkmonitor
nodebuglinkmonitor
Syntax Description
This command has no arguments or keywords.
Command Default
No default behavior or values
Command Modes
Privileged EXEC
Command History
Release
Modification
12.3(1)
This command was introduced.
Usage Guidelines
This command is used to display the statistics, which are used for debugging the status of the various conditions occurred during execution of the monitoring process.
Examples
The following example enables link monitoring statistics:
Router# debug link monitor
%DEBUG-ENABLED Error Rate Link Monitor
The following example disables link monitoring statistics:
Router# no debug link monitor
%DEBUG-DISABLED Error Rate Link Monitor
Related Commands
Command
Description
debugall
Enables debugging for link monitoring.
nodebugall
Disables debugging for link monitoring.
clearcounters
Clears show interface counters on all interfaces.
showlinkmonitordebug
Show link monitor error statistics.
debug list
To filter debugging information on a per-interface or per-access list basis, use the debuglist command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debuglist [list] [interface]
nodebuglist [list] [interface]
Syntax Description
list
(Optional) An access list number in the range from 1100 to 1199.
interface
(Optional) The interface type. Allowed values are the following:
channel--IBM Channel interface
ethernet--IEEE 802.3
fddi--ANSI X3T9.5
null--Null interface
serial--Serial
tokenring--IEEE 802.5
tunnel--Tunnel interface
Command Modes
Privileged EXEC
Usage Guidelines
The debuglist command is used with other debug commands for specific protocols and interfaces to filter the amount of debug information that is displayed. In particular, this command is designed to filter specific physical unit (PU) output from bridging protocols. The debuglist command is supported with the following commands:
debugarp
debugllc2errors
debugllc2packets
debugllc2state
debugrif
debugsdlc
debugtokenring
Note
All debug commands that support access list filtering use access lists in the range from 1100 to 1199. The access list numbers shown in the examples are merely samples of valid numbers.
Examples
To use the debuglist command on only the first of several Logical Link Control, type 2 (LLC2) connections, use the showllc2 command to display the active connections:
Router# show llc2
SdllcVirtualRing2008 DTE: 4000.2222.22c7 4000.1111.111c 04 04 state NORMAL
SdllcVirtualRing2008 DTE: 4000.2222.22c8 4000.1111.1120 04 04 state NORMAL
SdllcVirtualRing2008 DTE: 4000.2222.22c1 4000.1111.1104 04 04 state NORMAL
Next, configure an
extended bridging access list, numbered 1103, for the connection you want to filter:
The convention for the LLC debuglist command filtering is to use dmac = 6 bytes, smac = 6 bytes, dsap_offset = 12, and ssap_offset = 13.
Finally, you invoke the following debug commands:
Router# debug list 1103
Router# debug llc2 packet
LLC2 Packets debugging is on
for access list: 1103
To use the debuglist command for Synchronous Data Link Control (SDLC) connections, with the exception of address 04, create access list 1102 to deny the specific address and permit all others:
The convention is to use dmac = 0.0.0, smac = 0.0.0, and sdlc_frame_offset = 12.
Invoke the following debug commands:
Router# debug list 1102
Router# debug sdlc
SDLC link debugging is on
for access list: 1102
To enable SDLC debugging (or debugging for any of the other supported protocols) for a specific interface rather than for all interfaces on a router, use the following commands:
Router# debug list serial 0
Router# debug sdlc
SDLC link debugging is on
for interface: Serial0
To enable Token Ring debugging between two MAC address, 0000.3018.4acd and 0000.30e0.8250, configure an extended bridging access list 1106:
Router# debug list 1109
Router# debug rif
RIF update debugging is on
for access list: 1109
Related Commands
Command
Description
debugllc2errors
Displays LLC2 protocol error conditions or unexpected input.
debugllc2packet
Displays all input and output from the LLC2 protocol stack.
debugllc2state
Displays state transitions of the LLC2 protocol.
debugrif
Displays information on entries entering and leaving the RIF cache.
debugrtsp
Displays information on SDLC frames received and sent by any router serial interface involved in supporting SDLC end station functions.
debugtokenring
Displays messages about Token Ring interface activity.
debug llc2 dynwind
To display changes to the dynamic window over Frame Relay, use the debugllc2dynwindcommand in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugllc2dynwind
nodebugllc2dynwind
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Examples
The following is sample output from the debugllc2dynwind command:
Router# debug llc2 dynwind
LLC2/DW: BECN received! event REC_I_CMD, Window size reduced to 4
LLC2/DW: 1 consecutive I-frame(s) received without BECN
LLC2/DW: 2 consecutive I-frame(s) received without BECN
LLC2/DW: 3 consecutive I-frame(s) received without BECN
LLC2/DW: 4 consecutive I-frame(s) received without BECN
LLC2/DW: 5 consecutive I-frame(s) received without BECN
LLC2/DW: Current working window size is 5
In this example, the router receives a backward explicit congestion notification (BECN) and reduces the window size to 4. After receiving five consecutive I frames without a BECN, the router increases the window size to 5.
Related Commands
Command
Description
debugllc2errors
Displays LLC2 protocol error conditions or unexpected input.
debugllc2packet
Displays all input and output from the LLC2 protocol stack.
debugllc2state
Displays state transitions of the LLC2 protocol.
debug llc2 errors
To display
Logical Link Control, type 2 (LLC2) protocol error conditions or unexpected input, use the debugllc2errorscommand in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugllc2errors
nodebugllc2errors
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Examples
The following is sample output from the debugllc2errors command from a router ignoring an incorrectly configured device:
Each line of output contains the remote
MAC address, the local MAC address, the remote service access point (SAP), and the local SAP. In this example, the router receives unsolicited RR frames marked as responses.
Related Commands
Command
Description
debuglist
Filters debugging information on a per-interface or per-access list basis.
debugllc2dynwind
Displays changes to the dynamic window over Frame Relay.
debugllc2packet
Displays all input and output from the LLC2 protocol stack.
debugllc2state
Displays state transitions of the LLC2 protocol.
debug llc2 packet
To display all input and output from the Logical Link Control, type 2 (LLC2) protocol stack, use the debugllc2packet command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debugllc2packet
nodebugllc2packet
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
This command also displays information about some error conditions as well as internal interactions between the Common Link Services (CLS) layer and the LLC2 layer.
Examples
The following is sample output from thedebugllc2packet command from the router sending ping data back and forth to another router:
The next line indicates that this input was an RR command with the poll bit set. The other router has received sequence number 21 and is waiting for the final bit.
LLC: i REC_RR_CMD N(R)=21 p/f=1
The next two lines contain the MAC addresses of the sender and receiver, and the state of the router when it received this frame:
Filters debugging information on a per-interface or per-access list basis.
debugllc2dynwind
Displays changes to the dynamic window over Frame Relay.
debugllc2errors
Displays LLC2 protocol error conditions or unexpected input.
debugllc2state
Displays state transitions of the LLC2 protocol.
debug llc2 state
To display state transitions of the Logical Link Control, type 2
(LLC2) protocol, use the
debugllc2state command in privileged EXEC mode. To disable
debugging output, use the
no form of this command.
debugllc2state
nodebugllc2state
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
Refer to the ISO/IEC standard 8802-2 for definitions and explanations
of
debugllc2state command output.
Examples
The following is sample output from the
debugllc2state command when a router disables and enables
an interface:
Filters debugging information on a per-interface or
per-access list basis.
debug llc2 dynwind
Displays changes to the dynamic window over Frame Relay.
debugllc2errors
Displays LLC2 protocol error conditions or unexpected
input.
debugllc2packet
Displays all input and output from the LLC2 protocol stack.
debug lnm events
To display any unusual events that occur on a
Token Ring network, use the debuglnmevents
command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debuglnmevents
nodebuglnmevents
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
Unusual events include stations reporting errors or error thresholds being exceeded.
Examples
The following is sample output from the debuglnmevents command:
Router# debug lnm events
IBMNM3: Adding 0000.3001.1166 to error list
IBMNM3: Station 0000.3001.1166 going into preweight condition
IBMNM3: Station 0000.3001.1166 going into weight condition
IBMNM3: Removing 0000.3001.1166 from error list
LANMGR0: Beaconing is present on the ring
LANMGR0: Ring is no longer beaconing
IBMNM3: Beaconing, Postmortem Started
IBMNM3: Beaconing, heard from 0000.3000.1234
IBMNM3: Beaconing, Postmortem Next Stage
IBMNM3: Beaconing, Postmortem Finished
The following message indicates that station 0000.3001.1166 reported errors and has been added to the list of stations reporting errors. This station is located on Ring 3.
IBMNM3: Adding 0000.3001.1166 to error list
The following message indicates that station 0000.3001.1166 has passed the “early warning” threshold for error counts:
IBMNM3: Station 0000.3001.1166 going into preweight condition
The following message indicates that station 0000.3001.1166 is experiencing a severe number of errors:
IBMNM3: Station 0000.3001.1166 going into weight condition
The following message indicates that the error counts for station 0000.3001.1166 have all decayed to zero, so this station is being removed from the list of stations that have reported errors:
IBMNM3: Removing 0000.3001.1166 from error list
The following message indicates that Ring 0 has entered failure mode. This ring number is assigned internally.
LANMGR0: Beaconing is present on the ring
The following message indicates that Ring 0 is no longer in failure mode. This ring number is assigned internally.
LANMGR0: Ring is no longer beaconing
The following message indicates that the router is beginning its attempt to determine whether any stations left the ring during the automatic recovery process for the last beaconing failure. The router attempts to contact stations that were part of the fault domain to detect whether they are still operating on the ring.
IBMNM3: Beaconing, Postmortem Started
The following message indicates that the router is attempting to determine whether any stations left the ring during the automatic recovery process for the last beaconing failure. It received a response from station 0000.3000.1234, one of the two stations in the fault domain.
IBMNM3: Beaconing, heard from 0000.3000.1234
The following message indicates that the router is attempting to determine whether any stations left the ring during the automatic recovery process for the last beaconing failure. It is initiating another attempt to contact the two stations in the fault domain.
IBMNM3: Beaconing, Postmortem Next Stage
The following message indicates that the router has attempted to determine whether any stations left the ring during the automatic recovery process for the last beaconing failure. It has successfully heard back from both stations that were part of the fault domain.
IBMNM3: Beaconing, Postmortem Finished
Explanations follow for other messages that the debuglnmevents command can generate.
The following message indicates that the router is out of memory:
The following message indicates that Ring 3 is experiencing a large number of errors that cannot be attributed to any individual station:
IBMNM3: Non-isolating error threshold exceeded
The following message indicates that a station (or stations) on Ring 3 is receiving frames faster than they can be processed:
IBMNM3: Adapters experiencing congestion
The following message indicates that the beaconing has lasted for over 1 minute and is considered a “permanent” error:
IBMNM3: Beaconing, permanent
The following message indicates that the beaconing lasted for less than 1 minute. The router is attempting to determine whether either station in the fault domain left the ring.
IBMNM: Beaconing, Destination Started
In the preceding line of output, the following can replace “Started”: “Next State,” “Finished,” “Timed out,” and “Cannot find station n.”
debug lnm llc
To display all comm unication between the router/bridge and the LAN Network Managers (LNMs) that have connections to it, use the
debuglnmllc command in privileged EXEC mode. To disable debugging output, use the
no form of this command.
debuglnmllc
nodebuglnmllc
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
One line is displayed for each message sent or received.
Examples
The following is sample output from the
debuglnmllc command:
Router# debug lnm llc
IBMNM: Received LRM Set Reporting Point frame from 1000.5ade.0d8a.
IBMNM: found bridge: 001-2-00A, addresses: 0000.3040.a630 4000.3040.a630
IBMNM: Opening connection to 1000.5ade.0d8a on TokenRing0
IBMNM: Sending LRM LAN Manager Accepted to 1000.5ade.0d8a on link 0.
IBMNM: sending LRM New Reporting Link Established to 1000.5a79.dbf8 on link 1.
IBMNM: Determining new controlling LNM
IBMNM: Sending Report LAN Manager Control Shift to 1000.5ade.0d8a on link 0.
IBMNM: Sending Report LAN Manager Control Shift to 1000.5a79.dbf8 on link 1.
IBMNM: Bridge 001-2-00A received Request Bridge Status from 1000.5ade.0d8a.
IBMNM: Sending Report Bridge Status to 1000.5ade.0d8a on link 0.
IBMNM: Bridge 001-2-00A received Request REM Status from 1000.5ade.0d8a.
IBMNM: Sending Report REM Status to 1000.5ade.0d8a on link 0.
IBMNM: Bridge 001-2-00A received Set Bridge Parameters from 1000.5ade.0d8a.
IBMNM: Sending Bridge Parameters Set to 1000.5ade.0d8a on link 0.
IBMNM: sending Bridge Params Changed Notification to 1000.5a79.dbf8 on link 1.
IBMNM: Bridge 001-2-00A received Set REM Parameters from 1000.5ade.0d8a.
IBMNM: Sending REM Parameters Set to 1000.5ade.0d8a on link 0.
IBMNM: sending REM Parameters Changed Notification to 1000.5a79.dbf8 on link 1.
IBMNM: Bridge 001-2-00A received Set REM Parameters from 1000.5ade.0d8a.
IBMNM: Sending REM Parameters Set to 1000.5ade.0d8a on link 0.
IBMNM: sending REM Parameters Changed Notification to 1000.5a79.dbf8 on link 1.
IBMNM: Received LRM Set Reporting Point frame from 1000.5ade.0d8a.
IBMNM: found bridge: 001-1-00A, addresses: 0000.3080.2d79 4000.3080.2d7
As the output indicates, the
debuglnmllc command output can vary somewhat in format.
The table below describes the significant fields shown in the display.
Table 22 debug lnm llc Field Descriptions
Field
Description
IBMNM:
Displays LLC-level debugging information.
Received
Router received a frame. The other possible value is Sending, to indicate that the router is sending a frame.
LRM
The function of the LLC-level software that is communicating as follows:
CRS--Configuration Report Server
LBS--LAN Bridge Server
LRM--LAN Reporting Manager
REM--Ring Error Monitor
RPS--Ring Parameter Server
RS--Ring Station
Set Reporting Point
Name of the specific frame that the router sent or received. Possible values include the following:
Bridge Counter Report
Bridge Parameters Changed Notification
Bridge Parameters Set
CRS Remove Ring Station
CRS Report NAUN Change
CRS Report Station Information
CRS Request Station Information
CRS Ring Station Removed
LRM LAN Manager Accepted
LRM Set Reporting Point
New Reporting Link Established
REM Forward MAC Frame
REM Parameters Changed Notification
REM Parameters Set
Report Bridge Status
Report LAN Manager Control Shift
Report REM Status
Request Bridge Status
Request REM Status
Set Bridge Parameters
Set REM Parameters
from 1000.5ade.0d8a
If the router has received the frame, this address is the source address of the frame. If the router is sending the frame, this address is the destination address of the frame.
The following message indicates that the lookup for the bridge with which the LAN Manager was requesting to communicate was successful:
IBMNM: found bridge: 001-2-00A, addresses: 0000.3040.a630 4000.3040.a630
The following message indicates that the connection is being opened:
IBMNM: Opening connection to 1000.5ade.0d8a on TokenRing0
The following message indicates that a LAN Manager has connected or disconnected from an internal bridge and that the router computes which LAN Manager is allowed to change parameters:
IBMNM: Determining new controlling LNM
The following line of output indicates which bridge in the router is the destination for the frame:
IBMNM: Bridge 001-2-00A received Request Bridge Status from 1000.5ade.0d8a.
debug lnm mac
To display all management communication between the router/bridge and all stations on the local Token Rings, use the
debuglnmmac command in privileged EXEC mode. To disable debugging output, use the
no form of this command.
debuglnmmac
nodebuglnmmac
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
One line is displayed for each message sent or received.
Examples
The following is sample output from the
debuglnmmac command:
Router# debug lnm mac
LANMGR0: RS received request address from 4000.3040.a670.
LANMGR0: RS sending report address to 4000.3040.a670.
LANMGR0: RS received request state from 4000.3040.a670.
LANMGR0: RS sending report state to 4000.3040.a670.
LANMGR0: RS received request attachments from 4000.3040.a670.
LANMGR0: RS sending report attachments to 4000.3040.a670.
LANMGR2: RS received ring purge from 0000.3040.a630.
LANMGR2: CRS received report NAUN change from 0000.3040.a630.
LANMGR2: RS start watching ring poll.
LANMGR0: CRS received report NAUN change from 0000.3040.a630.
LANMGR0: RS start watching ring poll.
LANMGR2: REM received report soft error from 0000.3040.a630.
LANMGR0: REM received report soft error from 0000.3040.a630.
LANMGR2: RS received ring purge from 0000.3040.a630.
LANMGR2: RS received AMP from 0000.3040.a630.
LANMGR2: RS received SMP from 0000.3080.2d79.
LANMGR2: CRS received report NAUN change from 1000.5ade.0d8a.
LANMGR2: RS start watching ring poll.
LANMGR0: RS received ring purge from 0000.3040.a630.
LANMGR0: RS received AMP from 0000.3040.a630.
LANMGR0: RS received SMP from 0000.3080.2d79.
LANMGR0: CRS received report NAUN change from 1000.5ade.0d8a.
LANMGR0: RS start watching ring poll.
LANMGR2: RS received SMP from 1000.5ade.0d8a.
LANMGR2: RPS received request initialization from 1000.5ade.0d8a.
LANMGR2: RPS sending initialize station to 1000.5ade.0d8a.
The table below describes the significant fields shown in the display.
Table 23 debug lnm mac Field Descriptions
Field
Description
LANMGR0:
Indicates that this line of output displays MAC-level debugging information. 0 indicates the number of the Token Ring interface associated with this line of debugging output.
RS
Indicates which function of the MAC-level software is communicating as follows:
CRS--Configuration Report Server
REM--Ring Error Monitor
RPS--Ring Parameter Server
RS--Ring Station
received
Indicates that the router received a frame. The other possible value is sending, to indicate that the router is sending a frame.
request address
Indicates the name of the specific frame that the router sent or received. Possible values include the following:
AMP
initialize station
report address
report attachments
report nearest active upstream neighbor (NAUN) change
report soft error
report state
request address
request attachments
request initialization
request state
ring purge
SMP
from 4000.3040.a670
Indicates the source address of the frame, if the router has received the frame. If the router is sending the frame, this address is the destination address of the frame.
As the output indicates, all
debuglnmmac command messages follow the format described in the table above except the following:
LANMGR2: RS start watching ring poll
LANMGR2: RS stop watching ring poll
These messages indicate that the router starts and stops receiving AMP and SMP frames. These frames are used to build a current picture of which stations are on the ring.
debug local-ack state
To display the new and the old state conditions whenever there is a state change in the local acknowledgment state machine, use the
debuglocal-ackstate command in privileged EXEC mode. To disable debugging output, use the
no form of this command.
debuglocal-ackstate
nodebuglocal-ackstate
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Examples
The following is sample output from the
debuglocal-ackstate command:
Router# debug local-ack state
LACK_STATE: 2370300, hashp 2AE628, old state = disconn, new state = awaiting
LLC2 open to finish
LACK_STATE: 2370304, hashp 2AE628, old state = awaiting LLC2 open to finish,
new state = connected
LACK_STATE: 2373816, hashp 2AE628, old state = connected, new state = disconnected
LACK_STATE: 2489548, hashp 2AE628, old state = disconn, new state = awaiting
LLC2 open to finish
LACK_STATE: 2489548, hashp 2AE628, old state = awaiting LLC2 open to finish,
new state = connected
LACK_STATE: 2490132, hashp 2AE628, old state = connected, new state = awaiting
linkdown response
LACK_STATE: 2490140, hashp 2AE628, old state = awaiting linkdown response,
new state = disconnected
LACK_STATE: 2497640, hashp 2AE628, old state = disconn, new state = awaiting
LLC2 open to finish
LACK_STATE: 2497644, hashp 2AE628, old state = awaiting LLC2 open to finish,
new state = connected
The table below describes the significant fields shown in the display.
Table 24 debug local-ack state Field Descriptions
Field
Description
LACK_STATE:
Indicates that this packet describes a state change in the local acknowledgment state machine.
2370300
System clock.
hashp 2AE628
Internal control block pointer used by technical support staff for debugging purposes.
old state = disconn
Old state condition in the local acknowledgment state machine. Possible values include the following:
Disconn (disconnected)
awaiting LLC2 open to finish
connected
awaiting linkdown response
new state = awaiting LLC2 open to finish
New state condition in the local acknowledgment state machine. Possible values include the following: