Comment 6 for bug 1609861
Revision history for this message
| Ryan Harper (raharper) wrote Re: [Bug 1609861] Re: IPv6 MTU not applied correctly for pure IPv6 interfaces | #6 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
On Thu, Aug 4, 2016 at 5:28 PM, Dan Streetman <
<email address hidden>> wrote:
> > It appears that adding a:
> >
> > post-up ifconfig <bondname> mtu <mtuvalue> to the bond stanza will
> successfully work-around
> > the ifupdown bug.
>
> unfortunately no. because the point of the ipv6 mtu is to have a lower
> ipv6 mtu than the device mtu, to allow ipv6 tunneling in ipv4, if that
> post-up is unconditionally added for all inet6 mtu params then the ipv6
> mtu will never be successfully lowered to below the device mtu (whenever
> the device mtu is set, the ipv6 mtu is reset to the device mtu).
>
> I go into more detail in the ifupdown bug, but two examples:
>
> inet mtu 1500
> inet6 mtu 1480
> for this we want the device mtu to be 1500, and ipv6 mtu to be 1480.
>
OK; the current ifupdown code since 0.8.6 supports exactly this since it
changed to using sysctl for setting ipv6 mtu
>
> # no inet mtu specified
> inet6 mtu 1480
> for this we also want the device mtu to stay at its default of 1500, and
> the ipv6 mtu to be 1480
>
This should also be fine, underlying device gets default mtu of 1500, and
sysctl will handle 1480 setting for ipv6.
>
> # no inet mtu specified
> inet6 mtu 9000
> for this we want the device mtu to be 9000; the ipv6 will automatically be
> set to 9000 also.
>
The claim here is that this fails due to underlying device with default mtu
of 1500 prevents the sysctl of the device
from working. Which appears to be the case for plain interfaces:
root@x1:~# tail /etc/network/
auto ens8
iface ens8 inet6 static
address fd0d:ffe0:
mtu 9202
root@x1:~# ifup -v ens8
Parsing file /etc/network/
Configuring interface ens8=ens8 (inet6)
/bin/run-parts --exit-on-error --verbose /etc/network/
run-parts: executing /etc/network/
run-parts: executing /etc/network/
+ [ inet6 = meta ]
+ IF_BOND_SLAVES=
+ [ ]
+ [ ]
+ [ -z ]
+ exit
run-parts: executing /etc/network/
/sbin/modprobe -q net-pf-10 > /dev/null 2>&1 || true # ignore failure.
/sbin/sysctl -q -e -w net.ipv6.
/sbin/sysctl -q -e -w net.ipv6.
sysctl: setting key "net.ipv6.
/bin/ip link set dev ens8 up
/bin/ip -6 addr add fd0d:ffe0:
/lib/ifupdown/
Waiting for DAD... Done
/bin/run-parts --exit-on-error --verbose /etc/network/
run-parts: executing /etc/network/
run-parts: executing /etc/network/
run-parts: executing /etc/network/
+ [ inet6 = meta ]
+ [ ]
run-parts: executing /etc/network/
run-parts: executing /etc/network/
run-parts: executing /etc/network/
Now, in this scenario and post-up ifconfig <dev> mtu <mtuval> is sufficient.
I see that the post-up in the case of sharing the device name, like ens8
doesn't work as it would change ens8 mtu to the *lower* ipv6 value.
However, for vlans and bonds where there is a relationship but not direct
I think the post-up works fine:
auto ens8
iface ens8 inet static
bond-master bond0
mtu 9202
auto bond0
iface bond0 inet6 static
address fd0d:ffe0:
mtu 9202
post-up ifconfig bond0 mtu 9202
That does work, and would for ens8.1024 as well. It also works for the
pure ipv6 case
auto ens8
iface ens8 inet6 static
address fd0d:ffe0:
mtu 9202
post-up ifconfig ens8 mtu 9202
If there is also going to be an inet section (for ipv4 address) then, if
the mtu is smaller than the inet mtu
we can skip emitting the post-up.
This is something that we could do in curtin as we have knowledge of all
the devices and if mtu is set
as well as any ipv4 or v6 config.
The key case to handle is not adding a post-up if the ipv6 mtu is smaller
than ipv4 mtu (or 1500 if no mtu is set).
--
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> IPv6 MTU not applied correctly for pure IPv6 interfaces
>
> To manage notifications about this bug go to:
> https:/
>