Detect packet drops

[Carter Bullard]

I would give it a try none the less.  As I said argus does differentiate between TCP sequence number loss, out of order packets  and retransmission, so if the TCP doesn't have retansmissions, but the sensor doesn't see all the packets, argus will report loss.  The hard part is undestanding that the loss is due to sensor loss rather than data path loss.  

Because argus provides TCP sequence numbers you can / could see that the total bytes observed vs the bytes successfully transmitted are different.

I think you can do a first step guess iwith the existing tools. The argus data has most of what you need to figure it out, not sure you can do it just with the fields we print out.

Carter

On Oct 26, 2011, at 7:19 AM, elof2 at sentor.se wrote:

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