Fatty Pipes with Y2K problem - OT humor
Alex P. Rudnev
alex at Relcom.EU.net
Fri Jun 18 10:38:42 UTC 1999
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 at SDG.DRA.COM>
> To: rjoffe at centergate.com, nanog at merit.edu
> Subject: Re: Fatty Pipes with Y2K problem - OT humor
> rjoffe at 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)
More information about the NANOG