On Mon, Aug 11, 2003 at 02:16:30PM -0400, Steven M. Bellovin wrote:
> In message <Pine.NEB.4.53.0308111101210.688@rivendell.starwolf.com>, Greywolf w
> rites:
> >Thus spake Thor Lancelot Simon ("TLS> ") sometime Yesterday...
> >
> >TLS> The correct way to do this sort of thing is with network-layer routing
> >TLS> updates, not with disgusting link-layer hackery.
> >
> >You might want to tell this to the people who make failover boxes which
> >do just this in hardware.  They do exist.  Or, at least, this used to be
> >quite a common practice a few years ago.  I never got to manage one, but
> >I saw the setup for it.  I believe Cisco's failover HW takes the
> >"I-Will-Assume-The-Other's-IP-Address-AND-its-MAC-address" approach.
> >
> >Someone will, no doubt, tell me {if,that} I am mistaken.
> 
> It's called "Virtual Router Redundancy Protocol", RFC 2338.

Or Hot-Standby Router Protocol, HSRP, or a number of other variants.
Some move just the IP address (using the host MAC, and issuing a
gratuitous ARP on change of ownership), some "move" the MAC address
as well.

One of the reasons these hacks are necessary is that higher-level
mechanisms can take too long to notice the change. One mechanism
relies on ARP in each host, the other relies on a switch noticing
a MAC address moving ports.

There are other variants, including load-balancing mechanisms like
that used by Checkpoint's CPLS, Cisco's dCEF, Microsoft's WLBS,
and others.

At least some of these play "disgusting link-layer hackery" by
responding to ARP requests for the "virtual" router/service unicast
IP address with a reply giving a multicast MAC address. Others rely
on static config in switches to forward copies of packets to multiple
ports.

Each (all) of the nodes in the cluster then receive the packet,
and they do some quick hash-type calculation to determine which of
them will handle it for further processing. Failover and load
balancing basically is a matter of arbitrating ownership of the
various hash buckets, as well as replication of any necessary
session state for whatever the application is.

This seems to work for most devices, who will happily use the
multicast MAC destination (including NetBSD). It seems Cisco IOS
is an exception; it will only use such an address for a unicast IP
address if its configured statically, it won't accept such addresses
in ARP replies.


--
Dan.