[Openstack-operators] Multiple vlan ranges on same physical interface [ml2]

George Shuklin george.shuklin at gmail.com
Sun May 10 00:12:57 UTC 2015


Yes, that's result.

My plan was to allow 'internal' networks in neutron (by tenants itself), 
but after some struggle we've decided to fallback to 'created by script 
during tenant bootstrapping'.

Unfortunately, neutron has no conception of 'default physical segment' 
for VLAN autoallocation for tenant networks (it just grabs first available).

On 05/09/2015 03:08 AM, Kevin Benton wrote:
> So if you don't let tenants allocate networks, then why do the VLAN 
> ranges in neutron matter? It can just be part of your net-create scripts.
>
>
> On Fri, May 8, 2015 at 9:35 AM, George Shuklin 
> <george.shuklin at gmail.com <mailto:george.shuklin at gmail.com>> wrote:
>
>     We've got a bunch of business logic above openstack. It's
>     allocating VLANs on-fly for external networks and connect pieces
>     outside neutron (configuring hardware router, etc).
>
>     Anyway, after some research we've decided to completely ditch idea
>     of 'tenant networks'. All networks are external and handled by our
>     software with administrative rights.
>
>     All networks for tenant are created during tenant bootstrap,
>     including local networks which are now looking funny 'external
>     local network without gateway'. By nailing every moving part in
>     'neutron net-create' we've got stable behaviour and kept
>     allocation database inside our software. That kills a huge part of
>     openstack idea, but at least it works straightforward and nice.
>
>     I really like to see all that been implemented in vendor plugins
>     for neutron, but average code and documentation quality for them
>     are below any usable level, so we implements hw configuration by
>     ourselves.
>
>
>     On 05/08/2015 09:15 AM, Kevin Benton wrote:
>>     If one set of VLANs is for external networks which are created by
>>     admins, why even specify network_vlan_ranges for that set?
>>
>>     For example, even if network_vlan_ranges is 'local:1000:4000',
>>     you can still successfully run the following as an admin:
>>     neutron net-create --provider:network_type=vlan
>>     --provider:physical_network=local --provider:segmentation_id=40
>>     myextnet --router:external
>>
>>     On Thu, May 7, 2015 at 7:32 AM, George Shuklin
>>     <george.shuklin at gmail.com <mailto:george.shuklin at gmail.com>> wrote:
>>
>>         Hello everyone.
>>
>>         Got a problem: we want to use same physical interface for
>>         external networks and virtual (tenant) networks. All inside
>>         vlans with different ranges.
>>
>>         My expected config was:
>>
>>         [ml2]
>>         type_drivers = vlan
>>         tenant_network_types = vlan
>>         [ml2_type_vlan]
>>         network_vlan_ranges = external:1:100,local:1000:4000
>>         [ovs]
>>         bridge_mappings = external:br-ex,local:br-ex
>>
>>         But it does not work:
>>
>>         ERROR neutron.plugins.openvswitch.agent.ovs_neutron_agent [-]
>>         Parsing bridge_mappings failed: Value br-ex in mapping:
>>         'gp:br-ex' not unique. Agent terminated!
>>
>>         I understand that I can cheat and manually configure bridge
>>         pile (br-ex and br-loc both plugged to br-real, which linked
>>         to physical interface), but it looks very fragile.
>>
>>         Is any nicer way to do this? And why ml2 (ovs plugin?) does
>>         not allow to use mapping from many networks to one bridge?
>>
>>         _______________________________________________
>>         OpenStack-operators mailing list
>>         OpenStack-operators at lists.openstack.org
>>         <mailto:OpenStack-operators at lists.openstack.org>
>>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>>
>>     -- 
>>     Kevin Benton
>
>
>     _______________________________________________
>     OpenStack-operators mailing list
>     OpenStack-operators at lists.openstack.org
>     <mailto:OpenStack-operators at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>
> -- 
> Kevin Benton

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150510/4ee3b1b7/attachment.html>


More information about the OpenStack-operators mailing list