Open Stack

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@118

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.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/2ff20780/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Neutron trunks with Ironic.pdf
Type: application/pdf
Size: 66111 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161207/2ff20780/attachment.pdf>