In spite of their simplicity, virtual IP addresses offer two main advantages over their physical counterparts:
These advantages exist because virtual IP addresses are purely virtual and are not bound to a physical network wire.
If a virtual IP address is defined on a multihomed server with more than one physical NIC, a virtual IP address is a highly reachable IP address on the server when compared to any of the physical IP addresses. This is especially true in the event of server NIC failures. This assumes that the server is running a routing protocol and is advertising its “internal” virtual IP network—which only it knows about and can reach—to other network nodes.
Physical IP addresses might not be reachable because:
TCP/IP protocols use link-based (network-based) addressing to identify network nodes. As a result, the routing protocols preferentially deliver a packet to the server through the network that the target IP address is part of.
Dynamic routing protocols are extremely resilient to intermediate link and router failures, but they do not adapt well to failures of links at the last hop that ultimately delivers a packet to its destination.
This is because the last hop link is typically a stub link that does not carry any routing heartbeats. Therefore, if one of the physical cards in a server fails, the server can become inaccessible, along with any service that it hosts on the corresponding physical IP address. This can occur in spite of the fact that the server is still up and running and can be reached through the other network card.
The virtual IP address feature circumvents this problem by creating a virtual IP network different from any of the existing physical IP networks. As a result, any packet that is destined for the virtual IP address is forced to use a virtual link as its last hop link. Because it is purely virtual, this last hop link can be expected to always be up. Also, because all other real links are forcibly made to act as intermediate links, their failures are easily handled by the dynamic routing protocols.
The following figure illustrates a multihomed server with all nodes running a dynamic routing protocol.
Figure 8-1 Multihomed Server Running a Dynamic Routing Protocol
In this network, the server is a multihomed server hosting a critical network service. For simplicity, assume that all nodes are running some dynamic routing protocol.
If the client attempts to communicate with the server with the 18.104.22.168 IP address, it tries to reach the server through the nearest router, which is Router 1. If the 22.214.171.124 interface were to fail, Router 1 would continue to advertise reachability to the 126.96.36.199/FF.0.0.0 network and the client would continue to forward packets to Router 1. Thes undeliverable packets would ultimately be dropped by Router 1. Therefore, in spite of the fact that the service is still up and running and can be reached through the other active interface, it is rendered unreachable. In this scenario, a recovery would involve the ability of the client application to retry the alternate IP address 188.8.131.52 returned by the name server.
Consider the same scenario with the server configured with a virtual IP address and the client communicating with the virtual IP address instead of one of the server’s real IP addresses, as shown in the following figure.
Figure 8-2 Multihomed Server Using Virtual IP Addresses
In this configuration, if the 184.108.40.206 interface were to fail, the client would ultimately learn the new route through Router 2 and would correctly forward packets to Router 2 instead of Router 1. Thus, despite physical interface failures, a virtual IP address on a multihomed server acts as an always-reachable IP address for the server.
Generally speaking, if a connection between two machines is established by using a virtual IP address as the end-point address at either end, the connection is resilient to interface failures at either end.
There are two important side effects that directly follow from the highly reachable nature of virtual IP addresses:
They completely and uniquely identify a multihomed server
A multihomed server with a virtual IP address no longer needs to carry multiple DNS entries for its name in the naming system.
They significantly enhance the LAN redundancy inherent in a multihomed server
If one of the subnets that a server interfaces to fails completely or is taken out of service for maintenance, the routing protocols reroute the packets addressed to the virtual IP address through one of the other active subnets.
The resilience against interface failures provided by virtual IP addresses depends on the fault resilience provided by the dynamic routing protocols, as well as on fault recovery features such as retransmissions built into the application logic.
Unlike physical IP addresses, which are limited in their mobility, virtual IP addresses are highly mobile. The degree of mobility is determined by the number of servers that an IP address on a specific server could be moved to. In other words, if you choose a physical IP address as an IP address of a network resource, you are limiting the set of potential servers to which this resource could transparently fail over to.
If you choose a virtual IP address, the set of servers that the resource could be transparently moved to is potentially unlimited. This is because of the nature of virtual IP addresses; they are not bound to a physical wire and, as a result, they carry their virtual network to wherever they are moved. Again, there is an implicit assumption that the location of a virtual IP address is advertised to the owning server through some routing protocol. The ability to move an IP address across different machines becomes particularly important when you need to transparently move or fail over a network resource that is identified by an IP address (which could be a shared volume or a mission-critical service) to another server on another network.
This unlimited mobility of virtual IP addresses is an advantage to network administrators, offering more ease of manageability and greatly minimizing network reorganization overhead. For network administrators, shuffling services between different IP networks is the rule rather than the exception. The need often arises to move a machine hosting a particular service to some other IP network, or to move a service hosted on a particular machine to be rehosted on some other machine connected to a different IP network. If the service is hosted on a physical IP address, accommodating these changes involves rehosting the service on a different IP address pulled out from the new network, and appropriately changing the DNS entry for the service to point to the new IP address. However, if the service is hosted on a virtual IP address, the necessity of changing the DNS entries for the service is eliminated.
Virtual boards support configuring virtual IP addresses with a host mask. This results in a single address being used rather than an entire subnet. See Section 8.3, Reducing the Consumption of Additional IP Addresses.
Full resilience of connections to interface failures can be ensured only when the connections are established between machines through using virtual IP addresses as end point addresses. This means an application that initiates outbound connections to a virtual IP address should also use a virtual IP address as its local end point address.
This isn’t difficult if the application binds its local socket end point address with a virtual IP address. However, there are some legacy applications that bind their sockets to a wildcard address (such as 0.0.0.0). When these applications initiate an outbound connection to other machines, TCP/IP chooses the outbound interface’s IP address as the local socket end point address. In order for these legacy applications to take advantage of the fault resilience provided by the virtual IP address feature, the default source address selection behavior of TCP/IP has been enhanced to accommodate the use of a virtual IP address as the source IP address. As a result, whenever a TCP or UDP application initiates an outbound connection with a wildcard source IP address, TCP/IP chooses the first bound virtual IP address as the source IP address for the connection.
This enhanced source address selection feature can be enabled or disabled globally as well as on a per-interface basis. This feature is enabled by default on all interfaces.