[ovs-dev] [patch_v2 2/3] ovn: Add additional comments regarding arp responders.

Darrell Ball dlu998 at gmail.com
Sat Oct 1 23:34:53 UTC 2016


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.

Signed-off-by: Darrell Ball <dlu998 at gmail.com>
---
 ovn/northd/ovn-northd.8.xml | 25 ++++++++++++++++++++-----
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
index 77eb3d1..74ac5b3 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> or <code>router</code>,
+        and advances directly to the next table.  <code>localnet</code>
+        and <code>vtep</code> 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.  If the
+        inport is of type <code>router</code>, we skip install since
+        there is no known valid use case.  There is a special case:
+        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.
       </li>
 
       <li>
@@ -446,8 +461,8 @@ output;
         </pre>
 
         <p>
-          These flows are omitted for logical ports (other than router ports)
-          that are down.
+          These flows are omitted for router type ports and other
+          logical ports that are down.
         </p>
       </li>
 
-- 
1.9.1




More information about the dev mailing list