[Openstack-operators] MTU on Provider Networks

John Petrini jpetrini at coredial.com
Thu Sep 14 18:10:48 UTC 2017

Hi List,

We are running Mitaka and having an MTU issue. Instances that we launch on
our provider network use Jumbo Frames (9000 MTU). There is a Layer2 link
between the OpenStack switches and our Core. This link uses and MTU of

Up until recently this MTU mismatch has not been an issue because none of
our systems are sending large enough packets to cause a problem. Recently
we've begun implementing a SIP device that sends very large packets,
sometimes even over 9000 bytes and requires fragmentation.

What we found in our troubleshooting is that when large packets originate
from our network to an instance in OpenStack they are being fragmented (as
expected). Once these packets reach the qbrXXXXXXXX-XX port iptables
defragments the packet and forwards it to the tap interface unfragmented.
If we set the MTU on the tap interface to 1500 it will refragment the
packet before forwarding it to the instance.

A similar issue happens the other direction. Large packets originating from
the OpenStack instance are fragmented (we set the mtu of the interface in
the instance to 1500 so this is expected) but again once the packets reach
the qbr-XXXXXXXX-XX interface iptables defragments them again. If we set
the MTU of the qvbXXXXXXXX-XX to 1500 the packet is refragmented.

So long story short if we set the instance MTU to 1500 and the
qbrXXXXXXXX-XX and qvbXXXXXXXX-XX ports on the compute node to 1500 MTU the
packets remain fragmented and are able to traverse the network.

So the question becomes can we modify the default MTU of our provider
networks so that the instances created on this network receive a 1500 MTU
from DHCP and the ports on the compute node are also configured to a 1500

I've been looking at the following neutron config option in

physical_network_mtus =physnet1:9000,providernet:9000

Documentation on this setting is not very clear. Will adjusting this to
1500 for providernet accomplish what we need?

Thank You,

John Petrini
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170914/0fa23667/attachment.html>

More information about the OpenStack-operators mailing list