Bug 2030677 - BOND CNI: There is no option to configure MTU on a Bond interface
Summary: BOND CNI: There is no option to configure MTU on a Bond interface
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 4.10
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.10.0
Assignee: Marcin Mirecki
QA Contact: elevin
Depends On:
TreeView+ depends on / blocked
Reported: 2021-12-09 13:13 UTC by elevin
Modified: 2022-04-21 19:16 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2022-03-10 16:32:55 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github k8snetworkplumbingwg bond-cni pull 25 0 None open Allow setting bond MTU 2022-01-05 10:34:00 UTC
Github openshift bond-cni pull 29 0 None open Allow setting bond MTU (#25) 2022-01-27 16:29:20 UTC
Red Hat Product Errata RHSA-2022:0056 0 None None None 2022-03-10 16:33:08 UTC

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:

Steps to Reproduce:
1.Enable Bond CNI 
2.Create Bond interfece via NetworkAttachmentDefenition

Actual results:

Expected results:

Additional info:
Example for Bond NAD:
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
  name: bond-net1
  namespace: bond-test
  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)


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

  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.


Note You need to log in before you can comment on or make changes to this bug.