• Choose a category
• All
• Classic-Fiction

Providers quickly realized that they could achieve significant economies of scale if they were able to host more than one site on a single server. This trick would allow www.acme.com, www.ajax,com, www.xor.com, and many other sites to be transparently served by the same hardware. In response to this business need, virtual interfaces were born.

Virtual interfaces allow a daemon to identify connections based not only on the destination port number (e.g., port 80 for HTTP) but also on the connection’s destination IP address. Today, virtual interfaces are in widespread use and have proved to be useful for other applications besides web hosting.

The idea is simple: a single UNIX machine responds on the network to more IP addresses than it has physical network interfaces. Each of the resulting “virtual” network interfaces can be associated with a corresponding domain name that users on the Internet might want to connect to. This feature allows a single UNIX machine to serve literally hundreds of web sites. (By comparison, a competing Intel-centric operating system supports virtual interfaces but can only be practically used to host about a dozen sites. Of course, we could never name names.)

The HTTP 1.1 protocol defines a form of virtual-interface-like functionality (officially called “non-IP virtual interfaces”) that eliminates the need to assign unique IP addresses to web servers or to configure a special interface at the OS level. This approach conserves IP addresses and is useful for some sites, especially sites at which a single server is home to hundreds or thousands of home pages (such as universities). However, the scheme isn’t very practical for commercial sites; it reduces scalability (you must change the IP address of the site to move it to a different server) and may also have a negative impact on security (if you filter access to a site at your firewall based on IP addresses). It appears that true virtual interfaces will be around for a while.

Configuring virtual interfaces

Setting up a virtual interface involves two steps. First, you must create the virtual interface at the TCP/IP level. The exact way you do this depends on your version of UNIX; the next few sections provide instructions for each of our example systems. Second, you must tell the Apache server about the virtual interfaces you have installed. We cover this second step starting on page 694.

Solaris virtual interfaces

Solaris supports virtual interfaces (aka “secondary interfaces”) through the concept of a physical interface and a logical unit. For example, if hme0 was the name of a physical interface, hme0:1, hme0:2, and so on would be the names of the corresponding virtual interfaces. By default, each physical interface can have up to 256 virtual identities attached to it. If you need to change this limit, use ndd to change the parameter ip_addrs_per_if (see page 311 for details on using ndd).

To configure a virtual interface, just use ifconfig on one of the virtual names. (The underlying physical interface must already have been “plumbed.”) In most cases, you’ll want to set up the system so that the ifconfigs for virtual interfaces happen automatically at boot time.

Here is an example in which a Solaris machine has an address in private address space on an internal virtual private network (VPN) and an external address for the Internet, both associated with the same physical interface, hme0. To have these interfaces configured automatically at boot time, the administrator has set up two different hostname files: /etc/hostname.hme0 and /etc/hostname.hme0:1:

% ls -l /etc/host*

-rw-r--r-- 1 root 10 Nov 4 10:19 /etc/hostname.hme0

-rw-r--r-- 1 root 16 Dec 21 19:34 /etc/hostname.hme0:1

Hostname files can contain either hostnames from the /etc/hosts file or IP addresses. In this case, the administrator has used one of each:

% cat /etc/hostname.hme0

overkill

% cat /etc/hostname.hme0:1

206.0.1.133

% grep overkill