Recently active topics

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

Here is a useful combination of a custom command and an NQE query to show the state of all OSPF neighbors.OSPF data is not collected by default in Forward Enterprise, so we add the custom command "sh ip ospf neighbor"Output data for this command from one device looks like this:Command: sh ip ospf neighborNeighbor ID     Pri   State           Dead Time   Address         Interface10.200.30.42      0   FULL/  -        00:00:35    10.45.6.1    GigE1/0/010.200.30.42      0   FULL/  -        00:00:32    10.45.6.2    GigE1/0/110.200.30.42      0   FULL/  -        00:00:35    10.45.6.3    GigE1/0/210.200.30.42      0   FULL/  -        00:00:31    10.45.6.4    GigE1/0/310.10.10.200      1   FULL/BDR        00:00:03    10.45.6.5    Vlan200This NQE query will list the OSPF neighbors from all devices by parsing the data from the custom command./** * @intent Show OSPF neighbors on all devices collected with custom command 'sh ip ospf neighbor' * @description Show OSPF neighbors on all devices colle

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.

I have raised a support case for this as well, but I was wondering if anyone had seen it when you see different behavior when running a query in the library versus verify.I have created a query to display the vxlan address table, and when run in Verify the result shows 0 however when executed int he library it produces the complete list of passed entries as expected.The Query will always pass and has been added to verify so we can do a diff check on the VXLAN Address table during changes as requested by the engineers.Has anyone else experienced this, or got any suggestions on how to address this.Results from execution in Verify:Results from execution in Library (Sanitized): Code from Script:/** * @intent Display the Mac Address List for VXLAN * @description Will display the VXLAN mac address list and set the violation to false. */import "library/Arista Library";foreach device in network.deviceswhere device.platform.os == OS.ARISTA_EOSlet vxlanTables = vxlanTable(device)foreach item in

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 ?