DECnet-Plus
Planning Guide

For detailed information about DECnet-Plus routing, see the Routing Overview guide in the Phase V router product's documentation set.

2.4 Step 4: Plan for Your Name Services and the DECdts Time Service

The basic planning tasks related to the name services and DECdts are as follows:

• Decide to use the Local namespace, the DECdns distributed namespace, DNS/BIND, or several namespaces to maintain DECnet node name and addressing information. A distributed namespace uses both DECdns clerk and server software.
  Namespace planning for a distributed namespace includes designing the directory structure, planning an access control policy, and deciding on the contents of directories. For more information about planning a distributed namespace, read Chapters 6, 7, 8, 9, and 10.
  Also, if you are considering having multiple namespaces, read Section 2.4.2 and Section 7.1.
• If you choose to use a distributed namespace, plan which nodes become name servers and time servers.
  If your network uses a distributed namespace, every DECnet-Plus system in the network is a DECdns clerk and a DECdts clerk, but not every system should be a name server or a time server. Select your servers carefully based on the guidelines in Section 2.4.1.

You do not need to install a DECdns server if you use a Local namespace on all DECnet-Plus systems. All references to DECdns servers apply to those servers running on Digital UNIX or OpenVMS VAX systems. You need to configure one or more DECdns server systems if you intend to use a distributed namespace on one node or selected nodes. Use the following guidelines when choosing which DECnet-Plus systems will be DECdns and DECdts servers:

• Overall, Digital recommends you choose more time servers than name servers; therefore, the name server nodes can be a subset of the time server nodes. Two name servers and two time servers for every 1,000 nodes are usually sufficient. See your installation and configuration guides for detailed server configuration guidelines in both LAN and WAN environments.
• A DECdns server and a DECdts server must maintain at least one Phase IV-compatible address until no Phase IV nodes exist on the network that need to communicate with these servers. Lack of Phase IV-compatible addresses prevent the servers from communicating with Phase IV nodes.
• DECdns servers must have the NSP transport protocol enabled and should have the OSI transport protocol enabled. For DECnet Phase V networks using a distributed namespace, every system is a DECdns clerk and systems running either protocol must be able to communicate with any name server. If DECdns servers already exist on Phase IV systems, this requirement also ensures that they can talk to your DECnet-Plus DECdns servers in the network.

Digital recommends that you avoid using multiple namespaces. However, if your organization or network has special requirements that justify the use of multiple namespaces, you can create them and they can coexist without harm. See the DECnet-Plus DECdns Management guide for details about the implications of using multiple namespaces.

When multiple namespaces do exist in a network, they are separate and do not share information. You cannot replicate data across namespaces. Users can refer to a name in a namespace other than their own by including the namespace nickname in the full name reference.

If you want namespaces to interoperate, one trade-off is increased administrative overhead to keep track of and maintain entries in each namespace.

• Using multiple namespaces greatly increases the complexity of managing node object entries and soft links.
• Setting up access control to allow users to read entries in both namespaces is also complicated.

The easiest way to avoid the complexity is to limit node object entries and soft links to a single namespace, and use other namespaces for other purposes, such as testing, or building and using client applications.

If you need multiple namespaces in your network, and you want more than one namespace to contain node object entries and soft links, take the following steps after you install and configure new DECnet-Plus systems to ensure that they can communicate across namespaces:

• Decide which nodes each namespace will contain. Ensure that each node is registered in one, and only one, namespace.
• Create the namespaces you have planned. DECdns namespace creation involves configuring at least one server in each namespace.
• Run decnet_register once in each DECdns namespace to create the required DECnet-Plus directories. For instructions on running decnet_register, see your network management guide.
• Use the decnet_register export command to extract the node information from the Phase IV database. Edit the Export/Import file to correctly format the node information for the namespace you intend to use on the node. See your network management guide for more information.
• Use the decnet_register import command on each node to import the edited node information contained in the Export/Import file into the namespace on the node.
• Inform users that they must include a namespace nickname in a node full name when they refer to a node in a namespace other than their own.
• You can also create a soft link in your namespace for each node in another namespace. You can create this soft link in any directory that you consider appropriate.

  
  For example, a user in the IAF namespace could create a synonym soft link named IAF:.sample.Node01 that points to a node whose full name is ABC:.sales.Node01 in the ABC namespace. Then, users in the IAF namespace could refer to the node by the name Node01 and DECnet-Plus would translate the soft link to the node's full name. Make sure you establish adequate cross-namespace access control entries. Keep in mind that cross-namespace node synonym soft links must be manually updated if there is a change in the name of the node.

