| |
This topic discusses the following common problems and their potential solutions:
The remote IPX LAN number might have a static route on the dial-in side. Load STATICON and select Dynamically Configure Static Routing Tables to dynamically configure local and remote routing tables. To initiate dynamic configuration with a remote router, the call to that router must be Connected. Press Ins to use the Make Call option to attempt to make a call to a currently Not Connected WAN destination.
Add the following line to the workstation's AUTOEXEC.BAT file:
Set loadbalance local lan = on
Verify that the router is configured to use NLSP compatible with RIP/SAP. Set maximum path splits to 8.
If only one IPX packet is sent and received each time the routing software attempts to establish a connection, decrease the user data size value so that it is equal to or less than the size used by the frame relay switch. Also, ensure that the user data size is equal to or less than the physical receive packet size.
Two NetWare servers or routers have conflicting internal network numbers and both systems are in the same NLSP area, resulting in a duplicate NLSP system ID. A number of activities occur when this situation exists. If router A and router B have the same system ID, both routers attempt to assert that they own the system ID. First, router A issues LSPs that supersede router B's LSPs and purges any LSPs of router B that it does not have. Then, router B does the same to router A. It is possible that this increases the amount of LSP traffic in the network considerably, particularly if either router A or router B has many LSPs (for example, if either router is importing many routes and services).
Change the internal network number of one of the conflicting systems, or remove one of the systems from the network immediately. For information about how to find the node that is causing the problem, refer to IPX Connectivity Problems (Duplicate ID or Network Number).
It is normal for a system to have some sequence number skips, but the Sequence Number Skips value should not increase after the first five minutes of a router's operation, unless there is a duplicate NLSP system ID. Change the internal network number of one of the conflicting systems, or remove one of the systems from the network immediately. For information about how to find the node that is causing the problem, refer to IPX Connectivity Problems (Duplicate ID or Network Number).
There is a duplicate NLSP system ID, and many systems have fluctuating counts of routes and services because the services available through one or the other router become unreachable. If one of the systems in question can route, then all systems in the network are running the NLSP decision process frequently. Change the internal network number of one of the conflicting systems, or remove one of the systems from the network immediately. For information about how to find the malfunctioning node, refer to IPX Connectivity Problems (Duplicate ID or Network Number).
Router name has the same internal network number of number but a system ID of system_ID .
A duplicate internal network number has resulted in a duplicate system ID.
Change the internal network number of one of the conflicting systems, or remove one of the systems from the network immediately. For information about how to find the malfunctioning node, refer to IPX Connectivity Problems (Duplicate ID or Network Number).
Cause 1 ---Errant application is corrupting the NLSP graph or LSP database. Contact technical support. Cause 2 ---NLSP has a software error that is either corrupting the graph or causing the graph to be represented incorrectly. Contact technical support.LSP graph inconsistency detected in stored LSP from system name length number . There has been a memory corruption or software error.
The NLSP decision process is running frequently.
To observe this symptom, obtain access to a NetWare server or router running NLSP in the network and enter SET ISUL DEBUG=256 at the system console prompt. Every time the decision process runs, an entry is displayed at the system console. If the decision process runs at least every 30 seconds, there might be a duplicate system ID.
Change the internal network number of one of the conflicting systems, or remove one of the systems from the network immediately. For information about how to find the malfunctioning node, refer to IPX Connectivity Problems (Duplicate ID or Network Number).
If other router names do not display when the DISPLAY SERVERS command is used, the NLSP Local Area Addresses might be different. Load NIASCFG and select Configure NIAS > Protocols and Routing > Network Interfaces > IPX > IPX Expert Configuration option to set the IPX network number and area mask to zeros.
A system frequently appears and disappears on the LAN.
Cause 1 .---System is not transmitting its packets to the Designated Router properly.
Cause 2 ---Problem with the underlying media.
Look at LAN/WAN information in MONITOR and check for errors. Errors are specific to the media; therefore, press F1 (for online help) to see what different errors mean. Most errors indicate that there is a problem with the server's or router's network interface board. These errors could be caused by the software or hardware. To determine whether there is a problem with the software, restart the PC. If the problem continues, install a new interface board.
Cause 3 ---System misconfiguration.
By default, NLSP timers are set so that a system becomes unreachable when three packets are dropped. Look at the system's configuration to ensure that this setting has been used.
Cause 4 ---One or both of the systems are dropping packets.
Check the interface boards to determine whether packets are being dropped because of insufficient Event Control Blocks (ECBs). Increasing the maximum number of physical receive packets might help stop the system from dropping packets. To reach this option load install, select NCF file options > edit startup.ncf. Increase the maximum number of physical receive packets to at least 1524. However, the system might be incapable of handling the system load. In this case, increase the processor power of the system that is dropping packets, or reduce the load on the server by either removing NLM files or decreasing the number of users on the system. You can determine whether the system is using too much CPU processing power by using MONITOR and viewing utilization.
Cause 5 ---NLM on the server is not relinquishing control of the CPU frequently enough.
This is a rare occurrence. To determine whether this is occurring, select Performance in MONITOR. Look for processes that exceed many millions of cycles per iteration. You can also determine that an NLM is malfunctioning by removing the NLM from the server and observing whether the problem is resolved.
Cause 6 ---Internal error in NLSP.
If you have exhausted all other possibilities, you should document your system configuration, number of users, and error frequency and send a copy of the system configuration (SYS: SYSTEM\CONFIG.TXT), including the NLSP configuration file (usually located in \ETC\NLSP.CFG), to technical support.
If multiple systems on a LAN become unreachable intermittently, the Designated Router might be the source of the problem.
Cause 1 ---Designated Router does not have enough system memory to represent the LAN.
To determine whether this is the case, you can check whether the Designated Router is overloaded when the problem occurs or whether it has been overloaded in the past. Check the Level 1 Data Base Overloads statistic in IPXCON (parameter path: Select NLSP Information > System Information > Detailed NLSP System Information). If the Designated Router does not have sufficient memory to represent the LAN, then the LAN loses connectivity as new systems are added. You must then select another system on the network to become the Designated Router by increasing its priority in NIASCFG and issuing the REINITIALIZE SYSTEM command. In addition, you must add memory to the system that was overloaded. You might also want to check whether other systems in the network are overloaded. Refer to Many Systems Are Entering an Overloaded State.
Cause 2 ---Designated Router or some other system on the LAN is causing the network outage. Another system can cause this problem by electing itself as the Designated Router on the LAN.
A single malfunctioning system on a LAN might be causing all systems on the LAN to become unreachable intermittently. Using IPXCON, check the Designated Router Changes counter for all systems on the LAN (parameter path: Select Circuits > a specific circuit > Detailed Circuit Information). If a single system has a large value displayed in the Designated Router Changes counter, the system probably has connectivity problems with other systems on the LAN. Check whether the counter increases over time. If the Designated Router is not being restarted or unbound from a LAN, the counter should not increase. If the Designated Router Changes counters of all systems on the LAN are increasing, the system that should be the Designated Router probably has a connectivity problem. To determine whether the problem is particular to the system or to the network itself, remove the system from the LAN or decrease its Designated Router priority.
Cause 3 ---Two systems are contending to be the Designated Router for the LAN.
In this case, the Own LSP Purges counter increases (parameter path: Select NLSP Information > System Information > Detailed NLSP System Information). However, unless you are using ARCnet* or some other media that does not have IEEE addresses, only one system has the highest priority on the LAN (the MAC address is used as a tie breaker and IEEE addresses are unique). If necessary, change the priority on one of the contending routers.
You cannot bring up an IPX point-to-point link, but IP is working.
Cause 1 ---System on the other end of the link does not support IPXWAN, or IPXWAN is not supported over the media that you use.
Contact the router manufacturer to verify that its product supports IPXWAN.
Cause 2 ---Link has excessive errors.
Cause 3 ---One of the IPXWAN implementations has an error.
Load MONITOR and view LAN/WAN Information under a specific NIC or LAN adapter. Determine whether the link has excessive errors by viewing discrepancies in packet error counts.
Issue the SET ISLL DEBUG=ON command and capture the IPXWAN exchanges. Contact the manufacturer of the router that appears to be in violation of the IPXWAN specification.
Cause 4 ---Link has excessive errors.
Load MONITOR and view LAN/WAN Information under a specific NIC or LAN adapter. Determine whether the link has excessive errors by viewing discrepancies in packet error counts.
Cause 5 ---Timers are misconfigured, causing the link to drop packets. (Typically, the defaults are used for PPP.)
Check in MONITOR under Driver Statistics to determine whether this is the cause. Set the timers so that the values match those set on the remote node.
Cause 6 ---System is limited by the amount of memory or by the capacity of the CPU or bus.
Load MONITOR and view memory utilization to determine if the capacity of the CPU or memory is limiting the function.
Cause 7 ---Link itself is corrupting data.
If the link is corrupting data, the corrupt LSPs statistic increases. To check this, load IPXCON (parameter path: Select NLSP Information > System Information > Detailed NLSP System Information). Even a single corrupt LSP indicates a serious problem because LSPs are transmitted infrequently. Note that this counter is a global counter and it is possible that some other media is corrupting the data link.
Cause 1 ---Area address is set to the wrong value.
In this case, the number of destinations (known networks and services) implies local connectivity only. Also, the Initialization Failures statistic in IPXCON increases (parameter path: Select Circuits > Detailed Circuit Information). If you have configured area addresses, make sure that all systems that should be in communication have the same area addresses. It is acceptable for systems to have different addresses, if that is the desired configuration.
Cause 2 ---RIP is not enabled.
If you are running multiple areas on a LAN and are using RIP to interconnect the systems, verify that RIP is enabled on those servers that are interconnecting areas. Load NIASCFG and select Configure NIAS > Protocol and Routing > Bindings > IPX Binding > Expert Bind Options > RIP Bind Options > RIP State. If the RIP State is set to Auto in NIASCFG, there is a small chance that RIP will fail. To avoid having RIP fail, set RIP State to On.
Cause 3 ---Hub or bridge has failed.
Use IPXPING to check whether there is data-link connectivity.
Cause 4 ---LAN board driver does not support multicast, even though the driver's documentation claims that it does.
Use a driver that supports multicast or set the MAC Channel option to Broadcast (parameter path: Select Bindings > a specific binding > Expert Bind Options > NLSP Bind Options).
Cause 5 ---LAN board has failed. This system does not see other systems on a LAN, or it does not have any adjacencies in the Up state. However, it declares itself as being attached to the LAN.
In IPXCON, look for a system that is in the Initializing state. If a system on the LAN appears in the Initializing state on all other systems but has no neighbors itself, then the system can send but not receive. Check that system, particularly if it is the Designated Router. Use IPXPING to help determine the actual source of the problem. An interface board with a conflicting interrupt is a common source of this problem.
Cause 6 ---System is declaring itself the owner of the LAN, even though it is not the owner.
Reinitialize the system.
Cause 7 ---LAN has become partitioned temporarily during normal NLSP operation. This should occur only during an NLSP system's startup, and the error should be corrected within a few minutes.
Verify that the condition does not persist. If it does, check for a hardware problem or an NLSP software incompatibility with other systems.
The systems are not properly configured. Refer to Understanding and Setting Up for information about the solution.
A LAN is partitioned when there are duplicate LANs or one of the LANs is declared unreachable in IPXCON (parameter path: Select NLSP Information > LANs).
Cause 1 ---A hub or bridge has failed.
Use IPXPING to check whether there is data-link connectivity.
Cause 2 ---LAN board has failed. This system does not see other systems on a LAN, or it does not have any adjacencies in the Up state. However, it declares itself as being attached to the LAN.
In IPXCON, look for a system that is in the Initializing state (parameter path: Select NLSP Information > Neighbors). If a system on the LAN appears in the Initializing state on all other systems but has no neighbors itself, then the system can send but not receive. Check that system, particularly if it is the Designated Router. Use IPXPING to help determine the actual source of the problem.
Cause 3 ---System is declaring itself the owner of the LAN, even though it is not the owner.
Reinitialize the system.
Cause 4 ---LAN has become partitioned temporarily during normal NLSP operation. This should occur only during an NLSP system's startup, and the error should be corrected within a few minutes.
Verify that the condition does not persist. If it does, check for a hardware problem or for NLSP software incompatibility with other systems.
The router has not converged because it is configured for multicast and the driver does not support multicast, even though the driver's documentation claims that it does. Set the MAC Channel option to Broadcast (parameter path: Select Bindings > a specific binding > Expert Bind Options > NLSP Bind Options).
Cause 1 ---Physical problem on the workstation (for example, a broken LAN card). Replace the malfunctioning hardware. Cause 2 ---Packet filter that is discarding the system's packets has been implemented somewhere in the network. Check each intervening router and correct the filter configurations.
Cause 1 ---Server is misconfigured. Correct the server's configuration and make sure that it has connectivity by verifying that it has the routes and services typical for your network. Cause 2 ---Connectivity exists, but it is so poor that the transports above IPX cannot maintain connectivity. Set up an IPXPING test between the two systems. If the rate of dropped packets is high, the connectivity problem is probably caused by a malfunctioning link between the two networks. To determine which link has the problem, refer to Applications Perform Poorly. Cause 3 ---There is a duplicate network number. This can cause a duplicate system ID, provided that both systems are in the same area and the duplicate network numbers are two internal network numbers on two NetWare implementations of NLSP. The console probably displays the following message: Change the internal network number of one of the conflicting systems, or remove one of the systems from the network immediately. For information about how to find the malfunctioning node, refer to IPX Connectivity Problems (Duplicate ID or Network Number). Cause 4 ---Packet filtering has been implemented on a router. This can cause symptoms similar to those caused by duplicate network numbers (for example, network A might be visible from network B, but network B is not visible from network A). If communication does not occur within an NLSP area, it is usually easy to determine whether the network fault is caused by packet filtering or a duplicate network number. Use IPXCON to view duplicate LAN network numbers (parameter path: Select NLSP Information > LANs). If your system does not have a matching network number, use FILTCFG to remove the packet filtering.System server_name with internal network number number has my system ID in it.
Services are inaccessible in the area.
Cause 1 ---Services are being blocked by filters.
Examine the IPXCON Services option of each router in the path to isolate the router that is filtering the services.
Cause 2 ---Network connectivity problems.
Check that the network to which the service is attached exists. If the network does not exit, look for link connectivity in the path between the area in the network that is missing the network number and the area that is generating the service.
Cause 3 ---Service name conflict. This occurs when you have the same service name and the same type (for example, file server). If the service is a file service, then the user logging in might not have appropriate rights and, consequently, the login is rejected.
Cause 4 ---Under rare circumstances, the server from which you are logging in has insufficient space to store the service in the bindery.
Increase the disk space on the file server.
Cause 5 ---If there are many services, a third-party router might be unable to transmit the entire SAP table before the next periodic update. A third-party router can start transmitting the services again from the beginning of the table, instead of completing the current update.
Contact technical support.
The number of routes and services on a system shows that there is local connectivity only.
Cause 1 ---If the network to which the system is attached is an NLSP- only network, and if the system is not configured for RIP mode only, then the system might not receive RIP updates. If the following message is displayed at the system console, there is a RIP mode misconfiguration and the two routers cannot communicate:
Router server_name claims network number is really number
Cause 2 ---Two NLSP systems are configured with different area addresses. In this case, the Initialization Failures counter in IPXCON should be increasing (parameter path: Select Circuits > Detailed Circuit Information).
If you are on an area boundary and you are using RIP as the interarea protocol, configure RIP on both systems on the interface through which they are communicating.
Cause 3 ---One of the routers has the RIP State option set to Auto. If you intended to use RIP for interarea routing on the network, this condition is potentially serious. If the two NLSP routers are in communication with each other, they continue to run RIP. However, if they are connected together with a bridge or hub and that hardware fails and is brought up again sometime later, NLSP does not detect the condition and RIP does not turn on again.
If you are running RIP and SAP on the network and the routes and services fluctuate, refer to Services or Routes are Fluctuating Excessively.
The number of routes and services are fluctuating excessively. Some fluctuation is normal in a large network. Change is occurring constantly as systems are brought down for maintenance and other reasons. However, hundreds of routes and services appearing and disappearing indicates a network error. All the following problems are solved with the same procedure:
Cause 1 ---Misconfiguration with RIP and SAP.
Cause 2 ---Problem with a link.
Cause 3 ---Error in NLSP.
Cause 4 ---Two systems are competing for a system ID.
Cause 5 ---LAN is generating errors.
In NLSP, this determination is easy to make. Simply look at an affected system's neighbors to see whether they have the problem, too. Examine each system as you move outward. If just a single NLSP system is experiencing the problem, then the cause is probably a local connectivity problem. Check the system for neighbor state changes and disappearing services.
You should never let a periodic multiplier be less than 4. Because of timer skew, this means that after three packets containing the same route are dropped, the system loses this route. If any of the previously listed RIP and SAP parameters are different, you must reconfigure the values. Better still, use the default values, especially on LANs. Using different values for the timers is too risky to justify the savings on a LAN.
Migrate to NLSP.
Cause 1 ---Network-layer packets are being retransmitted because there is a software error or because two important timers are misconfigured in NIASCFG. The important timers are the Minimum Non-Broadcast LSP Transmission Interval timer (which indicates the amount of time before an LSP is retransmitted when there is no acknowledging Partial Sequence Number Packet [PSNP]) and the Partial SNP Interval timer (parameter path: Select Configure NIAS > Protocols and Routing > Protocols > Expert Configuration Options > NLSP Convergence Rate Configuration). The latter timer should be set to a value much smaller than the value set for the former timer because it acknowledges LSPs; if it is set too high, the LSP transmitter responds as if the LSP is lost and retransmits the LSP. If the problem persists after you reconfigure the timers, call technical support. Cause 2 ---Many changes are occurring in your network because there is too much RIP activity in your network. Migrate more of your network to NLSP. Cause 3 ---Some systems are sending too many updates.
You are experiencing poor application performance on systems in your network.
Cause 1 ---Suboptimal path has been selected by NLSP.
Cause 2 ---Application relies on ticks to retransmit its packets. This should not happen with the routing software, but it is possible that some other manufacturer's router does not comply with the ticks value.
If this is the case, increase the cost of the routing software to match the value of the router in question. This procedure should not affect other paths much, but it should help to stop the application from retransmitting packets.
Cause 3 ---Router is in an NLSP area and you have routers with load sharing enabled. This causes the application to retransmit packets needlessly.
If this is the case, turn off load sharing to see whether the situation improves.
Cause 4 ---Link speed is too slow. You might be choosing the optimal path, but throughput is still not adequate.
Cause 5 ---Malfunctioning routers in the end-to-end path or a link that is causing problems in the end-to-end path.
Determine the routers in the end-to-end path and check each router and link for abnormal behavior.
Cause 6 ---Load sharing is enabled between dissimilar paths.
Verify that the two paths have comparable media and data rates.
CALLMGR shows an IPX circuit but IPXCON does not.
IPXCON does not show a circuit until after IPXWAN has completed negotiation.
Check the link for errors, and make sure that both sides of the IPX link are implementing IPXWAN properly.
A single system is in an overloaded state.
Cause 1 ---System is running out of memory.
Cause 2 ---Another system is experiencing database overload. It is possible that another system in an overloaded state is causing your system to go into an overloaded state.
On each suspect system, use MONITOR to check whether the Alloc Memory Pool is set too low. If the value is too low, increase the value set for the Alloc Memory Pool or remove some applications.
Cause 3 ---Transient condition on that router.
If the problem persists, the system is running out of memory. If the value is too low, increase the value set for the Alloc Memory Pool or remove some applications.
Many systems are entering an overloaded state.
Cause 1 ---Systems are being overrun with routing information. Possibly the number of systems in the NLSP area has exceeded the number you originally intended.
Using IPXCON, look at the number of routers in the area (parameter path: Select NLSP Information > Routers). Add this number to the number of LANs in the area. This sum is a good indicator of the amount of memory that is required by an NLSP area. We recommend that you do not exceed 400 LANs and routers (total) in any single NLSP area. It is also possible that two areas have merged when they should not have. Determine whether routers are in the area that should not be there. Prevent the areas from merging or use area addresses.
Cause 2 ---Backbone has been imported multiple times into the NLSP area. NLSP is careful about the way that it imports external routes and services into the NLSP network. For example, only the Designated Router on a LAN imports information. Usually, if two NLSP systems are connected to the same RIP backbone but they are on different LANs, a conflict does not occur. If RIP reports two different routes to the same location, only the RIP route with the shortest hop count is imported into the NLSP network. However, it might be that most of the backbone is imported more than once. This can occur if there is more than one equal cost path from the NLSP network to the RIP network. To determine whether most of the backbone has been imported more than once, look carefully at all routers that are importing RIP.
Using IPXCON, find the systems that are importing RIP into the NLSP area, then determine whether RIP Active is displayed for the LAN (parameter path: Select NLSP Information > LANs). Find the Designated Router in each LAN. Look at the Forwarding table of each Designated Router. If more than one Designated Router is on the LAN, this is probably because you have turned off NLSP on the routers. In this case, you must run NLSP between the routers to reduce the amount of imported information on each LAN.
Connectivity is not possible on a single LAN, but it is possible on other LANs.
This almost certainly indicates a duplicate network number. Refer to No Communication Occurs between Two Networks for the solution. Usually, the network number that is the duplicate does not have the connectivity.
The NetWare Mobile IPX client loses connectivity to the server.
If you lose connectivity before you start an operation, you will see messages such as Access Denied , or it might look as if access is not available on your network drives. If you lose connectivity after you start an operation, you will receive a DOS critical error message that asks you whether you want the operation to abort, retry, or fail. The method of reestablishing the connection depends on whether you lose connectivity before or after you start an operation. This method is the same for each of the following causes.
Cause 1 ---The NetWare Mobile IPX client was out of range of wireless coverage for too long.
Return the client to the range of wireless coverage and reestablish the connection as explained in Re-establishing the Connection.
Cause 2 ---The driver used with NetWare Mobile IPX is not Network Event Service Layer (NESL) aware, so IPX is not sent the receive notification of data-link events.
Use only NESL-aware drivers. Reestablish the connection as explained in Re-establishing the Connection.
Cause 3 ---The wireless board was removed when a process was running in the background or the board was not correctly plugged in. This can happen when you swap boards.
Simply reinsert the wireless or Personal Computer Memory Card International Association (PCMCIA) board. Reestablish the connection as explained in Re-establishing the Connection.
Cause 4 ---The PCMCIA board was swapped when the portable was in a low-power state. This tends to confuse the card and socket services, and events are not sent to the drivers. This invariably causes computer lockup.
Do not swap the PCMCIA board when the portable is in a low-power state. Reestablish the connection as explained in Re-establishing the Connection.
If you lose connectivity before you start an operation, you can usually reestablish a connection by selecting Open/Save. If the HR Time To Live timer has expired, selecting Open/Save will not reestablish the connection and you must log in again.
If you lose connectivity after you start an operation, reestablish your connection as follows:
| |