Right, but it seems it's only when I create internal interface in OVS for use in the host system. If instead I create a system-level bond and use it for both vswitchd and vlan interfaces (like I've shown in my example) the resulting system interfaces, even though created on a bond that now has "master ovs-system", seem to be working fine even if vswitchd is not running.
I understand this is not a "proper" configuration, but I'm trying to understand what's wrong about it and how to measure its "wrongness" - frankly I don't even fully understand why it works at all, especially when vswitchd is turned off. Best Regards, Krzysztof On Tue, Jun 29, 2021, at 18:03, Ben Pfaff wrote: > Any use of OVS will bring down the network if vswitch fails. > > On Mon, Jun 28, 2021 at 03:26:00PM +0200, Krzysztof Klimonda wrote: > > Hi, > > > > Could you elaborate on that? Is there some documentation on this > > interaction I could read? Is this a potential performance issue, or > > offloading issue? What would be a better way to configure bonding with ovs > > that does not bring down network in case of vswitchd failure? > > > > Best Regards, > > Krzysztof > > > > On Fri, Jun 25, 2021, at 01:49, Ben Pfaff wrote: > > > Linux bonds and OVS bridges don't necessarily mix well. > > > > > > On Thu, Jun 24, 2021 at 10:25:58AM +0200, Krzysztof Klimonda wrote: > > > > Hi, > > > > > > > > I had a configuration like that in mind: > > > > > > > > # ip link add bond0 type bond > > > > # ip link set em1 master bond0 > > > > # ip link set em2 master bond0 > > > > # ip link add link bond0 name mgmt type vlan id 100 > > > > # ip link add link bond0 name ovs_tunnel type vlan id 200 > > > > > > > > # ovs-vsctl add-br br0 > > > > # ovs-vsctl add-port bond0 > > > > > > > > # ip link |grep bond0 > > > > 6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc > > > > noqueue master ovs-system state UP mode DEFAULT group default qlen 1000 > > > > 7: mgmt@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue > > > > state UP mode DEFAULT group default qlen 1000 > > > > # > > > > > > > > On Wed, Jun 23, 2021, at 18:51, Ben Pfaff wrote: > > > > > On Tue, Jun 22, 2021 at 09:58:49PM +0200, Krzysztof Klimonda wrote: > > > > > > Hi, > > > > > > > > > > > > I have tried the following configuration for the system-level > > > > > > network in the lab: > > > > > > > > > > > > > > > > > > +--vlan10@bond0 > > > > > > ens1--+ | > > > > > > ---bond0 (ovs-system)--+--vlan20@bond0 > > > > > > ens2--+ | > > > > > > +--vlan30@bond0 > > > > > > > > > > > > The idea is to plug bond0 into openvswitch so that I can add > > > > > > specific VLANs to my virtual topology, but push some of those VLANs > > > > > > into system without doing any specific configuration on the ovs > > > > > > side (for example, to have access to the management interface even > > > > > > if vswitchd is down). > > > > > > > > > > > > This seems to be working fine in my lab (there is access to the > > > > > > management interface - vlan10 - even when bond0 has ovs-system as > > > > > > master), but are there any drawbacks to such a configuration? > > > > > > > > > > It's hard to guess how you're implementing this. If you're doing it > > > > > with something like this: > > > > > > > > > > ovs-vsctl add-port br0 ens1 > > > > > ovs-vsctl add-port br0 ens2 > > > > > ovs-vsctl add-bond br0 bond0 ens1 ens2 > > > > > ovs-vsctl add-port br0 vlan1 tag=1 -- set interface vlan1 > > > > > type=internal > > > > > ovs-vsctl add-port br0 vlan2 tag=2 -- set interface vlan2 > > > > > type=internal > > > > > ovs-vsctl add-port br0 vlan3 tag=3 -- set interface vlan3 > > > > > type=internal > > > > > > > > > > then it ought to work fine. > > > > > > > > > > > > > > > > > -- > > > > Krzysztof Klimonda > > > > [email protected] > > > > > > > > > -- > > Krzysztof Klimonda > > [email protected] > -- Krzysztof Klimonda [email protected] _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
