|
HP OpenVMS Systems Documentation |
|
DECnet-Plus for OpenVMS
|
| Previous | Contents | Index |
The following subsections explain how to configure routing to use X.25 circuits on OpenVMS Alpha and VAX systems. On either system, you can use the advanced configuration procedure (invoking NET$CONFIGURE ADVANCED) to configure routing to use an X.25 data link. The procedure checks for network devices on the system that are supported by NET$CONFIGURE and then configures them. If the procedure finds that your system has WANDD or X.25 installed but not configured, you will see the following information:
You have installed wide area device support, but it has not been configured. You may configure it now if you want. * Do you want to configure Wide Area devices? [YES] : |
Answer yes.
For an Alpha system, the procedure displays the following information:
DEC X.25 software has been installed on this system. You have the option of configuring DECnet to run over X.25. * Do you want to configure DECnet over X.25? [NO] : |
You will see a list of choices for the type of X.25 circuit to use:
Types of X.25 circuits:
[1] - X.25 Dynamic Assigned (DA)
[2] - X.25 Static Incoming (IN)
[3] - X.25 Static Outgoing (OUT)
[4] - X.25 Permanent (PVC)
* Which type of X.25 circuit do you want to use? :
|
Select the X.25 dynamically-assigned circuit (Menu Option 1). The procedure then asks information about the circuit, including:
When you have entered the circuit, template, filter, and reachable address information, the procedure asks if you want to configure any other circuits. If you do not want to configure any other routing circuits, press the Return key for the default ([NO]). The configuration procedure continues with the next series of questions.
OpenVMS VAX Systems
If you answer yesto the question, "Do you want to configure wide area devices?" and you are using a VAX system, the procedure displays the following information:
The VAX P.S.I. software has been installed on this system. You have the option of configuring DECnet over P.S.I. (i.e., configuring DECnet over X.25 datalink mapping). * Do you want to configure DECnet over P.S.I.? [NO] : |
Answer yes to configure DECnet over X.25 Access (P.S.I.). The procedure displays the following list of choices:
Types of X.25 circuits:
[1] - X.25 Dynamic Assigned (DA)
[2] - X.25 Static Incoming (IN)
[3] - X.25 Static Outgoing (OUT)
[4] - X.25 Permanent (PVC)
* Which type of X.25 circuit do you want to use? :
|
Select the X.25 dynamically assigned circuit (Menu Option 1). The
procedure continues to ask for information, as described in
Section 8.8.3.2.
8.8.3.3 NCL Commands for Configuring X.25 Routing Circuits
To use NCL to manually configure X.25 routing circuits, following these steps:
ncl> create routing type endnode
ncl> set routing dna address format true, lifetime 63, -
_ncl> manual network entity titles {}, probe rate 20
ncl> enable routing
|
ncl> create routing circuit x25_circuit-1 type x25 da
ncl> set routing circuit x25_circuit-1 data link entity x25 access
ncl> set routing circuit x25_circuit-1 template template-name
ncl> set routing circuit x25_circuit-1 x25 filter { filter-name}
ncl> enable routing circuit x25_circuit-1
ncl> create routing circuit x25_circuit-1 reachable address ughh_v -
_ncl> address prefix /4145418715004108002b0ed41e
ncl> set routing circuit x25_circuit-1 reachable address ughh_v -
_ncl> dte address { 2267643 }
ncl> set routing circuit x25_circuit-1 reachable address ughh_v -
_ncl> mapping manual
ncl> enable routing circuit x25_circuit-1 reachable address ughh_v
|
ncl> create x25 access ncl> enable x25 access |
ncl> create x25 access template template-name (1) ncl> set x25 access template template-name - _ncl> destination dte address dte-address, - _ncl> dte class dte-class-name |
ncl> create x25 access filter filter-name (1) ncl> set x25 access filter filter-name - _ncl> inbound dte class dte-class-name, - _ncl> sending dte address dte-address ncl> enable x25 access filter |
X.25 static circuits emulate a permanent point-to-point circuit over an X.25 switched virtual circuit. The underlying X.25 connection is established when DECnet-Plus starts up, and the connection remains until explicitly terminated (normally at system shutdown).
When two systems communicate using X.25 static circuits, one system
must define the circuit as incoming, while the other system must define
it as outgoing. The system with an incoming circuit establishes
communication with the X.25 network provider and waits for a connection
from the other end. The system with the outgoing circuit initiates the
X.25 call to the waiting system. If the call fails, the system keeps
retrying until a successful connection is made. After the X.25
connection is established, the two systems automatically exchange
routing layer configuration information, autoconfigure their routing
databases, and begin two-way communications.
8.8.4.1 Configuring Outgoing X.25 Static Circuits
Take the following two steps to configure an outgoing X.25 static circuit:
NCL>create routing circuit circuit-name type x25 static outgoing (1) NCL>set routing circuit circuit-name template template-name (2) NCL>enable routing circuit circuit-name |
Take the following three steps to configure incoming X.25 static circuits:
NCL>create routing circuit circuit-name type x25 static incoming (1) NCL>set routing circuit circuit-name template template-name (2) NCL>set routing circuit circuit-name x25 filter {filter-name} (3) NCL>enable routing circuit circuit-name |
This chapter provides information about:
The information presented in the following sections supplements the
material provided by the OpenVMS Cluster Systems for OpenVMS
guide.
9.1.1 Adding, Modifying, or Deleting an OpenVMS Cluster Satellite Node
You must have planned your OpenVMS Cluster and have at least one OpenVMS Cluster boot node set up before using the information in this section. The following information is based on the CLUSTER_CONFIG.COM procedure found in the SYS$MANAGER directory. The OpenVMS Cluster Systems for OpenVMS guide describes this procedure. DIGITAL has modified the procedure to make it compatible with the DECnet-Plus software. In the following sections, only those portions of CLUSTER_CONFIG.COM that have been modified are discussed in detail.
You should also be familiar with the general concepts of the Maintenance Operations Protocol (MOP), and, in particular, the MOP client database, as described in Chapter 10.
If you are adding a new OpenVMS Cluster satellite node to your OpenVMS Cluster, see Section 9.1.1.1.
If you are making the transition from an existing Phase IV DECnet cluster satellite node to DECnet-Plus, see Section 9.1.2. After you have made the transition, you can invoke CLUSTER_CONFIG.COM to modify its characteristics.
You can delete a satellite node from the OpenVMS Cluster system with CLUSTER_CONFIG.COM whether or not the satellite node has made the transition to DECnet-Plus. If the satellite has not made the transition, a message appears stating that the client could not be removed from the client database. This will not cause a problem, and all root information will be deleted correctly.
By default, the satellite node information created by
CLUSTER_CONFIG.COM or NET$CONFIGURE.COM is placed in
the SYS$MANAGER root directory for the boot node. See
Section 9.1.4 for a discussion about making this information available
to other boot nodes in your OpenVMS Cluster system.
9.1.1.1 Adding a New Satellite Node to an OpenVMS Cluster Environment
To add a new OpenVMS Cluster satellite node to an OpenVMS Cluster environment, invoke the SYS$MANAGER:CLUSTER_CONFIG.COM procedure. This procedure does the following:
Refer to the OpenVMS Cluster Systems for OpenVMS guide for general information about CLUSTER_CONFIG.COM. You can enter a "?" at any prompt to display help text that explains what information is required at the prompt.
Table 9-1 explains the information specific to DECnet-Plus that CLUSTER_CONFIG.COM requests.
| Item | Response |
|---|---|
| What is the node's DECnet full name? |
Determine a full name with the help of your network manager. Enter a
string that includes:
For example: .world.networks.mynode mega:.indiana.jones columbus:.flatworld |
| What is the DECnet Phase IV compatible synonym name for this node? |
A node synonym is a short name for the node's full name. In an OpenVMS
Cluster environment, this name is used as the value of the SYSGEN
parameter
SCSNODE. It must also be defined in the namespace as the
synonym name for that node. Therefore, it must be a string of six or
less alphanumeric characters. By default, it is the first six
characters of the last simple name in the full name. For example:
Full name --- bigbang:.galaxy.nova.blackhole Synonym --- blackh Node synonyms greater than six characters in length are not supported if the node is an OpenVMS Cluster member. |
| What is the node's DECnet node address? | Enter the node's DECnet node address. This address is in the form area.node. Ask your network manager to help you determine this address. |
| Does synonym name need to be registered in the namespace [N]? |
Answer
YES to this question if the name of the node you are adding
has not been registered with the namespace. Registration makes your
node "known" to the namespace. You only need to do this once.
The registration might fail if your namespace has access control list (ACL) protection. If that occurs, your network manager must register the node for you. |
| What is the cluster alias full name? |
The alias name is the node name of the alias: the DECdns full name of
the object that stores the address towers for the alias. Do not enter a
node synonym.
If this node will not be participating in an OpenVMS Cluster alias, press carriage return. Determine the OpenVMS Cluster alias name with the help of your network manager. Enter a string that includes:
For example: .networks.farout mega:.proto.quikk |
| What is the Phase IV address of the cluster alias? |
The node ID of the alias could not be retrieved from the namespace, so
it must be calculated from the alias's Phase IV address. Enter the
Phase IV address of the alias in the
area.node format (for example, 63.137), or enter a 6-byte
ID in the format
AA-00-04-00-
xx-xx, where
xx-xx is calculated from the Phase IV node address. To
determine the Ethernet physical address, proceed as follows:
|
| What selection weight do you choose for this node? [0 for satellites] | The selection weight determines the percentage of incoming connections addressed to the alias that this node will handle. If the node is a satellite, take the default value of 0. For larger nodes, select a value between 1 and 10 (or larger if you want) according to the size of the node. |
The information you enter by means of CLUSTER_CONFIG.COM is automatically entered in the boot node's MOP client database and executed. The cluster_config procedure prompts you for other information. Then, it tells you when to boot your satellite node. The satellite node will run an AUTOGEN procedure shortly after booting.
After the satellite reboots, the NET$CONFIGURE procedure executes automatically. When it completes, the network starts, and the OpenVMS startup procedure continues until completion.
9.1.2 Making the Transition from an Existing DECnet Phase IV OpenVMS Cluster Satellite Node
Existing OpenVMS Cluster satellite nodes already have a root directory
on the system disk. Because these satellites are already in the OpenVMS
Cluster, you cannot use CLUSTER_CONFIG.COM to migrate them to
DECnet-Plus. However, you can take the following actions to migrate
the satellites:
Each of these steps is fully explained in the following list:
The following is a sample of the information requested when you
choose Option 8 of NET$CONFIGURE.COM, "Configure MOP Client
Database:"
* Which configuration option to perform? [1] : 8 * Do you wish to ADD or DELETE a MOP Client? [ADD] : * Name of the MOP Client? : tahini * Circuit for 'TAHINI'? : * Physical addresses for 'TAHINI'? : 08-00-2B-07-36-B6 * Secondary Loader for 'TAHINI'? : * Tertiary Loader for 'TAHINI'? : * System Image for 'TAHINI'? : "@net$niscs_laa(disk$v55:<sys10.>)" * Diagnostic Image for 'TAHINI'? : * Management Image for 'TAHINI'? : * Script File for 'TAHINI'? : * Dump File for 'TAHINI'? : * Verification for 'TAHINI'? [%X0000000000000000] : * Phase IV Client Address (aa.nnnn) for 'TAHINI'? [none] : 63.10 * Phase IV Client Name for 'TAHINI'? [TAHINI] : * Phase IV Host Address for 'TAHINI'? [63.61] : * Phase IV Host Name for 'TAHINI'? [CASIDY] : hummus * Do you wish to generate NCL configuration scripts? [YES] : %NET$CONFIGURE-I-CHECKSUM, checksumming NCL management scripts %NET$CONFIGURE-I-CONFIGCOMPLETED, DECnet-Plus for VMS configuration completed |
$ run sys$system:ncl ncl> @sys$manager:net$mop_client_startup.ncl |
One line in the file, create mop, generates an error message because the mop entity has already been created. You can ignore this message. |
The following example shows the information that network management
knows about the client configured in the previous step:
ncl> show mop client tahini all |
Node 0 MOP Client TAHINI
at 1995-04-21-18:32:38.205-04:00I0.448
Identifiers
Name = TAHINI
Characteristics
Circuit =
Addresses = {08-00-2B-07-36-B6, AA-00-04-00-0A-FC}
Secondary Loader = {}
Tertiary Loader = {sys$system:tertiary_vmb.exe}
System Image = {"@net$niscs_laa(DISK$V55:<SYS10.>)"}
Diagnostic Image = {}
Management Image = {}
Script File = {}
Phase IV Host Name = HUMMUS
Phase IV Host Address = 63.61
Phase IV Client Name = TAHINI
Phase IV Client Address = 63.10
Dump File = {}
Dump Address = 0
Verification = %X0000000000000000
Device Types = {}
|
| Previous | Next | Contents | Index |