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

John Belamaric jbelamaric at infoblox.com
Wed Mar 11 22:48:26 UTC 2015


This has been settled and we're not moving forward with it for Kilo. I agree tenants are an administrative concept, not a networking one so using them for uniqueness doesn't really make sense.

In Liberty we are proposing a new grouping mechanism, as you call it, specifically for the purpose of defining uniqueness - address scopes. This would be owned by a tenant but could be shared across tenants. It's still in the early stages of definition though, and more discussion is needed but should probably wait until after Kilo is out!


From: Kevin Benton <blak111 at gmail.com<mailto:blak111 at gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Thursday, March 12, 2015 at 6:38 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant

My concern is that we are introducing new objects in Neutron that are scoped to a tenant and we don't have anything else like that right now. For example, I can create 100 3-tier topologies (router + 3 subnets/networks) with duplicated names, CIDRs, etc between all of them and it doesn't matter if I do it on 100 different tenants or all under the same tenant.

Put a different way, tenants don't mean anything in the Neutron data model. They are just a tag to use to enforce quotas, policies, and filters on incoming API requests. Uniqueness shouldn't come from 'x' + tenant_id.

It seems like what is being introduced here is going to fundamentally change that by forcing the creation of separate tenants to have overlapping IPs. I think the barrier should be very high to introduce anything that does that.

Can you elaborate why tenants are used for uniqueness for IPAM instead of having a separate grouping mechanism?

On Wed, Mar 11, 2015 at 3:24 PM, Ihar Hrachyshka <ihrachys at redhat.com<mailto:ihrachys at redhat.com>> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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
>> 10.0.0.0/24<http://10.0.0.0/24> 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.

/Ihar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVAMCPAAoJEC5aWaUY1u57d/cH/A+nAuLrNaCPumjlOPJP90c3
4oSh0ioxEQw2uBRx1mWvcQle0M1U4Psy5CqIjeHgDhRlCNKB2gAYvm7/lCwZoCw7
pxLUerfZPFguNKYCUly1MYyo0gorycFgemoHKEFwHboDJfPdGYxdhW8HuemCClOG
ZSeRzjO2rGaHU8XT+QWgI14UBiAu+XlQHy3UwUKEaffXOnja7noCU99/6d7+6TgF
5/RdFhpfn6pcRvLboiquo57w6N3q7moORgrGSMuP8cnMMTxo9/TLie+vMXmLPobB
YmeG1ar1q0ouGKb6ZG7KokUyl6CdpgowZ6bqetPELjBLIO+uhcsJ6g9NvRl4T9o=
=WQ3Q
-----END PGP SIGNATURE-----

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150311/d7663fbe/attachment.html>


More information about the OpenStack-dev mailing list