Logical Networks (Part IV) – PVLAN Isolation

First published on TECHNET on Jun 04, 2013

In this blog, we continue our review of tenant isolation by looking at the implications of PVLANs on your logical network design – we will look at Network Virtualization and complete our review of Logical Networks in the next post. We Look forward to your feedback and comments.

Nigel Cain & Damian Flynn

Introduction

In VMM 2012 SP1 you can isolate VM Networks using either traditional VLAN/PVLANS or, if you are using Windows Server 2012 as your host operating system, you can choose to implement Network Virtualization . The latter option addressing the scale limitations associated with a traditional VLANs solution as well as allowing tenants to “bring their own network” or otherwise extend their network into your environment. The diagram at the link below shows each of these options and acts as a reference for the detailed discussion that follows.

http://www.microsoft.com/en-us/download/details.aspx?id=37137

In Part III – Network Isolation , we covered how to configure your Logical Network for “No Isolation” in cases where you do not need to separate workloads and what you should do / how you should design your logical network solution when you want to use traditional VLANS. In this post, we focus our attention on isolation using PVLANs.

PVLAN Isolation

Private Virtual LANs (PVLANS) are often used by Service Providers (Hosters) to work around the scale limitations of VLANS that we discussed in Part III. They essentially allow network administrators to divide a VLAN into a number of separate and isolated sub-networks which can then be allocated to individual customers (tenants). PVLANs share the IP subnet that was allocated to the parent VLAN, as you might expect, but, from a security perspective, although hosts connected to different PVLANs still belong to the same IP subnet, they require a router to communicate with each other and with resources on any other network.

A PVLAN consists of a Primary and Secondary VLAN pair - each machine that is part of a PVLAN pair can be configured in one of three modes as shown below. In Promiscuous mode, hosts are on the primary VLAN and are able to communicate directly with resources on the primary VLAN and also the secondary VLAN. In a Community mode, the secondary VLAN represents a community. Direct communication is permitted only with hosts in the same community and those that are connected to the Primary PVLAN in promiscuous mode. Isolated PVLANs are pretty much as described, in that direct communication is permitted only with promiscuous resources that exist in the Primary PVLAN.

SC VMM 2012 SP1 only supports isolated mode (as described above) and has no concept of primary (promiscuous) or community modes. What this means in practice is that a Virtual Machine connected to a PVLAN in this release is completely isolated from any other resources on the network. The only device it can directly communicate with is the default IP gateway. While this may feel like a severe limitation, there are a number of scenarios which work quite well in this configuration - the most common example of which is Front End Web Servers. In this specific scenario, all of the web servers in a web farm are placed on a single network subnet but are otherwise completely isolated from each other, PVLANs in this context helping to simplify management and improve overall security.

Note: Similar functionality to community mode can be achieved by adding second network adapter to each isolated virtual machine and connecting this adapter to a VM Network on which network virtualization has been enabled and to which (all) of the other “community” resources are also connected.

Returning to Logical Network design, you should create a single Logical Network when using PVLANs, configuring the properties of the Logical network (as shown below) to specify that “sites within this logical network are not connected” and “Network sites within this logical network contain private VLANs”.

The Networks Sites page of the Create Logical Network wizard includes a subtle but important difference for PVLANs – in addition to the primary VLAN, the “Associated VLANs and IP Subnets” section now contains an additional column Secondary VLAN. You should associate each primary VLAN and secondary PVLAN with a Network site within the logical network (as shown below) – you can define multiple PVLANS in the same Network Site as needed.

Note: Only one PVLAN can be in isolated mode per primary VLAN and you should take care to ensure that a different primary VLAN ID is used in each Network Site you create. The ID you use for the PVLAN, however, may be the same in each site – in fact using the same ID for the isolated PVLAN is recommended since it ensures consistency and simplifies management.

As before, VM Networks need to be created to allow virtual machines to connect to and use the Logical Network. Each VM Network you create is directly mapped to exactly one of the PVLANS that have been defined for that Logical Network. As a result, you can only have as many VM Networks as you have defined PVLANS. The create VM Wizard (below) will display only those PVLANS that have not already been allocated to an existing VM Network. The wizard does not offer the option for automatic assignment - even though the text suggests that this is actually possible.

To briefly summarize, create a single Logical Network to support PVLAN isolation, configured such that “sites within the logical network are not connected” and “Network sites within the logical network contain Private VLANs”. You should create a Network Site, define primary and secondary VLAN pairs and create VM Networks for each one (as shown below). In our example, we have chosen to designate PVLAN 5 as the isolated PVLAN for consistency across all primary VLANs, your implementation may be different.

As we discussed earlier, although each virtual machine you connect to one of these VM Networks will be assigned an IP address from the same subnet, it will only be able to communicate only with the default IP gateway. You should also be aware that If all of the virtual machines are present on the same physical host, isolation will be enforced through the Hyper-V Extensible Switch, otherwise you will need to make sure that each of the PVLANS you define in VMM are also configured for isolation mode on the Physical Switch.

To avoid potential IP conflicts with resources that exist on the primary VLAN (and any community VLANS that were created outside of VMM), it is recommended that you reserve a set of IP addresses / create a separate IP Pool for each PVLAN. As discussed, the IP addresses you reserve must be part of the IP subnet that was allocated to the primary VLAN.

Summary

SC VMM 2012 SP1 only supports isolation mode and has no concept of primary (promiscuous) or community PVLANS and you need to be aware of this restriction when designing your solution. That being said, there are a number of scenarios which work quite well in this configuration - the most common example of which is Front End Web Servers. In this specific scenario, all of the web servers in a web farm are placed on a single network subnet but are otherwise completely isolated from each other, PVLANs in this context helping to simplify management and improve overall security.