Identifying VM Network Latency using tracert and traceroute
search cancel

Identifying VM Network Latency using tracert and traceroute

book

Article ID: 437792

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

Network latency—the delay in data traveling between your local machine and a virtual machine (VM)—can cause lag and slow application performance. Using tools like Traceroute (or Tracert), you can analyze the round-trip time (RTT) at each hop along the network path to identify where delays occur.

This KB outlines Traceroute/Tracert as a first step in troubleshooting VM latency issues, as it provides clear visibility into hop-by-hop latency and helps isolate whether the issue lies within the host or the underlying physical network.

 

Environment

VMware ESXi

Resolution

For Windows VM using tracert 

  • To identify the source of VM latency, execute the tracert command and analyze the output
  • Type : tracert <destination IP>
  • For example (Windows VM) :
Windows VM>tracert 10.xx.xx.25

Tracing route to example.com [10.xx.xxx.25]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  10.xx.xxx.1
  2    67 ms   164 ms   318 ms  example.com [10.xx.xxx.25]

Trace complete.
  • The 1st hop shows a latency for <1ms, which is till the default gateway of the VM. However, post which in the 2nd hop we see the latency increased to 318 ms, which shows the latency to the destination physical device.
  • This shows that the latency has occured post the packet has left the Default Gateway, which is in the physical network.

 

For Linux VM using traceroute

Similarly, you can use the traceroute command in Linux to identify the latency.

The output would look something like this :

[linux-vm ~]$ traceroute 10.xx.xxx.25
traceroute to 10.xx.xxx.25 (10.xx.xxx.25), 30 hops max, 60 byte packets
 1  gateway (10.xx.xxx.1)  0.315 ms  0.288 ms  0.272 ms
2  example.com (10.xx.xxx.25)  67.124 ms  164.551 ms  318.002 ms
  • Here as well, the latency at the initial hop is only 0.272 ms, which is significantly lower than the 318.002 ms observed after the packet leaves the default gateway, indicating the delay occurs beyond the gateway in the physical network.