[ARGUS] the packet and byte count are unreasonably high

[Carter Bullard]

Hey Ming,
Sorry for the delayed response …
A few questions, and if you would respond to the mailing list that would be great …
Looks like you’re experiencing a bug, so if you can help us debug it that would also be great …

Do you have a sense of the percent errant records ?  Looks like you have 4 bad records, out how many ???
You can use rasort.1 to sort the flow for you, like:

   rasort -r archive -m spkts

Which may give you some control over seeing what the trends might be, if there are any ...

If you notice, the errant records are all the same flow, x.62277 -> y.445 … are there other records for this flow that look correct ??  Is this a production flow, or is it from a test ??

   ra -r archive - tcp and src port 62277 and dst port 445 

These are all TCP connections … TCP can you print the “stcpb” and “dtcpb” and the state when you print out these records ???
To help in understanding the extent of the error, can you also print out the “sloss”, “sretrans”, “dloss” and “dtretrans” ???  If these are reasonable values that will help diagnose.

The pkt and byte counters are 64-bit ints … some 32-bit machines can be very ’strange’ with 64-bit values, is either argus or your archiver a 32-bit machine ???
When you configure, does your machine support the XDR library ???   (“ checking for rpc/xdr.h… yes “)

Rather than printing the stime and ltime, if you could print the stime and our, that is an important value …
Does this happen every day ?  Every hour ??

These issues are pretty easy to find, I suspect a type mismatch processing something around the metrics DSR buffer, although we’ve been very careful of this for many years … but you never know …

And if you could share the errant flows … something like this should work …

   ra -r archive -w big.flow.problem.out - src pkts gt 4000000000

The filter currently handles only 32-bit values, I’ll fix that early next week ...

Carter


> On Nov 1, 2024, at 2:58 PM, Ming Fu via Argus-info <argus-info at lists.andrew.cmu.edu> wrote:
> 
> Hi,
> 
> Does anyone have similar problem? This happens to us from time to time. The read out from the archive has packets and bytes counter that are impossibly high.
> We are running the argus from 5.0.0 branch. This also happens to the 3.x argus before we upgraded to v5. I was hopping the upgrade to v5 would solve this problem, but it still happens.
> 
> ra -L -1 -c' ' -n -s dbytes,stime,ltime,saddr,daddr,proto,spkts,dpkts,sport,dport,sbytes  -r archive | sort -n
> ....
> Skip the lower counts
> ...
> 
> 3999669780 10/11.22:14:36.569519 10/11.22:15:05.029679 10.61.6.12 10.49.40.72 tcp 377597 2789170 62275 445 23006913
> 4185639434 10/11.22:12:16.415003 10/11.22:12:44.906949 10.61.6.12 10.49.40.72 tcp 182047 2918859 62268 445 11087544
> 14753212661760 10/11.22:16:52.131629 10/11.22:17:22.201542 10.61.6.12 10.49.40.72 tcp 845322578559266 17187209216 62277 445 3460172017553113607
> 2305843022098595842 10/11.22:18:22.302991 10/11.22:18:52.361259 10.61.6.12 10.49.40.72 tcp 4629700418014806016 5188147880946339125 62277 445 1077936128
> 2305843022098595842 10/11.22:18:52.361328 10/11.22:19:22.380591 10.61.6.12 10.49.40.72 tcp 4899986764475894443 5188147880946341913 62277 445 4953075936113354752
> 4706261611810128643 10/11.22:15:52.069615 10/11.22:16:22.104070 10.61.6.12 10.49.40.72 tcp 3458764519289913606 4665729215040269099 62277 445 13950255104
> 7514215852137765761 10/11.22:17:52.215696 10/11.22:18:22.302887 10.61.6.12 10.49.40.72 tcp 0 926742273327104 62277 445 1728685102
> 
> Regards,
> Ming
> 
> 
> _______________________________________________
> argus mailing list
> argus at qosient.com
> https://pairlist1.pair.net/mailman/listinfo/argus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1385 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20241103/22371023/attachment.bin>