[ovs-dev] [PATCH 1/2] ovn-northd: Ability to loop-back in a router.

Mickey Spiegel emspiege at us.ibm.com
Fri Jul 8 05:36:36 UTC 2016


-----Guru Shetty <guru at ovn.org> wrote: -----

>To: Mickey Spiegel/San Jose/IBM at IBMUS
>From: Guru Shetty <guru at ovn.org>
>Date: 07/07/2016 09:34PM
>Cc: ovs dev <dev at openvswitch.org>
>Subject: Re: [ovs-dev] [PATCH 1/2] ovn-northd: Ability to loop-back
>in a router.
>
>
>
>On 7 July 2016 at 21:28, Guru Shetty <guru at ovn.org> wrote:
>
>
>On 7 July 2016 at 20:30, Mickey Spiegel <emspiege at us.ibm.com> wrote:
>>To: dev at openvswitch.org
> >From: Gurucharan Shetty
> >Sent by: "dev"
> >Date: 07/05/2016 11:15AM
> >Subject: [ovs-dev] [PATCH 1/2] ovn-northd: Ability to loop-back in a router.
> >
> >Currently, when a client looks at a load balancer VIP,
> >it notices that it is in a different subnet than itself
> >and sends the packet to its connected router port's
> >MAC address. The load balancer intercepts it.
> >
> >If the load balancer VIP translates to an endpoint IP in a
> >different subnet (than the one client has), than the
> >load balancing works fine because the router will send
> >the packet to the correct destination.
> >
> >But if one of the endpoints that VIP translated into
> >was in the same subnet as the client, the OVN router
> >fails to send the packet back via the same interface.
> 
> So the load balancer is translating the destination IP,
> but leaving the MAC address unchanged?
> Based on the MAC address, the packet is forwarded to
> the router patch port?
>Yes. This does look like a common behavior. Atleast, the default
>Kubernetes load balancers (or any iptables based load-balancers) seem
>to do that.

This does not seem clean. I still wonder whether it would make
more sense to start over on a separate logical switch for the load
balancer, leading to a different patch port into the logical router.

> --snip... 
>
>
> I am concerned about two aspects of this proposal:
> 1. It applies to all traffic to directly connected subnets, not just
>    for load balancer traffic. That is a significant change in behavior.
>Agreed. (Having said that, some Physical routers seem to do the same
>thing. i.e. have the capability to send back the traffic. I am not
>sure whether all Physical routers are capable of doing it.)

A quick search told me that one of the major router vendors allowed
that 8 or 9 years ago. Not sure if they allow it now.

Their firewalls do not allow it by default, but have a configuration knob.

>  2. It is removing the inport early on in the router ingress pipeline,
>    which scares me and seems like it will make debugging difficult.
>    You could narrow it down quite a bit by matching on inport, but
>    that still leaves the behavior that concerns me for some traffic.
>    Looking at my design for NAT in a distributed router, removing
>    the inport would break it. I suspect there might be other
>    future features that might act on inport, such as RPF.
> 
>
>This is only true when the destination IP address is in the same
>subnet as the router port. For other cases, inport is available. Do
>you also need to send back traffic? I guess what I am getting at is,
>why do you think this will hurt other features which won't loop-back?

This is not about loopback. It is about the mechanism that you chose
to achieve your goal, zeroing out the inport very early in the router
ingress pipeline. Other lookups later in the router ingress pipeline
may need to have the inport available for match conditions. For the
NAT design that I am working on, I want to match on the router
gateway address (SNAT) and inport == gateway port, together. For
RPF, it could be any router port.

>Looks like my patch does it for every router port in that router.
>That is clearly wrong and was not my intention. If I limit it to only
>the port which has that subnet, would that satisfy your concern?

No. That is what I mentioned above by "narrow it down quite a bit
by matching on inport". You would still be zeroing out the inport
in some cases, which may affect later pipeline stages that want to
match on inport.

Once you put this change in, in what cases are you still precluding
inport == outport?
Only when the dest IP matches a default, static or dynamic route
rather than a connected subnet.
Does the inport == outport check still have any significant value
once you do that?
I would argue not much. The simplest solution in that case would
be to turn off the check for router datapaths, though I would still
think it should be protected by a configuration knob of some sort.
If you turn off the check for router datapaths, the change would be
in physical.c for table 34, and would not affect the logical flows
constructed by northd.

Mickey

>(For cases like that, a workaround would be to store inport in a
>register for later use? )
> 
> 
> >     /* NAT in Gateway routers. */
> >--
> >1.9.1
> >
> >_______________________________________________
> >dev mailing list
> >dev at openvswitch.org
> >http://openvswitch.org/mailman/listinfo/dev
> >
> 
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
> 
> 
> 




More information about the dev mailing list