Connect. Secure. Manage.
Meraki MX Warm Spare Design
Plan supported MX warm-spare deployments, reviewing addressing, switch connections, uplink arrangements and the effect of a device failure.
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.
Meraki MX warm spare design plans a supported failover pair for eligible physical MX devices. We check WAN links, local topology, addresses and fault detection together. Tests show which failures the design covers and how apps behave when the active unit changes. Two appliances alone do not prove that the full service can recover.
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.
Confirm the platform and deployment requirements
We check the supported appliance pairing, firmware, operating mode and licensing arrangement for the customer's design. Hardware warm-spare guidance should not be assumed to apply unchanged to a virtual MX rollout in a cloud platform. The proposal identifies the exact supported combination before equipment or circuits are committed.
The business need also needs definition. Is the aim to tolerate an appliance failure, an internet-circuit failure or a broader site outage? Those scenarios have different dependencies. A warm-spare pair may address one part of availability while leaving power, upstream switching or the app itself as a shared failure point.
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
Design the LAN topology deliberately
The active and spare appliances need the supported network access and visibility required by the high-availability mechanism. We review switching, VLANs and physical paths according to Meraki's current rollout guidance. Adding an improvised direct connection or redundant cable without understanding the topology can create problems rather than improve resilience.
We also assess the surrounding switches and their power supplies. Both appliances depending on one failed access or distribution device can leave the site offline despite a healthy spare. The diagram should show complete service paths, including the links used by downstream devices to reach whichever appliance is active.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Plan WAN addressing and provider dependencies
Internet handoffs, public addresses and upstream equipment must support the chosen arrangement. We establish whether the design uses separate appliance addresses, a supported virtual-address approach or another documented model, and check the provider's needs. Address availability and subnet constraints are checked before the installation window.
The failure of a circuit is considered separately from the failure of an appliance. Both MX units may depend on the same provider device or physical path. Where multiple internet services are used, we document their diversity and the capacity available when only one remains, rather than assuming the warm-spare setup makes the transports independent.
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 ↗Understand state and application recovery
High availability does not justify a universal promise of uninterrupted sessions. We review the supported behaviour for the features in use and test the customer's important apps. VPNs, translated connections and services tied to a public source address can have different recovery characteristics.
The acceptance criteria distinguish restoration of network reachability from preservation of a current session. A user may reconnect successfully after failover while an earlier transaction still needs to be repeated. Those limitations are explained before rollout so the business can judge whether the design meets its actual continuity need.
Protect management and operational ownership
Dashboard administration and monitoring should make the pair's role and health understandable. We set out who may change high-impact settings, how changes to the settings are reviewed and which team responds when redundancy is lost. A spare that is unavailable can remain unnoticed while the active unit continues carrying traffic.
Replacement procedures are also planned. The team needs to know how a failed appliance is removed and a supported replacement introduced without causing an avoidable role change or address conflict. Serial numbers, cabling and provider details belong in the operational record, not only in an engineer's installation notes.
Test the agreed failure scenarios
We capture the baseline and exercise approved appliance, link or upstream failures where safe. Tests observe the active role, forwarding paths, VPN state and representative app behaviour. We include restoration, because a returning component can expose a topology or addressing issue not visible during the initial failure.
A test should have a defined stop condition and recovery method. We do not disconnect several unrelated components simultaneously and infer which protection worked. Each scenario is recorded separately, with the conditions tested and any limitation that remains unverified in production.
Hand over the actual resilience boundary
The final design states what the pair protects against and which shared dependencies remain. Monitoring, local assistance and escalation contacts are aligned with those boundaries. Periodic checks should identify setup or cabling changes that could undermine the tested arrangement over time.
MCI can design a new pair or review an inherited Meraki SD-WAN site whose failover behaviour is unclear. Share the appliance models, internet handoffs and local switching diagram. We can establish a supported warm-spare scope and show its behaviour without treating an extra appliance as a substitute for a complete availability design.
Technical references
- MX warm spare high availability — Cisco / Cisco Meraki
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.