Linux odie 4.8.0-53-generic #56~16.04.1-Ubuntu SMP Tue May 16 01:18:56 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Here the answer is yes and no.
The mtu is configured via systemd-networkd:
# grep MTU /etc/systemd/network/*
/etc/systemd/network/10-c42-bond0.netdev:MTUBytes=9000
/etc/systemd/network/10-c42-bslave1.link:MTUBytes=9000
/etc/systemd/network/10-c42-bslave2.link:MTUBytes=9000
After boot the MTU on all these interfaces is 1500.
It needs the command 'ip l set bond0 mtu 9000'
to switch all these interfaces together to jumbo frames.
Before this bug occurs (e.g. 4.8.0-46), it has been working without explicitly setting the MTU on the command line.
The same misbehaviour is on a second hardware:
Linux dilbert 4.10.0-21-generic #23~16.04.1-Ubuntu SMP Tue May 2 12:57:17 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
So the situation is for me:
Jumbo Frames are working again, but there seems to be a conflict with systemd 229.
Linux odie 4.8.0-53-generic #56~16.04.1-Ubuntu SMP Tue May 16 01:18:56 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Here the answer is yes and no.
The mtu is configured via systemd-networkd: network/ * network/ 10-c42- bond0.netdev: MTUBytes= 9000 network/ 10-c42- bslave1. link:MTUBytes= 9000 network/ 10-c42- bslave2. link:MTUBytes= 9000
# grep MTU /etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
After boot the MTU on all these interfaces is 1500.
It needs the command 'ip l set bond0 mtu 9000'
to switch all these interfaces together to jumbo frames.
Before this bug occurs (e.g. 4.8.0-46), it has been working without explicitly setting the MTU on the command line.
The same misbehaviour is on a second hardware:
Linux dilbert 4.10.0-21-generic #23~16.04.1-Ubuntu SMP Tue May 2 12:57:17 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
So the situation is for me:
Jumbo Frames are working again, but there seems to be a conflict with systemd 229.