Troubleshooting Novell IPX Connectivity

Clients Cannot Communicate with NetWare Servers over Router

Symptom: Clients might not be able to connect to servers on their directly connected networks. In either case, connections cannot be made to servers on the other side of the router. Table 10-4 outlines possible causes and suggested actions when clients cannot communicate with NetWare servers over a router.

Table 10-4 : IPX: Clients Cannot Communicate with NetWare Servers over Router

Possible Causes	Suggested Actions
A client or a server is not attached to the network	Step 1 Connect both the client and the server to the same network and verify that they can communicate with each other. Step 2 If they cannot communicate, check the configurations. For troubleshooting information, refer to the documentation provided by the manufacturer. Step 3 Attach a network analyzer to the network to which the client and server are temporarily connected. Look for the source addresses of both. Step 4 If you find the source addresses, end stations are operating properly. If you do not find the addresses, check the configuration of the clients and servers. For troubleshooting information, refer to the documentation provided by the manufacturer.
Router interface is not functioning	Step 1 Use the show interfaces EXEC command to check the operation of the router. Verify that the status line indicates that the interface and line protocol are up. Step 2 If the interface is administratively down, add the no shutdown interface configuration command to the configuration for the that interface. Step 3 If the interface or line protocol is down, check the cable connections from the router. If necessary, replace the cable. Step 4 If, after replacing the cable, the output of the show interfaces EXEC command still indicates that the interface and line protocol are down, contact your router technical support representative.
Router network number specification is misconfigured for NetWare 2.15, causing problems for Routing Information Protocol (RIP), which relies on network numbers to route traffic	Step 1 Check the router configuration to see whether Novell IPX routing is enabled. If not, add the ipx routing global 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 or the show ipx interface EXEC command to get the network number of the server as it is specified on the router. Step 4 Compare the network numbers. If they do not match, reconfigure the router with 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 Novell IPX internetwork. On the server side of the router, make sure that the network number assigned to the router interface matches the network number for the server.
Router network number specification is misconfigured for NetWare 3.11 or 4.x, causing problems for RIP, which relies on network numbers to route traffic	Step 1 Check the router configuration to see whether Novell IPX routing is enabled. If not, add the ipx routing global configuration command and related commands as necessary. Step 2 Get the external network number of the server interface that is attached to the network to which the router is also attached. Do not use the internal network number of a 3.11 server. Step 3 Use the write terminal privileged EXEC or the show ipx interface EXEC command to compare the external network number of the server with the network number specified on router. Step 4 If the network numbers do not match, reconfigure the router with correct network numbers. Step 5 If the network numbers match, check the router interface on the client side and make sure that the network number assigned is unique with respect to all of the network numbers in your Novell IPX internetwork.
NetWare 2.15 and 3.11 network number mismatch on the same network or backbone, causing problems for RIP, which relies on network numbers to route traffic	Step 1 If NetWare 2.15 servers are on the same physical cable with NetWare 3.11 servers, the network number for the connected interface of any 2.15 server and the external network number for the connected interface of any 3.11 server must match. Compare the external network numbers for the 3.11 servers with the network numbers for the 2.15 servers. Step 2 If these numbers do not match, reconfigure the servers to make them match. Refer to the server documentation for information concerning these modifications.
Misconfigured access list	Step 1 Remove ipx access-group interface configuration command specifications on all relevant interfaces. Step 2 See whether traffic can get through by testing connectivity between the client and 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 ipx traffic EXEC command to determine whether the "bad hop count" field is incrementing. Step 2 If this counter is incrementing, use a network analyzer to look for packet loops on suspect segments. Look for RIP and SAP updates. If a backdoor bridge exists, you are likely to see hop counts that increment up to 16; the route then disappears and reappears unpredictably. Step 3 Look for known remote network numbers that show up on the local network. Examine these packets, looking for packets whose source address is the MAC address of the remote node instead of the MAC address of the router. Step 4 Use a fanout to isolate the local Ethernet into smaller segments. Step 5 Examine packets on each segment. The back door is located on the segment on which a packet appears whose source address is the remote node's MAC address instead of the MAC address of the router.
Duplicate network numbers on Novell servers	Step 1 Use the show ipx servers EXEC command to look for duplicate network numbers. This command generates a list of servers by type, name, network number, MAC address, hop count, and interface. Step 2 If you see duplicate network numbers, modify server configurations to eliminate duplicate network numbers from your internetwork.
Nonfunctional FDDI ring	Step 1 Use the show interfaces fddi EXEC command to determine the status of interface. Step 2 If the show interfaces fddi EXEC command indicates that the interface and line protocol are up, use the ping ipx privileged EXEC command to test connectivity between routers. Step 3 If the interface and line protocol are up, make sure that 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 the 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 the 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 ipx privileged EXEC command to test connectivity between routers. Step 3 If routers do not respond to the ping test, refer to 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 Ethernet backbone. Step 3 If the show interfaces ethernet EXEC command indicates that the interface and line protocol are up, use the ping ipx privileged EXEC command to test connectivity between routers. Step 4 Obtain analyzer traces and look for packets from target servers, client, and routers. Step 5 Any known nodes that do not appear as expected are suspects for being problem nodes. Locate and determine whether the node and its cables are functional. If not, replace or reconfigure 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 functional; replace it if necessary. Step 3 If the show interfaces token EXEC command indicates that the interface and line protocol are up, use the ping ipx privileged EXEC command to test connectivity between routers. Step 4 If the remote router does not respond, check the ring specification on all nodes attached to the Token Ring backbone. The ring speed for all of the nodes must be the same. Step 5 If necessary, modify ring speed specifications for clients, servers, and routers. On routers that support setting the ring speed in software, use the ring-speed interface configuration command. Change jumpers as needed for modular router platforms. For more information about ring speed specification, refer to the hardware installation and maintenance manual for your system.
Mismatched Ethernet encapsulation methods	Step 1 Check the encapsulation type that is being used by clients and servers. Step 2 Compare the encapsulation types with the encapsulation type specified in the configuration of the router. By default, Cisco routers use Novell's Frame Type Ethernet_802.3 encapsulation. Cisco refers to this as "novell-ether" encapsulation.) Step 3 If servers and clients are using what Novell refers to as "Frame Type Ethernet _II," use the ipx encapsulation arpa interface configuration command to make sure that the router also uses this form. (This particular encapsulation mismatch problem also applies to DEC/VMS hosts and servers that are running Novell server software.) Step 4 If clients and servers on a particular interface are using Frame Type Ethernet_II, Ethernet_SNAP, or Ethernet_802.2 encapsulation, change the encapsulation type of the router to match. Step 5 As a last resort, disable Novell IPX routing and enable bridging. Note that Cisco routers running Software Release 9.21 and later can translate Frame Type Ethernet_802.2, Ethernet_802.3, Ethernet_II, and Ethernet_SNAP encapsulation types on the same interface or between different interfaces. Each encapsulation type requires a unique network number.

