Comment 7 for bug 1889454

This has caused a lot of nuisance reports from users and engineers alike when working on OpenStack systems. I looked into this and found the following:

- This error refers specifically to the MTU being too large when attempting to transmit a packet out of openvswitch onto the linux interface 'br-int', which is a 'LOCAL' port plugged into the br-int switch. As opposed to transmitting a packet into the br-int "switch" or some other real port.

- This happens generally for both broadcast/multicast packets and when packets are "flooded" due to the location of the MAC being unknown (which is a normal occurance due to l2 switching table expiry). However the packets are not useful, since the interface is down, they don't go anywhere. Hence the error is harmless and does not represent a real problem. Note that such errors with a different interface name such as a tap device, physical device, etc are likely to be real errors and should not be ignored. They can only be ignored for these un-used "LOCAL" ports with the same name as the bridge, i.e. br-int.

- The MTU of this br-int 'local' port follows the minimum MTU of all ports plugged into the switch, you can temporarily set it with "ip link set" however the next time a port is added or removed from the switch, it will be reset.

- It is expected to have interfaces with different MTUs on br-int when you have networks with different MTUs, and this shows particularly in the case of DVR where you have native (1500) byte MTU external networks and GRE/VXLAN overlay networks with a reduce MTU on the same br-int. But it can also happen without DVR with tenant networks of different MTUs or when you connect provider networks directly to VMs.

- This "local" br-int port on the switch is not used in OpenStack, and is down, despite that, the current openvswitch kernel code attempts to transmit the packet out this down interface resulting in the MTU error. I have looked at whether it would be a sensible operation to skip this at the openvswitch level or not but have not come to a determination on that.

- You can request openvswitch to set this MTU specifically to some other value, using the following ovs-vsctl command to set the mtu_request parameter. This is a harmless workaround that prevents the error from being logged and I would recommend people use that. I also think that neutron should make this request itself. Note that 9000 suits most environments but it needs to be set to the same (or at least higher) value as global-physnet-mtu. This setting is stored in the OVS database and will persist reboots/restarts.

 ovs-vsctl set Interface br-int mtu_request=9000