- Test - lists.nanog.org

Re: Peering versus Transit
by Eric D. Madison 02 Oct '96

02 Oct '96

Peering is becoming a real touchy issue. Most of the larger providers don't really want to peer with anyone else because they can't really handle the extra traffic, or they are afraid of peering with a company that doesn't have the technical staff that is truly knowledgable about backbone routing. With the major peering points getting more accessable to smaller providers, this becomes even more evident. And to be truthful, it can be understood. Their have been quite a ISP's get temporarily shutdown at one of the MAE's because of "errors" in routing procedures. No names mentioned, but for example about changing peering requirements. One of the larger providers said they required three meet points + 2-3 private interconnects at DS-3 or higher... when we said that we could do that by the end of November, they said, "Really?.. that is going to cost both companies a large sum in hardware and DS-3 local loop fees." They changed their requirements to be just three meet points. If you look at the monthly cost of buying a DS-3 from MCI, Sprint, UUNet, AGIS, or PSI, it is much cheaper to get a connection to a MAE, and trying to get peering. Eric At 10:07 PM 9/30/96 -2900, you wrote: > > Sean, > > It almost makes one think the evil telcos are plotting a new > service/product that would be damaged by legacy contracts, eh? > > -alan > internet engineer for the enquirer? > >> >> >These days peering agreements are business deals. >> >> They have always been business deals. I'm just amazed as some of the >> lengths some providers go to justify what should be a plain-old >> business decision. If you don't intend to peer with another provider, >> just say so. The only providers I tend to get really peeved at are >> the ones that keep changing their stories. >> >> AGIS told me in January '96 that their peering agreement was being >> revised by their lawyers and they would send it as soon as it was >> ready. Since I hadn't heard from AGIS in a while, I sent another >> note to AGIS and was told they now require DS3 connections to four >> exchange points. No idea what happened to that peering agreement >> from January. >> >> MCI told me in February '96 that their peering agreement as >> on hold pending review by their lawyers and they would let me know >> when it was ready. The last response I've received from MCI is the >> person in charge of peering had changed. No word from the new guy. >> And MCI took their peering policies off their web page. No idea >> what happened to MCI's policies in the mean time. >> >> Since March of 1995 (yes '95) I've gone through three product managers >> for Sprintlink who have told me their peering agreement is on the way, >> under legal review, on hold, or being revised. DRA met Sprint's peering >> 'requirements' a couple of times now. But by the time I hear back from >> their product manager du jure, they've changed their requirements again. >> >> I'm puzzled why these providers seem to have new peers show up at the >> same time they are telling me new peerings are on 'hold.' Should I >> start taking this personally? If you don't intend to peer with other >> providers, why not say so? Why go through the trouble of making >> peering questionaires and listing peering requirements, when you are >> just going to come up with a new excuse if you don't want to peer >> with the other provider. >> >> >They happen to >> >be business deals that have $0 attached to them for all sorts >> >of reasons Sean D et al explained far more eloquently than I could, >> >but they are still business agreements. Just like any other contract, >> >be in breach at your peril. >> >> Breach of contract is a civil matter, not criminal. If you have a >> peering agreement that says thou shalt not next-hop third-party routes, >> and they do, you get to terminate the agreement and/or sue the other >> provider, not arrest them. >> >> People seem to be very quick to call things they don't like illegal. >> Not all misrouted packets are the result of illegal activities, most >> of them are just misrouted packets. MCI didn't plan to send me packets >> across mae-east, they just happened to believe some bad routing information. >> >> If you are going to start arresting people simply because packets are >> misrouted, big providers misroute a lot more packets than little providers >> simply due to size. This is a dangerous game to start playing because >> it can easily blow up in your face. >> >> >Which leaves the case where you send traffic to say ISP X >> >*without* any form of peering agreement with ISP X. Contracts >> >with the IXP should prevent this from happening. If you >> >try this, I hope they filter your MAC address. >> >> Some IXPs do this, but the operators aren't always able to keep up with >> the changing arrangements of the various providers and end up blackholing >> a bunch of traffic every so often for varying lengths of time. The routing >> protocols have problems dealing with networks which don't have the 'shared- >> fate' property. >> >> Most other IXP contracts are silent about relationships between ISPs. >> -- >> Sean Donelan, Data Research Associates, Inc, St. Louis, MO >> Affiliation given for identification not representation >> > > >-- >Alan Hannan >Not Employed Networking, Ltd. >email: alan(a)mindvision.com. >phone: 402/488-0238 > > ________________________________________________________ Eric D. Madison - Senior Network Engineer ACSI - Advanced Data Servics - ATM/IP Backbone NOC - 800-291-7889 - noc(a)acsi.net

4 4

GES (jvnc.net) as the purveyor of bad routing advertisements
by Gordon Cook 02 Oct '96

02 Oct '96

COOK: I am going to resurrect the bad advertisement thread because I have some additional knowledge of the subject that I hope will be constructive to share with the Nanog community. After Mat Petach's posts I have done some further research. The 'evil ISP' was jvnc.net also known as GES. I have known these people and their subsequent history in some considerable detail since I joined the staff of the JVNC supercomputer center in September 1987. I had a free account there (in return for my newsletter) from the summer of 1992 until midsummer of this year. From November 1994 until April 17 1996 I used it for all my email activity. In mid April of 1996 a routing problem appeared that made it unusable for me and I switched my email and base of operations to net access. One highly significant thing that has not been said is that this "evil ISP" is the one that Princeton University depends on for its connectivity to the internet. JVNCnet is (was?) one of the NSFnet regionals and has been getting inter regional connectivity money from NSF in order to use MCI to connect Princeton to the rest of the Internet. As Mat Petach wrote, this is not the first time *HE* has had trouble. It is not the first time that many other people have had trouble either. JVNC has lost quite a few major corporate connections over the last 2 or 3 years. And one day early last month Princeton University lost its internet connectivity at roughly 10 AM. It wasn't restored until roughly 6 PM the same day. Less than a week later it suffered a second multi hour outage. I believe that there is ample evidence that the folk at Princeton have to be very aware of the nature of their provider. Yet I have seen no signs that Princeton is ready to pull up its stakes. Yesterday afternoon, I called Ira Fuch's office. (Ira is VP of computing and telecom at princeton if I have his title right.) I told his secretary my concerns indicating I was contemplating going public with them shortly and saying that I'd like to communicate with Ira to get his take on the matter. I called up today at 3:30 pm EST and was told that Ira had no comment on my call nor on the email from this thread that I sent him. I have also called Sergio Heker, the GES CEO and asked his secretary to ask him to call me.... Leaving with her a summary of the reasons for my call. An hour later I received a call from an old acquaintance who happened to be visiting Sergio who apparently didn't feel up to calling me. We talked for an hour and as a result of that conversation I see no reason to change my assessment. An assessment which also has as part of its foundation a continuous input of email messages from various sources describing developments there over the past 6 months. On September 28 matthew petach wrote: I'm going to ask the rest of the NANOG community for their thoughts/opinions on a problem that's been plaguing us periodically that we haven't been able to find a satisfactory solution for yet. There's an ISP back on the East Coast that has been periodically advertising more specific routes for /24's out of our CIDR blocks and black-holing the traffic within their network. We've called all the listed numbers for their technical, admin, billing, and any other contacts we can find, and haven't been able to reach a human; we've left messages of various levels of nastyness, from very sugary on up to vaguely threatening. In every case, including the current one, it's been more than 24 hours, and they still haven't made any response to the problem; in fact, I just got paged by our NOC early this morning informing me they've stolen another one of our /24's. COOK: Matthew tends to assume in his remarks that the "evil ISP" knew what it was doing when it 'stole' his routing announcements. I have evidence that says that is probably not true. In mid April of this year when I would use the 56 kbs connection from my house to log into net access and telnet from there to tigger.jvnc.net to read email, the response from tigger slowed to about 300 baud and I would see several periods an hour where for up to 3 minutes I'd get no echo to my screen of what I was trying to type or read. Traceroutes showed my RETURN traffic was coming by way of the CIX. My connection had become unusable. I did a lot of frantic inquiry and found out that the placement of an AS path filter on the JVNC golden gate router would solve my problem. Calling their NOC, I asked for the filter to be installed and was told that only the net manager could approve such a request. Making multiple calls on April 17 I was told that my request was "under consideration." I spoke that evening to several recent employees and was told that it would probably stay under consideration until hell froze over because there was no one who wanted to touch the routing configs made by a now ex- employee during the transition to MCI in the May- June 1995 time period. Why, because there was no one there who had the knowledge to put things back together if anything broke. Consequently I suspect that the bad routing advertisements may result not from any purposeful action but rather from ignorance. On the basis of further investigation I have also ascertained that staffing has become really stretched and another possibility for the non response to complaints is that the voice mail and email may never have gotten through. Staff turnover at GES between the summer of 92 and 93 was 100%. I have had recent estimates that the current turnover rate may be close to 100% every 6 months. The history of the privatization and spin off of GES from Princeton is in itself an interesting story. One with which I am VERY familiar having been informed of a number of events in 1992 as they were happening and talking directly with people involved on both sides of the story. Unfortunately since that history is now more than 4 years old, none of my sources are willing to go on record and I doubt that I'll be doing any write up of it. Still the situation is that GES (JVNC) is suffering from enormous problems and has been suffering for quite a while. These problems are well known to industry insiders but much less well known to the Nanog community at large. Without clear knowledge of the situation at GES that has been causing these experiences for members of the network community, they are likely to be repeated again and again. With a clearer view of the situation, those involved may be able to decide on the most rational courses of action to take. ************************************************************************ The COOK Report on Internet For subsc. pricing & more than 431 Greenway Ave, Ewing, NJ 08618 USA ten megabytes of free material (609) 882-2572 (phone & fax) visit http://pobox.com/cook/ Internet: cook(a)cookreport.com For case study of MercerNet & TIIAP induced harm to local community http://pobox.com/cook/mercernet.html ************************************************************************

1 0

ATM v/s SONET
by Bharat Ranjan 02 Oct '96

02 Oct '96

> >Vendors such as Fore are starting to offer OC-3c/12/c and OC-48c (future) >interfaces on their ATM switches. Using these interfaces, the switches can be >connected together in a ringlike fashion. A service offered when connected in >a ring is called Fast Failover Recovery, or something along that line. This >service provides functionality that is identical to SONET >protection-switching. Basically, bandwidth is reserved around the ring for >protection scenarios. When the ATM switches detect failure (fiber cut, node >failure, etc.), they recreate the VP around the opposite direction of the >ring using the reserved bandwidth. This is done at the ATM level, versus the >physical level for SONET. As expected, the switchover time is in seconds >versus the milliseconds for SONET. > >For networks that carry data that is not sensitive to this increased >switchover time, does it make sense to use SONET at all? The question comes >down to why do you need a SONET ring when then same functionality and speed >is provided by the ATM ring? mm mm sssss nnnnnn * Bharat Ranjan * m m m s nnnnnnn * Network Engineer * m m m sssss nn nn * MSN Network Services * m m s nn nn * (206)-936-0471 * m m sssss nn nn * bharatr(a)microsoft.com * ******************************************************* * The opinions/ideas in this memo are not necessarily * * those of Microsoft Corp. * ******************************************************* > > > >

1 0

Need hints on proper default route selection
by Curtis Generous 02 Oct '96

02 Oct '96

We have a WAN that is multihomed with 2 NSP's (as customers, not peers). Small routers with limited memory; full iBGP mesh; BGP routes not redistributed into IGP. Our routing policy had been: [] Point default to NSP #1 [] Take internal routes from NSP #2 [] Have a second, lower pref default to NSP #2 Recently, we have been bitten by failures on our 10mbit link to NSP #1 (default) where the ethernet-lookalike link between us became uni-directional (common netedges failure mode). This failure was not detected by the router hardware so the bulk of our traffic continued to send the data out that interface and into a black hole. To get around this failure mode, we got NSP #1 to also send us their internal routes and we changed our candidate default-network to point to one of their well-known annoucements instead of the directly attached interface. So our new policy had been for quite a while: [] Take internal routes from NSP #1 [] Select an annoucement as candidate default net from NSP #1. [] Take internal routes from NSP #2 [] Select an annoucement as alternate candidate default net to NSP #2. The problem we have been experiencing now is that both NSP #1 and NSP #2 have been undergoing some major internal restructuring, causing daily change/loss of candidate net annoucements, or change in aggregation boundaries, etc..... making it a daily exercise at selecting proper candidate route selection. Can anyone provide an alternate or better strategy on how to deal with this? tia, --curtis

3 2

Re: Peering versus Transit
by Eric D. Madison 02 Oct '96

02 Oct '96

>But you're talking about getting connections to 3 exchange points and >the "stuff" in between. I would say costs might be roughly even. That is exactly what I am talking about. The cost of getting the connection to a meet point is minimal.. the people and equipment are costs. That is why if a small provider gets a connection to a single meet point no one wants to peer with them, they don't have the engineer, monitoring, and maintenance. >But what about when you add in the network engineering, monitoring, >and maintenance you need when you run your own network? Have you >checked out market price on clueful network people who dance with >BGP? The cost comparison might look different then... > I know the cost very well. My Cisco Rep is loving it too. We are still rolling out of our network and finding the right people with true knowledge of this business is hard to find. I am trying to find good IP backbone people now and am having a hard time, especially in the Washington, DC area. All the good ones are already taken in this area. It's really becoming a chosen few that "really" know this business and know it well enough to build a living, breathing network from the ground up. Eric

1 0

Peering versus Transit
by William Allen Simpson 02 Oct '96

02 Oct '96

It has appeared to me for some time (and I've mentioned it before) that peering "restrictions" have gotten completely out of hand. I believe this is because terminology and agreements for "peering" and "transit" have become ill defined. I can see no justification under any circumstances why any provider would refuse to peer with another at an established exchange point for exchanging their _own_ customers' traffic! But note: this should not mean transit to others who are not customers of the provider, or to other exchange points around the world. I firmly believe that this is where the current model has gone awry. Worse, the current technology used at the exchange points could encourage abuse. What is to stop anyone connected to an exchange from simply dumping packets anonymously at the link level into the various inter-exchange providers' routers and getting free transit? Instead of negotiating with other providers for inter-exchange transit, I advocate that each attachment to an exchange negotiate with the exchange _operator_ for transit to other exchanges, and the exchange negotiate with inter-exchange providers for the aggregate. Separating the peering from transit provides greater clarity in agreements, with opportunity for better quality monitoring and control, while promoting greater redundancy in the Internet mesh, and greater competition in the inter-exchange transit market. ---- Until this happens, in the case in point, I would recommend that Wonderland (an org, not a net?) has no _transit_ peering to offer Sprint "in kind", as Sprint likely already has enough transit agreements to reach those same exchanges. Wonderland might have better spent its $5M+ per annum obtaining service from an existing trans-atlantic provider, or cooperating with another provider to join multiple links under existing transit agreements with Sprint and others, thereby reducing the trans-atlantic congestion. > From: Peter Galbavy <peter(a)wonderland.org> > > Besides, most of the major providers previously based the bulk of > > their peering 'requirements' on how many DS3s you had. Now most > > 'major' providers seem to have gone cold turkey. MCI, Sprint, and > > UUNET told me they won't peer with *anyone* new. > > But seriously, lets face it, DS3's are "cheap" and these people > want more customes no freeloaders. Like us, who are paying $5M+ a > year for a trans-atlantic DS3 and Sprint are very insistant that > we build a US network based on DS3s to peer with them, even with > the obvious fact that we have no US customers and have already paid > for a connection which in reality should be matched by the large > US carriers, rather than taking the piss once you have this > investment. I only mention Sprint, since the others you mention > are a tad more sensible, but still slow, while Sprint are in a > glacier. > 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

15 29

Re: Peering versus Transit
by Vadim Antonov 02 Oct '96

02 Oct '96

Sanjay Dani(maillists) <indus(a)professionals.com> wrote: > 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? How long did it take for OS vendors to come up with fixes? A week. And for how long telcos can't do anything about annoying calls? A hundred years. That only confirms my point. >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. Sorry, to me what you tell does not make sense. If you want to change things you need to come up with something which actually works and build it. Then you'll get all the stake and will be as interested in perpetuating status quo. (BTW, hey, Sprint, where's my stake?) >No, it is beginning to suck. Have you checked reliability >of the backbones lately? I started a company to _do_ something about it, ok? >Sigh.. old hats like you have a >hard time realizing that old models have to, and will, >change. I suspect that i'm younger. I simply have better tuned B.S. detectors. Reading Pravda helps to learn that things often aren't what they appear to be. >PS. This is my last email on this topic. Thank you very much. --vadim

3 2

Re: "Basic BGP configuration problem"
by Mark Borchers 01 Oct '96

01 Oct '96

> > > >(a) In the past various Sprint people have suggested multihoming to > >different SprintLink POPs as a solution to their refusal to hear > >specifics of their aggregates from peers. Well, with four POPs having > >problems in the same day, perhaps a better term would be multi-screwed. > > We are working on adjusting our multihoming policies such that > multihoming with Sprint will be a viable solution for customers. > Excellent news. Is it official? Would you be willing to furnish any further details at this time? Mark Borchers InfiNet Network Engineering NOC: (757) 624-2295 ext. 3007 Disclaimer: My opinions, while sound, may or may not reflect those of the guys who own this outfit.

2 1

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