Rack Layout diagram

A rack layout diagram shows the server room or wiring closet racks with all of the
equipment and patch panels. If you have equipment mounted to be accessible from
both the front and back of the cabinet, then you should have diagrams for both the
front and the back.

A rack layout diagram should be meticulously accurate about what equipment is

mounted in which numerical position on the rack.

You’ll use a rack layout diagram when planning for where to put that next piece of
equipment, as well as when talking to technicians and other IT staff about where to
find things. It’s extremely important when you’re telling somebody to shut off the
power to a particular device that they get the right one.

Rack layouts can also specify things like which aisle is hot and which one is cold, as well
as power distribution. However, I don’t recommend putting patch cords on a rack
diagram. That information is likely to change regularly, and it only clutters up the
picture without adding much useful information. I’ll talk about how to record patching
information later.

Photo: Banalities  on Flickr

Wi-Fi diagram
If you have an important Wi-Fi component to your network, that should be
documented. For Wi-Fi, I like to see floor layouts showing the physical locations of all
access points (APs), preferably with RF radiation patterns indicated. This is particularly
important if there are any special antennas in use with non-symmetrical radiation
patterns.

As well, a good Wi-Fi diagram shows all of the SSIDs along with their intended
purposes and security mechanisms. And if there are central Wi-Fi controllers, this
information should be indicated in a text box.

Cable plan
A similar diagram that comes in handy whenever you’re troubleshooting an office
network problem (like finding the guy who created a loop by cleverly plugging two jacks
into the same unauthorized workgroup switch) is a cable plan. This diagram allows you
to map the usually inscrutable jack numbers to physical locations in your building.

Routing protocol diagram

Another useful diagram is a routing protocol design. If there are separate routing
domains that don’t directly exchange routes with one another, I often make them
separate diagrams. For example, if I have an internal OSPF or EIGRP routing domain
and an external Internet BGP routing domain, I always make these separate diagrams.

The routing protocol diagram should indicate all autonomous systems, internal areas,
and redistribution points and it should clearly indicate special features such as route
tagging or filtering.

Security diagram
Another special-purpose network diagram I like to include in my documentation
package is a security view. It’s similar to the Layer 3 diagram except that it focuses on
things like the Internet edge, as well as any internal or Internet DMZs.

Of course, all special security equipment needs to be clearly indicated on this diagram.
The standard Layer 3 diagram includes firewalls, but the security diagram needs to also
include any special security probes, IDS/IPS devices and passive or active taps. I also
want to see central management devices like SIEMs and log servers on this diagram. If
there are any important NAT rules or firewall rules, it’s often useful to indicate these as
well.
Photo: Haria Varlan  on Flickr

Cloud services diagram

If you have any cloud services like AWS, you should document them. Cloud service
diagrams need to include all of the security zones, and should probably also include all
of the virtual servers in the environment.

If you have any special network security infrastructure in your cloud services like
firewalls, load balancers, or WAF virtual devices, they need to be clearly described so
that the next person can easily understand what you’ve done and how to manage it.

If you have a VPN between the cloud and your internal network, it’s extremely
important to include that feature on the diagram because it’s here the most sensitive
information will typically be sent, and it’s also a potential backdoor into your network.

Patching table
In a data center, you should document your patch panels. Data centres usually have
many different kinds of links, from fibre and copper to perhaps some twinax or
Infiniband. And every device is both important and potentially unique. Mistakes could
take down the entire network.

Conversely, the patch panels that support all of the users in the west wing of the third
floor probably has most of those users connected to identically configured switch ports.
It’s certainly useful to keep a good patch table for it, but it’s really not as critical as the
data centre patching information. As I mentioned earlier, though, you do want to have
a physical map showing where all of those office cables go so you can troubleshoot
problems down to the end user.

At a minimum, the patching documentation should show, for every port in the panel,
exactly what’s connected on the other end of the cable. If the device or panel on the
other end has lots of ports, then the destination port should be uniquely identified along
with the device.

The documentation should also indicate what type of patch cord is used. Is it Category
6? Is it fibre? If it’s fibre, is it single mode or multi-mode and what are the connector
types on both ends? If the patch cords have unique identifying numbers, which is a
good practice, those numbers should be included as well.

Asset tracking
It’s very useful to have a table of asset tracking information. For this, I’m usually not
too concerned about commodity items like phones, printers, or workstations. Instead,
the list should include the critical pieces of infrastructure like switches, routers, and
firewalls, as well as any critical pieces of server hardware.

In the asset tracking information table, I want to see manufacturer names, models,
serial numbers, and license numbers. You also want to include support contract
numbers so you know who to call if something goes wrong.

Photo: Pixabay

Password vault
One important and useful piece of documentation is a password vault. If you have static
administrative passwords on any of your network appliances, store these credentials in
an encrypted vault of some kind. In general, I prefer the devices to use a central
authentication system like RADIUS or TACACS, but inevitably there will be some devices
that need static passwords. And in most cases, you’ll also have fallback passwords that
can be used if the central authentication system breaks.