On 2020-02-26 13:26:43 -0800 (-0800), Dan Sneddon wrote: [...]

That has never been supported. It is not feasible to have two VMs on the same network+subnet that have the same IP, even if they are owned by different tenants. That isn't a Neutron limitation, that's a limitation of IP-over-Ethernet that applies to all networks.

Think of the non-virtualized equivalent, if you had a physical network subnet with two computers using the same IP address there would be a conflict, even if one computer was owned by Alice and the other computer was owned by Bob. There is no way to make that work in a virtualized cloud environment unless the two tenants are using different network subnets.

It's probably useful to level-set on terminology, since not all these same words are used to mean the same things in different contexts. From Neutron's perspective "network" is your OSI layer 2 broadcast domain, and "subnet" is your OSI layer 3 addressing. Obviously to reuse the same layer 3 (IP) addresses on different systems you need them to reside on separate layer 2 (Ethernet) networks and have independent routing, most likely with some layer 3 address translation in place if they are ever expected to communicate with one another. As Dan points out, though, this has nothing to do with multi-tenancy and everything to do with the fundamentals rules of network engineering. -- Jeremy Stanley

What I'm referring to here are two separate tenants in the same region - each with their own unique Layer 2 broadcast domain but sharing the same subnet definition - with DHCP requiring the use of namespaces and ... the other element escapes me. But subnets don't necessarily presume Layer 3. not subnets are specifcally how we model l3 adress ranges. they dont assume ipv4 or ipv6 at least not any more. also network in neuton generally do model the l2 broadcast domain however if you are using an l3 network backend like calico a network models a set of network segments where each segment is a broadcast domain. Routing/switching between subnets yes, the use of a subnet definition is not.

On Wed, 2020-02-26 at 19:35 -0800, Adam Peacock wrote: the use of subnet definitions has always been required if you are using neuton as your ipam service. you cannoth create a port and set an fix ip on the port without fort addign the port to a network and a subnet, even in the provider routing case with neutron.

This used to be supported as far back as the Icehouse release, just not clear when the support for this configuration was changed or removed.

can you provide the exact set of command you used to create this configuration. i have worked on openstack since havana and even quantum required you to define subnets. is it possible you are thinking of nova networks? by the way there is a convince feature for those that come form a nova networks world to automate this call "get me a network" it was orginaly porposed in mitaka https://specs.openstack.org/openstack/neutron-specs/specs/mitaka/get-me-a-ne... and impleneted in netwon https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/ge... the docs are here https://docs.openstack.org/neutron/train/admin/config-auto-allocation.html basicaly there are 3 steps as an operator you do "openstack network set public --default" to setup a default netwrok which will be used to attach a neutorn router too. you then create a default subnet pool that will be used to allcoate subnets to auto created networks openstack subnet pool create --share --default \ --pool-prefix 192.0.2.0/24 --default-prefix-length 26 \ shared-default and the a new tenant just does "openstack network auto allocated topology create --or-show" this will create a router, a netwrok and allocate a subnet to the network then attach teh reouter to the default network as the upstream network and the newly create network/subnet.

//adam

/a/dam,

*Adam Peacock*

Principal Architect Office: +1-916-794-5706

On Wed, Feb 26, 2020 at 2:13 PM Jeremy Stanley <fungi@yuggoth.org> wrote:

...

On 2020-02-26 13:26:43 -0800 (-0800), Dan Sneddon wrote: [...]

...

That has never been supported. It is not feasible to have two VMs on the same network+subnet that have the same IP, even if they are owned by different tenants. That isn't a Neutron limitation, that's a limitation

of

...

IP-over-Ethernet that applies to all networks.

Think of the non-virtualized equivalent, if you had a physical network subnet with two computers using the same IP address there would be a conflict, even if one computer was owned by Alice and the other computer was owned by Bob. There is no way to make that work in a virtualized

cloud

...

environment unless the two tenants are using different network subnets.

It's probably useful to level-set on terminology, since not all these same words are used to mean the same things in different contexts. From Neutron's perspective "network" is your OSI layer 2 broadcast domain, and "subnet" is your OSI layer 3 addressing. Obviously to reuse the same layer 3 (IP) addresses on different systems you need them to reside on separate layer 2 (Ethernet) networks and have independent routing, most likely with some layer 3 address translation in place if they are ever expected to communicate with one another.

As Dan points out, though, this has nothing to do with multi-tenancy and everything to do with the fundamentals rules of network engineering. -- Jeremy Stanley