[Digital logo]
[HR]

DECnet-Plus for OpenVMS
Applications Installation and Advanced Configuration


Previous | Contents

Integrated mode routing works in the following way: It sends DECnet Phase IV messages across the network using DECnet Phase V Network layer protocols. Routers receiving DECnet Phase IV packets translate them to OSI CLNP format before forwarding them. Messages destined for DECnet Phase IV systems are translated to Phase IV format only on the last hop of their journey. Integrated mode routing allows routers to route both DECnet Phase IV and Phase V traffic while storing a single network topology in their internal databases.

Under integrated mode, DECnet-Plus systems attempt to send packets in DECnet Phase V format unless one of the following is true:

Integrated mode routing is the only mode supported on OpenVMS systems preceding DECnet/OSI for OpenVMS Version 6.0.

Segregated mode routing handles DECnet Phase IV and Phase V as independent protocols. Routers do not translate messages between DECnet Phase IV and Phase V formats. The routers must maintain separate network topologies in their internal databases to handle each type of protocol.

Under segregated mode, DECnet-Plus end systems transmit messages in the Phase IV address format if they have a DECnet Phase IV translatable destination address. All other messages are sent in DECnet Phase V format. If you use non-Digital routers that do not support Digital's technique of translating DECnet Phase V addresses to DECnet Phase IV, you may want to use segregated mode routing.

On OpenVMS systems, integrated mode is the default routing mode. Use integrated routing mode in an integrated routing environment where the routers can handle Phase-IV-to-Phase-V or Phase-V-to-Phase-IV packet format conversions. Use segregated routing mode when the adjacent router(s) cannot perform Phase-IV-to-Phase-V or Phase-V-to-Phase-IV packet conversions.


Note

If your OpenVMS system is running cluster alias, you must use integrated mode.

1.2.11.4 ESHello Timer

The default ESHello Timer attribute determines the interval, in seconds, when the end system (ES) sends out its hello. This interval multiplied by 3 is the amount of time the other end of a routing adjacency will wait before determining that this system is no longer able to accept connections.

* Routing default ESHello Timer?                        [600] : 

To select the default of 600, press Return. Otherwise, choose your own value and press Return.

1.3 Configuring Devices

The net$configure procedure checks for network devices on the system that are supported by net$configure and then configures them. If the procedure finds that you have WANDD or X.25 installed but not configured, you will see the following information:

You have installed wide area device support, but it has not been 
configured.  You may configure it now if you want. 
 
* Do you want to configure Wide Area devices?          [YES] : N 
%NET$CONFIGURE-I-SCANCONFIG, scanning device configuration - please wait 

Answer YES if you want to configure WANDD.


Note

If you answer NO to configuring wide area devices, you will not see any information regarding X.25 or P.S.I. configurations.

1.3.1 Configuring Asynchronous Connections

If you have installed and configured WANDD software on this system, you have the option of configuring it to support asynchronous connections.

* Do you want asynchronous datalink support?            [NO] : 

For more information on configuring asynchronous connections, see Appendix A.

1.3.2 Configuring Data Links and Routing Circuits

You now need to supply names for the data links and routing circuits you have on your system. Specify the simple name that you want to use for each data link and routing circuit.

* Data Link name to use for ESA0 (DESVA)?         [CSMACD-0] : 
* Routing Circuit Name for Data Link 'CSMACD-0'?  [CSMACD-0] : 

1.3.2.1 Specifying Circuit Cost and Routing Priority

The following applies only if your DECnet-Plus is a routing node.

For each data link and routing circuit pair entered, specify the circuit cost and router priority at level 1. If your node is also a level 2 router, you will be asked for level 2 cost and router priority.

Cost indicates the cost of traffic on a particular circuit. Priority refers to the priority for becoming a designated router on a LAN at level 1 or level 2.

* Level 1 Cost for Routing Circuit 'CSMACD-0'?             [8] : 
* Level 1 Router Priority for Routing Circuit 'CSMACD-0'? [64] : 
* Level 2 Cost for Routing Circuit 'CSMACD-0'?             [8] : 
* Level 2 Router Priority for Routing Circuit 'CSMACD-0'? [64] : 

1.3.3 Enabling Phase IV Addressing on Routing Circuits

If you previously specified a Phase IV-compatible address in order to communicate with Phase IV nodes (as in Section 1.2.6), entering YES to the following question allows Phase IV messages to be transmitted on the circuit. Answering NO to this question means that no Phase IV messages will be transmitted on the circuit.

* Enable Phase-IV Addressing on Routing Circuit 'CSMACD-0'? [YES] : 

1.3.4 FDDI Large Packet Support

If you have an FDDI-type circuit on your system, you have the option of enabling FDDI large packet support. (A large packet is 4 KB in size, where an Ethernet packet is 1500 bytes in size.) FDDI large packet support allows you to fully use the bandwidth of FDDI. (A DECnet-Plus router on the LAN, preferably on the FDDI, is required to enable large packet support.)

If you choose not to enable FDDI large packet support on the system, the FDDI circuit uses the bandwidth of Carrier Sense, Multiple Access with Collision Detection (CSMA-CD) instead.

If there is an FDDI-type circuit on the system, the procedure displays the following message:

An FDDI-type circuit has been found on the system.  You have the 
option of enabling FDDI large packet support on the system.  Note 
that a DECnet-Plus router on the LAN (preferably on the FDDI) is 
required in order to use FDDI large packet support. 
 
* Enable FDDI large packet support?                     [NO] : 
 

If you want to enable FDDI large packet support, answer YES.

1.3.5 Configuring an Alpha System

  1. For an Alpha system, the procedure displays the following information:
    DEC X.25 software has been installed on this system.  You have 
    the option of configuring DECnet to run over X.25. 
     
    * Do you want to configure DECnet over X.25?            [NO] : 
    

    Answer YES if you want to configure DECnet over X.25.
    If you answer YES, you will see a list of choices for the type of X.25 circuit to use:
         Types of X.25 circuits: 
     
         [1] - X.25 Dynamic Assigned (DA) 
         [2] - X.25 Static Incoming (IN) 
         [3] - X.25 Static Outgoing (OUT) 
         [4] - X.25 Permanent (PVC) 
     
    * Which type of X.25 circuit do you want to use?             : 4 
    

    This prompt allows you to select the type of routing circuit you want to use over X.25. The menu offers four choices:
    Enter the number for the type of circuit you want.
  2. The procedure then asks for information about the routing circuit.
    * Routing Circuit Name to use?                   [X25-PVC-0] : 
    

    Specify the simple name you want to use for the routing circuit. You can use the default or you can supply a name (for example, X25-PSI-0).
  3. The procedure then asks for a template name to use for the circuit you just specified.
    * Template name?                                 [X25-PVC-0] : 
    

    Specify the simple name of an X25 Access template. A default name is provided or you may enter your own name (for example, X25-DA-1).
    All X.25 routing circuits use an X25 Access template to either make or accept a network connection.
    Use the X.25 configuration program to configure X25 Access templates.
  4. If you chose to configure an X.25 dynamically assigned (DA) circuit or an X.25 static incoming (IN) circuit, the procedure asks for a filter name.
    * Filter name?                                    [X25-DA-0] : 
    

    Specify the simple name of an X25 Access filter. You may accept the default or you may enter your own name (for example, X25-IN-0).
    Static incoming and dynamically assigned X.25 circuits use an X25 Access filter to receive inbound network connections.
    For a static incoming circuit, the X25 Access filter must specify inbound DTE class, sending DTE address, call data value, and call data mask.
    For a dynamically assigned circuit, the X25 Access filter must specify inbound DTE class, call data value, and call data mask.
    Use the X.25 configuration program to configure X25 Access filters.
  5. If you choose to configure an X.25 dynamic assigned (DA) circuit, the procedure displays this prompt:
    * Do you want to configure any reachable addresses?     [NO] :                
    

    If you answer NO, the procedure skips to the question, "Configure another PSI routing circuit for DECnet?".
    If you want to configure any reachable address subentities, answer YES. The procedure displays the following prompt:
    * Reachable address name?                                    :                
    

    Specify the simple name of the reachable address subentity that you want to create (for example, ACCOUNTS_DEPT).
  6. The procedure then asks for the reachable address prefix:
    * Reachable address prefix                                   :                
    

    The reachable address subentity name is used to select the remote DTE address to where a routing packet is sent. The selection is done by finding a reachable address subentity that has an address prefix matching the beginning of the remote NSAP in the routing packet.
    Specify the address prefix for this reachable address entity. The address prefix is a string of characters that is a valid beginning of an NSAP (for example, 41:45436192:). The address prefix matches all NSAPs.
  7. The procedure then prompts for the reachable address data terminal equipment (DTE) list:
    * Reachable address dte list?                                :                
    

    You can configure a reachable address subentity with one or more DTE addresses. If more than one DTE address is configured, then only one is selected each time a packet is sent. All the remote DTE addresses must be accessible by the DTE class configured in the X25 Access template already configured for the associated dynamic assigned circuit.
    Specify the list of remote DTE addresses for this reachable address entity. A DTE address consists of 1 to 15 decimal characters. The DTE addresses in the list should be separated by commas (for example, 2,3,4).
  8. The procedure then prompts for additional reachable addresses:
    * Any more reachable addresses you wish to configure?   [NO] :                
    

    If you want to configure another reachable address subentity for this circuit, answer YES.
  9. When you have entered the circuit, template, and filter names and you have specified the appropriate reachable address information, the procedure asks if you want to configure any other circuits.
    * Configure another PSI routing circuit for DECnet?     [NO] :                
    

    If you do not want to configure any other PSI routing circuits, press Return for the default ([NO]). The configuration procedure continues with the next series of questions (such as FDDI large packet support or transports, for example).
  10. If no devices are found on the Alpha system, the procedure displays the following prompt:
    * Should a SYSMAN IO AUTO be executed?                       :                
    

    If you answer YES, the net$configure procedure invokes the SYSMAN IO AUTO command to find devices on the system. If you answer NO, there are no devices to configure.

    1.3.6 Configuring a VAX System

    If you answer YES to the question, "Do you want to configure Wide Area devices?" and you are using a VAX system, the procedure displays the following information:

    * Do you want to configure Wide Area devices?          [YES] : 
    

    Answer YES if you want to configure DECnet over P.S.I.

    If you answer YES, the procedure displays the following:

       This is the Configuration Procedure for the 
       =========================================== 
     
             VAX Wan Device Drivers for DECnet/OSI for VMS 
             ============================================= 
     
      The Wide Area Network Datalinks and Drivers are  a  prerequisite 
      for  DECnet/OSI.  They  also  provide  synchronous  datalinks in 
      systems that do not use DECnet/OSI for networking. 
     
     
      Access to DECnet/OSI datalinks (created by NCL) is  possible via 
      the QIO interface to the WAN pseudo-driver, WANDRIVER.   Layered 
      products  that use synchronous devices  do not  normally require 
      programming  access to WANDRIVER.  For  further information, see 
      the "DECnet/OSI for VMS WANDD Programming" guide. 
     
    Do you wish to use WANDRIVER [N] ? y 
    Will you use DEC HDLC [Y] ? 
    Will you use LAPB/E (VAX P.S.I. requires LAPB/E) [Y] ? 
     
      The DSV11 (Q-bus), DIV32 (Q-bus), DSB32 (BI-bus), DSF32 (MI-bus) and 
      DSW devices are soft-loadable. The WANDD startup procedure will load 
      the microcode for these devices if required. 
     
    Do you have any soft-loadable microcode devices on this system [N] ? 
    Will you use the VAXft DSF32 device driver [N] ? y 
     
      The  VAXft  DSF32  software  supports the  pairing  of  physical 
      controllers to  provide  a fault-tolerant  configuration. Such a 
      pairing  is  called  a  Failover Set. The  DSF32 device does not 
      automatically create the failover sets, so you will need to pair 
      controllers using the Failover Set Manager software. 
     
      This  management  software can be  invoked during system startup 
      from within the command procedure WANDD$STARTUP_SF.COM, which is 
      placed  in  the SYS$STARTUP  directory  by the  kit installation 
      procedure. If you want to have these Failover Sets automatically 
      configured  when  the system  starts up  you will need to modify 
      WANDD$STARTUP_SF.COM to  include  Failover Set Manager commands 
      that you require. 
     
    Are you satisfied with the answers you have given [Y] ? 
     
      If you have already started up the  WAN  Drivers  and  Datalinks 
      (that    is,    if    you    have   already   successfully   run 
      SYS$STARTUP:WANDD$STARTUP.COM  since  your   system   was   last 
      booted),  then  you will need to reboot your system for your new 
      configuration to take effect. 
     
    %NET$CONFIGURE-I-SCANCONFIG, scanning device configuration - please wait 
    * Do you want to configure DECnet over X.25?            [NO] : yes 
     
        Types of X.25 circuits: 
     
        [1] - X.25 Dynamic Assigned (DA) 
        [2] - X.25 Static Incoming (IN) 
        [3] - X.25 Static Outgoing (OUT) 
        [4] - X.25 Permanent (PVC) 
     
    * Which type of X.25 circuit do you want to use?             : 1 
    * Routing Circuit Name to use?                    [X25-DA-0] : 
    * Template name?                                  [X25-DA-0] : 
    * Filter name?                                    [X25-DA-0] : 
    * Do you want to configure any reachable addresses?     [NO] : 
    *  Configure another X.25 routing circuit for DECnet?   [NO] : 
    

    The procedure continues to ask for information. See Section 1.3.5 for the types of questions you will see and possible responses you can enter.

    If no devices are found on the VAX system, the procedure displays the following prompt:

    * Should a SYSGEN AUTOCONFIGURE ALL be executed?             :                
    

    If you answer YES, the net$configure procedure invokes the SYSGEN AUTOCONFIGURE ALL command to find devices on the system. If you answer NO, there are no devices to configure.

    1.4 Configuring the Network Service Protocol (NSP) Transport

    If you want the system to communicate with DECnet Phase IV nodes, answer YES to the following question.

    * Configure the NSP Transport?                         [YES] :                
    

    If you answer NO, the procedure still loads the NSP Transport image. However, NSP Transport is not configured or usable until you run the net$configure procedure and answer YES to the question, "Configure the NSP Transport?"

    To determine the maximum number of active transport connections allowed at any one time to this transport, the procedure displays the following prompt:

    * Maximum number of logical links?                     [200] :                
    

    You are then prompted to set the following values:

    * Maximum transmit and receive window?                 [20] : 
    
    * Maximum receive buffers?                           [4000] :       
    

    Digital recommends setting a value of 20 for the maximum transmit and receive window option. The recommended value to set the maximum receive buffers is no more than maximum window multiplied by maximum transport connections for normal network operation in a typical network environment.

    Selecting other values than these can significantly alter the behavior of your system and network and should only be done after a thorough analysis of your network traffic and application requirements.

    High values of maximum receive buffers may require considerable buffering capacity on your node; therefore, a non-paged pool should be allocated accordingly. If your node does not have enough non-paged pool, maximum receive buffers should be set to a smaller value than maximum window multiplied by maximum transport connections.

    The transport receiver's window is determined by a combination of maximum transport connections, maximum receive buffers, and maximum window. During the life of the connection, the receiver quota fluctuates according to the value of maximum receive buffers divided by currently active connections. The credit window sent to the remote transmitter may or may not be this quota value, depending on the value of maximum window. If maximum window is set to less than the determined receiver quota, this value is used instead for the credit granted to the remote transmitter.

    The transmitter of a transport connection uses the credit sent by the remote receiver as its transmit window, unless its maximum window is a lower value. In that case, maximum window is used for the transmitter window.

    1.5 Configuring the OSI Transport

    If you want the system to communicate with DECnet-Plus nodes, OSI nodes of other vendors, or if you plan to install the OSAK, FTAM, or VT software, answer YES. If you want to use the DECnet over TCP/IP and/or OSI applications over TCP/IP, answer YES.

    * Configure the OSI Transport?                         [YES] :               
    

    If you answer NO, the procedure still loads the OSI transport images. However, OSI transport is not configured or usable until you run the net$configure procedure and answer YES to the OSI transport question.

    To determine the maximum number of active transport connections allowed at any one time to this transport, the procedure displays the following prompt:

    * Maximum number of logical links?                     [200] :                
    

    You are then prompted to set the following values:

    * Maximum transmit and receive window?                 [20] : 
    
    * Maximum receive buffers?                           [4000] :       
    

    Digital recommends setting a value of 20 for the maximum transmit and receive window option. The recommended value to set the maximum receive buffers is no more than maximum window multiplied by maximum transport connections for normal network operation in a typical network environment.

    Selecting other values than these can significantly alter the behavior of your system and network and should only be done after a thorough analysis of your network traffic and application requirements.

    High values of maximum receive buffers may require considerable buffering capacity on your node; therefore, a non-paged pool should be allocated accordingly. If your node does not have enough non-paged pool, maximum receive buffers should be set to a smaller value than maximum window multiplied by maximum transport connections.

    The transport receiver's window is determined by a combination of maximum transport connections, maximum receive buffers, and maximum window. During the life of the connection, the receiver quota fluctuates according to the value of maximum receive buffers divided currently active connections. The credit window sent to the remote transmitter may or may not be this quota value, depending on the value of maximum window. If maximum window is set to less than the determined receiver quota, this value is used instead for the credit granted to the remote transmitter.

    The transmitter of a transport connection uses the credit sent by the remote receiver as its transmit window, unless its maximum window is a lower value. In that case, maximum window is used for the transmitter window.

    You are then prompted:

    * Run OSI Applications over TCP/IP?                    [YES] : 
    

    Answer YES to this question if you want to run any of your OSI applications over TCP/IP. This causes the configuration utility to build the appropriate RFC 1006 template and establish a listener port for port 102.

    * Run DECnet over TCP/IP?                             [YES] : 
    

    Answering YES to this question enables DECnet-Plus to run over a TCP/IP network to any system that has enabled this same feature. The configuration utility builds the appropriate RFC 1859 template and establishes a listener port for Port 399. (The default name for the RFC 1859 template is osit$rfc1006plus.)

    1.5.1 Congestion Avoidance

    One feature of OSI transport is the ability to use the Congestion Experienced field in the Connectionless-mode Network Service (CLNS) routing header, and to implement a Congestion Avoidance scheme in heavily congested networks. The CLNS Congestion Experienced field is used by routers that support this feature (such as DECNIS) to give an early indication of congestion. When OSI transport receives data that passed through a network path where the Congestion Experienced bit is set, OSI transport reduces the transmit rate of the sending end system to help alleviate network congestion.

    This feature works well in networks where all protocols support Congestion Avoidance mechanisms. However, it has been noted that in some heavily congested multi-protocol networks, this feature can negatively impact the performance of DECnet compared to other protocols.

    Digital recognizes that most of its customers have multi-protocol networks. In this environment, not all network protocols have Congestion Avoidance mechanisms. Therefore, the default of this characteristic is disabled.

    If you operate in an environment where you can take advantage of Congestion Avoidance mechanisms, Digital recommends that you enable the feature again.

    You are asked a new question about multi-protocol networks:

    * Is this system operating in a multi-protocol network? [YES] : 
    

    If you take the default answer of YES, then the OSI transport Congestion Avoidance characteristic is set to FALSE.

    A NO answer to this question sets the characteristic to TRUE.

    To change transport Congestion Avoidance values, you must invoke net$configure in ADVANCED mode and use Option 4 (Configure Transports) and answer NO to the question.

    1.5.2 Setting Up the OSI Loopback Test Application Account

    If you answered YES to the "Configure the OSI Transport?" question described earlier, the procedure displays the following prompt:

    * Username for OSI loopback test application to use? [SYSTEST] : 
    

    Press Return to accept the default user name for the application loopback test account. The procedure displays a message stating that the default OSI templates have been created.

    %NET$CONFIGURE-I-CREDEFOSITEMPLATE, created default OSI templates 
    

    1.5.3 Creating Additional OSI Templates

    If you configure OSI transport, net$configure automatically creates the default OSI templates required by the OSAK and FTAM installation and verification procedures (IVPs).

    * Do you want to create additional OSI templates?       [NO] :  yes 
    

    If you answer YES to the previous prompt, the procedure displays prompts to obtain the information required to configure the OSI template; otherwise, the procedure skips to the Event Dispatcher question (see Section 1.6).

    * Type of network service (CLNS/CONS/RFC1006)?  [CLNS] : 
    

    If you want to use Connectionless-mode Network Service (CLNS), press Return. If you want to use Connection Oriented Network Service (CONS), enter CONS. If you want to use DECnet over TCP/IP and/or OSI applications over TCP/IP enter RFC1006.

    For more information about types of network service, refer to the DECnet-Plus for OpenVMS Network Management guide or type a question mark (?) at the prompt.

    Depending on which network service you select, you will see one of the following prompts:

    * Name of the OSI template?               [OSIT$CLNS_Default0] : 
    
    * Name of the OSI template?               [OSIT$CONS_Default0] : 
    
    * Name of the OSI template?               [OSIT$RFC1006_Default0] : 
    

    Enter the name you want to use for the OSI template (for example, OSI_TEMPLATE_1) or press Return to accept the default OSI template name.

    * Will this template be used for inbound packets?              : 
    

    If you want this template to be used for inbound connections, enter YES. If you want this template to be used for outbound connections, enter NO.

    * Transport Classes to support?                       [4] : 
    

    Enter the number of the transport protocol class you want to use for this template. DECnet-Plus for OpenVMS supports three transport protocol classes: 0, 2, and 4. If you select CONS as the network service type, the default is 0, 2, 4. If you select CLNS, the default is 4. If you select RFC 1006, the default is 0, 2. You can also configure multiple OSI templates. For more information about transport protocol classes, refer to the DECnet-Plus for OpenVMS Network Management guide or type a question mark (?) at the prompt.

    1.5.3.1 CLNS Network Service

    If you select the network service CLNS, you will see the following prompt:

    * Use full CLNP or Null Internet?            [Full CLNP] : 
    


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

    [HR]

      PROFILE_001.HTML
      OSSG Documentation
       2-DEC-1996 12:33:22.04
    

    Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

    Legal