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. > 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
