Overview of General Modem and NAS Line Quality

Introduction

This document discusses ways to verify the performance of the digital modems at the network access server (NAS) as well as the T1/E1 line connected to the NAS. It will not discuss the performance or configuration of the client side modems. For more information on this subject, refer to Configuring Client Modems to Work with Cisco Access Servers.

Before You Begin

Conventions

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

Prerequisites

Readers of this document should be knowledgeable of the following:

General modem and line operational quality is closely tied to many factors such as:

• The ability of the modem to interoperate with the vast and evershifting range of peer modems (of various quality) encountered in the field.

• The quality of the circuit (end-to-end connection) between the client modem and the NAS.

• The quality of the modems on both the client side as well as on the NAS.

• The number of analog to digital (A/D) conversions in the circuit.

Before proceeding on the overview of general modem and NAS line quality, you should verify the basic factors shown below:

• The NAS receives modem calls.

  If any of the modems in the NAS has problems receiving calls, you should call into the NAS from a handset and verify that the modem on the NAS responds with the answer back tone. You should call out from the NAS to make sure that the dialout is able to ring a phone. If you have a problem with call signaling use the debug isdn q931 command to verify that the telco switch is sending the NAS all the setup information. If further troubleshooting is required, refer to these URLs:

  • T1 Troubleshooting

  • Dialup Technology: Troubleshooting Techniques

  • E1 R2 Signaling Configuration and Troubleshooting

  • E1 Troubleshooting

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.

Network Diagram

Note: Telco converts the analog signal from the client's modem to digital. There is no need to convert the digital signal back to analog because we are using a T1 line from the Public Switched Telephone Network (PSTN) to the NAS. Therefore, in this circuit, there is only one A/D conversion. This topology is required for V.90 56 kbps connections because in order to transmit at V.90 speeds a NAS modem needs full digital access to the PSTN. Such a connection is only available through the T1/E1 of the NAS.

Verifying the Digital Path Between the NAS and the Switch

To verify the quality of the T1/E1 lines coming into the NAS, follow the steps outlined below. Use the various show commands and concepts to ensure that the T1/E1 lines on the NAS are functioning properly.

The commands available on the NAS to gain an overall view of T1/E1 quality into the NAS are shown and explained below:

• show controllers t1 - This command is used to verify the T1 line for error free operation.

• show controllers t1 call-counter - This command is used to verify the DS0s are functioning properly.

• show modem operational-status slot/port - This command is being used to verify that there are no extraneous A/D conversions in the path between the NAS and the local telco switch.

Note: Evaluating the T1/E1 solely at the NAS may not give an accurate picture of the T1/E1 quality. If possible, the T1 service provider should run tests to verify that they are receiving frames from the NAS. If you experience erratic T1/E1 behavior, a Bit Error Rate Test (BERT) may also be run at the telco.

Verifying Overall Quality of the T1/E1

If you have the output of a show controllers {t1|e1} command from your Cisco device, you can use to display potential issues and fixes. In order to use , you must be a registered customer, be logged in, and have JavaScript enabled.

There should be virtually no errors at the T1/E1 layer. Check the T1/E1 counters on the NAS using the show controllers t1 or show controllers e1 command.

Note: The commands shown here are T1 commands. If you use E1s simply replace t1 with e1 in the command itself.

The following output displays a healthy T1 line. Notice there are no alarms, violations, or errored seconds.

maui-nas-01#show controllers t1
T1 0 is up.
  Applique type is Channelized T1
  Cablelength is long gain36 0db
  No alarms detected.
  Version info of slot 0:  HW: 4, Firmware: 16, PLD Rev: 0

Manufacture Cookie Info:
 EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x42,
 Board Hardware Version 1.32, Item Number 800-2540-2,
 Board Revision A0, Serial Number 15264684,
 PLD/ISP Version 0.0, Manufacture Date 29-Sep-1999.

  Framing is ESF, Line Code is B8ZS, Clock Source is Line Primary.
  Data in current interval (844 seconds elapsed):
     0 Line Code Violations, 0 Path Code Violations
     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
  Total Data (last 58 15 minute intervals):
     0 Line Code Violations, 0 Path Code Violations
     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,
     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

