Bug 1945506

Summary: OCP on OSP. ML2/OVN w DVR fails to build SDN infrastructure properly if detached ports with FIPs are used for communication
Product: Red Hat OpenStack Reporter: Alex Stupnikov <astupnik>
Component: python-networking-ovnAssignee: ffernand <ffernand>
Status: CLOSED DUPLICATE QA Contact: Eran Kuris <ekuris>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 16.1 (Train)CC: afariasa, apevec, ffernand, lhh, lmartins, majopela, scohen
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: ovn2.13-20.12.0-149.el8fdp Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-09-10 15:03:56 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 Alex Stupnikov 2021-04-01 07:44:09 UTC
Description of problem:

One of our customers is running RHOSP 16.1 ML2/OVN deployment with DVR and faces communication problems when two VMs from same tenant network are using Floatig IPs to communicate with each other. This case is a bit special for the following reasons:

- one of VMs (client) should have used floating IP attached to its port. But in reality we can see that server sees SNAT source IP from client side instead of VM's FIP
- second VM (server) is using Fixed IP and FIP addresses from detached port to server client's requests
- from VM's perspective we can see that TCP connection is established, client is able to trasfer initial request and get TCP ack from server, server is able to transfer some data in return, but client's TCP acks can't reach the server.

We have collected some tcpdumps to understand this issue better and it looks like this problem is caused by asymmetric traffic and inconsistent processing of affected TCP flow by stateful firewall.

I will provide more information about IP addresses and data we have privately.