Of all the duties of a network administrator, documenting the network is one of the most important. Remember that you're responsible for the operations of the network. If you have no documentation, you'll spend more time solving problems than is necessary. A solid documentation set is the most powerful tool you have in your toolbox.
Networks are complicated animals that tend to grow quickly. Even if you're managing a small LAN, the number of configuration parameters involved is staggering. To visualize this, think about all the physical components involved in your network--client workstations, servers, printers, hubs, routers, switches, and possibly remote access equipment. Each of these components has several logical configuration parameters such as IP addresses, protocols, frame types, and SNMP information to name a few. Any problem on the network can involve anywhere from one to all of these parameters.
Most network troubleshooting is pure brainwork. The last thing you want to do is stop thinking about the problem so that you can find some seemingly trivial piece of information. Your documentation set serves as your atlas, dictionary, and encyclopedia. Don't leave home without it!
Ideally, Network documentation begins with the design phase. In fact, there's no better way to design a network than to draw it. As you're designing your network, you'll undoubtedly create drawings and tables of the proposed structure. These preliminary sketches should be used to create your documentation. Because designs change and evolve, you'll never create a final documentation set. Don't view the documentation process as a one-time task. Instead, your network documentation is a work in progress. If you don't have any documentation for your network, you'd better get to work. There's no time to waste. Without this documentation, you'll spend most of your troubleshooting time trying to track down data that should be readily available.
Several tools are available for network documentation, ranging from simple to overly complicated:
CAUTION: Be sure to keep backups of your documentation, regardless of the tools used to create it. If your documentation is drawn on paper, make photocopies. If it's stored online, make several copies on different machines. You won't want to relive the documentation process in the event of some unfortunate disaster.
TIP: It helps to keep a copy of your documentation with you at all times. If you're in charge of a WAN, you'll definitely want to keep the documentation handy when you visit remote sites.
As with any large task, it's beneficial to split the documentation process into two areas: physical documentation and logical documentation. The most important point to remember when documenting is consistency. There's no single acceptable way to document a network. As long as your format is consistent, you'll make it easier for those who follow to figure out the network structure. You'll also be less likely to leave anything out. Figure A.1 shows a simple, consistent network diagram.
The keys to effective documentation are consistency and simplicity.
Many people believe that there's one set of symbols to use when diagramming a network. Unfortunately, nobody can decide which set of symbols is the correct one. It's inherent in human nature to make sciences out of everything, complicating the process until we forget the original point. Remember that these diagrams are not designed to exhibit personal insight or intelligence. Instead, they're for your own use in troubleshooting day-to-day problems.
The key to good diagramming is consistency. Choose a symbol and stick with it. For example, you might want to use a picture of a desktop computer for clients and a tower computer for servers. Don't make some clients look like towers and others desktops. The whole reason for using symbols is to instantly recognize what each piece of equipment is. It doesn't matter whether the actual PCs are desktops or not. Nobody cares. Represent each piece of equipment with the simplest icon that conveys the purpose of the hardware. Figure A.2 shows some of the common symbols used to diagram networks.
TIP: It's a good idea to create a legend for your diagrams. This way others can easily decipher your symbols.
These symbols are commonly used for network diagrams.
You need to know a great deal of information about your servers. From a physical standpoint, it's important to know what type of hardware you have. Create a configuration sheet for each server that lists every peripheral, including model number and driver version. Many hardware problems are attributed to conflicting drivers. Having this information on hand can cut an hour-long support call down to ten minutes. Figure A.3 shows a sample server configuration sheet. Be sure to include the following information in your configuration sheets:
If this information is not readily available, you need to do an equipment inventory. This is not a task to be taken lightly. Your users will not be happy about your pulling their systems out to record the information. The good news is, however, that if you do it right, you won't have to do it again. When you get new equipment, you can record the information before putting it in production. Your documentation can benefit from your corporate real estate and asset management department. They will usually keep track of serial numbers and equipment assignment. Equipment is also usually assigned a capital asset ID for internal tracking. Asset tags can be used to identify equipment in a standard format rather than using serial numbers, making it easier to inventory and track your systems by using a software package such as Microsoft's Systems Management Server. SMS is an administrator's dream and is discussed in detail in Chapter 25, "Administering an Enterprise with SMS."
Like servers, routers contain important information that you need to note. If a router goes down, an entire office can lose contact with the WAN. In this type of time-critical environment, the last thing you want to do is track down configuration parameters. Figure A.4 shows a sample router configuration sheet. When you create a configuration sheet for your routers, include the following:
It helps to keep configuration data handy for each server.
Router configuration data is an invaluable tool, when needed.
Noting the physical characteristics of your hubs is important. Because they usually are distributed between floors, it's critical that you have information on each one during a troubleshooting scenario. Hubs don't really need their own documentation because their port mappings will be present in the cable configuration sheets and the backbone map. You'll want to keep track of any differences between hub models that you're using on your network.
Patch panels provide an efficient modular wiring solution. On the other hand, without proper documentation, they can become an administrator's nightmare. This is easy to illustrate. Imagine a panel with 300 jacks. Each jack corresponds to a piece of equipment somewhere on your network. If client A cannot see client B, and you have no idea which port corresponds to which piece of equipment, you're forced to run all over the office to trace cables. In your mad dash through the office, you find that client A is connected to port 51-B-16, which plugs into port 13 of hub 4c, whereas client B is connected to port 51-c-12, which is connected to port 22 of hub 3a instead of port 22 of hub 4c. By documenting your patch panel, you could have easily looked at your chart to see that port 51-c-12 should be connected to port 22 of hub 4c. In this example the port isn't connected to the correct hub, so you can find the problem in Step one. Remember that patch panels are the hubs of the wiring system. It helps to know where the actual connections are. A template for mapping your patch panel circuits is included later in the chapter.
Remote access equipment comes in many shapes and sizes. They do, however, all have one thing in common: They use modems. Whether you're using integrated modem boxes or nailing external modems to the wall, you need to keep track of the configuration specs for each one. If you make the decision to use different types and models of modems, you especially need to document the configuration. Depending on your RAS strategy, you need to document the following:
In larger networks, it's important to utilize a high bandwidth backbone. Consider an office with multiple floors. Each floor could conceivably have its own hubs where the network equipment for that floor would converge. The hubs could then be attached to a fiber optic backbone, which connects the floors. It's important to document the backbone. If one floor loses connectivity while the other floors are unaffected, it's easy to track down the source of the problem. Your backbone documentation should contain a backbone map and listing of fiber connection points. Fiber optics also use patch panels. It's important to know which port in the patch panel corresponds to which floor.
When mapping the logical layers of your network, it's important to remember that there are several layers of abstraction with several categories per layer. The best way to make sure that you aren't missing anything is to write down what kind of services your network supports. Most networks support file services, print services, and messaging. Determining the services your network provides can help you gain a clearer picture of what you're trying to accomplish.
WANs that use TCP/IP almost always use some type of subnetting scheme. Subnets are differentiated by a network number that contains some number of hosts. Each host is bound to that subnet. To communicate with a host in another subnet, a router must exist that resides on both subnets. Depending on the size of the company, your subnet requirements can become very large. When you document your subnet scheme, include the following for each subnet:
Depending on the services you are using, there are several other items you will want to record. DHCP scopes, HOSTS and LMHOSTS file entries, and any static routing tables are essential if you are using them.
The Windows NT domain structure enables you to manage access and control user accounts at a high level of abstraction. Unlike TCP/IP subnetting, the domain structure enables you to group systems by functional groups. Domains can extend across subnets, adding complexity to the network diagram. For example, you might want everyone in accounting to log on to the Accounting domain. If you're using TCP/IP and you have accounting people in five different cities, you more than likely have people from five different subnets logging on to the same domain. On the other hand, if your corporate headquarters are all on one subnet, you have many people from the same subnet logging on to different domains. This can cause an overlap in your documentation. You should always document in levels to minimize confusion. Figure A.5 shows a simple domain map.
When you document your domain structure, include the following:
A domain map can help you solve permission-related problems.
How you use the information in this section will definitely vary depending on the messaging system you're using. Each vendor has its own structure, but they are usually similar. If you're using Microsoft Exchange, you'll need to keep track of organization and site structure. If you're using a simple SMTP/POP server, your documentation will be considerably lighter. This is because most SMTP/POP servers don't implement complex replication strategies that ease the burden of a single server. In any case, include the following information for each mail server:
If you're in a situation in which you have no network documentation, there are a few things you need to find out immediately. Proper documentation takes time and might not be feasible in some situations. In this case, you need to create a quick and dirty set of documentation. The following sections explain five things you absolutely must know about your network.
Without this, you'll go completely insane trying to troubleshoot problems. You need to know who has what address, who the name servers are, what the DHCP scope is, what machine is the WINS server, and where the routers reside. Imagine a situation in which one client cannot log on to the domain across a subnet while all other machines log on without a problem. This type of situation can involve the WINS server, the router on the local subnet, the router on the remote subnet, the PDC, and the local client. Without knowledge of the addressing scheme, you could conceivably spend hours on this issue.
It's important to have a list of each server and its corresponding duties. Each of your servers runs a different variety of services and programs to accomplish its tasks. As your network grows and evolves, it's easy to forget which services are running on a particular machine. Most server-level problems are caused by conflicts between software. By keeping a list of server duties nearby, you can significantly ease the troubleshooting process.
Many types and versions of operating systems are on the market. Each version usually has several service packs associated with it. It's important to know what versions you're running on your network. Remember that service packs should only be applied if there's an immediate need for the update. For this reason, you might have several different subversions of Windows NT running on your network. When troubleshooting a software conflict, it always helps to know what service pack you're running on your system.
This tool keeps you from running up and down the stairs all day. When a machine loses contact with the network, first check the hub to see whether or not there's a connection. In this case, it helps to know what hub, and what port in that hub, the machine is connected to. I've spent many a day walking from the PC to the local wiring closet to the central wiring closet, tracing the wire from the patch panel to the hub. It's nearly impossible to trace a cable if you use an effective cable management system. With a patch panel map, you can look down and see that PC 451 is connected to Hub 12b, port 23.
Many problems encountered by users on a Windows NT network are caused by a lack of permissions. As an administrator, you're working with multiple levels of abstraction, and it's nearly impossible to remember all aspects of your network. Domain trusts and permissions can become complicated as your network grows. You can reduce this complexity by creating a trust diagram. This diagram shows the domain structure and contains local and global groups for each domain. Glancing at this document while you view the permissions for a particular resource might keep you from overlooking the source of the problem.
This section provides some basic templates you can use to document your network. Each template contains the basic information you need to create a working documentation set. Remember that every network is unique. You might want to add more information to these templates, depending on your situation.
Your documentation set should be broken down as follows:
Routers
Hubs
Patch Panels
Backbone
TCP/IP Information
Windows NT Domain Structure
Messaging System Information
Software configuration
The TCP/IP addressing scheme template shown in Figure A.6 is used to keep track of assigned IP addresses. It contains only IP addresses and descriptions of their use.
The server hardware configuration template shown in Figure A.7 is broken down by hardware subsystem. This should include all information relevant to the hardware that makes up the system.
Like the hardware template, the server software configuration template should describe everything on the system (see Figure A.8). In this case, however, we are only concerned with the logical side of the system.
The router configuration template shown in Figure A.9 is used to record information about your routers. Router models vary, so you might want to add additional information to this template.
This is the TCP/IP addressing scheme template.
This is the server hardware configuration template.
This is the server software configuration template.
This is the router configuration template.
The cable configuration template shown in Figure A.10 helps you keep track of your modular wiring system. Without it, you will be forced to trace cables to check a connection.
This is the cable configuration template.
These templates are just a small sampling of the information you can find in your network. Every network is a different beast, so these templates won't fit your network perfectly. You need to sit down and figure out which information is most crucial for you. Remember that a good documentation set can mean the difference between a quick fix and massive downtime. By planning ahead and compiling information in a central location, you can greatly reduce the amount of time spent troubleshooting problems.
© Copyright, Macmillan Computer Publishing. All rights reserved.