Documentation from Creating Linux Web Farms
If a machine, or service running on a machine, becomes unavailable, it is often useful to substitute another machine. The substitute machine is often referred to as a hot stand-by. In the simplest case, IP address takeover involves two machines, each with their own IP address that, are used for administrative access. In addition, there is a virtual IP address that is accessed by end-users. The virtual IP address will be assigned to one of the servers, the master.
IP address takeover begins with the hot stand-by bringing up an interface for the virtual IP address. This is most conveniently done by using an IP alias, that is, setting up a second logical interface on an existing physical interface. Once the interface is up, the hot stand-by is able to accept traffic, and answer ARP requests, for the virtual IP address. This does not, however, ensure that all traffic for the virtual IP address will be received by the hot stand-by.
Though the master host may be inaccessible, it may still be capable of answering ARP requests for the hardware address of the virtual IP address. If this occurs then each time a host on the LAN sends out an ARP request there will be a race condition, and potentially packets will be sent to the master which has been determined to have failed in some way. In addition, even if the master host does not issue ARP replies, traffic will continue to be sent to the interface on the master host. This will continue until the ARP cache entries of the other hosts and routers on the network expire.
To expediate fail-over and ensure all traffic goes to the the hot stand-by, a technique known as gratuitous ARP is used. Usually ARP works as follows. Host A sends out an ARP request for the hardware address of an IP address on host B. Host B sees the request and sends an ARP reply containing the hardware address for the interface with the IP address in question. Host A then records the hardware address in its ARP cache so it doesn't have to do an ARP request and wait for a reply each time it wants to send a packet. Entries in an ARP cache typically expire after about two minutes. A gratuitous ARP is an ARP reply when there was no ARP request. If the ARP reply is addressed to the broadcast hardware address then all hosts on the LAN will receive the ARP reply and refresh their ARP cache. If gratuitous ARPs are sent often enough then no host's ARP entry for the IP address in question should expire, so no ARP requests will be sent out, so there is no opportunity for a rouge ARP reply from the failed master to be sent out.
To relinquish an address obtained through IP address takeover the interface for the virtual address should be taken down. Furthermore, to ensure a rapid transition, gratuitous ARP should be issued with the hardware address of the interface on the master host with the virtual address. Depending on the service, it may be better to reverse the roles of the hot stand-by and master once the failed master comes back on line, rather than undoing fail-over. To do this effectively the hosts will need to negotiate ownership of the virtual IP address, ideally using a heartbeat protocol.
Gratuitous ARP can be used to maliciously take over the IP address of a
machine. Because of this, some routers and switches ignore, or can be
configured to ignore gratuitous ARP. On a given network, this may or may
not be an issue, but for IP address takeover to be successful, the
equipment must be configured to accept gratuitous ARP or flush the ARP
caches as necessary. Other than this there are no known problems with using
gratuitous ARP and, hence, IP address takeover on both switched and
non-switched ethernet networks.
Copyright © 2000-2005,
Last Updated: Tue May 17 17:37:25 2005 +0900
Debian is a registered trademark of Software in the Public Interest, Inc.
Red Hat, the Red Hat Shadowman logo and Fedora are registered trademarks of Red Hat, Inc.
Red Hat may also be refered to as RedHat on this site.
Linux is a registered trademark of Linus Torvalds.
All other trademarks are the property of their respective owners.
Copyright © 2000-2005,