Troubleshooting XNS

Clients Cannot Connect to Servers over Router

XNS Broadcast Packets Not Forwarded by Router

Clients Cannot Connect to Server over PSN

Troubleshooting XNS

This chapter presents protocol-related troubleshooting information for Xerox Network Systems (XNS) connectivity problems. The sections in this chapter describe specific XNS symptoms, the problems that are likely to cause each symptom, and the solutions to those problems.

Clients Cannot Connect to Servers over Router

Symptom: Clients cannot make connections to XNS servers across a router. Clients might be able to connect to servers on their directly connected networks.

Table 12-1 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 12-1 : XNS: Clients Cannot Connect to Servers over Router

Possible Problem Solution

Router interface is down Step 1 Use the show interfaces EXEC command to check the status of the router interfaces.
Step 2 If the status line indicates that an interface that should be up is "administratively down," use the no shutdown interface configuration command on the interface.
Step 3 If the status line indicates that the interface or line protocol is in any other state, refer to the "Troubleshooting Hardware and Booting Problems" and "Troubleshooting LAN Media Problems" chapters.

Hardware or media problem For information on troubleshooting hardware problems, see the "Troubleshooting Hardware and Booting Problems" chapter. For information on troubleshooting media problems, see the "Troubleshooting LAN Media Problems" chapter and the "Troubleshooting Serial Line Problems" chapter.

XNS routing is not enabled on router Step 1 Use the show running-config privileged EXEC command to view the router configuration. Check to see if XNS routing is enabled on the router.
Step 2 If XNS routing is not enabled, add the xns routing router configuration command and related commands as necessary.
For more information on configuring XNS routing, see the Network Protocols Configuration Guide, Part 2.

Mismatched router network number If the network number specified on the router is different from that configured on XNS servers, RIP will not be able to forward traffic correctly.
Step 1 Check the network numbers of network servers.
Step 2 Use the show xns interface EXEC command to obtain the network number specified on the server side of the router.
Step 3 Compare the network numbers. If they do not match, reconfigure the router or the server, as appropriate, with the correct network number.
Step 4 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 the XNS internetwork.

Misconfigured access list Step 1 Use the show xns access-list privileged EXEC command on routers in the path from source to destination. This command shows whether there are access lists configured on the router.
Step 2 Disable all access lists that are configured on the router using no xns access-group commands.
Step 3 Test the connection from the client to the server to see whether connections are now possible. If the connection is successful, an access list is blocking traffic.
Step 4 To isolate the problem access list, apply one access list statement at a time until you can no longer create connections.
Step 5 When the problem list is identified, alter it so that necessary traffic is allowed to pass. Configure explicit permit statements for traffic that you want to be forwarded by the router.
Step 6 If problems persist, continue testing for problem access lists on all routers in the path from source to destination.

Backdoor bridge between segments Step 1 Use the show xns traffic EXEC command to determine whether the bad hop count field is incrementing.
C4000# show xns traffic
Rec: 3968 total, 0 format errors, 0 checksum errors, 0 bad hop count,
3968 local destination, 0 multicast
[...]

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 will probably see hop counts that increment up to 15, at which point the route will disappear. The route reappears unpredictably.
Step 3 Use a network analyzer to examine the traffic on each segment. Look for known remote network numbers that appear 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 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 a local router.

