This brings up something I'd like to discuss. We have a config option called "allow_overlapping_ips" which actually defaults to False. It has been suggested [1] that this should be removed from Neutron and I've just started playing around with ripping it out [2] to see what the consequences are.
A purely L3 routed network, like Calico, is a case where it is more complex to implement allowing overlapping ip addresses. If we deprecate and eventually remove allow_overlapping_ips, will this be a problem for Calico? Is the shared address space in Calico confined to a single flat network or do you already support tenant private networks with this technology? If I recall from previous discussions, I think that it only supports Neutron's flat network model in the current form, so I don't think it should be a problem. Am I correct? Please confirm. Carl [1] http://lists.openstack.org/pipermail/openstack-dev/2014-May/036336.html [2] https://review.openstack.org/#/c/179953/ On Fri, May 1, 2015 at 8:22 AM, Neil Jerram <neil.jer...@metaswitch.com> wrote: > Thanks for your reply, Kevin, and sorry for the delay in following up. > > On 21/04/15 09:40, Kevin Benton wrote: >> >> Is it compatible with overlapping IPs? i.e. Will it give two different >> VMs the same IP address if the reservations are setup that way? > > > No, not as I've described it below, and as we've implemented Calico so far. > Calico's first target is a shared address space without overlapping IPs, so > that we can handle everything within the default namespace. > > But we do also anticipate a future Calico release to support private address > spaces with overlapping IPs, while still routing all VM data rather than > bridging. That will need the private address TAP interfaces to go into a > separate namespace (per address space), and have their data routed there; > and we'd run a Dnsmasq in that namespace to provide that space's IP > addresses. > > Within each namespace - whether the default one or private ones - we'd still > use the other changes I've described below for how the DHCP agent creates > the ns-XXX interface and launches Dnsmasq. > > Does that make sense? Do you think that this kind of approach could be in > scope under the Neutron umbrella, as an alternative to bridging the TAP > interfaces? > > Thanks, > Neil > > >> On 16/04/15 15:12, Neil Jerram wrote: >> >> I have a Neutron DHCP agent patch whose purpose is to launch dnsmasq >> with options such that it works (=> provides DHCP service) for TAP >> interfaces that are _not_ bridged to the DHCP interface (ns-XXX). For >> the sake of being concrete, this involves: >> >> - creating the ns-XXX interface as a dummy, instead of as a veth pair >> >> - launching dnsmasq with --bind-dynamic --listen=ns-XXX --listen=tap* >> --bridge-interface=ns-XXX,tap* >> >> - not running in a separate namespace >> >> - running the DHCP agent on every compute host, instead of only on the >> network node >> >> - using the relevant subnet's gateway IP on the ns-XXX interface (on >> every host), instead of allocating a different IP for each ns-XXX >> interface. >> >> I proposed a spec for this in the Kilo cycle [1], but it didn't get >> enough traction, and I'm now wondering what to do with this >> work/function. Specifically, whether to look again at integrating it >> into Neutron during the Liberty cycle, or whether to maintain an >> independent DHCP agent for my project outside the upstream Neutron >> tree. >> I would very much appreciate any comments or advice on this. >> >> For answering that last question, I suspect the biggest factor is >> whether routed TAP interfaces - i.e. forms of networking >> implementation >> that rely on routing data between VMs instead of bridging it - is in >> scope for Neutron, at all. If it is, I understand that there could be >> a >> lot more detail to work on, such as how it meshes with other Neutron >> features such as DVR and the IPAM work, and that it might end up being >> quite different from the blueprint linked below. But it would be good >> to know whether this would ultimately be in scope and of interest for >> Neutron at all. >> >> Please do let me now what you think. >> >> Many thanks, >> Neil >> >> [1] https://blueprints.launchpad.net/neutron/+spec/dhcp-for-routed-ifs >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev