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:

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.

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

Reply via email to