Open Stack

I believe it would need to be like:

 network_vlan_ranges = physnet1:100:300, phynet2:100:300, phynet3:100:300

Additional comments inline:

On Mon, Feb 10, 2014 at 8:49 PM, Vinay Bannai <vbannai at gmail.com> wrote:

> Bob and Kyle,
>
> Thanks for your review.
> We looked at this option and it seems it might meet our needs. Here is
> what we intend to do:
>
> Let's say we have three racks (each rack supports three VLANs - 100, 200
> and 300).
> We create the following config file for the neutron server
>
>
>
>
> tenant_network_type = vlan
>  network_vlan_ranges = physnet1:100:300
>  network_vlan_ranges = phynet2:100:300
>  network_vlan_ranges = phynet3:100:300
>  integration_bridge = br-int
>  bridge_mappings = physnet1:br-eth1, physnet2:br-eth1, physnet3:br-eth1
> Is this what you meant?
>
> Vinay
>
>
> On Sun, Feb 9, 2014 at 6:03 PM, Robert Kukura <rkukura at redhat.com> wrote:
>
>> On 02/09/2014 12:56 PM, Kyle Mestery wrote:
>> > On Feb 6, 2014, at 5:24 PM, Vinay Bannai <vbannai at gmail.com> wrote:
>> >
>> >> Hello Folks,
>> >>
>> >> We are running into a situation where we are not able to create
>> multiple provider networks with the same VLAN id. We would like to propose
>> a solution to remove this restriction through a configuration option. This
>> approach would not conflict with the present behavior where it is not
>> possible to create multiple provider networks with the same VLAN id.
>> >>
>> >> The changes should be minimal and would like to propose it for the
>> next summit. The use case for this need is documented in the blueprint
>> specification.
>> >> Any feedback or comments are welcome.
>> >>
>> >>
>> https://blueprints.launchpad.net/neutron/+spec/duplicate-providernet-vlans
>> >>
>> > Hi Vinay:
>> >
>> > This problem seems straightforward enough, though currently you are
>> right
>> > in that we don't allow multiple Neutron networks to have the same
>> segmentation
>> > ID. I've added myself as approver for this BP and look forward to
>> further
>> > discussions of this before and during the upcoming Summit!
>>
>>
I kind of feel like allowing a vlan to span multiple networks is kind of
wonky. I feel like a better abstraction would be if we had better access
control over shared networks between tenants. This way we could explicitly
allow two tenants to share a network. Is this the problem you are trying to
solve though doing it with the same vlan?  How do you plan on enforcing
that mac_addresses are unique on the same physical network?

Multiple networks with network_type of 'vlan' are already allowed to
>> have the same segmentation ID with the ml2, openvswitch, or linuxbridge
>> plugins - the networks just need to have different physical_network
>> names.
>
>
This is the same for the NSX plugin as well.


> If they have the same network_type, physical_network, and
>> segmentation_id, they are the same network. What else would distinguish
>> them from each other?
>>
>> Could your use case be addressed by simply using different
>> physical_network names for each rack? This would provide independent
>> spaces of segmentation_ids for each.
>>
>> -Bob
>>
>> >
>> > Thanks!
>> > Kyle
>> >
>> >> Thanks
>> >> --
>> >> Vinay Bannai
>> >> Email: vbannai at gmail.com
>> >> Google Voice: 415 938 7576
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Vinay Bannai
> Email: vbannai at gmail.com
> Google Voice: 415 938 7576
>
> _______________________________________________
> 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/20140211/846a4310/attachment-0001.html>