If you find that the T1 line has alarms or is encountering errors, use the T1 troubleshooting flowchart to isolate and correct it. It is always a good idea to perform a Loopback Tests for T1/56K Lines, as well as referring to the Hard Plug Loopback Test for E1 Lines Flowchart, to verify that your errors are not caused by the router or other hardware issues.

The Output Interpreter tool allows you to receive an analysis of the show controllers {t1|e1} command output.

If the tool finds any abnormalities with the show controller t1 command output, it will generate a troubleshooting procedure based on the symptom indicated. You can use that procedure in conjunction with the T1 troubleshooting flowchart and E1 troubleshooting flowchart to help you resolve your issue.

Evaluating DS0s Using the show controllers t1 call-counters Command

Verify the quality of each of the DS0s on the T1/E1 with the show controllers t1 call-counter command. In the output look for any DS0s with abnormally high "TotalCalls" and abnormally low "TotalDuration". Part of a sample output from a show controllers t1 call-counter command with a bad DS0 is shown below:

TimeSlot   Type   TotalCalls   TotalDuration
    1       pri         873       1w6d
    2       pri         753       2w2d
    3       pri        4444      00:05:22

Notice that timeslot 3 has received a large number of calls in a short period. This is indicative of a bad DS0 and you should contact your provider on this issue.

Note: You can use the isdn service dsl command in order to busy out a suspected bad DS0.

Performing a Loopback Call on the T1 Line

Verify that there are no extraneous analog-to-digital conversions in the path between the NAS and the local telco switch. Unwanted A/D conversions produce near-end echo, which digital modems such as MICA may be unable to handle and will prevent the pulse code modulation (PCM) modem connections from working.

PCM modem connections such as V.90 require that there only be one A/D conversion in the entire signal path. Since the PSTN switch near the client performs an A/D conversion, any other A/D conversions on the line will cause loss of performance. Often, unwanted conversions from digital-to-analog (D/A) are produced at channel banks.

You should verify that there are no channel-banks on the line between the NAS and the switch. You can test whether you have any unwanted A/D conversions by checking the near-end echo after dialing out from the NAS and back in again. Use the following procedure to determine whether the path to the switch is suitable for digital modems:

1. Ensure that the T1/E1 line is provisioned to allow outgoing calls from the NAS on the T1.

2. Reverse Telnet into a MICA modem and, using the AT Commands, dial the number of the T1 you are testing as shown below:

   as5200-1#telnet 172.16.186.50 2007
      Trying 172.16.186.50, 2007 ... Open 
      User Access Verification
      Username: cisco
      Password:
      Password OK
      at
      OK
      atdt 5554100
      CONNECT 33600/REL - MNP
      User Access Verification
      Username: cisco
      Password:
      as5200-1>
   

3. The call will proceed to the switch, loop back to the NAS, and then connect to one of the other modems.

4. After you connect to one of the digital modems, use the show modem operational-status slot/port command from another Telnet session, where the slot/port is the particular modem in use, and check the value of "Parameter #26 Far End Echo Level:".

If the level is less than -55dBm, then the line should be okay; if greater, then you probably have an extraneous analog-to-digital conversion in the path to the switch. Remember that with negative numbers, -75dBm is less than -55dBm, while -35dBm is greater than -55dBm. If you determine that you have unwanted A/D conversions, contact your service provider to correct them.

Gathering Modem Performance Information

This section discusses the modem performance on the NAS. For more details on gathering information from the client modems, refer to the Configuring Client Modems to Work with Cisco Access Servers document. If possible, gather various logs from the client PCs such as modemlog.txt and ppplog.txt. These logs can be used with the Disconnect Reasons section of this document to determine if there are any unwanted disconnects.

Note: The commands discussed below are for MICA modems. If your NAS has NextPort Software Port Entity (SPEs) instead of MICA modems, refer to the document Comparing NextPort SPE Commands to MICA Modem Commands to obtain the equivalent NextPort command for each MICA command.

To verify the quality of modems on the NAS, use the various show commands and concepts below to ensure that the modems on the NAS are functioning properly. The commands used to gain an overall view of modem behavior on the NAS are shown and explained below:

