Set Up Cisco 2511 Access Server

Purpose

To give network administrators an understanding how a modem pool works and to guide in setting up a dial-in modem pool using the Cisco 25xx Access and Communication Server. An access server is used to provide dial-up access to a local network and Internet Resources. This document is not intended to provide setup parameters for users accessing the server.

Overview of Modem <==> Access Server Communication

The end-to-end topology for a dial­in connection looks like:

The Cisco Access Server and client PC are called Data Terminal Equipment (DTE), and the access server and client modems are called Data Circuit­terminating Equipment (DCE). The Cisco Access Server uses three pairs of wires to connect the DCE to the DTE. In each pair, one wire transmits and the other receives. These pairs are TX/RX, RTS/CTS, and DTR/DCD. Each pair requires specific configuration on the DTE and DCE.

1.   TX/RX ­ Data Transfer

Transmit: DTE >­­­TX­­­> DCE

Receive: DTE <­­­RX­­­< DCE

Transmit and receive speed is set on the modem using the TX/RX wire pair. Notice that the DCE transmits on RX and receives on TX.  The speeds at which the two devices are communicating on the RS­232 must be the same. If they are not, you will get a speed mismatch, where either garbage or nothing appears on the screen when dialing in to the modem.

To set the port speed on the access server use the speed xxxxxx line configuration command. A complete example of setting up an access server line follows.

2. R  TS/CTS ­ Hardware Flow Control

Request to Send: DTE >­­­RTS­­­> DCE

Clear to Send: DTE <­­­CTS­­­< DCE

This pair of wires indicates the ability of a device to receive data. For example, when the DCE has a full data buffer and can no longer accept data from the DTE for transmitting, it will lower the CTS signal. When the access server can no longer accept data, it lowers the RTS signal. Both the access server and the modem must agree to hardware handshake with CTS/RTS. If they do not agree on handshaking, they will tend to overflow each other's buffers. Dropped characters or packet errors are typical signs of a handshaking mismatch. 

To set the access server async port to use CTS/RTS handshaking use the flowcontrol hardware command. An example of setting up an access server line folows.

Configuration commands vary from modem to modem. Look for "Hardware Handshaking" or "RTS/CTS Flow Control" in the modem manual.

3.   DTR/DCD ­ Modem Control Data Terminal Ready:

DTE >­­­DTR­­­> DCE

Data Carrier Detect: DTE <­­­DCD­­­< DCE

This pair of wires is used between the DTE and the DCE to initiate and receive calls. When the access server is ready, DTR output is high. The access server lowers DTR to drop any existing calls and return to the stored configuration. The modem uses DCD output to indicate that a call has arrived that needs servicing by the access server. The modem drops DCD to indicate loss of the call.

The access server and modem must agree on the function of DTR and DCD.

Back to Top

Prerequisites

Before setting up the Cisco 25xx Access Server you must have:

1. A dedicated connection to the MOREnet backbone or plans for installation
2. Assigned IP addresses
3. A facility capable of supporting power requirements for the access server and the modems attached to it
4. Knowledge of TCP/IP based applications, particularly telnet and a workstation for telnet access to the access server.

Equipment For Setting Up Modem Pool

These are step-by-step instructions for setting up the Cisco 2511 or 2512 Access Communications Server. Please be aware that your access server comes with full documentation of hardware and software setup configuration guides on Cisco's UniverCD CD-ROM.

Note: Completion of these steps may require some network downtime.

Unpack Your Access Communication Server

The following items are included with each device:

1	Cisco 2511 or 2512 Access Communication Server
1	v.35 Serial Cable
2	Octal cables kits with RJ45 plugs and 16 DB25 to RJ45 converter hoods
1	Rack/Wall mount kit
1	Console port attachment kit    1 DB25 to RJ45 Terminal (DTE) connector     1 DB25 to RJ45 Modem (DCE) connector     1 "rolled" UTP flat ribbon cable with RJ45 on each end
1	Power Cord
1	AUI-LAN Transceiver
1	UniverCD CD-ROM
	Unpack Your Modem 1 USR, MultiTech or SupraFax Modem
