Re: Wackamole failing after cable dis-/reconnect

On Wednesday, Oct 22, 2003, at 06:44 US/Eastern, Toralf Richter wrote:
> I have a Spread/Wackamole setup which works at least testing-wise fine 
> as long as I fail one machine of the two machine setup by completely 
> rebooting it or by killing the Wackamole or Spread daemon.
> I the above case(s) the other machine in that litte cluster takes over 
> with a very short outage only.
>
> The problem which I encounter is after disconnecting physically the 
> network interface's cable on either machine and afterwards 
> reconnecting that cable.
> Step by step I do the following, assuming initially both machines are 
> fine an listening:
> 1. disconnect NIC cable of machine A (which is 2.4.20 kernel, German 
> SUSE 8.2 distro)
> 2. watch syslog on the other machine B (which is RH 7.1, kernel 
> 2.4.2-2), wait for Wackamole to complete the arp spoof
> 3. watch ping -t on a Windows box on the same network. After 
> disconnection there is a brief outage of one-two seconds, then the 
> other machine jumps in, and ping is receiving good responses again
> 3. reconnect NIC cable of machine A (where Spread daemon and Wackamole 
> have continued running while the cable was off)
> 4. watch syslog of machine B, Wackamole brings the VIP down
> 5. watch syslog of machine A, there is no activity, apart from the 
> notice that the cacle has been reconnected and a 100Mbit link has been 
> established

Machine A should drop one of its VIPs here -- which from your later 
description sounds like it does.

The "bug" is that it doesn't re-arp the VIP that it keeps.  I agree 
this is not the desired behaviour.  I'll need to look at the algorithm 
and see if there is a way that A can realize that "at start" it was in 
conflict with at least one of its peers and re-arp all conflicting VIPs.

// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Postal Engine -- http://www.postalengine.com/
// Ecelerity: fastest MTA on earth