Possible Problem	Solution
Router interface is down	Step 1 Use the show interfaces EXEC command to check the status of the router interfaces. Step 2 If the status line indicates that an interface that should be up is "administratively down," use the no shutdown interface configuration command on the interface. Step 3 If the status line indicates that the interface or line protocol is in any other state, refer to the "Troubleshooting Hardware and Booting Problems" and "Troubleshooting LAN Media Problems" chapters.
Hardware or media problem	For information on troubleshooting hardware problems, see the "Troubleshooting Hardware and Booting Problems" chapter. For information on troubleshooting media problems, see the "Troubleshooting LAN Media Problems" chapter and the "Troubleshooting Serial Line Problems" chapter.
XNS routing is not enabled on router	Step 1 Use the show running-config privileged EXEC command to view the router configuration. Check to see if XNS routing is enabled on the router. Step 2 If XNS routing is not enabled, add the xns routing router configuration command and related commands as necessary. For more information on configuring XNS routing, see the Network Protocols Configuration Guide, Part 2.
Mismatched router network number	If the network number specified on the router is different from that configured on XNS servers, RIP will not be able to forward traffic correctly. Step 1 Check the network numbers of network servers. Step 2 Use the show xns interface EXEC command to obtain the network number specified on the server side of the router. Step 3 Compare the network numbers. If they do not match, reconfigure the router or the server, as appropriate, with the correct network number. Step 4 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 the XNS internetwork.
Misconfigured access list	Step 1 Use the show xns access-list privileged EXEC command on routers in the path from source to destination. This command shows whether there are access lists configured on the router. Step 2 Disable all access lists that are configured on the router using no xns access-group commands. Step 3 Test the connection from the client to the server to see whether connections are now possible. If the connection is successful, an access list is blocking traffic. Step 4 To isolate the problem access list, apply one access list statement at a time until you can no longer create connections. Step 5 When the problem list is identified, alter it so that necessary traffic is allowed to pass. Configure explicit permit statements for traffic that you want to be forwarded by the router. Step 6 If problems persist, continue testing for problem access lists on all routers in the path from source to destination.
Backdoor bridge between segments	Step 1 Use the show xns traffic EXEC command to determine whether the bad hop count field is incrementing. `C4000#` `show xns traffic` `Rec: 3968 total, 0 format errors, 0 checksum errors, 0 bad hop count,` `3968 local destination, 0 multicast` `[...]` 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 will probably see hop counts that increment up to 15, at which point the route will disappear. The route reappears unpredictably. Step 3 Use a network analyzer to examine the traffic on each segment. Look for known remote network numbers that appear 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 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 a local router.

XNS Broadcast Packets Not Forwarded by Router

Symptom: XNS servers do not respond to broadcast requests from clients.

Table 12-2 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 12-2 : XNS: XNS Broadcast Packets Not Forwarded by Router

Possible Problem Solution

Missing or misconfigured xns helper-address command Step 1 Enable the debug xns packet privileged EXEC command and check the output for XNS packets that have an unknown type xx specification.
Step 2 Use the show running-config privileged EXEC command to view the router configuration. Check the configuration of the client-side interface to see if an xns helper-address interface configuration command entry is present.
Step 3 If the xns helper-address command is not present, add it to the client-side interface.
Step 4 If the command is present, make sure that the MAC address specified in this command is a type of broadcast.

Following is an example of an all-nets broadcast:

interface ethernet 0

xns helper-address -1.ffff.ffff.ffff

Following is an example of a directed broadcast:

interface ethernet 1

xns helper-address 40.ffff.ffff.ffff

Depending on the network configuration, the helper address specification will differ. For more information, refer to the Cisco IOS Network Protocols Configuration Guide, Part 2 and Network Protocols Command Reference, Part 2.

Missing xns forward-protocol router configuration command Step 1 Enable the debug xns packet privileged EXEC command and check the output for XNS packets that have an unknown type xx specification.
Step 2 Use the show running-config privileged EXEC command to view the router configuration. Look for an xns forward-protocol global configuration command entry.
Step 3 If the xns forward-protocol command is not present, add it as appropriate.

Misconfigured access list Step 1 Use the show access-lists command to see if there are access lists configured on the router.
Step 2 Disable any access lists that are enabled on the router.
Step 3 Test the connection to see whether connections are now possible. If the connection is successful, an access list is blocking traffic.
Step 4 Enable access lists one at a time until connections are no longer possible.
Step 5 Alter the problem list so that traffic can pass. Configure explicit permit statements for traffic that you want to be forwarded by the router.
Step 6 If problems persist, continue testing for problem access lists on all routers in the path from source to destination.