1	Power adapter

Back to Top

Hardware Setup

1. Unpack the contents and check to be sure all equipment is included. If anything is missing please contact MOREnet Network Operation Cener.

2. Attach the Octal Cables to the back of the access server. In most cases it is easier to attach these cables first. If your particular physical environment makes this impractical, simply complete each instruction in the best order for your situation.

3. Attach the thick green/blue v.35 Serial cable to the port labeled "Serial 0" on the back of the access server.

4. Attach the DB25 to RJ45 converter hoods to the back of each modem .

5. Place the access server and the modems wherever you wish, remember though, you may at some point have 16 modems attached, along with the v.35 cable attachment from the serial 0 interface on the access server to the CSU/DSU. The access server can be rack mounted, or placed on a table or shelf. Try to plan ahead. Eventually you will have to make the physical switch of the CSU/DSU from the present equipment, to the 2511.

6. Once the physical placement of the new equipment has been planned, if practical, attach the male RJ45 ends of the Octal cables to the RJ45 ports on the back of the modems. You may wish to do this after you swap out the old equipment and put in the new.

7. At this point you are ready to switch from your present equipment to the Cisco. Power off and unplug the Cisco 2501 or 2502 presently in use. When you do this, access to MOREnet and the Internet will be lost. 

8. Remove the v.35 Serial cable presently connected, from the back of the CSU/DSU. 

9. Disconnect the LAN connection (either the Ethernet transceiver or Token Ring DB9 connector).

10. Remove this equipment to make room for the new access server and modems. 

11. Attach your LAN connection to the back of the access server.

12. Attach the v.35 green/blue serial cable to the back of the CSU/DSU.

13. Plug in and power on the access server. In a few moments you should see your CSU/DSU return to a normal state.

14. Plug in and power on your modems.

Note:   Before connecting your modems to the PSTN (Public Switched Telephone Network) complete the remainder of the configuration process. You don't want anyone calling while you are doing this, and if the number has been made available, someone will call!

Back to Top

Configure Cisco's 2500 Series Access Server IOS

After completing the hardware setup, configure the Cisco Internet-work Operating System (IOS). This procedure is more fully documented in the Access and Communication Server Configuration Guide, and the Access and Communication Server Command Reference, available on the UniverCD -ROM. In this guide we will explore only a few of the many features available.

Access the Cisco 2500 Series Operating System

Your access server was shipped pre-configured to operate just as your previous 2501 or 2502 model did before it was disconnected. You can access the router either by attaching an ASCII terminal to the console port of the router, or from a workstation on your local LAN via telnet. Telnet is the preferred method because it is likely you will use this method almost exclusively to communicate with the access server. Therefore we will not cover console port access here.

1. From any workstation on your network open your favorite telnet program and enter the IPaddress of the access server. This can be the ethernet or serial address of your router.

2. At the prompt type in the password shown in the line vty 0 4 section of the printed configuration file shipped with your access server. It will not be echoed back to your screen.

Note:   For the remainder of this guide, bold constant width type indicates commands entered into the access server.

User Access Verification

Password:

MySchool>

The > sign at the end of the prompt indicates we are in EXEC mode.

The Cisco user interface is separated into a hierarchy of privilege levels. Each level provides access to a superset of commands that includes all commands from the previous level. In EXEC mode the configuration of the access server cannot be viewed or modified. We can, however, display who is using the access server:

MySchool>who

MySchool>who

Line     User      Host(s)           Idle Location

1 tty 1   charley   Async interface   0 

* 18 vty 1             idle              0 128.206.206.126

MySchool>

From this prompt we can issue many other commands including a "?" which will list all commands available at this prompt. All commands except the "?" must be followed by ENTER. Your router has been shipped with 3 command levels:

EXEC       (level 1) user mode or exec mode
ENABLE   (level 15) enable mode
CONFIG   Global configuration mode

Anyone with a valid user ID and password can use EXEC commands.

Only administrators should use the enable password to use ENABLE commands. This mode gives root access to the router.

CONFIG commands are used to edit your router’s configuration. This must be done from the enable mode:

MySchool>enable

Password:

