There is nothing more important than our customers.
Skip to content
Network Access Software
Version 2.3B.01
June 1999
----------------------------------------------------------------------------
INTRODUCTION:
----------------------------------------------------------------------------
Cabletron Network Access Software, Version 2.3B.01 is the embedded software
that runs on the Access Server 316 asynchronous device server, as well as on
the DECserver 90M, 700-series and 900-series asynchronous device servers.
Included with Cabletron Network Access Software (CNAS), Version 2.3B.01 are a
number of addition optional software programs which work with the CNAS V2.3B
software but which run on other systems, not the Access Server itself. These
programs include Access Server Manager, Access Server Loader, Cabletron
RADIUS Server, and HarvestD. These programs are described separately within
these release notes.
Access Server units are communications servers for Ethernet LANs. They
support remote PC dialup access for IP, IPX, and AppleTalk networks. They
also provide a convenient method to logically connect asynchronous terminals,
personal computers, and other asynchronous devices using LAT, Telnet or
Rlogin to one or more service nodes (hosts) on an Ethernet. Once the
terminal, asynchronous device or PC is connected, a user can use application
programs and utilities as though the device is directly connected to a host.
Thus, it may be possible to use the Access Server to connect all terminals to
service nodes in place of traditional interfaces.
It is recommended that one thoroughly review this release note prior to the
installation or upgrade of this product.
----------------------------------------------------------------------------
Firmware Specification:
----------------------------------------------------------------------------
Status Version No. Type Release Date
Current FlashRAM Version 2.3B.01 Customer June 1999
Current CD-ROM Version 2.3B Customer April 1999
Previous Version 2.3A DIGITAL brand November 1998
release
----------------------------------------------------------------------------
HARDware compatibility:
----------------------------------------------------------------------------
All versions of the Access Server are supported. The DECserver 90M,
700-series and 900-series units are also supported.
----------------------------------------------------------------------------
BootPROM compatibility:
----------------------------------------------------------------------------
ROM Version 7.2 on Access Server 316 and DECserver 700 or 900 series units
is required to support all features. ROM Version 5.1 on DECserver 90M units
is required to support all features. Earlier version ROM firmware may be used
with some reduction in feature support.
----------------------------------------------------------------------------
Network Management Software Support:
----------------------------------------------------------------------------
NMS Platform Version No. Module No.
Access Server Manager 2.3B N/A
ClearVISN (Element Manager) 3.0 N/A
If you install this image, you may not have control of all the latest
features of this product until the next version(s) of network management
software. Please review the software release notes for your specific network
management platform for details.
----------------------------------------------------------------------------
SUPPORTED FUNCTIONALITY:
----------------------------------------------------------------------------
Features Support
ARP YES
ATCP (AppleTalk Control Protocol) YES
BootP YES
CHAP YES
DHCP YES
DNS YES
IPCP (Internet Protocol Control Protocol) YES
ICMP YES
IP YES
IPXCP (Internet Packet Exchange Control Protocol) YES
Kerberos V4 YES
LAT YES
LPD YES
PAP YES
PPP YES
RADIUS Client/Server(*Server not included in this release.) YES
Rlogin YES
SLIP & Compressed SLIP YES
SNMP YES
TCP YES
TCP/IP Keepalive Timer YES
TELNET client & Server YES
TFTP and Directed TFTP YES
TN3270 YES
Local and remote Management via TELNET YES
Remote management via Windows GUI YES
UDP YES
Van Jacobson header compression YES
WINS YES
PC Dialup Remote Access Support
The Cabletron Network Access Software provides remote connectivity to IP
networks via SLIP (Serial Line Internet Protocol), CSLIP (Compressed SLIP),
and via PPP (Point-to-Point Protocol). As many IP systems as there are serial
ports on the Access Server unit may be connected. These systems can run IP
applications (such as Telnet, FTP, X-Windows, and so on) on the serial line
and communicate with other IP services on the network. The Access Server
software also routes IP datagrams between asynchronous SLIP or PPP ports.
Access Server units support host multiplexing for attached Novell NetWare
clients. NetWare clients may attach directly to the Access Server via
asynchronous lines or may dial into the Access Server. The Access Server uses
IPXCP and PPP to establish an asynchronous link between the remote NetWare
client and the Access Server. Once established, the Access Server provides a
transparent link to the network for asynchronously connected clients. Each
asynchronously attached client looks and acts as if it were directly
connected to the local area network (LAN).
The Access Server software supports host multiplexing for attached AppleTalk
hosts. The Access Server software acquires and assigns AppleTalk addresses
for attached hosts via AARP and PPP. The Access Server unit uses the AARP
protocol to acquire a new address for a connecting host, and it uses the PPP
ATCP protocol to assign this address to the host. The Access Server keeps a
cache of already acquired addresses to optimize the connection process. The
system administrator can configure the address cache size.
Access Server units using either SLIP or PPP can be configured to provide
asynchronous communications between two LANs for hosts supporting TCP/IP.
This support requires that manual routing table entries be made for all hosts
that need to communicate across the wide area link. Once table entries have
been made, hosts use the Access Server port like a gateway. Since the routing
entries are static, there is no forwarding or fallback in the event the
Access Server link is broken. This feature provides a low-cost wide area
network (WAN) link appropriate for smaller remote LANs.
AUTOLINK -- This feature provides a generic asynchronous serial data link
connection (or session) for dial-in ports. This feature allows a system
administrator to configure a dial-in port to service PPP and SLIP framed
protocol users and interactive terminal users with minimal user interaction.
An AUTOLINK session examines characters received from the attached device. If
a PPP or SLIP packet is detected, the current session will attempt to change
itself into the corresponding type of data link session, PPP or SLIP. If
AUTOLINK does not detect a PPP or SLIP start frame character, it will select
character-cell terminal emulation.
Dynamic Host Configuration Protocol (DHCP) -- DHCP is a combination of four
IETF RFC's, which together enable automatic and reliable distribution of IP
addresses. CNAS V2.3B.01 support for DHCP allows the Access Server to operate
as a DHCP proxy to obtain a leased IP address for a remote client from a DHCP
server on the network. The Access Server maintains the address on behalf of
the remote client for the duration of the session. This feature eases the
network manager's job by letting the DHCP server automatically provide IP
addresses for each port as needed, rather than having to assign and maintain
permanent IP addresses for each Access Server port. The Access Server itself
does not learn its IP address from a DHCP server.
Inactivity Timer -- Access Server software supports an inactivity timer for
SLIP- and PPP-based connections. Inactivity can be monitored on a server-wide
or per-port basis. When the configurable inactivity threshold is exceeded,
the CNAS Version 2.3B.01 software automatically tears down the SLIP or PPP
connection. The inactivity timer ignores normal keepalive or maintenance
messages, such as PING, counting only data traffic as activity.
WINS auto-configure support -- The Windows Internet Name Service (WINS)
provided by Microsoft with Windows NT and Windows 95 provides a distributed
database for mapping NetBIOS names to IP addresses. WINS is often used in
combination with DHCP so that dynamically assigned IP addresses can be
automatically updated in the WINS database. WINS requires a WINS server (that
is, a Windows NT server) and a WINS client (Windows for Workgroups, Windows
95, or Windows NT workstation). This feature on the Access Server allows
dial-up clients to receive WINS configuration information automatically when
a PPP connection is initially established.
WAN Communications for Terminals
For WAN communications, terminal users can connect to remote hosts via
Telnet through a TCP/IP router or gateway. In addition, terminal users can
connect to a local service node running DECnet, where they can "SET HOST" to
a remote system via the DECnet network terminal protocol. If this system has
the requisite X.25 or SNA 3270 access routines, a terminal user could
communicate to a remote SNA or X.25 host through the appropriate gateway and
this intervening host. An Access Server terminal user cannot communicate
directly to remote hosts through DECnet routers or X.25/SNA gateways. WAN
traffic will not provide the same high level of performance as local terminal
connections due to the additional DECnet or Internet protocol overhead. The
Access Server unit units support connections to WANs via modems.
Security Features for Remote Access User Authentication
Server-wide Login Passwords -- A server-wide login password can be enabled
by the system administrator. If enabled, the terminal user must enter a login
password to access server functions. Login password provides low-level, basic
security.
PAP -- Password Authentication Protocol (PAP) is the password scheme
supported by PPP. PAP uses an ID/password pair. PAP ID/passwords may be
stored in the Access Server unit, or may be stored in a separate
authentication service such as Kerberos V4 or RADIUS.
CHAP -- Challenge Handshake Authentication Protocol (CHAP) is a PPP-based
challenge/response authentication scheme. If enabled, users accessing the
Access Server unit via applications supporting CHAP may use the PPP CHAP
scheme, with passwords stored on the Access Server unit or with RADIUS.
Local User Accounts A limited amount of user authentication information may
be entered directly into the Access Server non-volatile memory. This may be
useful when a smaller number of users need authentication or where a shared
authentication service is not available. Local user accounts support both
PAP, CHAP and interactive authentication.
Kerberos Authentication -- Provision for user authentication is included in
the Access Server software using Kerberos V4. In addition, users may change
their Kerberos passwords (stored on the Kerberos master database) remotely
from the Access Server unit. User authentication is a security feature that
requires a user to enter a valid user name and password pair before being
allowed to log in to the Access Server. The user must have been previously
registered (user name and password) with a Kerberos Key Distribution Center
on a host running the Kerberos server software. This effectively gives users
on the network their own password to log in to the network through the Access
Server, using Kerberos. Kerberos uses the Data Encryption Standard to
authenticate its messages over the network. No Kerberos passwords are
transmitted in the clear.
Kerberos Authenticated PAP -- The Access Server software allows a PPP
Password Authentication Protocol user name/password pair to be directly
forwarded to a Kerberos V4 Key Distribution Center for authentication without
the need for an interactive login process, but directly from the PPP login.
Dial-back Authentication -- CNAS supports a dialer service that allows both
mandatory and interactive dial-back. The dialer service is made up of
configurable "dial service" parameters that control how a user may use the
dialer service, and a dialer engine responsible for processing the outbound
request and placing the port into a desired state upon successful call
completion. User profile information required to support the dialer service
and dial-back may be stored either directly in the Access Server unit for a
limited number of users, or may be obtained from the RADIUS user profile
database. CNAS supports both standard Call Back Control Protocol and
Microsoft's Call back Control Protocol for Windows 95 and Windows NT clients.
The Access Server automatically supports either type when configured for dial
back.
RADIUS Attributes Supported in this Release -- Please refer to the document
RADIUS_SURVIVAL.TXT on your kit distribution media for a description of the
supported RADIUS Attributes for this release.
RADIUS Authentication and Authorization -- CNAS includes a RADIUS client
application that conforms to IETF RFC 2138 and RFC 2139. RADIUS is an
Internet standard that describes an open protocol for communicating
authentication, authorization, and accounting data between remote access
servers and shared authentication servers. The RADIUS client is interoperable
with other RADIUS server implementations, and is supported when used with the
Cabletron RADIUS Server (C-RADIUS) application included on the CNAS CD-ROM.
SecurID -- CNAS includes ACE/Server Client Code support for the Security
Dynamics ACE/Server system. The ACE/Server Client Code included with the CNAS
software provides encrypted, token-based, two-factor authentication using
one-time passcodes. CNAS code includes both an SDI-developed encryption
algorithm and a DES encryption algorithm. Users can select the appropriate
algorithm based on the ACE/Server available from Security Dynamics in their
geography. The CNAS Version 2.3B.01 client supports Version 1.3 through
Version 2.3 of the Security Dynamics ACE/Server.
Additional Access Control Features
The Access Server unit provides functions that enhance security features
already available in the service nodes. Access Server security includes the
ability to lock a terminal's keyboard from other users, optional login
protection, and non-privileged local mode of operation as a default.
A user may lock the terminal by using a lock password. This allows the user
to leave sessions running at the terminal without fear of security
violations. When a terminal is locked, all input from the terminal is ignored
until the lock password is reentered. The lock feature may be disabled by the
system administrator.
Each terminal port can be set up to operate in a secure mode, which causes
all commands that relate to other users to be disabled for that port.
Access Server users usually have access to the non-privileged local mode. In
this mode, users may only issue commands that affect their own terminal
environment. The server has a privileged mode for system administrator's use.
The mode is password protected. The system administrator can further restrict
nonprivileged and secure ports by enabling the LIMITED VIEW characteristic,
which prohibits users from viewing tables of LAT nodes, LAT services, and
certain Internet databases.
The system administrator can restrict the port user to a predetermined set
of commands by creating a command menu with these commands in it, and
defining this menu as the default menu on the port. In this case, the menu is
automatically entered when the user logs into the port. The user cannot exit
from the menu, except to log out of the port.
Groups (LAT) -- Every terminal and service node in a LAT network is a member
of one or more groups specified by a list of numbers from 0 to 255. Groups
allow an easy means of subdividing the network into what appears to be many
smaller networks. A terminal user is only aware of the services that are
offered by nodes in the same group(s). The system administrator can specify
the authorized group(s) in which a terminal is a member. The authorized
groups define the set of services that the user is allowed to access. In
addition, for those nodes that implement group codes, a user can further
limit access to services by disabling some of the authorized groups using a
non-privileged group command. The user-settable group codes are a subset of
the authorized groups. Groups provide a restrictive view of the network. This
restricted view is mainly for user convenience. Groups apply only to LAT
connections.
Terminal to Host Support
The Cabletron Network Access Software provides concurrent local area
terminal (LAT) and Telnet or Rlogin TCP/IP protocol support from an Access
Server communications server to enable connectivity to host systems that use
LAT or TCP/IP protocols. The TCP/IP protocol suite is used to connect to UNIX
host systems and other host systems that support the TCP/IP protocol suite.
The TCP/IP protocols are based on the University of California's 4.3 Berkeley
Software Distribution (BSD).
Remote login client (Rlogin) -- The Rlogin protocol, described in
informational RFC 1282, allows users to log onto a remote computer (similar
to Telnet). Rlogin supports pre-authenticated sessions on hosts that have
been configured with trust relationships. This allows users to connect to
those hosts without needing to enter a username and password.
3270 Terminal Emulation -- allows the users of an ANSI video terminal or PC
in terminal emulation mode (VT100, VT200, VT300, VT400 mode) within an
Internet network, to interactively access IBM host-based applications
developed for IBM 3270 display stations. TN3270 server-wide key-mapping is a
feature that allows the network manager to make up to six customized terminal
types and associated key-mappings available on the server. An individual port
can access any one of these key-mappings without using up additional NVRAM.
The port user chooses one of the terminal types with the SET PORT TN3270
TERMINAL command.
Auto-connection Auto-connection is a function that automatically connects a
user terminal to a service node when connection failures occur or upon user
login to the server. In conjunction with this function, a dedicated or
preferred service can be specified for each terminal user.
If a dedicated service is specified, the Access Server unit will attempt to
connect to that service when a character is typed on the terminal keyboard or
when an existing connection fails. In dedicated service mode, only one
session is available. As this mode is designed to simulate a direct terminal
connection, no local mode commands or messages are available to the terminal
user. Ports with dedicated service can be automatically logged out of the
server when the user logs out of the service node.
If a preferred service is specified, the Access Server unit will attempt to
connect to that service as with the dedicated service mode of operation.
However, the terminal user can enter local mode and establish other sessions.
Automatic Protocol Selection
It is possible to automatically connect to an Internet host or LAT service
without explicitly identifying the connection as LAT or Telnet. If the port
is configured with a value for the default protocol as "ANY," the terminal
server will attempt a LAT connection first to the name specified in the LAT
service field. If the service is not available or unknown, the terminal
server will then automatically attempt a Telnet connection to the Internet
host specified in the command.
Automatic Session Failover (LAT) -- If a service is available on two or more
service nodes, and a connection to a service fails, the server will attempt
to connect the user to another service node offering the same service. The
user does not have to be connected to that service node. Furthermore, the
user's context at the time of failure is not automatically restored and login
to the new service is required. This feature is supported only for LAT
connections.
Load Balancing (LAT) -- When a connection is made to a service the actual
node for the connection is determined by load balancing. Load balancing is a
process that the server uses when more than one node offers the same service.
Service nodes do not have to be configured in a cluster in order for load
balancing to be used. Service nodes with the same names may be running
different operating systems. Using the load balancing process, the server
connects to the node with the highest rating for the service desired. This
rating is based on the current loading on the nodes that offer the service.
Multiple Sessions -- The Access Server unit allows each user to establish
and maintain up to eight sessions to one or more service nodes. Only one
session per user can be active at a time. Through simple switching commands,
the user can access the different sessions without repeating a login dialogue
each time. Some operating systems may impose limits on the number of LAT or
Telnet sessions that a host will support.
On-Demand Loading (LAT) -- The Access Server unit implements the ODL
(On-Demand Loading) font-loading protocol, which allows Asian-language
terminals that implement the ODL protocol to communicate with an OpenVMS host
via a terminal server. The Asian-language terminals will be able to request
font definitions from an OpenVMS host when connected to a Access Server. This
feature is supported only for LAT connections.
Outbound Connection Queues (LAT) -- If a terminal user requests a connection
to a service and the requested service is currently in use, the terminal
server users may opt to have the requested connection queued to the remote
service. If the user's port has been appropriately configured, this feature
is performed automatically whenever a connection fails for this reason. The
connection request is queued at the service node end and is processed
first-in/first-out (FIFO) until such time as the user's connection request
can be completed. This feature assists in the fair management of limited
network resources. Once queued for connection, the user also has the option
to cancel the queue entry and proceed with other sessions. This feature is
supported only for LAT connections. Similar functionality may be available
via a print filter program on a Telnet host.
Terminal Device/Session Management Protocol -- The Access Server also
implements and supports the Terminal Device/Session Management Protocol
(TD/SMP) to manage multiple sessions at the device level. The Access Server
provides the ability to communicate with devices that also implement this
protocol (such as VT420, VT330+, or VT340+), and assist in the management of
multiple sessions for these devices. By implementing this protocol, the
Access Server can permit attached devices to maintain screen and keyboard
context for multiple LAT and/or Telnet sessions, as well as allow these
devices to run multiple LAT and/or Telnet sessions concurrently.
The Access Server software will support block-mode transfers of up to 2,048
bytes.
Host to Printer Support
The Access Server unit also allows for host-initiated connections to serial
printers. A serial printer can be shared between LAT print requests and
Telnet requests. Telnet requests cannot be queued on the server. A print
symbiont on service nodes can initiate connections to serial printers
connected to Access Server ports. This allows the printers to be distributed
throughout a facility and accessed transparently by service node users.
Incoming host-initiated connect requests may be queued FIFO at the server.
The Cabletron Network Access Software kit includes software that allows
serial printing from UNIX or Windows NT hosts by using Line Printer Daemon
(LPD). The Access Server listens for print requests from remote hosts on the
Local Area Network and responds to them. The Access Server implementation of
LPD supports printing of ASCII and PostScript files.
UNIX hosts can also use a Telnet print filter that encapsulates the output
of a printer interface program into Telnet format and sends the encapsulated
data through an Access Server Telnet Listener port to the specified printer.
LPD is the recommended method and use of the print filter is not supported.
CNAS also supports raw TCP Listeners for remote printing.
Reverse LAT, Telnet Listener, and TCP Listener
The Access Server unit supports reverse LAT, Telnet Listener, and TCP
Listener. These facilities are provided to enable a network node, such as a
host system, to connect to a Access Server port. This facility could be used
to support printers, a modem pool for outgoing calls, devices such as
point-of-sale terminals or bar-code readers and connection to the
asynchronous ports of a system without other network access, such as an
Ethernet controller. Reverse LAT, Telnet Listener, and TCP Listener also
provide the ability to group physical ports into logical groupings. For
example, ports connected to the asynchronous interfaces of the same system
could be grouped so that a connect request would be routed to any of the
currently unused ports. A logical grouping can contain any number of ports
from one to all of the ports on the server.
The Cabletron Network Access Software allows the Access Server to support
RAW TCP. The Access Server unit can be configured to process TCP traffic
directly without using Telnet options negotiation. This option is supported
for hosts connecting to Access Server unit TCP listeners.
The system administrator can assign an individual IP address per Telnet
Listener. This provides a means to uniquely identify a service per Access
Server port, as needed, using standard DNS name resolution. This eliminates
the need to specify a TCP port number when connecting to services.
Port-to-port connections on the same server are also supported.
Directed TFTP Directed TFTP is a feature that allows the Access Server to
load from a single, pre-specified TFTP server. Once configured for Directed
TFTP, the Access Server ROM firmware downloads its operating image from the
specified TFTP server rather than soliciting a response from a BOOTP server.
Directed TFTP makes it easier for the Access Server to obtain an operating
image over the wide area network (WAN). Directed TFTP requires a minimum ROM
firmware revision of V5.1 for the DECserver 90M and V7.1 for all other
supported access server platforms.
Gateway Failover Access Server units are able to detect whether the default
gateway has gone out of service, and are able to locate and use other
gateways (if available and configured).
TCP/IP Keepalive Timer (RFC 1122) -- The TCP keepalive timer determines
whether a TCP connection with a remote host is active and should remain open.
After a TCP connection is established, the TCP/IP keepalive timer waits a
configurable length of time and then sends a probe to the remote host. If the
remote host responds, the TCP keepalive timer waits again. If it does not
receive a response, it continues to send probes until a set maximum is
reached. If the host does not respond after the last probe is sent, the
access server drops the connection.
Accounting and Billing
The Access Server unit running CNAS supports two accounting methods. One is
an SNMP-based UNIX utility called HarvestD. The other is via Remote Access
Dialup User Services protocol (RADIUS).
Access Server Accounting Log -- Access Server memory can be reserved for
storing significant user events, such as logins, session connects, password
failures, and more, so that the unit itself contains a log of accounting
events. These events can be useful in supporting capacity planning, audit
trails, billing, and connection troubleshooting. These events can be browsed
via an SNMP management station or via the access servers command line user
interface. The accounting log will store all events until the user-selected
buffer size is exceeded. Once the buffer size is exceeded, the oldest event
will be dropped and the newest added. Accounting events can also be sent, as
they occur, to a physical console port where they can be displayed on a
connected terminal/printer or redirected to a remote connection. To print or
display events as they occur does not require that any Access Server memory
be reserved.
An accounting threshold variable can also be set that will notify a
potential harvester application to begin reading entries before the
accounting log is full. These notifications are in the form of SNMP traps.
HarvestD --The harvestd utility provides reliable logging of accounting
events. The Access Server unit logs accounting events in its volatile memory.
Harvestd reliably copies these logs to a host's disk. The harvestd
application is provided in C-language source code format, can easily be built
for many types of UNIX systems, and is provided as an unsupported utility.
RADIUS Accounting -- The CNAS software includes a RADIUS (RFC 2139) client.
The RADIUS client is capable of generating accounting information for
significant user actions including logins, session connects and services
used. For a complete description of the RADIUS and RADIUS Accounting
attributes supported in the Access Server, refer to the RADIUS Survival
Guide, provided as an ASCII text file on the CNAS CD-ROM distribution media.
Access Server Management
The Access Server unit supports several facilities supporting both local and
remote management. These include the command line interface, the console
port, the remote console port, and Access Server Manager. Protocols that are
used to manage the Access Server include MOP, Telnet, and SNMP.
Management via the console port using the command line interface (CLI) -- an
environment using the CLI is a logical extension of the user environment. The
system administrator is a server user with a privileged status. The system
administrator sets a terminal to this status using a command that requires a
password. This privileged status allows the system administrator to enter
commands not usually available to server users. These commands set server
characteristics, provide control over server port usage, and provide the
ability to control the user's access to the server and network services.
In service mode, the terminal input is passed directly to the connected
service node with several exceptions. One exception, called the local switch
character, allows the user to enter local mode from service mode. The
key may also be used for this function. Other exceptions, called the forward
and backward switch characters, allow the user to switch between sessions
without the need to enter local mode. The switch characters are disabled by
default but may be enabled by command. Both CTRL/S and CTRL/Q are usually
interpreted locally, but flow control using these characters can be disabled.
Remote management of the Access Server unit using the CLI -- The Access
Server unit implements the console carrier feature that enables access to the
Access Server local mode from either a Telnet host or from a Phase IV or
Phase V DECnet host on the same LAN. With the exception of remote console
port configuration, the entire local mode user interface is accessible to the
remote console carrier user. This includes the privileged commands if the
user knows the server's privileged password. This capability allows
centralized server management and remote server diagnosis.
The Telnet remote console feature is also available and can be used to
support remote server management as stated above.
Management of the Access Server unit using Access Server Manager (ASM) --
The Access Server Manager application runs on 32-bit Windows-based operating
systems and has a graphical user interface that allows easy configuration of
many access server features. The Access Server Loader application is
integrated with Access Server Manager. Access Server Manager supports the
following functions:
- Download firmware from a PC load host to the access server
- Download IP address configuration information to the access server
- Configure the access server network protocols
- Configure ports for remote access and terminal server functions
- Configure modems attached to Access Server port
- Configure access server security
- Configure access server dialer services
- Make a Telnet console connection to an access server and issue commands
Management of the Access Server unit using SNMP -- The Access Server unit
has an SNMP (Simple Network Management Protocol) agent that allows it to be
managed by an SNMP network management system such as the ClearVISN element
manager. Information can be retrieved (GET) and modified (SET) from the
server.
Local Mode and Service Mode
For the most part, the environment provided by the Access Server unit is
identical to the environment that the user would experience if attached
directly to the service node. When operating in this mode, the user is said
to be in service mode. Occasionally, such as during connection establishment,
the user interacts directly with the Access Server. When operating in this
mode, the user is in local mode.
In local mode, the terminal input is interpreted directly by the software as
commands to be performed by the server. Local mode has three different levels
of privilege: privileged, non-privileged, and secure.
- Privileged mode is provided for the system administrator to control the
environment of the server and the terminal users. Access to this mode is
password protected.
- Nonprivileged commands allow the terminal user to control their service
sessions, set the terminal characteristics, and show server information.
- The system administrator can set the server to secure mode on a
per-terminal basis, which further limits the commands that users can enter to
only those that directly relate to the user's own terminal.
Management and Ease of Use
Online HELP Facility -- A full online reference HELP facility is available.
The server's HELP command provides information on the correct syntax and
details about each command. In addition, a tutorial HELP feature allows new
users to quickly learn the basics of Access Server operation. Tutorial HELP
may be entered upon logging into the server. HELP is based on whether the
user is secure, nonprivileged, or privileged.
Command Prompting -- The command prompting feature allows users to solicit
specific help
based upon where they are in the command sequence. The user types a question
mark and is presented with a list of next possible commands or keywords.
Command Groups -- The command group feature allows users to define their own
command word(s), which, when invoked, will execute a sequence of stored
server commands.
Command Line Recall and Editing -- The Access Server unit supports multiple
command line entry recall and editing.
Customized Menus -- This feature allows the privileged user to create a
customized menu style user interface rather than the command line interface.
Directory Service (LAT) -- Any Access Server user can obtain a directory of
LAT services available to that user with a SHOW SERVICES command. Services
for which the user is not authorized will not be displayed. Services apply
only to LAT connections.
Welcome Identification -- The Access Server unit standard welcome banner,
which includes server type, version number, and internal base level, is
issued whenever a user successfully logs in to the server. The server will
also print a Server-Manager-settable identification string. This can be
useful for automatic server identification or for small daily messages used
for communications with the Access Server users.
Troubleshooting Facilities
Several facilities exist for managing and troubleshooting server operation.
The system administrator in privileged mode can set up server identification
information, change port characteristics, or fine-tune the operating
characteristics of the server. Troubleshooting facilities include diagnostic
tests, a remote console feature, and online statistics.
A privileged user can diagnose Ethernet communications problems by looping
messages to an Ethernet host and through the Ethernet hardware interface at
the server. To diagnose terminal problems, users can execute a command to
transmit test data to their terminal, or the Server Manager can send test data
to any terminal.
The capability also exists for the system administrator to test a service
connection by sending data from the initiating port to the service node, and
then back again. The data is then compared and any discrepancies reported. At
the service node, the data can be looped back by the LAT protocol, or
internally or externally at the service port. This feature is supported only
by Access Server service nodes; OpenVMS service nodes do not support this
service loopback capability.
The server maintains a variety of statistics and counters. These include the
following: Ethernet data link statistics, LAT protocol statistics, port
character counters, and port error statistics. This data can be displayed and
zeroed by the system administrator. Server parameters that can be modified
and displayed include the server identification, circuit timer, session
limits, and login limits.
Internet statistics are also maintained by the server. Internet
characteristics such as Internet address and subnet mask can be modified and
displayed. IP, ICMP, TCP, IP, UDP, DNS, and SNMP protocol statistics can be
displayed.
Permanent Characteristics
The Access Server unit maintains permanent characteristics in nonvolatile
memory, which is retained even when the power is disconnected. Permanent
characteristics are maintained for service and server parameters, as well as
per-port parameters. Permanent characteristics can be reset to factory
defaults by pressing the software reset button on the hardware unit at the
power is applied to the unit.
Port Characteristics Configuration
Characteristics governing the operation of an individual port can be
displayed by a non-privileged terminal user interactively from the user's
terminal. Many of the characteristics may be set by the user, but certain
characteristics are privileged and may only be changed by the system
administrator.
Port parameters that can be set and displayed include: speed, character
size, group codes, parity, terminal type, access, autobaud, default protocol,
and password protection.
Port Access
Port access is the characteristic that determines how a port may access or
be accessed by interactive users and service nodes. A port on an Access
Server unit may be configured in different ways depending on the device
attached to the port and its intended use.
* Access Local-Designed for interactive terminals. This allows the device
(typically an interactive terminal) attached to the port to CONNECT to LAT or
Telnet. Additional example: dial-in modem.
* Access Remote-Designed for application-driven devices such as asynchronous
printers that are allocated by a service node process. This allows the
implementation of certain shared printers by multiple service nodes.
Additional example: dial-out modem.
* Access Dynamic-Designed for devices (such as personal computers or
printers with keyboards) that require both local and remote access.
Additional example: dial-in/dial-out modem.
* Access None-Designed to allow the system administrator to disable the use
of a port.
With printer support capabilities, the configuration procedure of remote
printers needs to be done once and will be automatically reconfigured on
system startup. The particular server port must be configured for remote
access and set up to match the characteristics of the printer. Improved
printer sharing allows a printer on the server to be shared among hosts using
LAT and hosts using Telnet.
Access Server Initialization
The Access Server ROM-based firmware provides the necessary maintenance
operation protocols for downline loading Access Server software from a TCP/IP
host via BOOTP/TFTP, or from a Phase IV or Phase V DECnet load host over the
Ethernet into server memory should that be desired. The Access Server
software is normally loaded from nonvolatile memory (Flash RAM) incorporated
in the Access Server hardware. The Access Server software come pre-loaded in
Flash RAM. All self-test diagnostics are in Access Server ROM and are
executed on power-up prior to downline loading the server. In the event of a
bugcheck caused by a fatal error, the unit will normally attempt to upline
dump server memory to the load host. The upline dump is via either BOOTP/TFTP
or MOP. Following this, the unit will automatically initialize itself and
invoke a downline load.
----------------------------------------------------------------------------
Installation and Configuration Notes:
----------------------------------------------------------------------------
The Access Server is shipped pre-configured with the latest version of
software in Flash RAM. The CNAS-KIT CD-ROM package included with the Access
Server includes a backup copy of the pre-loaded operational code as well as
the software documentation and optional software utilities. If you would like
to upgrade an existing Access Server , please contact your local sales
representative to order a new CD-ROM kit. Please note that the latest
software version for use in Flash RAM is Version 2.3B.01, while Version 2.3B
is the version included on the CD-ROM. Customers who load their Access Server
from Flash RAM should not replace the factory-provided Version 2.3B.01 load
image with the Version 2.3B load image from the CD-ROM.
Software Requirements
When a new firmware release becomes available, the Access Server units rely
on network hosts to download and update the server software image stored in
Flash RAM. Supported operating systems for load hosts include; OpenVMS VAX,
OpenVMS Alpha, DECnet/OSI for OpenVMS, Windows NT, Windows 95, DIGITAL UNIX,
as well as many generic UNIX operating systems. The following table lists the
minimum version of these operating systems that are supported load hosts. In
general, all later versions of these operating systems can provide load host
support. However, support for all later versions is not guaranteed.
Supported Operating System Minimum Version
DECnet OSI for OpenVMS Version 5.5
Digital UNIX Version 1.0
Windows 95 N/A
Windows NT Version 3.51
OpenVMS VAX Version 5.0
SunOS Release 4
IBM AIX Version 3.1.1
SCO UNIX System V /386 Release 3.2 V2.0
HP-UX Version 8.0
If you are installing this kit on a UNIX host other than a DIGITAL UNIX
host, ensure that you read the README FILE provided with the installation
kit. It includes examples and hints relevant to the installation procedure,
specifically, the making of CMU BOOTP sources on different UNIX systems and
platforms. Note that the CMU BOOTP sources are provided only as a convenience
to those users that do not have BOOTP in their systems. Cabletron Systems
does not offer any support of the BOOTP sources nor does it provide any
warranties on their operation.
The following information refers to the disk space required on the load
host's system disk. The disk space size is approximate. (Actual sizes may
vary depending on the user's system environment, configuration, and software
options.)
Load host Disk Space Required
Open VMS (VAX and Alpha) Systems 9,790 blocks
DIGITAL UNIX (Alpha) 4,995 M bytes
UNIX 4,772 M bytes
Load host Disk Space Required
Microsoft Windows 8,777 M bytes
+ All Components 1.90 M bytes
+ Access Server Manager 5.54 M bytes
+ Access Server Loader 1.33 M bytes
+ Documentation
----------------------------------------------------------------------------
Firmware Changes and Enhancements:
----------------------------------------------------------------------------
Incorrect IP address assigned when booting from Flash RAM -- When Network
Access Software Version 2.3A or 2.3B boots from Flash RAM on an Access Server
unit that has no IP address defined in NVRAM, the IP address becomes set to a
constant and bogus value of 65.77.0.0. It cannot be cleared (i.e. IP
disabled), but it can be manually changed to a legal value. This affects
DS700, DS900 and AS316 units. DS90TL and DS90M units are not affected. This
problem has been fixed in Version 2.3B.01, which is identified on the Access
Server displays as software base level BL49-62a.
Erroneous Flash RAM status messages Messages pertaining to Flash RAM
programming status were erroneously displayed when an non-compressed software
load image was loaded anytime after a Flash RAM update was performed using a
compressed image. This problem has been fixed in Version 2.3B.01, which is
identified on the Access Server displays as software base level BL49-62a.
The changes and enhancements listed below were introduced in Version 2.3B or
2.3A :
User framed or callback framed login -- This version of software corrects a
problem in which users could not be logged as a framed or callback-framed
user, if the IP address was supplied by the RADIUS authentication host (DHCP
disabled) and no port or client IP address was configured.
Multisession (TDSMP) -- This version of software corrects a problem in which
TDSMP ports would lock-up and had to be manually logged out from another port
to restore operation.This version of software corrects a problem in which
changing a port characteristic when a port is running Multisessions causes
the Local prompt to be displayed in the wrong session window upon command
completion. The problem only occurs if one or more host sessions is receiving
data while the command is being executed from a local session. In addition to
displaying the prompt in the wrong session window both the local session and
the host session hang.
LPD -- This version of software corrects a problem in which LPD will reject
a print command if the filename was larger than 32 characters. RFC 1179
states software needs to support 131 character filenames.
LAT -- This version of software corrects a problem in which intermittent LAT
session delays were experienced when a user was utilizing VMS command type
ahead while the port was receiving data.
Memory leak -- This version of software corrects a problem in which after
multiple weeks of runtime there was no IP connectivity available through the
access server.
Port inactivity timer -- This version of software corrects a problem in
which a local user with inactivity timeout enabled would always be logged out
after 2 minutes even though the server's inactivity timer value was set
differently.
SLIP connection -- This version of software corrects a problem in which a
user could not establish a PPP connection on port 7 of a DECserver 90M access
server.
Initialize Factory console command -- This version of software corrects a
problem in which the software initialize command with the factory parameter
was inhibited on some access servers.
Improper error code -- This version of software corrects a problem in which
an improper error code and error message is displayed when NVRAM storage
allocation for Command Groups and Menus is exhausted.
Crashes -- This version of software corrects a problem which would cause the
access server to crash with codes of 1157, 002, 547 if a user locally managed
LPD print jobs. This version of software also corrects a problem which would
cause the access server to crash with a code of 299 on receipt of a DHCP
configuration frame that contained identification for more than two WINS name
servers.
Telnet -- This version of software includes the access server name in the
Telnet IAC SENDLOC response.
Flash RAM -- This version of software includes support for Intel's 28F020
and AMD's AM29F080B Flash RAM devices.
----------------------------------------------------------------------------
Known Restrictions and Limitations:
----------------------------------------------------------------------------
Cabletron RADIUS Server
The Cabletron RADIUS Server (C-RADIUS) utility is not currently included on
the CNAS V2.3B CD-ROM. Customers who purchase a CNAS V2.3B kit may contact
Cabletron to obtain the C-RADIUS kit at a future date.
Enhanced Displays
Enhancements to some displays were not captured for the final documentation.
For example, DHCP now provides these Access Server network parameters:
default DNS domain name, DNS name servers, WINS name servers, client (port)
IP addresses. In some screens that display this information, the data is
"tagged" to indicate its source. The current "tags" are as follows: (From
DHCP), (From Port), (From Client), (From RADIUS).
Viewing Online Documentation
When viewing the books online, be sure to expand the display window to
properly display code examples and tables.
Errata to Network Access Software Management Guide
In the Specifying an Authentication Method section on p. 23-24 of the CNAS
Management Guide the following elaboration should be added:
If the value for LCP Authentication is set to either LCP PAP /NoUsername or
LCP CHAP/NoUsername, then the login will fail unless there was a prior
interactive login that succeeded. That is, the NoUsername forms of
authentication are considered too weak to be acceptable when Autolink
Authentication is Enabled.
Enabled (or Disabled)Restrictions on Access Server Usage in the Terminal to
Host Environment
While terminal connections using the Access Server have been designed to
simulate direct terminal connections as much as possible, a few differences
exist because of the nature of the product. Under most circumstances, these
differences are not noticed by terminal users or service node application
programs. However, applications that are directly dependent on the following
functions may not operate as with a direct connection:
* Applications that depend on reading or setting the terminal speed,
character size, and parity by manipulating system data structures
* Applications that depend on an extremely fast response time (typically
less than 200 ms) to operate
* Applications that use an alternate terminal driver in the service node
* Applications that expect incoming connections to have fixed device names
Software Restrictions
* Complete support cannot be granted on UNIX systems where customization has
taken place.
* Some UNIX implementations, other than those listed, may operate
successfully, but no support is implied.
* Some System V systems, such as HP-UX and SCO, may not support the upline
dump of server memory.
* For OpenVMS Version 5.x systems, the following OpenVMS classes are
required for full functionality of this layered product.
+ OpenVMS required saveset
+ Network support
NOTE:
The following copyright applies to the CMU BOOTP implementation shipped with
the CNAS kit.
Copyright (c) 1988 Carnegie Mellon University
Permission to use, copy, modify, and distribute this program for any purpose
and without fee is hereby granted, provided that this copyright and
permission notice appear on all copies and supporting documentation, the name
of Carnegie Mellon not be used in advertising or publicity pertaining to
distribution of the program without specific prior permission, and notice be
given in supporting documentation that copying and distribution is by
permission of Carnegie Mellon and Stanford University. Carnegie Mellon makes
no representations about the suitability of this software for any purpose. It
is provided "as is without express or implied warranty.
The following copyright applies to the CNAS operating software.
Copyright (c) 1986, 1987 Regents of the University of California.
All rights reserved.
Redistribution and use in source and binary forms are permitted provided
that this notice is preserved and that due credit is given to the University
of California at Berkeley. The name of the University many not be used to
endorse or promote products derived from this software without specific prior
written permission. This software is provided "as is" without express or
implied warranty.
(#)Version.c.4.8 (Berkeley) 4/7/88
Installation Problems
Generic UNIX: The generic UNIX installation kit requires a C-compiler,
linker, libraries and stripper. Some commercial UNIX systems do not include
these utilities as standard components. The CMU BOOTP server implementation
included in the generic UNIX kit is designed for BSD style UNIX systems, and
may not build properly on all UNIX platforms. The add_DECserver utility in
the generic UNIX kit may fail to operate properly on some UNIX platforms, by
issuing a spurious error message "Invalid image name" when a valid image name
is entered. This is caused by an unexpected return code from the chmod UNIX
utility. The add_DECserver utility in the generic UNIX kit does not include
AS316 as a valid access server platform ID. Use the DS700X platform ID
instead.
Windows 95/NT: Some ASCII text files will not display properly in the MS
Windows NOTEPAD utility. This is because of differences in carriage control
formatting introduced in ISO 9660 format conversion. The affected files will
display properly using the MS Windows WORDPAD utility. The README.TXT file
was inadvertently left off the kit media. If you select "yes" to view the
README file at the end of the installation, a file not found error will be
displayed.
OpenVMS: Use of the "OPTIONS N" option in the OpenVMS installation procedure
normally prints hard copy of the release notes. No soft copy of the release
notes is provided in the kit, so a non-existent file error will be obtained.
The CNAS Installation Guide lists the CD-ROM directory for the OpenVMS kit
incorrectly as: device-id:[CNAS.CNAS023]. The correct directory is
device-id:[CNAS]. The CD-ROM insert instructions are correct.
Flash RAM Update Problem
After a successful update of the Flash RAM in a DECserver 90M access server,
the access server should be rebooted. If a standard, non-compressed operating
image is loaded by the DS90M, via the network, after a successful Flash RAM
update, but before a reboot of the DS90M from the updated Flash RAM image, a
spurious attempt to program Flash RAM will be made by the firmware, and
failure codes will be displayed. The Flash RAM image is not affected by this
error.
DEC MultiSwitch 900 Hub Auto-discovery Problem
The DECserver 90M access server will not be auto-discovered by the ClearVISN
element manager when all the following conditions are true: (a) ClearVISN is
using the IP address of the MultiSwitch 900 Management Agent Module (MAM) to
manage the DECserver 90M, (b) the load image operating in the DECserver 90M
is the non-compressed image (MNENG3). The compressed load image (MNENG2) does
not have this problem.
Modem Configuration
This note explains how to determine if an Access Server modem can support
both callback, and non-callback type logins on its port. It also provides the
modem configuration values needed to support each of the cases. If your modem
does not support appropriate configuration values, you will not be able to
perform both callback and interactive authentication without callback on the
same port.
When certain modem functions complete, a "result" code may be returned to
the attached port. Modem configuration parameters determine if the result
code is returned, and its format. When the Access Server dials out to
initiate a callback, it wants to receive a "long" format result code. But
when an incoming call is connected, the Access Server wants to suppress the
results code.
Some modems provide a single configuration value that provides exactly this
combination; but many do not.
The need to suppress receipt of result codes becomes an issue only if a
client dialing in to the port requires an interactive login. The issue is
irrelevant for PPP clients that use LCP authentication. But if SLIP is used
with AUTOLINK AUTHENTICATION, or Window 3.1 PPP clients are used, the
information in this note must be applied for proper operation. If your modem
does not have the level of sophistication required, you will not be able to
use AUTOLINK and DIALER on the same port.
Below are two approaches to configuring the Access Server modem, so that
dialback and non-dialback logins are both supported by the port. There may be
other approaches, depending on the specific features of your modem.
* Configure your modem to provide Results Codes only if the call is
initiated from the modem and to suppress Results Codes for all calls
initiated from the client. On some modems, this is value Q2.
* Configure your modem to reload the modem configuration parameters from the
modem's NVRAM, following dropping of DTR (&D3 on some modems). Also,
configure the results codes by using value Q1V1. Thus, each time a dialback
session ends (which re-configured the modem to return results codes), the
modem is reverted back to the configured setting for suppressing Results
codes.
In each of the above cases, the DIALER Init string should be configured to
be Q0V1. This requests Long form Results codes, when a dialed out call gets
connected.
Some modems have different capabilities than others, and react slightly
differently under the same circumstances. While the following guidelines may
not appear to be optimal for your particular brand of modem, they were
developed in an attempt to make the majority of modems behave as similarly as
possible.
NOTE
Modems used for AUTOLINK sessions and dialback access should be configured
to include the following:
ATQ1&C1&S1&D3 (save values in modem's NVRAM profile)
Q1 - disable result codes
&C1 - cause DCD to track actual state of remote modem's carrier
&S1 - assert DSR at start of handshake
&D3 - hang up, on DTR transition reset modem to NVRAM (initial) state
The critical feature that assignment "&D3" provides is this: the
configuration parameters stored in the Modem's NVRAM become the active values
following each port logout. This guarantees that following a session that was
initiated using a callback, the modem will be reset to use value Q1, which
disables results codes for the next incoming call.
Please note that the ports configured without AUTOLINK may still be subject
to problems with result code strings from modems. One example of this is when
PORT AUTHENTICATION is enabled. If you are going to be using the port for
dialback, or, for any other reason require that the modem be configured to
provide result codes on dial in, then you should use PORT AUTOLINK
AUTHENTICATION and not use PORT AUTHENTICATION.
PPP Callback
Certain callback requests can appear to be accepted but do not result in a
return phone call. If the user is trying to use PPP to establish a PPP
callback session, and the port being used has LCP passive open disabled
(meaning the server immediately transmits characters in an attempt to start
up the session), the callback request is likely to be lost.
To avoid this problem, enter the following command for every port which
could possibly use PPP to negotiate a PPP callback session:
Local> DEFINE PORT [n] LCP PASSIVE ENABLE
This specifies that when a port logs in, the server is to passively wait for
the client to begin PPP session negotiation.
CBCP Callback and Terminal Window Authentication
Windows 95 clients (and similar) that support CBCP callback may not use the
terminal window option for interactive (non-PPP) authentication if callback
is desired. If you do, the callback will be initiated by the Access Server,
but because the original connection to the client is broken first, the client
believes that the connection is lost and will not answer the callback. The
Access Server will try the call a second time, but then give up and log the
port out. This procedure may tie up the port for about 90 seconds.
Callback Numbers
It is recommended that the callback number for a given session come from
exactly one source, and that all other possible sources of callback numbers
have the value representing 'do not care', for example, '(Any)', '(None)' or
'*'. If you specify different numbers in multiple sources, the callback will
likely fail because of phone number authorization failure. That is to say,
the precedence relations of multiple phone numbers is problematic in this
release.
The possible sources of callback numbers are:
* RADIUS Callback-Number Attribute
* PPP Client (by means of LCP Callback Option negotiation)
* Security Realm default authorization value for DialBack Number
* Dialer Service value for Number
Access Server Accounting
A session disconnect event in the Access Server accounting log includes
fields for the number of bytes transmitted and received during the life of
the associated session. For TD/SMP sessions, these counters are invalid (they
are correct for sessions other than TD/SMP sessions). When accessing the
accounting log by means of the user interface, these counters follow the
"TX:" and "RX:" fields in a Session Disconnect event. When accessing the
accounting log by means of SNMP, these counters are available by means of the
objects acctEntrySentBytes and acctEntryReceivedBytes. This anomaly is also
visible for active TD/SMP sessions by means of the SNMP CHARACTER-MIB in the
objects charSessInCharacters and charSessOutCharacters.
AppleTalk
There are certain situations that can cause an attached AppleTalk host to
have a "stale" AppleTalk address (an address not contained in the current
network range). This occurs if the network range changes during the lifetime
of an ATCP connection, and the connection's address is not within the new
range. Examples of this might be if the routers on a network were
reconfigured with a new network range or if no routers were active and then
one or more routers began functioning. The user is not notified of the new
network configuration and continues to operate with this "stale" address.
This situation may not disrupt current network service connections but can
inhibit future service connections.
Unfortunately, it can be difficult for the user to distinguish this problem
from other unrelated network problems (for example, routers going down). In
general, if users see reduced service access, they should try disconnecting
the ATCP connection (making sure the port gets logged out, for example, due
to modem control) and then reconnecting. At this time, the connection will be
given a valid address within the current network range.
Telnet Remote Console
When memory utilization is at or near 100%, a Telnet remote console
connection request to the access server may be rejected.
It is possible, in some circumstances, for the Telnet connection to the
remote console to be broken, without disconnecting the remote console session
itself. In this situation, the remote console will be continually "in use",
and unavailable until the access server is rebooted. The TCP KEEPALIVE timer
feature may be used to advantage to cause the remote console session at the
access server to disconnect after a specified period of time during which TCP
connectivity is broken.
PING
There is a bug, which causes the output from a completed PING to be
displayed in local mode instead of in session mode. This happens if the user
starts a PING session, hits the break key, and does not resume the PING
session before the test completes. If the user remains in session mode, the
PING output displays properly.
Cannot Abort User Authentication
The documentation indicates that a user can abort User Authentication
requests once all information has been entered and the actual request has
been sent onto the network by typing a Break or local-switch character on the
terminal. This feature is not implemented in the current release. Once the
request is sent to the Kerberos KDC or security server the user must wait for
a response from the KDC or security server or a timeout to occur before
additional local mode commands may be entered. The timeout is controlled by
the SET|DEFINE|CHANGE {KERBEROS|RADIUS|SECURID} TIMEOUT command. This
limitation applies to both user login authentication and the KPASSWD command.
Incorrect Login to Local Mode by Framed AUTOLINK user
When using Autolink Protocol, a user may perform an interactive login (on
Pass1) that identifies the user for a Framed access. Framed access is
determined either from a Realm ACCESS = FRAMED, or, when using RADIUS
authentication, from the RADIUS Service_Type attribute. This always results
in starting "Pass2" of Autolink. If the user allows the Pass2 Autolink timer
to expire or enters a CR on a dumb terminal, the user is logged in to the
Local Prompt. This action should have caused a login rejection during Pass2,
because the Pass1 authentication authorized Framed operation. This error is
not as significant as it might first appear. Without privilege, or
Permissions, this local mode user will not be able to do much. (PPP users
typically would only have permission for Telnet and PPP). This will be
corrected in the next release.
Other Issues
* The INITIALIZE command does not properly measure the amount of delay time
until the command is invoked. Add 1 minute to the time you specify to make
sure an adequate delay takes place before the access server is initialized.
When setting up internet gateways, be aware of the following:
- For class A and B addresses, the subnet mask must be at least as long as
the network class portion. For class C addresses, the subnet mask must be at
least as long as 255.255.0.0.
- Network 17.1.1.1 mask 255.0.0.0 is illegal, since its network portion has
extra bits not included in the subnet mask.
- All subnet masks must have contiguous ones, starting from the left.
- Network xxxx mask 255.255.255.255 is illegal. Use HOST xxxx instead.
* On OpenVMS systems, limitations apply to the TSM GET CHARACTERISTIC
command procedure which causes it to truncate a port Username if the Username
has embedded spaces. When using TSM$NA_VXX_GET_CHAR.COM, the following
guidelines apply:
- The port Username can be an ASCII character string of up to 16 characters,
optionally containing up to 4 embedded spaces. A port Username containing 4
embedded spaces would therefore contain 5 ASCII substrings which collectively
form the port Username. For example: define port [n] username "Port 1 A B C"
- A port Username, whose substring components are separated by multiple
spaces, will be compressed thus reducing multiple spaces to a single space
between the ASCII substrings. For example, a port Username defined with
"define port [n] username "A B C D"" will result in the command: "define port
[n] username "A B C D"" being generated and placed in the server_SETUP.COM
file.
- A port Username consisting of more than 5 ASCII substrings will be
truncated thus leaving the first 5 ASCII substrings to form the port
Username. Single characters or substrings beyond the 5th substring in the
Username will be discarded.
Protocol Failover Interactions with Authorization
Behavior of Protocol Failover (CONNECT , when Port Default
Protocol is ANY):
In general, if the user enters the CONNECT command, the software
will first attempt a LAT connection, followed byTelnet, followed by Rlogin.
The failover occurs as expected, if the user has Authorization "permission"
for all three types of connections. In the event that there is no LAT service
with the specified name, the Access Server will failover to the Telnet
protocol. If the named host does not have Telnet enabled, the Access Server
will try Rlogin. If the user does not have permission for one of these
protocols, then a connection via that protocol is not attempted, and an error
message generated.
If the user has permission for LAT, then the failover to Telnet, then
Rlogin, will always occur as expected. For example, if the user permissions
are: (LAT NOTELNET RLOGIN) and the remote host system does not run LAT.
Local> CONNECT MYHOST
Soliciting...
Trying...
(normal host login banner appears here)
The Rlogin connection is successful in this example. If the user does not
have permission for LAT, then the only other protocol attempted is Telnet. If
the user only has permission for Rlogin (NOLAT NOTELNET RLOGIN), then the
[CONNECT] RLOGIN command should be used, instead of CONNECT .
The following is an example of the error messages generate when the user
only has permission for Rlogin. The first message indicates that the user
does not have permission for LAT. The second indicates the user does not have
permission for Telnet. The Access Server does not failover to Rlogin, because
the user doesn't have permission for LAT. Note that the RLOGIN command is
successful (assuming remote host is properly configured).
Local> CONNECT MYHOST
Local -854- Insufficient Privilege for Command
Local -854- Insufficient Privilege for Command
Local> RLOGIN MYHOST
Trying...
(normal host login banner appears here)
Information from DHCP Servers
When DHCP is enabled on the Access Server, information received from DHCP
servers at boot time will be used in preference to locally configured
information from NVRAM. This information includes items such as default DNS
domain name, DNS name servers, WINS name servers, and default IP gateways.
The logic behind this feature is that DHCP Servers should always know best
in any true DHCP-managed environment. DHCP on the Access Server is enabled by
default. If you wish to disable the learning feature, you may disable DHCP
(using a DEFINE INTERNET DCHP DISABLE command). This will also disable DHCP
for the purpose of obtaining IP addresses for Access Server ports.
Locally Configured Name Servers from DHCP
In the SHOW INTERNET NAME RESOLUTION display, some Locally Configured name
servers may be listed by IP address and the pseudonym "(From DHCP)". You will
not be able to remove these name servers individually, using a CLEAR INTERNET
NAMESERVER "name" command. Using a CLEAR INTERNET NAMESERVER ALL command will
remove them, but also removes any truly locally configured entries.
WINS Server Information
To obtain new WINS Server information from DHCP, you must reboot the Access
Server. This information is acquired and stored only during the Access Server
software initialization. This restriction also applies to DNS Server
information that is denoted as "(From DHCP)".
RADIUS Reply-Messages Not Sent to PPP Clients
The current software version does not attempt to send a Reply-Message from a
RADIUS Access-Accept or Access-Reject packet to a PPP dial-in client. It is
recommended that Reply-Messages not be used for PPP users' accounts.
Telnet Server Echo
A Telnet server session to a network access server physical port made
through the Telnet listener will respond with WILL-ECHO to a DO-ECHO request
from a Telnet client; however, the Access Server will not actually perform
echoing. Echoing of incoming network data is the responsibility of the device
attached to the physical port.
TN3270 Enhancement
Abbreviating keymap and/or terminal names is not acceptable. Since the
system manager can create new terminal and keymap names, abbreviations might
be ambiguous.
Development Notes for 'harvestd' Utility
This section is for customers that desire to modify the harvestd source code.
The software was developed under the CWEB environment. That means modifying
.w files, using ctangle to generate .c and .h files. To generate
documentation, one needs to run cweave to create .tex file, tex to generate
.dvi file, and dvips to generate .ps file. All of this software is available
from a GNU ftp site. To develop software independent of documentation, one
can start with .c and .h files. Such files generated by ctangle are not human
readable. One can use the following to generate a more readable file:
pp.sh ctangled_file > readable_file
This file has no comments, because ctangle extracts all such comments.
Show Port Authorization Display
The data in this display reflects the values at the time of login. They are
not updated dynamically due to commands issued from a Local prompt.
If a user has changed the state of the port's privilege status, or has
enabled SLIP or PPP on the port, the permissions attributes {PRIV, PPP, or
SLIP} displayed by the command SHOW PORT AUTHORIZATION do not change. The SET
PRIVILEGE command (which requires a password) creates a privileged status on
the port, without disturbing the user's authorization record, which may not
provide for the privileged port status.
Similarly, the port PPP and SLIP enabled or disabled status are separate
from the user's SLIP or PPP permissions. The port must be enabled for PPP or
SLIP in order for the user's PPP or SLIP permission to be valid on that
particular port.
Vendor-Specific RADIUS attributes
Each security realm has a default set of permissions that are applied only
when the Service-Type is NAS-Prompt. In this case, the permissions identified
in the realm limit the commands that the user can enter. For example, if the
Permission says NOTELNET, then the user cannot issue a Telnet request at the
Local Prompt. With RADIUS servers, it may be necessary to use the
Vendor-Specific attribute to supply a mask that covers all of the permissions.
The Realm default permissions also include a DialOut Service, which is
necessary to complete callbacks. A Vendor-Specific attribute for DialOut
Service also exists. With RADIUS Servers, it may be necessary to use the
Vendor-Specific attribute to supply the DialOut Service. Alternatively, the
DialOut Service may be defined as the DEDICATED or PREFERRED SERVICE on the
port. Provisions are also made to define a DialOut Service in the Local User
Accounts.
Using Multiple RADIUS Hosts
When you name multiple hosts for a specific RADIUS realm, the Access Server
will try to contact each of the hosts, in round-robin fashion, should one
fail to respond to a request. The number of seconds between retries and total
time spent waiting for user authentication, are configurable parameters.
These are modifiable via commands CHANGE RADIUS INTERVAL, and CHANGE
RADIUS TIMEOUT respectively.
Unexpected Authentication Failures with PPP, PPP/Callback
This version of CNAS implements a policy of rejecting PPP authentication
attempts, in cases where the user authentication itself succeeds, but some
authorization factor requires that the login be denied. The console messages
will report this as an Authentication Failure. An example of this occurs when
the client is PPP but the RADIUS authorization information says that the
user's Framed-Protocol must be SLIP.
Another example occurs when a dialout number is unavailable for a requested
callback. Typically this is a problem with the callback authorization
information supplied by the user's account, or by other authorization
defaults on the access server. In the callback case, a problem exists since
some PPP client implementations will immediately disconnect the phone after
negotiating callback and receiving an authentication acknowledgment. If the
callback is denied as a result of authentication, the access server will
'pretend' that the authentication itself failed. This causes the PPP dial-in
client to give a failure message to the user immediately, albeit a
potentially confusing one. Otherwise the PPP client waits indefinitely for a
callback that is not going to occur. Since PPP ports do not have the benefit
of interactive error messages, problems with PPP connections, or callback PPP
connections are best diagnosed by looking at the Access Server Accounting
Log. This must be performed by a privileged user, such as the system
administrator.
Severe Errors
Severe errors may cause your Access Server unit to hang or bugcheck. If your
Access Server unit hangs for more than 90 seconds, you will have to power
down and up to restore normal operation. If this should occur, please
describe the operating conditions on the Access Server unit at the time of
the hang.
If a FATAL BUGCHECK occurs, a bugcheck message is printed on the console
terminal. The message shows the vital registers at the time of the bugcheck.
Normally, an upline crash dump is automatically created when a fatal bugcheck
occurs.
For other types of problems, a crash dump is also an extremely valuable
tool. For example, if you experience a problem that is not easily
reproducible, a crash dump will normally allow Cabletron to fix the problem
even though it cannot be reproduced. You can force a CRASH by typing CRASH at
the local mode prompt in privileged local mode. A code 300 fatal bugcheck
will immediately occur.
The location of the crash dump file may be determined as follows:
* After the Access Server unit reinitializes, enter local mode and enter a
SHOW SERVER STATUS command. Information in this display will indicate the
Ethernet address of the dump host. You can identify the dump host from this
address.
* OpenVMS systems: The crash dump will be located in the
SYS$COMMON:[DECSERVER] directory on the dump host, and the filename will be
NA9xxxxxx.DMP, or NA7xxxxxx.DMP where xxxxxx is the DECnet node name assigned
to the network access server as defined using the DSV$CONFIGURE configuration
procedure.
For example, if the DECserver 90TL with node name LAT041 bugchecks, the
crash dump will be found in SYS$COMMON:[DECSERVER]DS9LAT041.DMP on the dump
host.
* ULTRIX systems: The crash dump will be located in /usr/lib/dnet on the
dump host and the filename will be DS9xxxxxx.DMP or DS7xxxxxx.DMP where
xxxxxx is the DECnet node name assigned to the network access server as
defined using the DSVCONFIG configuration procedure.
For example, if the DECserver 90TL with node name LAT041bugchecks, the crash
dump will be found in /usr/lib/dnet/ds9lat041.dmp on the dump host.
* DIGITAL UNIX and other UNIX systems: The crash dump will be located in the
/tftpboot directory. The file name will be one of the following:
- WW_xxxxxx.DUMP
- WWxxxxxx
- MN_xxxxxx.DUMP
- MNxxxxxx
Copy the crash dump file to TK50 tape, QIC tape, DAT tape or another media.
If these media types are not available, indicate the format of the copy
(COPY, BACKUP, FLX, etc.) on a label.
Crash dumps may also be accepted via Internet mail in a suitable archive
format, such as a ZIP file. Contact your authorized service representative
for specific arrangements.
Any other problems than those listed above should be reported to our
Technical Support Staff.
When reporting problems, describe one problem at a time. This simplifies
record keeping and facilitates a quick response. Keep the description simple
yet accurate. Illustrate a general problem with several examples. If a FATAL
BUGCHECK error occurs, submit a crash dump.
Because problems are often difficult to reproduce with different system
configurations, please include as much detail as possible when reporting a
problem. Define as precisely as possible the state of your system when the
problem occurred and indicate the sequence of events or commands that caused
the problem. Attempt to reproduce the situation, if possible, using the
minimum number of steps.
If one of your user programs causes a problem in the Access Server unit and
you are unable to send the program to Cabletron, try to reproduce the problem
with a standard utility. If this is not possible, try to describe the
program's operation before and after the suspected failure.
When a problem report contains concise problem information, that problem is
more likely to be reproduced and corrected. Please ensure that any questions
are direct and simply stated so they can be answered clearly and directly.
Documentation Problems
When describing a problem found in a manual, specify the full title of the
manual and identify the appropriate section, table, or page number. Describe
what the manual says and also describe the suggested correction. If you are
reporting an error with online help, please identify the full command and
screen.
----------------------------------------------------------------------------
Compliance support:
----------------------------------------------------------------------------
Compliance Level Compliant
Year 2000 Yes
Known Anomalies: None.
IETF Standards MIB Support:
RFC No. Title Groups Supported
1157 Simple Network Management Protocol ifTable, atTable,
(SNMP) ipAddrTable,
ipRoutingTable,
tcpConnTable
1213 MIB II System, Interfaces,
Address Translation, IP,
ICMP, TCP, UDP, SNMP
1243 AppleTalk MIB AARP, Port, DDP, RTMP,
ZIP, NBP
1284 Ethernet-like Interface Types Statistics
1316 Definition of Managed Objects for Port, Session
Character Stream Devices
1317 Definition of Managed Objects for General Port,
RS232-like hardware devices Asynchronous Port, Input
Signal, Output Signal
1471 The Definitions of Managed Objects for LCP
the Link Control Protocol of the
Point-to-Point Protocol
1473 The Definitions of Managed Objects for IPCP
the IP Network Control Protocol of the
Point-to-Point Protocol
----------------------------------------------------------------------------
Cabletron Private Enterprise MIB Support:
----------------------------------------------------------------------------
Title Description
None N/A
Cabletron Private Enterprise MIBs are available in ASN.1 format from the
Cabletron web site at:
http://www.cabletron.com/support/mibs/ . Indexed MIB documentation is also
available.
SNMP Trap Support:
RFC No. Title
1157 Simple Network Management Protocol
----------------------------------------------------------------------------
Cabletron Private Enterprise trap Support:
----------------------------------------------------------------------------
Title
None
GLOBAL SUPPORT:
By Phone: (603) 332-9400
By Email: support@cabletron.com
By Web: http://www.cabletron.com/support
By Fax: (603) 337-3075
By Mail: Cabletron Systems, Inc. P.O. Box 5005 Rochester, NH 03867-5005
For information regarding the latest firmware available, recent release note
revisions, or if you require additional assistance, please visit the
Cabletron Support web site.
NOTICE:
AppleTalk is a registered trademark of Apple Computer, Inc.
Alpha, DECnet, DIGITAL, OpenVMS, and VAX are registered trademarks of COMPAQ
Computer Corporation.
HP is a registered trademark of Hewlett-Packard Company.
IBM is a registered trademark of International Business Machines,
Corporation.
Novell and NetWare are registered trademarks of Novell, Inc.
SCO is a trademark of Santa Cruz Operations, Inc.
SecurID is a registered trademark of Security Dynamics Technologies, Inc.
Sun is a registered trademark of Sun Microsystems, Inc.
UNIX is a registered trademark in the United States and other countries,
licensed exclusively through X/Open Ltd.
Windows and Windows 95 are registered trademarks of Microsoft Corporation.
Windows NT is a trademark of Microsoft Corporation.