|
|
This chapter presents protocol-related troubleshooting information for Xerox Network Systems (XNS) connectivity problems and consists of the following sections:
The symptom modules consist of the following sections:
With the emergence of XNS as an important PC-based network operating environment, network administrators have had increasing requirements to interconnect and segment PC LANs running the XNS networking protocol. This scenario focuses on a variety of problems that can impair server access over a routed internetwork.
Figure 13-1 is a map of the XNS internetwork discussed in this case. It illustrates an interconnection between two sites over an arbitrary serial network. The symptom encountered in this scenario is that Client-A cannot access Server-1 and Server-2 on the other side of the serial link. However, Client-A can access Server-3 on the local wire.
Because no connections can be made over the serial link, it initially appears that there is a problem with traffic getting through the routers.
The relevant elements of the internetworking environment shown in Figure 13-1 can be summarized as follows:
Given the situation, several problems could explain connectivity symptoms.
The following problems are likely candidates for the first symptom. (Client-A cannot access services on Server-1 and Server-2.)
This list is loosely ordered according to a combination of two criteria: ease of problem determination and likelihood of being the actual problem.
In general, it is useful to eliminate the most likely problems first and then to tackle the more complex problems as necessary. The problem-solving process that follows illustrates this strategy.
After you determine a possible problem list, you must analyze each potential cause. The following discussion considers the problems listed and illustrates the resolution of discovered problems.
The first step is to determine whether clients are physically attached to the network, as follows:
Step 1 Visually inspect the physical attachment of each client and attempt to connect to a local server. If a connection can be established, the client obviously is attached.
Step 2 If a connection cannot be established to a local server (either one does not exist or the connection attempt fails), use a protocol analyzer to determine whether clients are sending any packets. Look for packets with the hardware address of each client as the source address.
Step 3 As an alternative, use the debug xns packet privileged EXEC command on the locally connected router (in this case Router-D) and look for each client's source address. If packets appear that include the hardware address of the respective client as the source address, the client is active on the network, and connectivity to Router-D is functional.
In order to use debug xns packet, you must disable fast switching. (Use the no xns route-cache interface configuration command on Ethernet interface E2.)
In this case, assume that connectivity is verified up to Router-D from Client-A.
The next step is to determine whether the remote servers are attached to their Ethernet segments. This process is very similar to determining whether the clients are attached to the Downtown segment.
Step 1 As in the prior procedure, start by visually inspecting the attachment of the servers to their Network.
Step 2 Using a protocol analyzer, determine whether the servers (in this case, Server-1 and Server-2) are sending any packets on their local networks. Look for packets with the hardware address of each server as the source address.
In this case, assume that connectivity is verified up to Router-M from Server-1.
Use the write terminal privileged EXEC command to determine whether XNS routing is enabled. Use the xns routing global configuration command if it is not. Use the show protocols EXEC command to determine what protocols are running on which interfaces.
Use the write terminal privileged EXEC command to determine whether the network number matches the client or the server network number. Use the xns network interface configuration command to change or assign the proper network number to the interface.
In the process of eliminating the preceding problems, it is highly likely that the status of each router interface has been verified. You can further confirm the status of the router interfaces using the following procedure:
Step 1 Issue the show xns interface EXEC command on each router. The interfaces should indicate that the interface and line protocol are up. The show xns interface command displays additional information about the status of an interface.
Step 2 You also can ping between the routers to confirm that the interfaces are operational.
Again, for the purposes of this scenario, assume that all of the interfaces are functional.
Access list problems are commonly the cause of connectivity problems. For details concerning access list issues, refer to Table 13-1 in the "Clients Cannot Communicate with XNS Servers over Routers" symptom module later in this chapter.
For the purposes of this scenario, assume that the write terminal privileged EXEC command output for both Router-D and Router-M indicates that there are no relevant access list specifications.
MAC addresses for XNS configurations are obtained in one of two ways: either from the router hardware address embedded in the system firmware or by random assignment (when the system software initializes before the interface is initialized). In some rare cases, the randomly generated MAC address for different routers will be the same. If these numbers are not unique, and the routers are on the same internetwork, communication will not occur. If Router-M and Router-D have the same MAC address, no traffic will traverse the serial link.
Use the following procedure to check for nonunique MAC addresses:
Step 1 Use the write terminal privileged EXEC command to examine the current configuration of each router in the path (Router-D and Router-M).
Step 2 Check the hardware address specified in the xns routing global configuration command. If this system-generated number matches for both routers, reinitialize one of the routers and see if connectivity over the link is reestablished. To reinitialize a router, you may need to turn XNS routing off then turn it back on.
Step 3 Test for connectivity between clients and servers.
Step 4 If connectivity is still blocked, reexamine the configuration of the routers.
Step 5 If the routers still have matching MAC addresses, use the show controllers interface-type EXEC command to obtain an actual MAC address from each router.
Step 6 Use the xns routing global configuration command to enter the selected MAC address (for example, xns routing 00aa.54f1.003e).
In general, this problem occurs more frequently in Token Ring implementations. For the purposes of this scenario, assume that the MAC addresses are different.
Next, look for a missing or misconfigured xns forward-protocol global configuration command, as follows:
Step 1 To diagnose this configuration problem, use the EXEC write terminal privileged EXEC command. In the output, look for the global command xns forward-protocol. This command must include the proper type number.
Step 2 To discover the type number, use the EXEC debug xns packet command or use a protocol analyzer to capture the trace.
Assume for the purposes of this scenario that the xns forward-protocol command is properly configured. Unfortunately, connectivity to the remote hosts from Client-A is still blocked when test connections are attempted.
Next, look for a missing or misconfigured XNS helper address specification. On each of the routers, issue the write terminal EXEC command to look for xns helper-address interface configuration command specifications. The xns helper-address command must include either an all nets specification (-1.ffff.ffff.ffff) or directed broadcast specification (20.ffff.ffff.ffff).
If the all nets specification is used, it must be specified on Router-M (serial interface S0) and Router-D (Ethernet interface E2). Figure 13-2 illustrates the flow of broadcast traffic from clients and the application of the all nets broadcast specification. If a directed broadcast specification is used, it is only required on Router-D (Ethernet interface E2).
Assume that the helper address is not included in the original configuration and is added as a correction. This restores connectivity between Client-A and the remote hosts.
This scenario focused on diagnosing blocked connectivity in XNS internetworks. The problem that was discovered was that the helper address specification was not present in the configuration. This was resolved with the addition of a directed-broadcast helper address which allowed the routers to forward XNS broadcast packets.
Figure 13-3 and Figure 13-4 provide representative configuration listings for Router-M and Router-D as discussed in this scenario. These configurations illustrate the configuration commands required to interconnect the two Ethernet segments over the T1 line.
The symptom modules in this section pertain to XNS internetwork problems. Specific XNS connectivity symptoms are discussed in the following sections:
Symptom: Clients might not be able to connect to servers on their directly connected networks. In either case, no connections can be made to servers on the other side of the router. Table 13-1 outlines possible causes and suggested actions when clients cannot communicate with XNS servers over routers.
| Possible Causes | Suggested Actions |
|---|---|
| Clients or servers are not attached to network | Step 1 Connect both clients and servers to the same network and verify that they can communicate.
Step 2 If they cannot communicate, check the configuration of the client and the server. For troubleshooting information, refer to the software documentation for the host. Step 3 Attach a network analyzer to the network to which the clients and servers are temporarily connected. Look for the source addresses of both. Step 4 If you find the source addresses, the end stations are operating properly. If you do not find their addresses, check the configuration of the clients and servers (consult your client and server documentation for more information). |
| Router interface is not functioning | Step 1 Use the show interfaces EXEC command to check the status of the router.
Step 2 If the interface is administratively down, specify the no shutdown interface configuration command on the interface. Step 3 If the interface or line protocol is down, check cable connections from the router. If necessary, replace the cable. Step 4 If, after replacing the cable, the show interfaces EXEC command indicates that the interface and line protocol are not up, contact your router technical support representative. |
| Router network number specification is misconfigured for XNS server, causing problems for RIP | Step 1 Use the write terminal privileged EXEC command to verify that XNS routing is enabled. If not, add the xns routing router configuration command and related commands as necessary.
Step 2 Get the network number from the target network server. Step 3 Use the write terminal privileged EXEC command or show xns interface EXEC command to obtain the network number specified on the server side of the router. Step 4 Compare the network numbers. If they do not match, reconfigure the router with the correct network number. Step 5 If the network numbers match, check the router interface on the client side and make sure that the assigned network number is unique with respect to all network numbers in your XNS internetwork. |
| Misconfigured access list | Step 1 Remove any xns access-group interface configuration command specifications on all relevant interfaces.
Step 2 See whether traffic can get through by testing the connectivity of the client to the target server. If the connection now works, the access list needs modification. Step 3 To isolate the location of the bad access list specification, apply one access list statement at a time until you can no longer create connections. Step 4 Make sure that access lists are applied to the correct interface. Normally, filters are applied to outgoing interfaces. |
| Backdoor bridge between segments | Step 1 Use the show xns traffic EXEC command to determine whether the bad hop count field is incrementing.
Step 2 If this counter is increasing, use a network analyzer to look for packet loops on suspect segments. Look for routing updates. If a backdoor bridge exists, you are likely to see hop counts that increment up to 15; the route will disappear and can reappear unpredictably. Step 3 Use a protocol analyzer to examine the traffic on each segment. Look for known remote network numbers that show up on the local network. That is, look for packets from a remote network whose source address is not the source address of the router. Step 4 Use a fanout or similar device to isolate the local Ethernet into smaller segments. Step 5 The back door is located on the segment on which a packet from a remote network appears whose source address is not the source address of the router. |
| Nonfunctional Fiber Distributed Data Interface (FDDI) ring | Step 1 Use the show interfaces fddi EXEC command to determine the status of the interface.
Step 2 If show interfaces fddi EXEC command indicates that the interface and line protocol are up, use the ping xns EXEC command to test connectivity between routers. Step 3 If the interface and line protocol are up, make sure the MAC addresses of upstream and downstream neighbors are as expected. If all zeros appear in either of the address fields for these neighbors, a physical connection problem is likely. Step 4 In this case (or if status line does not indicate that the interface and line protocol are up), check patch-panel connections. Use an optical time domain reflectometer (TDR) or light meter to check connectivity between routers. Ensure that signal strength is within specification. |
| Nonfunctional serial link | Step 1 Use the show interfaces serial EXEC command to determine the status of the interface.
Step 2 If the show interfaces serial EXEC command indicates that the interface and line protocol are up, use the ping xns command to test connectivity between routers. Step 3 If the routers do not respond to the ping test, follow the serial line troubleshooting techniques described in the "Troubleshooting Serial Line Problems" chapter. |
| Nonfunctional Ethernet backbone | Step 1 Use the show interfaces ethernet EXEC command to determine the status of the interface.
Step 2 If the status line does not indicate that the interface and line protocol are up, check the physical attachment of the router to the Ethernet backbone. Step 3 If the show interfaces ethernet EXEC command indicates that the interface and line protocol are up, use the ping xns command to test connectivity between routers. Step 4 Obtain analyzer traces and look for packets from target servers, clients, and routers. Step 5 Any known nodes that do not appear as expected are suspects for being problem nodes. Locate the node and determine whether the node and its cables are functional. If not, replace or reconfigure the node and its cables as needed. |
| Nonfunctional Token Ring backbone | Step 1 Use the show interfaces token EXEC command to determine the status of the interface.
Step 2 If the status line indicates that the interface and line protocol are not up, check the cable from the router to the Multistation Access Unit. Make sure that the cable is good; if necessary, replace the cable. Step 3 If the show interfaces token EXEC command indicates that the interface and line protocol are up, use the ping xns EXEC command to test connectivity between routers. Step 4 If the remote router does not respond, check the ring specification on all nodes that are attached to the Token Ring backbone. The ring speed for all nodes must be the same. Step 5 If necessary, modify ring speed specifications for clients, servers, and routers. Step 6 On routers that support setting the ring speed in software, use the ring-speed interface configuration command. On modular router platforms, change jumpers as needed. For more information about ring speed specification, refer to the hardware installation and maintenance documentation for your system. |
Symptom: Clients are unable to get response from servers using XNS broadcast when they attempt to connect over a router. Table 13-2 outlines possible causes and suggested actions when XNS broadcast packets cannot get through a router.
| Possible Causes | Suggested Actions |
|---|---|
| Missing xns helper-address interface configuration command | Step 1 Enable the debug xns packet privileged EXEC command and look for XNS packets that have an unknown type xx specification.
Step 2 Use the write terminal privileged EXEC command to verify that the xns helper-address interface configuration command is configured for the incoming interface (for XNS broadcast traffic from stations). Step 3 If the xns helper-address command is not present, add it as appropriate. Depending on the network configuration, the specification of the helper address may differ. For more information, refer to the section "Helper Address Specification Hints" later in this chapter and to the Router Products Configuration Guide and Router Products Command Reference publications. |
| Misconfigured xns helper-address specification | Step 1 Check the router interface configuration on the client side for the xns helper-address interface configuration command.
Step 2 Make sure that the MAC address field specified in this command is a type of broadcast. Example of an all nets broadcast: interface ethernet 0
xns helper-address -1.ffff.ffff.ffff
Example of a directed broadcast: interface ethernet 1
xns helper-address 40.ffff.ffff.ffff
|
|
Missing xns forward-protocol router configuration command | Step 1 Enable the debug xns packet privileged EXEC command and look for XNS packets with the unknown type xx.
Step 2 Use the write terminal privileged EXEC command to look in the router configuration for the xns forward-protocol global configuration command. Step 3 If the command is not present, add it as appropriate. |
| Misconfigured access list | Step 1 Refer to Table 13-1 for suggested actions. |
The following illustrations and accompanying text discuss some of the implications of XNS helper address assignment, some potential pitfalls, and general behavioral characteristics. The Router Products Command Reference and Router Products Configuration Guide publications provide details about configuration commands associated with helper address assignment.
Consider the simple configuration illustrated in Figure 13-5. In this case, Router-A separates two Ethernet segments (Ethernet-20 and Ethernet-10). Clients on Ethernet-20 must be able to access services from Server-1 and Server-2 on Ethernet-10.
The helper address specification is as follows:
interface ethernet 0 xns network 20 xns helper-address -1.ffff.ffff.ffff
Here, -1 is used to specify flooding to all nets.
As an alternative, you can specify a network number. In this case, specify XNS network 10 as follows:
interface ethernet 0 xns network 20 xns helper-address 10.ffff.ffff.ffff
The network configuration illustrated in Figure 13-6 is similar to that illustrated in Figure 13-5, except that Ethernet-20 and Ethernet-10 are separated by a serial network and two routers (Router-A and Router-B). As before, clients on Ethernet-20 must be able to access services from Server-1 and Server-2 on Ethernet-10.
Assuming the use of the all nets broadcast address, the helper address specifications for the two routers would be as follows:
!Router-A helper address specification: ! interface ethernet 0 xns network 20 xns helper-address -1.ffff.ffff.ffff !Router-B helper address specification: ! interface serial 0 xns network 30 xns helper-address -1.ffff.ffff.ffff
As in the prior example, -1 is used to specify flooding to all nets. Note that the helper address specification is required on Router-B because of the use of the all nets (-1) network specification (on Router-A). You can specify a specific network number as an alternative. In this case, you would specify XNS network 10 on Router-A only as follows:
!Router-A helper address specification: ! interface ethernet 0 xns network 20 xns helper-address 10.ffff.ffff.ffff
The key difference between the following example and prior examples is that Server-1 and Server-2 are now on separate Ethernet segments, and clients access Server-1 and Server-2 via different routers (Router-B and Router-C). Refer to Figure 13-7.
The all nets broadcast configurations for the routers follow:
!Router-A helper address specification: ! interface ethernet 0 xns network 20 xns helper-address -1.ffff.ffff.ffff !Router-B helper address specification: ! interface serial 0 xns network 30 xns helper-address -1.ffff.ffff.ffff !Router-C helper address specification: ! interface serial 2 xns network 50 xns helper-address -1.ffff.ffff.ffff
Note that the helper address specification is required on both Router-B and Router-C because of the use of the all nets (-1) network specification on Router-A.
Use care in assigning broadcast-type helper addresses when XNS networks are interconnected over multiple routers and when clients are using XNS broadcast. Although traffic will not permanently loop, local client queries can leak out through a router, resulting in excess traffic. Consider the situation illustrated in Figure 13-8.
In this example, helper addresses are assigned to the Ethernet interfaces on Router-A and Router-B. The interface configurations might be as follows:
!Router-B helper address specifications: ! interface ethernet 0 xns network 10 xns helper-address -1.ffff.ffff.ffff ! interface ethernet 1 xns network 20 xns helper-address -1.ffff.ffff.ffff !Router-A helper address specifications: ! interface ethernet 2 xns network 10 xns helper-address -1.ffff.ffff.ffff ! interface ethernet 3 xns network 20 xns helper-address -1.ffff.ffff.ffff
Consider what happens to Packet-Y from Client-A that is destined for Server-Y on XNS network 20. Assume that no access lists are in place and that Router-B is the first to get a query from Client-A. Because the query is intended for an offnet host, Router-B broadcasts the query out of Ethernet interface E1 and onto XNS network 20. The broadcast finds its way to Server-Y (causing a response, assuming that Server-Y is operational) and also lands at Ethernet interface E3 on Router-A. There, the packet is dropped. This is the expected behavior.
Now consider Packet-X, a client query from Client-B that is also intended for Server-Y. In this case, the broadcast packet finds its server on the same wire to which it is connected. However, Router-A forwards this broadcast because the source address is local--which puts the locally targeted packet onto XNS network 10. This packet will continue to propagate outward through the network until the internetwork terminates (or until the packet has traversed 15 routers), but it will not leak back into XNS network 20 because the routers see that the source network in the packet is 20. In no case is the packet sent back along the path to its source network. In the preceding example, the packet would be dropped when it reaches Ethernet interface E0 on Router-B.
This situation is a type of partial loop. True routing loops are prevented, but some excess traffic is created.
Symptom: Local servers are responding, but servers on the other side of a packet-switched network (PSN) that interconnects routers do not respond. A router appears to block XNS over the PSN. Table 13-3 outlines possible causes and suggested actions when clients cannot connect to a server over a PSN.
| Possible Causes | Suggested Actions |
|---|---|
| X.25 address mapping error | Step 1 Use the write terminal privileged EXEC command or the show x25 map EXEC command to examine the configuration of the router.
Step 2 Make sure that the MAC addresses and X.121 addresses specified in any x25 map xns interface configuration commands match the addresses associated with the respective destination routers. For information about address mapping, refer to the section, "Notes about PSN Address Map Specifications," later in this chapter. |
| Frame Relay address mapping error | Step 1 Use the write terminal privileged EXEC command to examine the configuration of the router.
Step 2 Make sure that the MAC addresses and DLCI addresses specified in any frame-relay map xns interface configuration commands match the addresses associated with the respective destination routers. For information about address mapping, refer to the section, "Notes about PSN Address Map Specifications," later in this chapter. |
| Misconfigured network number specification on servers or routers | Step 1 See Table 13-1 for suggested actions. |
| Encapsulation mismatch | Step 1 Use the write terminal privileged EXEC command or the show interfaces EXEC command to look for an encapsulation interface configuration command, such as encapsulation x25 or encapsulation frame-relay.
If an encapsulation command is not present, the default is High-Level Data Link (HDLC) encapsulation. Step 2 For PSN interconnections, you must explicitly specify the encapsulation type. |
When routing XNS (or any protocol) over a PSN, you must specify mapping between the protocol and the PSN addresses. Consider the two examples illustrated in Figure 13-9 and Figure 13-10. Figure 13-9 illustrates an address map specification when routing XNS over an X.25 PSN, while Figure 13-10 illustrates an address map specification when routing XNS over a Frame Relay network. Relevant configurations and a brief explanation of command variables are provided in the following discussions. For more information about address map specifications, refer to the Router Products Configuration Guide and Router Products Command Reference publications.
As illustrated in Figure 13-9, XNS-to-X.25 address map specifications would be required for both Router-A and Router-B.
The specific interface configurations are as follows:
!Router-A interface serial 0 x25 map xns 30.0800.0c00.5552 15552223334 broadcast ! Above specifies XNS-to-X.121 address map configuration for Router-A !Router-B interface serial 1 x25 map xns 30.0800.0c00.4321 15551231234 broadcast ! Above specifies XNS-to-X.121 address map configuration for Router-B
In the preceding configurations, the MAC address is obtained using the write terminal privileged EXEC command on the target router. Look for the xns routing router configuration command in the configuration listing. It is displayed with the auto-generated MAC address appended to the command. For Router-A in Figure 13-9, you would see the following listing:
xns routing 0800.0c00.4321
Figure 13-10 illustrates essentially the same interconnection arrangement as Figure 13-9, except that the PSN used is a Frame Relay network. In an analogous manner, XNS-to-Frame Relay address map specifications would be required for both Router-A and Router-B.
The specific interface configurations would be as follows:
! interface serial 0 frame-relay map xns 30.0800.0c00.5552 20 broadcast ! Above specifies XNS-to-DLCI address map configuration for Router-A interface serial 0 frame-relay map xns 30.0800.0c00.4321 30 broadcast ! Above specifies XNS-to-DLCI address map configuration for Router-B
In these example configurations, the MAC address is obtained in the same manner as described in the X.25 example: use the write terminal privileged EXEC command on the target router and look for the xns routing router configuration command in the configuration listing.
|
|