Package: openvswitch-switch
Version: 2.15.0+ds1-2+deb11u1
Severity: normal
Dear Maintainer,
today we noticed on several hosts that the upgrade of openvswitch-switch
left the network configuration in a broken state. This doesn't happen
every time, but it is easily reproducible. We're using an OVSBridge with
two physical interfaces and an internal port. The config looks like this:
allow-vmbr2 ens19
iface ens19 inet manual
ovs_type OVSPort
ovs_bridge vmbr2
allow-vmbr2 ens20
iface ens20 inet manual
ovs_type OVSPort
ovs_bridge vmbr2
allow-vmbr2 stor0
iface stor0 inet static
address 172.25.42.80
netmask 255.255.255.0
ovs_type OVSIntPort
ovs_bridge vmbr2
auto vmbr2
iface vmbr2 inet manual
ovs_type OVSBridge
ovs_ports stor0 ens19 ens20
The starting situation looks like this:
3: ens19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master
ovs-system state UP group default qlen 1000
link/ether 02:a7:4d:e2:1e:50 brd ff:ff:ff:ff:ff:ff
4: ens20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master
ovs-system state UP group default qlen 1000
link/ether b2:b6:81:92:b6:05 brd ff:ff:ff:ff:ff:ff
26: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether ba:20:fd:9e:fa:66 brd ff:ff:ff:ff:ff:ff
27: vmbr2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UNKNOWN group default qlen 1000
link/ether 66:b7:9e:3e:48:4c brd ff:ff:ff:ff:ff:ff
28: stor0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UNKNOWN group default qlen 1000
link/ether e6:da:c8:f2:58:f4 brd ff:ff:ff:ff:ff:ff
inet 172.25.42.80/24 brd 172.25.42.255 scope global stor0
valid_lft forever preferred_lft forever
and after running 'dpkg-reconfigure openvswitch-switch' several times to
reproduce the problem, it looks like this:
3: ens19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master
ovs-system state UP group default qlen 1000
link/ether 02:a7:4d:e2:1e:50 brd ff:ff:ff:ff:ff:ff
4: ens20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master
ovs-system state UP group default qlen 1000
link/ether b2:b6:81:92:b6:05 brd ff:ff:ff:ff:ff:ff
26: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether ba:20:fd:9e:fa:66 brd ff:ff:ff:ff:ff:ff
29: stor0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether e6:da:c8:f2:58:f4 brd ff:ff:ff:ff:ff:ff
30: vmbr2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 66:b7:9e:3e:48:4c brd ff:ff:ff:ff:ff:ff
Note that both stor0 and vmbr2 have gotten new interface numbers,
their state is now DOWN, and the IP address of stor0 is gone.
According to ifupdown, the interfaces are configured. The issue can be
fixed by calling 'ifdown vmbr2; ifup vmbr2', where ifdown outputs:
RTNETLINK answers: Cannot assign requested address
We've tested this with 2.15.0+ds1-2+deb11u1, 2.15.0+ds1-8~bpo11+1 and
2.15.0+ds1-10, and they all exibit the same behaviour. It may be relevant
that we're using ifupdown 0.8.36.
Obviously it is inconvenient to get updates and then find networking
in an inconsistent state. I can provide more information if necessary,
and since we've been able to reproduce this we can also run things with
debugging or test patches, but some direction about what you need would
be appreciated.
Best regards,
Roel
-- System Information:
Debian Release: 11.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.4.140-1-pve (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages openvswitch-switch depends on:
ii kmod 28-1
ii lsb-base 11.1.0
ii netbase 6.3
ii openvswitch-common 2.15.0+ds1-2+deb11u1
ii procps 2:3.3.17-5
ii uuid-runtime 2.36.1-8+deb11u1
openvswitch-switch recommends no packages.
openvswitch-switch suggests no packages.
-- no debconf information
