1 Network_Management Some network management concepts and tools are described in this NCL HELP file for easy access. For more detailed information refer to the Network Management manual. 2 Access_Control Available methods for controlling access to network information and the policies used to determine that access depend upon the operating system(s) involved. 3 Rights_Identifiers_(OpenVMS) HP DECnet-Plus for OpenVMS uses VMS rights identifiers to perform access checks on all manageable entities. This differs from the Phase IV software, which used VMS privileges for access to the permanent database and for write access. Read access to the volatile database in Phase IV was unprotected. The rights identifier NET$EXAMINE grants a user read access to the network configuration data. The NET$MANAGE rights identifier grants read and write access to the network configuration data, and NET$SECURITY grants ability to set default accounts. These rights allow the network manager to restrict access to network parameters. Access is granted to an individual user by means of the AUTHORIZE utility on OpenVMS. The following command examples grant access: UAF> GRANT/ID NET$EXAMINE Joe ! Grant user JOE read access to local network data UAF> GRANT/ID NET$MANAGE Joe ! Grant user JOE read/write access to local network data UAF> GRANT/ID NET$SECURITY Joe ! Grant user JOE ability to set default accounts In lieu of NET$MANAGE rights, the BYPASS privilege will grant read and write access. 3 Proxies_(OpenVMS) Proxies are managed using the AUTHORIZE facility. Here are examples of adding proxies to grant access to remote user SMITH on node LAMCHP to the JONES account on the local node: UAF> ADD/PROXY DOMAIN:LAMCHP.SCH.DEC.COM::SMITH JONES UAF> ADD/PROXY DEC:.SCH.LAMCHP::SMITH JONES UAF> ADD/PROXY LOCAL:.LAMCHP::SMITH JONES Each proxy record should specify a default account, regardless of whether a default wildcard proxy exists, to ensure that at least one valid destination account is specified. For example, if a default wildcard proxy existed on DEC:.SCH.PRKCHP: UAF> SHOW/PROXY * Default proxies are flagged with (D) DEC:.SCH.LAMCHP::* * (D) The SYSTEM user on node LAMCHP would have default proxy access into the SYSTEM account on PRKCHP. If the network manager then wished to add ALTERNATE as an alternate account to be used from the SYSTEM account on LAMCHP, while still retaining SYSTEM as the default, he would need to explicitly specify that default in the new proxy record like so: UAF> ADD/PROXY DEC:.SCH.LAMCHP::SYSTEM SYSTEM/DEFAULT, ALTERNATE So the proxy database on PRKCHP would now look like this: UAF> SHOW/PROXY * Default proxies are flagged with (D) DEC:.SCH.LAMCHP::* * (D) DEC:.SCH.LAMCHP::SYSTEM SYSTEM (D) ALTERNATE If he instead did this: UAF> ADD/PROXY DEC:.SCH.LAMCHP::SYSTEM ALTERNATE So the proxy database looked like this: UAF> SHOW/PROXY * Default proxies are flagged with (D) DEC:.SCH.LAMCHP::* * (D) DEC:.SCH.LAMCHP::SYSTEM ALTERNATE then DEC:.SCH.LAMCHP::SYSTEM would no longer have default access to PRKCHP's SYSTEM account. That is because only one proxy record is considered for proxy processing; and in this case, the exact match DEC:.SCH.LAMCHP::SYSTEM is preferred over the DEC:.SCH.LAMCHP::* match. This DEC:.SCH.LAMCHP::SYSTEM proxy record does not specify any default account. For further information on how proxies are used to grant access, refer to HELP NETWORK_MANAGEMENT ACCESS_CONTROL OPENVMS_POLICY. 3 OpenVMS_Policy Access can be established using an explicitly specified account, a default proxy account, an application-specific default account, or a nonprivileged default account. The following steps are used to determine if a remote user will be granted access. (Note that access control checking is handled in the same fashion for a local user who specifies the local node or 0 in a command.) 1. If explicit access control information is provided, this information is evaluated first. When an empty access control string is provided, as in: $ DIR PRKCHP"":: $ DIR 0"":: No proxy checking is performed. Instead, access checking is continued at Step 3. When both a username and password are explicitly provided, as in the following examples: $ DIR PRKCHP"PRKCHP_USER PASSWD":: $ DIR 0"PRKCHP_USER PASSWD":: $ MCR NCL SHOW NODE PRKCHP"PRKCHP_USER PASSWD" ALL that account must be accessible using that password (even if a valid proxy exists), in order for access to succeed. If this fails (say, for example, the password is wrong or the account does not exist), then no further checking is performed and access is denied. When only the username is explicitly provided, as in: $ DIR PRKCHP"PRKCHP_USER":: $ DIR 0"PRKCHP_USER":: $ MCR NCL SHOW NODE PRKCHP"PRKCHP_USER" ALL the local proxy database is searched for one proxy record matching source_node::username_on_source. An exactly matching proxy record is preferred over a wildcard match. (Refer to HELP NETWORK_MANAGEMENT ACCESS_CONTROL PROXIES for more information if a wildcard proxy is present.) If a match is not found, then no further checking is performed and access is denied. If a match is found, the selected proxy record is examined to determine if access should be attempted using this explicitly specified local username. It does not matter if this local username is specified in the proxy record as the default account or not. As long as that username is included somewhere in that proxy record, then access will be attempted via that account. For example, if the following command were issued by SYSTEM on LAMCHP: $ DIR PRKCHP"PRKCHP_USER":: And PRKCHP had one of the following proxy records in its database: LAMCHP::SYSTEM PRKCHP_USER LAMCHP::SYSTEM PRKCHP_USER (D) LAMCHP::SYSTEM SYSTEM (D) PRKCHP_USER Then access would be attempted using the explicitly specified PRKCHP_USER account. If this access succeeds, the remote user is mapped into the specified account and granted the rights and default privileges for that account. If there is a problem (say, for example, the directory for that account does not have the correct owner), then no further checking is performed and access is denied. 2. If no access control information was provided at all (not even an empty string), as in: $ DIR PRKCHP:: $ DIR 0:: $ MCR NCL SHOW NODE PRKCHP ALL The proxy database is scanned for a proxy record matching source_node::username_on_source. (A default wildcard proxy may not be sufficient. Refer to HELP NETWORK_MANAGEMENT ACCESS_CONTROL PROXIES for more information.) If no matching proxy record is found, then access control checking proceeds to Step 3. If a matching proxy record is found, but it does not specify a default account, then access will NOT be attempted using that proxy. Instead, access checking proceeds to Step 3. If the matching proxy record specifies a default account, then access is attempted using that account. If this succeeds, the user is granted the rights and default privileges of this default account. If this fails (say, for example, the directory for that account does not have the proper owner), then no further checking is done and access is denied. 3. If an application-specific default is present, as indicated by the session control application user name attribute, then access will be attempted using that account. If this access fails (say, for example, the specified account is non-existent), then no further checking is performed and access is denied. If no default was specified for that particular application, access checking is continued with Step 4. --- NOTE --- The CMIP Management Listener (CML) application uses this method of access to allow remote users to perform NCL SHOW commands. This is why the session control application CML user name is usually set to CML$SERVER, and this account is generally granted the NET$EXAMINE right. Even if a remote user does not include explicit access control information in an NCL command, and even if he does not possess a default proxy account with NET$EXAMINE or BYPASS, his NCL SHOW requests will still be permitted via the CML$SERVER account. 4. If a non privileged default has been established, as indicated by the session control non privileged user attribute, then access will be attempted using that account. If this access fails, or if the session control non privileged user attribute has not been set, then access is denied. 3 Tru64_UNIX_Policy On Tru64 UNIX, access control policy is as follows: o Any user is allowed to use the show command. o To execute any command that modifies network data, the user must have superuser privileges. o When commands default to the local node (either by not specifying a node, or using Node 0), NCL communicates with the CML application by way of pipes, and the priviledges are determined by the user id (UID) that NCL is running under. o When commands are issued to a remote node or to the local node by explicitly including the node name (for example, using node alpha on the system named alpha), then the access granted depends on the access control provided; the session control attributes defined for CML on the target node; and the proxy accounts set up on the target node. o The access control used with a command is determined as follows: -- If any explicit access control is included on the command line, that is what is used. The information can be provided either after the node name (for example, node alpha/smith/abc or through the use of a "by" clause, for example, by user = smith, password = abc). -- If no explicit access control is provided, then NCL checks if any default access has been previously set, and if so, uses that. Default access is set using the set ncl default access by user = USER, password = PASSWORD command. The current state of NCL's default access can be checked with the show ncl default access command. -- If neither of the these cases applies, no access information is used. o When an NCL command arrives at a target node, the access control accompanying the command, along with the session control proxy entries and session control application cml characteristics determine what will be allowed. By default (as DECnet is initially installed), all show commands are allowed, and commands that alter network data are allowed only if the root account and password are explicitly provided. To modify this behavior, refer to the appropriate manual entries on session control. 2 Naming_Service_Management The decnet_register tool is the primary method used by the namespace administrator to manage the node objects contained in both the DECdns distributed name service (DECdns) and the Local namespace. The DECdns control program, dnscp, can also be used to manage the DECdns namespace and its contents. Refer to HELP NETWORK_MANAGEMENT TOOLS DECNET_REGISTER. Or see the DECnet-Plus Network Management book for information about decnet_register and for instructions on registering, deregistering, modifying, and renaming node names. See the DECdns Management guide for information about dnscp and for detailed instructions on managing the namespace and its contents. 2 Remote_Node_Management Phase V remote nodes are managed using NCL, and Phase IV remote nodes are managed using NCP. Refer to the appropriate remote node type below for more information. For information on managing the remote console subsystem (ASCII console) of a network server on a LAN, refer to HELP NETWORK_MANAGEMENT TOOLS CONSOLE_CARRIER. 3 Phase_V_Nodes To issue NCL commands to remote Phase V nodes, simply include the remote nodename or address in the ncl command. Normally, any access beyond an ncl "show" will require that some type of access control information is provided. For information about how access control is handled on a remote node, refer to HELP NETWORK_MANAGEMENT ACCESS_CONTROL. To perform a series of ncl commands on a remote Phase V node, you may find it convenient to set up default entity and access control information within ncl using SET NCL DEFAULT commands. For information on how to modify this default NCL context, refer to HELP NCL DEFAULT_CONTEXT. To specify access control information to be used for a single NCL command on the remote Phase V node, use either the "by" preposition or an access control string. See HELP NCL SPECIFYING_ACCESS_CONTROL for more information. 3 Phase_IV_Nodes DECnet-Plus lets you manage remote systems running Phase IV software from a system running DECnet-Plus network management. To execute an NCP command, follow the specific platform instructions. Because NCL is not backwards compatible with NCP, NCP scripts do not work under the NCL utility. To run NCP scripts, you need to use the convert command in the decnet_migrate utility. For more information on this utility, see the DECnet-Plus Network Management book or HELP NETWORK_MANAGEMENT TOOLS DECNET_MIGRATE. 4 Tru64_UNIX To manage remote Phase IV nodes on Tru64 UNIX, access NCP within the NCL utility, as in: ncl> ncp tell foobar show executor characteristics You must enter the entire NCP command at the ncl> prompt or type ncl ncp at the system prompt. For example: %ncl ncp tell foobar show executor characteristics 4 OpenVMS You can use the NCP Emulator tool to manage remote Phase IV nodes with the TELL and SET EXECUTOR NODE commands. The TELL command allows you to perform a single NCP command on the remote node, and you may choose to supply access control information within the command. For example, to zero the executor counters on a remote Phase IV node from a local Phase V node, enter the following: $ run sys$system:ncp NCP> tell remnod"account password" zero exec counters The NCP Emulator tool is not intended for management of Phase V nodes, so all NCP commands are not supported. The following error is returned if an unsupported NCP Emulator command is attempted on a Phase V system without specifying a remote Phase IV system: NCP> zero exec counters %NCP-W-SYSMGT, System-specific management function not supported When you wish to perform a series of commands on a single remote Phase IV node, you can set your default NCP context to that node using the NCP SET EXECUTOR NODE command; again you may choose to supply default access control information within that command. For example, after the following command is issued, all subsequent commands within that NCP session will be performed on node FAZ4ND using the specified access control information: $ mcr ncp NCP> set executor node faz4nd"account password" See HELP NETWORK_MANAGEMENT TOOLS NCP_EMULATOR for more information on the use of the NCP Emulator. 2 Logical_Names_(OpenVMS) System logical names can be defined in SYS$MANAGER: NET$LOGICALS.COM which allow you to modify certain network defaults. If you don't have a net$logicals procedure on your node, you can create one by copying the SYS$MANAGER: NET$LOGICALS.TEMPLATE file. Here are some of those logicals: NET$entity_name_STARTUP Specifies a logical name that points to an alternate file location for that entity's startup script. NET$IGNORE_DECNET If set to true, the network is not started. If not defined or set to false, the network starts normally. NET$IGNORE_EVD If set to true, the event dispatcher is not started. Use of this logical is unsupported. NET$STARTUP_MOP If set to true, MOP starts. If not defined or set to false, MOP is not started. Note that in order for MOP to start correctly, the MOP startup scripts must exist on the system, so MOP must have been configured using net$configure. Simply defining this logical is not enough to create the MOP entity. NET$STARTUP_QUIET_NCL If defined to false, NCL output is maximized during network startup. NET$NOISY_SHUTDOWN If defined to true, NCL output is displayed during shutdown. NCL$ENVIRONMENT Defining to "NoBackTrans" prevents NCL from translating addresses to fullnames. NET$APPLICATION_SHUTDOWN Defined to point to a site-specific procedure which will shutdown network applications before DECnet is shutdown. NET$LOCAL_NAME_DATABASE Defined to point to a LOCAL database file if that file is located somewhere other than SYS$SYSTEM. NET$LOCAL_CLOSE If defined to 1, the NET$LOCAL_NAME_DATABASE file will be closed after each reference. In addition, logicals can be defined in NET$LOGICALS.COM to modify default quotas for the NET$ACP, NET$EVD or NET$MOP processes or to assign the output for those processes to certain files. Care must be taken in modifying these defaults. Please refer to the .TEMPLATE file for more information. 2 Startup_Scripts_(OpenVMS) During configuration, net$configure creates ASCII files of NCL commands, called NCL scripts, for each configurable entity. Here are some startup scripts created by net$configure: NET$ALIAS_STARTUP.NCL NET$APPLICATION_STARTUP.NCL NET$CSMACD_STARTUP.NCL NET$DDCMP_STARTUP.NCL NET$DNS_CLERK_STARTUP.NCL NET$DTSS_CLERK_STARTUP.NCL NET$EVENT_STARTUP.NCL NET$FDDI_STARTUP.NCL NET$HDLC_STARTUP.NCL NET$MODEM_STARTUP.NCL NET$MOP_CIRCUIT_STARTUP.NCL NET$MOP_CLIENT_STARTUP.NCL NET$NODE_STARTUP.NCL NET$NSP_TRANSPORT_STARTUP.NCL NET$OSI_TRANSPORT_STARTUP.NCL NET$SEARCHPATH_STARTUP.NCL NET$SESSION_STARTUP.NCL As you can see, the script files are generally named as follows, where "entity_name" is almost always a module or entity: SYS$MANAGER:NET$entity_name_STARTUP.NCL If you need to customize the startup of network components further than net$configure allows, you must edit the appropriate script with a text editor and then execute it to save the changes until the next time you run net$configure. For example, say you wished to modify all the Event Dispatcher Sinks so that UIDs were no longer displayed in events. This is not something you can easily configure the Event Dispatcher to do using net$configure. (Refer to the DECnet-Plus Applications Installation and Advanced Configurations manual for more information regarding the script changes that net$configure can make.) In order to make this change, you could add the ncl command "set event dispatcher sink * displayuids false" to the end of the SYS$MANAGER:NET$EVENT_STARTUP.NCL script, then re-execute that script, as in: NCL> @SYS$MANAGER:NET$EVENT_STARTUP.NCL This would make the change you requested. However, the next time you run net$configure, depending upon what answers you provide, your customized NET$EVENT_STARTUP.NCL script could be replaced with a new script, essentially removing your changes. Before this could happen, however, net$configure would display a list of NCL scripts that had been manually modified and warn you that those customized scripts might be renamed to .NCL-OLD. If you then selected to have net$configure create a new NET$EVENT_STARTUP.NCL, you'd need to manually merge the customizations from the .NCL-OLD file into the new .NCL file. Maintaining customized scripts in this way could become cumbersome, so DECnet provides a method for retaining changes to certain scripts which users frequently customize. DECnet allows you to permanently save any edits made to the following scripts by renaming those customized script files to local scripts: NET$EVENT_STARTUP.NCL -> NET$EVENT_LOCAL.NCL NET$MOP_CLIENT_STARTUP.NCL -> NET$MOP_CLIENT_LOCAL.NCL NET$APPLICATION_STARTUP.NCL -> NET$APPLICATION_LOCAL.NCL NET$SEARCHPATH_STARTUP.NCL -> NET$SEARCHPATH_LOCAL.NCL At startup, if a NET$SEARCHPATH_LOCAL.NCL script is found, it is executed in lieu of the NET$SEARCHPATH_STARTUP.NCL script. If any local script exists for the EVENT, MOP_CLIENT, or APPLICATION entities, then that local script is executed immediately after the standard version of that script. The advantage to using these local scripts is that they will remain unchanged when net$configure is run, even if you do choose to have net$configure modify the standard versions of those scripts. 2 Shutdown_and_Restart_(OpenVMS) Any network-dependant applications should be shutdown before the network itself is shutdown. For a complete system shutdown, the OpenVMS shutdown procedure SYS$SYSTEM:SHUTDOWN.COM calls SYS$MANAGER:NET$SHUTDOWN.COM before it calls the site-specific SYS$MANAGER:SYSHUTDWN.COM procedure. Therefore, it is not sufficient to shutdown site-specific network applications within the SYSHUTDWN procedure. Instead, the SYS$MANAGER:NET$APPLICATION_SHUTDOWN.TEMPLATE is provided for this purpose. This file should be renamed to .COM and edited to include the site-specific shutdown procedures of your network applications. You also need to define the NET$APPLICATION_SHUTDOWN logical in SYS$MANAGER:NET$LOGICALS.COM to point to this site-specific procedure. If the NET$APPLICATION_SHUTDOWN logical is defined, NET$SHUTDOWN will call your site-specific procedure to shut down the network applications before DECnet itself is shut down. To shut down DECnet-Plus, enter: $ @sys$startup:net$shutdown To restart DECnet, enter: $ @sys$startup:net$startup 2 MOP_(OpenVMS) With the MOP (Maintenance Operations Protocol) module, you can: - Downline load and upline dump - Use the console carrier on a network server - Use the configuration monitor - Run lookback tests To set up a basic MOP configuration, invoke the configuration procedure: $ @sys$manager:net$configure Then select Option 1 "Perform an entire configuration", and answer YES to the Load MOP question to create new MOP client and circuit scripts. Then select Option 8 "Configure MOP Client database" as many times as necessary to ADD or DELETE MOP Clients. Once MOP has been correctly configured, net$configure will have created net$mop_client_startup.ncl and net$mop_circuit_startup.ncl scripts. The client script must contain, in addition to any default client information, CREATE MOP and ENABLE MOP commands. You may then add or delete MOP Clients at any time by invoking net$configure and selecting Option 8 "Configure MOP Client database" option. Anytime after MOP has been configured, you may control whether or not MOP starts automatically at boot time by defining (or not defining) the following system logical: $ define/system/nolog net$startup_mop true You will find this and other logicals (including some which affect MOP performance) in the net$logicals.com procedure. (Refer to HELP NETWORK_MANAGEMENT LOGICAL_NAMES for additional information on the net$logicals.com procedure.) Anytime after MOP has been configured, if no NET$MOP process is present, you may re-start it manually by: $ @sys$system:startup network mop For additional information on the configuration and use of MOP, refer to the DECnet-Plus Network Management book. 2 Event_Dispatcher_(OpenVMS) By default, the NET$EVD process is started, and the event dispatcher is created and enabled. Thus, you need not start EVD yourself. However, if you do need to re-start a new NET$EVD process, you can do so by: $ @sys$system:startup network evd You may modify the NET$EVENT_STARTUP.NCL script by invoking net$configure, and selecting Option 6 "Configure Event Dispatcher". Choose the ADVANCED option of net$configure if you wish to customize the Event Dispatcher. If you wish to tailor your Event Dispatcher further (say, to block certain events perhaps), you may create a NET$EVENT_LOCAL.NCL script, which, if present, will be automatically executed immediately following the NET$EVENT_STARTUP.NCL script during startup. If you do not have a SYS$MANAGER:NET$EVENT_LOCAL.NCL script on your system, you may create one by copying and editing the SYS$MANAGER:NET$EVENT_LOCAL.TEMPLATE file. Refer to HELP NETWORK_MANAGEMENT STARTUP_SCRIPTS for more information concerning the NET$EVENT_LOCAL.NCL script. 2 Running_Over_TCP-IP HP DECnet-Plus for OpenVMS allows you to run DNA and OSI applications over an IP network backbone. Applications include those supplied by HP, third-party applications, and user-written applications. RFC 1006 and RFC 1859 (formerly known as RFC 1006 Extension) are standards of the Internet community. RFC 1006 defines how to implement ISO 8073 Class 0 on top of TCP. Hosts that implement RFC 1006 are expected to listen on TCP port 102. RFC 1859 defines how to implement ISO 8073 Transport Class 2 Non-use of Explicit Flow Control on top of TCP. Hosts that implement RFC 1859 are expected to listen on TCP port 399. The DECnet over TCP/IP feature (RFC 1859) allows traditional DECnet applications (such as MAIL, CTERM, and FAL) to accept IP names and addresses. The OSI applications over TCP/IP feature (RFC 1006) allows OSI applications (such as FTAM and VT) to accept IP names and addresses. 3 Configuring Methods of configuring OSI over TCP/IP and DECnet over TCP/IP depend upon the operating system in use. 4 Tru64_UNIX Running OSI applications over TCP/IP (RFC1006) is automatically enabled when you install and configure DECnet. To enable DECnet over TCP/IP (RFC1859), you can either run "decnetsetup advanced" and answer "yes" to the question "Do you want to configure DECnet over TCP/IP?" or you can run dxdecnetsetup, select the advanced format, and select the "Configure DECnet over TCP/IP" option. 4 OpenVMS If you want to use OSI applications over TCP/IP and/or DECnet over TCP/IP, invoke NET$CONFIGURE with the ADVANCED option, and select Option 4 ("Configure Transports") to configure (or reconfigure) the OSI transport. You can then create a new OSI transport NCL script (or replace the old script). You must also include Domain in your Session Control naming search path by selecting Option 2 to rename your node. This is described in Section 2 of the Applications Installation and Advanced Configuration Manual. For the changes to take effect, either disable the OSI transport entity (if it exists) and invoke the new OSI transport NCL script, or reboot the system. NCL> disable osi transport NCL> do sys$manager:net$osi_transport_startup.ncl Also, ensure that TCP/IP is started on the node and that the PWIP driver is loaded. When configuring RFC 1006, RFC 1859, or both, each element in the OSI transport entity's set of RFC 1006 listener ports attribute corresponds to a TCP listener port. By default, NET$CONFIGURE sets the OSI transport RFC 1006 listener ports attribute to { 102, 399 }. Port 102 is required for RFC 1006, and port 399 is required for RFC 1859. 3 Additional_Template_Creation_(OpenVMS) To create RFC 1006 or RFC 1859 templates in addition to the default templates, use Option 4 under the NET$CONFIGURE ADVANCED option. When the procedure asks if you want to create additional OSI templates, answer yes. Then select RFC 1006 as the network service. The RFC 1006 port number attribute of the OSI transport template subentity must contain a TCP port number that is one of the chosen RFC 1006 or RFC 1859 listener ports. The default value for the RFC 1006 port number attribute is 102. If you create an OSI transport template subentity to use with DECnet over TCP/IP (RFC 1859), then set the RFC 1006 port number attribute of that template to 399. 3 Disabling_(OpenVMS) DECnet-Plus only attempts to locate TCP/IP if the RFC 1006 listener ports attribute set of the OSI Transport entity is not empty. To disable OSI over TCP/IP (RFC 1006) and/or DECnet over TCP/IP (RFC 1859), you can discontinue listening on the appropriate port(s). Port 102 applies to RFC 1006, and Port 399 applies to RFC 1859. For example, this will disable both RFC 1006 and RFC 1859: NCL> disable osi transport NCL> remove osi transport rfc1006 listener ports {102,399} NCL> enable osi transport 2 Tools 3 Console_Carrier The console carrier provides access to the remote console subsystem (ASCII console) of a network server on a LAN. The console carrier interface does not use NCL. Instead, you can enter commands at the operating system to use the console carrier. 4 OpenVMS The Phase IV NCP CONNECT NODE and NCP CONNECT VIA commands have no Phase V equivalent. Instead, use SET HOST to use the console carrier function of MOP on Phase V: $ SET HOST/MOP Either the NET$MANAGE or the NET$DIAGNOSE rights identifiers or BYPASS privilege is required to use the Console Carrier on OpenVMS. For further information about the console carrier on OpenVMS systems, refer to the DECnet-Plus Network Management book, Appendix I. 4 Tru64_UNIX For further information about the console carrier on Tru64 UNIX systems, see the ccr command in the DECnet-Plus for Network Management book, Appendix K. 3 GUI_(Graphical_User_Interface) NCL can be accessed through either a command line interface or a Graphical User Interface (GUI). The GUI allows network managers to view the status of network components and control those components from a Motif-based window interface. This utility provides a hierarchical graphical approach to the management of DECnet-Plus. The manageable components of DECnet-Plus (modules, entities and subentities) are represented in a tree-like structure below the icon that represents the node you are managing. This provides an easy way to familiarize yourself with the organization of these manageable entities (the entity hierarchy). Another way to view the entity hierarchy is to use this help facility -- see HELP ENTITY_HIERACHY. For further information regarding the network management GUI, refer to the DECnet-Plus Network Management book. 4 Invoking On Tru64 UNIX, the GUI is located at dna_mgmt. On OpenVMS, you can invoke the NCL GUI by: $ run sys$system:net$mgmt The same OpenVMS rights required to run NCL on are also required to run this utility. Refer to HELP NETWORK_MANAGEMENT ACCESS_CONTROL RIGHTS_IDENTIFIERS for more information about rights identifiers. 4 Displaying_NCL_Commands You may choose to enable the displaying of NCL commands in order to see what NCL commands are being issued on your behalf by the GUI. Do so by pulling down the Options menu, selecting the Default Actions menu item, and enabling Display NCL Commands in the dialog box. The NCL commands will appear in the window from which you started the GUI. Viewing these commands will help familiarize you with NCL syntax. 4 Tasks The NCL GUI can also perform task-oriented functions which involve many NCL commands or are complex in some way. The currently supported NCL GUI tasks are: o show known links o show known node counters o check transports You can invoke these tasks by pulling down the Tasks menu and selecting the appropriate task. 3 Decnet_Migrate Using the decnet_migrate utility, you can: - Convert NCP commands to NCL commands (where equivalents exist) - Collect information about your network configuration - Set up routing between Phase IV and Phase V areas. For further information on the use of the decnet_migrate, you may either Invoke the utility and access help, as in: $ run sys$update:decnet_migrate DECNET_MIGRATE> help Or refer to the DECnet-Plus Network Management book. 3 Decnet_Register With decnet_register, you can manage the node names and addressing information in both the Local namespace and the DECdns namespace, using either the command-line or forms-driven version of the tool. On OpenVMS, invoke decnet_register as follows. By default, decnet_register starts in forms mode from a video terminal and in command mode from a hardcopy terminal. $ run sys$system:decnet_register You can define the following logical before invoking decnet_register if you want to force command mode: $ define decnet_register_commands 1 Some examples using the command line interface are provided here. To obtain further help regarding the decnet_register utility, either invoke the utility and enter "?" at the Option prompt, or refer to the DECnet-Plus Network Management book. 4 Examples The following example demonstrates how to modify a pre-existing LOCAL registration using decnet_register's command line interface: $ define decnet_register_commands 1 $ run sys$system:decnet_register modify node LOCAL:.logic directory_service LOCAL - towers {SC3/NSP/24.6,SC3/TP4/24.6} show node LOCAL:.logic directory_service LOCAL full exit The following example shows how to register a Phase V node in the LOCAL namespace, explicitly specifying session control Version 3 for NSP. If the session version is not specified, NSP towers will still default to SC2, and OSI towers will default to SC3: $ define decnet_register_commands 1 $ run sys$system:decnet_register register node LOCAL:.newno1 directory_service LOCAL - towers {SC3/NSP/24.224,TP4/24.224} synonym newno1 show node LOCAL:.newno1 directory_service LOCAL full exit This example shows how to use decnet_register from an OpenVMS node to register a Phase V node in the WINTER namespace. The node being registered is an OpenVMS node that is configured to run NSP, OSI Transport Class 4, and OSI Transport Class 2 for DECnet over IP: $ define decnet_register_commands 1 $ run sys$system:decnet_register register node WINTER:.xpr.newno1 directory_service DECdns - towers {SC3/NSP/24.224,TP4/24.224,TP2/IP=161.114.94.128} - synonym newno1 show node Winter:.xpr.newno1 directory_service DECdns full exit Note that only decnet_register on OpenVMS accepts IP tower registrations, and those registrations must be made in the DECdns directory service. IP towers cannot be registered in the LOCAL namespace. Furthermore, decnet_register does not handle Domain (Bind) registrations. 3 Configuration_Monitor The LAN configuration monitor listens for system id messages on the LAN and records the results. HP-supplied LAN stations transmit a system id message every 10 minutes on average. Therefore, by listening to these messages the configuration monitor builds a database containing details about most systems that are operational. To use the Configuration Monitor, MOP must be started on the system, refer to HELP MOP for information on how to configure and start MOP. If a mop circuit has already been created, you may start the configuration monitor by enabling that function on that MOP circuit, as in: ncl> enable mop circuit csmacd-1 function {configuration monitor} The configuration monitor then stores the data it collects as a set of station subentities, one for each address from which a system id is received. The name of a station entity is constructed from a LAN address. Use the show command to view the contents of this database, as in: ncl> show mop circuit csmacd-1 station * all To discontinue operation of the configuration monitor and delete the contents of the database, you may disable that function, as in: ncl> disable mop circuit csmacd-1 function {configuration monitor} 3 NCP_Emulator_(OpenVMS) Using the NCP Emulator, you can manage remote Phase IV nodes with the "tell" and "set executor node" commands. Before you invoke the NCP Emulator, make sure the NET$MOP process is running. To invoke the NCP Emulator, enter: $ run sys$system:ncp The following example modifies the cost on circuit sva-0 on boston, a remote Phase IV node: NCP> tell boston"bostonaccount bostonpwd" - _NCP> set circuit sva-0 cost 4 The NCP Emulator was designed to facilitate software installations on DECnet Phase V systems; it was not intended as a replacement for NCL. For more information on the NCP Emulator and the limited set of NCP commands it supports, refer to the Network Management manual. 3 DNS$Control With dns$control you can manage the components of DECdns and the contents of the DECdns namespace. To invoke dns$control on OpenVMS, enter: $ run sys$system:dns$control For more information about dns$control, you may either invoke the utility and enter "help" at the DNS> prompt, or refer to the DECnet-Plus DECdns Management manual. 3 NET$Configure_(OpenVMS) This procedure is used to configure your DECnet-Plus system. The net$configure options are: FAST, BASIC, or ADVANCED. For help in determining which option to use and how to invoke that option, refer to the option descriptions below. 4 FAST This option will be invoked the first time you configure a Phase V node by: $ @sys$manager:net$configure Choose to continue with this FAST default configuration if: - You are upgrading from a DECnet Phase IV node and you plan to use the existing Phase IV configuration. - The node is not in a cluster. - You are not running and do not plan to run this as a DNS Server. After the FAST configuration has been run once on your system, the configuration option defaults to BASIC. For more information about the FAST configuration option, refer to the Installation and Basic Configuration manual. 4 BASIC Choose this option if... - The node is in a cluster. - You are upgrading or reconfiguring DECnet-Plus. - You need to access a DECdns server for network addresses. - You want to run DECnet over TCP/IP (RFC 1859) and/or OSI applications over TCP/IP (RFC 1006). - You only have one communications device, or you have multiple devices, all of which will be used for DECnet-Plus communications. - You want to use the default names for all devices and routing circuits (for example, default csmacd-0, rather than sva-0). - You want to autoconfigure your network addresses only. - You want to configure both the NSP and OSI transports and only want to create default OSI templates. You want to enable both DECnet over TCP/IP or OSI applications over TCP/IP. - You do not want to enable FDDI large packet support (if you have an FDDI-type circuit). - You want to set the routing characteristic DNS Address Format to TRUE (this attribute controls the interpretation of address structuring). - You want to use integrated mode routing. To invoke net$configure using the BASIC option, enter: $ @sys$manager:net$configure For more information about the BASIC configuration, refer to the Installation and Basic Configuration manual. 4 ADVANCED Choose the ADVANCED option if... - Your configuration is complex. - You need to customize your network's configuration. - Your system has multiple communication devices, and you want them to run a mix of protocols. - You want to configure a cluster with both DECnet Phase IV and DECnet Phase V nodes. - You want the option to give specific names to all devices and routing circuits. You also want the option of not configuring all your devices for DECnet-Plus. - You want the option of manually entering your network addresses. - You want to configure either the NSP transport or the OSI transport (or both). You want the option to create additional OSI templates. You want the option of enabling/disabling DECnet over TCP/IP or OSI applications over TCP/IP. - You want the option of enabling FDDI large packet support (if you have an FDDI-type circuit). - You want the option of setting the routing characteristic DNA Address Format to TRUE or FALSE (to control the interpretation of address structuring). - You want the option of using either intregated mode routing or segregated mode routing. - You want the option to provide default accounts for FAL. To invoke net$configure using the ADVANCED option, enter: $ @sys$manager:net$configure advanced For more information about the ADVANCED configuration, refer to the Applications Installation and Advanced Configuration manual.