We see this on Noble with 255.4-1ubuntu8.17 and 8.18, on bonded hosts whose netplan default route carries "mtu: 1500" while the interfaces run at 9000 bytes.
Besides a networkd restart, a carrier return adds the copy as well. link_carrier_gained() calls link_request_static_configs() (src/network/networkd-link.c, v255.4, lines 1519-1575), and link_request_route() re-sends the tracked route. The tracked route has mtu 0 whenever networkd learned it from the kernel (after a restart, or after the route was deleted and added again outside networkd), or created it before the MTU was set in place with `ip route change`. On 2026-09-18 a switch reset dropped carrier on these hosts' bonds for about 13 seconds; the journals of the six that cover the day show it, and none of them restarted networkd. By 2026-10-02, six of seven hosts held the unclamped copy next to the clamped route; the one that had rebooted after the reset held one route. The staged patch reads RTAX_MTU and counts the IPv4 MTU in the identity, which should cover this path too. When 255.4-1ubuntu8.19 is in noble- proposed, we can test it on one of these hosts with both a networkd restart and a carrier drop, and report the result here. -- 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
