How to Plan Network Redundancy with Meraki

Network downtime is one of the most disruptive and expensive events a UK business can experience. When the network goes down, everything stops — email, cloud applications, VoIP phones, payment systems, and access to shared files all become unavailable simultaneously. For businesses that depend on internet connectivity for daily operations (which today is virtually every business), even a brief network outage can have significant financial and operational consequences.

Network redundancy is the practice of building backup pathways and failover mechanisms into your network infrastructure so that the failure of any single component does not bring down the entire network. Cisco Meraki, with its cloud-managed networking platform, provides several powerful tools and features that make implementing network redundancy more accessible and manageable than traditional networking solutions — particularly for UK businesses that may not have large dedicated network engineering teams.

This guide explains the principles of network redundancy, how Meraki's platform supports redundant architectures, and the practical steps to design a resilient network that keeps your business operational even when components fail.

Understanding Network Redundancy Principles

Network redundancy operates on a simple principle: eliminate single points of failure. Every component in your network — from the internet connection to the firewall, from the core switch to the wireless access points — represents a potential point of failure. If any single component fails and there is no redundant alternative, the services that depend on that component become unavailable.

Redundancy can be implemented at multiple layers of the network. WAN redundancy ensures that internet connectivity continues even if one internet connection fails, by providing two or more independent internet circuits from different providers. Device redundancy ensures that the failure of a switch, firewall, or access point does not take down the network, by deploying devices in pairs or clusters. Path redundancy ensures that data can reach its destination even if a cable is damaged or a link between switches fails, by providing multiple physical paths between network devices.

The goal is not necessarily to make every component redundant — that would be prohibitively expensive — but to identify the components whose failure would have the greatest business impact and build redundancy at those critical points.

Conducting a Business Impact Analysis

Before investing in network redundancy, UK businesses should conduct a structured business impact analysis to understand where their greatest vulnerabilities lie. This involves mapping every business-critical application and service to the network components it depends upon, then assessing the financial and operational impact of each component failing. For a typical UK office, the internet connection is almost always the single most impactful point of failure — when it goes down, cloud-hosted email, CRM systems, VoIP telephony, and web-based applications all become unavailable simultaneously.

The results of this analysis should guide your redundancy investment priorities. A solicitors firm that relies entirely on cloud-hosted case management software and VoIP telephony would prioritise WAN redundancy above all else, as losing internet connectivity renders the entire practice unable to function. A manufacturing business with on-premises production systems might prioritise switch redundancy at the factory floor to ensure barcode scanners and production line equipment remain connected, even if a brief internet outage would be tolerable.

Quantifying the cost of downtime in pounds per hour helps justify the investment in redundancy to stakeholders who may view it as an unnecessary expense. When a one-hour outage costs the business several thousand pounds in lost productivity and missed revenue, the annual cost of a secondary internet connection or a warm spare firewall looks very reasonable by comparison. This financial justification is particularly important when presenting redundancy proposals to boards and finance directors who may not appreciate the technical risks without a clear business case expressed in monetary terms.

WAN Redundancy with Meraki MX

For most UK businesses, the single most impactful redundancy investment is a second internet connection. The Meraki MX security appliance makes dual-WAN connectivity straightforward to implement and manage. Every MX appliance supports at least two WAN interfaces, and some models support a dedicated USB cellular failover connection as a tertiary backup.

When you connect two internet circuits to a Meraki MX, you can configure them in several modes. Active-passive mode uses the primary circuit for all traffic and automatically fails over to the secondary circuit if the primary becomes unavailable. This is the simplest configuration and works well when your secondary circuit is a lower-bandwidth or higher-cost connection (such as a 4G/5G cellular backup) that you only want to use during outages.

Load-balancing mode distributes traffic across both circuits simultaneously, providing increased total bandwidth during normal operation and automatic failover if either circuit fails. This mode maximises the utilisation of both connections but requires that both circuits have adequate bandwidth for critical traffic.

