Validation on bridge-ports type definition to prevent switching loop

[etcshad0vv]

What happened:

We have identified that on vlan-aware bridge(vlan filtering 1) when we enslaved multiple vlan interfaces to act as trunk/access ports, and based on the fact that default pvid is set 1 for untagged frames on bridge, in case type set on NodeNetworkConfigurationPolicy for bridge-ports is trunk it will create loop when using multiple vlan interfaces as access/trunk ports, so i guess a validation step should be identifying when enslaving vlan subif to not allow you to set type as trunk, only access port should be allowed.

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):
You can test this with below definition

      - bridge:
          options:
            stp:
              enabled: false
          port:
          - name: dummy0.100
            vlan:
              enable-native: true
              mode: trunk
              trunk-tags:
                - id: 100
          - name: dummy0.200
            vlan:
              enable-native: true
              mode: trunk
              trunk-tags:
                - id: 200
        description: Linux bridge with dummy trunk ports
        ipv4:
          dhcp: false
          enabled: false
        ipv6:
          dhcp: false
          enabled: false
        name: br-dummy
        state: up
        type: linux-bridge
      - description: Dummy interface
        name: dummy0
        state: up
        type: dummy
        ipv4:
          enabled: false  
      - description: VLAN sub-interface using dummy0, id 100
        name: dummy0.100
        state: up
        type: vlan
        vlan:
            base-iface: dummy0
            id: 100
      - description: VLAN sub-interface using dummy0, id 200
        name: dummy0.200
        state: up
        type: vlan
        vlan:
            base-iface: dummy0
            id: 200

Bridge vlan output

br-dummy         1 PVID Egress Untagged

dummy0.100       1 PVID Egress Untagged
         2-4094

dummy0.200       1 PVID Egress Untagged
         2-4094

Anything else we need to know?:

Environment:

• kubernetes-nmstate image (use kubectl get pods --all-namespaces -l app=kubernetes-nmstate -o jsonpath='{.items[0].spec.containers[0].image}'):

oc get pods --all-namespaces -l app=kubernetes-nmstate -o jsonpath='{.items[0].spec.containers[0].image}'
registry.redhat.io/container-native-virtualization/kubernetes-nmstate-handler-rhel8@sha256:d25fe2735181b8bec769d87f37fe8b3eef23fc11f009e4b63c6fe96b83f0d838

• NetworkManager version (use nmcli --version)

nmcli --version
nmcli tool, version 1.22.8-5.el8_2

• Kubernetes version (use kubectl version):

oc version
Client Version: 4.5.0-202005291417-9933eb9
Server Version: 4.5.13
Kubernetes Version: v1.18.3+47c0e71

• OS (e.g. from /etc/os-release):

cat /etc/os-release
NAME="Red Hat Enterprise Linux CoreOS"
VERSION="45.82.202009181447-0"
VERSION_ID="4.5"
OPENSHIFT_VERSION="4.5"
RHEL_VERSION="8.2"
PRETTY_NAME="Red Hat Enterprise Linux CoreOS 45.82.202009181447-0 (Ootpa)"
ID="rhcos"
ID_LIKE="rhel fedora"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:8::coreos"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="OpenShift Container Platform"
REDHAT_BUGZILLA_PRODUCT_VERSION="4.5"
REDHAT_SUPPORT_PRODUCT="OpenShift Container Platform"
REDHAT_SUPPORT_PRODUCT_VERSION="4.5"
OSTREE_VERSION='45.82.202009181447-0'

[qinqon]

Hi, kubernetes-nmstate delegates the validation on nmstate, so this has to be implemented on nmstate, you can contact them here and ask about it, https://github.com/nmstate/nmstate#contact.

Also note that the nmstate version from kubernetes-nmsate is 0.2.z so maybe they have fixed it at 0.3.z or 0.4.z.

[etcshad0vv]

Thanks @qinqon will close this one then.

[phoracek]

@etcshad0vv if you open an RFE for nmstate, would you please link it here too? I'd be interested in tracking the progress of it. Thanks o/

[etcshad0vv]

Sure thing Petr

[etcshad0vv]

nmstate/nmstate#1413

[phoracek]

On top of the nmstate issue, we are yet to add a support for vlan-filtering to kubernetes-nmstate. We plan to start working on it in the near future.