Curtin vmtest verification for eoan using systemd from -proposed has run successfully.
(neipa) ipv6_mtu % egrep "242-7ubuntu3.3" output/EoanTestNetworkMtu/logs/install-serial.log [ 136.520219] cloud-init[765]: Get:12 http://archive.ubuntu.com/ubuntu eoan-proposed/main amd64 libnss-systemd amd64 242-7ubuntu3.3 [126 kB] [ 136.527400] cloud-init[765]: Get:13 http://archive.ubuntu.com/ubuntu eoan-proposed/main amd64 udev amd64 242-7ubuntu3.3 [1202 kB] [ 136.693312] cloud-init[765]: Get:14 http://archive.ubuntu.com/ubuntu eoan-proposed/main amd64 libudev1 amd64 242-7ubuntu3.3 [76.9 kB] [ 136.701002] cloud-init[765]: Get:15 http://archive.ubuntu.com/ubuntu eoan-proposed/main amd64 systemd-sysv amd64 242-7ubuntu3.3 [9360 B] [ 136.722467] cloud-init[765]: Get:17 http://archive.ubuntu.com/ubuntu eoan-proposed/main amd64 libpam-systemd amd64 242-7ubuntu3.3 [130 kB] [ 136.743657] cloud-init[765]: Get:19 http://archive.ubuntu.com/ubuntu eoan-proposed/main amd64 systemd amd64 242-7ubuntu3.3 [3440 kB] [ 137.138458] cloud-init[765]: Get:20 http://archive.ubuntu.com/ubuntu eoan-proposed/main amd64 libsystemd0 amd64 242-7ubuntu3.3 [262 kB] [ 142.884502] cloud-init[765]: Preparing to unpack .../libnss-systemd_242-7ubuntu3.3_amd64.deb ... [ 142.887869] cloud-init[765]: Unpacking libnss-systemd:amd64 (242-7ubuntu3.3) over (242-7ubuntu3.2) ... [ 142.924747] cloud-init[765]: Preparing to unpack .../udev_242-7ubuntu3.3_amd64.deb ... [ 142.962745] cloud-init[765]: Unpacking udev (242-7ubuntu3.3) over (242-7ubuntu3.2) ... [ 143.165029] cloud-init[765]: Preparing to unpack .../libudev1_242-7ubuntu3.3_amd64.deb ... [ 143.168604] cloud-init[765]: Unpacking libudev1:amd64 (242-7ubuntu3.3) over (242-7ubuntu3.2) ... [ 143.206268] cloud-init[765]: Setting up libudev1:amd64 (242-7ubuntu3.3) ... [ 143.272647] cloud-init[765]: Preparing to unpack .../systemd-sysv_242-7ubuntu3.3_amd64.deb ... [ 143.275554] cloud-init[765]: Unpacking systemd-sysv (242-7ubuntu3.3) over (242-7ubuntu3.2) ... [ 143.594537] cloud-init[765]: Preparing to unpack .../libpam-systemd_242-7ubuntu3.3_amd64.deb ... [ 143.599803] cloud-init[765]: Unpacking libpam-systemd:amd64 (242-7ubuntu3.3) over (242-7ubuntu3.2) ... [ 143.680250] cloud-init[765]: Preparing to unpack .../systemd_242-7ubuntu3.3_amd64.deb ... [ 143.785319] cloud-init[765]: Unpacking systemd (242-7ubuntu3.3) over (242-7ubuntu3.2) ... [ 144.362457] cloud-init[765]: Preparing to unpack .../libsystemd0_242-7ubuntu3.3_amd64.deb ... [ 144.366022] cloud-init[765]: Unpacking libsystemd0:amd64 (242-7ubuntu3.3) over (242-7ubuntu3.2) ... [ 144.423950] cloud-init[765]: Setting up libsystemd0:amd64 (242-7ubuntu3.3) ... [ 149.340746] cloud-init[765]: Setting up udev (242-7ubuntu3.3) ... [ 152.700118] cloud-init[765]: Setting up systemd (242-7ubuntu3.3) ... [ 154.478301] cloud-init[765]: Setting up systemd-sysv (242-7ubuntu3.3) ... [ 154.481899] cloud-init[765]: Setting up libnss-systemd:amd64 (242-7ubuntu3.3) ... [ 154.485400] cloud-init[765]: Setting up libpam-systemd:amd64 (242-7ubuntu3.3) ... [ 198.012728] cloud-init[765]: systemd is already the newest version (242-7ubuntu3.3). (neipa) ipv6_mtu % cat output/EoanTestNetworkMtu/collect/etc_netplan/50-cloud-init.yaml # This file is generated from information provided by the datasource. Changes # to it will not persist across an instance reboot. To disable cloud-init's # network configuration capabilities, write a file # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following: # network: {config: disabled} network: version: 2 ethernets: interface0: addresses: - 192.168.1.2/24 - 2001:4800:78ff:1b:be76:4eff:fe06:1000/64 ipv6-mtu: 1501 match: macaddress: '52:54:00:12:34:00' mtu: 1601 set-name: interface0 interface1: addresses: - 192.168.2.2/24 - 2001:4800:78ff:1b:be76:4eff:fe06:2000/64 ipv6-mtu: 1501 match: macaddress: '52:54:00:12:34:02' mtu: 1501 set-name: interface1 interface2: dhcp4: true match: macaddress: '52:54:00:12:34:04' set-name: interface2 interface4: addresses: - 2001:4800:78ff:1b:be76:4eff:fe06:5000/64 - 192.168.5.2/24 ipv6-mtu: 8900 match: macaddress: '52:54:00:12:34:08' mtu: 9000 set-name: interface4 interface5: addresses: - 2001:4800:78ff:1b:be76:4eff:fe06:6000/64 - 192.168.6.2/24 ipv6-mtu: 1480 match: macaddress: 52:54:00:12:34:0c mtu: 1480 set-name: interface5 (neipa) ipv6_mtu % grep . output/EoanTestNetworkMtu/collect/interface0_* output/EoanTestNetworkMtu/collect/interface0_dev_mtu:1601 output/EoanTestNetworkMtu/collect/interface0_ipv6_mtu:1501 (neipa) ipv6_mtu % grep . output/EoanTestNetworkMtu/collect/interface1_* output/EoanTestNetworkMtu/collect/interface1_dev_mtu:1501 output/EoanTestNetworkMtu/collect/interface1_ipv6_mtu:1501 (neipa) ipv6_mtu % grep . output/EoanTestNetworkMtu/collect/interface4_* output/EoanTestNetworkMtu/collect/interface4_dev_mtu:9000 output/EoanTestNetworkMtu/collect/interface4_ipv6_mtu:8900 (neipa) ipv6_mtu % grep . output/EoanTestNetworkMtu/collect/interface5_* output/EoanTestNetworkMtu/collect/interface5_dev_mtu:1480 output/EoanTestNetworkMtu/collect/interface5_ipv6_mtu:1480 -- 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/1671951 Title: networkd should allow configuring IPV6 MTU Status in systemd: Unknown Status in cloud-init package in Ubuntu: Confirmed Status in netplan.io package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Bionic: Confirmed Status in netplan.io source package in Bionic: Fix Released Status in systemd source package in Bionic: Fix Committed Status in cloud-init source package in Disco: New Status in netplan.io source package in Disco: Fix Released Status in systemd source package in Disco: Won't Fix Status in cloud-init source package in Eoan: New Status in netplan.io source package in Eoan: Fix Released Status in systemd source package in Eoan: Fix Committed Status in cloud-init source package in Focal: Confirmed Status in netplan.io source package in Focal: Fix Released Status in systemd source package in Focal: Fix Released Bug description: = netplan.io = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Apply a netplan configuration that specifices ipv6-mtu: network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ipv6-mtu: 6000 * Check that MTU bytes, is at least IPv6MTUBytes on the interface: $ sysctl net.ipv6.conf.eth0.mtu net.ipv6.conf.eth0.mtu = 6000 [Regression Potential] * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] * Original bug report below = end of netplan.io = = systemd = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Use IPv6MTUBytes= setting in a .network unit * Restart systemd-network * Check that there no error messages / warnings about not-recognizing this option * Check that MTU bytes, is at least IPv6MTUBytes on the interface [Regression Potential] * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] * Original bug report below = end of systemd = 1) Zesty 2) systemd-232-19 3) I need to configure the IPV6 MTU for tunneling by adding an IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 static address in the [Network] section 4) networkd does not parse or read the value and does not apply this configuration to the interface. Upstream has discussed this issue here: https://github.com/systemd/systemd/pull/1533 But it's been closed in favor of only setting via RA. However, we know of multiple use-case which are currently supported in ifdupdown where we want to retain control over IPV6 MTU values outside of PMTU Discovery configurations. Some context from those discussions >> Client systems that route their ipv6 packets to a 6in4 router also >> have to have their ipv6 mtu lowered. They could lower their link mtu, >> so their ipv6 packets are small enough, but that reduces performance >> of their ipv4 network. Yes. Anything that creates a PMTUD black hole can result in situations where the higher header overhead of IPv6 will cause IPv4 to pass but IPv6 traffic to be dropped. One example here is egress from an ipsec tunnel wherein the next hop MTU is too low for IPv6 datagrams to pass. Another is VM -> whatever -> host bridge -> tunnel ingress. If the datagram cannot enter the tunnel due to size, it is dropped, and an ICMP response uses the tunnel address as a source, which may not be routable back to the origin. This one is an issue with IPv4 as well, and is one case where manually setting the IPv6 MTU lower than the (also manually set) device MTU is of benefit. In essence, any of these sort of cases that require an explicit setting of the device MTU will likely require a setting of the IPv6 mtu as well to account for its larger header overhead. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1671951/+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
