Acked-by: Mickey Spiegel <mickeys....@gmail.com>
A few very minor nits below.
On Fri, Oct 21, 2016 at 1:36 PM, Darrell Ball <dlu...@gmail.com> wrote:
> 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>
> Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com>
> Co-authored-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com>
> Acked-by: Han Zhou <zhou...@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
> type ports.
>
> 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
> --- a/ovn/northd/ovn-northd.8.xml
> +++ b/ovn/northd/ovn-northd.8.xml
> @@ -435,20 +435,75 @@
> <h3>Ingress Table 10: 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 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.
> + </p>
> +
> + <p>
> + 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
>
Instead of "peer of the logical router port" (did you mean the logical
router port or the logical switch router type port?), perhaps just
"peer logical router port"?
> + 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
>
There is an extra space in "peer router".
> + 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.
>
There is a context switch going into the last sentence that can be a bit
confusing. How about:
After the VM learns a MAC binding for an associated distributed logical
router, that MAC binding will be used for all communication needing
routing, hence ...
> + </p>
> +
> + <p>
> + 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.
> + </p>
> +
> + <p>
> + 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
>
I prefer a comma between "responds" and "or".
> + 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:
> </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.
> + 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.
>
Change "will" to "would" in both places above, since this is part of the
hypothetical rationale and not an action that will actually be taken.
> </li>
>
> <li>
> <p>
> 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>:
> </p>
>
> @@ -475,7 +530,7 @@ output;
> <p>
> 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>:
> </p>
> --
> 1.9.1
>
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
