cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4023
Views
0
Helpful
2
Replies

ISE 2.2 timestamp format and timezone string in logs and reports

Marc Luethi
Level 1
Level 1

Hi all

 

We have an ISE 2.2 Patch 13 setup, and followed the recommendation in the Install Guide to set UTC for the deployment. 

 

The customer has limited admin access to the ISE's live logs and radius logs, but is not quite happy with the timestamps in the logs, as they hold no clue to the timezone these entries are meant to be read with. 

 

 

Is there a way to configure the ISE to include a timezone string with the timestamps, and maybe get rid of prehistoric timestamp formats like May 20, 2019 08:10:04.911 AM  (which are good for people still using wrist watches with two dials to measure time by the sun), to get something more internationally standardized? ISO-8601 springs to mind (which would turn our example into 2019-05-20T08:10:04.911Z ), or at least something along the lines of RFC 3339, which, as RFCs go, isn't actually brand new, either? 

 

The timezone thing in ISE 2.2 is utterly confusing, as for example the popups shown upon login are able to make it perfectly clear what time it was when the admin logged in. But only in the popup, message but not in the audit log for administrator logins

 

admin login with UTC timestamp.png    admin login report without UTC timestamp.png

 

 

Radius Authentication Reports seem to be in 24hr format, but have no timezone string included:

Radius Auth report - without timezone.png

 

At the same time, Radius Live Logs and Radius Live Sessions are in 12hr AM/PM Format, but have no information about the timezone, either:

Radius Live Sessions AMPM.pngRadius Live Log AMPM.png

 

Thanks for your comments an pointers

 

Marc

 

2 Accepted Solutions

Accepted Solutions

Arne Bier
VIP
VIP

Hi @Marc Luethi 

 

I have never used UTC as the timezone in my ISE deployments since I don't have deployments that span more than one timezone. 

And you're right - the PAN will not display timezone against any time stamp (even in ISE 2.4 or later).  

How would you expect it to behave if you had even#1 coming from a PSN in UTC+10 and a event#2 coming from UTC+12 ? Chronologically they may come into the MnT at the same time, and the operator needs a normalised display of these events. That probably why UTC is recommended for such multi-timezone deployments.

 

Have you tried sending a product enhancement request via this link

 

cheers

View solution in original post

Hi Arne

Don't get me wrong, I'm all in favour of running the ISE with UTC, and I have no issue with following the recommendation from the Confguration Guides - for the precise reason you're highlighting.

 

What nags me is the inconsistent use of 12hr vs 24hr time format (as in Reports vs Live Logs) and the lack of timezone designators in (almost) all instances of timestamps across the GUI. It' okay to have the timestamps in UTC; but an ASCII based timestamp (especially if in a non-local timezone) MUST include a timezone designator, unless of course it's accepted that it's NTPv4's 128bit format. ;-)

 

I just submitted an Enchancement request at the link you provided, thanks for that!

 

best regards

Marc

 

View solution in original post

2 Replies 2

Arne Bier
VIP
VIP

Hi @Marc Luethi 

 

I have never used UTC as the timezone in my ISE deployments since I don't have deployments that span more than one timezone. 

And you're right - the PAN will not display timezone against any time stamp (even in ISE 2.4 or later).  

How would you expect it to behave if you had even#1 coming from a PSN in UTC+10 and a event#2 coming from UTC+12 ? Chronologically they may come into the MnT at the same time, and the operator needs a normalised display of these events. That probably why UTC is recommended for such multi-timezone deployments.

 

Have you tried sending a product enhancement request via this link

 

cheers

Hi Arne

Don't get me wrong, I'm all in favour of running the ISE with UTC, and I have no issue with following the recommendation from the Confguration Guides - for the precise reason you're highlighting.

 

What nags me is the inconsistent use of 12hr vs 24hr time format (as in Reports vs Live Logs) and the lack of timezone designators in (almost) all instances of timestamps across the GUI. It' okay to have the timestamps in UTC; but an ASCII based timestamp (especially if in a non-local timezone) MUST include a timezone designator, unless of course it's accepted that it's NTPv4's 128bit format. ;-)

 

I just submitted an Enchancement request at the link you provided, thanks for that!

 

best regards

Marc