- Test - lists.nanog.org

Re: peering tools
by Sean Donelan 10 Apr '00

10 Apr '00

On Fri, 07 April 2000, Scott Call wrote: > As we (ATG) are about to move into PAIX, SIX, and MAE-East ATM, I wanted > to ask what the members of Nanog used to manage their peering with > others (software wise). Currently we are all Cisco based, but Juniper > and others are also eventualities. > > I've looked at the RtConfig program and it seems like a place to > start, but I get the feeling that this is not the method most use. Most folks configure provider-to-provider BGP peering sessions manually. Fortunately they change fairly infrequently. A few use some automated tools to push and collect router configurations, and macro or script tools like M4 and Perl. Even fewer use RtConfig or other database driven configuration tools. ANS had the closest to fully automated their peering configurations, but they're gone now. The basic problem is most providers have homegrown systems which can't share data with other providers. RPSL/IRRDB are attempts to communicate the information between providers, but generally different providers use very different forms and procedures. Sprint used a completely different method of exchanging information about BGP configutions than Cable&Wireless does. So if you peer with 50 different people, you may have 55 different processes (yes, some providers have more than one process even within their own company). I suspect Randy will explain its not a problem with Verio, but Verio is a exception.

3 2

RE: NAPs
by Martin, Christian 09 Apr '00

09 Apr '00

It is... All the links are dead. -chris > -----Original Message----- > From: bmanning(a)vacation.karoshi.com > [mailto:bmanning@vacation.karoshi.com] > Sent: Saturday, April 08, 2000 3:00 PM > To: hank(a)att.net.il > Cc: mct(a)netaxs.com; danny(a)tcb.net; nanog(a)merit.edu > Subject: Re: NAPs > > > > > >There's http://www.ep.net/ ... > > > > How is this different than http://www.isi.edu/div7/ra/NAPs/ > ? Perhaps Bill > > can add a pointer from div7 site to ep.net site? > > > > -Hank > > http://www.isi.edu/div7/ra/NAPs/ is or should be defunct > as the project has been over for a number of years. EP.net > is keeping up with the changes (as best as it can in a passive > manner) and I help when I can. > > --bill >

1 0

RE: Policies: Routing a subset of another ISP's address block
by Greene, Dylan 09 Apr '00

09 Apr '00

Hey there.. I'd imagine this works fine, but doesn't it leave you w/ inconsistent-as, where you've got a prefix being advertised from the private ASN, stripped & replaced w/ each upstream ASN? I mean, it should work, but is it a very good idea? The inconsistent-as list isn't _too_ big right now, which is good, as each one effectively breaks a number of common path filters. But if that starts to becomes common practice, the list gets bigger and bigger & more filters get broken. ..Dylan > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Jesper Skriver > Sent: Friday, April 07, 2000 2:21 PM > To: Daniel L. Golding > Cc: David Harrison; nanog(a)merit.edu > Subject: Re: Policies: Routing a subset of another ISP's address block > > Actually I've helped quite a few such customers, my recommendation > usually is to get PI space from RIPE, and get both providers to announce > it from their ASN, this works quite well, and also save a ASN - if the > customer really want to run BGP, we have arrangements with other ISP's > here, that we find a private ASN (that none of us use currently), and > assign this ASN to the customer, and we then strip the private ASN on > the edges of our network. this is interesting (since it overwrites the rule that multihoming to two isps requires a public asn assignment) and i've tested exactly this scenario (again, a customer uses some private asn and is peering with two isps; both of them strip this asn at their boundaries (remove-private-as)) in my lab before and it worked fine. it results in propagating routes to the same networks with two distinct as path attributes, though. i've been looking for any operational experience with this setup. so, do you claim that you couldn't detect *any* problems with this setup? -- dima.

8 7

NAPs
by Danny McPherson 08 Apr '00

08 Apr '00

Does anyone maintain a list of all the "public" NAPs *globally* with name, contact, media-type/speed and location information? If yes, would you mind sending me a pointer? Else, I'll compile it and make it available but need some help, especially with non-North American. Thanks in advance! -danny

4 4

Re: Policies: Routing a subset of another ISP's address block
by Daniel L. Golding 07 Apr '00

07 Apr '00

