netdev - Re: [PATCH net-next] bonding,vlan: propagate MAC failover changes to VLANs

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: <1334776810.2426.44.camel@bwh-desktop.uk.solarflarecom.com>
Date:	Wed, 18 Apr 2012 20:20:10 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Jay Vosburgh <fubar@...ibm.com>
CC:	<netdev@...r.kernel.org>, "David S. Miller" <davem@...emloft.net>,
	Patrick McHardy <kaber@...sh.net>,
	Andy Gospodarek <andy@...yhouse.net>
Subject: Re: [PATCH net-next] bonding,vlan: propagate MAC failover changes
 to VLANs

On Wed, 2012-04-18 at 11:49 -0700, Jay Vosburgh wrote:
> Ben Hutchings <bhutchings@...arflare.com> wrote:
> 
> >On Wed, 2012-04-18 at 11:02 -0700, Jay Vosburgh wrote:
> >> 	With bonding's fail_over_mac=active, during failover the MAC
> >> address of the bond itself changes to match that of the slave.
> >> 
> >> 	This patch adds a notifier call to cause VLANs stacked atop the
> >> bonding to also change their MAC addresses to the new address when a
> >> failover occurs.
> >> 
> >> 	While it is legal for a VLAN to have a MAC address that differs
> >> from the underlying device, at least one device (qeth) that requires the
> >> use of fail_over_mac for bonding cannot handle the VLAN's MAC differing
> >> from that of the bond; thus, it needs the MAC change to propagate up
> >> to any VLANs when fail_over_mac is set to active.
> >[...]
> >
> >This doesn't make sense to me.  You're applying the behaviour to all
> >VLANs on top of a bond, whether or not the underlying device is driven
> >by qeth, and ignoring any MAC address changes that don't involve the
> >bonding driver.
> 
> 	With the patch, the PROPAGATE event is only generated if bonding
> is set for fail_over_mac=active, which is normally only enabled on those
> devices that require it (some devices for IBM's pseries and zseries
> architectures and Infiniband, which doesn't have VLANs).

Yeah, OK, that makes sense.

> 	Devices that do not use bonding's fail_over_mac will not have
> VLANs following MAC changes.

I take it that the devices with this limitation on source MAC address
have an essentially unchangeable MAC address?  If they are limited to
single address but it's changeable then they should be emitting this
notification too.

> >I think either of these would be better fixes:
> >1. Make VLAN devices follow changes to the parent device's MAC address
> >unless they are assigned an address of their own.
> >2. Add a configuration flag for VLAN devices to follow changes to the
> >parent device's MAC address.
> 
> 	#1 would be a behavior change for all VLAN devices, which I
> sought to avoid.
> 
> 	#2 would be an additional configuration option that would have
> to be enabled just for this case (unless VLANs following MAC changes of
> the parent device is a generally desirable feature).

I don't know whether it is generally desirable.  My guess would be that
unless a VLAN device is explicitly configured to use its own address
then it is desirable.

> The patch requires
> no additional option settings beyond what are currently in use.

Right, I understand that this ought to Just Work, if possible.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
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