Re: Wackamole failing after cable dis-/reconnect

Theo Schlossnagle wrote:

> 
> 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

Hi Theo,
thanks for your reply. A few remarks from me:
> Machine A should drop one of its VIPs here -- which from your later 
> description sounds like it does.
As I said in the earlier email, on reconnection of the cable to machine 
A, machine B drops the VIP, visible in the syslog.
machine A does not do anything regarding the VIP, at least not anything 
that appears in the syslog. Therefore I would suppose, that whle the 
cable is off machine A it keep the VIP - but dring physical 
disconnection naturally can not respond to it. on disconnection of the 
cable machine B picks up the VIP and broadcasts the updated arp 
information. on reconnection it drops the VIP but does not broadcast arp 
information (if I run wackamole from the command line with -d, I do not 
see the shared arp cache beeing updated and broadcast). So to me it 
seems, that wackamole in the cases it shuts a VIP down on a machine 
should broadcast as well, just as it when it claims a VIP.

> 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.
Correct me if I am wrong, but I think the problem is that after the 
reconnection of the cable Wackamole does not really come into an "at 
start" position, because it does not notice or respond to down or up 
condition the physical network link.

I would be happy if that helped you. If my further explanations seem 
redundand to you, I beg your apologies.

Have a nice day.

-- 
Mit freundlichen Gruessen / Kind Regards
Toralf Richter

fon 069.94 34 05-10
fax 069.94 34 05-27
[email protected]

triplesense GmbH
Hanauer Landstraße 186
60314 Frankfurt am Main