HP OpenVMS Systems Documentation

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.

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:

decnet_migrate> collect data_file (1)
decnet_migrate> report report_file data=data_file (2)

1. Collects all information about your network and places it in a data file.
2. Reports information gathered with the collect command. In this example, the data is supplied from the data file and reported in a report file.

The following example shows how to use the show path command:

decnet_migrate> show path from node-name to node-name

For more information and an example output of the collect, report, and show path commands and their associated parameters, see Appendix D.

3.2 Determining the DECnet Version of Your System

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:

• Byte 0 = Customer ECO
• Byte 1 = DEC ECO
• Byte 2 = DEC Version (4 for Phase IV, 5 for DECnet-Plus for OpenVMS)
• Byte 3 = Reserved

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

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.

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:

• Use the WANrouter configuration program if your network configuration is simple and you have only a few interphase links to set up.
• Use the decnet_migrate create ipl_initialization_file command if your network configuration is complex and you have many interphase links to set up. This command automatically produces the NCL commands to create the links.

Invoke decnet_migrate on an OpenVMS system by entering the following command:

$ run sys$update:decnet_migrate

The following example shows how to create a command file that creates interphase link entries:

decnet_migrate> create ipl_initialization_file output-file (1) for
node-name (2)

1. Specifies the name of the command file you want to create.
2. Specifies the name of the DECnet Phase V level 2 routing node on which you want to create interphase link entries.

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

If either subnetwork contains more than one area, or if multiple subnetworks are interconnected, you must create interphase links to provide routing information about the nonadjacent areas.

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:

1. Identify all the DECnet Phase V level 2 routers that require interphase links. These are your target routers.
2. For each target router:
   1. Use the create ipl_initialization_file command specifying the target router.
   2. Run the resulting DCL command file to create the interphase link entries in the target router's reachable-address table.
   3. Wait at least 15 minutes for the routing information to propagate through the network.
3. Repeat step 2 n times, where n is the number of target routers.

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:

• Selecting name services and determining the order in which name services are searched
• Managing the in-memory naming cache for resolving names and addresses
• Managing DECdns and local namespace information using the decnet_register registration tool
• Updating and creating a local node's Phase IV database with information from a remote DECnet node's database

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.

Note that the search path information for a system is maintained in two separate search paths:

• One for forward translation or naming (node name to address translation)
• One for backtranslation (address to node name translation)

5.1.1 Determining the Order for Name Service Searches

Do not edit the NET$SEARCHPATH_STARTUP.NCL script. If you need to change the naming search path information, use NCL or rerun NET$CONFIGURE.

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.

5.1.3.1 Displaying the Naming Search Path

To display information about the search path maintained for forward translation or naming (node name to address translation), use the following nclcommand. Descriptions of the display example follow:

# 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 = "*"
            ]
        )

Note that each name service can have more than one entry, each template defining a different way for the name to be searched.