On Thu, Mar 9, 2017 at 11:52 PM, Numan Siddique <nusid...@redhat.com> wrote: > Thanks for the review. Please see inline. > > > On Fri, Mar 10, 2017 at 1:44 AM, Russell Bryant <russ...@ovn.org> wrote: >> >> On Mon, Feb 27, 2017 at 12:59 AM, <nusid...@redhat.com> wrote: >> > From: Numan Siddique <nusid...@redhat.com> >> > >> > Presently, the icmp4 requests to the router gateway ip are sent to the >> > connectiont tracker, but the icmp4 reply packets responded by >> > 'lr_in_ip_input' stage are not sent to the connection tracker. >> > Also no zone ids are assigned for the router ports. Because of which >> > the icmp4 request packets in the connection tracker will be in the >> > UNREPLIED state. If the CMS has added ACLs to drop packets which >> > are not in ESTABLISHED state, the icmp4 replies will be dropped. >> > >> > To fix this issue, this patch adds a priority-110 flow in >> > 'ls_in_pre_acl' >> > stage which doesn't set reg0[0] = 1 for icmp4 request packets destined >> > to the router gateway ips. >> > >> > Alternate solution would be to assign zone ids for the router ports >> > and send the packets from the router ports to the connection tracker. >> > >> > The approach used in this patch seems to be simpler. >> > >> > Signed-off-by: Numan Siddique <nusid...@redhat.com> >> > --- >> > ovn/northd/ovn-northd.8.xml | 29 +++++++++++--- >> > ovn/northd/ovn-northd.c | 92 >> > +++++++++++++++++++++++++++------------------ >> > 2 files changed, 79 insertions(+), 42 deletions(-) >> >> >> Can you clarify where the packet gets dropped? It seems like we have >> flows trying to handle this already. We skip conntrack for the router >> interface ports. Roughly, I would expect: >> > > The packets are getting dropped because of the flow > > table=52, n_packets=40, n_bytes=3920, > priority=2001,ct_state=-est+trk,ip,reg15=0x3,metadata=0x3 ac > tions=drop > > This flow corresponds to logical flow - > table=4 (ls_out_acl ), priority=2001 , match=((!ct.est || (ct.est && > ct_label.blocked == 1)) && (outport == > "ce575934-f308-45b8-b9cd-457646da213d" && ip)), action=(drop;) > > > This logical flow is added by neutron OVN plugin when the port is configured > with security groups. When I clear the security groups for the port or add a > specific security group rule to allow icmp, it works fine.
The above flow could be hit at two different points (#2 and #5 below). In my local testing, it looks like it's happening in #5 so at least we aren't hitting conntrack related flows in a part of the pipeline where we don't expect it. > >> >> 1) inport == lport1, logical switch ingress pipeline. packet sent >> through conntrack. >> >> 2) outport == router interface port, logical switch egress pipeline. >> packet *skips* conntrack since it's a router interface. >> >> 3) router datapath, icmp respose generated, sent back to logical switch >> ... >> >> 4) inport == router interface, logical switch ingress pipeline, packet >> *skips* conntrack since it's a router interface >> >> 5) outport == lport1, logical switch egress pipeline, packet sent >> through conntrack, which should find an existing conntrack entry >> established in step 1. packet delivered to lport1. >> > > The connection tracking entry has this > > $ sudo conntrack -L | grep 10.0.0.1 > conntrack v1.4.3 (conntrack-tools): 54 flow entries have been shown. > icmp 1 29 src=10.0.0.6 dst=10.0.0.1 type=8 code=0 id=7486 [UNREPLIED] > src=10.0.0.1 dst=10.0.0.6 type=0 code=0 id=7486 mark=0 > secctx=system_u:object_r:unlabeled_t:s0 zone=1 use=1 > > You think this should be addressed by neutron OVN plugin ? I don't think it's a Neutron issue. I see the conntrack entry remaining in the UNREPLIED state, even in the working case where there's not an ACL dropping the reply. icmp 1 29 src=10.0.0.10 dst=10.0.0.1 type=8 code=0 id=25857 [UNREPLIED] src=10.0.0.1 dst=10.0.0.10 type=0 code=0 id=25857 mark=0 zone=8 use=1 If I ping a different address (something past the logical router), I see a proper conntrack entry that's not in the UNREPLIED state. I wonder if there's something about how we are generating the ICMP response from the logical router that's making conntrack not properly associate it with the request? -- Russell Bryant _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
