[openstack-dev] [neutron] Vlan aware VMs or trunking
Vasyl Saienko
vsaienko at mirantis.com
Wed Dec 7 18:19:28 UTC 2016
On Wed, Dec 7, 2016 at 7:34 PM, Kevin Benton <kevin at benton.pub> wrote:
> >It work only when whole switch is aimed by single customer, it will not
> work when several customers sharing the same switch.
>
> Do you know what vendors have this limitation? I know the broadcom
> chipsets didn't prevent this (we allowed VLAN rewrites scoped to ports at
> Big Switch). If it's common to Cisco/Juniper then I guess we are stuck
> reflecting bad hardware in the API. :(
>
@Kevin
It looks that I was wrong, on the example I provided I expected to
configure VLAN mapping on Gig0/1 uplink. It will not work in this case, but
if configure VLAN mapping at ports where baremetal are plugged (i.e: Fa0/1
- 0/5) it should work :)
I definitely need more practice with VLAN mapping...
>
> On Wed, Dec 7, 2016 at 9:22 AM, Vasyl Saienko <vsaienko at mirantis.com>
> wrote:
>
>>
>>
>> On Wed, Dec 7, 2016 at 7:12 PM, Kevin Benton <kevin at benton.pub> wrote:
>>
>>>
>>>
>>> On Wed, Dec 7, 2016 at 8:47 AM, Vasyl Saienko <vsaienko at mirantis.com>
>>> wrote:
>>>
>>>> @Armando: IMO the spec [0] is not about enablement of Trunks and
>>>> baremetal. This spec is rather about trying to make user request with any
>>>> network configuration (number of requested NICs) to be able successfully
>>>> deployed on ANY ironic node (even when number of hardware interfaces is
>>>> less than number of requested attached networks to instance) by implicitly
>>>> creating neutron trunks on the fly.
>>>>
>>>> I have a concerns about it and left a comment [1]. The guaranteed
>>>> number of NICs on hardware server should be available to user via nova
>>>> flavor information. User should decide if he needs a trunk or not only by
>>>> his own, as his image may even not support trunking. I suggest that
>>>> creating trunks implicitly (w/o user knowledge) shouldn't happen.
>>>>
>>>> Current trunks implementation in Neutron will work just fine with
>>>> baremetal case with one small addition:
>>>>
>>>> 1. segmentation_type and segmentation_id should not be API mandatory
>>>> fields at least for the case when provider segmentation is VLAN.
>>>>
>>>> 2. User still should know what segmentation_id was picked to configure
>>>> it on Instance side. (Not sure if it is done automatically via network
>>>> metadata at the moment.). So it should be inherited from network
>>>> provider:segmentation_id and visible to the user.
>>>>
>>>>
>>>> @Kevin: Having VLAN mapping support on the switch will not solve
>>>> problem described in scenario 3 when multiple users pick the same
>>>> segmentation_id for different networks and their instances were spawned to
>>>> baremetal nodes on the same switch.
>>>>
>>>> I don’t see other option than to control uniqueness of segmentation_id
>>>> on Neutron side for baremetal case.
>>>>
>>>
>>> Well unless there is a limitation in the switch hardware, VLAN mapping
>>> is scoped to each individual port so users can pick the same local
>>> segmentation_id. The point of the feature on switches is for when you have
>>> customers that specify their own VLANs and you need to map them to service
>>> provider VLANs (i.e. what is happening here).
>>>
>>
>> It work only when whole switch is aimed by single customer, it will not
>> work when several customers sharing the same switch.
>>
>>
>>>
>>>
>>>>
>>>> Reference:
>>>>
>>>> [0] https://review.openstack.org/#/c/277853/
>>>> [1] https://review.openstack.org/#/c/277853/10/specs/approved/VL
>>>> AN-aware-baremetal-instances.rst at 35
>>>>
>>>> On Wed, Dec 7, 2016 at 6:14 PM, Kevin Benton <kevin at benton.pub> wrote:
>>>>
>>>>> Just to be clear, in this case the switches don't support VLAN
>>>>> translation (e.g. [1])? Because that also solves the problem you are
>>>>> running into. This is the preferable path for bare metal because it avoids
>>>>> exposing provider details to users and doesn't tie you to VLANs on the
>>>>> backend.
>>>>>
>>>>> 1. http://ipcisco.com/vlan-mapping-vlan-translation-%E2%80%93-part-2/
>>>>>
>>>>> On Wed, Dec 7, 2016 at 7:49 AM, Armando M. <armamig at gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> 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/v
>>>>>>> lan-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.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.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.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.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.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.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/87109cf4/attachment.html>
More information about the OpenStack-dev
mailing list