Guest

Dial-on-Demand Routing (DDR)

Troubleshooting Dial Technology Connectivity - Non-DDR Callout

Document ID: 14955

Updated: Jul 09, 2007

   Print

Introduction

This document provides methods of troubleshooting different types of dial connections and is not intended to be read from start to finish. The structure is designed to allow the reader to skip forward to the sections of interest, each of which are variations on the overall troubleshooting theme for a specific case. This document covers three main scenarios; before you begin to troubleshoot, determine what type of call is being attempted and go to that section:

Prerequisites

Requirements

There are no specific prerequisites for this document.

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.

History

Dialup is simply the application of the public switched telephone network (PSTN) that carries data on behalf of the end user. It involves a customer premises equipment (CPE) device sending the telephone switch a phone number to which to direct a connection. The AS3600, AS5200, AS5300, and AS5800 are all examples of routers that have the ability to run a Primary Rate Interface (PRI) along with banks of digital modems. The AS2511, on the other hand, is an example of a router that communicates with external modems.

The carrier market has grown significantly, and the market now demands higher modem densities. The answer to this need is a higher degree of interoperation with the telephone company equipment and the development of the digital modem. This is a modem that is capable of direct digital access to the PSTN. As a result, faster CPE modems have now been developed that take advantage of the clarity of signal that the digital modems enjoy. The fact that the digital modems connecting into the PSTN through a PRI or Basic Rate Interface (BRI) can transmit data at over 53k using the V.90 communication standard, attests to the success of the idea.

The first access servers were the AS2509 and AS2511. The AS2509 could support 8 incoming connections using external modems, and the AS2511 could support 16. The AS5200 was introduced with 2 PRIs and could support 48 users using digital modems, and it represented a major leap forward in technology. Modem densities have increased steadily with the AS5300 supporting 4 and then 8 PRIs. Finally, the AS5800 was introduced to fill the needs of carrier class installations needing to handle dozens of incoming T1s and hundreds of user connections.

A couple of outdated technologies bear mentioning in a historical discussion of dialer technology. 56Kflex is an older (pre-V.90) 56k modem standard that was proposed by Rockwell. Cisco supports version 1.1 of the 56Kflex standard on its internal modems, but recommends migrating the CPE modems to V.90 as soon as possible. Another outdated technology is the AS5100. The AS5100 was a joint venture between Cisco and a modem manufacturer. The AS5100 was created as a way to increase modem density through the use of quad modem cards. It involved a group of AS2511s built as cards that inserted into a backplane shared by quad modem cards, and a dual T1 card.

Conventions

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

Non-DDR Callout

There are a few common reasons to do a non-DDR outbound call from a Cisco access server:

  • To use the access server with Cisco Dialout Utility.

  • To use the access server as a terminal server to access a character cell dialup session on another server, perhaps to manually log in and start PPP later.

  • To test or configure a modem (refer to Configuring Reverse Telnet).

Similar to troubleshooting DDR Callouts, the general flow of reasoning for troubleshooting Non-DDR Callouts resembles the following:

  1. Is the TCP connection to the listening port successful? (A yes advances to the next question)

  2. Is the modem able to offer the AT prompt?

  3. Does the call make it out to the PSTN?

  4. Does the remote end answer the call?

  5. Does the call complete?

  6. Is data passing over the link?

  7. Is the session established? (PPP or Terminal)

A Few Notes About the Cisco Dialout Utility

The Cisco Dialout Utility allows a community of Windows PCs to effectively share the modem resources of an access server. The general steps in setting up the Cisco Dialout Utility for a community of users are:

  1. Set up the Network Access Server (NAS) with the following commands under the line configurations:

    line 1 16
    modem InOut
    rotary 1
    transport input all
    flowcontrol hardware
  2. Install Cisco Dialout on the PCs that will be using the NAS's modems. Verify the configurations:

    1. Double-click on the dialout utility icon at the bottom right of the screen.

    2. Click More.

    3. Click Configure Ports.

  3. Enabling modem logging on the PC is also suggested. This is done by clicking Start > Control Panel > Modems. Select your Cisco dialout modem and click the Properties button. Select the Connection tab, then click the Advanced button. Select the Record a log file check box.

  4. Configure Dial Up Networking on the PCs to use the Cisco Dialout COM port.

There are a few things to know about the port number selection for Cisco Dialout Utility. By default, it tries to use TCP port 6001. This implies that it is the only user on an outbound NAS. Since this is not normally the case, it is better to use 7001 to take advantage of the rotary function. TCP listener processes are created by putting the transport input command on a line configuration. Here's a table of what the various IP port number ranges do:

Table 3: TCP Listener Ports Set Up by The "Transport Input" Command

2000 Telnet protocol
3000 Telnet protocol with rotary
4000 Raw TCP protocol
5000 Raw TCP protocol with rotary
6000 Telnet protocol, binary mode
7000 Telnet protocol, binary mode with rotary
9000 XRemote protocol
10000 XRemote protocol with rotary

A rotary allows someone to make an inbound TCP connection to a specified port and end up connecting to any modem currently available that has the rotary group number. In the above example, the rotary group sets up listeners on 3001, 5001, 7001, and 10001. Cisco Dialout Utility uses binary mode, so 7001 is the correct number to configure the client programs to use on the PCs.

Troubleshooting Non-DDR Dialout

Try these steps to troubleshoot your non-DDR dialout.

  1. To watch the initial success of a non-DDR callout (for example, a Configuring Reverse Telnet callout), use the debug telnet command to see the incoming telnet connection to the router.

  2. If the TCP connection is being refused, there is either no listener at the specified address and port or someone is already connected to that port. Verify the address to which you are connecting, and verify the port number.

    Also, ensure the modem inout (or modem dtr-active) and the transport input all commands appear under the line configuration for the line being reached. If using the rotary function, ensure the rotary 1 (or whatever number you chose) command also appears in the line configuration. To see whether someone is connected, telnet to the router and use the show line command. Look for an asterisk to indicate that the line is in use. Also, use the show line n command to ensure Clear to Send (CTS) is high and data set ready (DSR) is not. Use the clear line n command to disconnect the current session on that port number.

At this point, the telnet should be working. Next, identify the type of media that is being used for the outbound connection:

External Async Modem Non-DDR Callout

To identify an external async modem non-DDR callout (for example,Configuring Reverse Telnet callout), perform the following:

  1. Enter the AT command, and ensure that an OK response appears. If the OK response does not appear, enter the AT&FE1Q0 command. Enter the AT command again to see whether the OK response appears. If the OK response appears, the modem may need to be initialized. If you still do not get an OK response, verify the cabling, line speed, and parity settings on the local async modem to the router connection. For further reference, see the Modem-Router Connection Guide.

  2. Turn up the volume on the modem's speaker with the ATM1 command and enter ATDT <number>.

  3. If the remote end does not seem to be answering, verify that the call is being placed by the originating modem by calling a local number manually with the command ATDT <number>and listening for the ring.

  4. If there is no ring, the call is not getting out.

    Swap the originating modem's cables and try again. If it still is not working, try a handset on the line. Be sure to use the same cable that the modem was using. If the handset is not able to make an outbound call even with the new cable, contact the telco to check the originating phone line.

  5. If the modem seems to be placing the calls as expected, ensure that the called phone number is correct.

    Use a handset to call the receiving number. Be sure to use the same cable that the modem was using. If a manual call is able to reach the receiving number, listen for the remote modem to offer answerback tone (ABT). If the call goes unanswered or no ABT is heard, the receiving modem may not be set to autoanswer. The command to tell most modems to autoanswer is ATS0=1. The receiving modem may need to be initialized or debugged. If the receiving modem is attached to a Cisco router, refer to the Modem-Router Connection Guide for further details. Verify the modem, and replace as needed.

  6. If a manual call is not able to reach the answering async modem, change the phone cables on the receiving modem and try a regular phone on the receiving modem's line. If the call can be received by the regular phone, there is likely a problem with the receiving modem. Verify the modem, and replace as needed.

  7. If the manual call is still not able to reach the regular phone on the line in question, try another (known good) line in the receiving facility. If that connects, have the telco check the phone line going to the receiving modem.

  8. If the manual call is not able to reach the receiving facility and this is a long-distance call, have the originating side try another (known good) long-distance number.

    If that works, the receiving facility or line may not be provisioned to receive long-distance calls. If the originating line cannot reach any other long-distance numbers, it may not have long distance enabled. Try 10-10 codes for different long distance companies.

  9. Ensure that the async modems train up.

    If the async modems do not train up, manually call the number and listen for static. There may be other factors interfering with train up. There may be a cable problem between the receiving modem and the DTE to which it is attached. Trainup failures are likely a circuit or incompatibility problem. Some of this can be remedied by detuning the modems, which limits them to less "aggressive" speeds. As an example of the technique, llet's try a connection to one of Cisco's test systems. First, we'll want to enable the speaker and DCE rate information reporting:

    atm1
    OK

    Next, we dial into a static lab:

    at
    OK
    atdt914085703932
    NO CARRIER

    The normal connection seems to be failing. In this case we know it is a noisy line, so put the modem to factory defaults (&f), turn on the speaker (m1), and cap the modem at 28.8 (&n14 for USR modems) with the following command:

    at&fm1&n14
    OK 

    Now we try the dial again:

    atdt914085703932 
    CONNECT 28800/ARQ 
    
    
    Welcome! Please login with username cisco, password
    cisco, and type the appropriate commands for your test:
    
    ppp - to start ppp
    slip - to start slip
    arap - to start arap
    
    access-3 line 29 MICA V.90 modems
    
    
    User Access Verification
    
    Username: cisco
    Password:
    
    access-3>
  10. Ensure that data is flowing. Press the Return key a few times to see whether data is flowing back and forth from the remote system to the local session. If data is not flowing, there may be a cable or signal problem when the remote async modem tries to communicate with the remote DTE. Debug and replace as needed.

If entering data gets a reasonable response from the other side, the modem connection is working.

CAS T1/E1 Non-DDR Callout

Follow these steps to perform a CAS T1/E1 non-DDR callout.

  1. Diagnose a CAS T1/E1 async modem Non-DDR Callout, use the following commands, then try to make a call:

    warning Warning: Running debugs on a busy system could crash the router by overloading the CPU or over-running the console buffer.

    router# debug modem
    router# debug modem csm
    router# debug cas
    

    Note: The debug cas command is available on Cisco AS5200 and AS5300 platforms running Cisco IOS?? Software Release 12.0(7)T and later. In prior versions of IOS, the command service internal would have to be entered into the main level of the router's configuration and modem-mgmt csm debug-rbs would need to be entered at the exec prompt. Debugging RBS on the Cisco AS5800 requires connecting to the trunk card. (Use modem-mgmt csm no-debug-rbs to turn off the debug.)

  2. Enter the AT command and ensure that an OK response appears.

    If the OK response does not appear, enter the AT&F command. Enter the AT command again to see whether the OK response appears. If the OK response appears, the modem may need to be initialized. If you still do not get an OK response, there may be a problem with the modem module. Before a call can be placed, a modem must be allocated for the call. To view this process and the subsequent call, use the debug output to determine whether this is happening. For example:

    Turning on the debugs:

    router#conf t 
    Enter configuration commands, one per line.  End with CNTL/Z. 
    router(config)#service internal 
    router(config)#^Z 
    router#modem-mgmt csm ? 
      debug-rbs     enable rbs debugging 
      no-debug-rbs  disable rbs debugging 
    router#modem-mgmt csm debug-rbs 
    router# 
    neat msg at slot 0: debug-rbs is on 
    neat msg at slot 0: special debug-rbs is on 

    Turning off the debugs:

    router# 
    router#modem-mgmt csm no-debug-rbs 
    neat msg at slot 0: debug-rbs is off

    Debugging this information on an AS5800 requires connecting to the trunk card. The following is an example of a normal outbound call over a CAS T1 that is provisioned and configured for FXS-Ground-Start:

    Mica Modem(1/0): Rcvd Dial String(5551111) 
    [Modem receives digits from chat script]
    
    CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0 
    
    CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
    EVENT_CHANNEL_LOCK at slot 1 and port 0 
    
    CSM_PROC_OC4_DIALING: 
    CSM_EVENT_DSX0_BCHAN_ASSIGNED at slot 1, port 0 
    
    Mica Modem(1/0): Configure(0x1) 
    
    Mica Modem(1/0): Configure(0x2) 
    
    Mica Modem(1/0): Configure(0x5) 
    
    Mica Modem(1/0): Call Setup 
    
    neat msg at slot 0: (0/2): Tx RING_GROUND 
    
    Mica Modem(1/0): State Transition to Call Setup 
    
    neat msg at slot 0: (0/2): Rx TIP_GROUND_NORING 
    [Telco switch goes OFFHOOK]
    
    CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
    EVENT_START_TX_TONE at slot 1 and port 0 
    
    CSM_PROC_OC5_WAIT_FOR_CARRIER: CSM_EVENT_DSX0_START_TX_TONE at slot 1, 
    port 0 
    
    neat msg at slot 0: (0/2): Tx LOOP_CLOSURE [Now the router goes OFFHOOK]
    
    Mica Modem(1/0): Rcvd Tone detected(2) 
    
    Mica Modem(1/0): Generate digits:called_party_num=5551111 len=8 
    
    Mica Modem(1/0): Rcvd Digits Generated 
    
    CSM_PROC_OC5_WAIT_FOR_CARRIER: CSM_EVENT_ADDR_INFO_COLLECTED at slot 1, 
    port 0 
    
    CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  EVENT_CHANNEL_CONNECTED at slot 1 
    and port 0 
    
    CSM_PROC_OC5_WAIT_FOR_CARRIER: CSM_EVENT_DSX0_CONNECTED at slot 1, 
    port 0 
    
    Mica Modem(1/0): Link Initiate 
    
    Mica Modem(1/0): State Transition to Connect 
    
    Mica Modem(1/0): State Transition to Link 
    
    Mica Modem(1/0): State Transition to Trainup 
    
    Mica Modem(1/0): State Transition to EC Negotiating 
    
    Mica Modem(1/0): State Transition to Steady State 
    
    Mica Modem(1/0): State Transition to Steady State Speedshifting 
    
    Mica Modem(1/0): State Transition to Steady State

    Debugs for T1s and E1s with other signaling types are similar.

    Getting to this point in the debugging indicates that the calling and answering modems have trained and connected. If a modem is properly allocated for the outbound call but the connection fails to get this far, the T1 must be examined. Use the show controller t1/e1 command to verify that T1/E1 is working. See Troubleshooting Serial Lines for an explantion of show controller output. If the T1/E1 is not working properly, then T1/E1 troubleshooting is necessary.

  3. If the modem seems to be placing the calls as expected, ensure that the called phone number is correct.

    Use a handset to call the receiving number. If a manual call is able to reach the receiving number, listen for the remote modem to offer answerback tone (ABT). If the call goes unanswered or no ABT is heard, the receiving modem may not be set to autoanswer. The command to tell most modems to autoanswer is ATS0=1. The receiving modem may need to be initialized or debugged. If the receiving modem is attached to a Cisco router, refer to the Modem-Router Connection Guide for further details. Verify the modem, and replace as needed.

  4. If the manual call is still not able to reach the regular phone on the line in question, try another (known good) line in the receiving facility. If that connects, have the telco check the phone line going to the receiving modem.

  5. If this is a long distance call, have the originating side try another (known good) long-distance number.

    If that works, the receiving facility or line may not be provisioned to receive long-distance calls. If the originating (CAS) line cannot reach any other long-distance numbers, it may not have long distance enabled. Try 10-10 codes for different long distance companies.

  6. Ensure that the async modems train up.

    If the async modems do not train up, manually call the number and listen for static. There may be other factors interfering with train up. There may be a cable problem between the receiving modem and the DTE to which it is attached. Trainup failures are likely a circuit or incompatibility problem. Some of this can be remedied by detuning the modems, which limits them to less "aggressive" speeds. As an example of the technique, let's try a connection to one of Cisco's test systems.

    at
    OK 

    Next we dial into a static lab:

    at
    OK
    atdt914085703932
    NO CARRIER

    The normal connection seems to be failing. In this case we know it's a noisy line, so let's put the modem to factory defaults (&f), turn on the speaker (m1), and cap the modem at 28.8 (S56=28800) with the following command:

    at&fs56=28800
    OK 

    Now we try the dial again:

    atdt914085703932 
    CONNECT 28800/ARQ 
    
    Welcome! Please login with username cisco, password
    cisco, and type the appropriate commands for your test:
    
    ppp - to start ppp
    slip - to start slip
    arap - to start arap
    
    access-3 line 29 MICA V.90 modems
    
    User Access Verification
    
    Username: cisco
    Password:
    
    access-3>
  7. Ensure that data is flowing.

    Press the Return key a few times to see whether data is flowing back and forth from the remote system to the local session. If data is not flowing, there may be a cable or signal problem when the remote async modem tries to communicate with the remote DTE. Debug, and replace as needed.

If entering data gets a reasonable response from the other side, the modem connection is working.

PRI Non-DDR Callout

