- Test - lists.nanog.org

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

Re: Unregistered addresses [Re: Map Frame Relay Question]
by Erik-Jan Bos 21 May '96

21 May '96

Per, > This is the second time in just a couple of weeks I've seen mail from > people apparently believing that unregistered addresses are supposed > to work in the Net. Has the Net come so far that ignorance and > cluelessness is so widespread among people trying to manage boxes > that they think officially allocated addresses is a refinement? > A kind of dotting of i's and crossing of t's, not really necessary? > Like cars drive just fine without licence plates? > > Heaven knows there's enough people who think the whole thing works by > some strange magic, but the current apparent trend is verging on the > absurd. Don't you (only sometimes) think that the number of weekend drivers on the Internet-road is increasing, just like the number of prefixen in the default free routers of the Internet (hint for weekend drivers: these are the routers that have a clue)? BTW, see ftp://ftp.nic.surfnet.nl/surfnet/net-management/ip/nets.ps for the latest update on the number of prefixen. :-). __ Erik-Jan.

1 0

Re: PPP over SONET
by Peter Lothberg 21 May '96

21 May '96

> On Tue, 21 May 1996, Peter Lothberg wrote: > > > Or do you have many small OC-3 routers? > ^^^^^^^^^^^^^^^^^^ > Now, that's a thought! ;-) > > Michael Dillon Voice: +1-604-546-8022 > Memra Software Inc. Fax: +1-604-546-3049 > http://www.memra.com E-mail: michael(a)memra.com > > Exponential growth, yes, well where do you think circiuts like this will be before the end of the year? Hssi2/0 is up, line protocol is up Hardware is cxBus HSSI Description: PL00190596 ICM-PEN-2<-->ICM-UK-1 Internet address is 198.67.131.25/29 MTU 4470 bytes, BW 45045 Kbit, DLY 200 usec, rely 255/255, load 248/255 Encapsulation HDLC, loopback not set, keepalive set (10 sec) Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 5d02h Output queue 0/40, 24883016 drops; input queue 0/75, 175 drops, 109723 flushes 5 minute input rate 21531000 bits/sec, 15203 packets/sec 5 minute output rate 43820000 bits/sec, 13082 packets/sec -Peter

1 0

Unregistered addresses [Re: Map Frame Relay Question]
by Per Gregers Bilse 21 May '96

21 May '96

This is the second time in just a couple of weeks I've seen mail from people apparently believing that unregistered addresses are supposed to work in the Net. Has the Net come so far that ignorance and cluelessness is so widespread among people trying to manage boxes that they think officially allocated addresses is a refinement? A kind of dotting of i's and crossing of t's, not really necessary? Like cars drive just fine without licence plates? Heaven knows there's enough people who think the whole thing works by some strange magic, but the current apparent trend is verging on the absurd. >I am working at a site that has a Cisco 7010? Router >running V 10.0 The router uses a frame relay connection >to an Internet Provider to connect to the outside World. > >Most of the subnets here are "legal" (i.e. registered w/Internic). >However, we have several that aren't. > >Everything works great of the legal subnets. However, the >'illegal' ones cannot connect or even ping anything on the >Frame Relay side of the router. There are technical reasons >why we are not able to get the bogus subnets changed right now. > >I'm wondering if I need to have a map frame relay directive >in the interface description to handle traffic to & from >the subnet that's giving me problems. > >The access-list filters look OK and the interface in question >has no filtering at all. > >Ideas would be greatly appreciated! -- ------ ___ --- Per G. Bilse, Mgr Network Operations Ctr ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 6233803, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since 1982 --- http://www.EU.net e-mail: bilse(a)EU.net

1 0