[Indigo]<Portola>Nova>GatewayOperation.bravo!1

This memo documents the operation of the Nova Gateway program and related Pup software. Further information on Nova operation may be found in two Data General manuals: How to Use the Nova Computers and Disk Operating System User’s Manual.

Turn the Power key to the On position. Load the Pup Gateway disk into disk unit 0 (the unit number is marked on the yellow Ready light). Hereafter, disk units 0 and 1 will be referred to by their software designations DP0 and DP1. Flip DP0’s Load/Run switch to the Run position and wait for the yellow Ready light to come on (about 45 seconds). Turn on the terminal and make sure it is selected to On-Line.

On machines with Decision disk controllers (SDD and EOS), the Gateway version of Data General Disk Operating System (Dos) is started by setting the data switches to 100040 octal (switches 0 and 10 up and the rest down), then pressing Reset followed by Program Load. The terminal should print out the message:

Press Reset.
Set the data switches to 1400.
Press Deposit AC0.
Set the data switches to 61333.
Press Deposit followed by Instruction Step.
Set the data switches to 100033.
Press Program Load.

If the Nova’s terminal is a Texas Instruments Silent 700, now type the command PAD followed by carriage return (all Dos commands are terminated by carriage return). This command establishes that the terminal is a TI 700, which needs padding characters inserted after carriage returns so as to permit the typehead to return to the left margin.

Type the command GATEWAY followed by carriage return. The program will print out several messages about loading boot files, followed by information about number of available packet buffers, and finally the message "Gateway in operation". At this point the Gateway program is running. However, it takes approximately one minute for new routing information to be propagated throughout the inter-network, so it may not be possible for connections to be established through the Gateway during the first minute after the Gateway program is started.

The Gateway program has a simple command interpreter that responds to single-character commands typed on the Nova’s terminal. The program prints the remainder of the command name followed, in some cases, by the message [CONFIRM], to which the appropriate response is Y or N to confirm or cancel the command.

Prints out a summary of various operating statistics, including the date the Gateway program was created, the length of time it has been running (hours:minutes:seconds), the number of times each server has been invoked (explained later in this memo), and a matrix showing number of packets forwarded from one directly-connected network to another. The two SDD/El Segundo Ethernets are numbered 10 and 11, the EOS Ethernet is 12, and the ADL Ethernet 13. The network of leased lines interconnecting the various Gateways is referred to as network 7. The number of discarded packets is also listed. Discard of packets is not cause for alarm: it is a normal consequence of the great disparity in speed between the Ethernet and the leased lines, and does not give rise to loss of information in file transfers or terminal connections.

Enables or disables automatic repetition of the Gateway Statistics command every five seconds. Enabling automatic updating is appropriate only if the Nova’s terminal is a display.

Prints out operating summaries for the Synchronous Line Adaptor (SLA), which is the name of the Nova interface to the leased lines. Each SLA is capable of handling four lines, only some of which are currently used; the remaining ones are normally looped back with special terminator plugs. For each line, the number of packets successfully sent and received on that line is printed, followed by the number of instances of three types of errors: CRC (Cyclical Redundancy Check) errors, Sync errors (bit synchronization was lost), and Control sequence errors. The total number of errors should be much less than one percent of the packets successfully received. If a high error rate occurs on a single in-use line (whose state is "Up"), the line or modem is suspect, whereas if frequent errors occur on all lines (or particularly on "Looped back" lines), the SLA interface is suspect.

This command also prints out the SLA routing table. At present, there are four hosts in the SLA network: the Parc Gateway (SLA host 1), the SDD/El Segundo Gateway (2), the EOS Gateway (4), and the ADL Gateway (5). However, the software is capable of handling expansion of the SLA network by addition of more lines and Gateways. Under normal circumstances, the routing table for a particular Gateway should show that it can reach itself through one of the looped-back lines and all other Gateways through one or more of the connected lines.

The Gateway program maintains the current date and time, which it gives out to other hosts that request it. The date and time are obtained from another Gateway when the Gateway program is started. The Reset Time command causes the local date and time to be invalidated so as to force the Gateway program to reset itself from another Gateway. This is necessary if the local time has become incorrect. (The Nova clock is not particularly accurate and can’t be regulated to closer than about one second per day. Also, the software doesn’t know about changes between Standard and Daylight time, so a manual Reset Time command must be issued to force these changes.)

A data base of host names and addresses is maintained at Parc and distributed to all Gateways for use in responding to name lookup requests from Altos. The data base distribution procedure is automatic, with requests for data base update generated once per hour. The Probe for New Directory command simply forces such an update to occur immediately.

