I've talked to many network administrators over the years, and I've visited and consulted for a variety of operations that had anywhere from 10 to 600 clients. The one characteristic that all the organizations have had in common is the lack of good network documentation. Even in my own business, my documentation has, at times, been quite weak. Creating documentation is time-consuming, detail-oriented, and boring. It is also absolutely essential to the health of your network. An administrator's handbook containing network documentation could even save your job.
To help ease the process and show the value of creating such documentation, I recently gave my admin students a class project. They were to find out everything they could about our network, but they couldn't leave their computers to do it. After a few classes of pulling together all the pieces of what each student thought was critical information, I made a checklist of the sum total of the items. The question afterward was "What did we miss?" I decided that the best way to make sure we had covered all the bases was to apply the seven-layer OSI Reference Model to our checklist and see whether we had addressed the documentation of each layer. Most of our items fell within the parameters of one of the seven layers. A few spanned multiple layers or all layers. Below is a list of the seven layers and what needs to be documented at each one. I've also put together a network documentation outline that breaks these items down into an easy-to-read list.
Layer 1: Physical Layer
The bulk of your documentation needs to be done at Layer 1. A full description of each device on the network is essential for inventory control, future upgrade planning, and physical security. Device, in this instance, refers to computer hardware, peripherals, routers, and switches. You should also make sure that you document network cabling and patch panels. You may want to make use of system inventory software to simplify documenting these items, especially in larger organizations. If you want to get a flavor for what these software packages can do, check out Belarc Advisor, a free download that allows you to audit the hardware, gather operating system information, and get a list of installed application versions for one PC. Belarc and other vendors offer more robust packages that can be used by businesses to automatically gather information from hardware and software throughout your network. You should also diagram the topology and architecture of the network using a tool such as Microsoft Visio, and this diagram should be kept up-to-date as the network changes. This diagram can help you do some pre-emptive planning and answer important questions about your network. Are hubs close to being maxed out? If just a few nodes are added to the topology, will it push you into a quick buying decision? This is valuable information for the managers of your organization, and your documentation could be the ammunition you need to get new purchases approved during planning meetings with management.
Layer 2: Data Link Layer
The Data Link Layer is responsible for the communication between the network and the physical layers. One of the primary network specifications handled at the Data Link Layer is the hardware address (also called the MAC address) of network adapter cards. Every network adapter in the world has a unique hardware address, based on the vendor of the adapter. You should have a list of MAC addresses for each network adapter on your network. You should know what speed they are and what protocols they support. Plus, you should have statistics from a network monitoring application that shows baseline information about activity on your network.
Layer 3: Network Layer
The Network Layer defines the standards of how data is communicated across your network and between your network and other networks, including the Internet. Network Layer documentation should include information about WAN links, Internet connections, and VPN and RAS servers. This is the layer that is responsible for converting a logical name into an IP address. So the documentation of your subnet should include a map of NetBIOS/Host names and IP addresses,
DHCP scopes, gateway/router addresses, proxy server addresses, WINS and DNS server addresses, and IP addresses and information on any other network servers. Network Layer documentation should also include policies on the naming conventions of computers and users, domain controllers, and routers/switches.
Layer 4: Transport Layer
The Transport Layer is responsible for the packets getting to their destination in the proper sequence and without errors. This is a critical layer for security, especially firewalls and screening routers. The two primary protocols that operate at this layer are TCP and UDP, and one of the main methods that firewalls use to block or allow traffic is based upon TCP and UDP port numbers. Your documentation should include a list of which port numbers your firewall(s) allows.
Layer 5: Session Layer
The Session Layer makes sure that a system can open a communications connection with a remote system and that data can flow back and forth between the systems. Examples of protocols that work at the Session Layer include Telnet, SSH, SNMP, and SSL. In terms of documentation, you should include SSL-enabled sites in security documentation, and you should have a policy about having SNMP enabled for network monitoring and management. Telnet and SSH will probably be documented as part of your remote access plan for administrators.
Layer 6: Presentation Layer
The Presentation Layer transforms data into a form understandable to the recipient. If encryption is required, it takes place here, as does decryption. The Presentation Layer also participates in encapsulation and decapsulation and encoding and decoding, such as in multimedia applications like MPEG. There really aren't any documentation activities that relate specifically to the Presentation Layer.
Layer 7: Application Layer
The Application Layer is the interface that controls applications such as e-mail and other applications used to send or receive information. I'll use this space to talk about application in the more traditional sense—the ones that are installed on operating systems. The network administrator must have policies in writing from the powers-that-be that spell out what applications should be available on the network and to whom. Without this document, administrators are in a precarious position. If a user wants an application, and you withhold it with no written policy, you face appeal. If you give a user an application, and someone higher up doesn't think you should have done so, you face reprimand. If you have policies in hand that make the decisions for you, you will have the needed consistency.
Final Word
In the network documentation outline, I've listed what I think are the most important documents, including polices, that you should have available to you at all times. These could be in the form of hard copy, an interactive intranet site available only to administrators, or even a CD that admins carry with them (or a combination thereof). The important thing is that you have them. Creating documentation is certainly nobody's idea of fun, but it doesn't have to be torture, either.
