Troubleshooting Modems
Available Languages
Contents
Introduction
Modern analogue modem communications have become very complex. The latest technologies no longer rely on a simple basic layout, but expect the telephone company (Telco) cloud be built on digital technology end-to-end. This has led to a dramatic increase in bandwidth at the cost of increased complexity. Most modem call connectivity now depends on the components shown in the following diagram:
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Background Information
Local loops provide an error-free interface with the Telco cloud. A remote client may have either an analogue or a digital loop, and access servers are usually designed to operate over a digital loop. If one of the loops fails, further connectivity between the ends also fails.
The Telco cloud transmits the digital signals transparently, end to end. In case a link in the middle does not meet this requirement (such as, extra analogue to digital conversions, voice channel compressions, sporadic data losses, and so on), the modem connectivity is likely to be affected, even though neither end sees anything wrong with their loop.
In summary, low call success rate (CSR), poor connect speeds, frequent retrains, and so on, are not necessarily the symptoms of poor modem design. It may not be the modems that need to be checked first.
Troubleshoot
This section lists common problems erlated to modems, and provides information on how to fix them.
Clients That Place Both Modem and Digital Calls Report Connectivity Problems
Sometimes, clients that place both modem (V.92, V.90, V.34) and digital (ISDN, Switched 56, V.110 or V.120) calls report connectivity problems.
As discussed in the introduction, modem protocols are transmitted on top of digital technology. Because of their origins in more error-prone analogue communications, modem protocols are more robust and adaptive to line errors. The problem may not be very noticeable, but is still there. First, troubleshoot the digital calls:
-
Check controller and interface statistics to ensure that the line between the access server and the nearest Telco exchange is free of errors. For clients and access servers that use Cisco equipment, you can check the statistics at controller and interface levels. For third-party products, either follow the vendor documentation, or get a protocol analyzer. The statistics need to be checked at the Telco side as well (just in case the problem affects only the signals sent to the nearest Telco exchange);
-
If the counters are clean, but the line is not terminated directly in the Telco exchange (intermediate line extenders or exchanges are involved), check the whole path to the Telco exchange for errors;
-
After the line is confirmed clean, check the signaling. For Channel Associate Signals (CAS) troubleshooting techniques, see Troubleshooting ISDN Connections.
For more information, see Overview of General Modem and NAS line Quality.
Note: Perform all these checks before you attempt to troubleshoot your modem
Clients with Certain Accounts Cannot Connect
Clients with certain accounts, or those that call from certain locations, cannot connect. Some modem brands try to connect, with no satisfactory results, while clients in other locations do not seem to be affected.
These problems are not likely to be caused by modems themselves. Accounts (calling and called number ids, names and passwords) are handled by protocols or applications that reside on top of modem protocols (PPP, AAA, RPMS, and so on). It may not help to troubleshoot the modem if the protocols or applications need to be removed or changed.
To proceed further, try to troubleshoot:
-
Point to Point Protocol (PPP). See Dialup Technology: Troubleshooting Techniques.
-
Authentication, Authorization, and Accounting (AAA).
-
Resource Pool Manager Server (RPMS).
Unless special features are involved (such as, using the ID of the calling number or called number), the problem seems to be somewhere in the Telco cloud. If you relocate the same modem to a different location, only one factor changes: the call path. If the change is sufficient to resolve the problem, the endpoints are configured properly, and you may not need to troubleshoot further. The Telco line between the access server and the nearest Telco exchange is presumably okay, as only specific clients have the problem. A possible workaround is to find modem settings, which would allow the modems to connect, despite the Telco problems. For details, see Fine-Tuning Modems.
Note: This workaround is not a solution. To find a solution, contact your Telco in order to investigate the line between the client and the nearest Telco exchange, and further along the call path
Clients at Certain Locations Report Poor Connectivity
Occasionally, clients at certain locations report poor connectivity. This includes low connect speeds, often retrains, high error rates, and so on. Some modem brands try to connect with no satisfactory results, while other locations do not seem to be affected.
Unless special features are involved (such as, using the ID of the calling number or called number for RPMS), the problem seems to be somewhere in the Telco cloud. When you use the same modem in a different location, only one factor changes: the call path (within the Telco cloud, the paths for incoming and outgoing calls may differ). If the change is sufficient to resolve the problem, the endpoints are configured properly, and you may not need to troubleshoot further. The Telco line between the access server and the nearest Telco exchange is presumably okay, as only specific locations have the problem. The problem is most likely with the Telco exchange nearest to the client. Check if the calls in question arrive at the access server at all, as explained in Dialup Technology: Troubleshooting Techniques.
If the call makes it through, and the Telco line between the client and the nearest Telco exchange appears to be clean as well (for instance, if the client does not see the problem when it calls other local numbers, such as the San-Jose Dial-in Lab, or Australia Dial-in Lab), you may need to check the whole call path to troubleshoot further.
To check the call path:
-
First, check interior wiring as a possible source of trouble.
-
Connect two client modems back to back over the wiring (to make one modem place a call without waiting for dial tone use ATX3D, and to make the other modem reply without waiting for ring signal use ATA). After the modems train up and go into data mode, generate some traffic over the line, then use escape sequence (usually Hayes +++ or TIES +++AT) to switch the modems into command mode, and verify line parameters (Signal-to-Noise Ratio [SNR], signal quality, retrains, and so on).
-
Disconnect all equipment plugged into same phone line in parallel with the modem.
-
Run a phone cord (preferably quad or Unshielded Twisted Pair [UTP]) from the network interface straight to the modem.
-
-
Ensure that the client modem is running the latest firmware from its manufacturer (consistent with the protocols that the server modem supports). Also check whether you want to reconfigure the client modem so that it can connect more robustly. See Fine-Tuning Modems for more details. For example, you can try to cap the client modem's DCE speed. If it is a Rockwell client, try to use AT+MS=56,1,300,42000 in order to try a K56Flex connect at 42Kbps. Alternatively, try +MS=11,1,300,19200 for a V.34 connection at 19.2Kbps.
-
Enable modem logging on the client
for further analysis. -
If you use Microsoft Windows, check the disconnect code
. -
Check the connection diagnostics with a USR modem AT i11
or a Lucent modem AT i11 . -
If you use a Winmodem driven by the CPU, ask the modem vendor for the existing AT-command to troubleshoot a connection. Some modem vendors use the UnIModem diagnostics code from Microsoft (AT#UG).
Call path investigation may require closer involvement of your Telco. To identify the potential problems, check the connection parameters for the specific calls with the show modem operational-status command, as discussed in Overview of General Modem and NAS line Quality. For more information, see this Release Note. A possible workaround is to find modem settings, which would allow the modems to connect even despite the Telco problems. See Fine-Tuning Modems.
Clients at Certain Locations Connect, but Later, the Call Drops
Although clients at some locations are able to connect, the call drops after sometime. Some modem brands try to connect with no satisfactory results, while other locations do not seem to be affected.
Unless special features are involved (for example, calling or called number ID for RPMS), the problem seems to be somewhere in the Telco cloud. If you use the same modem in a different location, only one factor changes: the call path (also remember that within the Telco cloud, the paths for incoming and outgoing calls may differ). If the change is sufficient to get the problem resolved, the access server is likely to be configured properly, and may not require you to troubleshoot further. The Telco line between the access server and the nearest Telco exchange is presumably okay as well, since only specific locations hit the problem. To make sure the dial-up client is not the root of the problem, verify that:
-
The client does not initiate PPP disconnect. See Dialup Technology: Troubleshooting Techniques.
-
The client does not initiate modem disconnect. The reasons for modem disconnect in the modem log are explained in these documents:
-
The client does not initiate ISDN disconnect. See ISDN disconnect cause for more information. (See also Note 3.)
If the investigation reveals that the calls are disconnected due to mounting connectivity errors, try to find modem settings that would allow the modems to connect in spite of the Telco problems. For details, see Fine-Tuning Modems.
Note: This workaround is not a solution. To find a solution, contact your Telco in order to investigate the line between the client and the nearest Telco exchange, and further along the call path.
Some Models of Modems Cannot Connect, While Others at the Same Locations Can
At times, some models of modems are unable to connect, while other models at the same location are able to do so. This can sometimes be a question of vendor compatibility. To identify why exactly the disconnect occurs, check the modem log for disconnect reasons. (See also Note 1):
The possible workaround is to identify the settings that would enable modems avoid the compatibility issue. For details, see Fine-Tuning Modems. If no workaround helps (for example, disabling all the proprietary features), contact the client modem vendor for further troubleshooting.
Ensure that you remove PPP. The client modem should dial from a terminal program, such as Windows HyperTerminal, using AT-commands. Configure the access server so that it does not automatically start PPP for all users, but allows an exec login (for example, via async mode interactive on the group-async interface, and autoselect PPP on the lines). This is so that the client can directly control and glean useful information from the modem and, once connected, it can generate exec traffic to stress the connection.
On the client terminal, begin to log the session (select Transfer > Capture Text in HyperTerminal).
-
Gather the following information from the client modem:
-
ATI, ATI0, ATI1, ATI2.
-
AT&V0, AT&V1, AT&V2.
Note: Some commands may return ERROR on some modems. You can ignore such errors.
-
-
Reset the modem to factory defaults (or the otherwise desired settings), and ensure that the speaker is always on:
-
AT&F
-
ATL2M2
-
-
Begin to record the call to a .WAV file. To do so on Windows NT, select Start > Programs > Accessories > Multimedia > Sound Recorder.
The red button starts the recording, but do not hit it until you start to dial. In the HyperTerminal window, start to dial.
-
ATDT <number>
If the call does not connect, or if the required modulation is not negotiated, stop the recording after NO CARRIER appears in the terminal window. If the issue is that the call does connect as desired, but that after some time it is disconnected, then continue to record the .WAV file. You need to press the red record button again every minute if you use Sound Recorder.
If the call does connect, either in the desired modulation or an unwanted one, gather the following interesting information while connected.
-
on the server side, the show modem operational-status (MICA, NextPort) or modem at-mode / at@e1 (Microcom) information.
-
on the client side, escape to AT mode through +++, and get ATI6, AT&V1, AT&V2. You can go back online with ATO.
-
-
When the call is complete, save the Sound Recorder file. To do so, select File > Save As > Format Change.
Format: PCM
Attributes: 8.000 kHz, 8 Bit, Mono 7 kb/sec
File name: filename.wav
Send the information you collect to the Cisco Technical Assistance Center (TAC) for analysis.
Specific Models of Modems Have Poor Connectivity
Specific models face poor connectivity in terms of low connect speeds, often retrains, high error rates, and so on. Other models at the same locations have good connectivity.
This can sometimes be a question of vendor compatibility. To identify why exactly the disconnect happens, check the modem log for disconnect reasons. (See also Note 1):
The following investigation may also shed some light on why the certain client modems fail:
-
First, check interior wiring as a possible source of trouble.
-
Connect two client modems back to back over the wiring (to make one modem place a call without waiting for dial tone, use ATX3D, and to make the other modem reply without waiting for ring signal, use ATA). After the modems train up and go into data mode, generate some traffic over the line, then use escape sequence (usually Hayes +++ or TIES +++AT) to switch the modems into command mode, and verify line parameters (SNR, signal quality, retrains, and so on).
-
Disconnect all equipment plugged into same phone line in parallel with the modem.
-
Run a phone cord (preferably quad or UTP) from the network interface straight to the modem.
-
-
Ensure that the client modem is running the latest firmware from its manufacturer (consistent with the protocols that the server modem supports). Also reconfigure the client modem so that it can connect more robustly. See Fine-Tuning Modems for details. For example, you can try to cap the client modem's DCE speed. If it is a Rockwell client, try AT+MS=56,1,300,42000 in order to attempt a K56Flex connect at 42Kbps. Alternatively, try +MS=11,1,300,19200 for a V.34 connection at 19.2Kbps.
-
Enable modem logging on the client
for further analysis. -
If you use Microsoft Windows, check the disconnect code
. -
Check the connection diagnostics with a USR modem AT i11
or a Lucent modem AT i11 . -
If you use a Winmodem driven by the CPU, ask the modem vendor for the existing AT-command to troubleshoot a connection. Some modem vendors use the UnIModem diagnostics code from Microsoft (AT#UG).
A possible workaround is to find the settings, which would allow the modems avoid the compatibility issue. See Fine-Tuning Modems. If no workaround helps (for example, disabling retrains on the access server internal modems), contact the client modem vendor to troubleshoot further.
Specific Models of Modems Connect, but Later the Call Drops
Some models of modems are able to connect, but later the call drops. Other models at the same locations stay connected.
This can sometimes be a question of vendor compatibility. To identify why the disconnect happens, check the following (See also Note 1):
-
Whether PPP termination was requested. See Dialup Technology: Troubleshooting Techniques.
-
Whether modem termination was requested. Modem disconnect reasons in the modem log are explained at:
-
ISDN disconnect cause. (See also Note 3).
If the investigation reveals that the calls are disconnected due to mounting connectivity errors, a possible workaround is to get the latest modem firmware or settings, which allow the modems to avoid the compatibility issue. For details and a compatibility matrix see Fine-Tuning Modems. If the workaround does not help (such as limiting the maximum speed either manually or using aggressive modem capping), contact the client modem vendor to troubleshoot further.
Calls to Certain Numbers (DS1 or Access Server) Fail to Connect
Calls from various locations with various modem models to certain numbers (DS1 or access server) fail to connect. The same clients at the same locations connect okay to other local numbers (such as the San-Jose Dial-in Lab, or Australia Dial-in Lab).
Check the statistics at controller and interface levels for errors (see the introduction for more information). For example, if the access server terminates more than one Telco line, ensure that all the lines are synchronized (usually it means the lines must be taken from same provider), as explained in Clock Synchronization. The check needs to be done on both the access server and Telco sides (if the problem affects the signals that come from the access server to the nearest Telco exchange, the access server may not report any errors). Before you proceed with modem troubleshooting ensure that there are virtually no errors at the T1/E1 layer.
Next, make sure the calls do reach the access server, as explained in Dialup Technology: Troubleshooting Techniques. If the calls do arrive, check the show controller <e1|t1> call-counters command. For some Telco problems, certain DS0 channels typically report very low connect times and a very high number of calls.
For the last test, the Telco needs to allow the access server to be called itself through the Telco exchange. Also verify that there are no extraneous analog to digital conversions in the path between the access server and the switch. This produces a near-end echo, which digital modems may be unable to handle, and prevents PCM modem connections from working. When you provision a T1 or E1 link to the Telco, make sure that there is a purely digital path between the access server and the Telco switch. This is the case if there is a direct T1 or E1 link to the switch. If the channels are routed through a channel bank, for example, and thereby converted from digital to analog and back again, the digital integrity of the channels is lost. This means that:
-
Pulse code modulation (PCM) (V.90, K56Flex or X2) modem modulation cannot be used. Only V.34 and below can be used, and even V.34 performance may be impaired.
-
Digital services such as switched 56 or ISDN data cannot be provided.
-
Digital modems, such as MICA, will not work well, due to the high level of near-end echo.
Typical symptoms on MICA with a near-end A-D conversion are:
-
No PCM (K56Flex or V.90) carrier.
-
Mediocre (19.2 - 26.4) V.34 carrier for local calls.
-
Long distance calls cannot train up in V.34, V.32bis or V.32. However, if the client modem is capped at 2400bps V.22bis, it can train up fine.
Note: V.22bis does not require echo cancellation.
If the Telco cannot deliver a purely digital path to the access server, MICA (or other digital modems) are not recommended, and it is better to use analog V.34 modems, such as Sara (integrated analog Microcom modems in Cisco 2600 or 3600 routers).
To determine whether the path to the switch is suitable for digital modems, complete these steps:
-
Ensure that the DS1 line is provisioned to allow dialout.
-
Enable debug modem and debug modem csm or debug csm modem to identify which modem answers the call.
-
Establish a reverse telnet connection to a modem and place the call.
-
After the modems train up, generate some traffic (such as, terminal length 0 and show tech-support), then check show modem operational-status at both ends.
The most typical symptoms that indicate problems with the line to the nearest Telco exchange are:
-
Regular error correction (EC) retransmissions.
-
Continuous increase in the total retrains counter.
-
Signal quality (SQ) value less than three.
-
Signal to noise ratio (SNR) below 30 dB.
-
Receive level much below transmit level.
-
Non-zero frequency offset, phase jitter frequency, phase jitter level or phase roll.
-
Far end echo level less than -40 dB.
-
Gaps in the middle of the line shape or considerable rolloffs at the edge(s).
Near-end (also known as talker or local) echo is a portion of an originator's signal which is reflected back to the originator, from the local central office (CO), over the originator's local loop. Near-end echo is normally only seen by modems on analog lines as it is caused by impedance mismatch at the hybrid, which is the transformer that joins the two-wire analog local loop to the four-wire Telco transmission network.
Far-end echo is that portion of the transmitted analog signal which has bounced off of the remote modem's analog front end.
In the following diagram:
-
FEC - Far End Echo
-
NEC - Near End Echo
Modern modulations (V.32 and above) use echo cancellers to enable transmitted and received signals simultaneously to occupy the same frequency band. These have a digital signal processor (DSP) to keep track of the signal transmitted, and then subtract that signal from the signal received. Modern client (analog line side) modems contain both near-end and far-end echo cancellers. MICA modems contain only far-end, not near-end echo cancellers, because they do not expect to be connected to an analog local loop. With a digital local connection, there should be virtually no near-end echo.
Here are some examples of show modem operational-status output from a good T1 (digital to the switch) and a bad (A-D converted) T1. In addition to the difference in the far-end echo, also note the SNR difference (41 dB vs. 35 dB) that results in a perfect 33600 carrier compared to a mediocre 28800 carrier.
Good connection
isdn2-9>show modem operation 1/55
Modem(1/55) Operational-Status:
Parameter #0 Disconnect Reason Info: (0x0)
Type (=0 ): <unknown>
Class (=0 ): Other
Reason (=0 ): no disconnect has yet occurred
Parameter #1 Connect Protocol: LAP-M
Parameter #2 Compression: V.42bis both
Parameter #3 EC Retransmission Count: 0
Parameter #4 Self Test Error Count: 0
Parameter #5 Call Timer: 44 secs
Parameter #6 Total Retrains: 0
Parameter #7 Sq Value: 4
Parameter #8 Connected Standard: V.34+
Parameter #9 TX,RX Bit Rate: 33600, 33600
Parameter #11 TX,RX Symbol Rate: 3429, 3429
Parameter #13 TX,RX Carrier Frequency: 1959, 1959
Parameter #15 TX,RX Trellis Coding: 16, 16
Parameter #16 TX,RX Preemphasis Index: 0, 0
Parameter #17 TX,RX Constellation Shaping: Off, Off
Parameter #18 TX,RX Nonlinear Encoding: Off, Off
Parameter #19 TX,RX Precoding: Off, Off
Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm
Parameter #21 Signal Noise Ratio: 41 dB
Parameter #22 Receive Level: -12 dBm
Parameter #23 Frequency Offset: 0 Hz
Parameter #24 Phase Jitter Frequency: 0 Hz
Parameter #25 Phase Jitter Level: 0 degrees
Parameter #26 Far End Echo Level: -73 dBm
Parameter #27 Phase Roll: 22 degrees
Parameter #28 Round Trip Delay: 3 msecs
Parameter #30 Characters transmitted, received: 83, 3194
Parameter #32 Characters received BAD: 0
Parameter #33 PPP/SLIP packets transmitted, received: 0, 0
Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0
Parameter #36 EC packets transmitted, received OK: 81, 105
Parameter #38 EC packets (Received BAD/ABORTED): 0
Parameter #39 Robbed Bit Signalling (RBS) pattern: 0
Parameter #40 Digital Pad: None, Digital Pad Compensation: None
Line Shape:
.........*
........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
*
Bad T1 (CAS) - channel bank connection to the switch - far-end echo is -36dBm
term-server-1#show modem operation 1/38
Modem(1/38) Operational-Status:
Parameter #0 Disconnect Reason Info: (0x0)
Type (=0 ): <unknown>
Class (=0 ): Other
Reason (=0 ): no disconnect has yet occurred
Parameter #1 Connect Protocol: LAP-M
Parameter #2 Compression: V.42bis both
Parameter #3 EC Retransmission Count: 2
Parameter #4 Self Test Error Count: 0
Parameter #5 Call Timer: 96 secs
Parameter #6 Total Retrains: 1
Parameter #7 Sq Value: 3
Parameter #8 Connected Standard: V.34+
Parameter #9 TX,RX Bit Rate: 28800, 28800
Parameter #11 TX,RX Symbol Rate: 3429, 3429
Parameter #13 TX,RX Carrier Frequency: 1959, 1959
Parameter #15 TX,RX Trellis Coding: 16, 16
Parameter #16 TX,RX Preemphasis Index: 0, 6
Parameter #17 TX,RX Constellation Shaping: Off, Off
Parameter #18 TX,RX Nonlinear Encoding: Off, Off
Parameter #19 TX,RX Precoding: Off, Off
Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm
Parameter #21 Signal Noise Ratio: 35 dB
Parameter #22 Receive Level: -13 dBm
Parameter #23 Frequency Offset: 0 Hz
Parameter #24 Phase Jitter Frequency: 0 Hz
Parameter #25 Phase Jitter Level: 0 degrees
Parameter #26 Far End Echo Level: -36 dBm
Parameter #27 Phase Roll: 0 degrees
Parameter #28 Round Trip Delay: 6 msecs
Parameter #30 Characters transmitted, received: 8636, 116
Parameter #32 Characters received BAD: 0
Parameter #33 PPP/SLIP packets transmitted, received: 0, 0
Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0
Parameter #36 EC packets transmitted, received OK: 124, 63
Parameter #38 EC packets (Received BAD/ABORTED): 4
Parameter #39 Robbed Bit Signalling (RBS) pattern: 0
Parameter #40 Digital Pad: None, Digital Pad Compensation: None
Line Shape:
.........*
......*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.......*
........*
*
For details, see Overview of General Modem and NAS line Quality and this Release Note.
If the tests do not indicate any problems with the line, proceed with the Telco further along the call paths.
Calls to Certain Numbers (DS1 or Access Server) Have Poor Connectivity
Calls from various locations with various modem models to certain numbers (DS1 or access server) have poor connectivity in terms of low connect speeds, often retrains, high error rates, and so on. The same clients at the same locations have good connectivity when they call other local numbers (such as the San-Jose Dial-in Lab, or Australia Dial-in Lab).
Check the statistics at controller and interface levels for errors (see the introduction for more information). For example, if the access server terminates more than one Telco line, ensure that all the lines are synchronized (usually it means the lines must be taken from same provider), as explained in Clock Synchronization. The check needs to be done on both the access server and Telco sides (if the problem affects the signals that come from the access server to the nearest Telco exchange, the access server may not report any errors).
If you have verified that things are fine at the T1 or E1 layer, yet things do not behave acceptably well at the modem layer, here are some things to verify:
-
Collect representative statistics (see also note 1) on which side initiates disconnects, and what is the reason for it. For the access server side disconnect reasons are explained at:
Check whether Fine-Tuning Modems makes any impact on connect times or disconnect reasons.
-
Ensure that you use good modem code (refer to Fine-Tuning Modems)
-
Ensure that you tune the DS0 paths through the Telco for optimal performance. Note that suboptimalities can be found anywhere in the DS0 / 3.1KHz path:
-
Within the client modem's premises wiring (for example, extensions).
-
The client's local loop (long loop, load coils, bridge taps).
-
Within a switch configuration too much - or not enough - digital or analog padding
-
Problematic trunks within the Telco (old microwave links, old E&M four-wire analog trunks).
-
In order to factor out (most of) the local Telco network transmission network and local loops, it is a good idea to dial out from your own known good client (modem and loop to the nearest Telco switch) into the target access server. If you get a connection of the desired quality, this proves that the access server, its modems, and its DS1 line are healthy.
To determine whether the path to the switch is suitable for digital modems, complete these steps:
-
Ensure that the DS1 line is provisioned to allow dialout.
-
Enable debug modem and debug modem csm or debug csm modem to identify which modem answers the call.
-
Establish a reverse telnet connection to a modem and place the call.
-
After the modems train up, generate some traffic (such as, terminal length 0 and show tech-support), then check show modem operational-status at both ends.
The most typical symptoms that indicate problems with the line to the nearest Telco exchange are:
-
Regular error correction (EC) retransmissions.
-
Continuous increase in the total retrains counter.
-
Signal quality (SQ) value less than three.
-
Signal to noise ratio (SNR) below 30 dB.
-
Receive level much below transmit level.
-
Non-zero frequency offset, phase jitter frequency, phase jitter level or phase roll.
-
Far end echo level less than -40 dB.
-
Gaps in the middle of the line shape or considerable rolloffs at the edge(s).
Near-end (also known as talker or local) echo is a portion of an originator's signal which is reflected back to the originator, from the local CO, over the originator's local loop. Near-end echo is normally only seen by modems on analog lines as it is caused by impedance mismatch at the hybrid, which is the transformer that joins the two-wire analog local loop to the four-wire Telco transmission network.
Far-end echo is that portion of the transmitted analog signal which has bounced off of the remote modem's analog front end.
In the following diagram:
-
FEC - Far End Echo
-
NEC - Near End Echo
Modern modulations (V.32 and above) use echo cancellers to enable transmitted and received signals simultaneously to occupy the same frequency band. These have a DSP keep track of the signal transmitted, and then subtract that signal from the signal received. Modern client (analog line side) modems contain both near-end and far-end echo cancellers. MICA modems contain only far-end, not near-end echo cancellers, because they do not expect to be connected to an analog local loop. With a digital local connection, there should be (virtually) no near-end echo.
Here are examples of show modem operational-status from a good (digital to the switch) and a bad (A-D converted) T1. In addition to the difference in the far-end echo, also note the SNR difference (41 dB vs. 35 dB) that results in a perfect 33600 carrier compared to a mediocre 28800 carrier.
Good connection
isdn2-9>show modem operation 1/55
Modem(1/55) Operational-Status:
Parameter #0 Disconnect Reason Info: (0x0)
Type (=0 ): <unknown>
Class (=0 ): Other
Reason (=0 ): no disconnect has yet occurred
Parameter #1 Connect Protocol: LAP-M
Parameter #2 Compression: V.42bis both
Parameter #3 EC Retransmission Count: 0
Parameter #4 Self Test Error Count: 0
Parameter #5 Call Timer: 44 secs
Parameter #6 Total Retrains: 0
Parameter #7 Sq Value: 4
Parameter #8 Connected Standard: V.34+
Parameter #9 TX,RX Bit Rate: 33600, 33600
Parameter #11 TX,RX Symbol Rate: 3429, 3429
Parameter #13 TX,RX Carrier Frequency: 1959, 1959
Parameter #15 TX,RX Trellis Coding: 16, 16
Parameter #16 TX,RX Preemphasis Index: 0, 0
Parameter #17 TX,RX Constellation Shaping: Off, Off
Parameter #18 TX,RX Nonlinear Encoding: Off, Off
Parameter #19 TX,RX Precoding: Off, Off
Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm
Parameter #21 Signal Noise Ratio: 41 dB
Parameter #22 Receive Level: -12 dBm
Parameter #23 Frequency Offset: 0 Hz
Parameter #24 Phase Jitter Frequency: 0 Hz
Parameter #25 Phase Jitter Level: 0 degrees
Parameter #26 Far End Echo Level: -73 dBm
Parameter #27 Phase Roll: 22 degrees
Parameter #28 Round Trip Delay: 3 msecs
Parameter #30 Characters transmitted, received: 83, 3194
Parameter #32 Characters received BAD: 0
Parameter #33 PPP/SLIP packets transmitted, received: 0, 0
Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0
Parameter #36 EC packets transmitted, received OK: 81, 105
Parameter #38 EC packets (Received BAD/ABORTED): 0
Parameter #39 Robbed Bit Signalling (RBS) pattern: 0
Parameter #40 Digital Pad: None, Digital Pad Compensation: None
Line Shape:
.........*
........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
*
Bad T1 (CAS) - channel bank connection to the switch - far-end echo is -36dBm
term-server-1#show modem operation 1/38
Modem(1/38) Operational-Status:
Parameter #0 Disconnect Reason Info: (0x0)
Type (=0 ): <unknown>
Class (=0 ): Other
Reason (=0 ): no disconnect has yet occurred
Parameter #1 Connect Protocol: LAP-M
Parameter #2 Compression: V.42bis both
Parameter #3 EC Retransmission Count: 2
Parameter #4 Self Test Error Count: 0
Parameter #5 Call Timer: 96 secs
Parameter #6 Total Retrains: 1
Parameter #7 Sq Value: 3
Parameter #8 Connected Standard: V.34+
Parameter #9 TX,RX Bit Rate: 28800, 28800
Parameter #11 TX,RX Symbol Rate: 3429, 3429
Parameter #13 TX,RX Carrier Frequency: 1959, 1959
Parameter #15 TX,RX Trellis Coding: 16, 16
Parameter #16 TX,RX Preemphasis Index: 0, 6
Parameter #17 TX,RX Constellation Shaping: Off, Off
Parameter #18 TX,RX Nonlinear Encoding: Off, Off
Parameter #19 TX,RX Precoding: Off, Off
Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm
Parameter #21 Signal Noise Ratio: 35 dB
Parameter #22 Receive Level: -13 dBm
Parameter #23 Frequency Offset: 0 Hz
Parameter #24 Phase Jitter Frequency: 0 Hz
Parameter #25 Phase Jitter Level: 0 degrees
Parameter #26 Far End Echo Level: -36 dBm
Parameter #27 Phase Roll: 0 degrees
Parameter #28 Round Trip Delay: 6 msecs
Parameter #30 Characters transmitted, received: 8636, 116
Parameter #32 Characters received BAD: 0
Parameter #33 PPP/SLIP packets transmitted, received: 0, 0
Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0
Parameter #36 EC packets transmitted, received OK: 124, 63
Parameter #38 EC packets (Received BAD/ABORTED): 4
Parameter #39 Robbed Bit Signalling (RBS) pattern: 0
Parameter #40 Digital Pad: None, Digital Pad Compensation: None
Line Shape:
.........*
......*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.......*
........*
*
For details, see Overview of General Modem and NAS line Quality and this Release Note.
If loops to the nearest Telco switches (both from the client and the access server sides) appear to be clean, and the suboptimalities lie somewhere in the Telco path, here are some things you can do:
-
Make a non-EC call in V.22bis at 2400bps. If the circuit is healthy, there should be virtually no errors seen. If you let the connection sit idle and see recurrent errors (especially with code 0x7B, '{' in ASCII), it indicates the presence of (controlled) clock slips (for example, within the Telco's T-spans, rarely seen)
-
If the transmit or receive power levels seen on our clients are too high or too low, adjust the transmit levels, and add or remove line or trunk padding.
If you see healthy V.34 carrier, but receive weak or no pulse code modulation (PCM) connects (where the PCM code on the clients is known to be compatible with the server modems):
-
Verify that the circuit paths to the client modems can sustain a PCM connection. In other wirds, ensure that they do not have an extra analog to digital conversion.
-
Examine the digital padding in the path.
Proceed with Telco to investigate further along the call paths.
Calls to Certain Numbers (DS1 or Access Server) Connect, but Later the Call Drops
Calls from various locations with various modem models to certain number(s) (DS1 or access server) connect okay, but later the call drops. The same clients at the same locations have good connectivity when they call other local numbers (such as the San-Jose Dial-in Lab, or Australia Dial-in Lab).
First, check the statistics at controller and interface levels for errors (see the introduction for more information). For example, if the access server terminates more than one Telco line, ensure that all the lines are synchronized (usually it means the lines must be taken from same provider), as explained in Clock Synchronization. The check needs to be done on both the access server and Telco sides (if the problem affects the signals that come from the access server to the nearest Telco exchange, the access server may not report any errors).
Next, ensure that the calls do reach the access server, as explained in Dialup Technology: Troubleshooting Techniques. Then check the show controller <e1|t1> call-counters. For some Telco problems, certain DS0 channels typically report very low connect times and a very high number of calls. Collect representative statistics (also see Note 1) on which side initiates disconnects, and what the reason is:
-
Whether PPP termination was requested. See Dialup Technology: Troubleshooting Techniques.
-
Whether modem termination was requested. Modem disconnect reasons in the modem log are explained at:
-
ISDN disconnect cause. (See also Note 3).
If the calls disconnect due to mounting connectivity errors, see if Fine-Tuning Modems makes any impact on connect times and/or disconnect reasons.
-
Ensure that you use good modem code (refer to Fine-Tuning Modems)
-
Ensure that you tune the DS0 paths through the Telco for optimal performance. Note that suboptimalities can be found anywhere in the DS0 / 3.1KHz path:
-
Within the client modem's premises wiring (for example, extensions).
-
The client's local loop (long loop, load coils, bridge taps).
-
Within a switch configuration too much - or not enough - digital or analog padding
-
Problematic trunks within the Telco (old microwave links, old E&M four-wire analog trunks).
-
In order to factor out (most of) the local Telco network transmission network and local loops, it is a good idea to dial out from your own known good client (modem and loop to the nearest Telco switch) into the target access server. If you get a connection of the desired quality, this proves that the access server, its modems, and its DS1 line are healthy.
To determine whether the path to the switch is suitable for digital modems, complete these steps:
-
Ensure that the DS1 line is provisioned to allow dialout.
-
Enable debug modem and debug modem csm or debug csm modem to identify which modem answers the call.
-
Establish a reverse telnet connection to a modem and place the call.
-
After the modems train up, generate some traffic (for example, terminal length 0 and show tech-support), then check show modem operational-status at both ends.
The most typical symptoms that indicate problems with the line to the nearest Telco exchange are:
-
Regular error correction (EC) retransmissions.
-
Continuous increase in the total retrains counter.
-
Signal quality (SQ) value less than three.
-
Signal to noise ratio (SNR) below 30 dB.
-
Receive level much below transmit level.
-
Non-zero frequency offset, phase jitter frequency, phase jitter level or phase roll.
-
Far end echo level less than -40 dB.
-
Gaps in the middle of the line shape or considerable rolloffs at the edge(s).
Near-end (also known as talker or local) echo is a portion of an originator's signal which is reflected back to the originator, from the local CO, over the originator's local loop. Near-end echo is normally only seen by modems on analog lines as it is caused by impedance mismatch at the hybrid, which is the transformer that joins the two-wire analog local loop to the four-wire Telco transmission network.
Far-end echo is that portion of the transmitted analog signal which has bounced off of the remote modem's analog front end.
Far-end echo is that portion of the transmitted analog signal which has bounced off of the remote modem's analog front end.
In the following diagram:
-
FEC - Far End Echo
-
NEC - Near End Echo
Modern modulations (V.32 and above) use echo cancellers to enable transmitted and received signals simultaneously to occupy the same frequency band. These have a DSP keep track of the signal transmitted, and then subtract that signal from the signal received. Modern client (analog line side) modems contain both near-end and far-end echo cancellers. MICA modems contain only far-end, not near-end echo cancellers, because they do not expect to be connected to an analog local loop. With a digital local connection, there should be (virtually) no near-end echo.
Here are examples of show modem operational-status from a good (digital to the switch) and a bad (A-D converted) T1. In addition to the difference in the far-end echo, also note the SNR difference (41 dB vs. 35 dB) that results in a perfect 33600 carrier compared to a mediocre 28800 carrier.
Good connection
isdn2-9>show modem operational 1/55
Modem(1/55) Operational-Status:
Parameter #0 Disconnect Reason Info: (0x0)
Type (=0 ): <unknown>
Class (=0 ): Other
Reason (=0 ): no disconnect has yet occurred
Parameter #1 Connect Protocol: LAP-M
Parameter #2 Compression: V.42bis both
Parameter #3 EC Retransmission Count: 0
Parameter #4 Self Test Error Count: 0
Parameter #5 Call Timer: 44 secs
Parameter #6 Total Retrains: 0
Parameter #7 Sq Value: 4
Parameter #8 Connected Standard: V.34+
Parameter #9 TX,RX Bit Rate: 33600, 33600
Parameter #11 TX,RX Symbol Rate: 3429, 3429
Parameter #13 TX,RX Carrier Frequency: 1959, 1959
Parameter #15 TX,RX Trellis Coding: 16, 16
Parameter #16 TX,RX Preemphasis Index: 0, 0
Parameter #17 TX,RX Constellation Shaping: Off, Off
Parameter #18 TX,RX Nonlinear Encoding: Off, Off
Parameter #19 TX,RX Precoding: Off, Off
Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm
Parameter #21 Signal Noise Ratio: 41 dB
Parameter #22 Receive Level: -12 dBm
Parameter #23 Frequency Offset: 0 Hz
Parameter #24 Phase Jitter Frequency: 0 Hz
Parameter #25 Phase Jitter Level: 0 degrees
Parameter #26 Far End Echo Level: -73 dBm
Parameter #27 Phase Roll: 22 degrees
Parameter #28 Round Trip Delay: 3 msecs
Parameter #30 Characters transmitted, received: 83, 3194
Parameter #32 Characters received BAD: 0
Parameter #33 PPP/SLIP packets transmitted, received: 0, 0
Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0
Parameter #36 EC packets transmitted, received OK: 81, 105
Parameter #38 EC packets (Received BAD/ABORTED): 0
Parameter #39 Robbed Bit Signalling (RBS) pattern: 0
Parameter #40 Digital Pad: None, Digital Pad Compensation: None
Line Shape:
.........*
........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
*
Bad T1 (CAS) - channel bank connection to the switch - far-end echo is -36dBm
term-server-1#show modem operational 1/38
Modem(1/38) Operational-Status:
Parameter #0 Disconnect Reason Info: (0x0)
Type (=0 ): <unknown>
Class (=0 ): Other
Reason (=0 ): no disconnect has yet occurred
Parameter #1 Connect Protocol: LAP-M
Parameter #2 Compression: V.42bis both
Parameter #3 EC Retransmission Count: 2
Parameter #4 Self Test Error Count: 0
Parameter #5 Call Timer: 96 secs
Parameter #6 Total Retrains: 1
Parameter #7 Sq Value: 3
Parameter #8 Connected Standard: V.34+
Parameter #9 TX,RX Bit Rate: 28800, 28800
Parameter #11 TX,RX Symbol Rate: 3429, 3429
Parameter #13 TX,RX Carrier Frequency: 1959, 1959
Parameter #15 TX,RX Trellis Coding: 16, 16
Parameter #16 TX,RX Preemphasis Index: 0, 6
Parameter #17 TX,RX Constellation Shaping: Off, Off
Parameter #18 TX,RX Nonlinear Encoding: Off, Off
Parameter #19 TX,RX Precoding: Off, Off
Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm
Parameter #21 Signal Noise Ratio: 35 dB
Parameter #22 Receive Level: -13 dBm
Parameter #23 Frequency Offset: 0 Hz
Parameter #24 Phase Jitter Frequency: 0 Hz
Parameter #25 Phase Jitter Level: 0 degrees
Parameter #26 Far End Echo Level: -36 dBm
Parameter #27 Phase Roll: 0 degrees
Parameter #28 Round Trip Delay: 6 msecs
Parameter #30 Characters transmitted, received: 8636, 116
Parameter #32 Characters received BAD: 0
Parameter #33 PPP/SLIP packets transmitted, received: 0, 0
Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0
Parameter #36 EC packets transmitted, received OK: 124, 63
Parameter #38 EC packets (Received BAD/ABORTED): 4
Parameter #39 Robbed Bit Signalling (RBS) pattern: 0
Parameter #40 Digital Pad: None, Digital Pad Compensation: None
Line Shape:
.........*
......*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.......*
........*
*
For details, see Overview of General Modem and NAS line Quality and this Release Note.
If loops to the nearest Telco switches (both from the client and the access server sides) appear to be clean, and the suboptimalities lie somewhere in the Telco path, here are some things you can do:
-
Make a non-EC call in V.22bis at 2400bps. If the circuit is healthy, there should be virtually no errors seen. If you let the connection sit idle and see recurrent errors (especially with code 0x7B, '{' in ASCII), it indicates the presence of (controlled) clock slips (for example, within the Telco's T-spans, rarely seen)
-
If the transmit or receive power levels seen on our clients are too high or too low, adjust the transmit levels, and add or remove line or trunk padding.
If you see healthy V.34 carrier, but receive weak or no pulse code modulation (PCM) connects (where the PCM code on the clients is known to be compatible with the server modems):
-
Verify that the circuit paths to the client modems can sustain a PCM connection. In other wirds, ensure that they do not have an extra analog to digital conversion.
-
Examine the digital padding in the path.
Proceed with Telco to investigate further along the call paths.
Modems Do Not Pick Calls
To troubleshoot this problem, complete these steps:
-
Check whether the call arrives at the access server with Dialup Technology: Troubleshooting Techniques.
-
Check if the ISDN calls have the correct Bearer Capability, and ensure that DoV is not configured.
-
Check whether the modems are configured to pick voice calls.
-
Verify that the modemcap settings, as explained in Modem Management Operations (see also Note 2), are correct (for example, S0 register is not set to 0 or too high a value):
-
If RPM or RPMS is used, first check if the problem persists after the feature is disabled. If this helps, proceed with locally configured RPM and verify the modemcap settings.
-
Check if the B-channels are not busy, (show isdn active) and there are free modems (show modem). If the modems are marked bad, it can be either a hardware or a software problem.
-
Hardware failure typically resides with a certain carrier card or a certain modem card. Modems do not necessarily need to be marked as bad, but they fail on all calls since bootup. Hardware replacement is the solution.
-
In case of software failure, the modems typically work okay after each reboot, but later are marked as bad at random (may be in clusters of one, two, three, six or 12 within same modem card) or simply fail all further calls. If the problem is seen only during peak hours, check modem statistics show modem . A high No Answer rate spread evenly across all modems indicates that the access server simply cannot handle such a volume of calls. If a high rate of No Answer is specific to few modems only, it still is likely to indicate a software failure. Firmware reload is a workaround. The solution is to upgrade software and have modem autorecovery enabled (for Cisco 3600 routers, the network module [NM] may need replacement if the output of the show diag command indicates that the part number is not -02 version: 800-0553x-02). For further information, refer to MICA and Nextport modems.
-
Modems Pick Calls, but Fail to Train Up
Sometimes, modems pick up calls, but do not train up. To verify this, collect representative statistics (also see Note 1) on which side initiates disconnects, and what the reason is. For the access server side, disconnect reasons are explained at:
Also the CSR must be decreasing, and modems must stop somewhere in the middle of the modem state transitions.
First check whether the modem country is configured correctly. Check for errors on the controller or interface on both the access server and Telco sides (if the problem affects the signals coming from the access server to the nearest Telco exchange, the access server may not report any errors). If RPM or RPMS is used, check if the problem persists after the feature is disabled. Then try with locally configured RPM and verify that the modemcap settings, as explained in Modem Management Operations (also see Note 2), are correct:
Check modem statistics using show modem (MICA) or show spe (NextPort) command. If clusters of one, two, three, six or 12 modems within same modem card have unusually high number of failed calls or are marked as bad, it can be either a hardware or a software problem.
-
For hardware failure it is typical to stay with a certain carrier card or a certain modem card. Modems do not necessarily need to be marked as bad, but they fail all calls since the bootup. Hardware replacement is the solution.
-
For software failure it is typical that the modems work okay right after each reboot, but later are marked bad at random (may be in clusters of one, two, three, six or 12 within the same modem card) or simply fail all further calls. Firmware reload is a workaround. The solution is to upgrade software and have modem autorecovery enabled (for Cisco 3600 routers, the NM may need replacement, if the output of show diag shows that the part number is not -02 version: 800-0553x-02). For further information, refer to MICA and Nextport modems.
If the problem is not found specific to the architecture of the access server, see whether Fine-Tuning Modems makes any impact on connect times and disconnect reasons.
Modems Train Up, but Connectivity is Poor
These problems can be equally attributed to Telco, client modem(s) or the access server. If no previous statistics for the location is available, ITU-T V.56 series recommendations may serve a first approximation of which connect rates in which proportions you can expect. Check for errors on the controller and interface. The check needs to be made on both the access server and Telco sides (if the problem affects the signals coming from the access server to the nearest Telco exchange, the access server may not report any errors). It may also be required to proceed with Telco further along the path.
If RPM or RPMS is used, first check if the problem persists after the feature is disabled. If this helps, investigate locally configured RPM and modemcap, as explained below.
Verify that the modemcap settings as explained in Modem Management Operations (also see Note 2), are correct:
Try Fine-Tuning Modems and see if it brings improvements with any type of the modems. Check connection parameters for the specific calls with show modem operational-status, as discussed in Overview of General Modem and NAS line Quality and this Release Note to identify the potential problems.
Modems Do Train Up, but PPP Does Not Start
To verify this, check the disconnect reason in the modem logs. Check that the CSR does not decrease, and the modems pass through all the state transitions successfully. In the configuration check:
-
Whether PPP on the access server is configured in interactive or dedicated mode. If PPP is set to be selected interactively, and the client does not send PPP autoselection sequence, as specified in RFC 1662, PPP connectivity from the point of view of the access server is impossible. Investigate the client side or Telco.
-
Whether modem lines and modem interface (usually group-async) are configured correctly (for sample configurations, see the introduction to this section or Dialup Technology: Troubleshooting Techniques).
-
Whether any modems are left orphaned outside group-async interface group range. None should be left orphaned.
Modems Train Up, and PPP Starts, but the Call Later Drops
Check whether the clients, the Telco or the access server initiates the disconnects.
-
First verify whether the PPP link was terminated correctly (this disconnect can be initiated by the client or the access server) with Dialup Technology: Troubleshooting Techniques.
-
If the PPP was not terminated correctly, the Telco may be the reason. Decode the disconnect reasons in the modem log. (See also Note 1).
-
If the modems also report an unexpected disconnect, the Telco may be at fault. It is best to compare the disconnect reasons from both ends of the connection. Refer to ISDN disconnect cause. (See also Note 3).
-
If the access server dropped the connection, check that interesting traffic is correctly defined on the corresponding dialer interface. The debug dialer events command should report if the access server disconnected calls on time-out.
If the drops are initiated by clients, troubleshooting the access server is unlikely to help. Try the recommendations from the client modem troubleshooting section and proceed with investigating the client side first. Even if the abrupt drops happen just to every client tested, this fact alone is not sufficient to identify what exactly makes them all disconnect from the access server. If the investigation results require further assistance from Cisco, documented your findings and open a case with the Cisco TAC.
No Specific Problems Found, but CSR is Low
To identify whether the CSR is high or low, you need reference figures typical to the area. The objective is to achieve a CSR of 95 percent. However, in an ISP environment, with a wide variety of client modems and a huge range of local loop conditions, it is a hard target to achieve. Since CSR is a complex issue, it is difficult to quote expected call success rates. This is due to the various conditions that affect a modem call. For example:
-
What switch types are in use?
-
Does the site use tandem COs?
-
Have the lines been qualified (BERT tests, and so on) to ensure they are clean?
-
What is the quality and integrity of the copper cable plant?
-
Does the call topology include analog hops?
-
Are channel banks or SLIC cards being used in the network?
-
Are the lines ISDN PRI or channelised E1s?
-
What is the distribution of client modems?
Note: These are just a few of the factors.
The statistics must be representative. There must be at least ten calls per modem in order to make any preliminary conclusions, but it is generally recommended to wait until there have been a few thousand calls (also see Note 1). Each modem connection is unique. Two calls from the same modem to same destination number may take two completely different paths through the PSTN network and may well end up on different physical host modems. The local loop, the copper connection from the customers premises to the local exchange, can suffer from environmental conditions that are unique to that customer, although most local loop providers try to ensure that the local loop characteristic fall within an acceptable range. Client modems utilize different chipsets that vary from manufacturer to manufacturer and often within product lines of the same manufacturer.
Here are the parameters you should monitor:
-
CSR: show modem summary
-
Connect speeds: show modem connect-speeds, show modem log (MICA) or show port modem log (NextPort)
-
Signal to noise ratio (SNR): show modem operational-status (MICA, NextPort), AT@E1 (Microcom), show modem log (MICA) or show port modem log (NextPort)
-
Transmit and receive levels: show modem operational-status (MICA, NextPort), AT@E1 (Microcom)
-
Modem modulations and protocols: show modem log (MICA) or show port modem log (NextPort)
-
Modem disconnect reasons: show modem call-stats
-
Retrains and EC block retransmits: show modem log (MICA) or show port modem log (NextPort), show modem operational-status (MICA, NextPort)
For more details, see Overview of General Modem and NAS line Quality and this Release Note.
It is acceptable for the CSR reported by Cisco access servers to be a few percent less than the CSR reported by third-party access servers because of differences in how they consider the call to be successful. In Cisco access servers, the call is marked as successful only after it succeeds both the initial train up and EC negotiation phase (unless EC is negotiated, user data cannot be passed over the link). Third-party access servers tend to consider the call as successful immediately after the initial train up has passed (that is, no EC failures are taken into account).
The low CSR problem can be equally attributed to the Telco, the clients or the access server. Try to improve the CSR by Fine-Tuning Modems. To troubleshoot modems and the Telco, see the client modem troubleshooting section. These symptoms are typical for problems with access server:
-
show modem reports clusters of one, two, three, six or 12 modems within same modem card having unusually high number of failed or No Answer calls.
-
show modemcall-stats reports clusters of one, two, three, six or 12 modems within same card having more than ten percent of their disconnects attributed to columns than dtrDrop or hostDrop and rmtLink (lostCarr may also count a good disconnect, if the client modems do not terminate LAP-M before disconnecting);
-
clusters of one, two, three, six or 12 modems within same modem card are marked as bad but, after firmware reload, can take calls again.
If the symptoms match, upgrade software and configure modem autorecovery. For further information, refer to MICA and Nextport modems.
Notes
Note 1
To automate modem statistics analysis, use the tools 
available as part of Cisco-centric Open Source Initiative (COSI) .
Note 2
To automate modemcap analysis, use the tools available as part of Cisco-centric Open Source Initiative (COSI) .
Note 3
ISDN signaling analysis can be automated by using the tools available as part of Cisco-centric Open Source Initiative (COSI) .
Related Information
Revision History
| Revision | Publish Date | Comments |
|---|---|---|
1.0 |
03-Sep-2006 |
Initial Release |
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)