Self-Healing Networks with Forward Enterprise Demonstration

Overview

This proof of concept shows how to build a self-healing network using Forward Enterprise's Network Query Engine (NQE) alongside a lightweight orchestration platform. The idea was inspired by a Forward Networks customer already running this pattern in production.

The demo network is small (nine devices across three vendors), but the pattern scales to much larger environments. Two NQE verification checks watch the network continuously:

• NTP server check: flags any device whose configured NTP servers don't match the approved list (with per-device-type exceptions, since some devices resolve DNS names to IPs automatically in their config).
• Interface description check: flags any interface missing a description.

When a check fails, Forward Enterprise's ServiceNow integration automatically opens an incident. A custom orchestration platform then picks up that incident, generates the fix using data pulled straight from Forward's NQE queries, waits for an engineer to approve it, pushes the config via Netmiko, and re-verifies the fix with a fresh snapshot before closing the ticket.

Nothing in the orchestration layer is doing anything clever on its own. All of the intelligence comes from NQE queries against Forward's normalized network model, and the orchestration platform just wires that data into ServiceNow and a templating step.

What you'll need

• Forward Enterprise, with your network already onboarded and collecting snapshots
• Two NQE verification checks: one for NTP server compliance, one for interface description coverage
• The Forward Enterprise ServiceNow integration enabled
• A ServiceNow instance (a developer instance is fine for testing)
• A simple orchestration platform capable of: polling ServiceNow, calling the Forward NQE API, rendering Jinja templates, and pushing config via Netmiko
• A lab or test network you're comfortable breaking on purpose (this demo uses ContainerLab)

Step-by-step walkthrough

1. Build your NQE verification checks. Each check is an NQE query with a boolean violation field, pass or fail. The NTP check compares each device's configured NTP servers (pulled live from the latest snapshot) against a reference list you define. Because the data is normalized across vendors, you can carve out exceptions per device type, for example using IP addresses instead of DNS names for a device that auto-resolves DNS in its config. The interface description check simply confirms every interface on every device has a description set. You can click into any result to jump straight to the line in the device config that produced it.
2. Enable the ServiceNow integration in Forward Enterprise. Once turned on, Forward automatically opens a ServiceNow incident any time a verification check moves into a failed state, no extra scripting required.
3. Confirm your baseline is clean. Before breaking anything, re-run both checks and confirm every device passes. This gives you a known-good starting point.
4. Break something (for the demo). On a lab device, remove the correct NTP servers, add an incorrect one, and strip the description off an interface. Verify the misconfiguration manually on the device (e.g., show ntp servers, show interface description) so you know what state you're starting from.
5. Take a new snapshot. In production this typically runs on a schedule; for a demo, trigger an on-demand snapshot so you don't have to wait.
6. Watch the checks fail. Once the snapshot completes, both NQE checks move to a failed state for the affected device, and two ServiceNow incidents are created automatically, one for the NTP violation and one for the missing interface description.
7. Let the orchestration pipeline pick up the tickets. The pipeline polls ServiceNow for incidents matching a known short description. When it finds one, it fires an NQE query to pull the specific violation data (e.g., which NTP servers are wrong and what they should be), and a second NQE query to gather supporting data, in this case the neighboring device and interface as advertised via LLDP, which is used to auto-generate a meaningful interface description.
8. Let the pipeline determine device type and generate the fix. A further NQE query tells the platform the device's management IP and platform type, so it can pick the correct Jinja template for that vendor's syntax. The rendered template becomes the exact configuration change needed to fix the violation.
9. Scope the change to a workspace. The platform creates a Forward Enterprise workspace containing only the affected device. For a small, isolated change like this, there's no need to re-evaluate the whole network, and this also keeps snapshot collection fast on large networks. (For a broader change, like a routing table update that could affect many devices, you'd take a full-network snapshot instead so you can review everything that changed.)
10. Review the proposed fix in ServiceNow. The ticket moves to "Pending Approval" with the generated configuration attached. The platform never pushes a change without a human signing off first.
11. Approve the ticket. An engineer reviews the proposed config, sets the ticket to approved, and adds themselves as approver.
12. The platform pushes the fix. Once approved, the orchestration platform logs into the device and applies the configuration via Netmiko.
13. The platform re-verifies automatically. After pushing the change, it triggers a new snapshot of the affected device and checks whether the previously-failing NQE query now passes.
14. The ticket closes itself. If the new snapshot shows the check passing, the platform closes the ServiceNow incident with a note confirming auto-remediation and validation succeeded. No manual close-out needed.
15. Confirm on the device. Re-run the same commands from step 4 on the device to confirm independently that the NTP servers and interface description are now correct.

Why this pattern is useful

Every step above is driven by data Forward Enterprise already normalizes across vendors, so the same orchestration logic works regardless of which of the three vendors a given device runs. The human approval gate keeps an engineer in the loop for every change, and because each fix is verified against a fresh snapshot before the ticket closes, you get a closed-loop guarantee that the remediation actually worked, not just that a command was sent. The whole cycle also leaves an audit trail: a ServiceNow ticket with the exact diff, plus before-and-after snapshots in Forward Enterprise.