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.
1 – 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.
1.1 – 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.
1.2 – 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.
1.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.
1.4 – 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.
3 – 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.1 – 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.2 – 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.
3.2.1 – 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
3.2.2 – 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.
4 – 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.
5 – 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.
6 – 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
7 – 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.
8 – 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.
9 – 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.
9.1 – Configuring
Methods of configuring OSI over TCP/IP and DECnet over TCP/IP
depend upon the operating system in use.
9.1.1 – 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.
9.1.2 – 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.
9.2 – 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.
9.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
10 – Tools
10.1 – 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.
10.1.1 – 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.
10.1.2 – 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.
10.2 – 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.
10.2.1 – 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.
10.2.2 – 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.
10.2.3 – 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.
10.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.
10.4 – 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.
10.4.1 – 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.
10.5 – 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}
10.6 – 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.
10.7 – 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.
10.8 – 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.
10.8.1 – 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.
10.8.2 – 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.
10.8.3 – 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.