networkd should allow configuring IPV6 MTU

[Ryan Harper]

= 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.

[Ryan Harper (raharper)]

I've a build of this fix here:

https://launchpad.net/~raharper/+archive/ubuntu/cloud-init-dev (systemd=232-19ubuntu3~fixbuild1)

I've tested this minimally in a Zesty VM and it's successfully applies an IPV6MTU in addition to the device mtu (if that's also included).

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "ipv6_mtu.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Dimitri John Ledkov (xnox)]

Please submit this as a pullrequest upstream.

[Ryan Harper (raharper)]

This also needs some discussion w.r.t how to handle IPV6-only devices; namely if you want to set the IPV6 MTU to something higher than the underlying device's current setting then the device MTU would need to be raised as well. That needs to be implemented and added to the patch.

[Dimitri John Ledkov (xnox)]

I'm very naive, so please bear with me if this is a silly question. As far as I can tell the existing MTU setting in networkd will apply to both ipv4 and ipv6 simultaniously. Are you arguing that you want specific control of MTU and use different values for ipv4 and ipv6? Would it not be sufficient to set the appropriatly-lowest/highest common denominator value for MTU?

[Ryan Harper (raharper)]

On Wed, May 17, 2017 at 1:14 PM, Dimitri John Ledkov <<email address hidden>
> wrote:

> I'm very naive, so please bear with me if this is a silly question. As
> far as I can tell the existing MTU setting in networkd will apply to
> both ipv4 and ipv6 simultaniously. Are you arguing that you want
> specific control of MTU and use different values for ipv4 and ipv6?
>

Yes

AFAICT, the MTUBytes field which is a link property, applies to the device
itself.

IPv6 has a separate *protocol* level MTU where it is used to fragment IPv6
packets
so they can be tunneled (among other things) over IPv4. There's also a
specific
IPv6 MTU setting to prevent IPv6 packets from being to small (I think 1280
is the
minimum MTU allowable for IPv6 packets.

Subsequently, the kernel has *two* MTUs, Device (ethernet, ppp, etc) and
IPv6 protocal

device: /sys/class/net/<interface>/mtu
ipv6: /proc/sys/net/ipv6/conf/<interface>/mtu

Would it not be sufficient to set the appropriatly-lowest/highest common
> denominator value for MTU?
>

It is not. In the case that you want to use 9000 MTU on an ipv6 address,
one
 needs to ensure that the MTU of the underlying device is raised from the
default to 9000
otherwise the V6 MTU means nothing.

In some cases you want to raise the MTU of the underlying device, but *not*
raise the MTU of the IPV6
this is a tunneling case:

eth0 mtu 9000
ipv6 mtu 1480

So, yes, we want independent control over v4 and v6 MTU.

Note, the upstream discussions (IMHO) punt the problem to Router
Advertisements; however what
does remain is that we currently have this control with ifupdown (with some
help of pre/post scripts).

I had a start at getting this working in networkd, however I wasn't able to
achieve the independent control

>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1671951
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/
> 1671951/+subscriptions
>

[Nish Aravamudan (nacc)]

Unsubscribing sponsors based upon IRC discussion with rharper:

10:57 < nacc> rharper: is LP: #1671951 actually ready to sponsor?
10:57 < ubottu> Launchpad bug 1671951 in systemd (Ubuntu) "networkd should
                allow configuring IPV6 MTU" [Medium,New]
                https://launchpad.net/bugs/1671951
11:07 < rharper> nacc: it was, but not sure of the status now; the debdiff
                 likely needs refreshed against systemd in artful; I'm not
                 sure of xnox or anyone else attempted to re-work the issue
                 upstream;
11:08 < nacc> rharper: ok, can i unsub sponsors for now?
11:08 < rharper> sure

[Ryan Harper (raharper)]

I've just seen that upstream systemd v239 claims to support IPV6MtuBytes

https://lwn.net/Articles/758128/

* networkd's .network files now support a new IPv6MTUBytes= option for
setting the MTU used by IPv6 explicitly as well as a new MTUBytes=
option in the [Route] section to configure the MTU to use for
specific routes. It also gained support for configuration of the DHCP
"UserClass" option through the new UserClass= setting. It gained
three new options in the new [CAN] section for configuring CAN
networks. The MULTICAST and ALLMULTI interface flags may now be
controlled explicitly with the new Multicast= and AllMulticast=
settings.

[Dimitri John Ledkov (xnox)]

The v239 merge for cosmic is in progress at the moment. There are a few regressions that need to be worked around.

[Dimitri John Ledkov (xnox)]

This is now in cosmic.

[Dimitri John Ledkov (xnox)]

Do we need this in bionic?

[Ryan Harper (raharper)]

On Wed, Aug 29, 2018 at 8:41 AM Dimitri John Ledkov
<email address hidden> wrote:
>
> Do we need this in bionic?

Yes

>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1671951
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1671951/+subscriptions

[Scott Moser (smoser)]

Hm...

Our tests show that this is not fixed in cosmic or bionic.

https://jenkins.ubuntu.com/server/job/curtin-vmtest-devel-amd64/533/console
shows curtin's vmtest failing. Partial output shows:

======================================================================
ERROR: test_ipv6_mtu_smaller_than_ipv4_v6_iface_first (vmtests.test_network_mtu.CosmicTestNetworkMtu)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/jenkins/slaves/torkoal/workspace/curtin-vmtest-devel-amd64/curtin-533/tests/vmtests/__init__.py", line 468, in wrapper
    raise RuntimeError(msg)
RuntimeError: skip_by_date(CosmicTestNetworkMtu.test_ipv6_mtu_smaller_than_ipv4_v6_iface_first) LP: #1671951 fixby=2018-09-26 removeby=2018-10-17: (PAST_FIXBY) Failed: 1480 != 1500
-------------------- >> begin captured stdout << ---------------------
iface=interface4 subnets=[{'address': '2001:4800:78ff:1b:be76:4eff:fe06:5000', 'netmask': 64, 'type': 'static', 'mtu': 1480}, {'address': '192.168.5.2/24', 'type': 'static', 'mtu': 1501}]
subnet:{'address': '2001:4800:78ff:1b:be76:4eff:fe06:5000', 'netmask': 64, 'type': 'static', 'mtu': 1480}
mtu_data:{'device': 1500, 'ipv6': 1500}
subnet_mtu=1480 ipv6_mtu=1500

--------------------- >> end captured stdout << ----------------------

[Ryan Harper (raharper)]

This may now be a cloud-init bug if the support is there since this is
a network-config v1 -> cloud-init renders netplan.
On Fri, Sep 28, 2018 at 9:12 AM Scott Moser <email address hidden> wrote:
>
> Hm...
>
> Our tests show that this is not fixed in cosmic or bionic.
>
> https://jenkins.ubuntu.com/server/job/curtin-vmtest-devel-amd64/533/console
> shows curtin's vmtest failing. Partial output shows:
>
> ======================================================================
> ERROR: test_ipv6_mtu_smaller_than_ipv4_v6_iface_first (vmtests.test_network_mtu.CosmicTestNetworkMtu)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/var/lib/jenkins/slaves/torkoal/workspace/curtin-vmtest-devel-amd64/curtin-533/tests/vmtests/__init__.py", line 468, in wrapper
> raise RuntimeError(msg)
> RuntimeError: skip_by_date(CosmicTestNetworkMtu.test_ipv6_mtu_smaller_than_ipv4_v6_iface_first) LP: #1671951 fixby=2018-09-26 removeby=2018-10-17: (PAST_FIXBY) Failed: 1480 != 1500
> -------------------- >> begin captured stdout << ---------------------
> iface=interface4 subnets=[{'address': '2001:4800:78ff:1b:be76:4eff:fe06:5000', 'netmask': 64, 'type': 'static', 'mtu': 1480}, {'address': '192.168.5.2/24', 'type': 'static', 'mtu': 1501}]
> subnet:{'address': '2001:4800:78ff:1b:be76:4eff:fe06:5000', 'netmask': 64, 'type': 'static', 'mtu': 1480}
> mtu_data:{'device': 1500, 'ipv6': 1500}
> subnet_mtu=1480 ipv6_mtu=1500
>
> --------------------- >> end captured stdout << ----------------------
>
>
> ** Attachment added: "console log of curtin vmtest amd64 533"
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1671951/+attachment/5194078/+files/curtin-vmtest-devel-amd64-533-console.log
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1671951
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1671951/+subscriptions

[Ryan Harper (raharper)]

Actually there needs to be changes to netplan to emit the correct IPV6BytesMtu setting to networkd; and then cloud-init can emit the correct netplan yaml for that. This feature is on the netplan roadmap here:

https://trello.com/c/nIjLIRSG/6-support-ipv6-mtu-bytes-configuration

[Łukasz Zemczak (sil2100)]

Hello Ryan, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.8 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Łukasz Zemczak (sil2100)]

Hello Ryan, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.10 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ryan Harper (raharper)]

