Did you know?
With images, you can convey so much more information, in a quicker and more effective way, than you can with text. No wonder there’s a saying: “A picture is worth a thousand words.”
And how helpful are that thousand words -- trapped in Excel spreadsheets -- when it comes to network operations? It seems logical to harness the power of images for another purpose: helping network and security engineers to better manage their infrastructure, improve their visibility of it, and simply be proactive rather than reactive. In this article, we will explore the power of the topology diagram for the network engineering and operation.
First, let’s define what we mean by network topology. Techopedia describes the concept as following: “Network topology refers to the physical or logical layout of a network. It defines the way different nodes are placed and interconnected with each other. Alternately, network topology may describe how the data is transferred between these nodes.”
With this definition, we already see a demarcation between the physical topology (how the nodes are physically connected) and the logical one (how data are transferred between the nodes, what protocols are in place). The network diagram is a schematic depicting the layout of the topology - a way to represent the topological reality.
For as long as there have been computer networks, we have drawn diagrams to represent the topologies – famous examples include the ARPA network, forerunner to today’s Internet which in 1969 consisted of just four nodes!
Indeed, the method of drawing out a topology has long been used to teach people how network connections work – see this example taken from Bob Metcalfe’s original notes on Ethernet in 1973:
Representing the live network in this way is clearly incredibly useful from a documentation standpoint. However, the immediate limitation of these diagrams is their static nature. When a change is applied on the production network, the same change needs to be echoed across all of the relevant network diagrams. What if the engineer forgot to update the diagram? What if another engineer modified an interconnection but didn’t tell the person responsible for the diagram maintenance?
The diagrams easily become obsolete and thus can no longer be trusted by the administrators. We often see the case of enterprise organisation which maintain their topology-based documentation simply because it’s mandatory but don’t actually rely on.
Maintaining the diagrams manually is extremely time-consuming. At the same time, the negative effect of unreliable documentation on the productivity of your engineers can be profound. When an incident happens, engineering teams must spend valuable time to make sure the information depicted reflects the actual reality before they can then use it.
When engineers don’t spend this time validating the information and base their decisions on wrong or incomplete information, they can make wrong decisions based on outdated documentation, effectively compromising network stability and security.
Here’s what IP Fabric does differently. We provide you with the exact representation of your network, automatically updated with the most recent data taken directly from the source, that is, your devices. Furthermore, you can select the most relevant view aligned with your immediate technical and business needs.
The effort spent on creating and updating those diagrams is completely removed, so you can shift your focus on interpreting the diagrams for administration purposes rather than maintaining and validating them.
Why are engineers spending so much time on creating those diagrams, anyway? The main answer to that is because it is easier for administrators to interpret the current state of the network in that way. If a link is down, a node doesn’t forward the traffic, or some configurations have changed, you can easily compare the current status and apply it on your diagram. This helps to understand the impact of this modification from a connectivity perspective.
Speaking of perspective, the greatest asset of IP Fabric diagrams is that you can visualize your network in different dimensions, each dimension being part of a certain logic and providing you with specific insights. This enables you to troubleshoot an incident and prepare for a change with a level of certainty.
To be clear, let me specify what dimensions I’m referring to. The first one being the protocol level; do I have to represent the physical interconnection between my network devices, do I rather represent how my switches, or my routers are logically communicating within each other (whether on Spanning Tree or routing protocols like BGP).
A different dimension – and very important in case of troubleshooting – could be traffic visualization. Instead of representing the interconnections of nodes, one can represent the path the packets will take from A – the user requesting a service – to B – the server where the service is hosted. Along the path will be displayed all devices crossed by the packets, also included if the firewalls allow that route or not. Having access to a network traffic vision allows one to identify the bottleneck and troubleshoot much faster.
As you probably know, in case of a service connectivity incident, the first to blame is always the network. Having the visualization that packets are reaching the server without any problem also helps to prove once and for all the innocence of the network and avoid this back-and-forth blame between the different IT departments.
Let’s now suppose one is investigating a critical incident which is directly impacting your business. The questions one needs to ask are: Where is the incident located? What has been impacted by this incident? How can I quickly fix the issue? When investigating the root cause of the problem, the question would be: What has changed between the incident and the moment when everything was under control?
In this case, the time dimension also can play a role in networking management. It is great to have an accurate actual representation of your network but it’s equally important to keep track of how your network was displayed previously.
IP Fabric’s automated Network Assurance platform has been built on a snapshot-based system, each snapshot depicting the network at a certain time point. The interface enables you to browse old snapshots, compare them with each other, identify the root cause, and make sure the root cause cannot impact other areas of your environment.
The last dimension concerns intent verification. An intent is a desired state or condition for the network – for example “I want my network to be fully redundant”, “I want all my production network devices to be AAA enabled”, or “no BGP peers should be configured that doesn’t fully establish.” Imagine being able to apply the intent to your diagram, overlaying color-coding: green showing compliance, yellow meaning warning, red means critical problem.
Having access to all those dimensions is a great asset to your network team, but the real power for the Network Management is to have the flexibility to switch from one perspective to another, being able to combine different dimensions, save the view, and share it with the stakeholders.
The version 4.0 of IP Fabric (to be released in coming days) will heavily focus on enhancing these visualization capabilities. Our development team have put in significant effort to enable our users to represent graphically very large network sites, reorganize the nodes and utilise the above-mentioned dimensions options in a quicker and simpler manner.
To conclude it is worth repeating this point: the network diagrams are simply a reorganization of a dataset previously collected, so our brain can easily and faster interpret that information and make effective decisions based on its interpretation.
If the dataset provided has wrong information, the whole diagram – whether created manually or dynamically – loses its purpose, and can no longer be trusted, having a completely counterproductive effect. This is the reason why data collection and sourcing are hugely important – a key feature of IP Fabric’s functionality.
By building the platform, the founders of IP Fabric wanted to make the life of network engineers easier by eliminating the common problems of non-reliable documentation and time-consuming diagrams drawing. IP Fabric always ensures that the data collected by the system are fully reliable and easily accessible. What could be a better source of information about the network topology than the network devices themselves?