Apple Talk

Document ID: 17578

Contents

Introduction
Prerequisites
      Requirements
      Conventions
ARA and Cisco - Version Compatibility
Client ARA Scripts
The Dial-in Line Set Up
      Basic Modem Line Configuration
      Cabling and Basic Line Setup Confirmation
      Modem Configuration in 7 Easy Steps
      Test the Dial-in Line
Configure
      Configurations
      AppleTalk Remote Access Set Up
Troubleshoot
      ARA and Error Correction
      Workarounds (in order of preference)
NetPro Discussion Forums - Featured Conversations
Related Information

Introduction

This document helps you set up the AppleTalk Remote Access. You get started with information about version compatibility between ARA and Cisco, as well as important background on ARA client scripts. Next, you learn how to set up your dial-in line, and then you learn how to get ARA started Also, you learn some troubleshooting hints to make the process as painless as possible.

Prerequisites

Requirements

There are no specific requirements for this document.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

ARA and Cisco - Version Compatibility

ARA Server and Client software currently comes in two versions: ARA 1.0 (1991 Release) and ARA 2.0 (1993 Release). Cisco implements ARA 1.0 with Cisco IOS^® versions up to and inclusive of 9.21. If an ARA 2.0 client dials into a Cisco Access Server with an IOS Version 9.21 or earlier, the client needs to check the compatibility check box in Options. If the Cisco Access Server runs Version 10.2 or later, it accepts connections from either ARA 1.0 or ARA 2.0 clients.

Before Version 10.2, the network number and zone name are taken directly from your Ethernet interface. From Version 10.2 onward, the network and zone must be configured:

arap network [network] [zone]

The network is a unique, non-extended network number, and the zone name is up to the administrator. It is a good idea to make the zone name unique to ARA users in order to eliminate unnecessary NBP traffic from the ARA connections. When you upgrade a box to IOS Version 10.2, you must add this command. Without it, you will be given an explicit error message that it is omitted.

Also, with Version 10.2, you can have ARA autoselect to bypass the commserver username and password prompts and still use TACACS to authenticate the ARA. Use the command: arap use-tacacs (single-line). This requires the extended TACACS server with the supplementary file.

We recommend Version 10.2 or newer.

Client ARA Scripts

ARA Client scripts make modems user-friendly when they emulate what "dumb terminal" users see when they dial into the commserver. They are also called communication command language (CCL) Scripts, ARA Scripts, and MNPLink Tool Documents.

The script runs up through the sign on until ARA is ready to be launched on both the client and server. It takes care of these steps:

1. Sets up the modem with the proper modem string of modem set-up commands.

2. Matches the rs232 speed on the modem and Macintosh.

3. Reports to the user the speed of the connection.

4. In the case of the CCL of the specific TACACS, signs on to the commserver.

   Once these are completed, it exits, and the ARA protocol runs.

   If you set up a modem on a Cisco Access Server, you need to perform steps 1 and 2 manually on the modem that serves or answers. Refer to the Modem Configuration Guide on the faxback server for the setup of most modems.

   Sometimes you need to modify ARA scripts for TACACS and add pauses or special sign-ons. Tools to modify the ARA script include these:

   • ScriptSwitcher, freeware available on the Internet and, hopefully soon, CCO

   • ResEdit, to change the type to "text" and back to "slnk"

   • ARA Modem ToolKit Version 2.0 from APDA (800) 282-2732, part# R0129LL/C $50 (this one includes a script tester and the Modem Scripting Guide)

The Dial-in Line Set Up

The ARA client modem set-up is taken care of by the ARA script and has the correct "hardware handshaking" cable. We need to do the same on the server side. You need the RS-232 cabling configuration:

• RJ-45 satin cable with a complete roll-over (CAB-500RJ)

• MMOD type DB25-RJ45 connector (CAB-5MODCM)/MODEM connector

---------                      --------------
| modem |(MMOD)-----ROLLOVER---| commserver |     *Recommended and supported
---------                      --------------

Refer to the Cabling Guide for Console and AUX Portsfor more information about these cabling requirements.

With the 2500-based access server, the octopus cable (CAB-OCTAL-ASYNC) provides the 500RJ, so all you need to get is an MMOD/MODEM connector.

These configurations also work if you dismantle the DB25-RJ45 adapter and move Pin 6 to Pin 8 on the RS-232 (DB-25) side. This wires the modem DCD output to the commserver DSR input.

---------                      --------------
| modem |(MDCE)-----ROLLOVER---| commserver |     *If MDCE is rewired
---------                      --------------

--------- -------------- | modem |(MDTE)-----STRAIGHT---| commserver | *If MDTE is rewired --------- -------------- 

Now plug the modem into any line, for instance, line 3, and turn it on.

Basic Modem Line Configuration

The basic setup for the modem line, here, line 3, now goes like this:

  line 3
  modem inout
  flowcontrol hardware
  speed 38400

You could use modem ri-is-cd instead of modem inout, but this allows the line to only accept inbound calls, not outbound. Leave this set to modem inout until everything is operative, so you can reverse Telnet to the modem to configure it.

Now configure in the command ip host MODEM3 2003 xx.xx.xx.xx, where xx.xx.xx.xx is the IP address of your Ethernet interface. This makes it easy to quickly establish a reverse Telnet connection to the modem.

Cabling and Basic Line Setup Confirmation

Before you go any further, test a few things to see if everything is all right so far. In order to check the modem and hardware states, type sh line 3. In the output, you see the states of the modem (per the modem inout or modem ri-is-cd state machine), the hardware handshake (CTS & RTS), and modem control (DSR & DTR) signals. It looks like this:

  Modem state: Idle
  ...
  Modem hardware state: CTS noDSR  DTR RTS

These can be on the same line in 9.1.

• If you see the modem in any state other than Idle, find out why. Use sh users to find out if the line is in use. It can be that DSR is high.

• If you see no CTS, you possibly do not have the modem plugged in or turned on since the modem provides CTS.

• If you see DSR when no call (or carrier tone) is present, you possibly have an MDCE connector, not an MMOD, or maybe the modem holds CD high all the time. The modem must present DCD when a call is present, and the cabling presents this to the commserver as DSR.

• If you see * next to the input signal (CTS* noDSR*), modem inout/ri-is-cd has not been applied to the line.

Now, once the modem is stable in the Idle CTS noDSR DTR RTS state, you are ready to connect to the modem to configure it.

Type modem3 at the # prompt. This initiates a reverse Telnet to the modem on line 3. If the modem responds with "OK" when you type at, you are now able to configure your modem. Remember to disconnect this connection to the modem fully; first escape with 6-X, type disc, and confirm. Otherwise, you still have a session to the modem. The sh line 3 command sees this and shows that the modem state is ready. Now go on to configure your modem to accept ARA and other calls.

Modem Configuration in 7 Easy Steps

Configure your modem with these 7 steps:

1. Start at factory defaults (&F).

2. Lock the speed on the DTE side of the modem. This is a must since the commserver has its speed locked. Often, if you send one AT command to the modem, it takes care of this. Sometimes a feature like port rate adjust or autobaud or direct changes this DTE speed to match the link speed. Sometimes this command is buried even deeper in the S registers. This varies by modem.

3. Turn off the software handshake and turn on the hardware handshake. There can be separate commands to control CTS and RTS that relate to half duplex operation. Skip those and find the control settings for hardware/software handshakes (CTS/RTS). This also varies by modem.

4. Set normal DTR operation (&D3).

5. Set normal DCD operation (&C1).

6. Turn on Best Error Correction, but know how to turn it off if necessary for troubleshooting. An ARA client modem is not designed for error correction sessions with the serving modem, but other client protocols can want error correction in the modem.

7. Write settings to modem NVRAM (&W). There can be several NVRAM locations.

Escape out of your Telnet and disconnect your session to the modem. This would be a good time to check sh line 3 again to see if the hardware states still look good.

 Modem State: Idle CTS noDSR RTS DTR

Test the Dial-in Line

Dial into the commserver from a client that runs terminal emulation software and see if you can get onto the commserver. Troubleshoot this connection before you go on to ARA setup. Use the Modem Configuration guide (available on the faxback server) if you need help. Remember that any problems you have can be on the client end, as well, such as port rate adjust.

Configure

Configurations

In this section, you are presented with the information to configure the features described in this document.

Note: Use the Command Lookup Tool ( registered customers only) to find more information on the commands used in this document.

AppleTalk Remote Access Set Up

ARA does not allow users to connect unless AppleTalk already runs on an interface. So bring up AppleTalk, and use sh app int to confirm that it is up and valid. For IOS Versions 10.2 and later , you could use the arap network ... command.

Next, determine where and how the ARA user database are stored. There can be an authentication required to connect to the commserver. There is always an ARA authentication, although it can be guest. There are several options to store the user database:

• In the configuration of the commserver:

  Pros: You can use just the standard ARA client script, and you do not need a TACACS server.

  Cons: If you have more than one commserver, you have to replicate the database in each one.

• In a TACACS server:

  Pros: One database accommodates all users, and you have better encryption of the password.

  Cons: A TACACS server is required, and you must have a special script (called TACACS Script) on every ARA client. Username and password are entered without error correction.

  Note: In the ARA client window, the user logs in as "guest." After he dials in, he is prompted for a TACACS username and a TACACS password. The sign-on is determined by the "login" statement on the line. One of login/login local/login tacacs needs to be configured on the line.

• In an enhanced TACACS server:

  Pros: Standard ARA client script, one database for all ARA users. Authentication is done with error correction.

  Cons: TACACS server is required with a special supplementary file.

You must choose one of these options.

