On 07/05/2020 13:32, Michael Braun wrote: > A linux bridge always adopts the smallest MTU of the enslaved devices. > When no device are enslaved, it defaults to a MTU of 1500 and refuses to > use a larger one. This is problematic when using bridges enslaving only > virtual NICs (vnetX) like it's common with KVM guests. > > Steps to reproduce the problem > > 1) sudo ip link add br-test0 type bridge # create an empty bridge > 2) sudo ip link set br-test0 mtu 9000 # attempt to set MTU > 1500 > 3) ip link show dev br-test0 # confirm MTU > > Here, 2) returns "RTNETLINK answers: Invalid argument". One (cumbersome) > way around this is: > > 4) sudo modprobe dummy > 5) sudo ip link set dummy0 mtu 9000 master br-test0 > > Then the bridge's MTU can be changed from anywhere to 9000. > > This is especially annoying for the virtualization case because the > KVM's tap driver will by default adopt the bridge's MTU on startup > making it impossible (without the workaround) to use a large MTU on the > guest VMs. >
Hi Michael, That isn't correct, have you tested with a recent kernel? After: commit 804b854d374e Author: Nikolay Aleksandrov <[email protected]> Date: Fri Mar 30 13:46:19 2018 +0300 net: bridge: disable bridge MTU auto tuning if it was set manually You can set the bridge MTU to anything before adding ports. E.g.: $ ip l add br1 type bridge $ ip l set br1 mtu 65000 $ ip l sh dev br1 12: br1: <BROADCAST,MULTICAST> mtu 65000 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether b6:ad:91:dc:5f:39 brd ff:ff:ff:ff:ff:ff And a second one (ens17, ens18 with MTU 1500, br0 new with MTU 1500): $ ip l set ens17 master br0 $ ip l set ens18 master br0 $ ip l set br0 mtu 65000 $ ip l sh dev br0 11: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65000 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether fe:ed:3f:df:94:1f brd ff:ff:ff:ff:ff:ff $ ip l sh dev ens17 8: ens17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:23:5f:13 brd ff:ff:ff:ff:ff:ff > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1399064 > > Signed-off-by: Michael Braun <[email protected]> > Reported-by: Li RongQing <[email protected]> > > -- > If found > https://patchwork.ozlabs.org/project/netdev/patch/[email protected]/ > but I am missing any follow up. So here comes a refresh patch that > addresses the issue raised. > --- > net/bridge/br_if.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c > index 4fe30b182ee7..f14e7d2329bd 100644 > --- a/net/bridge/br_if.c > +++ b/net/bridge/br_if.c > @@ -496,7 +496,7 @@ static int br_mtu_min(const struct net_bridge *br) > if (!ret_mtu || ret_mtu > p->dev->mtu) > ret_mtu = p->dev->mtu; > > - return ret_mtu ? ret_mtu : ETH_DATA_LEN; > + return ret_mtu ? ret_mtu : (64 * 1024); > } > > void br_mtu_auto_adjust(struct net_bridge *br) > Please CC bridge maintainers on bridge patches. Note that there's a mechanism in the bridge to disable auto-MTU tuning if the user *changes* the MTU manually (it's important the MTU actually changes by the op). The auto-tuning has been a constant headache. The patch also has a problem - it sets the MTU over ETH_MAX_MTU (65535). Cheers, Nik
