Set Up Cisco 2511 Access Server
Follow original document @ www.more.net ; Direct link is added above.This document is offered for informational support only. No active technical support is available and document revisions will not be made after the date noted at the bottom of this page.
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 dialin connection looks like:
| Cisco Access Server | => | RS232 | => | access server modem | => | PSTN (Public Switched Telephone Network) | => | client modem | => | RS232 | => | client PC |
The Cisco Access Server and client PC are called Data Terminal Equipment (DTE), and the access server and client modems are called Data Circuitterminating 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 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 RS232 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
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:
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.
Prerequisites
Before setting up the Cisco 25xx Access Server you must have:
- A dedicated connection to the MOREnet backbone or plans for installation
- Assigned IP addresses
- A facility capable of supporting power requirements for the access server and the modems attached to it
- 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 |
Hardware Setup
-
Unpack the contents and check to be sure all equipment is included. If anything is missing please contact MOREnet Network Operation Cener.
-
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.
-
Attach the thick green/blue v.35 Serial cable to the port labeled "Serial 0" on the back of the access server.
-
Attach the DB25 to RJ45 converter hoods to the back of each modem .
-
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.
-
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.
-
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.
-
Remove the v.35 Serial cable presently connected, from the back of the CSU/DSU.
-
Disconnect the LAN connection (either the Ethernet transceiver or Token Ring DB9 connector).
-
Remove this equipment to make room for the new access server and modems.
-
Attach your LAN connection to the back of the access server.
-
Attach the v.35 green/blue serial cable to the back of the CSU/DSU.
-
Plug in and power on the access server. In a few moments you should see your CSU/DSU return to a normal state.
-
Plug in and power on your modems.
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.
-
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.
-
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.
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
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:
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:
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:
This command displays the configuration stored in non-volatile RAM:
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:
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:
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:
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:
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.
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:
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.
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 riiscd (or modem dialin).
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 RS232 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:
where:
Sample snap shot:
Enter your modem initialization string now…
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).
NOTE: You can also use the disconnect command.
Do this for each of your modems
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.
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 headercompression 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.
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:
[text removed]
[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.
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:
In this case bert would automatically be telnetted to host x.x.x.x when he logged in to the access server.
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.
tacacsserver 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.
tacacsserver extended - use the extended TACACS command set
tacacsserver notify connections - send notification to the TACACS server of a connection attempt to another host
tacacsserver notify enable - send notification to the TACACS server that a user has entered enable mode
tacacsserver notify logout - send notification to the TACACS server that a user has logged out
tacacsserver 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.
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+:
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:
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.
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:
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:
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
| GROUP 10 | HOST all | slipon permit |
| GROUP 1011 | HOST all | slipon permit |
| GROUP 1501 | HOST all | slipon permit |
| GROUP 1506 | HOST all | slipon permit |
| GROUP 1511 | HOST all | slipon permit |
| GROUP 1516 | HOST all | slipon permit |
| GROUP 1521 | HOST all | slipon permit |
| GROUP 1526 | HOST all | slipon permit |
| GROUP all | HOST all | slipon deny |
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.
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.
