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  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]
Date:	Wed, 28 Feb 2007 17:08:59 -0800
From:	Jay Vosburgh <>
To:	Andy Gospodarek <>
Subject: Re: [PATCH] bonding: make IGMP flooding on active-backup bonds configurable 

Andy Gospodarek <> 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.


	-Jay Vosburgh, IBM Linux Technology Center,
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists