Documenting the Network – CompTIA Network+ N10-006 – 2.3


Having a well-documented design and internal processes can greatly simplify the management of the network. In this video, you’ll learn about logical network maps, physical network maps, asset management, IP address documentation, and the importance of documenting internal operating procedures.

<< Previous: Network Access ControlNext: Segmenting the Network >>


When we think about documenting the network, we have to think about how the network was originally created. We generally will create the network in large chunks. And we’ll usually have sections in between where not much is changing. We often will build a structure. And when we build that structure, we’ll wire everything on the inside for the network. And then it will sit that way for years. And then we might need to upgrade a section of it. So there will be another flurry of activity, and then the networks sits exactly the way it is for the next number of years.

Of course, during that time frame, you’re constantly adding and removing devices from the network and changing the way the entire network topology is designed. That means this documentation is going to be very important, especially since you can’t really physically see a lot of the network, because it’s in the ceilings, and the walls, and the floors.

You have to have some type of documentation that explains that the end of this cable is going to appear over in this room, and it’s going to be labeled in this way. This network diagramming and documentation is usually going to take a couple of different forms. You might have a physical diagram that shows you exactly where the wires and the fibers are. And then you might also have a logical diagram that separates the networks into different VLANs, so that you can understand how a switch might be configured.

Having updated documentation is always a challenge. And we’ll often see that the new hire has been tasked with documenting parts of the network. This not only provides you with some updated documentation, but it gives the new hire a way to understand exactly how the network is laid out. And very often, the person who’s hired the most recently is the one that understands the most about the way the network is designed. You generally want to have electronic versions of these network diagrams. And you might want to use a standalone program like Visio or OmniGraffle. You can even use offline versions on the web like Gliffy.com.

A logical network map would be a very high level view of a network layout. It might be a wide area network or a local area network, or it may just show the flow of an application. This isn’t necessarily pointing out every router and every switch and how they’re configured, but instead, giving you an idea of the overall traffic flow. This becomes useful if somebody wants to get a better understanding of how an application works or where your locations might be. And if you’re planning to upgrade or move any of this information, it’s useful to know how the network is organized.

If you’re someone who needs to understand exactly what devices are in place, how those devices are interconnected to each other, and where they might be located, then you might want to create a physical network map. This would show exactly where the wires are going. It might show IP addresses and MAC addresses. You might even have a picture of the rack itself. And you might specify where these devices are located in the rack visually. That way you’re able to direct someone to a specific rack in a specific location and point out exactly where that piece of equipment is located.

One way to track all of this equipment is through asset management. You want to be able to have a documentation of what all of the equipment is that you have– serial numbers or any identifying markers. And you might even want to add your own asset tags to each one of these devices. This is useful for your financial records. You can have this information available for audits to make sure that all the equipment is still in the building. And of course for taxes and depreciation, this can come in handy.

You’ll generally want to have the make and model of the device, maybe configuration information of what’s inside of that device, what adapter card you may have purchased, for instance, when it was purchased, where it was purchased, where it’s located, or anything else that might help you identify that particular asset. You would generally put a tag on the device to identify the asset. It might be a bar code like this one. It might be an RFID, so you can identify it through radio frequency waves. But it’s usually something visible. So not only can you see it with your human eye and identify that asset, but you can use electronic means as well.

You’ve now gathered a lot of information about this device. You have the type of device, its configuration, where it’s located, where you purchased it from. And you’ve put a tag on to that device. And you generally consolidate all of that information in asset management software. This is going to allow your help desk to gain access to understand what a particular user might have. You can report on how many of those types of devices you have and where they might be located. And it is usually a database that you build as the company grows. As you get more IT assets, you can add them to the database and really keep track of where everything might be in your organization.

From a networking perspective, another important piece of documentation is associated with your IP addresses. If you have a large organization, you may have a number of DHCP servers. And of course, it’s important that everybody is able to get an IP address when they connect to the network. So with IP address utilization reports, you’re able to understand the scopes and how they’re being used in your environment, how many IP addresses have been assigned to devices, and what are those devices, and do you have more IP addresses in the pool so that you can assign more at a later time.

This is something that’s usually integrated into your management system. There may be specialized DHCP software. And this may be able to provide us with reports that show us information about how many DHCP IP addresses you’ve put on to the network and how many have been used. This can give you more documentation that you can use to then understand what devices do I have out on the network and what type of access do these devices have.

For some reason, we often think of reading a vendor documentation as being the last thing we would do. But very often, this documentation contains everything you would need to know about managing and maintaining these very important IT assets. Usually, the vendor has an entire group who does nothing but create documentation. That vendor documentation team is building this information, putting it into a PDF form, and making it available to you for absolutely free.

There’s been a shift to online knowledge bases that make it even easier to find these details, so that you don’t even necessarily have to download the entire PDF file. You can go to a central knowledge base, you can search for the topic you want, and get just the details that you’re looking for. In fact, these days, it’s very unusual to get a physical book. We’re often given some type of media or a link out on the internet that we can use to download a PDF file that we can then read and search through to find the information we’re looking for.

Your internal documentation is also important. You probably have IT policies that have already been established. And there may be processes and procedures for things like people who are bringing their own equipment into the building or when visitors need to get inside of the data center.

You probably have operational procedures as well. If there’s an outage, there may be a list of people that need to be called immediately. If there’s a problem with the facilities– if your air conditioning or your heating in your data centers is not working properly– there’s probably a completely different group of people to contact.

You probably also have a process in place for software upgrades. For instance, things like operating systems may get updated at least once a month. So you need to have a set of documentation that describe the testing process and then how the change control will be handled for deploying that particular update. The important part is that you have the documentation. If everything has been written down and agreed to and everybody knows there’s one place to go to understand exactly what the process is and procedures might be.