[openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant
blak111 at gmail.com
Wed Mar 11 22:38:22 UTC 2015
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
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>
> -----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 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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> -----END PGP SIGNATURE-----
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev