[ovs-dev] [CudaMailTagged] [patch_v1] ovn: Add additional comments regarding arp responders.

[Darrell Ball]

On Tue, Sep 27, 2016 at 4:49 PM, Han Zhou <zhouhan at gmail.com> wrote:

>
>
> On Tue, Sep 27, 2016 at 2:36 PM, Darrell Ball <dlu998 at gmail.com> wrote:
> >
> > There has been enough confusion regarding arp responders in
> > ovn to warrant some additional comments;  hence add a
> > general description regarding why they exist and document
> > the special cases.
> >
> > The patch goes along with patch fix for vtep ports here:
> > https://patchwork.ozlabs.org/patch/675796/
> >
> > Signed-off-by: Darrell Ball <dlu998 at gmail.com>
> > ---
> >  ovn/northd/ovn-northd.8.xml | 21 ++++++++++++++++++---
> >  1 file changed, 18 insertions(+), 3 deletions(-)
> >
> > diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
> > index 307e8be..0755213 100644
> > --- a/ovn/northd/ovn-northd.8.xml
> > +++ b/ovn/northd/ovn-northd.8.xml
> > @@ -415,14 +415,29 @@
> >      <h3>Ingress Table 9: ARP/ND responder</h3>
> >
> >      <p>
> > -      This table implements ARP/ND responder for known IPs.  It
> contains these
> > -      logical flows:
> > +      This table implements ARP/ND responder for known IPs.  The
> advantage
> > +      of the arp responder flow is to limit arp broadcasts by locally
> > +      responding to arp requests without the need to send to other
> > +      hypervisors.  One common case is when the inport is a logical
> > +      port associated with a VIF and the broadcast is responded to on
> the
> > +      local hypervisor rather than broadcast across the whole network
> and
> > +      responded to by the destination VM.  It contains these logical
> flows:
> >      </p>
> >
> >      <ul>
> >        <li>
> >          Priority-100 flows to skip ARP responder if inport is of type
> > -        <code>localnet</code>, and advances directly to the next table.
> > +        <code>localnet</code> or <code>vtep</code>, and advances
> directly
> > +        to the next table.  These port types are skipped because the arp
> > +        requests are received by multiple hypervisors which all have the
> > +        same mac binding locally.  There are some special cases:
>
> How about this:
>
> These port types are skipped because ARP responder is not supposed to
> handle ARP requests that come from physical network.
>

There is a special case of the l2gateway where
a request comes from the physical network destined to a VM
somewhere; this is north->south traffic. This traffic hits a single
l2gateway inport and is associated with a logical switch.
There will be an arp responder on this source HV in gateway role.
Hence, there would be a single arp reply back out to the physical network.



> Otherwise, because all the chassises receiving the requests will reply,
> there will be redundant responses.
>

I got your point; let me roll in and elaborate a bit ?

"These port types are skipped.  Otherwise the arp
request is received by multiple hypervisors, which all have the
same mac binding downloaded from northd, which will cause
redundant arp replies, confusing the originator of the arp request. "




>
> > +        north->south traffic using the l2gateway port will use an arp
> > +        responder on the l2 gateway chassis in the context of a logical
> > +        switch datapath.  Another case is when traffic flows from
> > +        south->north or east->west and goes through the gateway router.
> > +        This arp request will flow through a transit logical switch at
> > +        the destination hypervisor before going through the gateway
> router
> > +        and its inport will be a logical switch router type port.
> >        </li>
> >
> >        <li>
> > --
> > 1.9.1
> >
> > _______________________________________________
> > dev mailing list
> > dev at openvswitch.org
> > http://openvswitch.org/mailman/listinfo/dev
>
>