This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

We have about 30 Windows VMs under vSphere 5.1. I am using esxtop to monitor the network and I see some odd behavior. Under the %DroppedPacketsReceived (%DRPRX) column you can see the problem. This column will show zeros for all VMs for a few seconds then all the VMs will show packet loss for a few seconds, then back to zero. I have a Win7 machine with Wireshark installed on this host, you can see it at the bottom of the screen shot. When I do a packet capture: - Will it show these dropped packets? - If so what would I be looking for?

alt text

asked 06 Nov '13, 10:50

HendersonD's gravatar image

HendersonD
51113
accept rate: 100%

Not a direct answer to your questions but just a hint, can this be related to one of this:

http://kb.vmware.com/kb/1010071

http://kb.vmware.com/kb/2039495

(06 Nov '13, 14:58) Edmond

I figured it out This thread about half way through talks about VDS Health Check sending out broadcast packets

https://communities.vmware.com/message/2280450

I disabled the Health Check and the dropped packets vanished. The Virtual Distributed Switch Health Check just looks at this switch and sees if it is setup correctly. Having the health check turned on generates broadcast packets. Not sure why my VMs are dropping these packets but turning it off is the solution.

permanent link

answered 07 Nov '13, 06:10

HendersonD's gravatar image

HendersonD
51113
accept rate: 100%

I accepted the answer, as it solves the problem.

(07 Nov '13, 06:18) Kurt Knochner ♦

From the VMware KB article:

Cite: 'Even though esxtop shows the packets as dropped at the virtual switch, they are actually dropped between the virtual switch and the guest operating system driver.'

So, to answer your question:

I have a Win7 machine with Wireshark installed on this host, you can see it at the bottom of the screen shot. When I do a packet capture: - Will it show these dropped packets?

The virtual machine will only be able to capture traffic directed to it's own machine, and therefor you won't see the traffic of the other virtual machines.

Answer to you question: No, you won't see any packets of other virtual machines. BTW: You won't see the 'dropped' packets anyway, as they are, well ... dropped ;-)).

You can change the operational mode of the vSwitch to 'promiscuous' mode. In that mode, the Win7 system (with Wireshark) will see 'everything' (depends on the configuration of port groups, vlans, etc.).

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1002934
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004099

However, that will probably cause even more problems (due to overload)!!

One possible solution to your problem is described in the VMware KB article: raise receive buffer sizes.

HOWEVER: it remains unclear what causes dropped frames for so many machines. It could be a network burst, a DoS attack or an error in the design.

To figure out what's going on, I suggest to mirror the physical network port(s) of the VMware host and capture that traffic. Maybe there is a traffic spike in the IO stats, that correlates to those dropped frames shown in esxtop. If there is nothing, the network traffic could be caused by another virtual machine. In that case you can either capture the traffic in each virtual machine (probably to many) or on the virtual switch after you placed it in promiscuous mode. WARNING: Don't do that without talking to your local VMware guru!! As I said, that might cause even more (severe) problems.

Another option: Capture on the VMware host itself with tcpdump

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1000880

And finally: See a blog post of @Jasper

http://blog.packet-foo.com/2013/04/capturing-packets-of-vmware-machines/

Regards
Kurt

permanent link

answered 07 Nov '13, 02:25

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 07 Nov '13, 02:33

Thanks for all the great suggestions I have seen the two VMWare KB articles. I will give them another shot but the first time I changed the Small RX buffer and RX Ring Size on one VM I did not see any changes in dropped packets. This is happening on every one of my 40+ server VMs and all of my View desktops so I would hate to think that these two parameters needed to be changed on all of them.

Kurt - I actually made a VM with Win7 and Wireshark installed. If you look at my screen shot above it is the last VM listed. I ran the capture using this VM and did not see a smoking gun. Again, this could be due to my ignorance on not knowing exactly what to look for in a packet capture or the packets are dropped between the virtual switch and the guest OS driver and therefore doing the capture inside the guest OS will never capture these dropped packets.

If I do the capture on the physical switch by running a port-mirror, what types of things am I looking for that would indicate packets are being dropped?

(07 Nov '13, 05:34) HendersonD

Apparently you found the solution yourself (see your answer). Just for the records:

I ran the capture using this VM and did not see a smoking gun.

As I said, you won't see any 'dropped' traffic in the virtual machine if the packets are dropped by the driver, so Wireshark will never know about those packets, hence no 'smoking gun' visible in Wireshark

(07 Nov '13, 06:18) Kurt Knochner ♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×23
×23

question asked: 06 Nov '13, 10:50

question was seen: 7,556 times

last updated: 07 Nov '13, 06:23

p​o​w​e​r​e​d by O​S​Q​A