|
Table Of Contents
DECnet Phase IV Routing Frame Format
Using DECnet in a Multiprotocol Environment
DECnet: Connections to DEC Hosts Fail over Router (End Node Problem)
Configuring a DECnet Node to Log DECnet Events
DECnet: Connections to DEC Hosts Fail over Router (Router Problem)
DECnet: End Nodes Cannot Find Designated Router
DECnet: Router or End Node Sees Incorrect Designated Router
DECnet: Routers Not Establishing Adjacencies
DECnet: Routing Node Adjacencies Toggle Up and Down
DECnet: No Phase IV Connectivity over Phase V Backbone
DECnet Phase IV and ISO CLNS Addresses
Troubleshooting DECnet
Digital Equipment Corporation (Digital) developed the DECnet protocol family to provide a well-thought-out way for its computers to communicate with one another. The first version of DECnet, released in 1975, allowed two directly attached PDP-11 minicomputers to communicate. In more recent years, Digital has included support for nonproprietary protocols, but DECnet remains the most important of Digital's network product offerings.
DECnet is currently in its fifth major product release (sometimes called Phase V and referred to as DECnet/OSI in Digital literature). DECnet Phase V is a superset of the OSI protocol suite and supports all OSI protocols as well as several other proprietary and standard protocols that were supported in previous versions of DECnet. As with past changes to the protocol, DECnet Phase V is compatible with the previous release (Phase IV, in this case).
Digital Network Architecture
Contrary to popular belief, DECnet is not a network architecture at all but is, rather, a series of products conforming to Digital's Digital Network Architecture (DNA). Like most comprehensive network architectures from large systems vendors, DNA supports a large set of both proprietary and standard protocols. The list of DNA-supported technologies grows constantly as Digital implements new protocols. Figure 11-1 illustrates an incomplete snapshot of DNA and the relationship of some of its components to the OSI reference model.
Figure 11-1 DNA and the OSI Reference Model
As Figure 11-1 shows, DNA supports a variety of media and link implementations. Among these are well-known standards such as Ethernet, Token Ring, Fiber Distributed Data Interface (FDDI), IEEE 802.2, and X.25. DNA also offers a traditional point-to-point link-layer protocol called Digital Data Communications Message Protocol (DDCMP) and a 70-Mbps bus used in the VAX cluster called the computer-room interconnect bus (CI bus).
The Network Layer
DECnet supports both connectionless and connection-oriented network layers. Both network layers are implemented by OSI protocols. The connectionless implementation uses the Connectionless Network Protocol (CLNP) and the Connectionless Network Service (CLNS). The connection-oriented network layer uses the X.25 Packet-Level Protocol (PLP), which is also known as X.25 Level 3, and the Connection-Mode Network Protocol (CMNP).
Although most of DNA was brought into OSI conformance with DECnet Phase V, DECnet Phase IV routing was already very similar to OSI routing. Phase V DNA routing consists of OSI routing (ES-IS and IS-IS), plus continued support for the DECnet Phase IV routing protocol.
DECnet Phase IV Routing Frame Format
The DECnet Phase IV routing protocol differs from IS-IS in several ways. One difference is in the protocol header. The DNA Phase IV routing layer header is shown in Figure 11-2; IS-IS packet formats are shown in Chapter 12, "Troubleshooting ISO CLNS."
Figure 11-2 A DNA Phase IV Routing Layer Header
The first field in a DNA Phase IV routing header is the routing flags field, which includes:
•A return-to-sender bit that, if set, indicates that the packet is returning to the source.
•A return-to-sender-request bit that, if set, indicates that request packets should be returned to the source if they cannot be delivered to the destination.
•An intraLAN bit, which is on by default. If the router detects that the two communicating end systems are not on the same subnetwork, it turns the bit off.
•Other bits that indicate header format, whether padding is being used, and other functions.
The destination node and source node fields identify the network addresses of the destination nodes and the source node.
The nodes traversed field shows the number of nodes the packet has traversed on its way to the destination. This field allows implementation of a maximum hop count so that obsolete packets can be removed from the network.
DECnet identifies two types of nodes: end nodes and routing nodes. Both end nodes and routing nodes can send and receive network information, but only routing nodes can provide routing services for other DECnet nodes.
DECnet routing decisions are based on cost, an arbitrary measure assigned by network administrators to be used in comparing various paths through an internetwork environment. Costs are typically based on hop count, media bandwidth, or other measures. The lower the cost, the better the path. When network faults occur, the DECnet Phase IV routing protocol uses cost values to recalculate the best paths to each destination. Figure 11-3 illustrates the calculation of costs in a DECnet Phase IV routing environment.
Figure 11-3 A DECnet Phase IV Routing Protocol Cost Calculation
Addressing
DECnet addresses are not associated with the physical networks to which the nodes are connected. Instead, DECnet locates hosts using area/node address pairs. An area's value ranges from 1 to 63, inclusive. A node address can be between 1 and 1023, inclusive. Therefore, each area can have 1023 nodes, and approximately 65,000 nodes can be addressed in a DECnet network. Areas can span many routers, and a single cable can support many areas. Therefore, if a node has several network interfaces, it uses the same area/node address for each interface. Figure 11-4 shows a sample DECnet network with several addressable entities.
Figure 11-4 Examples of DECnet Addresses
DECnet hosts do not use manufacturer-assigned Media Access Control (MAC)-layer addresses. Instead, network-level addresses are embedded in the MAC-layer address according to an algorithm that multiplies the area number by 1,024 and adds the node number to the product. The resulting 16-bit decimal address is converted to a hexadecimal number and appended to the address AA00.0400 in byte-swapped order, with the least significant byte first. For example, DECnet address 12.75 becomes 12363 (base 10), which equals 304B (base 16). After this byte-swapped address is appended to the standard DECnet MAC address prefix, the resulting address is AA00.0400.4B30.
Routing Levels
DECnet routing nodes are referred to as either Level 1 or Level 2 routers. A Level 1 router communicates with end nodes and with other Level 1 routers in a particular area. Level 2 routers communicate with Level 1 routers in the same area and with Level 2 routers in different areas. Together, Level 1 and Level 2 routers form a hierarchical routing scheme. This relationship is illustrated in Figure 11-5.
Figure 11-5 DECnet Level 1 and Level 2 Routers
End systems send routing requests to a designated Level 1 router. The Level 1 router with the highest priority is elected to be the designated router. If two routers have the same priority, the one with the larger node number becomes the designated router. A router's priority can be manually configured to force it to become the designated router.
As shown in Figure 11-5, multiple Level 2 routers can exist in any area. When a Level 1 router wishes to send a packet outside its area, it forwards the packet to a Level 2 router in the same area. In some cases, the Level 2 router may not have the optimal path to the destination, but the mesh network configuration offers a degree of fault tolerance not provided by the simple assignment of one Level 2 router per area.
The Transport Layer
The DNA transport layer is implemented by a variety of transports, both proprietary and standard. OSI transports TP0, TP2, and TP4 are supported.
Digital's own Network Services Protocol (NSP) is functionally similar to TP4 in that it offers connection-oriented, flow-controlled service with message fragmentation and reassembly. Two subchannels are supported—one for normal data and one for expedited data and flow control information. Two flow control types are supported—a simple start/stop mechanism where the receiver tells the sender when to terminate and resume data transmission and a more complex flow control technique, where the receiver tells the sender how many messages it can accept. NSP can also respond to congestion notifications from the network layer by reducing the number of outstanding messages it will tolerate.
Upper-Layer Protocols
Above the transport layer, DECnet supports its own proprietary upper-layer protocols as well as standard OSI upper-layer protocols. DECnet application protocols use the DNA session control protocol and the DNA name service. OSI application protocols are supported by OSI presentation- and session-layer implementations.
Troubleshooting DECnet
This section presents protocol-related troubleshooting information for DECnet Phase IV connectivity and performance problems. The procedures outlined apply only to environments in which DECnet routing is enabled on the router, not to environments in which DECnet is being bridged (that is, bridging is enabled on the router interfaces and EtherType 6003 is being passed).
This chapter does not discuss other Digital protocols, such as Maintenance Operation Protocol (MOP), local-area transport (LAT), local-area VAX cluster (LAVC), and local-area systems technology (LAST).
Note For information about troubleshooting ISO CLNS (DECnet Phase V) problems, refer to Chapter 12, "Troubleshooting ISO CLNS."
The section "Using DECnet in a Multiprotocol Environment" discusses possible problems when using DECnet in an internetwork running other protocols as well. The remaining sections describe specific DECnet symptoms, the problems that are likely to cause each symptom, and the solutions to those problems.
The following sections outline the most common network issues in DECnet networks:
•DECnet: Connections to DEC Hosts Fail over Router (End Node Problem)
•DECnet: Connections to DEC Hosts Fail over Router (Router Problem)
•DECnet: End Nodes Cannot Find Designated Router
•DECnet: Router or End Node Sees Incorrect Designated Router
•DECnet: Routers Not Establishing Adjacencies
•DECnet: Routing Node Adjacencies Toggle Up and Down
•DECnet: No Phase IV Connectivity over Phase V Backbone
Note In some of the symptom discussions that follow, Operator Communication Manager (OPCOM) messages are used to illustrate certain errors. These examples assume that OPCOM is running and event logging is enabled. For more information about event logging, see the section "Configuring a DECnet Node to Log DECnet Events" later in this chapter.
Using DECnet in a Multiprotocol Environment
It is important to remember that DECnet changes the MAC addresses of router interfaces. This behavior can cause problems for other protocols that are already enabled on the router.
If after enabling DECnet on a router interface other protocols (such as Novell IPX or XNS) experience connectivity loss due to address resolution problems, the problem is probably a result of DECnet changing the MAC address of the router interface.
As a rule, enable DECnet on router interfaces first, and then enable other protocols. Otherwise, use the copy running-config startup-config command to save the router configuration and then reload the router.
DECnet: Connections to DEC Hosts Fail over Router (End Node Problem)
Symptom: DECnet nodes cannot communicate when attempting to make connections over routers.
Note This section focuses on problems in end nodes. For router-related problems and solutions, see the section "DECnet: Connections to DEC Hosts Fail over Router (Router Problem)" later in this chapter.
Table 11-1 outlines the problems that might cause this symptom and describes solutions to those problems.
Table 11-1 DECnet: Connections to DEC Hosts Fail over Router (End Node Problem)
Possible Problem SolutionMisconfigured end node
1. Check the end node configuration using the show executor characteristics NCP1 command.
2. Make sure that the end node type (nonrouting Phase IV, routing Phase IV, area), node address, node name, and routing and link parameters are correctly specified.
3. Check the circuit characteristics using the show known circuit characteristics NCP command.
4. Make sure that the designated router, hello timer, router priority (if the node is a routing node), and other circuit characteristics are properly configured.
The following decnet commands are used to set the designated router, hello timers, and router priority on a Cisco router:
decnet hello-timer seconds
•seconds—Interval at which the Cisco IOS software sends hello messages. It can be a decimal number in the range 1 to 8191 seconds. The default is 15 seconds.
decnet router-priority value
To elect a designated router to which packets will be sent when no destination is specified, use the decnet router-priority interface configuration command.
•value—Priority of the router. This can be a number in the range 0 through 127. The larger the number, the higher the priority. The default priority is 64.
Misconfigured end node (continued)
5. Reconfigure the end node if any of the end node or circuit characteristics are misconfigured. For information on configuring end nodes, refer to the vendor documentation.
Host access control rejects connection
With this problem, users see the message "connect failed, access control rejected." This is typically a session-layer problem.
1. Make sure that the following requirements are satisfied:
•User-supplied access control information is correct
•Proxy access is set up correctly
•Proxy database and proxy account are correct
2. Make sure that the user's security access matches the access specifications for the user on the remote systems.
3. If there are problems in any of these areas, make changes as necessary.
Unrecognized object
With this problem, users see the message "connect failed, unrecognized object."
1. Use the tell NCP command to determine whether the object is defined on the target node. The syntax of the tell command is as follows:
tell target-node-name show known objects
2. If the object is not defined, log in as superuser and run NCP to define the object with the set object NCP command, as follows:
set object object-id
3. After the object is defined, use the tell NCP command to determine whether the object has a file specified, as follows:
tell target-node-name show object object-id character
4. Exit NCP and determine whether the file specified for the object exists.
5. If the file for the requested object does not exist, create the file.
6. Make sure the permissions for the specified file are correct.
Insufficient resource error
With an insufficient resource error, VMS2 users see the following message:
% system-E-REMRSC, insufficient system resource at remote node
Note: This error message might not indicate a problem. These parameter values can be set intentionally to prevent network connections beyond a certain number.
Try tuning the following DEC target system parameters:
•SYSGEN parameters:
–MAXPROCESSCNT
•NCP parameters:
–MAXIMUM LINKS
–ALIAS MAXIMUM LINKS
•AUTHORIZE parameters:
–MAXJOBS
–MAXACCTJOBS
1 NCP = Network Control Program
2 VMS = Virtual Memory System
Configuring a DECnet Node to Log DECnet Events
In addition to the diagnostic tools available on your router, DECnet environments provide a wealth of diagnostic information. DECnet nodes can use the DECnet Event Logging Facility (EVL) to track DECnet events. EVL allows you to monitor significant network events, such as lost packets and circuit failures.
The following steps outline the basic tasks required to enable event logging on a VMS system:
Step 1 Determine whether the OPCOM process is running:
$ show system
Step 2 If OPCOM does not appear in the list of running processes, enter the following command to start it:
$ @sys$system:STARTUP.com OPCOM
Step 3 Use the NCP to enable event logging:
$ MCR NCP
NCP> SET logging MONITOR KNOWN EventsNCP> DEFINE logging MONITOR KNOWN EventsNCP> SET logging MONITOR STATE ONNCP> DEFINE logging MONITOR STATE ONStep 4 Exit NCP:
NCP> Exit
Step 5 To monitor network events from a console terminal, enter the following command at the VMS system prompt:
$ REPLY/ENABLE = NETWORK
(This command is equivalent to the terminal monitor privileged exec command.)
DECnet: Connections to DEC Hosts Fail over Router (Router Problem)
Symptom: DECnet nodes cannot communicate when attempting to make connections over routers.
Note This section focuses on problems in the router. For end node-related problems and solutions, see the section "DECnet: Connections to DEC Hosts Fail over Router (End Node Problem)" earlier in this chapter.
Table 11-2 outlines the problems that might cause this symptom and describes solutions to those problems.
DECnet: End Nodes Cannot Find Designated Router
Symptom: End nodes cannot find a designated router. End nodes cannot access nodes that are on different LANs, but other nodes connected to the same LAN are accessible.
Table 11-3 outlines the problems that might cause this symptom and describes solutions to those problems.
DECnet: Router or End Node Sees Incorrect Designated Router
Symptom: Routers and end nodes see an incorrect or an unexpected designated router. If your network requires a specific router to be elected the designated router, allowing another router to become a designated router can cause unpredictable network behavior and can block connectivity in and out of the area.
Table 11-4 outlines the problems that might cause this symptom and describes solutions to those problems.
DECnet: Routers Not Establishing Adjacencies
Symptom: Routers do not establish adjacencies with other routers on the same LAN.
Table 11-5 outlines the problems that might cause this symptom and describes solutions to those problems.
DECnet: Routing Node Adjacencies Toggle Up and Down
Symptom: Routing adjacencies toggle up and down. Output such as the following appears repeatedly on the DEC system console:
%%%%%%%%%%% OPCOM 30-JUN-1993 1:25:07.45 %%%%%%%%%%%%Message from user DECNET on The BayDECnet event 4.16, adjacency rejectedFrom NODE 12.1 (The Bay), 30-JUN-1993 1:25:07.45Circuit UNA-0, Adjacent node = 1.101 (Vax1)%%%%%%%%%%% OPCOM 30-JUN-1993 1:25:07.46 %%%%%%%%%%%%Message from user DECNET on The BayDECnet event 4.15, adjacency upFrom NODE 12.1 (The Bay), 30-JUN-1993 1:25:07.46Circuit UNA-0, Adjacent node = 1.12 (Vax2)This output indicates that routers are constantly being added to and removed from the routing table. The OPCOM messages specify DECnet events 4.16 (adjacency rejected) and 4.15 (adjacency up) for specific routing nodes.
Table 11-6 outlines the problems that might cause this symptom and describes solutions to those problems.
DECnet: No Phase IV Connectivity over Phase V Backbone
Symptom: Communication between DECnet Phase IV areas separated by an ISO CLNS (Phase V) backbone fails. Phase IV nodes cannot communicate with other Phase IV nodes across a Phase V cloud. However, nodes can communicate with one another within the same Phase IV cloud.
Note For more information about troubleshooting DECnet /OSI internetworks, see Chapter 12, "Troubleshooting ISO CLNS."
Table 11-7 outlines the problems that might cause this symptom and describes solutions to those problems.
Table 11-7 DECnet: No DECnet Phase IV Connectivity over Phase V Backbone
Possible Problem SolutionMisconfigured addresses
1. Use the show interfaces command to confirm that CLNS and DECnet Phase IV are both configured on ISO CLNS backbone routers.
2. Make sure that the decnet conversion global configuration command is configured on backbone routers to allow DECnet Phase IV-to-ISO CLNS conversion.
3. Use the show running-config privileged exec command on backbone routers to verify that DECnet addresses agree with CLNS addresses.
Two kinds of addresses are easily misconfigured: DECnet addresses, which should be specified in decimal, and CLNS Network Service Access Point addresses, which should be specified in hexadecimal.
For more information, refer to the section "DECnet Phase IV and ISO CLNS Addresses" later in this chapter.
4. If the area addresses do not agree, confirm the address specifications and reconfigure the DECnet and CLNS addresses on the router.
For detailed information on configuring DECnet Phase IV, CLNS, and conversion, refer to the Cisco IOS Network Protocol Configuration Guide, Part 2.
ISO CLNS or DECnet not enabled on appropriate interfaces
1. On Phase IV routers bordering the backbone, use the show clns interface and show decnet interface commands to see which interfaces are running which protocols.
Verify that DECnet and ISO CLNS are enabled on backbone router interfaces where conversion will occur.
2. If DECnet is not configured on the correct interfaces, enable it. Make sure you specify the decnet cost interface configuration command to assign a cost to the interface. If ISO CLNS routing is not configured on the correct interfaces, use the clns router interface configuration command. The full syntax for this command is
clns routing
Use the no clns routing command to disable CLNS routing:
no clns routing
For detailed information on configuring DECnet Phase IV and ISO CLNS, refer to the Cisco IOS Network Protocol Configuration Guide, Part 2.
DECnet Phase IV and ISO CLNS Addresses
Address conversion between DECnet Phase IV and ISO CLNS (Phase V) requires that NSAP addresses be Phase IV compatible. If an address can be converted to a valid Phase IV address, it is Phase IV compatible.
To be compatible, the OSI area number must be between 1 and 63 (when converted to decimal) and the OSI station ID must be in the format AA00.0400.xxxx. In addition, the OSI area and the DECnet area (calculated from the OSI station ID) must match. This allows the DECnet Phase IV address to be extracted properly from the NSAP.
Table 11-8 shows addresses and their equivalent DECnet Phase IV addresses, and indicates whether the NSAP address is Phase IV compatible and why.
DECnet: Poor Performance
Symptom: Performance in a DECnet network is slow or unreliable. Connections to hosts over one or more routers are periodically inaccessible or drop unexpectedly.
Table 11-9 outlines the problems that might cause this symptom and describes solutions to those problems.
Table 11-9 DECnet: Poor Performance
Possible Problem SolutionDECnet traffic problem
1. Use the show decnet traffic exec command and check the Received and Forwarded fields in the output. In most cases, the values in these fields should match.
2. If the values do not match, check the Returned, Converted, Access Control Failed, No Route, and Encapsulation Failed fields to see what is causing the performance problem.
3. If the problem cannot be isolated or solved, contact your technical support representative for assistance.
Timer mismatch
1. Use the show decnet interface exec command on all routers in the network. Verify that the values configured for hello timers and routing update timers are consistent among all routers in the network.
The following is example output from the show decnet interface command:
C4500#show decnet interface[...]Ethernet0 is up, line protocol is up, encapsulation is ARPAInterface cost is 50, priority is 64, DECnet network: 0We are the designated routerSending HELLOs every 15 seconds, routing updates 40 seconds[...]2. If timer values are inconsistent, bring routers into conformance using the decnet hello-timer and the decnet routing-timer interface configuration commands. The hello timer can be restored to its default, 15 seconds, by using the no form of the command.
Media problem
1. Use the show interfaces exec command and look for CRCs1 in the output.
2. If there are CRCs, there is probably a media problem. Refer to the media troubleshooting chapter that covers the media type used in your network.
Input and Output queue drops
1. Use the show interfaces exec command to check the input and output queues. Look for drops. Each number is followed by a slash, the maximum size of the queue, and the number of packets dropped because the queue is full.
2. If drops are occurring, contact your technical support representative for assistance.
1 CRC = cyclic redundancy checks