Interpreting NextPort Disconnect Reason Codes

Introduction

This document describes how to interpret the call disconnect reason codes reported by Cisco NextPort universal digital signal processor (DSP) modules. NextPort is the next generation DSP used by Cisco to implement either voice, data, or fax on a given port. AS5350, AS5400, AS5850 platforms and new models of modem cards for AS5800 all employ digital modems with NextPort DSPs. For digital modems in C3600, AS5200, AS5300 and older models of cards for AS5800, check Mica Modem States and Disconnect Reasons : no modem firmware upgrade can make NextPort DSP out of Mica DSP or vice versa.

Prerequisites

Requirements

This document has no specific requirements.

Background Information

Whenever a call using the NextPort DSPs is cleared or disconnected, the NextPort module records the reason for the disconnect. This disconnect reason code can be used to determine whether the disconnect was normal or an error occurred. This reason code can be used to track down possible sources of failure. Modems can be disconnected due to a variety of factors such as client disconnects, telco errors, and call drops at the network access server (NAS). A "good" disconnect reason is that the DTE (client modem or NAS) at one end or the other wanted to terminate the call. Such "normal" disconnects indicate that the disconnect was not a result of modem or transmission level errors. For more information on determining whether the disconnect reason is "normal", refer to Overview of General Modem and NAS Line Quality

Note: The disconnect reason is managed in a first-come-first-serve fashion. This means that the first disconnect reason generated is the only disconnect reason recorded. If the modem and the NAS attempt to terminate the session simultaneously and the modem happens to save the disconnect reason before the LINK_TERMINATE message from the NAS is processed, then the NAS disconnect reason is ignored.

Components Used

This document is not restricted to specific software and hardware versions.

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Determining the Disconnect Reason

When evaluating whether you are experiencing good or bad disconnects, it is important to obtain the history of disconnects that a particular port has experienced. In most environments, the disconnect reason is obtained using modem call records or call tracker syslog messages. This disconnect code can then be interpreted using the table provided in this document (or check the for modem analysis tools). Use the following commands to determine the disconnect reason:

• The show spe modem disconnect-reason command does not display the disconnect reason code as a hexadecimal value. However, it does indicate the disconnect reason as a name. The name and class of the disconnect reason can be found in and respectively.

• The show port modem log command displays the Disconnect Reason Code as a hexadecimal value. Refer to the :

0x0..		0x001	0x002	0x003	0x004	0x005	0x006	0x007	0x008	0x009	0x00C	0x00D	0x00E	0x00F
	0x010	0x011	0x012
0x1..	0x100	0x101	0x102	0x103	0x104	0x105	0x106	0x107	0x108	0x109
	0x1F00	0x1F01	0x1F02	0x1F03	0x1F04	0x1F05	0x1F06	0x1F07	0x1F08
														0x1FFF
0x2		0x201	0x202	0x203	0x204	0x205	0x206
	0x210	0x211	0x212
	0x220	0x221	0x222		0x224	0x225
0x3..	0x3xx
0x4..		0x401		0x403	0x404				0x408
0x5..		0x501	0x502	0x503	0x504	0x505	0x506
														0x5FF

The next section looks at some examples.

Using the show port modem log Command

Use the show port modem log slot/port command to obtain the disconnect cause code (in Hex) for a particular call on a specific port. This disconnect code is identical to the cause code obtained from modem call-record and call-tracker syslog outputs. An example is shown:

*Jan  1 00:53:56.867: Modem State event: State: Terminate
*Jan  1 00:53:56.879: Modem End Connect event: 
  Call Timer                              :   195  secs
  Disconnect Reason Info                  :   0x220
      Type (=0  ):  
     Class (=2  ):  EC condition - locally detected
    Reason (=32 ):  received DISC frame -- normal LAPM termination

From the example above, note that the disconnect code is 0x220.

Using the show spe modem disconnect-reason Command

Use the show spe modem disconnect-reason {summary | slot | slot/spe} command to determine the distribution of disconnect reasons that the particular port has experienced. A sample summary output of all the ports is shown below:

