On Tue, Oct 4, 2016 at 5:33 PM, Mickey Spiegel <mickeys....@gmail.com> wrote:
> > > On Tue, Oct 4, 2016 at 4:53 PM, Darrell Ball <dlu...@gmail.com> wrote: > >> >> >> On Tue, Oct 4, 2016 at 3:48 PM, Mickey Spiegel <mickeys....@gmail.com> >> wrote: >> >>> On Mon, Oct 3, 2016 at 2:21 PM, Darrell Ball <dlu...@gmail.com> wrote: >>> >> > <snip> > > >> >>>> 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. >>>> >>> >>> I don't think this is a layering violation. You are objecting to an ARP >>> response >>> being generated by the switch on a port far away from the actual >>> destination >>> port. >>> Why is it so different whether the endpoint is a router or a VIF? >>> Both routers and VIFs can and do generate their own ARP responses, but >>> that does not rule out the optimization that responds to ARPs immediately >>> at the source switch port. >>> >>> >> >> I don't think we are going to agree on this one. >> Here we have a case where a logical switch is responding to arp requests >> on behalf >> of the logical router. Meaning these datapaths are not independent. >> >> We also have both logical switch ports and logical router ports sharing >> the same MAC >> and IP addresses. This apparently is what is done in Openstack. >> We have no test case where we really test this, as usual. >> Maybe you can add one. >> > > I am not following this comment. Of course logical switch ports and > logical router ports share MAC addresses. They have to, or packets > with the destination MAC equal to the router MAC will never reach > the logical router port from the logical switch. > > There was a choice in the modeling to specify addresses explicitly > on logical switch ports of type "router", rather than deriving them > from the corresponding logical router port. This puts an obligation > on the user to specify addresses on logical switch ports and the > corresponding logical router ports in ways that make sense. If this > is not configured correctly, then packets won't reach the logical > router port and the logical router port's MAC address will effectively > be unused. > I think you got the point - presumably one should inherit from the other. > > <snip> > > 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. >>>> >>>> If there are cases where an IP address can appear on the same network >>> with different MAC addresses, then you have a problem. We would need >>> to know more about this use case. >>> >>> Note that you pretty much do have a knob already to control this >>> behavior. >>> If the addresses specified on the switch's "router" type port are only >>> ethernet addresses, then the switch will not generate any ARP replies. >>> If the addresses specified on the switch's "router" type port include >>> both >>> ethernet and IP addresses, then the switch will generate ARP replies for >>> each specified ethernet/IP address combination. >>> >> >> Yeah, we can assign the same mac and ip to both logical switch and >> logical router ports. >> That is not what I mean about exposing the ability properly or modularity >> of datapaths. >> > > The MAC addresses have to align or it does not work. From a quick scan of > the code, > it looks like the IP addresses on logical switch ports are only used for > IPAM, DHCP, > and the logical switch ARP responder. At least at first glance, it does > not seem to make > sense to specify an IP address on the logical switch "router" port that is > not present on > the logical router itself. > An IP address explicitly configured/exposed on a logical switch port rather than just a logical router port is strange. A hidden implementation inheritance for this part would have been more palatable. > Whether all IP addresses on the logical router port should be > specified on the logical switch "router" port, that depends on the > implications with > respect to IPAM, DHCP, and the logical switch ARP responder. > >> >> The logical switch arp responder will make the logical router arp >> responder unused, as well. >> > > For ARP from a switch port inside OVN, yes. For ARP from localnet or VTEP, > the > logical router ARP responder is necessary. > >> >> What is mean by configuration knob is the logical router datapath code >> being >> the master of its own arp responder including early usage and making that >> transparent. >> Meaning, the proxying action in code is initiated from the logical router >> datapath under the >> control of an external knob >> That is not the case today. >> >> As I mentioned above, the logical router is not master of all relevant > knobs > today, in particular requiring corresponding logical switch "router" port > addresses > to be configured in a way that matches the logical router configuration. I > wonder > how important it is to address this knob in particular. > Hence, my earlier comment. > >> >> >>> >>> The only other place where it looks like a switch port IP address is used >>> is for IPAM and DCHP. I did not look into this in any more detail, so I >>> am >>> not sure of all the implications of leaving out the IP addresses from the >>> switch "router" type port. >>> >> > <snip> > > Most of the documentation patch looks good, modulo resolution of skipping > the > ARP responder for "router" ports. > > Mickey > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
