[RFC] network: expose per-port VLAN settings (bridge-access, bridge-pvid, bridge-vids) for bridge ports

[RFC] network: expose per-port VLAN settings (bridge-access, bridge-pvid, bridge-vids) for bridge ports

[Matthis Eicher]

Hi all,

I'd like to work on a small feature and wanted to check the approach with you before diving into programming and sending patches.

Problem
-------
A VLAN-aware Linux bridge is a common way to use a Proxmox VE host as a small switch: several physical NICs are enslaved to one bridge and each port is either an access port for one VLAN or a trunk for a subset of VLANs, optionally with one native (untagged) VLAN, e.g. for access points or switches with an untagged management network. ifupdown2 supports this per port:

    auto enp3s0
    iface enp3s0 inet manual
            bridge-access 10

    iface enp5s0 inet manual
            bridge-vids 10 40 50 60

    iface enp1s0f1 inet manual
            bridge-pvid 10
            bridge-vids 10 40 50 60

PVE already preserves these lines when saving the network config, but they are neither shown nor editable via API/GUI. The port looks like an untagged member of the bridge in the network view, which is misleading when troubleshooting, and the only way to change it is editing /etc/network/interfaces by hand.

Related: #2764 (open, which also mentions bridge-access/bridge-vids on ports in its description), #3128 (closed as duplicate of #2764), #3893 (bridge-level bridge-vids, fixed in pve-manager 8.2.9). In #5802 it was suggested to expose options that ifupdown2 already supports via the existing parser/writer; this would follow the same idea.

Proposal
--------
- pve-common (INotify): parse/write `bridge-access`, `bridge-pvid` and `bridge-vids` for eth/bond/vlan interfaces, reusing the pve-vlan-id-or-range format added for #3893.
- pve-manager (API2/Network): add optional parameters for these interface types:
  - `bridge_access` (single VLAN ID) for an access port,
  - `bridge_port_pvid` (single VLAN ID, native/untagged VLAN) and `bridge_port_vids` (list/ranges, tagged VLANs) for a trunk port.
  `bridge_access` is mutually exclusive with the other two. All of them are accepted regardless of the current bridge membership, so a port can be prepared before it is added to a bridge (the settings only take effect once the interface is a port of a VLAN-aware bridge).
- widget-toolkit (NetworkEdit): show the fields under "Advanced" (e.g. a mode selector access/trunk), so the default dialog stays as simple as today. If the interface is currently not a port of a VLAN-aware bridge, show a hint that the setting has no effect until it is.
- Network view: optionally a column/tooltip showing the port's access VLAN, or native and allowed VLANs, marked as inactive where they currently have no effect.
- pve-docs: short example in the VLAN section.

The bridge's own `bridge-pvid` (untagged VLAN of the bridge itself) is likewise not exposed yet; it could be added to the bridge dialog next to the existing bridge-vids field in the same series or later.

Open questions
--------------
1. Is this something you'd accept in general, or would you rather see it handled via SDN?
2. Any preference on parameter naming (`bridge_access`, `bridge_port_pvid`, `bridge_port_vids`)?
3. Should the fields live on the port (eth/bond) dialog as proposed, or on the bridge (as a per-port table)?
4. If a bridge's vlan-aware flag is disabled, or a port is removed from the bridge, the port settings silently stop having an effect. Should the API/GUI warn about that, keep the settings as they are, or remove them?
5. Should the bridge-level `bridge-pvid` be part of this series or a separate one?

I'm happy to send a patch series for common, widget-toolkit, manager and docs once the direction is clear.

Best,
Matthis Eicher