Re: [PATCH net-2.6] bonding: drop frames received with master's source MAC

["Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>]

Le 02/03/2011 00:08, Nicolas de Pesloüan a écrit :
[snip]
> Can we imagine that, at the time we change the bonding mode to -rr or
> -xor, we simply brodcast or multicast one or two frames with some random
> data and wait to see whether we receive the frame back? If we receive at
> least one frame with the same random data, in one of the slaves
> interface for this bonding, we know for sure the switch configuration is
> not "multicast loop safe". Bonding already send ARP requests/replies in
> many situations. Adding one broadcast/multicast frame at bond setup time
> is probably acceptable.
>
> And to ensure consistent results, we need to send such
> broadcast/multicast every time the link goes up for an already enslaved
> slave. This is not perfect, as the switch topology may change in a way
> that won't be detected by bonding, but still cause a new multicast loop,
> but...
>
> Knowing the switch configuration is not "multicast loop safe", we can,
> at a minimum, issue a warning, telling the user she should expect
> strange behaviors, like false duplicate address detection.
>
> And we can probably use this information into the should-drop logic, for
> mode that lack "inactive" slaves.
>

Still thinking about it:

We should drop the frame if :

the bonding interface is in -rr or -xor mode,
and we know the switch topology in front of our slaves is not "multicast
loop safe" (see above).
and the source MAC is the MAC of the bonding interface
and the destination MAC is a multicast one.

That being said, I wonder if this is only bonding related.

If one decide to configure two interfaces with the same MAC and connect
them to the same LAN, then we get the exact same situation. Having eth0
and eth1 share a single MAC and a single IP address, connected to a
switch in Etherchannel mode is a perfectly valid setup, while
suboptimal. And if the Etherchannel mode happens to be improperly
configured, we end up with the same problem as reported by Andy.

          Nicolas.

[ Resent, because netdev ML didn't get it the first time ]