Open Stack

One way to look at the VLANs is that it identifies a security zone that
meets some regulatory compliance standards. The VLANs on each rack are
separated from other VLANs by using VRF. Tenants in our case map to
applications. So each application is served by a VIP with a pool of VMs. So
all applications needing regulatory compliance would map to this VLAN. Make
sense?

As far your question about keeping mac_addresses unique, isn't that
achieved by the fact that each VM will have a unique mac since it is the
same control plane allocating the mac address? Or did I miss something??

Vinay


On Tue, Feb 11, 2014 at 12:32 PM, Aaron Rosen <aaronorosen at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140211/5a6e89a6/attachment.html>