LAN DESIGN - Part 1

by Wayne M. Krakau - Chicago Computer Guide, October 1994 - NewsWare, April 1996

This article will cover Network Design, and, by implication, management and troubleshooting. I am going to cover some nuts and bolts techniques and also give some more esoteric advice, generally concentrating on a proactive approach. It’s always easier to avoid trouble than fixing it and it’s better to be prepared for trouble than to be surprised by it.

In real estate the general theme is Location, Location, Location". In networking the general theme is Planning, Planning, Planning". There is a direct relationship between the amount and quality of planning that goes into a network and its eventual stability and reliability. Just because Local Area Networks look small, don't underestimate their complexity. Once you have more than one person sharing a computing resource, it’s just as complicated and potentially hazardous as if you have one hundred. Only the economies of scale are different.

The esoteric aspect to the planning process is the application of human resources. In the corporate world, in particular, it is very common to have upper management hold the opinion that their programmers and associated personnel are computer experts" and that since PCs are computers, these programmers must also be experts on PCs and LANs. This is a logical trap that can compromise the planning process. An active programmer has the wrong mindset and generally an inadequate background to handle the sophisticated and specialized planning required. The person assigned is given the responsibility but not the tools to complete the project.

An allowance must be made for additional training, considerable time for research, and for outside help as necessary. As an independent CNI (Certified Netware Instructor), I constantly see people taking CNE (Certified Netware Engineer) courses who are inadequately prepared for the course material. Tinkering with a PC at home or even at work while your main job is on other computer architectures doesn't equip an individual for LAN design. Even programming PC’s doesn't prepare you. It just qualifies an individual to be a potential quick learner and makes it less likely that the individual will be afraid of the technology. Even though such an assignment plays to the programmer’s ego, it is inherently dangerous and the turnover rate for LAN administrators gives evidence to that fact.

This is not meant to be a slam against programmers. If I ever forget to wear my seatbelt and end up going face-first through my windshield, and someone offers me a referral to a doctor who is world-renowned in the field of viral research at the Centers for Disease Control, I would decline. Most likely, I would request an experienced reconstructive plastic surgeon - preferably board-certified. It’s not that I don't respect the intelligence or competence of the virologist, it’s just that virology, while still a vital part of medicine, isn't even close to the specialty that I need. The mindset is wrong and the proper skills are not present. The same situation exists in my suggested approach towards programmers in a LAN design scenario. They are decidedly the wrong people for the job. I won’t go into the ethical ramifications involved when a programmer fraudulently uses a "Consultant" title and undeservedly claims expertise in LANs.

A trap that some firms fall into is to hire a high-end person. The problem there is that you end up spending premium dollars for an individual who is essentially idling 98% or more of the time with skills degrading all the while. One possible method out of this trap is to use a medium-skilled individual to

supervise one or more lightly skilled, but ambitious staff members. Then, develop a relationship with your favorite systems integrator so that a high-end person can be brought in as needed. This saves a lot of money while building in-house expertise. It also avoids the problem of having someone with an inappropriate background being forced to "wing-it". Since this is a potentially self-serving suggestion - my firm has been a systems integrator since 1983 and I worked for a mainframe-based systems integrator in my second-to-the- last big iron job - feel free to take it with whatever grains of salt that you feel necessary. However, please keep in mind that, for maximum personal profit, I could have suggested that you become completely dependent on a systems integrator for even day-to-day network management rather than maximizing the use of in-house personnel.

An additional consideration regarding programmers is the choice of software to use on your network. Programmers will normally lean towards the most programming-intensive choices. My suggestion on how to prioritize your software search is to start with unmodified packaged software, right off the shelf, at the top of the list, and end with completely custom code at the bottom. With Microsoft Windows becoming so popular, the most common and successful systems that I see use Visual Basic (or a similar tool) as the "glue" to combine multiple packages into a logically united system. By using the appropriate toolkits and the built-in flexibility of Windows, programming can be minimized while providing a virtually custom solution.

One of the most common problems that I see is a faulty cable plant. A bad cable plant has the potential of becoming the most time-consuming, labor-intensive, and incredibly expensive debugging session that you have ever experienced.

To even briefly summarize Ethernet cabling standards requires at least two pages of tiny type - and token ring is much worse! It is so complicated that I would have to write a booklet, as many manufacturers of token ring products have done, to get the same level of detail as two pages on Ethernet. Manufacturers’ literature can be a handy reference if you are knowledgeable enough to pick your way around proprietary features and limitations.

While I have heard rumors that such a thing is occasionally discovered, I personally have never seen a successful conversion of old telephone wiring into a LAN cable plant. I haven't even heard about one from other systems integrators and VARs either. Since most alleged "LAN cablers" can't even get their act together, how can you expect telephone cable installers, trained in much lower standards, to get it right? If you are thinking of using existing cable, even if someone tells you it was installed to high-speed data standards, have qualified personnel test it before planning on using it. We are not talking about simple continuity tests here. A rusty coathanger can pass one of those. We are talking about using test instruments specifically designed for a LAN environment. Even though my company uses another company to install cable, I encounter bad cable so often that I carry a LAN cable testing instrument with me as part of my standard toolkit. There are several brands and models available - just make sure that you get the cables tested by someone who can interpret the results. Depending on the size of your cable plant, you may want to purchase a test instrument and get training on how to use it.

Pick qualified installers. A select few telephone cable installers have successfully made the transition to LAN cabling, but most are just winging it. Try asking questions about the standards. Request an installation that doesn't follow standards and watch for the reaction. If the cabler declines the project on ethical grounds, that's a good sign. Ask about fiber. If they give you information that indicates that they are only familiar with old, expensive methods of putting in fiber and aren't trained in 3M's Hot-Melt system, that's a bad sign. They should also be testing with appropriate instrumentation and be willing to back their work.

I will continue this article on Network Design next month. Meanwhile, there are LANs out there awaiting rescue.