This backport to 18.04 LTS broke all our OpenStack compute nodes. We use
systemd-network to configure interfaces etc. and neutron-linuxbridge-
agent with some flat networks. In this scenario, the neutron agent
creates bridges for the flat networks and assigns them to physical
interfaces based on a mapping.
The backport now sets nomaster on these interfaces, effectively removing
the bridges and cutting of connectivity of all VMs using these flat
networks. This happened already when the systemd package was upgraded
(and systemd-networkd restarted).
Example:
```
10: flat-net1@data: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
master brq88363244-5f state UP group default qlen 1000
link/ether b0:22:28:1c:f7:12 brd ff:ff:ff:ff:ff:ff
```
The interface (VLAN here) is created and managed by systemd-networkd,
the bridge `brq88363244-5f` is managed by neutron. Of course, systemd-
networkd doesn't know anything about the bridge, this wasn't a problem
until now, but the latest patch update always sets nomaster to `flat-
net1`. We were really surprise by this change in 18.04 LTS.
Is there any recommend workaround to have systemd-networkd not set
nomaster or do we have to not use systemd-network at all?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1929560
Title:
link mac isn't set if already up
Status in systemd:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
Fix Released
Status in systemd source package in Focal:
Fix Released
Status in systemd source package in Groovy:
Fix Released
Bug description:
[impact]
if link is already up, configured mac isn't set
this also affects the master/nomaster configuration
[test case]
create .network config for the link, for example:
[Match]
Name=eth0
[Link]
MACAddress=00:16:3e:ff:ff:ff
[Network]
DHCP=yes
make sure the link is already up, and restart systemd-networkd:
root@test-f:/etc/systemd/network# ip l show eth0
61: eth0@if62: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode
DEFAULT group default qlen 1000
link/ether 00:16:3e:fc:b2:00 brd ff:ff:ff:ff:ff:ff link-netnsid 0
root@test-f:/etc/systemd/network# ip l set dev eth0 up
root@test-f:/etc/systemd/network# ip l show eth0
61: eth0@if62: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP mode DEFAULT group default qlen 1000
link/ether 00:16:3e:fc:b2:00 brd ff:ff:ff:ff:ff:ff link-netnsid 0
root@test-f:/etc/systemd/network# systemctl restart systemd-networkd
root@test-f:/etc/systemd/network# ip l show eth0
61: eth0@if62: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP mode DEFAULT group default qlen 1000
link/ether 00:16:3e:fc:b2:00 brd ff:ff:ff:ff:ff:ff link-netnsid 0
root@test-f:/etc/systemd/network# ip l set dev eth0 down
root@test-f:/etc/systemd/network# ip l show eth0
61: eth0@if62: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode
DEFAULT group default qlen 1000
link/ether 00:16:3e:fc:b2:00 brd ff:ff:ff:ff:ff:ff link-netnsid 0
root@test-f:/etc/systemd/network# systemctl restart systemd-networkd
root@test-f:/etc/systemd/network# ip l show eth0
61: eth0@if62: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP mode DEFAULT group default qlen 1000
link/ether 00:16:3e:ff:ff:ff brd ff:ff:ff:ff:ff:ff link-netnsid 0
[regression potential]
any regression would likely result in incorrectly set link mac and/or
master, or failure to correctly set mac and/or master
[scope]
this is needed for g and earlier
this is fixed upstream by commit
e16e4b3bedc57919b3ecb4096e941709a5d39b8a which is included in v247 so
this is fixed already in h and later
[other info]
this moves the configuration of the link mac and master out of the
link_up() function, so this also allows repeated calls to link_up()
without reconfiguring the link mac and master. That behavior is useful
for the commits for bug 1664844
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1929560/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
