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
