This is a normal autoselect sequence with inbound PPP LCP packets:

Note 1: The inbound traffic is displayed in hexadecimal format, 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 debug ppp negotiation to see whether any configuration request packets (the debugs will show them as CONFREQ) are coming from the remote end. If PPP packets are seen to be both inbound and outbound, proceed to the section "PPP Debugging." Otherwise, connect in from the call-originating end with a character-mode (or "exec") session (that is, a non-PPP session).

Note If the receiving end has the setting async modem dedicated under the async interface, an exec dial-in will see nothing but 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

If the modems connect with a terminal session and no data comes across, check the causes shown in Table 17-
Table 17-1: Modem Cannot Send or Receive Data

Possible Causes	Suggested Actions
Modem speed setting is not locked	1. Use the 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.
Modem speed setting is not locked (continued)	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 you cannot use flow control for some reason, limit the line speed to 9600 bps. Faster speeds likely will 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, see the section "Establishing a Reverse Telnet Session to a Modem," in Chapter 16. 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 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 is not configured on the local or remote modem or router	1. Use the Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out 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, see the section "Using debug Commands," earlier in this chapter. 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. 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.
Hardware flow control is not configured on the local or remote modem or router (continued)	Example: The following example sets hardware flow control on line 7: line 7 flowcontrol hardware Note: If you cannot use flow control for some reason, limit the line speed to 9600 bps. Faster speeds likely will 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, see the section "Establishing a Reverse Telnet Session to a Modem." 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.
dialer map commands are misconfigured	1. Use the 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, IPX1, 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 host name of the remote router. broadcast—An optional keyword that broadcast packets (such as IP RIP or IPX RIP/SAP updates) to be forwarded to the remote destination. In static routing sample configurations, routing updates are not desired and the broadcast keyword is omitted.
dialer map commands are misconfigured (continued)	dial-string—The remote site's phone number. Any access codes (for example, 9 to get out of an office; international dialing codes; and area codes) must be included. 3. Make sure that 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 that all other options in dialer map commands are correctly specified for the protocol that 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.
A problem has occurred with the dialing modem	Make sure that the dialing modem is operational and is securely connected to the correct port. See whether another modem works when connected to the same port.

1.

Debugging an incoming exec session generally falls into a few main categories. Possible causes and suggested actions can be found in Tables 17-2 through 17-5.

• Dialup client receives no exec prompt

• Dialup session sees "garbage"

• Dialup session ends up in an existing session

• Dialup receiving modem does not disconnect properly
  Table 17-2: Dialup Client Receives No exec Prompt

  Possible Causes	Suggested Actions
  Autoselect is enabled on the line	Attempt to access exec mode by issuing a carriage return.
  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 include "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, is enabled only on one device (either DTE or DCE), or is misconfigured	1. Use the Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out 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. 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 you cannot use flow control for some reason, limit the line speed to 9600 bps. Faster speeds likely will 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, see the section "Establishing a Reverse Telnet Session to a Modem," earlier in this chapter. 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. Figure 16-1 shows the hardware flow control command string for a Hayes-compatible modem.
  Modem speed setting is not locked	1. Use the For an explanation of the output of the show line command, see the section "Using debug Commands," earlier in this chapter. 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.
  Modem speed setting is not locked (continued)	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 you cannot use flow control for some reason, limit the line speed to 9600 bps. Faster speeds likely will 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, see the section "Establishing a Reverse Telnet Session to a Modem," earlier in this chapter. 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 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 17-3: Dialup Sessions Sees "Garbage"

  Possible Causes	Suggested Actions
  Modem speed setting is not locked	1. Use the 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 you cannot use flow control for some reason, limit the line speed to 9600 bps. Faster speeds likely will 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, see the section "Establishing a Reverse Telnet Session to a Modem," earlier in this chapter. 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 buffered mode, is often related to the way in which the modem handles error correction. This command varies widely from one modem to another.
  Modem speed setting is not locked (continued)	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 dial-in session ends up in an already existing session initiated by another user. That is, instead of getting a login prompt, a dial-in user sees a session established by another user (which might be a UNIX command prompt, a text editor session, and so forth).
Table 17-4: Dialup Session Ends Up in Existing Session

Possible Causes	Suggested Actions
Modem configured for DCD is 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 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 exec line configuration command.
Modem control is not enabled on the access server or router	1. Use the 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
Cabling is incorrect	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.") Two types of RJ-45 cabling are commonly encountered when connecting a modem: 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, then the cable is straight. If the order of the colors is reversed at each end, then 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.

Table 17-5: 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 the 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. 2. Configure the line for modem control using the modem inout line configuration command. Modem control is now enabled on the access server.
Modem control is not enabled on the router or access server (continued)	Note: Be certain to use the modem inout command instead of the

The troubleshooting approach for incoming calls starts at the bottom, but troubleshooting an outbound connection starts at the top. Outbound connection troubleshooting goes along these lines (a "yes" answer to the question gets to the next question):

• Does dial-on-demand routing initiate a call?

• If this is an async modem, do the chat scripts issue the expected commands?

• Does the call make it out to the PSTN?

• Does the remote end answer the call?

• Does the call complete?

• Is data passing over the link?

• Is the session established? (PPP or terminal)

To see whether the dialer is trying to make a call to its remote destination, use the command debug dialer events. More detailed information can be gained from debug dialer packet, but the debug dialer packet command is resource-intensive and should not be used on a busy system that has multiple dialer interfaces operating.

The following line of debug dialer events output for an IP packet lists the name of the DDR interface and the source and destination addresses of the packet:

If this does not occur, the most common reason is improper configuration, either of the interesting traffic definitions, the state of the dialer interface, or the routing (Table 17-6).
Table 17-6: Traffic Does Not Initiate a Dial Attempt

Possible Causes	Suggested Actions
Missing or incorrect "interesting traffic" definitions	1. Using the command show running-config, ensure that the interface is configured with a dialer group and that there is a global level dialer list configured with a matching number. 2. Ensure that the dialer-list command is configured to permit either an entire protocol or to permit traffic matching an access list. 3. Verify that the access list declares packets going across the link to be interesting. One useful test is to use the privileged exec command debug ip packet [list number] using the number of the pertinent access list, and then attempt to ping or otherwise send traffic across the link. If the interesting traffic filters have been properly defined, you will see the packets in the debug output. If there is no debug output from this test, then the access list is not matching the packets.
Interface state	Using the command
Interface in "standby" mode	Another (primary) interface on the router has been configured to use the dialer interface as a backup interface. Furthermore, the primary interface is not in a state of "down/down," which is required to bring the dialer interface out of standby mode. Also, a backup delay must be configured on the primary interface, or the backup interface command will never be enforced. To check that the dialer interface will change from standby to up/up (spoofing), it is usually necessary to pull the cable from the primary interface. Simply shutting down the primary interface with the configuration command shutdown will not put the primary interface into down/down, but instead will put it into administratively down, which is not the same thing. In addition, if the primary connection is via Frame Relay, the Frame Relay configuration must be done on a point-to-point serial subinterface, and the telco must be passing the "active" bit, a practice also known as "end-to-end LMI."
Interface that is "administratively down"	The dialer interface has been configured with the command no shutdown to remove this impediment.
Incorrect routing	Issue the exec command ip unnumbered is used on the remote router, use the address of the interface listed in the ip unnumbered command.) The output should show a route to the remote address via the dialer interface. If there is no route, ensure that static or floating static routes have been configured by examining the output of show running-config. If there is a route via an interface other than the dialer interface, the implication is that DDR is being used as a backup. Examine the router configuration to make sure that static or floating static routes have been configured. The surest way to test the routing in this case is to disable the primary connection and then execute the show ip route [a.b.c.d] command to verify that the proper route has been installed in the routing table. Note: If you attempt this during live network operations, a dial event may be triggered. This sort of testing is best accomplished during scheduled maintenance cycles.

If the routing and the interesting traffic filters are correct, a call should be initiated. This can be seen by using debug dialer events:

If the dialing cause is seen but no attempt is made to dial, the usual reason is a misconfigured dialer map or dialer profile (Table 17-7).
Table 17-7: Call Not Placed

Possible Problem	Suggested Actions
Misconfigured dialer map	Use the command show running-config to ensure that the dialing interface is configured with at least one dialer map statement that points to the protocol address and called number of the remote site.
Misconfigured dialer profile	Use the command dialer pool X command and that a dialer interface on the router is configured with a matching dialer pool—member X. If dialer profiles are not properly configured, you may see a debug message such as "Dialer1: Can't place call, no dialer pool set." Make sure that a dialer string is configured.

If the outbound call is a modem call, a chat script must execute for the call to proceed. For dialer map-based DDR, the chat script is invoked by the script dialer, configured on the TTY line. Both uses rely on a chat script existing in the router's global configuration, such as this, for example:

In either event, the command to view the chat script activity is debug chat. If the dial string (such as phone number) used in the dialer map or dialer string command were 5551212, the debug output would look like this:

Chat script problems can be broken into three categories:

• Configuration error

• Modem failure

• Connection failure

Table 17-8 shows chat script failures and suggested actions.
Table 17-8: Chat Script Failure

Output from debug chat Shows:	Suggested Action
No matching chat script found for [number]	A chat script has not been configured. Add one.
Chat script dialout finished, status = Connection timed out; remote host not responding	The modem is not responding to the chat script. Verify communication with the modem (see Table 16-2 in Chapter 16).
Timeout expecting: CONNECT	Possibility 1: The local modem is not actually placing the call. Verify that the modem can place a call by using reverse Telnet to the modem and manually initiating a dial. Possibility 2: The remote modem is not answering. Test this by dialing the remote modem with an ordinary POTS telephone.
Timeout expecting: CONNECT (continued)	Possibility 3: The number being dialed is incorrect. Verify the number by dialing it manually, and correct the configuration, if necessary. Possibility 4: The modem trainup is taking too long or the TIMEOUT value is too low. If the local modem is external, turn up the modem speaker volume and listen to the trainup tones. If the trainup is abruptly cut off, try increasing the TIMEOUT value in the chat-script command. If the TIMEOUT is already 60 seconds or more, see the section "Modem Trainup," earlier in this chapter.

ISDN Outbound Calling

The first thing to check at the first suspicion of an ISDN failure, either on a BRI or a PRI, is the output from

PPP authentication failure is a typical reason. Turn on debug ppp authentication before assuming that the connection failure is necessarily an ISDN problem.

Table 17-9 lists the ISDN cause code display in the following format within the debug commands:

Table 17-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 17-10: ISDN Cause Values

Hex Value	Cause	Explanation
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 incapable of accepting 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 it rejected the call for an unknown reason.
9C	Invalid number format	The connection could not be established because the destination address was presented in an unrecognizable format or because the destination address was incomplete.
9F	Normal, unspecified	This reports the occurrence of a normal event when no standard cause applies. No action is 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	This indicates that an attempt was made to connect to non-ISDN equipment—for example, to an analog line.
E0	Mandatory information element missing	The receiving equipment received a message that did not include one of the mandatory information elements. This is usually the result of 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 the result of 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, in print or online at www.cisco.com/univercd/home/home.htm.

For outbound calling via CAS T1 or E1 and integrated digital modems, much of the troubleshooting is similar to other DDR troubleshooting. (The same holds true for outbound integrated modem calls over a PRI line.) The unique features involved in making a call in this manner require special debugging in the event of a call failure.

As for other DDR situations, you must ensure that a call attempt is demanded—debug dialer events is useful for this (see the section "Verifying Dialer Operation," earlier in this chapter).

Before a call can be placed, a modem must be allocated for the call. To view this process and the subsequent call use the following debug commands:

debug modem

debug modem csm

debug cas

Note: The modem-mgmt debug rbs: