Re: [ovs-dev] [PATCH] ovn: Support ARP proxy in logical switches.

[Han Zhou]

On Tue, Jan 31, 2017 at 2:49 PM, Ben Pfaff  wrote:
>
> On Thu, Jan 05, 2017 at 12:33:51AM -0800, Han Zhou wrote:
> > On Wed, Jan 4, 2017 at 3:29 PM, Ben Pfaff  wrote:
> > > However, I'm concerned about the general utility here.  I usually
think
> > > of proxy ARP as being used for the kinds of applications you see in
the
> > > wikipedia on proxy ARP: https://en.wikipedia.org/wiki/Proxy_ARP.  This
> > > seems to aimed at a different application that is more like a weak
form
> > > of service function chaining than for the traditional applications of
> > > proxy ARP.
> > >
> > > Is this an appropriate application for proxy ARP?  Is it a common
enough
> > > use case to support in OVN?  Should it instead be handled through a
more
> > > general service function chaining interface?
> > >
> >
> > I have similar concerns about how useful it is. I agree it is kind of
> > lightweight SFC, but in my opinion it is not contradict with the fact
that
> > it is also Proxy ARP. At least the firewall example (the 3rd use case)
> > described in https://en.wikipedia.org/wiki/Proxy_ARP seems to be very
> > close. SFC may be a more general approach to redirect packets to a
> > firewall, but it is heavier, and may be difficult in a non-overlay
> > environment, while Proxy ARP is sufficient and simple for such specific
use
> > cases when the nodes are L2 adjacent. So I think it may be good to have
> > such feature in OVN, if the change is not intrusive.
>
> Do the general SFC patches that John McDowall is currently working on
> serve this use case too?

The scenario looks match, but with the SFC approach, if I understanding
correctly, it requires the VNF to be able to handle packets that is not
with dst mac equal to the mac of the VNF port. While with ARP proxy, MAC is
replaced with the MAC of the VNF (in my case it is just the MAC of the veth
interface in the host namespace where kubeproxy is running, which is not a
real so-called VNF), and no change is required in the VNF host/vm/container.

Thanks,
Han
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovn: Support ARP proxy in logical switches.

[Ben Pfaff]

On Thu, Jan 05, 2017 at 12:33:51AM -0800, Han Zhou wrote:
> On Wed, Jan 4, 2017 at 3:29 PM, Ben Pfaff  wrote:
> > However, I'm concerned about the general utility here.  I usually think
> > of proxy ARP as being used for the kinds of applications you see in the
> > wikipedia on proxy ARP: https://en.wikipedia.org/wiki/Proxy_ARP.  This
> > seems to aimed at a different application that is more like a weak form
> > of service function chaining than for the traditional applications of
> > proxy ARP.
> >
> > Is this an appropriate application for proxy ARP?  Is it a common enough
> > use case to support in OVN?  Should it instead be handled through a more
> > general service function chaining interface?
> >
> 
> I have similar concerns about how useful it is. I agree it is kind of
> lightweight SFC, but in my opinion it is not contradict with the fact that
> it is also Proxy ARP. At least the firewall example (the 3rd use case)
> described in https://en.wikipedia.org/wiki/Proxy_ARP seems to be very
> close. SFC may be a more general approach to redirect packets to a
> firewall, but it is heavier, and may be difficult in a non-overlay
> environment, while Proxy ARP is sufficient and simple for such specific use
> cases when the nodes are L2 adjacent. So I think it may be good to have
> such feature in OVN, if the change is not intrusive.

Do the general SFC patches that John McDowall is currently working on
serve this use case too?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovn: Support ARP proxy in logical switches.

[Ben Pfaff]

On Mon, Jan 09, 2017 at 04:08:08PM -0800, Han Zhou wrote:
> This is an intermediate solution because a better way to do it is to
> utilize the load-balancing feature of OVN to replace kubeproxy completely,
> and the problem won't exist at all. It just takes more effort to integrate
> and we are not there yet.

Guru has already built OVN-k8 integration, which includes a load
balancer.  Does it work for your case?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovn: Support ARP proxy in logical switches.

[Bruce Davie]

Han,
 Thanks - that makes sense to me. I can’t claim that this is a hugely general 
feature, but your use case seems legit to me (with the caveat that I’m no k8s 
expert).

Bruce

On Jan 9, 2017, at 4:08 PM, Han Zhou 
> wrote:

Hi Bruce,

This feature is useful for me. I had the concern because the use case for me is 
intermediate. It is for k8s integration. In k8s there is a kubeproxy running on 
each host to do service-ip NATting, and I am using OVS (programmed by OVN) to 
connect host network namespace to containers (and also connection between 
containers on the same host). When an NATted end-point of a service-ip happen 
to be on the same host (and of course, same L2, since we use bridged mode), 
then the return traffic would be forwarded directly to the source without going 
through the kubeproxy. With this ARP-proxy patch, the interface to the host 
network namespace is specified as ARP proxy port, and traffic between 
containers will go through the host for NATting.

This is an intermediate solution because a better way to do it is to utilize 
the load-balancing feature of OVN to replace kubeproxy completely, and the 
problem won't exist at all. It just takes more effort to integrate and we are 
not there yet.

Hope this clarifies my use case. But I'd like to hear if this feature would 
useful in any other circumstances.

Thanks,
Han

On Mon, Jan 9, 2017 at 2:57 PM, Bruce Davie 
> wrote:
>
> Han,
> Your comment gave me pause:
> > I have similar concerns about how useful it is.
>
> Whereas the current proxy ARP function in OVN has a pretty clear motivation & 
> tightly defined use case (to avoid needless broadcast of ARP requests across 
> the overlay when the logical router’s IP and MAC are known) it seems like 
> even you don’t really have a clear use case in mind for this additional 
> functionality. Can you try to lay our more clearly why you think this is a 
> useful enough addition to OVN to warrant the extra complexity?
>
> Thanks
> Bruce
>

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovn: Support ARP proxy in logical switches.

[Han Zhou]

Hi Bruce,

This feature is useful for me. I had the concern because the use case for
me is intermediate. It is for k8s integration. In k8s there is a kubeproxy
running on each host to do service-ip NATting, and I am using OVS
(programmed by OVN) to connect host network namespace to containers (and
also connection between containers on the same host). When an NATted
end-point of a service-ip happen to be on the same host (and of course,
same L2, since we use bridged mode), then the return traffic would be
forwarded directly to the source without going through the kubeproxy. With
this ARP-proxy patch, the interface to the host network namespace is
specified as ARP proxy port, and traffic between containers will go through
the host for NATting.

This is an intermediate solution because a better way to do it is to
utilize the load-balancing feature of OVN to replace kubeproxy completely,
and the problem won't exist at all. It just takes more effort to integrate
and we are not there yet.

Hope this clarifies my use case. But I'd like to hear if this feature would
useful in any other circumstances.

Thanks,
Han

On Mon, Jan 9, 2017 at 2:57 PM, Bruce Davie  wrote:
>
> Han,
> Your comment gave me pause:
> > I have similar concerns about how useful it is.
>
> Whereas the current proxy ARP function in OVN has a pretty clear
motivation & tightly defined use case (to avoid needless broadcast of ARP
requests across the overlay when the logical router’s IP and MAC are known)
it seems like even you don’t really have a clear use case in mind for this
additional functionality. Can you try to lay our more clearly why you think
this is a useful enough addition to OVN to warrant the extra complexity?
>
> Thanks
> Bruce
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovn: Support ARP proxy in logical switches.

[Han Zhou]

On Wed, Jan 4, 2017 at 3:29 PM, Ben Pfaff  wrote:
>
> [adding Bruce to leverage his knowledge of networking, if he's willing]

Thanks! It would be great to get some views from networking experts.

>
> It seems like the mechanics of this patch are mostly OK.  There is at
> least one inconsistency in ovn-nb.xml, where it says in one place that
> the new option is for all port types and in another that it's only for
> ports with an empty 'type'.  (For the record, if it's for every port
> type, then it should be in other_config.  'options' is intended for
> type-specific configuration, not for generic configuration.)

Ah, my bad. In the beginning I thought it may be applicable for any type,
but then I realized it is not. My current use case is for empty type only.
I'll move the text to the section "VMI (or VIF) Options". It may also be
useful for router type, but not likely for l2gateway, and definitely not
applicable for localnet.

>
> However, I'm concerned about the general utility here.  I usually think
> of proxy ARP as being used for the kinds of applications you see in the
> wikipedia on proxy ARP: https://en.wikipedia.org/wiki/Proxy_ARP.  This
> seems to aimed at a different application that is more like a weak form
> of service function chaining than for the traditional applications of
> proxy ARP.
>
> Is this an appropriate application for proxy ARP?  Is it a common enough
> use case to support in OVN?  Should it instead be handled through a more
> general service function chaining interface?
>

I have similar concerns about how useful it is. I agree it is kind of
lightweight SFC, but in my opinion it is not contradict with the fact that
it is also Proxy ARP. At least the firewall example (the 3rd use case)
described in https://en.wikipedia.org/wiki/Proxy_ARP seems to be very
close. SFC may be a more general approach to redirect packets to a
firewall, but it is heavier, and may be difficult in a non-overlay
environment, while Proxy ARP is sufficient and simple for such specific use
cases when the nodes are L2 adjacent. So I think it may be good to have
such feature in OVN, if the change is not intrusive.

> Bruce, the first file in the patch explains the application here pretty
> well, that's probably the bit that you should read.
>
> Thanks,
>
> Ben.
>
> On Thu, Dec 22, 2016 at 09:43:16PM -0800, Han Zhou wrote:
> > This patch support "arp_proxy" option for logical switch ports. If
> > a lsp with arp_proxy=true, all the arp request to known ipv4
> > addresses on the ls will be responded with the arp proxy lsp's MAC
> > address, except when the arp request come from the arp proxy lsp
> > itself.
> >
> > Signed-off-by: Han Zhou 
> > ---
> >  ovn/northd/ovn-northd.8.xml |  23 
> >  ovn/northd/ovn-northd.c | 119
--
> >  ovn/ovn-nb.xml  |  11 
> >  tests/ovn.at| 136

> >  4 files changed, 271 insertions(+), 18 deletions(-)
> >
> > diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
> > index f3c1682..aefa086 100644
> > --- a/ovn/northd/ovn-northd.8.xml
> > +++ b/ovn/northd/ovn-northd.8.xml
> > @@ -446,6 +446,19 @@
> >  
> >
> >  
> > +  In particular, if a logical switch port has option proxy_arp set
to
> > +  true, we call it an arp-proxy port. In such case, ARP requests to
> > +  IPv4 addresses of any logical port on the same logical switch
will
> > +  be responded with the MAC address of that arp-proxy port, except
when
> > +  the request comes from that arp-proxy port, which can still
learn the
> > +  real MAC of destination VM/Container. This feature is useful if
we
> > +  want all the traffic to/from any logical ports on the logical
switch
> > +  being forwarded to a particular logical port, which may act as a
proxy
> > +  and will forward the traffic to the real destination after some
pre-
> > +  processing.
> > +
> > +
> > +
> >ARP requests arrive from VMs from a logical switch inport of type
> >default.  For this case, the logical switch proxy ARP rules can
be
> >for other VMs or logical router ports.  Logical switch proxy ARP
> > @@ -521,6 +534,16 @@ output;
> >  
> >
> >  
> > +  If arp-proxy port is present in the logical switch, the above
> > +  mentioned Ethernet address E will be the one
belonging
> > +  to the arp-proxy port, and there will be Priority-60 flows
that
> > +  match ARP requests from the arp-proxy port to each known IP
address
> > +  of every logical switch port, and respond with ARP replies
in the
> > +  same format as above but with Ethernet address E
being
> > +  the real one belonging to each target logical switch port.
> > +
> > +
> > +
> >These flows are omitted for logical ports (other than router
ports)
> >

[ovs-dev] [PATCH] ovn: Support ARP proxy in logical switches.

[Han Zhou]

This patch support "arp_proxy" option for logical switch ports. If
a lsp with arp_proxy=true, all the arp request to known ipv4
addresses on the ls will be responded with the arp proxy lsp's MAC
address, except when the arp request come from the arp proxy lsp
itself.

Signed-off-by: Han Zhou 
---
 ovn/northd/ovn-northd.8.xml |  23 
 ovn/northd/ovn-northd.c | 119 --
 ovn/ovn-nb.xml  |  11 
 tests/ovn.at| 136 
 4 files changed, 271 insertions(+), 18 deletions(-)

diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
index f3c1682..aefa086 100644
--- a/ovn/northd/ovn-northd.8.xml
+++ b/ovn/northd/ovn-northd.8.xml
@@ -446,6 +446,19 @@
 
 
 
+  In particular, if a logical switch port has option proxy_arp set to
+  true, we call it an arp-proxy port. In such case, ARP requests to
+  IPv4 addresses of any logical port on the same logical switch will
+  be responded with the MAC address of that arp-proxy port, except when
+  the request comes from that arp-proxy port, which can still learn the
+  real MAC of destination VM/Container. This feature is useful if we
+  want all the traffic to/from any logical ports on the logical switch
+  being forwarded to a particular logical port, which may act as a proxy
+  and will forward the traffic to the real destination after some pre-
+  processing.
+
+
+
   ARP requests arrive from VMs from a logical switch inport of type
   default.  For this case, the logical switch proxy ARP rules can be
   for other VMs or logical router ports.  Logical switch proxy ARP
@@ -521,6 +534,16 @@ output;
 
 
 
+  If arp-proxy port is present in the logical switch, the above
+  mentioned Ethernet address E will be the one belonging
+  to the arp-proxy port, and there will be Priority-60 flows that
+  match ARP requests from the arp-proxy port to each known IP address
+  of every logical switch port, and respond with ARP replies in the
+  same format as above but with Ethernet address E being
+  the real one belonging to each target logical switch port.
+
+
+
   These flows are omitted for logical ports (other than router ports)
   that are down.
 
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index c56ac79..f897658 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -380,6 +380,10 @@ struct ovn_datapath {
 
 bool has_unknown;
 
+/* ARP proxy port: MAC of the lport will be used by arp
+ * responder for other lports in the same LS. */
+struct ovn_port *arp_proxy_port;
+
 /* IPAM data. */
 struct hmap ipam;
 };
@@ -2012,6 +2016,15 @@ build_port_security_ip(enum ovn_pipeline pipeline, 
struct ovn_port *op,
 }
 
 static bool
+lsp_is_arp_proxy(const struct nbrec_logical_switch_port *lsp)
+{
+
+bool is_arp_proxy = smap_get_bool(>options,
+  "arp_proxy", false);
+return is_arp_proxy;
+}
+
+static bool
 lsp_is_enabled(const struct nbrec_logical_switch_port *lsp)
 {
 return !lsp->enabled || *lsp->enabled;
@@ -2852,6 +2865,32 @@ build_lswitch_flows(struct hmap *datapaths, struct hmap 
*ports,
 ovn_lflow_add(lflows, od, S_SWITCH_IN_PORT_SEC_IP, 0, "1", "next;");
 }
 
+/* Check arp_proxy option for LS ports */
+HMAP_FOR_EACH (op, key_node, ports) {
+if (!op->nbsp) {
+continue;
+}
+
+if (lsp_is_arp_proxy(op->nbsp)) {
+if (op->n_lsp_addrs != 1) {
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
+VLOG_WARN_RL(, "one and only one address expected for arp "
+ "proxy port %s", op->json_key);
+continue;
+}
+if (op->od->arp_proxy_port) {
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
+VLOG_WARN_RL(,
+ "ARP proxy lsp %s already existed on ls "UUID_FMT
+ " but another lsp %s is seen",
+ op->od->arp_proxy_port->json_key,
+ UUID_ARGS(>od->key),
+ op->json_key);
+continue;
+}
+op->od->arp_proxy_port = op;
+}
+}
 /* Ingress table 10: ARP/ND responder, skip requests coming from localnet
  * and vtep ports. (priority 100); see ovn-northd.8.xml for the
  * rationale. */
@@ -2888,24 +2927,68 @@ build_lswitch_flows(struct hmap *datapaths, struct hmap 
*ports,
 for (size_t i = 0; i < op->n_lsp_addrs; i++) {
 for (size_t j = 0; j < op->lsp_addrs[i].n_ipv4_addrs; j++) {
 ds_clear();
-ds_put_format(, "arp.tpa