|
|
This chapter describes how to configure your access server to act as an AppleTalk Remote Access (ARA) server. It does not describe how to configure or use the client Macintosh. Refer to Apple Computer's Apple Remote Access Client User's Guide and the Apple Remote Access Personal Server User's Guide for information about how to use ARA software on your Macintosh. For a complete description of the commands in this chapter, refer to the chapter "AppleTalk Remote Access Commands" in the Access and Communication Servers Command Reference publication.
Cisco's implementation of ARA gives Macintosh users direct access to information and resources in remote locations. Macintosh users can connect to another Macintosh computer or AppleTalk network over standard telephone lines. For example, if you have a PowerBook at home and need to get a file from your Macintosh at the office, ARA software can make the connection between your home and office computers.
You can configure your access server to act as an ARA server by enabling AppleTalk and ARA Protocol on physical terminal (TTY) or virtual terminal (VTY) lines. Configuring your access server to act as an ARA server allows remote Macintosh users to dial in, become a network node, and connect to devices on other networks. ARA Protocol support on the access server is transparent to the Macintosh end user.
The following Macintosh and access server software support is required for ARA connectivity:
Figure 14-1 shows how your access server can act as an ARA server between remote Macintosh computers (in Figure 14-1, a Macintosh SE and a PowerBook) and devices on another network.
Enabling ARA on your access server permits the server to support ARA on the Macintosh and, therefore, to act as an ARA server.
AppleTalk is a client-server, or distributed, protocol. AppleTalk users share network resources, such as files and printers, with other users. Interactions with different servers are transparent to users, because the computer determines the location of the requested material and accesses it without requesting information from the user.
AppleTalk identifies several network entities: node, network, and zone. A node is any device connected to an AppleTalk network. The most common nodes are Macintosh computers and laser printers, but many other types of computers are also capable of AppleTalk communication, including IBM PCs, Digital VAX/VMS systems, and a variety of workstations. An access server, which provides only one network interface, is considered a node on the network. In this chapter, the term router refers to any device that routes AppleTalk packets. An AppleTalk network is a single logical cable, and an AppleTalk zone is a logical group of one or more (possibly noncontiguous) networks.
Apple Computer has produced a variety of internetworking products with which to connect AppleTalk local-area networks. Apple supports Ethernet, Token Ring, Fiber Distributed Data Interface (FDDI), and its own proprietary twisted-pair media access system (called LocalTalk).
Figure 14-2 compares the AppleTalk protocols with the standard seven-layer OSI model and illustrates how AppleTalk works with a variety of physical and link access mechanisms.
The Cisco AppleTalk implementation provides the following standard services in addition to the ability to transmit any AppleTalk packet:
The DDP and AARP protocols provide end-to-end connectivity between internetworked nodes. NBP maps network names to AppleTalk IP addresses. NBP relies on ZIP to help determine which networks belong to which zones. File and print access is provided through AFP and PAP, respectively, which work with applications such as AppleShare and print servers.
The Cisco AppleTalk implementation also includes the following enhancements:
AppleTalk, like many network protocols, makes no provision for network security. The AppleTalk protocol architecture requires that security measures be executed at higher application levels. The access server software supports AppleTalk network access lists, providing filters at the packet level.
AppleTalk was designed for local work groups. With the installation of over 1.5 million Macintosh computers in the first five years of the product's life, Apple found that some large corporations were exceeding the design limits of AppleTalk. Apple's solution was to create extended AppleTalk. The extended AppleTalk architecture increases the number of nodes per AppleTalk internetwork to over 16 million and an unlimited number of zones per cable.
The introduction of the extended AppleTalk architecture also introduced the concept of nonextended and extended networks. Nonextended AppleTalk networks are sometimes called "Phase 1," and extended networks are called "Phase 2." Nonextended networks refer to the nonextended AppleTalk Ethernet 1.0 networks (no longer supported by Apple but still supported by Cisco), and to the nonextended serial line-based networks, including those configured using X.25 and LocalTalk.
Extended networks refer to the extended AppleTalk-compliant networks configured on Ethernet (EtherTalk 2.0) and Token Ring media. Examples of nonextended and extended AppleTalk network configurations can be found in the section "Configuration Examples" later in this chapter.
The AppleTalk extended-network architecture provides extensions compatible with nonextended AppleTalk internetworks. The AppleTalk extended architecture was designed to remove the previous limits of 254 concurrently active AppleTalk nodes per cable, as well as the previous limit of one AppleTalk zone per cable. Extended AppleTalk contains better algorithms for choosing the best routers for traffic and is designed to minimize the amount of broadcast traffic generated for routing updates.
Another important feature in extended AppleTalk is the ability of a single AppleTalk cable to be assigned more than one network number. The size of the range of network numbers assigned to a cable determines the maximum number of concurrently active AppleTalk devices that can be supported on that cable, which is 254 devices per network number.
AppleTalk addresses are 24 bits long. They consist of two components: a 16-bit network number and an 8-bit node number. The Cisco AppleTalk software parses and displays these addresses as a sequence of two decimal numbers (the network number, a period, and the node number). For example, node 45 on network 3 is written as 3.45. A node is any AppleTalk-compatible device attached to the network. Each enabled AppleTalk interface on a router is a node on its connected network.
When a router is used to join two or more AppleTalk networks into an internetwork, the component physical networks remain independent of each other. A network manager may assign nodes on each physical network to a conceptual grouping known as a zone.
There are two main reasons to create zones in an AppleTalk internetwork: to simplify the process of locating and selecting network devices, and to allow for the creation of departmental work groups that may exist on several different and possibly geographically separated networks.
For example, consider a large AppleTalk internetwork that contains hundreds or thousands of shared resources and devices. Without a method of dividing this large number of resources and devices into smaller groups of devices, a user might have to scroll through hundreds or thousands of node names in the Chooser to select the one node to be used. By creating small conceptual groups of nodes, users can choose the resources they need much more quickly and easily than if they were sorting through a very long list of names.
A zone can include many networks that need not be located together physically. A zone is not limited by geographical area. The partitioning afforded by zone names is conceptual, not physical.
The network manager defines zones when he or she configures a router. For nonextended networks, each AppleTalk-configured interface must be associated with exactly one zone name, and for extended networks, each AppleTalk-configured interface can be associated with one or more zone names. Until a zone name has been assigned, AppleTalk capability is disabled for that interface. The section "Configure AppleTalk" later in this chapter lists the commands to use in the zone-naming process. Refer to the chapter "AppleTalk Remote Access Commands" in the Access and Communication Servers Command Reference publication for a description of each command and its guidelines for usage.
The Name Binding Protocol (NBP) maps network entity names to internetwork addresses. It allows users to specify descriptive or symbolic names; software processes refer to numerical addresses for the same entities. With NBP, almost all user-level programs respond to names instead of numbers. When users select an AppleTalk device, they are using the NBP protocol to translate the device's entity name to the entity's network address. Numerical addresses dynamically assigned to nodes are primarily used by the router software and by network managers in the ping process.
NBP provides four basic services for binding names to nodes and zones:
The nature of the AppleTalk addressing scheme is inherently volatile, and node addresses change frequently. Therefore, NBP associates numerical addresses with aliases that continue to reference the correct address if the address changes.
NBP uses the Zone Information Protocol (ZIP) to determine which networks belong to which zones. A router uses ZIP to maintain the network-number-to-zone-name mapping of the AppleTalk network.
Each access server or router maintains a data structure known as the zone information table. The table provides a listing of network numbers for each network in every zone. Each entry is a tuple (an inseparable network number-hop number set) that matches a network number with a zone name as supplied by the network manager.
AppleTalk supports dynamic configuration (discovery mode). Not all fields of an AppleTalk address need to be specified to configure an AppleTalk router. If there is another AppleTalk access server or router on the network, it might be able to supply the network number and zone name. A preconfigured router on an AppleTalk network acts as a seed router or access server, responding to configuration queries from other nodes on its network.
Seed routers come up and verify the configuration with an operational router. If the configuration is valid, they start functioning. Seed routers come up even if no other routers are on the network. On the other hand, a nonseed router must first communicate with a seed router before it can begin operation. A nonseed router must obtain and verify the configuration with another functioning router. The configuration of the nonseed router must match exactly with the configuration of the seed router for the nonseed router to function.
An end node always behaves in a manner similar to discovery mode. It uses any previous configuration as a starting point for initialization.
Unspecified parts of the AppleTalk address are entered as zero. Figure 14-1 lists AppleTalk addresses that feature unspecified addressing.
| AppleTalk Address | Description |
|---|---|
| 34.5 | Completely specified (network 34, node 5) |
| 0.5 | Partially qualified (network unspecified, node 5) |
| 122.0 | Partially qualified (network 122, node unspecified) |
| 0.0 | Completely unspecified |
AppleTalk automatically assigns node numbers. When the specified address is in use, the node randomly chooses its node number. The node will first try the node number that was its most recent address. If that number is unavailable, the node then searches for the next available address. If it reaches 254 without finding an available number, it cycles back to 1 and continues until it finds a free address. LocalTalk address restrictions are as follows: user node numbers are from 1 to 127, and server/printer node numbers are from 128 to 254. Nonextended Ethernet and extended media do not observe the server/user node distinction. The protocol reserves node numbers 0 and 255. Extended media also reserves the node number of 254.
For nonseed access servers, an interface will behave as an AppleTalk end node. If zero has been specified for a network number, that interface will not route any packets until it receives its network number from a seed router.
As long as one fully configured access server or router exists on a physical network segment (or cable), other routers directly attached to that cable can use discovery mode to determine their configuration; they can take their information from an operational access server or router. However, once the configuration process has stabilized for a particular AppleTalk network, all access servers and routers thereafter should be configured as seed routers. Note that synchronous X.25 network interfaces must be explicitly configured on each access server or router to be used as AppleTalk transports.
Node address information is maintained by tables appropriate to the media (usually AARP tables).
AppleTalk addresses, as explained in the section "Nonextended AppleTalk Addressing" earlier in this chapter, are composed of a 16-bit network and an 8-bit node number. In nonextended AppleTalk, nodes within a single cable can communicate using only their 8-bit node numbers.
A node in extended AppleTalk is always identified by its network and node number. Dynamic address resolution when an access server or router is not present includes the assignment of a random network number within a small range, as well as a node number. When an access server or router is present in the network, a node starts up using its newly acquired address for a short period of time. It then immediately requests the range of valid network numbers from an operational router. The node then uses this to determine its actual AppleTalk address by selecting an unassigned address.
A new concept of cable ranges is introduced with the extended AppleTalk. Ranges of network numbers and multiple zones can exist on a single logical cable. But the node can exist in only one zone and on only one network.
In an extended AppleTalk network, the mapping of a physical cable to a zone name is no longer valid. End nodes are expected to know the zone to which they belong or to choose from the list of available zones provided by a router. The router maintains a default zone that new nodes will use automatically if they have not chosen a zone previously.
Cisco access servers and routers with active AppleTalk interfaces register each interface separately. A unique interface name is generated by appending the interface type name and unit number to the access server or router name. For example, if an access server is named mycommserver and has AppleTalk enabled on Ethernet 0 in zone Engineering, the NBP registered name will be as follows:
mycommserver.Ethernet0:ciscoRouter@Engineering
The NBP name is deregistered in the event that AppleTalk is disabled on an interface by configuration or due to interface errors.
Registering each interface on the access server provides the AppleTalk site administrator with a positive indication that the access server and router is properly configured and operating.
One name is registered per interface; other service types are registered once for every zone name on the access server. The following display output from the show appletalk nbp command shows that each interface is uniquely identified, but that only one SNMP Agent is generated per zone.
Net Adr Skt Name Type Zone 4042 8 254 brown.Ethernet0 ciscoRouter Engineering 4028 8 254 brown.Async1 ciscoRouter Engineering
The access server answers AppleTalk responder requests. The listener is installed on the AppleTalk interface name registration socket.
The response packet generated supplies the bootstrap firmware version string, followed by the router operating software version string. These are displayed in the position of the Macintosh system version and the Macintosh printer driver version, respectively, in such applications as Apple's Inter·Poll.
The response packet contains strings similar to those displayed by the show version EXEC command.
The information is returned as follows:
Figure 14-3 illustrates a typical output display for Inter·Poll that lists this information.
To set up your access server as an ARA server, complete the following tasks:
The following tasks are optional:
To enable asynchronous callback to ARA clients, refer to the section "Call Back ARA Clients" in the "Configuring Terminal Lines and Modem Support" chapter.
Figure 14-4 shows how to connect a Macintosh directly to the access server and how to connect a Macintosh using internal and external modems. The directly connected Macintosh can be used as a terminal from which you can configure the access server.
To connect a Macintosh directly to the access server, use the FDTE version of the RJ-45-to-DB-25 adapter (Cisco Part Number: 29-FDTE-02) to connect the "rolled" RJ-45 cable from the access server to the Mini 8-to-DB-25 cable from the Macintosh.
If you are using the "octopus" cable to connect a modem to the access server, the octopus cable is an RJ-45 cable.
If not, use the MMOD version of the RJ-45-to-DB-25 adapter to connect a "rolled" RJ-45 cable from the access server to the modem. You can also use a Cisco MDCE adapter that you have modified by moving the DB-25 pin in position 6 to position 8.
Configure the line on the access server as follows:
Configure the modem as follows:
After setting up the cabling and the modem, test the line for a clean connection. Attempt to dial in to the access server. If you cannot, you should
For more information about configuring modems, refer to the appendix "Configuring Modem Support and Chat Scripts" in the Access and Communication Servers Command Reference publication.
If your modem does not support this configuration, refer to the chapter "Configuring Terminal Lines and Modem Support" earlier in this publication, or the chapter "Terminal Line and Modem Support Commands" in the Access and Communication Servers Command Reference publication for information about configuring a line to support your modem.
To configure ARA on your access server, you need to perform the following tasks:
The sections that follow describe each of these tasks. Refer to the chapter "AppleTalk Remote Access Commands" in the Access and Communication Servers Command Reference publication for information about commands listed in these tasks.
To enable AppleTalk routing, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable AppleTalk. | appletalk routing |
To create a new network or zone, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Create an internal AppleTalk network. | arap network [network-number] [zone-name] |
This is a required command. ARA will not run without it in Cisco IOS Release 10.2 and above.
To ensure that a new internal network is advertised, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Enable RTMP network advertising. | appletalk send-rtmps |
You can manually configure an interface for AppleTalk or, if an interface is connected to a network that has at least one other access server or router configured for AppleTalk, you can dynamically configure the interface using discovery mode.
If the AppleTalk network already exists, the zone and cable range must match the existing configuration. To identify existing cable ranges and zone names, configure the access server for discovery mode.
You can also configure an AppleTalk interface on a segment for which there are no AppleTalk routers.
To manually configure an interface for extended AppleTalk, perform the following tasks:
| Task | Command |
|---|---|
| Assign a cable range to an interface. | appletalk cable-range cable-range [network.node] |
| Assign a zone name to the interface. | appletalk zone zone-name |
If you assign more than one zone name, the first name you assign is the default zone.
You can define up to 255 unique zone names.
After you assign the address and zone name(s), the interface will attempt to verify them with other operational access servers or routers on the connected network. If there are any discrepancies, the interface will not become operational. If there are no neighboring operational access servers or routers, the access server will assume the configuration is correct, and the interface will become operational.
If an AppleTalk interface is connected to a network that has at least one other operational AppleTalk router or access server, you can dynamically configure the interface using discovery mode. In discovery mode, an interface acquires information about the attached network from an operational access server or router and then uses this information to configure itself. Once the interface has been configured, you can manually enter the dynamically acquired information.
Using discovery mode to configure interfaces saves time if the network numbers, cable ranges, or zone names change. You need to make the changes on only one operational access server or router.
Discovery mode is useful when you are changing a network configuration or when you are adding an access server to an existing network.
If there is no operational access server or router on the attached network, you must manually configure the interface as described in the earlier section "Manual Interface Configuration." Also, if a discovery-mode interface is restarted, another operational access server or router must be present before the interface can become operational.
An access server starts up by first acquiring its configuration from memory. Then, if an interface is not configured for discovery mode, the interface starts up as follows:
Using discovery mode does not affect an interface's ability to respond to configuration queries from other access servers on the connected network once the interface becomes operational.
When activating discovery mode, you do not need to assign a zone name. The interface acquires the zone name from another interface.
 | Caution Do not enable discovery mode on every access server and router on a network. If you do and all access servers restart simultaneously (for instance, after a power failure), the network will be inaccessible until you manually configure at least one access server. |
