On Thu, May 4, 2017 at 9:43 AM, Jiri Benc <jb...@redhat.com> wrote: > On Thu, 4 May 2017 09:37:00 +0000, Chiappero, Marco wrote: >> This looks conceptually wrong. Yes, ipvlan works at L3 (which is an >> implementation detail anyway), but slaves are Ethernet interfaces and >> should behave as much as possible as such regardless, with an >> individual MAC address assigned. > > Isn't the proper fix then converting ipvlan interfaces to be L3 only > interfaces? I.e., ARPHRD_NONE? There's not much ipvlan can do with > arbitrary Ethernet frames anyway. Of course, a flag to switch to the > new behavior would be needed in order to preserve backwards > compatibility. > There is mode = L3/L3s for that.
> This patchset looks very wrong. For proper support of multiple MAC > addresses, we have macvlan and it's pointless to add that to ipvlan. > And doing some kind of weird MAC NAT in ipvlan just to satisfy broken > tools that can't cope with multiple interfaces with the same MAC address > is wrong, too. Those tools are already broken anyway, there's nothing > preventing anyone to set the same MAC address to multiple interfaces. > I suppose those tools don't work with bonding and bridge, either? > +1 >> So, either we fix this by forcing slaves to stay in sync with master, > > Yes, that's the correct behavior. Well, at least as correct as one can > get with the ipvlan broken design of pretending that an interface is L2 > when in fact, it is not. > conceptually view it as a single link (one L2) but mux/demux @ L3 for multi-ns world with different routing needs without needing additional packet processing. > Jiri
