You just purchased a fancy new bookshelf from your favorite store that gives furniture funny names. You carefully place the gigantic box for this bookshelf, or as they call it a “bookenspiel” in your living room and cut the box open. There are a so many parts! The manufacturer seems to have crammed in half the world into the box. Building this bookshelf looks a bit daunting now. At the store, the bookshelf did not look like it would be this complicated to build. You continue taking bags of parts, boxes of parts and pieces of wood out. If it was not for the instruction manual you would have flung everything out of a window. The instruction manual lets you build the bookshelf. It takes half a day, but you get it done. However, imagine for a moment if there was no instruction manual. This half a day build becomes a full day or much longer. As a matter of fact, it might be so frustrating you give up. That instruction manual makes a huge difference. Documentation matters. It matters not just in the build of a bookenspiel, but in a network environment. It matters in all of IT. Even if you have a small local network or an enormous world-wide network, documentation should be required. You might say “Hold up; I know this network inside out! I don’t need documentation.” That might be true. However, documentation is there for those that come after you. You will not be there forever. Others on your team might not have that gigantic brain you have either.
I am a lover of all things written. I believe it is important to properly document what you are working on. It not only helps you when are trying to reference certain projects or look back at a specific item, but it is essential when troubleshooting. Portions of my study for the CCNP certification focused on proper documentation and making sure you have it handy. This really does apply well in the real world. When I started with my current company, the first thing my manager dropped on my lap was a 400+ page manual with information on all of our locations around the world. Yes, there is an online copy. He also gave me 100+ Visio tabs with all kinds of network diagrams. I definitely could not complain that I had no information. I had plenty of it. I was 110% fine with it. It was exactly what I would have written up if it did not exist. The first month or so, in between projects, I dedicated time to go through the network diagrams to ensure they were accurate. This meant I visited each piece of gear and verified all the links, neighbors, etc.; Even though the documentation existed, it came before my time. It was important to verify it. Of course, corrections were needed. If an issue had occurred and I had to rely on a certain diagram, inaccuracies would have added another layer to my troubleshooting.
There are various types of diagrams you can draw up for a network or even the way an application works/communicates. Here are some of the ones I make sure exist for each of my sites:
Physical Diagram –
This is usually the one everyone works on first. How is equipment physically connected to each other? This info can be gathered by physically looking at the devices or using helpful protocols like CDP or LLDP. Even with a small network, you need to know what cable connects to what interface. It will save you headaches during configuration. Your diagram can show physical closet separation as well.
Logical/L3 Diagram –
Lets say I show you a physical router. Without actually looking at the config, can you tell me what networks the router hosts? Unless you are a psychic, probably not. The goal of this diagram is to show you what subnets are reside on what devices. Do devices share a network? What is the gateway for a specific network? Do you want to call our specific circuit types or bandwidth? This diagram will show you that information.
Routing Diagram –
So the logical diagram shows us a bunch of subnets, perhaps on different devices. How do these subnets communicate with each other? The Routing Diagram works closely with the Logical/L3 Diagram. Either of these can also have information on the various access-lists that might exist on a device.
Application Diagram –
Depending on how complex an application might be in your environment, you might want to draw up a diagram on how it moves around the network as well. If its intricate enough, you can write up information in a separate manual as well. Below is a diagram of how some domain controllers would connect out to Cisco Umbrella.
There are all kinds of diagrams out there. Depending on the size of your environment, putting these together will take some time and work, but it will be worth it. Then you can someday dump a 400+ page doc on someone’s lap too!