- NANOG - lists.nanog.org

IRR route entries
by Marc Slemko 01 Oct '96

01 Oct '96

At http://compute.merit.edu/problems.html, there is a list of routes being advertised with ASs inconsistent with those in the IRR. I'm having a bit of trouble understading a few things. I will take an example of 192.139.72.0/24, which is one of our client's blocks. It shows up with an inconsistent origin AS in http://compute.merit.edu/stats/mae-east/problems/IRR/3561.960930.html: 192.139.72.0/24 192.41.177.181 (3561 577 852 6171 IGP) [ AS2493 AS2493] 6171 is the AS that it should be originating from, however according to this it appears that at least something thinks it should be coming from AS2493, who used to be our provider until perhaps six or eight months ago when we dropped them because they were simply too clueless to make things work. Our new provider is AS852; our advertisements were coming from them for a while until CA*net figured out how make things work with us talking BGP to AS852 who talks BGP to CA*net (AS577, at least for their backbone). You may remember me asking about advisory attributes a few weeks back; that was because CA*net was trying to tell us that the reason our route advertisements weren't making it past CA*net's borders was because our entries didn't have an advisory field in them. Thanks for the responses on that one; I thought the advisory attribute was obsolete, but CA*net insisted it was needed. Interestingly enough, the other change we told them to make in the routing database which they said wouldn't do anything was made and when it was made things did start working. <sigh> Anyway, back to the issue at hand: All our IRR updates are done into the CA*net routing database (crcd). current situation appears to be as follows: Script started on Tue Oct 1 09:24:40 1996 marcs@alive:/usr/var/tmp$ whois -h whois.canet.ca 192.139.72.0 route: 192.139.72.0/24 descr: NET-LI01 origin: AS6171 remarks: AGT Advanced Communications - WorldGate mnt-by: CANET-RC changed: wtowbin(a)agtac.net 960612 source: CANET route: 192.139.0.0/16 descr: NETBLK-CANET-192-139 origin: AS577 comm-list: CANET_PROXY_AGGRS mnt-by: CANET-RC changed: config(a)canet.ca 950419 source: CANET route: 192.139.72.0/24 descr: NET-LI01 origin: AS2493 mnt-by: CANET-RC changed: briand(a)nds.netsvc.istar.ca 960503 source: CANIX [From this, it appears to me like the first one should be preferred because of the date on it.] marcs@alive:/usr/var/tmp$ whois -h whois.ra.net 192.139.72.0 route: 192.139.72.0/24 descr: NET-LI01 origin: AS6171 advisory: AS690 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(218) 5:3561(147) remarks: AGT Advanced Communications - WorldGate mnt-by: CANET-RC changed: wtowbin(a)agtac.net 960612 source: CANET route: 192.139.72.0/24 descr: NET-LI01 origin: AS852 advisory: AS690 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(218) 5:3561(147) remarks: AGT Advanced Communications - WorldGate mnt-by: CANET-RC changed: wtowbin(a)agtac.net 960612 source: CANET [AFAIK, the above one was deleted from the crcd on 960612, at the same time the one above it was added.] route: 192.139.72.0/24 descr: NET-LI01 origin: AS542 advisory: AS690 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(218) 5:3561(147) mnt-by: CANET-RC changed: config(a)canet.ca 960207 source: CANET [This one is left over from our old provider before I*Star bought them.] route: 192.139.72.0/24 descr: NET-LI01 origin: AS2493 mnt-by: MAINT-AS2493 changed: briand(a)nds.netsvc.istar.ca 960503 source: ANS route: 192.139.72.0/24 descr: NET-LI01 origin: AS2493 mnt-by: MAINT-AS2493 changed: briand(a)nds.netsvc.istar.ca 960503 source: MCI [The above two are from our old provider after they were bought by IStar, aka AS2493. Does the source mean that they are submitting them directly to ANS and MCI? My best guess on the situation is that, for some reason, AS2493 is submitting updates to MCI and ANS, who are their service providers, and they are being preferred over the correct ones.] marcs@alive:/usr/var/tmp$ whois -h whois.ans.net 192.139.72.0 route: 192.139.72.0/24 descr: NET-LI01 origin: AS2493 mnt-by: MAINT-AS2493 changed: briand(a)nds.netsvc.istar.ca 960503 source: ANS [ANS sure thinks AS2493 is the right one.] marcs@alive:/usr/var/tmp$ Script done on Tue Oct 1 09:25:15 1996 There are also a few different problems with some of our other addresses, for example (from http://compute.merit.edu/stats/aads/problems/IRR/3561.960929.html) 207.167.0.0/19 198.32.130.12 (3561 577 852 6171 IGP) [] There should be no old providers screwing anything up here, since this is a newish block. It shows up in the CA*net database, at whois.ra.net, but is still listed as not being properly registered. There are others that are showing up, but these seem to be the two types of problems that are showing up. Can anyone provide any helpful hints on what is going on? Thanks.

