[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <24645.1249491676@death.nxdomain.ibm.com>
Date: Wed, 05 Aug 2009 10:01:16 -0700
From: Jay Vosburgh <fubar@...ibm.com>
To: Jiri Bohac <jbohac@...e.cz>
cc: davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH, RFC] bonding: prevent outgoing packets on inactive slaves
Jiri Bohac <jbohac@...e.cz> wrote:
>Applications exist that broadcast/multicast packets on all
>devices in the system (e.g. avahi-mdns).
>
>When a device is an inactive slave of a bond in active-backup
>mode, its MAC address may be set identical to other divecies in
>the bond. The broadcast/multicast packets may then confuse
>switches to direct packets to the inactive slave, rather than the
>active one.
>
>This patch makes sure the TX queues on inactive slaves are
>deactivated.
>
>Signed-off-by: Jiri Bohac <jbohac@...e.cz>
I'd love to include this patch; many times I've tracked down
"bonding" problems to some errant dingus confusing the switch, but I
think this patch will break some things, and therefore has to be a NAK.
Specifically, I suspect this will break users of some protocols
that intentionally (and legitimately) bind directly to the slave
underneath bonding, LLDP for one. I'm fairly sure there are such users,
because the inactive slave rx path was changed last year to permit
explicit binds to the inactive slaves to receive packets that normally
would be dropped:
commit 0d7a3681232f545c6a59f77e60f7667673ef0e93
Author: Joe Eykholt <jre@...vasystems.com>
Date: Wed Jul 2 18:22:01 2008 -0700
net/core: Allow certain receives on inactive slave.
Allow a packet_type that specifies the exact device to receive
even on an inactive bonding slave devices. This is important for some
L2 protocols such as LLDP and FCoE. This can eventually be used
for the bonding special cases as well.
Signed-off-by: Joe Eykholt <jre@...vasystems.com>
Signed-off-by: Jay Vosburgh <fubar@...ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@...hat.com>
The fact that they're receiving on the inactive slave suggests
that there may be transmits on the same slave, and a quick read of the
LLDP spec seems to agree. I'm also unsure of exactly how FCoE operates
in this regard (whether it does anything that will break due to this
patch).
Anybody have better information about LLDP or FCoE?
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists