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

[Mickey Spiegel]

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

>This commit changes that behavior and lets an OVN router
>loop-back the packet via the same interface.
>
>Signed-off-by: Gurucharan Shetty <guru at ovn.org>
>---
> ovn/northd/ovn-northd.8.xml | 10 ++++++++++
> ovn/northd/ovn-northd.c     | 10 ++++++++++
> 2 files changed, 20 insertions(+)
>
>diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
>index 6bc83ea..08e9d4e 100644
>--- a/ovn/northd/ovn-northd.8.xml
>+++ b/ovn/northd/ovn-northd.8.xml
>@@ -743,6 +743,16 @@ output;
>         port's own IP address is used to SNAT packets passing through that
>         router.
>       </li>
>+
>+      <li>
>+        Allow router to send back the packet to the same router port from
>+        which it was received (for cases where the destination IP address
>+        is in the same subnet as the router port).  For router ports with an
>+        IP address of <var>A</var> and mask of <var>M</var>, a priority-20 flow
>+        is added with a match for <code>ip4.dst ==
>+        <var>A</var>/<var>M </var></code> and an action of
>+        <code>inport = ""</code>.
>+      </li>
>     </ul>
> 
>     <p>
>diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
>index f4b4435..158f10d 100644
>--- a/ovn/northd/ovn-northd.c
>+++ b/ovn/northd/ovn-northd.c
>@@ -2367,6 +2367,16 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap *ports,
>                           "drop;");
>             free(match);
>         }
>+
>+        /* When destination IP address is in the same subnet as the
>+         * router port, the packet may need to be eventually sent
>+         * back the same port.  For cases like that, allow sending
>+         * out the inport. */
>+        match = xasprintf("ip4.dst == "IP_FMT"/"IP_FMT,
>+                          IP_ARGS(op->network), IP_ARGS(op->mask));
>+        ovn_lflow_add(lflows, op->od, S_ROUTER_IN_IP_INPUT, 20,
>+                      match, "inport = \"\"; next;");
>+        free(match);
>     }

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

I am not sure what is the best alternative to address the problem.
This seems related to the basic load balancer design, the questions
that I asked at the beginning.

Brainstorming about workarounds, I wonder if it would be better to
have the load balancer traffic enter the router on a different port,
but that would require changing switch datapaths coming out of the
load balancer.

Wondering whether we should relax the restriction on
inport == outport for router datapaths, relying on TTL to mitigate
loops?
Perhaps controlled by a configuration knob?

Mickey

>     /* NAT in Gateway routers. */
>-- 
>1.9.1
>
>_______________________________________________
>dev mailing list
>dev at openvswitch.org
>http://openvswitch.org/mailman/listinfo/dev
>