Open Stack

Henry, thank you very much for your reply.  To try to tie together our
discussion here with what's in the launchpad bug report I opened
(https://bugs.launchpad.net/neutron/+bug/1269926), here is the method used
to create the network.  I'm creating the network via a UI, which does a
rest api POST to https://<ip>/powervc/openstack/network/v2.0//networks with
the following payload:

name: "test4094"
provider:network_type: "vlan"
provider:physical_network: "default"
provider:segmentation_id: 4094
Per the documentation, I assume the tenant_id is obtained via keystone.

Also interesting, I see this in /var/log/neutron/server.log:

2014-01-17 17:43:05.688 62718 DEBUG neutron.plugins.ml2.drivers.type_vlan
[req-484c7ddd-7f83-443b-9427-f7ac327dd99d 0
26e92528a0bc4d84ac0777b2d2b93a83] NT-E59BA3F Reserving specific vlan 4094
on physical network default outside pool
reserve_provider_segment /usr/lib/python2.6/site-packages/neutron/plugins/ml2/drivers/type_vlan.py:212

Which indicates OpenStack realizes this is outside the vlan range yet still
allowed it.  Lending even more credence to the fact that I'm incorrect in
my thinking that this should have been prevented.  Further information to
help understand why this is not being enforced would be greatly
appreciated.

Thanks!

- Paul

Henry Gessau <gessau at cisco.com> wrote on 01/16/2014 03:31:44 PM:

> Date: Thu, 16 Jan 2014 16:31:44 -0500
> From: Henry Gessau <gessau at cisco.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>    <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [neutron] ML2 vlan type driver does not
>    honor network_vlan_ranges
> Message-ID: <52D84FC0.8020100 at cisco.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> network_vlan_ranges is a 'pool' of vlans from which to pick a vlans for
> tenant networks. Provider networks are not confined to this pool. In
fact, I
> believe it is a more common use-case that provider vlans are outside the
> pool so that they do not conflict with tenant vlan allocation.
>
> -- Henry
>
> On Thu, Jan 16, at 3:45 pm, Paul Ward <wpward at us.ibm.com> wrote:
>
> > In testing some new function I've written, I've unsurfaced the problem
that
> > the ML2 vlan type driver does not enforce the vlan range specified in
the
> > network_vlan_ranges option in ml2_conf.ini file.  It is properly
enforcing
> > the physical network name, and even checking to be sure the
segmentation_id
> > is valid in the sense that it's not outside the range of ALL validvlan
ids.
> >  But it does not actually enforce that segmentation_id is within the
vlan
> > range specified for the given physical network in network_vlan_ranges.
> >
> > The fix I propose is simple.  Add the following check to
> > /neutron/plugins/ml2/drivers/type_vlan.py
> > (TypeVlanDriver.validate_provider_segment()):
> >
> >         range_min, range_max = self.network_vlan_ranges
[physical_network][0]
> >         if segmentation_id not in range(range_min, range_max):
> >             msg = (_("segmentation_id out of range (%(min)s through "
> >                      "%(max)s)") %
> >                    {'min': range_min,
> >                     'max': range_max})
> >             raise exc.InvalidInput(error_message=msg)
> >
> > This would go near line 182 in
> > https://github.com/openstack/neutron/blob/master/neutron/plugins/
> ml2/drivers/type_vlan.py.
> >
> > One question I have is whether self.network_vlan_ranges
[physical_network]
> > could actually be an empty list rather than a tuple representing the
vlan
> > range.  I believe that should always exist, but the documentation is
not
> > clear on this.  For reference, the corresponding line in
> ml2_conf.ini is this:
> >
> > [ml2_type_vlan]
> > network_vlan_ranges = default:1:4093
> >
> > Thanks in advance to any that choose to provide some insight here!
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > 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/20140117/7ae7ea7c/attachment.html>