Ian Wells <ijw.ubu...@cack.org.uk> wrote:
Right. Note that custom MTU works out of the box only starting from Mitaka.
It's been in from at least Kilo (give or take a some bugfixes, it seems,
all of which deserve backporting).
It never worked as you would expect, though indeed a lot of code to
calculate MTU was in place.
- It won’t work in OVS hybrid setup, where intermediate devices (qbr)
will still have mtu = 1500, that will result in Jumbo frames dropped. We
have backports to fix it in Liberty at:
https://review.openstack.org/305782 and
https://review.openstack.org/#/c/285710/
Indeed, you can actively request the MTU per virtual network as you
create them, subject to segment_mtu and path_mtu indicating they're
achievable.
No. MTU is not available for setting during network creation. It’s only
calculated as per get_mtu() [relying on path_mtu and physical_network_mtus
and segment_mtu; note the latter is renamed since Mitaka into
global_physnet_mtu].
In this instance, configure your switches with a 9000 MTU and set
segment_mtu = path_mtu = 9000. The virtual network MTU will then default
to 8950 for a VXLAN network (the biggest possible packet inside VXLAN in
that circumstance) and you can choose to set it to anything else below
that number as you net-create. The MTU should be correctly advertised by
DHCP when set.
As I said, no, you can’t set it on network creation.
Also, having the network using 8950 is not enough for Jumbo frames, because
till Mitaka (and the next minor Liberty release) Nova was not using that
value to bump MTU for intermediate devices participating in the hybrid
bridge setup.
I hope you don't find you have to do what Akihiro suggests. That was
good advice about three releases back but nowadays it actually breaks the
code that's there to deal with MTUs properly.
Yes, indeed it’s not needed since Kilo to modify dnsmasq configuration to
set the option. advertise_mtu is now True since Mitaka, and for earlier
releases, you just set it to True explicitly.
Ihar
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
