How should switches and routers be configured for redundancy?

What work must continue when a device fails? ↑

Redundancy is designed to keep essential work going through equipment failures and maintenance. Before installing a second device, decide which failures the design must withstand and what work must continue.

A small office might tolerate the time needed to swap in a spare. But if PC-A must keep completing transactions with the internal server App-S, waiting for a replacement may not be acceptable. Work with the people responsible for the business process to distinguish a brief failure to establish new connections from losing work already in progress.

Separate the failure scenarios, too. A cut cable, a switch losing power, and a router losing its uplink leave different functions and paths unavailable. Work may also need to continue during planned software maintenance. For each scenario, the design should list both the functions that stop and those that must keep working.

In the two-tier example, A1 has separate L3 connections to D1 and D2. The design provides a path to the server through D2 if D1 fails. But if PC-A connects only to A1, it cannot retain access when A1 fails. Mark both the surviving path after a D1 failure and the disconnected endpoints after an A1 failure. That makes the protection provided by the two uplinks clear.

If both devices depend on the same power source or conduit, a power outage or conduit damage can take both down. Keep the dependencies identified in failure-domain design in view here as well. Providing a backup for one device and separating shared causes of failure are different preparations; testing one does not verify the other.

The same dual-uplink design can produce different outcomes depending on what fails. On the left, D1 fails. On the right, A1 fails—the only device PC-A connects to. Having healthy devices upstream does not, by itself, preserve PC-A's access.

Two switches or two cables: what's the difference? ↑

Link redundancy addresses a connection failure; device redundancy addresses the loss of functions a device provides. If both cables terminate on the same switch, both paths become unavailable when that switch loses power.

Bundling several links between two switches into an EtherChannel allows traffic to use the remaining members if one link fails. But capacity decreases, and the assignment of flows to links can change. The relationship between combined link capacity and a single flow's speed is the same as in the link-aggregation article.

The situation changes if the links terminate on two independent switches. A supported stack or multichassis technology must make them act as one logical peer before you can design link aggregation across them under those supported conditions. Connecting cables to any two switches and enabling LACP does not automatically create one bundle.

With independent devices connected by L2 paths, STP may block forwarding on some paths to prevent loops. Having an alternate path does not mean both links carry traffic normally. For the two-tier example's L3 uplinks, STP is not the path-selection mechanism: routing selects the paths. Keep the behavior of L2 and L3 alternatives separate.

A stack cannot move a disconnected endpoint's cable to another port. If PC-A connects only to A1, losing power to A1 removes its physical access. Healthy endpoints and uplinks on A2 do not let PC-A communicate. Decide separately whether critical endpoints need their own alternate connections.

Give cable failure, switch failure, and a broken stack connection separate rows in the test plan. In each test, check the endpoints' ports, AP power, uplinks, and management access. Verify control-plane switchover and state retention on the actual model, software, and connections. A result from one product does not apply to every stack.

Compare two cables to the same switch with uplinks distributed across stack members. Even on the right, PC-A loses access if it connects only to A1 and A1 fails.

Gateway failure: where does the PC send traffic? ↑

If a default gateway fails, a PC needs another device to take over that gateway role to keep communicating. To explain this, we'll use a separate L2 access design, not the earlier two-tier configuration. The PC's VLAN extends to both GW1 and GW2.

Suppose PC-A is 10.60.10.21/24 and its default gateway is the virtual IP address 10.60.10.1. First-hop redundancy protocols such as HSRP and VRRP allow routers to take over the role of this virtual gateway. An L3 switch that supports the same function can act as a router here, too.

Normally, GW1 holds the active role and forwards traffic sent to the virtual gateway. In a typical virtual-MAC configuration, PC-A sends frames to the virtual MAC associated with that virtual IP. The diagram's virtual MAC illustrates that relationship; it does not imply that HSRP and VRRP use the same address format.

When GW2 detects GW1's failure and takes over, PC-A can keep its gateway IP setting and continue using the same virtual gateway. The switches must forward the virtual MAC toward the new device, whose routing and policy must also be correct. Even after the active role changes, frames may take time to start reaching the new device.

This change does not automatically copy NAT mappings, firewall connection state, or VPN cryptographic state. First-hop redundancy provides endpoints with a gateway they can continue to use. In the two-tier example, however, that gateway is A1: a D1 failure is not automatically the PC's HSRP failover. Both designs may use an alternate path after a failure, but the gateway location and the function being transferred differ.

In first-hop tests, record the PC's gateway information, the active role, the forwarding location of the virtual MAC, and the actual request and reply paths. Consult each protocol's documentation for its terminology and behavior. Use HSRP's Active and Standby labels, and VRRP's role names, according to that protocol's own states and transition procedures.

This diagram uses a separate PC VLAN extended to GW1 and GW2 at L2. It shows GW2 taking over the virtual gateway role after GW1 fails.

Gateway up, upstream path down: what happens? ↑

A device being up does not mean it can reach the destination. A PC may receive a reply from its gateway, yet the business operation can still fail if that gateway has lost its path to the server.

In the earlier L2 comparison, suppose GW1's user-facing interface stays up but its uplink fails. If that failure is not among the conditions monitored by the first-hop protocol, GW1 may remain active. The configuration must specify which interfaces, routes, or reachability checks to track and how their results affect the role.

If GW1 can route around the failed uplink, it may continue serving as the gateway. Distinguish the current active device choosing another healthy path from transferring the gateway role itself. Tracking something unrelated to the actual business path can trigger an unnecessary switchover or miss a real failure.

Back in the two-tier routed-access example, PC-A's gateway remains A1. What changes is the upstream path through D1. A1 must detect the failure, update its routes, and apply the change to forwarding before sending through D2. After checking the route in the RIB, verify that the FIB reflects it and that actual packets take the new path.

The server's return route and policy for A1's subnet must also work through D2. Once you have confirmed requests leaving through D2, check that replies return as well. Path tracking and first-hop redundancy can complement each other, but enabling them does not prove end-to-end communication works.

Now return to the two-tier routed-access design. After D1 fails, PC-A's gateway stays on A1. Only A1's upstream path to the server changes to D2.

New packets get through—so why do existing connections fail? ↑

An alternate path may exist, but users may still need to reconnect if the state required by existing connections is missing. Record when packets start getting through again separately from when the application finishes its work.

If edge device E1 translates the address and port for PC-A's Internet connection, replies need that mapping. Replacement edge device E2 may know the route but not the mapping, leaving it unable to return replies for an existing flow to the original endpoint. This is a NAT issue; distinguish it from internal traffic that uses no NAT.

For a stateful firewall, check connection state; for a VPN, check security-association state as well. Implementations differ in what they synchronize, when they do so, and which connections survive a switchover. HSRP, VRRP, and a routing change do not synchronize that state by themselves.

For a teaching timeline, place the failure at 0ms, detection at 40ms, selection of a new route at 120ms, a test packet's successful round trip at 180ms, and completion of a business transaction at 900ms. These are neither test results nor product guarantees. The invented values show that detection, route selection, packet round trips, and business recovery can finish at different times after the same failure.

Business recovery can take longer because of retransmissions, new connections, authentication, or an application's retry delay. Measure to identify the cause; do not count all the time until a transaction finishes as routing convergence. Test existing connections separately from work started by a new user to distinguish the effect on each.

The results should identify the connection types and business operations tested. Distinguish a successful save from a simple response. Some packets may return while other sessions remain broken. Record which work continued and which required reconnection so operators can see both the protection provided and the remaining problems.

For the same failure, the diagram marks detection, route selection, a packet round trip, and business completion at separate times. It shows why the entire interval up to business completion should not be reported as routing convergence.

Can the remaining side handle the load and enforce policy? ↑

After a failure, check not just whether a path exists, but whether the remaining resources can carry the same work. If the design relied on spare capacity spread across two devices, losing one may eliminate that headroom.

In the two-tier example, each access device's 8Gbps demand uses 80% of its one remaining 10Gbps link to D2. The three access devices' combined 24Gbps uses 60% of D2's 40Gbps service connection. The same failure leaves different headroom on access and aggregation links, so one ratio cannot establish that the whole network has enough capacity.

When connectivity returns, reconnections and deferred work can arrive together, creating more traffic than usual. Record drops and delay on each link alongside business-completion times, and check CPU load, session limits, and circuit bottlenecks. A low average utilization can hide a brief overload; look for intervals the measurements may have missed.

Measure capacity through security devices with the required policies and inspection enabled. Higher throughput obtained by disabling inspection or allowing blocked guest traffic is not throughput under the required security conditions. Test representative allowed and denied traffic under the same conditions on both the normal and replacement devices.

Work may resume while only one device or path remains, leaving less protection against the next failure. Report the surviving path's load, the impact of another failure, and the repair and return plan separately. Distinguishing restored service from restored redundancy helps set the right urgency for further maintenance.

Can a repaired device return without disrupting work? ↑

Returning a repaired device is more than powering it on. Routes, roles, and state change again: it is a second transition. A successful failover does not remove the need to test the return separately.

First, check that D1 or GW1 returns with software, configuration, and policy matching the current operating baseline. It may be missing changes applied to D2 during the incident. Do not stop at checking that neighbors have formed and links are up; verify that the device is ready to handle traffic with the current configuration and policies.

With preemption or automatic route restoration configured, traffic may move as soon as the device reconnects. Check the product documentation and current configuration for automatic-return conditions, delays, and manual controls. Schedule the work and assign people to watch routes and traffic so an apparently simple cable connection does not cause another outage. The business representative checking existing sessions should also be ready at the transition.

After the return, recheck existing connections, new requests, both traffic directions, load, and traffic that must remain denied. If results differ from expectations, follow the approved stop criteria and roll back to the alternate operating state. Do not test a return without the management path and configuration needed to roll it back.

In the final record, distinguish normal operation, operation on the alternate path, preparation for return, and the protection available after return. Apply the same criteria to the next article's core design for multiple blocks. When adding a core, first identify the failures to withstand and the functions other devices must take over. In design validation, record only what was actually observed.

Operating on D2 alone is different from restoring redundancy with D1 back in service. Also decide which state to return to if the reintroduction causes a problem.