1 1

Re: CLASS B address sold (fwd)
by Vince Fuller 01 Oct '96

01 Oct '96

> I really didn't think that anyone would "buy" it. Two years ago when I was working on Wall St., we needed an entire class B, the brokerage payed $64,000 for it. Cool. If anyone else has $32,000 - $64,000 to spend on a /16 (aka class-B), please let me know. --Vince

1 0

Re: Peering versus Transit
by owen＠DeLong.SJ.CA.US 01 Oct '96

01 Oct '96

> Matt Zimmerman <mdz(a)netrail.net> writes: > > because you're using THEIR resources to do so, without > > explicit permission from them. > > That's a repetition of the same position that's been stated over and > over, without justification. If A sends to B directly in the absence > of an advertised route, A is "stealing" resources from B. If B sends > to A indirectly through A's transit provider, then B is "stealing" > resources from A. What makes the former case worse in your mind than > the latter, when it results in higher reliability, lower cost, and a > sounder architecture? > The latter is not "stealing", it's sending packets to the advertised route. The former is "stealing", it's sending packets to an unannounced route. Owen

1 0

Re: Advice on dealing with Sprint
by Darrel Lewis/TEIR/Thomson 01 Oct '96

01 Oct '96

Wait a sec, I was under the impression that multihoming with sprint was only a problem if you used PA addresses from Sprint. If you have PI addressing, or your addressing is from (for example) MCI, you shouldn't see a problem. Was I missing something? -D Darrel Lewis Network Engineer Thomson Electronic Information Resources dlewis(a)teir.com wsimpson @ greendragon.com ("William Allen Simpson") 09/30/96 04:57 PM To: jon @ worf.netins.net (Jon Green) @ Internet cc: nanog @ merit.edu @ Internet Subject: Re: Advice on dealing with Sprint Coming back to an old topic from whence we diverged, my advice would be _not_ to connect or multihome with Sprint unless they accept you as a peer and share the cost. Earlier, we have learned that Sprint doesn't multihome properly, as it deliberately ignores paths to its own "customers" seen from other ISPs even when its own lines are down. You learned that they have restrictive policies on routers. And more recently, we learned that Sprint has extremely restrictive policies on peering (exchanging routes). There really isn't much point to multihome with Sprint except to load share directly to Sprint's customers. You don't get any of the other benefits of redundancy. Why bother paying for the link and Sprint for the privilege? I can tell you, since my upstream provider switched a few weeks ago from multihome with Sprint and MCI, to nap.net and MCI, we've had _much_ better service! When nap.net has had problems, multihoming has actually worked correctly.... And multihoming with MCI and AlterNet seems to work well together, too. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

3 2

Re: Peering versus Transit
by William Allen Simpson 01 Oct '96

01 Oct '96

> From: "Craig A. Huegen" <c-huegen(a)quad.quadrunner.com> > Unfortunately, people who think non-operationally tend to have their heads > in the clouds. People who think both operationally and developmentally > are hard to find, but are the best at realizing better methods that are > scalable. > > "Old hats" might have a problem accepting some change, but they are a bit > wiser. Most "old hats" at least know what an RFC is. Or can at least > pass up marketing hype and find real-world results as a basis for judging > performance within a network (and I'm not just referring to hardware). > > The problem is that "new hats" tend to re-invent the wheel way too many > times. > I believe that you are being unfair to rather a large number of folks -- speaking as an "old hat", indeed probably much older hat than most of those on this list, who knows what an RFC is.... Indeed, I happen to think of folks like those that operate Sprint (et alia) as the "new" kids on the block. And we get more "new" kids all the time, such as yourself. Not everyone agrees on how the Internet should be operated, or what the model should be, or even that there should be a single model! We explicitly set things up so that many funding models could be tried. That assumed that all participants would peer with each other at neutral locations (the NAPs). The restrictive peering policies of a few large carriers are making that difficult. Some folks, both old and new, are exploring the issues and suggesting solutions. Please do not disparage such comments and questions. They were actually quite accurate and helpful. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Re: CLASS B address sold (fwd)
by Michael Dillon 01 Oct '96

01 Oct '96

---------- Forwarded message ---------- Date: Mon, 30 Sep 1996 20:42:46 -2900 (CDT) From: Jamie Downs <egon(a)atw.fullfeed.com> Reply-To: inet-access(a)earth.com To: inet-access(a)earth.com Subject: Re: CLASS B Resent-Date: Mon, 30 Sep 1996 19:42:57 -0600 (MDT) Resent-From: inet-access(a)earth.com > A few weeks ago...someone had a Class B for sale...is it still Too late. I'm told the closing bid was $32,000... > Rick egon ============================== ISP Mailing List ============================== Email ``unsubscribe'' to inet-access-request(a)earth.com to be removed. Wrap your text at 80 columns, don't post messages with long lines.

4 3

Re: "Basic BGP configuration problem"
by Vadim Antonov 01 Oct '96

01 Oct '96

William Allen Simpson <wsimpson(a)greendragon.com> wrote: >> For a good laugh, call: >> 800-669-8303 >> and select option 2. > >I did! Note that it was recorded at 7 pm, saying it would take 2 hours. >Here it is at midnight.... How many real engineers they got? One and unhappy one at that? When i was the only engineer there i had five times less customers to tend to; and i had quite a stressful life. The only reason for me leaving Sprint was woeful cluelessness of management about realities of labour market in the field. --vadim

1 0

Re: "Basic BGP configuration problem"
by William Allen Simpson 01 Oct '96

01 Oct '96

> From: "Bradley Dunn" <bradley(a)dunn.org> > Date: Mon, 30 Sep 1996 23:34:48 -0400 > > For a good laugh, call: > 800-669-8303 > and select option 2. > I did! Note that it was recorded at 7 pm, saying it would take 2 hours. Here it is at midnight.... You know how it is, those small, naive ISPs are having trouble with a correct BGP configuration, ruining everyone's peering! ;-) Anyway, I'm actually thankful they _have_ such a status message! This is a real improvement over recent times past, as folks can figure out what is wrong, and know what trouble ticket has been registered. I thank Sprint for improving that part of their service.... WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Re: Peering versus Transit
by Sanjay Dani 01 Oct '96

01 Oct '96

> From avg(a)quake.net Mon Sep 30 19:05 PDT 1996 > >I didn't know access service providers are not paid by their > >web browsing clients. > > The cost of transaction is split between content providers and > clients. Is this that hard to understand? I guess you missed the sarcasm. Try applying your statement to your own argument and see who is trying to fleece whom? This is homework. No need to fill up my mailbox anymore. > Heh. That's an example of how stupid technology is being > preserved by stupid legistlation. The laws regarding POTS are > generally legal fixes for techincal problems (like inability > to block annoying calls). Forgotten the syn flood attack so quickly? Heard of IP spoofing? > FYI -- i had a more than an engineering role in service providers > covering together all time zones on this planet. One of them > was the first ISP in 16-odd countries. Another was the first > commercial DS-3 backbone in the world. That does not make your one sided arguments stand any more than they did. Goes to prove experience does not necessarily equate insight into all aspects of the business. You have a stake in perpetuating the status quo. Me in changing it because it doesn't make sense. > So why you just don't learn why the present system is here, > and why it delivers while others only promise. No, it is beginning to suck. Have you checked reliability of the backbones lately? Sigh.. old hats like you have a hard time realizing that old models have to, and will, change. Sanjay. PS. This is my last email on this topic.

2 1

Re: Peering versus Transit
by Eric Sobocinski 01 Oct '96

01 Oct '96

On Mon, 30 Sep 1996 at 18:44 PDT, Vadim Antonov <avg(a)quake.net> wrote: > > Michael Dillon <michael(a)memra.com> wrote: > > >What if you are FlyBite Couriers Inc. and you have a parcel for Bigco > >Inc's art department. The sign on the door at BigCo says "No deliveries, > >go to the back door, this means you!". But you are to lazy so you walk in, > >argue with the receptionist for a minute and dump your package on the > >floor. She has to call in one of the mailroom people from the far end of > >the building complex to deliver the package. > > Er. That situation may actually end up in court. Legally, the parcel > is still in posession of FBC Inc. -- nobody signed the receipt and > nobody left drop-shipment authorization. So sender of the packet > has all reasons to sue FBC Inc. > > So, thank you for playing, but the analogy is somehow wrong. > > > It is not a "theft", it is more like trespassing. It is illegal and > > covered by codes related to unauthorized use of equipment. > > FlyBite Couriers has caused Bigco to spend their own resources in order to > deliver the package to teh art department. Is FlyBite Couriers guilty of > theft? No. Are they guilty of trespass? I don't think so. Actually, they *are* guilty of trespass! The owner has the right to restrict some or all uses of a piece of property. BigCo clearly posted that a particular use (delivery of packages) was banned on their property. Legally, this would be no different than if they had posted "no hunting" and would be enforced the same way. The fact that the owner encourages the same activity on an adjacent property (at the back of the building) is irrelevant. Equally irrelevant is suitability: It doesn't matter that delivery in the lobby might seem preferable. The analogy holds well enough that you could apply the same legal remedies to unwanted delivery of network packets as you would for physical trespass. Upon discovery, the "trespassed" party somehow warns the offending party of their transgression in some sort of well-documented way (grievance, cease-and-desist order, injunction). Should the offending party repeat the action, you have evidence of at least negligence and should have no problem pressing a suit in an appropriate court. All of this is void, of course, if there's some law or superceding agreement that allows such deliveries, regardless of what is "posted". I admit that I don't know what the NSF and various NAP hosts require as far as peering at NAPs, but everything I've heard so far implies that they don't require peering except in very specific circumstances. > Analogy was wrong. They're guilty of fraud if you want legal definition. > They promised sender to deliver parcel, took money and didn't. I find the analogy was right, but they may also be guilty of fraud depending upon the local legal definition of delivery. If so, it could probably be prosecuted with or without an accompanying trespass charge. And, of course, your mileage may vary in an international or non-USA situation. > >This makes good sense too. However, there are always two sides to every > >traffic engineeriung question... > > Exactly. That's why traffic engineering at IXPs is always is a matter > of mutual agreement. Dumping packets at somebody is doing something > without an agreement, ok? Agreed. > --vadim --eric Disclaimer: Of course I'm not an attorney, else the above advice would have cost you plenty. :-) Eric P. Sobocinski | Internet: sobo(a)merit.net | 1075 Beal #2220 Merit Computer Network | or sobo(a)merit.edu | Ann Arbor, MI 48109-2112 Hardware Engineering | | 1.313.763.4895 (USA)

1 0