Network Documentation

Describe the purpose of configuration management documentation. This chapter describes the process of documenting networks in each phase, including wire schemes, network maps, documentation, cable management, asset management, baselines, and change management.

Documentation is critical in organizations of all sizes, especially during troubleshooting processes and network modifications. Some of the most important characteristics of network documentation include the following:

Each organization should have a standard that defines how the documentation is created, maintained, and accessed.
It is usually centrally maintained in a repository that is accessible by everyone.
Different users should have different permissions for the documentation files (read/write).
It should be secured.

A common place for storing some of the network documentation is the internal help desk system. Users should open a support ticket for every network problem or change, and this system should keep track of all network changes for future reference. An example of such an open source tracking system is Bugzilla. Another common location for storing documentation is a knowledge-base system, which offers many options including search functionality.

Back to book index.

Contents hide

Wire Schemes

Network Maps

Cable Management

Asset Management

Baselines

Change Management

Summary

Wire Schemes

The cabling system is a fundamental part of network performance in organizations of any size, but this becomes critical as the network grows larger. The cabling system needs to be standardized across the entire infrastructure to avoid spending too much time on Layer 1 troubleshooting.

A very important aspect in organizing and documenting cabling systems is a wire mapping device, which has the ability to show the exact manner in which the wires go through the infrastructure. In medium and large enterprise environments, a structured cabling approach is always desired, which means having a dedicated person, team, or external company to take care of the network cabling according to different standards.

Different cabling standards exist to ensure consistency in this area. For example, for twisted-pair cabling, two standards exist:

EIA/TIA-568A
EIA/TIA-568B

Details about the wire mapping for these two standards can be found in Chapter 14, including wire mapping differences. Usually, the two standards are used in different locations, with EIA/TIA-568A being used for horizontal cabling. These decisions should be made in the design phase, before starting the implementation, as cabling is very difficult to replace once a mistake has been made. Cable systems usually have a long life that usually coincides with the building’s lifespan.

Note: You cannot terminate one side of the cable with EIA/TIA-568A and the other with EIA/TIA-568B because they use different Transmit/Receive wire pairs.

All the wiring and cabling system design and implementation steps should be properly documented and used as a baseline for any type of Layer 1 troubleshooting.

Wire schemes can be built either in a table or in a graphical representation. The wire scheme presented in Figure 25.1 below illustrates a graphical representation of a wiring block section:

Figure 25.1 – Wire Scheme Example

Network Maps

Networks are subject to constant changes during their lifetime and this usually happens in steps or phases. Starting from the design and implementation phase, different elements and blocks are added to the network to increase functionality. The downside of this is network complexity is also increased and you have to keep up with these changes by reflecting them in the documentation.

Most of the network infrastructure layout is transparent to an end user and this may include:

Device positioning
Cabling system topology
Cable types
End-to-end connections

All of these physical and logical layouts have to be documented because they will become critical at a later point in time, when you will need to troubleshoot specific issues. The recommendation is to document the network map starting with the design phase and continue with every step in the implementation process. However, if you start to manage a network that already exists but does not have any type of documentation, you can start building a network map step by step, following a few logical phases:

Determine the area the network spans (may be multiple floors or multiple buildings)
Document every network device, including location and function in the network
Track every cable and complete the network map with end-to-end connections
Proceed with documenting the logical aspect of the network, including VLANs, routing protocol areas, filtering mechanisms, and other configuration-derived policies

Network mapping documentation should contain diagrams that show network connectivity or other upper layer processes. Using dedicated software to create these diagrams, the icons associated with different network devices can provide as much granularity as you want in representing the interaction between network elements.

Some of the most commonly used software specialized in building network diagrams includes:

Microsoft Visio (for Windows)
OmniGraffle (for Mac OS)

You can even use online diagram building tools, such as www.gliffy.com, which can create network diagrams like the one below:

Figure 25.2 – Network Diagram Example

Once you have the network map documented, you can use it in many ways, including:

Troubleshooting
Network planning and upgrades
Understanding traffic flows

Network maps are very useful because seeing the network in visual form is much more intuitive than analyzing tables or text documents when trying to find specific information. Network maps can come in multiple forms:

Physical diagrams
Rack device mapping diagrams
Logical diagrams

Physical diagrams show exactly how the devices connect at Layer 1 and what specific cable type is used between each pair of devices. Specialized software allows you to build the rack and include each device in the correct rack position using dedicated pictograms that are specific to each device model. This approach is very useful for new people in the organization who are not familiar with the data center layout. An example of a rack device mapping diagram can be seen in Figure 25.3 below:

Figure 25.3 – Rack Device Mapping Diagram

Logical network maps can be very important because they show a high-level view of the network, including:

Logical interaction between devices (how they are configured to communicate with each other)
Traffic flows
WAN connectivity

Logical maps may not contain detailed information, as they may only show network blocks and areas instead of specific devices. These types of maps are very useful when analyzing traffic and application behavior over a large infrastructure. Sometimes logical diagrams can be built on top of physical diagrams, but you should separate the two sets of diagrams for simplicity.

Cable Management

Cable management is not very important in SOHO environments but it becomes critical as the organization grows. There are some international standards, such as ANSI/TIA/EIA-606 – Administration Standard for the Telecommunications Infrastructure of Commercial Buildings, that go into detail about how cables should be managed inside an enterprise infrastructure. Some of the things it describes include the following:

