Hi Vinay,
On Tue, Feb 11, 2014 at 4:20 PM, Vinay Bannai <vban...@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 <aaronoro...@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 <vban...@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 <rkuk...@redhat.com>wrote: >>> >>>> On 02/09/2014 12:56 PM, Kyle Mestery wrote: >>>> > On Feb 6, 2014, at 5:24 PM, Vinay Bannai <vban...@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: vban...@gmail.com >>>> >> Google Voice: 415 938 7576 >>>> >> _______________________________________________ >>>> >> OpenStack-dev mailing list >>>> >> OpenStack-dev@lists.openstack.org >>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> > >>>> > >>>> > _______________________________________________ >>>> > OpenStack-dev mailing list >>>> > OpenStack-dev@lists.openstack.org >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> > >>>> >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> >>> >>> -- >>> Vinay Bannai >>> Email: vban...@gmail.com >>> Google Voice: 415 938 7576 >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Vinay Bannai > Email: vban...@gmail.com > Google Voice: 415 938 7576 > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
