- Test - lists.nanog.org

Sprint NAP
by Robert Bowman 29 Apr '96

29 Apr '96

Does anyone have a valid URL to the sprint nap? I can't seem to find much formal information on the RAs homepage nor sprints. And this url is dead: http://www.ra.net/routing.arbiter/NSFNET/NAPs/Sprint/Sprint.html\ Thanks. Robert Bowman Sr. Hole Plugger Exodus Communications Inc. rob(a)exodus.net (408) 522-8473

2 1

Routes and routing tables
by Christian Nielsen 29 Apr '96

29 Apr '96

As I think we are done talking about DNS, I have been looking at our routing tables as of late. I am seeing that many providers with blocks of address space do not aggregate the addresses. I think that if this is so, there needs to be something done to fix it. Once again, we are not even getting a full BGP table and know that if I see problems on a smaller scale, their most be more of these problems out there. thanks Christian Nielsen Vyzynz International Inc. cnielsen(a)vii.com,CN46,KB7HAP Phone 801-568-0999 Fax 801-568-0953 Private Email - Christian(a)Nielsen.Net BOFH - cnielsen(a)one.dot PS :)

6 6

Re: Peering Policies and Route Servers
by avg＠postman.ncube.com 29 Apr '96

29 Apr '96

There are two good reasons to peer only with backbones of comparable size: 1) technical -- this allows to do hot-potato routing with minimal resulting delay assymetry 2) economical -- peering at IXP is favouring smaller folks in cost/benefit game. For a large ISP the percentage of additional destinations the small ISP offers is smaller, and so is the benefit of peering. ANd extra peerings are far from "free". They produce extra paths which need to be processed by routers, and so translate in shorter lifetime of the equipment -- which means very real money. It also reduces effectiveness of aggregation and increases risk of catastrophic failures (large ISPs spend significant part of engineering resources and practice rather strict controls on configuration process to ensure sanity of routing; they also have to _trust_ each other. Most of garbadge in routing tables comes from small ISPs, and is usually hard to fix (no 24hr NOC etc). So the "three IXPs" limitation is specifically designed to ensure equality of sizes (to a some extent), other provisions of BLIAs ("blia" is a common profanity in Russian, btw :) include 24hr NOC etc. Thus, far from being anti-competitive restrictions those policies only serve to level the playing field -- as players who skip investment in infrastructure, engineering and operations would get unfair advantage otherwise. No sane NSP would refuse peering with a new nationwide DS-3 backbone -- providing that it is something more than hot air. The plank is going to be raised to OC-3 pretty soon, though.... --vadim

1 0

BGP assistance requested
by Larry Rosenman 28 Apr '96

28 Apr '96

I am currently having my BGP baptism with a multipoint frame connection and trying (with some but not a lot of success) to balance the traffic to have it make some sense. is there anyone on this list willing to spend 15-20 minutes on the phone walking thru my config and making some suggestions? we are on one providers net with 3 interfaces to 3 different routers, so it is making my reading of the BGP tutorial from Cisco harder. Any help would be appreciated. (The router config would be available to any helpers). THanx in advance. if this request isn't in keeping with this list, please let me know. Larry Rosenman -- Larry Rosenman Phone: +1 214-399-0210 (voice) Internet: ler(a)lerami.lerctr.org US Mail: 900 Lake Isle Circle, Irving, TX 75060-7726

1 0

Network number by country matrix wanted
by gih＠aarnet.edu.au 28 Apr '96

28 Apr '96

I'm attempting to do a detailed end to end traffic flow analysis here, and I was wondering if anyone has got a table of network number and country code table I can use in the post processing of the data. Any pointers would be greatly apprecated! thanks, Geoff Huston Telstra Internet

1 0

Re: Routes and routing tables
by Avi Freedman 28 Apr '96

28 Apr '96

> On Sat, 27 Apr 1996, Avi Freedman wrote: > > > Take a look at http://www.routes.netaxs.com for the output of an > > Avi, > > I can't get to the site, no DNS... > > > www.routes.netaxs.com > Server: lonepeak.vii.com > Address: 206.71.77.2 > > *** lonepeak.vii.com can't find www.routes.netaxs.com: Non-existent domain > > maybe your dns isn't updated yet.. > > Christian Nielsen > Vyzynz International Inc. cnielsen(a)vii.com,CN46,KB7HAP > Phone 801-568-0999 Fax 801-568-0953 > Private Email - Christian(a)Nielsen.Net BOFH - cnielsen(a)one.dot PS :) Argh, apologies. It's http://routes.netaxs.com. It's that stupid 'http://www' reflex. Same thing that makes me type 'thought' instead of 'though'. Avi

1 0

Re: Inter-exchange media types
by Paul Ferguson 27 Apr '96

27 Apr '96

Wolfgang brings up a good point; there are certainly regional interests in creating exchange points within certain geographic areas. This is a Good Thing (tm). We should encourage this is every way, shape or form. Especially in SE Asia, and other areas where traffic traverses already congested links back to the US just to reach its final destination in SE Asia. I realize this is borderline NANOG topic, but it really *does* affect North American network Ops when traffic has to transit NA links just to reach its final destination 25 km away from where it originated. This is insane. While I do not mean to point out SE Asia as the most violent offender of this transient problem, the problem exists elsewhere in the world; SE Asia just happens the be the most handy real-world reference. Food for thought. - paul At 10:48 AM 4/25/96 -0700, Wolfgang Henke wrote: > > The problem for the major exchanges may soon be what to do when the > gigaswitch runs out of bandwidth. > > >It seems to suggest more exchange points; like for example the recent >interest in new regional packet exchanges in California and Utah. > >When large 'tier 1' providers run into bottleneck problems, do we >have to rely more on the intermediate and smaller ones to connect us? > > >Wolfgang >

2 1

max. prefix length
by algold＠lambda.lncc.br 26 Apr '96

26 Apr '96

Sorry for the newbie question: Is there a consensus on the maximum network prefix length that can be accepted for announcement between full-routing BGp speakers ? -- ----------------------------------------------------------------------------- | Alexandre Leib Grojsgold | tel: + 55 21 542-2746 | | LABORATORIO NACIONAL DE COMPUTACAO CIENTIFICA | fax: + 55 21 295-8499 | | 22.290 Rio de Janeiro - RJ - Brasil | | -----------------------------------------------------------------------------

3 2

Re: max. prefix length
by Paul Ferguson 26 Apr '96

26 Apr '96

At 05:31 PM 4/26/96 -0400, Sean Doran wrote: > >Technically, anything between a /0 (which, Paul, would be >the minimum length ;> ) and a /32 is supported by BGP4. > Can I be often confused dyslexic and. :-) - paul

