Argus giving wrong bytes results ?
Riccardo Veraldi
Riccardo.Veraldi at cnaf.infn.it
Fri Jul 9 10:20:10 EDT 2010
IT happened to me that netflow results analyzed with netflow-analyzer
were completely different
from network traffic measured by mrtg regarding some specific machines
which where behind a specific
switch port so that I Could compare mrtg statistics with netflow
statistics and results where as I Said
completely different, apparently Netflow was not reliable. I was using
Netflow v5 protocol.
I still have not tried with argus but I Am going to do it soon
Rick
Mike Tancsa wrote:
> At 12:39 PM 7/6/2010, Carter Bullard wrote:
>> Hey Mike,
>> I did make some changes to the clients to deal with your netflow
>> problem.
>> Did you get a chance to test whether the latest radium() is behaving
>> better?
>
> Hi Carter,
> Sorry for the delay. I just tried with the latest version, and
> still I am getting bogus netflow results. I built radium on FreeBSD
> 7.3 just with the default ./configure
>
>
> racluster -L0 -nr radium.arg - srcid 192.168.1.82 | head
> StartTime Flgs Proto SrcAddr Sport Dir
> DstAddr Dport TotPkts TotBytes State
> 21:57:00.190000 Ne udp 192.168.1.118.123 ->
> 192.168.1.82.123 86469112 1037629354 INT
> 21:57:11.670000 Ne tcp 192.168.1.81.62830 ->
> 10.1.1.3.9010 5 403 FIN
> 21:57:14.706000 Ne tcp 192.168.1.81.59931 ->
> 10.1.1.3.9010 36028797 8358962383 FIN
> 21:57:16.186000 Ne tcp 192.168.1.81.51973 ->
> 10.1.1.3.9010 5 403 FIN
> 21:57:19.730000 Ne tcp 192.168.1.81.58569 ->
> 10.1.1.3.9010 5 403 FIN
> 21:57:23.886000 Ne tcp 192.168.1.81.55401 ->
> 10.1.1.3.9010 6 407 FIN
> 21:57:24.794000 Ne tcp 192.168.1.81.63774 ->
> 10.1.1.4.9010 5 402 FIN
> 21:57:26.006000 Ne tcp 192.168.1.81.51267 ->
> 10.1.1.3.9010 5 403 FIN
> 21:57:26.134000 Ne tcp 192.168.1.81.53147 ->
> 10.1.1.3.9010 36028797 8431019977 FIN
>
> ---Mike
>
>
>> Carter
>>
>> On Jun 10, 2010, at 11:11 AM, Mike Tancsa wrote:
>>
>> > At 11:08 AM 6/10/2010, Carter Bullard wrote:
>> >> 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.
>> >
>> > Hi,
>> > I was just putting it together when your email came in :) I
>> will send offlist.
>> >
>> > ---Mike
>> >
>> >> 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
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
>> 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
>>
>>
>>
>>
>
More information about the argus
mailing list