- Test - lists.nanog.org

multi-homing
by Dana Hudes 06 Dec '99

06 Dec '99

The pressure is on to use co-location service only from Big Players. Indeed, remember the big fight over Exodus peering arrangements? Someone (GTE?) decided that Exodus should pay them for transit and pulled peering. since no other large network pulled such stunt the result was that GTE customers were inconvenienced more than Exodus customers. The message is loud and clear. If you want your server farm to have good access, put it in a good co-location facility in the US run by (or connect your co-located equipment to) a very large provider who has good redundancy not only of their network as a whole but of their colo facility (a co-lo facility with only one WAN circuit does not have good redundancy even if the LAN is exceedingly good and fault-tolerant etc.). Outside the US, the filtering of long prefixes doesn't seem to be as much of a problem -- but nobody wants to see an announcement from their peer of a /16 broken into individual /24 all with the same next hop. Even when router memory and CPU capacity are not near limits, it is annoying. (sorry that the previous version went out in MIME format, I had replied to someone else's MIME formatted message). Dana

6 7

More sites to shutdown over new year's
by Sean Donelan 06 Dec '99

06 Dec '99

Yet more sites are planning to shutdown part or all of their networks, or disconnect the networks over the New Year's weekend. http://www.zdnet.com/intweek/stories/news/0,4164,2404384,00.html

1 0

Re: Mars lander (Re: How to achieve application reliability)
by brett watson 06 Dec '99

06 Dec '99

> How can you be so sure the hosts you were hitting with pings and > traceroutes were the same hosts? It's quite possible smoke and mirrors > were in between (smoke: web directors answering the pings... mirrors: > anycast addressing with policy routing). > > It's getting pretty wierd to debug IP these days... sure, i was admittedly making some blind assumptions. i didn't check any dns entries. then again we've all seen a few other "media events" fall over and die because folks haven't done the server/os/app side very well. -brett

1 0

Re: Mars lander (Re: How to achieve application reliability)
by Sean Donelan 06 Dec '99

06 Dec '99

On Sun, 05 December 1999, Nathan wrote: > Here is a great link explaining in detail the design and architecture of > the web accelerators on the net that were designed to support the load that > marspolarlander.com was supposed to generate.......although they have no > feed to push....it was impressive. > > http://www.netapp.com/tech_library/3071.html Yes, it was very impressive. I was hoping they would be successfull, because in a few weeks the next event will also require some interesting web site hosting. If it had worked, then the people who follow could just copy it. Even without a feed to push, the sites were unresponsive for parts of the day. http://www.newsbytes.com/pubNews/99/140268.html I'm very concerned we still haven't proven we know how to handle big event sites on the Internet.

3 2

Verio Decides what parts of the internet to drop
by doug＠safeport.com 06 Dec '99

06 Dec '99

IMHOTS Apparently for their convenience Verio has decided what parts of the Internet I can get to. With no notification. This was (eventually) posted to the BSDI mailing list when some of us were cut from access to the site we need to maintain our OS. For this I pay them. Doug Denault -------------- "John A." wrote: > > Heres a little more light on the subject. This is a message we recieved > from Verio explaining why anybody that goes through their network can't > get to bsdi. Because of this message, we are considering moving to a > different backbone. > > John A. > Provide.Net > Ypsilanti, MI > > >Date: Wed, 1 Dec 1999 01:15:07 +0000 > >From: Wade Moeller <wmoeller(a)noc.verio.net> > >To: smike(a)provide.net > >Cc: Case Updates <updates(a)vanwebserv.verio.net> > >Subject: [v-666704] Routing to BSDI.com > >X-Mailer: Mutt 0.95.1i > >X-Disclaimer: My opinions are mine, and not those of anyone else. > > > >Hello there. I am writing in regards to case #666704. You have > >opened this ticket complaining that you cannot reach bsdi.com. I am > >going to explain to you exactly what is happening and who needs to > >fix this. > > > >What is happening: > > Cray Computer Corp. split up their Class B into two /17 networks > >and gave routing control over those IPs to 2 different ISPs. Below > >are the routes being announced and the IP delegation from ARIN. > > > >First half of the Class B: > >BGP routing table entry for 134.195.0.0/17, version 15625171 > >Paths: (7 available, best #3) > > Advertised to peer-groups: > > internal pop rr-pop > > 1 3404 > > 165.117.56.98 (metric 33) from 165.117.1.145 (165.117.1.145) > > Origin incomplete, metric 4294967294, localpref 100, valid, > >internal > > Community: 1:1000 2548:183 2548:666 3706:153 > > > >Second half of the Class B: > >BGP routing table entry for 134.195.128.0/17, version 15624883 > >Paths: (19 available, best #13) > > Advertised to peer-groups: > > internal pop rr-pop > > 1 10487 > > 165.117.56.98 (metric 33) from 165.117.1.145 (165.117.1.145) > > Origin IGP, metric 4294967294, localpref 100, valid, internal > > Community: 1:1000 2548:183 2548:666 3706:153 > > > >Arin Delegation: > >Cray Computer Corporation (NET-CRAYCOS) > > P.O. Box 17500 > > Colorado Springs, CO 80935 > > > > Netname: CRAYCOS > > Netnumber: 134.195.0.0 > > > >Verio has a BGP policy where we limit what announcements we will > >listen to when they are advertised to use. This is keep the size of > >the routing table in check. The policy is as follows: > > > >0.0.0.0-127.255.255.255 Verio will listen to no announcements less > >then a /20 > >128.0.0.0-191.255.255.255 Verio will listen to no announcement less > >then a /16 > >192.0.0.0-223.255.255.255 Verio will listen to no announcement less > >then a /24. > > > >We have modeled this after the allocation boundaries in use by ARIN, > >IE ARIN will not give out a /17 in the 128.0.0.0-191.255.255.255 IP > >space. > > > >Therefore we are ignoring the two /17 announcements since we will only > >accept them as a single /16 announcement. > > > >This is the current Verio policy and this is the future Verio policy. > >There has been much discussion of this policy and it is still in place > >so it will not be changing in the foreseeable future. > > > >Who needs to fix this: > > As you can see the routes for each net-block is going through > >BBNPlanet (AS1) and then onto Colorado Internet Cooperative > >Association (AS3404) and Simple Network Communications, Inc. > >(AS10487). Those last two companies need to consolidate their > >announcements so that they are able to announce the entire /16. > >Alternatively they may ask BBNPlanet to aggregate the the /17s into > >one /16 which we will listen to. These are the only 2 actions that > >will let Verio's routers see those networks and route to them. > > > >If you have any further questions please do not hesitate to ask. > > > >-- > >Wade Moeller Network Tech I > >wmoeller(a)noc.verio.net (800)551-1630 > >Here an OS, there an OS....I need more computers. -- Douglas Denault support(a)safeport.com Voice: 301-469-8766 Fax: 301-469-0601

