Even before packets start flowing, enterprise networks are complex, data-intensive repositories of topology, configuration, and state information. This information is often required to solve operational issues—like finding sources of unwanted traffic drops or protocol configuration errors—or to find problems before they become issues.
Yet, this valuable information typically goes untapped because getting at it requires too much work. The data is scattered across devices and stored in different formats with disparate methods to access it.
Forward Networks’ Network Query Engine (NQE) removes the burden of collecting, parsing, and querying network information. NQE takes configuration files and state information from across all your network devices and cloud environments and exposes it in a well-defined schema that can be queried like a database, enabling a new range of network management capabilities and insights.
Today, answering even basic questions about a network can be challenging and time-consuming. Consider this simple task: find all device interfaces in your network whose operational status does not match their configured status. For example, if an interface is configured to be UP but is operationally DOWN, we want to know about this!
To implement this simple check, we need to 1) log in to all of our devices, 2) use the available method to retrieve the data, 3) extract out information we need from the data, and 4) put this information into some common data structure so that the check can easily be written. In some cases, we may be able to use proper APIs, like SNMP or NetConf, to retrieve this data. In other cases—and in almost every significant real-world case we've seen—some of the data on some of the devices has to be retrieved from the CLI interface of a device and parsed from human-oriented, ill-specified, vendor-specific textual output.
To illustrate, consider getting the operational and administrative statuses from all interfaces on a Cisco NX-OS device and on an A10 ACOS device. On Cisco NX-OS, we have to run two commands, "show running-config" and "show interfaces brief" to get at all the data.
On A10 ACOS, we have to run "show interfaces".
The outputs from these three commands are all completely different, and we have to write 3 ad-hoc parsing functions to grab the data we want.
Developing programs to collect the needed data on one or two devices or platforms for one or two data points is not that hard. But doing this across all of your vendors, platforms, and OSes, for the thousands of data points (some rather obscure) that you may need, is an enormous effort.
When you can efficiently get answers, many operational tasks can be accelerated.
Beyond the simple question about interfaces above, operators have expressed interest in answering a long list of questions:
Every network engineer we talked to has questions like these, and they need network-wide information to answer them completely. Occasionally, engineers would query manually and get partial answers. In other cases, where they had tools teams or scripting-savvy network teams, they would invest the time and effort. One network operator who went down this path reported that 80% of the effort was spent in basic collecting and parsing of device and vendor-specific formats and details.
Unsurprisingly, nobody reported that this was work they'd want to do because it's tedious to get collection, parsing, and querying right across vendors and all device types (switches, routers, firewalls, and load balancers), as it requires ongoing development and maintenance (as the devices evolve and new firmware versions come out), and because it adds risk (that the star coder who made this leaves). There are libraries to help with network-device collection, access, and parsing, but none get you all the way to the finish line. Existing tools/techniques like SNMP, HTTP APIs, and YANG outputs often only work on a subset of devices, require software upgrades that you are not ready to apply, or don't cover all the data that you need.
Given the level of effort required, many questions are simply not answered, leaving operators blind to potential problems in their network or working long weekends hunting down the needles in their haystacks. Fortunately, now, help is on the way...
As part of the underlying engine of its network assurance and intent-based verification platform, Forward Networks already does the hard work to create a centralized, vendor-agnostic internal representation of all this network configuration and state information across all layer 2-7 device types. This information powers applications like search, verification, behavioral diffs, and more—all of which can be accessed via our GUI or API.
But this raw information could do other things—if exposed the right way—to answer questions like those above, as well as enable live queries, custom verification checks, compliance documentation, and new dashboards.
This is why we developed NQE. NQE provides access to normalized, structured data about the network, enabling network teams to focus directly on the higher-level aspects of their use cases, which is actually making their networks more resilient, agile, and robust. Data queries for specific needs can now efficiently be written in a small fraction of the time, usually in a few lines of code or in a graphical query editor.
Our key design goals for enabling this level of access to our structured, normalized network data model were to ensure the availability of data was:
In particular, we aimed to have a normalized data model, in the sense that device information (interface details for example) is represented with the same information structure, regardless of vendor, platform, and OS. This normalization allows you to easily write queries and scripts that work across your entire fleet. We also wanted the data to be structured, in the sense that data is fully-parsed—you won't need to parse further into some string to extract out the embedded structure. Again, this simplifies programming because it eliminates a bunch of annoying details, like dealing with differences in textual representation of MAC addresses that arise across platforms.
We believe we've achieved these goals and invite the community to try it out. The data model is not 100% complete (more on that later), but feedback from operators convinced us to accelerate this feature and make it available as soon as possible.
Using NQE, we can now easily answer our original question about interfaces with mismatched operational and configured states. In particular, you can get all the data you need, across all devices in your network, with this short (and sweet) query, and the output is immediately consumable:
That's it! Notice what you did not have to deal with: no collection and storage of data, no reading manuals to find out which command to run, no dirty regular expressions to parse the data, and no vendor-specific hacks. This single query works for all devices supported by Forward Networks!
NQE is designed to make access to data easy. For some people, writing the scripts to collect information is a challenge—that’s why we’ve introduced AI Assist. This handy feature lets you use natural language prompts to run searches in the Network Query Engine (NQE), making it super easy for engineers of all skill levels to perform advanced network queries—no steep learning curve required.
Plus, AI Assist goes a step further by generating clear, natural language explanations for your queries. This not only makes the data more accessible but also helps teams collaborate and communicate better. It’s like having a built-in translator for your network!