Argus memory issues

[Carter Bullard]

So it looks like we could be just processing a massive amount of
flows.  I do have a fixed memory model for argus, so that we don't
grow over a certain memory foot print, we'll aggressively reclaim
records and hold low packet flows for only the status interval,
(usually 5 secs),  that may work very well for you.

So what are we thinking then, are we not leaking memory and you've got
a lot of flows?  Should I switch to thinking about how to keep your
argus better behaved?

Carter



On Aug 19, 2007, at 10:48 PM, Peter Van Epp wrote:

> On Sun, Aug 19, 2007 at 07:04:50PM -0700, Mike Iglesias wrote:
>> Peter Van Epp wrote:
>>> 	That has been my experience too. I tried going back to versions  
>>> that
>>> I swear were working fine, but now they exhibit the same problem  
>>> and I don't
>>> know why. There may be a traffic issue though, my 2.0.6  
>>> production system
>>> while not eating memory (it has been at 256K since June last year  
>>> as I recall)
>>> is taking a long time in perl post processing, but I can't find  
>>> any obvious
>>> reason why. Scanning looks reasonably normal, traffic isn't  
>>> overly high. I too
>>> am wondering about storm because I too am not recognizing  
>>> anything I think
>>> is storm traffic (things have been quiet on the infection front  
>>> for months)
>>> and I expect I have storm infections here that I'm just not  
>>> seeing :-).
>>
>> Look for systems with a lot of UDP traffic to find stormworm, or  
>> recently,
>> skype.  The recent Skype problems have caused systems here to have  
>> over
>> 170,000 other systems talking to them via UDP.  You may be seeing  
>> some of
>> that, but that didn't start happening until Wed or Thurs last week.
>>
>>
>> -- 
>> Mike Iglesias                          Email:       iglesias at uci.edu
>> University of California, Irvine       phone:       949-824-6926
>> Network & Academic Computing Services  FAX:         949-824-2069
>
> 	Thats probably this one then:
>
> Our hosts scanning:
>
>     206.12.30.58          1,715,073          1,688,535
>    206.12.16.134            452,350             41,940
>
> 	the lead one I'd classify as skype because it mostly connects with
> the remote hosts. The planetlab machine (206.12.16.134) used to be  
> our usual
> top gun doing codeen refusals :-). As you say the top one started  
> Wednesday
> or so of last week, but isn't doing a lot of traffic (just a lot of  
> hosts)
> which would be sensible for skype because our packeteer is limiting  
> its
> bandwidth. Yep almost certainly skype:
>
> 17 Aug 07 12:00:53           udp    206.12.30.58.64973 <->     
> 213.243.12.1.29703 1        1         95           69          CON
> 17 Aug 07 12:00:53           udp    206.12.30.58.64973 <->    
> 201.82.71.152.39982 1        1         95           77          CON
> 17 Aug 07 12:00:53           udp    206.12.30.58.64973 <->     
> 80.132.18.11.8813  1        1         95           77          CON
> 17 Aug 07 12:00:53           udp    206.12.30.58.64973 <->   
> 200.218.240.62.12927 1        1         95           69          CON
> 17 Aug 07 12:00:53           udp    206.12.30.58.64973 <->      
> 193.88.6.58.11416 1        1         464          73          CON
> 17 Aug 07 12:00:53           udp    206.12.30.58.64973 <->    
> 201.22.47.231.61036 1        1         60           75          CON
> 17 Aug 07 12:00:53           udp    206.12.30.58.64973 <->  
> 192.195.234.145.33975 1        1         95           75          CON
> 17 Aug 07 12:00:53           udp    206.12.30.58.64973 <->     
> 59.117.75.10.23119 1        1         95           72          CON
>
> skype directory lookup (although unsuccessful this time):
>
> 17 Aug 07 12:05:22     I     udp    206.12.30.58.64973  ->   
> 63.209.144.212.33033 1        0         64           0           INT
> 17 Aug 07 12:05:26     I     udp    206.12.30.58.64973  ->   
> 63.209.144.212.33033 1        0         64           0           INT
> 17 Aug 07 12:05:30     I     udp    206.12.30.58.64973  ->   
> 63.209.144.212.33033 1        0         64           0           INT
> 17 Aug 07 12:05:32     I     udp    206.12.30.58.64973  ->   
> 63.209.144.212.33033 1        0         64           0           INT
> 17 Aug 07 12:05:36     I     udp    206.12.30.58.64973  ->   
> 63.209.144.212.33033 1        0         64           0           INT
> 17 Aug 07 12:06:14     I     udp    206.12.30.58.64973  ->   
> 63.209.144.217.33033 1        0         159          0           INT
> 17 Aug 07 12:06:16     I     udp    206.12.30.58.64973  ->   
> 63.209.144.217.33033 1        0         159          0           INT
>
> Peter Van Epp / Operations and Technical Support
> Simon Fraser University, Burnaby, B.C. Canada
>