Open Stack

On Wed, 2020-02-26 at 19:35 -0800, Adam Peacock wrote:
> 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.
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-network.html
and impleneted in netwon https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/get-me-a-network.html

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