Geographic routing hack

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

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. :slight_smile:

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. :slight_smile:

                                -Bill

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

"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