[ LiB ]Data Compression and Error Control Scenarios

Configuring the Modem (DCE)

In this portion of the chapter, you will learn about the tasks involved in configuring the modem:

Connecting to the Modem (DCE)

Asynchronous dial-up involves the use of analog modems to convert data into streams of information that can be carried over phone lines. These modems can be attached externally, as with the Cisco 2511 access server, or they can be integrated into the product, as with Cisco AS5200 series access servers. The line that connects the modem can be a physical asynchronous line (external modem) or a virtual line inside an integrated modem module (integrated modem).

In the following sections, you will learn to

Differentiating Between a Forward and Reverse Connection to a Modem

Cisco access servers support two types of connections to a modem: incoming asynchronous line (forward) and outgoing asynchronous line (reverse). A user who dials into an access server from a remote terminal through an asynchronous line makes a forward connection, and a user who connects through an access server to an attached modem to configure that modem makes a reverse connection, known as reverse Telnet.

A host can make reverse-Telnet protocol connections to devices attached to a Cisco access server. Different port numbers (20xx, 40xx, and 60xx) are used for different device types. This is because each type has its own unique data type and protocol negotiations. The remote host must specify a particular TCP port on the router to connect with individual lines or a rotary group. For example, the remote host might make a reverse-Telnet connection to the modem using port 2097. The TCP port number 2097 specifies a Telnet connection (TCP port 2000) to line 97.

For the Telnet protocol, the base TCP port for individual lines is 2000, and the base TCP port for rotary groups is 3000. If the service provided is the raw TCP protocol (no Telnet), the base TCP port for individual lines is 4000, and the base TCP port for rotary groups is 5000. Telnet protocol (binary mode) uses 6000 as the base TCP port for individual lines and 7000 as the base TCP port for rotary groups. The Xremote protocol uses 9000 as the base TCP port for individual lines and 10000 as the base TCP port for rotary groups.

You need to use the transport input command to specify which protocol to use when connecting to a line using reverse Telnet:




Router(config-line)#transport input {all | lat | mop | nasi | none | pad |
  rlogin | telnet | v120}

For example, if you enter the command transport input all, all possible command option protocols can be used for the connection. The command options are lat | mop | nasi | none | pad | rlogin | telnet | v120. Each command option protocol can also be specified individually.

Configuring a Reverse-Telnet Session

The EXEC commands described in this section allow you to initiate and control a reverse-Telnet session. You use the telnet command to make a Telnet connection to a host or to a particular port on a host:




Router#telnet [host] [port] [/debug]

You can specify the target host either by host name or by IP address. You can use the optional debug switch to obtain more-detailed information about the connection. If you simply enter the name of the host to which you want to make a connection, the system tries to establish a Telnet session with that host by default. The interface through which the connection is made provides the source IP address for the connection.

You use the disconnect command to cut off a particular session or all sessions:




Router#disconnect [session-number]

Also, you can put the current session on hold by pressing Ctrl-Shift-6 followed by x.

Configuring Line Types

Access servers use four different line types:

A connection to a specific access server line is valuable when that line has a dial-out modem, parallel printer, or serial printer attached to it. To establish a connection to such a line, the remote host or terminal should specify a particular TCP port on the access server. For example, if you were to make a Telnet connection to line 97 (2000 + 97), you would need to enter telnet ip-address 2097.

The show line command displays status information on all line types:




Router#show line [line-number]

If you want more-detailed information on a particular line (such as baud rate, modem state, and modem hardware state), you need to specify the line-number when issuing this command.

Example 3-1 shows the output from the show line command. The absolute line numbers are displayed in the Tty column. The next column (Typ) shows the type of line assigned to each line numberCTY, TTY, AUX, vty, or LPT. The line speed associated with each line is shown in the Tx/Rx column. For example, the AUX line can transmit and receive at 9600 bps. The line's autoselect state is shown in the column labeled A. A value of F indicates that autobaud has been configured for the line, and a hyphen indicates that it has not.

Example 3-1. show line Command Output
Router#show line
Tty Typ      Tx/Rx      A Modem  Roty AccO AccI   Uses   Noise  Overruns   Int
*    0 CTY              -    -      -    -    -      0       0     0/0       -
    65 AUX   9600/9600  -    -      -    -    -      0       1     0/0       -
    66 vty              -    -      -    -    -      0       0     0/0       -
    67 vty              -    -      -    -    -      0       0     0/0       -
    68 vty              -    -      -    -    -      0       0     0/0       -
    69 vty              -    -      -    -    -      0       0     0/0       -
    70 vty              -    -      -    -    -      0       0     0/0       -

The type of modem signal configured for the line can be callin, callout, cts-req, DTR-Act, inout, or RIisCD. The Roty column indicates the rotary group configured for the line. If an output or input access list is configured for the line, it is shown in the AccO and AccI columns, respectively. The Uses column shows the number of TCP connections established to or from a line since the system was restarted. The system also reports on the number of times noise has been detected on each line since the last restart. The Overruns column indicates the number of hardware (UART) overruns and software overflows that have occurred on each line since the last system restart. Hardware overruns are buffer overrunsthey occur when the UART chip receives bits from the software faster than it can process them. Conversely, software overflows occur when the software receives bits from the hardware faster than it can process them.

Basic Modem Configuration

This portion of the configuration section introduces you to some of the beginning stages of modem configuration:

Configuring an Interface

The interface async command and the line command are used to configure an asynchronous port. The interface async command lets you configure the protocol or logical aspects of the asynchronous port. The line command lets you configure the physical aspects of the same port. You use the interface async command to configure internal characteristics, such as protocol encapsulation and authentication schemes. But you use the line command to configure external characteristics such as the basic modem-related parameters on an access server.

To make a successful asynchronous connection, you need to configure both the modem and the access server. You need to have the modem

You should also have the Carrier Detect (CD) signal accurately reflect the carrier state.

On the access server, you need to configure the line to which the modem is attached. You begin by using the line command to specify the particular line being configured:




Router(config)#line [aux | console | tty | vty] line-number [ending-line-number]

You use the login command to set a login password on the line. This prevents unauthorized connection on the line:




Router(config-line)#login

You specify the password using the password command:




Router(config-line)#password string

You configure flow control on the line using the flowcontrol command:




Router(config-line)#flowcontrol {none | software [lock] [in | out] | hardware
  [in | out]}

Because software flow control (xon and xoff characters) is not recommended for modems used with Cisco routers, use this command to specify that Request to send (RTS) and Clear to send (CTS) signals will be used to control the flow of data on the line by setting flowcontrol hardware.

Getting the modem to lock DTE speed ensures that the modem will always communicate with the access server at the specified speed. You use the speed command to set both the transmit and receive speed:




Router(config-line)#speed bps

The speed command lets you set the maximum transmit and receive speed between the modem and the access server. The chosen speed value needs to be expressed in bps.

You use the transport input all command if you want every protocol to be passed to the access server through the line.

The stopbits command allows you to set the number of stop bits transmitted per byte:




Router(config-line)#stopbits {1 | 1.5 | 2}

You use the modem command to configure the type of modem signal for the line:




Router(config-line)#modem inout

If you specify a value of inout, the line uses the modem for both incoming and outgoing calls.

Standard Modem AT Commands

Modem vendors all have their own unique set of modem commands. However, several modem attention (AT) commands are common to most of them. The AT command syntax is ATargument. The modem command prefix "AT" may be in uppercase or lowercase, but not mixed case. Any characters that follow the "AT" are treated as commands, and any characters preceding it are ignored.

The standard command for loading factory default settings is AT&Fargument. The factory default settings are read-only. The argument can have a value of 0, 1, or 2, where 1 is the default.

S-registers are low-level modem service registers. You can modify modem behavior by setting numeric values in various modem control registers. The S0 (answer on ring) command, for instance, sets the modem to answer a call on a particular ring when it is in auto-answer mode. Its command syntax is ATS0=argument. The command ATS0=1 sets a modem to automatically answer all incoming calls on the first ring.

For lines configured with caller ID, automatic answering on the second ring is recommended. You use the command AT&C1 to get the CD signal to accurately reflect line state. Its command syntax is AT&Cargument. Specifying 1 (the default value) as the argument causes the modem to send the CD signal when it connects with another modem and to drop the signal when it disconnects.

