[openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant

Ihar Hrachyshka ihrachys at redhat.com
Wed Mar 11 22:24:15 UTC 2015

Hash: SHA1

On 03/10/2015 06:34 PM, Gabriel Bezerra wrote:
> Em 10.03.2015 14:24, Carl Baldwin escreveu:
>> Neutron currently does not enforce the uniqueness, or
>> non-overlap, of subnet cidrs within the address scope for a
>> single tenant.  For example, if a tenant chooses to use
>> on more than one subnet, he or she is free to do so.
>> Problems will arise when trying to connect a router between these
>> subnets but that is left up to the tenant to work out.
>> In the current IPAM rework, we had decided to allow this overlap
>> in the reference implementation for backward compatibility.
>> However, we've hit a snag.  It would be convenient to use the
>> subnet cidr as the handle with which to refer to a previously
>> allocated subnet when talking to IPAM.  If overlap is allowed,
>> this is not possible and we need to come up with another
>> identifier such as Neutron's subnet_id or another unique IPAM
>> specific ID.  It could be a burden on an external IPAM system --
>> which does not allow overlap -- to work with a completely
>> separate identifier for a subnet.
>> I do not know of anyone using this capability (or mis-feature)
>> of Neutron.  I would hope that tenants are aware of the issues
>> with trying to route between subnets with overlapping address
>> spaces and would avoid it.  Is this potential overlap something
>> that we should really be worried about?  Could we just add the
>> assumption that subnets do not overlap within a tenant's scope?
>> An important thing to note is that this topic is different than 
>> allowing overlap of cidrs between tenants.  Neutron will continue
>> to allow overlap of addresses between tenants and support the
>> isolation of these address spaces.  The IPAM rework will support
>> this.
>> Carl Baldwin
> I'd vote for allowing against such restriction, but throwing an
> error in case of creating a router between the subnets.
> I can imagine a tenant running multiple instances of an
> application, each one with its own network that uses the same
> address range, to minimize configuration differences between them.

I agree with Gabriel on the matter. There is nothing inherently wrong
about a tenant running multiple isolated network setups that use
overlapping addresses (as there is nothing wrong about multiple
tenants doing the same).

There seems to be a value in disallowing overlapping subnets attached
to the same router though.

All in all, there seems to be no need to limit neutron API just
because most external IPAM implementation do not seem to care about
supporting the use case.

It's also an issue that the change proposed is backwards incompatible.

Version: GnuPG v1


More information about the OpenStack-dev mailing list