Wireshark-users: Re: [Wireshark-users] Interface Details >Receive but no buffer ISUUE
Tal Bar-Or wrote:
Hello,
I did capture on a server that is used to download regularly big dv
movie files 4Gbytes each the transfer is usually slow and i have been
asked to figure out why ,the server itself HP DL360 G5 with the
on-board broadcom(NC326i) network card type.
after analysing short download capture of 250Mbytes i saw huge amount
of Duplicate ACK along with lost segment, fast retransmits.
i noticed that on Interface Details the *Receive but no Buffer* is
huge and increasing my question is could it be the reason for such
latency and lost data, what could be the cause for such huge values.
Losing packets because the capturing PC can't keep up with the traffic
is normal. In most cases, the capturing PC has to accommodate the
SENDING and RECEIVING packets on the monitored hosts.
Why don't you send an edicap chopped (we really only need the headers)
packet trace where you see the most number of issues.
In general, you have to go through the following checklist
1) Make sure you're not capturing on the INGRESS *and* EGRESS point on
the switch. For example, if you capture the entire VLAN, you'll capture
the same packet as it enters and exits the switch.
2) Make sure you're not dropping on the monitoring (span'ed) switch
port. So as you're mirroring your server's packets to the port
connected to the PC running Wireshark, keep an eye on the switch port
(span destination) to see if the switch is losing packets during the
mirroring process.
3) If you are capturing on the server itself, monitor that server's port
to make sure traffic destined for the server is not being dropped. (and
of course, see if Wireshark tells you that it dropped packets as well).
Now, you have to figure out if any packet losses are real or if they are
just an artifact of switches losing packets during the mirroring process.
For example, if you see a gap in tcp conversation (packet out of order,
previous packet lost alerts in wireshark), but you never ever see a
retransmission, it's a good indication that it was only lost during the
mirroring process.
If you see duplicate ACKs *everywhere* chances are that you're capturing
the same packet twice. To see if this is the case, look at the IP ID.
Do you see the same IP ID for the two ACKs? While this is not fool
proof, it's a good indication that you duplicated the packet. "editcap
-d" was designed to remove duplicates that are near each other (+/- 4
packets I believe).
Now, it's possible that you can look for tcp.seq==xxxx to see if a
retransmission occurred. However, this can get a little trick if SACK
is in use. In fact, this exact scenario will be covered during this
years Sharkfest.
Now, if the fast retransmits are real, and are triggered by triple
duplicate ACKs, then you have a real packet loss problem.
It might be best if you upload a sample so we can help you with reading
the trace file. Again, you should chop it up as we only need about 128
bytes of the packet.
--
Thanks,
Hansang
