Openstack routed provider network

Miguel Lavalle miguel at mlavalle.com
Wed Jul 27 14:50:25 UTC 2022


Ignazio,

You might find the following two presentations useful to understand what
segments are and how they are used in routed networks:

https://www.openstack.org/videos/summits/austin-2016/mapping-real-networks-to-physical-networks-segments-and-logical-networks-in-neutron
https://www.openstack.org/videos/summits/barcelona-2016/scaling-up-openstack-networking-with-routed-networks

And to summarize what you will find in those presentations:

1) A segment is a single L2 broadcast domain, be it a vlan or a vxlan or
any other way to realize a L2 broadcast domain in the networking fabric.
2) A Neutron network can be created stitching together 1 or several
segments. If after putting several segments together in a Neutron network
they become a single L2 broadcast domain (i.e. they are stitched together
via switching) then you have a multi-segment Neutron network. However ....
3) If the segments in a Neutron network are stitched together with L3
routers, then you have a routed provider network. In such networks, each
segment is a separate L2 broadcast domain, which should provide higher
levels of scalability
4) To better understand the terminology, you may also find it useful to
understand the distinction between  "provider networks" and "tenant
networks". A provider network is one that was mapped explicitly at creation
by a cloud admin to specific segments, most likely to achieve certain
performance / scalability goals. A tenant network is one for which, at
creation, Neutron assigned automatically a segment

Best regards

Miguel

On Wed, Jul 27, 2022 at 3:01 AM Ignazio Cassano <ignaziocassano at gmail.com>
wrote:

> Hello, thanks for your reply.
> The segment id is the vlan id  (in your example 101) ?
> My understanding is that  some compute nodes in a rack are connected to a
> vlan, and other on another vlan.
> Then I can create a network (segmentation1) and scheduler put the vm on
> the compute node where vlan is present.
> So for users exists only segmentaion1 network and they do not know it is
> splitted in more vlans.
> Is it correct ?
> Ignazio
>
> Il giorno mer 27 lug 2022 alle ore 09:27 Lajos Katona <
> katonalala at gmail.com> ha scritto:
>
>> Hi,
>> I suppose you referenced this document:
>>
>> https://docs.openstack.org/neutron/latest/admin/config-routed-networks.html
>>
>> In Neutron terminology segments appear on different layers, on the API a
>> segment is a network type / seg. id / phys-net / net uuid tuple (see [1]).
>> What is interesting here that this segment has to be a representation on
>> the compute where l2-agent (ovs-agent) can know which segment is the one it
>> can bind ports.
>> That cfg option is in ml2_conf.ini, and bridge_mappings, where the
>> admin/deployer can state which bridge (like br-ex) is connected to which
>> provider network (out of Openstack's control).
>> So for example a sample config in ml_conf.ini like this:
>>
>> bridge_mappings = public:br-ex,physnet1:br0
>>
>> Means that on that compute VM ports can be bound which has a network
>> segment like this: ( network_type: vlan, physical_network: *physnet1*, segmentation_id:
>> 101, network_id: 1234-56..)
>> More computes can have the same bridge-physnet mapping, the deployer's
>> responsibility is to have these connected to the same switch, whatever.
>>
>> [1]:
>> https://docs.openstack.org/api-ref/network/v2/index.html?expanded=create-segment-detail#segments
>>
>> Ignazio Cassano <ignaziocassano at gmail.com> ezt írta (időpont: 2022. júl.
>> 26., K, 21:04):
>>
>>> Hello All, I am reading documentation about routed provider network.
>>> It reports: "
>>> Routed provider networks imply that compute nodes reside on different
>>> segments. "
>>>
>>> What does mean ?
>>> What is a segment it this case ?
>>> Thanks for helping me"
>>> Ignazio
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20220727/c8aa7d1e/attachment-0001.htm>


More information about the openstack-discuss mailing list