Jesper, Do you then suggest the elimination of the ARIN multihomed issuance policy - which is, BTW, the method most folks use to get PI space these days? After all, you can't be truly multihomed without PI space in your scheme of things. This would seriously raise the bar for folks to get PI space in the first place. You would effectively ban anyone doing BGP advertisements that doesn't have their own PI space already. This is a troublesome suggestion. It denies the benefits of multihoming to small enterprises and ISPs, effectively discriminating against them. I find your line of reasoning, which is essentially "tough cookies" to be unconvincing. I must also assume that you haven't worked for a small ISP or CLEC recently, nor have you had such for a customer. There must be room for providers of all sizes in the marketplace. If this thesis enjoyed widespread acceptance by the major Tier I ISPs, I have no doubt that it would be considered anti-competative. - Dan Golding On Wed, 5 Apr 2000, Jesper Skriver wrote: > On Wed, Apr 05, 2000 at 10:45:07AM -0400, Daniel L. Golding wrote: > > On Wed, 5 Apr 2000, Jesper Skriver wrote: > > > > > > > > On Wed, Apr 05, 2000 at 08:33:25AM -0400, David Harrison wrote: > > > > > > > > We have a situation where we have a client who wants to be dual-homed > > > > for redundancy. They are not large enough to get addresses from ARIN. > > > > Given that they are wanting us to allow another provider to route a > > > > subset of one of our address blocks(5 /24's out of a /16). > > > > Looking for some recommendation/dangers and general policies in > > > > reference to this. Thanks for any input. If this is the incorrect list > > > > to post this on please let me know. > > > > > > Refuse to do it, the customer must get PI addresses for this purpose. > > > > That's simply not true. Many ISPs will advertise another's netblocks for a > > mutual downstream. The client doesn't have enough IP space to qualify for > > PI space in any case unless they utilize a /21 to 80% while being > > multihomed. > > Bad luck ... > > I can say for sure, that we doesn't accept more specific announcements within > our PA blocks, nor does we accept traffic with a source within these > blocks. > > > I don't see the logic behind refusing the customer a request of this sort. > > Exploding routing tables, and it makes it impossible to do anti-spoofing > filters ... > > /Jesper > > -- > Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 > Work: Network manager @ AS3292 (Tele Danmark DataNetworks) > Private: Geek @ AS2109 (A much smaller network ;-) > > One Unix to rule them all, One Resolver to find them, > One IP to bring them all and in the zone to bind them. >

3 2

The Cidr Report
by Tony Bates 07 Apr '00

07 Apr '00

This is an auto-generated mail on Fri Apr 7 12:00:02 PDT 2000 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 07Apr00 0) General Status Table History ------------- Date Prefixes 310300 74847 010400 74802 020400 74868 030400 74911 040400 75068 050400 74793 060400 74813 070400 75152 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 65.45.0.0/19 from AS10585 *** Bogus 219.91.160.0/22 from AS7742 *** Bogus 219.91.164.0/23 from AS7742 AS Summary ---------- Number of ASes in routing system: 7138 Number of ASes announcing only one prefix: 3959 (2159 cidr, 1800 classful) Largest number of cidr routes: 982 announced by AS701 Largest number of classful routes: 1040 announced by AS701 1) Gains by aggregating at the origin AS level --- 07Apr00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 437 152 285 65.2% BCnet Backbone AS7046 468 320 148 31.6% COQUI-NET PRTC Internet AS9706 155 21 134 86.5% Pusan Metropolitan City Office of AS9269 159 27 132 83.0% Hong Kong CTI AS1221 493 380 113 22.9% TELSTRA-AS AS2609 124 17 107 86.3% EUnet-TN AS7657 269 171 98 36.4% The Internet Group Limited AS705 314 218 96 30.6% ALTERNET-AS AS7545 159 64 95 59.7% TPG Internet Pty Ltd AS174 561 472 89 15.9% Performance Systems International AS4293 293 205 88 30.0% Internal ASN for C&W AS7496 125 38 87 69.6% Power Up AS6429 207 122 85 41.1% RDC-INTERNET AS9304 108 26 82 75.9% Hutchcity AS577 255 176 79 31.0% Bell Backbone AS7029 142 70 72 50.7% ALLTELNET AS209 446 378 68 15.2% Qwest Communications AS9557 80 15 65 81.2% Pakistan Telecommunication Compan AS1727 155 92 63 40.6% MRMS-WEST AS3602 309 247 62 20.1% Sprint Canada Inc. AS7260 110 50 60 54.5% NORLIGHT AS7018 519 459 60 11.6% AT&T WorldNet Service Backbone AS701 1040 981 59 5.7% Alternet AS3749 120 61 59 49.2% TECNET AS4740 339 281 58 17.1% Ozemail Pty Ltd (ASN-OZEMAIL) AS724 199 143 56 28.1% DLA-ASNBLOCK-AS AS816 331 276 55 16.6% UUNET Canada (ASN-UUNETCA-AS4) AS7568 66 18 48 72.7% C.S. Communications Co., Ltd. AS6595 87 42 45 51.7% DODDSEUR AS5106 73 29 44 60.3% AADS-COLUMBUS For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: Policies: Routing a subset of another ISP's address block
by Phillip Vandry 07 Apr '00

07 Apr '00

> I can say for sure, that we doesn't accept more specific announcements within > our PA blocks, nor does we accept traffic with a source within these > blocks. So you might not allow a customer to break up your block, but you haven't said that you wouldn't allow a customer to announce a fragmented block belonging to someone else, supposing this other party does not share your policy. > > I don't see the logic behind refusing the customer a request of this sort. > > Exploding routing tables, and it makes it impossible to do anti-spoofing > filters ... You're going to have to exempt multihomed downstream customers from your anti spoofing filters anyway, whether they use your space, someone else's or their own. To put it another way, if you have clueful downstreams, you should delegate anti spoofing to them, they will do it closer to the edge where there is no asymetrical routing. -Phil

3 3

Re: Policies: Routing a subset of another ISP's address block
by Jesper Skriver 07 Apr '00

07 Apr '00

On Wed, Apr 05, 2000 at 12:29:53PM -0400, Jim Duncan wrote: > Jesper Skriver writes: > > > I don't see the logic behind refusing the customer a request of this sort. > > > > Exploding routing tables, and it makes it impossible to do anti-spoofing > > filters ... > > It's only a problem if the ISPs expect to handle transit traffic from the > customer. I suspect that most multi-homed customers do _not_ intend nor > desire to carry traffic from one provider to another over their own > network. No, this is not correct. Lets assume provider A has x.x.0.0/16 assigned, and deny any traffic with a souce address within this range on all peering (and transit) links, and lets assume, that customer Z get's provider B to announce x.x.10.0/24 for him, this means that the customer Z cannot reach anything on provider A's network in the case where the link to provider A fails. > Apologies if I've misunderstood the discussion, but with regard to > anti-spoofing of source addresses, a multi-homed non-ISP customer on the > edge of the network is no different from a single-homed customer: you > filter so that all packets leaving that network meet the criteria for > packets sourced on that customer's network. Yes, but you also need to make sure that others cannot spoof source addresses that you has declared to be spoofing safe (so people can trust the source address for authentication purposes). > Of course, the best way to implement this is for the _customers_ to > implement this filtering on all the interfaces of all their routers. > That's where there's going to be router CPU to spare, and if they did > that, then the ISPs wouldn't have to worry about it. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.

1 0

Take A look
by 9yyyeff＠aol.com 07 Apr '00

07 Apr '00

UNIVERSITY DIPLOMAS Obtain a prosperous future, money earning power, and the admiration of all. Diplomas from prestigious non-accredited universities based on your present knowledge and life experience. No required tests, classes, books, or interviews. Bachelors, masters, MBA, and doctorate (PhD) diplomas available in the field of your choice. No one is turned down. Confidentiality assured. CALL NOW to receive your diploma within days!!! 1-212-465-3248 Call 24 hours a day, 7 days a week, including Sundays and holidays. rem- hhiitt44(a)popmail.com

1 0

Leaving ARIN
by Kim Hubbard 06 Apr '00

06 Apr '00

As announced this week at the ARIN Public Policy Meeting, I have decided to resign as President of the American Registry for Internet Numbers (ARIN). While I have greatly enjoyed my time with ARIN and continue to believe in and support ARIN's goals, I feel it is time for me personally to make a change. We hope to find a replacement by mid-June, however, I want to make sure the transition to a new president is as smooth as possible and will do whatever is necessary to ensure this. We have hired an Executive Search firm to help us in our search. If you know of anyone you think may be appropriate for this position please have them go to http://www.arin.net/arin/employ.htm for more information. I want to take this opportunity to thank each of you who have given me your support and encouragement. Over the years, I have made many friends through my work and have had some great times with many of you at NANOG, IETF and ARIN meetings. I will treasure those memories always. I don't have any specific plans as yet, other than taking a long vacation this summer, but I do plan to keep up with ARIN activities so hopefully I'll see you around :-) Take care, Kim Hubbard ARIN

1 0