It seems there are some limitations to what systemd will do with IPv6BytesMTU.

1) if LinkLocalAddressing is not disabled, it will clobber any IPv6BytesMTU value set.

[Network]
LinkLocalAddressing=ipv6
Address=10.10.10.10/24
IPv6MTUBytes=1470

This results in: /proc/sys/net/ipv6/conf/<iface>/mtu having a value of 1500

if I disable LinkLocalAddressing like so:

[Network]
LinkLocalAddressing=no
Address=10.10.10.10/24
IPv6MTUBytes=1470

Then I get 1470.

This seems like a bug; do we need an upstream issue to track this?

2) systemd-networkd will not raise the device MTU limit automatically. The default device MTU is 1500. If you set IPv6BytesMTU to 1520, then systemd-networkd emits this message:

Nov 26 19:13:59 rharper-b2 systemd-networkd[593]: eth2: Cannot set IPv6 MTU for interface: Invalid argument

which is the same message you get if you: echo "1520" > /proc/sys/net/ipv6/conf/<iface>/mtu:

# echo 1520 > /proc/sys/net/ipv6/conf/eth2/mtu
bash: echo: write error: Invalid argument

If this is considered "acceptable" behavior for systemd, then it will leave netplan with a decision when it is presented with a config which sets an ipv6-mtu bytes value that is bigger than the default device value (1500), or bigger than an specified device mtu. Will it report an error with the config?

