[ovs-dev] [PATCH RFC v2 0/8] Introduce connection tracking tc offload

Paul Blakey paulb at mellanox.com
Sat Jul 20 08:26:59 UTC 2019

Hi Marcelo, thanks for reporting this, can you dump the datapath rules via ovs-appctl dpctl/dump-flows -m --names
Also running "tc filter show dev ns2-veth-ab ingress" while it happened can show us more details.

I'll try and reproduce it on my end.
How often does this happen? and what is the setup ?

From: Marcelo Ricardo Leitner <marcelo.leitner at gmail.com>
Sent: Friday, July 19, 2019 12:59:26 AM
To: Paul Blakey
Cc: dev at openvswitch.org; Roi Dayan; Yossi Kuperman; Rony Efraim; Oz Shlomo; David Miller; Aaron Conole; John Hurley; Simon Horman; Justin Pettit; Joe Stringer; Ben Pfaff
Subject: Re: [PATCH RFC v2 0/8] Introduce connection tracking tc offload

On Thu, Jul 04, 2019 at 05:28:19PM +0300, Paul Blakey wrote:
> Hi,
> The following patches add connection tracking offload to tc.
> We plan on offloading the datapath rules to netdev one to one to tc rules.
> We'll be using upcoming act_ct tc module which is currently under review in netdev for the datapath ct() action.
> Tc chains and tc goto chain action for the recirc_id() match and recirc() action.
> cls_flower will do the matching on skb conntrack metadata for the ct_state matches.
> The patchset for act_ct and cls_flower is here: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flwn.net%2FArticles%2F791584%2F&amp;data=02%7C01%7Cpaulb%40mellanox.com%7C8dee9790121f41af67d408d70bcb35e2%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636990839726360059&amp;sdata=1EU4nuslHxzKahEkN%2BvkvhEc3ZvZtoWhfwZg6pKO%2BDA%3D&amp;reserved=0
> So datapath ovs connection tracking rules:
> recirc_id(0),in_port(ens1f0_0),ct_state(-trk),... actions:ct(zone=2),recirc(2)
> recirc_id(2),in_port(ens1f0_0),ct_state(+new+trk),ct_mark(0xbb),... actions:ct(commit,zone=2,nat(src=,mark=0xbb),ens1f0_1
> recirc_id(2),in_port(ens1f0_0),ct_state(+est+trk),ct_mark(0xbb),... actions:ct(zone=2,nat),ens1f0_1
> recirc_id(1),in_port(ens1f0_1),ct_state(-trk),... actions:ct(zone=2),recirc(1)
> recirc_id(1),in_port(ens1f0_1),ct_state(+est+trk),... actions:ct(zone=2,nat),ens1f0_0

Hi Paul,

Sometimes I'm seeing ghosts^Wbogus values with nat:

[root at localhost ~]# ovs-ofctl dump-flows br0
 cookie=0x0, duration=788.595s, table=0, n_packets=3, n_bytes=180, priority=50,ct_state=-trk,tcp,in_port="ns2-veth-ab" actions=ct(table=0,zone=2)
 cookie=0x0, duration=788.584s, table=0, n_packets=0, n_bytes=0, priority=50,ct_state=-trk,tcp,in_port="ns1-veth-ab" actions=ct(table=0,zone=2)
 cookie=0x0, duration=788.589s, table=0, n_packets=3, n_bytes=180, priority=50,ct_state=+new+trk,tcp,in_port="ns2-veth-ab" actions=ct(commit,zone=2,nat(src=,output:"ns1-veth-ab"
 cookie=0x0, duration=788.551s, table=0, n_packets=0, n_bytes=0, priority=50,ct_state=+est+trk,tcp,in_port="ns1-veth-ab" actions=ct(zone=2,nat),output:"ns2-veth-ab"
 cookie=0x0, duration=788.546s, table=0, n_packets=0, n_bytes=0, priority=50,ct_state=+est+trk,tcp,in_port="ns2-veth-ab" actions=ct(zone=2,nat),output:"ns1-veth-ab"
 cookie=0x0, duration=788.531s, table=0, n_packets=22, n_bytes=1672, priority=10 actions=NORMAL

[root at localhost ~]# cat /proc/net/nf_conntrack
ipv4     2 tcp      6 26 SYN_SENT src= dst= sport=41524 dport=5001 [UNREPLIED] src= dst= sport=5001 dport=41524 mark=0 secctx=system_u:object_r:unlabeled_t:s0 zone=2 use=2

Note the 'dst=' where it should have been
Interesting that it is always this address.

Here, it worked:
ipv4     2 tcp      6 58 CLOSE_WAIT src= dst= sport=41616 dport=5001 src= dst= sport=5001 dport=41616 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 zone=2 use=2

I cannot reproduce this with direct tc tests and neither with

I'm using:
kernel: 192f0f8e9db7efe4ac98d47f5fa4334e43c1204d + recird_id patches
iproute2: 0f48f9f46ae83c042d36c1208b0f79966f92a951 + act_ct patches
ovs: c99d14775f78cb38b2109add063f58201ba07652 + this series (including the fixup)

More information about the dev mailing list