IPv6 MTU not applied correctly for pure IPv6 interfaces
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
curtin |
Fix Released
|
Medium
|
Unassigned | ||
curtin (Ubuntu) |
Fix Released
|
Medium
|
Unassigned |
Bug Description
[Impact]
* In a pure IPv6 environment: if the MTU value configured for a particular interface is greater than the value of the underlying device, the MTU for such interface will be set to the value of the device.
[Test Case]
* On a Xenial 16.04 system:
- From this YAML: http://
- Curtin generates this /e/n/i: http://
- Use the /etc/network/
- Check the MTU size of the device
PASS: bond2 has MTU 9202
FAIL: bond2 has MTU 1500
ubuntu@
4: ens8: <BROADCAST,
5: ens9: <BROADCAST,
9: bond2: <BROADCAST,
[Original Description]
[Environment]
MAAS 2.0
[Description]
The MTU size of IPv6 must be <= device MTU (which == IPv4 MTU). This requires curtin to increase the size of the dev MTU to match the IPv6 size on pure IPv6 environments. For this scenario, the solution would be to add the following lines to e/n/i:
auto bond2
iface bond2 inet manual
mtu 9202
Related branches
- Scott Moser (community): Approve
- Server Team CI bot: Approve (continuous-integration)
-
Diff: 3212 lines (+1750/-914)30 files modifiedcurtin/commands/apply_net.py (+155/-1)
curtin/commands/curthooks.py (+4/-51)
curtin/net/__init__.py (+67/-30)
curtin/net/network_state.py (+45/-1)
examples/network-ipv6-bond-vlan.yaml (+56/-0)
examples/tests/basic_network_static_ipv6.yaml (+22/-0)
examples/tests/network_alias.yaml (+125/-0)
examples/tests/network_mtu.yaml (+88/-0)
examples/tests/network_source_ipv6.yaml (+31/-0)
examples/tests/vlan_network_ipv6.yaml (+92/-0)
tests/unittests/test_net.py (+54/-13)
tests/vmtests/helpers.py (+129/-166)
tests/vmtests/test_basic.py (+17/-39)
tests/vmtests/test_bcache_basic.py (+5/-8)
tests/vmtests/test_bonding.py (+0/-205)
tests/vmtests/test_mdadm_bcache.py (+9/-11)
tests/vmtests/test_multipath.py (+5/-13)
tests/vmtests/test_network.py (+205/-352)
tests/vmtests/test_network_alias.py (+40/-0)
tests/vmtests/test_network_bonding.py (+63/-0)
tests/vmtests/test_network_enisource.py (+91/-0)
tests/vmtests/test_network_ipv6.py (+53/-0)
tests/vmtests/test_network_ipv6_enisource.py (+26/-0)
tests/vmtests/test_network_ipv6_static.py (+42/-0)
tests/vmtests/test_network_ipv6_vlan.py (+34/-0)
tests/vmtests/test_network_mtu.py (+155/-0)
tests/vmtests/test_network_static.py (+44/-0)
tests/vmtests/test_network_vlan.py (+77/-0)
tests/vmtests/test_raid5_bcache.py (+5/-8)
tests/vmtests/test_uefi_basic.py (+11/-16)
Changed in curtin (Ubuntu): | |
status: | Confirmed → Fix Committed |
status: | Fix Committed → Fix Released |
Changed in curtin: | |
status: | Fix Committed → Fix Released |
Are you suggesting that the existing eni which has mtu 9202 is not being applied correctly? That sounds like an ifupdown bug instead.
I'm attempting to reproduce in our vmtest to confirm.