netdev - Re: [PATCH] IPv6: DAD from bonding iface is treated as dup address from others

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 7 Oct 2011 02:13:26 -0400
From:	Chuck Anderson <cra@....EDU>
To:	netdev@...r.kernel.org
Subject: Re: [PATCH] IPv6: DAD from bonding iface is treated as dup address
	from others

On Thu, Oct 06, 2011 at 06:24:36PM -0700, Yinglin Sun wrote:
> On Thu, Oct 6, 2011 at 5:59 PM, Jay Vosburgh <fubar@...ibm.com> wrote:
> >        Why are you setting up the port channel after configuring the
> > bond?
> >
> >        As a possible workaround, if you have control over the setup
> > process (perhaps it's some sort of manual process), adding one slave to
> > the bond, leaving the other soon-to-be slaves down, then setting up the
> > switch, and finally adding the remaining slaves should work around the
> > issue, since if the bond has only one slave it won't see any looped
> > packets.
> >
> >        Or you could bring the bond up as active-backup, then change the
> > mode to balance-xor once the switch is configured.
> >
> >        Ultimately, though, the problem stems from the settings mismatch
> > between the switch and the bonding system; balance-xor is meant to
> > interoperate with etherchannel, and when the switch is not configured
> > properly, correct behavior is difficult to guarantee.
> >
> 
> Jay,
> 
> Thanks a lot for the suggestion.
> 
> It's mainly about usability. We would like to provide customers with
> consistent IPv6 configuration procedures as IPv4.  Such workarounds
> could be confusing and generate customer calls.

You've created/encouraged your customers to create a broken network
configuration by connecting two bonded links to a non-bonded,
non-etherchannel switch port pair.  This type of misconfiguration,
when applied to inter-switch trunks, can cause major network issues,
like looping and broadcast storms, taking down the entire network
unless something like Spanning Tree is enabled to protect against such
accidental loops.  It should be avoided at all costs.  Luckily, if the
Linux host in this case is not being used as a switch/bridge, the
impact of this might not be so bad--perhaps limited to the IPv6 DAD
issue you report.

If you want better usability and plug-n-play bonding, then require
LACP/802.3ad to be used.  Please don't encourage your customers to
connect misconfigured devices to the network, thanks.
--
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