• Call Tracker - This can be used to capture detailed data on the progress and status of calls, from the time the network access server receives a setup request or allocates a channel, until a call is rejected, terminated, or otherwise disconnected. Please refer to the document Understanding Call Tracker Outputs for more information.

• show modem summary - This command is used to verify the connection success percentage of all incoming calls. Provides an overview of all the modem's performance.

• show modem - This command is used to verify the quality and state of an individual modem.

• show modem connect-speeds - This command is used to verify reasonably high modem connect speeds.

• show modem call-stats - This command is used to determine the type of disconnects seen.

• show modem operational-status - This command displays performance statistics for individual modems.

Determining Overall Modem Success with the show modem summary Command

To verify the connect success percentage of all incoming calls on all modems, use the show modem summary command as shown below:

router#show modem summary
         Incoming calls       Outgoing calls      Busied   Failed   No    Succ 
Usage  Succ   Fail  Avail   Succ   Fail  Avail    Out      Dial     Ans   Pct. 
   0%  4901    171     24      0      0     24        1        0    27     96%

Note: The show modem summary command is significant only with a large sample of incoming calls. For further information on the output of the various fields, refer to the table below.

Note: The show modem summary command is significant only with a large sample of incoming calls. For further information on the output of the various fields, refer to the table below.

Obtaining Per-Modem Statistics Using the show modem Command

To verify the quality and state of an individual modem, use the show modem command.

router#show modem 
Codes:
* - Modem has an active call
C - Call in setup
T - Back-to-Back test in progress
R - Modem is being Reset
p - Download request is pending and modem cannot be used for taking calls  
D - Download in progress
B - Modem is marked bad and cannot be used for taking calls
b - Modem is either busied out or shut-down
d - DSP software download is required for achieving K56flex connections
! - Upgrade request is pending
 
                 Inc calls     Out calls     Busied   Failed    No      Succ 
  Mdm  Usage    Succ   Fail   Succ   Fail      Out     Dial    Answer   Pct. 
* 1/0    17%      74      3      0      0       0        0       0       96% 
* 1/1    15%      80      4      0      0       0        1       1       95% 
* 1/2    15%      82      0      0      0       0        0       0      100% 
  1/3    21%      62      1      0      0       0        0       0       98% 
  1/4    21%      49      5      0      0       0        0       0       90% 
* 1/5    18%      65      3      0      0       0        0       0       95%  
  ...

Information to note from the commands above can be found in the table below:

Category	Description
Succ Pct	For incoming calls to the NAS, "Succ Pct" represents the percentage that resulted in the carrier being negotiated. For most dialin applications, you want this to be at least 90 percent
Fail	This indicates the NAS modem went offhook, but the modems end to end failed to train up. Remember that a single problematic client modem, redialing over and over again, can result in a misleadingly high number of "Fail". Hence, be aware of the actual mix of client modems being used. Having an excessive percentage of "Fail" on incoming calls is often indicative of either signaling problems during call setup or poor channel quality. If you see a large number of Fails in the show modem summary output, use the show modem command to determine if the failures are limited to a single modem or a cluster of possible "bad" modems.
Succ	This command indicates that modems trained up and the Cisco IOS® Software Release saw Data Set Ready (DSR) go high. However this does not mean that upper layer protocols, such as Point-to-Point Protocol (PPP) negotiated successfully.
No Ans	This indicates that the Call Switch Module (CSM) routed a call to a modem, but the modem failed to answer. For most dialin applications, you want this to be less that one percent of the total number of calls. A high number of "No Ans" could be either due to a modem misconfiguration or the router CPU being busy. Use the show proccesses cpu command to verify that the 5 minute CPU utilization is not over 90%. Other common causes of "No Ans" include signaling problems between the NAS and the switch, modem bugs, and channel associated signaling (CAS) issues caused by R2 misconfiguration. For more information on this subject, refer to E1 R2 Signaling Theory.

Gathering Modem Data Rates with the show modem connect-speeds Command

