AI-Assisted Network Change Review: Pre-Checks, Safe Diffs and Rollback

AI-assisted network change review is useful when it reduces boring human mistakes: missed route filters, wrong VRF names, unsafe ACL order, forgotten rollback commands or a change ticket that says “add one prefix” but touches ten devices. It is not useful when it becomes an untrusted black box pushing configuration into production.

The practical pattern is simple: let automation collect facts, let an AI assistant review the proposed change against those facts, and keep a human approval gate before deployment. This works especially well for data center fabrics, BGP edge policy, EVPN/VXLAN VRF changes and branch firewall updates where a small syntax error can become a wide outage.

X Follow @ipexptobe

If you are building this kind of workflow, keep it close to existing operational pages: AI Infrastructure & Automation, Data Center Networking, the BGP Table Watch, Start Here networking topics and the Resources page.

Source: generic sanitized diagram created for Network freak / IPexpToBe; no customer data or production identifiers used.

Problem: network changes fail in the gap between intent and device state

Most serious change problems are not caused by engineers forgetting how BGP, EVPN or ACLs work. They happen because the real network state differs from the mental model. A route map already contains an emergency line. A peer group inherits a maximum-prefix value that is too low. A VRF has an extra route target from a previous migration. A firewall policy relies on object ordering. A leaf pair is missing a small exception that exists everywhere else.

AI can help here because it is good at comparing text, extracting assumptions and asking uncomfortable questions. But the AI must receive bounded evidence. “Is this change safe?” is too vague. “Compare this proposed diff against these pre-checks and identify policy, reachability, rollback and blast-radius risks” is much better.

Design: split the workflow into evidence, review, approval and verification

1. Collect a pre-change snapshot

Before generating or reviewing any configuration, capture the current state. At minimum, collect:

• current running configuration for the target devices, normalized to remove timestamps and secrets;
• routing tables for the affected VRF or address family;
• BGP neighbor summary, received/advertised prefix counts and route-policy names;
• EVPN MAC/IP tables, VNI state and NVE/VTEP status for VXLAN changes;
• interface status, errors, drops and LACP state for physical or port-channel changes;
• known test endpoints and expected reachability paths.

The snapshot does not need to include every command from every device. It must include enough evidence to prove that the proposed change touches the expected blast radius only.

2. Define intent and invariants

Intent is what should change. Invariants are what must not change. Without invariants, a review tool can only say whether a diff looks syntactically plausible. With invariants, it can identify real operational risk.

change_intent:
  scope: add a new application subnet to VRF APP
  devices: leaf-101, leaf-102, border-11, border-12
  expected_new_prefixes:
    - 10.0.0.0/24       # documentation prefix, replace with your real source of truth
  allowed_policy_changes:
    - route-map RM-APP-EXPORT add one permit line
    - prefix-list PL-APP-OUT add one exact prefix

invariants:
  - no default route export from VRF APP
  - no changes to shared services VRF
  - BGP sessions must remain Established
  - advertised prefix count may increase by one only
  - rollback commands must be present before deployment

Use documentation prefixes in templates and examples. In production, feed the workflow from your source of truth instead of hand-written addresses in a chat prompt.

Implementation: a safe AI review prompt pattern

A robust prompt for a local assistant, CI job or Hermes-style automation task should be explicit about role boundaries. The assistant is reviewing; it is not approving production deployment.

You are reviewing a network change. Do not invent missing state.
Use only the provided pre-checks, proposed diff and stated intent.
Return findings in four sections:
1. Blockers: issues that should stop deployment.
2. Warnings: risks that need human confirmation.
3. Verification commands: exact checks after deployment.
4. Rollback gaps: missing or unsafe rollback steps.

If evidence is missing, say what evidence is missing.

Then attach the normalized pre-check output and the proposed diff. Keep secrets out. Replace usernames, public addresses, customer names, hostnames and ticket references with neutral tokens before the AI step. The goal is operational review, not publishing or exposing sensitive configuration.

Example review checks for BGP policy

For a BGP route-policy change, ask the AI reviewer and the automation validator to check:

• Does the prefix list permit only the intended exact prefixes?
• Does the route map have an explicit deny or expected fall-through behavior?
• Will communities, local preference or MED change for existing routes?
• Does maximum-prefix leave enough headroom after the new route?
• Are import and export route targets unchanged for unrelated VRFs?
• Does rollback remove only the newly added lines?

This catches the common “one prefix” mistake where a le/ge entry or route-map sequence accidentally permits a much wider block.

Example review checks for EVPN/VXLAN

For an EVPN/VXLAN fabric change, focus on consistency and fault domain:

• VNI, VLAN and VRF mappings are identical on the leaf pair.
• Anycast gateway MAC and SVI settings match the site standard.
• Route targets match the intended tenant only.
• Border leaf import/export policy does not leak test or backup segments.
• MTU and underlay ECMP state are healthy before troubleshooting overlay symptoms.

Verification: prove the network still matches the intent

Verification must be machine-readable where possible. Do not finish a change with “looks good” in a terminal window. Compare before and after values:

# Examples: adapt to your platform
show bgp vrf APP summary
show bgp vrf APP ipv4 unicast neighbors advertised-routes | include 10.0.0.0/24
show route vrf APP 10.0.0.0/24
show nve peers
show l2route evpn mac-ip all | include <test-endpoint>
show interface counters errors non-zero

Good post-checks answer three questions:

1. Did the intended route, VLAN, VNI or policy appear?
2. Did unrelated routes, sessions and counters stay stable?
3. Can an application-level test prove the path works through the expected firewall, load balancer or border leaf?

Troubleshooting: what to do when the AI review disagrees with the engineer

Treat disagreement as a signal, not as a verdict. If the AI flags a route leak that the engineer believes is impossible, check the evidence. Was the pre-change route table collected from the right VRF? Was the generated diff complete? Did the prompt include inherited peer-group policy? Did the source of truth contain stale data?

The most useful review result is often “missing evidence”. For example, if a proposed border leaf export policy is supplied without current advertised-route counts, the reviewer should not guess. It should ask for the missing count and mark the deployment as higher risk until the operator provides it.

Practical takeaways

• Use AI for review, summarization and risk detection; do not let it silently approve production changes.
• Always provide pre-change facts, proposed diffs, intent and invariants together.
• Normalize outputs and remove sensitive identifiers before sending them to any assistant.
• Start with narrow use cases: BGP prefix-list changes, VRF route-target updates, ACL edits and EVPN tenant onboarding.
• Make rollback a first-class artifact, not something written during an outage.
• Verify invariants after the change with commands that can be compared automatically.

AI-assisted network automation is not about replacing network engineering judgment. It is about making the boring checks consistent enough that engineers can spend more time on design decisions and less time hunting for a missing route-map sequence during a maintenance window.

Follow Network freak for more networking notes, diagrams and troubleshooting tips.

X @ipexptobe on X