This command causes control to be given to the Debugger. From within the Debugger, the Gateway program is resumed by typing $P. Ordinarily, the debugger is flushed when the Gateway program is started (to gain more storage for buffering packets), so it is not possible to issue the Debug command. However, the debugger is retained if the Gateway program is started up by the command GATEWAY/D.

The primary purpose of the Gateway is to forward Pups (Parc Universal Packets) from one network to another. However, the fact that the Nova is somewhat underutilized by this task and that it is in operation all the time makes it a desirable source of other services as well. These services are necessarily limited to those that are relatively easy to implement and whose resource requirements don’t significantly impact the Nova’s primary role as a Gateway, but they make life considerably more pleasant for Alto users than would be the case were these services not available.

This service is actually related intimitely with the Nova’s role as a Gateway. It provides routing information to all hosts on directly-connected networks. It is by means of this routing information that Alto Pup software such as FTP is able to communicate with hosts on other networks.

This service translates inter-network name/address expressions into addresses usable for communication. When an Alto subsystem is requested to establish contact with a host addressed symbolically (e.g., "Maxc"), it generates a name lookup request, to which the gateway responds by supplying the corresponding inter-network address (e.g., "3#200#").

Altos running microcode release X23 (including all Alto-IIs) are capable of boot-loading over the Ethernet if a suitable server is available to provide the boot files. The Nova Gateway provides this service for a limited set of boot files that are useful on an Alto with no disk loaded or with a disk that won’t boot (e.g., DMT, Scavenger, FTP, CopyDisk, and a NetExec providing more convenient access to the other boot files). There is no intention, however, of making available a complete set of Alto subsystems by this means.

In addition to these services, the Gateway program also implements several internal support protocols, such as the one that automatically updates the network directory data base.

The Pup Gateway disk contains all files needed for normal operation and maintenance of the Nova Gateway. The Pup Gateway Backup disk is a bit-for-bit copy of the regular disk. Due to the general unreliability of the Dos file system, it is prudent to back up the regular disk whenever significant changes are made to its contents. The procedure for doing this is described later.

A complete list of files on the disk may be obtained by issuing the Dos Executive command LIST/A. The files essential to normal Gateway operation are described below. Note that the Dos file system truncates filenames to ten characters before the period and two after the period, and turns all lower-case letters into upper-case; so, for example, the file GateParameter.Txt is actually stored as GATEPARAME.TX.

A parameter file that specifies the configuration for this particular gateway. All Nova Gateways run the same Gateway program, and differences in configuration are dealt with by this parameter file. The specifications in this file include:

These are Alto bootstrap files, given out by the Gateway program when an Alto is boot-loaded over the Ethernet. These files are updated occasionally when new versions of the programs are released at Parc.

The Gateway software includes the capability for remote updating of files on the Gateway Nova’s disk. It is also possible to remotely command the Gateway to restart, to reset its date and time, and to perform other operations. We use this remote control capability at Parc to release new versions of the Gateway program and to update the boot files. Therefore the following procedures should not be needed in the ordinary course of events.

This section describes procedures for obtaining new Gateway software or other files from Parc and installing them on the Gateway disk. This involves stopping the Gateway program briefly, so one should first make certain that there are no users who might be affected.

The following procedure assumes that the file being updated is Gateway.Sv, but it applies to any other file. The procedure requires use of some Alto connected to the same Ethernet as the Gateway Nova.

1. While the Gateway Nova is still in operation, run FTP on an Alto, connect to Maxc, and retrieve file <Portola>Gateway.Sv (Gateway-related files will generally be released from the <Portola> directory). After closing the connection to Maxc, leave the Alto running FTP.

3. Run the FTP program on the Nova, connect to the Alto, and retrieve Gateway.Sv (the command language for the Nova FTP is essentially identical to the Alto version). Note that since no name server is running at this point, it is necessary to refer to the Alto by number rather than name (e.g., if the Alto’s Ethernet address is 123, you connect to "123#"). After retrieving the file, quit out of FTP to the Dos Executive.

One might wonder why it is not possible simply to connect directly to Maxc from the Nova FTP in order to retrieve files. In order to do this, FTP would have to communicate over the SLA line to Parc. However, FTP (and other standard Nova subsystems) does not contain the software for driving the SLA interface, but rather contains drivers only for Ethernet and MCA (a network to which many Novas are connected at Parc). Hence, FTP running on the Gateway Nova can communicate only with machines on the directly connected Ethernet.

Important: The following procedure works only on Novas with Decision disk controllers. I do not know of any bit-for-bit copy program that works with Data General disk controllers.

