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 :slight_smile: The staff is currently
off-line recovering! Seriously.

Sean, one for your book :slight_smile:


I smell a problem :slight_smile: 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.

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.