MySchool#

Back to Top

Getting Around in Configuration Mode

Before attempting to modify any configuration parameters, it might be helpful to see the present set up. A distinction must be made between the running configuration and the configuration saved in nonvolatile RAM. When the access server is first powered up, it learns its expected behavior by reading the configuration file saved in non-volatile RAM. Once the access server has completed the boot process, you can modify the configuration.

Important:  Any changes you make to the running configuration take affect immediately, but they are not automatically saved in nonvolatile RAM. You must execute a write memory command to save your changes.

The following command displays the current operating configuration:

MySchool#show running­config

This command displays the configuration stored in non-volatile RAM:

MySchool#show startup­config

Just as there are multiple privilege command levels, Cisco's uner interface supports different types of configuration modes. For example, some commands are global in nature. That is, they affect the operation of the entire access server. Some commands may affect only a particular portion of the access server (for example, modem lines).

To enter global configuration mode:

MySchool#config terminal

Enter configuration commands, one per line.  End with CNTL/Z

MySchool(config)#

Configuration commands entered from this prompt apply to the access server as a whole. To do any configuration modifications you must first enter global configuration mode:

To enter line configuration mode:

MySchool(config)#line 1 3

MySchool(config­line)#

Configuration commands entered here affect lines 1 through 3. We could specify any one single line, or as we have done here, a range of lines.

To enter interface configuration mode:

MySchool(config)# interface Group-Async1

MySchool(config­if)#

Commands entered in interface configuration mode apply to interfaces. Here we have chosen the first (of 16) available asynchronous interfaces. 

Each port on the Cisco 2500 series Access Server (including the aux and console) is assigned a specific line number. 1 - 16 apply to the async modem ports. They may be referenced in a couple of ways:

The following command enters line configuration mode and any instructions here will apply to the first 3 modem lines:

MySchool#config terminal

Enter configuration commands, one per line.  End with CNTL/Z.

MySchool(config)#line 1 3

MySchool(config­line)#

The following command is equivalent:

Notice though the lines are referred to as tty lines. The issue here is to make a distinction between tty lines and vty lines. The term vty indicates we are applying commands to virtual terminal lines, which are created for incoming telnet sessions, not incoming calls.

MySchool#config terminal

Enter configuration commands, one per line.  End with CNTL/Z.

MySchool(config)#line tty 1 3

MySchool(config­line)#

The following command would apply to telnet connection lines:

It is unlikely you will encounter a need to configure vty lines. It is much more likely that you might want to clear a vty line if there is a hung session on it. In the following example, if you mistakenly put in tty 1 instead of vty 1, the user on line one will be disconnected:

MySchool#who    

Line     User       Host(s)                Idle Location

1 tty 0              services.more.net

    *   2 tty 1              idle                   3w1d 128.206.206.126

17 vty 0              idle                      0 128.206.206.126

MySchool#clear line tty 2

[confirm]

[OK]

MySchool#who    

Line     User       Host(s)                Idle Location

1 tty 1              services.more.net

17 vty 0              idle                      0 128.206.206.126

Back to Top

Other Commands You Need to Know

There is an additional section that shows examples of the most common commands you will need to use and the output from those commands where applicable. Any command can be shortened as long as it is unambiguous (for example, show configuration can be typed as sho conf, but not as sho con).

Specific Commands to Configure Your Modems

The following is a step-by-step example of configuring the access server and modems. The modems are configured using a reverse telnet that is explained later. Lines beginning with a "!" represent a comment, and can be used in the access server configuration file.

The following assumes that we will lock DTE speed, set hardware (RTS/CTS) flowcontrol, set carrier detect to reflect the actual carrier state, and set the modem to hang up on loss of DTR.

Note: 115200 is the maximum speed for the 25xx access servers, but 57600 is recommended.

Note: To "undo" or remove any configuration commands use the "no" form of the command. For example, to remove the flowcontrol hardware command use no flowcontrol hardware.

MySchool#config term

Enter configuration commands, one per line.  End with CNTL/Z.

MySchool(config)#line 1 3

MySchool(config­line)#speed 57600

MySchool(config­line)#modem inout

MySchool(config­line)#flowcontrol hardware

MySchool(config­line)#end

MySchool#

Back to Top

Basic Modem Configuration Tasks

This section covers configuring your modems. It would be impossible to account for every situation, but this section should be enough to get your modem pool active.

Security on your Modems

To configure the access server use modem inout or modem ri­is­cd (or modem dialin).

Turn Security off:  Use modem inout to allow incoming and outgoing connections to the modem. You will need modem inout while configuring the modem.

Turn Security on: Use modem ri­is­cd to allow incoming-only connections.
This is highly recommended unless you absolutely need to use the access server to dial out.

Cabling other than that recommended at the beginning of this section can cause modem control to fail since modem DCD may not be wired.

On the modem usually &C1 and &D2 control this function. This is often referred to as RS­232 standard operation.

Configure Your Modems

Now configure each attached modem using a reverse telnet connection. From the access server prompt initiate another telnet session using the command:

MySchool#telnet x.x.x.x 20yy

where:

x.x.x.x is your primary ethernet address of your router, or gateway
20yy       is the port number of your modem
MODEM 1 is PORT 2001
MODEM 2 is PORT 2002

Back to Top

Sample snap shot:

MySchool#telnet 204.184.26.254 2001 …. telnets you into a session with the modem.

AT     Attention modem
OK … tells you that you are in a terminal session with the modem.

Enter your modem initialization string now…

AT ... see the back modem string pages for your proper command

To exit the modem you must use the Cisco escape sequence: CTL+SHT 6 immediately followed by x. Then disconnect you session by issuing a clear line 1 (or the number of your modem you were just configuring).

MySchool>enable

password: ernie

MySchool#telnet 204.184.26.254 2001

************************************************

*      Welcome to our school’s modem pool       * 

* Enter your user ID and password as prompted. *

************************************************

AT

OK

AT&FS0=1&C1&D3&e1&E4&e15$BA0$SB115200&W0

OK

CTL SHT 6

x         … If this is unsuccessful, disconnect your telnet session.

MySchool#clear line 1

confirm(y)

MySchool#

disconnecting active connection

MySchool#

NOTE:  You can also use the disconnect command.

MySchool#disconnect

confirm(y)

MySchool#

disconnecting active connection

MySchool#

MySchool#telnet 204.184.26.254 2002

Do this for each of your modems

Back to Top

Specific Commands to Configure the Access Server Async Interfaces

Finally, in order to give users SLIP/PPP access, we need to configure what are referred to as Asynchronous interfaces. Each interface must provide an IP address for the remote user, and some environment settings for the remote workstation. Interfaces, regardless of their type, must be configured one at a time. We cannot specify a range of interfaces as we can with line configuration commands. There are many possibilities for configuration of async interfaces. This is the recommended configuration for allowing SLIP/PPP access to users. Each line is explained below. 

MySchool#conf term

Enter configuration commands, one per line.  End with CNTL/Z.

MySchool(config)# interface Group-Async1

MySchool(config­if)#ip unnumbered Ethernet0

MySchool(config­if)#ip tcp header­compression passive

MySchool(config­if)#async mode interactive

MySchool(config­if)#group-range 1 16

MySchool(config­if)#peer default ip address pool ModemsIP

MySchool(config­if)#ip local pool ModemsIP 204.185.54.127 204.185.54.142

MySchool(config­if)#end

MySchool#write memory

ip unnumbered Ethernet0 - Whenever the unnumbered interface generates a packet (for example, for a routing update), it uses the address of the specified interface as the source address of the IP packet. 

ip tcp header­compression passive - Header-compression will be determined by the calling workstation.

async mode interactive - Lets the user ask for an ip address using the slip command.

peer default ip address pool ModemsIP - This is the IP address pool that will be assigned to the calling workstation as a result of the slip default command. It should be an address from the pool of addresses assigned to your network.

Group-range 1 16 - This is the group of async lines you want this to apply to.

ip local pool ModemsIP x.x.x.x  x.x.x.y - This defines the group of IP addresses you will use for the async lines. This assigns the group of addresses to the name ModemsIP.