The Meraki MX monitors the health of each WAN connection continuously, sending probe traffic to detect outages. When a failure is detected, traffic is automatically rerouted to the surviving circuit — typically within seconds. This failover is transparent to users; active sessions may experience a brief interruption, but connectivity is restored almost immediately without any manual intervention.

Optimising WAN Failover Performance

While the Meraki MX handles WAN failover automatically, there are several configuration decisions that affect how smoothly the failover occurs and how well the network performs on the backup connection. One critical consideration is bandwidth asymmetry — your primary connection might be a 500 Mbps fibre leased line, while your backup is a 100 Mbps broadband circuit or a 50 Mbps cellular connection. During a failover event, the available bandwidth may drop dramatically, and without proper traffic shaping, critical applications could be starved of bandwidth by less important traffic.

The Meraki MX addresses this through its traffic shaping and application-aware firewall capabilities. By configuring traffic shaping rules, you can ensure that during a failover to the lower-bandwidth backup circuit, business-critical applications such as VoIP, video conferencing, and your primary cloud applications receive priority access to the available bandwidth, while less critical traffic such as software updates and file synchronisation is throttled. This approach ensures that the business can continue operating effectively even on a reduced-bandwidth connection.

For UK businesses considering cellular backup, the Meraki MX supports USB cellular modems as a tertiary WAN connection. This provides an additional layer of protection against the scenario where both fixed-line connections fail simultaneously — for example, if they share a common physical path into the building that is damaged by roadworks or flooding. A 4G or 5G cellular connection uses an entirely independent infrastructure, providing genuine diversity in your connectivity resilience.

SD-WAN and Intelligent Path Selection

Modern Meraki MX appliances include SD-WAN capabilities that go beyond simple failover. With SD-WAN, the MX can make per-application routing decisions based on real-time performance metrics for each WAN connection, including latency, jitter, and packet loss. If your primary connection begins experiencing degraded performance — perhaps due to congestion at your ISP rather than a complete outage — the MX can automatically route latency-sensitive applications such as voice and video over the secondary connection while keeping bulk data traffic on the primary.

This intelligent path selection means that your dual-WAN investment delivers value not just during complete outages, but during the far more common scenarios of partial degradation that can severely affect application performance. For UK businesses that rely heavily on real-time communication tools such as Microsoft Teams or Zoom, SD-WAN path selection can significantly improve the user experience even during normal daily operation.

Firewall High Availability with Warm Spare

The firewall is the gateway between your internal network and the internet. If it fails, all internet connectivity ceases — even if your internet circuits are functioning perfectly. Meraki's Warm Spare feature provides firewall-level redundancy by pairing two identical MX appliances in a high-availability configuration.

In a Warm Spare configuration, one MX acts as the primary (active) appliance, handling all traffic. The second MX acts as the spare (standby), maintaining a synchronised copy of the primary's configuration and state. If the primary appliance fails — due to a hardware fault, power issue, or any other reason — the spare automatically takes over, assuming the primary's IP addresses and continuing to process traffic. The failover is typically completed within seconds, and because the spare already has the correct configuration, no manual intervention is required.

Warm Spare configuration is managed entirely through the Meraki dashboard, making it significantly simpler to deploy than traditional high-availability firewall configurations, which often require complex VRRP or HSRP configurations and command-line expertise.

Warm Spare Deployment Considerations

When planning a Warm Spare deployment, several practical considerations affect the effectiveness and reliability of the configuration. Both MX appliances must be identical models running the same firmware version. The spare appliance requires its own Meraki licence, which means the cost of firewall high availability includes not just the second hardware unit but also an ongoing licence for the standby device. For UK businesses budgeting for this, the licence cost of the spare should be factored into the total cost of the high-availability solution from the outset.

Physical placement of the spare appliance is another important consideration. Both units should be connected to the same network segments and have access to the same WAN connections, but ideally they should be powered from different power sources or protected by different uninterruptible power supplies. If both the primary and spare MX are connected to the same power strip and that strip fails, your high-availability configuration provides no protection. Similarly, if both units are in the same rack and a localised environmental issue such as overheating affects the rack, both units could fail simultaneously.

It is also essential to test the Warm Spare failover periodically, not just at initial deployment. Hardware and software changes over time can introduce subtle issues that prevent failover from functioning correctly. We recommend scheduling a controlled failover test at least twice per year, documenting the failover time and verifying that all services resume correctly on the spare unit. This testing discipline gives you confidence that the redundancy mechanism will actually work when you need it during a genuine incident.

Switch Redundancy and Stacking

At the switching layer, Meraki MS switches support physical stacking — connecting multiple switches together so they operate as a single logical unit. A stack of switches shares a single management interface, a single configuration, and a common switching fabric. If one switch in the stack fails, the remaining switches continue to operate, and devices connected to functioning switches maintain network access.

For core network redundancy, deploy your core switches in a stack of at least two units, with uplinks from each access switch connected to different members of the core stack. This ensures that the failure of any single core switch does not disconnect any part of the network. For additional resilience, connect critical servers and infrastructure to multiple switch ports using link aggregation (LACP), distributing their connections across different stack members.

Physical Cabling and Path Diversity

Effective switch redundancy extends beyond simply deploying multiple switches — the physical cabling infrastructure must also support redundant paths. When connecting access switches to core switches in a stacked configuration, run the uplink cables through different cable routes or conduits wherever possible. If all uplinks follow the same physical path, a single event such as accidental damage during building work or a rodent chewing through cables in a ceiling void could sever all connections simultaneously, defeating the purpose of having redundant switch hardware.

For businesses occupying multiple floors of a building, this means running uplink cables through separate risers or cable shafts to the core switching location. Where the building infrastructure only provides a single riser, consider deploying a small distribution switch on each floor to provide local resilience, rather than relying solely on long cable runs back to a centralised core. This distributed approach also reduces the volume of cabling needed and can simplify troubleshooting when connectivity issues arise on a specific floor.

Link Aggregation for Critical Connections

Link Aggregation Control Protocol (LACP) is a valuable tool for increasing both bandwidth and redundancy for critical network connections. By bundling multiple physical links into a single logical connection, LACP provides increased throughput during normal operation and automatic failover if one of the bundled links fails. Meraki MS switches support LACP natively, and the configuration is managed entirely through the Dashboard with just a few straightforward settings — a significant simplification compared to the command-line configuration required on traditional managed switches.

Common use cases for LACP in UK business environments include connections between access and core switches, links to file servers and network-attached storage devices, and uplinks to virtualisation hosts running multiple virtual machines. For any device or connection where both high bandwidth and link resilience are important, LACP provides an effective and cost-efficient solution that uses standard Ethernet cabling and does not require any additional licensing or specialist hardware beyond the switch ports themselves.

Wireless Redundancy with Auto-RF

Meraki's wireless access points include an intelligent feature called Auto-RF that provides a degree of wireless redundancy without any additional hardware. Auto-RF continuously monitors the radio frequency environment and automatically adjusts each access point's channel, transmit power, and other radio parameters to optimise coverage and performance.

If an access point fails, neighbouring access points detect the coverage gap and automatically increase their transmit power to extend their coverage area and compensate. While this does not provide the same level of redundancy as a dedicated backup AP, it significantly reduces the impact of an AP failure on user experience — particularly in environments with overlapping coverage, which is the recommended deployment model.

For mission-critical wireless environments — such as warehouses using wireless barcode scanners or healthcare facilities using wireless medical devices — you may want to deploy additional access points specifically for redundancy, ensuring that the failure of any single AP does not create a coverage gap in any critical area.

Planning Wireless Coverage for Resilience

