On Wed, Dec 7, 2016 at 7:34 PM, Kevin Benton <ke...@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 <vsaie...@mirantis.com> > wrote: > >> >> >> On Wed, Dec 7, 2016 at 7:12 PM, Kevin Benton <ke...@benton.pub> wrote: >> >>> >>> >>> On Wed, Dec 7, 2016 at 8:47 AM, Vasyl Saienko <vsaie...@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@35 >>>> >>>> On Wed, Dec 7, 2016 at 6:14 PM, Kevin Benton <ke...@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. <arma...@gmail.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 7 December 2016 at 04:02, Vasyl Saienko <vsaie...@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@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. <arma...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 6 December 2016 at 08:49, Vasyl Saienko <vsaie...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
