Some weeks ago I noticed that 167.216.128.247/32 (www.digisle.net) appears to reach web servers located in physically different places broadly dependent on where you see it from. I presume this is done by advertising the same prefix from border routers which are in seperate IGP domains or something (confederations maybe?), but I wonder what people's views on the concept are, since it could potentially be quite confusing in certain circumstances (e.g. debugging routing problems) ? Superficially it seems like a 'cool hack' for geographic content-distribution (which is what Digital Island do), but up until now I've always seen this sort of thing done by exploiting NS record sorting order properties with the kludge of different A records in the various zonefiles, and I wondered if doing it with routing policy in this way is strictly RFC compliant (or for that matter if anyone cares if it isn't) ? M.
Martin Cooper wrote:
Some weeks ago I noticed that 167.216.128.247/32 (www.digisle.net) appears to reach web servers located in physically different places broadly dependent on where you see it from.
I presume this is done by advertising the same prefix from border routers which are in seperate IGP domains or something (confederations maybe?), but I wonder what people's views on the concept are, since it could potentially be quite confusing in certain circumstances (e.g. debugging routing problems) ?
Superficially it seems like a 'cool hack' for geographic content-distribution (which is what Digital Island do), but up until now I've always seen this sort of thing done by exploiting NS record sorting order properties with the kludge of different A records in the various zonefiles, and I wondered if doing it with routing policy in this way is strictly RFC compliant (or for that matter if anyone cares if it isn't) ?
This certainly isn't a new idea, although it is generally considered poor form to do this with stateful protocols (such as TCP), since the 'closest' instance of the address can change mid-session, and thus cause a reset. Several presentations on using this hack in various situations have been made at NANOG. See http://www.hilander.com/nanog11 for one such presentation. Alec -- Alec H. Peterson - ahp@hilander.com Staff Scientist CenterGate Research Group - http://www.centergate.com "Technology so advanced, even _we_ don't understand it!"
Note that the particular case in question could also be an implementation of Cisco's DistributedDirector product, which responds to DNS requests with the closest server to the querying machine. /cah On Mon, Aug 02, 1999 at 02:59:05PM -0600, Alec H. Peterson wrote: ==> ==>Martin Cooper wrote: ==>> ==>> Some weeks ago I noticed that 167.216.128.247/32 ==>> (www.digisle.net) appears to reach web servers ==>> located in physically different places broadly ==>> dependent on where you see it from. ==>> ==>> I presume this is done by advertising the same ==>> prefix from border routers which are in seperate ==>> IGP domains or something (confederations maybe?), ==>> but I wonder what people's views on the concept are, ==>> since it could potentially be quite confusing in ==>> certain circumstances (e.g. debugging routing ==>> problems) ? ==>> ==>> Superficially it seems like a 'cool hack' for ==>> geographic content-distribution (which is what ==>> Digital Island do), but up until now I've always ==>> seen this sort of thing done by exploiting NS ==>> record sorting order properties with the kludge ==>> of different A records in the various zonefiles, ==>> and I wondered if doing it with routing policy in ==>> this way is strictly RFC compliant (or for that ==>> matter if anyone cares if it isn't) ? ==> ==>This certainly isn't a new idea, although it is generally considered poor ==>form to do this with stateful protocols (such as TCP), since the 'closest' ==>instance of the address can change mid-session, and thus cause a reset. ==> ==>Several presentations on using this hack in various situations have been ==>made at NANOG. See http://www.hilander.com/nanog11 for one such ==>presentation. ==> ==>Alec ==> ==>-- ==>Alec H. Peterson - ahp@hilander.com ==>Staff Scientist ==>CenterGate Research Group - http://www.centergate.com ==>"Technology so advanced, even _we_ don't understand it!"
"Craig A. Huegen" wrote:
Note that the particular case in question could also be an implementation of Cisco's DistributedDirector product, which responds to DNS requests with the closest server to the querying machine.
Doubtful, since he states that requests going to a specific IP address are reaching geographically diverse web servers. Alec -- Alec H. Peterson - ahp@hilander.com Staff Scientist CenterGate Research Group - http://www.centergate.com "Technology so advanced, even _we_ don't understand it!"
> Some weeks ago I noticed that 167.216.128.247/32 > (www.digisle.net) appears to reach web servers > located in physically different places broadly > dependent on where you see it from. > > I presume this is done by advertising the same > prefix from border routers which are in seperate > IGP domains or something Don't need to do anything complicated, actually... Just make sure that your IGP hop-count represents your internal costs relatively well, when your border router picks up an inbound packet, it'll forward it to the topologically closest server. > but I wonder what people's views on the concept are, > since it could potentially be quite confusing in > certain circumstances (e.g. debugging routing > problems) ? Nah, the per-logical-server shared addresses are virtual-hosted on machines that have per-physical-server unique addresses, which you switch to for everything after the initial page/connection/whatever. Else you can't do any stateful connections with clients, since the connection with the client might get re-routed to a different server after it was established. So your debugging is always on the per-physical-server unique addresses, just like it is now. > Superficially it seems like a 'cool hack' for > geographic content-distribution Well, I wouldn't call it a hack, it's just straight-forward routing. And it's really important to realize that it's not geographic distribution, which is useless, but _topological_ load-balancing, which actually saves money and latency. > but up until now I've always > seen this sort of thing done by exploiting NS > record sorting order properties with the kludge > of different A records in the various zonefiles, Maybe by folks who haven't thought about the issue, or aren't trying to distribute across servers in multiple locations. But that won't actually do any geographic or topological load-balancing, since you have no way of knowing which DNS server somebody's going to reach, without applying this same trick to your DNS servers. Which I recall suggesting wrt the roots, back at the Montreal IEPG, and getting roundly boo'ed. :-) Anyway, doing this type of topological load balancing has been reasonably common, to the best of my knowledge, for at least three years. I know the first time we tried it was in 1996, on a project for Oracle's corporate web site. > and I wondered if doing it with routing policy in > this way is strictly RFC compliant (or for that > matter if anyone cares if it isn't) ? I sure _hope_ nobody's been drafting RFCs that tell me how I can route my internal traffic. :-) -Bill
participants (4)
-
Alec H. Peterson -
Bill Woodcock -
Craig A. Huegen -
Martin Cooper