Back to Top

Configure User Authentication on the Access Server

At this point you are ready to configure the Cisco 25xx Access Server authentication scheme. Some of you will be using the access server itself to provide user authentication. Others might choose to use xtacacs or tacacs+. This section will discuss each of these methods of user authentication.

Authentication using the 25xx Access Server

User authentication on the 25xx is easy in most cases. Users and their passwords are entered in global configuration mode and unless there are special circumstances, can be entered quickly and easily. In some cases there might be circumstances where some additional parameters can be associated with a specific user. There are of course some drawbacks to using this method. Users cannot change their own passwords, each one must be changed by the sysadmin. It is impractical to do this with large numbers of users. It would be very difficult to manage such an environment. There is also very little accounting function available under this method. The access server is simply not designed to store this kind of information.

To configure user authentication on the access server, telnet to your 25xx, login and enter admin mode. The following command is used to add users and passwords to the configuration:

MySchool#conf term

Enter configuration commands, one per line.  End with CNTL/Z.

MySchool(config)#username bert password ernie

MySchool(config)#username charley password consulting

MySchool(config)#end

MySchool#sho run

Building configuration.

[text removed]

username bert password 7 104D080B11181D05

username charley password 7 011709035304131C24

[text removed]

Remove a User or Changing Their Password

If you need to remove a user or change their password you use the "no" version of the command.  Since the user's password is encrypted you will not be able to view the password.

Remove the user and add them back in as a new user with a new password. 

MySchool#conf term

Enter configuration commands, one per line.  End with CNTL/Z.

MySchool(config)#no username bert

MySchool(config)#username bert password ernie2

MySchool(config)#end

MySchool#sho run

Building configuration.

The passwords are encrypted when displayed. The 7 indicates the encryption method and in this case is Cisco's proprietary encryption method. The only supported encryption methods are 0 for clear text (not recommended) and 7, the Cisco method.

In addition to simply assigning a username and password, this command can also associate an autocommand or an access-list with a specfic user. For example:

MySchool(config)#username bert password ernie

autocommand telnet x.x.x.x

In this case bert would automatically be telnetted to host x.x.x.x when he logged in to the access server.

Back to Top

TACACS/XTACACS

TACACS (Terminal Access Controller Access Control System) and originally was developed for the Department of Defense. XTACACS (extended TACACS), provides password checking, authentication and notification of user actions for security and accounting purposes, information about protocol translator and communication server use. This information is used in UNIX auditing trails and accounting files. Standard TACACS is rarely used any longer and we will focus only on XTACACS and TACACS+. What follows is a standard XTACACS configuration.

MySchool#conf term

Enter configuration commands, one per line.  End with CNTL/Z.

MySchool(config)#tacacs­server host x.x.x.x

MySchool(config)#tacacs­server extended

MySchool(config)#tacacs­server notify connections

MySchool(config)#tacacs­server notify enable

MySchool(config)#tacacs­server notify logout

MySchool(config)#tacacs­server notify slip

MySchool(config)#end

MySchool#

tacacs­server host x.x.x.x - specify the ip address of the machine running the tacacs server. Multiple TACACS servers can be specified simply by duplicating the command for each server host machine.

tacacs­server extended - use the extended TACACS command set

tacacs­server notify connections - send notification to the TACACS server of a connection attempt to another host

tacacs­server notify enable - send notification to the TACACS server that a user has entered enable mode

tacacs­server notify logout - send notification to the TACACS server that a user has logged out

tacacs­server notify slip - send notification to the TACACS server that a user has requested a SLIP connection.

Each of these commands is fully documented in the Access and Communications Server Command Reference available on the UniverCD cd-rom.

As you are aware by now, in order for TACACS to function, there must be a TACACS daemon running on a host somewhere on your network. At the time of this writing there are four platforms for running XTACACS; Unix (most any flavor), Windows (all flavors), and a pre-release for Netware 4.1 and 3.12. I have used the Netware and Windows versions in addition to the Unix version.

The Windows version offers little advantage at this time except accounting and a GUI interface. Using the access server itself will be just as effective. The Windows version is shareware and is reasonably priced.

The WindowsNT version will authenticate users using the NT user tables.

The Netware version seems to provide the most benefit. It is, however, limited in its ability to distiguish one group from another, although you can specify which users will be granted access and which will not. In my very limited testing I saw no way to specify one group authorized for slip and another group not authorized, for example. This is also commercial software and lists for $250 per license with a discount for multiple licenses.

Back to Top

TACACS+

To my knowledge, there is only one stable platform for TACACS+, and that is the UNIX platform (most any flavor). There are TACACS+ daemons in beta testing for other platforms. AAA/TACACS+ provides more detailed accounting information as well as more administrative control of authentication and authorization processes. The following is a sample of the commands used to configure the access server for aaa/tacacs+:

!Tell the commserver to use the aaa/tacacas+ protocol

aaa new-model

!Set up the default login process. He will use this process if no other login !rocess is specified

aaa authentication login default tacacs+ enable

!Set up another login process

aaa authentication login telnet tacacs+ line

!Do not allow any process to take place unless accounting records can be !ritten to the tacacs+ server

aaa accounting exec start-stop tacacs+

aaa accounting commands 0 start-stop tacacs+

aaa accounting network start-stop tacacs+

aaa accounting system start-stop tacacs+ 

!Tell him about the tacacs+ server

tacacs-server host 198.209.250.153

tacacs-server key q1Fc1w3YWDd.c

The aaa authentication login commands specify the process the commserver will use to authenticate users. If no login process is specified on a line the the default will be used, which is to first ask the tacacs+ server, and if a deny is returned allow the enable password to be used to gain access. If however a login process is specified for a line like this:

line vty 0 4

password poppins

login authentication telnet

logout-warning 240

absolute-timeout 5

The telnet process is used so if there is no response from a tacacs+ server, the user can gain access using the assigned line password, "poppins".

AAA/TACACS+ commands are fully documnted in the Access and Communication Server Configuration Guide, and the Access and Communication Server Command Reference, available on the UniverCD cd-rom. As of this writing MOREnet is using XTACACS in our production environment. There are plans however to move to AAA/TACACS+ in the near future.

Back to Top

Configure a UNIX TACACS/XTACACS or TACACS+ Server

It would once again be impossible to document every possible daemon configuration issues in this discussion. Here I will try to provide some tips for setting up a TACACS daemon in a Unix environment. In the interest of brevity I must assume the reader has a working knowledge of the Unix environment and shell commands.

It is not particularly difficult to set up an XTACACS or TACACS+ daemon. FTP the source code from one of the resources listed below and copy the file wherever you want to put it (probably /usr/local/src). Read the README and MAKEFILE notes. You will need to provide the full path to where ever you want the logs to be (the default is fine). Check and see if any CFLAGS need to be set in your environment. Go ahead and "make" the binary.

For the XTACACS daemon you will want to run the daemon as a stand alone process. I suggest not running it from inetd. You will almost certainly want to run it like the following:

/usr/local/bin/xtacacsd -s -l

The -s switch means "I am a standalone daemon" and the -l switch enables logging. In addition the -h switch instructs the daemon to create a separate wtmp file for each host that makes a request of the daemon.

Finally you might also want to use some of the configuration file options that are available to you in which case you will want to start the daemon with somwthing like:

/usr/local/etc/xtacacsd -s -l -c /usr/local/etc/xtacacsd-conf 

The configuration file then has many options that can be controlled from it. The most common use for MOREnet is to allow some users to use SLIP access and deny others. The following line accomplishes this:

## 1/1/96 ESK - Allow SLIP groups slip access through terminal server 

Notice the last line. It means deny everyone not included in the above groups SLIP access. The reason this is necessary is because the daemon is simply going down the list looking for a match. If we left this line off, any one could access SLIP. Read the XTACACS documentation for further details.

TACACS+ is an entirely different beast, although at least part of its job is the same. TACACS+ uses its own configuration file to store user and group attributes. This allows for much "finer" control of the access process but has one serious drawback. When a user changes his password, the system updates /etc/passwd (probably/maybe). Since TACACS+ uses its own password file the administrator must come up with a way to update this file. Utilities are included to port passwd(5) type files to TAC+ files, bnut it means that this process must be done periodically. Unitil the TAC+ password file is updated, the user will be unable to login using his new password. S/he will still be able to use the old password.

One big advantage to TACACS+ is the ability to return an "autocommand" based on user or group etc. As mentioned earlier when using the 25xx access server itself for configuration, we could associate a "username" with a command. The same thing applies here, but in this case we have the power to reasonably manage large numbers of users at this level.

Another advantage of TACACS+ is its level of accounting. The TAC+ daemon writes ascii text files instead of wtmp files that can be difficult to manage. The user is free to write his own scripts (eg. Perl scripts) to use the data however he sees fits. The daemon however will write an "accounting" file of its own, in addition to the usual logfile. This file is also in ascii text and is easy to interpret.

Back to Top

Troubleshoot Modem Pool Problems

There are any number of things that can (and almost surely will) go wrong during modem pool operation. This section will provide tips for troubleshooting and correcting modem pool problems.

The following commands are useful for watching modem activity. Each command is followed by a sample of the command's output. Each of these commands is fully documented in the UniverCD shipped with your access server.

Show Line Status Command

MySchool#sho line 1

Tty Typ     Tx/Rx     A Modem  Roty AccO AccI  Uses    Noise   Overruns

I  1 TTY  57600/57600  - inout     -     - &   -    14        15        0/0

Line 1, Location: " ", Type: " "

Length: 24 lines, Width: 80 columns

Baud rate (TX/RX) is 57600/57600, no parity, 1 stopbits, 8 databits

Status: No Exit Banner

Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out  

Modem Callout, Modem RI is CD, Line usable as async interface  

Output non-idle

Modem state: Idle

Special Chars: Escape  Hold  Stop  Start  Disconnect  Activation

^^x     none   -     -     &nbbsp;  none

Timeouts:      Idle EXEC    Idle Session    Modem Answer  Session   Dispatch

0:10:00        2:00:00                      4:00:00     not set

Session idle time reset by output.

Session limit is not set.

Time since activation: never

Editing is enabled.

History is enabled, history size is 10.

Full user help is disabled

Allowed transports are telnet rlogin.  Preferred is telnet.

No output characters are padded

No special data dispatching characters

Modem hardware state: noCTS noDSR  DTR RTS

Group codes:    0

TCP/IP header compression enabled

Back to Top

Using the Debug Command to Debug Your Modems

MySchool#term mon

MySchool#debug modem

TTY12: DSR was dropped

TTY12: Quickly dropping DTR

tty12: Modem: READY->CARDROP

TTY12: Line reset

TTY12: Modem: CARDROP->HANGUP

TTY12: dropping DTR, hanging up

tty12: Modem: HANGUP->IDLE

TTY12: restoring DTR

TTY15: Line reset

TTY15: Modem: READY->HANGUP

TTY15: dropping DTR, hanging up

tty15: Modem: HANGUP->IDLE

MySchool#undebug all

Back to Top

Debuggin Your TACACS Authentication

MySchool#term mon 

MySchool#debug tacacs

TAC: Sent notification type LOGOUT (7) to 204.184.50.200, Id 387

TAC: received extended ANSWER (2) from 204.184.50.200, via Ethernet0  Id 387

TAC: ack received for type (LOGOUT) 7 to 204.184.50.241, Id 387

TAC: Sent notification type LOGOUT (7) to 204.184.50.200, Id 2538

TAC: received extended ANSWER (2) from 204.184.50.200, via Ethernet0  Id 2538

TAC: ack received for type (LOGOUT) 7 to 204.184.50.241, Id 2538

MySchool#undebug all

Note:  Be sure to issue the undebug all command to stop debugging.

Resources

XTACACS for Unix

ftp://ftp.navya.com/pub/vikas/

TACACS Server v2.0 for Novell Netware

http://www.mindweave.com/tacacs/

Modems Information

MultiTech Systems Inc.
USRobotics

Cisco Informative Web Links

Managing Modems
Cisco Access Server Configuration 

Back to Top