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.
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 applicat
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 n
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
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 restr
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
