How to Draw Clear L3 Logical Network Diagrams

The biggest single problem I’m seeing when working on enterprise networks is the lack of L3 logical network diagrams. Most of the time I’m facing situations where a customer doesn’t have any logical network diagrams to give. L3 diagrams are vital for troubleshooting or for planning changes. Also, logical diagrams are in many cases more valuable than physical ones. Sometimes I see “Logical-Physical-Hybrid” diagrams that are mostly useless. If you don’t know your network logical topology, you are blind. Generally, it seems it is an uncommon skill to be able to visualize networks logically. For this reason, I’m writing  about drawing clear logical network diagrams.

What information should be represented in L3 diagram?

To be able to draw a logical network diagram, you should know exactly what information is presented in which diagram. If you don’t, you’ll start to mix information and end up with those useless hybrid diagrams. Good L3 diagrams consist of the following information:

  • Subnets
    • VLAN IDs
    • Names
    • Network address and subnet mask
  • L3 Devices
    • At least Routers, Firewalls, VPN devices
    • Most important servers (Such as DNS servers etc.)
    • Their IP -addresses
    • Logical interfaces
  • Routing protocol information


What information should NOT be represented in L3 diagram?

Following information should not be presented in L3 diagrams, because it really belongs to another layer, and therefore should be presented in that level documentation:

  • Basically all L2 and L1 information
  • L2 switches (Only the management interface can be presented)
  • Physical connections


Symbols used in L3 diagrams

Generally, logical symbols are used in logical diagrams. Most of them are self-explanatory, but since I’ve seen mistakes, here are a couple of examples.

  • A subnet is represented as a pipe or line:

subnet

  • A VRF or some area not exactly known is represented as a cloud:

cloud

What information do you need to be able to draw L3 diagram?

To be able to create a logical network diagram, you first need to have following information:

  • L2 (or L1) diagram – presenting physical connections between L3 devices and switches.
  • L3 device configurations – text files or access to GUI, etc.
  • L2 device configurations – text files or access to GUI, etc.

Case Study

In this case study, we are using a simple network as an example. There are Cisco switches and Juniper Netscreen firewalls in the network. A L2 network diagram is provided, as well as the configurations from most of the devices. Configuration files from ISP routers aren’t provided, as many times in real life you won’t get them from the ISP. The L2 topology of the network follows:

 

L2 Network Diagram

Here are configuration files from devices. Only details needed here are included.

asw1

asw2

asw3

csw1

csw2

fw1

fw2

outsw1

outsw2

 

Gathering information and Visualizing it into drawings

Okay – now that we have all the information needed, let’s start drawing.

Step-by-Step drawing process

  1. Collection phase:
    1. First open the configuration file (ASW1 in this case)
    2. Pick-up every single IP-address definition for the interfaces. In this case, there is only one address (192.168.10.11) and it has a mask of 255.255.255.128. The name of the interface is vlan250 and the name of vlan 250 is In-mgmt.
    3. Pick-up every static route from the configuration. In this case, there is only one (ip default-gateway) and it is pointing to 192.168.10.1.
  2. Drawing phase:
    1. Now, lets visualize all information we have picked up. First, draw a device that has the name ASW1. ASW1 happens to be switch, so we’ll use the switch symbol.
    2. Draw a subnet (pipe). Give it the name In-mgmt, VLAN-ID 250 and network address 192.168.10.0/25.
    3. Connect ASW1 and the subnet symbols together.
    4. Insert a text field on the line between ASW1 and the subnet symbol. Add a logical interface name and IP-address in the text field. In this case, the interface name is vlan250 and the IP-address last octet is .11. (It is common to write only the last octet of an IPv4 address because the network address is already seen in the drawing.)
    5. There is another device connected to the subnet: In-mgmt. Or at least, there should be. We don’t yet know the name of the device, but it’s IP-address is 192.168.10.1. This is because ASW1 has a default gateway pointed to that address. So, let’s draw that device in the diagram and give it have a name of “??” for now. Let’s also add its address of .1 into diagram. (BTW, I always mark unclear information in red so that you can immediately see what information requires clarification.)

At this point, we have diagram like this:

partial-network2

Repeat this step-by-step process for every network device. Pick-up all IP-related information and visualize it in the same diagram: every IP-address, every interface and every static route. During the process, your diagram will become increasingly accurate. Be sure to draw devices that you don’t yet know, just like we did above with address 192.168.10.1. Once you have done this for every network device you know, you can start to figure out the unclear information. You can verify from MAC and ARP tables if there is a device in place or not. (I wonder if I should write next blog post around that subject?)

Finally, you will have a logical diagram like this:

L3 Network Diagram

Conclusion

It’s so simple to draw logical network diagrams, once you know a suitable method. It is a time-consuming, manual process, but there is no magic. Once you have a complete L3 diagram, it is not hard to keep it up to date. The benefits are well worth the effort.

  • You are able to plan changes quickly and accurately.
  • Troubleshooting is easier than before. Let’s say someone needs to resolve a problem where service is not working from 192.168.0.200 to 192.168.1.200. By looking at the L3 diagram, you can immediately say that it is not caused by a firewall.
  • You can keep your firewall rulebases correct. I’ve seen situations where firewalls have rules for traffic that they are never going to route. That clearly shows that network’s logical topology is not known.
  • Usually, once an L3 diagram has been completed, you will see immediately which parts are not logically redundant, etc. In other words, the L3 topology (and redundancy) is as important as physical redundancy.
Jaakko Rautanen

Jaakko Rautanen

Jaakko is a network engineer currently working in the enterprise field as a consultant. His specialties are troubleshooting, network surveys, documentation and to carry out major changes. In the past he used to work in Managed Services Field by managing LAN, WAN and Security equipment. His motto is: "There is not a technical problem you can't solve."
  • http://twitter.com/Network_Keith Keith Miller

    Very well written and timely blog post. I have struggled with diagrams up to this point in my career. The biggest question I usually have is “Am I putting too much information or not enough?” I appreciate the time you took to pull and show configs while also giving diagrams to illustrate.

    Do you think it would be appropriate to throw things in like routing processes if you are using a dynamic routing protocol? If so, what do you think would be the best way to fit it in?

    Again, excellent job! Looking forward to more from you.

    Regards,
    Keith

    • Kevin Gray

      You must create separate diagrams for physical and for logical. The physical diagrams show how things are physically connected and how they are racked. The logical diagrams show how traffic gets from point A to point B. I agree 100% that hybrid diagrams don’t work. Also, when doing your logical diagrams, think in terms of North-South, East-West. We often talk about traffic in those terms. North-South traffic is like from the Internet into your site. This could also be from the MPLS WAN into your site. This should be top to bottom in your logical drawing. (like how Jaakko drew it) East-West traffic is traffic that passes between environments (or even tiers) within your site. (perhaps between two customers you’re hosting, perhaps between the web, app, and database tiers) This should be left to right in your logical drawing.

    • Jaakko Rautanen

      Thanks! It really took time to write this.

      My opinion is you can put more information in the diagram if it is valuable and you will keep it up to date. Dynamic routing protocol information surely is that kind of information. Probably most visual way to present routing protocols is to draw colored areas(circle, rectangle etc) to the background. You can put other information (such as AS-number, protocol name etc.) as a text inside area. You can use different colors for each routing domain.

      • http://twitter.com/Network_Keith Keith Miller

        Thank you for the reply and that makes sense. I’m going to start experimenting with new ways of creating diagrams for our team. Thanks again for this post!

  • Stefan

    As Keith said it already – indeed a timely posting. One comment I would have is rather a Q: has anybody ever seen a need for application(s)-oriented network diagrams? I see such, in conjunction with “monitoring maps” products such as solarwinds, useful in order to provide easy access (“health” dashboard view + drill-in details) to info for the critical points in the “path” of the app flow (access switch ports, PoCs, trunks, FWs, LBRs, WAN circuits, etc. -> by monitoring errors & discards, CPU, memory, utilization, etc. – as pertaining to each [inter]-network device supporting the app). These could also provide immediate ops use, for access to specific network info supporting a specific app, especially in cases of “performance” issues. In the end, any network is as good as the apps running on top of it :-)

    • Cashell

      An Application Flow diagram is absolutely critical when troubleshooting any large-scale or “enterprise” type application. If you don’t know what pieces are involved, where they live, how they’re talking, and all that, you’re going to have a nightmare trying to understand a failure (especially if it’s performance related, and not “down”).

      I typically see that as separate from monitoring, though. Diagrams are documentation. Some monitoring tools can provide or assist with diagrams, and some do support “service” definitions, where they can monitor a collection of objects together to help you get status information for an application, but I think it should complement your network and application flow diagrams.

  • Techkid

    Very nice article. Well laid out

  • http://twitter.com/wmann Michael K.

    So you but all access switches which do only L2 forwarding in the L3 diagramm because they have an IP address in the managemet vlan? I think it makes more sense to have only L3 devices in the L3 diagramm.

    • Jaakko Rautanen

      Well they are L3 devices from management point of view.

      • Jaakko Rautanen

        I put management interface of L2 switches into L3 diagram because of I always want to see visual way which path management connection is going. This is must when making changes.

  • john

    Jumps are a carryover from electrical engineering circuit design that were abandoned over 20 years ago (for good reason), and could only be relevant in designing a circuit to reflect paths of physical conductivity. So much for leaving out L1 from an L3 diagram.

    A pipe for a subnet? Has anyone looked that the diagramming used to design the Internet? Apparently not.

    I won’t even comment on how well the end product is to read. It does succeed in communicating, if clumsily. Sadly, unlike electrical engineering, there appears to be no real independently consistent standards for network diagramming. Just whatever visio tells you to do, which is just disappointing.

    • Conrad

      Not quite understanding what you’re trying to say here John – particularly your middle paragraph about subnets. Do you have any examples you could point toward that illustrate what a network digram should look like?

  • koppelo

    This is a dumb question, but routing between 192.168.x.x networks occurs on the switches, right?

    • Jaakko Rautanen

      Right, and in CSWs to be more precise.

  • Ryan Milton

    Wow, how timely! I was recently hired to a company that has outdated info. I’m the new guy, so we/I need this kind of “visual.” I didn’t know where to start my own diagramming. One question: How do you represent accurately when multiple sub-interfaces are each in a different vlan on a router?

    • Jaakko Rautanen

      Sorry I forgot to add logical interfaces to L3 diagram. Usually I add them.

      Subinterfaces are logical L3 interface in most cases. Usually I place them next to the IP-address of the interface.

      There are two things to remember:
      1) Only L3 interfaces to L3 diagram. (Sometimes physical interface can be logical L3 interface at the same time)
      2) In some devices L3 interface can be SVI (Vlan5) or subinterface (G0/1.5) or same as physical one (G0/1). But every time L3 interface has IP-address.

  • Amelia

    Nice article. Helped a lot!

  • nice guy

    Where is the Subnet “pipe” shape located?

    • Jaakko Rautanen

      It is called “ethernet” in the MS Visio

  • Oscar Bruno

    I was looking for how to make vehicular networking diagram and found it with Conceptdraw pro. I must say that I’m impressed with this product.

    Checked out ConceptDraw this morning. A couple of observations

    1) It appears to be quite powerful
    2) They offer different packages relating to different needs
    3) As a non-tech ancient person I’m somewhat figured it out, it seems not complex
    4) It gets a 4 Mouse rating from MacWorld.
    5) It can work with Visio

  • A.C.

    This is a great post. Question, how would you represent your wireless infrastructure? Would you show the connections on the L1/L2 diagram, break it out into a separate wireless diagram, or move them into the L3 diagram. I am mostly concerned with the APs, and where applicable, the controller.

    Thanks,

  • evadlegne

    I know this post is getting a little old but I wanted to ask one quick question I didn’t see asked in the comments (maybe I overlooked it in the article too). When creating a logical diagram and you are labeling interfaces and you have a dozen or so VLANs tagged on a single interface, what’s the best way to show that?

    I probably don’t follow many of these practices here (as I should be). My process is simply to present the scenario. What is it you are trying to explain or show? If you have a good answer to this question and you accomplish this in a neat, organized, easy to read, network diagram then I think the mission was accomplished. If only you can read your diagram than you have failed.

  • Hal Martin

    Outstanding. Really good post, great advice, and very much needed in the industry. Thank you for your thoughts… Best, Hal