Documenting a network

[Ronni Feldt]

Hi,

I don't know if this is the right place, but here goes.

I'm  about to document a network and before just collecting a lot of  information in some document, I thought I would create some kind of  template. Searching for information on best-practices, good advices,  other peoples experiences, guidelines etc. I havn't found anything that  really works.

This might be because you can document a network in as many ways as you can design a network.

What  I'm looking for is some kind of generic template that is very network  centric, which means it should document "The Network" eg. routers,  switches and so on and not hosts, active directory, printers, storage  etc.

The goal is that a person who have never seen the network should be able to get a basic undestanding of how it works.

Does anyone know where to find such a template, if it exists?

What are your experiences in documenting a network? Which kind of information did you include and how many details?

And did it work, did people use it afterwards or did it end up on some shelf?

[Marvin Rhoads]

There is no common standard or template that I have ever seen. There are however, many common aspects. What to include usually depends on two things - intended audience and amount of information necessary (which is related to #1 in part and driven by your network's size and complexity in second part). You might have a look at some examples such as posted on this external link.

I'm an old school network guy - e.g., one of my jobs defined 'the network' as everything between the wall jack (at the end user side) and the patch panel (at the server side). On the former side lay "desktops" (another organization's job and not "worthy" of network documentation) and on the latter side were "servers" (with their own documentation needs met by yet another part of the organization. That is a bit of a myopic definition from most customers' points of view but it served us as a service delivery model. Thus our documentation boundaries were clear and didn't require we put a lot of information in the diagram like printer names or server locations etc. Mind you this was for a tens of thousands customers size network in multiple locations. So, that level of specialization was fine. We further broke down network documentation between the transport / WAN folks and the local LAN folks. LAN diagrams had all the sites shown with the routers and switches and some VLAN and IP information, a first level notation of system names, management IPs etc. WAN diagrams had link speeds, circuit IDs, etc. The cabling team had their documentation that had things like rack layouts, floor plans, rack elevations, patch panel locations, cable IDs, riser connections documented, etc. In a large multi-national network environment like that we lived by our network documentation. It was updated regularly, version controlled and parts were used by every engineer or admin every day.

So, long explanation without a clear answer, yes?

My advice - decide what's important and makes sense in your environment. Capture that. Put on a diagram what makes sense to see visually. Put in a spreadsheet / table / Wiki page / Sharepoint portal etc. what makes sense to view tabular form. Make reference to one from the other and vice versa. Above all have in place a PROCESS to keep it current. Communicate and follow that process among all folks who have the ability to change any of the aspects or the need to use them. Remember, the tool (or technology) is only one part of the equation. Without the process and people knowing about and following it, the best tool / ideal diagram is quickly rendered irrelevant or obsolete.