Description of problem: When a VM is connected to a bridge using a NetworkAttachmentDefinition with a VLAN ID, we can see that the VM receives packets from the VLAN ID and also the untagged packets from the bridge. Version-Release number of selected component (if applicable): OCP 4.10.51 OpenShift Virtualization 4.10.8 How reproducible: Always Steps to Reproduce: 1. Create a bridge with a physical interface: ``` apiVersion: nmstate.io/v1 kind: NodeNetworkConfigurationPolicy metadata: name: br-extnet-enp3s0-policy-workers spec: desiredState: interfaces: - description: enp3s0 interface name: enp3s0 state: up type: ethernet - bridge: options: stp: enabled: false port: - name: enp3s0 description: Linux bridge with enp3s0 as a port ipv4: dhcp: true enabled: true name: br-extnet state: up type: linux-bridge nodeSelector: node-role.kubernetes.io/worker: "" ``` 2. Create a NAD using the bridge and a VLAN ID: ``` apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: br-extnet-network namespace: jorti spec: config: '{ "cniVersion": "0.3.1", "name": "br-extnet-network", "type": "cnv-bridge", "bridge": "br-extnet", "vlan": 1000, "macspoofchk": false }' ``` 3. Create a VM connected to the NAD: ``` domain: devices: interfaces: - bridge: {} macAddress: 02:a2:a6:00:00:06 model: virtio name: default networks: - multus: networkName: br-extnet-network name: default ``` Actual results: In the node we can see that the veth of the VM is also using VLAN 1: ``` sh-4.4# bridge -d vlan port vlan-id vetheb545c41 1 Egress Untagged <---------- 1000 PVID Egress Untagged ``` A tcpdump in the VM reveals packets not belonging to VLAN 1000. Expected results: The VM must be connected only to VLAN 1000 Additional info: I see a similar issue reported upstream: https://github.com/containernetworking/plugins/issues/667
Juan, thanks for reporting this. The team will look into it ASAP.
https://github.com/containernetworking/plugins/pull/875 proposes a well received solution. It is still under a review
We will attempt a backport. It can be tracked via https://bugzilla.redhat.com/show_bug.cgi?id=2209318
Verified with CNV 4.13.1 cnv-containernetworking-plugins-rhel9:v4.13.1-2 The verification scenario is is kind of a combination between the one detailed in the BZ description with the comment #3. 1. Create this policy: apiVersion: nmstate.io/v1 kind: NodeNetworkConfigurationPolicy metadata: name: br-extnet spec: desiredState: interfaces: - bridge: options: stp: enabled: false port: - name: eno3 description: Linux bridge with eno3 as a port ipv4: enabled: true dhcp: false address: - ip: 192.168.6.1 prefix-length: 24 name: br-extnet state: up type: linux-bridge nodeSelector: kubernetes.io/hostname: cnv-qe-17.cnvqe.lab.eng.rdu2.redhat.com 2. Create this NAD: apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: br-extnet-network namespace: yoss-ns spec: config: '{ "cniVersion": "0.3.1", "name": "br-extnet-network", "type": "cnv-bridge", "bridge": "br-extnet", "vlan": 1000, "macspoofchk": false, "preserveDefaultVlan": false }' * Note that you must add the `"preserveDefaultVlan": false`, which did not appear in the original scenario, in spec.config (as it is default true). 3. Create this VM: apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: metadata: name: vm1 namespace: yoss-ns spec: running: false template: spec: domain: devices: disks: - name: containerdisk disk: bus: virtio - name: cloudinitdisk disk: bus: virtio interfaces: - name: default bridge: {} - name: test-br bridge: {} resources: requests: memory: 1G cpu: cores: 2 networks: - name: default pod: {} - multus: networkName: br-extnet-network name: test-br volumes: - name: containerdisk containerDisk: image: quay.io/openshift-cnv/qe-cnv-tests-fedora-staging:37 - name: cloudinitdisk cloudInitNoCloud: userData: |- #cloud-config password: password chpasswd: { expire: False } nodeSelector: kubernetes.io/hostname: cnv-qe-17.cnvqe.lab.eng.rdu2.redhat.com 4. Run the VM (virtctl start vm1 ) 5. Once the VM up and running, I enter the VM's console and manually set an IP address to its secondary interface (192.168.6.11, which is in the same subnet as the IP address assigned to the bridge in the NNCP). 5. Enter the selected node (the one on which the bridge is created and the VM is running), and run sh-5.1# arping -A -I br-extnet 192.168.6.1 ARPING 192.168.6.1 from 192.168.6.1 br-extnet 6. In the VM - sniff the traffic on the secondary NIC: [fedora@vm1 ~]$ sudo tcpdump -lni eth1 arp -vv [ 2523.778526] device eth1 entered promiscuous mode dropped privs to tcpdump tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes The output remains empty, because the traffic from the node, which is not directed to the VLAN to which eth1 on the VM belongs, is filtered. For extra verification - when removing the `"preserveDefaultVlan": false` entry from the NetworkAttachmentDefinition's spec.config (and recreating the NAD and the VM), the traffic is not filtered, and tcpdump catch the traffic: [fedora@vm1 ~]$ sudo tcpdump -lni eth1 arp -vv [ 2523.778526] device eth1 entered promiscuous mode dropped privs to tcpdump tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes 14:27:17.321752 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.6.1 is-at 78:ac:44:63:79:82, length 28 14:27:18.321778 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.6.1 is-at 78:ac:44:63:79:82, length 28 14:27:19.321812 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.6.1 is-at 78:ac:44:63:79:82, length 28 14:27:20.321853 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.6.1 is-at 78:ac:44:63:79:82, length 28
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (OpenShift Virtualization 4.13.1 Images), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2023:3686