Files for dates in the past and future when starting radium collection of netflow data

[Carter Bullard]

Hey Jesse,
I don't have any netflow v9 here, so I can't test the fixes I put in place.
Can I make a copy of the clients available to you for testing ????

Carter

On Jun 4, 2014, at 10:48 AM, Carter Bullard <carter at qosient.com> wrote:

> Hey Jesse,
> So wireshark thinks these are netflow v9 records.  Does this jive with your understanding ???
> The v9 support is less mature than the v5 support, so let me go through this and see what is up.
> 
> Carter
> 
> On Jun 4, 2014, at 10:12 AM, Jesse Bowling <jessebowling at gmail.com> wrote:
> 
>> Hi Carter,
>> 
>> This is:
>> 
>> Red Hat Enterprise Linux Server release 6.5 (Santiago)
>> Linux test 2.6.32-431.17.1.el6.x86_64 #1 SMP Fri Apr 11 17:27:00 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
>> 
>> It is a VM, if that makes a difference...
>> 
>> Thanks!
>> 
>> Cheers,
>> 
>> Jesse
>> On Jun 4, 2014, at 9:59 AM, Carter Bullard <carter at qosient.com> wrote:
>> 
>>> Hey Jesse,
>>> Thanks for making the change to the " new " way of doing things.
>>> These records are all screwed up, so there maybe a radium bug.
>>> Let me work on this....
>>> 
>>> Just a few things.  What platform is your radium running on??  32 or 64  bit???
>>> 
>>> Carter
>>> 
>>> On Jun 4, 2014, at 9:12 AM, Jesse Bowling <jessebowling at gmail.com> wrote:
>>> 
>>>> Hello Carter,
>>>> 
>>>> I uploaded one file to you yesterday based on my previous config. Today I tried changing the configuration of radium to comment out “RADIUM_CISCONETFLOW_PORT” and only use " RADIUM_ARGUS_SERVER=cisco://...”. This seemed to make no difference in what I’m seeing, as I still get the wide spread of records.
>>>> 
>>>> I’m using argus-clients Version 3.0.7.31 from Jun 2nd.
>>>> 
>>>> I’m uploading a new tcpdump + flow file archive momentarily...
>>>> 
>>>> Cheers,
>>>> 
>>>> Jesse
>>>> 
>>>> On Jun 3, 2014, at 11:41 AM, Carter Bullard <carter at qosient.com> wrote:
>>>> 
>>>>> Hey Jesse,
>>>>> Although, what you’re doing is fine, you are using an obsoleted method for getting netflow records.
>>>>> 
>>>>> You should use:
>>>>> #RADIUM_ARGUS_SERVER=cisco://192.168.0.4:9699
>>>>> 
>>>>> where the address is the address of the data source.
>>>>> 
>>>>> More than likely, the date problems are coming from the netflow records
>>>>> themselves, as we just do what the netflow records say is the time. 
>>>>> You could write a copy of the stream to a file, and we can check if
>>>>> radium is generating good timestamps, but rasplit() is messing up.
>>>>> 
>>>>> If you could upload the packet file to ftp at ftp.qosient.com:incoming and I’ll check it out.
>>>>> 
>>>>> Carter
>>>>> 
>>>>> 
>>>>> On Jun 3, 2014, at 9:59 AM, Jesse Bowling <jessebowling at gmail.com> wrote:
>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> I have a radium client listening on port 9995 collecting netflow records from a remote source (v5). When I attach an rasplit client configured to split on 5 minute files, I get files for dates ranging from April 26th to July 15th (from a test run this morning).
>>>>>> 
>>>>>> I’m curious what the issue might be, any help?
>>>>>> 
>>>>>> $ egrep -v '^#|^[ \t]*$' /etc/radium.conf 
>>>>>> RADIUM_DAEMON="yes"
>>>>>> RADIUM_MONITOR_ID=<snip>
>>>>>> RADIUM_MAR_STATUS_INTERVAL=60
>>>>>> RADIUM_CISCONETFLOW_PORT=9995
>>>>>> RADIUM_ACCESS_PORT=561
>>>>>> RADIUM_BIND_IP=127.0.0.1
>>>>>> 
>>>>>> Started with:
>>>>>> 
>>>>>> radium -f /etc/radium.conf
>>>>>> /usr/local/bin/rasplit -M time 5m -w /srv/argus/%Y/%m/%d/argus.%Y.%m.%d.%H.%M.%S -d -S 127.0.0.1
>>>>>> 
>>>>>> I also made a tcpdump of the startup process, Carter, in case that would be useful. Please let me know where to upload it if it would be handy.
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> Jesse
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6837 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20140604/09c448e7/attachment.bin>