mark at exonetric
Mar 23, 2009, 9:58 AM
Post #4 of 5
(4041 views)
Permalink
|
-----------------------------------------------------------
First, regarding the duplication issue :
tcpdump -e -r s1-tcpdump-arp.dat -n | fgrep 82.138.254.24
shows that the IP 82.138.254.24 associated with the "first" group of
IPs,
gets sent in an grat. arp packet 32 times within a period of as
follows.
22:46:52.656125 00:e0:81:41:3e:4c > ff:ff:ff:ff:ff:ff, ethertype ARP
(0x0806), length 60: arp reply 82.138.254.24 is-at 00:e0:81:41:3e:4c
i.e. same originating MAC and always to the broadcast address (if my
reading is correct).
That doesn't seem right to me.
-----------------------------------------------------------
Second, regarding the missing grat. arp packets:
I've filtered out the 'arp reply' packets and then just selected the
source MAC,
dst MAC and the announced IP. I also took out the IP addresses not
being managed
by wackamole itself. Those totals aren't what I would expect if all
members of a
VIF group are treated equally.
I "failed" and "re-enabled" the s2 node with 'wackatrl -f/s' once or
twice during the collection
period, so I'd expect the second group of 4 IPs to show up the most as
they flip
back and forth between hosts. MAC ending '4c' represents host s1 and
MAC ending
'96' represents host s2.
It's possible I didn't wait long enough between disable and re-enable
to see
the 3rd and 4th IPs to be re-announced though. So I need to redo this
and wait
longer between the wackatrl state changes.
for the second VIF group:
82.138.255.18: host s1 sent 96 identical grat. arp packets announcing
itself for that IP (broadcast)
82.138.254.25: host s1 sent 32 identical grat. arp packets announcing
itself for that IP (broadcast)
82.138.255.25: host s1 sent 0 grat. arp packets
82.138.254.27: host s1 sent 1 grat. arp packets announcing itself for
that IP (unicast, to router I think)
for the first VIF group:
82.138.255.17: host s1 sent 64 identical grat. arp packets announcing
itself for that IP (broadcast)
82.138.254.24: host s1 sent 32 identical grat. arp packets announcing
itself for that IP (broadcast)
82.138.255.24: host s1 sent 0 grat. arp packets
82.138.254.26: host s1 sent 0 grat. arp packets.
markimac% tcpdump -e -r s1-tcpdump-arp.dat -n | awk '/arp reply/
{print $2 "-- " $4 " -- " $12}' | sort -n | uniq -c | sort -k 5 -nr
reading from file s1-tcpdump-arp.dat, link-type EN10MB (Ethernet)
96 00:e0:81:41:3e:4c-- ff:ff:ff:ff:ff:ff, -- 82.138.255.18
64 00:e0:81:41:3e:96-- ff:ff:ff:ff:ff:ff, -- 82.138.255.17
64 00:e0:81:41:3e:4c-- ff:ff:ff:ff:ff:ff, -- 82.138.255.17
32 00:e0:81:41:3e:96-- ff:ff:ff:ff:ff:ff, -- 82.138.255.18
32 00:e0:81:41:3e:96-- ff:ff:ff:ff:ff:ff, -- 82.138.254.25
32 00:e0:81:41:3e:4c-- ff:ff:ff:ff:ff:ff, -- 82.138.254.24
1 00:e0:81:41:3e:4c-- 00:02:17:e0:40:1c, -- 82.138.254.27
markimac% tcpdump -e -r s2-tcpdump-arp.dat -n | awk '/arp reply/
{print $2 "-- " $4 " -- " $12}' | sort -n | uniq -c | sort -k 5 -nr
reading from file s2-tcpdump-arp.dat, link-type EN10MB (Ethernet)
96 00:e0:81:41:3e:4c-- ff:ff:ff:ff:ff:ff, -- 82.138.255.18
64 00:e0:81:41:3e:96-- ff:ff:ff:ff:ff:ff, -- 82.138.255.18
64 00:e0:81:41:3e:96-- ff:ff:ff:ff:ff:ff, -- 82.138.255.17
64 00:e0:81:41:3e:4c-- ff:ff:ff:ff:ff:ff, -- 82.138.255.17
32 00:e0:81:41:3e:96-- ff:ff:ff:ff:ff:ff, -- 82.138.254.25
32 00:e0:81:41:3e:4c-- ff:ff:ff:ff:ff:ff, -- 82.138.254.24
Regards,
Mark
On 23 Mar 2009, at 15:50, Theo Schlossnagle wrote:
> Looks right to me. You are grat-arping from every IP to every IP on
> your network...
>
> 82.138.255.16/28
> 82.138.254.16/28
>
> There are 16 address - 2 (net/bcast) ... so 14 people on each
> network that need to be notified that the IPs are owned by new
> machines. You have 4 IPs configured on each box.... 3 are on one
> subnet and 1 is on the other... So, you should see 3*14 + 1*14
> gratuitous arp responses from each machine. Your tcpdump looks
> fine. If you look inside the payload, you'll see all the
> combinations represented in the source and target addresses.
>
>
> On Mar 22, 2009, at 6:53 PM, Mark Blackman wrote:
>
>> Ok, i've attached the correct config, wackamole debug output and
>> tcpdump of arp-only
>> packets.
>>
>> The original config was the result of paring down the 4 IPs per
>> group to a single IP
>> as a test.
>>
>> - Mark
>>
>> <wackamole-diag-correct.tgz>
>>
>>
>> On 22 Mar 2009, at 22:25, Mark Blackman wrote:
>>
>>>
>>> On 20 Mar 2009, at 17:18, Theo Schlossnagle wrote:
>>>
>>>> config file, and an arp-only tcpdump on every interface for the
>>>> same time period and the relevant syslog output.
>>>>
>>>
>>> Attached as requested. Sent only to yourself as it include client
>>> set-up details, but feel
>>> free to respond on the list.
>>>
>>> Two machines, s1 and s2 both on the following 3 subnets
>>>
>>> 10.10.10.0/24
>>> 82.138.255.16/28
>>> 82.138.254.16/28
>>>
>>> the spread daemon is configured to use the 10.10.10.0/24 subnet IPs
>>>
>>> the machines take responsibility for two groups of 4 IPs as
>>> the configuration file should indicate. With luck I've merely
>>> screwed up the configuration.
>>>
>>> I've attached the tcpdump output (arp) from each machine, suitable
>>> for tcpdump -r playback, both configuration files (hopefully
>>> identical)
>>> and finally output from both wackamole daemons with '-d' specified.
>>>
>>> I ran wacktrl -f / wackatrl -s sequence while the daemons were
>>> running
>>> as an example.
>>>
>>> Cheers,
>>> Mark Blackman
>>> Exonetric
>>>
>>>
>>>
>>> <wackamole-diag.tgz>
>>>
>>>
>>>
>>
>
> --
> Theo Schlossnagle
> Principal/CEO
> OmniTI Computer Consulting, Inc.
> Web Applications & Internet Architectures
> w: http://omniti.com p: +1.443.325.1357 x201 f: +1.410.872.4911
>
>
>
>
_______________________________________________
wackamole-users mailing list
wackamole-users [at] lists
http://lists.backhand.org/mailman/listinfo/wackamole-users
|
wackamole-2.1.4-patches.txt
