Go back

Do You Really Need Another Single Pane of Glass for Network Visibility

NB author by Phillip Gervasi Jul 21, 2017

Few things make network engineers cringe more than hearing terms like “single pane of glass.” Often, with regard to the various tools we use for network visibility, a single pane of glass is really just another pane glass. But having a single source of truth is still a worthy goal and the panacea of network administrators. I still want an easier time tracking changes and viewing a variety of network information without having to log into several network visibility tools and dozens of devices. Having a single place to go to find almost any information I’d need about my network is huge, so long as it’s done right.

Where a lot of people get this wrong is that they try to cram everything IT-related into one viewing pane. Typically, I’ve ended up using one or two tabs useful to me as a network engineer before moving on to another tool or logging into network appliances themselves.

This ends up being a waste of time, and the software becomes largely abandoned.

Also, many tools organize information only by platform, but there’s just too much going on to categorize the multitude of technologies in production under labels such as Cisco ASA, Juniper MX5, Catalyst 3850, or whatever other appliance is running on the network. This applies to categorizing by type of platform as well, such as access switch, firewall, router, IPS, etc. Often I run one technology across many of these devices at once. It’s that technology I’m usually concerned with, not necessarily the specific appliance.

For example, I might have my top of rack switches, MDF routers, and even a couple firewalls all participating in the same routing process. In this case, it’s that process I care about most, not necessarily the platform. This applies to all the technologies we use such as QoS, multicast, BGP, and even performance metrics and related trouble tickets. These are the things I really care about, not what platform a particular box is.

When troubleshooting reachability to a new subnet, I would have to log into a small pile of routers to run a library of OSPF show commands in order to check if configurations are correct, adjacencies are formed properly, and prefixes are learned or filtered where I expect them to be. Even then, this gives me only part of the picture. I may still need to look at specific interfaces, Layer 2 issues and access lists.

In this example, there are so many layers to search through that having a single place to collect and view this information would be extremely valuable in a very practical sense; however, this requires several things in order to work well.

First, I need the information to update automatically. If this doesn’t happen, there’s just no way I’m going to spend my days updating configuration snippets and network diagrams. Dynamic updates, not manual, are what will maintain usefulness.

Second, I need really good built-in templates. Based on my personal experience, I don’t believe networks are all too different from company to company, so I think it makes much more sense to have things work right of the box. I don’t want to spend weeks customizing views or hiring developers to do it for me. That being said, I still want the ability to customize to my heart’s content if I want to, but not because I have to.

Third, I want to search what I actually care about rather than compile some sort of mental picture going device by device. In keeping with my previous example, it’s important that I can select OSPF as a view rather than just search by router name. That way, in one snapshot I can see all the devices running the process and click on each of those devices to quickly see configuration snippets, adjacencies, etc.

Fourth, from an operations perspective, I care about flows and dependencies. For example, a single pane of glass that I log into needs to provide real-time flow monitoring so I can see a Layer 2 path between two IP addresses. This is so important to me in routine troubleshooting, and a solid tool needs to provide that functionality.

I believe being able to search by technology, application, or even by incident has profound significance in network operations. Being able to search for “OSPF 100” or “open ServiceNow tickets” provides the network visibility that’s so difficult to get device by device or by stitching together a tapestry of inadequate tools.

NetBrain’s Dynamic Network Maps gives me, as a network engineer, virtually any information about the network visualized through pre-defined ‘layers’ in a single view. Layers can be toggled on and off dynamically and provide insight into performance, design, security, and even related tickets all in one place. And keeping this sort of single data repository makes is much easier for an entire team of engineers to glean insight from shared activity logs that track configuration changes.

This results in a highly functional tool that provides all of those views in one place. Consider the power with regard to even the mundane task of tracking down what switchport a device is plugged into. NetBrain’s Dynamic Maps correlates ARP and MAC addresses across an environment and identifies which switch and switchport that device is plugged into. The alternative would have been going switch by switch, searching through ARP tables, and looking at individual interface information.

What we end up with is a single pane of glass that’s really not a single pane of glass. Using this tool I can toggle through various layers of my network to search by technology or data point and have a view into almost infinite detail of my network including the network dependencies that are so cumbersome to learn manually.

Don’t cringe when you hear “single pane of glass.” It really isn’t a dirty word. A single place to go to easily find meaningful information about our networks is a huge benefit, so long as it’s done right.

Related