A network is a dynamic, living entity. It changes based upon business requirements and needs to be flexible and scalable. Technology jumps ahead by leaps and bounds and as it changes as does the requirements of out networks.

Documentation is something that is rarely kept up to date and if it is more oft than not it is in accurate. I thought I would post some documentation centric posts up to share with some of my processes.

Logical vs Physical

The important point here is distinguish what you are looking at. A physical diagram looks at the physical connection between devices and can include information such as interfaces, medium, and rack/site location. A logical diagram can include information such as IP addresses, traffic flow and type, access control, VLANs, and more. It is very important to maintain up to date copies of both as they are useful in team environments, provide great top down view. Here are two examples. One a logical and one a physical.

Lets get physical!

As you can see the physical diagram includes information about its exact whereabouts, layout, port mappings, physical attached location. Nothing about vlans, dmz, or configuration information.


The logical diagram represents the areas and connections. My logical diagram shows information such as subnets and how the network is.

Document ALL the networks

Every little change, no matter how small is important. You could be changing some route-maps one day, get hit by a bus on the way home and that knowledge is lost. Yes we will go to your funeral and then rue your name when we cannot figure out why you chose do to what you did. Information that you may have found irreverent or when you think to yourself  “Gee, why would someone want to know this?” may come in handy when you find your DC burnt down, DR scenario, or scoping extra power requirements.


My documentation motto of “Even the smallest change requires documentation” I believe is a good step. By updating these evolving documents you won’t be lost next outage and have a better understanding on the network. I recommending all new people to jobs especially to do this as you find that you have the most to learn and gain. If there is something missing, make it up. Document and investigate yourself. I bet your managers and co-workers will not mind at all.

4 thoughts on “Physi-o-logical

  1. I couldn’t agree more. I would love to see Cisco include a little ‘nag’ message line “Did you document this change?” right after you issue a wr mem command.

    1. With Juniper I know ppl who have done that with a commit script. Im guessing on IOS you could use an EEM script to detect config changes and send a “friendly reminder”

      1. EEM script would be nice. Harder but better practice in the long run would be having engineers and staff commit to a cycle of update upon writing something. I know even our third party designers aren’t as diligent – and they deal with dozens of customers a day.

Leave a Reply

Your email address will not be published. Required fields are marked *