Bug 1547074
| Summary: | [OVN] South->north ipv4 path MTU discovery support | |||
|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Bernard Cafarelli <bcafarel> | |
| Component: | python-networking-ovn | Assignee: | Lucas Alvares Gomes <lmartins> | |
| Status: | CLOSED ERRATA | QA Contact: | Roman Safronov <rsafrono> | |
| Severity: | high | Docs Contact: | ||
| Priority: | high | |||
| Version: | 16.0 (Train) | CC: | agoossen, ahleihel, amuller, apevec, astillma, atragler, chrisw, dalvarez, djuran, dsneddon, ekuris, fhallal, haili, jamsmith, jiji, jlibosva, jschluet, lariel, lhh, lmartins, majopela, mburrows, mleitner, njohnston, nlevinki, nusiddiq, rhos-maint, rsafrono, scohen, tfreger, tredaelli | |
| Target Milestone: | z2 | Keywords: | Triaged | |
| Target Release: | 16.1 (Train on RHEL 8.2) | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | docs-accepted | |||
| Fixed In Version: | python-networking-ovn-7.0.1-0.20191205040313.2ef5322.el8ost | Doc Type: | Known Issue | |
| Doc Text: |
Transmission of jumbo UDP frames on ML2/OVN routers depends on a kernel release that is not yet available.
+
After receiving a jumbo UDP frame that exceeds the maximum transmission unit of the external network, ML2/OVN routers can return ICMP "fragmentation needed" packets back to the sending VM, where the sending application can break the payload into smaller packets. To determine the packet size, this feature depends on discovery of MTU limits along the south-to-north path.
+
South-to-north path MTU discovery requires kernel-4.18.0-193.20.1.el8_2, which is scheduled for availability in a future release. To track availability of the kernel version, see https://bugzilla.redhat.com/show_bug.cgi?id=1860169.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1702331 1702564 (view as bug list) | Environment: | ||
| Last Closed: | 2020-10-28 15:36:47 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | 1553839, 1700733, 1702564, 1850957, 1854084 | |||
| Bug Blocks: | 1685634, 1702331, 1842606 | |||
|
Description
Bernard Cafarelli
2018-02-20 13:15:21 UTC
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 |