[ovs-dev] [patch_v5 2/3] ovn: Add additional comments regarding arp responders.
dlu998 at gmail.com
Fri Oct 21 20:36:38 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>
Signed-off-by: Ramu Ramamurthy <ramu.ramamurthy at us.ibm.com>
Co-authored-by: Ramu Ramamurthy <ramu.ramamurthy at us.ibm.com>
Acked-by: Han Zhou <zhouhan at gmail.com>
v4->v5: Splice in some rewording from review from multiple sources.
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 | 67 +++++++++++++++++++++++++++++++++++++++++----
1 file changed, 61 insertions(+), 6 deletions(-)
diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
index df53d4c..930ebf4 100644
@@ -435,20 +435,75 @@
<h3>Ingress Table 10: ARP/ND responder</h3>
- This table implements ARP/ND responder for known IPs. It contains these
- logical flows:
+ This table implements ARP/ND responder in a logical switch 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 arrive from VMs from a logical switch inport of type
+ default. For this case, the logical switch proxy ARP rules can be
+ for other VMs or logical router ports. Logical switch proxy ARP
+ rules may be programmed both for mac binding of IP addresses on
+ other logical switch VIF ports (which are of the default logical
+ switch port type, representing connectivity to VMs or containers),
+ and for mac binding of IP addresses on logical switch router type
+ ports, representing their logical router port peers. 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. When a VM sends an ARP request for a
+ distributed logical router port and if the peer router type port of
+ the attached logical switch does not have an IP address configured,
+ the ARP request will be broadcast on the logical switch. One of the
+ copies of the ARP request will go through the logical switch router
+ type port to the logical router datapath, where the logical router ARP
+ responder will generate a reply. The mac binding in a VM for an
+ associated distributed logical router will be used for all
+ communication needing routing, hence the action of a VM re-arping for
+ the mac binding of the logical router port should be rare.
+ 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 destination 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. In either case, logical switch ARP responder rules
+ will not be hit. 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. ARP requests sent to <code>localnet</code> or
+ <code>vtep</code> ports can be received by multiple hypervisors.
+ Now, because the same mac binding rules are downloaded to all
+ hypervisors, each of the multiple hypervisors will respond. This
+ will confuse L2 learning on the source of the ARP requests. ARP
+ requests received on an inport of type <code>router</code> are not
+ expected to hit any logical switch ARP responder flows. 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>:
@@ -475,7 +530,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