Now, determine how ARA is to be launched. Only one of these three options is configured on the line. (This matches with the Authentication issues closely.)

• arap enable

  If you use the special TACACS script on the client (option 2), and the user database is stored in a TACACS server, the script uses the arap command to launch ARA as it exits.

• arap dedicated, arap enable

  If you service only ARA clients on the line, and the user database is in the configuration of the commserver or in an enhanced TACACS server, you can configure the line for "arap dedicated." This bypasses any "login" statement on the line.

• autoselect arap, arap enable

  This options looks for an MNP Link Request packet that comes from the client ARA stack. If it sees one through ASCII 22 framing character for Version 1.0 or 11 for Version 2.0, it launches ARAP. If it sees a carriage return, ASCII 13, it goes through sign on and then the exec process.

                    autoselect arap       arap dedicated
  arap enable         arap enable          arap enable
       |                   |                    |
       |                   |                    |   ------------
       |                   |                    |   |          |
       |                ---------               ----|          |  ---------
       |               ( select? )------------------|   ARA    |--|  ARA  |
       |                ---------               ----| launched |  |sign-on|
       |                   |                    |   |          |  ---------
       |            -------------   -------     |   |          |
       -------------|comm server|---|type |------   ------------
                    |  login*   |   |arap*|
                    -------------   -------
  

  * TACACS Script needed on client.

Now, configure the line for ARA. Here are some sample ARA configurations.

• ARA only lines username database on commserver (standard ARA script on client)

         username krist password xxxxxx
         line 3
         arap enable
         arap noguest
         arap dedicated

  This allows krist to connect as a registered user. Guest access is now off. As soon as DSR is raised, the commserver launches ARAP. Login commands have no effect here.

• With autoselect on a shared protocol line (standard ARA script on client)

         username krist password xxxxxx
         line 3
         arap enable
         arap noguest
         autoselect arap
         login local

  In this case, the ARA client sends out the MNP4 Link Request. Autoselect sees this, launches ARAP, then authenticates the user as a registered user (from the local database per login local).

• All users authenticated as they connect to the commserver (special TACACS script on client)

         username krist password xxxxxxx
         line 3
         arap enable
         login local

  This allows the user krist to connect with the special TACACS script. This special script prompts the client for username and password, then launches ARAP. Login Local allows this function to be tested without the need to get into TACACS. In the client ARA window, krist selects the guest button.

• With autoselect on a shared protocol line with enhanced TACACS server

         tacacs-server host x.x.x.x
         line 3
         arap enable
         arap noguest
         arap use-tacacs

  Take a look at the file tacacs.doc with the xtacacsd source distribution on CCO to learn how to set up TACACS and the TACACS supplementary file.

Troubleshoot

ARA and Error Correction

One common problem with the use of the standard ARA scripts is that the serving modem can intercept the MNP4 Link Request packet and respond back to the ARA stack in the client.

   -----   --------------             ---------------   ------------
   |Mac|   |client modem|------/------|serving modem|   |ARA Server|
   -----   --------------             ---------------   ------------

-------->-------->-------->-------> | WRONG <--------<--------<--------<------- 

-------->-------->-------->-------->-------->-------> | RIGHT <--------<--------<--------<--------<--------<------- 

ARA uses an MNP4 error correction session established between the client and the server. It expects the serving modem to pass the MNP4 Link Request packet on to the server. Often you configure the serving modem to support error correction: Version 42 error correction means the fallback sequence LAPM --> MNP4 --> no EC.

In the case of ARA calls, the serving modem cannot respond to the MNP4 Link Request, or the error correction link is between the Mac Client and the serving modem. If this happens, the ARA connection fails. Your Mac displays the message "Communicating at 14.4Kbps," hangs for around 60 seconds, and then displays a failed connection message. This is what happened: The ARA client script saw a 14400 connect message, presented that on the screen of the Mac, paused .5 seconds, and then exited. When the ARA script exited, the client ARA stack sent the MNP4 LR packet. If the serving modem still listened for MNP4 requests, it accepted them and responded.

Workarounds (in order of preference)

These are the workarounds in the order of preference.

1. Use ARA 2.0 on the client, and 10.2 on the server. ARA 2.0 has modified the MNP4 packets with different framing, so the serving modem passes the packet through to the ARA server.

2. Modify the behavior of the modem if possible to use this EC fallback. LAPM-->No EC. The modem does not listen for or respond to MNP4 messages. This is safe as your SLIP; PPP and Terminal users use LAPM (since everyone uses Version 42 these days).

3. Modify the ARA client script to extend the .5 second pause before it exits. This takes experimentation to determine how long a pause is needed to account for the behavior of the serving modem. All client ARA scripts need to be modified in this way.

4. Use the TACACS modification in the script, but this is a clumsy way to add a delay at the end of the script.

Option 1 is your best bet.

NetPro Discussion Forums - Featured Conversations

Related Information

• Technical Support & Documentation - Cisco Systems