North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Alternative to BGP-4 for multihoming?

  • From: Paul A Vixie
  • Date: Mon Mar 13 13:08:45 2000

> That doesn't solve one of the growing uses of such systems, which is
> so-called "geographical redundancy".  

That's a strawman error.  This isn't the kind of system you'd use for
geographical diversity.  That's a different problem and has a different
solution.  ifdefault solves the multihoming-without-bgp problem, and as
far as I know, ifdefault solves THAT problem better than any alternative
I've ever heard of.

> The ways to do this sort of thing are very limited.


> Whatever you do, you end up needing either "smart" (ie. sometimes lame)
> DNS servers or to originate BGP routes from multiple locations with the
> same IP address actually going to different machines depending on which
> route is used (which is lame even more often, although it is not as bad if
> one facility is normally an unused backup one, but that introduces lots of
> other issues).

Inconsistent-AS.  "Ick."

> If you have a better solution for this, I'm sure the world would love to
> hear it.  Yes, many or most or all of the current implementations do or
> can be configured to do some questionable things.  However, your solution
> doesn't address the whole "distributed" aspect of it.

There are three interesting aspects to the geographical diversity problem.

1. "site down."  In this event, the other site(s) can detect this by
periodic monitoring, and use RFC2136 DNS Dynamic Update to remove the
down site's A RR so that clients won't trip over it.  This requires
low TTL's and it's not elegant but it's better than nothing.  I've used
this for local redundant clusters like MX farms, too.

2. "network partition."  Both (all) mirror sites might be reachable by a
lot of clients but they can't reach each other and there are many clients
who can each only reach one of the mirrors rather than all reaching all.
Monitoring and RFC2136 won't help in this case unless there's an authoritative
nameserver colocated with each content server and you have to be willing
to pay the incoherence penalty which I'm not.

3. "worst case."  Even without a partition, there are some client/mirror
pairings which will fare considerably worse than others.  DNS round robin,
the default for BIND since 1994 or so, spreads the pain evenly but doesn't
make it stop.

The important technical thing to do all three of cases 1, 2, and 3 is to be
able to issue HTTP redirects to a better server, if there's a reason to think
that there is a better server for a given client.

Now, as some of you know, I cofounded a company several years ago to address
this problem (which as I said earlier is different from the multihoming-
without-BGP problem), but we changed direction before completing this work.
All I've got to say about THAT right now is that my biggest competitive
worry as CTO of Vayu Communications Inc. was a company called "rndnetworks"
and their product called "radware".  Nobody else, ESPECIALLY Cisco with their
Distributed Director, came anywhere close to solving the right problem in the
right way.  rndnetworks, on the other hand, caused me to lose sleep at night.

Therefore, when a customer of MFN/Abovenet asks for a recommendation, I tell
them to look into the rndnetworks products in this area.