DECnet-Plus for OpenVMS
Network Management

Refer to Chapter 8 for a more detailed description of how DECnet Phase V routing uses X.25.

H.2.11.1 DLM Outgoing Circuit

Phase IV DLM circuits of type OUTGOING are replaced by routing circuits of type x25 static outgoing in DECnet Phase V. The circuit's data link entity characteristic is set to X25 access. There is an additional parameter, initial minimum timer, that clears the circuit if no adjacency has been established when this timer expires.

Parameters for the outgoing call are defined by an associated X25 Access template which is specified by the routing circuit template attribute.

Table H-11 shows the parameter mapping rules.

Table H-11 DLM Outgoing Circuit DLM Database

Phase IV Name	Phase V Entity	Attribute	Type
CIRCUIT	routing circuit	Identifier	Simple name
COST +	N/A ³
COUNTER TIMER +	N/A
DTE +	N/A
HELLO TIMER +	N/A ³
MAXIMUM DATA +	x25 access template 5	packet size	Unsigned
MAXIMUM RECALLS +	routing circuit	maximum call attempts	Unsigned
MAXIMUM WINDOW +	x25 access template 5	window size	Unsigned
NETWORK	x25 access template 5	dte class	Simple name
NUMBER	x25 access template 5	destination dte address	DTE address
OWNER	N/A
RECALL TIMER +	routing circuit	recall timer	Unsigned
STATE +	routing circuit	N/A ¹
TYPE	N/A
USAGE	routing circuit	type ²	x25 static outgoing
VERIFICATION +	routing circuit	receive verifier 4	Hex string
	routing circuit	transmit verifier 4	Hex string

For example:

NCP> set circuit x25-out usage outgoing network mynet number 12345678920 -  
_ maximum data 256 maximum window 7 maximum recalls 10 recall timer 60 -  
_ state on  

ncl> create x25 access template rou_temp  
ncl> set x25 access template rou_temp dte class mynet,destination dte -  
_ncl> address 12345678920  
ncl> set x25 access template rou_temp packet size 512,window size 7  
ncl> create routing circuit x25-out type x25 static outgoing  
ncl> set routing circuit x25-out maximum call attempts 10, recall timer 60  
ncl> set routing circuit x25-out template rou_temp  
ncl> enable routing circuit x25-out  

Phase IV DLM circuits of type INCOMING are replaced by routing circuits of type x25 static incoming in DECnet Phase V. The circuit's data link entity characteristic is set to X25 access. There is an additional parameter, initial minimum timer, that clears the circuit if no adjacency has been established when this timer expires.

Parameters for call negotiation can be defined by an associated X25 Access template which is specified by the routing circuit template attribute.

Parameters for incoming call capture are defined by one or more X25 Access filters which are determined by the routing circuit x25 filters attribute.

When setting up an X25 Access filter for use with this type of circuit, specify the following filter characteristics for calls originating from DECnet Phase V systems:

• call data mask%xff
• call data value%x81

For calls originating from a Phase IV DLM system, use the subaddress range filter characteristic to select calls on the basis of the DTE subaddress or the call data value filter characteristic to select calls on the basis of the call data string DECNET_DLM.

Table H-12 shows the parameter mapping rules.

Table H-12 DLM Incoming Circuit Database

Phase IV Name	Phase V Entity	Attribute	Type
CIRCUIT	routing circuit	Identifier	Simple name
COST +	routing circuit	N/A ³
COUNTER TIMER +	N/A
DTE +	x25 access filter	N/A
HELLO TIMER +	routing circuit	N/A ³
MAXIMUM DATA +	x25 access template	packet size	Unsigned
MAXIMUM WINDOW +	x25 access template	window size	Unsigned
NETWORK +	x25 access filter	inbound dte class	Simple name
NUMBER +	x25 access filter	sending dte address	DTE address
OWNER	N/A
STATE +	N/A ¹
TYPE	N/A
USAGE	routing circuit	type	x25 static incoming
VERIFICATION +	routing circuit	receive verifier 4	Hex string
	routing circuit	transmit verifier 4	Hex string

