Join Us at Our Upcoming Events Events
Skip to Main Content

A Programmer’s Perspective on the Current State of Network Tools

Part 1

I know the title of this article looks technical and boring like it could have been taken right out of an IEEE magazine, and we will get to the technical bits soon, but this is really a story about network superheroes like you, and the stories you create to get the job done, because (spoiler alert) the software is not going to do it for you. 

Programming code languageEvery one of us has an inner MacGyver, with stories about using some random tool to solve a networking problem. Just the other day, I used a bobby pin to start a 2U server with no faceplate by connecting the right jumper on the motherboard. It was pretty cool, I thought, and I actually wrote a story about it. I love stories like these, and when talking to people in the computer technology business and they say, “I remember when…”, I know what’s coming next is their own story, and oftentimes all the way back to Fortran, punch cards, and bubble memory.

For NetOps veterans it is not that different, with stories about Novell, token ring, hubs, parallel ports, etc. But rarely are their stories about good tools. More often than not, other tools like duck tape and python are in there somewhere, and the real story is the creative genius somebody had to solve a problem with them.

Tools of the Trade (Or Lack Thereof)

For example, I was in an Uber recently on an hour-long drive to the airport, and the kind gentleman driver, after asking what I do, started telling me his story. I could hardly hear behind the protective plastic Covid barrier, but that did not phase him a bit. His job was to support networks in Texas, which were constantly getting taken down by lightning. Being in the tools business myself, I asked what they used for monitoring and troubleshooting. He laughed and said something about trucks and binoculars. 

What a great story, and a perfect example of a problem in need of some good tools for monitoring and troubleshooting. But what was common between his stories, and others I hear all time, was the abundance of problems, and not the tools to address them.

Why, because in many cases like these the tools do not exist, and people are left to their own creative devices to figure out how to solve network problems. And why is that? Because networks are more often than not designed without tools for monitoring or troubleshooting them. Designing a network is like a game of chess, where one needs the foresight and experience to know that problems will occur, and that the quality of the design and tools put in place beforehand will determine the ability to solve those problems and how long it will take.

Hmm, I bet there is an equation for that. 

The Power of Strategic Thinking

Network Design chess pieceBut just like most people who play chess, that only think one or two moves ahead, most network designers only think about the initial successful operation of the network, not beyond the fact that it will change, and break, and what tools should be put in place to monitor, troubleshoot, and fix it. But that is only part of the problem. The other is the network vendors who either claim their network solution will never have a problem, or the network solution will provide everything you need to monitor and troubleshoot.

Unfortunately, neither is true, but they are more than happy for you to spend your whole budget on just them. So, don’t be fooled, my friends! There is no network solution out there that in and of itself, will come built-in with the visibility, analysis, and visualization your NetOps team will need to keep the network up and performing at its peak as the organization changes and grows, along with the requirements of the network.

Think longer-term, support the superheroes that run the network, and save some of your budget to partner with an NPM solutions company. There are many options out there, and there are a few important factors to consider when choosing one.

Data Visualization and the Components of the Network

First of all, this article assumes that the network will be designed for users, so we will NOT focus on that, because they will be taken care of. Here we will focus on the importance of designing a network for the people who take care of it, the NetOps team. So let’s talk about designing a network so that it can be monitored, and when it breaks, fix it.

Global network data packets

To monitor and troubleshoot a network, you must have some level of visibility into the data traveling across the network at as many capture points as possible along with the network, and as much information about the state of the devices like routers and switches that connect the network together. The level of visibility into the data can be the actual packets, flows, or higher-level statistics.

The higher the granularity of data, and the more analysis of that data, and the longer that data and analysis are saved, and the more visualizations available for the analysis, and how integrated and interactive it is, will all determine how expensive the initial cost will be, as well as the maintenance and training and scale of that solution over time. Yes, it is non-trivial, so be prepared to spend some time on it, because it is worth it and absolutely necessary.

How to Best Utilize Flow Data

The good news, as I mentioned in my previous article, Identifying Network Issues Hop-by-Hop, is that many networks already have routers and switches in place that have the ability to provide flow data. For those networks without flow capability, appliances can be added that will generate flow. But the flow data in and of itself won’t tell you anything. And even the ability to collect the flow, and look at it won’t tell you much. The best way to utilize the flow data is to collect it all into a single server, analyze it, and provide a single pane of glass UI to visualize the analysis. And those two pieces, the analysis, and the visualization, and how well they are integrated to help you tell the story, play a critical role in determining how long it will take to discover and solve a network performance problem. 

Breaking Down Network Traffic Hop-by-Hop

A network is a bunch of wires connected by devices like AP’s, routers, and switches, with clients and servers at the ends. Horrible metaphor, which is why I refer again back to my road and highway article, where the traffic is traveling through the network hop-by-hop. Being able to visualize the flow of traffic through the network, will greatly enhance your ability to understand the behavior of the network. When looking at your NPM options choose a solution that provides the ability to visualize the traffic hop-by-hop, and break that traffic down visually and interactively, make changes to the network right from there, allow you to zoom in, all the way to the packets when possible, and go back in time to compare just about everything.

But wow, is that really it? A bunch of features? As a software engineer, having developed and worked on network monitoring and troubleshooting tools for over 25 years, it makes me sad that I was not able to make a bigger difference and help span the massive gap between where we are now, and where we should be and could be if we would make a few fundamental changes to the way we think about and develop software for NetOps. Hence these articles. Maybe they will help.

A Modern Portrait of Data Analysis

So today I want to talk about where we are now with the analysis and visualization of data. In my opinion, it is not quite the dark ages but not that far from it. How do I know? Just look at where we are today with movies and video games and compare that to where we are with the state of the art in commercial NPM analysis and visualization products. Have you seen Avatar? Played any MMOs recently, have you played Final Fantasy XIV? Given the Oculus a try?

And on the other hand, have you seen a typical router CLI, or WireShark, or ping? There, kinda puts things into perspective, right? And why is that? Supply and demand of course. There are not as many network engineers as there are people who make movies or play video games, which means the NPM industry is not as big and does not have as much money being spent on it.

What Do We Want?

But wait, movies and video games are mostly digital now and depend on the performance of networks, and the other tools used in those industries to manage the content, serve the content, and count the money, are also dependent on the network and the ability of it to perform. But yet, in comparison to the tools used to create movies and video games, and the movies and video games themselves, NPM tools are very primitive. And why is that? Because all of the super creative people are working on the movies and games instead of NPM solutions. 

But cool metaphors are not limited to movies and video games, but other industries make great metaphors for analyzing and visualizing network data as well. Take finance for example. Hard to believe that analyzing money and the economy is more enticing a career than IT and NetOps. But it is another example I like to use as a metaphor for visualizing network data.

Create the Change

Years ago, I started using Google Finance, a cool interactive web app, written in ActionScript for Flash. Remember Flash? This cool little app would let you choose multiple stock ticker symbols, and graph them. It was very interactive and responsive, and you could also easily zoom in and out, and see events in the graph that had a major impact on the stock. I used the tool for years, and then it hit me that just like this UI was perfect for visualizing multiple stock values and events over time, it would also be perfect for visualizing pretty much any network statistic over time.

I got to work and developed Compass, which is like Google Finance on steroids. It is a very popular data visualization view available in both LiveWire and OmniPeek. That was ten years ago. Don’t worry, since then we have ported it from Flash to HTML5 and Javascript. 

The Network of the Future

But enough about the past, what about the future? So here goes, my prediction for the future of NPM is that a network tools development engineer, a game developer, and a movie producer will become roommates in college. The use of state of the art game developer tools in and of itself would be a paradigm shift, but the real magic will happen when the expertise of the network engineer, the creativity of the game developer, and the storytelling and production skills of the movie producer work together to create the next generation network monitoring and troubleshooting solution.

NetOps heroesThis will be the catalyst, or the paradigm shift, that will lead us into a renaissance of new tools and solutions, and companies that build them. And this will attract new types of people who would actually be interested in NetOps as a career, instead of making movies or video games.

Call me a dreamer, but without hope, we are lost in a world without emotion, and without emotion, there is no love. Without love, what is the meaning of life? And we will talk more about how important emotion is in Part 2 of this article. So stay tuned, and join us soon for a deeper look into thoughts about the state of NPM, and where it could be going, and what you should look for when choosing one.

By: Chris Bloom, Lead Technical Engineer