02-12-2020 01:41 AM - edited 02-21-2020 11:13 AM
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 ?
Solved! Go to Solution.
02-13-2020 04:36 AM
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.
02-12-2020 06:14 AM
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.
02-12-2020 08:03 AM
02-20-2020 08:00 PM
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.
02-12-2020 10:31 AM
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.
02-13-2020 04:36 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide