Skip to main content
Question

Integrating Forward Networks with CI/CD or automation tools – real examples?

  • December 19, 2025
  • 1 reply
  • 33 views

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.

1 reply

devecis
Employee
  • Employee
  • January 6, 2026

Like many teams, we started by optimizing for speed—pushing changes in minutes instead of days. But we quickly learned that automating bad configs just breaks the network faster. We were moving quickly, but not always in the right direction.

 

We experimented with device-in-the-loop testing and GNS3 simulations, but ultimately found the most efficient approach was modeling changes directly in the Forward Networks sandbox, using Forward to act as the validation gate for ACL and firewall updates in our pipeline.

 

Here were the real world solutions we implemented...

 

The “Holy Grail” (CI/CD)


For planned changes, my preferred stack is GitLab + Ansible + Forward Networks, with Forward acting as a validation gate in the pipeline. Most often this is used for ACL and firewall rule updates submitted via merge requests. As part of the pipeline, we use the prediction engine to validate intent: will the new rule allow the required traffic, will it block anything that currently works, or will it accidentally expand access? Because the analysis runs against the full network model, we can prove the outcome of a proposed rule before touching a device. If the prediction doesn’t match our intent, the pipeline fails and the change never reaches production.

 

The Change Window (Pre/Post Validation)


Not every change goes through CI/CD. For maintenance, vendor work, or one-off changes, I rely on pre- and post-change snapshots. I take a snapshot immediately before and after the change window and compare the two to see what actually changed. This approach makes it easy to validate that the change behaved as expected and to quickly spot unintended second- or third-order effects—reachability, routing, or security posture changes that wouldn’t be obvious from device-level checks alone.

 

Features I Rely on Most

 

NQE (Network Query Engine): This is my go-to for Golden Config verification. I use it to ensure we are adhering to our standards as much as possible across the fleet.

The DIFFs Page: This is critical for my "read-outs." Being able to instantly see the delta between two snapshots gives me immediate clarity on what actually changed on the wire.

 

Tips & Lessons Learned
 

Experiment with the platform: The best way to learn the platform is to get your hands dirty and experiment. If you'd like to practice in a safe environment with help and guidance, try https://quest.fwd.app - Login with your community login and password.

Learn a little NQE: You don't need to be a developer, but knowing the basics of NQE opens up so much power.

Ask for help: There is no harm in reaching out. The community and the support team are her to help you solve the hard problems.