[Feature Request] Allow multiple interfaces in the provider network

[abasitt]

Description

In the providernework, we have two resources
1- defaultInterface
2- customInterfaces

Both of these resources accept single interface. I think we should extended custominterfaces to accept multiple interfaces e.g.
customInterfaces:
- interface: eth1,eth2

We have a discussion on slack about this feature. The reason, I want to do this is because I want to have multiple NICs to be part of the same providernetwork. I can't use bonding because both NICs are connected to two different standalone individual switches and many of the endpoints are orphan ports (only accessible via single NIC).

Who will benefit from this feature?

No response

Anything else?

No response

[zbb88888]

can multus support this ？

[abasitt]

With multus multiple interfaces like this can be injected directly in to the pod but I don't think so multus can do anything like that to create br-provider in OVS and plumb multiple NICs to it.

[zbb88888]

oh, I get it, for the case multiple NICs to be part of the same provider network.

if inserting two nics to one bridge, does the Ovs bridge know which one to forward?

[abasitt]

I believe it will know, since OVS is a layer2 bridge and based on mac learning, it will know which underlay NIC to pick for layer2 forwarding.

[zbb88888]

Does OVS has any doc about how to use in this case？

[zhangzujian]

Generally, Kube-OVN works as CNI and it is not responsible for connecting physical networks. If more than one nics on the same host are added to the same OVS bridge, while the nics are connected to the same physical bridge, there is a possible risk of network failure, such as broadcast storm.

The solution is to add a new linux bridge mastering the two nics, and use the linux bridge as the provider network interface. This may bring few complexities, but this is not a common user scenario. On the other side, only one host need to work as a bridge between different physical switches, how much will the complexities be?

[abasitt]

I couldn't find the exact use-case in the official doc. but this is the closest.
https://docs.openvswitch.org/en/latest/faq/vlan/

e.g.
$ ovs-vsctl add-br br0
$ ovs-vsctl add-port br0 eth0
$ ovs-vsctl add-port br0 eth1
$ ovs-vsctl add-port br0 eth0 tag=10
$ ovs-vsctl add-port br0 eth1 tag=10

[abasitt]

What difference would that make if there is a storm in the physical network and if linux bridge is infront of it ? I am not OVS expert but i am assuming OVS will have same level of protection and flags like STP that's also available in linux bridge?

[zhangzujian]

What difference would that make if there is a storm in the physical network and if linux bridge is infront of it ? I am not OVS expert but i am assuming OVS will have same level of protection and flags like STP that's also available in linux bridge?

Preovider network is a cluser-wide resource. If user sets incorrect interface names in a provider network by accident, all nodes may be influenced. The main point is that Kube-OVN is a CNI plugin and what you need is out of its responsibility. On the other hand, your requirement is not a comment user scenario, while it will bring unnecessary complexities to Kube-OVN.

[abasitt]

I agree the use case that I am trying is probably not the common scenario. At the moment I do have a workaround of using linux bridge and then use provider-network on top.