The most visible indicator of modem connection quality (in fact the only one typically available to a Windows dial-up networking client) is the initial modem connect speed. However, it is important here to stress that the initial connect speed is misleading for the reasons shown below:

• The speed used by a modern modem connection may vary throughout the duration of the connection. This is due to constant retrains and speedshifts performed by the modems for adjustment to line conditions.

• For a given circuit quality, at some point a higher carrier rate may yield lower effective throughput than a lower carrier rate due to increased block errors, retrains, and retransmissions. For example, (on a given circuit) a rate of 28800 bps can provide better throughput than a link with a nominal rate of 42000 BPS Hence, a Transmission Control Protocol (TCP) file transfer would provide an accurate representation of the true carrier rate.

However, the initial modem connect speed information is useful for trend analyses. To see the initial connect speeds on the NAS, execute the commands shown below:

• show modem connect-speeds 56000

• show modem connect-speeds 46667

• show modem connect-speeds 38000

• show modem connect-speeds 33600

• show modem connect-speeds 14400

For V.34 connections, a typical healthy distribution of initial connect speed is shown below. The example shown below was a NAS configured with a Channelized T1 and attached Microcom 3.3.20 NAS modems:

Note: The output below is shortened due to space limitations.

asfm07#show modem connect-speeds 33600 
  transmit connect speeds 
  Mdm    16800  19200  21600  24000  26400  28800  31200  32000  33600 TotCnt 
  2/0       18     23    28      24     36     44     55     12     66    353
  ...  ...
  2/47      8      17     15     25     33     43     37      2      5    145  
  Tot       17    109     60    226    932   2482   1884     44    216   7666 
  Tot %      0      1      0      2     12     32     24      0      2 
    receive connect speeds 
  Mdm    16800  19200  21600  24000  26400  28800  31200  32000  33600 TotCnt 
  ... 
  ...   Tot       18    116     88    614   2608   2844    904      0      1   7667 
  Tot %      0      1      1      8     34     37     11      0      0 

Healthy V.34 connections will be in the 21600 to 33600 BPS range at 2400 BPS increments. However, you should also obtain a peak in the 26400-31200 BPS range.

as2#show modem connect-speeds 56000
  transmit connect speeds
 
  Mdm   48000  49333  50000  50667  52000  53333  54000  54667  56000 TotCnt
  ...  Tot     1888   6412    939   5557    994    977      0    261      1  53115
  Tot %      3     12      1     10      1      1      0      0      0
  ...
as2#show modem connect 46667
  transmit connect speeds
 
  Mdm   38667  40000  41333  42000  42667  44000  45333  46000  46667 TotCnt
  ...  Tot      577    675    446     46    550   1846   3531    186   1967  53121
  Tot %      1      1      0      0      1      3      6      0      3
  ...

For PCM speeds (for example K56Flex, or V.90) it is harder to characterize a typical distribution of speeds, because PCM connections are so heavily dependent on the specific details of the telephony path between client and server. Look for a peak in the connect speed distribution from 44-50 kbps. However, remember that the presence of impairments such as extraneous Analog-to-Digital (A/D) converters, bridge taps, and load coils may prevent PCM connections or produce distorted data.

Determining General Disconnect Causes with the show modem call-stats Command

At the system level, use the show modem call-stats command to determine that "good" disconnects indicted by "rmtLink" and "hostDrop" are occurring rather than "bad" ones. Here is some typical healthy output from MICA modems depicting the disconnect cause for dialin calls:

router#show modem call-stats
       compress  retrain lostCarr userHgup  rmtLink  trainup hostDrop wdogTimr 
  Mdm     #   %    #   %    #   %    #   %    #   %    #   %    #   %    #   % 
 Total  103      554      806      130     8654      206     9498        0 

The "rmtLink" is a remote client-requested disconnect and "hostDrop" is a data terminal ready (DTR) drop at the NAS. These are good disconnects as far as the modems are concerned.

The other reasons indicated by the show modem call-stats command are "bad" and should be less than 10% of total disconnects/calls. The total disconnects/calls here would be the sum of all totals in the "Total" row.

