| |
Observe the procedures described in the following sections when you are configuring IPX or NLSP for the Novell Internet Access Server 4.1 routing software:
To isolate and resolve problems with IPX, complete the following steps:
Verify that workstations can connect to all desired servers.
If a problem with LAN connectivity occurs, refer to IPX Connectivity Problems (Duplicate ID or Network Number). If you are using the NetWare Mobile IPXTM software, refer to NetWare Mobile IPX Client Loses Connectivity to the Server.
Verify that the IPX network number is different for each LAN across a WAN link.
IMPORTANT: Each LAN segment must have a unique IPX network number. It is a common error to incorrectly use the same IPX network number on each side of an unnumbered PPP or WAN link.
Verify that all servers and routers in the entire internetwork have unique internal network numbers.
In addition, each network segment has a unique network number, and all servers and routers on the same segment must have their interfaces configured with the same IPX network number.
Look at the routing table in IPXCON on any NetWare Link Services ProtocolTM (NLSPTM ) system in the suspected area (parameter path: Select NLSP Information > Routers).
Determine whether there are routers that appear and disappear from the table (these routers might also become unreachable for brief periods of time). Then establish a remote connection with RCONSOLE and check for any error messages indicating duplicate internal network numbers.
Typically, if you can log in to a server, but cannot establish a connection to the same server using RCONSOLE, then the server is configured with a duplicate IPX address.
Enable SAP on one of the interfaces in a router in the NLSP area.
Between SAP periodic updates, you should see two routers (or more, if more than one router has the same internal network number) being listed as unreachable and then reachable. This should occur every 5 to 10 seconds.
After you have identified the NLSP systems with the problem, load IPXCON to determine to which networks the servers or routers are connected (parameter path: Select NLSP Information > Routers).
Select the NLSP router that is the source of the problem. You might need to select the router several times because its connectivity is intermittent.
If the router is a Novell router, then the internal network number is probably a duplicate.
Change one of the router's internal network numbers and restart the system.
For WAN links, verify that third-party routers use IPXWANTM software (RFC 1362, 1551, or 1634).
To establish an IPX connection to third-party routers over a WAN, the third-party routers must support IPXWAN; otherwise, problems with initiating, maintaining, or terminating the IPX connection occur.
Verify that the IPX network number is different for each WAN link unless an unnumbered RIP is used (in which case, the IPX network number is zero).
To isolate and resolve IPX connectivity problems, complete the following steps:
Find the server or router that is connected to the same segment as the workstation.
If more than one server or router connects the workstation to the network, look at each system to determine if it has proper connectivity. If the system with which you are communicating is a server, then use that system.
Check the forwarding table on both systems.
If you are on the server or router representing network A, then find network B in the forwarding table. Load IPXCON (parameter path: Select Forwarding > Display entire forwarding table).
If network B is not displayed in the table, then exit and enter the forwarding table until it appears.
If network B still does not appear in the table, probably a router in the path either is malfunctioning or has a duplicate system ID.
If the route shows up intermittently, then probably a router in the path has a duplicate system ID.
If the route shows up consistently, then look at the route and select Potential Paths by selecting the network on the Forwarding Table menu.
Make sure that the potential path leads to the correct network by looking at the intermediate routers.
If a duplicate network number exists, you can determine the location of the duplicate number from this window.
If all the routers in the path seem to be correctly configured, then write down the addresses of all the LANs and routers in the path.
Use IPXPING to check all routers or servers in the end-to-end path (do this from one side only). Also, check the end points.
If connectivity is occurring from a workstation, make sure that the workstation can log in to the first server or router in the path or that it has access through the router in question.
If the connectivity loss is only temporary (for example, you occasionally get abort retries on the workstation), then let IPXPING run for several minutes. Check for packet loss during this time, then examine the router at which packet loss occurred.
It is also possible that a router is malfunctioning in the end-to-end path. Usually, IPXPING can help you determine where the fault is occurring.
Once you have found the router that has the problem, check its potential paths.
All downstream routes from the first router to the router that has the problem should also be potential paths on this router. If this is not the case and the router does not quickly acquire the downstream routes, then the system probably has a software error in it. Contact the router manufacturer's technical support for further assistance. To help minimize problems like this, you should purchase only NLSP-certified routers.
If connectivity loss occurs outside an NLSP area, check each router in the end-to-end path for an external RIP route.
RIP can be used between NLSP areas. Therefore, it is necessary to check the end-to-end path in a more tedious way, as follows:
Find the next-hop router from each of the servers.
Look at that system's forwarding database.
Find the next-hop router from that system, and so on, until you have found where the route leads. Do the same from the other side of the path as well.
This process is difficult with the current implementation of RIP and SNMP for Novell, because RIP shows only the next-hop LAN and Network Interface Card (NIC) address (over LANs) instead of the internal network number of the system. SNMP cannot receive packets that are addressed to a NIC; the packets must be addressed to the internal network number. You must work backward, first finding all routers attached to the LAN, and then finding the receiving LAN card on each router. One of the routers you should start with is the next-hop router. Repeat these steps until you find the destination network number. If you do not find a duplicate network number in either direction, check each link in the path for errors.
To isolate and resolve problems with NLSP, complete the following steps:
Determine connectivity.
Determine whether RIP is active.
| |