How to verify a network change: pre- and post-checks by vendor

The method: capture, change, capture, compare

Every verification follows the same four steps, whatever the platform.

1. Write the intent and the rollback trigger first. One sentence on what should change, a list of what must not change (the invariants), and the measurable condition that makes you roll back. Example: “Allow VLAN 230 on the uplink trunks of dist-1 and dist-2; no other VLAN, port-channel or spanning-tree root changes; roll back if any access switch loses its uplink for more than 60 seconds.”
2. Capture the pre-state. Run the same command set on every device in scope, including both members of every redundant pair, as close to the window as you can. Save each output to a file named with the change number, the device, pre or post, and the time.
3. Make the change, then capture the post-state twice. Once immediately after the window, and once after a delay: 30 minutes at least, longer if the change affects traffic that peaks later. ARP and MAC aging, BGP hold timers and DHCP leases mean some failures only appear later.
4. Compare. Diff the configuration against the pre-change copy and read every changed line against the intent. Then compare state: neighbors, route counts, port-channel members, redundancy roles, MAC and ARP counts, counters and probe results.

Three habits make the comparison trustworthy:

• Complete captures. Disable paging first: terminal length 0 on Cisco (opens in a new tab) IOS XE, Cisco NX-OS (opens in a new tab) and Arista EOS (opens in a new tab), set cli screen-length 0 on Juniper (opens in a new tab) Junos (opens in a new tab), set cli pager off on PAN-OS.
• Two reads, not cleared counters. Read counters twice, a known interval apart. A counter that rises between two reads tells you what is happening now; a cumulative total does not, and clearing counters erases history someone else may need.
• The data plane, not only the control plane. A neighbor can be up while traffic is dropped. Keep a list of probes (ping, TCP connect, application checks) across the paths the change touches, and run the same list before and after.

Words in capitals in the commands below (PEER, NAME, INTERFACE, ADDRESS, CHG-NUMBER) are placeholders for your values.

What to check for each change type

Match the checks to the change. For each type, the list says what must be true afterward.

• Routing (BGP). Every session that was established is established again. Prefixes received and advertised per neighbor match the baseline, or differ exactly as intended. Best paths for your key prefixes are unchanged unless the change targeted them. No new flaps in the log.
• Routing (OSPF). The same neighbors in FULL state (on a broadcast segment, 2WAY between two routers that are neither DR nor BDR is normal). Route counts per area and source match the baseline. Interface costs are as intended.
• Interfaces and port-channels (LAGs). Every interface in scope is up, with no new input or CRC errors between two reads. Every port-channel has the same members bundled as before, and the LACP partner on each member is the device you expect.
• ACL or firewall policy. The traffic you meant to permit passes and the traffic you meant to block does not, tested with a policy lookup and a live probe. Hit counters rise on the new or changed entries. An explicit final deny does not start climbing.
• VLAN and spanning tree. The VLAN exists, is active, and is allowed on exactly the intended trunks; the rest of each allowed list is unchanged. The root bridge for each VLAN or instance is unchanged. The topology-change count stops rising after the window. MAC table counts return close to the baseline.
• First-hop redundancy (HSRP, VRRP). Each group is active (HSRP) or master (VRRP) on the intended router, with a standby or backup present. Preemption and tracking behave as designed.
• MLAG and vPC. Peer link and keepalive up, consistency checks passing, every MLAG or vPC interface active on both peers, no new orphan ports.
• HA pairs (firewalls, supervisors, stacks). Both members present, roles as expected, configuration and state synchronized, and no unplanned failover during the window.
• Software upgrades. The intended release is running, and committed where the platform asks for it, on every member. Modules, transceivers and licenses match the baseline; neighbor, route, MAC and ARP counts are back to the baseline; no new crash or error messages. Separate the lines a new release adds by default from lines that disappeared: a missing line after an upgrade is a regression until proven otherwise.

One trunk mistake is worth checking every time. On Cisco (opens in a new tab) IOS XE and Cisco NX-OS (opens in a new tab), switchport trunk allowed vlan 230 replaces the whole allowed list, while switchport trunk allowed vlan add 230 adds to it. Compare the allowed list before and after any trunk change.

Cisco IOS XE pre- and post-checks

Run each command before and after the change on every device in scope. On a Catalyst stack, run them on the active switch; the output covers every member.

Save a copy of the running configuration before you start. After the change, show archive config differences with that file name compares it with the running configuration. With no file name, the same command compares the startup configuration with the running configuration, which is the quickest way to find unsaved work before the window.

Cisco NX-OS pre- and post-checks

Create a checkpoint before every change. checkpoint NAME saves the configuration in a form NX-OS (opens in a new tab) can diff and roll back to, and show diff rollback-patch checkpoint NAME running-config shows exactly what changed since. Checkpoint names must be unique and must not start with the word system.

Add vrf all, or vrf NAME, to routing commands when your design uses VRFs. ACL hit counts appear per entry only when the ACL includes statistics per-entry.

Arista EOS pre- and post-checks

Make the change in a configuration session. configure session NAME holds the change until you commit it, show session-config diffs shows exactly what the commit will do, and that diff is the one you attach to the ticket. Inside the session, commit timer 00:10:00 commits with an automatic rollback unless you confirm with configure session NAME commit before the timer expires. Both commits are state-changing and belong in the approved window.

ACL hit counts appear per entry only when the ACL includes counters per-entry.

Juniper Junos pre- and post-checks

Junos (opens in a new tab) has no running and startup split: the committed configuration is active, and it is what the device boots. Use the commit tools instead. commit check validates the candidate. commit confirmed 10 commits with an automatic rollback after 10 minutes unless you confirm with commit; it is state-changing, so run it only in the approved window. commit comment "CHG-NUMBER" ties the commit to the ticket.

After the change, show configuration | compare rollback 1 shows what the last commit changed. If the change took several commits, find the right rollback number in show system commit. set cli timestamp prints the time above every output, and appending | save /var/tmp/FILE to a show command keeps the output on the device.

Palo Alto Networks PAN-OS pre- and post-checks

Save a copy of the configuration before you start, then review the pending change with show config diff, or with Preview Changes in the commit dialog of the web interface, before you commit. test security-policy-match tells you which rule a flow would hit without sending traffic: run the same test flows before and after. Run the HA checks on both firewalls of a pair.

The routing commands below apply to the legacy routing engine. If the Advanced Routing Engine is enabled, the routing show commands differ; use the CLI reference for your release.

How to decide the verdict

“Completed” is a workflow state, not an outcome. Record one of five verdicts, and decide in this order:

1. Blocked. The change did not start, or stopped before its first state-changing step, because a pre-check or the go/no-go gate failed. Example: the pre-check found the standby firewall out of sync. The evidence is the failed pre-check.
2. Rolled back. The change was made and then reversed, because the rollback trigger fired or the team chose to back out, and the post-rollback checks show the baseline restored. If the rollback did not restore the baseline, you have an incident: open one and record Degraded.
3. Degraded. The change is in place, but the intent was only partly met, or something outside the intent changed and stayed changed. Example: an upgrade completed and reachability held, but a DHCP relay line disappeared from one of two cores. Record the regression, its owner and the fix.
4. Inconclusive. No regression found, but the evidence is incomplete: no baseline for a device in scope, a post-check not run, the delayed check skipped. Say what is missing and what would close the gap.
5. Verified. The intent was met, every invariant held, every difference between pre and post is explained by the intent, and the delayed check passed.

Any difference you cannot explain blocks Verified. “Probably noise” goes in the ticket as a question with an owner, not as a pass. See change verdict and completed is not verified.

Where to store the evidence

The change record is the record. Months later it is where the next engineer, the problem manager or an auditor will look, so the evidence belongs there, not in a chat thread or on a laptop.

• Attach the raw files: pre, post and delayed outputs per device, the configuration diff and the probe results, named consistently, for example CHG-NUMBER_DEVICE_post_TIMESTAMP.txt.
• Write a short work note: the verdict, one sentence of reason, the checks run, who verified and when.
• Close with the verdict, not with “successful”. If your ITSM close codes only offer success or failure, put the verdict in a field of its own, or at the start of the closing note, so it can be reported.
• Remove secrets (keys, community strings, password hashes) before attaching configurations. On Arista EOS (opens in a new tab), show running-config sanitized masks them.
• Link related records: the incident a failed change caused, or the problem record a Degraded verdict opens.