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