- NANOG - lists.nanog.org

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

Internet Y2K and Europe, South America, and Middle East
by Sean Donelan 22 Dec '99

22 Dec '99

Is anyone aware of any regional joint ISP monitoring and communication efforts over New Year's for European, South American and Middle East ISPs? Or are most ISPs in those areas relying on a US-based backbone provider to keep them informed? North America, Asia, Australia/New Zealand seem to have a plethora of groups.

4 3

All the chemical factories are OK, but their web page will be down..
by Alan Clegg 22 Dec '99

22 Dec '99

Subject line says it all. I got this today from the Chemical Safety Board.. Silly season is definitely upon us. Have a happy and safe new year! AlanC ------- Forwarded Message From: csb_automailer(a)csb.gov To: abc-chem(a)firehouse.net Subject: CHEMICAL SAFETY BOARD WEB SITE TO UNDERGO PRECAUTIONARY 24-HOUR Y2K SHUT DOWN; ALSO, YEAR 2000 CHEMICAL SAFETY CARD AVAILABLE Date: Tue, 21 Dec 1999 17:54:45 -0500 The following message is from the United States Chemical Safety and Hazard Investigation Board (CSB), Washington D.C. As a precaution and to protect critical information systems, the CSB web site will be shut down, temporarily, for approximately 24 hours beginning at 8 a.m. Eastern Standard Time (U.S.A.) on December 31st. This is a precautionary Y2K-related shutdown. The web site is scheduled to return to operation on the Internet at Saturday morning, Jan. 1, 2000. Chemsafety.gov users are advised to download information from the site prior to the shutdown. We regret this inconvenience. On a positive Year 2000 note, the CSB advises that copies of its "fully Y2K-compliant" chemical safety calendar wallet card are available for distribution. For details visit http://www.chemsafety.gov/about/cards.htm . This message was transmitted at 5:31 PM Eastern Time (U.S.A.) on December 21, 1999. ________________________________________________________ Visit us on the World Wide Web at http://www.chemsafety.gov - -- This mailing came from the csbnews list maintained by the Office of External Relations, U.S. Chemical Safety and Hazard Investigation Board, Washington, D.C. - -- To unsubscribe to this list please send a message from the subscribed email account to csbinfo(a)csb.gov with the subject line blank and the words "unsubscribe csbnews" (no quotation marks) in the body of the message. Please note: if the "from" address at the top of this message is from an address other than csb_automailer(a)csb.gov please contact the sender. ------- End of Forwarded Message

1 0

NANOG 18
by Pam Ciesla 21 Dec '99

21 Dec '99

Merit Network will be closed for the holidays starting Friday, 12/24 thru January 3rd :*). NANOG-support will be checking mail, but not regularly. While you can still register durning this time the registration page will not be updated until our return. The registration page is current at this time. Check the NANOG webpage for agenda topics http://www.nanog.org. Happy holidays and hope to see you in the next century. Pam Pam Ciesla Events Coordinator Merit Network,Inc. 734-936-0172 - phone 4251 Plymouth Road 734-647-3185 - fax Bldg.I, Suite 2000 pam(a)merit.edu Ann Arbor, MI 48105

1 0

Re: Internet Y2K and Europe, South America, and Middle East
by Sean Donelan 21 Dec '99

21 Dec '99

