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

[Han Zhou]

On Tue, Jan 31, 2017 at 2:49 PM, Ben Pfaff <blp at ovn.org> 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 <blp at ovn.org> 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