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. <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. 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. > > > >> >> 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
