Bug 2138133
| Summary: | [16.2][OVN][HWOFFLOAD][TRANSPARENT VLAN] Flows removed after 2 minutes | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Miguel Angel Nieto <mnietoji> |
| Component: | openvswitch | Assignee: | Eelco Chaudron <echaudro> |
| Status: | CLOSED NOTABUG | QA Contact: | Eran Kuris <ekuris> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 16.2 (Train) | CC: | apevec, cfontain, chrisw, echaudro, egarciar, fleitner, hakhande, mleitner |
| Target Milestone: | --- | Keywords: | Triaged |
| 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: | 2022-11-25 07:31: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: | |||
|
Description
Miguel Angel Nieto
2022-10-27 10:51:07 UTC
Are there any other tests or changes in the cluster happening in parallel? Because if you adding/removing ports from OVS, for example, the data path flows might have to change as well and then you see the behavior reported. fbl No, there is anything happening in parallel. This behaviour is only happening with transparent vlan and tcp traffic. It is working fine for icmp and udp and for vlan, geneve or vlan trunk Is there an easy way to replicate this without OCP (or even better OVN ;). Any update on #3? Hi, I do not know how to reproduce it with ovs only, maybe i can reproduce it in the way I opened the bug and you can connect to the setup to debug it. Changing DFG to NFV. Please reach back if there is anything we need to check. Thanks! To confirm, after changing the MTU to 1500, I do not see the representor traffic for the active TCP session. Only the occasional ARPs for which the flows have timed out. [heat-admin@computehwoffload-r740-0 ~]$ sudo tcpdump -i ens6f1_0 -nne dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ens6f1_0, link-type EN10MB (Ethernet), capture size 262144 bytes 13:33:35.351301 fa:16:3e:a9:06:cf > fa:16:3e:80:38:21, ethertype 802.1Q (0x8100), length 56: vlan 146, p 0, ethertype ARP, Request who-has 60.60.220.101 tell 60.60.220.100, length 38 13:33:35.351355 fa:16:3e:80:38:21 > fa:16:3e:a9:06:cf, ethertype 802.1Q (0x8100), length 52: vlan 146, p 0, ethertype ARP, Reply 60.60.220.101 is-at fa:16:3e:80:38:21, length 34 13:34:10.679312 fa:16:3e:a9:06:cf > fa:16:3e:80:38:21, ethertype 802.1Q (0x8100), length 56: vlan 146, p 0, ethertype ARP, Request who-has 60.60.220.101 tell 60.60.220.100, length 38 13:34:10.679381 fa:16:3e:80:38:21 > fa:16:3e:a9:06:cf, ethertype 802.1Q (0x8100), length 52: vlan 146, p 0, ethertype ARP, Reply 60.60.220.101 is-at fa:16:3e:80:38:21, length 34 13:34:46.007310 fa:16:3e:a9:06:cf > fa:16:3e:80:38:21, ethertype 802.1Q (0x8100), length 56: vlan 146, p 0, ethertype ARP, Request who-has 60.60.220.101 tell 60.60.220.100, length 38 13:34:46.007372 fa:16:3e:80:38:21 > fa:16:3e:a9:06:cf, ethertype 802.1Q (0x8100), length 52: vlan 146, p 0, ethertype ARP, Reply 60.60.220.101 is-at fa:16:3e:80:38:21, length 34 13:35:21.335277 fa:16:3e:a9:06:cf > fa:16:3e:80:38:21, ethertype 802.1Q (0x8100), length 56: vlan 146, p 0, ethertype ARP, Request who-has 60.60.220.101 tell 60.60.220.100, length 38 13:35:21.335343 fa:16:3e:80:38:21 > fa:16:3e:a9:06:cf, ethertype 802.1Q (0x8100), length 52: vlan 146, p 0, ethertype ARP, Reply 60.60.220.101 is-at fa:16:3e:80:38:21, length 34 13:35:56.663360 fa:16:3e:a9:06:cf > fa:16:3e:80:38:21, ethertype 802.1Q (0x8100), length 56: vlan 146, p 0, ethertype ARP, Request who-has 60.60.220.101 tell 60.60.220.100, length 38 13:35:56.663423 fa:16:3e:80:38:21 > fa:16:3e:a9:06:cf, ethertype 802.1Q (0x8100), length 52: vlan 146, p 0, ethertype ARP, Reply 60.60.220.101 is-at fa:16:3e:80:38:21, length 34 13:36:31.991377 fa:16:3e:a9:06:cf > fa:16:3e:80:38:21, ethertype 802.1Q (0x8100), length 56: vlan 146, p 0, ethertype ARP, Request who-has 60.60.220.101 tell 60.60.220.100, length 38 13:36:31.991437 fa:16:3e:80:38:21 > fa:16:3e:a9:06:cf, ethertype 802.1Q (0x8100), length 52: vlan 146, p 0, ethertype ARP, Reply 60.60.220.101 is-at fa:16:3e:80:38:21, length 34 13:37:07.319411 fa:16:3e:a9:06:cf > fa:16:3e:80:38:21, ethertype 802.1Q (0x8100), length 56: vlan 146, p 0, ethertype ARP, Request who-has 60.60.220.101 tell 60.60.220.100, length 38 13:37:07.319467 fa:16:3e:80:38:21 > fa:16:3e:a9:06:cf, ethertype 802.1Q (0x8100), length 52: vlan 146, p 0, ethertype ARP, Reply 60.60.220.101 is-at fa:16:3e:80:38:21, length 34 13:37:42.647356 fa:16:3e:a9:06:cf > fa:16:3e:80:38:21, ethertype 802.1Q (0x8100), length 56: vlan 146, p 0, ethertype ARP, Request who-has 60.60.220.101 tell 60.60.220.100, length 38 13:37:42.647419 fa:16:3e:80:38:21 > fa:16:3e:a9:06:cf, ethertype 802.1Q (0x8100), length 52: vlan 146, p 0, ethertype ARP, Reply 60.60.220.101 is-at fa:16:3e:80:38:21, length 34 13:38:17.975361 fa:16:3e:a9:06:cf > fa:16:3e:80:38:21, ethertype 802.1Q (0x8100), length 56: vlan 146, p 0, ethertype ARP, Request who-has 60.60.220.101 tell 60.60.220.100, length 38 13:38:17.975422 fa:16:3e:80:38:21 > fa:16:3e:a9:06:cf, ethertype 802.1Q (0x8100), length 52: vlan 146, p 0, ethertype ARP, Reply 60.60.220.101 is-at fa:16:3e:80:38:21, length 34 The issue was caused by the MTU, when reducing the MTU in the vm, then it works fine. Closing the BZ |