Yesterday (9/21/2026) provided one of those networking lessons that is difficult to ignore.
A telecommunications failure disrupted air traffic across one of the busiest regions in the United States. Flights were stopped or delayed at Newark Liberty, JFK, LaGuardia, Philadelphia and other airports after communications problems developed at the FAA’s Philadelphia Terminal Radar Approach Control facility — the TRACON responsible for handling significant portions of the region’s air traffic.
The initial headlines made the cause sound almost painfully familiar: Someone cut a fiber-optic cable.
For anyone who has spent time designing or operating telecommunications networks, that immediately raises an obvious question:
How can one fiber cut take down communications supporting air traffic control?
But as more details emerged, the story became considerably more interesting.
There Actually Was a Backup
According to FAA Administrator Bryan Bedford, the primary telecommunications circuit into the Philadelphia facility failed. Normally, that is exactly the situation redundancy is designed to handle.
Primary fails.
Backup takes over.
Users may never even notice.
Except this time, when the system attempted to move to the backup connection, the FAA discovered that the backup fiber had also been damaged. A construction crew working on an NJ Transit project between New Brunswick and North Brunswick had severed the fiber cable. Bedford described the damaged section as substantial; reports said roughly 600 feet of fiber was involved. The result was exactly the scenario network engineers design redundant systems to prevent:
The primary failed, and the backup was unavailable.
Controllers lost access to critical radar and communications capabilities, flights were stopped, aircraft were diverted, and delays propagated across the national air transportation system. Reuters reported roughly 7,000 delayed or canceled flights nationwide during the disruption.
And that leads to the much more important networking question.
Was the Network Redundant, or Was It Resilient?
Those are not necessarily the same thing. It is easy to draw a network diagram containing two lines:
Primary Fiber
Site A ============================== Site B
Backup Fiber
Site A ============================== Site B
Look at that diagram and we can proudly write: REDUNDANT
But the physical network may look more like this:
Site A
|
+------+------+
| |
Circuit 1 Circuit 2
| |
+------+------+
|
Conduit
|
Railroad ROW
|
Site B
Now we have two logical circuits but perhaps only one meaningful physical failure domain.
One backhoe could still ruin everybody’s day.
To be clear, there is no evidence yet that this is exactly what happened Monday. The reporting instead indicates a dual failure: a failure of the primary circuit combined with physical damage to the backup fiber. The precise architecture and physical routing of those circuits have not been publicly documented in enough detail to conclude that they shared the same conduit or right-of-way.
But that distinction doesn’t make the engineering questions go away.
It makes them more important.
Redundancy Requires More Than Two Circuits
When I teach network resiliency, this is an important distinction. Having two circuits is only the beginning.
For infrastructure this critical, engineers should be asking:
- Are the circuits physically path diverse?
- Do they enter the facility through different entrances?
- Do they travel through different conduits and rights-of-way?
- Do they terminate on separate optical equipment?
- Are they served from independent power systems?
- Are they provided by different carrier networks where practical?
- Is the backup path continuously monitored?
- Is failover regularly tested?
- Will operations know immediately if the backup has failed while the primary is still operating?
- Is there a third, technologically independent path for catastrophic failures?
The last few questions may be the most interesting ones in this incident.
A backup connection is not particularly useful if it can remain broken without anyone realizing it until the primary fails.
And Here Is Where the Story Gets Even More Interesting
This was not a completely unforeseen problem. After serious Newark air traffic control communications problems in 2025, the FAA undertook significant telecommunications upgrades between New York and Philadelphia. In July 2025, the FAA announced that it had transitioned to a new fiber-optic communications network between New York and the Philadelphia TRACON. The FAA specifically said the upgrade provided fiber connections over two separate communications paths, intended to allow equipment to continue operating if one path was disrupted.
The agency had also announced additional high-bandwidth telecommunications connections, a temporary satellite backup system, and plans for a STARS hub in Philadelphia so that the facility would not depend entirely upon the New York-based STARS infrastructure. Which makes Monday’s outage worthy of considerably more technical examination.
- What exactly failed on the primary circuit?
- When exactly was the backup fiber damaged?
- Was the backup being continuously monitored?
- If it had already failed, how long had it been unavailable?
- Why wasn’t its condition detected before the primary circuit failed?
- Were additional communication paths available, and if so, why couldn’t they carry the required radar and voice traffic?
- And what happened to the alternative backup mechanisms previously announced?
Those are far more useful questions than simply asking who cut the fiber.
“Diverse” Needs to Mean Diverse
There is another lesson here that extends well beyond air traffic control. Anyone who has purchased telecommunications circuits has probably encountered the phrase: diverse routing.
But diversity has layers:
- Carrier diversity doesn’t necessarily guarantee fiber diversity.
- Fiber diversity doesn’t necessarily guarantee conduit diversity.
- Conduit diversity doesn’t necessarily guarantee central-office diversity.
And two beautifully separate paths might still converge on the same bridge, railroad right-of-way, manhole, utility vault or building entrance.
True resiliency requires engineers to examine the entire failure domain from end to end. I often describe this as looking for the backhoe problem. Imagine putting a backhoe anywhere along the route. Can you find one place where digging through the ground disconnects both paths? If the answer is yes, you don’t have the level of physical diversity you probably think you have.
The Network Worked Exactly as a Safety-Critical Network Should — After It Failed
There is one important point worth recognizing. The aviation system responded conservatively. When controllers couldn’t reliably obtain the radar and communications information required to manage aircraft safely, the FAA stopped or restricted traffic. That created thousands of delays and cancellations. But delays are preferable to trying to operate aircraft in an uncertain communications environment.
In networking terminology, the system failed safe. That is good engineering.
The question is why the communications architecture reached the point where it needed to.
The Bigger Networking Lesson
It would be easy to dismiss yesterday’s disruption as another construction accident. You know: someone dug in the wrong place.
A fiber cable was cut. Technicians repaired it. Planes started flying again. But network engineers should see something different.
This was an enormous real-world demonstration of the difference between: availability, redundancy, diversity, resiliency and disaster recovery.
They are related concepts. They are not interchangeable.
You can have redundant circuits and still have common failure domains. You can have geographically diverse fiber and still share equipment.
You can have a backup network that nobody notices has failed. And you can design excellent automatic failover only to discover that the thing you’re failing over to isn’t there anymore.
That is why redundancy cannot simply be drawn onto a network diagram.
It has to be engineered, physically verified, continuously monitored and regularly tested.
Yesterday, one of the most sophisticated transportation systems in the world provided us with a very expensive reminder of that principle.
And the question I would like answered isn’t simply:
Who cut the fiber?
It is:
Why wasn’t the communications architecture able to survive it?
When Was the Recovery?
NJ Transit says the fiber was accidentally severed at about 9:45 a.m. EDT on Monday, September 21. By just after 6:00 p.m., Transportation Secretary Sean Duffy announced that the telecommunications lines had been repaired and airport operations were resuming. That puts the repair/restoration window at roughly 8¼ hours. I found the following timeline:
- 9:45 a.m. — construction crew severs the Verizon fiber near the NJ Transit Delco Lead project between New Brunswick and North Brunswick.
- During the afternoon, crews were splicing/reconnecting the cable; one report said 36 of 56 fibers had been completed while restoration was underway.
- About 6:00 p.m. — Duffy announces that the telecom lines have been repaired and Northeast airport operations are resuming.
This highlights another telecom reality: repairing a major fiber cut can actually be faster than recovering the services that depended on it. Newark, for example, saw essentially no commercial arrivals from about 9:40 a.m. until after 5:20 p.m., and the airline network continued dealing with cancellations and displaced aircraft and crews well after the telecommunications service itself was restored. The impact affects the entire air travel network, and the recovery could take days.
If you would like to help support the continued development of independent networking, broadband, Wi-Fi, VoIP, and packet analysis content, please consider joining our Patreon community where you will gain access to exclusive technical resources, downloadable labs and PCAPs, bonus course content, troubleshooting guides, and additional member-only material. Comments and technical discussion are always welcomed at our Patreon community or on our Discord server. You can also support our work by simply buying us a coffee — every contribution helps us continue creating practical, real-world network science education for professionals and enthusiasts alike.