North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Fatty Pipes with Y2K problem - OT humor
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 <[email protected]> > To: [email protected], [email protected] > Subject: Re: Fatty Pipes with Y2K problem - OT humor > > > [email protected] (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 :-) > > > >http://www.cbs2.com/news/stories/news-990617-081237.html > > 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)
|