HOT-WIRED, Part Two

by Wayne M. Krakau - Chicago Computer Guide, May 1994 - NewsWare, February 1996

In the last tale in this trilogy of horror (in the Stephen King tradition), another reseller called us in to find out why some newly added workstations on his client's token ring were mysteriously slowing down and sometimes losing contact with applications servers on the network. The need for help was urgent, and the problem sounded suspiciously like it could involve the cable plant, so I had my cabling integrator, Bruce Kahn of Telnet Communications Consulting, Inc. (708-215-0003), a local cabling company meet us there. We ran our usual software tests as well as the diagnostic software that the client had. Both programs presented unusual results.

One program could see all of the nodes (a node being any entity on the network, such as workstations, direct network connected printers, file servers, and applications servers), but showed repeated bursts of errors, especially when someone shut down a workstation. The other program missed some nodes that we knew were logged on and showed errors on the nodes that it could find. Finally, it would start mixing up token ring addresses and login names!

To track down the last and most bizarre problem, we created a set of login names that corresponded to the cable numbering scheme used at this site. With all of the workstations logged in with their cable plant number, we could cross reference office layout diagrams to find which workstations were having problems. We also recorded the token ring addresses so we could detect further discrepancies.

In the next round of tests, some nodes were producing thousands of errors while others were disappearing and reappearing randomly. Because of token ring's design, we couldn't tell if the errors were originating at those nodes or if the actual problems were elsewhere and we were only seeing the aftereffects. The network wasn't stable enough to get accurate software-based test results.

At that point, we started examining the cable plant. The quality of the wiring organization was very professional, but looks alone are not enough to evaluate a network. The most obvious initial problem was the use of segments of UTP with media filters (for conversion between UTP and STP) to connect between wiring closets on a system that used STP in one closet and the workstations associated with it while using UTP in the other. UTP should not be used to connect dissimilar media closets. Fiberoptic cable is the only safe way to connect them. We even looked up that standard, just to make sure that we remembered the rule correctly. With the new, less expensive and more reliable methods of installing fiberoptic cable available, there is no excuse for violating this rule other than a lack of knowledge and training on the part of the installer. A bid based on the older fiberoptic installation procedures can be high enough to encourage clients to cut corners.

Next, using the cable lengths originally supplied by the cable installer, we calculated the total length of the longest UTP lobe (a lobe being the cable going to a workstation or other node) and the cable between the most distant wiring closets. This number was greater than the allowed number as listed in the standard tables used for UTP cable in token ring networks. This meant that even if we ignored the mixed media problem, there was still a major standards violation.

We got out my LANcat, a test instrument programmed with the IEEE standards for the cables used with all of the common networking systems made by Datacom Technologies, Inc. (800-468-5557) and also

sold under the Fluke brand name. We started testing individual cable runs. While the cables themselves (both UTP and STP) and the terminations were all of very high quality, all of the sample runs that we analyzed tested out as longer than the cable installer said they were.

To double check our figures, we used a tape measure on the shorter runs and counted ceiling tiles on the longer runs to get an independent reading of the cable lengths. These figures matched the LANcat's readings. This made the UTP length violation much worse than we originally expected. No wonder we couldn't get a stable reading from software-based tests. High-quality cable and manual dexterity can't make up for ignoring standards based on the laws of physics.

As a short term fix, the applications servers were moved to the same area as the workstations that used them the most. This reduced the occurrences of workstations losing contact with them, but did not clear up the underlying problem.

At this time, client management has refused to rethink its cabling strategy. A series of classic misunderstandings is slowing progress. The cabling company, probably not as experienced in data cabling as they presented themselves, warned the client of possible problems, but did not press the issue. While many cabling companies would have declined the project on ethical grounds, not wishing to burden a client with a cable plant guaranteed to cause problems, this company deferred to what they may have assumed to be the greater knowledge of the MIS department of the client corporation.

In a typical train of thought, the MIS people work with those big, scary mainframe computers, and therefore, must be the ultimate computer experts. PCs are computers, and LANs involve PCs, so they must be experts on them, too. Riiiiiiight.

In reality, mainframe computer people may be the only group more strictly divided into specialties than the medical profession. As evidence, recruitment procedures are almost comical, with MIS managers demanding a match on industry, specific application within that industry, language, dialect, sub-dialect, database, database dialect, code generator, report generator, and programmer utilities - all just to qualify for an initial interview! Even within those narrowly defined specialties, the knowledge level varies according to a standard bell curve, with a few real experts at the high end, a few filter-feeders at the low end (named for the sea creatures that just sit there and gather food as it drifts by), and a great mass of just plain average folks in the middle - exactly like most other professions (including systems integrators).

The MIS people saw planning a cable plant as a cabling-only issue. They deferred to the people they thought that were experts in that field and assumed that the installer would refuse to install a defective cable plant. They may also have greatly underestimated the amount of knowledge needed for them to create a reliable preliminary plan prior to bringing in the cable installer. Remember, I've been beating on LANs for over 11 years and have had extensive related experience (see the bio at the beginning of this column), and I still bring in Bruce and his people to work with us on cable planning and any serious troubleshooting. I know the value of bringing in fellow professionals who are experts in fields that I can only dabble in.

Over the years, I have become very cynical about cable plants. That's because I see so many bad ones. The possibility of using spare pairs of telephone wires as network cables has never materialized for any company that I've dealt with. Even using data cable pulled by phone cabling specialists has been a complete disaster. The only systems that I've seen work were meticulously planned, professionally installed and warrantied by experienced data cable installers, and tested not just for continuity, but using sophisticated test instruments, for compliance to international standards appropriate to the specific type of network. That's the only sure way to avoid cabling nightmares.