Description of problem: Can not configure MTU for Bond interface Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1.Enable Bond CNI 2.Create Bond interfece via NetworkAttachmentDefenition 3. Actual results: Expected results: Additional info: Example for Bond NAD: apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: bond-net1 namespace: bond-test spec: config: '{ "type": "bond", "cniVersion": "0.3.1", "name": "bond-net1", "ifname": "bond0", "mode": "balance-tlb", "failOverMac": 1, "linksInContainer": true, "miimon": "100", "links": [ {"name": "net1"}, {"name": "net2"} ], "capabilities": {"mac": true, "ips": true}, "ipam": {"type": "static"} }'
As long as all SR-iov VFs have the same PTU, this MTU should use. And if the MTU is different, the bond creation should fails. For reference, SR-IOV mtu is configured in the SriovNetworkNodePolicy (see https://docs.openshift.com/container-platform/4.9/networking/hardware_networks/configuring-sriov-device.html) Thanks!
When we define a linux bond, the slaves take the mtu value of the bond. Should we not follow this in the cni? Add the mtu to the network configuration, and update the bond cni to update the bond (with the slaves updated automatically). Setting bond mtu based on the slave mtu would be quite counter-intuitive.
Linux bond behaviour has beer designed for NICs, not VFs. Here is what is different with VFs: 1/ SR-IOV CNI configures the MTU of the VFs 2/ bond CNI take control of VFs configured by SR-IOV CNI 2.1/ today, bond CNI can just reuse the configured MTU, and fail to create the bond if the MTU is not identical for all VFs. ANd if the MTU needs to be changed, it can be done with escalated privileges by the pod (NET_ADMIN) 2.2/ we could enhance the behaviour to allow bond-CNI to changhe the MTU of the VFs but it cannot be greater than the PFs MTU, and the origibnal MTU should be set back to the original value when a bond is destroyed so the VFs can be allocated to a pod without bond and have the expected behaviour. So we can add the MTU parameter in OCP4.11 but this is not MVP for OCP4.10, where bond CNI will be delivered as Tech Preview.
Server Version: 4.10.0-rc.1 ============== 4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 789 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 9a:87:96:5f:d5:6e brd ff:ff:ff:ff:ff:ff spec: config: |- {"type": "bond", "cniVersion": "0.3.1", "name": "bond-net", "ifname": "bond0", "mode": "active-backup", "failOverMac": 1, "linksInContainer": true, "miimon": "100", "mtu": 789, "links": [{"name": "net1"},{"name": "net2"}], "capabilities": {"mac": true, "ips": true}, "ipam": {"type": "static"}}
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 (Moderate: OpenShift Container Platform 4.10.3 security update), 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/RHSA-2022:0056