networkd should allow configuring IPV6 MTU
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | cloud-init (Ubuntu) |
Undecided
|
Unassigned | ||
| | Bionic |
Undecided
|
Unassigned | ||
| | netplan.io (Ubuntu) |
Undecided
|
Unassigned | ||
| | Bionic |
Undecided
|
Unassigned | ||
| | systemd (Ubuntu) |
Medium
|
Unassigned | ||
| | Bionic |
Undecided
|
Unassigned | ||
Bug Description
= 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:/
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.
Related branches
- Server Team CI bot: Approve (continuous-integration) on 2017-10-05
- Scott Moser: Approve on 2017-10-05
- Chad Smith: Pending requested 2017-10-04
-
Diff: 544 lines (+128/-134)13 files modifiedcurtin/commands/curthooks.py (+19/-5)
examples/tests/network_alias.yaml (+0/-2)
examples/tests/network_static_routes.yaml (+10/-15)
tests/vmtests/__init__.py (+20/-1)
tests/vmtests/test_network.py (+15/-11)
tests/vmtests/test_network_bonding.py (+16/-17)
tests/vmtests/test_network_bridging.py (+15/-9)
tests/vmtests/test_network_enisource.py (+2/-4)
tests/vmtests/test_network_ipv6.py (+0/-11)
tests/vmtests/test_network_ipv6_enisource.py (+3/-17)
tests/vmtests/test_network_ipv6_vlan.py (+0/-6)
tests/vmtests/test_network_mtu.py (+26/-24)
tests/vmtests/test_network_vlan.py (+2/-12)
| Ryan Harper (raharper) wrote : | #1 |
| Ryan Harper (raharper) wrote : | #2 |
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.]
| tags: | added: patch |
| tags: | added: zesty |
| Changed in systemd (Ubuntu): | |
| importance: | Undecided → Medium |
| Dimitri John Ledkov (xnox) wrote : | #4 |
Please submit this as a pullrequest upstream.
| Ryan Harper (raharper) wrote : | #5 |
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) wrote : | #6 |
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-
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/
ipv6: /proc/sys/
Would it not be sufficient to set the appropriatly-
> 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:/
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
> https:/
> 1671951/
>
| Nish Aravamudan (nacc) wrote : | #8 |
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
https:/
11:07 < rharper> nacc: it was, but not sure of the status now; the debdiff
11:08 < nacc> rharper: ok, can i unsub sponsors for now?
11:08 < rharper> sure
| Changed in systemd (Ubuntu): | |
| status: | New → Confirmed |
| tags: | added: id-5a6a5c89cfbc4063786d54f6 |
| Ryan Harper (raharper) wrote : | #9 |
I've just seen that upstream systemd v239 claims to support IPV6MtuBytes
https:/
* 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) wrote : | #10 |
The v239 merge for cosmic is in progress at the moment. There are a few regressions that need to be worked around.
| tags: | added: id-5b74352f76a21f210334eafd |
| Dimitri John Ledkov (xnox) wrote : | #11 |
This is now in cosmic.
| Changed in systemd (Ubuntu): | |
| status: | Confirmed → Fix Released |
| Dimitri John Ledkov (xnox) wrote : | #12 |
Do we need this in bionic?
| Ryan Harper (raharper) wrote : | #13 |
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:/
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
> https:/
| Scott Moser (smoser) wrote : | #14 |
Hm...
Our tests show that this is not fixed in cosmic or bionic.
https:/
shows curtin's vmtest failing. Partial output shows:
=======
ERROR: test_ipv6_
-------
Traceback (most recent call last):
File "/var/lib/
raise RuntimeError(msg)
RuntimeError: skip_by_
-------
iface=interface4 subnets=
subnet:{'address': '2001:4800:
mtu_data:{'device': 1500, 'ipv6': 1500}
subnet_mtu=1480 ipv6_mtu=1500
-------
| Ryan Harper (raharper) wrote : | #15 |
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:/
> shows curtin's vmtest failing. Partial output shows:
>
> =======
> ERROR: test_ipv6_
> -------
> Traceback (most recent call last):
> File "/var/lib/
> raise RuntimeError(msg)
> RuntimeError: skip_by_
> -------
> iface=interface4 subnets=
> subnet:{'address': '2001:4800:
> mtu_data:{'device': 1500, 'ipv6': 1500}
> subnet_mtu=1480 ipv6_mtu=1500
>
> -------
>
>
> ** Attachment added: "console log of curtin vmtest amd64 533"
> https:/
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
> https:/
| Ryan Harper (raharper) wrote : | #16 |
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:/
| Changed in cloud-init (Ubuntu): | |
| status: | New → Confirmed |
| Changed in cloud-init (Ubuntu Bionic): | |
| status: | New → Confirmed |
| Changed in systemd (Ubuntu Bionic): | |
| status: | New → In Progress |
| description: | updated |
Hello Ryan, or anyone else affected,
Accepted systemd into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
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.
| Changed in systemd (Ubuntu Bionic): | |
| status: | In Progress → Fix Committed |
| tags: | added: verification-needed verification-needed-bionic |
| Łukasz Zemczak (sil2100) wrote : | #18 |
Hello Ryan, or anyone else affected,
Accepted systemd into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
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) wrote : | #19 |
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]
LinkLocalAddres
Address=
IPv6MTUBytes=1470
This results in: /proc/sys/
if I disable LinkLocalAddressing like so:
[Network]
LinkLocalAddres
Address=
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-
which is the same message you get if you: echo "1520" > /proc/sys/
# echo 1520 > /proc/sys/
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) wrote : | #20 |
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.
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:/
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
> https:/
| Dimitri John Ledkov (xnox) wrote : | #22 |
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/
1800
$ cat /proc/sys/
1600
Thus one can set a different from the device, ipv6-specific mtu.
| tags: |
added: verification-done verification-done-bionic removed: verification-needed verification-needed-bionic |
| Ryan Harper (raharper) wrote : | #23 |
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) wrote : | #24 |
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) wrote : | #25 |
This was done inside a VM.
This was all done in a single /etc/systemd/
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.
I've a build of this fix here:
https:/
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).