Argus giving wrong bytes results ?

Carter Bullard carter at qosient.com
Thu Jun 10 11:08:26 EDT 2010


Hey Mike,
I'll need to get either your argus data file, or a flow-tools like netflow file, or the pcap to fix this problem,
if that is workable for you.    Can't seem to replicate it here with anything I have.

Carter

On Jun 8, 2010, at 2:44 PM, Mike Tancsa wrote:

> 
> Actually, I think I found what might be a bug in radium at least.  Using the lastest dev version (Radium Version 3.0.3.11), I get some strange netflow results as compared to radium 3.0.2.  The packet counts should be 5, not 36028797.  I can send pcaps offline of the netflow data if you like. Its just from a tiny cisco Frame router.  Starting up the old version of radium gives the correct results. I use the same .conf file for both.
> 
> 12:28:53.988000 Ne         tcp     192.168.135.81.51857     ->      10.10.197.3.9010         5        402 FSPA_
>   12:28:54.709000 Ne         tcp     192.168.135.81.55318     ->      10.10.197.3.9010         5        386 FSPA_
>   12:28:55.517000 Ne         tcp     192.168.135.81.53690     ->      10.10.197.3.9010         5        403 FSPA_
>   12:28:55.617000 Ne         tcp     192.168.135.81.60303     ->      10.10.197.3.9010         5        403 FSPA_
>   12:28:58.433000 Ne         tcp     192.168.135.81.60752     ->      10.10.197.3.9010         5        403 FSPA_
>   12:28:58.713000 Ne         tcp     192.168.135.81.57136     ->      10.10.197.3.9010         5        403 FSPA_
>   12:29:02.969000 Ne         tcp     192.168.135.81.60152     ->      10.10.197.3.9010         5        401 FSPA_
>   12:29:04.297000 Ne         tcp     192.168.135.81.53716     ->      10.10.197.3.9010  36028797 8358962383 FSPA_
>   12:29:07.231000 Ne         tcp     192.168.135.81.51299     ->      10.10.197.3.9010  36028797 8358962383 FSPA_
>   12:29:15.879000 Ne         tcp     192.168.135.81.58679     ->      10.10.197.3.9010         5        401 FSPA_
>   12:29:17.887000 Ne         tcp     192.168.135.81.50642     ->      10.10.197.3.9010         5        403 FSPA_
>   12:29:19.111000 Ne         tcp     192.168.135.81.55935     ->      10.10.197.3.9010  36028797 8358962383 FSPA_
>   12:29:19.603000 Ne         tcp     192.168.135.81.51737     ->      10.10.197.3.9010  36028797 8431019977 FSPA_
>   12:29:25.389000 Ne         tcp     192.168.135.81.56375     ->      10.10.197.3.9010         5        411 FSPA_
>   12:29:29.993000 Ne         tcp     192.168.135.81.64352     ->      10.10.197.3.9010  36028797 8286904789 FSPA_
>   12:29:30.121000 Ne         tcp     192.168.135.81.53483     ->      10.10.197.3.9010         5        403 FSPA_
>   12:29:41.178000 Ne         tcp     192.168.135.81.51055     ->      10.10.197.3.9010         5        386 FSPA_
>   12:29:46.166000 Ne         tcp     192.168.135.81.52996     ->      10.10.197.3.9010         5        386 FSPA_
>   12:29:46.590000 Ne         tcp     192.168.135.81.65290     ->      10.10.197.3.9010         5        401 FSPA_
>   12:29:48.298000 Ne         tcp     199.212.135.83.54323     ->      10.10.197.3.9010         5        387 FSPA_
>   12:29:50.778000 Ne         tcp     192.168.135.81.53839     ->      10.10.197.3.9010  36028797 7926616819 FSPA_
>   12:29:52.671000 Ne         tcp     192.168.135.81.55540     ->      10.10.197.3.9010  36028797 7998674413 FSPA_
>   12:29:54.507000 Ne         tcp     192.168.135.81.59975     ->      10.10.197.3.9010         5        386 FSPA_
> 
> 
> At 06:33 AM 6/8/2010, carter at qosient.com wrote:
>> There is a HUGE difference between per transaction flow data and interface counters. If you simply print out your Argus data, you can see this. ra -r argus.data.file You have to transform the bi-directional flow data, that accounts for conversations, into RMON style data, that counts ingress and egress packets based on a layer 2 address.If you want to compare SNMP interface counters with Argus data, you will need to use any aggregator, such as racluster, ragator, or rabins, using the "rmon" mode, modifying the flow key to track one of the Mac addresses in the records. racluster -m smac -M rmon -r argus.data.fileNow the src and dst counters will look like interface egress and ingress counters, respectively.ragraph(), supports this style of aggregation. ragraph sbytes dbytes -t time 5s -m smac -M rmon -r argus.data.fileBUT, you will have to modify your argus.conf to enable ARGUS_GENERATE_MAC_DATA so that you have layer 2 information in your argus data.Carter
>> 
>> Sent from my Verizon Wireless BlackBerry
>> From: Reykjavik hindisvik <hindisvik at gmail.com>
>> Date: Mon, 7 Jun 2010 12:23:23 +0200
>> To: <carter at qosient.com>
>> Cc: <argus-info-bounces+carter=qosient.com at lists.andrew.cmu.edu>; Argus<argus-info at lists.andrew.cmu.edu>
>> Subject: Re: [ARGUS] Argus giving wrong bytes results ?
>> Hello,
>> 
>> Thank you for your answers. I have tried using sapp_bytes and dapp_bytes, the result downloading a file seems to be correct but it does not fix my issue : Outbound traffic is not really OK and Inbound is absolutely wrong (50Mb instead of 100Mb...)
>> 
>> What I would like to do is tu use the result of racount -r xxx.xxx.xxx.xxx.ra to draw a graph with cacti.
>> One problem is the ra file will be huge so I'm compelled to rotate it every 5 minutes, and I have to tell Cacti it's a Gauge data source, not a counter data source.
>> Has anyone ever tried to do this?
>> Is there a argus command which will be more appropriated than raccount ?
>> 
>> Before using Argus I was using SNMP with InOctets and OutOctet, and on Linux deveices I was using Iptables+accounting (which was giving me a COUNTER type cacti value).
>> 
>> Here is my agent server conf file :
>> 
>> ARGUS_FLOW_TYPE="Bidirectional"
>> ARGUS_FLOW_KEY="CLASSIC_5_TUPLE"
>> ARGUS_DAEMON=yes
>> ARGUS_MONITOR_ID=`hostname`
>> ARGUS_ACCESS_PORT=561
>> ARGUS_INTERFACE=eth1
>> ARGUS_SET_PID=yes
>> ARGUS_PID_PATH="/var/run"
>> ARGUS_FLOW_STATUS_INTERVAL=0.5
>> ARGUS_MAR_STATUS_INTERVAL=60
>> ARGUS_DEBUG_LEVEL=0
>> ARGUS_GENERATE_RESPONSE_TIME_DATA=no
>> ARGUS_GENERATE_PACKET_SIZE=no
>> ARGUS_GENERATE_JITTER_DATA=no
>> ARGUS_GENERATE_MAC_DATA=no
>> ARGUS_GENERATE_APPBYTE_METRIC=yes
>> 
>> Thanx you for your ideas, I'm a bit stuck...
>> 
>> H.
>> 
>> 
>> 2010/6/7 <<mailto:carter at qosient.com>carter at qosient.com>
>> Also, Argus uses a different definition for source and destination since Argus works with flow data not interface data, and that can cause confusion.
>> 
>> What are the differences that you are seeing? How are you running the client programs?
>> 
>> Carter
>> 
>> Sent from my Verizon Wireless BlackBerry
>> 
>> ----------
>> From: Reykjavik hindisvik <<mailto:hindisvik at gmail.com>hindisvik at gmail.com>
>> Date: Sun, 6 Jun 2010 09:31:42 +0200
>> To: <<mailto:argus-info at lists.andrew.cmu.edu>argus-info at lists.andrew.cmu.edu>
>> Subject: [ARGUS] Argus giving wrong bytes results ?
>> 
>> Hello,
>> 
>> I would like to use argus to draw graph of bandwidth usage for our network. Today, I'm using SNMP which give me a graph of my bandwidth, and I've setup Argus which draw the same graph for the same Network Interface but does not give me the same results at all...
>> 
>> I can't believe it's a bug but I bet it's just a different way to get the packets and maybe there's an option to get the same results as I have with SNMP.
>> 
>> For example : When I download a 130Mb File, SNMP show me 130MB, but Argus show me much more (maybe be it includes size of header or something that SNMP don't...) and for me the result in the right.
>> So my question is :
>> 
>> 1) What does exactly makes the difference ?
>> 2) Is there a way to get the same results (option or something...)
>> 3) Maybe I can recount it after with a math formula to get the same results, but which formula ?
>> 
>> Thanx for your ideas.
>> 
>> Best regards,
>> 
>> H.
>> 
> 
> --------------------------------------------------------------------
> Mike Tancsa,                                      tel +1 519 651 3400
> Sentex Communications,                            mike at sentex.net
> Providing Internet since 1994                    www.sentex.net
> Cambridge, Ontario Canada                         www.sentex.net/mike
> 
> 

Carter Bullard
CEO/President
QoSient, LLC
150 E 57th Street Suite 12D
New York, New York  10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax



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


More information about the argus mailing list