NAS>show spe modem disconnect-reason summary
===CLASS OTHER====  =====CLASS DSP====  ===CLASS EC LCL===  ==CLASS EC FRMR===
Software Rst     0  No Carrier     341  No LR            0  Frmr Bad Cmd     0
EC Termntd       0  No ABT dtctd     0  LR Param1        0  Frmr Data        0
Bad MNP5 Rx      0  Trainup flr    328  LR Incmpt        0  Frmr Length      0
Bad V42B       110  Retrain Lt       0  Retrns Lt      226  Frmr Bad NR      0
Bad COP stat     0  ABT end flr      0  Inactivity       0  
ATH              0                      Protocol Err     1  ===CLASS EC LD====
Aborted          0  ====CLASS HOST====  Fallbck Term    74  LD No LR         0
Connect Tout   198  Hst NonSpec      0  No XID          67  LD LR Param1     0
Reset DSP        0  HST Busy         0  XID Incmpt       0  LD LR Incmpt     0
                    HST No answr     0  Disc         21448  LD Retrns Lt     0
===CLASS EC Cmd===  HST DTR       3615  DM               5  LD Inactivty     0
Bad Cmd          0  HST ATH          0  Bad NR           0  LD Protocol      0
                    HST NoDialTn     0  SABME Online     0  LD User          0
=====N O N E======  HST No Carr   5276  XID Online       0  
None            39  HST Ack          0  LR Online        0  TOTAL        31728 
HST NoDialTn     0  SABME Online     0  LD User          0=====N O N E======
HST No Carr   5276  XID Online       0  None            39  HST Ack          0
LR Online        0  TOTAL        31728

From the example above, let us say that we are interested in the disconnect category "Disc" within CLASS EC LCL. To determine what the disconnect reason Disc means, go to the entry corresponding to the class (CLASS EC LCL ) and the disconnect reason name (Disc) which shows a hex code of 0x220 and is a normal disconnect.

• CLASS OTHER

• CLASS DSP

• CLASS EC LCL

• CLASS EC Cmd

• CLASS EC FRMR

• CLASS EC LD

• CLASS HOST

NextPort Disconnect Reason Code Summary Table

