This is about instance (VM) interface, not hypervisor physical interface.

Thanks!

Tony

On Sep 23, 2024 3:42 PM, Michael Knox <michael@knox.net.nz> wrote:

Hi Tony, 

For our clouds, we always use jumbo frames (9000) for the tenant networks. We have one cloud with a lot of Oracle RAC workloads, the large MTU helps a lot, it was a negative to use 1500 during the build out of it. Our switches are 25Gb by default, if that matters. As for our management, tooling networks, we stick with 1500, likewise with our Ceph networks. I know in a past life, where I was doing a lot of VMware, it was always jumbo frames. The layered tenant networks tend to benefit from a larger MTU. 

It's not bad practice to go to 9000 MTU, you will just need to do some validation on your fabric and make sure the changes result in an outcome that works for your cloud's workloads and the changes are supported by the switching hardware. Make sure to check if the switch vendor is exactly 1500 or 9000 (we have one Cisco ACI setup where it is a bit over 9000 due to Cisco padding). 

Hope that helps. 

Cheers

Michael 

On Mon, Sep 23, 2024 at 5:08 PM Łukasz Chrustek <lukasz@chrustek.net> wrote:

Hi Tony,

yes, I'm aware that, and already found it, thanks anyway :), but - is there any reason why this settings isn't default ?

> With this setting in neutron.conf, instance will get MTU 1500.

> [DEFAULT]
> global_physnet_mtu = 1558


> Thanks!
> Tony
> ________________________________________
> From: Łukasz Chrustek <lukasz@chrustek.net>
> Sent: September 23, 2024 11:22 AM
> To: openstack-discuss
> Subject: Network MTU setting in ovn/ovs

> Hi,

> I have a question about increasing MTU for tenant network. Now it set to 1442 by default on geneve baked tenant network.
> Is there any drawbacks or it is some kind of bad practice to increase this MTU to 1500 bytes or higher ?

> We had an issue with one migrated instance from older version of openstack (where was linuxbrigde configured), there mtu was set to 1500, so the settings for i.e. docker inside the vm was set respectively to the higher value.

> --
> Best regards
>  Lukasz Chrustek




--
Regards
 Lukasz Chrustek