This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.
We want to deploy the ISE's nodes in primary- secondary to high availability.
One Node is in Europe and the another node is in America.
Is there exist some restriction about the distance or times, to syncronize between each one?.
Of course, the timezone for each node will be different (GMT - 8 and GMT +1 for example).
I was reading the way for implement it, but it didn't show any information about this.
Make your timezones BOTH UTC
What kind of connection do you have between the 2 sites?
I hope you find this information useful, if it was satisfactory for you, please mark the question as Answered.
Please rate post you consider useful.
My suggestion is to lab this between two boxes in a virtual environment. I dont think there is an issue with this since the clock has to be NTP and from a reliable clock source (please do not use windows). From my understanding the timezone is just an offset to the raw time data that is learned from NTP so if you have two nodes in different timezones should be covered. I understand that using UTC is a pain but James brings up a good solution. I feel that if you configure this in a lab you should be ok.
*Please rate helpful posts*
Sorry for answer a little late. I had not the information before by the client.
The connection between the two sites is a International MPLS (no internet from our perspective). This is the information:
BW: 2 Mbps
Delay: 200 ms
I put the 2 Nodes ISE in that way:
Node in Europe (We will call NodeA):
- Administration (PAN) Primary
- Monitoring (MNT)
- Policy (PSN)
- NTP Server: Public NTP Server. 18.104.22.168
CA Certificate: Self-Certificate_from_ise_node_America
Node in America (We will call NodeB):
- Administration (PAN) Secondary
NTP Server: Public NTP Server. 22.214.171.124 (the same NTP Server)
The NodeB is registered from NodeA using its dns name, with no problem (so I assumed that the certificate, credential and DNS resolve correctly).
Waiting for a couple of hour, the NodeB viewed from the NodeA in the section Administration - System - Deployment state OUT OF SYNC.
When I tried to sync manually, the NodeA showed the following message:
Internal Error: Server returned HTTP Response Code: 500 for URL: https://NodeB/deployment-rpc/cert
And happened everytime I tried to sync.
The NodeB is no possible to access through http server web page correctly after its register. It shows the portal page, but it doesn't matter if you use a correct user or bad user, after you click Logging, return a white page without information.
The solution to use the same timezone
I will put in practice, making the nodes using for both UTC.
If you guys have another ideas, it's appreciate it.
Sync issues, which are usually due to time changes or Network Time Protocol (NTP) sync issues, you must correct the system time and perform a manual sync-up through the UI.
I am having a similar issue to the above and I am curious if the license/certificate will have issues once the NTP server or clock is changed.
Thanks and Regards,
Are these nodes virtual? If so, please make sure that the Virtual Host Machine is syncing with the NTP server properly before deploying the VM image. Once that is done, ensure that you are using the same NTP server on both the Virtual Host Machine and the VM.
The licenses will be fine, but you may have to generate new certs once the time syncs up. It can take 15-20 minutes for the NTP polling to sync the times.
Please Rate Helpful posts and mark this question as answered if, in fact, this does answer your question. Otherwise, feel free to post follow-up questions.
You have to make your own calculations as in
Just one of them is virtual.
Apparently is not a sync problems, but a possible bug CSCuh70984 is hitting. Although is not discarded the delay issue between the nodes (200 ms), maybe is not the problem.
We will do the workaround if the problem is resolved.
I'll let you know guys.