Private VLAN Support in Windows Server 2012

    One of the main components of the new Hyper-V in Windows Server 2012 is the Hyper-V Extensible Switch. Hyper-V Extensible Switch is a second-level software-controlled switch that has a number of interesting features, including support for Private VLAN (PVLAN) technology. I will briefly describe the implementation of PVLAN in the Hyper-V switch and will focus more on the configuration of private VLANs for virtual machines (VMs). You can see the technology in action in the first demo of a web cast dedicated to new Hyper-V features in Windows Server 2012.

    The essence of PVLANs has already been discussed on Habr, in particular, here. For Hyper-V, you can assign each Hyper-V Extensible Switch port one primary (primary or Primary VLAN ID) identifier and one or more secondary (Secondary VLAN ID). Unlike a hardware switch with a specific number of ports, the port on the Hyper-V switch is identified by a virtual machine, or rather a network adapter (since there may be several) of a virtual machine connected to this port. Therefore, hereinafter, set the settings for the Hyper-V Extensible Switch = port = set the settings for the corresponding virtual machine.

    So, when configuring PVLANs and specifying Primary and Secondary VLAN ID, the corresponding port can be configured in one of three modes:
    • promiscuous (mixed) - in this mode, the VM can exchange packets with any ports that have a Primary VLAN ID;
    • community (general) - in this mode, the VM can exchange packets with any other ports configured in the community mode, which have the same Primary and Secondary VLAN IDs; in addition (see above), the VM can communicate with promiscuous ports that have the same Primary VLAN ID;
    • isolated - in this mode, the VM can only interact with promiscuous ports with the same Primary VLAN ID.

    In addition, it should be noted that the Hyper-V Extensible Switch puts the port in trunk mode, which "looks" at the physical host network adapter. Provided that your hardware switches do not block tagged packets, the logic of the considered modes does not depend on whether the VMs are running on the same physical host as Windows Server 2012 or on different ones.

    One of the main applications of PVLAN is the additional isolation of VMs running in your data center and belonging to different departments, departments or organizations. I will explain with an example. Suppose four VMs are running on the same host (see the figure below). SRV1 and SRV2 belong, say, to the sales department, they run some application components, for example, in one SharePoint, in another SQL Server with a SharePoint database. SRV4 is owned by the finance department and must be isolated from the VMs of other departments. Finally, SRV3 runs the services that all VMs on a given host or multiple hosts need. A possible solution to this problem using PVLAN:
    1. Configure SRV1 and SRV2 in community mode with Primary VLAN ID = 2 and Secondary VLAN ID = 5; Of course, you yourself determine the specific values ​​of the identifiers;
    2. Configure SRV4 in isolated mode with Primary VLAN ID = 2 and Secondary VLAN ID = 4;
    3. Configure SRV3 in promiscuous mode with Primary VLAN ID = 2 and Secondary VLAN ID = 4 and 5.

    image

    Now let's implement this task in Windows Server 2012. Let's start with SRV4. PVLAN configuration is done by PowerShell cmdlets. As noted, the Hyper-V switch port is identified by the network adapter of the VM connected to this port. The easiest way is to obtain information about VM network adapters using the Get-VMNetworkAdapter command , specifying the VM name as a parameter:

    image

    As you can see, in SRV4 there is a single network adapter with a name that matches the name of the virtual machine itself - SRV4. The current VLAN settings of the corresponding Hyper-V Extensible Switch port can be seen using Get-VMNetworkAdapterVlan :

    image

    SRV4 is currently in Access mode with a single VLAN ID of zero. This default setting for a VM is equivalent to the fact that there are no VLANs at all. And all the other VMs are in the same state for now: SRV1, SRV2, SRV3. We enable the mode we need for SRV4 with the Set-VMNetworkAdapterVlan command :

    Set-VMNetworkAdapterVlan -VMName srv4 -VMNetworkAdapterName srv4 -Isolated -PrimaryVlanId 2 -SecondaryVlanId 4


    The -VMName and -VMNetworkAdapterName parameters indicate the names of the VM and network adapter, respectively, with the remaining parameters, specify the mode and Primary and Secondary VLAN ID. Checking the settings:

    image

    Please note that starting from this moment, SRV4 cannot interact with other VMs until we properly configure PVLAN for them as well. We will do this with the appropriate commands, using the PowerShell command pipeline, where the result of executing one command is transmitted to the input of the following:

    Get-VMNetworkAdapterVlan -VMName srv3 | Set-VMNetworkAdapterVlan -Promiscuous -PrimaryVlanId 2 -SecondaryVlanIdList 4-5
    Get-VMNetworkAdapterVlan -VMName srv2 | Set-VMNetworkAdapterVlan -Community -PrimaryVlanId 2 -SecondaryVlanId 5
    Get-VMNetworkAdapterVlan -VMName srv1 | Set-VMNetworkAdapterVlan -Community -PrimaryVlanId 2 -SecondaryVlanId 5


    Note that in the first command, the Secondary VLAN ID list is specified by the range. In addition, you can set different identifier values ​​by listing them with a comma and enclosing in quotation marks: -SecondaryVlanIdList “4,5” .

    At any time, you can return the settings to their original state, for example, for SRV4 by doing:

    image

    In conclusion, a few words about the trunk mode. As I mentioned above, Hyper-V puts in the trunk mode the port to which the physical network adapter is connected. But if necessary, any VM can be switched to trunk mode so that it can receive packets with different VLAN IDs. For the same SRV4, the command will look like:

    image

    Here -AllowedVlanIdList sets the list of allowed VLAN IDs, both Primary and Secondary, and the -NativeVlanId parameterindicates which VLAN the untagged packets will belong to.

    Thus, support for PVLAN technology, along with other Hyper-V Extensible Switch capabilities, will help provide an additional level of VM isolation within the multi-tenant architecture.

    You can find more information on the Microsoft Virtual Academy portal .
    But the best, from my point of view, source of information is the product itself, which you can download and try the listed features in practice.

    Also popular now: