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 ? Thanks, Paul. ________________________________ From: Marcelo Ricardo Leitner <[email protected]> Sent: Friday, July 19, 2019 12:59:26 AM To: Paul Blakey Cc: [email protected]; 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&data=02%7C01%7Cpaulb%40mellanox.com%7C8dee9790121f41af67d408d70bcb35e2%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636990839726360059&sdata=1EU4nuslHxzKahEkN%2BvkvhEc3ZvZtoWhfwZg6pKO%2BDA%3D&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=5.5.5.7),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@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=192.168.0.30)),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@localhost ~]# cat /proc/net/nf_conntrack ipv4 2 tcp 6 26 SYN_SENT src=192.168.0.2 dst=192.168.0.1 sport=41524 dport=5001 [UNREPLIED] src=192.168.0.1 dst=233.185.30.138 sport=5001 dport=41524 mark=0 secctx=system_u:object_r:unlabeled_t:s0 zone=2 use=2 Note the 'dst=233.185.30.138' where it should have been 192.168.0.30. Interesting that it is always this address. Here, it worked: ipv4 2 tcp 6 58 CLOSE_WAIT src=192.168.0.2 dst=192.168.0.1 sport=41616 dport=5001 src=192.168.0.1 dst=192.168.0.30 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 hw_offload=false. I'm using: kernel: 192f0f8e9db7efe4ac98d47f5fa4334e43c1204d + recird_id patches iproute2: 0f48f9f46ae83c042d36c1208b0f79966f92a951 + act_ct patches ovs: c99d14775f78cb38b2109add063f58201ba07652 + this series (including the fixup) _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
