The NBase-Xyplex Access Server is a multi-protocol terminal server which supports direct Asyncronous connections for most Serial peripherals. These devices can be either terminals, printers, async modems for remote access, console ports for UNIX workstations, management port on switches, hand-held scanners, and a variety of other data-collecting serial devices. The access server can concurrently support users who are logged into IP and VMS systems, dial-in and dial-out with interactive, SLIP or PPP sessions, network printing, and provide network access to serial Management Ports on other network devices.
The purpose of this document is to provide an overview on the initial key issues you should be aware of when first working with the unit. These key issues include: the server's loading process, user interface concepts, server and port configurations, and safe methods for rebooting the server after it has been configured.
BootStrap:
The access server REQUIRES that it be connected to a 10 mbps Ethernet LAN before it will start the normal loading sequence. The unit does not support 100 mbps fast ethernet. During the loading process, if a LAN connection is not seen by the unit, then it will not load and the following message will be displayed on an attached terminal:
"Searching for a Functional Standard Ethernet Network."
To resolve this problem, verify the cabling between the LAN and the ethernet port on the access server. For 10baseT connections, a straight-thru ethernet cable is required between the access server and a DCE device (such as an ethernet hub or switch), and a cross-over ethernet cable is required for connections to a DTE device (such as a bridge/router). Once the LAN is detected, the unit will complete a hardware self test and begin to load. To complete the loading process and become fully functional, the server requires two files: the software image or runtime code AND the parameter file. The access server will first load the runtime image, then load and implement the parameter database. The server's boot ROMs are designed to load both files using several loading protocols.
A.) SOFTWARE Image
The Access Server defaults to load the runtime image using protocols in the following order:
| CARD | For loading from a local FLASH memory card that is inserted in the unit. |
| XMOP | Xyplex's proprietary load protocol where one Xyplex device will act as a load server for another Xyplex device. |
| MOP | The unit will send DEC MOP load broadcasts across the LAN searching for a VAX load server. |
| BOOTP | The unit will send a bootp broadcast, searching for a bootp server to gain an ip-address to use so it can tftp download the image runtime code from a tftp host. If an router is between the Xyplex device and the bootp server, you will need to ensure the router will forward bootp packets on to the bootp server. Bootp is not routable. CISCO calls this a helper IP. |
| RARP | The unit will send a rarp broadcast looking for a response from a rarp server to provide an ip-address to use so it can tftp download the image runtime code from a tftp host. |
Once the access server has downloaded the image file, it will then decompress and implement the runtime code it received.
B.) PARAMETER File
Once the server has processed the runtime image, it will then download
and implement the parameter database. The parameter file contains all
of the server and port settings. Should this file be incomplete or
corrupted, the access server will either complete the bootstrap process
using the default parameter set, or it will not completely boot/reboot,
instead displaying a flashing LED error code on the front panel. To
correct this situation, please reference the "Getting Started" manual
and follow the process to gain access to the ROM Configuration Menu in
order to default the server and port settings. There is also a
Technical Paper available on our service and support website.
The process will require a directly attached terminal to any single async port on the server. The server's default parameter load protocols are in the order below (this order may vary depending on the access server hardware type you are working with):
| NVS | Non-Volatile Storage located within the unit on the motherboard. This is the default for all NBase-Xyplex access servers except the N9-720 which has no NVS on board. |
| CARD | The only NBase-Xyplex access server that can retrieve its parameter file from an on-board flash memory card would be the N9-720 server. No other server can support this function directly. |
| XMOP | Using the Xyplex proprietary protocol, the server will broadcast a load request to get a copy of its parameter file from another Xyplex device which has stored its parameter file. The responding Xyplex device must have a local flash memory card (where it stores the parameter files for other units) and have "Manager Load" and "Parameter Service" as enabled functions. |
| MOP | The unit will send DEC MOP load broadcasts across the LAN searching for a VAX load server that is running the Xyplex software process "xyp_manager" and has an NCP entry for that access server as well as a copy of its parameter file. NOTE: "xyp_manager" is not supported on OpenVMS version 6.2 or higher. |
| BOOTP | Same process as for the image loading, but the unit will look for a file named "x012345.prm" from the tftp server (where 012345 represents the last 6 digits of the unit's ethernet address). |
| RARP | Same process as for the image loading, but the unit will look for a file named "x012345.prm" from the tftp server (where 012345 represents the last 6 digits of the unit's ethernet address). |
Login:
Once the server is fully booted, the RUN and LAN lights will flash about once per second. At this time, press the
Once the port and the terminal are communicating properly, you will see the server's default welcome message and be prompted to log into the server:
Welcome to the Xyplex Terminal Server.
Enter username>
At this point, the server is just looking for any name or character sting to be entered. It is not looking for something specific - whatever you enter is not important. The "string" you provide will appear on certain "show port" screens as a visual reference to indicate who is logged in there, for user & administrator convenience only.
Enter username> enter_some_string
After entering any alpha or numeric string, you are presented with the default port prompt:
Xyplex>
At this point you are logged into and talking to an active and functional access server port. The next step is to configure the unit to meet your needs and goals.
Configuration:
The parameter database is where the access server's unique profile and port settings are stored, and from where they are reloaded each time the server is rebooted. The parameter file is where all the changes you make to the server and each port are saved. This file needs to be protected so that it does not get corrupted during a reboot.
In order to make changes to the parameter file (i.e. configure the unit), you must be in privileged (priv) mode. The sequence is as follows (please note the user command and the default privilege password):
Xyplex> set priv
Password: system
Xyplex>>
The port prompt has changed to include a double greater-than symbol. You may shorten this sequence by the single command string "set priv system", but this is software version dependent.
The server has two memory levels, if you will, thus there are two types of commands used during configuration.
First: Level 1 is Active Memory (or operational database) which is the current configuration the server and ports are working with while the unit is in operation. Should you issue a "SET" command to change a parameter to a different value, that configuration change would be lost when the port is logged out (for port settings) or if the server was rebooted. The SET command allows for a temporary change to the active working parameter set. If the SET command was used to change a port setting, that setting will revert back to the original setting when the port resets for any reason (including a simple logout by the user on that port; or if someone in privileged mode logs that port out; or if the server is rebooted).
Second: Level 2 memory is Permanent Memory (or stored configuration) which is recalled upon a reboot or port logout. Should you want to make a change to the server and port settings that needed to be recalled after a reboot of the server or after a port is logged out, a "DEFINE" command would be required.
The SET commands can be used by both privileged and non-privileged users. The DEFINE commands are limited to the privileged user only. The following examples will illustrate the affect of the SET command versus DEFINE command after a user logs out:
A. Change the port prompt in the Active Memory configuration:
Xyplex> set port prompt "Port_3"
The yield of the above command:
Port_3> logout
After the user logs out, the port will reset and go back to the values as defined in the Permanent memory database. Note the port prompt once the user logs back into the port:
Xyplex>
B. Change the port prompt in the Level 2 Permanent Memory configuration:
Xyplex>> define port prompt "Port_3"
The yield of the above command:
Xyplex>> logout
After the user logs out of the port, it will reset and read the settings stored in the permanent database, implementing the new setting. Notice the port prompt once the user logs back into the port:
Port_3>
When configuring the access server, there is an parameter feature called "CHANGE" that, when enabled, will automatically execute the SET command whenever you issue a DEFINE command, thus eliminating the need for typing in the second command line.
To enable the CHANGE feature, execute:
Xyplex>> set server change enable
Xyplex>> define server change enable
Here is how it is helpful: When you define an internet address to the serverusing "Xyplex>>define server internet address 10.10.10.3", the ip-address is written to permanent memory, which would then require either the SET command to also be issued or a reboot of the entire server in order for the value to become active. If you only issued a SET command with"Xyplex>>set server internet address 10.10.10.3", the ip-address would become active immediately, but lost when the server was rebooted unless the DEFINE was also performed. This example illustrates that changing both the temporary and permanent configuration would require two commands without a reboot. With CHANGE enabled, when you issued the define server internet address command, the server would:
1. update the permanent configuration database,
2. automatically execute the SET command so the ip-address would become active right away without requiring a reboot.
Please Note: NOT all server or port parameters can be changed with the SET command. When the CHANGE feature is enabled, at some point you will define some parameter and be prompted with a warning or informational message:
"Xyplex -729- Parameter cannot be modified by a SET command."
Some of the commands cannot be "set" because the change could affect any users that may be logged into that particular server/port(s). The message is also displayed when enabling certain server-wide features and protocols (such as LPD, Radius, IPX, etc), because memory resources will need to be allocated for the feature's use. These features will also display the message "Xyplex -705- Change leaves approximately ####### bytes free".
If you see this message after making a parameter change to a port, you will need to reset the port for the change to become active/operational immediately. To do this, you simply need to issue the command "logout port #" (which, in addition to "set"-ting the parameter, will also disconnect any user who may be connected to it):
Xyplex>> logout port #
(where "#" is the physical port number you made the change to)
If you see this message after issuing a command to change a server-wide parameter, or enable a feature, then you will need to reboot the server at some point for the new parameter to be implemented. Follow the instructions on safe reboot methods in the next section of this paper.
Rebooting:
Important: To reboot the server, it is strongly recommended you use the configuration/parameter friendly reboot command "initialize":
Xyplex>> initialize
This is a command where the server will, by default, wait for one minute before it automatically reboots using the process boot/load sequences discussed earlier. You can also modify the time to reboot by providing a time argument:
Xyplex>> initialize delay #
(where "#" is the variable in minutes before the unit will reboot)
If the time argument is "0" the unit will reboot immediately. If the time argument is greater than "0", the server will reboot in that number of minutes specified.
The beauty of the "initialize" command is that it is parameter-database friendly. Provided the parameter/configuration file is current and up-to-date and in an idle state (see the "show parameter server" screen), the server will terminate all processes and proceed through a normal bootstrap process. If the server is still writing the parameter changes to permanent memory, it will not prematurely terminate the write process so as to prevent corruption of the parameter database. The server will instead give you a warning message:
"Xyplex -198- WARNING - changed configuration has not been saved."
After you issue the last "define" command, the server waits a period of time to make sure there are no more "defines" to follow, then it writes the "lump sum" of your commands all at once to the parameter storage locations (i.e. flashcard, NVS, host). All of this takes approximately 30-40 seconds from the moment you issued the last define command. If the unit is forced to reboot while writing parameters, then the file will get corrupted. The "initialize" command will not force a reboot, and therefor, if it has not yet saved the changes, it will display the above message. Should this happen, give the Xyplex device another minute or so in order to complete the process of writing the parameter database to memory, then try issuing the "initialize" command again.
Normally NOT Suggested:
There are three methods of rebooting
the access server that are not sensitive to the storing status of the
parameters. It is not suggested you execute either of them unless you
verify the parameters are saved and current beforehand. The server
command to check on the status of the parameter file storage state is:
Xyplex>> show parameter server
Check for the status, version, and storage state of the parameter servers. The storage state needs to be "Idle", the status should be "current", and the versions at each location should be the same as the value listed next to "Last Update Version" in the first column. Again, the parameter database health is your responsibility should you do any of the next three processes.
1. There is a server command "Crash". This command will reboot the server, but the process is as gentle as the word itself reflects. When you use this command, the server will immediately attempt to dump its core memory to a dump server. CRASH is not sensitive to the state of the parameter set. If the server is writing parameters to permanent memory, this command will terminate the write process immediately and there is a 100% probability that the configuration will become corrupted. Once the parameter set is corrupt, the server will not reboot thereafter, and the LEDs will begin flashing an error message on the front of the terminal server. The only method of recovery is defaulting the server and port settings. Please reference the Web URL listed earlier in this document for instructions on how to do this.
2. Another reboot process that is NOT sensitive to the parameter set is a power cycle of the unit. In other words, pulling the power cord. All processes are terminated immediately including all the rules related to checking for a complete and valid parameter set. Defaulting the unit will be in order if the parameter database gets corrupted.
3. The third reboot process, again not suggested, is using the reset switch. Pressing the reset switch with a paperclip two quick times will force the server to reboot. This process is also NOT parameter database sensitive. Should the server be writing parameters to memory, the write and verify process is terminated regardless of whether or not the process had been completed. If the unit displays a flash error code on a reboot, you will have to default the server parameters and start anew as well.
On a positive note: It is possible that, if the parameter file is current and in an idle state, and you happen to reboot using these last three mechanisms, you could be in luck and not have a problem. These reboot methods do work, but there is a high level of risk when used. It is best to always reboot using the "initialize" command whenever it is possible to access the server's command line interface (CLI).
Additional Information:
The NBase-Xyplex Access Servers are a reliable network device. They support several network protocols for loading its runtime code and server profile configuration/parameter files. Once the server is up and running, they can be configured to operate with permanent and temporary settings using the Define and Set commands at the server's command line interface, i.e. port prompt. The Access Server provides a help utility to solve command line syntax errors. It will always highlight or note the command or argument that are not known and will provide you with a list of valid commands or verbs it was expecting to see. The Access Server also provides informational and warning messages when certain conditions are met to assist you when working with and configuring the server. You are able to reboot the server from local or remote locations using the Initialize command knowing it will validate the status of the parameter file first.
A key element when working with devices attached to physical ports on the server is the wiring between the ports and third party devices. The manual NBase-Xyplex provides with each unit, will list the expected DTE and DCE pinouts and cable to use. The server supports various show port screens to display the port status and port counters, not discussed above, that can be used in troubleshooting communications issues. The access Server also allows you to view port characteristics, alternate characteristics, and telnet characteristics to look at various port settings. These and many more commands are described and discussed in the documentation Commands Reference Guide. This and other manuals are on our service and support web page as well as on CD-ROM.
The intent of this document was to give a brief overview of a few key issues the System Administrator should know when working with the Access Server. The Access Server is a flexible device that can be configured to meet many and various needs.
Additional Documentation and Resources:
NBase-Xyplex has available on our web site numerous detailed command line help files to assist you in configuring the access server and its ports. Help files are also available that outline the process to use certain Host applications and features which interact with the access server's functionality (ex. CSPORTD printing, etc); as well as some unique configurations other customers have implemented.
The web URL below brings you to the main page of the Customer Support area.