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

Marcelo Ricardo Leitner marcelo.leitner at gmail.com
Thu Jul 18 21:59:26 UTC 2019


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://lwn.net/Articles/791584/
> 
> 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 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=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 at 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)


More information about the dev mailing list