[ARGUS] [RE]Re: argus.conf explanation of timeout queue configuration

Carter Bullard carter at qosient.com
Sat Apr 2 16:07:26 EDT 2022


Hey Koohong,
I think that they are similar, but there are some real differences …. If a flow has packets it is active, and while its active we will report every ARGUS_FLOW_STATUS_INTERVAL.  This does seem to be ATO, but it is ITO that is confusing.  In argus, once a flow reports, it goes into the ITO state.  If a packet shows up, the flow immediately goes to the ATO status … The end result is if a flow gets to the end of the ITO, there isn’t anything to report, so we do not generate a flow record.

Carter


> On Apr 1, 2022, at 11:52 PM, Koohong Kang <khkang at seowon.ac.kr> wrote:
> 
> 
> 
> Hello Cart,
> 
> 
> 
> As you know well, there are two timers in Cisco Netflow,
> 
> such as a flow active timeout and a flow inactive timeout.
> 
> 
> 
> + IP packet for a given 5-tuple
> 
> ATO : active flow time out
> 
> ITO : inactive flow time out
> 
> F : flow generation
> 
> 
> 
> +----+------------------+--+------+------+---+---+----> time
> 
>          |<---------->|        |<-------------------->|
> 
>                    ITO        F                         ATO                F
> 
> 
> I think that ARGUS_FLOW_STATUS_INTERVAL works as if ATO,
> 
> and ARGUS_IP_TIMEOUT works as if ITO.
> 
> 
> 
> # If the flow cache remains idle for the protocol specific timeout period,
> # Argus will delete the flow, and 'forget' any information that it may have
> # observed for the flow.
> 
> 
> I think that the only difference between Argus and Cisco Netflows is that
> 
> you do NOT generate the flow record when ITO. Am I right?
> 
> 
> 
> Koohong
> 
> 
> 
>> 
>> -----------Original Message-----------
>> Sender : Carter Bullard < carter at qosient.com >
>> To : Koohong Kang < khkang at seowon.ac.kr >
>> CC : Argus < argus-info at lists.andrew.cmu.edu >
>> Date : 2022-04-02 00:10:17
>> Subject : Re: argus.conf explanation of timeout queue configuration
>> 
>> Hey Koohong,
>> I have added some text in the sample argus.conf file to provide more detail on the timeout queue configuration.
>> Take a look and if this helps, I’ll put it it the distribution.
>> 
>> Carter
>> 
>> # Argus has a number of flow cache timers that specify how long argus
>> # will 'remember' the cache of idle flows.  When a flow cache is generated,
>> # it exists in the active flow status queue.  When the status interval is
>> # 'done', the flow is reported, can the flow cache is placed on a protocol
>> # specific timeout queue.  If new packets come in that match the flow cache,
>> # the cache is removed from the timeout queue, and placed back on the active
>> # status queue.  Flows can go through this cycle indefinately.
>> #
>> # If the flow cache remains idle for the protocol specific timeout period,
>> # Argus will delete the flow, and 'forget' any information that it may have
>> # observed for the flow.
>> #
>> # The default values for specific protocols have been chosen to aggresively
>> # timeout flow caches for traditionally short lived flows to conserve memory
>> # utilization, and to provide retention of long lived flows, based on the
>> # average length of their idle period.
>> #
>> # Increasing timeout values will have an impact on argus memory use, so
>> # take care when modifying values.
>> #
>> # The maxium value for any timeout is 65534 seconds.
>> #
>> # If you think there is a flow type that doesn't have appropriate
>> # timeout support, send email to the developer's list, we'll add one
>> # for you.
>> #
>> 
>> 
>> 
>>> On Apr 1, 2022, at 1:32 AM, Koohong Kang <khkang at seowon.ac.kr <mailto:khkang at seowon.ac.kr>> wrote:
>>> 
>>> 
>>> 
>>> Hi Carter,
>>> 
>>> Thank you for your kind and swift reply.
>>> 
>>> Yes, the ARGUS_FLOW_STATUS_INTERVAL is working well to reduce the number of flows.
>>> 
>>> By the way, I think that the comments about the timers in the argus.conf sample file
>>> 
>>> "argus-3.0.8.2/support/Config/argus.conf" are not understandable enough for their usage.
>>> 
>>> I mean that the explanation of ARGUS_IP_TIMEOUT or ARGUS_TCP_TIMEOUT seems appropriate
>>> 
>>> for the flow timeout under the idle state (like Cisco NetFlow Time Out Timer).
>>> 
>>> Anyway, do you have any resources for me to learn how to use them?
>>> 
>>> 
>>> 
>>> Thank you very much for your help.
>>> 
>>> 
>>> 
>>> Koohong
>>> 
>>> 
>>>> 
>>>> -----------Original Message-----------
>>>> Sender : Carter Bullard < carter at qosient.com <mailto:carter at qosient.com> >
>>>> To : Koohong Kang < khkang at seowon.ac.kr <mailto:khkang at seowon.ac.kr> >
>>>> CC : Argus < argus-info at lists.andrew.cmu.edu <mailto:argus-info at lists.andrew.cmu.edu> >
>>>> Date : 2022-03-31 22:21:58
>>>> Subject : Re: About Argus
>>>> 
>>>> Hey Koohong,
>>>> There are a lot of internal timers !!  But there is only one that will potentially decrease the number of flow records coming from argus.   That is the ARGUS_FLOW_STATUS_INTERVAL.
>>>> This variable specifies how often argus will report on long lived flows.  The default is 5 seconds, but you can increase that to any number.  Some like 60.
>>>> 
>>>> What happens when you increase this variable?  You will report on ongoing flows every 60 seconds, rather than 5s.  If you have a lot of long lived flows, then the flow count will go down.
>>>> 
>>>> What are the negatives ???  Well … #1 is you will use more memory, which can be a big problem.  You will hold short lived flow caches in memory long after they are finished.   #2 is that if you are processing real-time flows, your analytics won’t see network activity until 60 seconds after it occurs.  For some, that is a no starter.  I like 5 seconds, so that live analytics can see traffic sooner, and then I post-process the files with the program racluster.1.
>>>> 
>>>> % racluster -r argus.file -w racluster.argus.out
>>>> % racount -r argus.file
>>>> % racount -r racluster.argus.out
>>>> 
>>>> If these counts from racount.1 are similar, then increasing the ARGUS_FLOW_STATUS_INTERVAL will not help you much, because the network traffic you are watching is composed of a lot of short flows.  If that is the case, increasing the interval will just waste resources and make argus slower.  BUT, if the numbers are really different, then increasing the ARGUS_FLOW_STATUS_INTERVAL will decrease argus’s output.
>>>> 
>>>> There are a few  ra* programs that can help you manage the flow counts, racluster.1, rabins.1.  It maybe that they can help you.
>>>> 
>>>> Carter
>>>> 
>>>> 
>>>>> On Mar 31, 2022, at 2:39 AM, Koohong Kang <khkang at seowon.ac.kr <mailto:khkang at seowon.ac.kr>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Hello Carter,
>>>>> 
>>>>> 
>>>>> Nowadays I am using your valuable tool Argus for my project.
>>>>> 
>>>>> By the way, I would like to ask a question about Argus.
>>>>> 
>>>>> As you know well, there are a number of state timers in the argus.conf files
>>>>> 
>>>>> that expires the flows under the idle state.
>>>>> 
>>>>> I am wondering what if we increase these timer values.
>>>>> 
>>>>> I think that if  ARGUS_IP_TIMEOUT is increased from 30 to 60,
>>>>> 
>>>>> then the number of generated flows should be decreased
>>>>> 
>>>>> because the flows under idle state stay much longer at the caches.
>>>>> 
>>>>> However, the results from Argus are the exact opposite of what I expected,
>>>>> 
>>>>> that is the number of flows are increased.
>>>>> 
>>>>> What am I doing wrong?
>>>>> 
>>>>> Could give me any comments, please?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Thanks in advance,
>>>>> 
>>>>> 
>>>>> Koohong
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> ----------------------------------------------
>>>>> Prof. Koohong Kang
>>>>> Dept. of Information and Communications Eng.
>>>>> Seowon University, Cheongju, 361-742, South Korea
>>>>> Tel:+82-43-299-8773, Fax:+82-43-299-8710
>>>>> Homepage: http://poisson.seowon.ac.kr <http://poisson.seowon.ac.kr/> 
>>>> 
>>> 
>>> 
>>> 
>>> ----------------------------------------------
>>> Prof. Koohong Kang
>>> Dept. of Information and Communications Eng.
>>> Seowon University, Cheongju, 361-742, South Korea
>>> Tel:+82-43-299-8773, Fax:+82-43-299-8710
>>> Homepage: http://poisson.seowon.ac.kr <http://poisson.seowon.ac.kr/> 
>> 
> 
> 
> 
> ----------------------------------------------
> Prof. Koohong Kang
> Dept. of Information and Communications Eng.
> Seowon University, Cheongju, 361-742, South Korea
> Tel:+82-43-299-8773, Fax:+82-43-299-8710
> Homepage: http://poisson.seowon.ac.kr <http://poisson.seowon.ac.kr/> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20220402/dca10a85/attachment-0001.htm>


More information about the argus mailing list