How do you document a network?

I'm not sure how to ask this question, since I'm not in the field. Say you're a network admin and you leave your job. How does the new guy know where to start?

Solution 1:

It depends on the size of the network, number of users, number of nodes (computers, servers, printers, etc.) and the size of your IT staff, among other things.

It also depends on your goal. Are you documenting the network for training and maintenance purposes, insurance/loss prevention, etc?

Personally, I document my networks in such a way that I know I can derive any missing information based on what is documented. From a practical stance, there is a point of diminishing returns when your documentation gets too granular.

A good rule of thumb I use is that there should be documentation in a known location that is thorough enough that if I get hit by a bus tonight, another administrator can keep the core network running while he/she fills in the missing pieces over the next few days/weeks.

Here is an overview of what I think is most important about one of my networks. For the record this is a Windows-only shop with about 100 users and 5 offices.

• Administrator credentials for all servers. Obviously this should be kept secure.
• IP Addresses and NetBIOS names for any node on the network with a static IP address, including servers, workstations, printers, firewalls, routers, switches, etc.
• Basic server hardware information, such as Service tags or equivalent, total disk capacity, total RAM, etc.
• Major roles of each server, such as Domain Controller, File Server, Print Server, Terminal Server, etc.
• Location of backup tapes/drives.
• Information about the account numbers and credentials for services like remote office voice and data providers.
• External DNS for websites and routing.

If there was anything strange about a setup or workflow that would not be immediately obvious to a new administrator, I would write a short "brief" about it as well.

Solution 2:

I find it's best to incorporate all of the following:

• Prose: A general overview in paragraph form, which helps with initial big picture and also can describe evolution over time
• Tables: Tabular lists, either address-keyed, environment-keyed, or machine-keyed (preferably all of the above)
• Diagrams: Definitely need diagrams with multiple levels of detail. On any decent size network, it's just impossible to sanely capture it all on one page and make it easily digestible. You want one diagram at the global level, with infrastructure devices (routers, switches, tunnel endpoints, etc.), and another several for the compute resources fronted by each of those routers or endpoints.

Additional notes about diagrams... Geographic distribution is an easy way to segment, but you also need logical views based on installation function. Also, label like crazy, making full use of typefaces and colors.

Solution 3:

The most effective and thorough way to start this process is to build it from a disaster recovery scenario - e.g. the building went up in flames and all we have are the offsite backups. What will we need to buy first, and how will it need to be configured?

Kyle already gave great details, but I find that the DR approach helps me to take things one piece at a time.

Solution 4:

Kyle's answer is great advice. At a bare minimum though, you could probably get away with listing out:

• Servers (include hostnames, IPs, and roles)
• Network hardware (switches, routers, firewalls)
• Master password archives (domain passwords, admin passwords)
• A rough document outlining network policies and any strange setups (include here any outliers such as machines which aren't part of the domain(s))