Detect packet drops
elof2 at sentor.se
elof2 at sentor.se
Wed Oct 26 07:19:11 EDT 2011
Hmmm, the manual says that the *loss fields counts packet loss OR
the amount of retransmissions.
Since I'm only interested in detecting drops I don't see how this help me.
I know it is hard to detect drops when you don't have the original data to
compare with, but it should be possible to get a rough drop estimate by
analysing e.g. tcp counters. The easiest way would be to look at a tcp
stream and note every gap there is. Gaps = packet loss.
If argus could distinguish between Loss and Retransmission, one could more
easily see the amount of "SPAN drops" and amount of retransmissions on the
(PS. From a discussion some year ago, in a perfect world, the
retransmission counter should also be split in two: One counter for tcp
retransmissions and one counter for duplicate packets, i.e. when the
sniffer get two copies of the exact same packet. The latter case is not
really retransmissions but rather a faulty SPAN setup.)
Oh well, I know all of this is quite obscure, hard to fix and would
inflict too many changes in the already existing *loss fields and in the
protocol flags field, so I don't expect argus to handle things as
perfectly as I would like.
Therefor my original question remain:
Is there a commandline tool that show me a rough estimate of drops in the
I found yet a typo in the manual. It says:
psloss percent source pkts retransmitted or dropped.
pdloss percent destination pkts retransmitted or dropped.
it should be
I'm just curious... How do the *loss counters in argus work?
If I have a single packet, a TCP SYN, this is registered by ra -Zb as:
spkts dpkts sloss dloss state
1 0 1 0 S_
Why is sloss=1 when only one packet exist?
On Tue, 25 Oct 2011, Carter Bullard wrote:
> You can print % loss for a number of flow types, TCP, RTP, ESP, but if you aggregate all the flow records to try to get a singular loss ratio for the whole "wire", the way aggregation is done, we may not retain loss, if the protocols merged don't all have loss metrics.
> This is a hard detection problem, but you should be able to detect large %loss situations with existing tools. If you print loss as a percent:
> racluster -r file -m proto -s stime dur sploss dploss - tcp
> Do you get anything that looks useful?
> Carter Bullard, QoSient, LLC
> 150 E. 57th Street Suite 12D
> New York, New York 10022
> +1 212 588-9133 Phone
> +1 212 588-9134 Fax
> On Oct 25, 2011, at 10:17 AM, elof2 at sentor.se wrote:
>> Hi Carter and list!
>> Is there any way to easily detect loss in SPAN-traffic?
>> If I mirror two 1 Gbps full-duplex ports to a 1 Gbps SPAN port, in theory the switch could try to copy 4 Gbps onto it, resulting in dropped packets.
>> The sniffer machine receiving the mirrored traffic could be heavily loaded and drop packets.
>> In protocols such as TCP, these drops are detectable, due to gaps in the sequence counters.
>> Generating a pcap-file, scp:ing it to a machine running wireshark and then looking at the expert info is such a hassle. I'm looking for a commandline tool that show me when packets are missing (by printing a * for every missed packet) or giving me an estimated ratio of drops per minute.
>> Is there such a tool?
>> I'm guessing that argus can't help me, since it doesn't distinguish between loss and retransmissions in the 'flgs' field:
>> * - Both Src and Dst loss/retransmission
>> s - Src loss/retransmissions
>> d - Dst loss/retransmissions
More information about the argus