For example:

NCP> set executor subaddresses 20-30  
NCP> set circuit x25-inc usage incoming network mynet -  
_ maximum data 256 maximum window 7  
NCP> set circuit x25-inc sta on  

ncl> create x25 access filter rou_filt  
ncl> set x25 access filter rou_filt subaddress range {[20..30]}, inbound dte -  
_ncl> class mynet  
ncl> create routing circuit x25-inc type x25 static incoming  
ncl> set routing circuit x25-inc x25 filters {rou_filt},template rou_temp  
ncl> enable routing circuit x25-inc  

Phase IV DLM circuits of type PERMANENT are replaced by routing circuits of type x25 permanent in DECnet Phase V. The circuit's data link entity characteristic is set to X25 access.

The circuit's template characteristic is set to the name of the X25 Protocol DTE PVC that will be used by this routing circuit.

Table H-13 shows the parameter mapping rules.

Table H-13 DLM PVC Database

Phase IV Name	Phase V Entity	Attribute	Type
CIRCUIT	routing circuit	Identifier	Simple name
CHANNEL +	routing circuit	template	Simple name 1,2
	x25 protocol dte pvc x ²	channel	Unsigned
COST +	N/A 5
COUNTER TIMER +	N/A
DTE	x25 protocol dte	Identifier ²	Simple name
HELLO TIMER +	N/A 5
MAXIMUM DATA +	x25 protocol dte pvc x	packet size	Unsigned
MAXIMUM WINDOW +	x25 protocol dte pvc x	window size	Unsigned
NETWORK	N/A
OWNER	N/A ³
STATE +	routing circuit	N/A 4
TYPE	N/A
USAGE	routing circuit	type	x25 permanent
VERIFICATION +	routing circuit	receive verifier 6	Hex string
	routing circuit	transmit verifier 6	Hex string

For example:

NCP> set circuit x25-perm usage permanent network mynet -   
_ dte 123456789 channel 9  
NCP> set circuit x25-perm maximum data 256 maximum window 7  
NCP> set circuit x25-perm state on owner executor  

ncl> create x25 protocol dte dsv-0 pvc x25-perm channel 9,packet size 256, -  
_ncl> window size 7  
ncl> create routing circuit x25-perm type x25 permanent  
ncl> set    routing circuit x25-perm template x25-perm  
ncl> enable routing circuit x25-perm  

Phase IV user PVCs are equivalent to a pvc subordinate entity belonging to an x25 protocol dte entity. Table H-14 shows the parameter mapping rules.

Table H-14 Application PVC Database

Phase IV Name	Phase V Entity	Attribute	Type
CIRCUIT	x25 protocol dte pvc x ¹	Identifier	Simple name
CHANNEL +	x25 protocol dte pvc x ¹	channel ³	Unsigned
COUNTER TIMER +	N/A
DTE	x25 protocol dte	Identifier ¹	Simple name
MAXIMUM DATA +	x25 protocol dte pvc x ¹	packet size ³	Unsigned
MAXIMUM WINDOW +	x25 protocol dte pvc x ¹	window size ³	Unsigned
NETWORK	x25 protocol dte	Identifier	Simple name
OWNER	N/A ²
STATE +	x25 protocol dte pvc x ¹	N/A
TYPE	N/A
USAGE	N/A

For example:

NCP> set circuit x25-perm usage permanent network mynet -   
_ dte 123456789 channel 9  
NCP> set circuit x25-perm maximum data 256 maximum window 7  
NCP> set circuit x25-perm state on  

ncl> create x25 protocol dte dsv-0 pvc x25-perm channel 9,packet size 256, -  
_ncl> window size 7  

The basic mechanism for security is the same in both DECnet Phase IV and Phase V.

• Each incoming call acquires a set of rights identifiers based on the address of the remote DTE from which the call was received.
• Each user (or user process) has a set of rights identifiers acquired from the OpenVMS rights database.
• Each outgoing call to a multihost system acquires a set of rights identifiers based on the identity of the Access system's node.

Rights identifiers are then used to determine the level of access allowed to a particular VAX P.S.I. object (for example, a remote DTE). The access level is defined by access control lists (ACLs).

In DECnet Phase V, an ACL is always defined as an attribute of some network management entity. The syntax of an ACL is defined as a set of access control entries (ACEs). An ACE has the following format:

{Identifiers = {simplename1,simplename2,...},Access = access level}

where the simplename1,... strings are valid OpenVMS system rights identifiers.

H.3.1 VAX P.S.I. Security Specific Identifiers

In Phase IV, VAX P.S.I. security defines the following rights identifiers:

• PSI$X25_USER--- The rights identifier that must be granted to any user or process that is allowed to issue an IO$_ACCESS QIO
• PSI$DECLNAME--- The rights identifier that must be granted to any process that is allowed to declare itself as a network process by issuing an IO$_ACPCONTROLQIO

System managers can add other identifiers by the normal means.

DECnet Phase V X.25 security still uses the PSI$X25_USERand PSI$DECLNAMErights identifiers. Other identifiers are defined automatically by the configuration procedures. System managers can add other identifiers by the normal means.

H.3.2 VAX P.S.I. Security Access Actions

In Phase IV, VAX P.S.I. allows the following access actions:

• NONE --- No access to VAX P.S.I.
• INCOMING --- Allow incoming, non-reverse charge calls
• INCOMING+REVERSE_CHARGE --- Allow all incoming calls, including reverse charge calls
• OUTGOING --- Allow outgoing reverse charge calls
• OUTGOING+CHARGE --- Allow all outgoing calls, including reverse charge calls

DECnet Phase V uses the following access levels:

• NONE --- No access permitted.
• REMOTE CHARGE --- For outgoing calls, permit only those that use the reverse charge facility. For incoming calls, permit only those that do not use the reverse charge facility.
• ALL --- Permit all calls, whether or not they use the reverse charge facility. Since separate ACLs are used for incoming or outgoing calls, it is possible to specify different controls for each direction.

This section discusses database mapping.

H.3.3.1 The Remote DTE Rights Database

The Phase IV remote DTE rights database contains the rights identifiers associated with remote DTEs that want to make incoming calls to your system.

In DECnet Phase V, this information is distributed among the set of x25 access security dte class remote dte entities. Each x25 access security dte class remote dte entity has a rights identifiers attribute that is the set of rights identifiers possessed by a remote DTE. These identifiers are used by X.25 security when checking the ACL against an incoming call from the remote DTE.

For example:

ncl> create x25 access security dte class default remote dte MATCHALL -  
_ncl> remote address prefix *  
ncl> set x25 access security dte class default remote dte MATCHALL -  
_ncl> rights identifiers (PSI$OPEN_SECURITY)  

Note

The following security information is relevant only to multihost functionality.

The Phase IV access node rights database contains the rights identifiers associated with Access nodes that are allowed to make outgoing calls through a multihost node.

In DECnet Phase V, this information is distributed among the set of x25 server security nodes entities at the multihost node. Each x25 server security nodes entity has a rights identifiers attribute that is the set of rights identifiers possessed by one or more Access system nodes, as defined by the nodes attribute. These identifiers are used by X.25 security when checking the ACL against an outgoing call from the Access node.

For example:

ncl> create x25 server security nodes clients  
ncl> set x25 server security nodes clients nodes { ORG:.mynode }  
ncl> set x25 server security nodes clients rights identifiers -  
_ncl> { PSI$OPEN_SECURITY }  

DECnet Phase V does not have an entity corresponding to the local DTE access control database used in Phase IV.

H.3.3.4 The Remote DTE Access Control Database

The Phase IV Remote DTE Access Control Database contains the ACLs that control the access actions associated with outgoing calls to remote DTEs.

In DECnet Phase V, this information is distributed among the set of x25 access security dte class remote dte entities. Each x25 access security dte class remote dte entity has an acl attribute that is the set of ACEs used by X.25 security when checking outgoing calls to the remote DTE.

For example:

