Linux bridges have their MTU overwritten when you add an interface

  • Post author:
  • Post category:Linux

I discovered last night that network bridges on linux have their Maximum Transmission Unit (MTU) overwritten by whatever is the MTU value of the most recent interface added to the bridge. This is bad. Very bad. Specifically this is bad because MTU matters for accurately describing the capabilities of the network path the packets will travel on, so it shouldn't be clobbered willy nilly. Here's an example of the behaviour: # ip link add egr-br-ens1f0 mtu 1500 type bridge # ip link show dev egr-br-ens1f0 3: egr-br-ens1f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 7e:33:1b:30:d8:00 brd ff:ff:ff:ff:ff:ff # ip link add egr-eaa64a-o mtu 8950 type veth peer name egr-eaa64a-i # ip link show dev egr-br-ens1f0 3: egr-br-ens1f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 7e:33:1b:30:d8:00 brd ff:ff:ff:ff:ff:ff # brctl addif egr-br-ens1f0 egr-eaa64a-o # ip link show dev egr-br-ens1f0 3: egr-br-ens1f0: <BROADCAST,MULTICAST> mtu 8950 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether da:82:cf:34:13:60 brd ff:ff:ff:ff:ff:ff So you can see here that the bridge had an MTU of 1,500 bytes. We create a veth pair with an MTU of 8,950 bytes and add it to…

Continue ReadingLinux bridges have their MTU overwritten when you add an interface

Juno nova mid-cycle meetup summary: bug management

  • Post author:
  • Post category:OpenStack

Welcome to the next exciting installment of the Nova Juno mid-cycle meetup summary. In the previous chapter, our hero battled a partially complete cells implementation, by using his +2 smile of good intentions. In this next exciting chapter, watch him battle our seemingly never ending pile of bugs! Sorry, now that I'm on to my sixth post in this series I feel like it's time to get more adventurous in the introductions. For at least the last cycle, and probably longer, Nova has been struggling with the number of bugs filed in Launchpad. I don't think the problem is that Nova has terrible code, it is instead that we have a lot of users filing bugs, and the team working on triaging and closing bugs is small. The complexity of the deployment options with Nova make this problem worse, and that complexity increases as we allow new drivers for things like different storage engines to land in the code base. The increasing number of permutations possible with Nova configurations is a problem for our CI systems as well, as we don't cover all of these options and this sometimes leads us to discover that they don't work as expected in…

Continue ReadingJuno nova mid-cycle meetup summary: bug management

End of content

No more pages to load