Bonding SR-IOV interfaces fails about bond-cni HOT 3 OPEN

@howels can you show the CNI error? Either from the Pod description or from the Multus logs? A pod stuck in container creating usually means the CNI isn't able to create the interface at all and returns an error.

Also - where did you get the bond config?
"mode": "802.3ad",
"xmit_hash_policy": "layer3+4",

Aren't supported in the main branch right now. 802.3ad will be accepted and set, but xmit_hash_policy isn't part of the config.

c/f #17

from bond-cni.

I found that this works, but only when I moved to SLES 15 and removed the default network statement ( v1.multus-cni.io/default-network: bond-net1). Otherwise I would get a message saying that my slave interfaces could not be found.

As for the bond config, this was just the normal way that we configure bonds so I re-used that for my SR-IOV bonds. What are your defaults for xmit_hash_policy?

from bond-cni.

The default setting can be per-OS I think, but we expect it to be 0, which is hashing based on the MAC. The real impact of setting this depends on the network set up - but we can definitely move to include it from #17 if it meets your use case.

v1.multus-cni.io/default-network: bond-net1

I'll try to track down why this is interfering with the bond network. I think this is a new setting for Multus, and it may be an issue because of the order in which it's ran compared to the bonding command.

from bond-cni.