[ovs-discuss] [OVN] egress ACLs on Port Groups seem broken
Hi all, I'm writing the code to implement the port groups in networking-ovn (the OpenStack integration project with OVN). I found out that when a boot a VM, looks like the egress traffic (from VM) is not working properly. The VM port belongs to 3 Port Groups: 1. Default drop port group with the following ACLs: _uuid : 0b092bb2-e97b-463b-a678-8a28085e3d68 action : drop direction : from-lport external_ids: {} log : false match : "inport == @neutron_pg_drop && ip" name: [] priority: 1001 severity: [] _uuid : 849ee2e0-f86e-4715-a949-cb5d93437847 action : drop direction : to-lport external_ids: {} log : false match : "outport == @neutron_pg_drop && ip" name: [] priority: 1001 severity: [] 2. Subnet port group to allow DHCP traffic on that subnet: _uuid : 8360a415-b7e1-412b-95ff-15cc95059ef0 action : allow direction : from-lport external_ids: {} log : false match : "inport == @pg_b1a572c6_2331_4cfb_a892_3d9d7b0af70c && ip4 && ip4.dst == {255.255.255.255, 10.0.0.0/26} && udp && udp.src == 68 && udp.dst == 67" name: [] priority: 1002 severity: [] 3. Security group port group which the following rules: 3.1 Allow ICMP traffic: _uuid : d12a749f-0f75-4634-aa20-6116e1d5d26d action : allow-related direction : to-lport external_ids: {"neutron:security_group_rule_id"="9675d6df-56a1-4640-9a0f-1f88e49ed2b5"} log : false match : "outport == @pg_d237185f_733f_4a09_8832_bcee773722ef && ip4 && ip4.src == 0.0.0.0/0 && icmp4" name: [] priority: 1002 severity: [] 3.2 Allow SSH traffic: _uuid : 05100729-816f-4a09-b15c-4759128019d4 action : allow-related direction : to-lport external_ids: {"neutron:security_group_rule_id"="2a48979f-8209-4fb7-b24b-fff8d82a2ae9"} log : false match : "outport == @pg_d237185f_733f_4a09_8832_bcee773722ef && ip4 && ip4.src == 0.0.0.0/0 && tcp && tcp.dst == 22" name: [] priority: 1002 severity: [] 3.3 Allow IPv4/IPv6 traffic from this same port group _uuid : b56ce66e-da6b-48be-a66e-77c8cfd6ab92 action : allow-related direction : to-lport external_ids: {"neutron:security_group_rule_id"="5b0a47ee-8114-4b13-8d5b-b16d31586b3b"} log : false match : "outport == @pg_d237185f_733f_4a09_8832_bcee773722ef && ip6 && ip6.src == $pg_d237185f_733f_4a09_8832_bcee773722ef_ip6" name: [] priority: 1002 severity: [] _uuid : 7b68f430-41b5-414d-a2ed-6c548be53dce action : allow-related direction : to-lport external_ids: {"neutron:security_group_rule_id"="299bd9ca-89fb-4767-8ae9-a738e98603fb"} log : false match : "outport == @pg_d237185f_733f_4a09_8832_bcee773722ef && ip4 && ip4.src == $pg_d237185f_733f_4a09_8832_bcee773722ef_ip4" name: [] priority: 1002 severity: [] 3.4 Allow all egress (VM point of view) IPv4 traffic _uuid : c5fbf0b7-6461-4f27-802e-b0d743be59e5 action : allow-related direction : from-lport external_ids: {"neutron:security_group_rule_id"="a4ffe40a-f773-41d6-bc04-40500d158f51"} log : false match : "inport == @pg_d237185f_733f_4a09_8832_bcee773722ef && ip4" name: [] priority: 1002 severity: [] So, I boot a VM using this port and I can verify that ICMP and SSH traffic works good while the egress traffic doesn't work. From the VM I curl to an IP living in a network namespace and this is what I see with tcpdump there: On the VM: $ ip r get 169.254.254.169 169.254.254.169 via 10.0.0.1 dev eth0 src 10.0.0.6 $ curl 169.254.169.254 On the hypervisor (haproxy listening on 169.254.169.254:80): $ sudo ip net e ovnmeta-0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf tcpdump -i any po rt 80 -vvn tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 21:59:47.106883 IP (tos 0x0, ttl 64, id 61543, offset 0, flags [DF], proto TCP (6), length 60) 10.0.0.6.34553 > 169.254.169.254.http: Flags [S], cksum 0x851c (correct), seq 2571046510, win 14020, options [mss 1402,sackOK,TS val 22740490 ecr 0,nop,wscale 2], length 0 21:59:47.106935 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 169.254.169.254.http > 10.0.0.6.34553: Flags [S.], cksum 0x5e31 (incorrect -> 0x34c0), seq 3215869181, ack 2571046511, win 28960, options [mss 1460,sackOK,TS val 2000
Re: [ovs-discuss] [OVN] egress ACLs on Port Groups seem broken
On Mon, Jun 18, 2018 at 10:43:22PM +0200, Daniel Alvarez Sanchez wrote: > I'm writing the code to implement the port groups in networking-ovn (the > OpenStack integration project with OVN). I found out that when a boot a VM, > looks like the egress traffic (from VM) is not working properly. The VM > port belongs to 3 Port Groups: There's a lot of information here but I don't see any output from ovn-trace. Have you tried that? Usually it's the first thing I reach for. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [OVN] egress ACLs on Port Groups seem broken
On Mon, Jun 18, 2018 at 1:43 PM, Daniel Alvarez Sanchez wrote: > > Hi all, > > I'm writing the code to implement the port groups in networking-ovn (the OpenStack integration project with OVN). I found out that when a boot a VM, looks like the egress traffic (from VM) is not working properly. The VM port belongs to 3 Port Groups: > > 1. Default drop port group with the following ACLs: > > _uuid : 0b092bb2-e97b-463b-a678-8a28085e3d68 > action : drop > direction : from-lport > external_ids: {} > log : false > match : "inport == @neutron_pg_drop && ip" > name: [] > priority: 1001 > severity: [] > > _uuid : 849ee2e0-f86e-4715-a949-cb5d93437847 > action : drop > direction : to-lport > external_ids: {} > log : false > match : "outport == @neutron_pg_drop && ip" > name: [] > priority: 1001 > severity: [] > > > 2. Subnet port group to allow DHCP traffic on that subnet: > > _uuid : 8360a415-b7e1-412b-95ff-15cc95059ef0 > action : allow > direction : from-lport > external_ids: {} > log : false > match : "inport == @pg_b1a572c6_2331_4cfb_a892_3d9d7b0af70c && ip4 && ip4.dst == {255.255.255.255, 10.0.0.0/26} && udp && udp.src == 68 && udp.dst == 67" > name: [] > priority: 1002 > severity: [] > > > 3. Security group port group which the following rules: > > 3.1 Allow ICMP traffic: > > _uuid : d12a749f-0f75-4634-aa20-6116e1d5d26d > action : allow-related > direction : to-lport > external_ids: {"neutron:security_group_rule_id"="9675d6df-56a1-4640-9a0f-1f88e49ed2b5"} > log : false > match : "outport == @pg_d237185f_733f_4a09_8832_bcee773722ef && ip4 && ip4.src == 0.0.0.0/0 && icmp4" > name: [] > priority: 1002 > severity: [] > > 3.2 Allow SSH traffic: > > _uuid : 05100729-816f-4a09-b15c-4759128019d4 > action : allow-related > direction : to-lport > external_ids: {"neutron:security_group_rule_id"="2a48979f-8209-4fb7-b24b-fff8d82a2ae9"} > log : false > match : "outport == @pg_d237185f_733f_4a09_8832_bcee773722ef && ip4 && ip4.src == 0.0.0.0/0 && tcp && tcp.dst == 22" > name: [] > priority: 1002 > severity: [] > > > 3.3 Allow IPv4/IPv6 traffic from this same port group > > > _uuid : b56ce66e-da6b-48be-a66e-77c8cfd6ab92 > action : allow-related > direction : to-lport > external_ids: {"neutron:security_group_rule_id"="5b0a47ee-8114-4b13-8d5b-b16d31586b3b"} > log : false > match : "outport == @pg_d237185f_733f_4a09_8832_bcee773722ef && ip6 && ip6.src == $pg_d237185f_733f_4a09_8832_bcee773722ef_ip6" > name: [] > priority: 1002 > severity: [] > > > _uuid : 7b68f430-41b5-414d-a2ed-6c548be53dce > action : allow-related > direction : to-lport > external_ids: {"neutron:security_group_rule_id"="299bd9ca-89fb-4767-8ae9-a738e98603fb"} > log : false > match : "outport == @pg_d237185f_733f_4a09_8832_bcee773722ef && ip4 && ip4.src == $pg_d237185f_733f_4a09_8832_bcee773722ef_ip4" > name: [] > priority: 1002 > severity: [] > > > 3.4 Allow all egress (VM point of view) IPv4 traffic > > _uuid : c5fbf0b7-6461-4f27-802e-b0d743be59e5 > action : allow-related > direction : from-lport > external_ids: {"neutron:security_group_rule_id"="a4ffe40a-f773-41d6-bc04-40500d158f51"} > log : false > match : "inport == @pg_d237185f_733f_4a09_8832_bcee773722ef && ip4" > name: [] > priority: 1002 > severity: [] > > > > So, I boot a VM using this port and I can verify that ICMP and SSH traffic works good while the egress traffic doesn't work. From the VM I curl to an IP living in a network namespace and this is what I see with tcpdump there: > > On the VM: > $ ip r get 169.254.254.169 > 169.254.254.169 via 10.0.0.1 dev eth0 src 10.0.0.6 > $ curl 169.254.169.254 > > On the hypervisor (haproxy listening on 169.254.169.254:80): > > $ sudo ip net e ovnmeta-0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf tcpdump -i any po > rt 80 -vvn > tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes > 21:59:47.106883 IP (tos 0x0, ttl 64, id 61543, offset 0, flags [DF], proto TCP (6), length 60) > 10.0.0.6.34553 > 169.254.169.254.http: Flags [S], cksum 0x851c (correct), seq 2571046510, win 14020, options [mss 1402,sackOK,TS val 22740490 ecr 0,nop,wsc
Re: [ovs-discuss] [OVN] egress ACLs on Port Groups seem broken
Hi folks, Sorry for not being clear enough. In the tcpdump we can see the SYN packets being sent by port1 but retransmitted as it looks like the response to that SYN never reaches its destination. This is confirmed through the DP flows: $ sudo ovs-dpctl dump-flows recirc_id(0),in_port(3),eth(src=fa:16:3e:78:a2:cf,dst=fa:16:3e:bf:6f:51),eth_type(0x0800),ipv4(src=10.0.0.6,dst= 168.0.0.0/252.0.0.0,proto=6,frag=no), packets:4, bytes:296, used:0.514s, flags:S, actions:4 recirc_id(0),in_port(4),eth(src=fa:16:3e:bf:6f:51,dst=fa:16:3e:78:a2:cf),eth_type(0x0800),ipv4(src= 128.0.0.0/128.0.0.0,dst=10.0.0.0/255.255.255.192,proto=6,frag=no),tcp(dst=32768/0x8000), packets:7, bytes:518, used:0.514s, flags:S., actions:drop $ sudo ovs-appctl ofproto/trace br-int in_port=20,tcp,dl_src=fa:16:3e:78:a2:cf,dl_dst=fa:16:3e:bf:6f:51,nw_src=10.0.0.6,nw_dst=169.254.169.254,tcp_dst=80 | ovn-detrace Flow: tcp,in_port=20,vlan_tci=0x,dl_src=fa:16:3e:78:a2:cf,dl_dst=fa:16:3e:bf:6f:51,nw_src=10.0.0.6,nw_dst=169.254.169.254,nw_tos=0,nw_ecn=0,nw_ttl=0,tp_sr c=0,tp_dst=80,tcp_flags=0 bridge("br-int") 0. in_port=20, priority 100 set_field:0x8->reg13 set_field:0x5->reg11 set_field:0x1->reg12 set_field:0x1->metadata set_field:0x4->reg14 resubmit(,8) 8. reg14=0x4,metadata=0x1,dl_src=fa:16:3e:78:a2:cf, priority 50, cookie 0xe299b701 resubmit(,9) 9. ip,reg14=0x4,metadata=0x1,dl_src=fa:16:3e:78:a2:cf,nw_src=10.0.0.6, priority 90, cookie 0x6581e351 resubmit(,10) * Logical datapath: "neutron-9d5615df-a7ba-4649-82f9-961a76fe6f64" (0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf) [ingress] * Logical flow: table=1 (ls_in_port_sec_ip), priority=90, match=(inport == "8ea9d963-7e55-49a6-8be7-cc294278180a" && eth.src == fa:16:3e:78:a2:cf && i p4.src == {10.0.0.6}), actions=(next;) 10. metadata=0x1, priority 0, cookie 0x1c3ddeef resubmit(,11) * Logical datapath: "neutron-9d5615df-a7ba-4649-82f9-961a76fe6f64" (0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf) [ingress] * Logical flow: table=2 (ls_in_port_sec_nd), priority=0, match=(1), actions=(next;) ... 47. metadata=0x1, priority 0, cookie 0xf35c5784 resubmit(,48) * Logical datapath: "neutron-9d5615df-a7ba-4649-82f9-961a76fe6f64" (0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf) [egress] * Logical flow: table=7 (ls_out_stateful), priority=0, match=(1), actions=(next;) 48. metadata=0x1, priority 0, cookie 0x9546c56e resubmit(,49) * Logical datapath: "neutron-9d5615df-a7ba-4649-82f9-961a76fe6f64" (0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf) [egress] * Logical flow: table=8 (ls_out_port_sec_ip), priority=0, match=(1), actions=(next;) 49. reg15=0x1,metadata=0x1, priority 50, cookie 0x58af7841 resubmit(,64) * Logical datapath: "neutron-9d5615df-a7ba-4649-82f9-961a76fe6f64" (0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf) [egress] * Logical flow: table=9 (ls_out_port_sec_l2), priority=50, match=(outport == "74db766c-2600-40f1-9ffa-255dc147d8a5), actions=(output;) 64. priority 0 resubmit(,65) 65. reg15=0x1,metadata=0x1, priority 100 output:21 Final flow: tcp,reg11=0x5,reg12=0x1,reg13=0x9,reg14=0x4,reg15=0x1,metadata=0x1,in_port=20,vlan_tci=0x,dl_src=fa:16:3e:78:a2:cf,dl_dst=fa:16:3e:bf:6f:51,nw_src=10.0.0.6,nw_dst=169.254.169.254,nw_tos=0,nw_ecn=0,nw_ttl=0,tp_src=0,tp_dst=80,tcp_flags=0 Megaflow: recirc_id=0,eth,tcp,in_port=20,vlan_tci=0x/0x1000,dl_src=fa:16:3e:78:a2:cf,dl_dst=fa:16:3e:bf:6f:51,nw_src=10.0.0.6,nw_dst= 168.0.0.0/6,nw_frag=no Datapath actions: 4 At this point I would've expected the connection to be in conntrack (but if i'm not mistaken this is not supported in ovn-trace :?) so the return packet would be dropped: $ sudo ovs-appctl ofproto/trace br-int in_port=21,tcp,dl_dst=fa:16:3e:78:a2:cf,dl_src=fa:16:3e:bf:6f:51,nw_dst=10.0.0.6,nw_src=169.254.169.254,tcp_dst=80 | ovn-detrace Flow: tcp,in_port=21,vlan_tci=0x,dl_src=fa:16:3e:bf:6f:51,dl_dst=fa:16:3e:78:a2:cf,nw_src=169.254.169.254,nw_dst=10.0.0.6,nw_tos=0,nw_ecn=0,nw_ttl=0,tp_src=0,tp_dst=80,tcp_flags=0 bridge("br-int") 0. in_port=21, priority 100 set_field:0x9->reg13 set_field:0x5->reg11 set_field:0x1->reg12 set_field:0x1->metadata set_field:0x1->reg14 resubmit(,8) 8. reg14=0x1,metadata=0x1, priority 50, cookie 0x4017bca3 resubmit(,9) 9. metadata=0x1, priority 0, cookie 0x5f2a07c6 resubmit(,10) * Logical datapath: "neutron-9d5615df-a7ba-4649-82f9-961a76fe6f64" (0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf) [ingress] * Logical flow: table=1 (ls_in_port_sec_ip), priority=0, match=(1), actions=(next;) 10. metadata=0x1, priority 0, cookie 0x1c3ddeef resubmit(,11) * Logical datapath: "neutron-9d5615df-a7ba-4649-82f9-961a76fe6f64" (0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf) [ingress] * Logical flow: table=2 (ls_in_port_sec_nd), priority=0, match=(1), actions=(next;) ... 44. ip,reg15=0x4,metadata=0x1, priority 2001, cookie 0x3a87f6e9 drop * Logical datapath: "neutron-9d5615df-a7ba-4649-82f9-961a76fe6f64" (0cf12eb0-fdb3-4087-98b0-9c5
Re: [ovs-discuss] [OVN] egress ACLs on Port Groups seem broken
Sorry, the problem seems to be that this ACL is not added in the Port Groups case for some reason (I checked wrong lflows log I had): _uuid : 5a1bce6c-e4ed-4a1f-8150-cb855bbac037 actions : "reg0[0] = 1; next;" external_ids: {source="ovn-northd.c:2931", stage-name=ls_in_pre_acl} logical_datapath: 0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf match : ip pipeline: ingress priority: 100 Apparently, this code is not getting triggered for the Port Group case: https://github.com/openvswitch/ovs/blob/master/ovn/northd/ovn-northd.c#L2930 On Tue, Jun 19, 2018 at 10:09 PM, Daniel Alvarez Sanchez < dalva...@redhat.com> wrote: > Hi folks, > > Sorry for not being clear enough. In the tcpdump we can see the SYN > packets being sent by port1 but retransmitted as it looks like the response > to that SYN never reaches its destination. This is confirmed through the DP > flows: > > $ sudo ovs-dpctl dump-flows > > recirc_id(0),in_port(3),eth(src=fa:16:3e:78:a2:cf,dst=fa: > 16:3e:bf:6f:51),eth_type(0x0800),ipv4(src=10.0.0.6,dst= > 168.0.0.0/252.0.0.0,proto=6,frag=no), packets:4, bytes:296, used:0.514s, > flags:S, actions:4 > > recirc_id(0),in_port(4),eth(src=fa:16:3e:bf:6f:51,dst=fa: > 16:3e:78:a2:cf),eth_type(0x0800),ipv4(src=128.0.0.0/ > 128.0.0.0,dst=10.0.0.0/255.255.255.192,proto=6,frag=no),tcp(dst=32768/0x8000), > packets:7, bytes:518, used:0.514s, flags:S., actions:drop > > > $ sudo ovs-appctl ofproto/trace br-int in_port=20,tcp,dl_src=fa:16: > 3e:78:a2:cf,dl_dst=fa:16:3e:bf:6f:51,nw_src=10.0.0.6,nw_dst=169.254.169.254,tcp_dst=80 > | ovn-detrace > > Flow: tcp,in_port=20,vlan_tci=0x,dl_src=fa:16:3e:78:a2: > cf,dl_dst=fa:16:3e:bf:6f:51,nw_src=10.0.0.6,nw_dst=169. > 254.169.254,nw_tos=0,nw_ecn=0,nw_ttl=0,tp_sr > c=0,tp_dst=80,tcp_flags=0 > > bridge("br-int") > > 0. in_port=20, priority 100 > set_field:0x8->reg13 > set_field:0x5->reg11 > set_field:0x1->reg12 > set_field:0x1->metadata > set_field:0x4->reg14 > resubmit(,8) > 8. reg14=0x4,metadata=0x1,dl_src=fa:16:3e:78:a2:cf, priority 50, cookie > 0xe299b701 > resubmit(,9) > 9. ip,reg14=0x4,metadata=0x1,dl_src=fa:16:3e:78:a2:cf,nw_src=10.0.0.6, > priority 90, cookie 0x6581e351 > resubmit(,10) > * Logical datapath: "neutron-9d5615df-a7ba-4649-82f9-961a76fe6f64" > (0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf) [ingress] > * Logical flow: table=1 (ls_in_port_sec_ip), priority=90, > match=(inport == "8ea9d963-7e55-49a6-8be7-cc294278180a" && eth.src == > fa:16:3e:78:a2:cf && i > p4.src == {10.0.0.6}), actions=(next;) > 10. metadata=0x1, priority 0, cookie 0x1c3ddeef > resubmit(,11) > * Logical datapath: "neutron-9d5615df-a7ba-4649-82f9-961a76fe6f64" > (0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf) [ingress] > * Logical flow: table=2 (ls_in_port_sec_nd), priority=0, > match=(1), actions=(next;) > > ... > > 47. metadata=0x1, priority 0, cookie 0xf35c5784 > resubmit(,48) > * Logical datapath: "neutron-9d5615df-a7ba-4649-82f9-961a76fe6f64" > (0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf) [egress] > * Logical flow: table=7 (ls_out_stateful), priority=0, match=(1), > actions=(next;) > 48. metadata=0x1, priority 0, cookie 0x9546c56e > resubmit(,49) > * Logical datapath: "neutron-9d5615df-a7ba-4649-82f9-961a76fe6f64" > (0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf) [egress] > * Logical flow: table=8 (ls_out_port_sec_ip), priority=0, > match=(1), actions=(next;) > 49. reg15=0x1,metadata=0x1, priority 50, cookie 0x58af7841 > resubmit(,64) > * Logical datapath: "neutron-9d5615df-a7ba-4649-82f9-961a76fe6f64" > (0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf) [egress] > * Logical flow: table=9 (ls_out_port_sec_l2), priority=50, > match=(outport == "74db766c-2600-40f1-9ffa-255dc147d8a5), > actions=(output;) > 64. priority 0 > resubmit(,65) > 65. reg15=0x1,metadata=0x1, priority 100 > output:21 > > Final flow: tcp,reg11=0x5,reg12=0x1,reg13=0x9,reg14=0x4,reg15=0x1, > metadata=0x1,in_port=20,vlan_tci=0x,dl_src=fa:16:3e:78: > a2:cf,dl_dst=fa:16:3e:bf:6f:51,nw_src=10.0.0.6,nw_dst=169. > 254.169.254,nw_tos=0,nw_ecn=0,nw_ttl=0,tp_src=0,tp_dst=80,tcp_flags=0 > Megaflow: recirc_id=0,eth,tcp,in_port=20,vlan_tci=0x/0x1000,dl_ > src=fa:16:3e:78:a2:cf,dl_dst=fa:16:3e:bf:6f:51,nw_src=10.0.0.6,nw_dst= > 168.0.0.0/6,nw_frag=no > Datapath actions: 4 > > > > At this point I would've expected the connection to be in conntrack (but > if i'm not mistaken this is not supported in ovn-trace :?) so the return > packet would be dropped: > > $ sudo ovs-appctl ofproto/trace br-int in_port=21,tcp,dl_dst=fa:16: > 3e:78:a2:cf,dl_src=fa:16:3e:bf:6f:51,nw_dst=10.0.0.6,nw_src=169.254.169.254,tcp_dst=80 > | ovn-detrace > Flow: tcp,in_port=21,vlan_tci=0x,dl_src=fa:16:3e:bf:6f: > 51,dl_dst=fa:16:3e:78:a2:cf,nw_src=169.254.169.254,nw_dst= > 10.0.0.6,nw_tos=0,nw_ecn=0,nw_ttl=0,tp_src=0,tp_dst=80,tcp_flags=0 > > bridge("br-int") > > 0. in_port=21, priority 100 > set_field:0x
Re: [ovs-discuss] [OVN] egress ACLs on Port Groups seem broken
On Tue, Jun 19, 2018 at 10:37 PM, Daniel Alvarez Sanchez < dalva...@redhat.com> wrote: > Sorry, the problem seems to be that this ACL is not added in the Port > Groups case for some reason (I checked wrong lflows log I had): > s/ACL/Logical Flow > > _uuid : 5a1bce6c-e4ed-4a1f-8150-cb855bbac037 > actions : "reg0[0] = 1; next;" > external_ids: {source="ovn-northd.c:2931", > stage-name=ls_in_pre_acl} > logical_datapath: 0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf > match : ip > pipeline: ingress > priority: 100 > > > Apparently, this code is not getting triggered for the Port Group case: > https://github.com/openvswitch/ovs/blob/master/ovn/northd/ > ovn-northd.c#L2930 > > > > The problem is that build_pre_acls() [0] function checks if the Logical Switch has stateful ACLs but since we're now applying ACLs on Port Groups, it'll always return false and it won't apply the pre ACLs for conntrack. [0] https://github.com/openvswitch/ovs/blob/master/ovn/northd/ovn-northd.c#L2852 > > On Tue, Jun 19, 2018 at 10:09 PM, Daniel Alvarez Sanchez < > dalva...@redhat.com> wrote: > >> Hi folks, >> >> Sorry for not being clear enough. In the tcpdump we can see the SYN >> packets being sent by port1 but retransmitted as it looks like the response >> to that SYN never reaches its destination. This is confirmed through the DP >> flows: >> >> $ sudo ovs-dpctl dump-flows >> >> recirc_id(0),in_port(3),eth(src=fa:16:3e:78:a2:cf,dst=fa:16: >> 3e:bf:6f:51),eth_type(0x0800),ipv4(src=10.0.0.6,dst=168.0.0. >> 0/252.0.0.0,proto=6,frag=no), packets:4, bytes:296, used:0.514s, >> flags:S, actions:4 >> >> recirc_id(0),in_port(4),eth(src=fa:16:3e:bf:6f:51,dst=fa:16: >> 3e:78:a2:cf),eth_type(0x0800),ipv4(src=128.0.0.0/128.0.0.0,d >> st=10.0.0.0/255.255.255.192,proto=6,frag=no),tcp(dst=32768/0x8000), >> packets:7, bytes:518, used:0.514s, flags:S., actions:drop >> >> >> $ sudo ovs-appctl ofproto/trace br-int in_port=20,tcp,dl_src=fa:16:3e >> :78:a2:cf,dl_dst=fa:16:3e:bf:6f:51,nw_src=10.0.0.6,nw_dst=169.254.169.254,tcp_dst=80 >> | ovn-detrace >> >> Flow: tcp,in_port=20,vlan_tci=0x,dl_src=fa:16:3e:78:a2:cf,dl_d >> st=fa:16:3e:bf:6f:51,nw_src=10.0.0.6,nw_dst=169.254.169.254, >> nw_tos=0,nw_ecn=0,nw_ttl=0,tp_sr >> c=0,tp_dst=80,tcp_flags=0 >> >> bridge("br-int") >> >> 0. in_port=20, priority 100 >> set_field:0x8->reg13 >> set_field:0x5->reg11 >> set_field:0x1->reg12 >> set_field:0x1->metadata >> set_field:0x4->reg14 >> resubmit(,8) >> 8. reg14=0x4,metadata=0x1,dl_src=fa:16:3e:78:a2:cf, priority 50, cookie >> 0xe299b701 >> resubmit(,9) >> 9. ip,reg14=0x4,metadata=0x1,dl_src=fa:16:3e:78:a2:cf,nw_src=10.0.0.6, >> priority 90, cookie 0x6581e351 >> resubmit(,10) >> * Logical datapath: "neutron-9d5615df-a7ba-4649-82f9-961a76fe6f64" >> (0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf) [ingress] >> * Logical flow: table=1 (ls_in_port_sec_ip), priority=90, >> match=(inport == "8ea9d963-7e55-49a6-8be7-cc294278180a" && eth.src == >> fa:16:3e:78:a2:cf && i >> p4.src == {10.0.0.6}), actions=(next;) >> 10. metadata=0x1, priority 0, cookie 0x1c3ddeef >> resubmit(,11) >> * Logical datapath: "neutron-9d5615df-a7ba-4649-82f9-961a76fe6f64" >> (0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf) [ingress] >> * Logical flow: table=2 (ls_in_port_sec_nd), priority=0, >> match=(1), actions=(next;) >> >> ... >> >> 47. metadata=0x1, priority 0, cookie 0xf35c5784 >> resubmit(,48) >> * Logical datapath: "neutron-9d5615df-a7ba-4649-82f9-961a76fe6f64" >> (0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf) [egress] >> * Logical flow: table=7 (ls_out_stateful), priority=0, match=(1), >> actions=(next;) >> 48. metadata=0x1, priority 0, cookie 0x9546c56e >> resubmit(,49) >> * Logical datapath: "neutron-9d5615df-a7ba-4649-82f9-961a76fe6f64" >> (0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf) [egress] >> * Logical flow: table=8 (ls_out_port_sec_ip), priority=0, >> match=(1), actions=(next;) >> 49. reg15=0x1,metadata=0x1, priority 50, cookie 0x58af7841 >> resubmit(,64) >> * Logical datapath: "neutron-9d5615df-a7ba-4649-82f9-961a76fe6f64" >> (0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf) [egress] >> * Logical flow: table=9 (ls_out_port_sec_l2), priority=50, >> match=(outport == "74db766c-2600-40f1-9ffa-255dc147d8a5), >> actions=(output;) >> 64. priority 0 >> resubmit(,65) >> 65. reg15=0x1,metadata=0x1, priority 100 >> output:21 >> >> Final flow: tcp,reg11=0x5,reg12=0x1,reg13=0x9,reg14=0x4,reg15=0x1,metada >> ta=0x1,in_port=20,vlan_tci=0x,dl_src=fa:16:3e:78:a2:cf, >> dl_dst=fa:16:3e:bf:6f:51,nw_src=10.0.0.6,nw_dst=169.254. >> 169.254,nw_tos=0,nw_ecn=0,nw_ttl=0,tp_src=0,tp_dst=80,tcp_flags=0 >> Megaflow: recirc_id=0,eth,tcp,in_port=20,vlan_tci=0x/0x1000,dl_src >> =fa:16:3e:78:a2:cf,dl_dst=fa:16:3e:bf:6f:51,nw_src=10.0.0.6,nw_dst= >> 168.0.0.0/6,nw_frag=no >> Datapath actions: 4 >> >> >> >> At this point I would've expected the connection to be in conntrack (but >> if
Re: [ovs-discuss] [OVN] egress ACLs on Port Groups seem broken
On Tue, Jun 19, 2018 at 2:53 PM, Daniel Alvarez Sanchez wrote: > > > > On Tue, Jun 19, 2018 at 10:37 PM, Daniel Alvarez Sanchez < dalva...@redhat.com> wrote: >> >> Sorry, the problem seems to be that this ACL is not added in the Port Groups case for some reason (I checked wrong lflows log I had): > > s/ACL/Logical Flow >> >> >> _uuid : 5a1bce6c-e4ed-4a1f-8150-cb855bbac037 >> actions : "reg0[0] = 1; next;" >> external_ids: {source="ovn-northd.c:2931", stage-name=ls_in_pre_acl} >> logical_datapath: 0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf >> match : ip >> pipeline: ingress >> priority: 100 >> >> >> Apparently, this code is not getting triggered for the Port Group case: >> https://github.com/openvswitch/ovs/blob/master/ovn/northd/ovn-northd.c#L2930 >> >> >> > The problem is that build_pre_acls() [0] function checks if the Logical Switch has stateful > ACLs but since we're now applying ACLs on Port Groups, it'll always return false > and it won't apply the pre ACLs for conntrack. > > [0] https://github.com/openvswitch/ovs/blob/master/ovn/northd/ovn-northd.c#L2852 Yes, thanks Daniel for finding the problem! I am checking why the test case didn't find out. I will work on the fix asap. Thanks, Han ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [OVN] egress ACLs on Port Groups seem broken
Hi Han, I'm sending the patch now which fixes it but feel free to modify it. Thanks! Daniel On Wed, Jun 20, 2018 at 12:06 AM, Han Zhou wrote: > > > On Tue, Jun 19, 2018 at 2:53 PM, Daniel Alvarez Sanchez < > dalva...@redhat.com> wrote: > > > > > > > > On Tue, Jun 19, 2018 at 10:37 PM, Daniel Alvarez Sanchez < > dalva...@redhat.com> wrote: > >> > >> Sorry, the problem seems to be that this ACL is not added in the Port > Groups case for some reason (I checked wrong lflows log I had): > > > > s/ACL/Logical Flow > >> > >> > >> _uuid : 5a1bce6c-e4ed-4a1f-8150-cb855bbac037 > >> actions : "reg0[0] = 1; next;" > >> external_ids: {source="ovn-northd.c:2931", > stage-name=ls_in_pre_acl} > >> logical_datapath: 0cf12eb0-fdb3-4087-98b0-9c52cafd0bdf > >> match : ip > >> pipeline: ingress > >> priority: 100 > >> > >> > >> Apparently, this code is not getting triggered for the Port Group case: > >> https://github.com/openvswitch/ovs/blob/master/ > ovn/northd/ovn-northd.c#L2930 > >> > >> > >> > > The problem is that build_pre_acls() [0] function checks if the Logical > Switch has stateful > > ACLs but since we're now applying ACLs on Port Groups, it'll always > return false > > and it won't apply the pre ACLs for conntrack. > > > > [0] https://github.com/openvswitch/ovs/blob/master/ > ovn/northd/ovn-northd.c#L2852 > > Yes, thanks Daniel for finding the problem! I am checking why the test > case didn't find out. > I will work on the fix asap. > > Thanks, > Han > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss