multihoming without BGP

Dana Hudes dhudes at
Fri Jun 13 13:25:23 UTC 1997

Paul A Vixie wrote:
> But there's no guarantee that you need separate addresses per home
> page.
> If you don't count Lynx or Mosaic as part of your target audience,
> then you
> can depend on the "Host:" keyword sent in queries by *all* modern
> browsers.

I had to jump in here with a correction and clarification. We 
are using Netscape Enterprise Server 2.0. The 'software virtual
server' feature doesn't work with any version of Netscape Navigator
up to and including Communicator Preview 5. The server sees a
HTTP 1.0 not HTTP 1.1 request.  In my logs I do see some webcrawlers
sending HTTP 1.1 so it isn't completely a server issue. 
Netscape Enterprise 3.0 is coming out RSN but I don't know that it will
be any better. If it is I'll speak up here.

The result is we are, on Solaris 2.5.1, burning an IP address for each
website on the host system rather than using CNAME and software virtual
servers. It also results in a server process running for each website.

As for Lynx, one cannot cavalierly dismiss it. A current Lynx has
to be supported for at least the blind/visually impaired users.
I know one personally.

> But if you do need to support old Lynx and Mosaic, you can assign all
> 100
> PA's as virtual interfaces on a single "ifdefault" machine.
> Remember that the machine with the "ifdefault" hack just runs a squid
> cache
> in accelerator mode.  Your web servers are all highly custom and
> probably
> very fragile, you should leave them alone.  The "ifdefault" box is
> just a
> front end -- it becomes, or adds a hop before, your exit gateway.
> > 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.
> Indeed you are, sir!  The interfaces that matter are the uplink ones,
> not
> the downlink ones.  A SYN packet comes in on some interface, and what
> "ifdefault" is trying to do is make sure your SYN-ACK goes out to the
> exit
> gateway that's reachable via that same interface.  The local end of
> the
> TCP connection is bound to a local socket, we're just trying to get
> the
> "remote" end of each TCP connection bound to a reasonable upstream
> gateway
> rather than having to use a single system-wide default or run full
> BGP.
> > 4) It puts the onus for fail-over on the DNS server, which means one
> > is going to be using very short TTL.
> People who multihome do that anyway.
> > 5) Unless (#1), (#4) implies that fail-over will be manual.  Is your
> > Emacs ready to rock and roll on 50 zone files?
> No it isn't but there are four or five packages in the /contrib subdir
> of
> BIND that can robohack your zone files to this end.
> > 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.
> But, but... I *DID* it.  I didn't just write the code (actually I
> didn't
> write much of the code, Ted Lemon wrote most of it) -- I ran this
> stuff on
> a high volume pornography site for three months and the credit card
> transaction dollar-o-meter was never as busy or as steady, before or
> since.
> I know it sounds hacky.  But so did ethernet's exponential backoff.
> The
> thing that makes this hack work is counter intuitive but the success
> is
> measurable.
> That's two folks who have come out today and said "well that's no damn
> good"
> without trying it.  I'm surprised, NANOG members usually have a more
> positive
> attitude.

More information about the NANOG mailing list