Example Configuration
This topic contains an example network configuration. This demonstrates the ROUTE-FILE entries required for various network connections, by starting with a single system and gradually adding connections.
The Initial Configuration
Imagine that you are the system manager of System A, a system running Solaris and connected to an Ethernet LAN.
Connected to the same LAN is System B, a Series 19 system running REALITY 7.0. To allow communication between the two systems, you must install UNIX-Connect on System A and then create various entries in the ROUTE‑FILE.
To allow incoming connections to System A, you will need to create one or more listening entries in the ROUTE-FILE. In this case, because System B is a Series 19 system, you will need a null network listening entry. For example:
System name : system_A_null_DDA Entry type : listening Device : /dev/rcs/tp4-nnw0 Interface type : TLI Provider type : ONE TSAP : 0203 NSAP : 0108003E221790 Network info : Comment : Null network DDA listening entry
The network type of the listening entry must be correct. For example, if incoming calls will be DDA null network (as in this case), then your listening entry must be DDA null network.
You need to create a separate listening entry for each type of network over which you will receive incoming calls (for example, OSI null, OSI full, TCP/IP and X.25). You also need to create a separate listening entry for each type of connection over which you will receive incoming calls (for example, OSI null DDA, OSI null ACI).
To allow your System A UNIX users to connect to System B you must create a destination entry for System B in System A's ROUTE-FILE. For example:
System name : System_B Entry type : destination Device : /dev/rcs/tp4-nnw0 Interface type : TLI Provider type : ONE TSAP : 0203 NSAP : 010000B9000190 Network info : Comment :
Your ROUTE-FILE entry, when displayed, should appear similar to the one shown above. The important points are:
The system name you use must be given to your users so that they can enter it as the system name when connecting. For example:
remlog System_B
This will result in display of the System B
Enter User Id:prompt.- The entry type must be “Destination”.
- This is a connection to a Series 19 system, so the network type must be “null”.
- You must enter the ethernet address of the Series 19 system (12 hexadecimal characters).
- For all other prompts, you can accept the default values.
Connection to UNIX
Also, connected to the LAN is System C, a system running UNIX V.4.
To allow your System A UNIX users to connect to System C, you will need to create a destination entry for System C in System A's ROUTE-FILE. In this case you have a choice of protocols, since both support null and full network OSI, and TCP/IP.
In this case we will use OSI full network, which is preferred over null network for connection between UNIX systems.
System name : System_C Entry type : destination Device : /dev/rcs/tp4-fnw0 Interface type : TLI Provider type : ONE TSAP : 0205 NSAP : 49000108003E21851301 Network info : Comment :
Your ROUTE-FILE entry, when displayed, should appear similar to the one shown above. The important points are:
The system name you use must be given to your users so that they can enter it as the system name when connecting. For example:
remlog System_C
This will result in display of the System C login: prompt.
- The entry type must be “Destination”.
- This is a connection to a UNIX system - you can select a network type of “null”, “full” or “tcp”.
- Because you are already using null network for connection to System B, you cannot use the same TSAP for full network connections. A TSAP of 0205 is recommended for full network connections, where null network connections are also required.
- You must enter the Ethernet address of the UNIX system (12 hexadecimal characters).
- For all other prompts, you can accept the default values.
To allow incoming connections from System C, you will need to create a full network or TCP listening entry as appropriate. For example:
System name : system_A_full_DDA Entry type : listening Device : /dev/rcs/tp4-fnw0 Interface type : TLI Provider type : ONE TSAP : 0205 NSAP : 49000108003E22179001 Network info : Comment : Full network DDA listening entry
Note: This is not necessary if incoming connections will use OSI null network, since you can use the null network listening entry created in step 1.
Network Replug
Connected to System C is System D. The connection between System C and System D is via a separate LAN, so System A cannot connect directly to System D.
To allow your System A UNIX users to connect to System D, a “network replug” must be performed via System C and you will therefore need to create a Q type entry in System A's ROUTE-FILE:
System name : System_D Entry type : Q type Referenced D system: System_C Comment : Replug to System_D
Your ROUTE-FILE entry, when displayed, should appear similar to the one shown above. The important points are:
- The name that you use as the system name of the Q type entry (in this example, System_D) must match the system name of a destination type entry on the intermediate system. The destination entry on the intermediate system defines the route to the ultimate destination (in this example, System D).
The system name you use must be given to your users so that they can enter it as the system name when connecting. For example:
remlog System_D
This will result in display of the System D
login:prompt.- The entry type must be “Q type”.
The “Destination system name to reference” (in this example, System_C) must be the system name of the destination entry in the ROUTE-FILE which specifies the intermediate system (the system which will perform the network replug).
A network replug is only possible over DDA circuits, so the referenced destination entry must have a connection type of DDA - this is the default, and is set when you press RETURN in response to the Is it a Character mode entry ? prompt.
Note: A network replug can also be used to allow connection between systems on the same LAN that do not share a common protocol; for instance, between a Series 19 and a UNIX system without an OSI transport stack. This is only possible, however, if you have a system that supports both protocols, to use as an intermediate system.
Remote Reality Database
Connected to the same LAN as System A, System B and System C is System E, a system running Solaris and Reality V9.1. System E holds a Reality database called DB.
To allow System A UNIX users to connect to the Reality database on System E, you will need to create two ROUTE-FILE entries on System A:
A destination entry for System E. For example:
System name : System_E Entry type : destination Device : /dev/rcs/tp4-fnw0 Interface type : TLI Provider type : ONE TSAP : 0205 NSAP : 49000100AA0002C70701 Network info : Comment :
As with System C, you have a choice of OSI null network, OSI full network or TCP/IP. In this case we have chosen OSI full network.
A Q-type entry for the database.
System name : DB Entry type : Q type Referenced D system: System_E Comment : Reality Database on System_E
Your ROUTE-FILE entries, when displayed, should appear similar to those shown above. The important points are:
- The destination entry for System E will be almost identical to that which you created for System C, but the system name must be unique and the ethernet address must be that of System E.
- When creating the Q-type entry, the “Destination system name to reference” must be the system name of the appropriate destination entry, that is, the system which holds the Reality database (in this example, System_E).
Notes:
- A Reality type entry must exist on System E that defines the Reality database, DB.
- You may also wish to create an entry in the USERS-FILE for each user wishing to log on to the Reality database. USERS-FILE entries are created under the local UNIX user-id and contain an entry for each destination system to which the user can connect. The “Destination system name” entered in the USERS-FILE must match the system name of the appropriate Q-type entry in the ROUTE-FILE (in this example, DB). The user-id entered in the USERS-FILE must be a valid UNIX user-id on the remote system and a valid Reality user-id on the Reality database.
Local Reality Database
Reality is installed on System A and a Reality database, called DB1, is created.
- To allow incoming
connections to the database, you will also need to create a Reality type entry
for DB1.
System name : DB1 Entry type : Reality Database path : /user0/realman/DB1 REALROOT path : /real/realman/4.1C Executable path : bin/reality Comment : DB1 database
Local Loopback
A program is installed on DB1, which acts as a client program initiating connections to UNIX servers on System A.
To allow the Reality and UNIX programs to communicate, you must create listening and destination loopback entries in the ROUTE-FILE.
System name : lb Entry type : listening Device : /dev/rcs/tp4-lb0 Interface type : TLI Provider type : LOOPBACK TSAP : 02,0203 NSAP : I Ethernet address : 000000000000 LSAP : FE Network info : Comment :
System name : loopback Entry type : destination Device : /dev/rcs/tp4-lb0 Interface type : TLI Provider type : LOOPBACK TSAP : 02,0203 NSAP : I Ethernet address : 000000000000 LSAP : FE Network info : Comment :
Your ROUTE-FILE entries, when displayed, should appear similar to those shown above.
Local Connection to Reality
A UNIX program is installed on System A, which acts as a client program initiating connections to DataBasic servers on DB1.
To allow communication between the UNIX client and the DataBasic server programs, you must create a Q-type entry in the ROUTE-FILE. This must have the same system name as the appropriate Reality entry, and must specify the local system as the Referenced D system.
System name : DB1 Entry type : Q type Referenced D system: loopback Comment : Local Loopback to DB1
Note that the Referenced D system field contains the system name of the destination loopback entry created in step seq n Loopback8.
Note: In general, each entry in the ROUTE-FILE must have a unique system name. The only exception is a Q-type entry, which can have the same name as a Reality or a SovereignX entry.
