Bug 2238969

Summary:	N/S routed traffic does not handle different network MTU sizes, if MTU external > MTU internal
Product:	Red Hat Enterprise Linux Fast Datapath	Reporter:	Rodolfo Alonso <ralonsoh>
Component:	ovn22.12	Assignee:	OVN Team <ovnteam>
Status:	CLOSED WONTFIX	QA Contact:	Jianlin Shi <jishi>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	FDP 22.L	CC:	ctrautma, jiji, mmichels
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2024-02-14 21:16:20 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:

Description Rodolfo Alonso 2023-09-14 15:11:22 UTC

Description of problem:
This BZ is related to:
* https://bugzilla.redhat.com/show_bug.cgi?id=2238494: this BZ refers to E/W traffic only.
* https://bugzilla.redhat.com/show_bug.cgi?id=1833813: this BZ tested only the case when the external network MTU was smaller than the internal network MTU.

The traffic between an external network and the internal one is routed using an OVN router. The external network is defined as gateway network.

In this BZ the condition is MTU external > MTU internal. In this case, Neutron does not set the gateway LRP:options:gateway_mtu, because the external MTU is greater. However:
* When the traffic (for example a ping) with MTU bigger than internal network MTU is sent from an external device, the 



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Deploy an OpenStack environment, using any OVN (geneve, vxlan) backend type: https://rhos-ci-jenkins.lab.eng.tlv2.redhat.com/view/QE/view/OSP17.1/
2. By default, any deployment using Jenkins will provide a flat external network named "public" with MTU=1500.
3. Create an internal network with smaller TMY:
  $ openstack network create --mtu 1200 private
  $ openstack subnet create --network private --subnet-range 10.0.120.0/28 sprivate
4. Create a router connecting both networks:
  $ openstack router create router1
  $ openstack router set --external-gateway public router1
  $ openstack router add subnet router1 sprivate
5. Create a server and a floating ip:
  $ openstack server create --network net1 --flavor cirros --image cirros server1
  $ openstack floating ip create public
  $ openstack floating ip set --port <VM_port> <FIP>
6. From the undercloud environment, ping the FIP with MTU=1400:
  $ ping <FIP> -M want -s 1400
  

Actual results:
The packet is fragmented when reaching the VM TAP device.

Expected results:
No packet is received in the VM TAP device.

Additional info:

Comment 1 Mark Michelson 2023-09-15 13:31:48 UTC

(I'm making this comment private since the comment I'm responding to is private. However, I have no idea why the original comment is private)

Hi Rodolfo, part of your explanation of the issue got cut off:

"In this BZ the condition is MTU external > MTU internal. In this case, Neutron does not set the gateway LRP:options:gateway_mtu, because the external MTU is greater. However:
* When the traffic (for example a ping) with MTU bigger than internal network MTU is sent from an external device, the "

Can you provide the rest of the context here?


Looking at the actual vs. expected results, it sounds like OVN is behaving as expected.

If you configure a gateway_mtu, then OVN responds to large packets with an ICMP "needs fragmentation" message. This would result in fragmented traffic being sent from the external client.

If you don't configure a gateway_mtu, then OVN has no knowledge of the MTU and simply attempts to forward the large packet to the client. The client's network stack presumably does the same thing as OVN would have done if a gateway_mtu were configured and sent an ICMP "needs fragmentation" message. This would again result in fragmented traffic being sent from the external client.

Do we have packet captures showing ICMP "needs fragmentation" messages being sent to the external client in this case? Do we know who is originating these ICMP messages if they exist?

Comment 2 Rodolfo Alonso 2023-09-21 14:06:31 UTC

Hello Mark:

I think I incorrectly copy/pasted the description. Let me complete it:
"""
In this BZ the condition is MTU external > MTU internal. In this case, Neutron does not set the gateway LRP:options:gateway_mtu, because the external MTU is greater. However:
* When the traffic (for example a ping) with MTU bigger than internal network MTU is sent from an external device, the packet reaches the compute node (where the VM is) and reaches br-int. However the packet is dropped in the TAP interface (smaller MTU).
* When the traffic is started from a VM, with a MTU bigger than the TAP interface, if "ping -M want" is used, the packets will be fragmented and will reach the external network device. But this device will reply with packets with size the MTU used (bigger than internal network MTU) and the same issue reported in the previous bullet point will happen.
"""

The "LRP.options.gateway_mtu" value will be set by Neutron in the case of MTU external < MTU internal. In the reported case (the opposite, MTU external > MTU internal) this config option is not set. If I manually define it, writing directly on the OVN database register, the issue persists. If I'm not wrong, this option defined in the LRP gateway port only fragments the egress traffic; in other words, it will fragment the traffic going to the external network. If the traffic coming from the external network is bigger than the "gateway_mtu" value, OVN won't fragment it.

Replying to the last question, I've tested in both directions (as reported in the first paragraph). The ICMP packets have always the DF (don't fragment) flag disabled. In the VM->external device case, if the ICMP size is bigger than the MTU, the kernel will generate the "needs fragmentation" messages. This is not happening in the other way.

Regards.

Comment 3 OVN Bot 2024-02-14 21:16:18 UTC

This issue is being closed as an automatic process due to the issue's age. If you wish to re-open this issue, please do so in Jira (https://issues.redhat.com) in the 'FDP' project. Please be sure to set the component to the latest OVN version where this issue is known to occur. If this is a feature request or improvement, please set the component to 'OVN'.