Open Stack

On Tue, Mar 10, 2015 at 10:38 PM, Gabriel Bezerra <gabrielb at lsd.ufcg.edu.br>
wrote:

> Em 10.03.2015 14:34, Gabriel Bezerra escreveu:
>
>  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.
>>
>
> Fixing my previous e-mail:
> I'd vote against such restriction, but throwing an error in case of
> creating a router between the subnets that overlap.

+1 to Gabriel's suggestion. Multiple routers and multiple subnets with
overlapping IPs is a perfectly valid scenario and is used in some
blueprints; for instance PLUMgrid plugin supports it. Throwing an error for
overlapping IPs on Router interfaces seems like the right approach.

>
>
>
>> 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.
>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150310/6d2a3acd/attachment.html>