Community

Manually auditing DNS configuration across a large network is slow, tedious, and error-prone. Engineers are often forced to comb through thousands of lines of device configuration to confirm that every router, firewall, and switch is pointing to the correct name servers. By the time the audit is complete, parts of the network may already be out of compliance again. With Forward Networks’ Network Query Engine (NQE), this kind of validation can be automated and continuously enforced using a simple, declarative query that evaluates the entire network model at once. Why this mattersDNS is a foundational service. A single misconfigured device can: Break application connectivity Bypass security monitoring by resolving through an untrusted resolver Violate regulatory or internal policy that mandates use of controlled DNS infrastructure  What this NQE checksThis query verifies that every monitored device is configured with the approved internal DNS servers—and only those servers.In this ex

Using the MLAG_INTERFACE_STATE output that is already provided we will check the interface state in relation to all MLAG configured interfaces, this will warn if their is less than 24 hours since the last state change.To violate the following must occur.The state is not “active-full”The Oper State of the interfaces on the local and remote device is not “up/up”The configuration state is not “ena/ena”/** * @intent Report on the MLAG Interface State * @description Using the show mlag interface detail command which is in commandType MLAG_INTERFACE_STATE * the data is retrieved by calling mlagTable within the arista library. This will violate if the interface * state does not match the expected results. */ //show mlag interfaces detail.mlagInterfaces = ``` local/remote mlag state local remote oper config last change changes-------

This query takes the rather limited show mlag config-sanity command from an arista switch and generates a violation if it does not match the output below.switch#show mlag config-sanityNo global configuration inconsistencies found.No per interface configuration inconsistencies found.The query identifies each line of the output and then creates two variables globalConfig  and interfaceConfig, interfaceConfig is identified by check if interface exists in the line. I am only expecting two lines therefore both variables once set won’t be added to.   Watch this space if this changes I will update the query.As in my previous queries I have included the extract that is in my “Arista Library” into the query for simplicity.Finally there maybe a better way to do this as I had some fun and games getting this one to work so any feedback is gratefully appreciated./** * @intent Mlag Config Sanity Checks * @description Using the Arista Library we will check the configuration Sanity, there are only two

This NQE uses the show mlag detail command which all that it should be in command.type of MLAG_STATE it did not appear so I added it as a custom command and will violate if the following occur:What I alert on:Mlag state is not AcitveNegotiate Status is not connectedPeer Config is not ConsistentPeer Link and/or local interface are not upIf both the local and peer device are both primary or both secondary admittedly the latter may be impossible but though of capturing it just in case Peer Link is error disabled.If the Agent is not showing as ruinning.What we warn on:We will also Warn on the following:If there any ports disabled, Inactive or Active PartialIf the number of port disabled, inactive or Active partial is the same as the total number of ports configured. /** * @intent Check the MLAG status * @description Using the AristaMLAGDetail function in the Arista Library check to verify the status is as expected * * This query also uses the violationProcessing function from the Utilitie

Using the “show vxlan config-sanity detail” command as a custom command we have a built a query that enables you to verify your vxlan configuration based on the “Result” field being anything other than “OK”, if you wish to accept warnings then simply adjust the relevant if statement in the “AristaVxLanSanity” section of this script./** * @intent Report on the Sanity of VXLAN configuration * @description Using the AristaVxlanSanity module of the Arista Library we will report any vxlan * configuration failures by category per device using the default assumptions of the Module * from the library */AristaVxlanSanity(device: Device) =foreach command in device.outputs.commands where command.commandText == "show vxlan config-sanity detail" //Retrieve only the command show vxlan config-sanity detail let deviceName = device.name let vxlanResponse = command.response let parsed = parseConfigBlocks(OS.UNKNOWN, vxlanResponse) foreach line in parsed foreach child in line.children

I’m curious to hear how different teams are using Forward Networks in their day-to-day workflows. Whether it’s for network visibility, change validation, security analysis, or troubleshooting, I’d love to learn what’s working best for you. Which features do you rely on the most? Have you integrated Forward Networks into your change management or automation processes? Any tips or lessons learned that could help others in the community? Looking forward to hearing real-world experiences and best practices from the community.

Hello,I am trying to create the NQE query, where i want to see the outputs of show module, show platform, depending upon the platform command might be different and then from those outputs i want to see the modules which are in down state.

Any time someone tells me they’re manually reviewing ACLs for compliance, I know they’re fighting a losing battle. That approach might work on a small network, but once you’re dealing with thousands—or tens of thousands—of devices, manual validation simply doesn’t scale. This came up recently in a conversation on specific ACL compliance requirement across an environment. They weren’t looking for advanced analytics or a flashy dashboard. They needed a reliable way to ensure their access control lists consistently met two basic security rules, everywhere, all the time. The compliance problem The first requirement was that every deny statement in an ACL must log. From a security and compliance standpoint, a deny that isn’t logged is effectively invisible. Traffic may be blocked, but without a log entry there’s no audit trail and no way to prove enforcement. The second requirement was that every ACL include an explicit deny-all statement. Most platforms apply an implicit deny at the end of

   Understanding how your network evolves is crucial, especially for spotting configuration changes and potential vulnerabilities. Forward Enterprise makes this process intuitive—even if many snapshots aren’t fully processed. Let’s walk through how to reveal changes and vulnerabilities without processing every snapshot. Step 1: Go to a processed snapshot in your network inventory.   Step 2: Find and select the device you’re interested in. Open its device card and view its configuration. This shows the current state, but you can also check its history to see all changes over time.   Step 3: Review the configuration history to spot changes. Look for when lines were added or modified. For example, if the text “foo” was added recently, you’ll see exactly when that change happened. The history view highlights both recent and older changes, including when the entire configuration was first introduced.   Step 4: To examine specific lines, highlight them in the config, right-click, and choose

Hi Team, Could you help me to understand how Forward Networks model the host ?

  The new ordered collections feature streamlines how you pull, organize, and present data from your inventory. It helps you quickly surface results—like the top 10 most vulnerable devices—organized the way you want, so you can act faster and share clearer insights with your team.Let’s walk through what ordered collections can do, when they’re most useful, and how to use the new syntax to save time and reduce manual filtering. Introduction: Why Ordered Collections MatterBefore ordered collections, finding and organizing your top results (say, the most vulnerable devices) meant extra filtering and sorting. Reports could show too many results, scattered by category, forcing you to click around or explain sorting steps to others. Now, ordered collections make it easy to: Limit results to exactly what you want (like the top 10) Sort by multiple criteria, such as vulnerability count and operating system Use familiar, flexible SQL-like syntax Handle both ordered (list) and unord

Where My Network Survey Lessons Really Began: High-Security Environments I’ve spent years surveying some of the most complex, layered, and mission-critical networks in high-security environments. One of the most impactful experiences came from supporting the Air Force’s Base Infrastructure Management (BIM) initiative—a massive effort to modernize, standardize, and truly understand the state of base-area network (BAN).These networks weren’t designed once; they were designed over time—by different teams, different contractors, and different mission owners. Every environment had its own personality, its own quirks, and its own technical ghosts. And when BIM kicked off, it quickly became clear that the Air Force needed a repeatable way to actually see what they had before they could improve it.Traditional approaches—flying in engineers to open comms closets and manually log into devices—took weeks and still left blind spots. We needed a better, faster, more reliable way to uncover the trut

One of the greatest strengths of using a digital twin is being able to separate the routing and firewall behavior of a particular traffic flow.For example, suppose we have a web application that is not functioning properly because traffic from the Internet cannot reach a public virtual-ip that is mapped to private IP on a top-of-rack switch on port 80.We enter this path search in the Forward Network Search bar.We can see immediately that the traffic is being blocked on an edge firewall (atl-edge-fw01). However, we don’t know what would happen to the traffic if it is permitted through this firewall and continues along its path.Are all the routing protocols properly configured to deliver the traffic to its destination? Is there another firewall in the path that would block the traffic?We can answer these questions by using permit-all mode.By enabling permit-mode, we pose the hypothetical question “what happens to the traffic if it is permitted through all the security rules in the path?”

In support of ongoing federal cybersecurity and supply-chain risk management initiatives, Forward Networks has developed a streamlined detection workflow for identifying devices manufactured by Huawei, ZTE, TP-Link or any other network device of concern that are within an enterprise or government environment.This proactive measure aligns with Cybersecurity and Infrastructure Security Agency (CISA) guidance and the Federal Zero Trust Architecture (ZTA) implementation goals outlined in OMB Memorandum M-22-09. This capability helps agencies rapidly locate unapproved or unmanaged devices—enhancing visibility, compliance, and operational integrity across complex network infrastructures. What’s Going OnBecause consumer network devices (routers, access points, and embedded network interface components) are widely deployed in home and small-office settings, they may appear in larger networks without full discovery or oversight. These “commercial off-the-shelf” (COTS) components can bypass stan

The default number of results returned for an NQE query executed from the API is 1000 (returned as a list assigned to the key “items”)You can increase the limit to 10,000 items. For retrieving results of more than 10,000 items, you will need to use the limit and offset parameters as part of your script, and concatenate the results of multiple API calls within the script.Below is a simple script in Python that concatenates successive chunks of 10,000 items into a single output:import requestsdef nqe_query_with_offset(): my_result = [] limit= 10000 offset = 0 network_id = "101" url = "https://fwd.app/api/nqe?networkId=" + network_id total_extracted = False while total_extracted == False: payload ={"queryId": "FQ_ac651cb2901b067fe7dbfb511613ab44776d8029", "queryOptions": { "limit": limit, "offset": offset}} print(payload) headers = { 'Content-Type': 'application/json', 'Authorization': 'Basic #KEY#'} response = requests.request("POST", url,

It always starts the same way. A team decides it’s time to get serious about network automation. They want to move fast, be resilient, eliminate toil, and reduce outages. Everyone’s on board. There’s talk of Python scripts, intent-based networking, even AI-powered predictions. But then someone finally asks the most basic question: “Do we actually know what IPs are in use?” Cue the awkward silence. Someone eventually mutters, “We’ve got a spreadsheet.”Honestly, I get it. I’ve been there. Most of us have. If you’ve got a few dozen devices and a small team, tracking IP allocations in Excel or Google Sheets might be enough. But once your environment scales—even modestly—that house of cards starts to wobble. Multiple admins start making updates. File shares go down. Local versions get out of sync. And suddenly, nobody knows what’s actually live in the network.Before you even think about automation, you need a reliable source of truth for your IPs. That’s where proper IP Address Management (

Date: 10/14/2025Time: 6:00 PM – 6:30 PM Pacific (9:00 PM – 9:30 PM Eastern)Duration: Approximately 30 minutesForward Quest will undergo scheduled maintenance this evening to improve platform performance. During this time, the site may be temporarily unavailable.Please note: Avoid starting a new Quest challenge during the maintenance window. Any active sessions may be interrupted. Thanks for competing and leveling up in Forward Quest!

As part of my onboarding with Forward Networks, I’ve been exploring its native dashboarding capabilities. While the built-in dashboards offer useful insights, I’m not fully convinced they’ll meet the specific reporting needs of our leadership team.To address this, I’m evaluating two integration options:SharePoint: Using the Forward API to retrieve and transform data, then render dashboards tailored to our requirements directly within SharePoint. Grafana Cloud: If SharePoint proves limiting, I’ll explore leveraging our existing Grafana Cloud instance for more flexible visualization.Has anyone integrated Forward with either platform? I’d really appreciate any experiences, suggestions, or recommendations.Below is the format I think supports the SLT teams requirements.Thanks for any feedback. 

The Framework Regional Variations Determining a Device’s Region Changing Variables Based on Region Knowing the Collection State Anatomy of a test Imports Pattern Matching Function Exceptions Report Putting Tests Together Making NQE Verifications  Creating Scorecards Summary Ok, so you make all your configs using Ansible or Netbox Config Templates and are feeling good that you’ve got a consistent configuration everywhere - nice! Having a solid templating system to produce standardized configs is a great first step. But once the devices have been made live on the network, how can we run in-life tests to make sure their configurations have not drifted away from the ‘golden’ one they started out with? Two general approaches might be used for this: Regenerate configs periodically and compare them with the live config. Write specific tests for parts of the configuration (security hardening measures for example) and leave the remainder unchecked. Option 1 is a fairly simple approach

You may often want to find all pattern matches within the device configuration and filter the results based on a regular expression.The following NQE query uses a regex filter as part of a two step process in the getMatch(device) function.First, we find peer-group names in a Cisco BGP configuration and stores each match in a string called groupName by matching on the pattern defined at the top of the query.Second, we iterate through each each pattern match and filter the groupName based on the regex `^PUBLIC.*(?:-4|-X)$`The regex matches a string that starts with the word “PUBLIC” and end with either “-4” or “-X”.The main foreach loop at the bottom of the query applies the function getMatch to output a list of devices along with all the matching peer group names pattern = ```router bgp {number} neighbor {groupName: string} peer-group```;getMatch(device) =foreach match in blockMatches(device.files.config, pattern)let validRegex = re`^PUBLIC.*(?:-4|-X)$`let groupName = match.data.groupNa

Just posting up a simple Python script that allows you to make API calls from behind a proxy that also requires authentication.I have capitalised things that you need to customise.  Of course it isn’t good practice to have usernames and passwords in your script so this is just for illustrative purposes.import requestsimport base64api_user = "YourApiUser"api_pass = "YourApiPassword"api_creds = api_user + ":" + api_passapi_bytes = api_creds.encode("ascii")api_encoded = base64.b64encode(api_bytes)print(api_encoded)api_string = api_encoded.decode("ascii")proxies = { "http": "http://YourProxyUser:YourProxyPassword@ProxyServerIp:ProxyPort", "https": http://YourProxyUser:YourProxyPassword@ProxyServerIp:ProxyPort",}try: response = requests.get("https://fwd.app/api/networks", proxies=proxies, headers={"Authorization" : "Basic " + api_string}) print(response.json())except requests.exceptions.ProxyError as e: print("Proxy error:", e) 

CISA just issued Emergency Directive 25‑03 mandating actions to identify and mitigate a campaign exploiting zero‑day vulnerabilities in Cisco ASA / Firepower devices. While the directive is written for federal agencies, the threat is relevant to any organization using those platforms. Below is a summary, risk assessment, and recommended mitigations — along with what Forward Networks is doing to support customers. What’s Going OnCampaign targets Cisco ASA and Firepower / FTD appliances Exploits include unauthenticated RCE and privilege escalation Persistence observed via ROM manipulation Linked to 'ArcaneDoor' activity CVEs: CVE‑2025‑20333 (RCE) and CVE‑2025‑20362 (privilege escalation) Directive mandates inventory, forensic dumps, patching, and reporting Why This Matters to Forward CustomersIf you rely on Cisco ASA, ASAv, or Firepower/FTD appliances in your network perimeter or DMZ, your infrastructure may be at risk of compromise, persistent code injections, or deeper intrusion. Becau

You can use the NQE group function to collapse rows that have multiple matching columns.In the following example, we make a list of all devices in the network (and store in a list called data), and group all the devices in data together that have matching values for Vendor, Model, OS, and OS Version. The matching values are grouped by attributes.Note that list stored in data just has device names. We don’t actually list all the device names within the select statement. The device is the identifier for each unique element that is hidden when you use the group function. We access the list of devices in each group (within the list data) with a foreach loop in order to count the unique items and provide a total in the last column./** * @intent List devices grouped by matching Vendor, Model, OS, and Version and the total number of devices in each group. * @description List devices grouped by matching Vendor, Model, OS, and Version and the total number of devices in each group. */foreach dev

Flagging an important warning from the FBI / IC3, and sharing resources to help you assess and reduce risk. Alert Number: I-082025-PSA - Russian Government Cyber Actors Targeting Networking Devices, Critical Infrastructure The High-LevelThe FBI is alerting that Russian FSB cyber actors (aka Center 16 / “Berserk Bear” / “Dragonfly”) are actively exploiting a known vulnerability in Cisco Smart Install (SMI) — CVE-2018-0171 — to target networking devices globally. These actors are using SNMP (especially older/insecure versions v1 and v2) and unpatched / end-of-life devices to:Collect configuration files. Modify configs to insert or enable unauthorized access. Do reconnaissance inside victim networks, with particular interest in protocols & applications used in critical infrastructure / industrial control systems.The vulnerability and use of legacy/unsecured protocols make aging equipment especially risky. Even if a device is not directly breached, weak practices may allow attackers in