: BGP isn't better. You don't need BGP for multihoming. My SF NANOG talk
: was on exactly this topic. If you get a little bit of PA space from each
: provider, and run a multihomed server (or a whole pile of them) with the
: "interface default" mods we made available, you don't need BGP at all.
You are convinced that ifdefault is production quality? Your slides don't
give me the feeling of absolute confidence. Is anyone using it in a
production environment?
At the time of the SF NANOG, it was running in production. That customer has
switched providers for various unrelated reasons and is no longer multihomed.
But it did run a 100Khit/day web server for about three months without trouble.
>From an operational standpoint BGP is what works, now.
Also, your solution only works on servers running BSD/OS 2.1. What about
other platforms where the source code is not available (How am I going to
magically convert my SGI/NT boxes into BSD/OS 2.1?) What about other
clients from our end who still need redundant internet connectivity?
I have received reports that this code ported trivially to NetBSD and to
FreeBSD. (In fact it was originally developed on NetBSD.) I don't know how
to get code patches made to SGI or NT, but one assumes that you'd start by
telling your sales rep that you would buy N more boxes next year if they add
this feature. But that assumes you have a strong strategic relationship with
your system vendor. If you don't, then you're right that you're not a
candidate for this. On the other hand you could probably put up a FreeBSD
or NetBSD or BSD/OS box and try this out, and maybe switch system vendors.
DNS round robin is also a crude way to balance loads over network
interfaces compared to path selection.
DNS round robin was never intended to solve the www.FOO.com problem.
I am extremely skeptical that ifdefault is ready for prime time.
You are welcome to that view, ignorant and reality-detached though it is.
I think that if you actually try it out, and then report back, I will listen
with a lot more interest to your comments as to its readiness for prime time.
Of course, the downsides of using the interface-default hack are:
1) it does not guarantee shortest path for the packets (unless someone
has hacked together an lbnamed version that talks to gated and sees
which interface has a shorter path to customer <x> based on number of
AS hops before it answers the DNS query).
2) It uses a separate address for each interface (not important for a
single box, but a room full of boxes, say, 50 of them, 3-way homed at
a single site... hmm, that's 100 extra addresses you didn't want to
use). I suspect that upstream providers will not be thrilled to hand
out more address space if they discover it is being put to such
inefficient use.
3) I have not looked at the code, but if it is on a per-interface
basis, based on the addresses in the packets, that would seem to
suggest that it might not like BSDI 3.0's virtual host scheme (adding
IP addresses to the loopback port and then proxy-arping them onto the
wire). If this is correct, that would mean you would have to use a
different physical machine for each customer. Of course, on this
point I'm purely speculating.
4) It puts the onus for fail-over on the DNS server, which means one
is going to be using very short TTL.
5) Unless (#1), (#4) implies that fail-over will be manual. Is your
Emacs ready to rock and roll on 50 zone files?
I admire Paul's hack; it is spiffy for what it is, but I would hardly
promulgate it as an advised way to multihome without using BGP.
---Rob
Suppose you run two nameds. One with an addr on provider A, and one
with an addr on provider B. Each one responds with only the address
from its respective provider. Suppose A goes down. Then (most) new
folks won't be able to reach your A name server and so won't even be
trying your A address. (You have to assume here that your site isn't
popular enough to be in most ISPs caches already... because if it were
that popular you probably can get PI space anyhow.)
This violates the rules of DNS however. Those nameservers can't claim
to be authoritative and yet yield different answers. (And Paul is
probably disappointed I'm suggesting it!)
But going to this extreme is probably not even necessary any longer.
MSIE 3 will skip past dead addresses and try all A records. Netscape
communicator is supposed to do that (I haven't tested). And Squid will
try all addresses. That leaves navigator 3.0. Give it six months.
Dean