Date:   Tue, 30 Jan 2018 22:14:20 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     Shannon Nelson <shannon.nelson@...cle.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     "Duyck, Alexander H" <alexander.h.duyck@...el.com>
Subject: RE: macvlan devices and vlan interaction

> -----Original Message-----
> From: Shannon Nelson [mailto:shannon.nelson@...cle.com]
> Sent: Tuesday, January 30, 2018 12:30 PM
> To: Keller, Jacob E <jacob.e.keller@...el.com>; netdev@...r.kernel.org
> Cc: Duyck, Alexander H <alexander.h.duyck@...el.com>
> Subject: Re: macvlan devices and vlan interaction
> 
> Hi Jake,
> 
> The current behavior seems logical to me, but I suppose Alex might argue
> differently.  The macvlan was put onto the default lowerdev assuming the
> lowerdev will hand it all the default traffic, and then the macvlan
> splits out its own vlan traffic.  As soon as the lowerdev assumption
> changes, it is going to change what gets pushed up to the macvlan dev.
> If the lowerdev is separating the vlan traffic out of the "default" flow
> headed to the macvlan, then the initial assumption has changed and the
> vlan traffic has been vectored off before it can be delivered up the
> stack to the macvlan.
> 
> There's an argument that the lowerdev shouldn't know anything about the
> upperdev's routing, just deliver to the upperdev and let the upperdev
> worry about it.  But perhaps this becomes is a question of precedence:
> does the lowerdev split traffic first by mac address or by vlan tag.
> 

There's a few issues at play here. (1) the device driver has no idea which VLANs apply to which devs. So when adding a VLAN to upperdev, it just sends a notification to the lowerdev, saying please add VLAN N. The lowerdev doesn't have a clue which this applies to.

The second issue (2) is that partially, when deciding where traffic goes, the stack prioritises VLANs over macvlan upperdevs, so we end up routing traffic that should have gone to a macvlan into a VLAN attached to the lowerdev instead.

> I don't like your option 1: as you point out, it breaks current
> functionality, likely depended upon in some containers that are using
> macvlans to manage their traffic.  We don't know what's going on inside
> that container and I don't think we want to break its ability to split
> its own vlans.
> 

I don't really want to break the ability either, but look at this scenario:

upperdev macvlan created on some lowerdev, and put into a container.
upperdev creates VLAN 10 and starts receiving VLAN 10 traffic.

now, lowerdev creates VLAN 10 on the same lowerdev, possibly unaware of what the container did.
 
suddenly the upperdev macvlan no longer receives any VLAN 10 traffic.

Worse, the behavior is *different* depending on whether the macvlan is offloaded or not.

In an offloaded macvlan, at least from what i can tell, VLANs have not worked on any open source driver in the upstream kernel today, so the original case of upperdev creates VLAN 10 will just not receive traffic. This is a separate issue which I have a patch to resolve, but it still has problems with the leaked VLAN issue (where VLANs are added to the lowerdev directly).

You can argue that this is administrator error, but I'd rather fix it so that it's not possible one way or another. Unfortunately, I don't have any good way to figure out how to prevent this. The driver doesn't have any indication which VLANs apply to which devices.

> Like I said, I think the current behavior is mostly correct, but a
> version of option 2 might be good to help support offload of the
> mac+vlan pair into a macvlan channel.
> 
> sln
> 

I don't really like either option, so suggestions are welcome.

Thanks,
Jake

Powered by blists - more mailing lists