ncl> create x25 access security dte class default remote dte MATCHALL -  
_ncl> remote address prefix *  
ncl> set x25 access security dte class default remote dte MATCHALL -  
_ncl> acl ((identifier = ( * ), access = ALL))  

The Phase IV Destination Access Control Database contains the ACLs that control the access actions associated with incoming calls to an X.25 destination.

In DECnet Phase V, this information is distributed among the set of x25 access security filter entities. Each x25 access security filter entity has an acl attribute that is the set of ACEs used by X.25 security when checking incoming calls for any filter that is using this X.25 access security filter.

For example:

ncl> create x25 access security filter DEFAULT  
ncl> set x25 access security filter DEFAULT acl ((identifier =( * ), -  
_ncl> access = ALL))  

X.25 security for DECnet Phase V allows protection for the x25 protocol dte pvc and x25 protocol group entities.

Each x25 protocol dte pvc has an acl attribute that is the set of ACEs used by X.25 security when checking access to this PVC.

For example:

ncl> set x25 protocol dte dsv-0 pvc x25-perm acl { -  
_ncl> (identifier =( * ), access = ALL) -  
_ncl> }  

Each bilateral closed user group (BCUG) has a remote dte attribute. This DTE address is associated with this entity for matching x25 access security dte class remote dte entities for both incoming and outgoing calls.

For example:

ncl> set x25 protocol group secret remote dte address 123456788  

A graphical user interface is available for network management on OpenVMS systems. This interface is a Motif application that is located at SYS$SYSTEM:NET$MGMT.EXE.

I.1 Network Management Graphical User Interface (NET$MGMT)

The NET$MGMT utility provides a hierarchical graphical approach to the management of DECnet Phase V. The manageable components of DECnet Phase V (modules, entities and subentities) are represented in a tree-like structure below the icon that represents the node you are managing. The NET$MGMT utility provides an easy way to familiarize yourself with the organization of these manageable entities. If you choose to enable the displaying of NCL commands from the Default Actions pulldown, NET$MGMT can also help familiarize you with NCL syntax.

In addition to issuing NCL commands on your behalf, NET$MGMT can also perform task-oriented functions which involve many NCL commands or are complex in some way. The currently supported NET$MGMT tasks are:

• SHOW KNOWN LINKS
• SHOW KNOWN NODE COUNTERS
• CHECK TRANSPORTS

NET$MGMT also checks to ensure that the system display has the proper fonts available. The required font is -*-helvetica-Bold-R-Normal--12-120-75-75-P-70-ISO8859-1. If this font is not available, a message is displayed and NET$MGMT exits.

I.2 Rights Required to Run NET$MGMT

The same rights required to run NCL are also required to run NET$MGMT. The process invoking NET$MGMT must have at least one of the following rights enabled, or the process must possess BYPASS privilege:

• NET$EXAMINE --- Grants read access only
• NET$MANAGE --- Grants read and write access
• NET$SECURITY --- Grants the ability to modify default access control information for session control applications

The NET$MGMT utility is based on Motif. As such, it can be invoked using the same methods you use to invoke any other Motif application. Refer to the OpenVMS DECwindows Users Guide for information about how to run this application remotely. You can also run it locally by issuing the following command:

$ run sys$system:net$mgmt 

The application will check for and load the Helvetica 12-point 75-pitch font. In the unlikely event that this font is not present, the application will exit with an error message.

Once you have started NET$MGMT, you can refer to the Help pull-down menus for more information.

I.4 Managing Other DECnet Phase V Nodes

You can use the NET$MGMT Set/Change Node option to manage a remote DECnet Phase V node. You have the option of providing explicit access control information. The remote account must have at least the NET$EXAMINE right in order to successfully switch management control to the remote node.

If you do not provide explicit access control information, your rights on the remote node will be determined by the rights granted to the account associated with the remote node's session control application CML. Generally, this account will be the CML$SERVER account which will have the NET$EXAMINE right. Therefore, you will usually need to supply explicit access control information to an account having NET$MANAGE right in order to make network configuration changes on a remote node.

  PROFILE_VMS_027.HTML
  OSSG Documentation
   2-DEC-1996 12:35:32.61

Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

Legal