If you are already using a namespace created with Version 1 of the VAX Distributed Name Service (DNS) running on DECnet-VAX Phase IV, you can continue to use this namespace when you upgrade your networking software to DECnet-Plus. However, because of differences in the way DNS Version 1 and DECdns Version 2 handle access control, you must follow several steps to prepare your DNS Version 1 namespace for use by DECnet-Plus. These differences affect the way in which DNS Version 1 and DECdns Version 2 interpret principal specifications in access control entries (ACEs).

In DNS Version 1, servers recognize principals only of the form nodename::username. In DECdns Version 2, servers recognize principals primarily of the form nodename.username. To make it possible for the DECdns Version 2 clerks and servers that you will create later to interpret and process the DNS Version 1-style ACEs already in use in the namespace, create a backtranslation directory (.DNA_BackTranslation) and node synonym directory (.DNA_Node_Synonym) in the namespace's root directory. Then, populate these directories by registering all the nodes participating in the Version 1 namespace. See your installation guides for complete information on how to prepare a DNS Version 1 namespace for use by DECnet-Plus.

You need to perform these operations only once to prepare a DNS Version 1 namespace for use with DECnet-Plus. Once the node synonym and backtranslation directories are populated, you can configure new DECdns clerks and servers, or convert existing DNS Version 1 servers to DECdns Version 2 format in the normal manner. See the DECnet-Plus DECdns Management guide for complete information on how to configure a DECdns server into an existing namespace and how to convert a DNS Version 1 clearinghouse to DECdns Version 2 format.

Note

If you do intend to convert any of your existing DNS Version 1 clearinghouses to DECdns Version 2 format, Digital strongly recommends that you do not configure DECnet-Plus on any of your existing DNS Version 1 server nodes until after you have prepared your DNS Version 1 namespace for use by DECnet-Plus.

If you are using a namespace created with DNS Version 1, you are already familiar with many of the distributed naming and namespace planning concepts described in Chapter 6 through Chapter 10 of this guide. However, be sure to read all the DECdns-related sections in this guide to better understand the differences between DNS Version 1 and DECdns Version 2.

2.5 Step 5: Choose the First End System to Migrate

It is important to carefully identify the first node to migrate because, in a sense, it is from this point that you will move most of the network to DECnet Phase V. You will use this first system to manage other systems during migration and, probably, to set up the DECdns name service and initialize the namespace, if you are not using a Local namespace. The following are recommendations for choosing the first node to migrate:

• You will use this node to manage other nodes during transition, so ensure that it has access to other systems you want to manage and, possibly, migrate.
• If you want to use DECdns and it does not exist on the network, make the first node you migrate a DECdns server and create a distributed namespace. See Section 7.6 for guidelines on choosing a name server node.
• You can configure this node as a DECdns clerk and use an existing Version 1 name server with the following conditions:
  • The server node must be adjacent to this first DECnet-Plus system.
    On a LAN, adjacent means on the same LAN as the existing server; in a WAN environment, it means no other systems, except the router, are configured between the Phase IV name server and the DECnet-Plus system.
  • All DECnet-Plus systems must have DECnet-Plus paths to the Version 1 name server.

For details, see the appendix on DECdns version interoperability in the DECnet-Plus DECdns Management guide.

This chapter discusses your immediate transition tasks and the tools you need to complete these tasks.

You will perform some of these tasks during DECnet-Plus configuration, some while running the transition tools immediately after configuration, and some at other times. For information about how to perform these tasks, see your installation and network management guides.

3.1 Tools: Network Management, Node-Name Management, and Transition

DECnet-Plus software includes the following tools to help you during transition. After transition, some of these tools are used for ongoing network management support and node-name management.

• sys$system:net$mgmt.exe (for OpenVMS) or
  /usr/sbin/dna_mgmt (for Digital UNIX)
  A graphical user interface provided to manage Phase V nodes. You can enable NCL logging if you wish to see any NCL commands performed on your behalf by this Motif-based application.
• decnet_register
  Use the decnet_register tool to manage the node names and addressing information contained in both Local namespaces and DECdns distributed namespaces. Use decnet_register to:
  • Register node names, node synonyms, and addresses in your namespaces.
  • Add addresses to a node registration.
  • Remove addresses from a node registration.
  • Modify a node registration's synonym or addresses.
  • Display a node registration and verify its internal consistency.
  • Export node registration information from a namespace to a text file.
  • Import node registration information from a text file into a namespace.
  • Update a remote node's registered address information with information obtained from the node itself.
  • Rename a registered node in a namespace.
  • Deregister a node from a namespace.
  
  You can also use decnet_register manage command to create and manage the directories associated with the DECdns namespace.

• decnet_migrate
  Use this tool to:
  • Check information on the network's current configuration
  • Set up routing between Phase IV and DECnet Phase V areas
  • Convert NCP command files to NCL command files and upgrade either DCL command files or UNIX scripts that contain NCP commands
    
    
  • Use the Language Sensitive Editor (LSE) to create and edit NCL command files <>
  • Learn NCL syntax and NCP/NCL equivalents
  
  For complete information about using decnet_migrate, see your network management guide.
  
  
• sys$update:net$convert_database
  Upgrades the object database for DECnet-Plus for OpenVMS and converts the Phase IV MOP database to the DECnet-Plus MOP client database. During net$configure you are asked if you want to convert Phase IV databases. Answering yes runs sys$update:net$convert_database.

  ---

  Note

  DECnet-Plus for OpenVMS uses the proxy file created with DECnet for OpenVMS Phase IV; therefore, no update is needed. <>

  ---

  
  
  
• /usr/field/objtoncl (for UNIX)
  Converts the Phase IV object database to an NCL script (see Section 3.3.1).
• /usr/field/proxytoncl (for UNIX)
  Converts the Phase IV proxy file to an NCL script (see Section 3.3.2).
• /usr/field/update_mopdb (for UNIX)
  Converts the Phase IV MOP database to the DECnet-Plus MOP client database (see Section 3.3.3). <>

Migrating a network ultimately means migrating individual systems. Follow your transition plan to decide which procedures you will use, and in what order. No one way to migrate is correct for all networks. However, the following steps always apply:

1. Determine if the default IDP is appropriate for your network, and, if not, obtain a unique IDP. See Section 3.2.1.
2. Decide if you will use a Local namespace, a DECdns distributed namespace, or both.
   • If you use a DECdns namespace, see Section 3.2.3 for information about migrating the first end node. See Section 3.2.4 for information about migrating subsequent end systems.
   • If you use a Local namespace, see Section 3.2.2 for instructions on how to create a Local namespace for each node you configure.
   • If you use both, refer to the DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration for detailed information.
3. For DECnet-Plus for OpenVMS, migrate OpenVMS cluster nodes. See Section 3.2.5.
4. Migrate local area networks. See Section 3.2.6.
5. Configure DECnet-Plus end systems in a multivendor OSI network, if your network is multivendor. See Section 3.2.7.

   ---

   Note

   The DECnet-Plus software installation procedure differs considerably from Phase IV installations. For complete instructions on installing and configuring, see your installation guides.

   ---

   3.2.1 IDP Planning

   To configure the first DECnet-Plus system, you must know its new OSI address, including your network's IDP and, in some cases, the preDSP as well.

   Determine if you can use the default IDP. If you cannot, before you start the transition to DECnet-Plus, apply for a unique IDP. For information about the format of DECnet Phase V addresses, see Chapter 4; for details about IDPs, see Section 4.1, and for instructions on how to get a unique IDP for your network, see Section 4.7.

   3.2.2 Using a Local Namespace: Migrating the Network

   With a Local namespace, migrating consists of installing and configuring DECnet-Plus. To create a Local namespace, take the following steps:

   1. Install and configure your DECnet-Plus software.
      1. When the configuration procedure prompts you for your node full name, type local:.nodename. The reserved nickname for the Local namespace is local.
      2. The configuration procedure automatically creates the local name file.
         If neither data file exists or is readable, the procedure creates the local name file with information for the node in it.

         
         
         
         For OpenVMS, if the DECnet Phase IV node data file sys$system:netnode_remote.dat exists and is readable, then answer YES to the question, Do you want to convert a Phase IV database? and the procedure converts it to the local name file.
         The procedure will also use the decnet_register export and import commands to extract the node information from the Phase IV database and to import it into the Local namespace.<>

   2. You are ready to use Go to Section 3.2.6.

   3.2.3 Using a Distributed Namespace: Migrating the First End Node

   Migrating the first end node includes several tasks that affect the management and migration of the entire network. These tasks include creating the namespace, configuring the first name server, and setting up access control. Therefore, it is important that the network manager carry out or oversee the migration of the first end node.

   To help you plan, this section outlines the steps required to install and configure the first DECnet-Plus system in the network. Section 3.2 is meant to serve as a "road map" to familiarize you with the transition steps you need to take. The goal is to prepare you for installation, configuration, and transition as documented in the installation guides.

   DECdns server software is not available for OpenVMS Alpha systems, therefore, all references to DECdns servers apply to those servers running on Digital UNIX or OpenVMS VAX systems.

   Choose the scenario that applies to your transition:

   • If the network does not have a DECdns namespace, create a new DECdns namespace when you migrate the first system (see Section 3.2.3.1).
   • If the network has a DNS Version 1 namespace (OpenVMS only), you join this existing namespace when you migrate the first system (see Section 3.2.3.2).
   • If your network already has a DECdns Version 2 namespace, follow the instructions in Section 3.2.4. Each node you install and configure is a subsequent node. If you are considering multiple namespaces, see Section 2.4.2 and Section 7.1 for restrictions and guidelines.

   3.2.3.1 If the Network Does Not Have a Namespace

   If you choose to install and configure the first DECnet-Plus node in a network with no existing namespace, follow the steps in this section. All references to DECdns servers apply to those servers running on Digital UNIX or OpenVMS VAX systems.

   1. On the system to undergo the transition, ensure that the permanent node database is up to date. Back it up. This database file is:
      sys$system:netnode_remote.dat (OpenVMS only)
      /usr/lib/dnet/nodes_p (Digital UNIX only)
   2. Replace any unsupported hardware.
   3. Install your DECnet-Plus software. As part of the installation and configuration, install and configure the DECdns server software.
      On an OpenVMS VAX system, perform the advanced configuration @sys$manager:net$configure advanced.
      On a Digital UNIX system, perform the advanced configuration, decnetsetup advanced.
      During the configuration procedure:
      1. It automatically configures the system as a DECdts server if a time synchronization service is not already running in your network.
      2. You create a namespace in one of the following ways:
         • If you specified local during network configuration, a local namespace is created automatically.
         • If you specified decdns during network configuration, DNS$CONFIGURE is called to create a new DECdns namespace.
         • If you choose DECdns, you also need to do the following after the configuration procedure exits:
           • Use the decnet_register manage command to create the namespace directories, create and enable a clearinghouse, and create the root directory of the namespace in that clearinghouse.
           • Use the decnet_register manage command to initialize the namespace for use by DECnet-Plus. This initialization creates the node synonym directory (.DNA_NodeSynonym by default), the backtranslation directory (.DNA_BackTranslation by default), and the global time servers directory (.DTSS_GlobalTimeServers by default).
           • Use the decnet_register manage command to create the .DNA_Registrar access control group. The group is initially empty; use decnet_register later to add members.
           • Rerun the configuration procedure for the system to configure it as a DECdns server and a DECdns clerk.
      3. Implement the namespacewide access control policy you have decided to use. Digital highly recommends this practice, especially in large networks. Section 7.4 describes how to plan an access control policy.
         To implement this policy, use the decnet_register manage command to add members to .DNS_Admin, the namespace administrator group, and add access to the root directory.
      4. Use the decnet_register manage command to modify default access control for the node directories.
      5. While you are using decnet_register, make sure that the account under which you will run your startup procedure has at least write access to the newly created clearinghouse and root directory.
      6. Your DECnet-Plus node cannot communicate with a Phase IV node until the namespace has an object and soft links for that Phase IV node. Therefore, if your network is to include Phase IV nodes, register those nodes in the namespace now. Follow these steps:
         1. Make sure that on the newly installed DECnet-Plus node, you have the up-to-date copy of:
            sys$system:netnode_remote.dat (OpenVMS only)
            /usr/lib/dnet/nodes_p (Digital UNIX only)
         2. Use decnet_register to populate the namespace with Phase IV node objects and soft links. See your network management guide.
            Do this before populating the namespace with any other node names.
            Use the decnet_register manage command to create the .DNA_Node directory at this time. The node information files are initially set up to register the Phase IV nodes in this directory. (If you want, you can edit those files to change the name of the directory into which the nodes are to be registered.)
         3. Use decnet_register to:
            • Fill .DNA_Node with objects for Phase IV node names.
            • Fill the .DNA_NodeSynonym directory with soft links pointing from each node's Phase IV-style synonym to its full object name.
            • Fill the .DNA_BackTranslation area subdirectories with soft links pointing from each node address to its full object name. Each area subdirectory is populated with the node IDs of systems in that area.

            After you install and configure the first DECnet-Plus system, install subsequent systems according to the transition schedule you have planned. See Section 3.3 for additional transition tasks.

            3.2.3.2 If the Network Has a DNS Version 1 Namespace

            If you are already using a namespace created with Version 1 of the VAX Distributed Name Service (DNS) running on DECnet-VAX Phase IV, you can continue to use this namespace when you upgrade your networking software to DECnet-Plus. However, because of differences in the way that DNS Version 1 and DECdns Version 2 handle access control, you must perform several steps to prepare your DNS Version 1 namespace for use by DECnet-Plus. These differences affect the way in which DNS Version 1 and DECdns Version 2 interpret principal specifications in access control entries (ACEs). For more information, refer to Section 2.4.3.

            3.2.4 Using a Distributed Namespace: Migrating Subsequent End Nodes

            The transition of any end node other than the first end node consists of installing and configuring the DECnet-Plus software. System managers can therefore migrate subsequent end nodes, as long as the network manager is available to supply the information required to answer the prompts during installation and configuration.

            Installers might need help registering nodes in the namespace. Near the end of the configuration, the procedure attempts to automatically register the node in the namespace. Registration could fail, depending on the type of installation being performed and the protection level of the namespace. If it does fail, you get a message stating that you will have to manually register this node in the namespace.

            To simplify node registration, you can implement one of the following strategies before installing subsequent nodes:

            • Manually register each subsequent system in the namespace before it is installed and configured. Use decnet_register. See your network management guide.
            • Enable node autoregistration for all directories into which users will register systems so that, during node configuration, each system can be registered automatically. Table 3-1 and Table 3-2 summarize how automatic registration and manual registration apply to:
              • New systems
              • Systems making the transition from Phase IV to DECnet-Plus
              • Systems downgraded from DECnet-Plus to Phase IV

            3.2.4.1 Registering a New System

            Table 3-1 describes how you use decnet_register to register a new system in the namespace after installing DECnet-Plus or Phase IV software on the system, assuming that the system is not currently registered in the namespace.

            Table 3-1 Registering a New System

            Phase of the New System	Autoregistration Allowed&185;		Autoregistration Disallowed&178;
            	Automatic Registration	Manual Registration	Automatic Registration	Manual Registration
            DECnet-Plus System	Yes	Not required	No	Register the system as a DECnet-Plus system.
            Phase IV System	No	Register the system as a Phase IV system.	No	Register the system as a Phase IV system.

            ---

            ¹If a directory allows autoregistration, all systems and users have read/write access to that directory, allowing anyone to register nodes in it.
            ²If a directory disallows autoregistration, only users who are explicitly granted read/write access to that directory can register nodes in it.
            

            ---

            ---

            Previous | Next | Contents | [Home] | [Comments] | [Ordering info] | [Help]

            ---

            
            

              PLAN_PROFILE_003.HTML
              OSSG Documentation
               2-DEC-1996 12:32:07.52
            

            Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

            Legal