cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1879
Views
35
Helpful
5
Replies

Inaccurate ISE documentation is potentially leading me to reset two ISE servers in HA.

damode
Level 1
Level 1

While setting up ISE 2.6 on SNS3595 servers, I chose the timezone as UTC, based on recommendation from ISE docs.

 

Now, I notice all radius logs showing up with some minor delay and incorrect time. When I looked up to change the timezone to Australia/Melbourne, it didnt allow me on the CLI and neither through GUI.

 

Going through similar posts on this forum, I realised its a bug and there is yet no patch for this, which means, I would have to reset ISE now.

 

Firstly, why the docs recommend to set timezone ot UTC instead of location specific ?

secondly, is there any better way rather than resetting ISE config and rebuilding ?

1 Accepted Solution

Accepted Solutions

I have never used UTC for ISE deployments in the various timezones in Australia. Granted though, all the nodes were in the same timezone. If they were NOT, then I would probably chose the primary timezone and set them all to that. At least then you have a reference point that is somewhat related to your geography.  If you think about it, there is nothing special about UTC vs AEST (for example) - they are both reference markers. If I am located in Brisbane (UTC+10) and I build all nodes with AEST (UTC+10), but I also have a few nodes floating around in Perth (UTC+8) - but I have to build them with AEST ... then I would appreciate my logs reporting the time in Brisbane, since I am situated there and looking at the logs. Things get funky with Daylight Savings etc.

A proper SYSLOG entry should always contain the timezone indicator for every line entry - there can be no confusion. I have no idea how well ISE would handle that.

It's all too complex - that's probably with Cisco Docs advise to just use UTC/GMT+0 - then you can do your own maths, based on the relative offset to UTC.

 

View solution in original post

5 Replies 5

Colby LeMaire
VIP Alumni
VIP Alumni

UTC has always been the recommended setting for timezone.  It is primarily for those deployments that span multiple timezones.  If all of the nodes in your deployment are in the same timezone and you do not expect to add new nodes in different timezones, then you can certainly set the local timezone.  The important thing is to keep all nodes in the same timezone.

The time within the Syslog or Radius requests shouldn't matter since I believe ISE will use the time that the message was received by ISE.  And yes, if you want to change the timezone, you should reset/rebuild the nodes.

Damien Miller
VIP Alumni
VIP Alumni
On the second question, there is currently no way to change the timezone on 2.6 without resetting the node and joining it back in.

Even though CSCvo49755 addressed in ISE 2.6 Patch 4, there is still some chance that updating timezone may lead to issues of replications among ISE nodes.

hello damode.

yup, u have to select selected TZ for all the nodes to be the same. idk why Cisco recommends exactly UTC as preferred. 

I have never used UTC for ISE deployments in the various timezones in Australia. Granted though, all the nodes were in the same timezone. If they were NOT, then I would probably chose the primary timezone and set them all to that. At least then you have a reference point that is somewhat related to your geography.  If you think about it, there is nothing special about UTC vs AEST (for example) - they are both reference markers. If I am located in Brisbane (UTC+10) and I build all nodes with AEST (UTC+10), but I also have a few nodes floating around in Perth (UTC+8) - but I have to build them with AEST ... then I would appreciate my logs reporting the time in Brisbane, since I am situated there and looking at the logs. Things get funky with Daylight Savings etc.

A proper SYSLOG entry should always contain the timezone indicator for every line entry - there can be no confusion. I have no idea how well ISE would handle that.

It's all too complex - that's probably with Cisco Docs advise to just use UTC/GMT+0 - then you can do your own maths, based on the relative offset to UTC.