freedman@netaxs.com (Avi Freedman) writes:
smd@clock.org (Sean Doran) writes:
P.S.: Curtis Villamizar had another interesting approach which involved pushing content far afield to machines with the same transport-layer (IP) addresses, relying upon closest-exit routing to connect one to the topologically-closest replication machine. Unfortunately, while this could be really
(this is something we've done a little of at work: we do have it in production use, and it's not so effective when there's asymmetric routing - which we have quite a bit for some European networks, eg two peerings with Ebone. Duplicating IP addresses definitely has its place, eg internal to a network for directing a bunch of RASs to a local version of a 'service' address.)
And Alec Peterson (now of Erols) has figured out an even arguably slicker way to do it.
This is a problem I've been musing over lately. The best way that I can see is to return suitable DNS answers to people. This avoids the route instability problems that Sean comments on, above: Client gets TCP session established. Routes change, their inbound route now reaches a different system which clearly doesn't know about the connection and *boom* goes the TCP session. Routes return to their previous situation but by this time it's too late. (Even worse is when the client connects *during* the route instability.) but with DNS you've still got to return a suitable answer. (You could route to your DNS server, but that doesn't address the asymmetry problems.) If the bulk of your data is from you to the client (web, euuw), then it's ok because you are in a position to decide what the best route back across your network is and pick the nearest/most appropriate server. Requests usually come from the client's nearest recursing/resolving DNS server and so that's just a SMOP to decide the best way back. Where you get really screwed up is having to support large numbers of IP addresses - good ol' HTTP/1.0 requests (it's that damn web, again). Using (n x number of "sites") isn't practical. Maybe the real operational issue is working out when we stop having to assign all these zillions of IP addresses for web servers. The marketting people don't want to make the change whilst their competitors aren't. James.
On Sat, Sep 20, 1997 at 03:17:14PM +0100, James R Grinter wrote:
This is a problem I've been musing over lately. The best way that I can see is to return suitable DNS answers to people. This avoids the route instability problems that Sean comments on, above:
Client gets TCP session established.
Routes change, their inbound route now reaches a different system which clearly doesn't know about the connection and *boom* goes the TCP session.
Routes return to their previous situation but by this time it's too late.
Agreed, that is a large problem. A DNS solution can be fairly easially implemented to accomplish this. With some more work, one could implement some more intelligent selection criteria on the DNS server (based on server load, availibility and the like).
but with DNS you've still got to return a suitable answer. (You could route to your DNS server, but that doesn't address the asymmetry problems.)
I'm pretty sure I've figured out a way to address this issue. Alec -- +------------------------------------+--------------------------------------+ |Alec Peterson - ahp@hilander.com | Erols Internet Services, INC. | |Network Engineer | Springfield, VA. | +------------------------------------+--------------------------------------+
Another flash from the past... In message <9709201517.ZM5712@renard.watching.org>, "James R Grinter" writes:
freedman@netaxs.com (Avi Freedman) writes:
smd@clock.org (Sean Doran) writes:
P.S.: Curtis Villamizar had another interesting approach which involved pushing content far afield to machines with the same transport-layer (IP) addresses, relying upon closest-exit routing to connect one to the topologically-closest replication machine. Unfortunately, while this could be really
This is a problem I've been musing over lately. The best way that I can see is to return suitable DNS answers to people. This avoids the route instability problems that Sean comments on, above:
Client gets TCP session established.
Routes change, their inbound route now reaches a different system which clearly doesn't know about the connection and *boom* goes the TCP session.
Routes return to their previous situation but by this time it's too late.
(Even worse is when the client connects *during* the route instability.)
Maybe this is unique to Europe? We put the prefix inside an aggregate. If routes to our /13 and /14 aggregates outside of our network are sloshing around that much that different provider interconnects are used mid TCP connection (often enough that it matters) there is clearly a serious problem in the adjacent provider and I can't see how they can stay in business (here in the US anyway). If this does occur some time in the middle of the few second long transfer (10s of seconds for a large slow transfer) then the client gets a RST and has to click again. If this is persistent, then someone in the path has a very serious problem. The only real problem you can run into is if someone is boneheaded enough to misconfigure their routing to do per prefix load splitting across WAN links or worse yet across providers. Again, such people don't deserve to stay in business (since *all* TCP traffic from their network will suck), but they do exist. The common newbie mistake is to configure per prefix load split among two default routes. Westnet used to do this many years ago. Some small network in Florida did this more recently. Curtis
In message <199712162008.PAA15876@brookfield.ans.net>, Curtis Villamizar writes :
The only real problem you can run into is if someone is boneheaded enough to misconfigure their routing to do per prefix load splitting
^^^^^^^^^^ per packet
across WAN links or worse yet across providers. Again, such people don't deserve to stay in business (since *all* TCP traffic from their network will suck), but they do exist. The common newbie mistake is to configure per prefix load split among two default routes. Westnet used to do this many years ago. Some small network in Florida did this more recently.
Curtis
Minor correction but big difference in meaning. Per prefix is fine. It is per packet load split that causes trouble., Curtis
Curtis et al.
Minor correction but big difference in meaning. Per prefix is fine. It is per packet load split that causes trouble.,
Excuse my ignorance here, but I presume you are refering to per packet load sharing where the the router A sends packets alternately to router B and router C, as opposed to "per packet" load sharing across two links between routers A & B. The former is obviously brain damaged, but I can't see the problem with the latter assuming the lines have similar delay characteristics so you don't get disordered packets etc., and in fact with the standard Cisco switching cache algorithms (and I presume most other vendors) this ends up nearly per prefix anyway. Or am I missing something horrendous here? -- Alex Bligh GX Networks (formerly Xara Networks)
participants (4)
-
Alec H. Peterson -
Alex Bligh -
Curtis Villamizar -
James R Grinter