On Tue, Mar 10, 2015 at 10:38 PM, Gabriel Bezerra <gabri...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