The command AT&D controls the Data Terminal Ready (DTR) signal from the DTE to the modem. Its command syntax is AT&Dargument. The standard command for getting the modem to hang up at DTR low is AT&D3.

The characters +++ are used to put a modem in command mode. If you issue this command at the near-end modem, it is transmitted to the far-end modem. If the far-end modem tries to interpret it, this might cause the connection to hang. You can overcome this common bug by entering the ATS2=255 or ATS2=128 commands at the far-end modem. The function of the S2 (escape code character) command is to store the ASCII decimal code for the escape code character. Its command syntax is ATS2=argument.

You can get a modem not to echo keystrokes to DTE in command mode by using the command ATE0. You can turn echo back on by entering RATE or RATE1 (1 is the default value).

The ATM(speaker) command is used to control a modem's speaker. Its command syntax is ATMargument. The default argument is 1, which means that the speaker is on during dial-string execution and remains on until a carrier is detected or the modem goes on hook. The standard command for turning off external audio output from the modem is ATM0.

The ATZ command returns the Cisco modem user interface to its default state and re-executes the initialization string. ATZ99 returns to the standard Cisco IOS software user interface (EXEC) mode.

Nonstandard Modem Commands

In addition to standard modem commands, a number of nonstandard commands are essential for modems attached to Cisco routers. Let's take a look at some of these commands and how they are used by three prominent modem vendorsMicrocom, Hayes, and U.S. Robotics (USR).

Any modem attached directly to a Cisco router needs to be configured for hardware flow control. USR modems use the command AT&H1&R2, where &H1 (transmit flow control) enables hardware flow control (CTS) and &R2 (receive hardware flow control) instructs the modem to send data to the DTE only if RTS is asserted. The AT\Q3 and AT&K3 commands are used to set hardware flow control on Microcom and Hayes modems, respectively.

The modem's serial port needs to be set to a fixed data-transfer rate. This means locking the DTE speed to prevent it from being negotiated down during the initial call setup. You use the DTE data rate command AT&B1 to lock the DTE speed on a USR modem. Specifying 1 as the command argument sets the DTE interface to follow the DTE data rate, regardless of the DCE connection rate. Microcom and Hayes lock the DTE speed using AT\J0 and AT&Q6, respectively.

You need to set the type of error control used on the modem. For a USR modem, you use the command AT&M4 to configure automatic selection between V.42, MNP error control, and a non-error-controlled data link. In this case, 4 is the default argument. When no error control is selected, an MNP or V.42 link request is ignored. The equivalent Microcom and Hayes commands are AT\N6 and AT&Q5, respectively.

You need to ensure that the best compression algorithm negotiated between two communicating modems is used. For a USR modem, you use the command AT&K1 to configure automatic selection/deselection of Microcom Networking Protocol (MNP) level 5 or V.42bis data compression. This assumes that an MNP or a Link Access Procedure for Modem (LAPM) link has been established. Data compression is enabled only if the DTE data rate is higher than the link rate and the remote DCE supports either the MNP level 5 option in the MNP link request or V.42bis in the LAPM link request. The compression commands used by Microcom and Hayes are AT%C1 and AT%Q9, respectively.

Show configuration commands allow you to display current modem settings. The USR modem inquiry command ATI4 gets the modem to send one screen of data to the DTE. The display indicates the settings for DTE band rate, parity, word length, S-register values, dial type, AT commands, and so on. AT/S1 and AT&V are the equivalent commands on Microcom and Hayes modems, respectively.

You need to be able to save any changes to the modem's configuration to its own nonvolatile RAM (NVRAM). Microcom, Hayes, and USR all use the command AT&W to achieve this.

You can use a modem's Help command to display all the AT commands for that modem. Microcom and Hayes both use AT$H, whereas USR uses AT$.

Initialization strings are used to send commands to modems before they dial out. No strings are required when you dial into a modem.

Configuring Chat Scripts

Asynchronous modems are not standard. This means that for optimal configuration, you must write custom chat scripts to perform certain tasks. A chat script is a string of text. It defines the handshaking that occurs between two DTE devices or between a DTE and its directly attached DCE (for example, an access server and a modem).

Here is the syntax for the chat-script command:




Router(config)#chat-script script-name expect-string send-string

