Hi Darrell, Yes the expected outcome is to drop new or non related connection, and allow only related or established connections.
Just for the clarity adding the details of the topology and pipeline rules. Description about the topology ========================= VM1 and VM4 VMs are on same compute node but with different SGs. For VM4, security rules configured are as below: Egress/Ingress Allow all For VM1, Egress Allow all Ingress Allow only from VMs which are in same security group. For above combination, all conntrack flows required (in tables 213, 214 on VM egress side and 243, 244) are properly programmed in the OVS. For traffic sent from VM4 to VM1 , conntrack is allowing traffic which should have been dropped as the ingress for later is to be allowed only from the VMs of the same SG. For VM1 , conntrack is directly sending traffic to "ct_state==-new+est-rel-inv+trk " flow by-passing "ct_state=+new+trk" flow in the ingress direction. Following is the pipe line rules details ============================== VM4 is on 112/15: (dpdkvhostuser: configured_rx_queues=1, configured_tx_queues=1, mtu=2140, requested_rx_queues=1, requested_tx_queues=1) VM1 is on 108/11: (dpdkvhostuser: configured_rx_queues=1, configured_tx_queues=1, mtu=2140, requested_rx_queues=1, requested_tx_queues=1) VM4 IP: 172.20.1.113 MAC: fa:16:3e:55:9e:33 VM1 IP: 172.20.1.117 MAC : fa:16:3e:f7:72:d3 I am doing Ping from VM4 (172.20.1.113 ) to VM1 (172.20.1.117). cookie=0x8000000, duration=2809.367s, table=0, n_packets=74, n_bytes=10426, priority=4,in_port=112,vlan_tci=0x0000/0x1fff actions=write_metadata:0x19f40000000000/0xffffff0000000001,goto_table:17 cookie=0x6900000, duration=2809.343s, table=17, n_packets=74, n_bytes=10426, priority=10,metadata=0x19f40000000000/0xffffff0000000000 actions=write_metadata:0x4019f40000000000/0xfffffffffffffffe,goto_table:211 cookie=0x6900000, duration=2809.313s, table=211, n_packets=54, n_bytes=8674, priority=61010,ip,metadata=0x19f40000000000/0x1fffff0000000000,dl_src=fa:16:3e:55:9e:33,nw_src=172.20.1.113 actions=goto_table:212 cookie=0x6900000, duration=15546.529s, table=212, n_packets=3669, n_bytes=361562, priority=61010,icmp actions=goto_table:213 cookie=0x6900000, duration=2809.308s, table=213, n_packets=54, n_bytes=8674, priority=61010,ip,metadata=0x19f40000000000/0x1fffff0000000000 actions=ct(table=214,zone=5021) cookie=0x6900000, duration=15546.544s, table=214, n_packets=3660, n_bytes=367508, priority=62020,ct_state=-new+est-rel-inv+trk actions=resubmit(,17) cookie=0x6900001, duration=2809.304s, table=214, n_packets=2, n_bytes=180, priority=62015,ct_state=+inv+trk,metadata=0x19f40000000000/0x1fffff0000000000 actions=drop cookie=0x6900000, duration=2809.295s, table=214, n_packets=10, n_bytes=908, priority=1000,ct_state=+new+trk,ip,metadata=0x19f40000000000/0x1fffff0000000000 actions=ct(commit,zone=5021),resubmit(,17) cookie=0x6800001, duration=2807.340s, table=17, n_packets=72, n_bytes=10246, priority=10,metadata=0x4019f40000000000/0xffffff0000000000 actions=write_metadata:0xc019f40000000000/0xfffffffffffffffe,goto_table:60 cookie=0x6800000, duration=15546.596s, table=60, n_packets=262265, n_bytes=19604926, priority=0 actions=resubmit(,17) cookie=0x8040000, duration=2807.338s, table=17, n_packets=70, n_bytes=9562, priority=10,metadata=0xc019f40000000000/0xffffff0000000000 actions=write_metadata:0xe019f4139d000000/0xfffffffffffffffe,goto_table:48 cookie=0x8500000, duration=15546.528s, table=48, n_packets=302458, n_bytes=34190652, priority=0 actions=resubmit(,49),resubmit(,50) cookie=0x805139d, duration=2808.378s, table=50, n_packets=70, n_bytes=9562, priority=20,metadata=0x19f4139d000000/0x1fffffffff000000,dl_src=fa:16:3e:55:9e:33 actions=goto_table:51 cookie=0x803139d, duration=2818.232s, table=51, n_packets=34, n_bytes=4613, priority=20,metadata=0x139d000000/0xffff000000,dl_dst=fa:16:3e:f7:72:d3 actions=load:0x1a5300->NXM_NX_REG6[],resubmit(,220) cookie=0x6900000, duration=2819.193s, table=220, n_packets=3455, n_bytes=207541, priority=6,reg6=0x1a5300 actions=load:0xe01a5300->NXM_NX_REG6[],write_metadata:0xe01a530000000000/0xfffffffffffffffe,goto_table:241 cookie=0x6900000, duration=2819.237s, table=241, n_packets=32, n_bytes=4851, priority=61010,ip,metadata=0x1a530000000000/0x1fffff0000000000,dl_dst=fa:16:3e:f7:72:d3,nw_dst=172.20.1.117 actions=goto_table:242 cookie=0x6900000, duration=15546.579s, table=242, n_packets=3738, n_bytes=368372, priority=61010,icmp actions=goto_table:243 cookie=0x6900000, duration=2819.235s, table=243, n_packets=32, n_bytes=4851, priority=61010,ip,metadata=0x1a530000000000/0x1fffff0000000000 actions=ct(table=244,zone=5021) cookie=0x6900001, duration=2819.230s, table=244, n_packets=2, n_bytes=196, priority=50,ct_state=+new+trk,metadata=0x1a530000000000/0x1fffff0000000000 actions=drop cookie=0x6900000, duration=15546.577s, table=244, n_packets=0, n_bytes=0, priority=62020,ct_state=-new-est+rel-inv+trk actions=resubmit(,220) cookie=0x6900000, duration=15546.552s, table=244, n_packets=3819, n_bytes=431050, priority=62020,ct_state=-new+est-rel-inv+trk actions=resubmit(,220) cookie=0x8000007, duration=2819.193s, table=220, n_packets=107, n_bytes=9431, priority=7,reg6=0xe01a5300 actions=output:108 Thanks Rohith From: Darrell Ball <[email protected]> Date: Thursday, 24 August 2017 at 12:20 AM To: Rohith Basavaraja <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [ovs-discuss] Conntrack issue in OVS (2.6)+DPDK Hi Rohith I might have missed the alias earlier. From the below o/p, I see the rule cookie=0x6900000, duration=15546.577s, table=244, n_packets=0, n_bytes=0, priority=62020,ct_state=-new-est+rel-inv+trk actions=resubmit(,220) not being hit. I also see the rule cookie=0x6900001, duration=2819.230s, table=244, n_packets=2, n_bytes=196, priority=50, ct_state=+new+trk,metadata=0x1a530000000000/0x1fffff0000000000 actions=drop having a drop action. What is the expectation of the test ? Is table 244 intended to drop non-related and non-established packets ? Thanks Darrell From: <[email protected]> on behalf of Rohith Basavaraja <[email protected]> Date: Wednesday, August 23, 2017 at 3:03 AM To: "[email protected]" <[email protected]> Subject: [ovs-discuss] Conntrack issue in OVS (2.6)+DPDK Hi, I see that if I have following rules, i.e not allow any new connections and allow only established and related flows, cookie=0x6900001, duration=2819.230s, table=244, n_packets=2, n_bytes=196, priority=50, ct_state=+new+trk,metadata=0x1a530000000000/0x1fffff0000000000 actions=drop cookie=0x6900000, duration=15546.577s, table=244, n_packets=0, n_bytes=0, priority=62020,ct_state=-new-est+rel-inv+trk actions=resubmit(,220) cookie=0x6900000, duration=15546.552s, table=244, n_packets=3819, n_bytes=431050, priority=62020,ct_state=-new+est-rel-inv+trk actions=resubmit(,220) We are still seeing that new connections are getting allowed, we see this behavior/issue only OVS + DPDK and not in OVS kernel mode. Wanted to check if this issue is already reported elsewhere or it’s new issue. Thanks Rohith
_______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
