Feature Request: systemd-networkd support for ovs (openvswitch) #2613

aboe76 · 2016-02-14T19:40:57Z

As stated on the devel mailinglist:
https://lists.freedesktop.org/archives/systemd-devel/2015-May/031959.html

I don't know ovs that well, but as I mentioned before: if they have an
OK API I think it might make sense to add native ovs support to
networkd (and nspawn).

Lennart

In the mailinglist (http://openvswitch.org/pipermail/dev/2015-January/050711.html) of openvswitch they point to https://tools.ietf.org/html/rfc7047

This will be a great addition to bridge and macvlan support.

Another source of information:
https://keepingitclassless.net/2014/08/sdn-protocols-3-ovsdb/

The text was updated successfully, but these errors were encountered:

poettering · 2016-02-15T12:47:05Z

Hmpf, a HTTP/JSON-RPC interface appears a bit too high-level for the low-level tool that networkd is...

johannbg · 2016-02-15T14:04:46Z

I have to ask since in the OVS setup you have three OVS daemons running
ovs-vswitchd, which is the core implementation of the switch
ovsdb-server, which manipulates the database of the vswitch configuration and flows
ovs-brcompatd which keeps the compatibility with the traditional bridges ( which should work with networkd already )

And you have two management commands
ovs-vsctl to manage openvswitch.
ovs-appctl to manage the ovs-vswitchd

Where does systemd/networkd fit in the above picture?
It needs to provide api which tools such as ovs might use but what else?

aboe76 · 2016-02-15T14:17:11Z

In my opinion systemd-network should provide the basic interfaces and mark them usable for ovs.
all the other configs should be done within ovs with ovs-vctl and ovs-appctl

something like: netdev options:
DEVICETYPE=ovs
TYPE=OVSBridge

and give the interface an ip..

nothing special..

johannbg · 2016-02-15T16:29:19Z

What's the differences to ovs bridge and regular linux bridge since afaikt you have to create a regular linux bridge and virtual ethernet interfaces and then associate those to ovs via ovs-vsctl add-br/add-port and networkd already supports regular linux bridge along with virtual ethernet interface ?

aboe76 · 2016-02-15T18:38:26Z

I think the main difference is the kernel module loading a different type of interface, but i'm not an ovs dev so I can be wrong

something like this what is in debian with ifupdown:
https://github.com/openvswitch/ovs/blob/master/debian/openvswitch-switch.README.Debian

mabra · 2016-07-31T01:10:36Z

First: I am not a linux expert ... I needed a whole week to make openvswitch running with debian (jessie).
The reason is more-fold, but the main problem is, at least (but not only) an uncoordinated systemstart.
The systemd.networking is invoking 'ovs-vsctl' to configure a bridge, which, in turn, needs the 'ovsdb-server', which starts later. What is need for the effected parties is coordination, which might be implemented better with a systemd unit and more explicit dependencies.
I am just on the way, to open a bug, for the short time - but this is another story.
BTW: OpenVswitch looks (at least ..) more feature rich then a linux bridge. If offers a centralized database to manage all bridges on a campus, it supports sFlow and NetFlow, it supports bidirectional port mirroring and traffic organizing (forwarding) by flows and not only traditonal switches (and routers!).
BTW, what is announced in the menioned README.Debian is not fully implemented. I needed a lon time to step through and find out, that "OVSPatchPort" is not implemented (what I need to connect two switches). I do not know, if this a packaging problem or what else, but I found a (dirty) workaround.

honsys · 2017-06-17T15:45:41Z

More than a year has passed; has there been any work / progress on this? I'd like to use systemd-networkd with OVS ...

I succeeded with a source install of openvswitch 2.7.0 recently ... building Centos-7 RPMs
with the OVS kernel module ...

untar the downloaded tar-file and cd to the top-level directory (./openvswitch-2.7.0) then:

yum install kernel-devel python-devel python34-devel
./configure --with-linux=/lib/modules/$(uname -r)/build

edit the resulting rhel/openvswitch-fedora.spec, changing:
"python3-devel" to "python34-devel" in the "Requires" line;
and also change "python2-openvswitch" to "python-openswitch" everywhere.

make rpm-fedora

The make should create:
ls -1 openvswitch-2.7.0/rpm/rpmbuild/RPMS/x86_64/
openvswitch-2.7.0-1.el7.centos.x86_64.rpm
openvswitch-debuginfo-2.7.0-1.el7.centos.x86_64.rpm
openvswitch-devel-2.7.0-1.el7.centos.x86_64.rpm
openvswitch-ovn-central-2.7.0-1.el7.centos.x86_64.rpm
openvswitch-ovn-common-2.7.0-1.el7.centos.x86_64.rpm
openvswitch-ovn-docker-2.7.0-1.el7.centos.x86_64.rpm
openvswitch-ovn-host-2.7.0-1.el7.centos.x86_64.rpm
openvswitch-ovn-vtep-2.7.0-1.el7.centos.x86_64.rpm

yum install the RPMs and note the new binaries in /usr/bin .. and equally important a coupla new
items in /etc/sysconfig/network-scripts/{ifup-ovs,ifdown-ovs} ... This simple bridge conf works fine
with ifup-ovs (but may crash the system with ifup!):

cat /etc/sysconfig/network-scripts/ifcfg-ovsbr0
DEVICE=ovsbr0
DEVICETYPE=ovs
TYPE=OVSBridge
ONBOOT=no
HOTPLUG=no
BOOTPROTO=static
IPADDR=172.17.0.1
NETMASK=255.240.0.0
#GATEWAY=172.16.0.1

Before the ifup-ovs, "lsmod | grep open" yields nothing.
After ifup-ovs, "lsmod | grep open" yields:

openvswitch 106775 14
nf_nat_ipv6 14131 1 openvswitch
nf_defrag_ipv6 35104 2 openvswitch,nf_conntrack_ipv6
libcrc32c 12644 1 openvswitch
nf_nat_ipv4 14115 2 openvswitch,iptable_nat
nf_nat 26147 5 openvswitch,nf_nat_ipv4,nf_nat_ipv6,xt_nat,nf_nat_masquerade_ipv4
nf_conntrack 111302 8 openvswitch,nf_nat,nf_nat_ipv4,nf_nat_ipv6,xt_conntrack,nf_nat_masquerade_ipv4,nf_conntrack_ipv4,nf_conntrack_ipv6

And "ps -ef|grep ovs" reveals ovsdb-server ovs-vswitchd up and running ...

Soooo ... seems it should be possible to incorporate ifup-ovs and ifdown-ovs into the magic
of systemd-networkd ... Perhaps it has been? If so, what do we need to know/do?

Cheers,
--david

keszybz · 2017-06-17T20:55:28Z

AFAIK, no work has been done on this.

honsys · 2017-06-18T12:56:25Z

Thanks for the feedback; Any notion of what it would take to make a stab at it? Perhaps
with some pointers, I can try.

Also I noticed a typing lapse in a key sentence of mine ... please accept my apologies with
this correction: change "python2-openvswitch" to "python-openswitch" everywhere ...

aboe76 · 2017-06-18T13:38:16Z

@honsys , see my comment: #2613 (comment)
I think letting systemd-networkd create a ovs bridge instead of a normal bridge is a good first step.

honsys · 2017-06-18T13:48:07Z

BTW I've also been able to use an OVS bridge stand-alone -- no legacy linux bridges.
KVM-libvirt "virt-install --network" option should point to a network created via "virsh net-create"
using a simple xml which provides the name of the OVS bridge setup with the ifup-ovs. The
resulting vNICs in the guest are attached directly to the OVS bridge. Docker can also be
instructed to use the same OVS bridge with a tad more work using ovs-docker CLI provided
with the install ... More later ...

Cheers,
--david

samarium · 2018-09-13T11:47:49Z

It seems like systemd can at least be convinced to poke openvswitch and configure the interfaces. Don't really need systemd to configure OVS, just cooperate with the switch fabric as maintained by OVS.

Tested using Ubuntu bionic.

# ovs-vsctl show
a9de4a5c-a1c5-45d6-a1c0-414a2e5f67d6
    ovs_version: "2.9.0"
# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 52:54:3e:a0:a0:a0 brd ff:ff:ff:ff:ff:ff

Build basic OVS bridge and some ports:

ovs-vsctl add-br ovsbr0
ovs-vsctl add-port ovsbr0 ovs1 tag=1 -- set interface ovs1 type=internal
ovs-vsctl add-port ovsbr0 ovs2 tag=2 -- set interface ovs2 type=internal

# ovs-vsctl show
a9de4a5c-a1c5-45d6-a1c0-414a2e5f67d6
    Bridge "ovsbr0"
        Port "ovs2"
            tag: 2
            Interface "ovs2"
                type: internal
        Port "ovs1"
            tag: 1
            Interface "ovs1"
                type: internal
        Port "ovsbr0"
            Interface "ovsbr0"
                type: internal
# ip addr
...
3: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether ea:f9:f5:25:b7:15 brd ff:ff:ff:ff:ff:ff
4: ovsbr0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether b6:84:10:a9:6f:4a brd ff:ff:ff:ff:ff:ff
5: ovs1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 22:fc:bc:29:bc:99 brd ff:ff:ff:ff:ff:ff
6: ovs2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 7a:4c:5f:53:fb:42 brd ff:ff:ff:ff:ff:ff
# networkctl
IDX LINK             TYPE               OPERATIONAL SETUP     
...
  3 ovs-system       ether              off         unmanaged 
  4 ovsbr0           ether              off         unmanaged 
  5 ovs1             ether              off         unmanaged 
  6 ovs2             ether              off         unmanaged 

6 links listed.

Create system-networkd configuration for OVS interfaces in /etc/systemd/network and then restart systemd-networkd

# cd /etc/systemd/network
# ls
50-ovsbr0.network  61-ovs1.network  62-ovs2.network
#
# cat 50-ovsbr0.network 
[Match]
Name=ovsbr0
#
# cat 61-ovs1.network 
[Match]
Name=ovs1

[Network]
Address=10.16.26.16/24
Gateway=10.16.26.19
DNS=10.16.26.19
Domains=q.we.rty.uiop
IPForward=yes
#
# cat 62-ovs2.network 
[Match]
Name=ovs2

[Network]
Address=250.2.16.1/8
# 
# systemctl restart systemd-networkd
# networkctl
IDX LINK             TYPE               OPERATIONAL SETUP     
...
  3 ovs-system       ether              off         unmanaged 
  4 ovsbr0           ether              carrier     configured
  5 ovs1             ether              routable    configured
  6 ovs2             ether              routable    configured

6 links listed.
# ip addr
...
4: ovsbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether b6:84:10:a9:6f:4a brd ff:ff:ff:ff:ff:ff
5: ovs1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 22:fc:bc:29:bc:99 brd ff:ff:ff:ff:ff:ff
    inet 10.16.26.16/24 brd 10.16.26.255 scope global ovs1
       valid_lft forever preferred_lft forever
6: ovs2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 7a:4c:5f:53:fb:42 brd ff:ff:ff:ff:ff:ff
    inet 250.2.16.1/8 brd 250.255.255.255 scope global ovs2
       valid_lft forever preferred_lft forever

Plumb ens3 into ovsbr0 to enable external connectivity and create systemd .network configuration for ens3 and restart systemd-networkd again.

ovs-vsctl add-port ovsbr0 ens3 tag=1 vlan_mode=native-untagged

# ovs-vsctl show
a9de4a5c-a1c5-45d6-a1c0-414a2e5f67d6
    Bridge "ovsbr0"
        Port "ovs2"
            tag: 2
            Interface "ovs2"
                type: internal
        Port "ovs1"
            tag: 1
            Interface "ovs1"
                type: internal
        Port "ens3"
            tag: 1
            Interface "ens3"
        Port "ovsbr0"
            Interface "ovsbr0"
                type: internal
    ovs_version: "2.9.0"
#
# cd /etc/systemd/network
# ls
40-ens3.network  50-ovsbr0.network  61-ovs1.network  62-ovs2.network
# cat40-ens3.network 
[Match]
Name=ens3
#
# systemctl restart systemd-networkd
# networkctl
IDX LINK             TYPE               OPERATIONAL SETUP     
  1 lo               loopback           carrier     unmanaged 
  2 ens3             ether              carrier     configured
  3 ovs-system       ether              off         unmanaged 
  4 ovsbr0           ether              carrier     configured
  5 ovs1             ether              routable    configured
  6 ovs2             ether              routable    configured

6 links listed.
# 
# ip addr show dev ens3
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master ovs-system state UP group default qlen 1000
    link/ether 52:54:3e:a0:a0:a0 brd ff:ff:ff:ff:ff:ff
# ip route
default via 10.16.26.19 dev ovs1 proto static 
10.16.26.0/24 dev ovs1 proto kernel scope link src 10.16.26.16 
250.0.0.0/8 dev ovs2 proto kernel scope link src 250.2.16.1 
#
# ping -c 3 10.16.26.19
PING 10.16.26.19 (10.16.26.19) 56(84) bytes of data.
64 bytes from 10.16.26.19: icmp_seq=1 ttl=64 time=0.701 ms
64 bytes from 10.16.26.19: icmp_seq=2 ttl=64 time=0.373 ms
64 bytes from 10.16.26.19: icmp_seq=3 ttl=64 time=0.836 ms

--- 10.16.26.19 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2027ms
rtt min/avg/max/mdev = 0.373/0.636/0.836/0.196 ms

After a reboot, OVS is running with previous configuration and addressed per /etc/systemd/network/*.network, no need to rebuild OVS configuration from scratch each time.
Persistent MAC addresses may require configuration in OVS or .network files.
MTU doesn't seem to work as documented when set in ens3 .network file, it doesn't flow to all the OVS devices, only some of them.

ssahani · 2019-11-25T18:04:53Z

I am going to work on this. @samarium I figure we need to talk to ovsdb via unix socket using JSON. https://mailman.stanford.edu/pipermail/openflow-discuss/2010-February/000744.html . Is there any formal documentation there ?

After a reboot, OVS is running with previous configuration and addressed per /etc/systemd/network/*.network, no need to rebuild OVS configuration from scratch each time.

This means we made the call then they persists

ykuksenko · 2022-06-08T20:00:36Z

any update on this?

prudentcircle · 2023-12-29T12:24:33Z

Intereting that still nobody felt the need for this even at the end of year 2023.

MarkMielke · 2023-12-29T17:48:43Z

I started to use NetworkManager for this instead. It's a bit problematic, though - NetworkManager is too magical, and it makes some immediate compromises in how it allows the OVS bridge to be configured that are not requirements of OVS itself, but are NetworkManager requirements. I wanted to try systemd-networkd as less magical, but without the basic support for OVS, it wasn't really an option.

The /etc/sysconfig/network-scripts/ifup-ovs worked really well for this - but this package is on its way out.

So, NetworkManager it is? Or we discuss how to make systemd-networkd do it better? :-)

poettering added RFE 🎁 Request for Enhancement, i.e. a feature request network labels Feb 15, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feature Request: systemd-networkd support for ovs (openvswitch) #2613

Feature Request: systemd-networkd support for ovs (openvswitch) #2613

aboe76 commented Feb 14, 2016

poettering commented Feb 15, 2016

johannbg commented Feb 15, 2016

aboe76 commented Feb 15, 2016

johannbg commented Feb 15, 2016

aboe76 commented Feb 15, 2016 •

edited

mabra commented Jul 31, 2016 •

edited

honsys commented Jun 17, 2017 •

edited

keszybz commented Jun 17, 2017

honsys commented Jun 18, 2017

aboe76 commented Jun 18, 2017

honsys commented Jun 18, 2017

samarium commented Sep 13, 2018

ssahani commented Nov 25, 2019 •

edited

ykuksenko commented Jun 8, 2022

prudentcircle commented Dec 29, 2023

MarkMielke commented Dec 29, 2023

Feature Request: systemd-networkd support for ovs (openvswitch) #2613

Feature Request: systemd-networkd support for ovs (openvswitch) #2613

Comments

aboe76 commented Feb 14, 2016

poettering commented Feb 15, 2016

johannbg commented Feb 15, 2016

aboe76 commented Feb 15, 2016

johannbg commented Feb 15, 2016

aboe76 commented Feb 15, 2016 • edited

mabra commented Jul 31, 2016 • edited

honsys commented Jun 17, 2017 • edited

keszybz commented Jun 17, 2017

honsys commented Jun 18, 2017

aboe76 commented Jun 18, 2017

honsys commented Jun 18, 2017

samarium commented Sep 13, 2018

ssahani commented Nov 25, 2019 • edited

ykuksenko commented Jun 8, 2022

prudentcircle commented Dec 29, 2023

MarkMielke commented Dec 29, 2023

aboe76 commented Feb 15, 2016 •

edited

mabra commented Jul 31, 2016 •

edited

honsys commented Jun 17, 2017 •

edited

ssahani commented Nov 25, 2019 •

edited