On Wed, Oct 5, 2016 at 10:08 AM, 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>
> ---
>
> 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
>
/otherwise/since
> + 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
>
Up to this point, I agree.
The rest of the description below (with the exception of "l2gateway"
at the bottom) is not about the priority 100 flows, and is not about inport.
It is about the priority 50 flows, whether to program ARP/ND responder
flows for IP/MAC combinations for logical switch ports of certain types.
Note that inport is not part of the match criteria for the priority 50
flows.
If these ARP/ND responder flows are programmed, they work on all
inports, unless overriden by the priority 100 flows above. For example,
an ARP for a logical router IP address may be received on a VIF inport.
The existing description of the priority 50 flows has an error. It should
be referring to "logical switch port" rather than "logical router port",
i.e.
instead of:
Priority-50 flows that match ARP requests to each known IP address
<var>A</var> of every logical router port, and respond with ARP
...
It should read:
Priority-50 flows that match ARP requests to each known IP address
<var>A</var> of every logical switch port, and respond with ARP
The rest of the description below (with the exception of "l2gateway" at the
bottom) should be attached to the paragraph that reads:
These flows are omitted for logical ports (other than router
ports)
that are down.
Something along the lines of:
+ Note that proxy arp for logical router ports is enabled, if a
+ corresponding IP address is configured on the peer logical
+ switch port of type <code>router</code>. 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. When the logical
+ switch datapath arp responder is used for ports of type
+ <code>router</code>, then arp requests from VMs would hit
+ the logical switch datapath broadcast rule. These arp requests
+ would not hit the logical router datapath arp responder. If arp
+ requests are received on <code>localnet</code> or
+ <code>vtep</code> logical switch ports, those arp requests
+ would be handled by the logical router datapath arp responder.
Mickey
+ 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
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
