Radium netflow collection: many records in the future?

[Carter Bullard]

Hey Jesse,
Each netflow packet contains multiple netflow records, and the time for
all the flows in the packet is relative to a timestamp at the beginning of the packet.
If chunks of netflow records are wrong, I'd want to say that we're not getting
a good timestamp and its affecting blocks of data.  Of course, we could
be not parsing the timestamp correctly, as well, but that is less attractive ;O)

What are the durations of these flows?  "-s +1dur ".   We have to parse both
a starting time and an ending time.

It maybe useful to capture the netflow packet stream, with tcpdump, and
double check that argus and wireshark agree.

Also, do you get some records that look good, and then a chunk of flows
that are off, then it goes back to being good?

If you just attach to the radium with ra(), writing that to a file, we'll see what
the actual netflow data stream, which may show this type of behavior ?

Carter

On Jul 23, 2013, at 9:36 AM, Jesse Bowling <jessebowling at gmail.com> wrote:

> Hi,
> 
> I'm collecting neflow records with radium, using argus-clients 3.0.7.9. I've found that I have quite a few records that list start times in the future; sometimes two months in the future! I notice that almost all the records with future dates list a 5 minute boundary as the start time, i.e.:
> 
> # ra -r argus.2013.09.10.00.00.00 -N 10 -w - - | ranonymize -r -
>                      StartTime      Flgs  Proto            SrcAddr  Sport   Dir            DstAddr  Dport  TotPkts   TotBytes State 
>       09/10/13 00:00:00.000000 Ne            17            1.0.2.1.54076     ->            1.0.3.1.63008        43      60370   REQ
>       09/10/13 00:00:00.000000 Ne             6          100.0.1.1.52469     ?>            1.0.4.1.53624         2       2551   INT
>       09/10/13 00:00:00.000000 Ne             6          100.0.1.1.52469     ?>            1.0.4.2.53359         2       2545   INT
>       09/10/13 00:00:00.000000 Ne             6          100.0.1.1.52469     ?>            1.0.4.3.53572         1       1275   INT
>       09/10/13 00:00:00.000000 Ne             6          100.0.1.1.52469     ?>            1.0.4.4.54880         2       2553   INT
>       09/10/13 00:00:00.000000 Ne             6          100.0.2.1.39995     ?>            1.0.5.1.59243         1         45   INT
>       09/10/13 00:00:00.000000 Ne             6            1.0.5.1.59243     ?>          100.0.2.1.39995         3       2700   INT
>       09/10/13 00:00:00.000000 Ne             6          100.0.3.1.54214     ?>          100.0.4.1.80           17        782   INT
>       09/10/13 00:00:00.000000 Ne             6            1.0.6.1.80        ?>          100.0.5.1.42526        36      51113   INT
>       09/10/13 00:00:00.000000 Ne             6          100.0.5.1.42526     ?>            1.0.6.1.80            6        349   INT
> 
> Can anyone suggest a strategy for determining whether the fault lies within the argus processing, or the netflow generation?
> 
> Thanks,
> 
> Jesse
> 
> $ grep -Ev '^#|^[ \t]*$' /etc/radium.conf
> RADIUM_DAEMON=yes
> RADIUM_MAR_STATUS_INTERVAL=60
> RADIUM_CISCONETFLOW_PORT=9996
> RADIUM_ACCESS_PORT=561
> 
> $ grep -Ev '^#|^[ \t]*$' /etc/ra.conf 
> RA_SET_PID="no"
> RA_PID_PATH="/var/run"
> RA_RUN_TIME=0
> RA_PRINT_MAN_RECORDS=no
> RA_PRINT_EVENT_RECORDS=yes
> RA_PRINT_LABELS=0
> RA_FIELD_SPECIFIER="stime:24 flgs proto saddr sport dir daddr dport pkts bytes state"
> RA_PRINT_NAMES=none
> RA_CIDR_ADDRESS_FORMAT="yes"
> RA_PRINT_RESPONSE_DATA=no
> RA_PRINT_UNIX_TIME=no
> RA_TIME_FORMAT="%D %T.%f"
> RA_USEC_PRECISION=6
> RA_USERDATA_ENCODE=Ascii
> RA_DELEGATED_IP="/usr/local/argus/delegated-ipv4-latest"
> 
> Started with:
> 
> /usr/local/bin/radium -f /etc/radium.conf
> /usr/local/bin/rasplit -M time 5m -S 127.0.0.1:561 -w /argus/netflow/%Y/%m/%d/argus.%Y.%m.%d.%H.%M.%S &
> 
> Cheers,
> 
> Jesse
> 
> -- 
> Jesse Bowling
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130723/9ad8a106/attachment.html>
-------------- 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/20130723/9ad8a106/attachment.bin>