Disconnect Reason Type	Disconnect Reason: Name	Disconnect Reason Code (Hex)	Description
CLASS OTHER
2	Software Rst	0x001	Cisco IOS® software disconnected the call for some indeterminate reason (SOFTWARE_RESET).
2	EC Termntd	0x002	Error Correction (EC) layer termination
2	Bad MNP5 Rx	0x003	The Microcom Network Protocol 5 (MNP5) decompression task received an illegal token in the data stream. There is probably a logic error in the implementation of compression, decompression or error correction by the modem or partner. (There is also the possibility of a transient line or RAM memory error.)
2	Bad V42B	0x004	The V.42bis or V.44 decompression task received an illegal token in the data stream. There is probably a logic error in either the modem's or partner's implementation of compression, decompression or error correction. (There is also the possibility of a transient line or RAM memory error.)
2	Bad COP stat	0x005	<reserved>
6,7	ATH	0x006	ATH command detected by local modem. The "ATH" (Hangup) AT command is detected by the local modem (NextPort). For example, following a dialout from IOS, the IOS DTE interface clears the call (by transmitting an inband "ATH" AT command), after the call is connected.
3	Aborted	0x007	AT mode "any key" abort of dial command The AT dial command was aborted by the "any key" abort command. For example, the host modem originates a call. During connection establishment, pressing "any key" will cause the AT dial command to be aborted.
3	Connect Tout	0x008	The call took too long to complete the connection. Notice that the S7 timer (wait for carrier after dial) expired for this disconnect. The causes include: Difficulty choosing (negotiating) a Layer I standard, A combination of Layer I and Layer II establishment taking too long. For example: error correction negotiation takes an extended amount of time on top of a retrain or because of bit-errors introduced when the client modem tries to connect at an "aggressive" rate (for example, the client modem receiver tries to connect at a rate it can't sustain). This disconnect could also happen if the answer modem heard no tone from the channel (for example, the originator was not a modem).
2	Reset DSP	0x009	DSP was reset (command/internal/spontaneous). The DSP within the host modem was reset by the Control Processor (CP) or Signal Processor (SP). The CP resets the DSP if mail messages from the CP to SP are not being acknowledged. The SP resets itself if it gets an internal inconsistency error.
4,6		0x00C	V.42bis or V.44 codeword size exceeded negotiated maximum.
4,6		0x00D	V.42bis or V.44 received codeword equal to next empty dictionary entry.
4,6		0x00E	V.42bis or V.44 received codeword greater than the next empty dictionary entry.
4,6		0x00F	V.42bis or V.44 received reserved command code.
4,6		0x010	V.42bis or V.44 ordinal size exceeded eight.
4,6		0x011	V.42bis or V.44 negotiation error.
4,6		0x012	V.42bis or V.44 compression error.

CLASS DSP
		0x1xx	DSP conditions reported by SPE
4,5	No Carrier	0x100	The SPE carrier signal is lost. NextPort detected a client modem carrier drop. The NextPort DSP stopped hearing carrier for a period greater than the value specified in Register S10 (hang-up delay after carrier loss). This could mean that the talk path went away or that the client stopped transmitting. If a layer II protocol (V.42 and/or V.42bis) is in effect, it is abnormal to see such a disconnect. Common causes are users "aborting" the call before a connection takes place. Incidental dialing, aborted starts, and client applications timing out when calls take too long to connect (due to multiple retrains during Layer 1 negotiation.) The carrier lost condition can also occur during normal data mode when the client abruptly drops carrier. The common cause is a non-negotiated or "dirty" disconnect on the part of the client modem (for example, the client modem just drops the carrier signal). This can occur if the link is abruptly dropped (network error), or power is shut off to the client modem disconnecting the call. This can also occur with "cheaper" client modems that do not implement the Layer I and/or Layer II clear-down protocols on a DTR drop. For a large number of client modems, this is considered a normal disconnection.
3	No ABT dtctd	0x101	No answer-back tone detected -- caller is probably not a modem
3	Trainup flrv	0x102	Call failure while modem training up due to incompatible modulation or bad line. This may be indicative of attempts to negotiate an unsupported modulation such as a legacy Rockwell proprietary modulation (K56Plus, V.FC, and so on). Other possible causes are DSP failures to train-up due to severe line impairments, impulse noises, interrupting training, incompatible modulation parameters, and perhaps the inability to properly select a Layer I standard.
4,5	Retrain Lt	0x103	Too many consecutive retrains or speed-shifts. The retrain limit is specified with Register S40. During the progress of a call, too many retrains occurred which rendered the call ineffective since the data rate would be so poor as to be useless. Other possible conditions are the client modem does not complete the clear-down protocol (for example, the Telco tore down the call in the middle of the connection) and NextPort (NP) attempts to recover the call by issuing retrains. Once the retrain limit is reached, NP will drop the call and report this disconnect reason.
3	ABT end flr	0x104	Problem detecting end of Answer-Back Tone(ABT). Negotiation failure or excessive noise during V.34 training. Host modems answer and send out V.8bis and modulated 2100Hz answer back tones (ABTs) with phase reversals, but encounter excessive noise during the trainup sequence. Look for errors on the path from the calling modem to the answering modem in either one or both directions. Similar behavior occurs when there is latency in the Public Switched Telephone Network (PSTN) for dial up that exceeds one second and causes the modems to be unable to train up the echo cancellers. Other possible causes are: The actual TX power levels are incorrect and the tones are then not handled by the remote side. There is too much excessive noise in Phase III and IV during V.34 training. There is operator error. There is network interference during V.34 training (someone picks up the extension).
3		0x105	SS7/COT (Continuity Test) operation completed successfully.
3		0x106	SS7/COT (Continuity Test) operation failed: T8/T24 timeout waiting for "tone on".
3		0x107	SS7/COT (Continuity Test) operation failed: T8/T24 timeout waiting for "tone off".
4		0x108	Modem On Hold (MOH) cleardown by NextPort. V.92 specifies that the cleardown reason can be: Cleardown due to incoming call Cleardown due to outgoing call Cleardown due to other reason
4		0x109	MOH timeout value reached. This value can be adjusted using Register S62 (V.92 Maximum MOH time).

CLASS EC LCL: EC condition, locally detected
		0x2xx	Local Error Correction (EC)conditions.
3	No LR	0x201	During negotiation a Link Request (LR) frame was not received. Peer may not support MNP.
3	LR Param1	0x202	The Received MNP LR frame had bad/unexpected PARAM1. For more information on PARAM1 refer to the V.42 specification.
3	LR Incmpt	0x203	The received MNP LR frame is incompatible with the host modem's settings for EC.
4,5	Retrns Lt	0x204	Too many consecutive retransmissions in EC. This disconnect reason can be caused by noise on the line. For instance, the host modem transmits data to the client modem, but noise on the line causes the data to be received incorrectly (or not at all) by the client side. So excessive noise can lead to excessive retransmissions. The client modem could also have disconnected without the host modem realizing this. So the host modem continuously retransmits, without knowing that the client modem is no longer present. Sometimes, when the call connects in LAPM or MNP, NextPort is unable to transmit a frame to the client modem. The client modem fails to acknowledge NextPort's initial transmission, then fails to respond to Register S19 (Error Correction Retransmission Limit) polls (the default is 12), so NP disconnects the call. One cause could be that the carrier in the transmit path degraded substantially while the client failed to downshift. Another cause could be a problem with the client's EC engine (as would happen on a Winmodem system if Windows stops responding).
6,7	Inactivity	0x205	Inactivity timeout, MNP Link Disconnect (LD) sent. The host modem sends the client modem a LD frame indicating an inactivity timeout has occurred.
4,5	Protocol Err	0x206	EC protocol error. This is a general catch-all protocol error. It indicates that a LAPM or MNP EC protocol error has occurred.
3	Fallbck Term	0x210	No EC fallback protocol available. Error correction negotiation has not been successful. The call is terminated because there is no error correction fallback protocol available. S-register S25 (link protocol fallback ) determines the available fallback protocol. The options are asynchronous framing, synchronous framing, or disconnect (hangup).
3	No XID	0x211	Never received eXchange IDentification (XID) frame during negotiation. Peer may not support MNP.
3	XID Incmpt	0x212	The received XID frame is incompatible with local settings. The client modem may not support LAPM within V.42.
3,4,5	Disc	0x220	Received Disconnect (DISC) frame. This is the normal LAP-M disconnect. The call terminated normally with a proper clear down from the client side. (For example, a V.42 disconnect packet was sent from the client modem to the host modem). The client modem dropped DTR and cleanly negotiated a clear-down protocol.
3,4,5	DM	0x221	Received DM frame. Peer is possibly disconnecting. The client modem indicates that it is disconnecting. During call setup, this reason indicates that the client modem is giving up on negotiating error correction.
4,5	Bad NR	0x222	Bad receive sequence number or ACK number was received. An MNP LD or LAP-M FRMR is sent. The host modem received a LAPM or MNP error correction frame with a bad sequence number or acknowledgment number. An LD or Frame Reject (FRMR) frame is sent to the client modem indicating that the host modem is disconnecting.
4,5	SABME Online	0x224	Received MNP XID frame in steady-state. This is interpreted as a LAPM error correction protocol error in steady state. It means that the client modem may have reset due to receiving a FRMR.
4,5	XID Online	0x225	Received MNP LR frame while in steady-state. This is interpreted as an MNP error correction protocol error in steady state. It means that the client modem has reset.

CLASS EC Cmd: EC detected bad command code
4,5	Bad Cmd	0x3xx	EC detected bad command code. The received unknown command is in the last 2 digits. An MNP LD or LAP-M FRMR frame is sent in response.

CLASS EC FRMR: EC detected FRMR from peer
4,5		0x4xx	EC conditions indicated by client in LAP-M FRMR frame. The bit-mapped reason is in the last two digits.
4,5	Frmr Bad Cmd	0x401	LAPM: peer reports bad command. The host modem received a FRMR frame from the client modem. The received FRMR frame indicates that the client modem received an error correction frame from the host modem that contained a bad command.
4,5	Frmr Data	0x403	LAPM: peer reports that data field is not permitted or is incorrect length (U frames). The host modem received a FRMR frame from the client modem. The received FRMR frame indicates that the client modem received an error correction frame from the host modem that contained a data field that is not permitted or contained a data field with an incorrect length (that is, U frame).
4,5	Frmr Length	0x404	LAPM: peer reports data field length is greater than N401 (the maximum information field length specified in V.42), but has good Frame Check Sequence(FCS). The NextPort modem received a FRMR frame from the client modem. The received FRMR frame indicates that the client modem received an error correction frame from NextPort that contained a data field length that is greater than the maximum number of octets that can be carried in the information field (N401) of an I frame, an SREJ frame, an XID frame, a UI frame, or a TEST frame. The frame check sequence is good.
4,5	Frmr Bad NR	0x408	LAPM: peer reports bad receive sequence number or N(R). The host modem received a FRMR frame from the client modem. The received FRMR frame indicates that the client modem received an error correction frame from the host modem that contained a bad receive sequence number.

CLASS EC LD: Error Correction (EC) detected Link Disconnect (LD) from peer
4,5		0x5xx	EC conditions indicated by client in MNP LD frame. Reason field is in the last 2 digits
3	LD No LR	0x501	MNP: peer never received LR frame. The host modem received a LD frame from the client modem. The received LD frame indicates that the client modem never received a link request from the host modem.
3	LD LR Param1	0x502	MNP: peer reports Link Request (LR) frame has bad parameter #1 The host modem received a Link Disconnect (LD) frame from the client modem. The received LD frame indicates that the client modem received a link request frame from the host modem that contained a bad (i.e. unexpected) PARAM1. For more information on PARAM1 refer to the V.42 specification.
3	LD LR Incmpt	0x503	MNP: peer reports LR frame is incompatible with its configuration The host modem received a Link Disconnect (LD) frame from the client modem. The received LD frame indicates that the client modem received a link request (LR) frame from the host modem that is incompatible with the configuration of the client modem.
4,5	LD Retrns Lt	0x504	MNP: peer reports too many consecutive EC retransmissions The host modem received a LD frame from the client modem. The received LD frame indicates that the client modem received too many consecutive retransmissions.
4,5	LD Inactivty	0x505	MNP: peer reports inactivity timer expired The host modem received a Link Disconnect (LD) frame from the client modem. The received LD frame indicates that the client modem's host (DTE) hasn't passed data to the client modem within a period of time.
3	LD Protocol	0x506	MNP: peer reports error The host modem received a LD frame from the client modem. The received LD frame indicates that the client modem received a MNP protocol error.
3	LD User	0x507	Normal MNP disconnect The host modem received a LD frame from the client modem. The received LD frame indicates a normal MNP termination.

CLASS HOST: Requested by host
6,7		0x1Fxx	Host initiated disconnect. Value is a sum of 0x1F00 and SessionStopCommand value. This is the other host terminate reason. The host reason is indicated in the low order bytes "xx".
3,6,7	HST NonSpec	0x1F00	Non-specific host initiated disconnect. Value is a sum of 0x1F00 and SessionStopCommand value. This is the "catch all" IOS initiated disconnect reason. It is used for all non-standard disconnects. For example, this could be a result of modem management software deciding to terminate the call. One possible explanation is a higher-level authentication failure RADIUS, TACACS, or another application issuing a DTR drop to the host modem. This type of disconnect will not count towards CSR when the host modem is in data mode.
3	HST Busy	0x1F01	Dialed number was busy. Disconnection has occurred because the host is indicating that the dialed number is busy.
3	HST No answr	0x1F02	Dialed number did not answer. Disconnection has occurred because the host is indicating that the dialed number didn't answer.
3,6,7	HST DTR	0x1F03	"Virtual" DTR dropped. This status is "reflected" from the "I/O port redirector" which is currently using the modem. Disconnection has occurred because the host dropped the "virtual" DTR line. This generic disconnect cause is initiated by the Cisco IOS software. Example causes are idle timeout, PPP LCP TERMREQ received, authentication failure, Telnet hangup, and so on. To determine the reason for the hang up, examine the "Radius" disconnect reason from the modem call-record terse command or from Authentication, Authorization, and Accounting (AAA).
6,7	HST ATH	0x1F04	"ATH" (hangup) command was detected by local host.
3	HST NoDialTn	0x1F05	No access to telco network. Disconnection has occurred because the host couldn't access the network (such as ISDN).
3,4,5	HST NoCarr	0x1F06	Network indicated disconnect. This is a client side triggered disconnect that is not a graceful call termination. It can occur during call set-up. A common cause is when users of Windows 95 or Windows 98 Dial Up Networking (DUN) hit "cancel" before the call reaches steady state. Another common reason is any client instigated DTR drop before steady state. During data mode, this is also a client side triggered disconnection that is not a graceful call termination (that is, a "dirty" disconnect). One very common cause is authentication failures.
3		0x1F07	NAS terminated SS7/COT operation. Disconnection has occurred because the NAS has terminated the SS7/COT (Continuity Test) operation.
3		0x1F08	The SS7/COT operation was terminated by the router because of a T8/T24 timeout.
-		0x1FFF	Unsolicited TERMINATING. The host sends this disconnect reason when it receives a unsolicited terminating message.

Disconnect Reason Types

Disconnect Type	Description
0	(unused)
1 - 0x2...	(unused)
2 - 0x4...	Other situations
3 - 0x6...	Condition occurred during call setup
4 - 0x8...	In data mode. Rx (line to host) data flushing OK
5 - 0xA...	In data mode. Rx (line to host) data flushing not OK (at present, applications should not be concerned about the "not OK")
6 - 0xC...	In data mode. Tx (host to line) data flushing OK
7 - 0xE...	In data mode. Tx (host to line) data flushing not OK (at present, applications should not be concerned about the "not OK")

Related Information

• Comparing NextPort SPE Commands to MICA Modem Commands
• Overview of General Modem and NAS Line Quality
• Access Technology Support Page
• Technical Support - Cisco Systems