Information presentation
Reports format
Drawings format
Work orders
Pathway, space, and grounding considerations (including identifiers and labeling)
Identifying cabling
Labeling cabling (including color coding and bar coding)

Cable management mandates that everything is tagged and labeled according to a standard so that every cable can be identified by anyone in the organization. The ANSI/TIA/EIA-606 standard describes possible ways of labeling cables. One of these is using the XXX-YYY-ZZZ format, where:

XXX is the building code
YYY is the floor and room code
ZZZ is the device and port code

For example, a cable labeled as DC01-02C-V011 can mean: Data Center 1 building, 2^nd floor room C, Voice port 11. With this method of labeling, anyone can easily track the cable across the infrastructure.

The ANSI/TIA/EIA-606 standard even includes cable standardization based on color, as can be seen in the screenshot below (taken from the official standard itself):

Figure 25.4 – ANSI/TIA/EIA-606 Cable Color Codes

Asset Management

Asset management is an important part of the documentation process, as you need to be sure of the following aspects:

How many devices you have
Which types of devices you have (model, purchase date, serial number, etc.)
Where the devices are located (including spares)
Support and warranty status for each device
Issues associated with each device
Status of each device (active, inactive, who is managing it)

Asset management is very important for financial reasons, as it calculates financial parameters like depreciation that are presented during audits. Asset management can be accomplished using simple spreadsheets, but it is recommended that you use dedicated software solutions in large environments so that you can create a database for the different records. Such software solutions scale as the company grows and this eliminates the complexity of using multiple asset tracking documents.

Each device (asset) should be tagged in order to be properly tracked within the infrastructure. The label might include information that is also part of the asset management solution records, such as:

Device name
Serial number
Barcode
Tracking number (ID)
RFID

Asset management software usually offers the following functionalities:

Master database for asset records creation and interrogation
Help desk functionality
Reporting functionalities
Alerts when the support or warranty period is over

Baselines

If you are in the middle of a troubleshooting process, you have probably already gathered statistics and have followed the network behavior at that specific point in time. In order for those results to be relevant, you have to compare them with the same data collected during normal network operations, which is the baseline of the network operations. The baseline establishes the specific status of the network on a “normal day” and this information should be recorded for future reference.

Having statistics that go back a long time will allow you to baseline what is happening in your network so you will be able to make better decisions about what you should be doing in the future. The baseline process can be performed on multiple network metrics:

Bandwidth utilization
Response time
Application performance
Resource utilization
Traffic patterns

Having a baseline ensures a point of reference for information accumulated over a long period of time. If you have this information, you can always go back to the past and use that information to plan your network accordingly, adhering to the initial design and behavior. Baselines used together with current network statistics can also provide trends that will allow you to predict future network behavior.

Figure 25.5 – Bandwidth Utilization Weekly Statistics Example

Figure 25.5 above shows a common bandwidth utilization traffic pattern for a connection to the Internet. Notice that there are peaks of traffic every day during business hours and that there is little traffic on the link in the evening and during the night. This happens regularly so you can use it as a baseline for any future strange behavior regarding bandwidth utilization.

Network baselines can be used in different reports to show what the current network status is or how it should be if you are encountering strange behavior.

Change Management

Almost every network is subject to changes over time. Some of these changes include the following:

Network upgrades
Change of functionalities
Changes caused by network issues

All of these modifications have the potential to impact the performance and the availability of the network, so it is very important that you go through a standardized process to manage each particular change. The changes you make need to have minimal impact on the goals of the organization, both from a business and a customer perspective. You should avoid network downtime by scheduling every change based on its impact on the network infrastructure (usually outside of business hours).

A change control mechanism is a process and series of procedures that ensures you will not have any major issues with implementing the changes. The overall change management purpose is to reduce or eliminate the negative impact a change can have on the organization. The change management process involves many areas of the organization, both in the initial process of development and in the normal day-to-day operations and approval chain.

The actual process of change management is specific to each business and is usually different from organization to organization. In small environments, you can just announce the change and receive immediate approval for it. On the other hand, in large organizations there are many forms to be filled out, and a lot of people will be involved who will evaluate the change’s impact on the organization, review it, and schedule as needed. With each change, there are usually a few mandatory components:

Reason for the change (business and/or technical)
Description of the change
Priority of the change (based on its impact)
Implementation steps of the change
Rollback procedure (in case something goes wrong)
Details about the requestor and review board members

Note: The rollback (recovery) procedure for each change is critical because a number of things might go wrong during a change maintenance window (e.g., machine errors or human errors), and you need to make sure that you have a way to bring the network back to its previous working state.

Summary

Each organization should have a standard that defines how the documentation is created, maintained, and accessed.
It is usually centrally maintained in a repository that is accessible by everyone.
Different users should have different permissions for the documentation files (read/write).
It should be secured.

The cabling system is a fundamental part of network performance in organizations of any size, but this becomes critical as the network grows larger. Cabling systems need to be standardized across the entire infrastructure to avoid spending too much time on Layer 1 troubleshooting.

Networks are subject to constant changes during their lifetime and this usually happens in steps or phases. Starting from the design and implementation phase, different elements and blocks are added to the network to increase functionality. The downside to this is network complexity is also increased, and you have to keep up with these changes by reflecting them in the documentation.

Most of the network infrastructure layout is transparent to a simple user and this may include: