Re: Fatty Pipes with Y2K problem - OT humor
rjoffe@centergate.COM (Rodney Joffe) writes:
We have had a significant pipe problem at our Sherman Oaks facility in Los Angeles as a result of a Y2K test failure :-) The staff is currently off-line recovering! Seriously.
Sean, one for your book :-)
I smell a problem :-) But hardly the first. The best one I've heard so far was the entire country of Fiji went off-line a few weeks ago when the telco was conducting their Y2K test. Even if you think everything will work correctly, having a contigency plan is still a good idea. BTW, President Clinton signed an executive order setting up the US Y2K coordination center I spoke about at NANOG this week. But guess what, the vendor of the conference bridge the NCS uses doesn't have a Y2K readiness statement on their web page. And speaking of that, to bring this on topic: NOC communications, and communicating during contigency operations. During the recent virus/worm scare an old problem has re-appeared. For a variety of reasons some organizations feel the best response to these virus/worms is to pull up the drawbridges and shut-off their network connections each time a new one makes the rounds. This also happened during the "Morris" Worm ten years ago, and one of the reasons why BBN was tasked with creating the Network Manager's Phonebook. I can't ask you to go against your corporate security people. But consider planning how to keep a NOC contact up and running when you feel you must disconnect the rest of your corporate or agency network. If you pull the plug on your main (only?) mail server, how do you redirect your NOC mail? The government backbone networks seemed to do this more than commercial networks, but the principle applies to both. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation
Btw, the Y2K annoying which does have place make more troubles than Y2K problem itself. If you think a little you understand Y2K problem can cause input/output errors during different requests, billung, accounting problems, etc etc, but hardly can influence real-time systems. No one router or server over the world know really about the year - it know _xxxxxxx seconds since yyyyyyy date_ time, and next second always is xxxxxx+1_. The problem exists, of course, because a lot of people should enter _the date of some event_ into this real-time systems (just before or after Y2K), and bad software can cause a mistaken data encoding/decoding, but when someone write in the magazine _the chip in your car can stop the engine just at 00:00:00 1 January_, written by some paper dirter, it have a little with the reality. This is just as with the hackers - anty-hackers systems and filters cause not less problems then the hackers themself. On Thu, 17 Jun 1999, Sean Donelan wrote:
Date: Thu, 17 Jun 1999 21:15:33 -0500 From: Sean Donelan <SEAN@SDG.DRA.COM> To: rjoffe@centergate.com, nanog@merit.edu Subject: Re: Fatty Pipes with Y2K problem - OT humor
rjoffe@centergate.COM (Rodney Joffe) writes:
We have had a significant pipe problem at our Sherman Oaks facility in Los Angeles as a result of a Y2K test failure :-) The staff is currently off-line recovering! Seriously.
Sean, one for your book :-)
I smell a problem :-) But hardly the first. The best one I've heard so far was the entire country of Fiji went off-line a few weeks ago when the telco was conducting their Y2K test.
Even if you think everything will work correctly, having a contigency plan is still a good idea. BTW, President Clinton signed an executive order setting up the US Y2K coordination center I spoke about at NANOG this week. But guess what, the vendor of the conference bridge the NCS uses doesn't have a Y2K readiness statement on their web page.
And speaking of that, to bring this on topic: NOC communications, and communicating during contigency operations.
During the recent virus/worm scare an old problem has re-appeared. For a variety of reasons some organizations feel the best response to these virus/worms is to pull up the drawbridges and shut-off their network connections each time a new one makes the rounds. This also happened during the "Morris" Worm ten years ago, and one of the reasons why BBN was tasked with creating the Network Manager's Phonebook.
I can't ask you to go against your corporate security people. But consider planning how to keep a NOC contact up and running when you feel you must disconnect the rest of your corporate or agency network. If you pull the plug on your main (only?) mail server, how do you redirect your NOC mail? The government backbone networks seemed to do this more than commercial networks, but the principle applies to both. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
participants (2)
-
Alex P. Rudnev -
Sean Donelan