One Office, One Cut: an animated explainer of twenty people on fibre, 4G and 5G when a digger cuts the fibre, comparing session-based failover with connection bonding, with scoreboards for people interrupted, calls cut off, call silence and payments interrupted, and a live router event log. Made by Munir Kotadia. Full description, screenshots and options: All the work, described.
Twenty people at work on fibre, 4G and 5G. Anna is closing a €48,000 contract on a Teams call, Ben is approving the month's supplier payments in online banking and Clara is taking a €4,800 card payment from a customer at reception. Halfway through the customer's sentence, a digger cuts the fibre in the street.
How to read this: a worked example, not a product benchmark. The conventional setup uses session-based WAN failover; the bonded setup keeps a tunnel to a Hub over multiple links. Timings and app outcomes are illustrative. Actual results depend on configuration, remaining capacity and how each service handles a network change.
Session-based failover gives each connection one line. Bonding spreads every connection across all of them.
Each figure is one person, coloured by what they are doing, and every dot is their traffic on its way to the service they use. The label on each desk shows which line that person's work runs on. A ring turns red when their work stops and amber while it recovers or runs slower.
The failover router keeps sending into the dead fibre until three health checks fail, then moves sessions to lines with different public addresses, so existing connections have to reconnect. The bonding router stops using the fibre within a fraction of a second, and the hub address the services see does not change.
Anna is on a Teams call with Martina Weber at Hansen Logistik. The fibre is cut 06:41 into the call, halfway through Martina's sentence.
Each row is one person's traffic and every tick is data getting through. Gaps are time when nothing got through. Anna, Ben and Clara are the thicker rows.
Four calls go silent for 9 s each. Ben and a colleague are logged out of online banking, sign in again with two-factor authentication, then have to check by hand whether their payment runs went through. Clara's card payment times out with an unknown status and has to be taken again. Five people on the web wait 4.5 s.
A few packets are lost at the moment of the cut and sent again; on the calls that is too few to hear. The banking sessions stay signed in, the payment run goes through once, and Clara's customer gets a receipt. With one line gone there is less capacity until the fibre is repaired; calls and payments need little of it.
The figures below are set for this example office of 20 people. They are placeholders, so replace them with your own.
failures × people × minutes ÷ 60 × hourly cost
With bonding, connections on the lines that are still working carry on, so these interruptions are avoided as long as the remaining lines have enough capacity for the work.
Illustrative simulation, not a benchmark. The office, people, timings, link characteristics, packet counts and application outcomes are constructed for explanation and have not been measured. The conventional example represents session-based WAN selection with health-check failover; it does not represent every SD-WAN or multi-WAN product. Its three-second detection interval and nine-second call silence are scenario assumptions. The bonded example assumes a working router-to-hub tunnel, a stable hub-facing public address, sufficient capacity on the surviving 4G and 5G links, and successful recovery of traffic after the fibre fails. It allows a brief packet-loss event, but the displayed application outcomes are illustrative. A stable public address can help preserve sessions; it does not guarantee that a bank session stays authenticated or that a payment is approved. Teams quality depends on packet loss, jitter, latency, available capacity and application behaviour. Payment status after a lost response must be checked through the terminal/provider workflow before retrying. The 50-packets-per-second voice rate and displayed audio-uptime/packet-loss values are model outputs based on assumptions, not captured call telemetry. Customer names and reserved documentation IP addresses make the example concrete; they do not imply endorsement. The calculator estimates staff time from user-entered assumptions, not verified losses or guaranteed savings.