Possible Problem	Solution
Missing or misconfigured xns helper-address command	Step 1 Enable the debug xns packet privileged EXEC command and check the output for XNS packets that have an unknown type xx specification. Step 2 Use the show running-config privileged EXEC command to view the router configuration. Check the configuration of the client-side interface to see if an xns helper-address interface configuration command entry is present. Step 3 If the xns helper-address command is not present, add it to the client-side interface. Step 4 If the command is present, make sure that the MAC address specified in this command is a type of broadcast. Following is an example of an all-nets broadcast: `interface ethernet 0` `xns helper-address -1.ffff.ffff.ffff` Following is an example of a directed broadcast: `interface ethernet 1` `xns helper-address 40.ffff.ffff.ffff` Depending on the network configuration, the helper address specification will differ. For more information, refer to the Cisco IOS Network Protocols Configuration Guide, Part 2 and Network Protocols Command Reference, Part 2.
Missing xns forward-protocol router configuration command	Step 1 Enable the debug xns packet privileged EXEC command and check the output for XNS packets that have an unknown type xx specification. Step 2 Use the show running-config privileged EXEC command to view the router configuration. Look for an xns forward-protocol global configuration command entry. Step 3 If the xns forward-protocol command is not present, add it as appropriate.
Misconfigured access list	Step 1 Use the show access-lists command to see if there are access lists configured on the router. Step 2 Disable any access lists that are enabled on the router. Step 3 Test the connection to see whether connections are now possible. If the connection is successful, an access list is blocking traffic. Step 4 Enable access lists one at a time until connections are no longer possible. Step 5 Alter the problem list so that traffic can pass. Configure explicit permit statements for traffic that you want to be forwarded by the router. Step 6 If problems persist, continue testing for problem access lists on all routers in the path from source to destination.

Clients Cannot Connect to Server over PSN

Symptom: Clients cannot connect to servers across a PSN. Clients can communicate with servers located on the local network.

Table 12-3 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 12-3 : XNS: Clients Cannot Connect to Server over PSN

Possible Problem Solution

Address mapping error Step 1 Use the show running-config privileged EXEC command to view the configuration of the router.
Step 2 If you are running X.25, make sure that x25 map xns interface configuration commands are properly configured. Make sure that MAC addresses and X.121 addresses are correctly specified.
Step 3 If you are running Frame Relay, make sure that frame-relay map xns interface configuration commands are properly configured. Make sure that MAC addresses and DLCIs are correctly specified.

Mismatched router network number Step 1 Check the network numbers of network servers.
Step 2 Check the network number specified on the server side of the router.
Step 3 Compare the network numbers. If they do not match, reconfigure the router or servers as appropriate with the correct network number.
Step 4 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 the XNS internetwork.

Encapsulation mismatch Step 1 Use the show interfaces EXEC command to determine the encapsulation type being used (such as encapsulation x25).
Step 2 If an encapsulation command is not present, the default is HDLC¹ encapsulation. For PSN interconnection, you must explicitly specify an encapsulation type.

¹ HDLC=High-Level Data Link Control

Possible Problem	Solution
Address mapping error	Step 1 Use the show running-config privileged EXEC command to view the configuration of the router. Step 2 If you are running X.25, make sure that x25 map xns interface configuration commands are properly configured. Make sure that MAC addresses and X.121 addresses are correctly specified. Step 3 If you are running Frame Relay, make sure that frame-relay map xns interface configuration commands are properly configured. Make sure that MAC addresses and DLCIs are correctly specified.
Mismatched router network number	Step 1 Check the network numbers of network servers. Step 2 Check the network number specified on the server side of the router. Step 3 Compare the network numbers. If they do not match, reconfigure the router or servers as appropriate with the correct network number. Step 4 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 the XNS internetwork.
Encapsulation mismatch	Step 1 Use the show interfaces EXEC command to determine the encapsulation type being used (such as encapsulation x25). Step 2 If an encapsulation command is not present, the default is HDLC¹ encapsulation. For PSN interconnection, you must explicitly specify an encapsulation type.

Table of Contents