| Previous | Table of Contents | Next |
Hour 2
You Can’t Have Too Much Documentation, Money, or Love!
Would you start out on a car trip in a strange country without a map? Of course you wouldn’t, but this is what people do every day when they fail to document their ever-expanding networks. When it comes time to troubleshoot, those who don’t have a map to go by will just shrug and shake their heads. Undocumented networks are mostly incomprehensible. You need some method of getting your bearings, and network documentation can be an compass in what can be a sea of confusion.
Navigating a Bad Network Neighborhood
There will be those who tell you that complete documentation is too much trouble, or that it takes too much time and doesn’t buy you all that much. This is utter hogwash. (Although many gray areas exist in network troubleshooting, this is one issue that is utterly black and white.) Folks without documented networks are the ones running around with their hair on fire while others with documented networks have fixed the problem, gone to lunch, done something productive, and gone home to spend time with their kids. This may sound rather judgmental, but there’s just too much evidence that suggests that you either document once and have a reference during times of trouble or you fail to document at all and end up having to figure out something multiple times during each crisis.
Not only does insufficient documentation waste time when your network is having problems, but it also causes unnecessary fear and confusion during the crisis. You owe it to yourself to have as clear a situation as possible when you start to troubleshoot—believe me, there’s enough uncertainty and doubt when you’re trying to find your way out of a bad network neighborhood without adding to it due to a lack of a good map.
Documentation Dividends
Enough with the dire warnings and horror stories! Let’s set aside all the negatives due to a lack of documentation. On the positive side, you can see tangible benefits to having an acceptable level of documentation. Perhaps the one benefit you’ll appreciate most is that a documented network is a network from which you can walk away. You can take a vacation from a documented network without worrying about whether you’re going to be called if something goes wrong. Because you’re not the only person with access to information about how your network is set up, others can deal with it while you watch the sun rise on your beach vacation without your pager or cellular phone going off. Because the work day is already occupied enough without having to drag somebody around to show him or her all of the nuances of the network, your network documentation does this for you, leaving you time to do other work. Table 2.1 describes the four major types of network documentation.
| Type | Purpose |
|---|---|
| Logical/functional map | This type of documentation gives an overview of how data flows in general. It leaves out individual workstations and wire runs and simply shows the important parts of the network (such as the servers, routers, and network segments). |
| Physical/layout map | This type of documentation shows very specific information about the network, including all wires, hubs, local switches, and workstations. |
| Device and cable labeling | This type of documentation consists of physical labels that identify the devices or cables they’re attached to in big, bold letters. |
| Detail/description | This type of documentation can consist of a logical write-up of an application or system, or an everyday log of what’s done to a device or system. It includes anything that’s not intuitive and not included in manufacturer’s documentation. |
Logical/Functional Maps
Logical or functional maps are probably the type of documentation that you’ll refer to most often. They’re used as a sort of “org chart” of your network, and, appropriately, they indicate which device or server is responsible for what function, as well as which devices depend upon other devices in order to work. Details are not as important here; flow is what you’re looking for. You’ll want to be able to determine, without being confused by unnecessary details, why department A can’t talk to the server, but department B can.
Not every PC or printer needs to be on this chart, but every device that somebody else relies on (such as your servers and routers) does. You’ll need to make a per-case decision as to whether to include hubs or switches on this type of chart, based on whether these act as a group or stand alone. In other words, on this type of chart, hubs and switches (being a “neighborhood”) are usually represented on their own, but there might be cases in which a switch connects two different “neighborhoods” that would be appropriately represented separately. See Figure 2.1 for an example of a simple logical network.
)
Figure 2.1 A simple logical map.
If you have a network that’s complex or larger than one site, it’s time to grab another piece of paper (it’s not worth it to try to cram everything into one map—it just makes your map hard to read). Typically, multiple sites need a separate high-level view, so draw out the site plan for how each site is connected. Each site will be represented by a box that refers to a separate detail map and will indicate how that site links to other maps. See Figure 2.2 for a sample map of a more complex network.
)
Figure 2.2 A more complex logical site map.
| Previous | Table of Contents | Next |