When an end system communicates to another node for the first time, the end system cache has no routing information for that node. The end system chooses at random an adjacent router and transmits the data to it, allowing the adjacent router to find a path to the destination node. The end system creates cache entries based on information about the routing path received from incoming data sent by routers and from advertisements sent directly from other end systems.
Cache entries are each assigned a precedence which determines the path chosen when two or more cache entries refer to the same destination. The Routing module assigns precedence as shown in Table 8-5, where 1 is the highest precedence. Direct reachability indicates the path is direct from source to destination without intermediary routers. Indirect indicates the path is through one or more intermediary routers. Reverse reachability implies the directness of the path is indeterminate at the time (whether a direct path exists will be resolved during subsequent communications).
A reverse path cache entry indicates that a data packet was received from an adjacent node on a specific circuit. The adjacent node could be the original sender or the last router that forwarded the packet. Given no other information, the most efficient path for sending response packets is usually the path the original data message followed.
Note
A static routing path that is defined by a reachable address of type outbound has the highest precedence. All other cache entries for the same destination are ignored.
Precedence | Reachability | Blocksize |
---|---|---|
1 | Direct | FDDI |
2 | Indirect | FDDI |
3 | Reverse | FDDI |
4 | Direct | not FDDI |
5 | Indirect | not FDDI |
6 | Reverse | not FDDI |
The Routing module follows these rules for making a cache entry:
When multiple paths with the same precedence exist for the same destination, the Routing module selects the path based on round robin. This helps balance the load on the paths. On multicircuit end systems, if no direct path to the destination node exists on a broadcast circuit, a duplicate packet is sent periodically, as determined by the probe rate.
The es cache holding time attribute determines how long an entry is held in the end system cache. The default is 600 seconds. The timer is refreshed each time a data packet is successfully received by the destination node over the path defined by the entry. The entry is deleted if no communication occurs between the source and destination nodes within the period defined by the timer. This maximizes the effectiveness of the end system cache.
Displaying Cache Entries
Cache entries are visible as network management entities known as routing destination cache.
On OpenVMS systems, use the System Dump Analyzer (SDA) to show cache entries, as in the following example:
$ analyze/system OpenVMS (TM) VAX System Analyzer SDA> net show routing cache %SDA-I-READSYM, reading symbol table SYS$COMMON:[SYSEXE]NET$SYMBOLS.STB;1 DECnet-Plus for OpenVMS Routing ES Cache Dump -------------------------------------------- %SDA-I-READSYM, reading symbol table SYS$COMMON:[SYS$LDR]NET$ROUTING_ES.STB;1 Routing Prefix DataBase Address 816C63A8 Prefix Table Start: 825D5F0C , End: 825D610C, Size 0 Routing Cache DataBase Address 816C6390 Cache Table Start: 825D10CC , End: 825D12CC, Size 1 Cache Entry at Address 825D256C NSAP: 4900 04AA0004 007F1321 OSI Transport - (4.895) Cache Circuit Entry Count : 1, Probe Count: 992 Cache Circuit List: 8260B500 Cache Circuit Entry: Type: BroadCast Format: PhaseV Reachability: Direct Blocksize: Non-FDDI Remaining LifeTime: 005F Holding Time: 0258 Data Link Address: 137F 000400AA ª..... 00000000 (4.895) SDA>
DECnet-Plus supports the inactive subset of CLNS, also known as null internet. An inactive subset PDU contains no Network layer addressing information; it is sent directly to the data link address derived from the destination NSAP address. Therefore, it cannot be routed by an intermediate system. This means that only LAN devices can support the inactive subset PDU, and the two communicating nodes must be on the same LAN. The inactive subset of CLNS allows communication with OSI systems that only implement the inactive subset.
Configuring CLNS with null internet is no different from configuring full CLNS, with the following restrictions:
For more information on configuring CLNS OSI transport to use the null internet, see Section 8.5.2.4.3.
You can turn the ability to transmit and receive inactive subset protocol data units (PDUs) on and off on a per circuit basis by defining a value for the circuit attribute inactive area address. The following example uses the default inactive area address attribute on a LAN:
ncl> create routing circuit csmacd-0 - _ncl> type csma-cd ncl> set routing circuit csmacd-0 - _ncl> inactive area address {49::FF-00} ncl> enable routing circuit csmacd-0
You must do this after the circuit is created, but before you enable it. The value is the address of an otherwise unused area in your network.
If you want to change the transport, modify the Routing module's preset attribute, inactive selector, with the selector of the transport you want to use. Only one transport may use the inactive subset and, by default, this is OSI transport (which has a default selector value of 33). To operate NSP over the inactive subset, before enabling the Routing module (and any circuits) enter the command:
ncl> set routing inactive selector 32
When using the inactive subset, destination NSAPs must contain the inactive area address followed by the data link address of the remote machine followed by the transport selector. For example:
49::FF-00:08-00-23-00-01-02:21
Reachable addresses allow the system manager to override the automatic routing mechanisms in DECnet-Plus. You can define reachable addresses for each circuit. Two types of reachable addresses are outbound and filter, as described below. (For information about reachable addresses used for OSI transport over X.25 CONS circuits, see Section 8.8.3.1.)
You can use NCL to switch from the default (outbound) to filter by setting the reachable address entity type attribute to the value filter. You must disable the routing reachable address entity before changing the value of the type attribute.
Note
For either the outbound or filter type of reachable address, you must set the mapping attribute to manual (the default is x.121). See the command example below.
The following reachable address attributes are supported by outbound reachable addresses:
The following example shows how to use NCL commands to create an outbound type of reachable address:
ncl> create routing circuit csmacd-0 reachable address to-area4 - _ncl> address prefix 49::00-04: ncl> set routing circuit csmacd-0 reachable address to-area4 - _ncl> mapping manual ncl> set routing circuit csmacd-0 reachable address to-area4 - _ncl> type outbound ncl> set routing circuit csmacd-0 reachable address to-area4 - _ncl> data format phaseiv ncl> set routing circuit csmacd-0 reachable address to-area4 - _ncl> block size 500 ncl> set routing circuit csmacd-0 reachable address to-area4 - _ncl> lan address aa-00-04-00-xx-xx
The permitted lan addresses attribute applies to filter reachable addresses for broadcast circuits only. This attribute specifies a set of LAN addresses corresponding to routers that are permitted to forward to this prefix. The default is an empty set. You must specify at least one LAN address. Specify these LAN addresses within a pair of braces, separating the addresses by commas, as in the last command in the following example, which shows how to create a filter reachable address.
ncl> create routing circuit csmacd-0 reachable address to-area4 - _ncl> address prefix 49::00-04: ncl> set routing circuit csmacd-0 reachable address to-area4 - _ncl> mapping manual ncl> set routing circuit csmacd-0 reachable address to-area4 - _ncl> type filter ncl> set routing circuit csmacd-0 reachable address to-area4 - _ncl> data format phasev ncl> set routing circuit csmacd-0 reachable address to-area4 - _ncl> permitted lan address {aa-00-04-00-xx-xx, aa-00-04-00-yy-yy}
DECnet Phase V nodes support multiple transport protocols. DECnet Phase IV nodes have Network Services Protocol (NSP) as the only transport protocol available. DECnet Phase V nodes have NSP and OSI transport available. DECnet Phase V automatically determines a compatible transport protocol between communicating nodes.
OSI transport on DECnet Phase V systems supports the Connection-Oriented Transport Protocol specification (International Standard ISO 8073) and the Connectionless-Mode Transport Protocol specification (International Standard ISO 8602). The OSI transport can use two types of network services:
On OpenVMS systems, the OSI transport implements the RFC 1006 and RFC 1859 specifications, using TCP network services.
The Routing module supports CLNS. The X25 Access module supports CONS.
DECnet-Plus automatically starts with both OSI transport and NSP. If, for any reason, you want to disable either transport protocol, use disable nsp or disable osi transport.
If you do not want session control to use a particular protocol, use one of the following commands:
ncl> delete session control transport service osi
ncl> delete session control transport service nsp
This section explains how to configure and manage:
This section explains how to configure the Network Services Protocol (NSP). The following example shows the commands to create the nsp entity on your system. Digital recommends that you accept the default settings (used in the example) for the various attributes and change these only if you need to. Refer to the DECnet-Plus Network Control Language Reference for more information about these attributes. Figure 8-5 shows the nsp entity and its subentities.
Figure 8-5 nsp Entity
ncl> create nsp ncl> set nsp delay factor 2, delay weight 3, - (1) _ncl> maximum remote nsaps 200, maximum transport connections 200, - (2) _ncl> maximum window 20, nsap selector 32, - (3) _ncl> retransmit threshold 5 ncl> enable nsp
For some NSP attributes, such as maximum remote nsaps or maximum transport connections, you can raise values at any time, but you cannot lower the value without first disabling NSP.
The following is an example of how to set up NSP:
ncl> create nsp ncl> set nsp maximum window 8 ncl> set nsp maximum transport connections 200 ncl> enable nsp ncl> create session control transport service nsp protocol %x04
Figure 8-6 shows the osi transport entity and its subentities.
Figure 8-6 osi transport Entity
When DECnet-Plus is configured, templates are set up for the OSI Transport module. Each template is an NCL database entry that manages network access. Each template includes a group of attributes that supply default values for certain parameters that influence the operation of a port on a transport connection. The templates store information and also may reference information located elsewhere.
Each OSI transport template corresponds to a specific type of network service to which OSI transport can direct outbound messages and from which it can receive inbound messages.
OSI transport supports three network services:
On OpenVMS systems, OSI transport supports RFC 1006 as a service and template.
Table 8-6 describes the templates that are set up for OSI transport on your system. Note that the null internet does not require a template.
Name | Network Service | Classes |
---|---|---|
Default | CLNS | 4 |
OSIT$LOOP_CONS | CONS | 0, 2, 4 |
OSIT$LOOP_CLNS | CLNS | 4 |
OSIT$RFC1006 | RFC1006 | 0 |
OSIT$RFC1006PLUS | RFC1859 | 2 |
Do not modify listed attributes of the default template. The other templates are defined in the NCL initialization script SYS$MANAGER:NET$OSI_TRANSPORT_STARTUP.NCL.
The following example shows the nclcommands you can use to create the osi transport entity on your system, setting attributes applicable to all types of services. Section 8.5.2.3 gives examples of commands required to configure CONS support. Digital recommends that you accept the default settings used in the examples for the attributes. Change them only if necessary. For more information on these attributes, refer to the DECnet-Plus Network Control Language Reference.
ncl> create osi transport ncl> set osi transport delay factor 4, delay weight 5,- (1) _ncl> maximum remote nsaps 64, - (2) _ncl> maximum transport connections 33, maximum window 20 (3) ncl> enable osi transport
On OpenVMS systems, disable the osi transport entity before modifying attributes that affect operation.
To configure CONS support on OpenVMS systems, each element in the set of the cons filters attribute of the osi transport entity must have a corresponding X25 Access filter of the same name. By default, the cons filters attribute of the osi transport entity is set to osi transport.
Similarly, the cons template attribute of the osi transport templatesubentity must contain a name that is an X25 Access filter and is contained in the set of cons filters of the OSI Transportentity. The default value of the cons template attribute of an osi transport templatesubentity is osi transport.
PROFILE_VMS_010.HTML OSSG Documentation 2-DEC-1996 12:35:02.11
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.