Argus giving wrong bytes results ?

Mike Tancsa mike at sentex.ca
Tue Jun 8 14:46:03 EDT 2010


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