OpenFlow flow not reinject to datapath

[jesson1]

Environment and version

[root@hg02-test openvswitch]# rpm -qi openvswitch
Name        : openvswitch
Version     : 2.12.4
Release     : 7.uel20
Architecture: x86_64
Install Date: Wed 15 May 2024 05:17:11 PM CST
Group       : Unspecified
Size        : 9262287
License     : ASL 2.0 and ISC
Signature   : RSA/SHA256, Fri 01 Dec 2023 10:37:15 AM CST, Key ID 9055a64e8df595ed
Source RPM  : openvswitch-2.12.4-7.uel20.src.rpm
Build Date  : Wed 22 Nov 2023 10:04:51 AM CST
Build Host  : localhost.localdomain
Packager    : UOS
Vendor      : UOS
URL         : http://www.openvswitch.org/
Summary     : Production Quality, Multilayer Open Virtual Switch
Description :
Open vSwitch is a production quality, multilayer virtual switch licensed under
the open source Apache 2.0 license.

[root@hg02-test openvswitch]# ovs-vsctl list open
_uuid               : 68749b29-2420-4515-859a-0ddba3c17013
bridges             : [d6bbe89a-9744-462c-af03-c53ae344038d, ee1a554a-bb2a-4ba6-aef0-5c32a78ab4e8]
cur_cfg             : 5128
datapath_types      : [netdev, system]
db_version          : "8.0.0"
dpdk_initialized    : false
dpdk_version        : none
external_ids        : {hostname="hg02-test", rundir="/var/run/openvswitch", system-id="5bda1fed-3f68-40ba-9d4b-722fb11d1609"}
iface_types         : [erspan, geneve, gre, internal, "ip6erspan", "ip6gre", lisp, patch, stt, system, tap, vxlan]
manager_options     : []
next_cfg            : 5128
other_config        : {max-idle="10000"}
ovs_version         : "2.12.4"
ssl                 : []
statistics          : {}
system_type         : uos
system_version      : "20"

[root@hg02-test ~]# uname -a
Linux hg02-test 4.19.90-2305.1.0.0199.67.uel20.x86_64 #1 SMP Wed Oct 11 17:16:56 CST 2023 x86_64 x86_64 x86_64 GNU/Linux

Problem symptoms

ARP packets enter the OVS bridge through the tunnel and match the flow table：

But the n_packets for this flow table entry remains 0, and the ARP packets are not captured on the virtual machine network interfaces corresponding to 1799 and 1800.
I can ensure that the ARP packets indeed enter through the tunnel port, as I can capture and observe them：

This is very strange. Upon inspecting the datapath, I discovered that the actual forwarding port is 1795, not the port expected by the OpenFlow.：

To verify, I captured packets on the virtual machine network interface corresponding to port 1795, and indeed, I captured the ARP packet：

In my observation, it seems that the OpenFlow flow table was not pushed to the datapath, and the datapath continues to use the old rules.

My Question

• Why is the datapath in the above image not expiring? Please note the observation of 'used:148.121', indicating that there has been no traffic for at least 148 seconds. Even though I've set 'max-idle', it doesn't seem to have any effect.
  
• Why aren't OpenFlow flow tables being pushed to the datapath? Is it related to the kernel version? How should I troubleshoot this?

Thank you for taking the time to read and consider this issue. Your help and support are greatly appreciated!

[chaudron]

Your entries should expire after 10 seconds, not sure why they are not. However, as you are using a rather old/unsupported version of OVS, I would suggest upgrading first before trying to debug the issue.

[jesson1]

We may not be able to upgrade the OVS version. Could someone provide some troubleshooting ideas?

[chaudron]

The revalidator threads are responsible for cleaning up the flow table. You should first check the ovs-vswitchd log for any odd messages. If that does not show anything odd, I would set the log level for ofproto_dpif_upcall to debug and see if anything pops up.

If this does not show anything, I would find a way to upgrade the OVS version.