17 34

Re: Verio Decides what parts of the internet to drop
by Alex P. Rudnev 06 Dec '99

06 Dec '99

I mean that, if there is rule no allow some prefixes, all ISP should follow this rule. All! It's the issue. Else, we have just what we have tiday - everything work, but some stohastic filtering add a lot of unpredicted behaviour into the routing. I know a lot of such specifics (class B / 24, see 144.206.* for example) which (1) work OK, (2) surely some part of the routing follow 144.206/16, but at some point /24 speciics appear and routing became just as it should be). Today, the only 2 rules are: (1) some blocks (195.* etc) can't use more than /20 (npot /19) specifics; it began a few years ago due to the Sprint policy; (2) Less than /24 announces are not mainly allowed. If someone want more (and no doubt many ISP want), let's they follow some negotiated rulesa and ask another to follow this rules, too. Alex R (now not ISP network engeneer, through). On Sun, 5 Dec 1999, Yakov Rekhter wrote: > Date: Sun, 05 Dec 1999 05:53:57 -0800 > From: Yakov Rekhter <yakov(a)cisco.com> > To: Alex P. Rudnev <alex(a)virgin.relcom.eu.net> > Cc: nanog(a)merit.edu > Subject: Re: Verio Decides what parts of the internet to drop > > Alex, > > > may be - but it shoudl be written in the RFC, not in the VERIO's policy. The > > global policy must be THE SAME over the global Internet. > > What would make such a policy "THE SAME over the global Internet" ? > > Yakov. > Aleksei Roudnev, (+1 415) 585-3489 /San Francisco CA/

1 0

MEDIA EVENT-Dec 3 1999 www.marspolarlander.org
by Sean Donelan 06 Dec '99

06 Dec '99

On Friday December 3, 1999 at 4:14pm EST the Mars Polar Lander crashes into Mars. NASA and UCLA plan to make a live feed of the data download available on the web site www.marspolarlander.org They are expecting 250 million visits tomorrow. Cable & Wireless appears to be the primary backbone for the event.

3 2

Re: Net 24 (was Re: Verio Decides what parts of the internet to drop)
by brandon＠rd.bbc.co.uk 06 Dec '99

06 Dec '99

> > Instead, we are looking at a routing system where some traffic will flow on > > some networks if it is a longer subnet of a class B address, and will not > > flow on some networks based on arbitrary filter decisions. Some kind of RFC > > based consistency would be great. ... > when this idea came up > a few years back, there was serious concern raised > about collusion and restraint of trade. And selective routability isn't? brandon

2 1

Re: multi-homing
by Sean Donelan 05 Dec '99

05 Dec '99

On Sun, 05 December 1999, Alex Rubenstein wrote: > I'd disagree whole-heartedly (partly because I am not a huge, national > tier-1). > > Wouldn't you rather connect your equipment to a smaller company, that is > potentially more flexible, has more clueful people, has better pricing, > and is multihomed to maybe 3 or 6 or 9 backbones? The top three Internet data centers I've seen are all inhouse designed and operated. Unfortunately, the worst three Internet data centers I've seen also were home-grown. Carrier operated co-location facilities have advantages and some disadvantages. The marketplace is driving them all to meet about the same level of quality, so there is less of a surprise factor associated with them. The Insurance Services Organization has already prepared underwriting reports on them, so its easy to get insurance. Other tenents have already done their own vetting of the operation. But, like every industry, there will always be some room for the specialty shops which offer a level of personal service large players can't justify. I find it interesting after the 1980's and the era of "personal computers" once again the computing industry is back to the timesharing model of large data centers. ASPs?

2 1

Mars lander (Re: How to achieve application reliability)
by Sean Donelan 05 Dec '99

05 Dec '99

On Sun, 05 December 1999, James Smith wrote: > First, Unix is the only way to go. :) Second, what do you > suggest instead of a /19? I was watching the mars polar lander web set up, in the hope the web would be able to handle the load. Unfortunately, they haven't gotten any data for downloading, so we can't tell how well the web sites would have held up. On Friday, at landing time, the marslander.jpl.nasa.gov redirector site seemed to work well. On the other hand, I did get a few error pages from the www.marspolarlander.com setup. I don't know if the loads on each site were equivalent.

1 0