How to Use VMware Distributed Switch Port Mirroring

In a VMware environment with a vSphere Distributed Switch, packet capture can be much cleaner than the standard-vSwitch workaround of creating temporary port groups and relying on promiscuous mode alone.

Distributed switching adds proper port mirroring features, which makes targeted VM capture easier and usually less noisy. But the details matter, because the original vSphere 5.x-era guidance is no longer enough for current environments.

The most important modern rule is this:

Local distributed port mirroring is still host-local. If the source or destination moves to another ESXi host, the session can stop working.

Why distributed switching helps

With a Distributed Switch, you can mirror traffic from selected VM ports to a dedicated monitoring destination instead of enabling broad promiscuous mode for a whole capture segment.

That is better because:

• you target only the ports you care about
• you reduce noise in the capture VM
• you avoid many of the duplicate-frame problems caused by mixing mirroring with promiscuous mode
• you can integrate virtual monitoring into a larger troubleshooting workflow more cleanly

In practice, this is the preferred VMware-native way to capture specific VM traffic when a vDS is available.

First correction: old licensing guidance is outdated

Older articles often frame distributed switches as an "Enterprise Plus only" feature tied to old vSphere editions.

That historical packaging has changed over time. In current Broadcom-era VMware environments, the exact availability of vDS and mirroring features depends on the version, platform design, and product entitlement in use.

So do not rely on old edition names when planning the capture. Check the actual capabilities exposed in the current vCenter and ESXi environment.

Local distributed port mirroring

The classic vDS capture method is Distributed Port Mirroring.

In this model:

• you select one or more source dvPorts
• you select a destination dvPort
• mirrored packets are copied to the destination VM

This is ideal when:

• the monitored VM and the capture VM are on the same ESXi host
• you want a VM-based capture target
• you need targeted capture without turning a whole segment promiscuous

The host-local limitation still exists

This is the most important operational caveat.

Broadcom’s current documentation confirms that Distributed Port Mirroring is local to the same ESXi host. If the source or destination port ends up on another host, the session can fail or stop forwarding mirrored traffic.

That means:

• if the monitored VM vMotions away, the mirror may break
• if the capture VM moves, the mirror may break
• if storage or compute movement changes the relevant destination association, the mirror may break

So a working mirror session at one moment does not guarantee it will still work later if placement changes.

Plan for host pinning during the capture window

Because of that locality rule, you should plan to keep:

• the monitored VM, and
• the capture VM

on the same ESXi host while the capture is active.

Practically, that often means:

• temporary DRS rules
• affinity constraints
• manual placement
• avoiding vMotion during the capture window

If you do not control movement, the capture may silently stop seeing what you think it is seeing.

Do not mix port mirroring and promiscuous mode casually

This part of the old guidance still holds.

If you enable promiscuous mode broadly on the same switching scope that is also being mirrored, you can create duplicate traffic and confuse analysis badly.

As a rule:

• use targeted port mirroring when available
• use promiscuous mode only when you actually need it
• do not assume both together are harmless

If you see duplicated frames in the capture VM, this is one of the first things to check.

Source and destination design

At a high level, a mirrored capture session needs:

• a source VM port or ports
• a destination monitoring port

The destination can often be:

• another VM acting as the capture appliance
• in some designs, a path toward a physical collector

The cleanest virtual design is usually a dedicated capture VM with:

• one management NIC
• one sniffing NIC

That keeps management traffic off the monitoring interface and helps keep the capture side more passive.

Current options beyond local mirroring

When the source and destination might span hosts, local distributed mirroring is not enough.

Current VMware guidance points to Encapsulated Remote Mirroring (L3) Source when you need mirrored traffic to survive host boundaries or be sent to a remote collector.

That means the vDS can:

• encapsulate the mirrored packets
• tunnel them over layer 3
• deliver them to a remote monitoring endpoint

Operationally, this is the modern answer when the old host-local mirror model is too fragile for the environment.

What remote or encapsulated mirroring changes

Remote mirroring solves one problem but introduces others.

Advantages:

• source and destination no longer have to stay on the same host
• capture can be delivered to an external collector
• host movement is less likely to invalidate the monitoring design

Tradeoffs:

• more complexity
• added encapsulation overhead
• more dependency on network path behavior
• more timestamp distortion than strict host-local capture

So this is useful, but it is not equivalent to a passive TAP in terms of timing or proof quality.

VLAN handling is not what many people expect

One especially important correction to older lab observations is this:

Broadcom currently documents that with Distributed Port Mirroring, Remote Mirror Source, and Remote Mirror Destination, the switching VLAN tag is not present in the mirrored packets as many people expect.

So if your analysis depends on preserved VLAN tags, validate the exact session type and resulting packet shape in your environment before relying on it.

Do not assume that a mirror session will preserve VLAN context the same way a physical wire capture might.

LACP caveat

Another current limitation worth calling out: VMware documents that port mirroring cannot be used to mirror LACPDU traffic used for LACP negotiation and control.

So if your troubleshooting target is specifically LACP negotiation behavior, this is not the right capture method.

Mirror destination limits and housekeeping

There are also implementation limits and lifecycle details that matter in current environments:

• some remote mirroring session types support only a small number of destination IPs per session
• stale mirroring sessions can block later configuration cleanup
• storage vMotion and other backing changes can break mirror destinations in some versions

That means mirror sessions should be treated like temporary operational objects:

• create them carefully
• validate them immediately
• remove them when done

A practical workflow

If you want to capture one VM’s traffic on a Distributed Switch, this is the sensible order:

1. Decide whether host-local mirroring is sufficient.
2. If yes, place the monitored VM and capture VM on the same ESXi host.
3. Create a local distributed port mirroring session with the target VM port as source and the capture VM port as destination.
4. Keep promiscuous mode off unless you have a specific reason to use it.
5. Validate that the capture VM sees the expected flows immediately.
6. Prevent host movement during the capture window.
7. Remove the session after the capture completes.

If host locality cannot be guaranteed, redesign around encapsulated remote mirroring instead.

When a capture VM is still not enough

Even with a well-configured vDS mirror session, writing packets into a capture VM still creates:

• guest CPU load
• storage I/O
• possible packet loss if the VM is underpowered

So if traffic volume is high, consider:

• limiting the scope of mirrored sources
• rotating files aggressively
• using an external collector for encapsulated mirroring
• pairing the virtual capture with physical capture if the question extends beyond the host boundary

Final takeaway

Distributed Switch port mirroring is the right VMware-native tool when you want targeted visibility into VM traffic without the broad blast radius of promiscuous mode.

But the old mental model needs updating: local distributed mirroring is still local to the ESXi host, and modern environments often need encapsulated remote mirroring when VMs can move or monitoring must leave the host.

Use local mirroring when source and destination can stay together. Use remote encapsulated mirroring when they cannot. And validate everything immediately, because VMware capture features are powerful, but very easy to mis-trust if you assume they behave like physical wire capture.