Syntax Description

border-peers	(Optional) Enables debugging output for border peer events.
interface interface	(Optional) Specifies a remote peer to debug by a direct interface.
ip address ip-address	(Optional) Specifies a remote peer to debug by its IP address.
core	(Optional) Enables debugging output for DLSw core events.
flow-control	(Optional) Enables debugging output for congestion in the WAN or at the remote end station.
messages	(Optional) Enables debugging output of core messages---specific packets received by DLSw either from one of its peers or from a local medium via the Cisco link services interface.
state	(Optional) Enables debugging output for state changes on the circuit.
xid	(Optional) Enables debugging output for the exchange identification-state machine.
circuit-number	(Optional) Specifies the circuit for which you want core debugging output to reduce the of output.
local-circuit circuit-number	(Optional) Enables debugging output for circuits performing local conversion. Local conversion occurs when both the input and output data-link connections are on the same local peer and no remote peer exists.
peers	(Optional) Enables debugging output for peer events.
fast-errors	(Optional) Debugs errors for fast-switched packets.
fast-paks	(Optional) Debugs fast-switched packets.
fst-seq	(Optional) Debugs FST sequence numbers on fast switched packets.
udp	(Optional) Debugs UDP packets.
reachability	(Optional) Enables debugging output for reachability events (explorer traffic). If no options are specified, event-level information is displayed for all protocols.
error | verbose	(Optional) Specifies how much reachability information you want displayed. The verbose keyword displays everything, including errors and events. The error keyword displays error information only. If no option is specified, event-level information is displayed.
sna | netbios	(Optional) Specifies that reachability information be displayed for only SNA or NetBIOS protocols. If no option is specified, information for all protocols is displayed.

Usage Guidelines

When you specify no optional keywords, the debug dlsw command enables all available DLSw debugging output.

Normally you need to use only the error or verbose option of the debug dlsw reachability command to help identify problems. The error option is recommended for use by customers and provides a subset of the messages from the normal event-level debugging. The verbose option provides a very detailed view of what is going on and is typically used only by service personnel.

To reduce the amount of debug information displayed, use the sna or netbios options with the debug dlsw reachability command if you know that you have an SNA or NetBIOS problem.

The DLSw core is the engine that is responsible for the establishment and maintenance of remote circuits. If possible, specifying the index of the specific circuit you want to debug reduces the amount of output displayed. However, if you want to watch a circuit initially come up, do not use the circuit-number option with the core keyword.

The core flow-control option provides information about congestion in the WAN or at the remote end station. In these cases, DLSw sends Receiver Not Ready (RNR) frames on its local circuits, slowing data traffic on established sessions and giving the congestion an opportunity to clear.

The core state option allows you to see when the circuit changes state. This capability is especially useful for determining why a session cannot be established or why a session is being disconnected.

The core XID option allows you to track the XID-state machine. The router tracks XID commands and responses used in negotiations between end stations before establishing a session.

Examples

The following sections show and explain some of the typical DLSw debug messages you might see when using the debug dlsw command.

The following example enables UDP packet debugging for a specific remote peer:

Router# debug dlsw peer ip-address 1.1.1.6 udp
 

The following message is sample output from the debug dlsw border-peers command:

*Mar 10 17:39:56: CSM: delete group mac cache for group 0
*Mar 10 17:39:56: CSM: delete group name cache for group 0
*Mar 10 17:40:19: CSM: update group cache for mac 0000.3072.1070, group 10
*Mar 10 17:40:22: DLSw: send_to_group_members(): copy to peer 10.19.32.5
 

The following message is from a router that initiated a TCP connection:

DLSw: START-TPFSM (peer 10.3.8.7(2065)): event:ADMIN-OPEN CONNECTION state:DISCONN
DLSw: dtp_action_a() attempting to connect peer 10.3.8.7(2065)
DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:DISCONN->WAIT_WR
DLSw: Async Open Callback 10.3.8.7(2065) -> 11002
DLSw: START-TPFSM (peer 10.3.8.7(2065)): event:TCP-WR PIPE OPENED state:WAIT_WR
DLSw: dtp_action_f() start read open timer for peer 10.3.8.7(2065)
DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:WAIT_WR->WAIT_RD
DLSw: passive open 10.3.8.7(11004) -> 2065
DLSw: START-TPFSM (peer 10.3.8.7(2065)): event:TCP-RD PIPE OPENED state:WAIT_RD
DLSw: dtp_action_g() read pipe opened for peer 10.3.8.7(2065)
DLSw: CapExId Msg sent to peer 10.3.8.7(2065)
DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:WAIT_RD->WAIT_CAP
DLSw: START-TPFSM (peer 10.3.8.7(2065)): event:SSP-CAP MSG RCVD state:WAIT_CAP
DLSw: dtp_action_j() cap msg rcvd from peer 10.3.8.7(2065)
DLSw: Recv CapExId Msg from peer 10.3.8.7(2065)
DLSw: Pos CapExResp sent to peer 10.3.8.7(2065)
DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:WAIT_CAP->WAIT_CAP
DLSw: START-TPFSM (peer 10.3.8.7(2065)): event:SSP-CAP MSG RCVD state:WAIT_CAP
DLSw: dtp_action_j() cap msg rcvd from peer 10.3.8.7(2065)
DLSw: Recv CapExPosRsp Msg from peer 10.3.8.7(2065)
DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:WAIT_CAP->WAIT_CAP
DLSw: Processing delayed event:SSP-CAP EXCHANGED - prev state:WAIT_CAP
DLSw: START-TPFSM (peer 10.3.8.7(2065)): event:SSP-CAP EXCHANGED state:WAIT_CAP
DLSw: dtp_action_k() cap xchged for peer 10.3.8.7(2065)
DLSw: closing read pipe tcp connection for peer 10.3.8.7(2065)
DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:WAIT_CAP->PCONN_WT
DLSw: Processing delayed event:TCP-PEER CONNECTED - prev state:PCONN_WT
DLSw: START-TPFSM (peer 10.3.8.7(2065)): event:TCP-PEER CONNECTED state:PCONN_WT
DLSw: dtp_action_m() peer connected for peer 10.3.8.7(2065)
DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:PCONN_WT->CONNECT
DLSw: START-TPFSM (peer 10.3.8.7(2065)): event:CORE-ADD CIRCUIT state:CONNECT
DLSw: dtp_action_u(), peer add circuit for peer 10.3.8.7(2065)
DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:CONNECT->CONNECT
 

The following message is from a router that received a TCP connection:

DLSw: passive open 10.10.10.4(11002) -> 2065
DLSw: START-TPFSM (peer 10.10.10.4(2065)): event:TCP-RD PIPE OPENED state:DISCONN
DLSw: dtp_action_c() opening write pipe for peer 10.10.10.4(2065)
DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:DISCONN->WWR_RDOP
DLSw: Async Open Callback 10.10.10.4(2065) -> 11004
DLSw: START-TPFSM (peer 10.10.10.4(2065)): event:TCP-WR PIPE OPENED state:WWR_RDOP
DLSw: dtp_action_i() write pipe opened for peer 10.10.10.4(2065)
DLSw: CapExId Msg sent to peer 10.10.10.4(2065)
DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:WWR_RDOP->WAIT_CAP
DLSw: START-TPFSM (peer 10.10.10.4(2065)): event:SSP-CAP MSG RCVD state:WAIT_CAP
DLSw: dtp_action_j() cap msg rcvd from peer 10.10.10.4(2065)
DLSw: Recv CapExId Msg from peer 10.10.10.4(2065)
DLSw: Pos CapExResp sent to peer 10.10.10.4(2065)
DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:WAIT_CAP->WAIT_CAP
DLSw: START-TPFSM (peer 10.10.10.4(2065)): event:SSP-CAP MSG RCVD state:WAIT_CAP
DLSw: dtp_action_j() cap msg rcvd from peer 10.10.10.4(2065)
DLSw: Recv CapExPosRsp Msg from peer 10.10.10.4(2065)
DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:WAIT_CAP->WAIT_CAP
DLSw: Processing delayed event:SSP-CAP EXCHANGED - prev state:WAIT_CAP
DLSw: START-TPFSM (peer 10.10.10.4(2065)): event:SSP-CAP EXCHANGED state:WAIT_CAP
DLSw: dtp_action_k() cap xchged for peer 10.10.10.4(2065)
DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:WAIT_CAP->PCONN_WT
DLSw: dlsw_tcpd_fini() for peer 10.10.10.4(2065)
DLSw: dlsw_tcpd_fini() closing write pipe for peer 10.10.10.4
DLSw: START-TPFSM (peer 10.10.10.4(2065)): event:TCP-CLOSE WR PIPE state:PCONN_WT
DLSw: dtp_action_l() close write pipe for peer 10.10.10.4(2065)
DLSw: closing write pipe tcp connection for peer 10.10.10.4(2065)
DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:PCONN_WT->PCONN_WT
DLSw: Processing delayed event:TCP-PEER CONNECTED - prev state:PCONN_WT
DLSw: START-TPFSM (peer 10.10.10.4(2065)): event:TCP-PEER CONNECTED state:PCONN_WT
DLSw: dtp_action_m() peer connected for peer 10.10.10.4(2065)
DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:PCONN_WT->CONNECT
DLSw: START-TPFSM (peer 10.10.10.4(2065)): event:CORE-ADD CIRCUIT state:CONNECT
DLSw: dtp_action_u(), peer add circuit for peer 10.10.10.4(2065)
DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:CONNECT->CONNECT
 

The following message is from a router that initiated an FST connection:

DLSw: START-FSTPFSM (peer 10.10.10.4(0)): event:ADMIN-OPEN CONNECTION state:DISCONN
DLSw: dfstp_action_a() attempting to connect peer 10.10.10.4(0)
DLSw: Connection opened for peer 10.10.10.4(0)
DLSw: CapExId Msg sent to peer 10.10.10.4(0)
DLSw: END-FSTPFSM (peer 10.10.10.4(0)): state:DISCONN->WAIT_CAP
DLSw: START-FSTPFSM (peer 10.10.10.4(0)): event:SSP-CAP MSG RCVD state:WAIT_CAP
DLSw: dfstp_action_e() cap msg rcvd for peer 10.10.10.4(0)
DLSw: Recv CapExPosRsp Msg from peer 10.10.10.4(0)
DLSw: END-FSTPFSM (peer 10.10.10.4(0)): state:WAIT_CAP->WAIT_CAP
DLSw: START-FSTPFSM (peer 10.10.10.4(0)): event:SSP-CAP MSG RCVD state:WAIT_CAP
DLSw: dfstp_action_e() cap msg rcvd for peer 10.10.10.4(0)
DLSw: Recv CapExId Msg from peer 10.10.10.4(0)
DLSw: Pos CapExResp sent to peer 10.10.10.4(0)
DLSw: END-FSTPFSM (peer 10.10.10.4(0)): state:WAIT_CAP->WAIT_CAP
DLSw: Processing delayed event:SSP-CAP EXCHANGED - prev state:WAIT_CAP
DLSw: START-FSTPFSM (peer 10.10.10.4(0)): event:SSP-CAP EXCHANGED state:WAIT_CAP
DLSw: dfstp_action_f() cap xchged for peer 10.10.10.4(0)
DLSw: END-FSTPFSM (peer 10.10.10.4(0)): state:WAIT_CAP->CONNECT
 

The following message is from a router that received an FST connection:

DLSw: START-FSTPFSM (peer 10.3.8.7(0)): event:SSP-CAP MSG RCVD state:DISCONN
DLSw: dfstp_action_c() cap msg rcvd for peer 10.3.8.7(0)
DLSw: Recv CapExId Msg from peer 10.3.8.7(0)
DLSw: Pos CapExResp sent to peer 10.3.8.7(0)
DLSw: CapExId Msg sent to peer 10.3.8.7(0)
DLSw: END-FSTPFSM (peer 10.3.8.7(0)): state:DISCONN->WAIT_CAP
DLSw: START-FSTPFSM (peer 10.3.8.7(0)): event:SSP-CAP MSG RCVD state:WAIT_CAP
DLSw: dfstp_action_e() cap msg rcvd for peer 10.3.8.7(0)
DLSw: Recv CapExPosRsp Msg from peer 10.3.8.7(0)
DLSw: END-FSTPFSM (peer 10.3.8.7(0)): state:WAIT_CAP->WAIT_CAP
DLSw: Processing delayed event:SSP-CAP EXCHANGED - prev state:WAIT_CAP
DLSw: START-FSTPFSM (peer 10.3.8.7(0)): event:SSP-CAP EXCHANGED state:WAIT_CAP
DLSw: dfstp_action_f() cap xchged for peer 10.3.8.7(0)
DLSw: END-FSTPFSM (peer 10.3.8.7(0)): state:WAIT_CAP->CONNECT
 

The following message is from a router that initiated an LLC2 connection:

DLSw-LLC2: Sending enable port ; port no : 0
           PEER-DISP Sent : CLSI Msg : ENABLE.Req   dlen: 20 
DLSw: Peer Received : CLSI Msg : ENABLE.Cfm CLS_OK dlen: 20 
DLSw-LLC2 : Sending activate sap for Serial1 - port_id = 887C3C
            port_type = 7 dgra(UsapID) = 952458
            PEER-DISP Sent : CLSI Msg : ACTIVATE_SAP.Req   dlen: 60 
DLSw: Peer Received : CLSI Msg : ACTIVATE_SAP.Cfm CLS_OK dlen: 60 
DLSw Got ActSapcnf back for Serial1 - port_id = 8978204, port_type = 7, psap_id = 0
 
DLSw: START-LLC2PFSM (peer on interface Serial1): event:ADMIN-OPEN CONNECTION state:DISCONN
DLSw: dllc2p_action_a() attempting to connect peer on interface Serial1
 PEER-DISP Sent : CLSI Msg : REQ_OPNSTN.Req   dlen: 106 
DLSw: END-LLC2PFSM (peer on interface Serial1): state:DISCONN->ROS_SENT
 
DLSw: Peer Received : CLSI Msg : REQ_OPNSTN.Cfm CLS_OK dlen: 106 
DLSw: START-LLC2PFSM (peer on interface Serial1): event:CLS-REQOPNSTN.CNF state:ROS_SENT
DLSw: dllc2p_action_c()
 PEER-DISP Sent : CLSI Msg : CONNECT.Req   dlen: 16 
DLSw: END-LLC2PFSM (peer on interface Serial1): state:ROS_SENT->CON_PEND
 
DLSw: Peer Received : CLSI Msg : CONNECT.Cfm CLS_OK dlen: 28 
DLSw: START-LLC2PFSM (peer on interface Serial1): event:CLS-CONNECT.CNF state:CON_PEND
DLSw: dllc2p_action_e() send capabilities to peer on interface Serial1
 PEER-DISP Sent : CLSI Msg : SIGNAL_STN.Req   dlen: 8 
 PEER-DISP Sent : CLSI Msg : DATA.Req   dlen: 418 
DLSw: CapExId Msg sent to peer on interface Serial1
DLSw: END-LLC2PFSM (peer on interface Serial1): state:CON_PEND->WAIT_CAP
 
DLSw: Peer Received : CLSI Msg : DATA.Ind   dlen: 418 
DLSw: START-LLC2PFSM (peer on interface Serial1): event:SSP-CAP MSG RCVD state:WAIT_CAP
DLSw: dllc2p_action_k() cap msg rcvd for peer on interface Serial1
DLSw: Recv CapExId Msg from peer on interface Serial1
 PEER-DISP Sent : CLSI Msg : DATA.Req   dlen: 96 
DLSw: Pos CapExResp sent to peer on interface Serial1
DLSw: END-LLC2PFSM (peer on interface Serial1): state:WAIT_CAP->WAIT_CAP
 
DLSw: Peer Received : CLSI Msg : DATA.Ind   dlen: 96 
DLSw: START-LLC2PFSM (peer on interface Serial1): event:SSP-CAP MSG RCVD state:WAIT_CAP
DLSw: dllc2p_action_k() cap msg rcvd for peer on interface Serial1
DLSw: Recv CapExPosRsp Msg from peer on interface Serial1
DLSw: END-LLC2PFSM (peer on interface Serial1): state:WAIT_CAP->WAIT_CAP
 
DLSw: Processing delayed event:SSP-CAP EXCHANGED - prev state:WAIT_CAP
DLSw: START-LLC2PFSM (peer on interface Serial1): event:SSP-CAP EXCHANGED state:WAIT_CAP
DLSw: dllc2p_action_l() cap xchged for peer on interface Serial1
DLSw: END-LLC2PFSM (peer on interface Serial1): state:WAIT_CAP->CONNECT
 

The following message is from a router that received an LLC2 connection:

DLSw-LLC2: Sending enable port ; port no : 0
 PEER-DISP Sent : CLSI Msg : ENABLE.Req   dlen: 20 
DLSw: Peer Received : CLSI Msg : ENABLE.Cfm CLS_OK dlen: 20 
DLSw-LLC2 : Sending activate sap for Serial0 - port_id = 887C3C
 port_type = 7 dgra(UsapID) = 93AB34
 PEER-DISP Sent : CLSI Msg : ACTIVATE_SAP.Req   dlen: 60 
DLSw: Peer Received : CLSI Msg : ACTIVATE_SAP.Cfm CLS_OK dlen: 60 
DLSw Got ActSapcnf back for Serial0 - port_id = 8944700, port_type = 7, psap_id = 0
 
DLSw: Peer Received : CLSI Msg : CONECT_STN.Ind   dlen: 39 
DLSw: START-LLC2PFSM (peer on interface Serial0): event:CLS-CONNECT_STN.IND state:DISCONN
DLSw: dllc2p_action_s() conn_stn for peer on interface Serial0
 PEER-DISP Sent : CLSI Msg : REQ_OPNSTN.Req   dlen: 106 
DLSw: END-LLC2PFSM (peer on interface Serial0): state:DISCONN->CONS_PEND
 
DLSw: Peer Received : CLSI Msg : REQ_OPNSTN.Cfm CLS_OK dlen: 106 
DLSw: START-LLC2PFSM (peer on interface Serial0): event:CLS-REQOPNSTN.CNF state:CONS_PEND
DLSw: dllc2p_action_h() send capabilities to peer on interface Serial0
 PEER-DISP Sent : CLSI Msg : CONNECT.Rsp   dlen: 20 
 PEER-DISP Sent : CLSI Msg : DATA.Req   dlen: 418 
DLSw: CapExId Msg sent to peer on interface Serial0
DLSw: END-LLC2PFSM (peer on interface Serial0): state:CONS_PEND->WAIT_CAP
 
DLSw: Peer Received : CLSI Msg : CONNECTED.Ind   dlen: 8 
DLSw: START-LLC2PFSM (peer on interface Serial0): event:CLS-CONNECTED.IND state:WAIT_CAP
DLSw: END-LLC2PFSM (peer on interface Serial0): state:WAIT_CAP->WAIT_CAP
 
DLSw: Peer Received : CLSI Msg : DATA.Ind   dlen: 418 
DLSw: START-LLC2PFSM (peer on interface Serial0): event:SSP-CAP MSG RCVD state:WAIT_CAP
DLSw: dllc2p_action_k() cap msg rcvd for peer on interface Serial0
DLSw: Recv CapExId Msg from peer on interface Serial0
 PEER-DISP Sent : CLSI Msg : DATA.Req   dlen: 96 
DLSw: Pos CapExResp sent to peer on interface Serial0
DLSw: END-LLC2PFSM (peer on interface Serial0): state:WAIT_CAP->WAIT_CAP
 
DLSw: Peer Received : CLSI Msg : DATA.Ind   dlen: 96 
DLSw: START-LLC2PFSM (peer on interface Serial0): event:SSP-CAP MSG RCVD state:WAIT_CAP
DLSw: dllc2p_action_k() cap msg rcvd for peer on interface Serial0
DLSw: Recv CapExPosRsp Msg from peer on interface Serial0
DLSw: END-LLC2PFSM (peer on interface Serial0): state:WAIT_CAP->WAIT_CAP
 
DLSw: Processing delayed event:SSP-CAP EXCHANGED - prev state:WAIT_CAP
DLSw: START-LLC2PFSM (peer on interface Serial0): event:SSP-CAP EXCHANGED state:WAIT_CAP
DLSw: dllc2p_action_l() cap xchged for peer on interface Serial0
DLSw: END-LLC2PFSM (peer on interface Serial0): state:WAIT_CAP->CONNECT
 

The following messages occur when a CUR_ex (CANUREACH explorer) frame is received from other peers, and the peer statements or the promiscuous keyword have not been enabled so that the router is not configured correctly:

22:42:44: DLSw: Not promiscuous - Rej conn from 172.20.96.1(2065)
22:42:51: DLSw: Not promiscuous - Rej conn from 172.20.99.1(2065)
 

In the following messages, the router sends a keepalive message every 30 seconds to keep the peer connected. If three keepalive messages are missed, the peer is torn down. These messages are displayed only if keepalives are enabled (by default, keepalives are disabled):

22:44:03: DLSw: Keepalive Request sent to peer 172.20.98.1(2065) (168243148)
22:44:03: DLSw: Keepalive Response from peer 172.20.98.1(2065) (168243176)
22:44:34: DLSw: Keepalive Request sent to peer 172.20.98.1(2065) (168274148)
22:44:34: DLSw: Keepalive Response from peer 172.20.98.1(2065) (168274172)
 

The following peer debug messages indicate that the local peer is disconnecting from the specified remote peer because of missed peer keepalives:

0:03:24: DLSw: keepalive failure for peer on interface Serial0
0:03:24: DLSw: action_d(): for peer on interface Serial0
0:03:24: DLSW: DIRECT aborting connection for peer on interface Serial0
0:03:24: DLSw: peer on interface Serial0, old state CONNECT, new state DISCONN
 

The following peer debug messages result from an attempt to connect to an IP address that does not have DLSw enabled. The local router attempts to connect in 30-second intervals:

23:13:22: action_a() attempting to connect peer 172.20.100.1(2065)
23:13:22: DLSw: CONN: peer 172.20.100.1 open failed, rejected [9]
23:13:22: action_a() retries: 8 next conn time: 861232504
23:13:52: action_a() attempting to connect peer 172.20.100.1(2065)
23:13:52: DLSw: CONN: peer 172.20.100.1 open failed, rejected [9]
23:13:52: action_a() retries: 9 next conn time: 861292536
 

The following peer debug messages indicates a remote-peer statement is missing on the router (address 172.20.100.1) to which the connection attempt is sent:

23:14:52: action_a() attempting to connect peer 172.20.100.1(2065)
23:14:52: DLSw: action_a(): Write pipe opened for peer 172.20.100.1(2065)
23:14:52: DLSw: peer 172.20.100.1(2065), old state DISCONN, new state WAIT_RD
23:14:52: DLSw: dlsw_tcpd_fini() closing connection for peer 172.20.100.1
23:14:52: DLSw: action_d(): for peer 172.20.100.1(2065)
23:14:52: DLSw: aborting tcp connection for peer 172.20.100.1(2065)
23:14:52: DLSw: peer 172.20.100.1(2065), old state WAIT_RD, new state DISCONN
 

The following messages show a peer connection opening with no errors or abnormal events:

23:16:37: action_a() attempting to connect peer 172.20.100.1(2065)
23:16:37: DLSw: action_a(): Write pipe opened for peer 172.20.100.1(2065)
23:16:37: DLSw: peer 172.20.100.1(2065), old state DISCONN, new state WAIT_RD
23:16:37: DLSW: passive open 172.20.100.1(17762) -> 2065
23:16:37: DLSw: action_c(): for peer 172.20.100.1(2065)
23:16:37: DLSw: peer 172.20.100.1(2065), old state WAIT_RD, new state CAP_EXG
23:16:37: DLSw: peer 172.20.100.1(2065) conn_start_time set to 861397784
23:16:37: DLSw: CapExId Msg sent to peer 172.20.100.1(2065)
23:16:37: DLSw: Recv CapExId Msg from peer 172.20.100.1(2065)
23:16:37: DLSw: Pos CapExResp sent to peer 172.20.100.1(2065)
23:16:37: DLSw: action_e(): for peer 172.20.100.1(2065)
23:16:37: DLSw: Recv CapExPosRsp Msg from peer 172.20.100.1(2065)
23:16:37: DLSw: action_e(): for peer 172.20.100.1(2065)
23:16:37: DLSw: peer 172.20.100.1(2065), old state CAP_EXG, new state CONNECT
23:16:37: DLSw: dlsw_tcpd_fini() closing write pipe for peer 172.20.100.1
23:16:37: DLSw: action_g(): for peer 172.20.100.1(2065)
23:16:37: DLSw: closing write pipe tcp connection for peer 172.20.100.1(2065)
23:16:38: DLSw: peer_act_on_capabilities() for peer 172.20.100.1(2065)
 

The following two messages show that an information frame is passing through the router:

DLSw: dlsw_tr2fct() lmac:c000.a400.0000 rmac:0800.5a29.75fe ls:5 rs:4 i:34
DLSw: dlsw_tr2fct() lmac:c000.a400.0000 rmac:0800.5a29.75fe ls:4 rs:4 i:34

Sample Debug DLSw Reachability Messages

The messages in this section are based on the following items:

• Reachability is stored in cache. DLSw+ maintains two reachability caches: one for MAC addresses and one for NetBIOS names. Depending on how long entries have been in the cache, they are either fresh or stale.

• If a router has a fresh entry in the cache for a certain resource, it answers a locate request for that resource without verifying that it is still available. A locate request is typically a TEST frame for MAC addresses or a FIND_NAME_QUERY for NetBIOS.

• If a router has a stale entry in the cache for a certain resource, it verifies that the entry is still valid before answering a locate request for the resource by sending a frame to the resource's last known location and waits for a resource. If the entry is a REMOTE entry, the router sends a CUR_ex frame to the remote peer to verify. If the entry is a LOCAL entry, it sends either a TEST frame or a NetBIOS FIND_NAME_QUERY on the appropriate local port.

• By default, all reachability cache entries remain fresh for 4 minutes after they are learned. For MAC addresses, you can change this time with the dlsw timer sna-verify-interval command. For NetBIOS names, you can change this with the dlsw timer netbios-verify-interval command.

• By default, all reachability cache entries age out of the cache 16 minutes after they are learned. For MAC addresses, you can change this time with the dlsw timer sna-cache-timeout command. For NetBIOS names, you can change the time with the dlsw timer netbios-cache-timeout command.

The following message shows that DLSw is sending an I frame to a LAN:

Dec  5 10:48:33:  DISP Sent : CLSI Msg : DATA.Req   dlen: 1086
 

The following message shows that DLSw received the I frame from the LAN:

Dec  5 10:48:35:  DLSW Received-disp : CLSI Msg : DATA.Ind   dlen: 4
 

The following messages show that the reachability cache is cleared:

Router# clear dlsw rea
 
23:44:11: CSM: Clearing CSM cache
23:44:11: CSM: delete local mac cache for port 0
23:44:11: CSM: delete local name cache for port 0
23:44:11: CSM: delete remote mac cache for peer 0
23:44:11: CSM: delete remote name cash dlsw rea
 

The next group of messages show that the DLSw reachability cache is added, and that a name query is perform from the router Marian:

23:45:11: CSM: core_to_csm CLSI_MSG_PROC - port_id 5EFBB4
23:45:11: CSM: 0800.5a30.7a9b passes local mac excl. filter
23:45:11: CSM: update local cache for mac 0800.5a30.7a9b, port 5EFBB4
23:45:11: CSM: update local cache for name MARIAN         , port 5EFBB4
23:45:11: CSM: Received CLS_UDATA_STN from Core
23:45:11: CSM: Received netbios frame type A
23:45:11: CSM: Processing Name Query
23:45:11: CSM: Netbios Name Query: ws_status = 6
23:45:11: CSM: Write to peer 0 ok.
23:45:11: CSM: Freeing clsi message
23:45:11: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB4
23:45:11: CSM: 0800.5a30.7a9b passes local mac excl. filter
23:45:11: CSM: update local cache for mac 0800.5a30.7a9b, port 658AB4
23:45:11: CSM: update local cache for name MARIAN         , port 658AB4
23:45:11: CSM: Received CLS_UDATA_STN from Core
23:45:11: CSM: Received netbios frame type A
23:45:11: CSM: Processing Name Query
23:45:11: CSM: Netbios Name Query: ws_status = 5
23:45:11: CSM: DLXNR_PEND match found.... drop name query
23:45:11: CSM: Freeing clsi message
23:45:12: CSM: core_to_csm CLSI_MSG_PROC - port_id 5EFBB4
23:45:12: CSM: 0800.5a30.7a9b passes local mac excl. filter
23:45:12: CSM: update local cache for mac 0800.5a30.7a9b, port 5EFBB4
23:45:12: CSM: update local cache for name MARIAN         , port 5EFBB4
23:45:12: CSM: Received CLS_UDATA_STN from Core
23:45:12: CSM: Received netbios frame type A
23:45:12: CSM: Processing Name Query
23:45:12: CSM: Netbios Name Query: ws_status = 5
23:45:12: CSM: DLXNR_PEND match found.... drop name query
23:45:12: CSM: Freeing clsi message
23:45:12: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB4
23:45:12: CSM: 0800.5a30.7a9b passes local mac excl. filter
23:45:12: CSM: update local cache for mac 0800.5a30.7a9b, port 658AB4
23:45:12: CSM: update local cache for name MARIAN         , port 658AB4
23:45:12: CSM: Received CLS_UDATA_STN from Core
23:45:12: CSM: Received netbios frame type A
23:45:12: CSM: Processing Name Query
23:45:12: CSM: Netbios Name Query: ws_status = 5
23:45:12: CSM: DLXNR_PEND match found.... drop name query
23:45:12: CSM: Freeing clsi message
23:45:12: CSM: core_to_csm CLSI_MSG_PROC - port_id 5EFBB4
23:45:12: CSM: 0800.5a30.7a9b passes local mac excl. filter
23:45:12: CSM: update local cache for mac 0800.5a30.7a9b, port 5EFBB4
23:45:12: CSM: update local cache for name MARIAN         , port 5EFBB4
23:45:12: CSM: Received CLS_UDATA_STN from Core
23:45:12: CSM: Received netbios frame type A
23:45:12: CSM: Processing Name Query
23:45:12: CSM: Netbios Name Query: ws_status = 5
23:45:12: CSM: DLXNR_PEND match found.... drop name query
23:45:12: CSM: Freeing clsi message
23:45:12: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB4
23:45:12: CSM: 0800.5a30.7a9b passes local mac excl. filter
23:45:12: CSM: update local cache for mac 0800.5a30.7a9b, port 658AB4
23:45:12: CSM: update local cache for name MARIAN         , port 658AB4
23:45:12: CSM: Received CLS_UDATA_STN from Core
23:45:12: CSM: Received netbios frame type A
23:45:12: CSM: Processing Name Query
23:45:12: CSM: Netbios Name Query: ws_status = 5
23:45:12: CSM: DLXNR_PEND match found.... drop name query
23:45:12: CSM: Freeing clsi message
23:45:18: CSM: Deleting Reachability cache
23:45:18: CSM: Deleting DLX NR pending record....
23:45:38: CSM: core_to_csm CLSI_MSG_PROC - port_id 5EFBB4
23:45:38: CSM: 0800.5a30.7a9b passes local mac excl. filter
23:45:38: CSM: update local cache for mac 0800.5a30.7a9b, port 5EFBB4
23:45:38: CSM: update local cache for name MARIAN         , port 5EFBB4
23:45:38: CSM: Received CLS_UDATA_STN from Core
23:45:38: CSM: Received netbios frame type 8
23:45:38: CSM: Write to peer 0 ok.
23:45:38: CSM: Freeing clsi message
23:45:38: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB4
23:45:38: CSM: 0800.5a30.7a9b passes local mac excl. filter
23:45:38: CSM: update local cache for mac 0800.5a30.7a9b, port 658AB4
23:45:38: CSM: update local cache for name MARIAN         , port 658AB4
23:45:38: CSM: Received CLS_UDATA_STN from Core
23:45:38: CSM: Received netbios frame type 8
23:45:38: CSM: Write to peer 0 ok.
23:45:38: CSM: Freeing clsi message
 

