- Test - lists.nanog.org

Re: BBN Peering issues
by Sean M. Doran 14 Aug '98

14 Aug '98

| Private Exchange. It is a private exchange between SPRINT and Exodus. I see. And is it your assertion that Exodus does not pay for this peering, and that, moreover, the payment does not include transit services? One of the reasons I wonder, of course, is that it is pretty apparent from traceroutes that Sprint is not routing towards Exodus uniformly (see below, note different exits). Now why would Sprint do that on a settlement-free basis? I'm also curious about the assertion that you have no transit at all. Not even from Worldcom, maybe? I'm sure a public reassertion that there Exodus has NO paid-for transit from ANYONE would be interesting to everyone. Sean. ... 8 mlm1-core.hssi0-0.swip.net (130.244.194.145) 72.640 ms 79.000 ms 6.226 ms 9 198.67.142.137 (198.67.142.137) 7.338 ms 8.505 ms 7.945 ms 10 198.67.142.77 (198.67.142.77) 97.600 ms 96.253 ms 95.975 ms 11 144.232.5.157 (144.232.5.157) 96.336 ms 95.309 ms 95.644 ms 12 sl-bb22-stk-6-0.sprintlink.net (144.232.8.178) 148.940 ms 149.329 ms 149.583 ms 13 sl-bb23-stk-8-0.sprintlink.net (144.232.4.110) 149.705 ms 149.598 ms 150.050 ms 14 sl-bb10-sj-6-0.sprintlink.net (144.232.8.193) 150.645 ms 150.973 ms 151.126 ms 15 144.232.3.26 (144.232.3.26) 151.027 ms 154.151 ms 152.050 ms 16 sl-gw3-sj-4-0-0-155M.sprintlink.net (144.232.3.50) 151.511 ms 151.648 ms 151.472 ms 17 sl-exodus-5-0-T3.sprintlink.net (144.228.44.6) 156.324 ms 175.375 ms 158.908 ms 18 scca-01-f8-0-0.core.exodus.net (209.1.169.21) 163.182 ms 164.906 ms 168.566 ms 19 sc3-f0-1-0.exodus.net (209.1.169.14) 153.999 ms 155.180 ms 159.556 ms 20 santaclara-cisco75.exodus.net (207.82.200.75) 156.249 ms 231.899 ms 167.273 ms 21 209.1.231.2 (209.1.231.2) 170.068 ms 167.423 ms 169.606 ms 22 dixon.delong.sj.ca.us (192.159.10.1) 166.376 ms 173.019 ms 159.060 ms versus (towards what used to be cam.vio.com) 8 mlm1-core.hssi0-0.swip.net (130.244.194.145) 7.232 ms 6.630 ms 6.842 ms 9 198.67.142.137 (198.67.142.137) 7.145 ms 6.821 ms 6.979 ms 10 198.67.142.77 (198.67.142.77) 95.533 ms 96.899 ms 95.645 ms 11 144.232.5.157 (144.232.5.157) 96.509 ms 97.051 ms 95.386 ms 12 144.232.5.2 (144.232.5.2) 96.226 ms 95.588 ms 96.827 ms 13 sl-bb10-pen-3-0.sprintlink.net (144.232.8.217) 151.164 ms 151.616 ms 152.558 ms 14 sl-gw6-sea-0-0-0.sprintlink.net (144.232.6.66) 154.156 ms 153.385 ms 151.895 ms 15 sl-exodus-4-0-T3.sprintlink.net (144.224.113.26) 155.599 ms 151.810 ms 154.255 ms 16 scca-21-pos-0-0-0.core.exodus.net (209.185.9.185) 229.000 ms 178.663 ms 187.497 ms 17 scca-12-p1-0-0.core.exodus.net (209.185.9.29) 188.063 ms 183.958 ms 231.547 ms 18 sc1-f6-0-0.exodus.net (209.1.169.2) 527.453 ms 561.012 ms 503.870 ms 19 sc1-f6-0-0.exodus.net (209.1.169.2) 572.187 ms 633.966 ms 547.594 ms 20 * * * note Seattle versus San Jose. Interestingly: vio.com SOA NS.CARAVAN.com hostmaster.NS.CARAVAN.com NS.CARAVAN.COM seems to live behind bayarea.net, a BBN Planet customer. Sean. (again)

2 1

Re: BBN Peering issues
by Sean M. Doran 14 Aug '98

14 Aug '98

Sean Doran wrote: > [suspicious stuff] Oops, I forgot that I was on NANOG rather than, say, inet-access or somesuch. Please forgive my not-very-operational posting. I suppose I could have framed it as, "gee, is there a misconfiguration causing Sprint not to route uniformly towards Exodus? I see strange stuff." Please forgive me. Sean.

1 0

Re: BBN Peering issues
by owen＠DeLong.SJ.CA.US 14 Aug '98

14 Aug '98

> | I checked before doing so, and I checked once again in light of your > | allegation. And, according to Exodus, this *IS* a PX. > > If by PX you mean "public exchange point", then Sprint is > being unusually inconsistent with its naming, numbering, and > topology conventions. > Private Exchange. It is a private exchange between SPRINT and Exodus. > I'm curious as to which exchange point it is, if that in fact is > what PX means. > > Of course, whatever type of connection it is, I'm curious about > the fact that packets are always drawn towards this one connection. > Are there others? If so, are they down or something? > > Sean. (wondering why Sprint would give away a single free T3) >

1 0

Re: BBN Peering issues
by owen＠DeLong.SJ.CA.US 14 Aug '98

14 Aug '98

The following is purely my opinion and has nothing to do with my employer, although in this case, my employment situation prevents me from saying what I really think should be said. There are a lot of things that should be said here. However, due to NDAs and company policies, I am not allowed to say most of them. However, I will say this: 1. At least one provider being cut off is a peer. 2. BBN's customers will feel pain when that provider is cut off. 3. That provider's customers will also feel pain. 4. BBN has not worked with that provider to resolve this privately under NDA. 5. The NDA which was part of the soon-to-be former peering arrangement prohibits the disclosure of many details that would be important here. 6. I suspect it will take much more than an hour for BBN to resolve this once they have taken the actual step of disconnecting any of these providers. Owen > Well basically you need to think of it like this. If the providers that > are getting cut were actually "peers" of BBN, then BBN would feal the > pain, in fact they are not "peers". BBN can cut them off their network and > will not feal a thing. BBN customers will still be able to reach the cut > ISPs from their transit providers. If the providers were "peer" then when > BBN tried to cut them they both would feal the pain and BBN would most > likley turn it back up in a hour or so. > > > Rather than limit this issue to within the confines of private > > communication, I would like to see it carried out as a very vocal and > > lively public one. That way, the general public will be able to make an > > educated decision regarding whether or not to purchase transit from > > BBN/GTE, in light of this. > > Well, in the past this stuff was resolved under NDAs. If you don't see a > lot of ISPs talking then most likely BBN just had them sign a NDA and > worked something out.

2 1

Route filtering
by Kummer, Joerg {PYN~Basel} 14 Aug '98

14 Aug '98

Q:Is there a common denominator in terms of route filtering policies on different ISP transit networks ? I know of - http://www.sprintlink.net/filter.htm - A message in the NANOG mailing list archive http://www.cctec.com/maillists/nanog/historical/9701/msg00645.html indicates that AGIS used to do route filtering - excerpt: >Essentially, they will filter on /19 in the 206+. >They will filter on /24 for the 192-205 range. >Everything else (0-191) will be filtered in the /16. However, I did not see any confirmation of that on AGIS' web server. Q: Does anybody know more about (current/planned) AGIS' policies ? I did not find more info in the NANOG mailing list archive... The info on http://www.nanog.org/filter.html is somehow disappointing We are customer of several ISPs and are trying to get an overview of filtering policies. We plan to run around 10 Internet access lines with different ISPs internationally in the next year (current: 6). We use NAT, no BGP; we would prefer using our own addresses rather than ISP-provided addresses. ->> Q: what should we ask the ISPs to advertise for us to get the best routeability ? We have the following public addresses: 145.245.0.0/16 151.120.0.0/16 141.167.0.0/16 162.132.0.0/16 196.3.32.0/20 196.3.48.0/21 (there are some more Class Cs) Previous plan was: - access #1 : 145.245.0.0/16 - access #2 : 151.120.0.0/16 - access #3 : 141.167.0.0/16 - access #4 : 162.132.0.0/16 - access #5 : 145.245.160.0/19 ... more /19s because we thought /19 would be safer than /24. and then we found out about the Sprintlink filtering policies. Current plan: - access #1 : 145.245.0.0/16 - access #2 : 151.120.0.0/16 - access #3 : 141.167.0.0/16 - access #4 : 162.132.0.0/16 - access #5 : 196.3.32.0/24 - access #6 : 196.3.33.0/24 /24s in 196 range seem to be ok for AGIS and Sprintlink... regards joerg ______________________________________ F. Hoffmann-La Roche LTD Joerg Kummer, Dipl. El.Ing. ETH Pharma Informatics/Network Engineering CH-4070 Basel Switzerland Phone : +41 61 688 81 32 Fax : +41 61 688 16 72 mailto:joerg.kummer@roche.com ______________________________________

1 0

Re: BBN Peering issues
by Scott Huddle 14 Aug '98

14 Aug '98

At 07:49 AM 19980813 -0700, Robert Bowman wrote: >[...] Let's face the facts, BBN is only 1.85% of my traffic. By all accounts, >we estimate to be in the area of 10-30% of their traffic. Source of data? -scott

1 0

