Connect. Secure. Manage.
WAN Recovery Runbooks
Develop practical recovery procedures for Cisco and Meraki WAN incidents, with decision points, contacts and safe steps for restoring connectivity.
Devices supported
across the UK
Client locations
supported
Traffic handled
at peak time
Average
response time
Average response is not a resolution time or a contractual guarantee. Support scope and response commitments are agreed for each engagement.
WAN recovery runbooks give engineers a safe sequence to follow when a site loses connectivity or starts switching unpredictably between paths. They turn design knowledge into decisions that can be made under pressure. MCI Network Services develops runbooks for Cisco and Meraki environments using the customer’s actual circuits, management access and application dependencies. A useful runbook explains when to act, when to stop and who has authority to approve the next step.
The whole path
Understand how sites, providers, cloud networks and security controls fit together.
Resilience that can be tested
Separate a second circuit from genuine end-to-end service resilience.
Provider coordination
Keep addressing, routing and escalation ownership clear across organisations.
Build procedures around recognisable symptoms
A procedure organised only by device model can be difficult to use during an incident. Users may report that one application has stopped, that all internet access is unavailable or that remote branches cannot reach a shared service. We organise the initial decision points around those symptoms and connect them to the relevant network components.
Each runbook states its scope and prerequisites. It identifies the sites covered, the expected topology and the tools available to the responding engineer. The procedure also describes what it does not cover, such as a cloud application’s internal failure or a carrier’s physical repair work. Clear boundaries keep a network response from becoming an uncontrolled attempt to fix unrelated systems.
Standards & partnerships
Confidence in the team behind your network.
Cisco Partner
Cisco Meraki
Cyber Essentials
Cyber Essentials PlusMCI Network Services is operated by Proxar Ltd. Certifications apply to the certified legal entity and the scope of its certificates. View accreditation information
Make access and communication part of recovery
The first checks establish whether the team can reach the edge devices and whether the management path depends on the failed WAN. We document alternative access, local contacts and any approved out-of-band method. Credentials themselves remain in the customer’s protected system; the runbook records how authorised people obtain them without embedding secrets in an ordinary document.
Communication needs the same preparation. We identify the incident owner, the people who can approve changes and the supplier escalation route. Where connectivity loss also removes the normal chat or telephony platform, the document provides an agreed alternative. A recovery process that assumes the failed service is available for coordination is incomplete, however accurate its technical commands may be.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Separate diagnosis from disruptive action
The opening stages gather evidence with low-impact checks. These may include interface state, routing neighbours, VPN status, recent changes and the reachability of agreed destinations. Expected results are included so that an engineer can interpret the output rather than simply collect it. Differences between Cisco CLI checks and Meraki dashboard observations are reflected in the procedure.
Disruptive actions are clearly marked. Restarting a router, clearing a tunnel or changing route preference can remove evidence or interrupt otherwise working applications. We specify the authorisation, impact assessment and verification needed before such steps. Where a workaround changes security or routing boundaries, its approval and removal conditions are recorded. Recovery should not leave an undocumented permanent exception behind.
Different environments. The same care.
Built around the work
your network supports.
Finance, banking and the wider private sector. We start with the systems and people that depend on your connections.
Finance & banking
Market-data paths, routing and provider coordination on clients’ behalf.
Financial-market services ↗Offices & multi-site teams
Reliable access between people, workplaces and business applications.
Office network design ↗Data centres & cloud
Network boundaries, workload connections and operational ownership.
Data centre networks ↗Define decision points and rollback conditions
A runbook is more than a linear checklist. It needs branches for the conditions an engineer may actually encounter: local interface down, carrier path unavailable with interface up, wrong default route, failed remote hub or exhausted backup capacity. We keep these branches manageable and link to deeper diagnostic procedures where the investigation exceeds first-line scope.
Rollback conditions are measurable. They can include loss of management access, a new application failure, an unexpected route advertisement or traffic moving through an unapproved security path. The document identifies who can stop the change and what state must be restored. It does not assume that reversing the last command will automatically reverse every session, routing and application effect.
Validate with the people who will use it
Draft procedures are walked through with the operations team before being accepted. We check that device names, dashboard paths, circuit references and supplier contacts are correct. A tabletop exercise can expose missing permissions or unclear ownership without affecting production. Where authorised, a controlled technical exercise demonstrates that the procedure works against the actual estate.
We record the difference between a rehearsed step and an untested assumption. Tests involving a live failover need an agreed window and application representatives where appropriate. The resulting changes improve the runbook’s practical value: fewer ambiguous instructions, clearer expected output and an escalation point before engineers reach the edge of their authority or expertise.
Maintain the document as the WAN changes
Runbooks should be reviewed after provider changes, device replacement, major software updates and significant incidents. Each document needs an owner, version and review trigger. We recommend keeping a readily accessible controlled copy outside the systems most likely to be unavailable during a WAN failure. An obsolete document can be more dangerous than no document if it sends traffic to retired infrastructure.
MCI’s WAN resilience services can combine recovery documentation with design review and failover exercises. We can also produce runbooks for a network your internal team continues to manage. The handover includes the decision flow, evidence requirements and responsibilities, allowing the customer to operate the network without relying on one person’s memory of how it was built.
Talk to a specialist
What does your network need next?
Tell us what you are planning, changing or trying to improve. We will help define a practical next step and the engineering scope.
+44 203 196 6566Choose option 1
sales@proxar.co.ukUK-wide service.
Most of our engineers are based in Kent, with a focus on London, Sussex, Essex and Berkshire.
Existing customers should use their agreed support and escalation channels. This form is for service enquiries, not a monitored emergency ticket.
Tell us what you need.
A short outline is enough. Please do not include passwords or sensitive network details.
Thank you. Your enquiry has been submitted.
Please check your name, email and message, then try again.
Your form session expired. Please try again.
Please wait a minute before sending another enquiry.
We could not submit your enquiry. Please call or email us instead.