|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Alternative to BGP-4 for multihoming?
> 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. Yes. > 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.
|