[Bug 1874661] Re: networkd sometimes doesn't set mtu received by dhcp

Dan Streetman ddstreet at canonical.com
Thu May 7 15:02:01 UTC 2020


it looks like your dhcp lease is expiring, which causes networkd to drop
your dhcp configuration, including resetting your mtu back to its
original value.  That's done asynchronously by netlink, and networkd
sets a flag "setting_mtu" while the netlink request to change the mtu is
pending.

However, immediately after your lease is lost, you regain it, and
networkd begins setting up the interface with the dhcp info, including
the mtu.  Unfortunately, since the mtu reset hasn't completed yet,
"setting_mtu" flag is still set, and the call to link_set_mtu() returns
silently without actually changing the mtu.  At least that's what seems
like is happening in your case.

It's unusual to lose your dhcp lease before renewing it, so you may be
able to look at why that's happening to avoid this (hopefully that's not
a separate bug in systemd...), but re: the failure to set mtu, I believe
that's going to be a problem that still exists upstream, so resolving
this bug will need fixing upstream first.  If you (or anyone else) has
time to open a bug upstream for this (preferably, after testing with
upstream systemd to verify it's still a bug upstream), please add a note
to this bug.

-- 
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/1874661

Title:
  networkd sometimes doesn't set mtu received by dhcp

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  I'm running ubuntu-minimal-1910-eoan on google compute engine with systemd 242-7ubuntu3.7.
  GCE has mtu 1460, set by dhcp. After having networking issues, I figured out that the mtu on the interface was sometimes incorrectly set to 1500.
  I manually changed it to 1420 to have a working system again and enabled debugging for systemd-networkd.

  Log (filtered for ens4, some columns removed for better readability):
  09:51:00 ens4: New device has no master, continuing without
  09:51:00 ens4: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST
  09:51:00 ens4: Link 2 added
  09:51:00 ens4: udev initialized link
  09:51:00 ens4: Saved original MTU: 1420
  09:51:00 ens4: Adding address: fe80::4001:aff:fea4:2/64 (valid forever)
  09:51:00 ens4: Gained IPv6LL
  09:51:00 ens4: Adding address: 10.164.0.2/32 (valid for 15h 15s)
  09:51:00 ens4: Adding route: dst: ff00::/8, src: n/a, gw: n/a, prefsrc: n/a
  09:51:00 ens4: Adding route: dst: fe80::4001:aff:fea4:2/128, src: n/a, gw: n/a, prefsrc: n/a
  09:51:00 ens4: Adding route: dst: fe80::/64, src: n/a, gw: n/a, prefsrc: n/a
  09:51:00 ens4: Adding route: dst: 10.164.0.2/32, src: n/a, gw: n/a, prefsrc: 10.164.0.2
  09:51:00 ens4: Adding route: dst: 10.164.0.1/32, src: n/a, gw: n/a, prefsrc: 10.164.0.2
  09:51:00 ens4: Adding route: dst: n/a, src: n/a, gw: 10.164.0.1, prefsrc: 10.164.0.2
  09:51:00 ens4: Link state is up-to-date
  09:51:00 ens4: found matching network '/run/systemd/network/10-netplan-ens4.network'
  09:51:00 Setting '/proc/sys/net/ipv6/conf/ens4/proxy_ndp' to '0'
  09:51:00 Setting '/proc/sys/net/ipv6/conf/ens4/use_tempaddr' to '0'
  09:51:00 Setting '/proc/sys/net/ipv6/conf/ens4/accept_ra' to '0'
  09:51:00 ens4: Started LLDP.
  09:51:00 ens4: Setting address genmode for link
  09:51:00 ens4: Setting address genmode done.
  09:51:00 ens4: Removing address 10.164.0.2
  09:51:00 ens4: Acquiring DHCPv4 lease
  09:51:00 ens4: Discovering IPv6 routers
  09:51:00 ens4: Removing address: 10.164.0.2/32 (valid for 15h 15s)
  09:51:00 ens4: Removing route: dst: 10.164.0.2/32, src: n/a, gw: n/a, prefsrc: 10.164.0.2
  09:51:00 ens4: DHCPv4 address 10.164.0.2/32 via 10.164.0.1
  09:51:00 ens4: Setting MTU: 1460
  09:51:00 Setting '/proc/sys/net/ipv6/conf/ens4/disable_ipv6' to '0'
  09:51:00 ens4: IPv6 successfully enabled
  09:51:00 ens4: Setting MTU done.
  09:51:00 ens4: Updating address: 10.164.0.2/32 (valid for 1d)
  09:51:00 ens4: Adding route: dst: 10.164.0.2/32, src: n/a, gw: n/a, prefsrc: 10.164.0.2
  09:51:00 ens4: Configuring route: dst: 10.164.0.1/32, src: n/a, gw: n/a, prefsrc: 10.164.0.2
  09:51:00 ens4: Configuring route: dst: n/a, src: n/a, gw: 10.164.0.1, prefsrc: 10.164.0.2
  09:51:00 ens4: Updating route: dst: 10.164.0.1/32, src: n/a, gw: n/a, prefsrc: 10.164.0.2
  09:51:00 ens4: Updating route: dst: n/a, src: n/a, gw: 10.164.0.1, prefsrc: 10.164.0.2
  09:51:00 ens4: Configured
  21:50:59 ens4: DHCP lease lost
  21:50:59 ens4: Removing address 10.164.0.2
  21:50:59 ens4: Setting MTU: 1420
  21:50:59 Setting '/proc/sys/net/ipv6/conf/ens4/disable_ipv6' to '0'
  21:50:59 ens4: IPv6 successfully enabled
  21:50:59 ens4: DHCPv4 address 10.164.0.2/32 via 10.164.0.1
  21:50:59 ens4: Removing route: dst: 10.164.0.1/32, src: n/a, gw: n/a, prefsrc: 10.164.0.2
  21:50:59 ens4: Removing route: dst: n/a, src: n/a, gw: 10.164.0.1, prefsrc: 10.164.0.2
  21:50:59 ens4: Removing address: 10.164.0.2/32 (valid for 12h 1s)
  21:50:59 ens4: Removing route: dst: 10.164.0.2/32, src: n/a, gw: n/a, prefsrc: 10.164.0.2
  21:50:59 ens4: Setting MTU done.
  21:50:59 ens4: Adding address: 10.164.0.2/32 (valid for 1d)
  21:50:59 ens4: Adding route: dst: 10.164.0.2/32, src: n/a, gw: n/a, prefsrc: 10.164.0.2
  21:50:59 ens4: Configuring route: dst: 10.164.0.1/32, src: n/a, gw: n/a, prefsrc: 10.164.0.2
  21:50:59 ens4: Configuring route: dst: n/a, src: n/a, gw: 10.164.0.1, prefsrc: 10.164.0.2
  21:50:59 ens4: Updating route: dst: 10.164.0.1/32, src: n/a, gw: n/a, prefsrc: 10.164.0.2
  21:50:59 ens4: Updating route: dst: n/a, src: n/a, gw: 10.164.0.1, prefsrc: 10.164.0.2
  21:50:59 ens4: Configured

  On dhcp renew (09:51:00), mtu got properly changed to 1460.
  On next dhcp renew (21:50:59) it got changed back to previous value 1420.
  In all cases, /run/systemd/netif/leases/2 correctly contained MTU=1460.

  There have been some changes to mtu handling in the past, I assume
  this is a regression, potentially from
  https://github.com/systemd/systemd/issues/12552 or
  https://github.com/systemd/systemd/issues/6593.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1874661/+subscriptions



More information about the foundations-bugs mailing list