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 <dlu...@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
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
