- Test - lists.nanog.org

mae-west route servers are both down hard
by Paul A Vixie 24 May '96

24 May '96

This... >From: noc(a)noc.ns.itd.umich.edu >Date: Thursday, May 23, 1996 4:26 PM >Subject: rs2.mae-west down indefinately > >The route server rs2.mae-west.ra.net has crashed with the same symptoms as >rs1.mae-west. Both servers will be down indefinately. Further >information will be passed on as it becomes available. We apologize for >any inconvenience this may cause. > >------------------------------------------------------------------------ > UMNet MichNet CICNet >Merit RA >------------------------------------------------------------------------ >Network Systems Consultant Network Operations Center >trouble(a)noc.ns.itd.umich.edu U of M Information Technology Division ...is not just an inconvenience. On the strength of Merit's publicity, quite a few peerships have been done through route servers, and to have both route servers down at the same time is a massive disruption to many of the folks who connect at MAE-W. I have two heavily overconfigured Alpha machines loaded in my van, with Stephen Stuart's port of RSd all ready for someone from Merit or ISI to load up their configuration tables. I've got a driver and a technician. I need someone from Merit or ISI to call me and arrange physical access as well as scheduling the download of the initial configuration files and turnover of the root account and other "system keys". The use of the machines, and the time to deliver and install them, have all been donated by people who are suffering due to MAE-West's ills. It is most extraordinary that we have let things suffer this long, and if the current plan is to wait until after the three day weekend, I consider that flatly unacceptable. E-mail me (paul(a)vix.com) or call me (1 415 747 0204) to arrange details.

2 1

NANOG Registration
by Pam Ciesla 24 May '96

24 May '96

Is closed for the May meeting. Pam

1 0

Automated processing of InterNIC changes?
by Steve Rubin 24 May '96

24 May '96

I thought all of you would find this amusing. Network Solutions, Inc. (INTERNIC-DOM) 505 Huntmar Park Drive Herndon, VA 22070 Domain Name: INTERNIC.NET Administrative Contact: Network Solutions, Inc. (HOSTMASTER) hostmaster(a)FUTURE-FOCUS.COM 619-452-4365 (FAX) (703) 742-4811 ^^^^^^^^^^^^^^^^ Neat.. -- Steven Eric Rubin <ser(a)aimnet.net> Aimnet Corporation Senior Network Engineer 2350 Mission College Blvd Phone: (408) 567-3820 x511 Santa Clara, CA 95054 Fax: (408) 567-3990 http://www.aimnet.com

3 2

Re: Worldly Thoughts - Regionalizing Peering
by Alec H. Peterson 24 May '96

24 May '96

Dave Siegel writes: > >Since these are designed to be regional exchanges, one would presume that >transit is still available elsewhere. > >Even at the large carrier level, I should think that the priority NAPs, >as well as the private interconnects, would contain complete information >on the other networks to back up any failure to route at a regional exchange. Er, um, well yes, but ideally if you get peering from all the big boys, you wouldn't need to purchase transit from someone. I think the idea of only exchanging local routes at any given regional exchange is not a bad idea, but I don't see how it would really end up working properly in a fluctuating environment. Alec -- +------------------------------------+--------------------------------------+ |Alec Peterson - chuckie(a)panix.com | Panix Public Access Internet and UNIX| |Network Administrator | New York City, NY | +------------------------------------+--------------------------------------+

2 1

Re: Worldly Thoughts - Regionalizing Peering
by Alan Hannan 24 May '96

24 May '96

Toodles, ] > 2. Even better, accept my routes into your network but only use them ] > within region... I know this isn't nearly as easy as #1, so I don't ] > expect it to happen, but it would be a significant performance benefit ] > for the local traffic your customers in the region are generating which ] > is headed towards me. Once outside the region, of course, you ignore the ] > direct routes from me and just give them to my transit provider. ] ] It becomes very entertaining to scale the above model (although it does ] provide an excuse to use nearly every BGP routing feature in IOS. :-) The model scales well, imho. Regionalize your network into pieces. Apply each of the pieces into 1 or more proximities to a NAP|MAE. Apply set filter lists onto peering sessions for appropriate peers. Let me expound. I run Internet-Net.net. I have a POP in every city w/ over 10,000 people. I aggregate M number of POPs to N number of Hubs. (use acronym NXP to mean network exchange point.....) I am connected to P number of NXPs. I go through each of my N Hubs, and identify if he is or is not in Pn's region. If he is, I add NXPn's peers to the allow list. If he's not, I don't. Won't this work? Is it "too confusing"? Let's say I have 1 HUB in Arizona. I decide that they are in the region of MAE-W, PACBELL, and the NXP in Phoenix. So, I accept routes from everyone at any of those NXPs, and I give my routes for this HUB only, to everyone at the NXP. I don't tell them about my route to customers homed to San Mateo, because I don't want to carry their traffic there, only stuff that's topolgically 'close' to them, as I feel that benefit to my customers is worth the peering relationship. I have a HUB in San Mateo. I decide that he's in the region of MAE-W and PACBELL and MAE-LA, but not the NXP in Phoenix. So, I accept routes from the folks at those NXPs, and only give the routes for my folks homed to my San Mateo HUB. My San Mateo Customers get to the folks at the NXP, and the other providers customers get to my customers CLOSE to the NXP in San Mateo. However, I don't have to backhaul them to another larger aggragation point, or to another NXP at which I hand off packets to their transit provider. Benefit: I gain low latency transit to most everyone. Drawback: It is technically challenging to create an automate system to regionalize and create appropriate filter lists. ---- Perhaps this is a problem that's only challenging to the smaller folks, those of us w/out the nationwide DS3|OC3 networks. However, I do feel it's a worthy problem, and one that would benefit the NANOG community were it intelligently solved. -a