1 0

Re: max. prefix length
by Sean Doran 26 Apr '96

26 Apr '96

-----BEGIN PGP SIGNED MESSAGE----- > >Is there a consensus on the maximum network prefix length that can be accepted > >for announcement between full-routing BGp speakers ? > > I would think it would be a /1, although I admit I've not actually > tried it. :-) Is there a consensus on what _can_ be accepted? Well, probably not. Depending on where you're connected and what you're trying to accomplish, there may be practical limits to the usefulness of certain prefix lengths. Technically, anything between a /0 (which, Paul, would be the minimum length ;> ) and a /32 is supported by BGP4. Most large networks won't accept a /0 (which is the ultimate default); some of our peers filter out anything shorter than a /8. A number of large networks, including Sprint and MCI, filter out anything longer than 24 bits. I suspect that if someone started announcing significant numbers of /32s (host routes), we would see more such filtering. A number of networks do no filtering at all. Sprint currently filters announcements from its non-customers as follows: in the classical "A" space: accept nothing longer than /8 [*] in the classical "B" space: accept nothing longer than /16 in newer "C" space: in 206/8: accept nothing longer than /19 in 207/8 - 223/8: accept nothing longer than /18 [*] in 194/8: accept nothing longer than /18 [*] (The things tagged with [*] are "soft"-ish policies. When technical ways emerge that will let us relax our filters to a degree (in the "C" space, to come more in-line with the registries' windowed allocation schemes; in "A" space, to allow very large subnets, like /12s in the "A" space perhaps), then we may do so. One of the things under test now is progressive dampening penalties across the entire address space. The idea is that the longer an unstable prefix happens to be, the longer it will be suppressed when it regains stability. Right now, in the initial testing, we're penalizing /24s such that if three flaps occur in 45 minutes, we suppress the unstable /24 for three hours after it becomes stable again. All other prefixes, including /23s, are suppressed for much less time (the shorter the prefix, the less "aggressively" dampened). The general idea is to make it worthwhile for people to consider doing aggregation even as simple as coalescing neighbouring /24s into a /23, or to renumber into an more aggregatable block, unless your announcement is _very_ stable.) Sean. P.S.: There are a depressing number of prefixes (some 25 or so, ALL of them /24s) that behave like these two. Please, folks, run BGP dampening code on your routers. SL-MAE-E>sh ip bgp 198.68.161.0 BGP routing table entry for 198.68.161.0/24, version 138091 Paths: (3 available, best #3) 3830 4388 3703, (suppressed due to dampening) 192.41.177.170 from 192.41.177.170 (204.157.228.1) Origin incomplete, metric 1, localpref 90, valid, external Dampinfo: penalty 6296, flapped 958 times in 17:20:54, reuse in 04:14:00 SL-MAE-E>sh ip bgp 198.184.184.0 BGP routing table entry for 198.184.184.0/24, version 737871 Paths: (1 available, no best path, advertised over EBGP) 690 1321 2386, (suppressed due to dampening) 192.41.177.140 from 192.41.177.140 (140.222.147.62) Origin incomplete, metric 1, localpref 90, valid, external Dampinfo: penalty 6288, flapped 405 times in 08:08:01, reuse in 04:14:00 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey iQCVAwUBMYFAtESWYarrFs6xAQEBIAP/ejJNi7QOv+rUbnmcAVloFM40DJpsjg+P Fw8xDof+4jjVO4Iv7J5V/uqgzKdY1Xt/oi8L+mLH3TeF4o5D/Go274xP+rUfiUcU NAahWl/lt0RMSVYQENQ8nVXOTBwGsJ98F6gSWbVm9SYiGq5fiIG4Y0H7l8FT4b9v XibRTwlHtl0= =VdrR -----END PGP SIGNATURE-----

1 0