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,reg15=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:

1) for ARP requests to IPs of non-gateway logical router ports, flooding
should be suppressed and ARP responder on LS should work;
2) for ARP requests to IPs of gateway router ports, it is still better to
be suppressed, if possible.

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. The example you gave is not
related to ARP responder. 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.

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.

Thanks,
Han
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to