Han
After much cross wiring, I will leave the early logical switch arp
responder ("router type") for
logical router ports in place, for now.
As stated, it is not a great optimization as VMs should not age the DLR mac
binding very often.
I think there is some opportunity to handle this more cleanly, in a
transparent way and allowing
for any optimization the customer may want.
Hopefully, that would all the problems we have had with arp responders less
common.
I will proceed with documentation for these special arp responder cases,
for now.
Thanks Darrell
On Tue, Oct 4, 2016 at 3:27 PM, Darrell Ball <dlu...@gmail.com> wrote:
>
>
> On Tue, Oct 4, 2016 at 11:04 AM, Han Zhou <zhou...@gmail.com> wrote:
>
>>
>>
>> On Tue, Oct 4, 2016 at 10:16 AM, Darrell Ball <dlu...@gmail.com> wrote:
>> >
>> >
>> >
>> > On Mon, Oct 3, 2016 at 3:16 PM, Han Zhou <zhou...@gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> On Mon, Oct 3, 2016 at 2:21 PM, Darrell Ball <dlu...@gmail.com> wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Mon, Oct 3, 2016 at 10:54 AM, Han Zhou <zhou...@gmail.com> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Sun, Oct 2, 2016 at 2:14 PM, Darrell Ball <dlu...@gmail.com>
>> wrote:
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Sun, Oct 2, 2016 at 11:27 AM, Han Zhou <zhou...@gmail.com>
>> wrote:
>> >> >> >>
>> >> >> >> On Sat, Oct 1, 2016 at 4:34 PM, Darrell Ball <dlu...@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
>>
>
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
