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 <ssmoser2+ubu...@gmail.com> 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
-- 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 cloud-init package in Ubuntu: New Status in netplan.io package in Ubuntu: New Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Bionic: New Status in netplan.io source package in Bionic: New Status in systemd source package in Bionic: New Bug description: 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 -- 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
