Draw a data center network diagram that you will actually use
Ask any network engineer what their least favorite job is, and most will refer to the documentation. Documentation, especially the data center network diagram, is often difficult to create and, quite often, even more difficult to maintain.
Physical topologies generally bear little resemblance to logical diagrams that show the true flow of the network. The trend is generally to make diagrams apply to all audiences, which can lead to massive diagrams covering all aspects of the network. Perhaps the biggest challenge of all is keeping the data center network diagram, or WAN diagrams, up to date with accurate information – this could be a full time job.
There are few things you can do to make network diagrams more manageable.
Choice of data center network diagram
First, decide what type of diagrams you will actually use. A single network environment might have four or five diagrams, each representing different aspects of the topology.
A physical network diagram describes hardware connectivity. Logical diagrams describe different network paths. You can have one physical diagram with several logical diagrams. Be careful, however, not to be too excessive; a diagram that is not used is a diagram that will not be updated.
I often find that physical topology diagrams are not commonly referenced. Consider a service distribution switch that may have many pairs of load balancers, firewalls, and suspended routers. It’s nearly impossible to show it neatly on one page, and splitting it up means even more diagrams. The valuable information in a physical diagram resides primarily in the interface interconnects, which administrators can easily glean from other places, such as the switch configuration.
Also, the physical diagrams do not describe the traffic flow. Figure 1, a physical diagram, can be an accurate representation of how data center equipment is wired. However, it does little to describe the actual traffic flow, as shown more accurately in the logic diagram in Figure 2.
Logic diagrams become even more important when you consider that many devices support constructs such as device contexts and virtual routing and forwarding (VRF). In Figure 2, physical firewalls support multiple contexts and the switching infrastructure supports multiple VRFs. Because network traffic is directed through Virtual LAN (VLAN) tagging, the physical diagram shown in Figure 1 is accurate, but certainly not as useful as Figure 2. data easily shows which VLANs are relevant for which devices and device contexts or VRFs. In addition to this diagram, there may be three or four other logical diagrams to describe environments configured on the same physical device, such as VPN access or outbound browsing. Although not all networks are constructed this way, it highlights the fact that not all types of diagrams are equally useful in all cases.
Once you have decided which type of network diagram best suits your needs, determine what information is relevant for each diagram. Include only relevant information. The example in this text highlighted the importance of calling VLANs for each network segment. Considering the specific architecture, it is important to have this information in the diagram along with the firewall context or VRF to associate with these VLANs.
Trying to document things that are subject to change only creates more work for the engineer or architect. For example, you are unlikely to need each individual virtual IP (VIP) address defined on the load balancer in the diagram. However, consider defining the subnet used for VIPs in general in the diagram, so that you can quickly identify and locate it. Again, if you need more VIP details, there are better places to get that information than the data center network diagram. Other important pieces of information to call on a diagram include policy-based routing or the web cache coordination protocol that can intercept and modify the native routed path.
Update this diagram before you need it
Once you have drawn relevant diagrams for your data center, the next question is how to keep them up to date.
Many tools are available that can not only create network diagrams but also keep them up to date. While that sounds appealing, it’s not without its issues. Most of these tools rely on device discovery to create accurate network maps and determine traffic flow. Discovery is not always a perfect process and the tool can be misled or blocked by devices such as firewalls or other security devices. Although diagramming tools can be useful, I find that many of my network diagrams are relatively static and require little work to keep up to date.
No two networks are the same. Much of what is required in your diagram depends on who will consume it. So while I almost never use physical diagrams, other teams such as data center facility managers may only be interested in physical topology and have no use for logical diagrams.
Most network engineers don’t want to spend their weekends creating and maintaining diagrams. By concentrating your diagrams and limiting their scope, you ensure that a single network change does not require you to update many diagrams. Also try to summarize information associated with a higher rate of change and then reference it elsewhere outside of the main data center network diagram. None of this will take you completely out of the diagramming game, but it can help change the ratio of engineering time to documentation.