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