[ovs-dev] Bug#743635: openvswitch: OVS should probably start before networking

Arno Töll arno at debian.org
Fri Apr 4 13:50:44 UTC 2014


Source: openvswitch
Severity: important

OVS is a software switch, and as such providing primarily L2 features. Therefore
it's unfortunate that it starts after networking (i.e. ifupdown) that may be used
to configure bridge ports provided by OVS.

Consider this configuration:

ovs-vsctl add-br br0
ovs-vsctl add-bond br0 bond0 eth0 eth1 lacp=active

/etc/network/interfaces

auto br0
iface br0 inet static
        address 10.10.100.84
        netmask 255.255.255.128
        network 10.10.100.0
        broadcast 10.10.100.127
        gateway 10.10.100.1

auto eth0
auto eth0 inet manual

auto eth1
auto eth1 inet manual


In such a setup there is no way where you ever could end up with a networking
setup that ends in remote reachable machine and is thus locking you out. This is
because ifupdown starts before openvswitch-{switch, controller}. Thus, ifupdown
does not find that interface as it isn't provided at this stage during the boot.

A possible fix would be to let openvswitch-{switch, controller} start before the
network. For example these LSB headers would do the job:

# X-Start-Before:    networking
# Required-Start:    $local_fs
# Required-Stop:     
# Default-Start:     S
# Default-Stop:      0 6

Arguably this is a cyclic dependency as - depending on the configuration - OVS may
indeed rely on a working network to connect to a remote controller. In such setups
it is probably advised to keep things as is, although OVS may still come up and
fail to connect to the controller which isn't that bad as it keeps reconnecting I
guess. That being said I believe that my use case is more common for OVS and
should thus be fixed.

Alternatively OVS should provide a way to configure it's own L3 stuff itself so that
such cyclic dependencies could be avoided. For example, the whole problem could be
avoided if the IP configuration was stored in the OVS database.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



More information about the dev mailing list