5 4

Re: RFC 1597
by Craig Labovitz 23 May '96

23 May '96

Might be a good time to mention that there is a web page that tracks all of the bogus routing information sent each day. See http://www.ra.net/statistics and select "routing problems." There is also now a mailing list where you can receive a daily list of all the bogus routes (RFC-1918, IANA reserved nets, host announcements, etc.) sent the previous day. To subscribe, send mail to routing-problems-request(a)ra.net. - Craig ------- Forwarded Message Return-Path: nanog-owner(a)merit.edu Received: from merit.edu (merit.edu [35.1.1.42]) by home.merit.edu (8.7.5/merit-2.0) with ESMTP id DAA07017; Thu, 23 May 1996 03:41:14 -0400 (EDT) Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id DAA09256 for nanog-outgoing; Thu, 23 May 1996 03:39:20 -0400 (EDT) Received: from chops.icp.net (chops.icp.net [199.0.55.71]) by merit.edu (8.7.5/merit-2.0) with ESMTP id DAA09251 for <nanog(a)merit.edu>; Thu, 23 May 1996 03:39:17 -0400 (EDT) Received: by chops.icp.net id <20677>; Thu, 23 May 1996 03:39:05 +0100 From: Sean Doran <smd(a)icp.net> To: djs(a)secure.net, nanog(a)merit.edu Subject: Re: RFC 1597 Cc: dfk(a)ripe.net, hank(a)sprint.net, insc(a)sprintlink.net, rv(a)INFORMATIK.UNI-DORTMUND.DE Message-Id: <96May23.033905+0100_edt.20677+12(a)chops.icp.net> Date: Thu, 23 May 1996 03:38:58 +0100 Sender: owner-nanog(a)merit.edu Precedence: bulk | I need a few class Cs. Hope nobody will mind if I take | 192.168.0.0/20. ;) Knock yourself out. :-) | *> 192.168.100.0/22 144.228.71.5 0 1239 1794 ? This appears to be a truly ancient (before 17 Jan 1996) typo or thinko or somesuch, and has been corrected. Sean. ------- End of Forwarded Message -- Craig Labovitz labovit(a)merit.edu Merit Network, Inc. (313) 764-0252 (office) 4251 Plymouth Road, Suite C. (313) 747-3745 (fax) Ann Arbor, MI 48105-2785

1 0

NAP Def.
by Dahc＠corenet.net 23 May '96

23 May '96

Is there an NFS doc somewhere that lists the requirements that must be met in order to call your self a NAP? If so what are the requirements. Chad

2 1

RFC 1597
by David J. Sharp 23 May '96

23 May '96

I need a few class Cs. Hope nobody will mind if I take 192.168.0.0/20. ;) *> 192.168.22.0 144.228.71.5 0 1239 1800 1804 1128 1955 3337 ? *> 192.168.100.0/22 144.228.71.5 0 1239 1794 ? *> 192.168.216.0 144.228.71.5 0 1239 1800 1755 1273 ? Shame on you 3337, 1794 and 1273. - david

3 2

Re: RFC 1597
by Sean Doran 23 May '96

23 May '96

| I need a few class Cs. Hope nobody will mind if I take | 192.168.0.0/20. ;) Knock yourself out. :-) | *> 192.168.100.0/22 144.228.71.5 0 1239 1794 ? This appears to be a truly ancient (before 17 Jan 1996) typo or thinko or somesuch, and has been corrected. Sean.

1 0

NetSCARF Project/USEC Code Release July 1
by William B. Norton 22 May '96

22 May '96

Hi all - In April, Merit received funding from the Resource Allocation Committee (RAC) to develop and evolve a prototype ISP Statistics Collection And Reporting Facility (NetSCARF) package. The basic idea is to make it dead easy for ISPs to collect and report data about their part of the Internet. The end result will hopefully be widely-available Internet performance data much as Merit produced during the operation of the NSFNET. The NetSCARF code is easy to install, runs automatically, and consists of four separate programs. Every fifteen minutes the collections program queries all network nodes in parallel. (This is especially important for large networks where the serial skew can affect the ability to correlate data.) Nightly these raw statistics get pre-processed (cooked). The cooked data is delivered to CGI scripts using what we think is the first Public Domain implementation of the OpStats (rfc1856) client/server model. Finally, ISP performance reports (based on the cooked data) are displayed on the web via the CGI scripts. We plan on making the source and pre-compiled executables available for each of these. SNMP Version 1 is used to query the network nodes, although the code includes support for the User Security (USEC) model for SNMPv2. ( The Routing Arbiter project will use the DES Encrytion facility, but this capability will be disabled for the public release due to export restrictions. ) During the operation of the NSFNET we found there were really only three graphs that were widely seen as useful. The first cut of the code includes only these three most popular graphs: System UpTime, Interface Uptime, and the McD's chart (total packets served) by the network. Alpha Testers? -------------- The first release of the code will be made around July 1, and we currently have a version of the code that runs on SunOS 4.1.4, BSDi, and AIX systems. We are looking for a couple of ISPs to try the code out and provide early feedback. If you operate one of these Unix varieties and have the time to work with us, please e-mail your name, daytime phone #, operating environment, and a description of your network (size, types of routers, etc.) to netscarf-team(a)merit.edu with the subject line "ALPHA TESTER". The code doesn't require much - just disk space, a network attachment, and a few CPU cycles periodically. Please see me at the NANOG if you have any questions or suggestions. More information about the NetSCARF project (including the text of the proposal) is available on-line: http://home.merit.edu/~wbn/RAC/play.html Bill ---------------------------------------------------------------------------- ----- William Norton <wbn(a)merit.edu> (313) 936-2656

1 0