A chat script consists of expect-send pairs that define the string that the local system expects to see from the remote device and the reply that the local system should send.

Example 3-2 demonstrates a chat script. The chat script name is defined as dial. The expect-send pair ABORT ERROR stops the chat script if an error occurs. The expect-send pair " " "ATZ" sends the AT command to the modem to reset it using the stored profile. The empty expect string means that this task is performed without expecting an input string. OK "ATDT \T" specifies that when the input string OK is received, the AT command is sent to instruct the modem to dial the telephone number in dialer-string or the start-chat command. The chat script specifies that the access server will wait up to 30 seconds for the input string CONNECT. The argument \c indicates the end of the chat script.

Example 3-2. Chat Script
Router(config)#chat-script dial ABORT ERROR ABORT BUSY "" "ATZ" OK "ATDT \T"
  TIMEOUT 30 CONNECT \c

Chat scripts generally perform tasks such as

The start-chat command allows you to manually start a chat script on any asynchronous line that is not currently active. The command syntax is




Router#start-chat regexp [line-number [dialer-string]]

You can configure chat scripts so that they are executed automatically for specific events. For example, a chat script configured for line activation is triggered by incoming traffic (CD going high).

In addition to line activation, other events commonly trigger the execution of a chat script:

Modem Autoconfiguration

The Cisco IOS software provides a modem autoconfiguration feature that facilitates the configuration of modems on access servers. With the autoconfiguration feature, you can configure modems without having to resort to modem configuration commands. You can use the asynchronous interface to autodiscover the type of modem on the line and to use that modem configuration. You can configure non-Cisco-supported modems by specifying modem information in the modem-autoconfiguration chat scripts.

Using the autoconfiguration feature requires you to manage the modem capability (modemcap) database. This consists of a list of AT configuration commands for setting each modem type's attributes. Modemcap exists as a file in the Cisco IOS software.

With automatic modem configuration, a chat script is executed each time a modem is reset. This sends a string of modem-configuration commands to the modem. The command string is generated automatically whenever the modem is recycled. For example, if you were using an AppleTalk Remote Access Protocol (ARAP) dial-in modem configured with flow control, it would receive a string that included commands to

To set up autoconfiguration on a modem, you need to

No other setup function is required for most modem configurations.

With automatic modem configuration, modems are configured to match current line settings. This means that the line configuration may be changed if the speed for the modem DTE differs from the current configuration on the line. You should, whenever possible, configure a line to expect a specific modem type. If none is specified, the access server tries to autodiscover the modem type. It does this by sending AT commands to the modem and then evaluating the response using the information in the modemcap database.

The access server's modemcap database has entries for several different modems. The actual entries in any particular modemcap database depend on the hardware and Cisco IOS version. If a particular modem is not currently supported, you can manually add it to the modemcap database so that it will be autodiscovered in future communication.

Modem Autoconfiguration Methods

There are two ways to configure modem autoconfiguration. You can configure modem autodiscovery, or you can specify a particular modem type to be used on the line. You also need to manage the modemcap database.

To configure modem autodiscovery, you use the following command:




Router(config-line)#modem autoconfigure discovery

Example 3-3 shows modem autodiscovery being configured on lines 1 through 16. The modem autoconfigure discovery command instructs the access server to send the AT string at various baud rates until successful reception is confirmed. This command also tells the access server to send a variety of AT commands in an effort to fully identify the modem from the entries in the access server's modemcap database.

Example 3-3. Configuring Modem Autodiscovery
Router(config)#line 1 16
Router(config-line)#modem autoconfigure discovery

The access server then builds the configuration string based on the discovered modem type and sends it to the modem. If the access server cannot identify the modem type, the default modem entry in the modemcap is used to build the configuration string.

If you know that the modem can be configured using one of the initialization strings in the modemcap database, you should use the following command to specify that modem type:




Router(config-line)#modem autoconfigure type modem-type

Because of the overhead and the possibility of configuration ambiguities associated with modem autodiscovery, you should configure the modem type whenever possible. This means that whenever the line resets, it automatically sends the correct initialization command string to the modem.

If none of the strings in the modemcap database properly initializes the modem, you need to configure the modem manually. Alternatively, you can change the modemcap database.

Configuring the Modemcap Database

Let's take a closer look at the modemcap database. Modem attributes have a full name and a two-or three-letter abbreviation. For example, factory defaults are abbreviated as FD. You should be familiar with these abbreviations for efficient management of the modemcap database.

One of the basic tasks in managing the modemcap database is viewing the modem entries in the modemcap file. You can do this using the show modemcap command. To display the modemcap entry for a particular modem type, you need to include the modem type as an argument to the show modemcap command. Example 3-4 shows the modemcap entry for the Codex 3260.

Example 3-4. show modemcap modem-type Command Output
Router#show modemcap codex_3260
Modemcap values for codex_3260
Factory Defaults (FD): &F
Autoanswer (AA): S0=1
Carrier detect (CD): &C1
Drop with DTR (DTR): &D2
Hardware Flowcontrol (HFL): *FL3
Lock DTE speed (SPD): *SC1
Best Error Control (BER): *SM3
Best Compression (BCP): *DC1
No Error Control (NER): *SM1
No Compression (NCP): *DC0
No Echo (NEC): E0
No Result Codes (NRS): Q1
Software Flowcontrol (SFL): [not set]
Caller ID (CID): &S1
On-hook (ONH): H0
Off-hook (OFH): H1
Miscellaneous (MSC): [not set]
Template entry (TPL): default
Modem entry is built-in

The modemcap entry includes

The default modem type has modemcap values for a few of the most common attributes, such as factory defaults and autoanswer. It has no command strings for attributes that vary widely with modem type, such as locking speeds, hardware flow control, compression, and error correction.

You can create a variant modemcap entry using the following command:




Router(config)#modemcap edit modem-name attribute at-command

This allows you to add a new modem to the modemcap database and add new attributes to an existing modem entry in the modemcap database.

Example 3-5 shows the creation of an entry for a new modem usr_new. The modemcap edit command creates the usr_new entry in the modemcap database and sets the new modem's caller ID to *U1. The second command locks the DTE speed on the usr_new modem. You can use the modemcap edit command to specify up to four layers of templates for the current modemcap entry. A template is another modemcap entry that the current entry points to. It's used to set any value not found in the current modemcap entry. In this example, usr_new points to the usr_courier modemcap entry as its template.

Example 3-5. Editing a Modemcap Entry
Router(config)#modemcap edit usr_new caller-id *U1
Router(config)#modemcap edit usr_new speed &B1
Router(config)#modemcap edit usr_new template usr_courier

The show modemcap command allows you to verify the access server's new modemcap entry. You can verify the new attribute values for a modemcap entry by specifying the modem name as an argument to the show modemcap command. The display for usr_new would be identical to that for usr_courier, except for the lock DTE speed, caller ID, and template attributes. You can also use the show running-config command to verify the attribute settings for a new modemcap entry.

You can remove a modem from the modemcap database by specifying its name as the only argument to the no modemcap edit command. If you specify the modem name and an attribute as arguments, the command removes only that modem attribute from the modem's modemcap entry.

Troubleshooting Modem Autoconfiguration

Here are some commands you can use to verify and debug modem autoconfiguration:

Let's look at some common problems associated with modem autoconfiguration and discuss how you might troubleshoot them. If a modem fails to respond, you should first check that it's plugged in and turned on. You should check whether the power-up configuration is set to load factory defaults. You should determine whether you can connect to the modem through reverse Telnet. It's important to check that there is a dial tone at the phone jack. Also, sometimes the modem could have hung up. This fact can be verified by entering the show line command. If an * appears next to the line, issue the clear line n command to reset it.

If a modem is not recognized by modem autoconfigure discovery, you need to check what modem configuration the line is using. You can do this using the show line command. You should establish whether the Cisco access server recognizes the modem. You can overcome modem autodiscovery problems by using the modem autoconfigure type command to specify a particular modem type.

Modem autoconfiguration might fail because of a problem with an original modemcap entry. If you have configured your own modemcap entry and reconfiguration appears to function, you should verify that the DTR attribute is not set to &D3. The manual that accompanies your modem contains information that can be invaluable when troubleshooting any problems.

[ LiB ]Data Compression and Error Control Scenarios