Question regarding MAC address configuraton with VLAN devices

Question regarding MAC address configuraton with VLAN devices

[Manish Chopra]

Hello Patrick,

I have a question regarding MAC address configuration of network devices specially
when VLANs are configured on that. Can you please help to address?

When user changes MAC address of a base network device [e.g., via ifconfig]
why existing VLAN device on top of that would add it's previous MAC address to
unicast list of base device instead of adapting the new MAC address
in it's own net device?

What we are trying to achieve here is that -

For a VF, if Hypervisor/Administrator has forced a MAC [e.g., via iproute2] then as a part of 
"learning process [of the new hypervisor forced mac] done by VF driver", it will simply call
"call_netdevice_notifiers(NETDEV_CHANGEADDR, dev)", which would notify the address change
to VLAN interfaces configured on top of VF device and they will adapt the hypervisor forced MAC too.
But that's not seems to be the behavior here, instead VLAN device on top of the VF device seems to be adding
It's previous MAC address to unicast list of base VF device. This configuration will not take effect
[since PF is blocking the VF's additional unicast MACs, if once a MAC has been forced to the VF], thus
effectively the VLAN interface will never receive traffic with it's configured MAC.


Regards,
Manish

RE: Question regarding MAC address configuraton with VLAN devices

[Manish Chopra]

> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Manish Chopra
> Sent: Thursday, April 02, 2015 12:46 AM
> To: Patrick McHardy
> Cc: netdev; Yuval Mintz
> Subject: Question regarding MAC address configuraton with VLAN devices
> 
> 
> Hello Patrick,
> 
> I have a question regarding MAC address configuration of network devices
> specially when VLANs are configured on that. Can you please help to address?
> 
> When user changes MAC address of a base network device [e.g., via ifconfig]
> why existing VLAN device on top of that would add it's previous MAC address to
> unicast list of base device instead of adapting the new MAC address in it's own
> net device?
> 
> What we are trying to achieve here is that -
> 
> For a VF, if Hypervisor/Administrator has forced a MAC [e.g., via iproute2] then
> as a part of "learning process [of the new hypervisor forced mac] done by VF
> driver", it will simply call "call_netdevice_notifiers(NETDEV_CHANGEADDR,
> dev)", which would notify the address change to VLAN interfaces configured on
> top of VF device and they will adapt the hypervisor forced MAC too.
> But that's not seems to be the behavior here, instead VLAN device on top of the
> VF device seems to be adding It's previous MAC address to unicast list of base VF
> device. This configuration will not take effect [since PF is blocking the VF's
> additional unicast MACs, if once a MAC has been forced to the VF], thus
> effectively the VLAN interface will never receive traffic with it's configured MAC.
> 
>

Hello Patrick,
Not sure if you have gone through this email, just to remind you again if you have missed it.

Thanks,
Manish 

> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Question regarding MAC address configuraton with VLAN devices

[Alexander Duyck]

On 04/01/2015 12:15 PM, Manish Chopra wrote:
> Hello Patrick,
>
> I have a question regarding MAC address configuration of network devices specially
> when VLANs are configured on that. Can you please help to address?
>
> When user changes MAC address of a base network device [e.g., via ifconfig]
> why existing VLAN device on top of that would add it's previous MAC address to
> unicast list of base device instead of adapting the new MAC address
> in it's own net device?
>
> What we are trying to achieve here is that -
>
> For a VF, if Hypervisor/Administrator has forced a MAC [e.g., via iproute2] then as a part of
> "learning process [of the new hypervisor forced mac] done by VF driver", it will simply call
> "call_netdevice_notifiers(NETDEV_CHANGEADDR, dev)", which would notify the address change
> to VLAN interfaces configured on top of VF device and they will adapt the hypervisor forced MAC too.
> But that's not seems to be the behavior here, instead VLAN device on top of the VF device seems to be adding
> It's previous MAC address to unicast list of base VF device. This configuration will not take effect
> [since PF is blocking the VF's additional unicast MACs, if once a MAC has been forced to the VF], thus
> effectively the VLAN interface will never receive traffic with it's configured MAC.
>
>
> Regards,
> Manish

What you are proposing would likely require significant changes to more 
than just VLANs.  It would have an impact on all stacked devices since 
normally the assumption is that we push addresses down, not up.  That is 
why the vlan_sync_address is simply checking to see if its current 
address is supported before pushing the address down.

Maybe we should look into adding some sort of flag to indicate that the 
address table is locked, like a IFF_L2_ADDR_LOCKED in order to indicate 
that the device only supports one L2 address and cannot be changed.  
Then you could probably pass that up to higher levels to force things 
like the address change you want in VLAN, and things like MACVLAN would 
simply fail if that flag is set.

- Alex

RE: Question regarding MAC address configuraton with VLAN devices

[Yuval Mintz]

> What you are proposing would likely require significant changes to more than
> just VLANs.  It would have an impact on all stacked devices since normally the
> assumption is that we push addresses down, not up.  That is why the
> vlan_sync_address is simply checking to see if its current address is supported
> before pushing the address down.
> 
> Maybe we should look into adding some sort of flag to indicate that the address
> table is locked, like a IFF_L2_ADDR_LOCKED in order to indicate that the device
> only supports one L2 address and cannot be changed.
> Then you could probably pass that up to higher levels to force things like the
> address change you want in VLAN, and things like MACVLAN would simply fail if
> that flag is set.
> 
> - Alex

I think there's an even simpler question here -
Today, if you'll have a network interface with a vlan stacked on top of it
and user calls 'ip link set ... address ...' the end result would be that the vlan
interface retains the original MAC and push it downward [to base device].
You can claim this is harmless, but I don't really think anyone intends this to
happen. [You may claim this is not an interesting flow, and you'll probably
be right; but that's beside the point ;-) ]

Perhaps limiting this only for devices-that-support-a-single-l2-address is too
harsh; Although in that case, we'll need to distinguish between MAC address
that were passed upward [e.g., vlan interface] and downward [e.g., macvlan], 

Re: Question regarding MAC address configuraton with VLAN devices

[Michal Kubecek]

On Wed, Apr 08, 2015 at 05:49:59AM +0000, Yuval Mintz wrote:
> I think there's an even simpler question here -
> Today, if you'll have a network interface with a vlan stacked on top of it
> and user calls 'ip link set ... address ...' the end result would be that the vlan
> interface retains the original MAC and push it downward [to base device].
> You can claim this is harmless, but I don't really think anyone intends this to
> happen.

If it wasn't intended, why would anyone write the code doing the sync
(and switching to promiscuous mode as a fallback)? The way I see it,
there were two options:

  (a) add upper device's address to lower device's uc list
  (b) propagate changed MAC address upwards

And the decision was to choose (a). While (b) might make some things
simpler (and others more complicated), changing the behaviour now when
people are used to it would be IMHO very unfortunate.

                                                        Michal Kubecek

RE: Question regarding MAC address configuraton with VLAN devices

[Yuval Mintz]

> > I think there's an even simpler question here - Today, if you'll have
> > a network interface with a vlan stacked on top of it and user calls
> > 'ip link set ... address ...' the end result would be that the vlan
> > interface retains the original MAC and push it downward [to base device].
> > You can claim this is harmless, but I don't really think anyone
> > intends this to happen.
> 
> If it wasn't intended, why would anyone write the code doing the sync (and
> switching to promiscuous mode as a fallback)?

I Didn't mean there's NO use-case where this is intended [e.g, this reflects
the logic behind the vlanmac configuration just fine] - I meant that it's
probably not the intended behavior for a plain vlan interface.

> The way I see it, there were two options:
> 
>   (a) add upper device's address to lower device's uc list
>   (b) propagate changed MAC address upwards
> 
> And the decision was to choose (a). While (b) might make some things simpler
> (and others more complicated), changing the behaviour now when people are
> used to it would be IMHO very unfortunate.
> 
>                                                         Michal Kubecek

I agree, although I'm not sure (a) and (b) can't co-exist under some strict set 
of rules.

I was thinking of perhaps marking the netdevice when eth_hw_addr_inherit() is
called, and unmark that flag on dev_set_mac_address(), assuming that as long
as a different MAC wasn't explicitly configured, the device should continue
inheriting the real dev MAC; But I think that would pose problems with APIs
that change the 'dev_addr' without the ndo, e.g., bonding devices.