Learn how Big Network’s engineers designed Unbreakable Internet — a reflex-driven architecture that keeps sessions alive across ISPs, links, and failover events. Built for operators and VNOs who demand uptime, visibility, and control without carrier lock-in.
Hosted by Jason E.
When you get three seasoned network engineers together in a room—each one with decades of scars from chasing outages that “couldn’t possibly happen”—the conversation doesn’t start with marketing language. It starts with stories about everything that did break.
Over coffee at Big Network HQ, I sat down with Tom Daly (CEO), Andrej Binder (CTO), and Martin Tonhauzer (Senior Engineer) to talk about the idea they call Unbreakable Internet.
Not the slogan—the system. What follows is an edited conversation about the engineering logic, the scars behind it, and why “failover” is no longer enough.
Jason: Let’s start with the obvious. If I’m a Virtual Network Operator (VNO) or one of their clients reading this, what does Unbreakable Internet actually mean?
Andrej: It’s the idea that you shouldn’t have to plan for “what happens when the Internet goes down.” You build once—redundant at every level—so you don’t live in that fear. The network may degrade, but it doesn’t break. Performance dips in 2025 are barely tolerable; total outages simply are not.
Martin: Exactly. Let’s think of Internet connectivity as a complete packaged service by your provider, not a mix of connections, routers, and playbooks that we hope will work. We help VNOs deliver Internet connectivity at the overlay layer - not tied to a physical link. We package the redundancy, the tunnels, the logic, the health checks—all the messy pieces an operator used to custom-build every time - into a service. Instead of paying for high-priced SLAs or ISP-specific engineering, you consume resilience as a service.
Jason: We’ve heard this before. But this isn’t another SD-WAN box that promises uptime—it’s the framework for never writing another “What do we do when it’s down?” runbook.
Andrej: Right. The goal is that a business decision maker never again needs to integrate all these parts and pieces to have a survivable connectivity plan.
Jason: Every operator reading this already has some failover. Why bother changing?
Andrej: Because most “dual-WAN” setups are held together by SLAs, routers and a bit of luck. Each business unit or branch negotiates its own ISPs, obtains SLAs, and deals with configuration quirks. Multiply that across dozens of sites and you’re managing chaos.
When you use Big Network you buy commodity internet access—fiber, LTE, Starlink, whatever—and our overlay makes it reliable. No ISP lock-in, no bespoke configs.
Martin: And most failover logic is dumb. A router sees link = up and assumes connectivity = good. We’ve watched ISPs change DHCP ranges during network maintenances without warning. The link light stays green while traffic silently dies. That’s not failover—that’s wishful thinking.
Jason: So Unbreakable Internet isn’t replacing failover; it’s absorbing it—making it invisible to the operator.
Andrej: Precisely. Redundancy should be built-in, not bolted-on.
Tom: Here’s the question we kept asking: How do you know your Internet is really up?
Some ADVANCED routers use basic ICMP pings as a sign of WAN health - an evolution beyond just a link light. But ISPs filter ICMP all the time—or worse, respond even when you’re stuck in a captive portal. Comcast literally drops non-paying customers into a “walled garden” that still answers pings. So the router thinks you’re fine while every human using the system learns that you don’t pay your credit card bills.
Martin: We’ve seen that in the field. Or T-Mobile filtering ICMP in certain regions—our ICMP only probes looked alive, but no data passed. We had to teach our software to recognize protocol-specific symptoms, not just binary link states.
Jason: So when you say intelligent health checks, you mean protocol-aware, context-aware, and adaptive across worldwide regions?
Andrej: Exactly. We test TCP, UDP, ICMP— via multiple WAN paths—then decide what’s really alive. Different traffic patterns, different probes, different reactions. That’s the difference between “failover logic” and what Tom calls reflex.
Tom: Traditional failover is a timeout and a prayer. What we built is a trained reflex—the network self-diagnoses the way a senior engineer would.
Every outage I’ve seen in my career came from one of two things:
So we turned the checklist into predictable code that thinks like a Senior Network Engineer.
Jason: Like a pilot’s pre-flight routine—same sequence every time, never skipped, just automated?
Tom: Exactly. Just as a surgeon runs through a pre-operation checklist to ensure all equipment is sterilized and accounted for, a similar sequence must be followed. Our system runs that checklist continuously at network speed. It verifies the physical layer, the DHCP lease, the gateway, reachablilty to known stable internet beacons—each layer of the OSI model—in the right order, every time.
It’s not artificial intelligence; it’s experienced intelligence, baked into code.
Jason: Which means the network reacts before the customer notices.
Tom: Or before support gets the 2 a.m. call from a store manager whose POS just went dark. We are taking years of in-the-trenches experience in operating networks and turning it into real, practicable, and reliable code. Other vendor products just don’t do these things - they say “that’s not what’s in the RFCs…” Instead, we turn into code what works in pragmatic network operations.
Jason: Talk to me about testing. How do you validate “unbreakable” without sounding like marketing hype?
Martin: Simple—you try to break it. We set up real devices in real environments: good fiber, bad DSL, flaky LTE. Then we start unplugging cables, changing IP ranges, rebooting processes. If traffic doesn’t survive, we fix the reason it didn’t.
Andrej: We call it living on bad Internet. We intentionally put ourselves on unstable links so customers don’t have to. Every probe, every metric, every failure mode is learned from real abuse in the field.
Tom: We’ve built layers of telemetry for that reason. Latency, jitter, loss—all logged and visualized through the portal. It’s how we prove resilience isn’t theoretical; it’s observable.
Jason: So your own QA is basically controlled chaos?
Martin: Exactly. Controlled chaos until the system stops caring that it’s chaos.
Jason: Let’s tie this back to who this is really for. You’re not selling to consumers—you’re building for operators.
Tom: Right. This is for people who already manage networks—VNOs, service providers, integrators. They don’t need another shiny box; they need leverage. Unbreakable Internet gives them engineering superpowers they can offer downstream without hiring another CCIE.
Andrej: We complement the operator, not replace them. They still choose carriers, deploy hardware, connect their clients—but now they have a platform that automates the resilience part.
Martin: And if you are that engineer who wants to tinker, you can. Everything’s transparent. We expose metrics, logs, and probes. You can go as deep as you want. But if you just want it to work, it does.
Jason: So for VNOs, it’s not about losing control—it’s about finally getting predictable performance without sacrificing flexibility.
Tom: Exactly. We took 50-plus years of collective network-engineering pain and turned it into code. That’s the differentiator. It’s not AI. It’s experience—compressed and reusable.
Jason: Last question. You’re at a conference, someone walks up and says, “I heard about Big Network—what’s Unbreakable Internet?” What’s your answer?
Andrej: It’s a network you don’t have to worry about. You build your business on it, and it quietly does its job.
Martin: Infrastructure-as-a-service at the overlay level. You get redundancy, performance, and visibility without hiring a networking team. We’re the experts—and we turn our expertise into running code–so you don’t have to be one.
Tom: There are plenty of products that promise unbreakable internet. The difference is that we’ve lived the breakage. We built the logic from the bottom of the OSI stack up, we’ve tested it on bad circuits, and we’ve baked those lessons into the product. You’re not just buying a box—you’re getting our collective judgment encoded in software.
Jason: And that’s what makes it feel less like a system and more like a reflex. You can’t control the Internet, but you can control how your network responds to it. That’s what Big Network built—and that’s why it refuses to go down.
If you’re an operator looking to deliver unbreakable Internet access to your customers, it starts with visibility.
Deploy Big Network’s flagship gateway, the IRG-655-1, at your customer premises for advanced failover, real-time diagnostics, and proactive alerting.
Pair it with the Big Network Platform to manage every connection from one pane of glass—because true reliability isn’t just about uptime; it’s about knowing why you’re still up.
