The ROUTE-FILE

The ROUTE-FILE contains the details of the hosts to which you will connect. This topic describes the different types of ROUTE-FILE entry and when to use them. It also describes the ROUTE-FILE Maintenance Utility, which allows you to create, modify and delete ROUTE-FILE entries.

Introduction

Routing information used by the UNIX-Connect software is held in the UNIX file /etc/ROUTE-FILE. When creating ROUTE-FILE entries, the information that you are required to enter varies according to the type of network and the network protocol.

Network Types

UNIX-Connect supports the following types of network:

Note that OSI and X.25 require additional software that does not form part of the standard UNIX-Connect product.

Network Configuration

For all network types, you must specify the following:

System Name Each entry in the ROUTE-FILE is identified by its system name. A system name must contain at least one character (it cannot be the single letter “q”) and must not be greater than 49 characters in length.

In the majority of cases, the system name must be unique. The one exception is a Q-type entry that references a local Reality database or SovereignX environment — in this case, the system name can be the name of the appropriate Reality or SovereignX entry. See Types of Entry.

Device The device to be used for this type of network connection. Whatever the network type, there is a default device which can be accepted simply by pressing RETURN in response to the appropriate prompt when creating ROUTE-FILE entries. See ROUTE-FILE Maintenance.

On systems with more than one controller of the same type (for example, with multiple Ethernet controllers or multiple X.25 controllers), a unique device name must be used for each controller. In order to route outgoing calls via the appropriate controller, the device name in the ROUTE-FILE destination entry must match the device name in the listening entry for that controller.

Note

Before installing multiple controllers, contact NEC support.

Provider Type (not required for local loopback connections)
The transport interface provider used varies according to the system and network type. When you create a ROUTE-FILE entry, the software automatically selects the provider type appropriate to the network type. You should always accept this selection unless advised otherwise by NEC support.

Connection Type (not required for local loopback connections)
The connection type may be DDA (Distributed Data Access) or character mode (ACI). When deciding which to use, you should consider the following:

  • DDA is preferred for terminal connections to Reality.

  • Character mode is preferred for terminal connections to the UNIX environment.

  • DDA must be selected for client/server connections.

  • Character mode must be selected for outgoing connections to Network Printers, terminal connections to non-NEC systems, and incoming connections from Terminal Servers that do not support DDA.

Note that when you use a character circuit for connection to another host, a new PLId is assigned. This might have implications for location based security. See Network Security and the User?s Reference: Administration for more information).

Null Network

For OSI null network connections the following additional information is required:

Full Network

For OSI full network connections, the following additional information is required:

X.25/XUI

For X.25/XUI connections, the following information is required:

TCP/IP

For TCP/IP connections, the following information is required:

Types of Entry

The ROUTE-FILE can contain seven different types of entry. A description of each is given below.

Destination

A destination entry defines a remote system. These entries contain full routing details for outgoing calls.

For DDA connections over TCP/IP, you can use a skeleton destination entry. This uses your Domain Name Service (DNS) to resolve the names of hosts that do not have destination entries in the ROUTE-FILE.

A default skeleton entry called DDAskeleton is created when UNIX-Connect is installed. You can add more if you wish, but only one can be active at any time. The active skeleton entry is defined in the file /etc/init.d/rcs and takes effect when the session manager is restarted.

Listening

A listening entry allows the session manager process to accept incoming calls from remote hosts. Listening entries are normally set up when UNIX-Connect is installed and do not change unless the local system's network connection is altered. For every network type in use there must be at least one listening entry and there may be two: one DDA and one character mode.

On systems with both null and full network OSI listening entries, each will normally require a different TSAP. Having multiple network interfaces increases the complexity, depending on the number of different network types that are in use. In some circumstances, multiple listening entries will be required, but with the ONE transport provider, it is also possible to use what is called multibind, where one listening entry is used for all network interfaces.

If Location Based Security is required and connection is via a non-NEC terminal server that does not associate a TSAP with each physical port, one listening entry will be required for each terminal server port. Note, however, that because each terminal server is uniquely identified by its NSAP, the actual number of listening entries required is that of the number of ports on the largest terminal server. For example, if your largest terminal server has 16 ports, you will need 16 listening entries, however many terminal servers you have.

Note

Each of these listening entries must be Type 2 character-mode.

On TCP/IP connections, most systems will accept a listening endpoint for “anyhost” or IP address 0.0.0.0. Your support representative will advise you if this does not apply.

Q-type

A Q-type entry references a destination entry. It can be used:

Reality

A Reality entry accepts incoming calls for a Reality database.

SovereignX

A SovereignX entry accepts incoming calls for a SovereignX environment.

Alternative Host

An Alternative Host entry allows you to specify one or more hosts to try if your initial connection fails. The entry consists of a list of destination entries in the order in which connection attempts are to be made. There is no limit to the number of alternative hosts.

When connection to an Alternative Host entry is attempted, the connection is routed to the first host in the list. If the connection fails, that host is marked as failed and the next one is tried (and so on until one succeeds).

Failed hosts remain marked as failed until a timeout period expires; subsequent connections to the Alternative Host entry will not try any hosts that are marked as failed. If none of the connections succeeds, an error message is displayed. The failed hosts will then be re-enabled and the next connection attempt will start again at the beginning of the list.

Alternative host entries are used, for example, to connect to a system via a Heartbeat Gateway where there are multiple gateways.

Local Host

A local host entry allows you to specify a DDA network name for your host system. This name will then be included in the Client-ID whenever you make a connection. If there is no local host entry, the name of the corresponding listening entry (that is, the listening entry that uses the same network device) will be used as the host name.

Heartbeat

Heartbeat entries are only required on Heartbeat Gateway systems. The system name of a Heartbeat entry is a Heartbeat application name - when a connection is attempted, the application name is passed to the Heartbeat software which returns a primary system name. The primary system name must match the system name of a destination entry in the Heartbeat Gateway's ROUTE-FILE. Refer to the SeriesX Heartbeat Reference Manual for more details.