[ovs-dev] [patch_v2] ovn: Add additional comments regarding arp responders.
Darrell Ball
dlu998 at gmail.com
Wed Oct 5 22:37:31 UTC 2016
On Wed, Oct 5, 2016 at 2:37 PM, Mickey Spiegel <mickeys.dev at gmail.com>
wrote:
> On Wed, Oct 5, 2016 at 10:08 AM, Darrell Ball <dlu998 at 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 <dlu998 at 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 overridden by the priority 100 flows above. For example,
> an ARP for a logical router IP address may be received on a VIF inport.
>
>
I agree the priority 50 flows are not inport specific but the overall
result, which
is what we really want to clarify is based on <both> the priority 100 skip
table flows
which are inport specific and the priority 50 arp responder flows proper.
Mentioning details regarding inport types is important to understand the
overall
behavior. I don't plan to limit important information, so I will not be
cutting the
description regarding inport types.
Also there are two descriptions for the priority 50 flows - one for V4 and
one for V6
and I don't want to repeat the overall explanation for both.
There are also two paragraphs references to "These flows are omitted..."
Alternatively, I will move the overall logic description to the
introductory paragraph
and briefly introduce the following flows, in one place; i.e. no repetition.
This location is not flow specific but rather about overall logic.
> 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
>
Actually, the existing description is incorrect for V6 as well as V4.
>
> 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>.
>
I can add this
> 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.
>
No change for above
> 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.
>
I was trying to communicate that matching the arp responder rule
logical switch router type ports occurs before the L2 broadcast rule
and the packet is not broadcast vs hitting the logical router datapath
arp responder rule, where broadcast on the logical switch has already
occurred.
I don't think your version communicates that and mine is not that well
worded, as well. I will reword.
> 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.
>
That is misleading. A common case is that arp requests go directly to the
VMs to be responded to by hopefully one VM. This happens when only
a logical switch forwarding is involved and there is no logical router
datapath. I will reword.
>
> 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 at openvswitch.org
>> http://openvswitch.org/mailman/listinfo/dev
>>
>
>
More information about the dev
mailing list