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

Darrell Ball dlu998 at gmail.com
Thu Oct 6 17:34:34 UTC 2016


There has been enough confusion regarding logical switch datapath
arp responders in ovn to warrant some additional comments;
hence add a general description regarding why they exist and
document the special cases.

Signed-off-by: Darrell Ball <dlu998 at gmail.com>
---

Note this patch is meant to be merge with the code change for vtep
inport handling here.
https://patchwork.ozlabs.org/patch/675796/

v3->v4: Capitalization fixes.
        Reinstate comment regarding L2 learning confusion.

v2->v3: Reword and further elaborate.

v1->v2: Dropped RFC code change for logical switch router
        type ports

 ovn/northd/ovn-northd.8.xml | 52 +++++++++++++++++++++++++++++++++++++++------
 1 file changed, 46 insertions(+), 6 deletions(-)

diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
index 77eb3d1..5ac351d 100644
--- a/ovn/northd/ovn-northd.8.xml
+++ b/ovn/northd/ovn-northd.8.xml
@@ -415,20 +415,60 @@
     <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.  This behavior is proxy ARP.
+      ARP requests received by multiple hypervisors, as in the case of
+      <code>localnet</code> and <code>vtep</code> logical inports need
+      to skip these logical switch ARP responders;  the reason being
+      that northd downloads the same mac binding rules to all hypervisors
+      and all hypervisors will receive the ARP request from the external
+      network and respond.  This will confuse L2 learning on the source
+      of the ARP requests.  These skip rules are mentioned under
+      priority-100 flows.  ARP requests arrive from VMs with a logical
+      switch inport type of type empty, which is the default.  For this
+      case, the logical switch proxy ARP rules can be for other VMs or
+      a logical router port.  In order to support proxy ARP for logical
+      router ports, an IP address must be configured on the logical
+      switch router type port, with the same value as the peer of the
+      logical router port.  The configured MAC addresses must match as
+      well.  If this logical switch router type port does not have an
+      IP address configured, ARP requests will hit another ARP responder
+      on the logical router datapath itself, which is most commonly a
+      distributed logical router.  The advantage of using the logical
+      switch proxy ARP rule for logical router ports is that this rule
+      is hit before the logical switch L2 broadcast rule.  This means
+      the ARP request is not broadcast on this logical switch.  Logical
+      switch ARP responder proxy ARP rules can also be hit when
+      receiving ARP requests externally on a L2 gateway port.  In this
+      case, the hypervisor acting as an L2 gateway, responds to the ARP
+      request on behalf of a VM.  Note that ARP requests received from
+      <code>localnet</code> or <code>vtep</code> logical inports can
+      either go directly to VMs, in which case the VM responds or can
+      hit an ARP responder for a logical router port if the packet is
+      used to resolve a logical router port next hop address.
+      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.
+        Priority-100 flows to skip the ARP responder if inport is
+        of type <code>localnet</code> or <code>vtep</code> and
+        advances directly to the next table.  The inport being of type
+        <code>router</code> has no known use case for these ARP
+        responders.  However, no skip flows are installed for these
+        packets, as there would be some additional flow cost for this
+        and the value appears limited.
       </li>
 
       <li>
         <p>
           Priority-50 flows that match ARP requests to each known IP address
-          <var>A</var> of every logical router port, and respond with ARP
+          <var>A</var> of every logical switch port, and respond with ARP
           replies directly with corresponding Ethernet address <var>E</var>:
         </p>
 
@@ -455,7 +495,7 @@ output;
         <p>
           Priority-50 flows that match IPv6 ND neighbor solicitations to
           each known IP address <var>A</var> (and <var>A</var>'s
-          solicited node address) of every logical router port, and
+          solicited node address) of every logical switch port, and
           respond with neighbor advertisements directly with
           corresponding Ethernet address <var>E</var>:
         </p>
-- 
1.9.1




More information about the dev mailing list