Draw up a data center network diagram you'll actually use
Creating a data center network diagram is time-consuming but necessary work. Keep the scope narrow and know the priorities of your diagram to save time and energy.
Ask any network engineer what their least favorite task is, and most will refer to documentation. Documentation, particularly the data center network diagram, is often hard to create and, many times, even harder to maintain.
Physical topologies typically have little resemblance to logical diagrams that show the true network flow. The tendency is usually to make diagrams apply to all audiences, which can lead to massive diagrams covering every aspect of the network. Perhaps the greatest challenge of all is keeping the data center network diagram, or diagrams of the extended network, 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.
Data center network diagram choices
First, decide what type of diagrams you'll actually use. A single network environment may have four or five diagrams, each depicting different aspects of the topology.
A physical network diagram describes the hardware connectivity. Logical diagrams depict different network paths. You may have a physical diagram along with several logical ones. However, be careful to not be too excessive; a diagram that isn't used is a diagram that won't get updated.
I often find that physical topology diagrams aren't commonly referenced. Consider a service distribution switch that may have many pairs of load balancers, firewalls and routers hanging off of it. Neatly showing that on one page is almost impossible, and splitting it up means even more diagrams. The valuable information from a physical diagram lies mostly in interface cross connects, which administrators can easily glean from other places, such as the switch configuration.
In addition, physical diagrams don't depict traffic flow. Figure 1, a physical diagram, may be an accurate depiction of how the equipment in the data center is cabled. However, it does little to describe actual traffic flow, as seen more accurately portrayed in the logical diagram in figure 2.
This physical diagram shows an enterprise network layout.
This logical network diagram provides more context than a physical diagram.
Logical diagrams become even more important when considering that many devices support constructs such as device contexts and virtual routing and forwarding (VRF). In figure 2, the physical firewalls support multiple contexts and the switching infrastructure supports multiple VRFs. Since the network traffic is directed via virtual LAN (VLAN) tagging, the physical diagram shown in figure 1 is accurate, but it certainly isn't as helpful as figure 2. The logical data center network diagram easily shows which VLANs are relevant to 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 equipment, such as virtual private network access or outbound browsing. While not all networks are built in this fashion, this does highlight the fact that not all types of diagrams are as useful in all cases.
Once you decide what type of network diagram best fits your needs, figure out what information is relevant to each diagram. Only include relevant information. The example in this text highlighted the importance of calling out the VLANs for each network segment. Having that information in the diagram as well as what firewall context or VRF to associate to those VLANs is important given the specific architecture.
Attempting to document things that will likely change only creates more work for the engineer or architect. For example, you're unlikely to need each individual virtual IP address (VIP) defined on the load balancer in the diagram. However, consider defining the subnet used for VIPs in general in the diagram, so you can quickly identify and locate it. Again, if you need more detail on the VIPs, there are better places to get that information than from the data center network diagram. Other important pieces of information to call out on a diagram include policy-based routing or Web Cache Coordination Protocol that can intercept and change the native routed path.
What exactly does SDN look like?
Diagramming software-defined networks is a hard topic to discuss since most engineers can't agree on what one is.
A software-defined networking (SDN) diagram would be more of a representation than an actual diagram, depending on how you interpret it. If you call OpenFlow or VMware's NSX SDN, then the diagram would resemble any normal one. It's all about depicting things logically in the end.
Update that diagram before you need it
Once you've drawn out diagrams that are relevant for your data center, the next question becomes how to keep them updated.
Making your diagrams focused and narrow in scope helps ensure that a single network change doesn't force you to update many diagrams.
Numerous tools are available that can not only create network diagrams, but also keep them up to date. While this sounds appealing, it's not without issues. Most of these tools rely on device discovery to build accurate network maps and determine traffic flow. Discovery is not always a perfect process and the tool can be misled or blocked by devices like firewalls or other security appliances. While diagramming tools can prove useful, I find that many of my network diagrams are relatively static and require little work to keep current.
No two networks are alike. Much of what is required in your diagram is a function of who will consume it. So while I hardly ever use physical diagrams, other teams such as the data center facilities managers may only take interest in the physical topology and have no use for logical diagrams.
Most network engineers don't want to spend their weekends creating and maintaining diagrams. Making your diagrams focused and narrow in scope helps ensure that a single network change doesn't force you to update many diagrams. Also, try to summarize information that's associated with a higher rate of change, then reference it somewhere else outside of the main data center network diagram. None of this will get you out of the diagramming game entirely, but it can help change the ratio of time spent on engineering versus documentation.
