[2.0,2.1] If I change what vlan an interface is on, then I cannot return it

[LaMont Jones]

It's possible that the VLAN where an interface lives is actually one that fails the validation we put on changing vlans in the api. See the attached file.

We need to relax the restrictions on what vlan can be assigned, at least somewhat.

[LaMont Jones (lamont)]

Recommissioning the node will restore the configuration.

[LaMont Jones (lamont)]

The configuration for the screenshots:

On the rack, ens4 is a trunkport, and the downlink to controlled networks. ens3 is the uplink to the internet and outside world.

On the host, ens3 is a switch accessport, untagged on vlan 4. It needs to be untagged, since dhcp doesn't get tagged.
Note that, because the host got an address from 172.19.0.0/16 during commissioning, it has a link to that subnet, which is linked to the vlan, which is how we know that the untagged interface is connected to vlan 4.

With this bug, it is impossible to create an interface via the api (on a new or existing machine), if the rack is using vlan tagging. If we wish to disallow "clamped ports" (trunkport with a native vlan other than vlan 1), then we should reject creating a vlan child of a physical interface that has has a non-zero vid. That is, I should be able to use the API to create what we see in the screenshots, but I should not be able to create ens3.5 on the host.

As a further note, we need to remember that there is ALWAYS a native vlan for a trunked port -- the default is vlan 1, and cisco doesn't show default items in the config dump, so it's not shown. Several best-practice documents recommend setting the native vlan port to something other than vlan 1 for all trunk ports, to cover a corner case that could allow a rogue machine to inject packets into vlan 1.

[Andres Rodriguez (andreserl)]

Hi!

**This is an automated message**

We believe this is may no longer be an issue in the latest MAAS release.
Due to the original date of the bug report, we are currently marking it
as Invalid. If you believe this bug report still valid against the
latest release of MAAS, or if you are still interested in this, please
re-open this bug report.

Thanks