HP OpenVMS Systems Documentation
DECnet-Plus for OpenVMS
Before you begin to change your network's configuration, make sure you have a clear picture of the network's current topology. Two decnet_migrate commands, collect and report, gather and organize information about the DECnet Phase IV and Phase V nodes and connections in your network. A third command, show path, displays the possible paths that node-to-node communication might take through the network, helping to determine what effect the transition has had on the network's communication paths.
You need network management privileges that allow you to display information for each remote node in the network, so the collect and show path commands can gather information from the nodes. You also need the same privilege for the local node.
The collect and show path commands operate by sending network management requests. They use the Network Information and Control Exchange (NICE) Protocol and the DIGITAL Network Architecture Common Management Information Protocol (DNA CMIP); they do not use the Simple Network Management Protocol (SNMP). The collect and show path commands can succeed only when the nodes are able to respond to either NICE or DNA CMIP network management requests. The commands do not work, for example, if the nodes respond only to SNMP requests.
For collect, if an area contains both routers that do and do not respond to NICE or DNA CMIP requests, you can collect information about the area by using the area=node:node_name parameter and specifying the node name of a router that does respond to NICE or DNA CMIP requests.
This use of the area parameter is useful when an area contains only a few routers, such as cluster alias routers, that respond to NICE or DNA CMIP. The collected data will not, however, contain information on nodes that do not respond to NICE or DNA CMIP requests, other than their network addresses. Invoke decnet_migrate on OpenVMS systems by entering the following command:
$ run sys$update:decnet_migrate
The following example shows how to collect and report information about your network configuration:
The following example shows how to use the show path command:
decnet_migrate> show path from node-name to node-name
Either DECnet Phase IV or DECnet-Plus for OpenVMS (Phase V; Alpha or VAX) can run on a particular system; thus, you cannot use the OpenVMS version to determine which software version is running. Instead, an item code for the $GETSYI system service (DECNET_VERSION) shows the version of DECnet that is running. The system cell containing the setting of this value is set by SYS$NETWORK_SERVICES when the system boots. You can read the value directly with a program or through the F$GETSYI lexical function with a command procedure. The DECNET_VERSION item has the following format:
To distinguish Phase IV from DECnet-Plus for OpenVMS, use DEC Version (byte 2).
For example, the lexical function F$GETSYI("decnet_version") returns the value %X00040000 for a system running Phase IV. DECnet/OSI for OpenVMS Version 6.3 returns %X00050902.
Any program or command procedure that requires different execution based on the DECnet version should check DECNET_VERSION.
The format of the version longword is as follows:
|Reserved|DEC Major|DEC Minor|User ECO| 31 0
|OpenVMS Alpha and VAX Version 6.1 and Version 6.2|
|00050902||DECnet/OSI Version 6.3 (+ ECO 2)|
|OpenVMS Alpha Version 7.0|
|00050B01||DECnet/OSI Version 7.0A MUP|
|OpenVMS VAX Version 7.0|
|00050B00||DECnet/OSI Version 7.0|
|00050B02||DECnet/OSI Version 7.0 (+ ECO 2)|
|OpenVMS Alpha Version 7.1|
|00050C00||DECnet-Plus Version 7.1|
|OpenVMS VAX Version 7.1|
|00050C00||DECnet-Plus Version 7.1|
DECnet Phase IV routers and DECnet-Plus host-based routers use a routing vector protocol to relay messages and exchange routing information. DECnet Phase V routing also features a link state routing protocol. These two protocols can coexist in the network.
All routers within an area must use the same routing protocol at level 1. However, DECnet Phase V allows level 2 routers to run either a routing vector or a link state protocol at level 2. Routers running different protocols at level 2 can communicate through interphase links. An interphase link directly connects a level 2 router using a routing vector protocol with a level 2 router using a link state protocol. DECnet Phase V routers running link state use manually configured reachable-address tables to route information across these interphase links.
Interphase links require the two areas connected by the interphase link to have different area numbers.
You can set up interphase links in one of two ways: use the WANrouter (or DECNIS) configuration program, as described in your router documentation, or use the decnet_migrate tool's create ipl_initialization_file command, as described in this chapter. Choose only one method, following these guidelines:
$ run sys$update:decnet_migrate
For more information about the create ipl_initialization_file
command, see Appendix D. The following sections provide more
information about setting up interphase links.
4.2 Configurations That Do Not Require Manually Created Interphase Links
The simplest configuration that connects DECnet Phase V link-state subnetworks to Phase IV routing-vector subnetworks is one in which only two subnetworks are connected, with only one area in each subnetwork, as shown in Figure 4-1.
Figure 4-1 Configuration with Adjacent Areas
In this case, you are not required to manually create the interphase
link because the adjacent areas automatically configure to each other.
4.3 Configurations That Require Manually Created Interphase Links
For small networks (for example, with three or four areas), you can enter the interphase link information into the reachable-address tables using the appropriate router configuration tools. For details, see the management documentation for your router.
For larger networks, you can use the create ipl_initialization_file command to create a DCL command file on an OpenVMS system. When executed, the command file creates interphase link entries in the reachable-address table on the target DECnet Phase V level 2 router. Whenever the level 2 network configuration changes, DIGITAL recommends that you use the create ipl_initialization_file command for every DECnet Phase V level 2 router that has interphase links.
Figure 4-2 shows a level 2 network configuration that requires manually created interphase links, because areas 2 and 4 are nonadjacent and, therefore, do not exchange routing information.
Figure 4-2 Configuration Requiring Manually Created Interphase Links
If your network configuration consists of multiple Phase IV routing-vector subnetworks connected by DECnet Phase V link-state subnetworks, you must run the create ipl_initialization_file command multiple times. Each time, specify the DECnet Phase V link-state level 2 router that needs interphase links. The same is true for networks that consist of multiple DECnet Phase V link-state subnetworks connected by Phase IV routing-vector subnetworks. Figure 4-3 shows two examples of these configurations.
Figure 4-3 Two Configurations with Multiple Interphase Links
If you use the create ipl_initialization_file command only once for each target router, the routing information created in the target routers' reachable-address tables is incomplete. It is incomplete because not all area routing information is available to each target router at the time the command is run. Information about nonadjacent areas becomes available only after you run the command file, created by the create ipl_initialization_file command.
For configurations with multiple interphase links, the simplest way to guarantee that routers have all required interphase links is to:
After you complete these steps, routing information for every area is
available to every level 2 router in the network.
4.5 Configurations with Multiple Interphase Links Between Two Subnetworks
You can use either a single interphase link or multiple interphase links to connect two subnetworks. This section discusses the advantages and disadvantages of both methods. Figure 4-4 shows the use of a single interphase link.
Figure 4-4 Single Interphase Link Between Two Subnetworks
The advantage of the configuration shown in Figure 4-4 is that it is easier to diagnose connectivity problems. The disadvantage is that it makes possible a single point of failure between the subnetworks.
You can use multiple interphase links to provide communication path redundancy between the subnetworks, as shown in Figure 4-5.
Figure 4-5 Multiple Interphase Links Between Two Subnetworks
In Figure 4-5, the configuration solves the problem of having a single point of failure, but it can result in areas being unreachable even though there is a physical path that could be used. This makes connectivity problems more difficult to diagnose.
For example, in Figure 4-5, if the lowest cost path from area 1 to
area 5 is through area 4, and the circuits connecting area 4 to area 5
go down, messages from area 1 to area 5 are still sent to area 4. This
is because area 1 cannot detect the loss of connectivity between areas
4 and 5. Therefore, area 1 continues to send these messages through
area 4 rather than through area 2, because the path through area 4 is
the lowest cost path to area 5, but the messages never reach area 5.
4.6 Special Considerations Regarding Network Costs
When the create ipl_initialization_file command gathers the information about which areas exist and which paths to use to reach those areas, it also calculates the cost associated with each path. A network cost is then associated with each interphase link in the reachable-address table.
A restriction is built into the reachable-address tables regarding network cost. Costs of 63 or more cannot be included in the table. If a path has a network cost of 63 or greater, when you run the create ipl_initialization_file command, the commands to create the interphase link for that path are included in the command file as comments. When you run the command file, that path will not be entered into the reachable-address table.
You can, however, edit the output_file_cre command file on OpenVMS to change the network cost values. You must have a clear picture of your network topology to be able to make good decisions about modifying network cost values.
Refer to your router management documentation for more information about network costs.
This chapter covers the following topics:
For storing name and address information, DECnet Phase V supports the local namespace, the DECdns distributed namespace, and the Domain Name System (DNS/BIND) distributed namespace. DECnet Phase V uses one or more of these namespaces to look up name or address information. The order in which DECnet Phase V searches the available namespaces is determined by the naming search path. The naming search path is set up during DECnet configuration. The naming search path applies to DECnet applications systemwide.
The ordering of the name services is important. The first name service listed is the primary name service to use on the system. The primary name service is the first choice used when looking up names and addressing information. The remaining name services listed are the secondary name services used on the system.
DECdns servers must be configured to use DECdns as the primary name service.
5.1.1 Determining the Order for Name Service Searches
On OpenVMS systems, the system administrator uses
NET$CONFIGURE to configure DECnet-Plus and set up one or more
name services for a node. From the information provided by the system
administrator, NET$CONFIGURE creates the
NET$SEARCHPATH_STARTUP.NCL script, which contains the naming
search path information for the node. For example, if the system
administrator chose the ordered list of LOCAL,DECDNS,DOMAINfor
the directory services at configuration time, then DECnet-Plus searches
the local namespace first for forward and back translation information.
If necessary, it will then search the DECdns namespace specified in the
node's DECdns name. Finally, if it still has not successfully obtained
the translation information, it will use the Domain Name System.
Do not edit the NET$SEARCHPATH_STARTUP.NCL script. If you need
to change the naming search path information, use NCL or rerun
5.1.2 Using the Naming Search Path to Interpret Abbreviated Node Names
Besides determining the order of searches, the naming search path
describes how DECnet should interpret any abbreviated node names
entered by users. The search path contains an ordered list of name
service keywords, each followed by a naming template
that specifies a "defaulting rule" so users can enter shorter node
names. In each template, the user-supplied portion of the name (usually
the node's terminating name or rightmost simple name) is indicated with
an asterisk (*). For example, if the DECdns template is
"ACME:.mgmt.*" and a user supplies the name accnt,
then the full name ACME:.mgmt.accnt will be looked up in
namespace ACME in the DECdns name service. See Section 5.1.3
for more examples.
5.1.3 Displaying and Modifying Search Path Information
You can use nclcommands to display information about the
search path maintained for forward or backward translation.
126.96.36.199 Displaying the Naming Search Path
# ncl show session control naming search path Node 0 Session Control AT 1996-03-19-10:26:03.809-05:00I49.474 Characteristics Naming Search Path = ( [ Directory Service = Local , (1) Template = "*" ] , [ Directory Service = Local , (2) Template = "local:.lky.*" ] , [ Directory Service = Local , (3) Template = "LOCAL:*" ] , [ Directory Service = DECdns , (4) Template = "*" ] , [ Directory Service = Domain , (5) Template = "*" ] )