Beyond wiggling the wires

I got a desperate call from a former employer recently begging me to visit my old network room and help determine what was causing lengthy service outages on one particular segment. Users on this segment could see local resources but were unable to see anything outside.

A group of eager consultants had been poring over the systems and communication racks in vain attempts to pinpoint the problem. When faced with no overt signs of trouble they resorted to one of my favorite approaches to system troubleshooting -- start rebooting! After shutting down file servers several times and power-cycling the hubs and routers, the network would work briefly and suddenly fail again.

When I arrived, my first step was to listen to what everyone had already done and get a sense of what they thought was wrong, to be sure that I understood the situation completely. Next, I began examining the router that connected the problem segment to the rest of the LAN. I fired up Telnet on a Windows NT server on the affected segment and connected to the router. By consulting the manual (yes, I read the manuals) I got the necessary commands and checked the IP parameters for every port. All the addresses matched the configuration document from the original installation. It was obvious that the router was configured correctly, and I believed nothing was wrong electronically with the equipment.

While I was trying to diagnose the problem, the entire network was in the midst of a wiring upgrade -- installers were pulling new station runs to accommodate higher speed communications. While no work was being done directly on the existing equipment, there had been a great deal of pulling and poking of cables as technicians traced runs and cataloged port assignments.

Remembering how easily the fastest switches and routers can be rendered impotent when a bad cable is used, I tried replacing the cable linking the router to the rest of the network. Voilá, everything worked!

Here's the moral of the story: Whenever you have a network problem, expect that 70 percent of the time bad cabling is the cause. A quick check with a cable scanner from Microtest, Fluke, Agilent, or Wavetek can verify that your cables are indeed properly wired and capable of supporting the network signaling rate you require.

One last point: when you find bad cables, THROW THEM OUT! I guarantee that if you leave one around, it will be picked up and used later, and you'll have to deal with a broken network again.

Neil Plotnick is the author of the "IT Professional's Guide to Managing Systems, Vendors and End-Users." He welcomes your questions and comments at Neil@NeilPlotnick.com.

We've all encountered bad cables, why are they made so poorly? Do you agree that they account for 70% off network downtime? What do you think?