You can activate discovery mode on an extended interface in one of two ways, depending on whether you know the cable range of the attached network. These methods are described in the sections that follow.
In the first method, you immediately put the interface into discovery mode by specifying a cable range of 0-0. Use this method when you do not know the network number of the attached network. To configure an interface for discovery mode using this method, perform the following tasks in interface configuration mode:
| Task | Command |
|---|---|
| Put the interface into discovery mode by assigning it the cable range 0-0. | appletalk cable-range 0-0 |
In the second method, you first assign cable ranges and then explicitly enable discovery mode. Use this method when you know the cable range of the attached network. To configure an interface for discovery mode using this method, perform the following tasks interface configuration mode:
| Task | Command |
|---|---|
| Assign an AppleTalk address to the interface. | appletalk cable-range cable-range [network.node] |
| Put the interface into discovery mode. | appletalk discovery |
You can also configure an AppleTalk interface on a LAN segment that does not have any AppleTalk routers by performing the following tasks starting in global configuration mode:
| Task | Command |
|---|---|
| Step 1 Turn on AppleTalk routing. | appletalk routing |
| Step 2 Specify an interface and enter interface configuration mode. | interface type number1 |
| Step 3 Specify the AppleTalk address as 1, which is the default address when there are no routers. | appletalk address 1.1 |
| Step 4 Specify the name of the local zone. | appletalk zone * |
You cannot use discovery mode for this configuration.
To enable ARA on a line, perform the following task in line configuration mode:
| Task | Command |
|---|---|
| Step 1 Turn on AppleTalk routing. | appletalk routing |
| Step 2 Enter line configuration mode. | line [console |tty | aux | vty] line-number [ending-line-number]1 |
| Step 3 Enable ARA on a line. | arap enable |
The commands in this section can be used to customize ARA support. Some of the commands are required for certain configurations. Possible functions include the following:
The following sections describe these tasks. Refer to the chapter "AppleTalk Remote Access Commands" in the Access and Communication Servers Command Reference publication for information about commands listed in these tasks.
To configure the access server to allow an ARA session to start automatically, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Configure a line to automatically start an ARA session. | autoselect {arap | ppp | slip | during-login}1 |
The autoselect command permits the access server to allow an appropriate process to start automatically when a starting character is received. The access server detects either a Return character, which is the start character for an EXEC session, or the start character for the ARA protocol. By issuing the command with the during-login argument, you can display the username or password prompt without pressing the Return key. While the Username or Password name is being presented, you can choose to answer these prompts or to start sending packets from an autoselected protocol.
For information on using ARA with TACACS, Extended TACACS, and AAA/TACACS+, refer to the "System Management" chapter earlier in this publication.
To set a line to function only as an ARA connection, perform the following task in line configuration mode:
| Task | Command |
|---|---|
| Configure a line for ARA only. | arap dedicated |
You can also set the line for autoselect with or without TACACS logins.
To set the maximum length of an ARA session for a line, perform the following task in line configuration mode:
| Task | Command |
|---|---|
| Set the maximum length of an ARA session. | arap timelimit [minutes] |
The default is to have unlimited length connections. This task is optional.
To configure when to display a disconnect warning, perform the following task in line configuration mode:
| Task | Command |
|---|---|
| Set when a disconnect warning message will be displayed, in number of minutes before the line is set to disconnect. | arap warningtime [minutes] |
This command is valid only when a session time limit is set.
A guest is a person who connects to the network without having to give a name or a password. To prohibit Macintosh guests from logging in through the access server, perform the following task in line configuration mode. Use the optional if-needed argument to allow users to log in as guests if they are already authenticated with a username or password.
| Task | Command |
|---|---|
| Prohibit guests from logging in to the ARA network. | arap noguest [if-needed] |
| Caution Do not use the arap noguest command if you are using modified (CCL) scripts and the login tacacs command. |
You can control access by requiring that users enter their password manually at the time they log in. To force manual password entry, perform the following task in line configuration mode:
| Task | Command |
|---|---|
| Require manual password entry. | arap require-manual-password |
You can control Macintosh access to zones and networks by using arap commands to reference access control lists configured using AppleTalk access-list commands.
To control what zones the Macintosh user will see, perform the following task in line configuration mode:
| Task | Command |
|---|---|
| Limit the zones the Macintosh user sees. | arap zonelist zone-access-list-number |
To control traffic from the Macintosh to networks, perform the following task in line configuration mode:
| Task | Command |
|---|---|
| Control access to networks. | arap net-access-list net-access-list-number |
The Cisco IOS software permits remote Macintosh users dialing in through asynchronous network devices that do not support ARA protocols to access AppleTalk services (such as file sharing and printing) elsewhere on the network. For example, you can enable a Macintosh client on the remote side of an X.25 network to connect to an AppleTalk network through the access server. To do so, you configure a virtual terminal (VTY) line on the access server in one of two ways:
To enable ARA on VTY lines and enable clients running different virtual terminal protocols to connect to an AppleTalk network through the access server, perform the following tasks, beginning in global configuration mode. The first three steps are required. The next eight steps (4 through 11) are optional:
| Task | Command |
|---|---|
| Step 1 Turn on AppleTalk routing. | appletalk routing |
| Step 2 Enter line configuration mode. | line vty line-number [ending-line-number] |
| Step 3 Enable ARA on a line. | arap enable |
| Step 4 Configure automatic protocol startup. | autocommand arap |
| Step 5 Set a dedicated ARA line. | arap dedicated |
| Step 6 Set the session time limit. | arap timelimit [minutes] |
| Step 7 Set the disconnect warning time. | arap warningtime [minutes] |
| Step 8 Disallow guests. | arap noguest |
| Step 9 Require manual password entry. | arap require-manual-password |
| Step 10 Limit the zones the Macintosh user sees. | arap zonelist zone-access-list-number |
| Step 11 Control access to networks. | arap net-access-list net-access-list number |
To customize the AppleTalk configuration, complete the following tasks:
This section describes how to perform these configuration tasks. Refer to the chapter "AppleTalk Remote Access Commands" in the Access and Communication Servers Command Reference publication for information about commands listed in these tasks.
Figure 14-5 shows a configuration in which an access server acting as an ARA server serves a local network that is not connected to an internetwork.
By default, the access server generates checksums for all ARA traffic that requests them. You might want to disable checksum generation and verification if you have an older LaserWriter printer or other device that cannot receive packets with checksums.
To disable checksum generation and verification, perform the following global configuration task:
| Task | Command |
|---|---|
| Disable the generation and verification of checksums for all AppleTalk packets. | no appletalk checksum |
The access server implements MacIP, a protocol that routes IP datagrams to IP clients using AppleTalk Datagram Delivery Protocol (DDP) low-level encapsulation. MacIP allows the access server to assign an ID number to a Macintosh computer that dials in. The ID number allows the Macintosh computer to run MacTCP applications.
Cisco access servers implement the MacIP address management and routing services described in the draft Internet RFC, A Standard for the Transmission of Internet Packets over AppleTalk Networks. This implementation of MacIP conforms to the September 1991 draft RFC with the following exceptions:
MacIP is required to provide access to IP network servers for those users. It is also required for environments in which Macintosh users use ARA or are connected to the network using LocalTalk or PhoneNet cabling systems.
MacIP services can also be useful when you are managing IP address allocations for a large, dynamic Macintosh population. There are several advantages to using MacIP in this situation:
However, there is an important disadvantage in implementing MacIP on an access server: memory usage in the access server increases in direct proportion to the total number of active MacIP clients (about 80 bytes per client).
To configure MacIP on the Cisco access server, AppleTalk must be configured on the access server as follows:
When setting up MacIP routing, keep the following address-range issues in mind:
To configure MacIP, perform the following tasks:
Step 1 Establish a MacIP server for a specific zone.
Step 2 Allocate IP addresses for Macintosh users by specifying at least one dynamic or static resource address assignment command for each MacIP server.
To establish a MacIP server for a specific zone, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Establish a MacIP server for a zone. | appletalk macip server ip-address zone server-zone |
A MacIP server is not registered using NBP until at least one MacIP resource is configured.
Dynamic clients are those that accept any IP address assignment within the dynamic range specified. Dynamic addresses are for users who do not require a fixed address, but can be assigned addresses from a pool.
To allocate IP addresses for Macintosh users if you are using dynamic addresses, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Allocate an IP address to a MacIP client. | appletalk macip dynamic ip-address [ip-address] zone server-zone |
For an example of configuring MacIP with dynamic addresses, see the section "MacIP Configuration Example."
Static addresses are for users who require fixed addresses for IP DNS services and for administrators who do not want addresses to change so they always know the IP addresses of the devices on their network.
To allocate IP addresses for Macintosh users if you are using static addresses, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Allocate an IP address to be used by a MacIP client that has reserved a static IP address. | appletalk macip static ip-address [ip-address] zone server-zone |
For an example of configuring MacIP with static addresses, see the section "MacIP Configuration Example."
In general, you should not use fragmented address ranges in configuring ranges for MacIP. However, if this is unavoidable, use the appletalk macip dynamic command to specify as many addresses or ranges as required, and use the appletalk macip static command to assign a specific address or address range.
An access list is a list of AppleTalk network numbers or zones that is maintained by the access server and used to control access to or from specific zones or networks.
The access server supports two general types of AppleTalk access lists:
AppleTalk-style access lists use zone names to regulate access to the internetwork. Zone names are good control points, because they are the only network-level abstraction that users can access. You can express zone names either explicitly or by using generalized argument keywords. Thus, using AppleTalk access lists simplifies network management and allows for greater flexibility when adding segments because reconfiguration requirements are minimal.
Because AppleTalk-style access lists are based on zones, they allow you to define access regardless of the existing network topology or any changes in future topologies--because they are based on zones. A zone access list is effectively a dynamic list of network numbers. The user specifies a zone name but the effect is as if the user had specified all the network numbers belonging to that zone.
IP-style access lists control network access based on network numbers. This feature is useful for defining access lists that control the disposition of networks that overlap, are contained by, or exactly match a specific network number range.
You can combine zone and network entries in a single access list. Network filtering is performed first, then zone filtering is applied to the result. However, for optimal performance, access lists should not include both zones and numeric network entries.
There are two types of filters you can use on AppleTalk networks:
AppleTalk network access control differs from that of other protocols in that the order of the entries in an access list is unimportant. However, there are still some constraints you need to keep in mind when defining access lists:
You access lists and filters to control access to AppleTalk networks. These tasks are described in the sections that follow.
An access list defines the conditions used to filter packets sent out of the interface. (These conditions are sometimes also used to filter incoming packets.) Each access list is identified by a number. All access-list commands that specify the same access list number create a single access list.
A single access list can contain any number and any combination of access-list commands. You can include network and cable range access-list commands and zone access-list commands in the same access list. However, you can only specify one each of the commands that specify default actions to take if none of the access conditions are matched. That is, a single access list can include only one access-list other-access command to handle networks and cable ranges that do not match the access conditions and only one access-list additional-zones command to handle zones that do not match the access conditions.
To create access lists that define access conditions for networks and cable ranges, perform one or more of the following tasks in global configuration mode:
The access list number can be a decimal value from 600 to 699.
To create access lists that define access conditions for zones, perform one or both of the following tasks in global configuration mode:
The access list number can be a decimal value from 600 to 699.
Two types of security can be used on your access server when it is acting as an ARA server:
The following sections describe these tasks. Refer to the chapter "AppleTalk Remote Access Commands" in the Access and Communication Servers Command Reference publication for information about commands listed in these tasks.
To configure your access server for internal username authentication, perform the following task in global configuration mode. Enter this information for each supported user.
| Task | Command |
|---|---|
| Specify a username and password. | username name password password1 |
There are two ways use TACACS security:
Use the arap use-tacacs command with Standard and Extended TACACS protocol for authentication within ARA sessions. You must already have set up an Extended TACACS server using the Cisco Extended TACACS server software, available by using FTP (see the README file in the ftp.cisco.com directory). When using this method with Standard TACACS, the remote user must login by entering username*password at the ARA username prompt, and arap at the password prompt.
Use the aaa authentication arap command with AAA/TACACS+.
To configure the Cisco device to use TACACS with ARA, perform one of the following tasks in line configuration mode:
| Task | Command |
|---|---|
| Enable TACACS under ARA. | arap use-tacacs [single-line]1 or aaa authentication arap2 |
For an example of enabling TACACS for ARA authentication, see the section "Configuration Examples" later in this chapter.
This section tells you how to modify your CCL script to work with TACACS security and how to configure a line to use a TACACS server for user authentication.
For information on how to use TACACS without modifying scripts, refer to "Enable Standard and Extended TACACS or AAA/TACACS+ for ARA Authentication" earlier in this chapter. For information about the arap commands, refer to the Access and Communication Servers Command Reference.
If you are currently using modified CCL scripts and want to migrate to nonmodified scripts, see "Configure to Use Modified and Unmodified Scripts Example" at the end of this chapter for information on how to use both in the same environment.
For several popular modems, we provide CCL files that you can use as examples to modify your CCL scripts to support TACACS security. This section explains how to use the CCL files provided by us to modify AppleTalk Remote Access CCL scripts to work with TACACS security.
We recommend using the ARA Modem Toolkit provided through the AppleTalk Programmers and Developers Association (APDA); it provides both syntax checking and a script player.
AppleTalk Remote Access CCL scripts are used primarily with modems to make connections to remote machines. When the connection has been established, the script ends and ARA is activated. TACACS authentication occurs after the connection is established but before the protocol becomes active.
Insert TACACS logic just before the end of a script. The CCL TACACS logic performs the following user authentication tasks:
| **before**Because of the underlying structure of the ARA protocol, both modem layer error control and protocol layer error control are disabled during the exchange of username and password. This makes the exchange highly susceptible to line noise, especially at higher baud rates. For this reason, we do not recommend the use of modified scripts, and encourage users to either upgrade to later versions of TACACS or to use the arap use-tacacs single-line command.@@before@@ | Caution **after**Because of the underlying structure of the ARA protocol, both modem layer error control and protocol layer error control are disabled during the exchange of username and password. This makes the exchange highly susceptible to line noise, especially at higher baud rates. For this reason, we do not recommend the use of modified scripts, and encourage users to either upgrade to later versions of TACACS or to use the arap use-tacacs single-line command.@@after@@ |
CCL scripts control logical flow by jumping to labels. The labels are the numbers 1 through 128, and will not necessarily be in sequential order in the script file. The TACACS logic in the Cisco IOS software CCL files have label numbers from 100 through 127. In most environments, you can copy the complete TACACS logic from a sample file.
The steps for creating a new TACACS CCL file are as follows:
Step 1 Copy the TACACS logic from a sample CCL script that contains TACACS logic into the new CCL script.
In most cases, you can insert the TACACS logic at the appropriate place in your CCL script. The one case that requires extra attention is when the original CCL script has labels that conflict with the logic in the new file. The labels must be resolved on a case-by-case basis, usually by changing the label numbers used by the original script. This is a fairly simple programming job, but you should read and understand the manual that comes with the Modem Toolkit before beginning.
Step 2 Locate the logical end of the script and insert the command jump 100.
You can locate the logical end of the script by following its flow. Most scripts have the following basic structure:
The characteristic logical end of the script is as follows:
It is common in this case to replace "pause 30" with "jump 100." In fact, this is usually the only change made to the logic of the original script.
To configure a line to use a TACACS server for user authentication, perform the following task in line configuration mode:
| Task | Command |
|---|---|
| Use a TACACS server for user authentication. | login tacacs or login authentication {default | list-name} |
Use the login tacacs command in TACACS and Extended TACACS. Use the login authentication command in AAA/TACACS+. Figure 14-6 shows the TACACS login screen on the Macintosh.
Figure 14-7 shows the TACACS password screen on the Macintosh.
Refer to the chapter "Managing the System" earlier in this publication, or the chapter "System Management Commands" in the Access and Communication Servers Command Reference publication for information about configuring a line to support your modem.
To display information about a running ARA connection, perform the following task in privileged EXEC mode (reached by entering the enable command and a password):
| Task | Command |
|---|---|
| Display information about a running ARA connection. | show arap [line-number] |
The show arap command with no arguments displays a summary of ARA traffic since the access server was last booted. The show arap command with a specified line number displays information about the connection on that line.
The access server software provides several commands you can use to monitor an AppleTalk network. In addition, you can use Apple Computer's Inter·Poll, which is a tool to verify that an access server is configured and operating properly. Use the commands described in this section to monitor an AppleTalk network using both access server commands and Inter·Poll.
To monitor the AppleTalk network, perform one or more of the following tasks:
To debug ARA connections, perform the following tasks in privileged EXEC mode:
This section contains the following examples of ARA configuration on the access server.
The following example configures the interface for an extended AppleTalk network. It defines the zones Orange and Brown. The cable range of one allows compatibility with nonextended AppleTalk networks.
Router(config)#appletalk routingRouter(config)#interface ethernet 0Router(config-if)#appletalk cable-range 69-69 69.128Router(config-if)#appletalk zone OrangeRouter(config-if)#appletalk zone Brown
The following example configures an extended network in discovery mode. In Figure 14-8, communication server A provides the zone and network number information to the interface when it starts.
Use the following commands to configure this extended network in discovery mode:
appletalk routing interface ethernet 0 appletalk cable-range 0-0 0.0
The following example configures the access server for ARA support, as described in the comments (lines beginning with an exclamation point [!]).
! Enable AppleTalk on the access server appletalk routing ! interface Ethernet 0 ip address 172.30.1.1 255.255.255.0 ! ! On interface Ethernet 0, assign network number 103 to the physical cable and ! assign zone name "Marketing Lab" to the interface. Assign a zone name if ! you are creating a new AppleTalk internet. If the internet already exists, ! the zone and cable range must match exactly, or you can leave the cable ! range at 0 to enter discovery mode. The suggested AppleTalk ! address for the interface in this example is 103.1 interface Ethernet 0 appletalk cable-range 103-103 103.1 appletalk zone Marketing Lab ! Configure a username and password for the access server. username jake password sesame ! On lines 4 through 8, InOut modems are specified, the lines are configured ! to automatically start an EXEC session or enable AppleTalk, AppleTalk Remote ! Access Protocol is enabled, the modem speed is specified as 38400 bps, and ! hardware flow control is enabled. line 4 8 modem InOut autoselect arap enabled speed 38400 flowcontrol hardware
Note that you must set your terminal emulator to match the speed that you set for the line.
The following example enables a Macintosh client running ARA on a remote network to connect across an X.25 network, through the access server, to an AppleTalk network. In this example, VTY lines 0 through 19 are configured for ARA.
Router(config)#appletalk routingRouter(config)#line vty 0 19Router(config-line)#arap enableRouter(config-line)#autocommand arapRouter(config-line)#arap dedicatedRouter(config-line)#arap timelimit 45Router(config-line)#arap warningtime 5Router(config-line)#arap noguestRouter(config-line)#arap require-manual-passwordRouter(config-line)#arap net-access-list 611
The Macintosh client connects to any VTY line from 0 through 19. When the EXEC prompt appears, ARA begins automatically on the line (because of the autocommand arap command). The VTY lines 0 through 19 are dedicated to ARA dial-in clients, and those clients have a 45-minute time limit. Five minutes before the line is disconnected, a warning message appears, indicating that the session will be disconnected in five minutes. Guest access is denied, and manual password entry is required. The AppleTalk access list 611 has been applied to the VTY lines, meaning that access to other networks through these VTY lines has been limited.
In the following example, the cable range is changed and the zone name is reentered.
The initial configuration is as follows:
appletalk cable-range 100-103 appletalk zone Twilight Zone
The cable range is expanded as follows:
appletalk cable-range 100-109
At this point, you must reenter the zone name as follows:
appletalk zone Twilight Zone
The following example illustrates MacIP support for dynamically addressed MacIP clients with dynamically allocated IP addresses in the range 172.16.8.2 to 172.16.8.10:
! Specify server address and zone appletalk macip server 172.16.8.1 zone Snark ! Specify dynamically addressed clients appletalk macip dynamic 172.16.8.2 172.16.8.10 zone Snark ! ! Assign the address and subnet mask for Ethernet interface 0 interface ethernet 0 ip address 172.16.8.1 255.255.255.0 ! ! Enable AppleTalk appletalk routing ! interface ethernet 0 appletalk cable range 69-69 69.128 appletalk zone Snark ! ! Specify server address and zone appletalk macip server 172.16.8.1 zone Snark ! ! Specify dynamically addressed clients appletalk macip dynamic 172.16.8.2 172.16.8.10 zone Snark
The following example illustrates MacIP support for MacIP clients with statically allocated IP addresses:
! Assign the address and subnet mask for Ethernet interface 0 interface ethernet 0 ip address 172.16.8.1 255.255.255.0 ! ! Enable AppleTalk appletalk routing ! interface ethernet 0 appletalk cable range 69-69 69.128 appletalk zone Snark ! Specify the server address and zone appletalk macip server 172.16.8.1 zone Snark ! Specify statically addressed clients appletalk macip static 172.16.8.11 172.16.8.20 zone Snark appletalk macip static 172.16.8.31 zone Snark appletalk macip static 172.16.8.41 zone Snark appletalk macip static 172.16.8.49 zone Snark
In the following example for TACACS and Extended TACACS, line 1 is configured for ARA and username authentication is performed on a TACACS server:
line 1 login tacacs arap enable
In the following example of AAA/TACACS+, line 1 is configured for ARA and username authentication is performed on a TACACS server:
line 1 login authentication arap authentication
The following example shows regular TACACS enabled for ARA authentication:
line 3 arap use-tacacs
The following example shows AAA/TACACS+ enabled for ARA authentication:
line 3 aaa authentication arap
In the following example, line 2 is configured as a dedicated ARA line, user authentication information is configured on the ARA server, and guests are disallowed from making ARA sessions:
username jsmith password woof line 2 arap dedicated arap noguest
In the following configuration, ARA is enabled on lines 2 through 16, username authentication is configured on the ARA server, and the lines are configured to automatically start an ARA session when an ARA user on a Macintosh attempts a connection:
username jsmith password woof line 2 16 autoselect arap enabled arap noguest
If you are currently using modified CCL scripts and want to migrate to nonmodified scripts, you can set your system to accept logins using both modified (CCL) and unmodified scripts by entering the following commands in line configuration mode:
!
! recognize a user trying to start an ARAP session with an unmodified script
!
autoselect arap
!
! don't require a "return" to get a Username: prompt from the line, so that
! modified scripts will see the prompt they normally expect.
!
autoselect during-login
!
! allow guest arap logins if the user has already authenticated (via the modified
! script at the Username: and Password: prompts), but disallow them if the user
! has not (is coming from an unmodified script).
!
arap noguest if-needed
!
The following example shows how to set up ARA functionality on an access server.
Log in to the access server, use the enable command to enter your password if one is set, use the configure command to enter configuration mode, and add the following commands to your configuration:
appletalk routing interface ethernet 0 appletalk cable-range 0-0 0.0 ! putsaccess server in discovery mode line 5 6 modem inout speed 38400 arap enabled autoselect
If you already know the cable-range and the zone names you need, include the information in the configuration file. If you do not know this information, let the access server learn about the AppleTalk network in discovery mode by following these steps:
appletalk cable-range 105-105 105.222 appletalk zone Marketing Lab ! Do not use quotation marks in this entry username arauser password arapasswd ! Add as many users as you need
The following example describes how to set up a Telebit T-3000 modem that you are attaching to an access server, which supports hardware flow control. The Macintosh will use a CCL script to configure the attached modem.
Start with the modem at factory defaults. (AT&F9 is the preferred configuration for hardware flow control. Use the direct command if you have a terminal attached to the modem, or use the T/D Reset sequence described in the Telebit T-3000 manual to reset the modem to the &F9 defaults.)
Attach a hardware flow control-capable cable between the modem and the device with which you are configuring the modem. (At this point, the modem is in hardware flow control mode, with auto-baudrate-recognition, and can detect your speed between 300 and 38,400 bps at 8-N-1. However, the modem must receive the flow control signals from the device to which you have the modem attached.)
Send the modem the following commands:
ATS51=6 E0 Q1 S0=2 &D3 &R3 S58=2 &W
This sequence tells the modem to perform the following tasks:
At this point, if you press the carriage return or type characters, no characters appear on your screen because the result codes are turned off. You can determine whether the modem is working by getting a list of its configuration registers using the following command:
AT&V
After the modem is configured, connect it to the access server with a modem-to-RJ45 adapter and an RJ-45 cable to the lines(s) that you plan to use.
The following commands are compatible with the Telebit 3000 settings described in this section:
arap enable
autoselect
no escape-character
flowcontol hardware
modem ri-is-cd
speed 38400
|
|