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.