Open Stack

Gabriel Bezerra <gabrielb at lsd.ufcg.edu.br> wrote on 03/10/2015 12:34:30 PM:

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

While I'd personally like to see this be restricted (Carl's position), I
know
of at least one existence proof where management applications are doing
precisely what Gabriel is suggesting - reusing the same address range to
minimize the configuration differences.

Ryan Moats
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150310/8a507027/attachment.html>