SAP Updates Not Propagated by Router

Symptom: SAP updates do not appear to be propagated by a router. Novell servers use SAP updates to broadcast the Novell services that they offer. Table 10-5 outlines possible causes and suggested actions when SAP updates are not being propagated by a router.

Table 10-5 : IPX: SAP Updates Are Not Propagated by Router

Possible Causes	Suggested Actions
Novell server is not sending SAP updates	Step 1 Use a protocol analyzer to look for SAP updates from the server. Step 2 If the server is not sending SAP updates, make sure the server is attached to the network. Step 3 In Ethernet environments, if the server is sending SAP updates, check the encapsulation type in the router configuration. The encapsulation type must match the Novell server encapsulation specification (Frame Type Ethernet_802.2, Frame Type Ethernet_802.3, Frame Type Ethernet_II or Frame Type Ethernet_SNAP). Step 4 Certain third-party NLMs are available that allow SAP updates to be disabled entirely. If you are using such software on your servers, make certain that the necessary SAP updates are being sent. Consult your third-party documentation for more information.
Ring speed specification mismatch	Step 1 Check the ring speed specifications on Novell servers and routers (4 or 16 Mbps). Step 2 If the ring speeds do not match, use the ring-speed interface configuration command to make the router configuration match server specifications.
Misconfigured access lists	Step 1 Disable any SAP-specific access lists by removing ipx input-sap-filter and ipx output-sap-filter interface configuration commands as appropriate. Step 2 Use the display servers command on the server to verify that the server is advertising services, or, if there is a Novell client on the other side of router, use the slist command on the client. Step 3 Use the debug ipx sap activity privileged EXEC command to look for server name, network number, and MAC address. If the SAP information of the Novell server is included in the updates from the router, an access list is causing SAP updates to be dropped at the router. Step 4 Revise access lists or filter statements as necessary and apply them individually to ensure that updates are being distributed appropriately.
Misconfigured network number on router or Novell server, causing problems for RIP, which relies on network numbers to route traffic	Step 1 Use the show ipx route or the show ipx servers EXEC command to determine whether there are any duplicate network numbers in the internetwork. If the routers or Novell servers have duplicate network numbers, the router might not send out SAP updates. Step 2 Check the server console for error messages. The system console log will indicate that there are misconfigured routers in the network if network numbers conflict. Step 3 If you find duplicate network numbers, modify server configurations or the ipx network interface configuration command on the router as appropriate.
Novell servers are unable to handle the rate at which routers generate SAP updates	Step 1 Compare the output of the show ipx servers EXEC command from the router with the output of the slist command from Novell servers. If the slist output for a Novell server shows only a partial listing of SAP entries, it is possible that the Novell servers are unable to handle the rate at which the router is generating SAP updates. This problem is more likely in older servers or servers with older LAN card drivers. Step 2 Use the ipx output-sap-delay interface configuration command to specify the delay between packets in a multipacket SAP update. Novell recommends a delay of 55ms. However, a delay of as little as of 5 ms may work. Use the lowest possible delay that corrects the problem.
SAP or RIP timers mismatch	Step 1 SAP and RIP timer values can be changed on servers running NetWare 4.x or later. Examine the configuration of the server and the routers to determine if the timer values are the same. Step 2 If the timer value configured on the server is more than 3 minutes greater than that configured on the router, the router will remove the server from the IPX servers table. This will result in clients being unable to see the services available on that server. Step 3 Bring the timer values within 3 minutes of each other to ensure that the router does not remove the server from its IPX servers table.
Limited-user version of NetWare software	Step 1 Check the software running on the server. If the software is a limited-user version, you must upgrade the version to support more users.
Nonunique MAC address on routers	Step 1 Use the write terminal privileged EXEC command to examine the current configuration of each router in the path. Step 2 Check the MAC address specified in the ipx routing global configuration command. Step 3 If this router-generated number matches for both routers, reinitialize one of the routers and see whether connectivity over the link is reestablished. Step 4 If the numbers still match, use the show interfaces EXEC command to get the real MAC address of one of the interfaces. Use the ipx routing command to assign the real MAC address to the router. In general, this problem is more likely to occur in Token Ring implementations. If the routers are interconnected over a serial line, no connection can be made over the serial line.

Novell NetBIOS Packets Cannot Get through Router

Symptom: Clients are unable to get response from servers running Novell NetBIOS when connections are attempted over a router. Table 10-6 outlines a possible cause and suggested actions when Novell NetBIOS packets cannot get through a router.

Table 10-6 : IPX: Novell NetBIOS Packets Cannot Get through Router

Possible Cause

Suggested Actions

Missing ipx type-20-propagation interface configuration command

Step 1 Use the debug ipx packet privileged EXEC command to look for Novell packets with an unknown specification as type 20. Step 2 Use the write terminal privileged EXEC command to check for an ipx type-20-propagation interface configuration command configured for the incoming and outgoing interface for Novell NetBIOS traffic from stations. Step 3 If the ipx type-20-propagation command is not present, add it as appropriate.

Client Cannot Access Remote Servers over Frame Relay

Symptom: In a hub-and-spoke environment, Novell clients are unable to connect to remote Novell servers across a Frame Relay network. Connections can be made to local servers. Table 10-7 describes possible causes and suggested actions when Novell clients cannot access remote servers over Frame Relay.

Table 10-7 : IPX: Novell Client Cannot Access Remote Servers over Frame Relay

Possible Causes	Suggested Action
The hub router is not forwarding Service Advertisement Protocol (SAP) packets because of the split horizon rule.	Step 1 If you are running Software Release 9.1 or earlier, use the novell sap interface configuration command to configure a static SAP at each spoke site indicating the Frame Relay interface of the hub router as the next hop. For information on the exact usage of the novell sap interface configuration command, see the "Router Products Command Reference." Step 2 If you are running Software Release 9.21 or later, configure subinterfaces on the Frame Relay interface of the hub router. Assign a subinterface to each spoke site. The hub router will treat each subinterface as a physical interface, allowing it to advertise SAPs without violating split horizon. For specific information on configuring subinterfaces, see the "Router Products Configuration Guide."
Frame Relay map statements and data link connection identifier (DLCI) assignments are misconfigured	Step 1 Examine the Frame Relay map assignments currently configured, using the show frame-relay map EXEC command. Step 2 Check each Frame Relay map statement to ensure that the DLCI assignments are correctly configured.
Novell servers are unable to handle the rate at which routers generate multi-packet SAP updates	Step 1 Compare the output of the show ipx servers EXEC command from the router with the output of the slist command from Novell servers. If the slist output for a Novell server shows a partial listing of SAP entries, it is possible that the Novell servers are unable to handle the rate at which the router is generating SAP updates. This problem is more likely in older servers or servers with older LAN card drivers. Step 2 Use the ipx output-sap-delay interface configuration command to specify the delay between packets in a multipacket SAP update. Novell recommends a delay of 55ms. However, a delay of as little as of 5 ms may work. Use the lowest possible delay that corrects the problem.
Slow serial line causes SAP updates to be dropped from the output queue of hub router	Step 1 Issue the show interfaces serial EXEC command and examine the value indicated in the output queue "drops" field. A large number of dropped packets may indicate that SAP updates are not reaching clients across the serial link. Step 2 Re-evaluate implemented SAP filtering. Eliminate the forwarding of any SAP updates that are not absolutely necessary. Use the access-list global configuration command and the ipx input-sap-filter, ipx output-sap-filter, and ipx router-sap-filter interface configuration commands, as appropriate. Step 3 Increase the available bandwidth if possible. Add a second serial line or obtain a single link with more available bandwidth. Step 4 Increase the output hold queue on the serial interface using the hold-queue length out interface configuration command. Step 5 Use the ipx output-sap-delay interface configuration command to specify the delay between packets in a multipacket SAP update. Use the lowest possible delay that corrects the problem.

