alt Hacker NewsA buddy was asking me if this story "holds water" earlier today (because I'm more into networking). I eventually decided it was plausible, but only through at least one, and probably multiple "rookie mistakes".
As described it was in the course of switching out copper TDM lines with fiber. On it's face that could be straightforward, but it's easy to imagine the router(s) terminating these lines didn't support the required line cards, so router upgrade(s) were required. So theoretically straightforward could have become more involved.
However, when doing far less critical updates, it's common to set up a test environment, do a dry run of the work, test the roll-back, test the monitoring and alerting, that sort of thing. Doesn't guarantee no outages, and I'm playing armchair QB here, but it seems like a botched job.
It's also telling the Transportation Secretary said things like "we aren't sure they if they aren't doing a great work for us". He also said "this is something businesses have been doing for decades and the FAA is the last to do it"; you'd assume that this is a process that someone (maybe not those doing the work) have developed deep experience with.
I'm not familiar with this L3HARRIS, I gather they are a defense contractor with billion dollar revenue.
Lots of things in this definitely raised my eyebrows.
Replies
The irony here is that this is basically a mirror of what happened at AOL on August 7th, 1996. See: https://www.theregister.com/on-prem/2018/04/16/i-crashed-aol...
I was the Sr. Internet Mail Administrator at AOL at the time, and this article was what The Register wrote based on what I had submitted to them. They made a few changes. I know they were trying to protect my identity, but I think they also wanted to make it a better story.
For us, everything started with a planned downtime to upgrade the main core router for the entire service. We had the best network engineers in the business, but even they can make a mistake. And they did. And then there was a whole domino effect of events that followed.
I don't have the full story because it happened in another business unit, but one of the worst outages I ever worked the rumour was it was caused by someone doing prep work for a later cutover to new hardware. Whatever they were doing to prep for the upcoming cutover, the router rebooted. They didn't know it rebooted, so they did the same thing to the secondary and tertiary a few minutes later. Also happened to be on a Friday.
So sometimes it's easy to rehearse all the critical stuff, and get a bit complacent with the stuff that is just expected to work, plugging something in that's not configured and getting it ready for the big migration. And it's hard to get a 100% perfect replica in a lab. So I think odds are you're right, but I think there is also a longer tail of possibilities as well. And in my experience, there is always tension between chasing the 9's of availability, and getting some "safe" work done when convenient.
The explanation could hold water, but that only demonstrates plausibility, not truth.
Seems that a router that previously terminated copper interfaces was switched to terminate fiber. That alone doesn't really tell us much without knowing whether this is really all that happened or if it's shorthand for a bigger move at a higher level in the protocol stack. For example you might "just" have changed copper Cat6 ports to fiber/SFP but still be doing GigEthernet and I rather doubt that a move that simple could make a router misbehave.
Moving up the stack this get more interesting. For example they might have moved from a copper star topology to a fiber ring, and rings need care or else chaos ensues. Similarly Ethernet gets pissy if there are loops but the spanning tree protocols need very careful usage. I assume since the word router was used that Ethernet was fine and we are in layer 3. An interface switch could have triggered recalculation or reannouncement of routes, for example by erroneously configured routing protocols. eg the Arkansas router announces it is the best hop for traffic to reach Chicago, gets swamped with traffic from Dallas, NY, etc, and falls over. (Yes, the tools provide guardrails. Who knows if they were enabled?)
However, and esp because Duffy is pointing at L3Harris, I suspect they installed (or perhaps removed) a Juniper TDM to Ethernet converter module (eg DS3 SmartSFP from that vendor) and something went bad. These modules are supposed to encap TDM into Ethernet but they don't (iirc) have any semantic awareness of a telephone call, so if they were to be hit by, say, a storm of TDM circuit messages (call setups, say) they might just pass them on, not rate limit them like a true telco packet switch would.
It might be pure coincidence that an AI system was hooked up to the FAA system the week before.
Bottom line: could be bad luck, could be basic screw up, we won't know for years.
> However, when doing far less critical updates, it's common to set up a test environment, do a dry run of the work, test the roll-back, test the monitoring and alerting, that sort of thing. Doesn't guarantee no outages, and I'm playing armchair QB here, but it seems like a botched job.
Quite possible. The DOGE antics from the early days of the administration applied an indiscriminate flame thrower to govt agencies gutting them without thought or planning. It's not surprising we are seeing critical govt systems start to fail. What's surprising is how long it took for the true extent of the damage to be revealed.
Hopefully, the midterm results will mean greater scrutiny and transparency into DOGE's antics.
Plausible I guess. Essentially a denial-of-service attack from a new device connected to the network. The article doesn't give more details but a device in the network can ... send traffic into the network ... and a device connected to a high speed link in a network with many old legacy/slow devices ... could cause problems.
The router was apparently a Juniper router. L3Harris I guess buys them and install/configures/whatnot. They don't make them.
I’m not clear what scenario you are trying to describe and if by into networking you are a principal level IC or home hobbyist
Did this router also jam radio and and radar?
or was that a coincidence?
As another with a network engineering background from the customer side as lead architect for a 1+ million port healthcare network, principal solution architect for a VAR, and now wired PLM for a major networking vendor (not the one in the article), I can't say the details given really say enough to come to any conclusion or doubts whatsoever.
I've seen simple copper->fiber migrations like this take down a large network and I've seen them be blamed when they turned out to be unrelated. I could come up with a scenario for most any view anyone wanted to speculate on because the details are so light and the possibilities are so many, but I won't because I don't have enough details to say which it might have been without just guessing myself. If they say they identified a broadcasting knob they disabled on the other ~60 routers already in service then that's what I'd leave such a conversation at for now - but I wouldn't necessarily trust that or what it really means without more info.
In the thread the other day I saw people blaming anything from AI to attacks to Starlink but few willing to admit they just needed more information to have any certainty about what to think beyond "it sucks this is down and I wonder what the reason will be". The only thing I'd raise my eyebrows at at this point would be if we don't get further details in reasonable time.