Designing a wireless network with built-in resilience requires a different approach to coverage planning than simply deploying the minimum number of access points needed for basic connectivity. Rather than spacing access points at the maximum possible distance from one another, a resilient wireless design deliberately overlaps coverage zones so that every area of the building is served by at least two access points. Under normal conditions, this overlapping coverage is managed by Auto-RF to avoid co-channel interference; if an access point fails, the neighbouring units can extend their coverage to compensate without leaving dead spots.

For UK businesses operating in older buildings — which often feature thick internal walls, reinforced concrete floors, and other construction materials that heavily attenuate wireless signals — a professional wireless site survey is strongly recommended before deployment. A site survey maps the radio frequency environment throughout the building, identifies areas with challenging propagation characteristics, and provides a data-driven access point placement plan that accounts for both coverage quality and resilience. The modest cost of a site survey is repaid many times over through reduced troubleshooting time and improved user experience across the lifetime of the deployment.

In environments where wireless connectivity is truly mission-critical — such as warehouses using wireless handheld scanners, healthcare facilities relying on wireless patient monitoring equipment, or manufacturing sites with wirelessly connected automation systems — consider deploying access points with an explicit N+1 redundancy model. Under this approach, each coverage zone is served by one more access point than strictly required for normal operation. If any single access point fails, full coverage and performance are maintained without relying solely on the auto-healing behaviour of neighbouring units, providing the highest level of wireless resilience available.

Testing Your Redundancy

A redundancy design that has never been tested is a hope, not a plan. Regular failover testing validates that your redundancy mechanisms work as expected and that failover times are within acceptable limits. Schedule failover tests at least annually — and after any significant network changes — for each layer of redundancy. Document the results, including failover times, any services affected, and any issues discovered. Use these results to refine your redundancy design and address any gaps.

Meraki's cloud-managed platform makes testing easier than traditional networks. You can simulate WAN failures by disabling a WAN port from the dashboard, trigger Warm Spare failover by temporarily powering off the primary MX, and observe switch stack behaviour by disconnecting a stack member. Throughout each test, the Meraki dashboard provides real-time visibility into failover progress and network status.

Building a Structured Failover Testing Programme

A structured failover testing programme ensures that your redundancy mechanisms remain functional over time and that your team knows how to respond when a genuine failure occurs. Create a testing schedule that covers each redundancy layer at least once per year, and document a step-by-step procedure for each test scenario. The procedure should include the expected behaviour during failover, the metrics to observe such as failover time and packet loss, and the specific criteria for a successful test. Maintain records of every test, noting any deviations from expected behaviour and the corrective actions that were taken.

Always conduct failover testing during planned maintenance windows, with appropriate stakeholders informed in advance. Whilst Meraki failover mechanisms are designed to be transparent to users, there is always a small risk that testing reveals an unexpected issue — and it is far better to discover such problems during a controlled maintenance window than during a genuine failure on a busy Monday morning. Ensure that your team has a clear rollback plan for each test, so that normal operation can be restored promptly if the failover does not behave as expected.

Documenting Your Redundancy Architecture

Comprehensive documentation is the often-overlooked foundation of effective network redundancy. Your documentation should include a network topology diagram showing all redundant components and failover paths, an inventory of all network hardware with serial numbers and licence expiry dates, a list of all WAN circuits with provider contact details and circuit reference numbers, and documented procedures for both automated and manual failover scenarios. This documentation proves invaluable not only during outage response but also during routine changes, when onboarding new team members, and when engaging third-party support providers.

Crucially, store your network documentation in a location that remains accessible even during a network outage. If your documentation is hosted exclusively on a cloud platform that requires your office network to access, it will be unavailable precisely when you need it most. Consider maintaining a printed copy of critical information — including WAN circuit details, ISP support telephone numbers, and basic failover procedures — in a clearly marked folder at each site. For organisations using Meraki across multiple locations, the Meraki Dashboard itself provides an excellent centralised view of the network, but ensure that at least one team member can access the Dashboard from a mobile device over a cellular connection during a fixed-line outage at the office.