Choose acceptance and rollback triggers before activation. Keep console/out-of-band access and assign the person who makes the recovery decision.

Quick reference

Stage	Record / test	Decision
Before	Ports, VLANs, routes, peers, HA, versions	Compatible and recoverable?
Activation	Approved scope and start time	Access and timer preserved?
Acceptance	Real flows, intended denies, redundancy	All agreed criteria pass?
Recovery	Known-good state and owner	Trigger reached or timer near expiry?
Closure	Save / confirm, monitor, document	Evidence and ownership complete?

What to understand first

A backup is only useful if it is compatible, accessible and recoverable with the available access path. Record credentials through the approved secret-management process, not in the worksheet.

Baseline the affected service and nearby dependencies. Include management, DNS, DHCP, routing, VPNs and monitoring where they are in scope.

Acceptance needs source-specific application tests and intended denies. A successful commit, link-up state or management ping is evidence of only part of the change.

Recovery differs by platform: IOS XE often applies running changes immediately; Junos candidate/confirmed commits have a timer; PAN-OS commit and Panorama push jobs have distinct target scope.

Commands and interpretation

Inspection commands are read-only unless explicitly labeled otherwise. Capture commands start collection; configuration-mode commits change device state.

Cisco IOS XE

Read-only EXEC

show interfaces status
show interfaces trunk
show ip route 192.0.2.10
show ip bgp summary

Inspect: Choose only commands supported by this device and relevant to the approved change; compare with baseline.

Junos

Read-only operational

show interfaces terse
show route 192.0.2.0/24 detail
show system commit

Inspect: Verify the correct instance and confirmed-commit timing; keep an independent management path.

PAN-OS

Read-only operational

show config diff
show jobs all
show high-availability state

Inspect: Review scope and job outcome. A Panorama push must be checked on the intended target devices.

Worked example · Illustrative, not a device capture

Junos configuration-mode sequence - changes device state

show | compare
commit check
commit confirmed 5 comment "CHG-123 validation window"
run show system commit
commit comment "CHG-123 validated"

Stage only the approved candidate. Run commit check before the timed commit; it can confirm an already-pending confirmed commit.

Issue the final commit only after acceptance. Track the timer. Rollback loads a candidate and requires a commit; choose the correct revision.

Troubleshooting sequence

Record current topology and a timestamped baseline; verify compatibility and the recovery method.
Assign change, test and recovery owners with an agreed deadline and stop conditions.
Make the reviewed change while preserving console/out-of-band access and any confirmed-commit timer.
Test management, actual allowed flows, intended denies and approved redundancy behavior.
If acceptance fails, follow the reviewed recovery decision; otherwise save/confirm, monitor and update documentation.

Common mistakes

Starting without a working independent access path.
Using a generic rollback command without knowing its state and revision.
Confirming the change before application tests finish.

Acceptance checks

Every agreed test has an owner, timestamp and result.
Accepted configuration is saved/confirmed and monitoring is clean.
Recovery records and as-built documentation are complete.

Primary references

Vendor documentation and protocol specifications support this guide. The diagrams, scenarios and troubleshooting sequences are Wolex-authored.

Network deployment & rollback acceptance