Follow these steps to perform a PRI non-DDR callout.

  1. Diagnose a PRI async modem Non-DDR Callout, use the following commands, then try to make a call:

    warning Warning:  Running debugs on a busy system could crash the router by overloading the CPU or over-running the console buffer!

    router# debug modem
    router# debug modem csm
    router# debug isdn q931
    router# debug isdn
    
  2. Enter the AT command and ensure that an OK response appears.

    If the OK response does not appear, enter the AT&F command. Enter the AT command again to see whether the OK response appears. If the OK response appears, the modem may need to use a modemcap to be initialized. This involves using the command modem autoconfigure type xxx , where xxx is the modem type. If you still do not get an OK response, there may be a problem with the modem module. Verify that the modem can place a call by manually initiating a dial. If the remote end does not seem to be answering, verify that the call is being placed by the modem by calling a local number manually with the command ATDT <number> and listening for the ring. If no call gets out, there may be an ISDN problem. Upon the first suspicion of an ISDN failure on a BRI, always check the output from show isdn status. The key things to note are that Layer 1 should be Active and Layer 2 should be in a state of MULTIPLE_FRAME_ESTABLISHED. Refer to Interpreting Show ISDN Status for information on reading this output, as well as for corrective measures.

    For outbound ISDN calls, debug isdn q931 and debug isdn events are the best tools to use. Fortunately, debugging outbound calls is very similar to debugging incoming calls. A normal successful call might look like this:

    *Mar 20 21:07:45.025: ISDN SE0:23: Event: 
    Call to 5553759 at 64 Kb/s
    
    *Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8  callref = 0x2C
    *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
    *Mar 20 21:07:45.041:         Channel ID i = 0x83
    *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
    *Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8  callref = 0xAC
    *Mar 20 21:07:45.145:         Channel ID i = 0x89
    *Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING
            Channel ID i = 0x0101
    *Mar 20 21:07:45.161:   -------------------
            Channel ID i = 0x89
    *Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8  callref = 0xAC
    *Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT
    

    Note that the CONNECT message is the key indicator of success. If a CONNECT is not received, you may see a DISCONNECT or a RELEASE_COMP (release complete) message followed by a cause code:

    *Mar 20 22:11:03.212: ISDN SE0:23: RX <-  RELEASE_COMP pd = 8  
    callref = 0x8F
    *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected 

    The cause value indicates two things.

    • The second byte of the 4- or 6-byte value indicates the point in the end-to-end call path from which the DISCONNECT or RELEASE_COMP was received. This can help you to localize the problem.

    • The third and fourth bytes indicate the actual reason for the failure. See Table 9 for the meanings of the different values.

  3. If the modem seems to be placing the calls as expected, ensure that the called phone number is correct.

    Use a handset to call the receiving number. If a manual call is able to reach the receiving number, listen for the remote modem to offer answerback tone (ABT). If the call goes unanswered or no ABT is heard, the receiving modem may not be set to autoanswer. The command to tell most modems to autoanswer is ATS0=1. The receiving modem may need to be initialized or debugged. If the receiving modem is attached to a Cisco router, refer to the Modem-Router Connection Guide for further details. Verify the modem, and replace as needed.

  4. If the manual call is still not able to reach the regular phone on the line in question, try another (known good) line in the receiving facility. If that connects, have the telco check the phone line going to the receiving modem.

  5. If this is a long distance call, have the originating side try another (known good) long-distance number.

    If that works, the receiving facility or line may not be provisioned to receive long-distance calls. If the originating (BRI) line cannot reach any other long-distance numbers, it may not have long distance enabled. Try 10-10 codes for different long distance companies.

  6. Ensure that the async modems train up.

    If the async modems do not train up, manually call the number and listen for static. There may be other factors interfering with train up. There may be a cable problem between the receiving modem and the DTE to which it is attached. Trainup failures are likely a circuit or incompatibility problem. Some of this can be remedied by detuning the modems, which limits them to less "aggressive" speeds. As an example of the technique, let's try a connection to one of Cisco's test systems.

    at
    OK

    Next we dial into a static lab:

    at
    OK
    atdt914085703932
    NO CARRIER

    The normal connection seems to be failing. In this case we know it's a noisy line, so let's put the modem to factory defaults (&f), turn on the speaker (m1), and cap the modem at 28.8 (S56=28800) with the following command:

    at&fs56=28800
    OK 

    Now we try the dial again:

    atdt914085703932 
    CONNECT 28800/ARQ 
    
    
    Welcome! Please login with username cisco, password
    cisco, and type the appropriate commands for your test:
    
    ppp - to start ppp
    slip - to start slip
    arap - to start arap
    
    access-3 line 29 MICA V.90 modems
    
    User Access Verification
    
    Username: cisco
    Password:
    
    access-3>
    
  7. Ensure that data is flowing.

    Press the Return key a few times to see whether data is flowing back and forth from the remote system to the local session. If data is not flowing, there may be a cable or signal problem when the remote async modem tries to communicate with the remote DTE. Debug, and replace as needed.

If entering data gets a reasonable response from the other side, the modem connection is working.

BRI Non-DDR Callout

This feature only works on the Cisco 3640 platform using Cisco IOS Software Release 12.0(3)T or later. It requires a later hardware revision of the BRI network module. This will not work with a WAN Interface Card (WIC).

  1. Diagnose a PRI async modem Non-DDR Callout, use the following commands, then try to make a call:

    warning Warning:  Running debugs on a busy system could crash the router by overloading the CPU or over-running the console buffer!

    router# debug modem
    router# debug modem csm
    router# debug isdn q931
    router# debug isdn
    
  2. Enter the AT command and ensure that an OK response appears.

    Enter the AT command and ensure that an OK response appears. If the OK response does not appear, enter the AT&F command. Enter the AT command again to see whether the OK response appears. If the OK response appears, the modem may need to use a modemcap to be initialized. This involves using the command modem autoconfigure type xxx , where xxx is the modem type. If you still do not get an OK response, there may be a problem with the modem module. Verify that the modem can place a call by manually initiating a dial. If the remote end does not seem to be answering, verify that the call is being placed by the modem by calling a local number manually with the command ATDT<number>and listening for the ring. If no call gets out, there may be an ISDN problem. Upon the first suspicion of an ISDN failure on a BRI, always check the output from show isdn status. The key things to note are that Layer 1 should be Active and Layer 2 should be in a state of MULTIPLE_FRAME_ESTABLISHED. Refer to Interpreting Show ISDN Status for information on reading this output, as well as for corrective measures.

    For outbound ISDN calls, debug isdn q931 and debug isdn events are the best tools to use. Fortunately, debugging outbound calls is very similar to debugging incoming calls. A normal successful call might look like this:

    *Mar 20 21:07:45.025: ISDN BR0: Event: Call to 5553759 at 64 Kb/s
    
    *Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x2C
    *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
    *Mar 20 21:07:45.041:         Channel ID i = 0x83
    *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
    *Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0xAC
    *Mar 20 21:07:45.145:         Channel ID i = 0x89
    *Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING
            Channel ID i = 0x0101
    *Mar 20 21:07:45.161:   -------------------
            Channel ID i = 0x89
    *Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0xAC
    *Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT

    Note that the CONNECT message is the key indicator of success. If a CONNECT is not received, you may see a DISCONNECT or a RELEASE_COMP (release complete) message followed by a cause code:

    *Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8  callref = 0x8F
    *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

    The cause value indicates two things.

    • The second byte of the 4- or 6-byte value indicates the point in the end-to-end call path from which the DISCONNECT or RELEASE_COMP was received. This can help you to localize the problem.

    • The third and fourth bytes indicate the actual reason for the failure. See Table 9 for the meanings of the different values.

  3. If the modem seems to be placing the calls as expected, ensure that the called phone number is correct.

    Use a handset to call the receiving number. If a manual call is able to reach the receiving number, listen for the remote modem to offer answerback tone (ABT). If the call goes unanswered or no ABT is heard, the receiving modem may not be set to autoanswer. The command to tell most modems to autoanswer is ATS0=1. The receiving modem may need to be initialized or debugged. If the receiving modem is attached to a Cisco router, refer to the Modem-Router Connection Guide for further details. Verify the modem, and replace as needed.

  4. If the manual call is still not able to reach the regular phone on the line in question, try another (known good) line in the receiving facility.

    If that connects, have the telco check the phone line going to the receiving modem.

  5. If this is a long distance call, have the originating side try another (known good) long-distance number.

    If that works, the receiving facility or line may not be provisioned to receive long-distance calls. If the originating (BRI) line cannot reach any other long-distance numbers, it may not have long distance enabled. Try 10-10 codes for different long distance companies.

  6. Ensure that the async modems train up.

    If the async modems do not train up, manually call the number and listen for static. There may be other factors interfering with train up. There may be a cable problem between the receiving modem and the DTE to which it is attached. Trainup failures are likely a circuit or incompatibility problem. Some of this can be remedied by detuning the modems, which limits them to less "aggressive" speeds. As an example of the technique, let's try a connection to one of Cisco's test systems.

    at
    OK 

    Next we dial into a static lab:

    at
    OK
    atdt914085703932
    NO CARRIER

    The normal connection seems to be failing. In this case we know it's a noisy line, so let's put the modem to factory defaults (&F), turn on the speaker (m1), and cap the modem at 28.8 (S56=28800) with the following command:

    at&fs56=28800
    OK

    Now we try the dial again:

    atdt914085703932 
    CONNECT 28800/ARQ 
    
    Welcome! Please login with username cisco, password
    cisco, and type the appropriate commands for your test:
    
    ppp - to start ppp
    slip - to start slip
    arap - to start arap
    
    access-3 line 29 MICA V.90 modems
    
    User Access Verification
    
    Username: cisco
    Password:
    
    access-3>
  7. Ensure that data is flowing.

    Press the Return key a few times to see whether data is flowing back and forth from the remote system to the local session. If data is not flowing, there may be a cable or signal problem when the remote async modem tries to communicate with the remote DTE. Debug, and replace as needed.

If entering data gets a reasonable response from the other side, the modem connection is working.

Common Problems

Debugging Session Establishment

At this point in the sequence, the modems are connected and trained up. Now it?s time to find out whether any traffic is coming across properly.

If the line receiving the call is configured with autoselect ppp and the async interface is configured with async mode interactive, use the command debug modem to verify the autoselect process. As traffic comes in over the async link, the access server will examine the traffic to determine whether the traffic is character-based or packet-based. Depending on the determination, the access server will then either start a PPP session or go no farther than having an exec session on the line.

A normal autoselect sequence with inbound PPP LCP packets:

*Mar  1 21:34:56.958: TTY1: DSR came up

*Mar  1 21:34:56.962: tty1: Modem: IDLE->READY
*Mar  1 21:34:56.970: TTY1: EXEC creation
*Mar  1 21:34:56.978: TTY1: set timer type 10, 30 seconds
*Mar  1 21:34:59.722: TTY1: Autoselect(2) sample 7E        (See Note 1)
*Mar  1 21:34:59.726: TTY1: Autoselect(2) sample 7EFF
*Mar  1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D
*Mar  1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D23
*Mar  1 21:34:59.734: TTY1 Autoselect cmd: ppp negotiate   (See Note 2)
*Mar  1 21:34:59.746: TTY1: EXEC creation
*Mar  1 21:34:59.746: TTY1: create timer type 1, 600 seconds
*Mar  1 21:34:59.794: TTY1: destroy timer type 1 (OK)
*Mar  1 21:34:59.794: TTY1: destroy timer type 0
*Mar  1 21:35:01.798: %LINK-3-UPDOWN: Interface Async1, changed state to up
(See Note 3)

Note 1: The inbound traffic is displayed in hexadecimal format. This is based on the bits coming in over the line, regardless of whether the bits are ASCII characters or elements of a packet. The bits represented in this example are correct for an LCP packet. Anything different would be either a malformed packet or character traffic.

Note 2: Having determined that the inbound traffic is actually an LCP packet, the access server triggers the PPP negotiation process.

Note 3: The async interface changes state to up, and the PPP negotiation (not shown) commences.

If the call is a PPP session and if async mode dedicated is configured on the async interface, use the command debug ppp negotiation to see whether any configuration request packets are coming from the remote end. The debugs show these as CONFREQ. If you observe both inbound and outbound PPP packets, refer to Troubleshooting PPP. Otherwise, connect from the call-originating end with a character-mode (or "exec") session (that is, a non-PPP session).

Note: If the receiving end displays async modem dedicated under the async interface, an exec dial-in only shows what appears to be random ASCII garbage. To allow a terminal session and still have PPP capability, use the async interface configuration command async mode interactive. Under the associated line?s configuration, use the command autoselect ppp.

If the modems connect with a terminal session and no data comes across, check the following:

Table 4: Modem Cannot Send or Receive Data

Possible Causes Suggested Actions
Modem speed setting is not locked
  1. Use the show line exec command on the access server or router. The output for the auxiliary port should indicate the currently configured Tx and Rx speeds. For an explanation of the output of the show line command, refer to Using Debug Commands.
  2. If the line is not configured to the correct speed, use the speed line configuration command to set the line speed on the access server or router line. Set the value to the highest speed in common between the modem and the access server or router port. To set the terminal baud rate, use the speed line configuration command. This command sets both the transmit (to terminal) and receive (from terminal) speeds. Syntax: speed bps Syntax Description: bps? Baud rate in bits per second (bps). The default is 9600 bps. Example: The following example sets lines 1 and 2 on a Cisco 2509 access server to 115200 bps: line 1 2 speed 115200

    Note: If, for some reason, you cannot use flow control, limit the line speed to 9600 bps. Faster speeds are likely to result in lost data.

  3. Use the show line exec command again, and confirm that the line speed is set to the desired value.
  4. When you are certain that the access server or router line is configured for the desired speed, initiate a reverse telnet session to the modem via that line. For more information, refer to Configuring Reverse Telnet.
  5. Use a modem command string that includes the lock DTE speed command for your modem. See your modem documentation for exact configuration command syntax.

    Note: The lock DTE speed command, which might also be referred to as port rate adjust or buffered mode , is often related to the way in which the modem handles error correction. This command varies widely from one modem to another.

    Locking the modem speed ensures that the modem always communicates with the Cisco access server or router at the speed configured on the Cisco auxiliary port. If this command is not used, the modem reverts to the speed of the data link (the telephone line), instead of communicating at the speed configured on the access server.
Hardware flow control not configured on local or remote modem or router
  1. Use the show line aux-line-number exec command and look for the following in the Capabilities field:
    Capabilities: Hardware Flowcontrol In, 
    Hardware Flowcontrol Out
    For more information, refer to Interpreting Show Line Output. If there is no mention of hardware flow control in this field, hardware flow control is not enabled on the line. Hardware flow control for access server-to-modem connections is recommended. For an explanation of the output of the show line command, refer to Using Debug Commands.
  2. Configure hardware flow control on the line using the flowcontrol hardware line configuration command. To set the method of data flow control between the terminal or other serial device and the router, use the flowcontrol line configuration command. Use the no form of this command to disable flow control. Syntax: flowcontrol {none | software [lock] [in | out] | hardware [in | out]} Syntax Description: none?Turns off flow control. software?Sets software flow control. An optional keyword specifies the direction: in causes the Cisco IOS software to listen to flow control from the attached device, and out causes the software to send flow control information to the attached device. If you do not specify a direction, both are assumed. lock?Makes it impossible to turn off flow control from the remote host when the connected device needs software flow control. This option applies to connections using the Telnet or rlogin protocols. hardware?Sets hardware flow control. An optional keyword specifies the direction: in causes the software to listen to flow control from the attached device, and out causes the software to send flow control information to the attached device. If you do not specify a direction, both are assumed. For more information about hardware flow control, see the hardware manual that was shipped with your router. Example: The following example sets hardware flow control on line 7: line 7 flowcontrol hardware

    Note: If for some reason you cannot use flow control, limit the line speed to 9600 bps. Faster speeds are likely to result in lost data.

  3. After enabling hardware flow control on the access server or router line, initiate a reverse telnet session to the modem via that line. For more information, refer to Configuring Reverse Telnet.
  4. Use a modem command string that includes the RTS/CTS Flow command for your modem. This command ensures that the modem is using the same method of flow control (that is, hardware flow control) as the Cisco access server or router. See your modem documentation for exact configuration command syntax.
Misconfigured dialer map commands
  1. Use the show running-config privileged exec command to view the router configuration. Check the dialer map command entries to see whether the broadcast keyword is specified.
  2. If the keyword is missing, add it to the configuration. Syntax: dialer map protocol next-hop-address [name hostname] [broadcast] [dial-string] Syntax Description: protocol? The protocol subject to mapping. Options include IP, IPX, bridge, and snapshot. next-hop-address? The protocol address of the opposite site's async interface. name hostname? A required parameter used in PPP authentication. It is the name of the remote site for which the dialer map is created. The name is case sensitive and must match the hostname of the remote router. broadcast?An optional keyword that broadcast packets (for example, IP RIP or IPX RIP/SAP updates) that is forwarded to the remote destination. In static routing sample configurations, routing updates are not desired and the broadcast keyword is omitted. dial-string? The remote site's phone number. Any access codes (for example, 9 to get out of an office, international dialing codes, area codes) must be included.
  3. Make sure that the dialer map commands specify the correct next hop addresses.
  4. If the next hop address is incorrect, change it using the dialer map command.
  5. Make sure all other options in dialer map commands are correctly specified for the protocol you are using.
For detailed information on configuring dialer maps, refer to the Cisco IOS Wide-Area Networking Configuration Guide and Wide-Area Networking Command Reference.
Problem with dialing modem Make sure that the dialing modem is operational and is securely connected to the correct port. Determine whether another modem works when connected to the same port.

Debugging an incoming exec session generally falls into a few main categories:

  • Dialup client receives no exec prompt. Refer to Table 17-2.

  • Dialup session sees "garbage." Refer to Table 17-3.

  • Dialup opens in existing session. Refer to Table 17-4.

  • Dialup receiving modem does not disconnect properly. Refer to Table 17-5.

Table 5: Dialup Client Receives No exec Prompt

Possible Causes Suggested Actions
Autoselect is enabled on the line Attempt to access exec mode by pressing Enter.
Line is configured with the no exec command
  1. Use the show line exec command to view the status of the appropriate line. Check the Capabilities field to see whether it says "exec suppressed." If this is the case, the no exec line configuration command is enabled.
  2. Configure the exec line configuration command on the line to allow exec sessions to be initiated. This command has no arguments or keywords.
Example: The following example turns on the exec on line 7: line 7 exec
Flow control is not enabled. or Flow control is enabled only on one device (either DTE or DCE). or Flow control is misconfigured.
  1. Use the show line aux-line-number exec command and look for the following in the Capabilities field:
    Capabilities: Hardware Flowcontrol In, 
    Hardware Flowcontrol Out
    
    For more information, refer to Interpreting Show Line Output. If there is no mention of hardware flow control in this field, hardware flow control is not enabled on the line. Hardware flow control for access server-to-modem connections is recommended. For an explanation of the output from the show line command, refer to Using Debug Commands.
  2. Configure hardware flow control on the line using the flowcontrol hardware line configuration command. Example: The following example sets hardware flow control on line 7: line 7 flowcontrol hardware

    Note: If for some reason you cannot use flow control, limit the line speed to 9600 bps. Faster speeds are likely to result in lost data.

  3. After enabling hardware flow control on the access server or router line, initiate a reverse telnet session to the modem via that line. For more information, refer to Configuring Reverse Telnet.
  4. Use a modem command string that includes the RTS/CTS Flow command for your modem. This command ensures that the modem is using the same method of flow control (hardware flow control) as the Cisco access server or router. See your modem documentation for exact configuration command syntax.
Modem speed setting is not locked
  1. Use the show line exec command on the access server or router. The output for the auxiliary port should indicate the currently configured Tx and Rx speeds. For an explanation of the output of the show line command, see the Using Debug Commands section in chapter 15.
  2. If the line is not configured to the correct speed, use the speed line configuration command to set the line speed on the access server or router line. Set the value to the highest speed in common between the modem and the access server or router port. To set the terminal baud rate, use the speed line configuration command. This command sets both the transmit (to terminal) and receive (from terminal) speeds. Syntax: speed bps Syntax Description: bps ?Baud rate in bits per second (bps). The default is 9600 bps. Example: The following example sets lines 1 and 2 on a Cisco 2509 access server to 115200 bps: line 1 2 speed 115200

    Note: If for some reason you cannot use flow control, limit the line speed to 9600 bps. Faster speeds are likely to result in lost data.

  3. Use the show line exec command again and confirm that the line speed is set to the desired value.
  4. When you are certain that the access server or router line is configured for the desired speed, initiate a reverse telnet session to the modem via that line. For more information, refer to Configuring Reverse Telnet.
  5. Use a modem command string that includes the lock DTE speed command for your modem. See your modem documentation for exact configuration command syntax.

Note: The lock DTE speed command, which might also be referred to as port rate adjust or buffered mode, is often related to the way in which the modem handles error correction. This command varies widely from one modem to another.

Locking the modem speed ensures that the modem always communicates with the Cisco access server or router at the speed configured on the Cisco auxiliary port. If this command is not used, the modem reverts to the speed of the data link (the telephone line) instead of communicating at the speed configured on the access server.

Table 6: Dialup Sessions See "Garbage"

Possible Causes Suggested Actions
Modem speed setting is not locked
  1. Use the show line exec command on the access server or router. The output for the auxiliary port should indicate the currently configured Tx and Rx speeds. For an explanation of the output of the show line command, see the Using Debug Commands section in chapter 15.
  2. If the line is not configured to the correct speed, use the speed line configuration command to set the line speed on the access server or router line. Set the value to the highest speed in common between the modem and the access server or router port. To set the terminal baud rate, use the speed line configuration command. This command sets both the transmit (to terminal) and receive (from terminal) speeds. Syntax: speed bps Syntax Description: bps ?Baud rate in bits per second (bps). The default is 9600 bps. Example: The following example sets lines 1 and 2 on a Cisco 2509 access server to 115200 bps: line 1 2 speed 115200

    Note: If for some reason you cannot use flow control, limit the line speed to 9600 bps. Faster speeds are likely to result in lost data.

  3. Use the show line exec command again and confirm that the line speed is set to the desired value.
  4. When you are certain that the access server or router line is configured for the desired speed, initiate a reverse telnet session to the modem via that line. For more information, refer to Configuring Reverse Telnet.
  5. Use a modem command string that includes the lock DTE speed command for your modem. See your modem documentation for exact configuration command syntax.

Note: The lock DTE speed command, which might also be referred to as is port rate adjust or buffered mode , often related to the way in which the modem handles error correction. This command varies widely from one modem to another.

Locking the modem speed ensures that the modem always communicates with the Cisco access server or router at the speed configured on the Cisco auxiliary port. If this command is not used, the modem reverts to the speed of the data link (the telephone line) instead of communicating at the speed configured on the access server.

Symptom: Remote dialin session opens up in an already-existing session initiated by another user. That is, instead of getting a login prompt, a dialin user sees a session established by another user (which might be a UNIX command prompt, a text editor session, or any other ongoing exchange).

Table 7: Dialup Session Opens in Existing Session

