[openstack-dev] [neutron] Vlan aware VMs or trunking
kevin at benton.pub
Tue Dec 6 17:01:09 UTC 2016
The segmentation type of the trunk (how the VM attached to the parent port
sees the traffic) has nothing to do with the provider segmentation details
(how the traffic will be encapsulated when it leaves the compute node).
You're right that a normal user won't know the latter details, but they
don't need to. The user specifies how they want traffic from arbitrary
networks encapsulated into their VM. So they can say they want netA on vlan
100, netB on vlan 200, and that's what the VM will see - even if netA is a
GRE network and netB is a vlan network on vlan 3000.
On Dec 6, 2016 08:51, "Vasyl Saienko" <vsaienko at mirantis.com> wrote:
> Hello Neutron Community,
> I've found that nice feature vlan-aware-vms was implemented in Newton .
> 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
> 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.* 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?
>  https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
>  https://review.openstack.org/#/c/361776/15/doc/networking-
>  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:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev