On Fri, Jul 09, 2021 at 01:37:12PM +0800, we...@ucloud.cn wrote: > From: wenxu <we...@ucloud.cn> > > A case for client A 10.0.0.2 snat to 1.1.1.2 with following flows. > > rule1: ovs-ofctl add-flow manbr "table=0,ct_state=-trk,ip,in_port=dpdk2, > actions=ct(table=1, nat)" > rule2: ovs-ofctl add-flow manbr > "table=0,table=1,ct_state=+trk+new,ip,in_port=dpdk2, actions=ct(commit, > nat(src=1.1.1.2)),dpdk3" > > When client A tcp connect to a non-exist server 1.1.1.3 > > The first syn packet will create the following conntrack 1 > But the second syn packet will wrongly create the conntrack 2 > > tcp,orig=(src=10.0.0.2,dst=1.1.1.3,sport=15690,dport=5001),reply=(src=1.1.1.3,dst=1.1.1.2,sport=5001,dport=15690),protoinfo=(state=SYN_SENT) > #conntrack 1 > tcp,orig=(src=1.1.1.2,dst=1.1.1.3,sport=15690,dport=5001),reply=(src=1.1.1.3,dst=1.1.1.2,sport=5001,dport=1024),protoinfo=(state=SYN_SENT) > #conntrack 2 > > The second syn packet gothrough rule1 and find the conntrack1 and > do nat. Then gothrough the rule2 will not find the only conntrack > for packet nated in the rule1 > The check_orig_tuple is used to fix for this situation(packet > nated in the first rule). But it should't check the nat_action_info > in the rule2. It should only check the CS_SRC_NAT and CS_DST_NAT. > > Signed-off-by: wenxu <we...@ucloud.cn>
Hi Wenxu, This patch appears to have gone stale in patchwork, for one reason or another. If it is still relevant then I think it needs to be revisited, by being reposted after appropriate preparation. As such I'm marking this patch as "Deferred" in patchwork. No action is required unless there is a desire to revisit this patch. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
