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

Han Zhou zhouhan at gmail.com
Tue Sep 27 23:49:55 UTC 2016


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. Otherwise, because all
the chassises receiving the requests will reply, there will be redundant
responses.

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



More information about the dev mailing list