Wireshark · Wireshark-users: Re: [Wireshark-users] Need help analyzing...

[Scott Chapman <scottchapman@xxxxxxxxxxxxxx>]

Thanks for teaching us how to fish!

A little more background on 192.168.1.95. It is Openfiler running on an ESXi server. The VM is using the enhanced vmxnet adapter. There is no VLAN on the ESXi server. The openfiler is serving (using CIFS) a software RAID-1 array of two 1.5T disk drives.

I am considering adding a second adapter to the machine to see if I can get some load balancing (but not sure that is the issue here).

-Scott
P.s. I have another machine which is performing *much* worse. I may try to grab a capture file and see if I can figure it out. otherwise I may send that along too for your help.

----- Original Message -----

Message: 2
Date: Mon, 29 Dec 2008 01:56:02 +0100
From: Sake Blok <sake@xxxxxxxxxx>
Subject: Re: [Wireshark-users] Need help analyzing...
To: Community support list for Wireshark
        <wireshark-users@xxxxxxxxxxxxx>
Message-ID: <20081229005602.GA30375@xxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii

On Mon, Dec 29, 2008 at 02:17:32AM +0200, Boaz Galil wrote:
> >  On Sun, Dec 28, 2008 at 8:17 PM, Sake Blok <sake@xxxxxxxxxx> wrote:
> >
> >    On Sun, Dec 28, 2008 at 08:47:10AM -0500, Scott Chapman wrote:
> >
> >    >    Please take a look at the log file attached and let me know what
> >    you
> >    >    think. I see a lot of TCP out of order. Is that an issue I should
> >    be
> >    >    worried about?
> >
> >    Nope, the out-of-order messages are all duplicate packets. Did you span
> >    a vlan on the switch? Did you capture both directions? Every packet will
> >    enter AND leave the vlan, hence duplicate packets. If you span a vlan,
> >    you'd better use only one direction instead of both.
>
>    I have downloaded the packet capture as well and I have a few questions:
>
>    1.       Why did you mention that he can ignore the duplicate packets? -
>    why does he have duplicate packets in the first place (or should I say
>    what could be the reason for that and can we ignore duplicate packets in
>    most scenarios*)? (Thanks for the tip on how to filter the duplicates).

Thank you for asking the right question. I took another look at the
tracefile and my first suggestion for the cause of the duplicate packets
was wrong. Normally when I see *every* packet twice, it is an artifact
from spanning a vlan and selecting both rx and tx traffic. As every
packet has to enter the switch and leave the switch, it will be captured
twice.

But in this case, it is different. Traffic from 192.168.1.246 to
192.168.1.95 is captured twice, while traffic in the other direction is
only captured once. I have seen this when doing the capturing on my
vmware host with vlan tagging enabled. If I capture on the vlan
interface, somehow traffic towards the guest-os is captured twice. I
don't know why that is, but removing the duplicates with editcap makes
it possible to look at the traffic more properly.

(Gerald, I saw that you gave a presentation on capturing traffic in
virtual environments on Laura's Summit, did you cover this artefact too?
Is the presentation online somewhere?)


> >    You can remove the duplicate packets from the tracefile with:
> >
> >    editcap -d <infle> <outfile>
> >
> >    I have looked at the resulting file and see that the two systems
> >    communicate at 200Mbit/s, which is better than the 10MB/s you were
> >    mentioning, but still not the speed you might expect. Part of this is

>    2.       How did you calculate the speed of the file transfer?

After removing the duplicates, I just opened the file and chose
"statistics -> Summary", since there is only one TCP session in the
tracefile.

If there are multiple sessions in the tracefile, you could use
"Statistics -> Conversations" instead. It will show you all the
conversations with their rx and tx bandwidth as seen in the tracefile.

Cheers,
    Sake