Should we file an upstream issue to see if networkd is willing to raise the device limit (or possibly emit a more helpful message to indicate that networkd cannot set an IPv6 MTU greater than the underlying device MTU?

[Jay Vosburgh (jvosburgh)]

Regarding #2 from comment #19:

As the defined range for the ipv6.mtu is from IPV6_MIN_MTU to the device's MTU, and the existing API returns an error if the ipv6.mtu is out of range, I think it's reasonable for a configuration with the ipv6.mtu > device MTU to fail.

[Ryan Harper (raharper)]

On Mon, Nov 26, 2018 at 11:11 PM Jay Vosburgh
<email address hidden> wrote:
>
> Regarding #2 from comment #19:
>
> As the defined range for the ipv6.mtu is from IPV6_MIN_MTU to the
> device's MTU, and the existing API returns an error if the ipv6.mtu is
> out of range, I think it's reasonable for a configuration with the
> ipv6.mtu > device MTU to fail.

I think that's reasonable too. We'll need to file a separate bug with
MAAS to ensure that
it knows it should set device MTU >= to the ipv6 MTU configured. This
will ensure
the configuration that gets generated will include both a raised
device MTU and an IPV6 MTU.

>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1671951
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1671951/+subscriptions

[Dimitri John Ledkov (xnox)]

Using systemd 237-3ubuntu10.10

Using:
[Match]
Name=ens3
[Network]
DHCP=ipv4
IPv6MTUBytes=1600
[Link]
MTUBytes=1800
[DHCP]
UseMTU=no
RouteMetric=100

I do get:

$ cat /sys/class/net/ens3/mtu
1800
$ cat /proc/sys/net/ipv6/conf/ens3/mtu
1600

Thus one can set a different from the device, ipv6-specific mtu.

[Ryan Harper (raharper)]

On Tue, Dec 4, 2018 at 6:31 AM Dimitri John Ledkov <email address hidden>
wrote:

> Using systemd 237-3ubuntu10.10
>
> Using:
> [Match]
> Name=ens3
> [Network]
> DHCP=ipv4
> IPv6MTUBytes=1600
> [Link]
> MTUBytes=1800
> [DHCP]
> UseMTU=no
> RouteMetric=100
>

Do you put this in the same .network file or .link file?

[Ryan Harper (raharper)]

On Tue, Dec 4, 2018 at 9:31 AM Ryan Harper <email address hidden>
wrote:

>
>
> On Tue, Dec 4, 2018 at 6:31 AM Dimitri John Ledkov <email address hidden>
> wrote:
>
>> Using systemd 237-3ubuntu10.10
>>
>> Using:
>> [Match]
>> Name=ens3
>> [Network]
>> DHCP=ipv4
>> IPv6MTUBytes=1600
>> [Link]
>> MTUBytes=1800
>> [DHCP]
>> UseMTU=no
>> RouteMetric=100
>>
>
> Do you put this in the same .network file or .link file?
>

FWIW, I'm not able to make this work inside a LXD container. Could you
provide more details on how you validated and in what environment?

[Dimitri John Ledkov (xnox)]

This was done inside a VM.
This was all done in a single /etc/systemd/network/10-netplan-ens3.network file. Note that [Link] is a valid section in a .network file. Note that i took netplan generated .network file as a base, and then modified it with above shown options. Disabled netplan. Rebooted.

I'm not quite sure how you can reproduce this inside a lxd container, since it's not using a physical link, but a .netdev devices. I expect that specifying similar things in .network should work, but it might not. That is because a veth pair is precreated outside of the container, and one may need to adjust the host-side of the veth pair which is a priviledged operation.

Note that e.g. one can set MTU on virtual devices created using .netdev units.

[Launchpad Janitor (janitor)]

This bug was fixed in the package netplan.io - 0.98-0ubuntu1

---------------
netplan.io (0.98-0ubuntu1) eoan; urgency=medium

  * New upstream release: 0.98 (LP: #1840832)
    - Added new "feature flags" to identify new features
    - Added support for "use-domains" for DHCP overrides
    - Added support for setting IPv6 MTU Bytes (LP: #1671951)
    - Added a DBus interface to query and run 'netplan apply' via other apps
    - Various build system fixes
    - Improved validation for bonding modes
    - Added support for "hash:" for hashed 802.1x passwords (LP: #1819831)
    - Tolerate devices without a /sys path (LP: #1810043)
    - Fix incorrect separator for networkd with ARP IP targets (LP: #1829264)
  * debian/control: Add Build-Depends on libsystemd-dev for DBus feature, and
    on dbus-x11 for dbus-launch used in tests.

 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 21 Aug 2019 14:49:16 -0400

[Brian Murray (brian-murray)]

Hello Ryan, or anyone else affected,

Accepted netplan.io into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.98-0ubuntu1~18.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ryan Harper (raharper)]

I launched a bionic image on serverstack, updated the netplan.io to proposed, modified the network config to set ipv6-mtu to 6000 and rebooted.

root@b-test-ipv6-mtu:~# 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://nova.clouds.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     0.97-0ubuntu1~18.04.1 500
        500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
     0.40.1~18.04.4 500
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
     0.36.1 500
        500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

root@b-test-ipv6-mtu:~# cat /etc/netplan/50-cloud-init.yaml
network:
    version: 2
    ethernets:
        ens3:
            dhcp4: true
            match:
                macaddress: fa:16:3e:4d:3c:6a
            set-name: ens3
            ipv6-mtu: 6000

root@b-test-ipv6-mtu:/run/systemd/network# cat 10-netplan-ens3.link
[Match]
MACAddress=fa:16:3e:4d:3c:6a

[Link]
Name=ens3
WakeOnLan=off
root@b-test-ipv6-mtu:/run/systemd/network# cat 10-netplan-ens3.network
[Match]
MACAddress=fa:16:3e:4d:3c:6a
Name=ens3

[Network]
DHCP=ipv4
LinkLocalAddressing=ipv6
IPv6MTUBytes=6000

[DHCP]
RouteMetric=100
UseMTU=true

~# cat /sys/class/net/ens3/mtu
8958
~# sysctl net.ipv6.conf.ens3.mtu
net.ipv6.conf.ens3.mtu = 8958

[Dimitri John Ledkov (xnox)]

Followup on my comments, are any changes required in networkd to support this in bionic?

[Ryan Harper (raharper)]

I tested with your single-file approach and that also fails. Note that bionic now has systemd 237, so maybe something is missing (or regressed) ?

$ apt-cache policy systemd
systemd:
  Installed: 237-3ubuntu10.26
  Candidate: 237-3ubuntu10.26
  Version table:
 *** 237-3ubuntu10.26 500
        500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     237-3ubuntu10.25 500
        500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
     237-3ubuntu10.19 500
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
     237-3ubuntu10 500
        500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

[Dimitri John Ledkov (xnox)]

I thought custom ipv6 MTU may not be lower than ipv4 one.

Hence request for 6000 ipv6 is not valid, when link is on 8958.

Can you try 9000?

On Wed, 28 Aug 2019, 15:41 Ryan Harper, <email address hidden> wrote:

> I launched a bionic image on serverstack, updated the netplan.io to
> proposed, modified the network config to set ipv6-mtu to 6000 and
> rebooted.
>
> root@b-test-ipv6-mtu:~# 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://nova.clouds.archive.ubuntu.com/ubuntu
> bionic-proposed/main amd64 Packages
> 100 /var/lib/dpkg/status
> 0.97-0ubuntu1~18.04.1 500
> 500 http://nova.clouds.archive.ubuntu.com/ubuntu
> bionic-updates/main amd64 Packages
> 0.40.1~18.04.4 500
> 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64
> Packages
> 0.36.1 500
> 500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic/main
> amd64 Packages
>
> root@b-test-ipv6-mtu:~# cat /etc/netplan/50-cloud-init.yaml
> network:
> version: 2
> ethernets:
> ens3:
> dhcp4: true
> match:
> macaddress: fa:16:3e:4d:3c:6a
> set-name: ens3
> ipv6-mtu: 6000
>
> root@b-test-ipv6-mtu:/run/systemd/network# cat 10-netplan-ens3.link
> [Match]
> MACAddress=fa:16:3e:4d:3c:6a
>
> [Link]
> Name=ens3
> WakeOnLan=off
> root@b-test-ipv6-mtu:/run/systemd/network# cat 10-netplan-ens3.network
> [Match]
> MACAddress=fa:16:3e:4d:3c:6a
> Name=ens3
>
> [Network]
> DHCP=ipv4
> LinkLocalAddressing=ipv6
> IPv6MTUBytes=6000
>
> [DHCP]
> RouteMetric=100
> UseMTU=true
>
>
> ~# cat /sys/class/net/ens3/mtu
> 8958
> ~# sysctl net.ipv6.conf.ens3.mtu
> net.ipv6.conf.ens3.mtu = 8958
>
> --
> You received this bug notification because you are subscribed to systemd
> in Ubuntu.
> Matching subscriptions: systemd
> https://bugs.launchpad.net/bugs/1671951
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1671951/+subscriptions
>

[Ryan Harper (raharper)]

See comment #20; ipv6 mtu is 1280 -> DEVICE_MTU.

I'm testing something in the middle now.

On Eoan with:

network:
    version: 2
    ethernets:
        ens3:
            addresses: [10.5.0.16/16]
            gateway4: 10.5.0.1
            dhcp4: false
            match:
                macaddress: fa:16:3e:c9:1e:fb
            mtu: 8958
            ipv6-mtu: 8960
            set-name: ens3
            nameservers:
                addresses: [10.5.0.2]
                search: [project.serverstack]

It works. Now on bionic-proposed, it does not.

Aug 28 16:59:56.659125 b-test-ipv6-mtu systemd-networkd[1149]: /run/systemd/network/10-netplan-ens3.network:11: Unknown lvalue 'IPv6MTUBytes' in section 'Network'

So, looks like bionic systemd is missing something.

[Ryan Harper (raharper)]

err, on Eoan, I used ipv6-mtu 6000.