Radium/ra client tools flow timestamps oddities with direct Netflow

[John Gerth]

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      gerth at graphics.stanford.edu  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 <iglesias at uci.edu <mailto: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 <mailto: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/20171204/5119c472/attachment.html>