The average network is a collection of configuration settings that exist in their own little island. They interact with each other and create situations where that interaction causes systemic issues in other places. Half of the job of a network engineer is figuring out those interactions and anticipating how they will impact other parts of the steady-state machine that we build to operate our applications. It’s hard enough to learn where all the switches are. Asking for anything more complicated is taxing for any engineer.
With the rise of networks that need to be more reliable for things like cloud applications and important use cases for financial or medical, it’s not enough to guess about the network state any longer. We can’t just hope that a configuration was done and that it was made in such a way as to lessen the impact on other systems. We can’t wish that things were configured correctly. We have to go one step further and actually verify that everything is done correctly. Adding that verification step into our routine is a source of contention, though. It’s a lot of extra work. It requires extra steps to get the information and make sure it’s accurate. It’s not what the standard network was built to provide. There needs to be a better tool out there to give us the info we need.
Moving Forward
If all of these challenges sound familiar to you, you’re not alone. Years ago, the team that started Forward Networks saw the same challenges. They had the vision to understand that network complexity was growing at a rate that was too fast for any one engineer or even team of engineers to understand at the right depth any longer. The more software constructs that are introduced into the networking, the harder it becomes to figure out how to verify basic configurations.
A quick example would be something like OSPF. If someone asks you a simple question like “Is the route to this host present?”, you can pull up a router and query the routing table with a command. But if someone asks you “Is this route present in the OSPF database?”, you need an entirely different command. You may even need to be on a different device depending on how your LSAs and areas are configured. You have to either know the protocol at a deep level or you have to guess correctly where you’re supposed to look.
Forward Networks can eliminate the guesswork. That’s because they’ve built a sophisticated modeling engine that builds a picture of the network at a point in time. Every data point is loaded into the model. Every configuration setting is present. When Forward Networks first launched back in 2016, this model was primarily used to test out network config changes to discover the impact that they might have in the state machine. It was a virtual way to discover the impacts of things network engineers could not predict.
However, Forward Networks has figured out that having the networking configuration state loaded into a model gives you even more capabilities. They released their Network Query Engine (NQE) in 2019 and built out the capabilities of it greatly. I first got a look at it in January 2019 during Cisco Live Europe and later an update during Networking Field Day 21 in November. The progress they’ve made is astounding! Take a look at this video about creating custom configuration checks, for example:
There’s some real power underneath the hood of NQE. This isn’t just a simple modeling tool anymore. Forward’s NQE can be the source of truth for your network configuration. Instead of guessing what’s going on, you can ask NQE to tell you exactly what’s happening.
Think of the power of this kind of tool in terms of the jobs you hate the worst. Want to go in and make sure that all your BGP timers are set to defaults? Ask NQE. Want to know that all interfaces that are configured at administratively enabled are also operationally active? NQE can tell you that. Want to figure out what the routing table looks like along the path of the packet as it traverses the network? NQE can pull all that together for you.
At Your Fingertips
The real power of the Forward Networks model, to me, is the ability to query it. Having spent a lot of time in my formative years working with databases I can tell you that the worst situation you can find yourself in is having data and not knowing it. The answer exists right here and yet you can’t find it. It’s like losing something on your desk. You know roughly where it is but you can’t come up with it. NQE fixes all that. It can provide you the answers for anything you need to know in your database. It can give you all the information you want right at your fingertips.
But it’s more than a simple network search engine. It’s a logic detector. It can help you look for negatives as well. It can help you define baselines and then search out devices or configurations that violate those baselines. Because Forward Networks can take periodic snapshots of the network to build the models you can also compare and contrast the two models to figure out if something important has changed.
In a world of CI/CD deployments, you need to know what’s going on at all times. You have to have some kind of reference to what is happening in the network. Yes, there are tools that keep track of those changes. But those tools are top-down. You have to check in those changes and ensure that what is pushed to production is actually what’s in the changelog. As more and more engineers start using these tools, you may quickly find that what is implemented may not match thanks to “tweaks” that engineers are famous for. Better to get the bottom-up vision of what’s actually going on from a Forward Networks. And how better to confirm it all than with NQE?
Bringing It All Together
The more time I spend with networks, the more I realize that a lot of my troubleshooting and optimization strategies involve a lot of questions. I need the answers before I can build out my solution or implement my fixes. That means I need the data to get those answers. The way I used to do it was cumbersome and painful. If I had access to a tool like Forward Networks and their NQE in the past, I think I could have spent much more time on other issues and less on gathering information that could have been right at my fingertips. I can’t wait to see how NQE continues to develop and grow.
For more information on Forward Networks and on the Network Query Engine, make sure you check out http://FowardNetworks.com.
