On Network Diagrams

Update: This page desperately needed some diagrams. So I've added some. -- Mark, 2008 May 26

I'm a consultant for telcos and ISPs who do VoIP. Nearly all of my customers have diagrams. They're always Visio. We use their diagrams to help do network design changes or troubleshooting.
At nearly every customer, as we start studying their diagrams in detail, they'll say, "wait, that's not right. This doesn't even show the FL-2100 we installed two years ago!" Or "no, there must be more cables than this. There's no way this is right." However, I still learn things from the diagrams, especially when I have commentary to help understand. And anything that's important must be re-checked.


Physical Layer Diagrams

Nearly everybody maintains *physical layer* diagrams; i.e., each box on the diagram represents a physical device, and each line represents a cable. Physical diagrams are nice, especially for troubleshooting wholesale outages, or counting available ports, or designing fault tolerance. And they're fine for 1994-era IP networking -- all hubs, no VLANs, one IP address per device.

But physical diagrams strain to convey:

  • VLANs. Which VLAN is this port assigned to? Is it a VLAN trunk?
  • Subnets. What subnet is this device a member of?
  • Roles. Which devices are doing routing? Switching? Basic servers?
  • Multiple IP routing tables per device. E.g., Cisco VRFs / MPLS VPNs.
  • Devices with numerous IP addresses within each IP stack.

    Visio users like to insert little pictures of the actual equipment. I don't do that; at best it's just pretty, and at worst it's distracting and doesn't print well.


    VLAN/Subnet Diagrams (Or, "how do i represent vlans on a network diagram?")


    VLAN/Subnet diagrams are what's needed. In this form, each box represents a VRF or IP routing table -- typically one per physical device. Each line represents an IP address assignment to a subnet. And at the center, we have some other shape, like an oval, to represent the actual subnets (or collision domains, if you'd like). In clean designs, one subnet is exactly one VLAN. We usually do not actually draw Layer-2 switching equipment in. VLAN/Subnet diagrams are great for following the paths of packets through the network.

    VLAN/Subnet diagrams of this form have their limitations, too:

  • No good at representing layer-2 redundancy
  • Not good at identifying available ports.
  • Not good for inventory; not every physical device is shown
  • They don't show what data flow is normal or expected.

    More tricks are needed when VRFs are involved.

    An alternate approach is to representing VLANs is to color-code the cables on a physical diagram. A blue cable is VLAN 101, a red cable is VLAN 102, a green cable is VLAN 103. This certainly can work as long as your number of VLANs is relatively small. ("Wait, which VLAN is magenta, and which is purple?")


    Application-Layer Communication

    There's yet another valuable abstraction for diagramming networks: Application-layer communication diagrams. These are much like UML Communication diagrams. Here, we don't show any underlying transport, but only the normal communication paths at the Application layer. For any given device X, there's a line drawn to every device Y where X and Y communicate at the application layer. This type is absolutely essential for developing effective firewall and IDS rules. It's also valuable for SIP VoIP platforms, where routing of SIP messages is complex and where it's reasonable to ask, "Where *should* this device be sending its INVITE? To what other devices will it be sending RTP?"