From a testing environment and the patch made by Yamen, I was able to test and validate the behavior of OVN when ovn_need_emit_frag is enabled. For some supplementary details, with the current implementation of OVN, it will only emit a "Need to frag" packet in the direction of Internal to External network. The motivation behind was in the case where Jumbo frames are enabled, internal network could be with a higher MTU around 8900 but some external networks could be stuck at the more classical MTU of 1500. It will not work between internal to internal network of different MTU and neither from external to internal networks. From the ongoing patch, it will most likely work on any new installation. But if upgrading the charm, it will be most likely required to restart manually neutron-server.service on all neutron-api units for the changes to be taken into account. The details about the testing environment : * Internal network: 192.168.123.0/24 with MTU 1442 * External network: 192.168.21.0/24 with MTU 900 * self-inst1 is hosted solely on the internal network but with a floating IP to the external network * a router is configured with the external network as default gateway Below are the tests after applying the charm with the fix from Yamen. (It wouldn't work at all otherwise on current versions of the charm) # # Part 1 ping under the MTU limit # ubuntu@self-inst1:~$ ping 192.168.21.2 -c 2 -M do -s 800 [1/1] PING 192.168.21.2 (192.168.21.2) 800(828) bytes of data. 808 bytes from 192.168.21.2: icmp_seq=1 ttl=63 time=3.26 ms 808 bytes from 192.168.21.2: icmp_seq=2 ttl=63 time=1.45 ms # # Part 2 ping over the MTU limit # ubuntu@self-inst1:~$ ping 192.168.21.2 -c 2 -M do -s 1400 PING 192.168.21.2 (192.168.21.2) 1400(1428) bytes of data. From 192.168.123.1 icmp_seq=1 Frag needed and DF set (mtu = 900) ping: local error: message too long, mtu=900 ubuntu@self-inst1:~$ sudo tcpdump -lnei ens2 icmp sudo: unable to resolve host self-inst1: Temporary failure in name resolution tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on ens2, link-type EN10MB (Ethernet), snapshot length 262144 bytes # # Part 1 under the MTU # 07:00:08.653716 fa:16:3e:11:ea:c9 > fa:16:3e:a1:5e:ee, ethertype IPv4 (0x0800), length 842: 192.168.123.168 > 192.168.21.2: ICMP echo request, id 1, seq 1, length 808 07:00:08.656941 fa:16:3e:a1:5e:ee > fa:16:3e:11:ea:c9, ethertype IPv4 (0x0800), length 842: 192.168.21.2 > 192.168.123.168: ICMP echo reply, id 1, seq 1, length 808 07:00:09.655592 fa:16:3e:11:ea:c9 > fa:16:3e:a1:5e:ee, ethertype IPv4 (0x0800), length 842: 192.168.123.168 > 192.168.21.2: ICMP echo request, id 1, seq 2, length 808 07:00:09.657005 fa:16:3e:a1:5e:ee > fa:16:3e:11:ea:c9, ethertype IPv4 (0x0800), length 842: 192.168.21.2 > 192.168.123.168: ICMP echo reply, id 1, seq 2, length 808 # # Part 2 requesting a packet over the MTU # 07:10:27.676260 fa:16:3e:a1:5e:ee > fa:16:3e:11:ea:c9, ethertype IPv4 (0x0800), length 576: 192.168.123.1 > 192.168.123.168: ICMP 192.168.21.2 unreachable - need to frag (mtu 900), length 542