[systemd-networkd] MTUBytes=9000 works on adapter, but not on bridge

cbc02009 · 2022-08-14 21:58:41

I'm trying to set up jumbo frames on my home network just to test it out, but I can't seem to figure out how to change the MTU for bridged adapters. This works fine and can ping other jumbo frame enabled adapters:

10-eno1.network

[Match]
Name=eno1

[Network]
Address=10.0.0.15/16
Gateway=10.0.0.1
IPv6PrivacyExtensions=kernel

[Link]
MTUBytes=9000

but adding it to a bridge causes all the packets to get dropped:

20-bind.network

[Match]
Name=eno1

[Network]
Bridge=br0

30-br0.netdev

[NetDev]
Name=br0
Kind=bridge
MACAddress=**:**:**:**

40-br0.network

[Match]
Name=br0

[Network]
Address=10.0.0.15/16
Gateway=10.0.0.1
DNS=10.0.0.17
IPv6PrivacyExtensions=kernel

[Link]
MTUBytes=9000

I noticed that the actual adapters in the bridge don't change their MTU, could that be the cause?

br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP group default qlen 1000
...
eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000

I've been searching google and reading through the systemd-networkd manual all day and I can't think of anywhere else to set the MTU. Has anyone else experienced this and know how to fix it?

EDIT: running

ip link set mtu 9000 eno1

makes the whole thing work. not sure how to fix my networkd setup though.

Last edited by cbc02009 (2022-08-14 22:02:41)

seth · 2022-08-15 06:43:26

I noticed that the actual adapters in the bridge don't change their MTU, could that be the cause?

Yes, you need jumbo support all the way.
Do you confirm the MTU on eno1 at 9000 w/o the bridge?

https://bugs.launchpad.net/ubuntu/+sour … ug/1850704 suggests that networkd at least did not apply the MTU for NICs that are already up when is starts

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

cbc02009 · 2022-08-15 08:33:58

seth wrote:

I noticed that the actual adapters in the bridge don't change their MTU, could that be the cause?
Yes, you need jumbo support all the way.
Do you confirm the MTU on eno1 at 9000 w/o the bridge?
https://bugs.launchpad.net/ubuntu/+sour … ug/1850704 suggests that networkd at least did not apply the MTU for NICs that are already up when is starts
find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

Yes, I can confirm that without the bridge everything works perfectly using just:

10-eno1.network

[Match]
Name=eno1

[Network]
Address=10.0.0.15/16
Gateway=10.0.0.1
IPv6PrivacyExtensions=kernel

[Link]
MTUBytes=9000

Sorry, I'm not sure I understand the link you posted. it looks like it's for a much older version of systemd, and the user mentions that the issue is fixed in newer versions.

seth · 2022-08-15 12:56:03

The idea was that if something else brought the NIC up before networkd might not have touched it (and the ubuntu patch being only downstream) - that's however negated by the fact that the MTU is correctly set w/o the bridge device.
I guess you're https://github.com/systemd/systemd/issues/24311

The only guess left would be that this is due to the NIC renaming, https://wiki.archlinux.org/title/Networ … face_names
As a possible mitigation there'd be https://aur.archlinux.org/packages/networkd-dispatcher/ (or just not using systemd-networkd)

Arch Linux

#1 2022-08-14 21:58:41

[systemd-networkd] MTUBytes=9000 works on adapter, but not on bridge

#2 2022-08-15 06:43:26

Re: [systemd-networkd] MTUBytes=9000 works on adapter, but not on bridge

#3 2022-08-15 08:33:58

Re: [systemd-networkd] MTUBytes=9000 works on adapter, but not on bridge

#4 2022-08-15 12:56:03

Re: [systemd-networkd] MTUBytes=9000 works on adapter, but not on bridge

Board footer