netdev - Re: [PATCH] bonding: make IGMP flooding on active-backup bonds configurable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200703010108.l2118x22001354@death.nxdomain.ibm.com>
Date:	Wed, 28 Feb 2007 17:08:59 -0800
From:	Jay Vosburgh <fubar@...ibm.com>
To:	Andy Gospodarek <andy@...yhouse.net>
cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] bonding: make IGMP flooding on active-backup bonds configurable 

Andy Gospodarek <andy@...yhouse.net> wrote:

>On Wed, Feb 28, 2007 at 02:39:42PM -0800, Jay Vosburgh wrote:
[...]
>> 	Why would you want to turn this off?
>
>When you connect active-backup bonds to 2 separate switches that are in
>'distant' parts of the network you can end up with a bunch of unwanted
>multicast data flowing everywhere and if you don't care whether or not
>your multicast traffic is highly available then it just seems like
>noise.  I thought the flexibility seemed nice.

	Ok, I can buy the "multicast spew" argument.

>> 	Also, I've got a replacement patch for this functionality that
>> seems to be better in all regards. It sends bonus IGMP joins when a
>> failover occurs, rather than simply duplicating them on all slaves (the
>> current system can leave switches in the dark if the slaves fail back to
>> the originals).  As chance would have it, I'm planning to post it as
>> part of a set in a a little while.
>> 
>
>That sounds like a nice add-on to the existing functionality.  I can see
>the value in something dynamic like that, but I can also see the value
>in something static like the functionality we have.  Did you plan to
>keep the existing functionality intact or just have it done dynamically?

	Well, I posted the patch just a bit ago, so you can see for
yourself, but no, it removes the existing "copy IGMP everywhere"
behavior.  I couldn't really think of an advantage to flooding
everywhere all the time if the hose is re-aimed during failover (if
you'll pardon my cheesy metaphor).

>Is this separate from your workqueue/refactoring patch or does it work
>on the existing code?

	This is separate, for the current mainline.

	-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