Method of procedure (MOP) template for network changes

What a MOP is for

The change record authorizes the work; the MOP is how the work is done. It is written before the change advisory board sees the change, reviewed by a peer who could run it, and followed during the window. Every step has an expected result, and the rollback is written, with its trigger, before anything is touched.

A MOP is specific to one change; a runbook covers a recurring operation. If you make the same change often, turn its MOP into a tested template for a standard change, and keep the pre-check and verification sections for every run.

Scope

• Intent in one sentence, and the invariants: what must not change.
• Devices in scope: hostname, role, site, platform, software release, and console or out-of-band access for each.
• Out of scope: what this change will not touch, stated so nobody widens it during the window.
• Dependencies: other teams, carriers, vendors and other changes in the same window.
• The window: start and end with the time zone, the latest time rollback can start and still finish inside the window, and any point of no return.

Risk and impact analysis

• Blast radius: the devices, paths, services and users affected if the change goes wrong, not only if it goes right.
• Redundancy during the change: will any service run on a single path, member or unit, and for how long?
• Expected impact, stated precisely: “one HSRP role change per core, each under 5 seconds of loss”, “the BGP session to ISP-A resets once”.
• What could go wrong: the realistic failure modes, each with likelihood, impact and mitigation.
• Testing: lab results, earlier runs of similar changes, and the release notes and known issues for any new software.
• Conflicts: change freezes, business events and other changes that touch the same devices or paths.

Pre-checks and the go/no-go decision

List each pre-check with its command and its pass condition, and keep the outputs: they are the baseline for verification. Typical pre-checks:

• Configuration saved, with no unsaved or uncommitted changes, and a copy stored off the device.
• Console or out-of-band access tested on every device in scope.
• Both members of every redundant pair healthy and in sync.
• No open incident on the affected services.
• Baseline outputs captured for every verification step (see how to verify a network change).
• Approvals in place, and the people needed on the call present.

Name the person who makes the go/no-go call. If a pre-check fails, the answer is no-go, and the change is recorded as Blocked with the failed check as its evidence.

Implementation steps

• Number every step, with one device and one action per step.
• Write the exact commands, ready to paste, and the configuration mode they run in.
• Give each step an expected result and a checkpoint: the command that proves the step worked before you continue.
• Estimate each step’s duration, so you know early when the window is at risk.
• Mark state-changing steps, and the step after which rollback becomes harder.
• Use the platform’s safety nets. Words in capitals in the commands below are placeholders for your values.

Verification steps with expected results

For each check, write the command, the expected result, and a place for the immediate and the delayed result. Expected results must be specific enough that two engineers would agree on pass or fail: “4 BGP neighbors established, received prefixes within 2% of the baseline” rather than “BGP OK”.

Include data-plane checks (probes across the paths the change touches), not only protocol state, and a delayed check at a set time after the window. End the section with the verdict: Verified, Degraded, Rolled back, Inconclusive or Blocked, as defined in how to verify a network change and in the glossary.

Rollback plan and trigger

• The trigger, written as measurable conditions: “roll back if fewer than 46 of 48 probes pass for 60 seconds, if either core is not Active or Standby for HSRP 5 minutes after its reload, or if the BGP session to ISP-A is not established within 10 minutes.”
• The decision owner, by name, and who they consult.
• The latest rollback start time that still finishes inside the window.
• The rollback steps, as exact as the implementation steps, with expected results.
• Rollback verification: the same checks as the baseline, with the baseline as the expected result.
• If rollback fails: who is called, in what order, and the fallback (console access, spare hardware, a vendor support case).

Where the platform offers a timed commit with automatic rollback (Junos (opens in a new tab) commit confirmed, EOS commit timer), use it for changes that could cut off your own access: the rollback then happens even if you can no longer reach the device. See rollback.

Communications

• Before: notice to affected users and the service desk, with the window and the expected impact.
• At the start: the bridge or channel is open, the people on it are named, and the service desk knows the change is live.
• At milestones: the go/no-go decision, each major step, any deviation.
• At the end: completed or rolled back, the verdict, and whom to call if something looks wrong tomorrow.
• Contacts: carriers and vendors, with contract or case numbers, in the MOP rather than in someone’s phone.

Approvals

• Technical review by a peer who could run the MOP.
• The owner of each affected service, for the impact and the window.
• Security, for any firewall policy, access-control or segmentation change.
• The change manager or change advisory board, as your change policy requires.

Record each approver, the MOP version they approved and the date. If the MOP changes after approval, it goes back for review.

Evidence to attach to the ticket

• The approved MOP version.
• Pre-check outputs (the baseline), per device.
• The configuration diff, per device.
• Immediate and delayed verification outputs, and the probe results.
• An execution log: each step with its time and who ran it, and any deviation from the MOP with the reason and who approved it.
• The verdict, with one sentence of reason.
• The communications sent.

Remove passwords, keys and community strings before attaching configurations.