Re: Radium/ra client tools flow timestamps oddities with direct Netflow

The times reported by argus tools depend on the setting of the TZ environment variable. The actual data values in flow records are always recorded as
"unix epoch" (seconds since 1 Jan 1970).

If I'm remembering correctly from the original post, these were Netflow v5 flows being fed into argus. I think that means that the timestamps are
created by whatever process is creating the Netflow V5 upstream of argus. You should take a look at the clock settings on those devices.

John Gerth      [email protected]  Gates 378   (650) 725-3273 

On 12/4/17 8:55 AM, Drew Dixon 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 <[email protected] <mailto:[email protected]>> 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:       [email protected] <mailto:[email protected]>
>     University of California, Irvine       phone:       949-824-6926
>     Office of Information Technology       FAX:         949-824-2270
>
>