Detect packet drops

[elof2 at sentor.se]

Hi Carter!

1.
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 
wire.

(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 
sniffed traffic?



2.
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
            sploss
            dploss


3.
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?

/Elof



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
> 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
>>
>> /Elof
>>
>>
>