VMware ESXi and vSphere Cluster Management
How to Specify Incoming and Outgoing Packet Loss Percentage in VMware Workstation Player
Learn how to configure incoming and outgoing packet-loss percentages in VMware Workstation Player and verify unreliable-network behavior from a guest VM.
Packet-loss simulation intentionally discards some network packets so you can test how a virtual machine and its applications behave on an unreliable network. It is useful for validating retry logic, timeout handling, reconnection behavior, error messages, synchronization, and general application resilience.
The configured percentage is a simulation target, not a guarantee that every short test produces exactly that percentage. Packet dropping is probabilistic, so use repeated tests and sufficiently large samples when measuring the result.
Understand the packet-loss settings
Packet loss means that packets are discarded before reaching their intended destination. A packet-loss percentage is the proportion of packets VMware attempts to drop during the simulation.
The relevant controls are normally found in the Advanced settings for the applicable VMware virtual network adapter or virtual network. The exact menu names and availability can vary with the VMware Workstation Player version, host operating system, and installed networking components.
The settings apply to traffic traversing the selected virtual networking path. They do not necessarily affect every network interface in the guest or every virtual network configured on the host.
Incoming and outgoing traffic
- Incoming transfer: traffic arriving at the configured virtual adapter or virtual-network side.
- Outgoing transfer: traffic leaving the configured virtual adapter or virtual-network side.
- Asymmetric packet loss: different loss rates in the two directions.
Always interpret direction from the perspective of the configured VMware virtual adapter. A host, guest, and virtual-network diagram can use different viewpoints, so a field that appears to describe “incoming” traffic may not match the direction you first expect from the application’s perspective.
Choose packet-loss percentages
Use equal incoming and outgoing values to model symmetric loss. Use different values to test an asymmetric condition, such as requests leaving normally while responses are frequently lost.
- 0%: disables intentional loss for that direction.
- Low loss, such as 1%: models mild intermittent impairment.
- Moderate loss, such as 10%: exercises resilience, retries, and timeout behavior.
- High loss, such as 50%: creates severe impairment. About half of the packets may be discarded over a large sample.
- 100%: prevents normal communication in the affected direction.
For example, setting incoming loss to 50% and outgoing loss to 50% creates a severely unreliable bidirectional network. Setting incoming loss to 50% and outgoing loss to 0% tests a flow in which traffic arriving at the configured adapter is impaired while traffic leaving it is not. Confirm the actual direction in your lab with a known sender and receiver.
Packet-Loss Percentage Test Matrix
| Incoming loss setting | Outgoing loss setting | Test purpose | Likely observable behavior |
|---|---|---|---|
| 0% | 0% | Baseline connectivity | No intentional packet dropping from this setting |
| 1% | 1% | Low-level intermittent impairment | Most traffic succeeds; occasional retries may occur |
| 10% | 10% | Moderate resilience testing | More retries, delayed responses, and occasional timeouts |
| 50% | 50% | Severe bidirectional loss testing | Many probes and application packets fail or require retransmission |
| 50% | 0% | One-direction impairment testing | One traffic direction is frequently lost while the other is not intentionally impaired |
| 100% | 100% | Complete simulated communication failure | Normal two-way communication cannot succeed through the affected path |
Configure packet loss in VMware Workstation Player
- Open the VMware virtual-network configuration area.
- Select the virtual network or virtual network adapter used by the VM.
- Open its Advanced settings.
- Locate the incoming and outgoing packet-loss percentage fields.
- Enter the desired value for each direction. Use the same value for symmetric loss or different values for asymmetric testing.
- Apply or save the configuration.
- Confirm that the VM is connected to the intended virtual network before testing.
- Record the original values so you can restore the lab afterward.
Verify the simulation from the guest
Use a repeatable connectivity test from the guest operating system. A controlled, reachable lab endpoint is preferable to a public Internet address because an external route can add unrelated loss, latency, firewall behavior, or congestion.
Windows
ping <test-ip-or-hostname> -n 100For a quick ten-probe check, you can use:
ping 8.8.8.8 -n 10The public-target example is convenient but less repeatable. A local or isolated lab endpoint gives a cleaner measurement.
Linux
ping -c 100 <test-ip-or-hostname>Review the number of probes sent, replies received, lost probes, and the reported packet-loss percentage. Run multiple probes because a small sample can differ substantially from the configured value. For example, 7 lost probes out of 10 is 70% observed loss and can occur during a 50% simulation.
Ping Result Interpretation
| Metric | Meaning | How it relates to configured loss |
|---|---|---|
| Sent | Number of probes transmitted by the guest | Defines the sample size |
| Received | Number of replies returned | Lower values can indicate packet loss, filtering, or an unreachable endpoint |
| Lost | Probes for which no reply was received | Includes simulated loss and any independent loss or filtering |
| Observed loss percentage | Lost probes divided by sent probes | Should approach the configured rate over repeated, large samples but will not necessarily equal it in a short run |
| Timeout messages | Replies were not received within the probe timeout | Can result from loss, latency, filtering, or endpoint problems |
| Round-trip time | Time for a probe to reach the endpoint and return | Packet loss may cause retries at higher protocols, but this setting alone does not specify latency |
Effects on protocols and applications
Packet loss does not look the same at every protocol layer. The result depends on whether the protocol retries, buffers, or simply gives up.
Protocol Behavior Under Packet Loss
| Protocol or workload | Typical effect of loss | What to test |
|---|---|---|
| ICMP ping | Some echo requests or replies time out | Reachability, observed loss, and variation across sample sizes |
| TCP web or API traffic | TCP retransmits lost segments, often causing slower responses and eventual timeouts rather than obvious data loss | Retry behavior, completion time, timeout thresholds, and error handling |
| UDP application traffic | Messages can disappear directly because UDP does not provide automatic retransmission | Application-level acknowledgements, sequence numbers, recovery, and acceptable loss |
| DNS queries | Queries or replies may be retried, delayed, or reported as failed | Resolver retries, fallback behavior, and user-facing errors |
| Remote desktop or SSH | Interactive sessions can become sluggish, freeze, or disconnect | Keepalives, reconnection, and session recovery |
| File transfer | TCP transfers may slow down or fail after repeated retransmissions | Integrity, resume support, throughput, and timeout behavior |
Loss can combine with latency, jitter, bandwidth limits, firewall rules, DNS problems, and real external network conditions. Therefore, a failed application test is not automatically proof that packet loss alone caused the failure.
Safe test design and cleanup
- Use isolated lab VMs and known test endpoints where possible.
- Keep a baseline result with both loss values set to 0% before introducing impairment.
- Change one condition at a time when you need to identify a failure threshold.
- Use enough probes and repeat tests rather than relying on one short run.
- Test both protocol-level results and application-level behavior.
- Restore incoming and outgoing packet loss to 0% after testing.
- Retest normal connectivity after removing the simulated impairment.
Troubleshoot unexpected results
No packet loss is observed
- Verify that the VM is connected to the virtual network or adapter you edited.
- Reopen Advanced settings and confirm that the values were applied and saved.
- Check whether the traffic actually traverses the configured VMware path.
- Increase the probe count and test controlled endpoints.
The measured rate does not equal the configured rate
- Packet dropping is probabilistic, especially in a small sample.
- Use 100 or more probes and repeat the test.
- Prefer local lab endpoints over public targets.
- Remember that TCP retransmissions can hide some effects at the application layer.
The VM cannot communicate at all
- Check whether 100% loss was applied in one or both required directions.
- Set both values to 0%, apply the change, and test again.
- Confirm the guest IP address, gateway, DNS settings, firewall, and adapter connection.
A TCP application is slow rather than visibly losing data
TCP retransmission is the likely reason. Measure completion time and timeout frequency, inspect application logs, and compare several loss rates to find the point at which the application fails.
The direction appears reversed
Run a one-direction test with a known sender and receiver. Record which field affects that flow from the configured VMware adapter’s perspective, then use that mapping consistently for the rest of the lab.
Example test plans
- Severely unreliable bidirectional network: incoming 50%, outgoing 50%. Expect roughly half of packets to be dropped in each direction over a sufficiently large sample, with noticeable short-run variation.
- Impaired arriving traffic: incoming 50%, outgoing 0%. Requests may leave normally while arriving replies or other traffic are frequently lost, subject to the adapter-direction interpretation.
- Impaired traffic leaving the configured adapter: incoming 0%, outgoing 50%. Use this to test retries, duplicate requests, and timeout handling in the affected flow.
- Normal networking restored: incoming 0%, outgoing 0%. No intentional packet dropping is introduced by these settings.
For related lab work, see packet-loss percentage configuration and apply the same controlled-test principles when investigating other virtual-network impairments.