On Fri, 31 Mar 2006, Jay Vosburgh wrote:

Krzysztof Oledzki <[EMAIL PROTECTED]> wrote:
[...]
I took this patch from linux-2.6 using git tree and applied to 2.6.16.1
together with recent "link status" fix. Unfortunately broadcast packet
duplication still occurs.

        I am unable to induce any duplicate packets using the current
netdev-2.6.git upstream branch (which should be the same bonding driver
as you're using).  I tried it with and without VLANs, using ping to
various addresses (unicast, subnet broadcast, all-1s broadcast).  I'm
using a Cisco switch, and I'm issuing the IOS command "clear mac
address-table dynamic" to induce it to (briefly) flood traffic to all
ports.

        The only duplicates I see are ping pointing out duplicate
returns from the multiple stations on the network.  I don't see bonding
delivering two copies of the same packet.

        Using the unmodified 2.6.16.1 kernel, I do see multiple copies
of the same packet from a ping to the broadcast address using the method
I describe above.

Thank you for your tests and fast response.

        I am using a different network device (tg3), although I'm not
sure how that would affect this.

Probably this is not releated.

        Under what circumstances are you seeing duplicates, and what
type of traffic is it?

If I set net.ipv4.icmp_echo_ignore_broadcasts=0 I'm seeing duplicates while pinging broadcast address:

# ping 192.168.149.255 -b
WARNING: pinging broadcast address
PING 192.168.149.255 (192.168.149.255) 56(84) bytes of data.
64 bytes from 192.168.149.21: icmp_seq=1 ttl=128 time=0.159 ms
64 bytes from 192.168.149.2: icmp_seq=1 ttl=64 time=0.267 ms (DUP!)
64 bytes from 192.168.149.11: icmp_seq=1 ttl=128 time=0.279 ms (DUP!)
64 bytes from 192.168.149.2: icmp_seq=1 ttl=64 time=0.288 ms (DUP!)
64 bytes from 192.168.149.10: icmp_seq=1 ttl=128 time=0.295 ms (DUP!)

Please notice that 192.168.149.2 responded two times.

If I run tcpdump on 192.168.149.2 it shows:

[EMAIL PROTECTED]:~# tcpdump -i vlan19 -n icmp -e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan19, link-type EN10MB (Ethernet), capture size 96 bytes

15:41:07.512007 00:14:22:b0:cb:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), 
length 98: 192.168.149.3 > 192.168.149.255: ICMP echo request, id 27686, seq 1, 
length 64
15:41:07.512111 00:14:22:b0:c9:f9 > 00:14:22:b0:cb:52, ethertype IPv4 (0x0800), 
length 98: 192.168.149.2 > 192.168.149.3: ICMP echo reply, id 27686, seq 1, length 
64
15:41:07.512139 00:14:22:b0:cb:52 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), 
length 98: 192.168.149.3 > 192.168.149.255: ICMP echo request, id 27686, seq 1, 
length 64
15:41:07.512160 00:14:22:b0:c9:f9 > 00:14:22:b0:cb:52, ethertype IPv4 (0x0800), 
length 98: 192.168.149.2 > 192.168.149.3: ICMP echo reply, id 27686, seq 1, length 
64

So it seems I must have done something wrong but I have no idea what? Wrong patch? I'm using exactly this one:
ftp://ftp.ans.pl/pub/patches/0140-bonding_suppress_duplicate_packets.patch

Best regards,

                                Krzysztof Olędzki

Reply via email to