[Date Next]
[Thread Prev]
[Thread Next]
Re: Routing Question-- Maybe a hack
- To: not-rr@town.hall.org
- Subject: Re: Routing Question-- Maybe a hack
- From: "Jeff Young" <young@mci.net>
- Date: Wed, 13 Dec 1995 10:54:41 -0500
- In-reply-to: Your message of "Wed, 13 Dec 1995 10:24:16 EST." <199512131524.KAA13334@excelsior.reston.mci.net>
- Reply-To: not-rr@town.hall.org
- Sender: owner-not-rr@town.hall.org
the most likely cause of this would be a failure of one of the "like-addressed" machines, right? i'll wager that the outcome of a second machine wedging itself into a tcp connection (which would in most cases time out anyway) is no worse than what happens when the first machine disappears: the connection is reset. at least at this point, the user can hit the "reload" button or take some other action. because the second "like-addressed" machine is now available albeit at a higher metric.
so if your igp is flapping the routes/metrics to one or more of the "like-addressed" machines, things break. but they break only for those hosts in close proximity to the flapping route or changing metric.
Jeff Young young@mci.net
> To: not-rr@town.hall.org
> Subject: Re: Routing Question-- Maybe a hack
> Date: Wed, 13 Dec 1995 10:24:16 -0500
> From: "John W. Stewart III" <jstewart@mci.net>
>
> i brought up dns as a way of describing a service that would
> most definitely work well using jack's proposal. the is as
> opposed to http which might not work so well...
>
> the point is that this host route approach may work ok for
> connectionless, single-packet-request, single-packet-response
> services like dns queries. however, the approach might not
> work so well for connection-oriented multi-packet services
> like http. if routing changes in some way, then one of the
> http servers could enter into a tcp connection "in the middle
> of a conversation" and the client would be messed up...
>
> /jws
>
> > Sorry to be dense about this. We don't have to do anything
> > to DNS (e.g., BIND)? DNS does the right thing because routes are pointing
> > you to the right place? I can live with the right answer for hosts
> > directly on the railroad ... we can worry about the other sites
> > later.
> >
> > Carl
> >
> > According to John W. Stewart III:
> > >
> > >
> > > the addressing issues are key here
> > >
> > > this idea is a slight modification to an idea we've had for
> > > sharing the load of dns queries. in that case, however, the
> > > address of the name servers is within an aggregate that we
> > > announce .. so the whole internet comes to us, and then we
> > > use the host route within our backbone to optimize routing.
> > > if you've got servers off of your backbone, then it gets
> > > harder .. and you probably don't want to inject /32s into
> > > the global routing mesh
> > >
> > > a difference between dns and http is that dns is a single-
> > > query, connectionless service while http is longer-lived and
> > > connection-oriented. the life of an http connection *is*
> > > relatively short, but since it's more than one packet, in an
> > > event where a server goes down, clients will not see a
> > > graceful transition
> > >
> > > /jws
> > >
> > > > Wow! Let me see if I get this. What happens when a Japanese user
> > > > types http://www.park.org/ is:
> > > >
> > > > 1) www.park.org resolves to 5.6.7.8
> > > > 2) the packet goes to the railroad
> > > > 3) the "best" route to 5.6.7.8 in this case
> > > > is right back into the Japanese infrastructure
> > > >
> > > > If a user in Australia does the same thing, they get pointed to the
> > > > edge of the railroad (Mae-East in this case) and the "best route"
> > > > to 5.6.7.8 in this case is town.hall.org.
> > > >
> > > > I think this works for hosts directly on the railroad. What if
> > > > we have a central park server already in Australia, but not on
> > > > the railroad? How does that work?
> > > >
> > > > Carl
> > > >
> > > > According to Jack Waters:
> > > > >
> > > > > Carl
> > > > >
> > > > > I thought about this a bit last night and wanted to throw out a possi
> ble
> > > > > solution. The real goal I think you have is to make web client use th
> e
> > > > > closest web server.
> > > > >
> > > > > Here's my proposal:
> > > > >
> > > > > On each worlds fair server, let's say two for now (call it
> > > > > www.worldsfair.org for now):
> > > > >
> > > > > Create two interfaces for
> > > > >
> > > > > 1) Machine1
> > > > > le0 --> 1.2.3.4 (the real address of the machine)
> > > > > vif0 --> 5.6.7.8 (the pseudo address of www.worldsfair.org)
> > > > > 2) Machine2
> > > > > le0 --> 9.0.1.2 (the real address of the machine)
> > > > > vif0 --> 5.6.7.8 (the pseudo address of www.worldsfair.org)
> > > > >
> > > > > In the DNS www.worldsfair.org would only map to 5.6.7.8
> > > > >
> > > > > Then in the railroad infrastructure, import the host route 5.6.7.8 in
> to th
> > > e
> > > > > IGP (presumably OSPF or ISIS) pointing to both machine1[2].
> > > > >
> > > > > With this, when a client resolves www.worldsfair.org, it will go to 5
> .6.7.
> > > 8
> > > > > which will be routed, once inside the railroad, to the *closest* 5.6.
> 7.8 a
> > > nd
> > > > > get to the closest (IGP-wise) web server.
> > > > >
> > > > The trick will be to make the host route dynamic enough to remove its
> > > > > announcement for one of the machines[1 || 2] when that machine (or mo
> re
> > > > > specifically httpd) is not available. This should be pretty easy to d
> o if
> > > > > you use gated on machine1[2]. A quick hack to remove the route from g
> ated
> > > > > could be implemented to "watch" httpd and remove the announcement. Of
> > > > > course, gated will automatically remove the announcement if the machi
> ne
> > > > > becomes diconnected or dies.
> > > > >
> > > > > This, I think, should accomplish what you are trying to do. Let me kn
> ow wh
> > > at
> > > > > you think.
> > > > >
> > > > > Thanks
> > > > > Jack
> > > > >
> > > > >
> > > > >
> > > > > Note the second interface is a
> > > > >
> > > > > At 11:13 AM 12/12/95 -0500, Carl Malamud [IMS] wrote:
> > > > > >> if you're talking about multiple servers in different
> > > > > >> locations with clients routing to them based on proximity
> > > > > >> that's very different. perhaps possible.
> > > > > >
> > > > > >You bet, that is what we want to do. Different answers for
> > > > > >different locations. I'll call Kim Claffy and see what she
> > > > > >has to contribute.
> > > > > >
> > > > > >How hard is it to manually define some border AS's (e.g., the
> > > > > >ones at the "edge" of Japan) and then ask the question: is this
> > > > > >IP address "beyond" the border AS's? From a host, what would
> > > > > >I do to ask that question?
> > > > > >
> > > > > >Carl
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
[Date Prev]
[Date Next]
[Thread Prev]
[Thread Next]