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

Darrell Ball dlu998 at gmail.com
Tue Oct 4 22:27:26 UTC 2016


On Tue, Oct 4, 2016 at 11:04 AM, Han Zhou <zhouhan at gmail.com> wrote:

>
>
> On Tue, Oct 4, 2016 at 10:16 AM, Darrell Ball <dlu998 at gmail.com> wrote:
> >
> >
> >
> > On Mon, Oct 3, 2016 at 3:16 PM, Han Zhou <zhouhan at gmail.com> wrote:
> >>
> >>
> >>
> >> On Mon, Oct 3, 2016 at 2:21 PM, Darrell Ball <dlu998 at gmail.com> wrote:
> >> >
> >> >
> >> >
> >> > On Mon, Oct 3, 2016 at 10:54 AM, Han Zhou <zhouhan at gmail.com> wrote:
> >> >>
> >> >>
> >> >>
> >> >> 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.
> >> >
> >> >
> >> > I think you missed the main aspect.
> >> > There is a layering violation in doing this and also a modeling issue.
> >> > The key idea can be summarized as "A logical router should respond to
> arps
> >> > to itself" rather than some logical switch proxying that.
> >> > This has implications for cases where an IP address is shared by
> several gateways
> >> > and then the binding is used to designate the gateway used.
> >> >
> >>
> >> So is it for L3 GW HA? Are different MACs supposed to be used when the
> router is hosted on different gateways?
> >
> >
> > One approach is for backups gateways to take over IP ownership, but we
> are probably getting
> > ahead of ourselves.
> >
> > I think we can speed up the debate, for the present state of the code.
> >
> > For the L3 gateway, there is a explicit mac binding entry being
> generated in northd.
> > This is NOT the arp responder we discuss in this patch.
> > This is an explicit binding rule.
> >
> > See the L3 gateway test.
> >
> >  table=6 (lr_in_arp_resolve  ), priority=100  , match=(outport ==
> "R1_join" && reg0 == 20.0.0.2), action=(eth.dst = 00:00:04:01:02:04; next;)
> >
> >
> > From ofproto tracing on HV1:
> > Rule: table=22 cookie=0 priority=100,reg0=0x14000002,r
> eg15=0x2,metadata=0x1
> > OpenFlow actions=set_field:00:00:04:01:02:04->eth_dst,resubmit(,23)
> >
> > The gets "helped along" by mac address sharing by transit logical switch
> and gateway
> > patch ports.
> >
> > # Connect R2 to join
> > ovn-nbctl lrp-add R2 R2_join 00:00:04:01:02:04 20.0.0.2/24
> > ovn-nbctl lsp-add join r2-join -- set Logical_Switch_Port r2-join \
> >     type=router options:router-port=R2_join
> addresses='"00:00:04:01:02:04"'
> >
> >
> > Let me know if you still think the logical switch "router type" arp
> responder
> > (in this patch) is needed for L3 gateway support.
> >
> >
> Darrell, thanks for explaining, but I think there may be some
> misunderstanding. I didn't mean the arp responder is "needed" for L3
> gateway to work. My point is that this patch will result in flooding of ARP
> request for router port IP, which seems unnecessary to me. My opinion to
> ARP responder for router port IP is:
>

Based on our phone discussion and agreement.


>
> 1) for ARP requests to IPs of non-gateway logical router ports, flooding
> should be suppressed and ARP responder on LS should work;
>

Yes, I agree and I am not changing that here.
That is the case when inport is of type "empty".
This patch is related to inport of type "router type" - since we have no
need for this case,
I will proceed.



> 2) for ARP requests to IPs of gateway router ports, it is still better to
> be suppressed, if possible.
>

We use a static arp binding for the DLR to GR hop, as discussed earlier.



>
> This patch would result in flooding for both cases. And for 2), I didn't
> see a clear reason why we have to disable the ARP responder to support GW
> HA. For my understanding no matter on which HV the GW router port binding
> is created, the MAC is the same, so it is not harmful to reply by ARP
> responder on LS before the binding is created.
>

We can come back to this one at the appropriate time.


> The example you gave is not related to ARP responder.
>

Looks like we had our wires crossed.
As we agreed, I mentioned it is an explicit binding rule hence even more
optimal
than early arp response - no need for sending and replying of arp packets.

"> This is NOT the arp responder we discuss in this patch.
> This is an explicit binding rule."



> ARP responder will be used only if a VIF is attached to the "join" switch,
> and the VM behind the VIF sends a ARP request to the gateway port.
>

As we agreed, this case is of little practical importance and we don't need
to optimize it.


> To put it simple, ARP is to resolve IP to MAC,
>
so it should be responded at the earliest point where the information is
> available.
>
Please let me know if I missed something.
>

No need to discuss this part.



>
> Thanks,
> Han
>



More information about the dev mailing list