This procedure causes a bit-for-bit copy to be made of the Gateway disk. Experience has shown the Dos file system to be quite unreliable, and it is not uncommon for data on a disk to be clobbered. Nova users at Parc back up their disks on a routine basis. Since the Gateway program does not make heavy use of the disk (and writes on it very infrequently), it is quite possible that the Gateway disk will never be clobbered. However, if the disk directory or the copy of Dos on the regular disk does get clobbered, one is in serious trouble without a backup.

If the normal Gateway disk does become clobbered, it may be restored from the Gateway Backup disk by putting the Backup disk in DP0, the regular (clobbered) disk in DP1, and running DKUTIL as above. One should never simply operate the Gateway running with the backup disk, since whatever caused the primary disk to be clobbered is likely to recur and clobber the backup disk as well.

A complete set of diagnostics for the Nova processor and memories, the SLA (made by Data General), and the Decision disks is included on the Gateway disk. These files all have names ending in ".BN", and are loaded using the EXEC program. The people responsible for maintaining the hardware should know how to run them.

Our experience with the SLA has been that the Data General diagnostic does not test it under realistic conditions. Therefore, if there are any indications of SLA or leased line trouble, one should first run the PupTest program (described in the next section). If a high error rate is discovered, further investigation is in order, regardless of whether or not the Data General diagnostic finds any problems. It should be noted that the Data General diagnostic will not operate unless all four lines have loop-back plugs installed; it does not suffice to locally loop back the modem, due to timing problems in the interface.

PupTest is a program developed primarily for checkout of the Pup software; however, some of its capabilities are helpful in locating and troubleshooting network problems. Both Alto and Nova versions of PupTest exist and operate similarly. The Nova version of PupTest (unlike FTP and other Nova subsystems) includes the SLA software and is therefore able to check out the SLA and the leased line directly.

The usual symptom of failure is likely to be that a user at SDD, EOS, or ADL is unable to access Maxc or some other machine in Palo Alto. There are a multitude of problems that can cause this, and one should not jump to the conclusion that the leased line or the Gateway is down. The following procedure should pinpoint the failing link.

The PupTest command used in this procedure is Echo. It requests the name or address of a host running an Echo Server, and it then sends Echo requests to that server. All Gateways have Echo servers, and any machine running PupTest itself has an Echo server. For each reply PupTest receives, it prints "!", and if no reply is received, it times out after 1.5 seconds, prints "?", and tries again. The test terminates when any key (e.g., space) is pressed.

1. Run PupTest on two Altos connected to the same Ethernet, and direct one of them to Echo to the other. One should address the other Alto by number rather than name; e.g., if the other Alto’s Ethernet address is 123, one should say "Echo to: 123#". If this doesn’t work, then the local Ethernet is broken.

2. Echo to the local Nova Gateway; that is, say "Echo to: n#", where n is the Gateway’s address on the local Ethernet (375, 56, and 1 for the SDD, EOS, and ADL Gateways respectively). If this doesn’t work, then the Gateway program is down or the Nova or its Ethernet interface is broken.

3. Echo, in turn, to each of the other Gateways along the path from the local Gateway to the unreachable destination. The path from the SDD Gateway (El-Portal) includes just Portola, the Gateway at Parc. The path from EOS and ADL also includes El-Portal. (It should be possible to reference these machines by name since the name lookup is performed by the local Gateway, which is known to be up by step 2.) If this doesn’t work, then there are a number of possibilities, some of which can be checked out by running PupTest on the Gateway Nova (see step 4). If it is possible to echo to Portola, then the most likely reason for inability to reach a host in Palo Alto (e.g., Maxc) is that the host itself is down.

4. Run PupTest on the Gateway Nova. Direct it to Echo to itself through one of the looped-back SLA lines; that is, say "Echo to: 7#n#", where n is the assigned SLA network address (2 for SDD, 4 for EOS, and 5 for ADL). Normal behavior in this case is for "!" and "$" to be printed out alternately ("$" means that the Echo server, running in the same machine, replied to an Echo request). If this doesn’t work, then the SLA interface is broken.

5. Press the AL (Analog Loopback) button on the modem so that it stays in its "in" position. Remove the three loop-back plugs from the back of the Nova, so that only the cable to the modem remains connected. Again direct PupTest to "Echo to: 7#n#". If this doesn’t work, then the local modem is broken. (When done with this test, restore the modem’s AL button to its "out" position and put back the loop-back plugs.)

6. If the previous test worked, but it was not possible to echo to Portola (step 3), then the failure is in the Gateway or modem at the far end of the first failing link or in the leased line itself. Determining which component has gone down requires cooperation with personnel at the far end.