Test and confirm OVN setups deployed with TripleO work with a MTU of 9000
East/West traffic works North/South doesn't when the external network has a lower MTU. Details at: https://mail.openvswitch.org/pipermail/ovs-discuss/2018-July/047039.html
More updates: TCP traffic with Jumbo frames work in OVN thanks to the mss parameter: VM (jumbo) to external network (1500): 15:13:07.703843 fe:5f:86:0e:d7:16 > 6e:f0:b7:6d:1a:7d, ethertype 802.1Q (0x8100), length 136: vlan 50, p 0, ethertype IPv4, 172.17.2.22.13222 > 172.17.2.11.6081: Geneve, Flags [C], vni 0xc, proto TEB (0x6558), options [8 bytes]: fa:16:3e:27:01:d2 > 52:54:00:87:5f:ff, ethertype IPv4 (0x0800), length 74: 192.168.10.11.36582 > 10.0.0.12.ssh: Flags [S], seq 3666828300, win 26706, options [mss 8902,sackOK,TS val 522289372 ecr 0,nop,wscale 3], length 0 ^ mss 8902 15:13:07.705051 6e:f0:b7:6d:1a:7d > fe:5f:86:0e:d7:16, ethertype 802.1Q (0x8100), length 136: vlan 50, p 0, ethertype IPv4, 172.17.2.11.39507 > 172.17.2.22.6081: Geneve, Flags [C], vni 0xa, proto TEB (0x6558), options [8 bytes]: fa:16:3e:cf:e0:be > fa:16:3e:86:c4:8c, ethertype IPv4 (0x0800), length 74: 10.0.0.12.ssh > 192.168.10.11.36582: Flags [S.], seq 897678929, ack 3666828301, win 28960, options [mss 1460,sackOK,TS val 3773538275 ecr 522289372,nop,wscale 7], length 0 ^ mss 1460 External network (1500) to VM (jumbo): 15:13:20.696155 6e:f0:b7:6d:1a:7d > fe:5f:86:0e:d7:16, ethertype 802.1Q (0x8100), length 136: vlan 50, p 0, ethertype IPv4, 172.17.2.11.53938 > 172.17.2.22.6081: Geneve, Flags [C], vni 0xa, proto TEB (0x6558), options [8 bytes]: fa:16:3e:cf:e0:be > fa:16:3e:86:c4:8c, ethertype IPv4 (0x0800), length 74: 10.0.0.12.sp-remotetablet > 192.168.10.11.ssh: Flags [S], seq 2902992110, win 29200, options [mss 1460,sackOK,TS val 3773551266 ecr 0,nop,wscale 7], length 0 ^ mss 1460 15:13:20.697077 fe:5f:86:0e:d7:16 > 6e:f0:b7:6d:1a:7d, ethertype 802.1Q (0x8100), length 136: vlan 50, p 0, ethertype IPv4, 172.17.2.22.41075 > 172.17.2.11.6081: Geneve, Flags [C], vni 0xc, proto TEB (0x6558), options [8 bytes]: fa:16:3e:27:01:d2 > 52:54:00:87:5f:ff, ethertype IPv4 (0x0800), length 74: 192.168.10.11.ssh > 10.0.0.12.sp-remotetablet: Flags [S.], seq 1283520009, ack 2902992111, win 26670, options [mss 8902,sackOK,TS val 522292621 ecr 3773551266,nop,wscale 3], length 0 ^ mss 8902 However, large ICMP and UDP packets won't work as with the reference implementation since OVN is not sending the ICMP 'need to frag' as it happens when the routing is done through iptables rules. In the OVS ML it was discussed a possible solution where we could use a network namespace as an extra hop to cover ICMP/UDP scenarios: https://mail.openvswitch.org/pipermail/ovs-discuss/2018-July/047086.html It's possibly not a good solution performance wise but otherwise it'll require kernel changes. For now, I think we should document the limitation as TCP connections work. The tests have been done on a OSP13 virtual setup deployed with infrared where the linux bridge interfaces of the host have been adjusted to mtu 9000 as well as the involved interfaces in every virtual node.
*** Bug 1697118 has been marked as a duplicate of this bug. ***
Verified on 16.1-RHEL-8/RHOS-16.1-RHEL-8-20200511.n.0 with python3-networking-ovn-7.1.1-0.20200507153427.fd1c0c3.el8ost.noarch Verified on an environment supporting 9000 bytes MTU on all bridges and nodes. External network MTU was configured to 1500. Verified that OVN router sends ICMP 'fragmentation needed' packet with maximal possible MTU in case a UDP/ICMP packet bigger than external network MTU should be forwarded to the external network. Verified that udp/ICMP packets with maximal possible MTU reported bt router are able to pass to the external network. Verified that TCP traffic is not affected and is able to pass as before. Verified also that after changing the MTU value for the network the value in ICMP message changes accordingly.
If this bug requires doc text for errata release, please set the 'Doc Type' and provide draft text according to the template in the 'Doc Text' field. The documentation team will review, edit, and approve the text. If this bug does not require doc text, please set the 'requires_doc_text' flag to '-'.
As appeared the feature is not working on the latest pudles Core ovn bz: https://bugzilla.redhat.com/show_bug.cgi?id=1850962 OSP bz: https://bugzilla.redhat.com/show_bug.cgi?id=1850957 Moving the RFE to FailedQA because we cant release it now
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Red Hat OpenStack Platform 16.1 bug fix and enhancement advisory), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2020:4284