Troubleshoot Novell TCP/IP network errors with TechRepublic's checklist

Just as with Windows or Linux systems, TCP/IP network configuration issues can prove quite frustrating to solve on Novell networks. TechRepublic's Steven Pittsley (a CNE himself) knows Novell administrators can save time if they follow a troubleshooting checklist. He's created the following step-by-step guide, which you can use the next time your Novell network experiences TCP/IP problems.

Please note: If you're experiencing TCP/IP troubles on a Windows or Linux system, check out TechRepublic's TCP/IP Checklist.

What changed last?

We do not live in a perfect world. Equipment breaks or software changes are made, and it's up to us to resolve the ensuing problems. When we're faced with network troubles, our first step should be to answer one simple question: What changed?

Many times, the answer to this question will provide the resolution to our problem. This guide offers some straightforward troubleshooting steps to help diagnose and resolve problems on misbehaving Novell TCP/IP networks.

Determine the scope of the problem

When troubleshooting any problem, take a moment to absorb the big picture. Is one user or a single system affected, or does the problem have an impact on the entire department? First, call the Help Desk to see if it is receiving similar complaints. Determining the scope and nature of a problem will allow you to diagnose and resolve any issue correctly and efficiently.

Single-client problem

If a single client is having connectivity problems, you can follow these steps to restore network service to your users and systems.

• Check physical connections. Sometimes users move their computers and forget to plug in the network connection. Occasionally, the network connection is accidentally removed. Reconnect both ends of the network cable and check to see if the cable has been severed or crushed by a heavy piece of furniture.

• Reboot the computer. As simple as it may be, rebooting the workstation resolves many problems. NetWare 5 clients will automatically reconnect if there's a lapse in the network signal, but older clients don't have this capability. Rebooting the workstation shouldn't make the problem worse, and it will provide you with a good starting point for troubleshooting configuration issues.

• Check the network signal. Verify that the network card has a green light. This does not always mean that the signal is good, but it is a sign of connectivity. Using a line tester, verify the physical cabling from the communications closet to the wall jack.

• Verify the line speed. Using a line tester, verify the speed of the connection. Switch ports can be forced to slower speeds, and network cards can be configured incorrectly. Also verify that the switch port and the network card are not both configured to auto sense the line speed. If they are, neither one will be able to determine the correct speed.

• Check the wiring closet. If you aren't receiving a signal at the client, head for the wiring closet. Reconnect both ends of the patch cable to ensure the connection is good. Next, check for a link light on the hub or switch port. If you don't have a link light, try another port. Finally, check for error lights on the network device and confirm that the network feeds are securely connected.

• Use PING to test connectivity. If everything in the communications closet is good, go back to the workstation and PING the local loopback address of 127.0.0.1. This will test the TCP/IP protocol stack and verify that it is working correctly. Next, try to PING various locations on the network. Start by PINGing a workstation on the same network segment as the non-working client. Finally, PING the default gateway, followed by a device on the other side of the gateway, such as a remote server or an Internet address. A failure of any of these devices should pinpoint the problem. The following example shows a successful PING of Novell's Web site:

• 
  
  Use TRACERT to test connectivity. If you are unsure of the IP addresses of various network devices, use the handy command line utility TRACERT. Select an Internet address, such as 192.233.80.4, which is Novell's home page, or TechRepublic's site (208.49.160.19). At a command prompt, type TRACERT and then the IP address. For instance, to check the route to TechRepublic, you would type TRACERT 208.49.160.19. The results will show each hop that the ICMP packet takes to reach the destination address, as shown in the following example. A failure of any of these devices should pinpoint the problem.

• 
  Use WINIPCFG to release/renew the IP address. Releasing and renewing the IP address lease can eliminate problems with a particular address. While the WINIPCFG screen is displayed, take a moment to verify the other settings. The following example shows the WINIPCFG screen from a Windows 98 workstation. Windows NT users can use WNTIPCFG and receive a similar screen.

• Try a different computer on the same network connection. If you don't know whether the issue is a computer problem or network problem, try using a different computer on the “bad” network connection. Using a laptop is probably the easiest method, but you can also borrow a nearby computer that is not in use. If the other computer works normally, then look to the non-functional computer to resolve the problem.

• Reinstall the network drivers. Reinstalling the network card driver will allow you to start from scratch with the network software. After doing this, you should have no doubts about the configuration of the network card.

• Install a new NIC. Network cards, like any other device, can go bad. Install a brand card, not one that has been sitting on the shelf for the past six months, so that you don't introduce new problems into the already fuzzy equation.

Department or area connectivity problem

When one or more segments of a TCP/IP network lose connectivity, the problem usually lies with the network equipment. Here are some troubleshooting tips that can help you isolate the problem and restore connectivity to your users and systems.

• Reboot at least one workstation. If the outage is brief, the workstations may regain connectivity after being rebooted. NetWare 5 clients will be able to reconnect automatically, but older clients will be unable to do so.

• Check the wiring closet. Collect a few data jack numbers and head to the communications closet. First, determine if all of the devices in the closet are powered on. A localized power outage is a common cause of network failures. Next, determine if all of the data jack numbers are connected to a single network device. If they are, move a couple to a different device and see if the problem goes away. Finally, look for error lights on the switch or hub and confirm that the network feeds are securely connected.

