Argus giving wrong bytes results ?

carter at qosient.com carter at qosient.com
Tue Jun 8 20:22:41 EDT 2010


Hey Mike,
This is not good.  I'll have time to fix this Thursday.  If you have packet data that replicates the problem, that would most helpful.  How were you running the programs?

Carter 

Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Mike Tancsa <mike at sentex.ca>
Date: Tue, 08 Jun 2010 14:46:03 
To: <carter at qosient.com>
Cc: <argus-info at lists.andrew.cmu.edu>
Subject: Re: [ARGUS] Argus giving wrong bytes results ?


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.




More information about the argus mailing list