- NANOG - lists.nanog.org

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

Re: Verio Decides what parts of the internet to drop
by Martin Cooper 05 Dec '99

05 Dec '99

Sean Doran <smd(a)clock.org> wrote: > It doesn't need to be equitable and fair to all; the fact is that > I consider my routing table slots to be a scarce resource, and > I will conserve that resource. Filtering is one approach; a step > towards your approach is relaxing filters for people willing to > pay me money to do so. This is the reality. The Internet is no longer an academic/ research network, and the sooner people accept that money talks (and bullsh*t walks) in a commercial context, the sooner an equitable mechanism for guaranteeing reachability to specific networks will become established. > People with hardcore reasons for using a too-long prefix will > probably be willing to pay a fee to an agent able to broker > cheapest-possible access to the routing slots in the networks > that are smart enough to sell them. I like this idea very much, because it makes a clear distinction between transit and reachability services. For instance, I might not want to use Sprint for transit, even though I want to have reachability to its customers. M.

1 0

Re: How to achieve application reliability
by Sean Donelan 05 Dec '99

05 Dec '99

On Sat, 04 December 1999, James Smith wrote: > Our only alternative is to eliminate every single-point failure with stuff > like high availability clustering, redundant feeds, battery backups, > nuclear reactors, physical separate sites on different planets, etc. :-) > (Pardon me, it's 2:00am and I'm getting punching) If you are using Microsoft products in your nuclear reactor, its not going to be very reliable. They aren't designed for that purpose. The tools exist to make very reliable network applications, but we can't force people to use them. So long as applications neglect to use the other information provided by the network, they are going to be vulnerable to single points of failure. Multiple A records exist for a reason. Even if you have high availability clustering, redundant feeds, battery backups, multi-homing, multi-sites; if you are depending on a single global network announcement there is nothing to prevent another ISP from announcing the same prefix with a shorter AS path length, and effectively blackholing your network. For people with ultra-high reliablility requirements, a /19 isn't the solution.

3 2

Net 24 (was Re: Verio Decides what parts of the internet to drop)
by Sean Donelan 05 Dec '99

05 Dec '99

On Sun, 05 December 1999, "Travis Pugh" wrote: > Absolutely. A standard would give ground rules, and would be something to > point to when you have to go to a client or customer and say "these are your > options." > > 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. I've always wondered, where is the RFC for network 24?

2 1