>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. :( 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.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
