More With Less: Multihoming Your Web Serve

Many web servers sit idle under normal usage. Take advantage of this by multihoming your server, and serve multiple IP addresses.

Liem Bahneman and Paul Forgey

R ecently, with so many web servers going into operation, the need for "multi-homing" or "virtual" has surfaced. Serving multiple hostnames for a single server has always been possible with domain name aliases. For example, one single system could host as well as but with old-style aliasing, these two hostnames were mapped to a single IP address, and thus, connections to these two hosts would yield the same web pages.
The problem with this is that different IP addresses will serve the same set of pages--not a viable solution if the president of wants a distinctive set of pages, unrelated to the rest of the physical site.
More recently, operating systems that can handle more than one interface per machine have appeared (some have always been around). The multiple interfaces can be physical, such as multiple network interface cards (Ethernet boards), or at the software level with "dummy" interfaces and IP aliasing. The most cost-effective, of course, would be the software variety. Instead of wasting money and precious bus slots on Ethernet boards, you can have as many dummy interfaces as you need.
These multiple interfaces allow you to map a single hostname to a single IP address. With the proper web server software, you are then able to serve specific documents to each requested IP addresses. In our example, could yield an entirely different file than yet exist on the same physical system and in most cases, the same web server daemon.
One of the most popular web servers for doing multiple, virtual hostnames is the Apache web server software. Apache is based on NCSA's httpd version 1.3. Apache was originally offered as a set of patches for NCSA's source, but eventually became its own entity. The name "Apache" is derived from the slogan "Apache is 'A PAtCHy' server". Being a flavor of NCSA's original httpd, the Apache httpd is a drop-in replacement.
The Apache server has extensions to recognize the hostname or IP of the requested server and page, and check if it is to offer a different of documents for that specific host. More technically, each virtual web server has its own DocumentRoot.
Here's a look at part of httpd.conf for Apache (version 0.6.5):
DocumentRoot /usr/etc/httpd/htdocs/sprockets
ErrorLog /usr/etc/httpd/logs/error_log
TransferLog /usr/etc/httpd/logs/access_log
DocumentRoot /usr/etc/httpd/htdocs/widgets
ErrorLog /usr/etc/httpd/logs/error_log
TransferLog /usr/etc/httpd/logs/access_log

These entries specify that connections to the specified VirtualHost will use the appropriate DocumentRoot for those requests. Instead of using the default DocumentRoot /usr/etc/httpd/htdocs, it will use a subdirectory in that path and chroot to it. Therefore, a request to will request the absolute file /usr/etc/httpd/htdocs/widgets/welcome.html.
So how is the actual task of multihoming done? If you have multiple interface cards in your system already, the web server needs to know only what extra hostnames or IP addresses to acknowledge. These hostnames can be either entries in the /etc/hosts file or DNS host table entries. For example, in /etc/hosts you may have the entries:
These would let httpd know the names associated with the IP addresses people will be connecting to.
If you have only one physical interface, you must use software (kernel) interfaces. This is accomplished in different ways by different operating systems. For example, Solaris' ability to have virtual interfaces is inherent, where in Linux you must use a 'dummy' interface module.
Here's a basic guide for three of the most popular operating systems in use for web serving:

For Linux:

Compile a kernel with both module and dummy interface support. Build both the kernel and the modules (make modules). After you've booted the new kernel, you may insert the dummy module, which is likely found as /usr/src/linux/drivers/net/dummy.o.
insmod -o dummy0 /usr/src/linux/drivers/net/dummy.o

The -o flag forces the module to be named "dummy0" instead of just dummy, so you can increment this value for each module you insert.
Now, you must give this interface an IP address:
ifconfig dummy0 [and other options if needed]

Route the interface:
route add -host dummy0
The last option is needed so the route is added to the correct interface.
The arp table is where a system handles address mapping between hardware (Ethernet card) addresses and IP addresses. Each Ethernet card has its own hardware address, and the arp table manages how the kernel associates IP addresses to that physical device.
Get the hardware address of your Ethernet board with
ifconfig eth0
and use this to add an arp entry for the dummy interface:
arp -s 00:xx:yy:zz:11:22 pub

And now you should be set. Ping or telnet to the new IP address and see if it works.

For Solaris:

This assumes you have ethernet support for "le0" in your boot files.
For any additional virtual host you need only do:
ifconfig le0:1 up
ifconfig le0:2 up

Once you have your virtual IP interfaces up and running, all you need is Domain Name Service (dns) hostname entries for those IP addresses and you are all set.

For Windows NT:

Windows NT allows up to 32 IP addresses per interface. Adding more IP addresses to the interface is very simple. Assuming you have administrative privileges, go to the Control Panel and double click on the Network icon. There should be a list box labeled "Installed Network Software:". Locate the entry labeled "TCP/IP Protocol" and double-click on it. Now, click on the "Advanced" button. At the top of the dialog box, there should be a drop-down combo box with all your network interfaces listed in it.
Select the interface you want to add IP addresses to. If there is only one interface installed, then you will be working on it by default. Type in the IP address and subnet mask you want to add, then click on the "Add" button. The IP address and subnet mask pair you typed will appear in a list box to the right. The subnet mask is almost always the same value. If you are on a class C network, this should be set to "".
Once you are happy with your setup, click on "OK" until you are back to the Control Panel window. Windows NT may ask you if this is a good time to reboot. While it is never a particularly convenient time to reboot, you must do so once you need your changes to take effect.
There are a few things you may want to be aware of in this new setup. When Windows NT wants to send a packet, it will pick the IP address that has the least use on it, giving preference from the first entry down. It will also behave the same way for multiple interfaces (as it should), but even on one interface, it will treat each IP address as a "virtual" interface. This can lead to certain problems. If you are running a name server based on BIND, zone transfers can become a problem. If the secondary server requests a zone transfer to one IP address, but gets a response back from another, the transfer will fail, as the secondary server did not request the answer from the unexpected source. Some DNS servers are aware of this problem and have worked around it. You may also want to include these new IP addresses in your reverse zone of your DNS server, as there are a lot of anonymous FTP servers which require that the IP address you are coming in from can be resolvable to a name.
Now to the software side. The DNS server now needs to be able to reverse-map these IP addresses so that your web server software can be happy and your customers can find you.
There are two options; you can assign and to use something like and for their Web server addresses (assuming your domain name is dussco), or they can use something like and I recommend the latter approach, as it makes more sense, and gives customers more of a feeling that these companies are fully on the net without relying on outside sources. If Dussco is being a secondary name server for and, they, of course, need to tell their network administrators to add the WWW A record. Be certain the reverse zone is also accurate and consistent with the forward mapping. This will eliminate a lot of administration and troubleshooting headaches--especially if you are telling your web server which host to assume based on hostname rather than IP address.
Now that your machine is set up correctly on the hardware end and your DNS server is correctly set up, your web software needs to be able to recognize that certain IP addresses are for certain pages. When choosing web server software, be sure that it supports this. Most web servers supporting this feature have a configuration dialog which asks for either IP addresses or hostnames which should have certain server root directories and default home pages. Remember, if you specify a hostname, the web server figures this out with a reverse resolution, so be certain your reverse files are set up correctly on your name server.
All the web server knows is that a request came in destined for a certain IP address, not name. Once this is done, you should now be able to support multiple web pages for multiple host or domain names on your Windows NT server.

Paul Forgey is a Windows NT programmer for TCP/IP based server applications at MetaInfo, Inc., and is the resident expert on DNS, Sendmail and POP3. Most of his programming motivation comes from Starbuck's coffee and Coca-Cola.

Liem Bahneman is Systems Administrator at SSC Inc