Lajos Katona katonalala at gmail.com
Fri Feb 7 08:22:12 UTC 2020


I assume you refer to this documentation (just to be sure that others have
the same base):

Based on that (and my limited knowledge of the usecases of this feature):
To avoid large l2 tenant networks and small tenant networks which the user
has to know and select,
routed provider nets "provide" the option to use a provider network
(characterized by a segment: physical network - segmentation type -
segmentation id)
and you can add more segments (as in the example for example with new VLAN
id, but on the same physnet on other compute) and add extra subnet range
for it
which is specific for that segment (i.e.: a group of computes).
With this the user will have 1 network to boot VMs on, but openstack
(neutron - nova - placement) will decide where to put the VM which segment
and subnet to use.

I mentioned placement: The feature should work in a way that based on
information provided by neutron (during segment & subnet creation)
placement knows
how many free IP addresses are available on a segment, and based on this
places VMs to hosts, that is not working as I know, see:
https://review.opendev.org/656885 & https://review.opendev.org/665155


Ignazio Cassano <ignaziocassano at gmail.com> ezt írta (időpont: 2020. febr.
6., Cs, 21:04):

> Hello,
> I am reading about openstack neutron routed provider networks.
> If I understood well, using segments I can create more subnets within the
> same provider net vlan id.
> Correct?
> In documentation seems I must use different physical network for each
> segment.
> I am using only one physical network ...in other words I created an
> openvswitch with a bridge (br-ex) with an interface on which I  receive all
> my vlans (trunk).
> Why must I use different physical net?
> Sorry, but my net skill is poor.
> Ignazio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200207/37146902/attachment.html>

More information about the openstack-discuss mailing list