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
