Bug 1795790
| Summary: | ACL with action reject never sends TCP reset | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux Fast Datapath | Reporter: | Tim Rozet <trozet> | ||||||
| Component: | OVN | Assignee: | Numan Siddique <nusiddiq> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Jianlin Shi <jishi> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | RHEL 8.0 | CC: | ctrautma, nusiddiq | ||||||
| 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: | 2020-04-06 15:09:53 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: | |||||||||
| Bug Blocks: | 1772655, 1810567, 1810570 | ||||||||
| Attachments: |
|
||||||||
The egress pipeline may not be what's dropping the packet. Numan may have some more insights into this. Looks like it is not possible to handle the TCP reset via OF: [root@ovn-control-plane ~]# ovs-ofctl -O openflow14 add-flow br-int 'table=0,tcp,tcp_flags=0,action=load:0x1->NXM_NX_TCP_FLAGS' 2020-02-03T18:30:24Z|00001|meta_flow|WARN|destination field tcp_flags is not writable There is also no mechanism today for OVN to be able to configure conntrack to send the reset. Therefore the packet is punted to controller, and the controller then sends a packet out. Numan noticed the packet out is being dropped by ovs-vswitchd: 2020-01-28T17:38:55.498Z|00028|ofproto_dpif_upcall(handler10)|INFO|received packet on unassociated datapath port 4294967295 @Tim - Can you please try this patch yourself if possible ? https://github.com/numansiddique/ovn/commit/1e83bddfc0e2230830f005cea72beeb53557d00a https://github.com/numansiddique/ovn/tree/tcp_reset_fix/v1 I am planning to write some system tests. I will submit the patch for review after the system tests. Thanks Numan I'll give it a try today. Thanks. The fix didn't seem to work. I still see the unassociated datapath. I'll ping you tomorrow morning my time and we can take a look at it. Attached the ovn trace output. Created attachment 1658027 [details]
fix logs
Actually I just realized I built off of the wrong ovn branch. Will fix it tmrw. Patch submitted for review - https://patchwork.ozlabs.org/patch/1234149/ Tested and it works for me! Fix is now available upstream. Is this downstream yet? Yes. Its alredy available d/s in ovn2.12 and ovn2.13 And its already addressed in this bz https://bugzilla.redhat.com/show_bug.cgi?id=1805651 I'll close this BZ. *** This bug has been marked as a duplicate of bug 1805651 *** |
Created attachment 1656119 [details] logs Description of problem: Creating an ACL with reject action never actually sends a TCP reset. The packet gets punted to the controller and then eventually dropped in egress pipeline. Version-Release number of selected component (if applicable): [root@ovn-control-plane ~]# rpm -qa | egrep 'ovn|openvswitch' openvswitch-2.12.0-1.fc31.x86_64 ovn-2.12.0-5.fc31.x86_64 ovn-host-2.12.0-5.fc31.x86_64 ovn-central-2.12.0-5.fc31.x86_64 How reproducible: Always Steps to Reproduce: 1. Create an ACL in OVN like: from-lport 1000 (ip4.dst==10.98.35.163 && tcp && tcp.dst==58585) reject 2. curl or create a tcp connection to the address 3. connection will eventually time out Actual results: connection timeout Expected results: TCP reset should be received. Additional info: See attachment for full output. There seems to be several problems with the current behavior: 1. Why are packets punted to the controller for TCP reset? Shouldn't this be handled via OpenFlow and conntrack? 2. If there is some reason for #1, there should be rate limiting on sending these packets to the controller. Otherwise an attacker could exploit this. 3. Why is the egress pipeline dropping the packet?