Bug 2030677

Summary: BOND CNI: There is no option to configure MTU on a Bond interface
Product: OpenShift Container Platform Reporter: elevin
Component: NetworkingAssignee: 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.10Keywords: 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
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"}
}'

Comment 1 Franck Baudin 2021-12-13 15:20:45 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!

Comment 2 Marcin Mirecki 2021-12-15 17:29:42 UTC
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.

Comment 3 Franck Baudin 2021-12-16 15:27:35 UTC
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.

Comment 8 elevin 2022-02-06 22:08:39 UTC
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"}}

Comment 10 errata-xmlrpc 2022-03-10 16:32:55 UTC
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