[ovs-dev] [patch_v2 1/3] ovn: Skip logical switch "router type" port arp responder install.

[Han Zhou]

On Sun, Oct 2, 2016 at 2:14 PM, Darrell Ball <dlu998 at gmail.com> wrote:
>
>
>
> On Sun, Oct 2, 2016 at 11:27 AM, Han Zhou <zhouhan at gmail.com> wrote:
>>
>> On Sat, Oct 1, 2016 at 4:34 PM, Darrell Ball <dlu998 at gmail.com> wrote:
>> >
>> > Do not install any potential logical switch "router type"
>> > port arp responders.  Logical router port arp responders
>> > should be sufficient in this respect.
>> > It seems a little wierd for a logical switch not proxying
>> > for a remote VIF to be responding to arp requests and we
>> > are not functionally using this capability in ovn.
>> >
>> Hi Darrell,
>>
>> The arp responder for patch port is useful e.g. when a VM pings the
default gateway IP. Would removing the flow cause the arp request get
flooded? And what's the benefit of removing it here?
>
>
> 1) Modelling: I would expect the L3 gateway arp responder to be
associated with the L3
> gateway router datapath, at the very least. That way, the modeling is
correct and we don't have a situation where, for example, a phantom gateway
router is never even downloaded to a HV,
> but is "responding" or rather appearing to respond to arp requests.
>

Ok, I see your concern. To achieve this expectation, it may be done in a
way that is similar as the regular LS ports: reply ARP only if
Logical_Switch_Port.up = true. When gateway router is bound to a chassis we
can set the LS patch port up to true. And for distributed routers we can
set patch port up directly. This way we can avoid responding ARP before
gate router is bound.

However, I wonder even this change may not be needed. For my understanding
ARP is just to resolve address. Do you see any real problem of replying
even if the gateway router is not yet bound? I don't think this is a
problem of modeling. It might look weird just because it behaves slightly
different from traditional view. I would prefer keep the simplicity.

> 2) We install an arp responder for the logical routers, including L3
gateway(s) today (see below).
> We check for inport in this rule and this inport is only associated with
the L3 gateway HV.
> So only the L3 gateway HV should respond. Meaning, if there is a
response, the L3 gateway
> datapath is really there.

But the L2 flooding would still happen, right?

>
> 3) Usually, there are a limited number of L3 gateways and therefore
associated bindings.
> Also, for VMs participating in south<->north traffic, the bindings are
less likely
> to timeout since there are multiple uses of the L3 gateway for each VM.
>

With a big L2, even a small percent of VM doing ARP will cause annoying
flooding. Moreover, considering containers come and go frequently this
would be more common. So I think it is still better to suppress ARP for
south-north if there is no real problem.

>
>>
>>
>>
>> Han
>
>