Bug 2162083

Summary: [OSP17.0][OVN][MTU] IPv6 traffic ignores logical switch external_ids neutron:mtu and logical router port gateway_mtu settings
Product: Red Hat Enterprise Linux Fast Datapath Reporter: Miro Tomaska <mtomaska>
Component: OVNAssignee: OVN Team <ovnteam>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Jianlin Shi <jishi>
Severity: unspecified Docs Contact:
Priority: high    
Version: FDP 22.GCC: ctrautma, ihrachys, jiji, lorenzo.bianconi, 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: 2023-02-06 16:41:22 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 Miro Tomaska 2023-01-18 17:56:22 UTC
It appears there is a regression from the BZ1846300 we have closed in 16.1.
According to testing mentioned in BZ1839847 comment 10 the issue still repdroduces in RHOSP 17.0.

To reproduce the issue follow comment#3 from BZ 1839847. I am going to paste it here

Reproducing steps:
I have virtual bridges on hypervisor allowing 9000 and all interfaces on nodes allowing mtu 9000.
I configured external network with mtu set to 1500.
Test1  If I send a big ipv4 packet with size 8800 from vm on the internal network it is not passing to the external network (dropped) - OK
Test2, If send a big ipv6 packet with size 8800 from vm on the internal network it is passing to the external network (single big full size packet just reaches) - not as expected, because configured neutron mtu and/or logical switch external_ids neutron:mtu are ignored. 
Test3, If I send a bigger ipv6 packet with size 8900 it is not reached (it's expected) but path mtu discovery is not working (see tracepath6 output) - not OK, according to the mail from Anita that you mentioned it is expected to be working somehow ("MTU path discovery should already handle it"). But as I wrote above we can create a separate BZ (RFE) for this issue.

Comment 1 lorenzo bianconi 2023-01-24 18:51:23 UTC
(In reply to Miro Tomaska from comment #0)
> It appears there is a regression from the BZ1846300 we have closed in 16.1.
> According to testing mentioned in BZ1839847 comment 10 the issue still
> repdroduces in RHOSP 17.0.
> 
> To reproduce the issue follow comment#3 from BZ 1839847. I am going to paste
> it here
> 
> Reproducing steps:
> I have virtual bridges on hypervisor allowing 9000 and all interfaces on
> nodes allowing mtu 9000.
> I configured external network with mtu set to 1500.
> Test1  If I send a big ipv4 packet with size 8800 from vm on the internal
> network it is not passing to the external network (dropped) - OK
> Test2, If send a big ipv6 packet with size 8800 from vm on the internal
> network it is passing to the external network (single big full size packet
> just reaches) - not as expected, because configured neutron mtu and/or
> logical switch external_ids neutron:mtu are ignored. 
> Test3, If I send a bigger ipv6 packet with size 8900 it is not reached (it's
> expected) but path mtu discovery is not working (see tracepath6 output) -
> not OK, according to the mail from Anita that you mentioned it is expected
> to be working somehow ("MTU path discovery should already handle it"). But
> as I wrote above we can create a separate BZ (RFE) for this issue.

Are you using DVR scenario? If so, can you please check the configured MTU of the physical NICs used to access the underlay network (localnet interfaces)? If not, can you please check the MTU size of each interfaces used to carry geneve traffic? In both cases they should be over the gateway configured MTU (OVN gateway_mtu).
Moreover, can you please share OVN nb/sb dbs?

Comment 2 Miro Tomaska 2023-02-06 16:41:22 UTC
Hi Lorenzo,

I discussed this issue with Slawek who mentioned in BZ18939847 comment#10 that he was able to reproduce it in 17.0 but does not remember the setup. Roman who originally filled the BZ does not also recall how to reproduce it. Finally, i was not able to reproduce it. I am just going to close this BZ as "insufficient data"

Comment 3 Red Hat Bugzilla 2023-09-19 04:32:36 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days