Clients Cannot Connect to Server over Packet-Switched Network

Symptom: Local servers are responding, but servers on the other side of a packet-switching network that interconnects routers do not respond. A router appears to block IPX over the packet-switched network (PSN). Table 10-8 outlines possible causes and suggested actions when clients cannot connect to servers over a PSN.

Table 10-8 : IPX: Clients Cannot Connect to Server over Packet-Switched Network

Possible Cause	Suggested Actions
X.25 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 X.121 addresses specified in any x25 map ipx interface configuration commands match the addresses associated with the respective destination routers. Refer to the following section, "Notes about Packet-Switched Network Address Map Specifications," for address-mapping information.
Misconfigured network number specification on servers or routers	Step 1 See Table 10-4 for suggested actions.
Encapsulation mismatch	Step 1 Use the write terminal privileged EXEC or the show interfaces EXEC command to determine the encapsulation type being used. Step 2 Look for a relevant packet-switching encapsulation type (such as encapsulation x25). If an encapsulation command is not present, the default is High-Level Data Link Control (HDLC) encapsulation. Step 3 For PSN interconnection, you must explicitly specify an encapsulation type.

Notes about Packet-Switched Network Address Map Specifications

When routing Novell IPX (or any protocol) over a PSN, you must specify mapping between the protocol and PSN addresses. Consider the two examples illustrated in Figure 10-7 and Figure 10-8. Figure 10-7 illustrates an address map specification for routing Novell IPX over an X.25 PSN, while Figure 10-8 illustrates an address map specification for routing Novell IPX over a Frame Relay network. Relevant configurations and a brief explanation of command variables are provided in the following discussions.

Address Mapping for Novell-to-X.25 Interconnection

As illustrated in Figure 10-7, Novell-to-X.25 address map specifications are required for both Router-A and Router-B.

Figure 10-7 : Network Diagram Illustrating Novell-to-X.25 Mapping

The interface specifications are as follows:

!Router-A X.25 mapping configuration        
!Specifies Novell-to-X.121 address map configuration for Router-A
!
interface serial 0
x25 map ipx 3c.0800.0c00.5552 15552223334 broadcast
!Router-B X.25 mapping configuration
!Specifies Novell IPX-to-X.121 address map configuration for Router-B
!
interface serial 1
x25 map ipx 3c.0800.0c00.4321 15551231234 broadcast

ipx routing 0800.0c00.4321        


 Note    

Address Mapping for Novell-to-Frame Relay Interconnection

Figure 10-8 shows essentially the same interconnection arrangement as shown in Figure 10-7, except that the PSN is a Frame Relay network. In an analogous manner, Novell-to-Frame Relay address map specifications are required for both Router-A and Router-B.

Figure 10-8 : Network Diagram Illustrating Novell-to-Frame Relay Mapping

The interface configurations are as follows:

!Router-A Frame Relay mapping configuration        
!Specifies Novell-to-DLCI address map configuration for Router-A
!
interface serial 0
frame-relay map ipx 3c.0800.0c00.5552 20 broadcast
!Router-B Frame Relay mapping configuration
!Specifies Novell-to-DLCI address map configuration for Router-B
!
interface serial 1
frame-relay map ipx 3c.0800.0c00.4321 30 broadcast

%DUAL-3-SIA: Route 3c.0800.0c00.4321 Stuck-in-Active        

 Note