- Test - lists.nanog.org

Re: After Y2K, critical infrastructure
by Sean Donelan 24 Dec '99

24 Dec '99

At 08:49 PM 12/23/99 -0500, Deepak Jain wrote: >Sorry to ruin your sleep. NT is ONLY C2 certified as a standalone >workstation. I.e. NO NETWORKING DRIVERS ENABLED Good grief Charlie Brown, it was a joke. C2 certification means about as much as Y2K certification. There are so many qualifications they are meaningless in any real world situation. It's another checkmark you have to make on the paperwork before winning the bid. I know my laptop is ready because it came with a Y2K-ready sticker on it. After I brought it home, I only needed to download a half-dozen different patches for Y2K, security, and just plain bugs. The issue of being C2 certified only as a standalone workstation is hardly unique to Microsoft NT. As far as I know, ALL the C2 certified operating systems Unix, VMS, VM, etc are only in standalone mode. Others, such as Linux, aren't certified even in standalone mode (well, maybe in the unplugged, encased in concrete, and dropped to the bottom of the ocean mode). If that wasn't a troll, I don't know what is.

2 1

After Y2K, critical infrastructure
by Sean Donelan 24 Dec '99

24 Dec '99

> I don't know how big of a deal is being made about 2.038K on a corporate > management level, but it would seem that the ensuing months would be just > about a perfect time to address this issue. After all, many companies have > teams for the date-field issue right now, and we've gotten pretty good in > the past couple of years at analyzing this problem. It would only make > sense to immediately move on to the 2038 work after Y2K settles down. Let's > just not wait until 2035 to deal with it this time, huh? After Y2K settles down, the most likely next bandwagon will be so-called critical infrastructure or Cyber-assurance. If you look behind the curtain, you will find many of the people involved in the Y2K hype are actually from the the critical infrastructure programs which got side-lined this year due to Y2K. I expect when they return to their "regular" jobs, they will want to keep the extra money they got this year for Y2K as part of their regular budget next year. I'm hoping the "hackers" will party and get drunk over New Year's, and leave the so-called critical infrastructure alone. If you think you filled out a lot of paperwork for Y2K, and you ain't seen anything yet. I for one sleep much better knowing Microsoft NT is certified C2 ready :-)

6 5

Re: Silly season
by Richard Steenbergen 23 Dec '99

23 Dec '99

On Wed, Dec 22, 1999 at 01:55:17PM -0900, Aaron Dewell wrote: > > Or February 6, 2106 at 6:28:14 if your UNIX system keeps an unsigned 32-bit > time_t. I Y2.038k tested my Solaris 7 box, it kept time past 3:14 AM 1/19/38, > but the date command would not set it. Which implies that the kernel itself is > unsigned, while the date command uses a signed number. Wasting an entire 2 billion seconds to check for a -1 error condition instead of the one's complement 0xFFFFFFFF is remarkably stupid imho. But it would break a lot of userland programs to change. As far as I know in BSD it is still a signed long, at least in machine/ansi.h. -- Richard A. Steenbergen <ras(a)above.net> http://users.quadrunner.com/humble PGP Key ID: 0x60AB0AD1 (E5 35 10 1D DE 7D 8C A7 09 1C 80 8B AF B9 77 BB) AboveNet Communications - AboveSecure Network Security Engineer, Vienna VA "A mind is like a parachute, it works best when open." -- Unknown

9 12

Floods Telcos and FCC outage reports
by Sean Donelan 23 Dec '99

23 Dec '99

The New Jersey state utility commission completed its investigation into the Rochelle Park, NJ central office failure due to flooding this fall. Bell Atlantic originally reported the cause as a dam breaking and water entering through doors left open by AT&T. AT&T disputed the report filed with the FCC. The state board investigators found no dam had broken and water had entered by a number of entrances, including cable vaults, basement plumbing fixtures, as well as the rear door. Bell Atlantic's report didn't mention the flood water entering through other entrances. The state board couldn't conclude whether any one source was the cause of the shutdown of the power plant at the central office. The board ordered both Bell Atlantic and AT&T to make improvements, investigate the flood risk at other locations, and report back to the board. Bell Atlantic stands by its report, except they now agree no dam broke. The FCC's investigation is continuing. Source: Bergen County Record http://www.bergen.com/news/flood23199912234.htm

1 0

Re: Internet Y2K Conference Call
by Sean Donelan 23 Dec '99

23 Dec '99

On Thu, 23 December 1999, "Alan Hannan" wrote: > Global Crossing is sponsoring a year-end Y2K Voice Conference Call > for ISPs and NSPs. Does anyone know how many conference calls will be in progress over New Year's. AT&T is providing most of the teleconference bridges for the big Y2K groups (ICC, I0PS, etc). There's something to be said for one of the few telephone companies that has experience with '00 rollovers, being incorporated in 1885. But I've also seen press on MCI Worldcom having many different conference bridges operating over New Year's. And I assume the same is true of other teleconference providers. Will this be the "mother's day" of conference bridges? How many simultaneous conference calls can the current voice bridge infrastructure support?

1 0

Silly season
by Sean Donelan 23 Dec '99

23 Dec '99

As Alan points out, it looks like silly season will be in full swing. Here is a site claiming it will check the top web sites in the world, and if 5% aren't responding at 1 minute before midnight (pick your time zone) a major disaster has happened. http://biz.yahoo.com/prnews/991222/inferno200_1.html As has been pointed out before, many sites plan to shutdown their web sites or disconnect from the Internet over the New Year's weekend. Which I guess is a self-fulling prediction. The Internet is still considered an "extra" and not a necessary connection like the telephone or ATM. I haven't heard anyone suggesting they would turn off their ATMs, even though they are Y2K ready, just to be safe. You can read ATM as representing either acronym.

4 5

Re: Replacement for NPD
by Vern Paxson 22 Dec '99

22 Dec '99

> Does anyone know of a replacement for the Network Probe Daemon software = > that was distributed through the IPMA website? I've been working with colleagues at PSC on a successor called "NIMI". Its goals are: (1) accommodate a wide range of measurement policies; (2) accommodate a wide range of measurement tools; (3) take security seriously; (4) take scaling seriously. There's a paper giving an overview available from: V. Paxson, J. Mahdavi, A. Adams, and M. Mathis, An Architecture for Large-Scale Internet Measurement. IEEE Communications, Vol.36, No.8, pp 48-54, August 1998. ftp://ftp.ee.lbl.gov/papers/nimi-ieee-comm98.ps.gz The software is alpha level and under active development. The current infrastructure is 28 hosts, which we're in the process of trying to grow to double that size within the next few months. Volunteers who can host a box are highly welcomed - drop me a line at vern(a)ee.lbl.gov if interested. Vern

1 0

RE: [announce-all] NAC Maintenance this weekend (fwd)
by Sean Donelan 22 Dec '99

22 Dec '99

On Fri, 10 December 1999, Alex Rubenstein wrote: > Something interesting for all you operational folks... got this from a > customer. I've seen some amazing disasters, but I think your customer passed along an urban legend. 38 people taken to a hospital, 8 cars destroyed, coverage by television in five states; and I can't find any published reports in the newswire databases. Unless my math is very wrong, I don't understand how a 300 amp surge could damage that much stuff.

9 9

Replacement for NPD
by Sindhu Xirasagar 22 Dec '99

22 Dec '99

Does anyone know of a replacement for the Network Probe Daemon software that was distributed through the IPMA website? Thanks Sindhu Xirasagar

1 0

Re: Need help from UUNet's routing specialist!
by Brian Dickson 22 Dec '99

22 Dec '99

> We (as8470) are Teleglobe customer. And we experience terrible > delays on Teleglobe to UUNet interconnect points. Teleglobe's customer > support engineers insist, that the problem caused by UUNet's routes > prioritization. > But I belive that this assymetric routing initiated by Teleglobe, not > UUNet. We apologise for this customer-provider issue propogating to NANOG. For the information of interested folks, and to clear up any incorrect perceptions, I have copied the list on my reply. Currently, private interconnects from Teleglobe to UUnet are multiple DS-3's, in multiple cities. However, as a result of incremental load, the management and load-balancing of these is tenuous, and event-sensitive. Specifically, internal events on either network, can cause congestion as a new closest-exit path is chosen. We are currently waiting for delivery of several OC-12 circuits to replace the plethora of DS-3's. Unfortunately, provisioning OC-12's is not something many LEC's can do, let alone in a timely manner. When these are in place, the problems should go away for the forseeable future. Provisioning of additional OC-12's should be feasible in the timelines anticipated for further growth of traffic. Until then, there is some traffic engineering being done via MEDs, for the purposes of avoiding congestion. Some of this is steady-state (since certain peerin glocations are currently under-provisioned), and some is in response to congestion events. In the absence of inter-provider MPLS, to handle such things inter-provider and intra-provider outages in a semi-optimal fashion, and in the absense of excess interconnect bandwidth (to handle outage-based peak loads), there will be instances where asymmetry is required to minimize network impact of such outages. The selection of routes for application of MEDs is done on a random basis, for scalability reasons. The choice of exit modulo these MEDs is still closest exit, and will vary based on the geographic location of the end system. (The MEDs are used to de-prefer a couple of peering locations; all others operate naturally, ie closest-exit.) I hope this explanation is clear enough; if anyone has questions about this or other Teleglobe issues, please feel free to contact me directly. -- Brian Dickson, Email: briand(a)teleglobe.net Director, Backbone Engineering Tel : +1 703 755 2056 Teleglobe Communications Corp., Fax : +1 703 755 2648 Rm 3214, 11480 Commerce Park Drive, Cell : +1 703 851 9053 Reston, Virginia, USA, 20191 http://www.teleglobe.com

2 3