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

Darrell Ball dlu998 at gmail.com
Wed Oct 5 17:08:21 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>
---

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

 ovn/northd/ovn-northd.8.xml | 37 ++++++++++++++++++++++++++++++++++---
 1 file changed, 34 insertions(+), 3 deletions(-)

diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
index 77eb3d1..7496284 100644
--- a/ovn/northd/ovn-northd.8.xml
+++ b/ovn/northd/ovn-northd.8.xml
@@ -415,14 +415,45 @@
     <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.
+      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.  <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.  The
+        inport being of type <code>router</code> has no valid use case.
+        No special filtering is done for these packets, as there would
+        be some additional flow cost for this and the value appears
+        limited, at this time.  The inport of type empty is the most
+        common case and includes both proxy arp for other VMs and also
+        logical router ports (if a corresponding IP address is configured
+        on the peer logical switch router type port).  There is a
+        requirement that both MAC and IP (if configured) be manually
+        enforced to match on logical switch router type and logical
+        router port peers.  If the 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.  There is a
+        disadvantage to using the logical router datapath arp responder,
+        when both logical switch and logical router datapath arp
+        responders can be used, in that the arp request from a VM would
+        have already hit the logical switch datapath broadcast rule.
+        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>
-- 
1.9.1




More information about the dev mailing list