On Mon, 20 December 1999, "Alex P. Rudnev" wrote: > What do you want to monitor? real time problems are not supposed to appear, > billing and accounting problems are not monitored at all. Why so many people > aware unexisting problems (some computer refuse to work due to Y2K - let me > smile for a 10 minutes hearing this - and so few people really understand Y2K > problems (billing systems, accounting systems, daily-log-analysing systems, and > so on). But this means that real Y2K problems appear approximateky 3 - 10 of > january, not at 12:00 31-December. > > And this means all this ISP monitoring is useless, you'll monitor not more than > people's paranoia about Y2K and will not monitor any real problems. I don't actually think the monitoring will pick up any Y2K problems. I'm interested in the communications and monitoring to pickup all the other problems, and trying to head off rumors when something inevitably doesn't work. For example, tonight if you go to the US government's Y2K web site it's not working. It appears to be a server problem with http://www.y2k.gov/ and not a network problem. You get an error "The request did not specify a valid virtual host." I don't think its Y2K problem, and if we could contact the operators, we might find out what's wrong. If something like that happened in the early morning of January 1, without good information, rumors will spread.

2 1

Re: Portable IP space, isolated networks, BGP, etc... (fwd)
by Tim Wolfe 21 Dec '99

21 Dec '99

I'm forwarding this off inet-access because there is a lot more BGP clue here. Anyone have any comments on the particular situation below, and/or regarding announcing different routes at multiple locations to multiple providers with single/many different ASNs? Thanks, -- Tim -------------------------------------------------- * Timothy M. Wolfe, Chief Network Engineer * * ClipperNet Corporation / It's a wireless world * * tim(a)clipper.net 800.338.2629 x 402 * * Sufficient for today = Inadequate for tomorrow * -------------------------------------------------- ---------- Forwarded message ---------- Date: Thu, 9 Dec 1999 12:58:46 -0800 (PST) From: Tim Wolfe <tim(a)clipper.net> Reply-To: list(a)inet-access.net To: list(a)inet-access.net Subject: Re: Portable IP space, isolated networks, BGP, etc... On Thu, 9 Dec 1999, James Fischer wrote: > From: "Troy Settle" <st(a)i-plus.net> > Subject: Portable IP space, isolated networks, BGP, etc... > > > I've been thrown into a situation where I've got 8 isolated networks > > connected to a variety of providers. Eventually, most of these will be > > connected with our own backbone. I need to find a way to make the > > transition as seemless as possible. > > > > First, it's my understanding that I can use a single ASN for the BGP > peering > > at each of these networks. Am I mistaken? > > Yes, this is a Big Mistake(tm). One would need a unique ASN for each site, > but they are only numbers, and the cost is like $500 each. Think about > the implications of two different sites, fed by the same provider, both > using the same ASN. Not a pretty picture. BGP hell. Could you please clarify what exactly the problem with doing this is? Many huge providers have multiple peering points that exchange routes using the same ASN for their peering routers don't they? -- Tim -------------------------------------------------- * Timothy M. Wolfe, Chief Network Engineer * * ClipperNet Corporation / It's a wireless world * * tim(a)clipper.net 800.338.2629 x 402 * * Sufficient for today = Inadequate for tomorrow * -------------------------------------------------- - Send 'unsubscribe' in the body to 'list-request(a)inet-access.net' to leave. Eat sushi frequently. inet(a)inet-access.net is the human contact address.

7 9

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

21 Dec '99

> For the record, is anyone seeing even vaguely decent connectivity via > teleglobe? It seems that 50% of the times customers complain they have > a poor connection to our network, it turns out that they're going via > teleglobe at some point! Um, maybe it has to do with your connection to the outside world? (BTW, are you refering to pre.org, specifically, or some other network?) Or at least connectivity between your upstream provider and either you or us... Currently we hear your routes only from insnet, via LINX and DE-CIX. (LINX does tend to have problems from time to time.) The proportion of complaints coming from customers of ours is most likely explained by the size of our customer base; a recent check on percentage of announced IPv4 space, shows us and our customers comprising about 20% of reachable addresses (ie, pro-rated by prefix size). > Are they running a 2400baud modem with a flaky fuse as their main > connection or something? Try multiple OC-12 (cross-section), with buildout to OC-48 (on dark fibre) underway, in North America and Europe, and deployment of significant numbers of nodes worldwide at significant connection speeds, over owned wet-fibre and dark-fibre capacity. We do have lots of *customers* whose links to us are congested; if anyone can find a way to force customers to upgrade, we'd dearly like to know. ;-) (These congested links have in-addr entries from our namespace, and this frequently leads to the incorrect conclusion that it is our network that has problems. In case anyone is curious, our naming convention for point to point links, is if-* for the Teleglobe end, and ix-* for the customer side, where the * is the numbering of Cisco interfaces converted from non-alpha to hyphens, in the zone named by the router designation. Example: if-12-1.bb3.NewYork.Teleglobe.net, would be the Teleglobe side, while ix-0-1-0.bb6.NewYork.Teleglobe.net would be the far-end of a link.) -- 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 1