|
Table Of Contents
debug ip traffic-export events
debug ip trigger-authentication
debug ip sctp api
To provide diagnostic information about Stream Control Transmission Protocol (SCTP) application programming interfaces (APIs), use the debug ip sctp api command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sctp api
no debug ip sctp api
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
In a live system, the debugging messages for performance, state, signal, and warnings are the most useful. These show any association or destination address failures and can be used to monitor the stability of any established associations.
Caution The debug ip sctp api command should not be used in a live system that has any significant amount of traffic running because it can generate a lot of traffic, which can cause associations to fail.
Examples
The following example shows SCTP calls to the API that are being executed and the parameters associated with these calls:
Router# debug ip sctp api
*Mar 1 00:31:14.211: SCTP: sctp_send: Assoc ID: 1
*Mar 1 00:31:14.211: SCTP: stream num: 10
*Mar 1 00:31:14.211: SCTP: bptr: 62EE332C, dptr: 4F7B598
*Mar 1 00:31:14.211: SCTP: datalen: 100
*Mar 1 00:31:14.211: SCTP: context: 1
*Mar 1 00:31:14.211: SCTP: lifetime: 0
*Mar 1 00:31:14.211: SCTP: unorder flag: FALSE
*Mar 1 00:31:14.211: SCTP: bundle flag: TRUE
*Mar 1 00:31:14.211: SCTP: sctp_send successful return
*Mar 1 00:31:14.211: SCTP: sctp_receive: Assoc ID: 1
*Mar 1 00:31:14.215: SCTP: max data len: 100
*Mar 1 00:31:14.215: SCTP: sctp_receive successful return
*Mar 1 00:31:14.215: SCTP: Process Send Request
*Mar 1 00:31:14.951: SCTP: sctp_receive: Assoc ID: 0
*Mar 1 00:31:14.951: SCTP: max data len: 100
*Mar 1 00:31:14.951: SCTP: sctp_receive successful return
.
.
.
Table 162 describes the significant fields shown in the display.
Related Commands
debug ip sctp congestion
To provide diagnostic information about Stream Control Transmission Protocol (SCTP) congestion parameters, use the debug ip sctp congestion command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sctp congestion
no debug ip sctp congestion
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
In a live system, the debugging messages for performance, state, signal, and warnings are the most useful. These show any association or destination address failures and can be used to monitor the stability of any established associations.
Debug commands other than those for performance, state, signal, and warnings can generate a great deal of output and therefore can cause associations to fail. These commands should be used only in test environments or when there are very low amounts of traffic.
Examples
The following example shows parameters used to calculate SCTP congestion:
Router# debug ip sctp congestion
SCTP: Assoc 0: Slow start 10.6.0.4, cwnd 3000
SCTP: Assoc 0: Data chunks rcvd, local rwnd 7800
SCTP: Assoc 0: Free chunks, local rwnd 9000
SCTP: Assoc 0: Data chunks rcvd, local rwnd 8200
SCTP: Assoc 0: Add Sack, local a_rwnd 8200
SCTP: Assoc 0: Free chunks, local rwnd 9000
SCTP: Assoc 0: Data chunks rcvd, local rwnd 7800
SCTP: Assoc 0: Data chunks rcvd, local rwnd 7000
SCTP: Assoc 0: Add Sack, local a_rwnd 7000
SCTP: Assoc 0: Free chunks, local rwnd 9000
SCTP: Assoc 0: Bundle for 10.5.0.4, rem rwnd 14000, cwnd 19500, outstand 0
SCTP: Assoc 0: Bundled 12 chunks, remote rwnd 12800, outstand 1200
SCTP: Assoc 0: Bundling data, next chunk dataLen (100) > remaining mtu size
SCTP: Assoc 0: Bundle for 10.5.0.4, rem rwnd 12800, cwnd 19500, outstand 1200
SCTP: Assoc 0: Bundled 12 chunks, remote rwnd 11600, outstand 2400
SCTP: Assoc 0: Bundling data, next chunk dataLen (100) > remaining mtu size
SCTP: Assoc 0: Bundle for 10.5.0.4, rem rwnd 11600, cwnd 19500, outstand 2400
SCTP: Assoc 0: Bundled 12 chunks, remote rwnd 10400, outstand 3600
SCTP: Assoc 0: Bundling data, next chunk dataLen (100) > remaining mtu size
SCTP: Assoc 0: Bundle for 10.5.0.4, rem rwnd 10400, cwnd 19500, outstand 3600
SCTP: Assoc 0: Bundled 4 chunks, remote rwnd 10000, outstand 4000
SCTP: Assoc 0: No additional chunks waiting.
SCTP: Assoc 0: Data chunks rcvd, local rwnd 7800
SCTP: Assoc 0: Data chunks rcvd, local rwnd 7000
SCTP: Assoc 0: Add Sack, local a_rwnd 7000
SCTP: Assoc 0: Chunk A22F3B45 ack'd, dest 10.5.0.4, outstanding 3900
SCTP: Assoc 0: Chunk A22F3B46 ack'd, dest 10.5.0.4, outstanding 3800
SCTP: Assoc 0: Chunk A22F3B47 ack'd, dest 10.5.0.4, outstanding 3700
SCTP: Assoc 0: Chunk A22F3B48 ack'd, dest 10.5.0.4, outstanding 3600
SCTP: Assoc 0: Chunk A22F3B49 ack'd, dest 10.5.0.4, outstanding 3500
SCTP: Assoc 0: Chunk A22F3B4A ack'd, dest 10.5.0.4, outstanding 3400
SCTP: Assoc 0: Chunk A22F3B4B ack'd, dest 10.5.0.4, outstanding 3300
SCTP: Assoc 0: Chunk A22F3B4C ack'd, dest 10.5.0.4, outstanding 3200
SCTP: Assoc 0: Chunk A22F3B4D ack'd, dest 10.5.0.4, outstanding 3100
SCTP: Assoc 0: Chunk A22F3B4E ack'd, dest 10.5.0.4, outstanding 3000
SCTP: Assoc 0: Chunk A22F3B4F ack'd, dest 10.5.0.4, outstanding 2900
SCTP: Assoc 0: Chunk A22F3B50 ack'd, dest 10.5.0.4, outstanding 2800
SCTP: Assoc 0: Chunk A22F3B51 ack'd, dest 10.5.0.4, outstanding 2700
SCTP: Assoc 0: Chunk A22F3B52 ack'd, dest 10.5.0.4, outstanding 2600
SCTP: Assoc 0: Chunk A22F3B53 ack'd, dest 10.5.0.4, outstanding 2500
SCTP: Assoc 0: Chunk A22F3B54 ack'd, dest 10.5.0.4, outstanding 2400
SCTP: Assoc 0: Chunk A22F3B55 ack'd, dest 10.5.0.4, outstanding 2300
SCTP: Assoc 0: Chunk A22F3B56 ack'd, dest 10.5.0.4, outstanding 2200
Table 163 describes the significant fields shown in the display.
Related Commands
debug ip sctp init
To show datagrams and other information related to the initializing of new Stream Control Transmission Protocol (SCTP) associations, use the debug ip sctp init command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sctp init
no debug ip sctp init
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
All initialization chunks are shown, including the INIT, INIT_ACK, COOKIE_ECHO, and COOKIE_ACK chunks. This debug command can be used to see the chunks associated with any initialization sequence but does not display data chunks sent once the association is established. Therefore, it is safe to use in a live system that has traffic flowing when you have trouble with associations failing and being reestablished.
Examples
The following example shows initialization chunks for SCTP associations:
Router# debug ip sctp init
*Mar 1 00:53:07.279: SCTP Test: Attempting to open assoc to remote port 8787...assoc ID is 0
*Mar 1 00:53:07.279: SCTP: Process Assoc Request
*Mar 1 00:53:07.279: SCTP: Assoc 0: dest addr list:
*Mar 1 00:53:07.279: SCTP: addr 10.5.0.4
*Mar 1 00:53:07.279: SCTP: addr 10.6.0.4
*Mar 1 00:53:07.279:
...
*Mar 1 00:53:13.279: SCTP: Assoc 0: Send Init
*Mar 1 00:53:13.279: SCTP: INIT_CHUNK, len 42
*Mar 1 00:53:13.279: SCTP: Initiate Tag: B4A10C4D, Initial TSN: B4A10C4D, rwnd 9000
*Mar 1 00:53:13.279: SCTP: Streams Inbound: 13, Outbound: 13
*Mar 1 00:53:13.279: SCTP: IP Addr: 10.1.0.2
*Mar 1 00:53:13.279: SCTP: IP Addr: 10.2.0.2
*Mar 1 00:53:13.279: SCTP: Supported addr types: 5
*Mar 1 00:53:13.307: SCTP: Process Init
*Mar 1 00:53:13.307: SCTP: INIT_CHUNK, len 42
*Mar 1 00:53:13.307: SCTP: Initiate Tag: 3C2D8327, Initial TSN: 3C2D8327, rwnd 18000
*Mar 1 00:53:13.307: SCTP: Streams Inbound: 13, Outbound: 13
*Mar 1 00:53:13.307: SCTP: IP Addr: 10.5.0.4
*Mar 1 00:53:13.307: SCTP: IP Addr: 10.6.0.4
*Mar 1 00:53:13.307: SCTP: Supported addr types: 5
*Mar 1 00:53:13.307: SCTP: Assoc 0: Send InitAck
*Mar 1 00:53:13.307: SCTP: INIT_ACK_CHUNK, len 124
*Mar 1 00:53:13.307: SCTP: Initiate Tag: B4A10C4D, Initial TSN: B4A10C4D, rwnd 9000
*Mar 1 00:53:13.307: SCTP: Streams Inbound: 13, Outbound: 13
*Mar 1 00:53:13.307: SCTP: Responder cookie len 88
*Mar 1 00:53:13.307: SCTP: IP Addr: 10.1.0.2
*Mar 1 00:53:13.307: SCTP: IP Addr: 10.2.0.2
*Mar 1 00:53:13.311: SCTP: Assoc 0: Process Cookie
*Mar 1 00:53:13.311: SCTP: COOKIE_ECHO_CHUNK, len 88
*Mar 1 00:53:13.311: SCTP: Assoc 0: dest addr list:
*Mar 1 00:53:13.311: SCTP: addr 10.5.0.4
*Mar 1 00:53:13.311: SCTP: addr 10.6.0.4
*Mar 1 00:53:13.311:
*Mar 1 00:53:13.311: SCTP: Instance 0 dest addr list:
*Mar 1 00:53:13.311: SCTP: addr 10.5.0.4
*Mar 1 00:53:13.311: SCTP: addr 10.6.0.4
*Mar 1 00:53:13.311:
*Mar 1 00:53:13.311: SCTP: Assoc 0: Send CookieAck
*Mar 1 00:53:13.311: SCTP: COOKIE_ACK_CHUNK
Table 164 describes the significant fields shown in the display.
Table 164 debug ip sctp init Field Descriptions
Field DescriptionInitiate Tag
Initiation chunk identifier.
Initial TSN
Initial transmission sequence number.
rwnd
Receiver window values.
Related Commands
debug ip sctp multihome
To show the source and destination of datagrams in order to monitor the use of the multihome addresses for Stream Control Transmission Protocol (SCTP), use the debug ip sctp multihome command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sctp multihome
no debug ip sctp multihome
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
More than one IP address parameter can be included in an initialization (INIT) chunk when the INIT sender is multihomed. Datagrams should be sent to the primary destination addresses unless the network is experiencing problems, in which case the datagrams should be sent to secondary addresses.
Caution The debug ip sctp multihome command generates one debug line for each datagram sent or received. It should be used with extreme caution in a live network.
Examples
The following example shows source and destination for multihomed addresses:
Router# debug ip sctp multihome
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 1404
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 476
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 28
SCTP: Assoc 0: Send Data to dest 10.5.0.4
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 1404
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 1404
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 1404
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 476
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 28
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 28
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 1404
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 1404
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 28
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 1404
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 476
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 28
SCTP: Assoc 0: Send Data to dest 10.5.0.4
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 1404
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 1404
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 1404
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 476
SCTP: Rcvd s=10.6.0.4 8787, d=10.2.0.2 8787, len 44
SCTP: Sent: Assoc 0: s=10.2.0.2 8787, d=10.6.0.4 8787, len 44
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 28
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 28
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 1404
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 1404
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 28
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 1404
SCTP: Rcvd s=10.5.0.4 8787, d=10.1.0.2 8787, len 476
Table 165 describes the significant fields shown in the display.
Table 165 debug ip sctp multihome Field Descriptions
Field Descriptions
Source address and port.
d
Destination address and port.
Related Commands
debug ip sctp performance
To display the average number of Stream Control Transmission Protocol (SCTP) chunks and datagrams being sent and received per second, use the debug ip sctp performance command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sctp performance
no debug ip sctp performance
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
In a live system, the debugging messages for performance, state, signal, and warnings are the most useful. These show any association or destination address failures and can be used to monitor the stability of any established associations.
Once enabled, the debug ip sctp performance command displays the average number of chunks and datagrams being sent and received per second once every 10 seconds. Note that the averages are cumulative since the last time the statistics were cleared using the clear ip sctp statistics command and may not accurately reflect the number of datagrams and chunks currently being sent and received at that particular moment.
Examples
The following example shows a low rate of traffic:
Router# debug ip sctp performance
SCTP Sent: SCTP Dgrams 5, Chunks 28, Data Chunks 29, ULP Dgrams 29
SCTP Rcvd: SCTP Dgrams 7, Chunks 28, Data Chunks 29, ULP Dgrams 29
Chunks Discarded: 0, Retransmitted 0
SCTP Sent: SCTP Dgrams 6, Chunks 29, Data Chunks 30, ULP Dgrams 30
SCTP Rcvd: SCTP Dgrams 7, Chunks 29, Data Chunks 30, ULP Dgrams 30
Chunks Discarded: 0, Retransmitted 0
Table 166 describes the significant fields shown in the display.
Related Commands
debug ip sctp rcvchunks
To provide diagnostic information about chunks received with Stream Control Transmission Protocol (SCTP), use the debug ip sctp rcvchunks command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sctp rcvchunks
no debug ip sctp rcvchunks
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The debug ip sctp rcvchunks command shows the following information about received chunks:
•Whether the chunk is for a new datagram or is part of a datagram that is being reassembled
•Whether the datagram is complete after receiving this chunk
•If the datagram is complete, whether the datagram is in sequence within the specified stream and can be delivered to the upper-layer protocol (ULP)
•The selective acknowledgments (SACKs) that are returned to the remote SCTP peer
•The cumulative transmission sequence number (Cum TSN) that was acknowledged and the number of fragments included
•Whether the datagram is received by the ULP
Caution The debug ip sctp rcvchunks command generates multiple debug lines for each chunk received. It should be used with extreme caution in a live network.
Examples
In the following example, a segmented datagram is received in two chunks for stream 0 and sequence number 0. The length of the first chunk is 1452 bytes, and the second is 1 byte. The first chunk indicates that it is for a new datagram, but the second chunk indicates that it is part of an existing datagram that is already being reassembled. When the first chunk is processed, it is noted to be in sequence, but is not complete and so cannot be delivered yet. When the second chunk is received, the datagram is both in sequence and complete. The application receives the datagram, and a SACK is shown to acknowledge that both chunks were received with no missing chunks indicated (that is, with no fragments).
Router# debug ip sctp rcvchunks
SCTP: Assoc 0: New chunk (0/0/1452/2C33D822) for new dgram (0)
SCTP: Assoc 0: dgram (0) is in seq
SCTP: Assoc 0: Add Sack Chunk, CumTSN=2C33D822, numFrags=0
SCTP: Assoc 0: New chunk (0/0/1/2C33D823) for existing dgram (0)
SCTP: Assoc 0: dgram (0) is complete
SCTP: Assoc 0: ApplRecv chunk 0/0/1452/2C33D822
SCTP: Assoc 0: ApplRecv chunk 0/0/1/2C33D823
SCTP: Assoc 0: Add Sack Chunk, CumTSN=2C33D823, numFrags=0
Table 167 describes the significant fields shown in the display.
Related Commands
debug ip sctp rto
To show adjustments that are made to the retransmission timeout (RTO) value when using Stream Control Transmission Protocol (SCTP), use the debug ip sctp rto command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sctp rto
no debug ip sctp rto
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The debug ip sctp rto command shows adjustments that are made to the retransmission timeout value (shown as retrans in the command output) because of either retransmission of data chunks or unacknowledged heartbeats.
Caution The debug ip sctp rto command can generate a great deal of output. It should be used with extreme caution in a live network.
Examples
In the following example, there is only one destination address available. Each time the chunk needs to be retransmitted, the RTO value is doubled.
Router# debug ip sctp rto
SCTP: Assoc 0: destaddr 10.5.0.4, retrans timeout on chunk 942BAC55
SCTP: Assoc 0: destaddr 10.5.0.4, rto backoff 2000 ms
SCTP: Assoc 0: destaddr 10.5.0.4, retrans timeout on chunk 942BAC55
SCTP: Assoc 0: destaddr 10.5.0.4, rto backoff 4000 ms
SCTP: Assoc 0: destaddr 10.5.0.4, retrans timeout on chunk 942BAC55
SCTP: Assoc 0: destaddr 10.5.0.4, rto backoff 8000 ms
SCTP: Assoc 0: destaddr 10.5.0.4, retrans timeout on chunk 942BAC55
SCTP: Assoc 0: destaddr 10.5.0.4, rto backoff 16000 ms
SCTP: Assoc 0: destaddr 10.5.0.4, retrans timeout on chunk 942BAC55
SCTP: Assoc 0: destaddr 10.5.0.4, rto backoff 32000 ms
Related Commands
debug ip sctp segments
To show short diagnostics for every datagram that is sent or received with Stream Control Transmission Protocol (SCTP), use the debug ip sctp segments command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sctp segments
no debug ip sctp segments
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The debug ip sctp segments command provides the short form of the output about datagrams. For the verbose form, use the debug ip sctp segmentv command.
Caution The debug ip sctp segments command generates several lines of output for each datagram sent or received. It should be used with extreme caution in a live network.
Examples
The following output shows an example in which an association is established, a few heartbeats are sent, the remote endpoint fails, and the association is restarted.
Router# debug ip sctp segments
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 56
SCTP: INIT_CHUNK, Tag: 3C72A02A, TSN: 3C72A02A
SCTP: Recv: Assoc 0: s=10.5.0.4 8787, d=10.1.0.2 8787, len 56
SCTP: INIT_CHUNK, Tag: 13E5AD6C, TSN: 13E5AD6C
SCTP: Sent: Assoc NULL: s=10.1.0.2 8787, d=10.5.0.4 8787, len 136
SCTP: INIT_ACK_CHUNK, Tag: 3C72A02A, TSN: 3C72A02A
SCTP: Recv: Assoc 0: s=10.5.0.4 8787, d=10.1.0.2 8787, len 100
SCTP: COOKIE_ECHO_CHUNK, len 88
SCTP: Sent: Assoc NULL: s=10.1.0.2 8787, d=10.5.0.4 8787, len 16
SCTP: COOKIE_ACK_CHUNK
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 52
SCTP: HEARTBEAT_CHUNK
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 52
SCTP: HEARTBEAT_CHUNK
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 52
SCTP: HEARTBEAT_CHUNK
SCTP: Recv: Assoc 0: s=10.5.0.4 8787, d=10.1.0.2 8787, len 56
SCTP: INIT_CHUNK, Tag: 4F2D8235, TSN: 4F2D8235
SCTP: Sent: Assoc NULL: s=10.1.0.2 8787, d=10.5.0.4 8787, len 136
SCTP: INIT_ACK_CHUNK, Tag: 7DD7E424, TSN: 7DD7E424
SCTP: Recv: Assoc 0: s=10.5.0.4 8787, d=10.1.0.2 8787, len 100
SCTP: COOKIE_ECHO_CHUNK, len 88
SCTP: Sent: Assoc NULL: s=10.1.0.2 8787, d=10.5.0.4 8787, len 16
SCTP: COOKIE_ACK_CHUNK
SCTP: Recv: Assoc 0: s=10.5.0.4 8787, d=10.1.0.2 8787, len 144
SCTP: SACK_CHUNK, TSN ack: 7DD7E423, rwnd 18000, num frags 0
SCTP: DATA_CHUNK, 4/0/100/4F2D8235
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 28
SCTP: SACK_CHUNK, TSN ack: 4F2D8235, rwnd 8900, num frags 0
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 128
SCTP: DATA_CHUNK, 4/0/100/7DD7E424
SCTP: Recv: Assoc 0: s=10.5.0.4 8787, d=10.1.0.2 8787, len 28
SCTP: SACK_CHUNK, TSN ack: 7DD7E424, rwnd 17900, num frags 0
SCTP: Recv: Assoc 0: s=10.6.0.4 8787, d=10.2.0.2 8787, len 44
SCTP: HEARTBEAT_CHUNK
SCTP: Sent: Assoc 0: s=10.2.0.2 8787, d=10.6.0.4 8787, len 44
SCTP: HEARTBEAT_ACK_CHUNK
SCTP: Recv: Assoc 0: s=10.5.0.4 8787, d=10.1.0.2 8787, len 128
SCTP: DATA_CHUNK, 7/0/100/4F2D8236
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 144
SCTP: SACK_CHUNK, TSN ack: 4F2D8236, rwnd 9000, num frags 0
SCTP: DATA_CHUNK, 7/0/100/7DD7E425
SCTP: Recv: Assoc 0: s=10.5.0.4 8787, d=10.1.0.2 8787, len 28
SCTP: SACK_CHUNK, TSN ack: 7DD7E424, rwnd 18000, num frags 0
SCTP: Recv: Assoc 0: s=10.5.0.4 8787, d=10.1.0.2 8787, len 28
SCTP: SACK_CHUNK, TSN ack: 7DD7E425, rwnd 17900, num frags 0
SCTP: Recv: Assoc 0: s=10.5.0.4 8787, d=10.1.0.2 8787, len 128
SCTP: DATA_CHUNK, 4/1/100/4F2D8237
Table 168 describes the significant fields shown in the display.
Related Commands
debug ip sctp segmentv
To show verbose diagnostics for every datagram that is sent or received with Stream Control Transmission Protocol (SCTP), use the debug ip sctp segmentv command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sctp segmentv
no debug ip sctp segmentv
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The debug ip sctp segmentv command provides the verbose form of the output for datagrams. For the simple form, use the debug ip sctp segments command.
Caution The debug ip sctp segmentv command generates multiple lines of output for each datagram sent and received. It should be used with extreme caution in a live network.
Examples
The following output shows an example in which an association is established, a few heartbeats are sent, the remote endpoint fails, and the association is restarted:
Router# debug ip sctp segmentv
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 56, ver tag 0
SCTP: INIT_CHUNK, len 42
SCTP: Initiate Tag: B131ED6A, Initial TSN: B131ED6A, rwnd 9000
SCTP: Streams Inbound: 13, Outbound: 13
SCTP: IP Addr: 10.1.0.2
SCTP: IP Addr: 10.2.0.2
SCTP: Supported addr types: 5
SCTP: Recv: Assoc 0: s=10.5.0.4 8787, d=10.1.0.2 8787, len 56, ver tag 0
SCTP: INIT_CHUNK, len 42
SCTP: Initiate Tag: 5516B2F3, Initial TSN: 5516B2F3, rwnd 18000
SCTP: Streams Inbound: 13, Outbound: 13
SCTP: IP Addr: 10.5.0.4
SCTP: IP Addr: 10.6.0.4
SCTP: Supported addr types: 5
SCTP: Sent: Assoc NULL: s=10.1.0.2 8787, d=10.5.0.4 8787, len 136, ver tag 5516B2F3
SCTP: INIT_ACK_CHUNK, len 124
SCTP: Initiate Tag: B131ED6A, Initial TSN: B131ED6A, rwnd 9000
SCTP: Streams Inbound: 13, Outbound: 13
SCTP: Responder cookie len 88
SCTP: IP Addr: 10.1.0.2
SCTP: IP Addr: 10.2.0.2
SCTP: Recv: Assoc 0: s=10.5.0.4 8787, d=10.1.0.2 8787, len 100, ver tag B131ED6A
SCTP: COOKIE_ECHO_CHUNK, len 88
SCTP: Sent: Assoc NULL: s=10.1.0.2 8787, d=10.5.0.4 8787, len 16, ver tag 5516B2F3
SCTP: COOKIE_ACK_CHUNK
SCTP: Recv: Assoc 0: s=10.5.0.4 8787, d=10.1.0.2 8787, len 144, ver tag B131ED6A
SCTP: SACK_CHUNK, len 16
SCTP: TSN ack: (0xB131ED69)
SCTP: Rcv win credit: 18000
SCTP: Num frags: 0
SCTP: DATA_CHUNK, flags 3, chunkLen 116
SCTP: DATA_CHUNK, 0/0/100/5516B2F3
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 28, ver tag 5516B2F3
SCTP: SACK_CHUNK, len 16
SCTP: TSN ack: (0x5516B2F3)
SCTP: Rcv win credit: 8900
SCTP: Num frags: 0
SCTP: Sent: Assoc 0: s=10.1.0.2 8787, d=10.5.0.4 8787, len 128, ver tag 5516B2F3
SCTP: DATA_CHUNK, flags 3, chunkLen 116
SCTP: DATA_CHUNK, 0/0/100/B131ED6A
SCTP: Recv: Assoc 0: s=10.6.0.4 8787, d=10.2.0.2 8787, len 44, ver tag B131ED6A
SCTP: HEARTBEAT_CHUNK
SCTP: Sent: Assoc 0: s=10.2.0.2 8787, d=10.6.0.4 8787, len 44, ver tag 5516B2F3
SCTP: HEARTBEAT_ACK_CHUNK
SCTP: Recv: Assoc 0: s=10.5.0.4 8787, d=10.1.0.2 8787, len 28, ver tag B131ED6A
SCTP: SACK_CHUNK, len 16
Table 169 describes the significant fields shown in the display.
Related Commands
debug ip sctp signal
To show signals that are sent from Stream Control Transmission Protocol (SCTP) to the application or upper-layer protocol (ULP), use the debug ip sctp signal command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sctp signal
no debug ip sctp signal
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The debug ip sctp signal command can be used to see if the current associations are stable or not. Because it generates output only on state transitions, it is safe to use in a live environment. It still should be used with caution, however, depending on the number of associations being handled by the system and the stability of the network.
The debug ip sctp state command is often used at the same time as the debug ip sctp signal command. Using the two commands together gives good insight into the stability of associations.
Examples
In the following example, a new association is requested and established. The peer then restarts the association and notes that the association failed and is being reestablished. The local peer then indicates that the association has failed because it has tried to retransmit the specified chunk more than the maximum number of times without success. As a result, the association fails (because of communication loss) and is terminated. The ULP requests that the association be attempted again, and this attempt succeeds. A shutdown is then received from the remote peer, and the local peer enters the shutdown acknowledge sent state, which is followed by the association being terminated. Again, another association attempt is made and succeeds.
Router# debug ip sctp signal
Router# debug ip sctp state
<new assoc attempt>
00:20:08: SCTP: Assoc 0: state CLOSED -> COOKIE_WAIT
00:20:15: SCTP: Assoc 0: state COOKIE_WAIT -> ESTABLISHED
00:20:15: SCTP: Assoc 0: Sent ASSOC_UP signal for CONFIGD_ASSOC
00:21:03: SCTP: Assoc 0: Restart rcvd from peer
00:21:03: SCTP: Assoc 0: Sent ASSOC_RESTART signal
00:21:04: SCTP: Assoc 0: chunk 62EA7F40 retransmitted more than max times, failing assoc
00:21:04: SCTP: Assoc 0: Sent ASSOC_FAILED signal, reason: SCTP_COMM_LOST
00:21:04: SCTP: Assoc 0: Sent ASSOC_TERMINATE signal
00:21:04: SCTP: Assoc 0: state ESTABLISHED -> CLOSED
<new assoc attempt>
00:21:04: SCTP: Assoc 0: state CLOSED -> COOKIE_WAIT
00:21:04: SCTP: Assoc 0: state COOKIE_WAIT -> COOKIE_ECHOED
00:21:04: SCTP: Assoc 0: state COOKIE_ECHOED -> ESTABLISHED
00:21:04: SCTP: Assoc 0: Sent ASSOC_UP signal for CONFIGD_ASSOC
00:21:04: SCTP: Assoc 0: Sent TERMINATE_PENDING signal
00:21:04: SCTP: Assoc 0: state ESTABLISHED -> SHUTDOWN_ACKSENT
00:21:04: SCTP: Assoc 0: Sent ASSOC_TERMINATE signal
00:21:04: SCTP: Assoc 0: state SHUTDOWN_ACKSENT -> CLOSED
<new assoc attempt>
00:21:04: SCTP: Assoc 0: state CLOSED -> COOKIE_WAIT
00:21:04: SCTP: Assoc 0: state COOKIE_WAIT -> COOKIE_ECHOED
00:21:04: SCTP: Assoc 0: state COOKIE_ECHOED -> ESTABLISHED
00:21:04: SCTP: Assoc 0: Sent ASSOC_UP signal for CONFIGD_ASSOC
Related Commands
debug ip sctp sndchunks
To show information about chunks that are being sent to remote Stream Control Transmission Protocol (SCTP) peers, use the debug ip sctp sndchunks command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sctp sndchunks
no debug ip sctp sndchunks
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The debug ip sctp sndchunks command provides the following information:
•Application send requests from the local SCTP peer
•Chunks being bundled and sent to the remote peer
•Processing of the selective acknowledgments (SACKs) from the remote peer, indicating which chunks were successfully received
•Chunks that are marked for retransmission
Caution The debug ip sctp sndchunks command generates large amounts of data if there is any significant amount of traffic flowing. It should be used with extreme caution in live networks.
Examples
The following example shows output for the debug ip sctp sndchunks command for a case in which data chunks are being sent, with some of them marked for retransmission:
Router# debug ip sctp sndchunks
SCTP: Assoc 0: ApplSend, chunk: 0/10412/100/A23134F8 to 10.5.0.4
SCTP: Assoc 0: ApplSend, chunk: 5/10443/100/A23134F9 to 10.5.0.4
SCTP: Assoc 0: ApplSend, chunk: 5/10448/100/A231355C to 10.5.0.4
SCTP: Assoc 0: Set oldest chunk for dest 10.5.0.4 to TSN A23134F8
SCTP: Assoc 0: Bundling data, added 0/10412/100/A23134F8, outstanding 100
SCTP: Assoc 0: Bundling data, added 5/10443/100/A23134F9, outstanding 200
SCTP: Assoc 0: Bundling data, added 4/10545/100/A23134FA, outstanding 300
SCTP: Assoc 0: Bundling data, added 10/10371/100/A23134FB, outstanding 400
SCTP: Assoc 0: Bundling data, added 11/10382/100/A23134FC, outstanding 500
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A231350F, numFrags=0
SCTP: Assoc 0: Reset oldest chunk on addr 10.5.0.4 to A2313510
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A2313527, numFrags=0
SCTP: Assoc 0: Reset oldest chunk on addr 10.5.0.4 to A2313528
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A231353F, numFrags=0
SCTP: Assoc 0: Reset oldest chunk on addr 10.5.0.4 to A2313540
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A2313557, numFrags=0
SCTP: Assoc 0: Reset oldest chunk on addr 10.5.0.4 to A2313558
SCTP: Assoc 0: ApplSend, chunk: 10/10385/100/A23135BE to 10.5.0.4
SCTP: Assoc 0: ApplSend, chunk: 8/10230/100/A23135BF to 10.5.0.4
SCTP: Assoc 0: ApplSend, chunk: 5/10459/100/A23135C0 to 10.5.0.4
SCTP: Assoc 0: ApplSend, chunk: 4/10558/100/A23135C1 to 10.5.0.4
SCTP: Assoc 0: Set oldest chunk for dest 10.5.0.4 to TSN A231355D
SCTP: Assoc 0: Bundling data, added 5/10449/100/A231355D, outstanding 100
SCTP: Assoc 0: Bundling data, added 3/10490/100/A231355E, outstanding 200
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A23135A4, numFrags=0
SCTP: Assoc 0: Reset oldest chunk on addr 10.5.0.4 to A23135A5
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A23135BC, numFrags=0
SCTP: Assoc 0: Reset oldest chunk on addr 10.5.0.4 to A23135BD
SCTP: Assoc 0: Process Sack Chunk, CumTSN=A23135C1, numFrags=0
SCTP: Assoc 0: ApplSend, chunk: 5/10460/100/A23135C2 to 10.5.0.4
SCTP: Assoc 0: ApplSend, chunk: 5/10461/100/A23135C3 to 10.5.0.4
SCTP: Assoc 0: ApplSend, chunk: 11/10403/100/A2313626 to 10.5.0.4
SCTP: Assoc 0: Set oldest chunk for dest 10.5.0.4 to TSN A23135C2
SCTP: Assoc 0: Bundling data, added 5/10460/100/A23135C2, outstanding 100
SCTP: Assoc 0: Bundling data, added 5/10461/100/A23135C3, outstanding 200
SCTP: Assoc 0: Bundling data, added 5/10462/100/A23135C4, outstanding 300
SCTP: Assoc 0: Bundling data, added 4/10559/100/A23135C5, outstanding 400
SCTP: Assoc 0: Bundling data, added 4/10560/100/A23135C6, outstanding 500
SCTP: Assoc 0: Bundled 12 chunk(s) in next dgram to 10.5.0.4
SCTP: Assoc 0: Bundling data, added 1/10418/100/A2313622, outstanding 9700
SCTP: Assoc 0: Bundling data, added 3/10502/100/A2313623, outstanding 9800
SCTP: Assoc 0: Bundling data, added 7/10482/100/A2313624, outstanding 9900
SCTP: Assoc 0: Bundling data, added 3/10503/100/A2313625, outstanding 10000
SCTP: Assoc 0: Bundling data, added 11/10403/100/A2313626, outstanding 10100
SCTP: Assoc 0: Bundled 5 chunk(s) in next dgram to 10.5.0.4
SCTP: Assoc 0: Mark chunk A23135C2 for retrans
SCTP: Assoc 0: Mark chunk A23135C3 for retrans
SCTP: Assoc 0: Mark chunk A23135C4 for retrans
SCTP: Assoc 0: Mark chunk A23135C5 for retrans
SCTP: Assoc 0: Mark chunk A23135C6 for retrans
SCTP: Assoc 0: Mark chunk A23135C7 for retrans
SCTP: Assoc 0: Mark chunk A23135C8 for retrans
SCTP: Assoc 0: Mark chunk A23135C9 for retrans
SCTP: Assoc 0: Mark chunk A23135CA for retrans
SCTP: Assoc 0: Bundled 6 chunk(s) in next dgram to 10.6.0.4
SCTP: Assoc 0: Mark chunk A23135C2 for retrans
SCTP: Assoc 0: Mark chunk A23135C3 for retrans
SCTP: Assoc 0: Mark chunk A23135C4 for retrans
Table 170 describes the significant fields shown in the display.
Related Commands
debug ip sctp state
To show state transitions in the Stream Control Transmission Protocol (SCTP), use the debug ip sctp state command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sctp state
no debug ip sctp state
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The debug ip sctp state command can be used to see if the current associations are stable or not. Because it generates output only on state transitions, it is safe to use in a live environment. It still should be used with caution, however, depending on the number of associations being handled by the system and the stability of the network.
The debug ip sctp state command is often used at the same time as the debug ip sctp signal command. Using the two commands together gives good insight into the stability of associations.
Examples
In the following example, a new association is requested and established. The peer then restarts the association and notes that the association failed and is being reestablished. The local peer then indicates that the association has failed because it has tried to retransmit the specified chunk more than the maximum number of times without success. As a result, the association fails (because of communication loss) and is terminated. The upper-layer protocol (ULP) requests that the association be attempted again, and this attempt succeeds. A shutdown is then received from the remote peer, and the local peer enters the shutdown acknowledge sent state, which is followed by the association being terminated. Again, another association attempt is made and succeeds.
Router# debug ip sctp signal
Router# debug ip sctp state
<new assoc attempt>
00:20:08: SCTP: Assoc 0: state CLOSED -> COOKIE_WAIT
00:20:15: SCTP: Assoc 0: state COOKIE_WAIT -> ESTABLISHED
00:20:15: SCTP: Assoc 0: Sent ASSOC_UP signal for CONFIGD_ASSOC
00:21:03: SCTP: Assoc 0: Restart rcvd from peer
00:21:03: SCTP: Assoc 0: Sent ASSOC_RESTART signal
00:21:04: SCTP: Assoc 0: chunk 62EA7F40 retransmitted more than max times, failing assoc
00:21:04: SCTP: Assoc 0: Sent ASSOC_FAILED signal, reason: SCTP_COMM_LOST
00:21:04: SCTP: Assoc 0: Sent ASSOC_TERMINATE signal
00:21:04: SCTP: Assoc 0: state ESTABLISHED -> CLOSED
<new assoc attempt>
00:21:04: SCTP: Assoc 0: state CLOSED -> COOKIE_WAIT
00:21:04: SCTP: Assoc 0: state COOKIE_WAIT -> COOKIE_ECHOED
00:21:04: SCTP: Assoc 0: state COOKIE_ECHOED -> ESTABLISHED
00:21:04: SCTP: Assoc 0: Sent ASSOC_UP signal for CONFIGD_ASSOC
00:21:04: SCTP: Assoc 0: Sent TERMINATE_PENDING signal
00:21:04: SCTP: Assoc 0: state ESTABLISHED -> SHUTDOWN_ACKSENT
00:21:04: SCTP: Assoc 0: Sent ASSOC_TERMINATE signal
00:21:04: SCTP: Assoc 0: state SHUTDOWN_ACKSENT -> CLOSED
<new assoc attempt>
00:21:04: SCTP: Assoc 0: state CLOSED -> COOKIE_WAIT
00:21:04: SCTP: Assoc 0: state COOKIE_WAIT -> COOKIE_ECHOED
00:21:04: SCTP: Assoc 0: state COOKIE_ECHOED -> ESTABLISHED
00:21:04: SCTP: Assoc 0: Sent ASSOC_UP signal for CONFIGD_ASSOC
Table 171 describes the significant fields shown in the display.
Related Commands
debug ip sctp timer
To provide information about Stream Control Transmission Protocol (SCTP) timers that are started, stopped, and triggering, use the debug ip sctp timer command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sctp timer
no debug ip sctp timer
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Many SCTP timers should not be restarted after they have been started once. For these timers, the first call succeeds in starting the timer, and subsequent calls do nothing until the timer either expires or is stopped. For example, the retransmission timer is started when the first chunk is sent, but then is not started again for subsequent chunks when there is outstanding data.
Caution The debug ip sctp timer command generates a significant amount of output. It should be used with extreme caution in a live network.
Examples
The following example shows the starting and stopping of various SCTP timers:
Router# debug ip sctp timer
SCTP: Assoc 0: Starting CUMSACK timer
SCTP: Timer already started, not restarting
SCTP: Assoc 0: Starting CUMSACK timer
SCTP: Timer already started, not restarting
SCTP: Assoc 0: Timer BUNDLE triggered
SCTP: Assoc 0: Starting RETRANS timer for destaddr 10.5.0.4
SCTP: Assoc 0: Starting RETRANS timer for destaddr 10.5.0.4
SCTP: Timer already started, not restarting
SCTP: Assoc 0: Starting RETRANS timer for destaddr 10.5.0.4
SCTP: Timer already started, not restarting
SCTP: Assoc 0: Starting RETRANS timer for destaddr 10.5.0.4
SCTP: Timer already started, not restarting
SCTP: Assoc 0: Stopping RETRANS timer for destaddr 10.5.0.4
SCTP: Assoc 0: Starting RETRANS timer for destaddr 10.5.0.4
SCTP: Assoc 0: Stopping RETRANS timer for destaddr 10.5.0.4
SCTP: Assoc 0: Starting CUMSACK timer
SCTP: Timer already started, not restarting
SCTP: Assoc 0: Starting CUMSACK timer
SCTP: Timer already started, not restarting
SCTP: Assoc 0: Starting CUMSACK timer
SCTP: Timer already started, not restarting
SCTP: Assoc 0: Starting CUMSACK timer
SCTP: Timer already started, not restarting
SCTP: Assoc 0: Starting CUMSACK timer
SCTP: Timer already started, not restarting
SCTP: Assoc 0: Stopping CUMSACK timer
SCTP: Assoc 0: Starting CUMSACK timer
SCTP: Assoc 0: Starting CUMSACK timer
SCTP: Timer already started, not restarting
Table 172 describes the significant fields shown in the display.
Table 172 debug ip sctp timer Field Descriptions
Field DescriptionCUMSACK
Cumulative selective acknowledgment.
RETRANS
Retransmission.
Related Commands
debug ip sctp warnings
To display diagnostic information about unusual situations in Stream Control Transmission Protocol (SCTP), use the debug ip sctp warnings command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sctp warnings
no debug ip sctp warnings
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
In a live system, the debugging messages for performance, state, signal, and warnings are the most useful. They show any association or destination address failures and can be used to monitor the stability of established associations.
The debug ip sctp warnings command displays information on any unusual situation that is encountered. These situations may or may not indicate problems, depending on the particulars of the situation.
Examples
The following example shows some events and conditions that are flagged as warnings:
Router# debug ip sctp warnings
SCTP: Assoc 0: No cookie in InitAck, discarding
SCTP: Assoc 0: Incoming INIT_ACK: inbound streams reqd 15, allowed 13
SCTP: Assoc 0: Incoming INIT_ACK request: outbound streams req'd 13, allowed 1
SCTP: Assoc 0: Remote verification tag in init ack is zero, discarding
SCTP: Remote verification tag in init is zero, discarding
SCTP: Assoc 0: Rwnd less than min allowed (1500) in incoming INITACK, rcvd 0
SCTP: Assoc 0: Rwnd less than min allowed (1500) in incoming INITACK, rcvd 1499
SCTP: Rwnd in INIT too small (0), discarding
SCTP: Rwnd in INIT too small (1499), discarding
SCTP: Unknown INIT param 16537 (0x4099), length 8
SCTP: Assoc 0: Unknown INITACK param 153 (0x99), length 8
SCTP: Assoc 0: No cookie in InitAck, discarding
SCTP: Assoc 0: No cookie in InitAck, discarding
SCTP: Processing INIT, invalid param len 0, discarding...
SCTP: Assoc 0: Processing INITACK, invalid param len 0, discarding...
Related Commands
debug ip sd
To display all session directory (SD) announcements received, use the debug ip sd command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sd
no debug ip sd
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
This command shows session directory announcements for multicast IP. Use it to observe multicast activity.
Examples
The following is sample output from the debug ip sd command:
Router# debug ip sd
SD: Announcement from 172.16.58.81 on Serial0.1, 146 bytes
s=*cisco: CBONE Audio
i=cisco internal-only audio conference
o=dino@dino-ss20.cisco.com
c=224.0.255.1 16 2891478496 2892688096
m=audio 31372 1700
SD: Announcement from 172.22.246.68 on Serial0.1, 147 bytes
s=IMS: U.S. Senate
i=U.S. Senate at http://town.hall.org/radio/live.html
o=carl@also.radio.com
c=224.2.252.231 95 0 0
m=audio 36572 2642
a=fmt:gsm
Table 173 describes the significant fields shown in the display.
Related Commands
debug ip sdee
To enable debug messages for Security Device Event Exchange (SDEE) notification events, use the debug ip sdee command in privileged EXEC mode. To disable SDEE debugging output, use the no form of this command.
debug ip sdee [alerts] [detail] [messages] [requests] [subscriptions]
no debug ip sdee [alerts] [detail] [messages] [requests] [subscriptions]
Syntax Description
Command Modes
Privileged EXEC
Command History
Examples
The following is sample SDEE debugging output. In this example, you can see which messages correspond to SDEE alerts, requests, and subscriptions.
Router# debug ip sdee alerts requests subscriptions
5d00h:SDEE:got request from client at 10.0.0.2
5d00h:SDEE:reported 13 events for client at 10.0.0.2
5d00h:SDEE:GET request for client 10.0.0.2 subscription IDS1720:0
5d00h:SDEE:reported 50 events for client 10.0.0.2 subscription IDS1720:0
5d00h: SDEE alert:sigid 2004 name ICMP Echo Req from 10.0.0.2 time 1021174067
5d00h: SDEE alert:sigid 2004 name ICMP Echo Req from 10.0.0.2 time 1021174071
5d00h: SDEE alert:sigid 2004 name ICMP Echo Req from 10.0.0.2 time 1021174072
5d00h: SDEE alert:sigid 2004 name ICMP Echo Req from 10.0.0.2 time 1021175127
5d00h:SDEE:missed events for IDS1720:0
Related Commands
debug ip security
To display IP security option processing, use the debug ip security command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip security
no debug ip security
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
The debug ip security command displays information for both basic and extended IP security options. For interfaces where ip security is configured, each IP packet processed for that interface results in debugging output regardless of whether the packet contains IP security options. IP packets processed for other interfaces that also contain IP security information also trigger debugging output. Some additional IP security debugging information is also controlled by the debug ip packet command in privileged EXEC mode.
Caution Because the debug ip security command generates a substantial amount of output for every IP packet processed, use it only when traffic on the IP network is low, so other activity on the system is not adversely affected.
Examples
The following is sample output from the debug ip security command:
Router# debug ip security
IP Security: src 172.24.72.52 dst 172.24.72.53, number of BSO 1
idb: NULL
pak: insert (0xFF) 0x0
IP Security: BSO postroute: SECINSERT changed to secret (0x5A) 0x10
IP Security: src 172.24.72.53 dst 172.24.72.52, number of BSO 1
idb: secret (0x6) 0x10 to secret (0x6) 0x10, no implicit
def secret (0x6) 0x10
pak: secret (0x5A) 0x10
IP Security: checking BSO 0x10 against [0x10 0x10]
IP Security: classified BSO as secret (0x5A) 0x10
Table 174 describes significant fields shown in the display.
The following line indicates that the packet was locally generated, and it has been classified with the internally significant security level "insert" (0xff) and authority information of 0x0:
idb: NULL
pak: insert (0xff) 0x0
The following line indicates that the packet was received via an interface with dedicated IP security configured. Specifically, the interface is configured at security level "secret" and with authority information of 0x0. The packet itself was classified at level "secret" (0x5a) and authority information of 0x10.
idb: secret (0x6) 0x10 to secret (0x6) 0x10, no implicit
def secret (0x6) 0x10
pak: secret (0x5A) 0x10
debug ip sla apm
To enable debugging output for Cisco IOS IP Service Level Agreements (SLAs) Application Performance Monitor (APM) operations, use the debug ip sla apm command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sla apm
no debug ip sla apm
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Release Modification12.3(14)T
This command was introduced. This command replaces the debug ip sla monitor apm command.
Examples
The following is sample output from the debug ip sla apm command:
Router# debug ip sla apm
Router# configure terminal
Router(config)# ip sla apm operation 123 start ftp://apm/config/iptv.cf
21:40:27: SAA-APM-123: downloading file (apm/config/iptv.cf) of size (534)
21:40:29: SAA-APM-123: downloading file (apm/scheduler/master.sch) of size (2500)
21:40:30: SAA-APM-123: downloading file (apm/scripts/iptv.scr) of size (1647)
21:40:32: SAA-APM-123: downloading file (apm/data/iptv.dat) of size (118)
21:40:32: SAA-APM-123: sending APM_CAPABILITIES_REQUEST message
21:40:32: sending control msg:
21:40:32: Ver: 1 ID: 29 Len: 48
21:40:32: SAA-APM-123: apm_engine version: major<1>, minor<0>
21:40:32: SAA-APM-123: sending APM_SCRIPT_DNLD message
21:40:32: sending control msg:
21:40:32: Ver: 1 ID: 30 Len: 148
21:40:37: SAA-APM-123: sending APM_SCRIPT_DNLD_STATUS message
21:40:37: sending control msg:
21:40:37: Ver: 1 ID: 31 Len: 148
21:40:38: SAA-APM-123: starting the operation
21:40:38: SAA-APM-123: sending APM_SCRIPT_START message
21:40:38: sending control msg:
21:40:38: Ver: 1 ID: 32 Len: 148
21:40:41: SAA-APM: 0,2144,0
.
.
.
21:49:42: SAA-APM-123: waiting for ageout timer to expire
21:55:13: SAA-APM-123: sending APM_SCRIPT_DONE message
21:55:13: sending control msg:
21:55:13: Ver: 1 ID: 42 Len: 148
21:55:13: SAA-APM-123: operation done
Router(config)# no ip sla apm
21:55:13: SAA-APM-123: sending APM_SCRIPT_DONE message
21:55:13: sending control msg:
21:55:13: Ver: 1 ID: 42 Len: 148
21:55:13: SAA-APM-123: operation done
debug ip sla error
To enable debugging output of Cisco IOS IP Service Level Agreements (SLAs) operation run-time errors, use the debug ip sla error command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sla error [operation-number]
no debug ip sla error [operation-number]
Syntax Description
operation-number
(Optional) Identification number of the operation for which debugging output is to be enabled.
Command Modes
Privileged EXEC
Command History
Release Modification12.4(4)T
This command was introduced. This command replaces the debug ip sla monitor error command.
Usage Guidelines
The debug ip sla error command displays run-time errors. When an operation number other than 0 is specified, all run-time errors for that operation are displayed when the operation is active. When the operation number is 0, all run-time errors relating to the IP SLAs scheduler process are displayed. When no operation number is specified, all run-time errors for all active operations configured on the router are displayed.
Note Use the debug ip sla error command before using the debug ip sla trace command because the debug ip sla error command generates a lesser amount of debugging output.
Examples
The following is sample output from the debug ip sla error command. The output indicates failure because the target is not there or because the responder is not enabled on the target. All debugging output for IP SLAs (including the output from the debug ip sla trace command) has the format shown in Table 176.
Router# debug ip sla error
May 5 05:00:35.483: control message failure:1
May 5 05:01:35.003: control message failure:1
May 5 05:02:34.527: control message failure:1
May 5 05:03:34.039: control message failure:1
May 5 05:04:33.563: control message failure:1
May 5 05:05:33.099: control message failure:1
May 5 05:06:32.596: control message failure:1
May 5 05:07:32.119: control message failure:1
May 5 05:08:31.643: control message failure:1
May 5 05:09:31.167: control message failure:1
May 5 05:10:30.683: control message failure:1
Table 176 describes the significant fields shown in the display.
Related Commands
debug ip sla monitor apm
Note Effective with Cisco IOS Release 12.4(4)T, the debug ip sla monitor apm command is replaced by the debug ip sla apm command. See the debug ip sla apm command for more information.
To enable debugging output for Cisco IOS IP Service Level Agreements (SLAs) Application Performance Monitor (APM) operations, use the debug ip sla monitor apm command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sla monitor apm
no debug ip sla monitor apm
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Release Modification12.3(14)T
This command was introduced. This command replaces the debug saa apm command.
12.4(4)T
This command was replaced by the debug ip sla apm command.
Examples
The following is sample output from the debug ip sla monitor apm command:
Router# debug ip sla monitor apm
Router# configure terminal
Router(config)# ip sla monitor apm operation 123 start ftp://apm/config/iptv.cf
21:40:27: SAA-APM-123: downloading file (apm/config/iptv.cf) of size (534)
21:40:29: SAA-APM-123: downloading file (apm/scheduler/master.sch) of size (2500)
21:40:30: SAA-APM-123: downloading file (apm/scripts/iptv.scr) of size (1647)
21:40:32: SAA-APM-123: downloading file (apm/data/iptv.dat) of size (118)
21:40:32: SAA-APM-123: sending APM_CAPABILITIES_REQUEST message
21:40:32: sending control msg:
21:40:32: Ver: 1 ID: 29 Len: 48
21:40:32: SAA-APM-123: apm_engine version: major<1>, minor<0>
21:40:32: SAA-APM-123: sending APM_SCRIPT_DNLD message
21:40:32: sending control msg:
21:40:32: Ver: 1 ID: 30 Len: 148
21:40:37: SAA-APM-123: sending APM_SCRIPT_DNLD_STATUS message
21:40:37: sending control msg:
21:40:37: Ver: 1 ID: 31 Len: 148
21:40:38: SAA-APM-123: starting the operation
21:40:38: SAA-APM-123: sending APM_SCRIPT_START message
21:40:38: sending control msg:
21:40:38: Ver: 1 ID: 32 Len: 148
21:40:41: SAA-APM: 0,2144,0
.
.
.
21:49:42: SAA-APM-123: waiting for ageout timer to expire
21:55:13: SAA-APM-123: sending APM_SCRIPT_DONE message
21:55:13: sending control msg:
21:55:13: Ver: 1 ID: 42 Len: 148
21:55:13: SAA-APM-123: operation done
Router(config)# no ip sla monitor apm
21:55:13: SAA-APM-123: sending APM_SCRIPT_DONE message
21:55:13: sending control msg:
21:55:13: Ver: 1 ID: 42 Len: 148
21:55:13: SAA-APM-123: operation done
debug ip sla monitor error
Note Effective with Cisco IOS Release 12.4(4)T, the debug ip sla monitor error command is replaced by the debug ip sla error command. See the debug ip sla error command for more information.
To enable debugging output of Cisco IOS IP Service Level Agreements (SLAs) operation run-time errors, use the debug ip sla monitor error command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sla monitor error [operation-number]
no debug ip sla monitor error [operation-number]
Syntax Description
operation-number
(Optional) Identification number of the operation for which debugging output is to be enabled.
Command Modes
Privileged EXEC
Command History
Release Modification12.3(14)T
This command was introduced. This command replaces the debug rtr error command.
12.4(4)T
This command was replaced by the debug ip sla error command.
Usage Guidelines
The debug ip sla monitor error command displays run-time errors. When an operation number other than 0 is specified, all run-time errors for that operation are displayed when the operation is active. When the operation number is 0, all run-time errors relating to the IP SLAs scheduler process are displayed. When no operation number is specified, all run-time errors for all active operations configured on the router are displayed.
Note Use the debug ip sla monitor error command before using the debug ip sla monitor trace command because the debug ip sla monitor error command generates a lesser amount of debugging output.
Examples
The following is sample output from the debug ip sla monitor error command. The output indicates failure because the target is not there or because the responder is not enabled on the target. All debugging output for IP SLAs (including the output from the debug ip sla monitor trace command) has the format shown in Table 176.
Router# debug ip sla monitor error
May 5 05:00:35.483: control message failure:1
May 5 05:01:35.003: control message failure:1
May 5 05:02:34.527: control message failure:1
May 5 05:03:34.039: control message failure:1
May 5 05:04:33.563: control message failure:1
May 5 05:05:33.099: control message failure:1
May 5 05:06:32.596: control message failure:1
May 5 05:07:32.119: control message failure:1
May 5 05:08:31.643: control message failure:1
May 5 05:09:31.167: control message failure:1
May 5 05:10:30.683: control message failure:1
Table 176 describes the significant fields shown in the display.
Related Commands
debug ip sla monitor slm
Note Effective with Cisco IOS Release 12.4(4)T, the debug ip sla monitor slm command is replaced by the debug ip sla slm command. See the debug ip sla slm command for more information.
To enable debugging output of detailed event messages for Cisco IOS IP Service Level Agreements (SLAs) Service Level Monitoring (SLM) Asynchronous Transfer Mode (ATM) operations, use the debug ip sla monitor slm command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sla monitor slm
no debug ip sla monitor slm
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Release Modification12.3(14)T
This command was introduced. This command replaces the debug saa slm command.
12.4(4)T
This command was replaced by the debug ip sla slm command.
Usage Guidelines
IP SLAs SLM ATM performance statistics cannot be retrieved from Cisco IOS devices using Simple Network Management Protocol (SNMP). The IP SLAs SLM ATM feature was designed to provide data by responding to extensible markup language (XML) requests.
Note This command may generate a large number of debugging messages.
Examples
In the following example, debugging is enabled for the IP SLAs SLM ATM feature and the IP SLAs XML feature for the purposes of debugging the XML requests and responses:
debug ip sla monitor slm
debug ip sla monitor xml
Related Commands
Command Descriptiondebug ip sla monitor xml
Enables debugging output of XML requests and responses for IP SLAs operations.
debug ip sla monitor trace
Note Effective with Cisco IOS Release 12.4(4)T, the debug ip sla monitor trace command is replaced by the debug ip sla trace command. See the debug ip sla trace command for more information.
To trace the execution of a Cisco IOS IP Service Level Agreements (SLAs) operation, use the debug ip sla monitor trace command in privileged EXEC mode. To disable trace debugging output, use the no form of this command.
debug ip sla monitor trace [operation-number]
no debug ip sla monitor trace [operation-number]
Syntax Description:
operation-number
(Optional) Identification number of the operation for which debugging output is to be enabled.
Command Modes
Privileged EXEC
Command History
Release Modification12.3(14)T
This command was introduced. This command replaces the debug rtr trace command.
12.4(4)T
This command was replaced by the debug ip sla trace command.
Usage Guidelines
When an operation number other than 0 is specified, execution for that operation is traced. When the operation number is 0, the IP SLAs scheduler process is traced. When no operation number is specified, all active operations are traced.
The debug ip sla monitor trace command also enables debug ip sla monitor error command for the specified operation. However, the no debug ip sla monitor trace command does not disable the debug ip sla monitor error command. You must manually disable the command by using the no debug ip sla monitor error command.
All debuggng output (including debug ip sla monitor error command output) has the format shown in the debug ip sla monitor error command output example.
Note The debug ip sla monitor trace command can generate a large number of debug messages. First use the debug ip sla monitor error command, and then use the debug ip sla monitor trace on a per-operation basis.
Examples
The following is sample output from the debug ip sla monitor trace command. In this example, an operation is traced through a single operation attempt: the setup of a connection to the target, and the attempt at an echo to calculate UDP packet response time.
Router# debug ip sla monitor trace
Router# IP SLA Monitor 1:Starting An Echo Operation - IP SLA Monitor Probe 1
May 5 05:25:08.584:rtt hash insert :3.0.0.3 3383
May 5 05:25:08.584: source=3.0.0.3(3383) dest-ip=5.0.0.1(9)
May 5 05:25:08.588:sending control msg:
May 5 05:25:08.588: Ver:1 ID:51 Len:52
May 5 05:25:08.592:cmd:command:RTT_CMD_UDP_PORT_ENABLE, ip:5.0.0.1, port:9, duration:5000
May 5 05:25:08.607:receiving reply
May 5 05:25:08.607: Ver:1 ID:51 Len:8
May 5 05:25:08.623: local delta:8
May 5 05:25:08.627: delta from responder:1
May 5 05:25:08.627: received <16> bytes and responseTime = 3 (ms)
May 5 05:25:08.631:rtt hash remove:3.0.0.3 3383IP SLA Monitor 1:Starting An Echo Operation - IP SLA Monitor Probe 1
May 5 05:26:08.104:rtt hash insert :3.0.0.3 2974
May 5 05:26:08.104: source=3.0.0.3(2974) dest-ip=5.0.0.1(9)
May 5 05:26:08.108:sending control msg:
May 5 05:26:08.108: Ver:1 ID:52 Len:52
May 5 05:26:08.112:cmd:command:RTT_CMD_UDP_PORT_ENABLE, ip:5.0.0.1, port:9, duration:5000
May 5 05:26:08.127:receiving reply
May 5 05:26:08.127: Ver:1 ID:52 Len:8
May 5 05:26:08.143: local delta:8
May 5 05:26:08.147: delta from responder:1
May 5 05:26:08.147: received <16> bytes and responseTime = 3 (ms)
May 5 05:26:08.151:rtt hash remove:3.0.0.3 2974IP SLA Monitor 1:Starting An Echo Operation - IP SLA Monitor Probe 1
Related Commands
Command Descriptiondebug ip sla monitor error
Enables debugging output of IP SLAs operation run-time errors.
debug ip sla monitor xml
Note Effective with Cisco IOS Release 12.4(4)T, the debug ip sla monitor xml command is replaced by the debug ip sla xml command. See the debug ip sla xml command for more information.
To enable debugging output of eXtensible Markup Language (XML) requests and responses for Cisco IOS IP Service Level Agreements (SLAs) operations, use the debug ip sla monitor xml command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sla monitor xml
no debug ip sla monitor xml
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Release Modification12.3(14)T
This command was introduced. This command replaces the debug saa xml command.
12.4(4)T
This command was replaced by the debug ip sla xml command.
Examples
In the following example, debugging is enabled for the IP SLAs SLM ATM feature and the IP SLAs eXtensible Markup Language (XML) feature for the purposes of debugging the XML requests and responses:
debug ip sla monitor slm
debug ip sla monitor xml
Related Commands
Command Descriptiondebug ip sla monitor slm
Enables debugging output of detailed event messages for IP SLAs SLM ATM operations.
debug ip sla mpls-lsp-monitor
To enable debugging output for the IP Service Level Agreements (SLAs) label switched path (LSP) Health Monitor, use the debug ip sla mpls-lsp-monitor command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sla mpls-lsp-monitor [operation-number]
no debug ip sla mpls-lsp-monitor [operation-number]
Syntax Description
operation-number
(Optional) Number of the LSP Health Monitor operation for which the debugging output will be displayed.
Command Default
Debugging is not enabled.
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the debug ip sla mpls-lsp-monitor command. This output shows that three VPNs associated with router 10.10.10.8 (red, blue, and green) were discovered and that this information was added to the LSP Health Monitor scan queue. Also, since router 10.10.10.8 is a newly discovered Border Gateway Protocol (BGP) next hop neighbor, a new IP SLAs operation for router 10.10.10.8 (Probe 100005) is being created, and added to the LSP Health Monitor multioperation schedule. Even though router 10.10.10.8 belongs to three VPNs, only one IP SLAs operation is being created.
Router# debug ip sla mpls-lsp-monitor
IP SLAs MPLSLM debugging for all entries is on
*Aug 19 19:59: IP SLAs MPLSLM(1):Next hop 10.10.10.8 added in AddQ
*Aug 19 19:59: IP SLAs MPLSLM(1):Next hop 10.10.10.8 added in AddQ
*Aug 19 19:59: IP SLAs MPLSLM(1):Next hop 10.10.10.8 added in AddQ
*Aug 19 19:59: IP SLAs MPLSLM(1):Adding vrf red into tree entry 10.10.10.8
*Aug 19 19:59: IP SLAs MPLSLM(1):Adding Probe 100005
*Aug 19 19:59: IP SLAs MPLSLM(1):Adding ProbeID 100005 to tree entry 10.10.10.8 (1)
*Aug 19 19:59: IP SLAs MPLSLM(1):Adding vrf blue into tree entry 10.10.10.8
*Aug 19 19:59: IP SLAs MPLSLM(1):Duplicate in AddQ 10.10.10.8
*Aug 19 19:59: IP SLAs MPLSLM(1):Adding vrf green into tree entry 10.10.10.8
*Aug 19 19:59: IP SLAs MPLSLM(1):Duplicate in AddQ 10.10.10.8
*Aug 19 19:59: IP SLAs MPLSLM(1):Added Probe(s) 100005 will be scheduled after 26 secs over schedule period 60
Related Commands
Command Descriptionauto ip sla mpls-lsp-monitor
Begins configuration for an IP SLAs LSP Health Monitor operation and enters auto IP SLA MPLS configuration mode.
debug ip sla slm
To enable debugging output of detailed event messages for Cisco IOS IP Service Level Agreements (SLAs) Service Level Monitoring (SLM) Asynchronous Transfer Mode (ATM) operations, use the debug ip sla slm command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sla slm
no debug ip sla slm
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Release Modification12.3(14)T
This command was introduced. This command replaces the debug ip sla monitor slm command.
Usage Guidelines
IP SLAs SLM ATM performance statistics cannot be retrieved from Cisco IOS devices using Simple Network Management Protocol (SNMP). The IP SLAs SLM ATM feature was designed to provide data by responding to extensible markup language (XML) requests.
Note This command may generate a large number of debugging messages.
Examples
In the following example, debugging is enabled for the IP SLAs SLM ATM feature and the IP SLAs XML feature for the purposes of debugging the XML requests and responses:
debug ip sla slm
debug ip sla xml
Related Commands
Command Descriptiondebug ip sla xml
Enables debugging output of XML requests and responses for IP SLAs operations.
debug ip sla trace
To trace the execution of a Cisco IOS IP Service Level Agreements (SLAs) operation, use the debug ip sla trace command in privileged EXEC mode. To disable trace debugging output, use the no form of this command.
debug ip sla trace [operation-number]
no debug ip sla trace [operation-number]
Syntax Description:
operation-number
(Optional) Identification number of the operation for which debugging output is to be enabled.
Command Modes
Privileged EXEC
Command History
Release Modification12.4(4)T
This command was introduced. This command replaces the debug ip sla monitor trace command.
Usage Guidelines
When an operation number other than 0 is specified, execution for that operation is traced. When the operation number is 0, the IP SLAs scheduler process is traced. When no operation number is specified, all active operations are traced.
The debug ip sla trace command also enables debug ip sla error command for the specified operation. However, the no debug ip sla trace command does not disable the debug ip sla error command. You must manually disable the command by using the no debug ip sla error command.
All debuggng output (including debug ip sla error command output) has the format shown in the debug ip sla error command output example.
Note The debug ip sla trace command can generate a large number of debug messages. First use the debug ip sla error command, and then use the debug ip sla trace on a per-operation basis.
Examples
The following is sample output from the debug ip sla trace command. In this example, an operation is traced through a single operation attempt: the setup of a connection to the target, and the attempt at an echo to calculate UDP packet response time.
Router# debug ip sla trace
Router# IP SLA Monitor 1:Starting An Echo Operation - IP SLA Monitor Probe 1
May 5 05:25:08.584:rtt hash insert :3.0.0.3 3383
May 5 05:25:08.584: source=3.0.0.3(3383) dest-ip=5.0.0.1(9)
May 5 05:25:08.588:sending control msg:
May 5 05:25:08.588: Ver:1 ID:51 Len:52
May 5 05:25:08.592:cmd:command:RTT_CMD_UDP_PORT_ENABLE, ip:5.0.0.1, port:9, duration:5000
May 5 05:25:08.607:receiving reply
May 5 05:25:08.607: Ver:1 ID:51 Len:8
May 5 05:25:08.623: local delta:8
May 5 05:25:08.627: delta from responder:1
May 5 05:25:08.627: received <16> bytes and responseTime = 3 (ms)
May 5 05:25:08.631:rtt hash remove:3.0.0.3 3383IP SLA Monitor 1:Starting An Echo Operation - IP SLA Monitor Probe 1
May 5 05:26:08.104:rtt hash insert :3.0.0.3 2974
May 5 05:26:08.104: source=3.0.0.3(2974) dest-ip=5.0.0.1(9)
May 5 05:26:08.108:sending control msg:
May 5 05:26:08.108: Ver:1 ID:52 Len:52
May 5 05:26:08.112:cmd:command:RTT_CMD_UDP_PORT_ENABLE, ip:5.0.0.1, port:9, duration:5000
May 5 05:26:08.127:receiving reply
May 5 05:26:08.127: Ver:1 ID:52 Len:8
May 5 05:26:08.143: local delta:8
May 5 05:26:08.147: delta from responder:1
May 5 05:26:08.147: received <16> bytes and responseTime = 3 (ms)
May 5 05:26:08.151:rtt hash remove:3.0.0.3 2974IP SLA Monitor 1:Starting An Echo Operation - IP SLA Monitor Probe 1
Related Commands
Command Descriptiondebug ip sla error
Enables debugging output of IP SLAs operation run-time errors.
debug ip sla xml
To enable debugging output of eXtensible Markup Language (XML) requests and responses for Cisco IOS IP Service Level Agreements (SLAs) operations, use the debug ip sla xml command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip sla xml
no debug ip sla xml
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Release Modification12.3(14)T
This command was introduced. This command replaces the debug ip sla monitor xml command.
Examples
In the following example, debugging is enabled for the IP SLAs SLM ATM feature and the IP SLAs eXtensible Markup Language (XML) feature for the purposes of debugging the XML requests and responses:
debug ip sla slm
debug ip sla xml
Related Commands
Command Descriptiondebug ip sla slm
Enables debugging output of detailed event messages for IP SLAs SLM ATM operations.
debug ip slb
To display debugging messages for the Cisco IOS Server Load Balancing (SLB) feature, use the debug ip slb command in privileged EXEC mode. To disable debug output, use the no form of this command.
debug ip slb {conns | dfp | icmp | reals | all}
no debug ip slb {conns | dfp | icmp | reals | all}
Syntax Description
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Release Modification12.0(7)XE
This command was introduced.
12.1(5)T
This command was integrated into Cisco IOS Release 12.1(5)T.
Usage Guidelines
See the following caution before using debug commands.
Caution Because debugging output is assigned high priority in the CPU process, it can render the system unusable. For this reason, only use debug commands to troubleshoot specific problems or during troubleshooting sessions with Cisco technical support staff. Moreover, it is best to use debug commands during periods of lower network flows and fewer users. Debugging during these periods reduces the effect these commands have on other users on the system.
Examples
The following example configures a debug session to check all IP IOS SLB parameters:
Router# debug ip slb all
SLB All debugging is on
Router#
The following example stops all debugging:
Router# no debug all
All possible debugging has been turned off
Router#
The following example shows Cisco IOS SLB DFP debug output:
Router# debug ip slb dfp
SLB DFP debugging is on
router#
022048 SLB DFP Queue to main queue - type 2 for Agent 161.44.2.3458229
022048 SLB DFP select_rc = -1 readset = 0
022048 SLB DFP Sleeping ...
022049 SLB DFP readset = 0
022049 SLB DFP select_rc = -1 readset = 0
022049 SLB DFP Processing Q event for Agent 161.44.2.3458229 - OPEN
022049 SLB DFP Queue to conn_proc_q - type 2 for Agent 161.44.2.3458229
022049 SLB DFP readset = 0
022049 SLB DFP Set SLB_DFP_SIDE_QUEUE
022049 SLB DFP Processing Conn Q event for Agent 161.44.2.3458229 - OPEN
022049 SLB DFP Open to Agent 161.44.2.3458229 succeeded, socket = 0
022049 SLB DFP Agent 161.44.2.3458229 start connect
022049 SLB DFP Connect to Agent 161.44.2.3458229 successful - socket 0
022049 SLB DFP Queue to main queue - type 6 for Agent 161.44.2.3458229
022049 SLB DFP Processing Conn Q unknown MAJOR 80
022049 SLB DFP Reset SLB_DFP_SIDE_QUEUE
022049 SLB DFP select_rc = -1 readset = 0
022049 SLB DFP Sleeping ...
022050 SLB DFP readset = 1
022050 SLB DFP select_rc = 1 readset = 1
022050 SLB DFP Agent 161.44.2.3458229 fd = 0 readset = 1
022050 SLB DFP Message length 44 from Agent 161.44.2.3458229
022050 SLB DFP Agent 161.44.2.3458229 setting Host 17.17.17.17, Bind ID 1 Weight 1
022050 SLB DFP Agent 161.44.2.3458229 setting Host 34.34.34.34, Bind ID 2 Weight 2
022050 SLB DFP Agent 161.44.2.3458229 setting Host 51.51.51.51, Bind ID 3 Weight 3
022050 SLB DFP Processing Q event for Agent 161.44.2.3458229 - WAKEUP
022050 SLB DFP readset = 1
022050 SLB DFP select_rc = 1 readset = 1
022050 SLB DFP Agent 161.44.2.3458229 fd = 0 readset = 1
022050 SLB DFP Message length 64 from Agent 161.44.2.3458229
022050 SLB DFP Agent 161.44.2.3458229 setting Host 17.17.17.17, Bind ID 1 Weight 1
022050 SLB DFP Agent 161.44.2.3458229 setting Host 68.68.68.68, Bind ID 4 Weight 4
022050 SLB DFP Agent 161.44.2.3458229 setting Host 85.85.85.85, Bind ID 5 Weight 5
022050 SLB DFP Agent 161.44.2.3458229 setting Host 17.17.17.17, Bind ID 111 Weight 111
022050 SLB DFP readset = 1
022115 SLB DFP Queue to main queue - type 5 for Agent 161.44.2.3458229
022115 SLB DFP select_rc = -1 readset = 0
022115 SLB DFP Sleeping ...
022116 SLB DFP readset = 1
022116 SLB DFP select_rc = -1 readset = 0
022116 SLB DFP Processing Q event for Agent 161.44.2.3458229 - DELETE
022116 SLB DFP Queue to conn_proc_q - type 5 for Agent 161.44.2.3458229
022116 SLB DFP readset = 1
022116 SLB DFP Set SLB_DFP_SIDE_QUEUE
022116 SLB DFP Processing Conn Q event for Agent 161.44.2.3458229 - DELETE
022116 SLB DFP Connection to Agent 161.44.2.3458229 closed
022116 SLB DFP Agent 161.44.2.3458229 deleted
022116 SLB DFP Processing Conn Q unknown MAJOR 80
022116 SLB DFP Reset SLB_DFP_SIDE_QUEUE
022116 SLB DFP Set SLB_DFP_SIDE_QUEUE
022116 SLB DFP Reset SLB_DFP_SIDE_QUEUE
debug ip snat
To display information about IP packets translated by the IP stateful network address translation (SNAT) feature, use the debug ip snat command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip snat [detailed]
no debug ip snat [detailed]
Syntax Description
Defaults
Disabled
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The SNAT feature allows two or more network address translators to function as a translation group. One member of the translation group handles traffic requiring translation of IP address information. It informs the backup translator of active flows as they occur. The backup translator can then use information from the active translator to prepare duplicate translation table entries enabling the backup translator to become the active translator in the event of a critical failure. Traffic continues to flow without interruption because the same network address translations are used and the state of those translations has been previously defined.
Caution Because the debug ip snat command generates a significant amount of output, use it only when traffic on the IP network is low, so other activity on the system is not adversely affected.
Examples
The following is sample output from the debug ip snat command:
Router# debug ip snat detailed
2w6d:SNAT:Establish TCP peers for PRIMARY
2w6d:SNAT (Send):Enqueuing SYNC Message for Router-Id 100
2w6d:SNAT(write2net):192.168.123.2 <---> 192.168.123.3 send message
2w6d:SNAT(write2net):ver 2, id 100, opcode 1, len 68
2w6d:SNAT (Send):Enqueuing DUMP-REQUEST Message for Router-Id 100
2w6d:SNAT(write2net):192.168.123.2 <---> 192.168.123.3 send message
2w6d:SNAT(write2net):ver 2, id 100, opcode 6, len 68
2w6d:SNAT (readfromnet):Enqueuing SYNC Message msg to readQ
2w6d:SNAT (Receive):Processed SYNC Message from Router-Id:0 for Router-Id:200's entry/entries
2w6d:SNAT (readfromnet):Enqueuing DUMP-REQUEST Message msg to readQ
try/entries
2w6d:SNAT(sense):Send SYNC message
2w6d:SNAT (Send):Enqueuing SYNC Message for Router-Id 100
2w6d:SNAT(write2net):192.168.123.2 <---> 192.168.123.3 send message
2w6d:SNAT(write2net):ver 2, id 100, opcode 1, len 68
2w6d:SNAT (readfromnet):Enqueuing SYNC Message msg to readQ
2w6d:SNAT (Receive):Processed SYNC Message from Router-Id:200 for Router-Id:200's entry/entries
Table 177 describes the significant fields shown in the display.
debug ip socket
To display all state change information for all sockets, use the debug ip socket command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip socket
no debug ip socket
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
Use this command to collect information on the socket interface. To get more complete information on a socket/TCP port pair, use this command in conjunction with the debug ip tcp transactions command.
Because the socket debugging information is state-change oriented, you will not see the debugging message on a per-packet basis. However, if the connections normally have very short lives (few packet exchanges during the life cycle of a connection), then socket debugging could become expensive because of the state changes involved during connection setup and teardown.
Examples
The following is sample output from the debug ip socket output from a server process:
Router# debug ip socket
Added socket 0x60B86228 to process 40
SOCKET: set TCP property TCP_PID, socket 0x60B86228, TCB 0x60B85E38
Accepted new socket fd 1, TCB 0x60B85E38
Added socket 0x60B86798 to process 40
SOCKET: set TCP property TCP_PID, socket 0x60B86798, TCB 0x60B877C0
SOCKET: set TCP property TCP_BIT_NOTIFY, socket 0x60B86798, TCB 0x60B877C0
SOCKET: created new socket to TCP, fd 2, TCB 0x60B877C0
SOCKET: bound socket fd 2 to TCB 0x60B877C0
SOCKET: set TCP property TCP_WINDOW_SIZE, socket 0x60B86798, TCB 0x60B877C0
SOCKET: listen on socket fd 2, TCB 0x60B877C0
SOCKET: closing socket 0x60B86228, TCB 0x60B85E38
SOCKET: socket event process: socket 0x60B86228, TCB new state --> FINWAIT1
socket state: SS_ISCONNECTED SS_CANTSENDMORE SS_ISDISCONNECTING
SOCKET: Removed socket 0x60B86228 from process 40 socket list
The following is sample output from the debug ip socket command from a client process:
Router# debug ip socket
Added socket 0x60B70220 to process 2
SOCKET: set TCP property TCP_PID, socket 0x60B70220, TCB 0x60B6CFDC
SOCKET: set TCP property TCP_BIT_NOTIFY, socket 0x60B70220, TCB 0x60B6CFDC
SOCKET: created new socket to TCP, fd 0, TCB 0x60B6CFDC
SOCKET: socket event process: socket 0x60B70220, TCB new state --> SYNSENT
socket state: SS_ISCONNECTING
SOCKET: socket event process: socket 0x60B70220, TCB new state --> ESTAB
socket state: SS_ISCONNECTING
SOCKET: closing socket 0x60B70220, TCB 0x60B6CFDC
SOCKET: socket event process: socket 0x60B70220, TCB new state --> FINWAIT1
socket state: SS_ISCONNECTED SS_CANTSENDMORE SS_ISDISCONNECTING
SOCKET: Removed socket 0x60B70220 from process 2 socket list
Table 178 describes the significant fields shown in the display.
Related Commands
Command Descriptiondebug ip tcp transactions
Displays information on significant TCP transactions such as state changes, retransmissions, and duplicate packets.
debug ip ssh
To display debugging messages for Secure Shell (SSH), use the debug ip ssh command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip ssh
no debug ip ssh
Syntax Description
This command has no arguments or keywords.
Defaults
Debugging for SSH is not enabled.
Command Modes
Privileged EXEC
Command History
Release Modification12.0(5)S
This command was introduced.
12.1(1)T
This command was integrated into Cisco IOS Release 12.1 T.
Usage Guidelines
Use the debug ip ssh command to ensure normal operation of the SSH server.
Examples
The following example shows the SSH debugging output:
Router# debug ip ssh
00:53:46: SSH0: starting SSH control process
00:53:46: SSH0: Exchanging versions - SSH-1.5-Cisco-1.25
00:53:46: SSH0: client version is - SSH-1.5-1.2.25
00:53:46: SSH0: SSH_SMSG_PUBLIC_KEY message sent
00:53:46: SSH0: SSH_CMSG_SESSION_KEY message received
00:53:47: SSH0: keys exchanged and encryption on
00:53:47: SSH0: authentication request for userid guest
00:53:47: SSH0: authentication successful for jcisco
00:53:47: SSH0: starting exec shell
debug ip tcp driver
To display information on TCP driver events; for example, connections opening or closing, or packets being dropped because of full queues, use the debug ip tcp driver command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip tcp driver
no debug ip tcp driver
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
The TCP driver is the process that the router software uses to send packet data over a TCP connection. Remote source-route bridging (RSRB), serial tunneling (STUN), and X.25 switching currently use the TCP driver.
Using the debug ip tcp driver command together with the debug ip tcp driver-pak command provides the most verbose debugging output concerning TCP driver activity.
Examples
The following is sample output from the debug ip tcp driver command:
Router# debug ip tcp driver
TCPDRV359CD8: Active open 172.21.80.26:0 --> 172.21.80.25:1996 OK, lport 36628
TCPDRV359CD8: enable tcp timeouts
TCPDRV359CD8: 172.21.80.26:36628 --> 172.21.80.25:1996 Abort
TCPDRV359CD8: 172.21.80.26:36628 --> 172.21.80.25:1996 DoClose tcp abort
Table 179 describes the significant fields shown in the display.
The following line indicates that the TCP driver user (RSRB, in this case) will allow TCP to drop the connection if excessive retransmissions occur:
TCPDRV359CD8: enable tcp timeouts
The following line indicates that the TCP driver user (in this case, RSRB) at IP address 172.21.80.26 (and using TCP port number 36628) is requesting that the connection to IP address 172.21.80.25 using TCP port number 1996 be aborted:
TCPDRV359CD8: 172.21.80.26:36628 --> 172.21.80.25:1996 Abort
The following line indicates that this connection was in fact closed because of an abnormal termination:
TCPDRV359CD8: 172.21.80.26:36628 --> 172.21.80.25:1996 DoClose tcp abort
debug ip tcp driver-pak
To display information on every operation that the TCP driver performs, use the debug ip tcp driver-pak command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip tcp driver-pak
no debug ip tcp driver-pak
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
This command turns on a verbose debugging by logging at least one debugging message for every packet sent or received on the TCP driver connection.
The TCP driver is the process that the router software uses to send packet data over a TCP connection. Remote source-rate bridging (RSRB), serial tunneling (STUN), and X.25 switching currently use the TCP driver.
To observe the context within which certain debug ip tcp driver-pak messages occur, turn on this command in conjunction with the debug ip tcp driver command.
Caution Because the debug ip tcp driver-pak command generates so many messages, use it only on lightly loaded systems. This command not only places a substantial load on the system processor, it also may change the symptoms of any unexpected behavior that occurs.
Examples
The following is sample output from the debug ip tcp driver-pak command:
Router# debug ip tcp driver-pak
TCPDRV359CD8: send 2E8CD8 (len 26) queued
TCPDRV359CD8: output pak 2E8CD8 (len 26) (26)
TCPDRV359CD8: readf 42 bytes (Thresh 16)
TCPDRV359CD8: readf 26 bytes (Thresh 16)
TCPDRV359CD8: readf 10 bytes (Thresh 10)
TCPDRV359CD8: send 327E40 (len 4502) queued
TCPDRV359CD8: output pak 327E40 (len 4502) (4502)
Table 180 describes the significant fields shown in the display.
The following line indicates that the TCP driver has sent the data that it had received from the TCP driver user, as shown in the previous line of output. The last field in the line (26) indicates that the 26 bytes of data were sent out as a single unit.
TCPDRV359CD8: output pak 2E8CD8 (len 26) (26)
The following line indicates that the TCP driver has received 42 bytes of data from the remote IP address. The TCP driver user (in this case, remote source-route bridging) has established an input threshold of 16 bytes for this connection. (The input threshold instructs the TCP driver to transfer data to the TCP driver user only when at least 16 bytes are present.)
TCPDRV359CD8: readf 42 bytes (Thresh 16)
debug ip tcp ecn
To turn on debugging of the TCP Explicit Congestion Notification (ECN) capability, use the debug ip tcp ecn command in privileged EXEC mode. To turn off the debugging, use the no form of this command.
debug ip tcp ecn
no debug ip tcp ecn
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Examples
The following example shows the messages that verify that the end hosts are connected and configured for ECN:
Router# debug ip tcp ecn
!
TCP ECN debugging is on
!
Router# telnet 10.1.25.31
Trying 10.1.25.31 ...
!
01:43:19: 10.1.25.35:11000 <---> 10.1.25.31:23 out ECN-setup SYN
01:43:21: 10.1.25.35:11000 <---> 10.1.25.31:23 congestion window changes
01:43:21: cwnd from 1460 to 1460, ssthresh from 65535 to 2920
01:43:21: 10.1.25.35:11000 <---> 10.1.25.31:23 in non-ECN-setup SYN-ACK
Before a TCP connection can use ECN, a host sends an ECN-setup SYN (synchronization) packet to a remote end that contains an ECE and CWR bit set in the header. This indicates to the remote end that the sending TCP is ECN-capable, rather than an indication of congestion. The remote end sends an ECN-setup SYN-ACK (acknowledgment) packet to the sending host.
In the example above, the "out ECN-setup SYN" text means that a SYN packet with the ECE and CWR bit set was sent to the remote end. The "in non-ECN-setup SYN-ACK" text means that the remote end did not favorably acknowledge the ECN request and that therefore the session is ECN capable.
The following debug output shows that ECN capabilities are enabled at both ends. In response to the ECN-setup SYN, the other end favorably replied with an ECN-setup SYN-ACK message. This connection is now ECN capable for the rest of the session.
Router# telnet 10.10.10.10
Trying 10.10.10.10 ... Open
Password required, but none set
!
1d20h: 10.1.25.34:11003 <---> 10.1.25.35:23 out ECN-setup SYN
1d20h: 10.1.25.34:11003 <---> 10.1.25.35:23 in ECN-setup SYN-ACK
Use the show tcp tcb command to display the end-host connections.
Related Commands
Command Descriptionip tcp ecn
Enables TCP ECN.
show tcp tcb
Displays the status of local and remote end hosts.
debug ip tcp intercept
To display TCP intercept statistics, use the debug ip tcp intercept command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip tcp intercept
no debug ip tcp intercept
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Examples
The following is sample output from the debug ip tcp intercept command:
Router# debug ip tcp intercept
A connection attempt arrives:
INTERCEPT: new connection (172.19.160.17:61774) => (10.1.1.30:23)
INTERCEPT: 172.19.160.17:61774 <- ACK+SYN (10.1.1.30:61774)
A second connection attempt arrives:
INTERCEPT: new connection (172.19.160.17:62030) => (10.1.1.30:23)
INTERCEPT: 172.19.160.17:62030 <- ACK+SYN (10.1.1.30:62030)
The router resends to both apparent clients:
INTERCEPT: retransmit 2 (172.19.160.17:61774) <- (10.1.1.30:23) SYNRCVD
INTERCEPT: retransmit 2 (172.19.160.17:62030) <- (10.1.1.30:23) SYNRCVD
A third connection attempt arrives:
INTERCEPT: new connection (171.69.232.23:1048) => (10.1.1.30:23)
INTERCEPT: 171.69.232.23:1048 <- ACK+SYN (10.1.1.30:1048)
The router sends more retransmissions trying to establish connections with the apparent clients:
INTERCEPT: retransmit 4 (172.19.160.17:61774) <- (10.1.1.30:23) SYNRCVD
INTERCEPT: retransmit 4 (172.19.160.17:62030) <- (10.1.1.30:23) SYNRCVD
INTERCEPT: retransmit 2 (171.69.232.23:1048) <- (10.1.1.30:23) SYNRCVD
The router establishes the connection with the third client and resends to the server:
INTERCEPT: 1st half of connection is established (171.69.232.23:1048) => (10.1.1.30:23)
INTERCEPT: (171.69.232.23:1048) SYN -> 10.1.1.30:23
INTERCEPT: retransmit 2 (171.69.232.23:1048) -> (10.1.1.30:23) SYNSENT
The server responds; the connection is established:
INTERCEPT: 2nd half of connection established (171.69.232.23:1048) => (10.1.1.30:23)
INTERCEPT: (171.69.232.23:1048) ACK -> 10.1.1.30:23
The router resends to the first two apparent clients, times out, and sends resets:
INTERCEPT: retransmit 8 (172.19.160.17:61774) <- (10.1.1.30:23) SYNRCVD
INTERCEPT: retransmit 8 (172.19.160.17:62030) <- (10.1.1.30:23) SYNRCVD
INTERCEPT: retransmit 16 (172.19.160.17:61774) <- (10.1.1.30:23) SYNRCVD
INTERCEPT: retransmit 16 (172.19.160.17:62030) <- (10.1.1.30:23) SYNRCVD
INTERCEPT: retransmitting too long (172.19.160.17:61774) => (10.1.1.30:23) SYNRCVD
INTERCEPT: 172.19.160.17:61774 <- RST (10.1.1.30:23)
INTERCEPT: retransmitting too long (172.19.160.17:62030) => (10.1.1.30:23) SYNRCVD
INTERCEPT: 172.19.160.17:62030 <- RST (10.1.1.30:23)
debug ip tcp transactions
To display information on significant TCP transactions such as state changes, retransmissions, and duplicate packets, use the debug ip tcp transactions command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip tcp transactions
no debug ip tcp transactions
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command is particularly useful for debugging a performance problem on a TCP/IP network that you have isolated above the data-link layer.
The debug ip tcp transactions command displays output for packets that the router sends and receives, but does not display output for packets that it forwards.
Examples
The following is sample output from the debug ip tcp transactions command:
Router# debug ip tcp transactions
TCP: sending SYN, seq 168108, ack 88655553
TCP0: Connection to 10.9.0.13:22530, advertising MSS 966
TCP0: state was LISTEN -> SYNRCVD [23 -> 10.9.0.13(22530)]
TCP0: state was SYNSENT -> SYNRCVD [23 -> 10.9.0.13(22530)]
TCP0: Connection to 10.9.0.13:22530, received MSS 956
TCP0: restart retransmission in 5996
TCP0: state was SYNRCVD -> ESTAB [23 -> 10.9.0.13(22530)]
TCP2: restart retransmission in 10689
TCP2: restart retransmission in 10641
TCP2: restart retransmission in 10633
TCP2: restart retransmission in 13384 -> 10.0.0.13(16151)]
TCP0: restart retransmission in 5996 [23 -> 10.0.0.13(16151)]
The following line from the debug ip tcp transactions command output shows that TCP has entered Fast Recovery mode:
fast re-transmit - sndcwnd - 512, snd_last - 33884268765
The following lines from the debug ip tcp transactions command output show that a duplicate acknowledgment is received when in Fast Recovery mode (first line) and a partial acknowledgment has been received (second line):
TCP0:ignoring second congestion in same window sndcwn - 512, snd_1st - 33884268765
TCP0:partial ACK received sndcwnd:338842495
Table 181 describes the significant fields shown in the display.
debug ip traffic-export events
To enable debugging messages for exported IP packet events, use the debug ip traffic-export events command in privileged EXEC mode. To disable debugging messages, use the no form of this command.
debug ip traffic-export events
no debug ip traffic-export events
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the debug ip traffic-export events command:
Router# debug ip traffic-export events
RITE:exported input packet # 547
RITE:exported input packet # 548
RITE:exported input packet # 549
RITE:exported input packet # 550
RITE:exported input packet # 551
RITE:exported input packet # 552
RITE:exported input packet # 553
RITE:exported input packet # 554
RITE:exported input packet # 555
RITE:exported input packet # 556
RITE:exported input packet # 557
RITE:exported input packet # 558
RITE:exported input packet # 559
RITE:exported input packet # 560
RITE:exported input packet # 561
RITE:exported input packet # 562
Related Commands
Command Descriptionip traffic-export profile
Creates or edits an IP traffic export profile and enables the profile on an ingress interface.
debug ip trigger-authentication
To display information related to automated double authentication, use the debug ip trigger-authentication command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip trigger-authentication [verbose]
no debug ip trigger-authentication [verbose]
Syntax Description
verbose
(Optional) Specifies that the complete debugging output be displayed, including information about packets that are blocked before authentication is complete.
Command Modes
Privileged EXEC
Usage Guidelines
Use this command when troubleshooting automated double authentication.
This command displays information about the remote host table. Whenever entries are added, updated, or removed, a new debugging message is displayed.
What is the remote host table? Whenever a remote user needs to be user-authenticated in the second stage of automated double authentication, the local device sends a User Datagram Protocol (UDP) packet to the host of the remote user. Whenever such a UDP packet is sent, the host IP address of the user is added to a table. If additional UDP packets are sent to the same remote host, a new table entry is not created; instead, the existing entry is updated with a new time stamp. This remote host table contains a cumulative list of host entries; entries are deleted after a timeout period or after you manually clear the table by using the clear ip trigger-authentication command.
If you include the verbose keyword, the debugging output also includes information about packet activity.
Examples
The following is sample output from the debug ip trigger-authentication command. In this example, the local device at 172.21.127.186 sends a UDP packet to the remote host at 172.21.127.114. The UDP packet is sent to request the remote user's username and password (or PIN). (The output says "New entry added.")
After a timeout period, the local device has not received a valid response from the remote host, so the local device sends another UDP packet. (The output says "Time stamp updated.")
Then the remote user is authenticated, and after a length of time (the timeout period) the entry is removed from the remote host table. (The output says "remove obsolete entry.")
myfirewall# debug ip trigger-authentication
TRIGGER_AUTH: UDP sent from 172.21.127.186 to 172.21.127.114, qdata=7C2504
New entry added, timestamp=2940514234
TRIGGER_AUTH: UDP sent from 172.21.127.186 to 172.21.127.114, qdata=7C2504
Time stamp updated, timestamp=2940514307
TRIGGER_AUTH: remove obsolete entry, remote host=172.21.127.114
The following is sample output from the debug ip trigger-authentication verbose command. In this example, messages about packet activity are included because of the use of the verbose keyword.
You can see many packets that are being blocked at the interface because the user has not yet been double authenticated. These packets will be permitted through the interface only after the user has been double authenticated. (You can see packets being blocked when the output says "packet enqueued" and then "packet ignored.")
TRIGGER_AUTH: packet enqueued, qdata=69FEEC
remote host=172.21.127.113, local host=172.21.127.186 (if: 0.0.0.0)
TRIGGER_AUTH: UDP sent from 172.21.127.186 to 172.21.127.113, qdata=69FEEC
Time stamp updated
TRIGGER_AUTH: packet enqueued, qdata=69FEEC
remote host=172.21.127.113, local host=172.21.127.186 (if: 0.0.0.0)
TRIGGER_AUTH: packet ignored, qdata=69FEEC
TRIGGER_AUTH: packet enqueued, qdata=69FEEC
remote host=172.21.127.113, local host=172.21.127.186 (if: 0.0.0.0)
TRIGGER_AUTH: packet ignored, qdata=69FEEC
TRIGGER_AUTH: packet enqueued, qdata=69FEEC
remote host=172.21.127.113, local host=172.21.127.186 (if: 0.0.0.0)
TRIGGER_AUTH: UDP sent from 172.21.127.186 to 172.21.127.113, qdata=69FEEC
Time stamp updated
TRIGGER_AUTH: packet enqueued, qdata=69FEEC
remote host=172.21.127.113, local host=172.21.127.186 (if: 0.0.0.0)
TRIGGER_AUTH: packet ignored, qdata=69FEEC
TRIGGER_AUTH: packet enqueued, qdata=69FEEC
remote host=172.21.127.113, local host=172.21.127.186 (if: 0.0.0.0)
TRIGGER_AUTH: packet ignored, qdata=69FEEC
debug ip urd
To display debugging messages for URL Rendezvous Directory (URD) channel subscription report processing, use the debug ip urd command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip urd [hostname | ip-address]
no debug ip urd
Syntax Description
Defaults
If no host name or IP address is specified, all URD reports are debugged.
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the debug ip urd command:
Router# debug ip urd
13:36:25 pdt:URD:Data intercepted from 171.71.225.103
13:36:25 pdt:URD:Enqueued string:
'/cgi-bin/error.pl?group=232.16.16.16&port=32620&source=171.69.214.1&li'
13:36:25 pdt:URD:Matched token:group
13:36:25 pdt:URD:Parsed value:232.16.16.16
13:36:25 pdt:URD:Creating IGMP source state for group 232.16.16.16
debug ip urlfilter
To enable debug information of URL filter subsystems, use the debug ip urlfilter command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip urlfilter {function-trace | detailed | events}
no debug ip urlfilter {function-trace | detailed | events}
Syntax Description
Defaults
This command is not enabled.
Command Modes
Privileged EXEC
Command History
Release Modification12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
Examples
The following is sample output from the debug ip urlfilter command:
Router# debug ip urlfilter
urlfilter:
Urlfilter Detailed Debugs debugging is on
Router# show ip urlfilter config
N2H2 URL Filtering is ENABLED
Primary N2H2 server configurations
=========================================
N2H2 server IP address:192.168.1.103
N2H2 server port:4005
N2H2 retransmission time out:6 (in seconds)
N2H2 number of retransmission:2
Secondary N2H2 servers configurations
============================================
Other configurations
=====================
Allow Mode:OFF
System Alert:ENABLED
Audit Trail:ENABLED
Log message on N2H2 server:DISABLED
Maximum number of cache entries:5
Maximum number of packet buffers:20
Maximum outstanding requests:1000
fw1_4#
1d15h:URLF:got a socket read event...
1d15h:URLF:socket recv failed.
1d15h:URLF:Closing the socket for server (192.168.1.103:4005)
1d15h:%URLF-3-SERVER_DOWN:Connection to the URL filter server 192.168.1.103 is down
1d15h:URLF:Opening a socket for server (192.168.1.103:4005)
1d15h:URLF:socket fd 0
1d15h:%URLF-5-SERVER_UP:Connection to an URL filter server(192.168.1.103) is made, the router is returning from ALLOW MODE
1d15h:URLF:got cache idle timer event...
1d16h:URLF:got cache absolute timer event...
1d16h:URLF:got cache idle timer event...
1d16h:URLF:creating uis 0x63A95DB4, pending request 1
1d16h:URLF:domain name not found in the exclusive list
1d16h:URLF:got an cbac queue event...
1d16h:URLF:socket send successful...172.17.192.130:8080) -> 192.168.1.103:1052 seq 3344720064 wnd 24820
1d16h:URLF:holding pak 0x634A8A08 (172.17.192.130:8080) -> 192.168.1.103:1052 seq 3344721524 wnd 24820
1d16h:URLF:holding pak 0x634A98CC (172.17.192.130:8080) -> 192.168.1.103:1052 seq 3344722984 wnd 24820
1d16h:URLF:got a socket read event...
1d16h:URLF:socket recv (header) successful.
1d16h:URLF:socket recv (data) successful.
1d16h:URLF:n2h2 lookup code = 1
1d16h:URLF:Site/URL Blocked:sis 0x63675DC4, uis 0x63A95DB4
1d16h:%URLF-4-URL_BLOCKED:Access denied URL 'http://www.google.com/', client 192.168.1.103:1052 server 172.17.192.130:8080
1d16h:URLF:(192.168.1.103:1052) RST -> 172.17.192.130:8080 seq 3361738063 wnd 0
1d16h:URLF:(172.17.192.130:8080) FIN -> 192.168.1.103:1052 seq 3344720064 wnd 0
1d16h:URLF:deleting uis 0x63A95DB4, pending requests 0
1d16h:URLF:got cache idle timer event...
1d16h:URLF:creating uis 0x63A95DB4, pending request 1
1d16h:URLF:domain name not found in the exclusive list
1d16h:URLF:got an cbac queue event...
1d16h:URLF:socket send successfull...
1d16h:URLF:holding pak 0x634A812C (172.17.192.130:8080) -> 192.168.1.103:1101 seq 3589711120 wnd 24820
1d16h:URLF:holding pak 0x634A2E7C (172.17.192.130:8080) -> 192.168.1.103:1101 seq 3589712580 wnd 24820
1d16h:URLF:holding pak 0x634A3464 (172.17.192.130:8080) -> 192.168.1.103:1101 seq 3589714040 wnd 24820
1d16h:URLF:got a socket read event...
1d16h:URLF:socket recv (header) successful.
1d16h:URLF:socket recv (data) successful.
1d16h:URLF:n2h2 lookup code = 0
1d16h:%URLF-6-URL_ALLOWED:Access allowed for URL 'http://www.alcohol.com/', client 192.168.1.103:1101 server 172.17.192.130:8080
1d16h:URLF:Site/URL allowed:sis 0x6367D0C4, uis 0x63A95DB4
1d16h:URLF:releasing pak 0x634A812C:(172.17.192.130:8080) -> 192.168.1.103:1101 seq 3589711120 wnd 24820
1d16h:URLF:releasing pak 0x634A2E7C:(172.17.192.130:8080) -> 192.168.1.103:1101 seq 3589712580 wnd 24820
1d16h:URLF:releasing pak 0x634A3464:(172.17.192.130:8080) -> 192.168.1.103:1101 seq 3589714040 wnd 24820
1d16h:URLF:deleting uis 0x63A95DB4, pending requests 0
1d16h:URLF:got cache idle timer event...
1d16h:URLF:creating uis 0x63A9777C, pending request 1
1d16h:URLF:domain name not found in the exclusive list
1d16h:URLF:got an cbac queue event...
1d16h:URLF:socket send successful...
1d16h:URLF:got a socket read event...
1d16h:URLF:socket recv (header) successful.
1d16h:URLF:socket recv (data) successful.
1d16h:URLF:n2h2 lookup code = 1
1d16h:URLF:Site/URL Blocked:sis 0x63677ED4, uis 0x63A9777C
1d16h:%URLF-4-URL_BLOCKED:Access denied URL 'http://www.google.com/', client 192.168.1.103:1123 server 172.17.192.130:8080
1d16h:URLF:(192.168.1.103:1123) RST -> 172.17.192.130:8080 seq 3536466275 wnd 0
1d16h:URLF:(172.17.192.130:8080) FIN -> 192.168.1.103:1123 seq 3618929551 wnd 0
1d16h:URLF:deleting uis 0x63A9777C, pending requests 0
1d16h:URLF:got cache idle timer event...
debug ip virtual-reassembly
To enable debugging of the virtual fragment reassembly (VFR) subsystem, use the debug ip virtual-reassembly command in privileged EXEC mode. To disable VFR debugging, use the no form of this command.
debug ip virtual-reassembly
no debug ip virtual-reassembly
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Examples
The following sample output from the debug ip virtual-reassembly command allows you to monitor datagram fragmentation and reassembly status—such as whether a datagram is incomplete and when fragments (from the datagram) are created (after a datagram is determined to be complete).
Router# debug ip virtual-reassembly
00:17:35: IP_VFR: fragment (sa:13.0.0.2, da:17.0.0.2, id:11745, offset:0, len:104) in fast path...
00:17:35: IP_VFR: created frag state for sa:13.0.0.2, da:17.0.0.2, id:11745...
00:17:35: IP_VFR: pak incomplete cpak-offset:0, cpak-len:104, flag: 1
00:17:35: IP_VFR: dgrm incomplete, returning...
00:17:35: IP_VFR: fragment (sa:13.0.0.2, da:17.0.0.2, id:11745, offset:104, len:104) in fast path...
00:17:35: IP_VFR: cpak-offset:0, cpak-len:104, npak-offset:104
00:17:35: IP_VFR: pak incomplete cpak-offset:104, cpak-len:104, flag: 1
00:17:35: IP_VFR: dgrm incomplete, returning...
00:17:35: IP_VFR: fragment (sa:13.0.0.2, da:17.0.0.2, id:11745, offset:208, len:104) in fast path...
00:17:35: IP_VFR: cpak-offset:0, cpak-len:104, npak-offset:104
00:17:35: IP_VFR: cpak-offset:104, cpak-len:104, npak-offset:208
00:17:35: IP_VFR: pak incomplete cpak-offset:208, cpak-len:104, flag: 1
00:17:35: IP_VFR: dgrm incomplete, returning...
00:17:35: IP_VFR: fragment (sa:13.0.0.2, da:17.0.0.2, id:11745, offset:312, len:104) in fast path...
00:17:35: IP_VFR: cpak-offset:0, cpak-len:104, npak-offset:104
00:17:35: IP_VFR: cpak-offset:104, cpak-len:104, npak-offset:208
00:17:35: IP_VFR: cpak-offset:208, cpak-len:104, npak-offset:312
00:17:35: IP_VFR: pak incomplete cpak-offset:312, cpak-len:104, flag: 1
00:17:35: IP_VFR: dgrm incomplete, returning...
00:17:35: IP_VFR: fragment (sa:13.0.0.2, da:17.0.0.2, id:11745, offset:416, len:92) in fast path...
00:17:35: IP_VFR: cpak-offset:0, cpak-len:104, npak-offset:104
00:17:35: IP_VFR: cpak-offset:104, cpak-len:104, npak-offset:208
00:17:35: IP_VFR: cpak-offset:208, cpak-len:104, npak-offset:312
00:17:35: IP_VFR: cpak-offset:312, cpak-len:104, npak-offset:416
00:17:35: IP_VFR: dgrm complete, switching the frags.
00:17:35: IP_VFR: switching fragment (sa:13.0.0.2, da:17.0.0.2, id:11745, offset:0, len:104)
00:17:35: IP_VFR: switching fragment (sa:13.0.0.2, da:17.0.0.2, id:11745, offset:104, len:104)
00:17:35: IP_VFR: switching fragment (sa:13.0.0.2, da:17.0.0.2, id:11745, offset:208, len:104)
00:17:35: IP_VFR: switching fragment (sa:13.0.0.2, da:17.0.0.2, id:11745, offset:312, len:104)
00:17:35: IP_VFR: switching fragment (sa:13.0.0.2, da:17.0.0.2, id:11745, offset:416, len:92)
00:17:35: IP_VFR: all fragments have been switched.
00:17:35: IP_VFR: pak_subblock_free - pak 0x64A3DC30
00:17:35: IP_VFR: pak_subblock_free - pak 0x6430F010
00:17:35: IP_VFR: pak_subblock_free - pak 0x6430F678
00:17:35: IP_VFR: pak_subblock_free - pak 0x643119B4
00:17:35: IP_VFR: deleted frag state for sa:13.0.0.2, da:17.0.0.2, id:11745
00:17:35: IP_VFR: pak_subblock_free - pak 0x64A3D5C8
Related Commands
debug ipc
To display debugging messages about interprocess communication (IPC) activity, use the debug ipc command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipc {all | ports | seats | sessions | zones}
no debug ipc {all | ports | seats | sessions | zones}
Syntax Description
Command Modes
Privileged EXEC
Command History
Release Modification12.2
This command was introduced.
12.3(11)T
The sessions and zones keywords were added.
Usage Guidelines
Use the debug ipc command to troubleshoot IPC issues discovered when the show ipc command is run. The debugging output varies depending on the types of IPC packets that are selected by the different keywords.
Caution Use the debug ipc all command with caution because it enables the debug ipc packets command and the volume of output can severely impact system performance. A confirmation message is displayed. We recommend that you use one of the other keywords to focus on a specific IPC activity and to limit the volume of output.
Examples
The following example shows the confirmation message that appears when the debug ipc all command is entered:
Router# debug ipc all
This may severely impact system performance. Continue? [confirm]
The following example shows how to enable the display of debugging messages about IPC sessions. The debugging output varies depending on the type of IPC activity that is specified. Each entry includes some text explanation—the example below shows that the IPC control session was opened to port 0x1030000, closed, and then cleared—followed by a series of header or data fields.
Router# debug ipc sessions
Session level events debugging is on
*Sep 14 13:13:35.435: IPC: Control Session opened to port 0x1030000
*Sep 14 13:13:35.439: -Traceback= 40779898 4077649C 40776A00 40777040 4077554C
*Sep 14 13:13:35.439: IPC: Session 0 to port 0x1030000 closed
*Sep 14 13:13:35.439: -Traceback= 4077A9D4 40776370 4077132C 40771A58 4062EC7C 4028EC8C 40649710 4057F87C
*Sep 14 13:13:35.439: IPC: Session handle of session 0 to port 0x1030000 cleared
*Sep 14 13:13:35.439: -Traceback= 407798EC 4077A9E0 40776370 4077132C 40771A58 4062EC7C 4028EC8C 40649710 4057F87C
Related Commands
Command Descriptiondebug ipc packets
Displays debugging messages about IPC packets.
show ipc
Displays IPC information.
debug ipc acks
To display debugging messages about interprocess communication (IPC) acknowledgments (ACKs), use the debug ipc acks command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipc acks [rx | tx] [dest destination-port-id] [source source-seat-id] [session session-id] [header dump]
no debug ipc acks [rx | tx] [dest destination-port-id] [source source-seat-id] [session session-id] [header dump]
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the debug ipc acks command to troubleshoot IPC ACK issues. To enable debugging for other IPC activities, use the debug ipc command.
Examples
The following example shows how to enable the display of packet headers only when debugging IPC ACK messages. The debugging output varies depending on the type of IPC activity that is specified. Each entry includes some text explanation—the example below shows that the server received an ACK HDR—followed by a series of header or data fields.
Router# debug ipc acks header dump
Aug 19 03:52:36.136:IPC:Server received ACK HDR:442A64E0 src:100000A, dst:406116E8, index:-1, seq:22045, sz:0, type:65535, flags:2 hi:1F371, lo:0
Related Commands
debug ipc errors
To display debugging messages about interprocess communication (IPC) errors and warnings, use the debug ipc errors command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipc errors [driver] [sequence] [timeout]
no debug ipc errors [driver] [sequence] [timeout]
Syntax Description
Command Modes
Privileged EXEC
Command History
Release Modification12.2
This command was introduced.
12.3(11)T
The driver, sequence, and timeout keywords were added.
Usage Guidelines
Use the debug ipc errors command to troubleshoot IPC error issues. To enable debugging for other IPC activities, use the debug ipc command. The debugging output varies depending on the type of IPC activity that is specified.
Examples
The following example shows how to enable the display of error debugging information about IPC messages that have timed out. The debugging output varies depending on the type of IPC activity that is specified. Each entry includes some text explanation—the example below shows that the message number 4428D3D0 timed out waiting for an acknowledgment (Ack)—followed by a series of header or data fields.
Router# debug ipc errors timeout
Message Timeouts debugging is on
*Sep 14 14:42:17.103: IPC: Message 4428D3D0 timed out waiting for Ack
*Sep 14 14:42:17.103: IPC: MSG: ptr: 0x4428D3D0, flags: 0x88, retries: 6, seq: 0x1030002, refcount: 2,
retry: 00:00:00, rpc_result = 0x0, data_buffer = 0x4442AB10, header = 0x4442AED4, data = 0x4442AEF4
HDR: src: 0x10000, dst: 0x103000A, index: 0, seq: 2, sz: 512, type: 0, flags: 0x400 hi: 0x1EC, lo: 0x4442AEF4
DATA: 00 00 00 05 00 00 00 00 00 00 00 3A 00 00 00 00 00 00 00 00
Related Commands
debug ipc events
To display debugging messages about interprocess communication (IPC) events, use the debug ipc events command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipc events [flushes] [retries]
no debug ipc events [flushes] [retries]
Syntax Description
flushes
(Optional) Displays only information related to IPC messages that are flushed.
retries
(Optional) Displays only information related to IPC messages that are re-sent.
Command Modes
Privileged EXEC
Command History
Release Modification12.2
This command was introduced.
12.3(11)T
The flushes and retries keywords were added.
Usage Guidelines
Use the debug ipc events command to troubleshoot IPC events issues. To enable debugging for other IPC activities, use the debug ipc command.
Examples
The following example shows how to enable the display of debugging messages about IPC events:
Router# debug ipc events
Special Events debugging is on
The following example shows how to enable the display of event debugging information about IPC messages that are re-sent. The debugging output varies depending on the type of IPC activity that is specified. Each entry includes some text explanation—the example below shows that there was a retry attempt for a specific message—followed by a series of header or data fields.
Router# debug ipc events retries
Message Retries debugging is on
*Sep 14 14:46:44.151: IPC: Retry attempt for MSG: ptr: 0x442AFE74, flags: 0x88, retries:4, seq: 0x1030003,
refcount: 2, retry: 00:00:00, rpc_result = 0x0, data_buffer = 0x445EBA44, header =0x445EBE08, data = 0x445EBE28
HDR: src: 0x10000, dst: 0x103000A, index: 0, seq: 3, sz: 512, type: 0, flags: 0x400 hi:0x201, lo: 0x445EBE28
DATA: 00 00 00 05 00 00 00 00 00 00 00 3A 00 00 00 00 00 00 03 D2
Related Commands
debug ipc fragments
To display debugging messages about interprocess communication (IPC) fragments, use the debug ipc fragments command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipc fragments [rx | tx] [dest destination-port-id] [source source-seat-id] [session session-id] [type application-type] [flags header-flag] [sequence sequence] [msgidhi msg-id-high] [msgidlo msg-id-low] [data offset offset-from-header value value-to-match dump bytes] [size size] [header dump]
no debug ipc fragments [rx | tx] [dest destination-port-id] [source source-seat-id] [session session-id] [type application-type] [flags header-flag] [sequence sequence] [msgidhi msg-id-high] [msgidlo msg-id-low] [data offset offset-from-header value value-to-match dump bytes] [size size] [header dump]
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the debug ipc fragments command to troubleshoot IPC fragment issues. To enable debugging for other IPC activities, use the debug ipc command.
Examples
The following example shows how to enable the display of debugging information about IPC fragments. The debugging output varies depending on the type of IPC activity that is specified. Each entry includes some text explanation—the example below shows that the server received a fragment message—followed by a series of header or data fields.
Router# debug ipc fragments
IPC Fragments debugging is on
01:43:55: IPC: Server received fragment MSG: ptr: 0x503A4348, flags: 0x100, retries: 0, seq: 0x0,
refcount: 1, retry: never, rpc_result = 0x0, data_buffer = 0x433809E8, header = 0x8626748, data = 0x8626768
HDR: src: 0x10000, dst: 0x2210015, index: 0, seq: 1, sz: 1468, type: 0, flags: 0x10 hi:0x9AA, lo: 0x7D0
DATA: 00 00 00 01 00 00 00 00 00 00 00 AA 00 00 00 00 00 00 17 E4
Related Commands
debug ipc nacks
To display debugging messages about interprocess communication (IPC) negative acknowledgments (NACKs), use the debug ipc nacks command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipc nacks [rx | tx] [dest destination-port-id] [source source-seat-id] [session session-id] [header dump]
no debug ipc nacks [rx | tx] [dest destination-port-id] [source source-seat-id] [session session-id] [header dump]
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the debug ipc nacks command to troubleshoot IPC NACK issues. To enable debugging for other IPC activities, use the debug ipc command.
Examples
The following example shows how to enable the display of packet headers only when debugging IPC NACK messages. The debugging output varies depending on the type of IPC activity that is specified. Each entry includes some text explanation—the example below shows that the server sent a NACK message and received a NACK header—followed by a series of header or data fields.
Router# debug ipc nacks header dump
IPC Nacks debugging is on
01:46:11: IPC: Server sent NACK MSG: ptr: 0x432A7428, flags: 0x100, retries: 0, seq: 0x0,
refcount: 1, retry: never, rpc_result = 0x0, data_buffer = 0x431E4B50, header = 0x855F508, data = 0x855F528
HDR: src: 0x2210015, dst: 0x10000, index: 1, seq: 3, sz: 0, type: 0, flags: 0x100 hi: 0x4A9, lo: 0x85AA3E8
01:46:11: SP: IPC: Server received NACK HDR: E46A448 src: 2210015, dst: 10000, index: 1, seq: 3, sz: 0, type: 0, flags: 100 hi: 4A9, lo: 85AA3E8
Related Commands
debug ipc packets
To display debugging messages about interprocess communication (IPC) packets, use the debug ipc packets command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipc packets [rx | tx] [dest destination-port-id] [source source-seat-id] [session session-id] [type application-type] [flags header-flag] [sequence sequence] [msgidhi msg-id-high] [msgidlo msg-id-low] [data offset offset-from-header value value-to-match dump bytes] [size size] [header dump]
no debug ipc packets [rx | tx] [dest destination-port-id] [source source-seat-id] [session session-id] [type application-type] [flags header-flag] [sequence sequence] [msgidhi msg-id-high] [msgidlo msg-id-low] [data offset offset-from-header value value-to-match dump bytes] [size size] [header dump]
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the debug ipc packets command to troubleshoot IPC packet issues. To enable debugging for other IPC activities, use the debug ipc command.
Caution Use the debug ipc packets command with caution because the volume of output can severely impact system performance. A confirmation message is displayed. We recommend that you use one of the optional keywords to focus on a specific IPC activity and to limit the volume of output.
Examples
The following example shows how to enable the display of IPC packet debugging messages and includes some sample output. The debugging output varies depending on the type of IPC activity that is specified. Each entry includes some text explanation—the example below shows that the IPC server received a message—followed by a series of header or data fields.
Router# debug ipc packets
This may severely impact system performance. Continue?[confirm] Y
Aug 19 030612.297 IPC Server received MSG ptr 0x441BE75C, flags 0x80, retries 0,
seq 0x0, refcount 1, retry never, rpc_result = 0x0, data_buffer = 0x443152A8,
header = 0x4431566C, data = 0x4431568C
HDR src 0x1060000, dst 0x1000C, index 2, seq 0, sz 28, type 770,
flags 0x40 hi 0x1F25B, lo 0x442F0BC0
DATA 00 00 00 06 00 00 00 02 00 00 00 06 00 E7 00 02 00 00 00 00
The following example shows how to enable the display of IPC messages received with a destination port of 0x1000C in session 1 with a message size of 500 rows.
Router# debug ipc packets rx dest 1000C session 1 size 500
Related Commands
debug ipc rpc
To display debugging messages about interprocess communication (IPC) remote-procedure call (RPC) packets, use the debug ipc rpc command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ipc rpc [rx | tx] [query | response] [dest destination-port-id] [source source-seat-id] [session session-id] [type application-type] [flags header-flag] [sequence sequence] [msgidhi msg-id-high] [msgidlo msg-id-low] [data offset offset-from-header value value-to-match dump bytes] [size size] [header dump]
no debug ipc rpc [rx | tx] [query | response] [dest destination-port-id] [source source-seat-id] [session session-id] [type application-type] [flags header-flag] [sequence sequence] [msgidhi msg-id-high] [msgidlo msg-id-low] [data offset offset-from-header value value-to-match dump bytes] [size size] [header dump]
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the debug ipc rpc command to troubleshoot IPC RPC packet issues. To enable debugging for other IPC activities, use the debug ipc command. The debugging output varies depending on the type of IPC activity that is specified.
Examples
The following example shows how to enable the display of packet headers only when debugging IPC RPC response messages. The debugging output varies depending on the type of IPC activity that is specified. Each entry includes some text explanation—the example below shows that the server received an RPC response—followed by a series of header or data fields.
Router# debug ipc rpc response header dump source 2210003
RPC debugging is on
01:53:43: SP: IPC: Server received RPC Reply HDR: E450048 src: 2210003, dst: 10000, index:0, seq: 1716, sz: 4, type: 2914, flags: 208 hi: A07, lo: E264DE8
Related Commands
debug iphc ipc
To display the IP header compression (IPHC) interprocessor communication (IPC) messages that are passed between the route processor (RP) and line cards (LCs), use the debug iphc ipc command in privileged EXEC mode. To disable the display of these messages, use the no form of this command.
debug iphc ipc [events | statistics]
no debug iphc ipc [events | statistics]
Syntax Description
events
(Optional) Displays IPHC IPC command and control events.
statistics
(Optional) Displays IPHC IPC counter updates.
Command Default
IPHC IPC messages are not displayed.
Command Modes
Privileged EXEC
Command History
Release Modification12.0(32)SY
This command was introduced.
12.4(10)
This command was integrated into Cisco IOS Release 12.4(10).
Usage Guidelines
If you issue the debug iphc ipc command without keywords, all the IPC messages that are passed between the RP and the LC are displayed. On routers with many interfaces and distributed systems, the number of IPC messages becomes unwieldy, because of all the counter updates. To display only the events that indicate interface state changes, issue the debug iphc ipc events command.
Examples
The following example enables the display of all IPHC IPC messages:
Router# debug iphc ipc
IPHC IPC statistics debugging is on
IPHC IPC event debugging is on
The following example disables IPHC IPC statistics debugging:
Router# no debug iphc ipc statistics
IPHC IPC statistics debugging is off
The following example enables the display of IPHC IPC event messages:
Router# debug iphc ipc events
IPHC IPC event debugging is on
The command output shows the event messages as the interface changes from enabled to administratively down:
%OSPF-5-ADJCHG: Process 1, Nbr 10.10.10.10 on Multilink8 from FULL to DOWN
%LINK-5-CHANGED: Interface Multilink8, changed state to administratively down.
IPHC IPC 2: Set Negotiated mesg (Mu PPP 128 2 0)
IPHC Mu8: Distributed FS disabled
IPHC IPC 2: Send Set Configured mesg (Mu PPP 128 2 0)
IPHC IPC Mu8: i/f state change complete (Up/Down: 0/1)
The following example enables the display of IPHC IPC counter updates:
Router# debug iphc ipc statistics
IPHC IPC statistics debugging is on
The command output shows the interface counter updates:
IPHC IPHC 2: recv Stats msg, count:4
IPHC IPC Mu8: stats update from LC
IPHC IPC Mu6: stats update from LC
IPHC IPC Se2/0/0/3:0: stats update from LC
IPHC IPC Se2/0/0/1:0: stats update from LC
Related Commands
Command Descriptionshow interfaces
Displays statistics for all interfaces.
show ipc
Displays IPC statistics.
Posted: Tue Jul 3 10:49:01 PDT 2007
All contents are Copyright © 1992--2007 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.