Re: [openstack-dev] [Neutron] Support for multiple provider networks with same VLAN segmentation id
Hi Vinay, On Tue, Feb 11, 2014 at 4:20 PM, Vinay Bannai 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 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 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 wrote: >>> On 02/09/2014 12:56 PM, Kyle Mestery wrote: > On Feb 6, 2014, at 5:24 PM, Vinay Bannai 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 >> _
Re: [openstack-dev] [Neutron] Support for multiple provider networks with same VLAN segmentation id
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 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 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 wrote: >> >>> On 02/09/2014 12:56 PM, Kyle Mestery wrote: >>> > On Feb 6, 2014, at 5:24 PM, Vinay Bannai 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://lis
Re: [openstack-dev] [Neutron] Support for multiple provider networks with same VLAN segmentation id
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 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 wrote: > >> On 02/09/2014 12:56 PM, Kyle Mestery wrote: >> > On Feb 6, 2014, at 5:24 PM, Vinay Bannai 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
Re: [openstack-dev] [Neutron] Support for multiple provider networks with same VLAN segmentation id
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 wrote: > On 02/09/2014 12:56 PM, Kyle Mestery wrote: > > On Feb 6, 2014, at 5:24 PM, Vinay Bannai 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! > > 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. 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
Re: [openstack-dev] [Neutron] Support for multiple provider networks with same VLAN segmentation id
On 02/09/2014 12:56 PM, Kyle Mestery wrote: > On Feb 6, 2014, at 5:24 PM, Vinay Bannai 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! 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. 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
Re: [openstack-dev] [Neutron] Support for multiple provider networks with same VLAN segmentation id
On Feb 6, 2014, at 5:24 PM, Vinay Bannai 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! 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