The following messages show that Marian is added to the network:

23:45:38: CSM: core_to_csm CLSI_MSG_PROC - port_id 5EFBB4
23:45:38: CSM: 0800.5a30.7a9b passes local mac excl. filter
23:45:38: CSM: update local cache for mac 0800.5a30.7a9b, port 5EFBB4
23:45:38: CSM: update local cache for name MARIAN         , port 5EFBB4
23:45:38: CSM: Received CLS_UDATA_STN from Core
23:45:38: CSM: Received netbios frame type 8
23:45:38: CSM: Write to peer 0 ok.
23:45:38: CSM: Freeing clsi message
23:45:38: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB4
23:45:38: CSM: 0800.5a30.7a9b passes local mac excl. filter
23:45:38: CSM: update local cache for mac 0800.5a30.7a9b, port 658AB4
23:45:38: CSM: update local cache for name MARIAN         , port 658AB4
23:45:38: CSM: Received CLS_UDATA_STN from Core
23:45:38: CSM: Received netbios frame type 8
23:45:38: CSM: Write to peer 0 ok.
23:45:38: CSM: Freeing clsi message
 

In the next group of messages, an attempt is made to add the router Ginger on the Ethernet:

0:07:44: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB4
0:07:44: CSM: 0004.f545.24e6 passes local mac excl. filter
0:07:44: CSM: update local cache for mac 0004.f545.24e6, port 658AB4
0:07:44: CSM: update local cache for name GINGER         , port 658AB4
0:07:44: CSM: Received CLS_UDATA_STN from Core
0:07:44: CSM: Received netbios frame type 8
0:07:44: CSM: Write to peer 0 ok.
 

In the following example, the output from the show dlsw reachability command indicates that Ginger is on the Ethernet interface and Marian is on the Token Ring interface:

G41# show dlsw reachability
 
DLSw MAC address reachability cache list
Mac Addr        status     Loc.    peer/port            rif
0004.f545.24e6  FOUND      LOCAL   P007-S000    --no rif--
0800.5a30.7a9b  FOUND      LOCAL   P000-S000    06C0.0621.7D00
                                   P007-S000    F0F8.0006.A6FC.005F.F100.0000.0000.0000
 
DLSw NetBIOS Name reachability cache list
NetBIOS Name    status     Loc.    peer/port            rif
GINGER          FOUND      LOCAL   P007-S000     --no rif--
MARIAN          FOUND      LOCAL   P000-S000     06C0.0621.7D00
                                   P007-S000     --no rif--
 

Syntax Description

This command has no arguments or keywords.

Defaults

Debugging is disabled for DRiP events.

Command History

Release	Modification
11.3(4)T	This command was introduced.

Usage Guidelines

When a TrBRF interface is configured on the RSM, the DRiP protocol is activated. The DRiP protocol adds the VLAN ID specified in the router command to its database and recognizes the VLAN as a locally configured, active VLAN.

Examples

Following examples show output for the debug drip event command.

DRiP gets a packet from the network:

612B92C0: 01000C00 00000000 0C501900 0000AAAA  .........P....**
612B92D0: 0300000C 00020000 00000100 0CCCCCCC  .............LLL
612B92E0: 00000C50 19000020 AAAA0300 000C0102  ...P... **......
612B92F0: 01010114 00000002 00000002 00000C50  ...............P
612B9300: 19000001 04C00064 04                 .....@.d.       
 

DRiP gets a packet from the network:

Recvd. pak
 

DRiP recognizes that the VLAN ID it is getting is a new one from the network:

6116C840:                       0100 0CCCCCCC            ...LLL
6116C850: 00102F72 CBFB0024 AAAA0300 000C0102  ../rK{.$**......
6116C860: 01FF0214 0002E254 00015003 00102F72  ......bT..P.../r
6116C870: C8000010 04C00014 044003EB 14        H....@...@.k. 
DRIP : remote update - Never heard of this vlan
 

DRiP attempts to resolve any conflicts when it hears of a new VLAN. The value action = 1 means to notify the local platform of change in state:

DRIP : resolve remote for vlan 20 in VLAN0
DRIP : resolve remote - action = 1
 

The local platform is notified of change in state:

DRIP Change notification active vlan 20

Another new VLAN ID was received in the packet:

DRIP : resolve remote for vlan 1003 in Vlan0
 

No action is required:

DRIP : resolve remote - action = 0
 

Thirty seconds have expired, and DRiP sends its local database entries to all its trunk ports:

DRIP : local timer expired
DRIP : transmit on 0000.0c50.1900, length = 24
612B92C0: 01000C00 00000000 0C501900 0000AAAA  .........P....**
612B92D0: 0300000C 00020000 00000100 0CCCCCCC  .............LLL
612B92E0: 00000C50 19000020 AAAA0300 000C0102  ...P... **......
612B92F0: 01FF0114 00000003 00000002 00000C50  ...............P
612B9300: 19000001 04C00064 04                 .....@.d. 

Syntax Description

This command has no arguments or keywords.

Defaults

Debugging is not enabled for DRiP packets.

Command History

Release	Modification
11.3(4)T	This command was introduced.

Usage Guidelines

Before you use this command, you can optionally use the clear drip command first. As a result the DRiP counters are reset to 0. If the DRiP counters begin to increment, the router is receiving packets.

Examples

Following is sample output for the debug drip packet command.

The following type of output is displayed when a packet is entering the router and you use the show debug command:

039E5FC0:     0100 0CCCCCCC 00E0A39B 3FFB0028    ...LLL.\Q#.?{.(
039E5FD0: AAAA0300 000C0102 01FF0314 0000A5F6  **............%v
039E5FE0: 00008805 00E0A39B 3C000000 04C00028  .....\Q#.<....@.(
039E5FF0: 04C00032 044003EB 0F                 .@.2.@.k.       
039FBD20:                   01000C00 00000010          ........
 

The following type of output is displayed when a packet is transmitted by the router:

039FBD30: A6AEB450 0000AAAA 0300000C 00020000  &.4P..**........
039FBD40: 00000100 0CCCCCCC 0010A6AE B4500020  .....LLL..&.4P. 
039FBD50: AAAA0300 000C0102 01FF0114 00000003  **..............
039FBD60: 00000002 0010A6AE B4500001 04C00064  ......&.4P...@.d
039FBD70: 04                                   . 

Related Commands

Command	Description
debug drip event	Displays debug messages for DRIP events.

Syntax Description

This command was no arguments or keywords.

Command History

Release	Modification
11.3(2)AA	This command was introduced.

Usage Guidelines

The debug dsc clock command displays TDM clock switching events on the dial shelf controller. The information displayed includes the following:

• Clock configuration messages received from trunks via the bus

• Dial shelf controller clock configuration messages from the router shelf over the dial shelf interface link

• Clock switchover algorithm events

Examples

The following example shows that the debug dsc clock command has been enabled, that trunk messages are received, and that the configuration message has been received:

AS5800# debug dsc clock
Dial Shelf Controller Clock debugging is on
AS5800#
00:02:55: Clock Addition msg of len 12 priority 8 from slot 1 port 1 on line 0
00:02:55: Trunk 1 has reloaded

Related Commands

Command	Description
show dsc clock	Displays information about the dial shelf controller clock.

Syntax Description

all	View all DSIP messages.
api	View DSIP client interface (API) messages.
boot	View DSIP booting messages that are generated when a download of the feature board image is occurring properly.
console	View DSIP console operation.
trace	Enable logging of header information concerning DSIP packets entering the system in a trace buffer.
transport	Debug the DSIP transport layer, the module that interacts with the underlying physical media driver.

Command History

Release	Modification
11.3(2)AA	This command was introduced.

Usage Guidelines

The debug dsip command is used to display messages for DSIP between the router shelf and the dial shelf. Using this command, you can display booting messages generated when the download of an image occurs, view console operation, trace logging of MAC header information, and view DSIP transport layer information as modules interact with the underlying physical media driver. This command can be applied to a single modem or a group of modems.

Once the debug dsip trace command is enabled, you can read the information captured in the trace buffer using the show dsip tracing command.

Examples

The following example shows the available debug dsip command options:

AS5800# debug dsip ?
  all        All DSIP debugging messages
  api        DSIP API debugging
  boot       DSIP booting
  console    DSIP console
  trace      DSIP tracing
  transport  DSIP transport

The following example indicates the debug dsip trace command logs MAC headers of the various classes of DSIP packets. View the logged information using the show dsip tracing command.

AS5800# debug dsip trace
NIP tracing debugging is on
AS5800# show dsip tracing
NIP Control Packet Trace
------------------------------------------------------------
Dest:00e0.b093.2238 Src:0007.4c72.0058 Type:200B SrcShelf:1 SrcSlot:11
MsgType:0 MsgLen:82 Timestamp: 00:49:14
------------------------------------------------------------
Dest:00e0.b093.2238 Src:0007.4c72.0028 Type:200B SrcShelf:1 SrcSlot:5
MsgType:0 MsgLen:82 Timestamp: 00:49:14
------------------------------------------------------------

Related Commands

Command	Description
debug modem dsip	Displays output for modem control messages that are received or sent to the router.

Syntax Description

name	(Optional) Host or PU name designation.

Usage Guidelines

The debug dspu activation command displays all DSPU activation traffic. To restrict the output to a specific host or physical unit (PU), include the host or PU name argument. You cannot turn off debugging output for an individual PU if that PU has not been named in the debug dspu activation command.

Examples

The following is sample output from the debug dspu activation command. Not all intermediate numbers are shown for the "activated" and "deactivated" logical unit (LU) address ranges.

Router# debug dspu activation 
 
DSPU: LS HOST3745 connected
DSPU: PU HOST3745 activated
DSPU: LU HOST3745-2 activated
DSPU: LU HOST3745-3 activated
...
DSPU: LU HOST3745-253 activated
DSPU: LU HOST3745-254 activated
 
DSPU: LU HOST3745-2 deactivated
DSPU: LU HOST3745-3 deactivated
...
DSPU: LU HOST3745-253 deactivated
DSPU: LU HOST3745-254 deactivated
DSPU: LS HOST3745 disconnected
DSPU: PU HOST3745 deactivated
 

Related Commands

Command	Description
debug dspu packet	Displays information on DSPU packet.
debug dspu state	Displays information on DSPU FSM state changes.
debug dspu trace	Displays information on DSPU trace activity.

Syntax Description

name	(Optional) Host or PU name designation.

Usage Guidelines

The debug dspu packet command displays all DSPU packet data flowing through the router. To restrict the output to a specific host or PU, include the host or PU name argument. You cannot turn off debugging output for an individual PU if that PU has not been named in the debug dspu packet command.

Examples

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

Router# debug dspu packet 
 
DSPU: Rx: PU HOST3745 data length 12 data:
    2D0003002BE16B80 000D0201
DSPU: Tx: PU HOST3745 data length 25 data:
    2D0000032BE1EB80 000D020100850000 000C060000010000 00
DSPU: Rx: PU HOST3745 data length 12 data:
    2D0004002BE26B80 000D0201
DSPU: Tx: PU HOST3745 data length 25 data:
    2D0000042BE2EB80 000D020100850000 000C060000010000 00
 

Related Commands

Command	Description
debug drip event	Displays debug messages for DRiP packets.
debug dspu state	Displays information on DSPU FSM state changes.
debug dspu trace	Displays information on DSPU trace activity.

Syntax Description

name	(Optional) Host or PU name designation.

Usage Guidelines

Use the debug dspu state command to display only the FSM state changes. To see all FSM activity, use the debug dspu trace command. You cannot turn off debugging output for an individual PU if that PU has not been named in the debug dspu state command.

Examples

The following is sample output from the debug dspu state command. Not all intermediate numbers are shown for the "activated" and "deactivated" logical unit (LU) address ranges.

Router# debug dspu state 
 
DSPU: LS HOST3745: input=StartLs, Reset -> PendConOut
DSPU: LS HOST3745: input=ReqOpn.Cnf, PendConOut -> Xid
DSPU: LS HOST3745: input=Connect.Ind, Xid -> ConnIn
DSPU: LS HOST3745: input=Connected.Ind, ConnIn -> Connected
DSPU: PU HOST3745: input=Actpu, Reset -> Active
DSPU: LU HOST3745-2: input=uActlu, Reset -> upLuActive
DSPU: LU HOST3745-3: input=uActlu, Reset -> upLuActive
... 
DSPU: LU HOST3745-253: input=uActlu, Reset -> upLuActive
DSPU: LU HOST3745-254: input=uActlu, Reset -> upLuActive
 
DSPU: LS HOST3745: input=PuStopped, Connected -> PendDisc
DSPU: LS HOST3745: input=Disc.Cnf, PendDisc -> PendClose
DSPU: LS HOST3745: input=Close.Cnf, PendClose -> Reset
DSPU: PU HOST3745: input=T2ResetPu, Active -> Reset
DSPU: LU HOST3745-2: input=uStopLu, upLuActive -> Reset
DSPU: LU HOST3745-3: input=uStopLu, upLuActive -> Reset
... 
DSPU: LU HOST3745-253: input=uStopLu, upLuActive -> Reset
DSPU: LU HOST3745-254: input=uStopLu, upLuActive -> Reset
 

Related Commands

Command	Description
debug drip event	Displays debug messages for DRiP packets.
debug drip packet	Displays information on DSPU packet.
debug dspu trace	Displays information on DSPU trace activity.

Syntax Description

name	Host or PU name designation.

Usage Guidelines

Use the debug dspu trace command to display all FSM state changes. To see FSM state changes only, use the debug dspu state command. You cannot turn off debugging output for an individual PU if that PU has not been named in the debug dspu trace command.

Examples

The following is sample output from the debug dspu trace command:

Router# debug dspu trace 
 
DSPU: LS HOST3745 input = 0 ->(1,a1)
DSPU: LS HOST3745 input = 5 ->(5,a6)
DSPU: LS HOST3745 input = 7 ->(5,a9)
DSPU: LS HOST3745 input = 9 ->(5,a28)
DSPU: LU HOST3745-2 in:0 s:0->(2,a1)
DSPU: LS HOST3745 input = 19 ->(8,a20)
DSPU: LS HOST3745 input = 18 ->(8,a17)
DSPU: LU HOST3745-3 in:0 s:0->(2,a1)
DSPU: LS HOST3745 input = 19 ->(8,a20)
DSPU: LS HOST3745 input = 18 ->(8,a17)
DSPU: LU HOST3745-252 in:0 s:0->(2,a1)
DSPU: LS HOST3745 input = 19 ->(8,a20)
DSPU: LS HOST3745 input = 18 ->(8,a17)
DSPU: LU HOST3745-253 in:0 s:0->(2,a1)
DSPU: LS HOST3745 input = 19 ->(8,a20)
DSPU: LS HOST3745 input = 18 ->(8,a17)
DSPU: LU HOST3745-254 in:0 s:0->(2,a1)
DSPU: LS HOST3745 input = 19 ->(8,a20)
 

Related Commands

Command	Description
debug drip event	Displays debug messages for DRiP packets.
debug drip packet	Displays information on DSPU packet.
debug dspu state	Displays information on DSPU FSM state changes.

Syntax Description

This command has no arguments or keywords.

Defaults

Debugging is not enabled.

Command History

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

Examples

The following displays sample output from the debug dss ipx event command:

Router# debug dss ipx event
DSS IPX events debugging is on

Router# conf t
Enter configuration commands, one per line.  End with CNTL/Z.

Router(config)# int vlan 22
Router(config-if)# ipx access-group 800 out
05:51:36:DSS-feature:dss_ipxcache_version():idb:NULL, reason:42,
prefix:0, mask:FFFFFFFF
05:51:36:DSS-feature:dss_ipx_access_group():idb:Vlan22
05:51:36:DSS-feature:dss_ipx_access_list()
05:51:36:DSS-base 05:51:33.834 dss_ipx_invalidate_interface Vl22
05:51:36:DSS-base 05:51:33.834 dss_set_ipx_flowmask_reg 2
05:51:36:%IPX mls flowmask transition from 1 to 2 due to new status of
simple IPX access list on interfaces

Related Commands

Command	Description
debug mls rp	Displays various MLS debugging elements.

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

This command helps you observe Enhanced IGRP feasible successor activity and to determine whether route updates are being installed and deleted by the routing process.

Examples

The following is sample output from the debug eigrp fsm command:

Router# debug eigrp fsm
 
DUAL: dual_rcvupdate(): 172.25.166.0 255.255.255.0 via 0.0.0.0 metric 750080/0
DUAL: Find FS for dest 172.25.166.0 255.255.255.0. FD is 4294967295, RD is 42949
67295 found
DUAL: RT installed 172.25.166.0 255.255.255.0 via 0.0.0.0
DUAL: dual_rcvupdate(): 192.168.4.0 255.255.255.0 via 0.0.0.0 metric 4294967295/
4294967295
DUAL: Find FS for dest 192.168.4.0 255.255.255.0. FD is 2249216, RD is 2249216
DUAL:   0.0.0.0 metric 4294967295/4294967295not found Dmin is 4294967295
DUAL: Dest 192.168.4.0 255.255.255.0 not entering active state.
DUAL: Removing dest 192.168.4.0 255.255.255.0, nexthop 0.0.0.0
DUAL: No routes. Flushing dest 192.168.4.0 255.255.255.0
 

In the first line, DUAL stands for diffusing update algorithm. It is the basic mechanism within Enhanced IGRP that makes the routing decisions. The next three fields are the Internet address and mask of the destination network and the address through which the update was received. The metric field shows the metric stored in the routing table and the metric advertised by the neighbor sending the information. "Metric... inaccessible" usually means that the neighbor router no longer has a route to the destination, or the destination is in hold-down.

In the following output, Enhanced IGRP is attempting to find a feasible successor for the destination. Feasible successors are part of the DUAL loop avoidance methods. The FD field contains more loop avoidance state information. The RD field is the reported distance, which is the metric used in update, query or reply packets.

The indented line with the "not found" message means a feasible successor (FS) was not found for 192.168.4.0 and EIGRP must start a diffusing computation. This means it begins to actively probe (sends query packets about destination 192.168.4.0) the network looking for alternate paths to 192.164.4.0.

DUAL: Find FS for dest 192.168.4.0 255.255.255.0. FD is 2249216, RD is 2249216
DUAL:   0.0.0.0 metric 4294967295/4294967295not found Dmin is 4294967295
 

The following output indicates the route DUAL successfully installed into the routing table:

DUAL: RT installed 172.25.166.0 255.255.255.0 via 0.0.0.0
 

The following output shows that no routes were discovered to the destination and the route information is being removed from the topology table:

DUAL: Dest 192.168.4.0 255.255.255.0 not entering active state.
DUAL: Removing dest 192.168.4.0 255.255.255.0, nexthop 0.0.0.0
DUAL: No routes. Flushing dest 192.168.4.0 255.255.255.0

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

Examples

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

Router# debug eigrp packet
 
EIGRP: Sending HELLO on Ethernet0/1
       AS 109, Flags 0x0, Seq 0, Ack 0
EIGRP: Sending HELLO on Ethernet0/1
       AS 109, Flags 0x0, Seq 0, Ack 0
EIGRP: Sending HELLO on Ethernet0/1
       AS 109, Flags 0x0, Seq 0, Ack 0
EIGRP: Received UPDATE on Ethernet0/1 from 192.195.78.24,
       AS 109, Flags 0x1, Seq 1, Ack 0
EIGRP: Sending HELLO/ACK on Ethernet0/1 to 192.195.78.24,
       AS 109, Flags 0x0, Seq 0, Ack 1
EIGRP: Sending HELLO/ACK on Ethernet0/1 to 192.195.78.24,
       AS 109, Flags 0x0, Seq 0, Ack 1
EIGRP: Received UPDATE on Ethernet0/1 from 192.195.78.24,
       AS 109, Flags 0x0, Seq 2, Ack 0
 

The output shows transmission and receipt of Enhanced IGRP packets. These packet types may be HELLO, UPDATE, REQUEST, QUERY, or REPLY packets. The sequence and acknowledgment numbers used by the Enhanced IGRP reliable transport algorithm are shown in the output. Where applicable, the network layer address of the neighboring router is also included.

Syntax Description

This command has no arguments or keywords.

Examples

The following is sample output from the debug fddi smt-packets command. In this example, an SMT frame has been output by Fiber Distributed Data Interface (FDDI) 1/0. The SMT frame is a next station addressing (NSA) neighbor information frame (NIF) request frame with the parameters as shown.

Router# debug fddi smt-packets 
 
SMT O: Fddi1/0, FC=NSA, DA=ffff.ffff.ffff, SA=00c0.eeee.be04, 
 class=NIF, type=Request, vers=1, station_id=00c0.eeee.be04, len=40
 - code 1, len 8 -- 000000016850043F
 - code 2, len 4 -- 00010200
 - code 3, len 4 -- 00003100
 - code 200B, len 8 -- 0000000100000000
 

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

This command helps you analyze the packets that have been received. However, because the debug frame-relay command generates a lot of output, only use it when traffic on the Frame Relay network is less than 25 packets per second.

Examples

The following is sample output from the debug frame-relay command:

Router# debug frame-relay
 
Serial0(i): dlci 500(0x7C41), pkt type 0x809B, datagramsize 24
Serial1(i): dlci 1023(0xFCF1), pkt type 0x309, datagramsize 13
Serial0(i): dlci 500(0x7C41), pkt type 0x809B, datagramsize 24
Serial1(i): dlci 1023(0xFCF1), pkt type 0x309, datagramsize 13
Serial0(i): dlci 500(0x7C41), pkt type 0x809B, datagramsize 24
 

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

The debug frame-relay callcontrol command is used specifically for observing FRF.4/Q.933 signaling messages and related state changes. The FRF.4/Q.933 specification describes a state machine for call control. The signaling code implements the state machine. The debug statements display the actual event and state combinations.

The Frame Relay switched virtual circuit (SVC) signaling subsystem is an independent software module. When used with the debug frame-relay networklayerinterface command, the debug frame-relay callcontrol command provides a better understanding of the call setup and teardown sequence. The debug frame-relay networklayerinterface command provides the details of the interactions between the signaling subsystem on the router and the Frame Relay subsystem.

Examples

The following state changes can be observed during a call setup on the calling party side. The debug frame-relay networklayerinterface command shows the following state changes or transitions:

STATE_NULL -> STATE_CALL_INITIATED -> STATE_CALL_PROCEEDING->STATE_ACTIVE 
 

The following messages are samples of output generated during a call setup on the calling side:

6d20h: U0_SetupRequest: Serial0
6d20h: L3SDL: Ref: 1, Init: STATE_NULL, Rcvd: SETUP_REQUEST, Next: STATE_CALL_INITIATED 6d20h: U1_CallProceeding: Serial0
6d20h: L3SDL: Ref: 1, Init: STATE_CALL_INITIATED, Rcvd: MSG_CALL_PROCEEDING, Next:
     STATE_CALL_PROCEEDING
6d20h: U3_Connect: Serial0
6d20h: L3SDL: Ref: 1, Init: STATE_CALL_PROCEEDING, Rcvd: MSG_CONNECT, Next: STATE_ACTIVE 6d20h:
 

The following messages are samples of output generated during a call setup on the called party side. Note the following state transitions as the call goes to the active state:

STATE_NULL -> STATE_CALL_PRESENT-> STATE_INCOMING_CALL_PROCEEDING->STATE_ACTIVE 
 
1w4d: U0_Setup: Serial2/3
1w4d: L3SDL: Ref: 32769, Init: STATE_NULL, Rcvd: MSG_SETUP, Next: STATE_CALL_PRESENT 1w4d: L3SDL: Ref: 32769, Init: STATE_CALL_PRESENT, Rcvd: MSG_SETUP, Next:
     STATE_INCOMING_CALL_PROC 1w4d: L3SDL: Ref: 32769, Init: STATE_INCOMING_CALL_PROC,
     Rcvd: MSG_SETUP, Next: STATE_ACTIVE 
 

Related Commands

Command	Description
debug frame-relay	Displays debugging information about the packets that are received on a Frame Relay interface.
debug frame-relay networklayerinterface	Displays NLI information.

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

Note Because the debug frame-relay events command does not generate much output, you can use it at any time, even during periods of heavy traffic, without adversely affecting other users on the system.

Examples

The following is sample output from the debug frame-relay events command:

Router# debug frame-relay events
 
Serial2(i): reply rcvd 172.16.170.26 126
Serial2(i): reply rcvd 172.16.170.28 128
Serial2(i): reply rcvd 172.16.170.34 134
Serial2(i): reply rcvd 172.16.170.38 144
Serial2(i): reply rcvd 172.16.170.41 228
Serial2(i): reply rcvd 172.16.170.65 325
 

As the output shows, debug frame-relay events returns one specific message type. The first line, for example, indicates that IP address 172.16.170.26 sent a Frame Relay ARP reply; this packet was received as input on the Serial2 interface. The last field (126) is the data-link connection identifier (DLCI) to use when communicating with the responding router.

Syntax Description

event	(Optional) Displays event or error messages related to Frame Relay fragmentation.
interface	(Optional) Displays fragments received or transmitted on the specified interface.
type	(Optional) Interface type for which you wish to display fragments received and/or transmitted.
number	(Optional) Interface number.
dlci	(Optional) DLCI value of the PVC for which you wish to display fragments received and/or transmitted.

Command History

Release	Modification
12.0(3)XG	This command was introduced.

Usage Guidelines

This command will display event or error messages related to Frame Relay fragmentation; it is only enabled at the PVC level on the selected interface.

This command is not supported on the Cisco MC3810 for fragments received by a PVC configured via the voice-encap command.

Examples

The following example shows sample output from the debug frame-relay fragment command:

router# debug frame-relay fragment interface serial 0/0 109
This may severely impact network performance.
You are advised to enable 'no logging console debug'. Continue?[confirm]
Frame Relay fragment/packet debugging is on
Displaying fragments/packets on interface Serial0/0  dlci 109 only
 
 
Serial0/0(i): dlci 109, rx-seq-num 126, exp_seq-num 126, BE bits set, frag_hdr 04 C0 7E 
 
Serial0/0(o): dlci 109, tx-seq-num 82, BE bits set, frag_hdr 04 C0 52 
 

The following example shows sample output from the debug frame-relay fragment event command:

router# debug frame-relay fragment event 
This may severely impact network performance.
You are advised to enable 'no logging console debug'. Continue?[confirm]
Frame Relay fragment event/errors debugging is on
 
Frame-relay reassembled packet is greater than MTU size, packet dropped on serial 0/0
      dlci 109
 
Unexpected B bit  frame rx on serial0/0 dlci 109, dropping pending segments
 
Rx an out-of-sequence packet on serial 0/0 dlci 109, seq_num_received 17
      seq_num_expected 19

Related Commands

Command	Description
debug ccfrf11 session	Displays the ccfrf11 function calls during call setup and teardown.
debug ccswvoice vofr-debug	Displays the ccswvoice function calls during call setup and teardown.
debug ccswvoice vofr-session	Displays the ccswvoice function calls during call setup and teardown.
debug voice vofr	Shows Cisco trunk and FRF.11 trunk call setup attempts; shows which dial peer is used in the call setup.
debug vpm port	Shows the behavior of the Holst state machine.
debug vtsp port	Shows the behavior of the VTSP state machine.
debug vtsp vofr subframe	Displays the first 10 bytes (including header) of selected VoFR subframes for the interface.

Syntax Description

This command has no arguments or keywords.

Examples

The following is sample output from the shows the display message returned in response to the debug frame-relay fragment command:

Router# debug frame-relay foresight
 
FR rate control for DLCI 17 due to ForeSight msg
 

This message indicates the router learned from the ForeSight message that DLCI 17 is now experiencing congestion. The output rate for this circuit should be slowed down, and in the router this DLCI is configured to adapt traffic shaping in response to foresight messages.

Related Commands

Command	Description
show frame-relay pvc	Displays statistics about PVCs for Frame Relay interfaces.

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

Within the FRF.4/Q.933 signaling specification, messages are divided into subunits called information elements. Each information element defines parameters specific to the call. These parameters can be values configured on the router, or values requested from the network.

The debug frame-relay informationelements command shows the signaling message in hexadecimal. Use this command to determine parameters being requested and granted for a call.

Note Use the debug frame-relay informationelements command when the debug frame-relay callcontrol command offers no clues as to why calls are not being set up.

Caution The debug frame-relay informationelements command displays a large amount of information in bytes. You must be familiar with FRF.4/Q.933 to decode the information contained within the debug output.

Examples

The following is sample output from the debug frame-relay informationelements command. In this example, each information element has a length associated with it. For those with odd-numbered lengths, only the specified bytes are valid, and the extra byte is invalid. For example, in the message "Call Ref, length: 3, 0x0200 0x0100," only "02 00 01" is valid, the last "00" is invalid.

lw0d# debug frame-relay informationelements
 
1w0d: Outgoing MSG_SETUP
 
1w0d: Dir: U --> N, Type: Prot Disc, length: 1, 0x0800 
1w0d: Dir: U --> N, Type: Call Ref, length: 3, 0x0200 0x0100 
1w0d: Dir: U --> N, Type: Message type, length: 1, 0x0500 
1w0d: Dir: U --> N, Type: Bearer Capability, length: 5, 0x0403 0x88A0 0xCF00 
1w0d: Dir: U --> N, Type: DLCI, length: 4, 0x1902 0x46A0 
1w0d: Dir: U --> N, Type: Link Lyr Core, length: 27, 0x4819 0x090B 0x5C0B 0xDC0A
1w0d:                  0x3140 0x31C0 0x0B21 0x4021
1w0d:                  0xC00D 0x7518 0x7598 0x0E09
1w0d:                  0x307D 0x8000
1w0d: Dir: U --> N, Type: Calling Party, length: 12, 0x6C0A 0x1380 0x3837 0x3635
1w0d:                  0x3433 0x3231
1w0d: Dir: U --> N, Type: Calling Party Subaddr, length: 4, 0x6D02 0xA000 
1w0d: Dir: U --> N, Type: Called Party, length: 11, 0x7009 0x9331 0x3233 0x3435 
1w0d:                  0x3637 0x386E
1w0d: Dir: U --> N, Type: Called Party Subaddr, length: 4, 0x7102 0xA000 
1w0d: Dir: U --> N, Type: Low Lyr Comp, length: 5, 0x7C03 0x88A0 0xCE65 
1w0d: Dir: U --> N, Type: User to User, length: 4, 0x7E02 0x0000 
 

Related Commands

Command	Description
debug frame-relay callcontrol	Displays Frame Relay layer 3 (network layer) call control information.

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

Use the debug frame-relay lapf command to troubleshoot the data-link control portion of layer 2 that runs over data-link connection identifier (DLCI) 0. Use this command only if you have a problem bringing up layer 2. You can use the show interface serial command to determine the status of layer 2. If it shows a Link Access Procedure, Frame Relay (LAPF) state of down-layer 2 has a problem.

Examples

The following is sample output from the debug frame-relay lapf command. In this example, a line being brought up indicates an exchange of set asynchronous balanced mode extended (SAMBE) and unnumbered acknowledgment (UA) commands. A SABME is initiated by both sides, and a UA is the response. Until the SABME gets a UA response, the line is not declared to be up. The p/f value indicates the poll/final bit setting. TX means send, and RX means receive.

1w0d# debug frame-relay lapf
 
1w0d: *LAPF Serial0 TX -> SABME Cmd p/f=1 
1w0d: *LAPF Serial0 Enter state 5
1w0d: *LAPF Serial0 RX <- UA Rsp p/f=1
1w0d: *LAPF Serial0 lapf_ua_5
1w0d: *LAPF Serial0 Link up!
1w0d: *LAPF Serial0 RX <- SABME Cmd p/f=1 
1w0d: *LAPF Serial0 lapf_sabme_78
1w0d: *LAPF Serial0 TX -> UA Rsp p/f=1
 

In the following example, a line in an up LAPF state should see a steady exchange of RR (receiver ready) messages. TX means send, RX means receive, and N(R) indicates the receive sequence number.

1w0d# debug frame-relay lapf
 
1w0d: *LAPF Serial0 T203 expired, state = 7 
1w0d: *LAPF Serial0 lapf_rr_7
1w0d: *LAPF Serial0 TX -> RR Rsp p/f=1, N(R)= 3 
1w0d: *LAPF Serial0 RX <- RR Cmd p/f=1, N(R)= 3 
1w0d: *LAPF Serial0 lapf_rr_7
1w0d: *LAPF Serial0 TX -> RR Rsp p/f=1, N(R)= 3 
1w0d: *LAPF Serial0 RX <- RR Cmd p/f=1, N(R)= 3 
1w0d: *LAPF Serial0 lapf_rr_7

Syntax Description

interface name

(Optional) Name of interface.

Usage Guidelines

You can use this command to determine whether the router and the Frame Relay switch are sending and receiving LMI packets properly.

Note Because the debug frame-relay lmi command does not generate much output, you can use it at any time, even during periods of heavy traffic, without adversely affecting other users on the system.

Examples

The following is sample output from the debug frame-relay lmi command:

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

The Frame Relay SVC signaling subsystem is decoupled from the rest of the router code by means of the Network Layer Interface intermediate software layer.

The debug frame-relay networklayerinterface command shows what happens within the network layer interface when a call is set up or torn down. All output that contains an NL relate to the interaction between the Q.933 signaling subsystem and the Network Layer Interface.

Note The debug frame-relay networklayerinterface command has no significance to anyone who is not familiar with the inner workings of the Cisco IOS software. This command is typically used by service personnel to debug problem situations.

Examples

The following is sample output from the debug frame-relay networklayerinterface command. This example displays the output generated when a call is set up. The second example shows the output generated when a call is torn down.

1w0d# debug frame-relay networklayerinterface
 
1w0d: NLI STATE: L3_CALL_REQ, Call ID 1 state 0 
1w0d: NLI: Walking the event table 1
1w0d: NLI: Walking the event table 2
1w0d: NLI: Walking the event table 3
1w0d: NLI: Walking the event table 4
1w0d: NLI: Walking the event table 5
1w0d: NLI: Walking the event table 6
1w0d: NLI: Walking the event table 7
1w0d: NLI: Walking the event table 8
1w0d: NLI: Walking the event table 9
1w0d: NLI: NL0_L3CallReq
1w0d: NLI: State: STATE_NL_NULL, Event: L3_CALL_REQ, Next: STATE_L3_CALL_REQ 
1w0d: NLI: Enqueued outgoing packet on holdq 
1w0d: NLI: Map-list search: Found maplist bermuda 
1w0d: daddr.subaddr 0, saddr.subaddr 0, saddr.subaddr 0 
1w0d: saddr.subaddr 0, daddr.subaddr 0, daddr.subaddr 0 
1w0d: nli_parameter_negotiation
1w0d: NLI STATE: NL_CALL_CNF, Call ID 1 state 10 
1w0d: NLI: Walking the event table 1
1w0d: NLI: Walking the event table 2
1w0d: NLI: Walking the event table 3
1w0d: NLI: NLx_CallCnf
1w0d: NLI: State: STATE_L3_CALL_REQ, Event: NL_CALL_CNF, Next: STATE_NL_CALL_CNF 
1w0d: Checking maplist "junk"
1w0d: working with maplist "bermuda"
1w0d: Checking maplist "bermuda"
1w0d: working with maplist "bermuda"
1w0d: NLI: Emptying holdQ, link 7, dlci 100, size 104 
 
1w0d# debug frame-relay networklayerinterface
 
1w0d: NLI: L3 Call Release Req for Call ID 1 
1w0d: NLI STATE: L3_CALL_REL_REQ, Call ID 1 state 3 
1w0d: NLI: Walking the event table 1
1w0d: NLI: Walking the event table 2
1w0d: NLI: Walking the event table 3
1w0d: NLI: Walking the event table 4
1w0d: NLI: Walking the event table 5
1w0d: NLI: Walking the event table 6
1w0d: NLI: Walking the event table 7
1w0d: NLI: Walking the event table 8
1w0d: NLI: Walking the event table 9
1w0d: NLI: Walking the event table 10
1w0d: NLI: NLx_L3CallRej
1w0d: NLI: State: STATE_NL_CALL_CNF, Event: L3_CALL_REL_REQ, Next: STATE_L3_CALL_REL_REQ 
1w0d: NLI: junk: State: STATE_NL_NULL, Event: L3_CALL_REL_REQ, Next: STATE_NL_NULL 
1w0d: NLI: Map-list search: Found maplist junk 
1w0d: daddr.subaddr 0, saddr.subaddr 0, saddr.subaddr 0 
1w0d: saddr.subaddr 0, daddr.subaddr 0, daddr.subaddr 0 
1w0d: nli_parameter_negotiation
1w0d: NLI STATE: NL_REL_CNF, Call ID 1 state 0 
1w0d: NLI: Walking the event table 1
1w0d: NLI: Walking the event table 2
1w0d: NLI: Walking the event table 3
1w0d: NLI: Walking the event table 4
1w0d: NLI: Walking the event table 5
1w0d: NLI: Walking the event table 6
1w0d: NLI: Walking the event table 7
1w0d: NLI: NLx_RelCnf
1w0d: NLI: State: STATE_NL_NULL, Event: NL_REL_CNF, Next: STATE_NL_NULL 
 

Related Commands

Command	Description
debug frame-relay callcontrol	Displays Frame Relay layer 3 (network layer) call control information.

Syntax Description

interface name	(Optional) Name of interface or subinterface.
dlci value	(Optional) Data-link connection indentifier (DLCI) decimal value.

Usage Guidelines

This command helps you analyze the packets that are sent on a Frame Relay interface. Because the debug frame-relay packet command generates large amounts of output, only use it when traffic on the Frame Relay network is less than 25 packets per second. Use the options to limit the debugging output to a specific DLCI or interface.

To analyze the packets received on a Frame Relay interface, use the debug frame-relay command.

Examples

The following is sample output from the debug frame-relay packet command:

The following lines describe a Frame Relay packet sent to a particular address; in this case AppleTalk address 10.2:

Serial0: broadcast - 0, link 809B, addr 10.2
Serial0(o):DLCI 100 type 809B size 104
 

The following lines describe a Frame Relay packet that went out on two different DLCIs, because two Frame Relay map entries were found:

Serial0: broadcast search
Serial0(o):DLCI 300 type 809B size 24
Serial0(o):DLCI 400 type 809B size 24
 

The following lines do not appear. They describe a Frame Relay packet sent to a true broadcast address.

Serial1: broadcast search
Serial1(o):DLCI 400 type 800 size 288
 

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

Displays error messages for link states and LMI status changes for PPP over Frame Relay sessions.

The debug frame-relay ppp command is generated from process level switching only and is not CPU intensive.

Examples

Router# debug frame-relay ppp
FR-PPP: encaps failed for FR VC 100 on Serial0 down
FR-PPP: input- Serial0 vc or va down, pak dropped
 

Router# debug frame-relay ppp
Router# debug frame-relay packet
 
Vi1 LCP: O CONFREQ [Closed] id 1 len 10
Vi1 LCP:    MagicNumber 0xE0638565 (0x0506E0638565)
Serial2/1(o): dlci 201(0x3091), NLPID 0x3CF(PPP), datagramsize 16
Vi1 PPP: I pkt type 0xC021, datagramsize 14
Vi1 LCP: I CONFACK [REQsent] id 1 len 10
Vi1 LCP:    MagicNumber 0xE0638565 (0x0506E0638565)
Vi1 PPP: I pkt type 0xC021, datagramsize 14
Vi1 LCP: I CONFREQ [ACKrcvd] id 6 len 10
Vi1 LCP:    MagicNumber 0x000EAD99 (0x0506000EAD99)
Vi1 LCP: O CONFACK [ACKrcvd] id 6 len 10
Vi1 LCP:    MagicNumber 0x000EAD99 (0x0506000EAD99)
Serial2/1(o): dlci 201(0x3091), NLPID 0x3CF(PPP), datagramsize 16
Vi1 IPCP: O CONFREQ [Closed] id 1 len 10
Vi1 IPCP:    Address 170.100.9.10 (0x0306AA64090A)
Serial2/1(o): dlci 201(0x3091), NLPID 0x3CF(PPP), datagramsize 16
Vi1 PPP: I pkt type 0x8021, datagramsize 14
Vi1 IPCP: I CONFREQ [REQsent] id 1 len 10
Vi1 IPCP:    Address 170.100.9.20 (0x0306AA640914)
Vi1 IPCP: O CONFACK [REQsent] id 1 len 10
Vi1 IPCP:    Address 170.100.9.20 (0x0306AA640914)
Serial2/1(o): dlci 201(0x3091), NLPID 0x3CF(PPP), datagramsize 16
Vi1 PPP: I pkt type 0x8021, datagramsize 14
Vi1 IPCP: I CONFACK [ACKsent] id 1 len 10
Vi1 IPCP:    Address 170.100.9.10 (0x0306AA64090A)
Vi1 PPP: I pkt type 0xC021, datagramsize 16
Vi1 LCP: I ECHOREQ [Open] id 1 len 12 magic 0x000EAD99
Vi1 LCP: O ECHOREP [Open] id 1 len 12 magic 0xE0638565
Serial2/1(o): dlci 201(0x3091), NLPID 0x3CF(PPP), datagramsize 18
Vi1 LCP: O ECHOREQ [Open] id 1 len 12 magic 0xE0638565
Serial2/1(o): dlci 201(0x3091), NLPID 0x3CF(PPP), datagramsize 18
Vi1 LCP: echo_cnt 4, sent id 1, line up 
 

Router# debug frame-relay ppp
Router# debug frame-relay packet
 
Vi1 LCP: O CONFREQ [Listen] id 24 len 10
Vi1 LCP:    MagicNumber 0xE068EC78 (0x0506E068EC78)
Serial2/1(o): dlci 201(0x3091), NLPID 0x3CF(PPP), datagramsize 16
Vi1 PPP: I pkt type 0xC021, datagramsize 19
Vi1 LCP: I CONFREQ [REQsent] id 18 len 15
Vi1 LCP:    AuthProto CHAP (0x0305C22305)
Vi1 LCP:    MagicNumber 0x0014387E (0x05060014387E)
Vi1 LCP: O CONFACK [REQsent] id 18 len 15
Vi1 LCP:    AuthProto CHAP (0x0305C22305)
Vi1 LCP:    MagicNumber 0x0014387E (0x05060014387E)
Serial2/1(o): dlci 201(0x3091), NLPID 0x3CF(PPP), datagramsize 21
Vi1 PPP: I pkt type 0xC021, datagramsize 14
Vi1 LCP: I CONFACK [ACKsent] id 24 len 10
Vi1 LCP:    MagicNumber 0xE068EC78 (0x0506E068EC78)
Vi1 PPP: I pkt type 0xC223, datagramsize 32
Vi1 CHAP: I CHALLENGE id 12 len 28 from "krishna"
Vi1 LCP: O TERMREQ [Open] id 25 len 4
Serial2/1(o): dlci 201(0x3091), NLPID 0x3CF(PPP), datagramsize 10
Vi1 PPP: I pkt type 0xC021, datagramsize 8
Vi1 LCP: I TERMACK [TERMsent] id 25 len 4
Serial2/1(i): dlci 201(0x3091), pkt type 0x2000, datagramsize 303
%SYS-5-CONFIG_I: Configured from console by console
Vi1 LCP: TIMEout: Time 0x199580 State Listen
 

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

For complete information on the FRAS process, use the debug fras message along with the debug fras error command.

Examples

The following is sample output from the debug fras error command. This example shows that no logical connection exists between the local station and remote station in the current setup.

Router# debug fras error
 
FRAS: No route, lmac 1000.5acc.7fb1 rmac 4fff.0000.0000, lSap=0x4, rSap=0x4
FRAS: Can not find the Setup

Related Commands

Command	Description
debug cls message	Displays information about CLS messages.
debug fras message	Displays general information about FRAS messages.
debug fras state	Displays information about FRAS data-link control state changes.

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

If many LLC2 sessions are being activated or deactivated at any time, this command may generate large amounts of output to the console.

Examples

The following is sample output from the debug fras-host activation command:

Router# debug fras-host activation
 
FRHOST: Snd      TST C to HOST, DA = 4001.3745.1088 SA = 400f.dddd.001e DSAP = 0x00 SSAP = 0x04
FRHOST: Fwd  BNN   XID to HOST, DA = 4001.3745.1088 SA = 400f.dddd.001e DSAP = 0x04 SSAP = 0x04
FRHOST: Fwd HOST   XID to  BNN, DA = 400f.dddd.001e SA = 4001.3745.1088 DSAP = 0x04 SSAP = 0x05
FRHOST: Fwd  BNN   XID to HOST, DA = 4001.3745.1088 SA = 400f.dddd.001e DSAP = 0x04 SSAP = 0x04
FRHOST: Fwd HOST SABME to  BNN, DA = 400f.dddd.001e SA = 4001.3745.1088 DSAP = 0x04 SSAP = 0x04
FRHOST: Fwd  BNN    UA to HOST, DA = 4001.3745.1088 SA = 400f.dddd.001e DSAP = 0x04 SSAP = 0x05
 

Syntax Description

This command has no arguments or keywords.

Examples

The following is sample output from the debug fras-host error command when the I-field in a TEST Response frame from a host does not match the I-field of the TEST Command sent by the FRAS Host:

Router# debug fras-host error
 
FRHOST: SRB TST R Protocol Violation - LLC I-field not maintained.
 

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

Use this command with great care. If many LLC2 sessions are active and passing data, this command may generate may generate a tremendous amount of output to the console and impact performance.

Examples

The following is sample output from the debug fras-host packet command:

Router# debug fras-host packet
 
FRHOST: Snd      TST C to HOST, DA = 4001.3745.1088 SA = 400f.dddd.001e DSAP = 0x00 SSAP = 0x04
FRHOST: Fwd  BNN   XID to HOST, DA = 4001.3745.1088 SA = 400f.dddd.001e DSAP = 0x04 SSAP = 0x04
FRHOST: Fwd HOST   XID to  BNN, DA = 400f.dddd.001e SA = 4001.3745.1088 DSAP = 0x04 SSAP = 0x05
FRHOST: Fwd  BNN   XID to HOST, DA = 4001.3745.1088 SA = 400f.dddd.001e DSAP = 0x04 SSAP = 0x04
FRHOST: Fwd HOST SABME to  BNN, DA = 400f.dddd.001e SA = 4001.3745.1088 DSAP = 0x04 SSAP = 0x04
FRHOST: Fwd  BNN    UA to HOST, DA = 4001.3745.1088 SA = 400f.dddd.001e DSAP = 0x04 SSAP = 0x05
FRHOST: Fwd HOST LLC-2 to  BNN, DA = 400f.dddd.001e SA = 4001.3745.1088 DSAP = 0x04 SSAP = 0x04
FRHOST: Fwd  BNN LLC-2 to HOST, DA = 4001.3745.1088 SA = 400f.dddd.001e DSAP = 0x04 SSAP = 0x05
FRHOST: Fwd HOST LLC-2 to  BNN, DA = 400f.dddd.001e SA = 4001.3745.1088 DSAP = 0x04 SSAP = 0x04
FRHOST: Fwd  BNN LLC-2 to HOST, DA = 4001.3745.1088 SA = 400f.dddd.001e DSAP = 0x04 SSAP = 0x04
 

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

Use of this command may result in large amounts of output to the screen. Only use this command for problem determination.

Examples

The following is sample output from the debug fras-host snmp command. In this example, the MIB variable k_frasHostConnEntry_get() is providing SNMP information for a FRAS host.

Router# debug fras-host snmp
 
k_frasHostConnEntry_get(): serNum = -1, vRingIfIdx = 31, frIfIdx = 12
Hmac = 4001.3745.1088, frLocSap = 4, Rmac = 400f.dddd.001e, frRemSap = 4
 

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

For complete information on the FRAS process, use the debug fras error along with the debug fras message command.

Examples

The following is sample output from the debug fras message command. This example shows incoming Cisco Link Services (CLS) primitives.

Router# debug fras message
 
FRAS: receive 4C23
FRAS: receive CC09

Related Commands

Command	Description
debug cls message	Limits output for some debugging commands based on the interfaces.
debug fras error	Displays information about FRAS protocol errors.
debug fras state	Displays information about FRAS data-link control state changes.

Syntax Description

This command has no arguments or keywords.

Examples

The following is sample output from the debug fras state command. This example shows the state changing from a request open station is sent state to an exchange XID state.

Possible states are the following: reset, request open station is sent, exchange xid, connection request is sent, signal station wait, connection response wait, connection response sent, connection established, disconnect wait, and number of link states.

Router# debug fras state 
 
FRAS: TR0 (04/04) oldstate=LS_RQOPNSTNSENT, input=RQ_OPNSTN_CNF
FRAS: newstate=LS_EXCHGXID

Related Commands

Command	Description
debug cls message	Limits output for some debugging commands based on the interfaces.
debug fras error	Displays information about FRAS protocol errors.
debug fras state	Displays general information about FRAS messages.

Syntax Description

This command has no arguments or keywords.

Examples

The following is sample output from the debug ftpserver command:

Router# debug ftpserver
 
Mar  3 10:21:10: %FTPSERVER-6-NEWCONN: FTP Server - new connection made.
-Process= "TCP/FTP Server", ipl= 0, pid= 53
Mar  3 10:21:10: FTPSRV_DEBUG:FTP Server file path: 'disk0:'
Mar  3 10:21:10: FTPSRV_DEBUG:(REPLY)  220
Mar  3 10:21:10: FTPSRV_DEBUG:FTProuter IOS-FTP server (version 1.00) ready.
Mar  3 10:21:10: FTPSRV_DEBUG:FTP Server Command received: 'USER aa'
Mar  3 10:21:20: FTPSRV_DEBUG:(REPLY)  331
Mar  3 10:21:20: FTPSRV_DEBUG:Password required for 'aa'.
Mar  3 10:21:20: FTPSRV_DEBUG:FTP Server Command received: 'PASS aa'
Mar  3 10:21:21: FTPSRV_DEBUG:(REPLY)  230
Mar  3 10:21:21: FTPSRV_DEBUG:Logged in.
Mar  3 10:21:21: FTPSRV_DEBUG:FTP Server Command received: 'SYST'
Mar  3 10:21:21: FTPSRV_DEBUG:(REPLY)  215
Mar  3 10:21:21: FTPSRV_DEBUG:Cisco IOS Type: L8 Version: IOS/FTP 1.00
Mar  3 10:21:21: FTPSRV_DEBUG:FTP Server Command received: 'PWD'
Mar  3 10:21:35: FTPSRV_DEBUG:(REPLY)  257
Mar  3 10:21:39: FTPSRV_DEBUG:FTP Server Command received: 'CWD disk0:/syslogd.d'r/'
Mar  3 10:21:45: FTPSRV_DEBUG:FTP Server file path: 'disk0:/syslogd.dir'
Mar  3 10:21:45: FTPSRV_DEBUG:(REPLY)  250
Mar  3 10:21:45: FTPSRV_DEBUG:CWD command successful.
Mar  3 10:21:45: FTPSRV_DEBUG:FTP Server Command received: 'PORT 171,69,30,20,22',32
Mar  3 10:21:46: FTPSRV_DEBUG:(REPLY)  200
Mar  3 10:21:46: FTPSRV_DEBUG:PORT command successful.
Mar  3 10:21:46: FTPSRV_DEBUG:FTP Server Command received: 'LIST'
Mar  3 10:21:47: FTPSRV_DEBUG:FTP Server file path: 'disk0:/syslogd.dir/.'
Mar  3 10:21:47: FTPSRV_DEBUG:(REPLY)  220
Mar  3 10:23:11: FTPSRV_DEBUG:Opening ASCII mode data connection for file list.
Mar  3 10:23:11: FTPSRV_DEBUG:(REPLY)  226
Mar  3 10:23:12: FTPSRV_DEBUG:Transfer complete.
Mar  3 10:23:12: FTPSRV_DEBUG:FTP Server Command received: 'TYPE I'
Mar  3 10:23:14: FTPSRV_DEBUG:(REPLY)  200
Mar  3 10:23:14: FTPSRV_DEBUG:Type set to I.
Mar  3 10:23:14: FTPSRV_DEBUG:FTP Server Command received: 'PORT 171,69,30,20,22',51
Mar  3 10:23:20: FTPSRV_DEBUG:(REPLY)  200
Mar  3 10:23:20: FTPSRV_DEBUG:PORT command successful.
Mar  3 10:23:20: FTPSRV_DEBUG:FTP Server Command received: 'RETR syslogd.1'
Mar  3 10:23:21: FTPSRV_DEBUG:FTP Server file path: 'disk0:/syslogd.dir/syslogd.1'
Mar  3 10:23:21: FTPSRV_DEBUG:FTPSERVER: Input path passed Top-dir(disk0:/syslogd.dir/) test.
Mar  3 10:23:21: FTPSRV_DEBUG:(REPLY)  150
Mar  3 10:23:21: FTPSRV_DEBUG:Opening BINARY mode data connection for syslogd.1 (607317 bytes).
Mar  3 10:23:21: FTPSRV_DEBUG:(REPLY)  226
Mar  3 10:23:29: FTPSRV_DEBUG:Transfer complete.
 

The sample output corresponds to the following FTP client session. In this example, the user connects to the FTP server, views the contents of the top-level directory, and gets a file.

FTPclient% ftp FTProuter
Connected to FTProuter.cisco.com.
220 FTProuter IOS-FTP server (version 1.00) ready.
Name (FTProuter:me): aa
331 Password required for 'aa'.
Password:
230 Logged in.
Remote system type is Cisco.
ftp> pwd
257 "disk0:/syslogd.dir/" is current directory.
ftp> dir
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
syslogd.1
syslogd.2
syslogd.3
syslogd.4
syslogd.5
syslogd.6
syslogd.7
syslogd.8
syslogd.9
syslogd.cur
226 Transfer complete.
ftp> bin
200 Type set to I.
ftp> get syslogd.1
200 PORT command successful.
150 Opening BINARY mode data connection for syslogd.1 (607317 bytes).
226 Transfer complete.
607317 bytes received in 7.7 seconds (77 Kbytes/s)
ftp>
 

The following debug ftpserver command output indicates that no top-level directory is specified. Therefore, the client cannot access any location on the FTP server. Use the ftp-server topdir command to specify the top-level directory.

Mar  3 10:29:14: FTPSRV_DEBUG:(REPLY)  550
Mar  3 10:29:14: FTPSRV_DEBUG:Access denied to 'disk0:'

Syntax Description

This command has no arguments or keywords.

Command History

Release	Modification
11.3(2)NA	This command was introduced.
12.0(3)T	This command was modified.

Caution This command slows down the system considerably and connections may time out.

Examples

The following are sample output from the debug h255 asn1 command.

Sample 1: Gatekeeper Trace with ASN1 Turned On, Call Being Established

This report shows two proxy call scenarios. A trace is collected on the gatekeeper with ASN1 turned on. The call is being established.

gk1# debug h225 asn1
H.225 ASN1 Messages debugging is on
gk1#24800006 03C00030 00300036 00380041 00450037 00430030 00300030 00300030
00300030 00310140 0F007000 74006500 6C003200 33004000 7A006F00 6E006500
32002E00 63006F00 6D020180 AAAA4006 00700074 0065006C 00320031 0033401E
0000015F C8490FB4 B9D111BF AF0060B0 00E94500 
value RasMessage ::= admissionRequest : 
  {
    requestSeqNum 7,
    callType pointToPoint : NULL,
    endpointIdentifier "0068AE7C00000001",
    destinationInfo 
    {
      h323-ID : "ptel23@zone2.com"
    },
    srcInfo 
    {
      e164 : "7777",
      h323-ID : "ptel213"
    },
    bandWidth 7680,
    callReferenceValue 1,
    conferenceID '5FC8490FB4B9D111BFAF0060B000E945'H,
    activeMC FALSE,
    answerCall FALSE
  }
value RasMessage ::= admissionConfirm : 
  {
    requestSeqNum 7,
    bandWidth 7680,
    callModel direct : NULL,
    destCallSignalAddress ipAddress : 
      {
        ip '65000001'H,
        port 1720
      },
    irrFrequency 30
  }
29000006 401E0000 65000001 06B8001D 
2480001D 03C00030 00300036 00380041 00390036 00300030 00300030 00300030
00300030 00320140 0F007000 74006500 6C003200 33004000 7A006F00 6E006500
32002E00 63006F00 6D014006 00700074 0065006C 00320031 00334002 8000015F
C8490FB4 B9D111BF AF0060B0 00E94540 
value RasMessage ::= admissionRequest : 
  {
    requestSeqNum 30,
    callType pointToPoint : NULL,
    endpointIdentifier "0068A96000000002",
    destinationInfo 
    {
      h323-ID : "ptel23@zone2.com"
    },
    srcInfo 
    {
      h323-ID : "ptel213"
    },
    bandWidth 640,
    callReferenceValue 1,
    conferenceID '5FC8490FB4B9D111BFAF0060B000E945'H,
    activeMC FALSE,
    answerCall TRUE
  }
value ACFnonStandardInfo ::= 
{
  srcTerminalAlias 
  {
    e164 : "7777",
    h323-ID : "ptel213"
  },
  dstTerminalAlias 
  {
    h323-ID : "ptel23@zone2.com"
  },
  dstProxyAlias 
  {
    h323-ID : "px2"
  },
  dstProxySignalAddress 
  {
    ip '66000001'H,
    port 1720
  }
}
C00203AA AA800600 70007400 65006C00 32003100 3301800F 00700074 0065006C
00320033 0040007A 006F006E 00650032 002E0063 006F006D 01800200 70007800
32660000 0106B8
value RasMessage ::= admissionConfirm : 
  {
    requestSeqNum 30,
    bandWidth 7680,
    callModel direct : NULL,
    destCallSignalAddress ipAddress : 
      {
        ip '66000001'H,
        port 1720
      },
    irrFrequency 30,
    nonStandardData 
    {
      nonStandardIdentifier h221NonStandard : 
        {
          t35CountryCode 181,
          t35Extension 0,
          manufacturerCode 18
        },
      data
'C00203AAAA8006007000740065006C00320031003301800F007000740065006C003200 ...'H
    }
  }
2980001D 401E0000 66000001 06B8001D 40B50000 1247C002 03AAAA80 06007000
74006500 6C003200 31003301 800F0070 00740065 006C0032 00330040 007A006F
006E0065 0032002E 0063006F 006D0180 02007000 78003266 00000106 B8
24C0001E 03C00030 00300036 00380041 00390036 00300030 00300030 00300030
00300030 00320140 0F007000 74006500 6C003200 33004000 7A006F00 6E006500
32002E00 63006F00 6D006600 000106B8 020180AA AA400600 70007400 65006C00
32003100 33401E00 00435FC8 490FB4B9 D111BFAF 0060B000 E94500
value RasMessage ::= admissionRequest : 
  {
    requestSeqNum 31,
    callType pointToPoint : NULL,
    endpointIdentifier "0068A96000000002",
    destinationInfo 
    {
      h323-ID : "ptel23@zone2.com"
    },
    destCallSignalAddress ipAddress : 
      {
        ip '66000001'H,
        port 1720
      },
    srcInfo 
    {
      e164 : "7777",
      h323-ID : "ptel213"
    },
    bandWidth 7680,
    callReferenceValue 67,
    conferenceID '5FC8490FB4B9D111BFAF0060B000E945'H,
    activeMC FALSE,
    answerCall FALSE
  }
value RasMessage ::= admissionConfirm : 
  {
    requestSeqNum 31,
    bandWidth 7680,
    callModel direct : NULL,
    destCallSignalAddress ipAddress : 
      {
        ip '66000001'H,
        port 1720
      },
    irrFrequency 30
  }

Sample 2: Source Proxy Trace with ASN1 Turned On, Call Being Torn Down

This report shows two proxy call scenarios. A trace is collected on the source proxy with ASN1 turned on. The call is being torn down

px1# debug h225 asn1
H.225 ASN1 Messages debugging is on
px1#
value H323-UserInformation ::= 
{
  h323-uu-pdu 
  {
    h323-message-body setup : 
      {
        protocolIdentifier { 0 0 8 2250 0 1 },
        sourceAddress 
        {
          h323-ID : "ptel213"
        },
        sourceInfo 
        {
          terminal 
          {
          },
          mc FALSE,
          undefinedNode FALSE
        },
        destinationAddress 
        {
          h323-ID : "ptel23@zone2.com"
        },
        activeMC FALSE,
        conferenceID '5FC8490FB4B9D111BFAF0060B000E945'H,
        conferenceGoal create : NULL,
        callType pointToPoint : NULL,
        sourceCallSignalAddress ipAddress : 
          {
            ip '3200000C'H,
            port 1720
          }
      }
  }
}
value RasMessage ::= admissionRequest : 
  {
    requestSeqNum 30,
    callType pointToPoint : NULL,
    endpointIdentifier "0068A96000000002",
    destinationInfo 
    {
      h323-ID : "ptel23@zone2.com"
    },
    srcInfo 
    {
      h323-ID : "ptel213"
    },
    bandWidth 640,
    callReferenceValue 1,
    conferenceID '5FC8490FB4B9D111BFAF0060B000E945'H,
    activeMC FALSE,
    answerCall TRUE
  }
2480001D 03C00030 00300036 00380041 00390036 00300030 00300030 00300030
00300030 00320140 0F007000 74006500 6C003200 33004000 7A006F00 6E006500
32002E00 63006F00 6D014006 00700074 0065006C 00320031 00334002 8000015F
C8490FB4 B9D111BF AF0060B0 00E94540 
2980001D 401E0000 66000001 06B8001D 40B50000 1247C002 03AAAA80 06007000
74006500 6C003200 31003301 800F0070 00740065 006C0032 00330040 007A006F
006E0065 0032002E 0063006F 006D0180 02007000 78003266 00000106 B8
value RasMessage ::= admissionConfirm : 
  {
    requestSeqNum 30,
    bandWidth 7680,
    callModel direct : NULL,
    destCallSignalAddress ipAddress : 
      {
        ip '66000001'H,
        port 1720
      },
    irrFrequency 30,
    nonStandardData 
    {
      nonStandardIdentifier h221NonStandard : 
        {
          t35CountryCode 181,
          t35Extension 0,
          manufacturerCode 18
        },
      data
'C00203AAAA8006007000740065006C00320031003301800F007000740065006C003200 ...'H
    }
  }
C00203AA AA800600 70007400 65006C00 32003100 3301800F 00700074 0065006C
00320033 0040007A 006F006E 00650032 002E0063 006F006D 01800200 70007800
32660000 0106B8
value ACFnonStandardInfo ::= 
{
  srcTerminalAlias 
  {
    e164 : "7777",
    h323-ID : "ptel213"
  },
  dstTerminalAlias 
  {
    h323-ID : "ptel23@zone2.com"
  },
  dstProxyAlias 
  {
    h323-ID : "px2"
  },
  dstProxySignalAddress 
  {
    ip '66000001'H,
    port 1720
  }
}
value RasMessage ::= admissionRequest : 
  {
    requestSeqNum 31,
    callType pointToPoint : NULL,
    endpointIdentifier "0068A96000000002",
    destinationInfo 
    {
      h323-ID : "ptel23@zone2.com"
    },
    destCallSignalAddress ipAddress : 
      {
        ip '66000001'H,
        port 1720
      },
    srcInfo 
    {
      e164 : "7777",
      h323-ID : "ptel213"
    },
    bandWidth 7680,
    callReferenceValue 67,
    conferenceID '5FC8490FB4B9D111BFAF0060B000E945'H,
    activeMC FALSE,
    answerCall FALSE
  }
24C0001E 03C00030 00300036 00380041 00390036 00300030 00300030 00300030
00300030 00320140 0F007000 74006500 6C003200 33004000 7A006F00 6E006500
32002E00 63006F00 6D006600 000106B8 020180AA AA400600 70007400 65006C00
32003100 33401E00 00435FC8 490FB4B9 D111BFAF 0060B000 E94500
2900001E 401E0000 66000001 06B8001D 
value RasMessage ::= admissionConfirm : 
  {
    requestSeqNum 31,
    bandWidth 7680,
    callModel direct : NULL,
    destCallSignalAddress ipAddress : 
      {
        ip '66000001'H,
        port 1720
      },
    irrFrequency 30
  }
value H323-UserInformation ::= 
{
  h323-uu-pdu 
  {
    h323-message-body callProceeding : 
      {
        protocolIdentifier { 0 0 8 2250 0 1 },
        destinationInfo 
        {
          gateway 
          {
            protocol 
            {
              h323 : 
                {
                }
            }
          },
          mc FALSE,
          undefinedNode FALSE
        }
      }
  }
}
01000600 08914A00 01088001 2800
value H323-UserInformation ::= 
{
  h323-uu-pdu 
  {
    h323-message-body setup : 
      {
        protocolIdentifier { 0 0 8 2250 0 1 },
        sourceAddress 
        {
          h323-ID : "ptel213"
        },
        sourceInfo 
        {
          vendor 
          {
            vendor 
            {
              t35CountryCode 181,
              t35Extension 0,
              manufacturerCode 18
            }
          },
          gateway 
          {
            protocol 
            {
              h323 : 
                {
                }
            }
          },
          mc FALSE,
          undefinedNode FALSE
        },
        destinationAddress 
        {
          h323-ID : "ptel23@zone2.com"
        },
        destCallSignalAddress ipAddress : 
          {
            ip '66000001'H,
            port 1720
          },
        activeMC FALSE,
        conferenceID '5FC8490FB4B9D111BFAF0060B000E945'H,
        conferenceGoal create : NULL,
        callType pointToPoint : NULL,
        sourceCallSignalAddress ipAddress : 
          {
            ip '65000001'H,
            port 1720
          },
        remoteExtensionAddress h323-ID : "ptel23@zone2.com"
      }
  }
}
00B80600 08914A00 01014006 00700074 0065006C 00320031 00332800 B5000012
40012800 01400F00 70007400 65006C00 32003300 40007A00 6F006E00 65003200
2E006300 6F006D00 66000001 06B8005F C8490FB4 B9D111BF AF0060B0 00E94500
0E070065 00000106 B822400F 00700074 0065006C 00320033 0040007A 006F006E
00650032 002E0063 006F006D 
value H323-UserInformation ::= 
{
  h323-uu-pdu 
  {
    h323-message-body callProceeding : 
      {
        protocolIdentifier { 0 0 8 2250 0 1 },
        destinationInfo 
        {
          gateway 
          {
            protocol 
            {
              h323 : 
                {
                }
            }
          },
          mc FALSE,
          undefinedNode FALSE
        }
      }
  }
}
value H323-UserInformation ::= 
{
  h323-uu-pdu 
  {
    h323-message-body alerting : 
      {
        protocolIdentifier { 0 0 8 2250 0 1 },
        destinationInfo 
        {
          mc FALSE,
          undefinedNode FALSE
        }
      }
  }
}
value H323-UserInformation ::= 
{
  h323-uu-pdu 
  {
    h323-message-body alerting : 
      {
        protocolIdentifier { 0 0 8 2250 0 1 },
        destinationInfo 
        {
          mc FALSE,
          undefinedNode FALSE
        }
      }
  }
}
03000600 08914A00 010000
value H323-UserInformation ::= 
{
  h323-uu-pdu 
  {
    h323-message-body connect : 
      {
        protocolIdentifier { 0 0 8 2250 0 1 },
        h245Address ipAddress : 
          {
            ip '66000001'H,
            port 11011
          },
        destinationInfo 
        {
          gateway 
          {
            protocol 
            {
              h323 : 
                {
                }
            }
          },
          mc FALSE,
          undefinedNode FALSE
        },
        conferenceID '5FC8490FB4B9D111BFAF0060B000E945'H
      }
  }
}
value H323-UserInformation ::= 
{
  h323-uu-pdu 
  {
    h323-message-body connect : 
      {
        protocolIdentifier { 0 0 8 2250 0 1 },
        h245Address ipAddress : 
          {
            ip '65000001'H,
            port 11007
          },
        destinationInfo 
        {
          gateway 
          {
            protocol 
            {
              h323 : 
                {
                }
            }
          },
          mc FALSE,
          undefinedNode FALSE
        },
        conferenceID '5FC8490FB4B9D111BFAF0060B000E945'H
      }
  }
}
02400600 08914A00 01006500 00012AFF 08800128 005FC849 0FB4B9D1 11BFAF00
60B000E9 45

Sample 3: Destination Router Trace, Both RAS and H.225 Traces Are Enabled

This report shows two proxy call scenarios. A trace is collected on a destination router where both destination proxy and destination gatekeeper co-exist. Both RAS and H.225 traces are enabled for one complete call.

px2#      
      RASLib::RASRecvData: successfully rcvd message of length 80 from 40.0.0.33:1585
      RASLib::RASRecvData: LRQ rcvd from [40.0.0.33:1585] on sock [6880372]
      RASlib::ras_sendto: msg length 111 sent to 40.0.0.33
      RASLib::RASSendLCF: LCF sent to 40.0.0.33
      H225Lib::h225TAccept: TCP connection accepted from 101.0.0.1:11002 on
socket [2]
      H225Lib::h225TAccept: Q.931 Call State is initialized to be [Null].
Hex representation of the received TPKT
030000A60802008005040488988CA56C0591373737377E008D0500B8060008914A000101400
6007000740065006C0032003100332800B50000124001280001400F007000740065006C00320
0330040007A006F006E00650032002E0063006F006D006600000106B8003DC8490FB4B9D111B
FAF0060B000E945000E07006500000106B822400F007000740065006C003200330040007A006
F006E00650032002E0063006F006D
      H225Lib::h225RecvData: Q.931 SETUP received from socket [2]
      H225Lib::h225RecvData: State changed to [Call Present].
      RASlib::ras_sendto: msg length 119 sent to 102.0.0.1
      RASLib::RASSendARQ: ARQ sent to 102.0.0.1
      RASLib::RASRecvData: successfully rcvd message of length 119 from 102.0.0.1:24999
      RASLib::RASRecvData: ARQ rcvd from [102.0.0.1:24999] on sock [0x68FC74]
      RASlib::ras_sendto: msg length 16 sent to 70.0.0.31
      RASLib::RASSendACF: ACF sent to 70.0.0.31
      RASLib::RASRecvData: successfully rcvd message of length 16 from 102.0.0.1:1719
      RASLib::RASRecvData: ACF rcvd from [102.0.0.1:1719] on sock [0x67E6A4]
      RASlib::ras_sendto: msg length 119 sent to 102.0.0.1
      RASLib::RASSendARQ: ARQ sent to 102.0.0.1
      RASLib::RASRecvData: successfully rcvd message of length 119 from 102.0.0.1:24999
      RASLib::RASRecvData: ARQ rcvd from [102.0.0.1:24999] on sock [0x68FC74]
      RASlib::ras_sendto: msg length 16 sent to 70.0.0.31
      RASLib::RASSendACF: ACF sent to 70.0.0.31
      RASLib::RASRecvData: successfully rcvd message of length 16 from 102.0.0.1:1719
      RASLib::RASRecvData: ACF rcvd from [102.0.0.1:1719] on sock [0x67E6A4]
Hex representation of the CALL PROCEEDING TPKT to send.
0300001B08028080027E000F050100060008914A00010880012800
      H225Lib::h225CallProcRequest: Q.931 CALL PROCEEDING sent from socket
[2]. Call state remains unchanged (Q.931 FSM simplified for H.225.0)
      H225Lib::h225TConn: connect in progress on socket [4]
      H225Lib::h225TConn: Q.931 Call State is initialized to be [Null].
Hex representation of the SETUP TPKT to send.
030000A50802008005040388C0A56C0591373737377E008D0500B8060008914A00010140060
07000740065006C0032003100332800B50000124001280001400F007000740065006C0032003
30040007A006F006E00650032002E0063006F006D005A00000D06B8003DC8490FB4B9D111BFA
F0060B000E945000E07006600000106B822400F007000740065006C003200330040007A006F0
06E00650032002E0063006F006D
      H225Lib::h225SetupRequest: Q.931 SETUP sent from socket [4]
      H225Lib::h225SetupRequest: Q.931 Call State changed to [Call Initiated].
      RASLib::RASRecvData: successfully rcvd message of length 123 from 90.0.0.13:1700
      RASLib::RASRecvData: ARQ rcvd from [90.0.0.13:1700] on sock [0x68FC74]
      RASlib::ras_sendto: msg length 16 sent to 90.0.0.13
      RASLib::RASSendACF: ACF sent to 90.0.0.13
Hex representation of the received TPKT
0300001808028080027E000C050100060008914A00010200
      H225Lib::h225RecvData: Q.931 CALL PROCEEDING received from socket [4]
Hex representation of the received TPKT
0300001808028080017E000C050300060008914A00010200
      H225Lib::h225RecvData: Q.931 ALERTING received from socket [4]
      H225Lib::h225RecvData: Q.931 Call State changed to [Call Delivered].
Hex representation of the ALERTING TPKT to send.
0300001808028080017E000C050300060008914A00010000
      H225Lib::h225AlertRequest: Q.931 ALERTING sent from socket [2]. Call
state changed to [Call Received].
Hex representation of the received TPKT
0300003508028080070404889886A57E0023050240060008914A0001005A00000D06A402003
DC8490FB4B9D111BFAF0060B000E945
      H225Lib::h225RecvData: Q.931 CONNECT received from socket [4]
      H225Lib::h225RecvData: Q.931 Call State changed to [Active].
Hex representation of the CONNECT TPKT to send.
030000370802808007040388C0A57E0026050240060008914A000100660000012AFC0880012
8003DC8490FB4B9D111BFAF0060B000E945
      H225Lib::h225SetupResponse: Q.931 CONNECT sent from socket [2]
      H225Lib::h225SetupResponse: Q.931 Call State changed to [Active].
      RASlib::ras_sendto: msg length 108 sent to 102.0.0.1
      RASLib::RASSendIRR: IRR sent to 102.0.0.1
      RASLib::RASRecvData: successfully rcvd message of length 108 from 102.0.0.1:24999
      RASLib::RASRecvData: IRR rcvd from [102.0.0.1:24999] on sock [0x68FC74]
      RASLib::RASRecvData: successfully rcvd message of length 101 from 90.0.0.13:1700
      RASLib::RASRecvData: IRR rcvd from [90.0.0.13:1700] on sock [0x68FC74]
Hex representation of the received TPKT
0300001A080280805A080280107E000A050500060008914A0001
      H225Lib::h225RecvData: Q.931 RELEASE COMPLETE received from socket [2]
      H225Lib::h225RecvData: Q.931 Call State changed to [Null].
      RASlib::ras_sendto: msg length 55 sent to 102.0.0.1
      RASLib::RASSendDRQ: DRQ sent to 102.0.0.1
      H225Lib::h225RecvData: no connection on socket [2]
      RASLib::RASRecvData: successfully rcvd message of length 55 from 102.0.0.1:24999
      RASLib::RASRecvData: DRQ rcvd from [102.0.0.1:24999] on sock [0x68FC74]
      RASlib::ras_sendto: msg length 3 sent to 70.0.0.31
      RASLib::RASSendDCF: DCF sent to 70.0.0.31
Hex representation of the RELEASE COMPLETE TPKT to send.
0300001A080280805A080280107E000A050500060008914A0001
      H225Lib::h225TerminateRequest: Q.931 RELEASE COMPLETE sent from socket [2]. Call state changed to [Null].
      H225Lib::h225TClose: TCP connection from socket [2] closed
      RASlib::ras_sendto: msg length 55 sent to 102.0.0.1
      RASLib::RASSendDRQ: DRQ sent to 102.0.0.1
      RASLib::RASRecvData: successfully rcvd message of length 3 from 102.0.0.1:1719
      RASLib::RASRecvData: DCF rcvd from [102.0.0.1:1719] on sock [0x67E6A4]
      RASLib::RASRecvData: successfully rcvd message of length 55 from 102.0.0.1:24999
      RASLib::RASRecvData: DRQ rcvd from [102.0.0.1:24999] on sock [0x68FC74]
      RASlib::ras_sendto: msg length 3 sent to 70.0.0.31
      RASLib::RASSendDCF: DCF sent to 70.0.0.31
      RASLib::RASRecvData: successfully rcvd message of length 3 from 102.0.0.1:1719
      RASLib::RASRecvData: DCF rcvd from [102.0.0.1:1719] on sock [0x67E6A4]
Hex representation of the RELEASE COMPLETE TPKT to send.
0300001A080280805A080280107E000A050500060008914A0001
      H225Lib::h225TerminateRequest: Q.931 RELEASE COMPLETE sent from socket [4]. Call state changed to [Null].
      H225Lib::h225TClose: TCP connection from socket [4] closed
      RASLib::RASRecvData: successfully rcvd message of length 55 from 90.0.0.13:1700
      RASLib::RASRecvData: DRQ rcvd from [90.0.0.13:1700] on sock [0x68FC74]
      RASlib::ras_sendto: msg length 3 sent to 90.0.0.13
      RASLib::RASSendDCF: DCF sent to 90.0.0.13

Syntax Description

This command has no arguments or keywords.

Command History

Release	Modification
11.3(2)NA	This command was introduced.
12.0(3)T	This command was modified.

Examples

The following are sample output from the debug h225 events command.

Sample 1: Source Proxy Trace with H.225 Turned On, Call Being Established

This report shows two proxy call scenarios. A trace is collected on the source proxy with H.225 turned on. The call is being established.

px1# debug h225 events
H.225 Event Messages debugging is on
px1#  H225Lib::h225TAccept: TCP connection accepted from 50.0.0.12:1701 on
socket [2]
      H225Lib::h225TAccept: Q.931 Call State is initialized to be [Null].
Hex representation of the received TPKT
0300007408020001050404889886A56C0580373737377E005B0500B0060008914A000101400
6007000740065006C003200310033020001400F007000740065006C003200330040007A006F0
06E00650032002E0063006F006D004EC8490FB4B9D111BFAF0060B000E945000C07003200000
C06B8
      H225Lib::h225RecvData: Q.931 SETUP received from socket [2]
      H225Lib::h225RecvData: State changed to [Call Present].
Hex representation of the CALL PROCEEDING TPKT to send.
0300001B08028001027E000F050100060008914A00010880012800
      H225Lib::h225CallProcRequest: Q.931 CALL PROCEEDING sent from socket
[2]. Call state remains unchanged (Q.931 FSM simplified for H.225.0)
      H225Lib::h225TConn: connect in progress on socket [4]
      H225Lib::h225TConn: Q.931 Call State is initialized to be [Null].
Hex representation of the SETUP TPKT to send.
030000A60802008405040488988CA56C0591373737377E008D0500B8060008914A000101400
6007000740065006C0032003100332800B50000124001280001400F007000740065006C00320
0330040007A006F006E00650032002E0063006F006D006600000106B8004EC8490FB4B9D111B
FAF0060B000E945000E07006500000106B822400F007000740065006C003200330040007A006
F006E00650032002E0063006F006D
      H225Lib::h225SetupRequest: Q.931 SETUP sent from socket [4]
      H225Lib::h225SetupRequest: Q.931 Call State changed to [Call Initiated].
Hex representation of the received TPKT
0300001B08028084027E000F050100060008914A00010880012800
      H225Lib::h225RecvData: Q.931 CALL PROCEEDING received from socket [4]
Hex representation of the received TPKT
0300001808028084017E000C050300060008914A00010000
      H225Lib::h225RecvData: Q.931 ALERTING received from socket [4]
      H225Lib::h225RecvData: Q.931 Call State changed to [Call Delivered].
Hex representation of the ALERTING TPKT to send.
0300001808028001017E000C050300060008914A00010000
      H225Lib::h225AlertRequest: Q.931 ALERTING sent from socket [2]. Call
state changed to [Call Received].
Hex representation of the received TPKT
030000370802808407040388C0A57E0026050240060008914A000100660000012AFF0880012
8004EC8490FB4B9D111BFAF0060B000E945
      H225Lib::h225RecvData: Q.931 CONNECT received from socket [4]
      H225Lib::h225RecvData: Q.931 Call State changed to [Active].
Hex representation of the CONNECT TPKT to send.
0300003808028001070404889886A57E0026050240060008914A000100650000012AFC08800
128004EC8490FB4B9D111BFAF0060B000E945
      H225Lib::h225SetupResponse: Q.931 CONNECT sent from socket [2]
      H225Lib::h225SetupResponse: Q.931 Call State changed to [Active].

Sample 2: Source Proxy Trace with H.225 Turned On, Call Being Torn Down

This report shows two proxy call scenarios. A trace is collected on the source proxy with H.225 turned on. The call is being torn down.

px1# debug h225 events
H.225 Event Messages debugging is on
px1#
Hex representation of the received TPKT
0300001A080200015A080200907E000A050500060008914A0001
      H225Lib::h225RecvData: Q.931 RELEASE COMPLETE received from socket [2]
      H225Lib::h225RecvData: Q.931 Call State changed to [Null].
      H225Lib::h225RecvData: no connection on socket [2]
Hex representation of the RELEASE COMPLETE TPKT to send.
0300001A080280015A080280107E000A050500060008914A0001
      H225Lib::h225TerminateRequest: Q.931 RELEASE COMPLETE sent from socket [2]. Call state changed to [Null].
      H225Lib::h225TClose: TCP connection from socket [2] closed
Hex representation of the RELEASE COMPLETE TPKT to send.
0300001A080280845A080280107E000A050500060008914A0001
      H225Lib::h225TerminateRequest: Q.931 RELEASE COMPLETE sent from socket [4]. Call state changed to [Null].
      H225Lib::h225TClose: TCP connection from socket [4] closed

Syntax Description

This command has no arguments or keywords.

Command History

Release	Modification
11.3(2)NA	This command was introduced.
12.0(3)T	This command was modified.

Caution This command slows the system down considerably and connections may time out.

Syntax Description

This command has no arguments or keywords.

Command History

Release	Modification
11.3(2)NA	This command was introduced.
12.0(3)T	This command was modified.

Syntax Description

ftp	Displays FTP events related to the authentication proxy.
function-trace	Displays the authentication proxy functions.
http	Displays HTTP events related to the authentication proxy.
object-creation	Displays additional entries to the authentication proxy cache.
object-deletion	Displays deletion of cache entries for the authentication proxy.
tcp	Displays TCP events related to the authentication proxy.
telnet	Displays Telnet related authentication proxy events.
timer	Displays authentication proxy timer-related events.

Command History

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

Usage Guidelines

Use the debug ip auth-proxy command to display authentication proxy activity. Refer to the Examples section for more information about the debug options.

Note The function-trace debugging information provides low-level software information for Cisco technical support representatives. No output examples are provided for this keyword option.

Examples

The following examples illustrates the output of the debug ip auth-proxy command. In these examples, debugging is on for object creations, object deletions, HTTP, and TCP.

In this example, the client host at 192.168.201.1 is attempting to make an HTTP connection to the web server located at 192.168.21.1. The HTTP debugging information is on for the authentication proxy. The output shows that the router is setting up an authentication proxy entry for the login request:

00:11:10: AUTH-PROXY creates info:
cliaddr - 192.168.21.1, cliport - 36583
seraddr - 192.168.201.1, serport - 80
ip-srcaddr 192.168.21.1
pak-srcaddr 0.0.0.0 

Following a successful login attempt, the debugging information shows the authentication proxy entries created for the client. In this example, the client is authorized for SMTP (port 25), FTP data (port 20), FTP control (port 21), and Telnet (port 23) traffic. The dynamic ACL entries are included in the display.

00:11:25:AUTH_PROXY OBJ_CREATE:acl item 61AD60CC
 
00:11:25:AUTH-PROXY OBJ_CREATE:create acl wrapper 6151C7C8 -- acl item 61AD60CC
00:11:25:AUTH-PROXY Src 192.168.162.216 Port [0]
00:11:25:AUTH-PROXY Dst 192.168.162.220 Port [25]
00:11:25:AUTH_PROXY OBJ_CREATE:acl item 6151C908
 
00:11:25:AUTH-PROXY OBJ_CREATE:create acl wrapper 6187A060 -- acl item 6151C908
00:11:25:AUTH-PROXY Src 192.168.162.216 Port [0]
00:11:25:AUTH-PROXY Dst 192.168.162.220 Port [20]
00:11:25:AUTH_PROXY OBJ_CREATE:acl item 61A40B88
 
00:11:25:AUTH-PROXY OBJ_CREATE:create acl wrapper 6187A0D4 -- acl item 61A40B88
00:11:25:AUTH-PROXY Src 192.168.162.216 Port [0]
00:11:25:AUTH-PROXY Dst 192.168.162.220 Port [21]
00:11:25:AUTH_PROXY OBJ_CREATE:acl item 61879550
 
00:11:25:AUTH-PROXY OBJ_CREATE:create acl wrapper 61879644 -- acl item 61879550
00:11:25:AUTH-PROXY Src 192.168.162.216 Port [0]
00:11:25:AUTH-PROXY Dst 192.168.162.220 Port [23]
 

The next example shows the debug output following a clear ip auth-proxy cache command to clear the authentication entries from the router. The dynamic ACL entries are removed from the router.

00:12:36:AUTH-PROXY OBJ_DELETE:delete auth_proxy cache 61AD6298
00:12:36:AUTH-PROXY OBJ_DELETE:delete create acl wrapper 6151C7C8 -- acl item 61AD60CC
00:12:36:AUTH-PROXY OBJ_DELETE:delete create acl wrapper 6187A060 -- acl item 6151C908
00:12:36:AUTH-PROXY OBJ_DELETE:delete create acl wrapper 6187A0D4 -- acl item 61A40B88
00:12:36:AUTH-PROXY OBJ_DELETE:delete create acl wrapper 61879644 -- acl item 61879550
 

The following example shows the timer information for a dynamic ACL entry. All times are expressed in milliseconds. The first laststart is the time that the ACL entry is created relative to the start up time of the router. The lastref is the time of the last packet to hit the dynamic ACL relative to the start up time of the router. The exptime is the next expected expiration time for the dynamic ACL. The delta indicates the remaining time before the dynamic ACL expires. After the timer expires, the debugging information includes a message indicating that the ACL and associated authentication proxy information for the client have been removed.

00:19:51:first laststart 1191112
 
00:20:51:AUTH-PROXY:delta 54220 lastref 1245332 exptime 1251112
00:21:45:AUTH-PROXY:ACL and cache are removed 

Related Commands

Command	Description
show debug	Displays the debug options set on the router.

Syntax Description

A.B.C.D.	(Optional) Displays the BGP neighbor IP address.
dampening	(Optional) Displays BGP dampening.
events	(Optional) Displays BGP events.
in	(Optional) BGP inbound information.
keepalives	(Optional) Displays BGP keepalives.
out	(Optional) Displays BGP outbound information.
updates	(Optional) Displays BGP updates.
vpnv4	(Optional) Displays VPNv4 NLRI information.

Command History

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

Examples

The following example displays the output from this command:

Router# debug ip bgp vpnv4 
03:47:14:vpn:bgp_vpnv4_bnetinit:100:2:58.0.0.0/8
03:47:14:vpn:bnettable add:100:2:58.0.0.0 / 8
03:47:14:vpn:bestpath_hook route_tag_change for vpn2:58.0.0.0/255.0.0.0(ok)
03:47:14:vpn:bgp_vpnv4_bnetinit:100:2:57.0.0.0/8
03:47:14:vpn:bnettable add:100:2:57.0.0.0 / 8
03:47:14:vpn:bestpath_hook route_tag_change for vpn2:57.0.0.0/255.0.0.0(ok)
03:47:14:vpn:bgp_vpnv4_bnetinit:100:2:14.0.0.0/8
03:47:14:vpn:bnettable add:100:2:14.0.0.0 / 8
03:47:14:vpn:bestpath_hook route_tag_chacle ip bgp *nge for vpn2:14.0.0.0/255.0.0.0(ok)

Syntax Description

This command has no arguments or keywords.

Defaults

Debugging for affinities is not enabled.

Command History

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

Examples

The following is output from the debug ip casa affinities command:

Router# debug ip casa affinities
 
16:15:36:Adding fixed affinity:
16:15:36:    10.10.1.1:54787 -> 10.10.10.10:23 proto = 6
16:15:36:Updating fixed affinity:
16:15:36:    10.10.1.1:54787 -> 10.10.10.10:23 proto = 6
16:15:36:    flags = 0x2, appl addr = 10.10.3.2, interest = 0x5/0x100
16:15:36:    int ip:port = 10.10.2.2:1638, sequence delta = 0/0/0/0
16:15:36:Adding fixed affinity:
16:15:36:    10.10.10.10:23 -> 10.10.1.1:54787 proto = 6
16:15:36:Updating fixed affinity:
16:15:36:    10.10.10.10:23 -> 10.10.1.1:54787 proto = 6
16:15:36:    flags = 0x2, appl addr = 0.0.0.0, interest = 0x3/0x104
16:15:36:    int ip:port = 10.10.2.2:1638, sequence delta = 0/0/0/0
 

Syntax Description

This command has no arguments or keywords.

Defaults

Debugging for packets is not enabled.

Command History

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

Examples

The following is output from the debug ip casa packets command:

Router# debug ip casa packets
 
16:15:36:Routing CASA packet - TO_MGR:
16:15:36:    10.10.1.1:55299 -> 10.10.10.10:23 proto = 6
16:15:36:    Interest Addr:10.10.2.2   Port:1638
16:15:36:Routing CASA packet - FWD_PKT:
16:15:36:    10.10.1.1:55299 -> 10.10.10.10:23 proto = 6
16:15:36:    Fwd Addr:10.10.3.2
16:15:36:Routing CASA packet - TO_MGR:
16:15:36:    10.10.10.10:23 -> 10.10.1.1:55299 proto = 6
16:15:36:    Interest Addr:10.10.2.2   Port:1638
16:15:36:Routing CASA packet - FWD_PKT:
16:15:36:    10.10.10.10:23 -> 10.10.1.1:55299 proto = 6
16:15:36:    Fwd Addr:0.0.0.0
16:15:36:Routing CASA packet - TICKLE:
16:15:36:    10.10.10.10:23 -> 10.10.1.1:55299 proto = 6
16:15:36:    Interest Addr:10.10.2.2   Port:1638  Interest Mask:SYN 
16:15:36:    Fwd Addr:0.0.0.0
16:15:36:Routing CASA packet - FWD_PKT:
16:15:36:    10.10.1.1:55299 -> 10.10.10.10:23 proto = 6
16:15:36:    Fwd Addr:10.10.3.2
 

Table 59: debug ip casa packets Commands Field Descriptions

Field	Description
Routing CASA packet - TO_MGR	Forwarding agent is routing a packet to the services manager.
Routing CASA packet - FWD_PKT	Forwarding agent is routing a packet to the forwarding address.
Routing CASA packet - TICKLE	Forwarding agent is signalling services manager while allowing the packet in question to take the appropriate action.
Interest Addr	Services manager address.
Interest Port	Port on the services manager where packet is sent.
Fwd Addr	Address to which packets matching the affinity are sent.
Interest Mask	Services manager that is interested in packets for this affinity.

Syntax Description

This command has no arguments or keywords.

Defaults

Debugging for wildcards is not enabled.

Command History

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

Examples

The following is output from the debug ip casa wildcards command:

Router# debug ip casa wildcards
 
16:13:23:Updating wildcard affinity:
16:13:23:    10.10.10.10:0 -> 0.0.0.0:0 proto = 6
16:13:23:    src mask = 255.255.255.255, dest mask = 0.0.0.0
16:13:23:    no frag, not advertising
16:13:23:    flags = 0x0, appl addr = 0.0.0.0, interest = 0x8107/0x8104
16:13:23:    int ip:port = 10.10.2.2:1638, sequence delta = 0/0/0/0
16:13:23:Updating wildcard affinity:
16:13:23:    0.0.0.0:0 -> 10.10.10.10:0 proto = 6
16:13:23:    src mask = 0.0.0.0, dest mask = 255.255.255.255
16:13:23:    no frag, advertising
16:13:23:    flags = 0x0, appl addr = 0.0.0.0, interest = 0x8107/0x8102
16:13:23    int ip:port = 10.10.2.2:1638, sequence delta = 0/0/0/0
 

and

Syntax Description

drops	Records dropped packets.
access-list	(Optional) Controls collection of debugging information from specified lists
receive	Records packets that are not switched using information from the FIB table, but are received and sent to the next switching layer
events	Records general CEF events.
prefix-ipc	Records updates related to IP prefix information. Possible updates include: Debugging of IP routing updates in a line card Reloading of a line card with a new table Route update from the route processor to the line card has exceeded the maximum number of routes Control messages related to FIB table prefixes
table	Produces a table showing events related to the FIB table. Possible types of events include: Routing updates that populate the FIB table Flushing of the FIB table Adding or removing of entries to the FIB table Table reloading process
ipc	Records information related to IPC in CEF. Possible types of events include: Transmission status of IPC messages Status of buffer space for ipc messages IPC messages received out of sequence Status of resequenced messages Throttle requests sent from a line card to the route processor
interface-ipc	Records IPC updates related to interfaces. Possible reporting includes an interface coming up or going down, updates to fibhwidb, fibidb, and so forth.

Syntax Description

events	Reports server events, like address assignments and database updates.
packets	Decodes DHCP receptions and transmissions.
linkage	Displays database linkage information (such as parent-child relationships in a radix tree).

Defaults

Disabled by default.

Command History

Release	Modification
12.0(1)T	This command was introduced.