If you’re managing a network, having the right documentation can save you both time and money. In this video, you’ll learn about network documentation, change management, cable management, and more.
<< Previous Video: WAN Termination Next: Availability Concepts >>
When it comes to documenting the internal processes and procedures for an organization, every company is going to be a little bit different. There will obviously be very different business objectives between organizations, so the processes and procedures may be dramatically different from one organization to another. Because of that, it’s incredibly important that you have documentation on how you handle all of these internal operating procedures within your organization.
For example, when a system goes down, there may be a specific notification process. This may be an electronic notification, or your processes may require that you call someone directly to let them know. If there are facilities issues, you need to know exactly how to handle that. And so there should be a set of processes and procedures for that as well.
We can also create processes and procedures for very specific tasks. For example, if we want to do any software upgrades, there may be a process that requires that we test the software upgrades and go through a formal change control process. It’s important that all of this documentation is available to whoever might need it. That way, it doesn’t matter what happens in the organization. You know exactly the process that will be followed to resolve that issue.
In the networking world, a lot of our documentation is on the network. There are so many different components to the network, and we’re not usually building it all at once. It’s usually built over a long period of time through multiple phases. Once it’s built, you may not even know exactly where the wires, the fibers, and the cables might be going. It’s all inside of the walls and the ceiling, and it may take an additional effort to be able to document all of that information.
We also tend to create different types of documentation. There may be a set of logical documents and a set of physical documents. And creating and maintaining this documentation may be one of the best pieces of information you have from a networking perspective. Everyone will understand the layout of the network, and it’s nice to have documentation that you can share with a third party to perform whatever task may be required.
For network documentation, we tend to use a standard set of symbols that look very similar to these. If you’re documenting a router, it’s usually a circular device with arrows pointing in and out. Whereas a switch may be a square with arrows pointing only one direction or the other. Firewalls might look like an actual firewall, and so on. This makes it easier when working with third party documentation because you can recognize exactly what icon is associated with which components.
We covered logical and physical network diagrams a bit in section 1.5 under network typologies. But let’s quickly review some of that information. When you’re creating logical network maps, you’re building out a broad perspective of the way the network might be configured. You can usually create this documentation with software such as Visio, OmniGraffle, or third party websites. This is a high level view, and it gives you a perspective of how the network may be connected at a very broad level. It’s not showing specific components or exactly where wires may be going, but you can understand by looking at diagrams like this, exactly what sites are connected and how they connect to each other.
This is helpful if you’re working with a third party that needs a general understanding of how the network is designed. If more details are required, you can move from a logical network map to more of a physical layout. Physical network maps will show individual components inside of the network. It will identify specific interfaces on devices. It may show IP addressing. And it gives you an idea of exactly where wires and cables may be running between different devices.
Some physical network maps will show the physical layout of the rack that’s in the data center. This way, you can show this rack diagram to a third party who may have never seen this rack before, and they’ll know exactly which component you’re referencing. In the world of information technology, nothing remains the same. There are constant changes that are occurring. You may need to upgrade software, make a firewall change, or you may need to modify the configuration of a switch.
Any time a change is made to any piece of hardware or any piece of software, there is additional risk associated with that modification. You might be changing a piece of software, but you’ve overlooked that that particular change is going to break another piece of that software. So a simple upgrade can turn into a very significant change that can affect the entire organization.
This is why many organizations will implement a formal change control process. You can’t make any type of change to any component unless it goes through a formal committee. That particular change is documented. You have a fallback plan if that particular change doesn’t work properly. And everyone knows that that change is going to occur.
In many organizations, this change control process is a normal part of business. Everyone knows about the change control process and nobody makes any changes until it’s gone through the formal committee. In some organizations, though, change control is not part of the corporate culture. And it may be difficult to implement a formal change control process unless you get the buy in from everybody in the organization.
As network professionals, we deal with a lot of different network cables. And it may not surprise you to know there is a standard for administering this on the ANSI/TIA/EIA 606. This is the Administration Standard for the Telecommunications Infrastructure of Commercial Buildings. This will provide you with information on how to document the network. There’ll be sample reports, how you would draw out the network, and how work orders might look.
You have, of course, many different cables going many different places on your network . And you need some way to identify these cables. These might be in a pathway. They might be in a space. There’s grounding cables that you would use. And you need some way to identify and label all of these different cables that you might use. You would use identifiers on the cables such as labels, some color coding, and barcoding. That could help anybody who happens to walk in the door understand everything they need to know about your cable infrastructure.
Here’s an example of a standard layout. You could decide on different colors to use for different tags for your labels. Some that might be demarcation point cables. You have network connections that might be green, and you might have station termination colored as blue. You can also use a standard port labeling format so that you could reference an individual port that might be in a particular building. For example, a port CB01-01A-D088 would be at CB01, which is the abbreviation for the main facility. It would be a 01A, which is floor one space A, and then the interface itself would be data port 88. And by having that entire label, you can reference that, hand it to a third party, and they know exactly what port you’re referencing.
It’s very easy these days to also document and keep a database of all of this information. So if anybody needs to know exactly how many ports may be in a particular building or particular floor, you can look that information up very quickly. The same thing applies for the servers that we might be using. There’s a physical device that’s in the data center. And you need some way to tell someone else exactly which component you’re referencing.
You can do that by creating a unique system ID for every device. It may have an asset tag associated with it. There might be a system name and a serial number. And you want to make this clearly visible on the devices. These servers have physical tags associated with them, along with serial numbers and information written on the device themselves. So you can hand someone else the documentation of exactly what you need to have performed on that exact device, and this makes it very easy to find this device in the rack.
Here’s a better look at these servers. You can see there’s barcodes or asset tags on these device. There’s labels that identify the name of the device. And then there’s an extra tag associated with the device as another piece of documentation that someone can reference when they’re looking for that individual server.
Most organizations have a number of WAN circuits that may be coming into the building. So it’s a good idea to also label all of those circuits as well. WAN circuits can operate normally, and then suddenly not operate at all. Not because of something that’s inside of your building, but with something that might be between your site and the other one, which you obviously have no control over. Because of that, you’ll need to document exactly which of those WAN circuits may be having a problem.
You need to document the demarc interface for that circuit, the associated CSU/DSU that’s connected to that demarc, and perhaps even the router that’s connected to the CSU/DSU. You want to know exactly what circuit ID is associated with that way in connection, the WAN provider and the phone number for their help des, and then perhaps an internal reference name that you can use when putting internal reports together.
If you have a monitoring system, you may want to include all of this information with the monitoring system. And if an error or an alert is created, it will have all of the details you need to be able to communicate with the WAN provider. The patch panels that are in our network closets have a number associated with a port that’s somewhere out on the floor. We want to somehow associate and document those port numbers on the patch panels themselves. You can see some documentation on this patch panel. And from here, you know exactly what port on the floor is associated with which port on the patch panel.
These numbers are usually unique. They usually increment in a particular area. And they may be geographically descriptive. There may be an east or west designation. In some IDFs or MDFs, there may even be a blueprint of a floor that documents exactly the numbers for every cube in every office.
Another good piece of ongoing documentation is a baseline of how the network is operating. With this baseline, we’re able to understand the normal utilization for the network, what the normal response times might be, and what type of throughput we would see at certain times of the day. From here, we can look at what’s happening now and compare it to what happened in the past. We can plan when we’re going to hit certain thresholds based on the activity we’ve seen in the past, and that might help with our budgeting process. We may not want to increase the overall bandwidth available on a network connection and pay the extra money until exactly the point it’s needed by the organization.
Here’s some baselines that have been created for a web server. You can see the amount of accesses per day over the last day or so. Here’s the Apache accesses by week. And you can see the individual days and exactly how many accesses have occurred. You can also see by month and even by year. This might give you an idea of what times of the year or times of the month may be busier than others, so that you can adjust the resources required to provide services on your network.
It’s also useful to have documentation of what devices you might have on your network. You need a record of every single asset. So this would include the routers, the switches, the cables, any fiber modules, CSU/DSUs, and any other network equipment that you have in your infrastructure. This is not only going to help you understand what equipment you have and where it may be located, but it will help your accounting team understand how the depreciation of these devices will be handled.
Some organizations will even add an asset tag to the device. So not only are you keeping a database of where this device is, you have a tag on the device that clearly identifies and has a visible tracking number of exactly how this is associated back to your database. The database itself is probably going to be a formal inventory management software. This could include not only the inventory of all of your devices, but it might include helpdesk and reporting functionality as well. And as the organization gets larger, you can add all of the new assets into the database and you’ll know exactly where this inventory happens to be.