TagDistributed Switch

#PowerCLI: Distributed switch portgroup usage. Good vs. bad vs. Max Power approach

From now on there are three ways of doing things: the right way, the wrong way, and the Max Power way.

Isn’t that the wrong way?

Yes! But faster!

This quote from Homer Simpsons came directly into my mind when I was doing some PowerCLI scripting during the week.


I started with the wrong / Max Power way and suddenly came to a much more smarter solution – the right way.

The task was to gather the usage on the virtual distributed switch portgroups within a world-wide environment with around 30 vCenter. (Final script on the bottom of this blog)

Once again I realized there are many roads to Rome and even with PowerCLI you can either go there by crawling or using a plane.

My first approach was to get each portgroup and have a look through each port if it has a connection to the virtual network adapter of a VM (each VM only has 1 Network adapter).

$ports = Get-VDSwitch | Get-VDPort -VDPortgroup $pg
$portsconnected = $ports | Where {$_.ConnectedEntity.Name -eq 'Network adapter 1'}

That approach was incredibly slow (> 12 hours) since it took a while to get all port objects of the distributed switch (more than 5000 per vDS).

Thanks to Brian Graf‘s great blog article we know how to access vSphere objects extension data in a much more elegant way.

$networks = Get-View -viewtype Network
Foreach ($network in $networks){
    $pgname = $network.Name
    $connectedports = ($network.VM).count 

Doing it that way it took 15 minutes instead of 12++ hours.

It really makes a huge difference if you code something right or wrong. That’s counts for Software, SQL-queries and also for all kind of scripts we use and built in our daily IT-infrastructure world.

The final script gives you an csv output file with the values

Datacenter, PortgroupName, VLANID, NumberOfConnectedPorts

Make sure to use Powershell 3.0++ so you can use the -append option in the export-csv cmdlet.


Good one

$results = @()

$cluster = get-cluster | Sort-Object -Property Name
$dcName = (Get-Datacenter).Name
$networks = Get-View -viewtype Network

Foreach ($network in $networks){
    $pgname = $network.Name
    $pg = Get-VDPortgroup -Name $pgname
    $vlanid = $pg.vlanConfiguration.VlanID
    $connectedports = ($network.VM).count

    $details = @{
        PortgroupName = $pgname
        VLANID = $vlanId
        NumberOfConnectedPorts = $connectedports
        Datacenter = $dcName

    $results += New-Object PSObject -Property $details

$results | export-csv -Append -Path c:\temp\newvDSnetworkConnected.csv -NoTypeInformation

 Bad one

$results = @()

$dcName = (Get-Datacenter).Name
$pgs = Get-VDSwitch | Get-VDPortgroup | Where {$_.IsUplink -ne 'True'}

foreach ($pg in $pgs){

    $ports = Get-VDSwitch | Get-VDPort -VDPortgroup $pg
    $portsconnected = $ports | Where {$_.ConnectedEntity.Name -eq 'Network adapter 1'}

    $pgname = $pg.name
    $vlanId = $pg.VlanConfiguration.VlanId

    $connectedports = $portsconnected.count
    $details = @{
        PortgroupName = $pgname
        VLANID = $vlanId
        NumberOfConnectedPorts = $connectedports
        Datacenter = $dcName
    $results += New-Object PSObject -Property $details 

$results | export-csv -Append -Path c:\temp\vDSnetworkConnected.csv -NoTypeInformation

vDS Rollback – Changing the Management VLAN

Introduced in vSphere 5.1, VMware’s vSphere Distributed Switch (vDS) brings a feature called “Rollback”. In KB 2032908 VMware provides a good overview of the features, to please read this first before you continue.

The Problem

While the advantages of this outweigh the disadvantages by far, there are situations when vDS Rollback can drive you nuts. Just happend today: We had ESXi server in VLAN 10 while vCenter, database, etc reside in VLAN 20. For VLAN 20 we had a vDS Portgroup with a VLAN configuration of “none” as the physical Switch (pSwitch) defined VLAN 20 to be the “native VLAN”

The native VLAN, by definition, is the network carried over a VLAN trunk connection without a 802.1q tag.

So this was the initial situation:


Now, we wanted the Management VLAN to be tagged to the pSwitch. In earlier releases the process looked like this:

  1. Change vDS configuration to VLAN: 20 and lose connection to vCenter (planned)
  2. Go to pSwitch and add VLAN 20 to the tagged VLANs on the trunk
  3. Connection will be restablished.

The problem with rollback is, that when you lose the connection to vCenter, ESXi are going to lose connection, too, triggering the rollback feature. As a result, your configuration which lead to losing the connection will be undone.

Solution 1: Disable Rollback

One solution is to disable rollback, take the “old” way to changing the VLAN configuration, then re-enable rollback:

Disable rollback:

  1. On your vCenter server nagivate to %programdata%\VMware\VMware VirtualCenter
  2. Open vpxd.cfg for edit.
  3. Change  <rollback>false</rollback> to  <rollback>true</rollback>
  4. Restart vCenter services from services.msc

Now follow the instructions as mentioned in the first section of this article. Finally, follow the steps above to enable rollback.

Solution 2: Native and Tagged VLAN 20

Another solution involves some pSwitch configuration: We have to configure the pSwitch to send untagged traffic to VLAN 20 (native VLAN) and accept traffic tagged with 20, too! Like this we can change the VLAN configuration of the Portgroup from “none” to VLAN 20 without a network interruption. Like this rollback will not kick.


Finally, the pSwitch can get a different native VLAN configuration without further interruption of vSphere management traffic.

Hope that helped!

PVLAN – A Widely Underutilized Feature

Hello folks, after some time of laziness I am now back with a short note on Private VLANs. I figured use cases for the Private VLAN feature are widely unknown in the field and therefore PVLAN is probably one of the most underutilized features of vSphere out there. Avoiding redundancy on the internet I don’t want to explain PVLAN here, so please read

in case you are not familiar with the concept, yet.

Use Case 1: Saving VLAN IDs

This is probably the only use case people are usually familiar with. Here is the situation: A hosting provider is concerned with providing network connectivity to multiple customers / tenants. For security reasons maybe, customers are to be isolated on layer 2: VLANs. With a possible values ranging from 0 through 4095 for VLAN IDs, we can create up to 4096 VLANs. Some VLAN IDs will be used by the provider himself (storage, vMotion, FT, Management,  etc etc). Though, I see more and more switches supporting 4096 VLANs, many of them are still restricted to a much lower number – 256 for example. You get the point? Only a fraction of possible VLAN IDs can actually be used restricting the number of customers / tenants a hosting provider can support. Further, using VLANs you will end up defining hundreds of subnets and reconfiguring your routers to support newly created networks.

With PVLAN, a provider can now try to put as many VMs into the Isolated secondary PVLAN only using a single VLAN ID but still separating hundreds of VMs from each other. In case a customer requires multiple VMs to talk to each other that traffic could go over a router in a Promiscuous secondary PVLAN or a Community could be created to relieve load from that router. But that would require a precious VLAN ID.

Use Case 2: DMZ

Yeah, you are reading this right! PVLANs can be used in a DMZ environment perfectly well! Think about it:

  1. In a Primary PVLAN the same IP subnet is to be used.
  2. PVLANs allow to further control traffic flow on layer 2 without the requirement for routers or firewalls.

Doesn’t that sound like something you want in a DMZ?

In a DMZ environment, we usually have two firewalls: an outer one protecting the DMZ from the internet and an inner one protecting the organization network from the DMZ and the internet.

The outer firewall protects VMs by filtering traffic to applications not supposed to be reachable from the internet. Still, DMZ systems can be intruded. In this case, when an attacker has gained control over a certain system in the DMZ, he or she gets unfiltered access to all other systems in the same DMZ. No firewall will stop him or her from accessing systems on certain ports.

PVLANs can help to restrict that access! Put your DMZ routers/firewalls in the Promiscuous secondary PVLAN and create Communities for multi-tiered applications. This way, intruding a VM the attacker will be contained in the Community secondary PVLAN unable to send ANY traffic to systems not part of that application.


This dramatically restrains the attacker in the number of possible targets for further attacks!

Use Case 3: Backup Network

From time to time, I see environments that use the old-school way of making backups of systems: agents in VMs, a dedicated backup network, every VM equipped with a second NIC attached to that backup network and a central backup server. What happens here is that people wrap their heads around security for production VLANs – maybe multiple of them – but then put all VMs together in a backup network that allows every VM to talk to every other VM in the company. That creates a big big broadcast domain and gives viruses and other stuff a red carpet for spreading over to other systems.

Now here is my suggestion: On that backup network create  a PVLAN. Configure the backup server(s) to be in the Promiscuous secondary PVLAN and put all VMs into Isolated. This way every backup agent will be able to connect to the backup server but no VM will be able to talk to another VM!


Use Case 4: Desktop Virtualization

In a VDI environment a valid concern regarding security is the ability of desktops to communicate directly with each others. Like this, users can exchange data without using enterprise storage or even viruses could spread easily. With PVLAN just put desktop VMs into an “Isolated” PVLAN and place central storage in “Promiscuous” PVLAN. Done 🙂


Hope that inspires you a bit and I will see PVLANs more often in the future.

© 2017 v(e)Xpertise

Theme by Anders NorenUp ↑