[Bug 2009743] Re: networkd: classless routes served by DHCP are created incorrectly
Nick Rosbrook
2009743 at bugs.launchpad.net
Thu Aug 3 17:52:00 UTC 2023
** Description changed:
+ [Impact]
+
+ Classless static routes served by DHCP are ignored by networkd in some
+ cases. Specifically, the gateway is not being set for routes whenever
+ the route destination is in the assigned network. This is a regression
+ in behavior since Focal.
+
+ [Test Plan]
+
+ This is basically taken from systemd-networkd-tests.py. Using a veth
+ pair, setup dnsmasq to serve the problematic routes:
+
+ $ cat > /etc/systemd/network/25-dhcp-server-veth-peer.network << EOF
+ [Match]
+ Name=veth-peer
+
+ [Network]
+ IPv6AcceptRA=no
+ Address=2600::1/0
+ Address=192.168.5.1/24
+ EOF
+
+ $ cat > /etc/systemd/network/25-test.network << EOF
+ [Match]
+ Name=veth99
+
+ [Network]
+ DHCP=ipv4
+ IPv6AcceptRA=false
+
+ [DHCPv4]
+ UseRoutes=yes
+ EOF
+
+ $ cat > /etc/systemd/network/25-veth.netdev << EOF
+ [NetDev]
+ Name=veth99
+ Kind=veth
+ MACAddress=12:34:56:78:9a:bc
+
+ [Peer]
+ Name=veth-peer
+ MACAddress=12:34:56:78:9a:bd
+ EOF
+
+ $ mkdir -p /etc/systemd/system/systemd-networkd.service.d/
+ $ cat > /etc/systemd/system/systemd-networkd.service.d/debug.conf << EOF
+ [Service]
+ Environment=SYSTEMD_LOG_LEVEL=debug
+ EOF
+
+ $ systemctl daemon-reload
+ $ systemctl restart systemd-networkd
+ $ mkdir -p /run/networkd-ci
+ $ dnsmasq --log-facility=/run/networkd-ci/test-dnsmasq.log --log-queries=extra --log-dhcp --pid-file=/run/networkd-ci/test-dnsmasq.pid --conf-file=/dev/null --bind-interfaces --interface=veth-peer --dhcp-leasefile=/run/networkd-ci/test-dnsmasq.lease --enable-ra --dhcp-range=2600::10,2600::20,2m --dhcp-range=192.168.5.10,192.168.5.200,2m --dhcp-option=option:mtu,1492 --dhcp-option=option:router,192.168.5.1 --port=0 --no-resolv --dhcp-option=option:classless-static-route,0.0.0.0/0,192.168.5.4,8.0.0.0/8,192.168.5.5,192.168.5.64/26,192.168.5.5 &
+
+ $ systemctl restart systemd-networkd
+
+ On an affected machine, the route to 192.168.5.64 on veth99 will be
+ missing it's gateway address:
+
+ $ ip r show dev veth99 192.168.5.64/26
+ 192.168.5.64/26 proto dhcp scope link src 192.168.5.181 metric 1024
+
+ And, there will be a log message explaining that this was done
+ intentionally:
+
+ $ journalctl -u systemd-networkd --grep="veth99.*assigned network"
+ Aug 03 16:58:49 mantic2 systemd-networkd[1418]: veth99: DHCP: requested route destination 192.168.5.64/26 is in the assigned network 192.168.5.0/24, ignoring gateway address 192.168.5.5
+
+ On a fixed machine, the route for to 192.168.5.64 will correctly have
+ its gateway configured:
+
+ $ ip r show dev veth99 192.168.5.64/26
+ 192.168.5.64/26 via 192.168.5.5 proto dhcp src 192.168.5.181 metric 1024
+
+ [Where problems could occur]
+
+ The patch is in the DHCPv4 client code for handling routes from the DHCP
+ server. It adds a flag, force_use_gw, to an internal function that
+ essentially overrides the "ignore" behavior whenever classless static
+ routes have been given. If we saw regressions, it would be related to
+ creation of static routes handed down by DHCPv4 servers.
+
+ [Original Description]
+
After upgrading 20.04 systems to 22.04, the classless routes served via
DHCP are not being registered correctly - they are missing the gateway
address.
Expected routes - these are taken from a 20.04 system on the same
network:
$ ip route
default via 10.10.1.1 dev enp24s0 proto dhcp src 10.10.64.12 metric 100
10.0.0.0/8 dev enp24s0 proto kernel scope link src 10.10.64.12
10.88.88.0/24 via 10.10.1.2 dev enp24s0 proto dhcp src 10.10.64.12 metric 100
10.96.0.0/11 via 10.10.1.2 dev enp24s0 proto dhcp src 10.10.64.12 metric 100
Actual routes - these are the routes created in one of the affected
22.04 systems:
$ ip route
default via 10.10.1.1 dev bond0 proto dhcp src 10.10.48.20 metric 100
8.8.8.8 via 10.10.1.1 dev bond0 proto dhcp src 10.10.48.20 metric 100
10.0.0.0/8 dev bond0 proto kernel scope link src 10.10.48.20 metric 100
10.10.1.1 dev bond0 proto dhcp scope link src 10.10.48.20 metric 100
10.10.1.2 dev bond0 proto dhcp scope link src 10.10.48.20 metric 100
10.88.88.0/24 dev bond0 proto dhcp scope link src 10.10.48.20 metric 100
10.96.0.0/11 dev bond0 proto dhcp scope link src 10.10.48.20 metric 100
Note the routes for 10.88.88.0/24 and 10.96.0.0/11 are missing the "via" gateway address, and therefore don't work.
(For some reason there are also static routes created for DNS server (8.8.8.8) and known gateways (10.10.1.1 and 10.10.1.2). These are redundant but harmless.)
Both the working and non-working systems are being managed by netplan.
The non-working system has a bonded interface but I have checked that is
not the cause of the problem - using a physical interface directly has
the same result.
I have attached the files /etc/netplan/00-installer-config.yaml and
/run/systemd/network/10-netplan-bond0.network of the affected system.
Affected system:
Ubuntu version: Ubuntu 22.04.2 LTS
systemd version: 249.11-0ubuntu3.6
Older system not affected:
Ubuntu version: Ubuntu 20.04.5 LTS
systemd version: 245.4-4ubuntu3.19
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2009743
Title:
networkd: classless routes served by DHCP are created incorrectly
Status in systemd:
Fix Released
Status in systemd package in Ubuntu:
Triaged
Status in systemd source package in Jammy:
Triaged
Status in systemd source package in Lunar:
Triaged
Bug description:
[Impact]
Classless static routes served by DHCP are ignored by networkd in some
cases. Specifically, the gateway is not being set for routes whenever
the route destination is in the assigned network. This is a regression
in behavior since Focal.
[Test Plan]
This is basically taken from systemd-networkd-tests.py. Using a veth
pair, setup dnsmasq to serve the problematic routes:
$ cat > /etc/systemd/network/25-dhcp-server-veth-peer.network << EOF
[Match]
Name=veth-peer
[Network]
IPv6AcceptRA=no
Address=2600::1/0
Address=192.168.5.1/24
EOF
$ cat > /etc/systemd/network/25-test.network << EOF
[Match]
Name=veth99
[Network]
DHCP=ipv4
IPv6AcceptRA=false
[DHCPv4]
UseRoutes=yes
EOF
$ cat > /etc/systemd/network/25-veth.netdev << EOF
[NetDev]
Name=veth99
Kind=veth
MACAddress=12:34:56:78:9a:bc
[Peer]
Name=veth-peer
MACAddress=12:34:56:78:9a:bd
EOF
$ mkdir -p /etc/systemd/system/systemd-networkd.service.d/
$ cat > /etc/systemd/system/systemd-networkd.service.d/debug.conf << EOF
[Service]
Environment=SYSTEMD_LOG_LEVEL=debug
EOF
$ systemctl daemon-reload
$ systemctl restart systemd-networkd
$ mkdir -p /run/networkd-ci
$ dnsmasq --log-facility=/run/networkd-ci/test-dnsmasq.log --log-queries=extra --log-dhcp --pid-file=/run/networkd-ci/test-dnsmasq.pid --conf-file=/dev/null --bind-interfaces --interface=veth-peer --dhcp-leasefile=/run/networkd-ci/test-dnsmasq.lease --enable-ra --dhcp-range=2600::10,2600::20,2m --dhcp-range=192.168.5.10,192.168.5.200,2m --dhcp-option=option:mtu,1492 --dhcp-option=option:router,192.168.5.1 --port=0 --no-resolv --dhcp-option=option:classless-static-route,0.0.0.0/0,192.168.5.4,8.0.0.0/8,192.168.5.5,192.168.5.64/26,192.168.5.5 &
$ systemctl restart systemd-networkd
On an affected machine, the route to 192.168.5.64 on veth99 will be
missing it's gateway address:
$ ip r show dev veth99 192.168.5.64/26
192.168.5.64/26 proto dhcp scope link src 192.168.5.181 metric 1024
And, there will be a log message explaining that this was done
intentionally:
$ journalctl -u systemd-networkd --grep="veth99.*assigned network"
Aug 03 16:58:49 mantic2 systemd-networkd[1418]: veth99: DHCP: requested route destination 192.168.5.64/26 is in the assigned network 192.168.5.0/24, ignoring gateway address 192.168.5.5
On a fixed machine, the route for to 192.168.5.64 will correctly have
its gateway configured:
$ ip r show dev veth99 192.168.5.64/26
192.168.5.64/26 via 192.168.5.5 proto dhcp src 192.168.5.181 metric 1024
[Where problems could occur]
The patch is in the DHCPv4 client code for handling routes from the
DHCP server. It adds a flag, force_use_gw, to an internal function
that essentially overrides the "ignore" behavior whenever classless
static routes have been given. If we saw regressions, it would be
related to creation of static routes handed down by DHCPv4 servers.
[Original Description]
After upgrading 20.04 systems to 22.04, the classless routes served
via DHCP are not being registered correctly - they are missing the
gateway address.
Expected routes - these are taken from a 20.04 system on the same
network:
$ ip route
default via 10.10.1.1 dev enp24s0 proto dhcp src 10.10.64.12 metric 100
10.0.0.0/8 dev enp24s0 proto kernel scope link src 10.10.64.12
10.88.88.0/24 via 10.10.1.2 dev enp24s0 proto dhcp src 10.10.64.12 metric 100
10.96.0.0/11 via 10.10.1.2 dev enp24s0 proto dhcp src 10.10.64.12 metric 100
Actual routes - these are the routes created in one of the affected
22.04 systems:
$ ip route
default via 10.10.1.1 dev bond0 proto dhcp src 10.10.48.20 metric 100
8.8.8.8 via 10.10.1.1 dev bond0 proto dhcp src 10.10.48.20 metric 100
10.0.0.0/8 dev bond0 proto kernel scope link src 10.10.48.20 metric 100
10.10.1.1 dev bond0 proto dhcp scope link src 10.10.48.20 metric 100
10.10.1.2 dev bond0 proto dhcp scope link src 10.10.48.20 metric 100
10.88.88.0/24 dev bond0 proto dhcp scope link src 10.10.48.20 metric 100
10.96.0.0/11 dev bond0 proto dhcp scope link src 10.10.48.20 metric 100
Note the routes for 10.88.88.0/24 and 10.96.0.0/11 are missing the "via" gateway address, and therefore don't work.
(For some reason there are also static routes created for DNS server (8.8.8.8) and known gateways (10.10.1.1 and 10.10.1.2). These are redundant but harmless.)
Both the working and non-working systems are being managed by netplan.
The non-working system has a bonded interface but I have checked that
is not the cause of the problem - using a physical interface directly
has the same result.
I have attached the files /etc/netplan/00-installer-config.yaml and
/run/systemd/network/10-netplan-bond0.network of the affected system.
Affected system:
Ubuntu version: Ubuntu 22.04.2 LTS
systemd version: 249.11-0ubuntu3.6
Older system not affected:
Ubuntu version: Ubuntu 20.04.5 LTS
systemd version: 245.4-4ubuntu3.19
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/2009743/+subscriptions
More information about the foundations-bugs
mailing list