Implement configurators for VLANs and Bonds

[milan-zededa]

This is the last missing piece needed to enable support for VLANs
and LAGs for EVE management and local network instances.
This functionality is described and designed in this document:
https://wiki.lfedge.org/display/EVE/EVE+VLAN+support+-+create+VLAN+and+bond+interfaces

A part of this commit is also a fix for Switch network VLANs,
where we forgot to configure the network uplink port as trunk, therefore
all tagged packets coming in and out of it would be dropped by bridge VLAN
filtering. As a result, VLANs were working correctly only for air-gapped
switch networks.

Test for VLANs and LAGs: lf-edge/eden#753

Signed-off-by: Milan Lenco milan@zededa.com

[eriknordmark]

The single "k" string raises a question about where and how we do the k swap.

If we have a vlan I assume we create vlan10 on top of eth0 and then we do a kvlan10 rename and create a vlan10 bridge. Is that correct?
In such a case do we also allow creating a network instance directly on eth0 (for untagged frames?) or not. That would end up causing a eth0->keth0 rename etc.

I don't think bonds cause the same potential complexity since a child of a bond is exclusive hence can not be used directly AFAIK. But bond0 could be used by both a local network instance and a switch network instance (just like vlan10 can be) which means we'd need a kbond0 rename AFAIU

[milan-zededa]

If we have a vlan I assume we create vlan10 on top of eth0 and then we do a kvlan10 rename and create a vlan10 bridge. Is that correct?
In such a case do we also allow creating a network instance directly on eth0 (for untagged frames?) or not. That would end up causing a eth0->keth0 rename etc.

Actually it was not planned to support this case, at least not for now (design document is here, note the sentence "NIM service should take care of not creating the kethx interfaces for physical IO adapters that are underlying adapters for other Vland or bond adapters"). Mostly to simplify (both EVE and the controller), we decided that it would not be allowed to attach network instance to a port which has higher-layer adapters (see this diagram).
So if eth has VLANs then it will not be possible to use it directly anymore. Do you think that this is a too much of a limitation for the future users of EVE?

I don't think bonds cause the same potential complexity since a child of a bond is exclusive hence can not be used directly AFAIK. But bond0 could be used by both a local network instance and a switch network instance (just like vlan10 can be) which means we'd need a kbond0 rename AFAIU

Yes, renaming is done and bridge is created for bond IF there is nothing defined on top of it (like vlans).

[eriknordmark]

So if eth has VLANs then it will not be possible to use it directly anymore. Do you think that this is a too much of a limitation for the future users of EVE?

I think that restriction is fine (at least for now) as long as we enforce it in the code and return an error if a NI tries to use it directly.

[milan-zededa]

So if eth has VLANs then it will not be possible to use it directly anymore. Do you think that this is a too much of a limitation for the future users of EVE?

I think that restriction is fine (at least for now) as long as we enforce it in the code and return an error if a NI tries to use it directly.

It is enforced in zedagent in parseSystemAdapterConfig (tested by TestInvalidLowerLayerReferences) and error is returned in DevicePortStatus. Basically we do not allow SystemAdapter to reference port which is used by higher-layer adapters (and NIs reference system adapters, not ports directly).

[eriknordmark]

LGTM