[ovs-dev] [patch_v4] ovn: Add additional comments regarding arp responders.
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.
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
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
@@ -415,20 +415,60 @@
<h3>Ingress Table 9: ARP/ND responder</h3>
- 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:
- 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.
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>:
@@ -455,7 +495,7 @@ output;
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>:
More information about the dev