Radium/ra client tools flow timestamps oddities with direct Netflow

[Carter Bullard]

Hey Drew,
Just as John and Mike are suggesting, none of the ra* programs “calculate" the timestamps.  All timestamps come from from the flow originator, which is in your case your router.  You can modify the timestamps through a number of programs, such as radium.1, ranonymize.1, but none of these are a solution that addresses your problem.

Either your router is way off in its time, or your printing the time zone.   Print the timestamps using the “-u” option, which will print in Unix time, then check to see what your system thinks of that timestamp.

   % ra -S localhost -u -N 1

            StartTime        Dur      Flgs  Proto            SrcAddr  Sport   Dir  DstAddr  Dport  SrcPkts  DstPkts     SrcBytes     DstBytes State 
    1512485199.926479   0.000000  e        ipv6-* fe80::1c09:e361:4*.135       ->  ff02::1               1        0           86            0   NNS

   % date -r 1512485199

    Tue Dec 5 09:46:39 EST 2017


Which is the correct time here.  If your Unix time is not correct, then the problem is in the box that is reporting the time.  If it is correct, then the problem is in your printing of the timezone, I would think. What we print from the timestamp fields is configured in your .rarc file, or your /etc/ra.conf file if you have one.  By default, we print local time, but you can set any time zone you would like.  Here is the configuration for EST ….

RA_TZ=“EST5EDT4,M3.2.0/02,M11.1.0/02"

Carter

> On Dec 4, 2017, at 11:55 AM, Drew Dixon <dwdixon at umich.edu> wrote:
> 
> We are in EST, output of the date command confirms EST (Mon Dec  4 11:50:46 EST 2017) so the difference between EST and GMT/UTC should be 5 hours for us rather than 8 where you're at, which is a big part of the reason why I'm kind of baffled here.  All upstream devices before the data hits my radium system were confirmed to be setup with ntp and properly configured with the same timezone (EST) etc..
> 
> An update on the -T option testing with radium...I just tested that, but I couldn't get it to accept a setting specified in hours (I tried -T 8h...-T8h...) both failed saying invalid parameter, so I converted 8 hours to seconds (28800) and that seemed to be accepted without throwing errors but it doesn't seem like the timestamps are being adjusted at all, still showing timestamps that are 8 hours in the future from current EST...
> 
> ***** From the radium man page *****
> -T threshold[smh] (secs)
> Indicate that radium should correct the timestamps of received argus records, if they are out of sync by threshold seconds. Threshold can be specified with the extensions s, m, or h for seconds, minutes or hours.
> *******************************************
> 
> The threshold doesn't really seem to specify a direction so I'm not sure if the threshold would adjust forward or backwards but it doesn't seem to be adjusting the timestamps at all, it's currently set like ....   -T28800
> 
> Thank you,
> 
> -Drew
> 
> On Mon, Dec 4, 2017 at 11:45 AM, Mike Iglesias <iglesias at uci.edu> wrote:
> On 12/04/2017 08:03 AM, Drew Dixon wrote:
> > I suppose to boil it down, I can't really seem to understand why the timestamps
> > are off by 8 hours in the future when the netflow data is certainly not delayed
> > in being processed by radium/racluster more than an hour or so at the very
> > most, for some flows- but probably more like ballpark ~10 minutes or so on
> > average.  Right now the only thing that might make sense is that radium is not
> > calculating the timestamps properly but I'm not certain.
> 
> 8 hours is the difference between US Pacific Standard Time and GMT/UTC.  What
> time zone does your system think it's in?  Use the "date" command to find out.
> 
> 
> --
> Mike Iglesias                          Email:       iglesias at uci.edu
> University of California, Irvine       phone:       949-824-6926
> Office of Information Technology       FAX:         949-824-2270
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20171205/d7f608d8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4045 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20171205/d7f608d8/attachment.bin>