On Fri, Mar 10, 2017 at 10:22 AM, 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. > > Also, this commit message is not accurate. > 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. > > > >> 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 ? > > > > Where in the above process is it coming apart? If it's broken, it >> sounds like a more general problem than ICMP. It would be any type of >> traffic to the router IP where we expect a response. >> >> -- >> Russell Bryant >> > > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
