Recently active topics

As a valued customer, your insights play a crucial role in helping us continually enhance the Forward platform. We would appreciate it if you could take a few minutes to share your experience by leaving a review on G2.Your feedback is completely anonymous, and the review process takes only about 10 minutes. As a thank you, the first 50 reviewers with an approved review will receive a $50 USD gift card from G2. The G2 team will send your gift card once your review is published.To be eligible for this promotion, please submit your review by November 15, 2025, at 11:59 PM EST.Thank you for being an integral part of the Forward Networks community and for providing a review. Review us on G2 

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!

In this tutorial we are going to graph CVE numbers over time using the Forward API, a python script and some open-source tool. Why would you want to do this? In summary, your boss wants to see PROGRESS! He wants to see progress towards expunging CVEs from network devices. He’s a simple guy and likes a graph. Let’s see how we can go about this. At the time of writing (release 25.9) Forward Enterprise’s CVE count is based on the current CVE database. If you pull up a snapshot from a month ago, the snapshot is compared with today’s CVE database. So going back to the vulnerability pages on old snapshots will not allow you to see how many CVEs you’ve squashed as a result of all those late-night maintenance windows. In the screenshot below we can see that 8 devices are vulnerable:To solve this conundrum we need to pull data out of the API into another application for storage and graphing. We are going to use:Prometheus - a ‘time-series’ database Grafana - an observability tool. (That’s dashb

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