[Bug 1671951] Re: networkd should allow configuring IPV6 MTU
Ryan Harper
1671951 at bugs.launchpad.net
Wed Oct 23 21:33:34 UTC 2019
I cannot verify this is working on bionic with ipv6 static addresses.
root at ubuntu:~# lsb_release -rd
Description: Ubuntu 18.04.3 LTS
Release: 18.04
root at ubuntu:~# cat /etc/cloud/build.info
build_name: server
serial: 20191021
root at ubuntu:~# uname -a
Linux ubuntu 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
root at ubuntu:~# apt-cache policy netplan.io
netplan.io:
Installed: 0.98-0ubuntu1~18.04.1
Candidate: 0.98-0ubuntu1~18.04.1
Version table:
*** 0.98-0ubuntu1~18.04.1 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
100 /var/lib/dpkg/status
0.40.1~18.04.4 500
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
0.36.1 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
root at ubuntu:~# apt-cache policy systemd
systemd:
Installed: 237-3ubuntu10.31
Candidate: 237-3ubuntu10.31
Version table:
*** 237-3ubuntu10.31 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
100 /var/lib/dpkg/status
237-3ubuntu10.29 500
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
237-3ubuntu10 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
root at ubuntu:~# cat /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.
# 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:
dhcp4: true
match:
macaddress: '52:54:00:12:34:00'
set-name: interface0
interface1:
dhcp4: false
dhcp6: false
addresses:
- 192.168.1.2/24
- 2001:4800:78ff:1b:be76:4eff:fe06:1000/64
match:
macaddress: '52:54:00:12:34:02'
mtu: 6666
ipv6-mtu: 5634
set-name: interface1
accept-ra: false
dhcp6-overrides:
use-mtu: false
link-local: [ ]
root at ubuntu:~# ip link show interface1
3: interface1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 6666 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 52:54:00:12:34:02 brd ff:ff:ff:ff:ff:ff
# sysctl net.ipv6.conf.interface1.mtu
net.ipv6.conf.interface1.mtu = 6666
root at ubuntu:~# cat /run/systemd/network/10-netplan-interface1.link
[Match]
MACAddress=52:54:00:12:34:02
[Link]
Name=interface1
WakeOnLan=off
MTUBytes=6666
root at ubuntu:~# cat /run/systemd/network/10-netplan-interface1.network
[Match]
MACAddress=52:54:00:12:34:02
Name=interface1
[Network]
LinkLocalAddressing=no
Address=192.168.1.2/24
Address=2001:4800:78ff:1b:be76:4eff:fe06:1000/64
IPv6AcceptRA=no
IPv6MTUBytes=5634
# journalctl -o short-precise -b 0 | egrep -i "(MTU|interface1)"
Oct 23 21:28:47.968910 ubuntu kernel: virtio_net virtio3 interface1: renamed from ens6
Oct 23 21:28:50.636014 ubuntu systemd-networkd[670]: Ignoring /run/systemd/network/10-netplan-interface1.network, because it's not a regular file with suffix .netdev.
Oct 23 21:28:50.636090 ubuntu systemd-networkd[670]: Ignoring /run/systemd/network/10-netplan-interface1.link, because it's not a regular file with suffix .netdev.
Oct 23 21:28:50.636706 ubuntu systemd-networkd[670]: Ignoring /run/systemd/network/10-netplan-interface1.link, because it's not a regular file with suffix .network.
Oct 23 21:28:50.640507 ubuntu systemd-networkd[670]: interface7: Saved original MTU: 1500
Oct 23 21:28:50.642454 ubuntu systemd-networkd[670]: interface6: Saved original MTU: 1500
Oct 23 21:28:50.643050 ubuntu systemd-networkd[670]: interface5: Saved original MTU: 1500
Oct 23 21:28:50.643629 ubuntu systemd-networkd[670]: interface4: Saved original MTU: 1500
Oct 23 21:28:50.644214 ubuntu systemd-networkd[670]: interface3: Saved original MTU: 1500
Oct 23 21:28:50.644939 ubuntu systemd-networkd[670]: interface2: Saved original MTU: 1500
Oct 23 21:28:50.645025 ubuntu systemd-networkd[670]: interface1: New device has no master, continuing without
Oct 23 21:28:50.645107 ubuntu systemd-networkd[670]: interface1: Flags change: +MULTICAST +BROADCAST
Oct 23 21:28:50.645175 ubuntu systemd-networkd[670]: interface1: Link 3 added
Oct 23 21:28:50.645456 ubuntu systemd-networkd[670]: interface1: udev initialized link
Oct 23 21:28:50.647448 ubuntu systemd-networkd[670]: interface1: Saved original MTU: 6666
Oct 23 21:28:50.648100 ubuntu systemd-networkd[670]: interface0: Saved original MTU: 1500
Oct 23 21:28:50.648670 ubuntu systemd-networkd[670]: lo: Saved original MTU: 0
Oct 23 21:28:50.655303 ubuntu systemd-networkd[670]: interface1: Interface name change detected, interface1 has been renamed to ens6.
Oct 23 21:28:50.655431 ubuntu systemd-networkd[670]: ens6: Interface name change detected, ens6 has been renamed to interface1.
Oct 23 21:28:50.675541 ubuntu systemd-networkd[670]: interface1: Link state is up-to-date
Oct 23 21:28:50.675782 ubuntu systemd-networkd[670]: interface1: found matching network '/run/systemd/network/10-netplan-interface1.network'
Oct 23 21:28:50.677101 ubuntu systemd-networkd[670]: interface1: Bringing link up
Oct 23 21:28:50.677242 ubuntu systemd-networkd[670]: interface1: IPv6 successfully enabled
Oct 23 21:28:50.683588 ubuntu systemd-networkd[670]: interface1: Link does not request DHCPv6 prefix delegation
Oct 23 21:28:50.686958 ubuntu systemd-networkd[670]: interface1: Flags change: +UP +LOWER_UP +RUNNING
Oct 23 21:28:50.687472 ubuntu systemd-networkd[670]: interface1: Started LLDP.
Oct 23 21:28:50.687554 ubuntu systemd-networkd[670]: interface1: Gained carrier
Oct 23 21:28:50.687842 ubuntu systemd-networkd[670]: interface1: Setting addresses
Oct 23 21:28:50.697061 ubuntu systemd-networkd[670]: interface1: Updating address: 192.168.1.2/24 (valid forever)
Oct 23 21:28:50.698167 ubuntu systemd-networkd[670]: interface1: Addresses set
Oct 23 21:28:52.021563 ubuntu systemd-networkd[670]: interface1: Adding address: fe80::5054:ff:fe12:3402/64 (valid forever)
Oct 23 21:28:52.021588 ubuntu systemd-networkd[670]: interface1: Gained IPv6LL
Oct 23 21:28:52.053025 ubuntu systemd-networkd[670]: interface1: Updating address: 2001:4800:78ff:1b:be76:4eff:fe06:1000/64 (valid forever)
Oct 23 21:28:52.053125 ubuntu systemd-networkd[670]: interface1: Configured
Oct 23 21:28:52.056906 ubuntu systemd-networkd-wait-online[691]: managing: interface1
Oct 23 21:28:52.216772 ubuntu systemd-networkd-wait-online[691]: managing: interface1
--
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/1671951
Title:
networkd should allow configuring IPV6 MTU
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 Released
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:
New
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/ubuntu/+source/cloud-init/+bug/1671951/+subscriptions
More information about the foundations-bugs
mailing list