** Description changed:
[ Impact ]
Static IPv4 routes configured with MTUBytes= can be duplicated without
their MTU after restarting systemd-networkd. A subsequent networkctl
reconfigure, netplan apply, or networkd restart can then silently remove
the routes that include MTU values. This can cause fragmentation and
connectivity failures.
This bug should be fixed in the stable release because it affects
existing configurations that depend on persistent route MTUs, such as
tunneled or overlay networks. The problem can occur whenever networkd is
restarted or the network is reconfigured.
The fix includes the IPv4 MTU in route identity and comparison logic and
parses RTAX_MTU from kernel route notifications. This prevents networkd
from incorrectly reusing a route whose MTU differs from the configured
value, allowing the stale route to be removed and recreated with the
correct MTU.
Release: Ubuntu Noble 24.04, systemd 255.4-1ubuntu8.17
[ Test Plan ]
Steps to reproduce:
Launch a VM running Noble 24.04: lxc launch ubuntu:noble noble-vm --vm -c
limits.cpu=1 -c limits.memory=4GiB
Shell into VM: lxc shell noble-vm
Create dummy netplan config: vim /etc/netplan/dummy.yaml
network:
version: 2
dummy-devices:
mgmt0:
addresses: [10.34.141.45/24]
dhcp4: false
mtu: 9000
routes:
- {to: 169.254.169.254/32, from: 10.34.141.45, scope: link}
- {to: 10.34.141.1, from: 10.34.141.45, scope: link, mtu: 1230,
table: 252}
- {to: 10.34.141.0/24, from: 10.34.141.45, scope: link, mtu: 9000,
table: 252}
- {to: default, via: 10.34.141.1, from: 10.34.141.45, mtu: 1230,
table: 252}
- {to: 10.34.134.128/25, type: unreachable, table: 252}
- {to: 10.34.128.0/22, type: unreachable, table: 252}
routing-policy:
- {from: 10.34.141.45, table: 252}
chmod 600 /etc/netplan/dummy.yaml
netplan generate && netplan apply
ip route list table 252
default via 10.34.141.1 dev mgmt0 proto static src 10.34.141.45 mtu 1230
unreachable 10.34.128.0/22 proto static
unreachable 10.34.134.128/25 proto static
10.34.141.0/24 dev mgmt0 proto static scope link src 10.34.141.45 mtu 9000
10.34.141.1 dev mgmt0 proto static scope link src 10.34.141.45 mtu 1230
Restart networkd: systemctl restart systemd-networkd
List duplicate routes in table:
ip route list table 252
default via 10.34.141.1 dev mgmt0 proto static src 10.34.141.45 mtu 1230
default via 10.34.141.1 dev mgmt0 proto static src 10.34.141.45
unreachable 10.34.128.0/22 proto static
unreachable 10.34.134.128/25 proto static
10.34.141.0/24 dev mgmt0 proto static scope link src 10.34.141.45 mtu 9000
10.34.141.0/24 dev mgmt0 proto static scope link src 10.34.141.45
10.34.141.1 dev mgmt0 proto static scope link src 10.34.141.45 mtu 1230
10.34.141.1 dev mgmt0 proto static scope link src 10.34.141.45
Reconfigure dummy mgmt0 interface: networkctl reconfigure mgmt0
List table to see missing mtu routes:
ip route list table 252
default via 10.34.141.1 dev mgmt0 proto static src 10.34.141.45
unreachable 10.34.128.0/22 proto static
unreachable 10.34.134.128/25 proto static
10.34.141.0/24 dev mgmt0 proto static scope link src 10.34.141.45
10.34.141.1 dev mgmt0 proto static scope link src 10.34.141.45
Relevant config excerpt: cat /run/systemd/network/10-netplan-
mgmt0.network
[Route]
Destination=10.34.141.1
PreferredSource=10.34.141.45
Scope=link
Table=252
MTUBytes=1230
[Route]
Destination=10.34.141.0/24
PreferredSource=10.34.141.45
Scope=link
Table=252
MTUBytes=9000
[Route]
Destination=0.0.0.0/0
Gateway=10.34.141.1
PreferredSource=10.34.141.45
Table=252
MTUBytes=1230
[ Where problems could occur ]
- The change affects IPv4 route matching, kernel route parsing, and route
- replacement during restart or reconfiguration. A regression could cause:
+ The change affects IPv4 route matching/replacement and kernel route
+ parsing during restart or reconfiguration. A regression could cause:
- Configured MTUs to be lost or incorrectly retained
- Routes to be removed without being recreated
- Duplicate routes or unexpected route-add failures
- Unnecessary route replacement and a brief connectivity interruption
- IPv6 route matching to change accidentally if the IPv4-only checks are
implemented incorrectly
Regression testing should repeat the scenario above and verify that the
final state contains exactly one route for each configured entry, with
- the expected MTU values.
-
- The main regression area is IPv4 route reconciliation after restart and
- reconfiguration. The patch is intended not to change IPv6 route identity
- or the behavior of routes without a configured MTU.
+ the expected MTU values. The patch is not intended to change IPv6 route
+ identity or the behavior of routes without a configured MTU.
[ Other Info ]
This is a focused backport for existing IPv4 route MTU support. It
introduces no new configuration options or protocol changes.
The configured MTU continues to be sent to the kernel as RTAX_MTU.
Parsing RTAX_MTU from kernel route notifications keeps networkd’s in-
memory route state synchronized with the live route and prevents stale
routes from being incorrectly reused.
Upstream bug:
https://github.com/systemd/systemd/issues/28853#event-11678617988
Upstream PR fix:
https://github.com/systemd/systemd/pull/31173/changes/7027cdbd79c26d5a8890759a37d70165c8aeb214
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2167098
Title:
IPv4 route MTUs silently dropped after networkd restart / networkctl
reconfigure / netplan apply
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2167098/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
