Debugging A Network

by Bob Seidel

I had an interesting experience debugging a computer network the other day. Interesting, of course, to nerds like me - and possibly a reader or two of my columns. I thought I would describe it to you.

I received a call from a new client. The client uses PCs heavily in their business and although things seemed to be running, the programs were running very, very slowly. Neither the person who sold them the computers, nor the supplier of their software, could fix the problem.

I was fairly certain right at the outset that the problem was a network problem. It could possibly have been a runaway virus or spyware program; I have often seen these rogue programs cause performance degrades, but never this much.

Fortunately, they were running Windows 2000 on their systems. Windows 2000, and its successor Windows XP, are "true" operating systems. Earlier systems such as Windows 98 were built on top of DOS and don't provide the level of monitoring and diagnostics that the newer systems do.

I started by looking at the Event Logs for their server computer. I didn't notice any network or communications errors, but I did notice a number of errors in which the server was unable to obtain an IP address from the router (the central piece of hardware in the network - not a PC). This would occur for a number of reasons, but network errors were a possibility.

In looking around, I noticed that the network cable going into the back of the server was looser than it should be. I decided to do a quick test by replacing the cable with another cable temporarily. No change. I also noticed a large amount of network activity at the router (its LEDs were blinking furiously), but the PCs did not show such activity.

I then took a fairly large file and started copying it from computer to computer in the network. It copied OK from Workstation A to Workstation B, taking about 3 minutes and utilizing the network about 25-50% of its capacity. When I attempted to copy the file to the server, Windows said it would have taken 72 minutes, and it was running at only 2.5% capacity. Aha! I then decided that the network adapter in the server was at fault, and replaced it. A Network Interface Card (NIC) is a very inexpensive component and so was prime for a replacement as a test.

To my dismay, the problem was still there. Performance was better, but still far from correct.

The big clue in determining the problem was that none of the PCs showed communications errors at all. This indicated to me that the problem was not in a PC, but must be in another part of the network. The only central, non-PC component was the router. As a next test, I replaced the router with my spare, and the network sprang to life! Enthusiastic office personnel were jumping up and down (really - well, almost) with joy! I replaced the router with a new, boxed one and left a happy client.

OK - so, the router was apparently bad. But some questions linger: If it was a bad router, why did replacing the NIC card in the server improve performance somewhat? The performance problem seemed to be only between the workstations and the server - I was able to successfully copy a file between workstations. If there is a problem in a router or switch limited to only one PC, it is usually just one bad port on the router. But I had changed ports during the test with the alternate cable.

I can only surmise that perhaps both the NIC and the router were both bad to some degree. But considering the cost of the new router vs. the cost of my debugging the network further, I made the right decision to replace the components.

So, after having read that, y'all who enjoyed it can meet me at the next local Nerd's Association meeting! For the remainder, I hope you at least learned a bit from it.

(Bob Seidel is a local computer consultant in the Southport / Oak Island area. You can visit his website at or e-mail him at