How not to build and manage a transcontinental data network
I am reading an article in The Register about a major Internet outage that occurred last December, when a handful of rogue packets managed to clog up a backbone network for more than a day and a half, blocking even VoIP 911 calls.
There are two rather frightening aspects of this fiasco. Both rather horrifying, as a matter of fact.
First, that in this day and age, in late 2018, a backbone service provider can still be brought to its knees by something as simple as a malformed packet. What on Earth are you doing, people? Have you heard of penetration testing? Fault tree analysis? Auditing your equipment and system software? Or have these essential steps been dropped just so that you can report some cost savings to your shareholders?
But it really is the second point that I find particularly upsetting. To quote, “the nodes along the fiber network were so flooded, they could not be reached by their administrators”.
Say what? Are you telling me that you had no alternate means to access your nodes? Like, you know, something as crude and simple as a dial-up port with a command-line based management interface? I mean, this is something even my little home office network used to have, and when I dropped it last year, reacting to rising landline costs and the fact that I no longer used that data/Fax phone line at all, I did so because I have dual network connections. To learn that a major backbone provider doesn’t have the kind of redundancy that I take for granted for my own little network is disconcerting, to say the least.
I suppose I should stop rambling now, though. Truth to tell, I am ignorant as to how CenturyLink’s actual network is configured, and I certainly never managed a fiber optic backbone network. I am simply reacting to the main points of The Register‘s article even though I cannot independently confirm its veracity. In my defense, The Register‘s articles tend to be well written and accurate. Even so, criticizing from a position of ignorance is never a smart thing to do.
Nonetheless, if The Register is correct, this really is not how a transcontinental data network should be configured and managed. This also seems to be the FCC’s conclusion.