Possible Causes Suggested Actions
Modem configured for DCD always high
  1. The modem should be reconfigured to have DCD high only on CD. This is usually accomplished by using the &C1 modem command string, but check your modem documentation for the exact syntax for your modem.
  2. You might have to configure the access server line to which the modem is connected with the no exec line configuration command. Clear the line with the clear line privileged exec command, initiate a reverse telnet session with the modem, and reconfigure the modem so that DCD is high only on CD.
  3. End the telnet session by entering disconnect, and reconfigure the access server line with the exec line configuration command.
Modem control is not enabled on the access server or router
  1. Use the show line exec command on the access server or router. The output for the auxiliary port should be show inout or RIisCD in the Modem column. This indicates that modem control is enabled on the line of the access server or router. For an explanation of the show line output, refer to Using Debug Commands.
  2. Configure the line for modem control using the modem inout line configuration command. Modem control is now enabled on the access server.

Note: Be certain to use the modem inout command instead of the modem ri-is-cd command while the connectivity of the modem is in question. The latter command allows the line to accept incoming calls only. Outgoing calls will be refused, making it impossible to establish a telnet session with the modem to configure it. If you want to enable the modem ri-is-cd command, do so only after you are certain the modem is functioning correctly.

Incorrect cabling
  1. Check the cabling between the modem and the access server or router. Confirm that the modem is connected to the auxiliary port on the access server or router with a rolled RJ-45 cable and an MMOD DB-25 adapter. This cabling configuration is recommended and supported by Cisco for RJ-45 ports. These connectors are typically labeled: Modem. There are two types of RJ-45 cabling: straight and rolled. If you hold the two ends of an RJ-45 cable side-by-side, you'll see eight colored strips, or pins, at each end. If the order of the colored pins is the same at each end, the cable is straight. If the order of the colors is reversed at each end, the cable is rolled. The rolled cable (CAB-500RJ) is standard with Cisco's 2500/CS500.
  2. Use the show line exec command to verify that the cabling is correct. See the explanation of the show line command output in Using Debug Commands.

Table 8: Dialup Receiving Modem Does Not Disconnect Properly

Possible Causes Suggested Actions
Modem is not sensing DTR Enter the Hangup DTR modem command string. This command tells the modem to drop carrier when the DTR signal is no longer being received. On a Hayes-compatible modem the &D3 string is commonly used to configure Hangup DTR on the modem. For the exact syntax of this command, see the documentation for your modem.
Modem control is not enabled on the router or access server
  1. Use the show line exec command on the access server or router. The output for the auxiliary port should show inout or RIisCD in the Modem column. This indicates that modem control is enabled on the line of the access server or router. For an explanation of the show line output, refer to Using Debug Commands.
  2. Configure the line for modem control using the modem inout line configuration command. Modem control is now enabled on the access server.

Note: Be certain to use the modem inout command instead of the modem dialin command while the connectivity of the modem is in question. The latter command allows the line to accept incoming calls only. Outgoing calls will be refused, making it impossible to establish a telnet session with the modem to configure it. If you want to enable the modem dialin command, do so only after you are certain the modem is functioning correctly.

Cause Code Fields

Table 9 lists the ISDN cause code fields that display in the following format within the debug commands:

i=0x y1 y2 z1 z2 [a1 a2]
Table 9: ISDN Cause Code Fields

Field Value Description
0x The values that follow are in hexadecimal.
y1 8--ITU-T standard coding.
y2 0--User 1--Private network serving local user 2--Public network serving local user 3--Transit network 4--Public network serving remote user 5--Private network serving remote user 7--International network A--Network beyond internetworking point
z1 Class (the more significant hexadecimal number) of cause value. Refer to the next table for detailed information about possible values.
z2 Value (the less significant hexadecimal number) of cause value. Refer to the next table for detailed information about possible values.
a1 (Optional) Diagnostic field that is always 8.
a2 (Optional) Diagnostic field that is one of the following values: 0--Unknown 1--Permanent 2--Transient

ISDN Cause Values

Table 10 lists descriptions of some of the most commonly-seen cause values of the cause information element - the third and fourth bytes of the cause code.

Table 10: ISDN Cause Values

Value Cause Description
81 Unallocated (unassigned) number The ISDN number was sent to the switch in the correct format; however, the number is not assigned to any destination equipment.
90 Normal call clearing Normal call clearing has occurred.
91 User busy The called system acknowledges the connection request but is unable to accept the call because all B channels are in use.
92 No user responding The connection cannot be completed because the destination does not respond to the call.
93 No answer from user (user alerted) The destination responds to the connection request but fails to complete the connection within the prescribed time. The problem is at the remote end of the connection.
95 Call rejected The destination is capable of accepting the call but rejected it for an unknown reason.
9C Invalid number format The connection could be not established because the destination address was presented in an unrecognizable format or because the destination address was incomplete.
9F Normal, unspecified Reports the occurrence of a normal event when no standard cause applies. No action required.
A2 No circuit/channel available The connection cannot be established because no appropriate channel is available to take the call.
A6 Network out of order The destination cannot be reached because the network is not functioning correctly, and the condition might last for an extended period of time. An immediate reconnect attempt will probably be unsuccessful.
AC Requested circuit/channel not available The remote equipment cannot provide the requested channel for an unknown reason. This might be a temporary problem.
B2 Requested facility not subscribed The remote equipment supports the requested supplementary service by subscription only. This is frequently a reference to long-distance service.
B9 Bearer capability not authorized The user requested a bearer capability that the network provides, but the user is not authorized to use it. This might be a subscription problem.
D8 Incompatible destination Indicates that an attempt was made to connect to non-ISDN equipment, such as an analog line.
E0 Mandatory information element is missing The receiving equipment received a message that did not include one of the mandatory information elements. This is usually due to a D-channel error. If this error occurs systematically, report it to your ISDN service provider.
E4 Invalid information element contents The remote equipment received a message that includes invalid information in the information element. This is usually due to a D-channel error.

For more complete information about ISDN codes and values, refer to the ISDN Switch Codes and Values chapter in the Cisco IOS Debug Command Reference for your version of IOS.

Related Information

Updated: Jul 09, 2007
Document ID: 14955