Or is it that these ATC networks are their own air-gapped network with less redundancy? That just doesn't add up. Or maybe there was only one line going to the ATC, with no multiple "ISPs" like a datacenter would have?
* There is supposed to be a primary and a secondary link, in this case the primary failed and the fail-over also failed. It's unclear from the reporting if they were damaged in the same incident or if the failover was not tested or monitored adequately.
The Philadelphia TRACON site has been notoriously unreliable and was supposedly improved in 2025, it's also unclear if these issue actually could stem from that implementation.
First big oops of this form that I remember:
"In December 1986, the ARPANET had 7 dedicated trunk lines between NY and Boston, except that they all went through the same conduit -- which was accidentally cut by a backhoe. "
One example was a site that had fiber and coax, from different companies. They might have shared a pipe at some point along their length, hard to say. But both connections went down at the same time for digital reasons, not physical. The providers had simultaneous unrelated backend router problems and the site lost contact to both gateways.
This was with a nice SD-WAN system that routed everything dynamically across both pipes to address latency and errors, but if the packets get dropped at the first hop in both networks, there's not much you can do!
The saving grace in that case was the third redundant connection, a 4G cell modem, with a lot less bandwidth but able to keep the critical transactions going. These days I'd certainly want Starlink on the roof as well.
In any system where both sides of redundancy always carry traffic then loss of one link can cause congestion failure if any link fails. This is a very common means of failure in electrical networks that requires load shedding. Well, you can't load shed air traffic.
A more complex system that I like, but comes with it's own set of constraints and implementation issues is a system where both lines carry all the traffic at all times. This way the default state of the system is always working and your first failure isn't invisibly critical.
But this is very hard as we see in TCP when things get out of order and high latency creeps in. You have to manage a lot more state at the data level.
That seems like an extremely foolhardy thing to do.
It seems like it would present a less-chaotic solution than that provided by having no data communications at all.
I'm rather certain the FAA does indeed either employ or contract people that are capable of providing the solution. I'm also quite certain those people live in a perpetual blizzard of responsibility diffusion bullshit: the FAA is a venerable and highly risk-adverse operation. If someone told me it takes months of meetings and sign-offs to so much as log into a router and perform a benign check of some setting, I wouldn't blink.
In this case, that outsourcing could easily look like "call local ISP's, get connections, set up tunnel".
One of the more popular means of diffusing responsibility. A mere symptom, in other words. Not a cause. There is a abundance of qualified contractors in our world that could provide a functioning fail-over solution using whatever medium one might imagine. Somehow, this does not happen. The problem is elsewhere.