Network Failover Simulator — Dual-WAN Detection & Route Switchover Interactive

Interactive dual-WAN failover simulator with a 3D edge-router/monitor/breaker workbench, path-monitoring and detection-delay controls, route-installation timing, preemptive restoration, curves & measurements, guided experiments, a model-verification bench and a knowledge-check quiz.

← Networking Labs
About this tool — how it works & FAQOpen ▾Close ▴

About the Network Failover Simulator

This simulator models a dual-WAN edge router serving an office LAN through a preferred primary provider path and an alternate backup path, with a path-monitoring processor deciding when to detect an outage and install the backup route, and when — if preemption is enabled — to return to a restored primary. Adjust link health, detection interval, route-installation delay and preemption, then send test traffic and watch the forwarding decision and outage timing.

What the simulator shows

• A real-time 3D cutaway workbench of the office LAN endpoint, dual-WAN edge router, primary and backup provider gateways, path-monitoring processor and remote server, with home view, focus-selected-part, toggleable full-enclosure view, exploded view, auto-rotate and expand controls, tappable numbered components with callouts, and labels matching a companion diagram. • Seven live controls: primary WAN link up/down, backup WAN link up/down, failure-detection interval, route-installation delay, "prefer restored primary" preemption toggle, periodic test-traffic toggle and traffic interval. • Play/pause, single-step (0.1 s) and larger-step (1 s) time controls, plus a playback-speed selector (10x slow motion, real time, 10x faster, 1 minute per second). • Five trial actions: start trial, stop trial, send test traffic, fail primary link and restore primary link, with a live "what is happening" sequence narrative, per-component operating status and forwarding-path tokens. • Six live metrics: whether the selected route is currently available, which path is active (primary/backup/none), elapsed failure-detection time, longest observed outage, successful probes delivered and probes dropped. • A Curves & measurements tab with a network-state-over-time chart, a delivery/probe-loss chart, the full model equations and snapshot measurements. • An Experiments tab with four guided scenarios (healthy probes, primary failure, no viable path with both links down, non-preemptive recovery), an automated model-verification bench of independent checks, and a timestamped event log with a copyable trial report. • A Learn & assess tab with four guided lessons, a two-question knowledge-check quiz and a written scope/reference statement.

How detection, installation and preemption interact

The model treats a failover event as two sequential delays rather than an instantaneous switch: first the monitoring processor must accumulate the configured detection interval while the primary path is down before it recognizes the outage, then the edge router needs the configured route-installation delay before the backup path actually carries new traffic. Probes sent during this window are dropped and count toward the longest observed outage — redundant hardware alone does not prevent an interruption, because both intervals still have to elapse.

Preemption ("prefer restored primary") governs what happens after the primary link comes back: with it enabled, the router returns to the primary once it has been restored for the configured interval; with it disabled, the router keeps forwarding through the already-active backup path even though the primary is healthy again, which the non-preemptive-recovery experiment is built to demonstrate.

Reading the delivery chart and equations

The model equations panel gives Tswitch = detection + route installation, states that delivery requires the selected path to be available, and that outage time accumulates only while no selected path is serving traffic. The state-over-time chart plots which route is selected against time, while the delivery chart tracks cumulative successful versus dropped test probes, letting you see exactly how long a probe run stalls during the detect-then-install window.

This is a generic tracked-route failover model, not an implementation of a specific protocol such as BGP, OSPF or VRRP, and not tied to any vendor's failover feature set. It models probe loss and switching delay only — application-layer retries, NAT state and transport-session survival across the switchover are outside its scope, and all traffic, addressing and fault injection are simulated locally with no real network activity.

Frequently asked questions

Why does the simulator show an outage even though a backup link is healthy?

A healthy backup path is not the same as an instant switchover. The model requires the monitoring processor to complete its configured detection interval before it recognizes the primary outage, and then the edge router needs its configured route-installation delay before the backup path is actually selected for new traffic. Probes sent during that combined window are dropped and count toward the longest observed outage.

What does the "prefer restored primary" (preemption) control do?

It determines behavior after the primary link comes back up. With preemption enabled, the router returns to the primary path once it has stayed healthy for the restoration interval. With it disabled, the router keeps forwarding through whichever backup path is already active even after the primary is healthy again — the non-preemptive-recovery experiment is designed specifically to show this.

What happens if both the primary and backup links go down?

The "no viable path" experiment sets both primaryUp and backupUp to false. Test probes continue failing indefinitely because redundancy only helps when at least one path is healthy — having two links cannot repair a scenario where neither is reachable.

Does this model a specific failover protocol like VRRP or BGP?

No. It is a generic tracked-route failover teaching model — detection interval and route-installation delay are illustrative parameters, not an implementation of any particular routing or first-hop-redundancy protocol. It also does not model application retries, NAT continuity or transport-session survival across a switchover, and all traffic is simulated offline.

Related tools & guides