• PING the network equipment from the affected area. Try to PING the switch from a workstation located in the affected area. If that is successful, PING the default gateway, followed by a device on the other side of the gateway. A failure on any of these devices should pinpoint the problem.

• Use TRACERT to test connectivity. As described in the previous section, use TRACERT to quickly test the network devices from the affected area to the Internet. If you use TRACERT from a working area and then from the non-working area, are both routes the same? If they aren't, the differences may help you pinpoint the problem.

• Verify any router or network changes. Because an entire area has been affected, it's possible that someone has made changes to a router or network device. Ask someone from the WAN team to confirm that the device is configured correctly. If the connection is made through a leased line, contact the provider's support desk to verify that the device is working correctly.

File server TCP/IP problem

Once TCP/IP is configured and working on a file server, you normally won't have many problems with it. However, occasionally something is changed and problems arise. Here are some tips to help you troubleshoot these problems and restore network service to your users or systems.

• Things to consider. Was any software recently installed on the file server? Has the server gone down lately? Why was it down? Press the up arrow key to scroll back through many of the recent commands that have been executed and look for something to be loaded, unloaded, SET, or changed.

• Check the physical connections. While it's normally rare to find your server unplugged from the network, you should never overlook the obvious. An operator or cleaning person could accidentally disconnect the network connection and not even realize it.

• Check the network signal. Verify that the network card has a green light to indicate that a network signal is present. Using a line tester, verify the physical cabling from the communications closet to the wall jack.

• Verify the line speed. If your network contains segments with differing speeds, use the line tester to verify the speed of the connection. Switch ports can accidentally be forced to a slower speed and network cards can be configured incorrectly.

• Check the wiring closet. Since most servers are in a secured area, many of the wiring closets are also well secured. However, if you're not receiving a signal at the server, head for the wiring closet. Check the patch cable and reconnect both ends to ensure the connection is good. Next, check for a link light on the hub or switch port. If you don't have a link light, try another port. Look for error lights on other ports and verify that the network feed is securely connected. You might also try a different port on the network device, or even try a different network device altogether. Before doing so, verify that the new device is working correctly.

• Verify that other protocols are working correctly. If your file server is running IPX or another protocol, verify that it is working correctly. If so, then you can begin to look toward a TCP/IP configuration problem. This is not always true, but it is very rare to see a network card unable to pass a single protocol.

• Are all network cards are having problems? If the file server has multiple network cards, determine whether one of them is having a problem or if they both have similar problems. It is rare for both network cards to physically fail at the same time. If one is working and the other one is not, check the configuration of the failing card.

• Check CONFIG.NCF and AUTOEXEC.NCF for changes. Verify that all the settings in these two boot files are correct. Someone may have recently changed something that is causing the problem you're facing.

• Verify bindings and network card configuration. Make sure that the network card bindings and configuration are correct. Using SET commands from the console, unbind the protocol from the network card, reload the driver, and bind the protocol back to the card.

• 
  Use PING to test connectivity. Using the NetWare server's PING utility, PING the local loopback of the file server to verify that the TCP/IP stack is working correctly. If this test is successful, PING a device that is on the same segment as the server, followed by the default gateway and a device on the other side of the gateway. A failure on any of these devices should pinpoint the problem. The following example shows the PING.NLM in action:

• 
  Use IPTRACE to test connectivity. A NetWare server's IPTRACE utility is very similar to TRACERT. Choose an IP address from a distant router or the Internet and at the server console type: IPTRACE <IP address>. You will be taken to a new screen that shows the route that the ICMP packet took to reach the destination. The following example shows the IPTRACE results screen.

• 
  Verify that the server is not discarding TCP/IP packets. From the server's system console screen, enter: SET TCP IP DEBUG = 1. The console screen should immediately start scrolling TCP/IP information. To stop the log, enter: SET TCP IP DEBUG = 0, and you shouldn't see any packets being DISCARDed. The following example shows the results of the TCP/IP debug screen.

• 
  Use TCPCON to gather TCP/IP statistics. NetWare 5.x includes a nifty utility called TCPCON.NLM. You should be able to see the values in the middle of the screen changing as network traffic flows to and from the server. Verify that IP routing is enabled by selecting Protocol Information -> IP -> IP Packet Forwarding. The IP Packet Forwarding field should be set to Router. TCPCON can also be used to verify the IP Routing Table. The following example shows the main screen of TCPCON.

• Install a new network card. If you determine that the network card is bad, install a new one. This will affect all your users and systems, including ones that might be working and currently in use.

• Reboot the server. Because of the impact that this solution will have on your users and systems, rebooting the file server should be used only as a last resort. On a NetWare 5 server, you can issue the RESTART SERVER command.

These troubleshooting steps may not solve all of your connectivity problems, but they should provide you with a good starting point. Hopefully, you will never need to use them. But as we noted earlier, we do not live in a perfect world.

Steve Pittsley is a CNE and desktop analyst for a Milwaukee hospital. When he's not troubleshooting TCP/IP challenges, he enjoys playing drums, bowling, and most sports.

Novell TCP/IP checklist

6

www.techrepublic.com

---