Open Stack

Hi Vinay,


On Tue, Feb 11, 2014 at 4:20 PM, Vinay Bannai <vbannai at gmail.com> wrote:

> 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?
>
>
Yes, I understand your desire to do this though I think that "networks"
should identify a security zone and not a "vlan".


> 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??
>

If I understand correctly what you want to do is to be able to create two
network sharing the same vlan (i.e):

neutron net-create net1 --provider:network_type=vlan
--provider:segmentation_id=1
neutron net-create net2 --provider:network_type=vlan
--provider:segmentation_id=1

in this case the mac_address uniqueness is not preserved as neutron
enforces those per networks and doesn't look at the segmentation_id part at
all.

It seems to me that you want something that allows you to share a network
between specific tenants only? I understand that sharing the same vlan
between tenants does accomplish this but it would be better if we were able
to do this type of thing regardless of the network_type.


> 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
>
> _______________________________________________
> 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/20140212/cb1ddf0d/attachment.html>