|
|
This chapter presents protocol-related troubleshooting information for DECnet Phase IV connectivity problems. This chapter consists of the following sections:
The symptom modules consist of the following sections:
Many DECnet internetworks continue to employ DEC's proprietary Phase IV network architecture. This scenario explores some internetworking problems unique to DECnet Phase IV. Figure 7-1 is a network map for this scenario and shows the network addresses of relevant end systems and routing nodes.
Assume that the following symptoms have been reported for this DECnet Phase IV network:
The relevant elements of the internetworking environment shown in Figure 7-1 can be summarized as follows:
The following problems are likely candidates for the first symptom (VAX-21 and VAX-31 cannot communicate with VAX-42):
The following problems are likely candidates for the second symptom (no connectivity to or from VAX-12 and VAX-15 in DECnet area 6):
The following problems are likely candidates for the third symptom (R&D, Test Engineering, and Finance nodes cannot communicate to any nodes in Product Marketing):
After you identify a list of possible problems, you can analyze each potential cause. Use your judgment and experience to determine where to start the diagnosis process. Notice that for these symptoms, some of the possible problems overlap. The following discussion considers the problems listed and illustrates resolution of discovered problems. Where possible, overlapping problems are addressed for all symptoms.
The first diagnostic activity to perform before attacking specific problems is to identify what connectivity is available on the network, as well as what is not.
Assume that the following connectivity is verified using set host connection commands from various (known operational) VAX hosts on the network:
After you identify working and broken connections, determine whether routers in the path of connection problems are enabled to support the routed or bridged protocols. Inspect the configuration listings for each of the routers as follows:
Step 1 Use the write terminal or show decnet interface EXEC commands to determine whether the configuration includes the decnet routing decnet-address global configuration command, as well as any decnet cost cost-value interface configuration commands for interfaces intended to route DECnet traffic.
Step 2 Because LAT is being bridged in this internetwork, review the configurations for appropriate bridging configuration commands, including the bridge group protocol global configuration command and the bridge-group group interface configuration command.
In this case, assume that these routers have been properly configured to support DECnet routing and to bridge LAT as needed.
Next, determine whether any access lists have been incorrectly applied or configured.
Step 1 Remove any access list specifications on all relevant interfaces.
Step 2 See whether traffic can get through by testing the connection from any clients to the target server.
Step 3 If connections now work, a misconfigured access list needs modification. If connectivity is not restored, access lists are not necessarily the problem. However, it is possible that access lists are improperly implemented, but masked by another problem. You may have to return to this step if, after connectivity is restored, connections are again lost when you reinstall access lists.
Step 4 If access lists are known to be the problem, isolate the location of the bad access list specification by applying one access list statement at a time until you can no longer create connections. Make sure that access lists are applied to the correct interface.
For the purposes of this scenario, assume that no access lists are used.
If a DECnet area is not contiguous (parts of one area are separated by another area), it is "partitioned," and nodes in the separate areas cannot communicate with each other. Use the following steps to determine whether areas are contiguous.
Step 1 Review the topology for any discontiguous areas.
Step 2 If any partitioned areas exist, eliminate them by reconfiguring the physical network or reassigning network area addresses so that all the Level 2 areas are contiguous.
For the purposes of this implementation, assume that there are no partitioned areas.
If a Level 2 DECnet router does not exist for a given area, the effect is similar to having a partitioned area. All traffic from the isolated area (that is, the area for which there is no Level 2 router) is ignored by all network devices that are not in the same area. This particular problem is suspected because there is no connectivity to or from nodes in DECnet area 6, as shown in Figure 7-2.
The following steps illustrate how to identify and remedy this problem:
Step 1 Use the show decnet route command at Router-R1 to determine whether a Level 2 router exists for DECnet area 6 in the route table. Figure 7-3 presents the output of the show decnet route command, which shows that there is not a Level 2 router for area 6.
Step 2 Because a Level 2 router is required to allow area 6 nodes to communicate with devices in other areas (even devices on the same physical cable), you must include an area 6 Level 2 routing node on the same cable with area 6 nodes.
You can set up one of the VAX hosts (such as DECnet node 6.101, VAX-12) as a Level 2 routing node, or you can add another router to the LAN segment as the Level 2 router for area 6.
Assume that after VAX-12 is reconfigured as a Level 2 router, area 6 nodes can communicate with nodes in other areas. However, VAX-31 still cannot communicate with VAX-42, and nodes in R&D still cannot communicate with nodes in Product Marketing. More troubleshooting remains to be done.
Depending on the situation, connectivity loss can result from misconfigured values for a variety of DECnet parameter settings on a router. If the cost of a path to a node, the number of hops to a node, the cost to an area, or the hops to an area exceed the configured values for a given router, connectivity to the remote node will be blocked. Troubleshoot this problem as follows:
Step 1 Use the show decnet interface command to determine whether the various maximum parameter values are set (cost, hops, area cost, and area hops).
Step 2 If any of these values are set, compare the configured value with the value indicated in the DECnet routing table (obtained with the show decnet route command).
Step 3 If any of the actual values exceed the configured values, change the configuration of the router accordingly (with the decnet max-cost, decnet area-max-cost, decnet max-hops, and decnet area-max-hops commands).
For this scenario, assume that none of these values are explicitly configured, which means that the default values are in effect. (The default values are the maximum possible values for DECnet.)
One symptom cited at the beginning of this scenario is that VAX-31 cannot communicate with VAX-42. (See Figure 7-4.) However, VAX-31 can communicate with VAX-43. This situation indicates that some DECnet traffic is passing between Test Engineering and Finance through Router-R2 and Router-R3.
One problem that can cause this symptom is an out-of-range DECnet node address. The easiest solution is to make sure that the router can accommodate the maximum allowable number of addresses (1023), as follows:
Step 1 Use the show decnet interface command at Router-R2 to determine the maximum address for the router. (See Figure 7-5.)
Step 2 Reconfigure Router-R2 with a maximum address value of 1023 using the decnet max-address global configuration command.
Assume that when this change is made, connectivity is restored between VAX-31 and VAX-42. However, the hosts and users in R&D and Product Marketing still are unable to communicate.
For this scenario, remember that VAX-22, VAX-42, VAX-1, VAX-2, VAX-31, and VAX-21 are all able to communicate with each other over the router links (Router-R1, Router-R2, and Router-R3). However, none of these hosts can communicate with VAX-14 or VAX-11. These facts point to a problem between Router-R3 and Router-R4.
In prior diagnostic steps, the following possible problems were eliminated:
One problem remains to be diagnosed: a possible configuration problem associated with DEC Token Ring implementations and differing router software versions.
The method of DECnet encapsulation over Token Ring differs between software releases. In particular, software prior to Software Release 9.1 uses an encapsulation method that does not interoperate with non-Cisco DECnet Token Ring nodes. Cisco routers that use Software Release 9.1 and later are, by default, configured to interoperate with non-Cisco nodes.
Assume that Router-R4 is running Software Release 9.1, while the other routers are running Software Release 9.0. In this situation, all 9.1 routers must be set to support the "pre-DEC" option in the decnet encapsulation interface configuration command. Figure 7-6 illustrates this problem and its effects on connectivity.
Diagnose this problem as follows:
Step 1 Use the show version EXEC command on all Token Ring-attached routers in the path where connectivity is blocked. Check the software version string for the release number.
Step 2 Look for routers that have Software Release 9.1 (and later) and earlier releases. If both are found, the DECnet encapsulation type being used must be reconciled for all Token Ring-attached routers.
Step 3 All-Cisco internetwork only--Use the write terminal privileged EXEC command on each of the routers running Software Release 9.1 or later. Look for a decnet encapsulation interface configuration command. If it is not present (and if all routers in the network are Cisco routers), add the decnet encapsulation pre-dec command. As an alternative, you can upgrade routers running a software release prior to Software Release 9.1 to Software Release 9.1 or later.
Interoperation internetwork--If you must support interoperation between Cisco routers and non-Cisco devices over Token Ring, upgrade the software versions on routers running a software release prior to Software Release 9.1 or later.
When the decnet encapsulation pre-dec command is configured for Router-R4, connectivity between nodes in R&D and Product Marketing is reestablished and all symptoms for this scenario are eliminated.
This scenario focused on diagnosing blocked connectivity in DECnet internetworks. Three problems were discovered and resolved:
Figure 7-7 illustrates a complete configuration listing for Router-R4 as discussed in this scenario. In this configuration, the Token Ring encapsulation is set to the pre-dec option. Also note that bridging is configured on the Ethernet interfaces to support all nonroutable protocols (such as DEC Maintenance Operation Protocol [MOP], LAT, Local Area VAX Cluster [LAVC], and Local Area Disk Services [LAD]). This configuration also includes the change to increase the DECnet maximum address to 1023.
In addition to the diagnostic tools available with 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 loosely outline the basic tasks required to enable event logging on a VMS system:
Step 1 Determine whether the Operator Communication Manager (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 Network Control Protocol (NCP) to enable event logging:
MCR NCP
SET logging MONITOR KNOWN Events
DEFINE logging MONITOR KNOWN Events
SET logging MONITOR STATE ON
DEFINE logging MONITOR STATE ON
Step 4 Exit 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.)
The symptom modules in this section pertain to DECnet internetwork problems and cover the following topics:
Symptom: DECnet nodes are unable to communicate when attempting to make connections over routers. This module focuses on possible causes related to router configuration. The next module, "Connection Attempts to DEC Hosts Fail over Routers (End Nodes)," addresses end node issues. Table 7-1 outlines possible causes and suggested actions when connection attempts to DEC hosts fail due to router configuration problems.
Symptom: Whenever a user attempts to connect to a DEC host over a router, the connection attempt fails. The previous module, "Connection Attempts to DEC Hosts Fail over Routers (Router Configuration)," focuses on issues relating to router configuration and implementation. This module focuses on possible causes associated with end nodes. Table 7-2 outlines possible causes and suggested actions when connection attempts to DEC hosts fail due to end node problems.
Symptom: When end nodes are unable to see a designated router, they cannot access any nodes that are on different LANs. Other nodes connected to the same LAN are accessible. Table 7-3 outlines possible causes and suggested actions when end nodes cannot find a designated router.
Symptom: If your network requires a specific router to be identified as 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 7-4 outlines possible causes and suggested actions when routers and end nodes see unexpected or incorrect designated routers.
Symptom: Connections sometimes drop unexpectedly, or hosts are sometimes inaccessible when connections are attempted over a router. Table 7-5 outlines possible causes and suggested actions for intermittent DECnet host connectivity over a router.
| Possible Causes | Suggested Actions |
|---|---|
| Misconfigured router (timers improperly configured) | Step 1 Use the show decnet interface EXEC command to verify that hello timers and routing update timers are consistent among all routers in the network.
Step 2 Use the decnet hello-timer and decnet routing-timer interface configuration commands to make any necessary configuration changes. |
| Disabled serial link or network media | Step 1 Refer to the discussion of media problems in Chapter 2, "Troubleshooting Router Startup Problems," for a general discussion of media problems.
Step 2 Refer to Chapter 3, "Troubleshooting Serial Line Problems," for procedures that isolate serial interconnection problems. |
Symptom: Router will not establish adjacency with any other routers known to be on the same LAN. Table 7-6 outlines possible causes and suggested actions when a router cannot establish adjacency with another router on the same LAN.
Symptom: Phase IV DECnet nodes are able to communicate with each other within a Phase IV area, but cannot access Phase IV nodes on the other side of a Phase V DECnet backbone. Table 7-7 outlines possible causes and suggested actions when there is no Phase IV connectivity over a Phase V backbone.
| Possible Causes | Suggested Actions |
|---|---|
| Misconfigured router (area addresses) | Step 1 Enable the debug clns packet privileged EXEC command to determine whether packets are being converted and sent out to DECnet Phase V.
Step 2 Use the write terminal privileged EXEC command to verify that DECnet area address (specified by the decnet routing global configuration command) agrees with the CLNS area address (specified by the network router configuration command). (These addresses can be misconfigured easily. The area address for DECnet is specified in decimal, while the area address for CLNS is specified in hexadecimal.) Step 3 If the area addresses do not agree, modify them as necessary. |
| Misconfigured router (ISO CLNS or DECnet not enabled on relevant interfaces) | Step 1 Use the write terminal command to verify that DECnet and ISO CLNS are enabled on all interfaces where conversion will occur.
Step 2 Enable routing on relevant interfaces as necessary. (For DECnet, use the decnet cost interface configuration command; for ISO CLNS, use one of the valid variations of the clns router interface configuration commands.) |
Symptom: When a node requests downline load services from a Maintenance Operation Protocol (MOP) server, a display similar to the following appears and repeats on the DEC system console:
%%%%%%%%%%% OPCOM 30-JUN-1993 12:55:08.65 %%%%%%%%%%%% Message from user DECNET on Wheel DECnet event 0.7, aborted service request From NODE 2.1 (Wheel), 30-JUN-1993 12:55:08.65 Circuit UNA-1, Line open error
The DEC node is unable to obtain its downline load from the MOP server. This symptom is commonly encountered by DEC terminal servers, MUX servers, and satellite nodes. Table 7-8 outlines a possible cause and suggested actions when service requests are aborted.
Symptom: The following output appears repeatedly on the DEC system console:
%%%%%%%%%%% OPCOM 30-JUN-1993 1:25:07.45 %%%%%%%%%%%% Message from user DECNET on The Bay DECnet event 4.16, adjacency rejected From NODE 12.1 (The Bay), 30-JUN-1993 1:25:07.45 Circuit UNA-0, Adjacent node = 1.101 (Vax1) %%%%%%%%%%% OPCOM 30-JUN-1993 1:25:07.46 %%%%%%%%%%%% Message from user DECNET on The Bay DECnet event 4.15, adjacency up From NODE 12.1 (The Bay), 30-JUN-1993 1:25:07.46 Circuit UNA-0, Adjacent node = 1.12 (Vax2)
In this example, the routers are constantly being added and removed from the routing table. Table 7-9 outlines possible causes and suggested actions when routing node adjacencies toggle up and down.
| Possible Causes | Suggested Actions |
|---|---|
| Hardware problem with routing node is causing a conflict between the designated router and another routing node | Step 1 At the DEC system console, look for OPCOM message pairs that indicate DECnet events 4.16 (adjacency rejected) and 4.15 (adjacency up) for specific routing nodes.
Step 2 Find the routing node or nodes that are causing the adjacency to toggle. Step 3 Troubleshoot the Ethernet cable or network interface card on the suspect nodes. (For details about isolating router hardware problems, refer to the hardware troubleshooting information in the "Troubleshooting Serial Line Problems" chapter.) |
| Total number of routing nodes in the network is more than 32 | Step 1 Enable debug decnet routing to determine whether the adjacency is being rejected.
Step 2 If the adjacency is being rejected, reduce the number of adjacent routers. |
Symptom: End nodes attached to a Token Ring segment are unable to communicate with hosts on the other side of a router. These end nodes are PCs running Pathworks 4.1.a. The hosts on the other side of the router are Novell-based servers. Table 7-10 outlines a possible cause and suggested actions when a Phase IV Prime host cannot communicate over a router.
|
|