Yes, They Were Overloaded. The Question Is Why.

This is my opinion. I’m asking questions about the official conclusions. I don’t have any private facts, and I’m not claiming anyone had bad motives.

Two huge systems went down a day apart. On Thursday, November 12, Microsoft 365 failed around the world. Email was late or unreachable, calendars broke, and the AI tools on that same platform, including Microsoft’s Copilot, couldn’t load or reach work files. Microsoft says the disruption ran from early Thursday through mid-morning Friday, Central Time, and that service was fully restored early Saturday.

Then Friday afternoon the FAA halted departures nationwide after a communications problem in air traffic control. Transportation Secretary Sean Duffy said radar and radio links became unstable at 3:36 p.m. Eastern. The stop was issued shortly after, for safety, and airspace reopened at 8:15 p.m. Eastern. Reuters, citing a flight-tracking service, reported that by late that night nearly 10,000 flights had been canceled. It was only the second nationwide halt of departures since September 11, 2001.

Officials say both events were overloads, and that they aren’t connected. I’m not convinced we have the full story yet.

Microsoft says a network change exposed a problem from an earlier capacity upgrade. No company volunteers the embarrassing details of a 30-hour outage while its customers and shareholders are watching, and I don’t buy that this is the whole story. This is a company selling AI that’s supposed to catch exactly this kind of problem, so where was it? If Microsoft’s future is AI assistants talking directly to each other while email goes the way of the fax machine, “we made a network change” isn’t good enough. An outage that hit users in more than 70 countries, on a platform used by hundreds of millions of people, deserves a full explanation, no matter how embarrassing it is. Now let’s focus on the FAA issue.

The FAA’s account gained detail over two days. On Friday, Duffy said switches and routers “got overloaded with data,” started giving inconsistent readings, and “because of that we shut the system down.” He also said, “We use 1980s little copper lines.” Homeland Security Secretary Markwayne Mullin said new patches and equipment appeared to be “overwhelming the older system.” Some news reports, citing unnamed sources, described a software update and a reboot. That wasn’t a finished official report.

On Saturday, Duffy said a contractor doing routine copper-to-fiber maintenance at a remote FAA site had a router flood other routers with “over 1,000 connection attempts every four to five seconds,” disrupting communications and some radar feeds. He identified that contractor as L3Harris, the FAA’s longtime telecom provider, and said L3Harris “actually owns that network.” Once the work was isolated, systems came back. Officials were still deciding whether it was an installation error or a faulty piece of equipment. FAA Administrator Bryan Bedford said there was “zero evidence of anything nefarious, and zero evidence of anything AI-related,” and that a root-cause review would be shared when it is done. Officials also said there was no connection to Microsoft.

I want to give Secretary Duffy some grace. He’s not an IT expert. He comes across as genuine and well-intentioned, and he’s relying on the experts for this explanation. My questions are aimed at that technical explanation, and at the experts behind it, not at him personally.

Installer error or a bad piece of gear: I don’t find either one acceptable. A system this important shouldn’t let one misconfigured or defective device force a national ground stop. If it was an installer error, the process and the testing failed. If the equipment was faulty, that’s on design and testing too. Who approved this change, and who was watching the network while it happened? Nobody has said. Nobody has put a price on it yet. But nearly 10,000 flights were canceled Friday and thousands more Saturday. It’s not hard to see the cost to airlines alone running into the hundreds of millions.

People also asked why any of the air traffic system would be reachable from the outside. The network that carries controller voice and radar is described as a private communications network, not the open internet, though it runs with contractor help and commercial phone-company connections. The FAA does share flight and weather data with airlines and pilots, on purpose. You can’t run a national air system in a locked room. My question is why a problem at one remote site, during maintenance, can be felt nationwide.

Airlines and other partners who need FAA data could get it over a dedicated private link. Think of a cable in the same data center, running from the FAA’s network to the airline’s. Heavily firewalled and monitored on both ends, with no public internet in the path. That’s how banks and stock exchanges do it.

A router that’s simply overwhelmed usually goes quiet, and its neighbors send traffic around it. It only takes others down when it keeps hammering them. Maybe it’s retrying connections until every neighbor is busy answering. Maybe the box flaps up and down and the whole network keeps recalculating routes. Or it loops traffic until the pipes fill up. There are standard protections for all of that. If those protections were in place, why did one router’s flood spread so far?

Why would a single router at a remote site be able to affect the trusted core of the network? Officials haven’t described how the FAA network is laid out, so I’m not claiming I know the design. Inside an internal network, though, routers often trust each other by default. If the sites aren’t segmented, and nothing limits how fast one device can contact the others, one bad box can flood everything it talks to. A well-built network has those guardrails. Where were they?

Duffy’s number is worth looking at. “More than 1,000 connection attempts every four to five seconds” is only about 200 to 250 new attempts per second. An ordinary home router wouldn’t be overloaded at that level. Enterprise gear is in another league, and the FAA and Microsoft aren’t running a home router from someone’s house. Cisco’s top enterprise firewalls are rated for as many as 360 million connections at once, and more than 5 million new connections a second. Fortinet’s top models are rated for as many as a billion sessions at once, and as many as 9 million new sessions a second. A few hundred attempts a second should be trivial for that class of gear. So maybe the equipment in the path was very old. Maybe the usual protections weren’t in place. Or the official explanation is incomplete.

