Open vswitch with libvirtd

[DanPartelly]

Is a vagrant/libvirtd config able to use open vswitch as a bridge instead of a Linux one or it's only a clab feature ?

[ipspace]

According to RedHat, you can make it work https://www.redhat.com/sysadmin/libvirt-open-vswitch but you have to create the OVS switches and the libvirt networks "manually" whereas vagrant-libvirt plugin together with libvirt itself automatically creates them for us as soon as a network name is mentioned in the Vagrantfile.

The only reason we have OVS for containers is because @jbemmel implemented it, and it was no more work than what we had to do with Linux bridges anyway. That's not the case for libvirt.

Anyway, why would you want to use Open vSwitch? Please don't tell me "just so the stupid firewall rules wouldn't apply"

[DanPartelly]

Im exploring the limits of possible host side configurations rather than really wanting a vSwitch bridge for anything. In an ideal world I would have never cared, but I had to look into host side because the issues on my distros.

The only big ticket feature I really want in networklab at the present time is support for fd.io Vector Packet Processing images/containers , both naked and with Linux Control Plane plugin + FRR + racoon, and this is something im willing to put work in towards the end of this year.

[ipspace]

OK, so let's shelve the OVS idea, fd.io is much more interesting.

If possible, I would go for containers. That might make it possible (depending on how they implemented it) to run fd.io in GitHub Codespaces. Also, it would make sense to have control plane (or how else are you going to configure it), where we could leverage FRRouting. In the ideal world, you'd only need a container building procedure (like what we have for Bird right now) and a device using frr as its parent (so it would inherit most of frr code) and with a different initial device/VRF/VLAN configuration.

[ssasso]

Potentially you don't even need to have different initial device configuration template if you use the VPP LCP plugin written by Pim (see i.e., https://ipng.ch/s/articles/2021/12/23/vpp-linux-cp-virtual-machine-playground/ - this is talking about a VM, but it should be easily applied to containers IF DPDK can run with veth pairs.

Btw, from that post you can find the entire post series.

[DanPartelly]

The only way to leverage FRR or other routing demons is LCP plugin. Naked VPP does not support routing protocols as far as I know. As for native management, VPP offer a command line shell, much like the FRR shell.

One item we have to do is figure out what can be configured through LCP and what cannot be configured and needs the VPP shell. Basic stuff such as addressing & routing setup should work with LCP.

Vpp can be used with containers. It appears that DPDK plugin for the DPDK backend is not used in this case.

https://fdio-vpp.readthedocs.io/en/latest/usecases/containers.html

[DanPartelly]

And their own "test bench" uses docker: https://s3-docs.fd.io/vpp/24.06/usecases/vpp_testbench/index.html