Bug 2030677
Summary: | BOND CNI: There is no option to configure MTU on a Bond interface | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | elevin |
Component: | Networking | Assignee: | Marcin Mirecki <mmirecki> |
Networking sub component: | multus | QA Contact: | elevin |
Status: | CLOSED ERRATA | Docs Contact: | |
Severity: | medium | ||
Priority: | medium | CC: | aos-bugs, cgoncalves, fbaudin, grajaiya, sscheink |
Version: | 4.10 | Keywords: | FutureFeature |
Target Milestone: | --- | ||
Target Release: | 4.10.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2022-03-10 16:32:55 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
elevin
2021-12-09 13:13:59 UTC
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 |