Open Stack

On 7 December 2016 at 04:02, Vasyl Saienko <vsaienko at mirantis.com> wrote:

> Armando, Kevin,
>
> Thanks for your comments.
>
> To be more clear we are trying to use neutron trunks implementation with
> baremetal servers (Ironic). Baremetal servers are plugged to Tor (Top of
> the Rack) switch. User images are spawned directly onto hardware.
>
Ironic uses Neutron ML2 drivers to plug baremetal servers to Neutron
> networks (it looks like changing vlan on the port to segmentation_id from
> Neutron network, scenario 1 in the attachment). Ironic works with VLAN
> segmentation only for now, but some vendors ML2 like arista allows to use
> VXLAN (in this case VXLAN to VLAN mapping is created on the switch.).
> Different users may have baremetal servers connected to the same ToR switch.
>
> By trying to apply current neutron trunking model leads to the following
> errors:
>
> *Scenario 2: single user scenario, create VMs with trunk and non-trunk
> ports.*
>
>    - User create two networks:
>    net-1: (provider:segmentation_id: 100)
>    net-2: (provider:segmentation_id: 101)
>
>    - User create 1 trunk port
>    port0 - parent port in net-1
>    port1 - subport in net-2 and define user segmentation_id: 300
>
>    - User boot VMs:
>    BM1: with trunk (connected to ToR Fa0/1)
>    BM4: in net-2 (connected to ToR Fa0/4)
>
>    - VLAN on the switch are configured as follow:
>    Fa0/1 - trunk, native 100, allowed vlan 300
>    Fa0/4 - access vlan 101
>
> *Problem:* BM1 has no access BM4 on net-2
>
>
> *Scenario 3: multiple user scenario, create VMs with trunk.*
>
>    - User1 create two networks:
>    net-1: (provider:segmentation_id: 100)
>    net-2: (provider:segmentation_id: 101)
>
>    - User2 create two networks:
>    net-3: (provider:segmentation_id: 200)
>    net-4: (provider:segmentation_id: 201)
>
>    - User1 create 1 trunk port
>    port0 - parent port in net-1
>    port1 - subport in net-2 and define user segmentation_id: 300
>
>    - User2 create 1 trunk port
>    port0 - parent port in net-3
>    port1 - subport in net-4 and define user segmentation_id: 300
>
>    - User1 boot VM:
>    BM1: with trunk (connected to ToR Fa0/1)
>
>    - User2 boot VM:
>    BM4: with trunk (connected to ToR Fa0/4)
>
>    - VLAN on the switch are configured as follow:
>    Fa0/1 - trunk, native 100, allowed vlan 300
>    Fa0/4 - trunk, native 200, allowed vlan 300
>
> *Problem:* User1 BM1 has access to User2 BM4 on net-2, Conflict in VLAN
> mapping provider vlan 101 should be mapped to user vlan 300, and provider
> vlan 201 should be also mapped to vlan 300
>
>
> Making segmentation_id on trunk subport optional and inheriting it from
> port network segmentation_id solves such problems.
> According to original spec both segmentation_type and segmentation_id are
> optional [0].
>
> Does Neutron/Nova place information about user's VLAN onto instance via
> network metadata?
>
> Reference:
> [0] https://review.openstack.org/#/c/308521/1/specs/newton/
> vlan-aware-vms.rst at 118
>

Ah, I was actually going to add the following:

Whether segmentation type and segmentation ID are mandatory or not depends
on the driver in charge of the trunk. This is because for use cases like
Ironic, as you wonder, these details may be inferred by the underlying
network, as you point out.

However, we have not tackled the Ironic use case just yet, for the main
reason that ironic spec [1] is still WIP. So as far as newton is concerned,
Ironic is not on the list of supported use cases for vlan-aware-vms, yet
[2]. The reason why we have not tackled it yet is that there's the
'nuisance' in that a specific driver is known to the trunk plugin only at
the time a parent port is bound and we hadn't come up with a clean and
elegant way to developer a validator that took into account of it. I'll
file a bug report to make sure this won't fall through the cracks. It'll be
tagged with 'trunk'.

[1] https://review.openstack.org/#/c/277853/
[2]
https://github.com/openstack/neutron/blob/master/neutron/services/trunk/rules.py#L215

Cheers,
Armando


>
> Thanks in advance,
> Vasyl Saienko
>
> On Tue, Dec 6, 2016 at 7:08 PM, Armando M. <armamig at gmail.com> wrote:
>
>>
>>
>> On 6 December 2016 at 08:49, Vasyl Saienko <vsaienko at mirantis.com> wrote:
>>
>>> Hello Neutron Community,
>>>
>>>
>>> I've found that nice feature vlan-aware-vms was implemented in Newton
>>> [0].
>>> However the usage of this feature for regular users is impossible,
>>> unless I'm missing something.
>>>
>>> As I understood correctly it should work in the following way:
>>>
>>>    1. It is possible to group neutron ports to trunks.
>>>    2. When trunk is created parent port should be defined:
>>>    Only one port can be parent.
>>>    segmentation of parent port is set as native or untagged vlan on the
>>>    trunk.
>>>    3. Other ports may be added as subports to existing trunk.
>>>    When subport is added to trunk *segmentation_type* and *segmentation_id
>>>    *should be specified.
>>>    segmentation_id of subport is set as allowed vlan on the trunk
>>>
>>> Non-admin user do not know anything about *segmentation_type* and
>>> *segmentation_id.*
>>>
>>
>> Segmentation type and ID are used to multiplex/demultiplex traffic in/out
>> of the guest associated to a particular trunk. Aside the fact that the only
>> supported type is VLAN at the moment (if ever), the IDs are user provided
>> to uniquely identify the traffic coming in/out of the trunked networks so
>> that it can reach the appropriate vlan interface within the guest. The
>> documentation [1] is still in flight, but it clarifies this point.
>>
>> HTH
>> Armando
>>
>> [1] https://review.openstack.org/#/c/361776
>>
>>
>>> So it is strange that those fields are mandatory when subport is added
>>> to trunk. Furthermore they may conflict with port's network segmentation_id
>>> and type. Why we can't inherit segmentation_type and segmentation_id from
>>> network settings of subport?
>>>
>>> References:
>>> [0] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
>>> [1] https://review.openstack.org/#/c/361776/15/doc/networking-gu
>>> ide/source/config-trunking.rst
>>> [2] https://etherpad.openstack.org/p/trunk-api-dump-newton
>>>
>>> Thanks in advance,
>>> Vasyl Saienko
>>>
>>> ____________________________________________________________
>>> ______________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161207/ae276925/attachment.html>