Re: BBN Peering issues
by owen＠DeLong.SJ.CA.US 14 Aug '98

14 Aug '98

Er, SPRINT's been doing this forever. Owen > Err, you are missing something. Obviously GTE knows this, that is the > point of killing the peering. The question is, is the method the GTE is > using to determine who should pay for transit accurate? Turn it around; > why shouldn't BBN pay Exodus to terminate the traffic for them? > > It just strikes me as odd that BBN is trying to [essentially] apply a > telecom-accepted/FCC-tarrifed method of termination payments to IP > packets. > > In effect, what BBN is doing is revolutionary. However, in my opinion, it > is sad to see essentially one of the founders of the Internet to bend the > Internet over and break out the Vaseline. However, that is just my > opinion. > > I wonder what Sprint and MCI's position is on this... Will we see them > doing that same? > > > > > As for any comments made by GTE/BBN regarding uneven traffic flow, I would > > sure as hell hope that is the case. Surely an HTTP 'GET' request consumes > > less bandwidth than the content spewed back. Then again, GTE/BBN may be > > too caught up to realize this, as they could very well be laughing their > > asses off all the way to the bank. > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > Atheism is a non-prophet organization. > I route, therefore I am. > Alex Rubenstein, alex(a)nac.net, KC2BUO, ISP/C Charter Member > Father of the Network and Head Bottle-Washer > Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 > Don't choose a spineless ISP! We have more backbone! http://www.nac.net > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > > >

1 0

NANOG Archives and Searching
by Eric Germann 14 Aug '98

14 Aug '98

Folks, Update on the NANOG Channel. We bust it up, HTMLize it and make it available as an IE Channel/NetCaster Channel as well as a content search tool. We updated the search engine this evening. Now you'll get more than 10 hits for a query and hopefully better performance. Go ahead and kick the tires. Let us know what you think. http://www.cctec.com/maillists/nanog Also, if you take the channel, Altavista Discovery is a great local search tool for indexing locally the fabulous technical content of this list :) Eric ========================================================================== Eric Germann CCTec ekgermann(a)cctec.com Van Wert, OH 45891 http://www.cctec.com Ph: 419 968 2640 Fax: 419 968 2641 Network Design, Connectivity & System Integration Services A Microsoft Solution Provider

1 0

Re: Rah for Patrick.
by Patrick W. Gilmore 14 Aug '98

14 Aug '98

At 06:25 PM 8/13/98 -0400, Jay R. Ashworth wrote: >Bravo, Patrick. _This_ is how a _man_ dies, to paraphrase Bob >Heinlein. > >This is a perfect counter-example to what I was bitching about with the >BBN fracas. Serve the customers, _then_ worry about the money. Thank you. Thank you very much. (And my favorite author, too. ;) I honestly expected to get flamed for that post (a bunch of "I told you so's"), but instead I got an overwhelming number of responses offering to help. I can't tell you how much I appreciate it. (Even if all of you wouldn't let me get any sleep. :) I am absolutely positive some of the help was offered because the vultures were circling, but some of them were honest offers of help. I think this shows that there is hope for the Internet community yet. In response to the money issue, it is easy for me, as a geek/engineer/operations guy to service the customer and ignore the cost, but I have learned the hard way that money _has_ to be made. I honestly believed (and still do) that if you service the customer right, and charge a fair price, the money will come. The problem is, there's a huge hump you have to get over in a startup, and servicing the customer well makes that hump bigger. Priori just couldn't make it over that hump. Thanx again for helping my customers. They really didn't deserve this. The efforts of people on this list and others probably kept some of them going "down with the ship". If any of you ever need any help with your routes, you got some free engineering coming. :) >Jay R. Ashworth jra(a)baylink.com TTFN, patrick ************************************************************** Patrick W. Gilmore voice: +1-650-482-2840 Director of Operations, CCIE #2983 fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "Tomorrow's Performance.... Today" **************************************************************

1 0

Re: What happened?
by joe＠vpop.net 14 Aug '98

14 Aug '98

Looks like InterNIC is cleaning house. Some 48,000 domains disappeared from the roots last night. -joe On Thu, 13 Aug 1998 18:03:26 -0400, "Steven J. Sobol" <sjsobol(a)nacs.net> wrote: >I'm getting bounces on my mailing lists from BELLATLANTIC.NET saying >"Host not found". > >After a little sleuthing, I've found that Bellatlantic.net is on hold!! > >I just got off the phone with their NOC. The guy there told me that >the problem will get fixed with tonight's update. He also told me that >apparently there were other domains that got put on hold by the InterNIC. > >I'd be very surprised if Bell Atlantic hadn't paid for their domains. I >have to assume this is an InterNIC issue. > >Anyone know what's up over there? ============================================================================= * NewsHub: Updated every 15 minutes/24 hours a day! * http://newshub.com/

3 2