And if they were connecting new high-capacity gear to outdated equipment, you throttle the new box. That’s standard practice. You cap how many connection attempts and sessions it can open to what the older gear can handle, and you bring it online in stages. Duffy described a flood of connection attempts, more than 1,000 every four to five seconds, not too much data. So the cap that matters is on connection attempts, not on speed. Those are routine settings on enterprise gear. If they weren’t set, that’s a planning and process gap.

Some people will ask why there isn’t a cloud firewall that would have blocked a flood like this. By the official Saturday account, the flood came from inside the FAA’s own network, not from the public internet. Cloud services that soak up outside attacks don’t help much if the problem starts inside the fence. That’s why segmentation between sites, and limits on how fast one device can contact the others, matter so much.

If officials are right that this came from inside during a planned swap, we need to talk about process. The accepted protocol is to make changes like this during low-volume hours. If you can’t do that, you test and perfect the work in a parallel environment before it ever goes live.

Asked why the work was done on a Friday afternoon, Duffy said work at small, remote sites is done during the day because it isn’t expected to affect the wider system, and that “there’ll be a reevaluation of when we do this work.” Bedford said maintenance on the network is logged on paper, so officials had to search paper records to figure out who was working where. The traveling public didn’t need advance notice. The airlines should have had it, so they could watch for anything unusual and report to the FAA any anomalies that might be tied to the upgrade. If a change at one remote site wasn’t supposed to touch the rest of the country, why wasn’t that assumption tested before the work went live in the middle of the flying day?

If Duffy’s account is accurate, how was that much risk allowed into a live national system? Who is overseeing L3Harris’s work and decisions? It should be someone with no financial ties to the contractor, and no incentive that depends on them. Was the vendor chosen because it was the lowest bid? I haven’t found a public record that says this work, or the long-running telecom contract behind it, was awarded solely as a low-bid job. The original network contract was competitively awarded years ago, which isn’t the same thing as choosing whoever was cheapest. Still, the question is worth asking. Astronaut Wally Schirra once said the scariest part of sitting on a rocket was knowing it was built by the lowest bidder. So was this job awarded on price, or on proven skill? Do the people choosing vendors have the technical background to tell which firms have the skills and procedures for work like this?

The most talented engineers I’ve worked with don’t work for a manufacturer. They work across a lot of customer sites, so they see many kinds of equipment and network layouts. They know more than one brand, and they work with the ISPs when something goes wrong or when a new system is being installed, even though the local phone company often owns the last mile. That’s the experience I’d want on a job this important, and in the room when the vendor is chosen.

Secretary Duffy has been consistent about copper and fiber, and I want to be fair about what he said. He’s said the system still uses “1980s little copper lines,” and on Saturday he tied the halt to work switching those lines to fiber. I’m not after him. I just disagree with how that point often gets framed. Degraded copper can be a problem. Copper itself isn’t the problem. Faulty lines can be replaced with fiber and hooked to the older radar and radio gear through converters, which makes the later move to fiber-ready equipment simpler.

The fiber network has to be built eventually, so build it now. Build it alongside the copper, not on top of it. Laying the fiber is the slow, physical part, especially at rural sites. Once it’s in, the routing and security can be set up quickly. Older radar and radio equipment can connect through fiber-to-copper converters, so nothing has to be replaced on day one.

Test the new network end to end, then move equipment over one site at a time, with a way to switch back if anything goes wrong. While the fiber is being built, a satellite link such as Starlink can be up in hours as a backup, and it can stay on afterward as long-term redundancy. Starlink is already advertising gigabit speeds, and the FAA itself has been testing Starlink at remote sites. Swapping a router onto a live network during the day isn’t that approach.

This isn’t the first time a single router problem during a network transition has rippled out like that. In 2009, according to the Transportation Department’s inspector general, a contractor technician misconfigured a router during a similar move toward fiber, and 129 air traffic facilities were affected.

If you rely on O365 or AI assistants, this week was a reminder that those tools sit on the same pipes as your email. When the pipes failed, the AI went down with them. You can’t rebuild the national airspace. You can have a way to reach customers that doesn’t depend on a single email account. Keep copies of the records you’d need if Outlook were gone for a day. And treat unexpected “reset your password” messages during a widely reported outage with caution.

Officials say nothing nefarious happened. If that’s right, why could one malfunctioning router at one remote site force a nationwide ground stop?

Does Occam’s razor apply here? One faulty router at one remote site is a simple story, but a single device bringing down a nationwide system isn’t simple at all. The simpler explanation may be that the network was never segmented to contain a problem like this.

The official story isn’t reassuring, and a missing design safeguard isn’t either. Both deserve a clear public answer in the root-cause report.

And if one rogue router really did cause a national ground stop, I have a follow-up about the briefing itself. Giving airlines a quiet heads-up before planned maintenance makes sense. Describing the failure afterward in so much public detail is a different call. A remote site, a copper-to-fiber swap, a few hundred connection attempts a second, and a flood that other routers couldn’t contain. I can see why they wanted to explain it. The public had just lived through a national disruption and a wave of cyberattack rumors, and a clear explanation builds trust. But you also don’t hand adversaries a map of how fragile a system is, or how little it took to halt it. I haven’t seen a security expert quoted on this specific choice. Officials still have to own that choice. Either those details were safe to share because the weakness is already fixed, or sharing them was a risk.

If you’re a network engineer, I’d like to hear from you. Do you buy the official explanation? Tell me in the comments.