Use debug modem to obtain further information on the disconnect cause. However, if the drop was initiated by the PSTN network, it will show as DTR drop (since with digital modems, the data terminal equipment (DTE) handles the PSTN interface).

Good Modem Disconnect Reasons

Modems can be disconnected due to a variety of factors such as client disconnects, telco errors, and call drops at the NAS. A "good" disconnect reason is that the DTE (client modem or NAS) at one end or the other wanted to shut it down. For example, the NAS may have reached an idle timeout period and instructed the modem to disconnect the call or the clients may have clicked on the "Disconnect" button because they were done with their session. Such disconnects are "normal" and indicate that the disconnect was not a result of modem or transmission level errors. DTR drops are not due to modem issues, they are considered "good" reasons for a disconnect. However, if you believe that the number of DTR drops are high, look at other factors such as the NAS configuration.

It is undesirable to have the modem connection end without one of the DTEs initiating the disconnect. A modem will report the reasons why the connection ended. MICA has dozens of discrete disconnect reasons, but they all fall into one of several classes shown below:

• EC DISC: remote client modem requested disconnect (indicated by "rmtLink")

• Local DTE requested disconnect (indicated by "dtrDrop" or "hostDrop")

  • DTR drop (need to check local DTE (NAS and Cisco IOS) for an explanation)

  • +++ / ATH received - which causes the modem to hang-up

  • network-initiated disconnect - for example the PSTN circuit cleared

  • received PPP LCP TERMREQs (Termination Request) from the peer

• Problem with the modem link (Bad Disconnects)

  • lost carrier

  • too many EC retransmissions

  • too many retrains

  • modem protocol error: bad EC frame or illegal compression data

For more information on the various MICA states, as well as the disconnect reasons reported by MICA modems, refer to the MICA Modem States and Disconnect Reasons and Interpreting NextPort Disconnect Reason Codes documents.

Inspecting Individual Modems with the show modem operational-status Command

If you have the output of a show modem operational-status command from your Cisco device, you can use to display potential issues and fixes. To use , you must be a registered customer, be logged in, and have JavaScript enabled.

If you use the show modem command and observe that certain modems or cluster(s) of modems are experiencing high rates of failures or if you just want to inspect particular MICA modems, you should use the show modem operational-status command.

For more information on understanding the show modem operational-status output, refer to the IOS show modem Command Reference.

Measure and record the values for the important modem performance metrics, so that you have a good understanding of how things are working, and so that you can tell whether configuration changes are providing any significant improvement.

The Output Interpreter tool allows you to receive an analysis of the show modem operational-status command output.

The tool provides information that you can use to evaluate parameters for the current call (for example, signal-to-noise ratios (SNRs) and connect speeds). The quality of modem calls can be affected by factors such as SNRs, line shapes, and digital pads, and Output Interpreter provides an evaluation of these factors in simple terms. You can use the analysis and recommendations to troubleshoot the issue further.

For further information, refer to What is the Difference Between Async and LAP-M Framing? For information on general line impairments, see Understanding Line Impairments. For information on transmit and receive levels, refer to Understanding Transmit and Receive Levels on Modems.

Other Options

If you have verified the T1 layer is operating within specifications, yet things are not behaving acceptably well at the modem layer, here are some things to try:

• Make sure that you are running the latest modem firmware code. You can download the modem firmware from Downloads on www.cisco.com. In order to upgrade the code on the NAS, see Software Installation and Upgrade Procedures.

• Dial out from your own known good modem/local loop into the target NAS. If you get a connection of the desired quality, this proves that the NAS, its modems, and its T1/E1 line are healthy.

When troubleshooting modem connectivity issues, it is important to understand that there are many conflicting factors that affect the connection, hence it may be difficult to pinpoint an area of failure. Also if the problem lies within the PSTN network, it may be hard to correct it.

Related Information

• Understanding Line Impairments
• Configuring Client Modems to Work with Cisco Access Servers
• T1 Troubleshooting
• Dialup Technology: Troubleshooting Techniques
• E1 R2 Signaling Configuration and Troubleshooting
• Dial Case Study Overview
• 56k Client Modem Troubleshooting
• Cable Modems Technology Support
• Technical Support & Documentation - Cisco Systems