Hi,

Jim Blake · ‎01-22-2016

I have an ESXi 6.0 test host, upon which I am evaluating ISE 2.0. I have built two ISEs, in the same manner as I would (and which works fine every time) for ISE 1.3. The two servers are running as Primary/Secondary, on the same ESXi6.0 host as a Windows 2K12r2 server which is doing AD/DNS/DHCP/CA duties. I have created a wildcard certificate on both ISEs, using the Win2K12 CA server as my Root-CA.

I joined the ISE Servers to the AD Domain. I was using time.nist.gov on the ISEs for NTP. That exposed a sensitivity that doesn't exist in ISE 1.3, in that ISE 2.0 was unhappy to join because of clock skew until I made my lab switch the NTP server and all servers were made NTP clients of the switch. Once I did that, the ISEs joined AD no problem. (The lab switch in turn gets its NTP from time.nist.gov)

I can see that the ISEs are using the switch, from the output of "show ntp" on each ise attached below.

When I test users (Administration/External Identity Sources/Active Directory/ Connection/Test Users) the users authenticate on AD perfectly

However, when I run all diagnostics (Administration/External Identity Sources/Active Directory/ <domain name>/Active Directory Diagnostic Tool), I consistently get an NTP failure, the details of which are:

"NTP Client is not synchronized. Could not connect to any peer".

This didn't happen with ISE 1.3 running in ESXi 5.5. I have followed the same process in building these servers as I would with the previous versions. It seems a little odd that ISE 2.0 should complain about NTP peers...it's got its server, as shown by the "show ntp" command output, so what's it talking of peers for?

Hmmm...bit confused here....some clues would be appreciated!

Jim

ISE-100-30/admin# show ntp
Configured NTP Servers:
192.168.255.255

synchronised to NTP server (192.168.255.255) at stratum 4
   time correct to within 543 ms
   polling server every 64 s

     remote           refid      st t when poll reach   delay   offset jitter
==============================================================================
127.127.1.0     .LOCL.          10 l 284   64 360    0.000    0.000   0.000
*192.168.255.255 130.88.200.4     3 u   16   64 377    0.678 422.156 23.330

* Current time source, + Candidate , x False ticker

Warning: Output results may conflict during periods of changing synchronization.

ISE-100-40/admin# show ntp
Configured NTP Servers:
192.168.255.255

synchronised to NTP server (192.168.255.255) at stratum 4
   time correct to within 529 ms
   polling server every 64 s

     remote           refid      st t when poll reach   delay   offset jitter
==============================================================================
127.127.1.0     .LOCL.          10 l 286   64 360    0.000    0.000   0.000
*192.168.255.255 130.88.200.4     3 u   10   64 377    0.708 420.176 48.633

* Current time source, + Candidate , x False ticker

Warning: Output results may conflict during periods of changing synchronization.

ISE-100-40/admin#

jan.nielsen · ‎01-22-2016

Is 192.168.255.255 that you have set as ntp server in subnet 192.168.255.0/24 ? If so, you will get into trouble as that is the broadcast address of the network, which you can't assign to any host.

Jim Blake · ‎01-22-2016

Hi Jan,

192.168.255.255 is the loopback address of the switch. The host is on VLAN 200, with address 192.168.200.250, the servers are on VLAN 100 with addresses 192.168.100.30 (ISE), .40 (ISE) and .20 (Win2K12R2).

I *think* that should be OK...it works with ESXi5.5/ISE 1.3.

However, thanks for the comments.

Javier Henderson · ‎01-22-2016

Jim,

It seems that your ISE is synchronized to the NTP server, given the output above, though the offset and jitter are a bit on the high side (almost half a second off the time source). However, the errors you're getting seem to be incorrect. I'd recommend that you open a TAC case with us, so we can take a closer look.

Javier Henderson

Cisco Systems

Jim Blake · ‎01-22-2016

Hi Javier

Offset and jitter are possibly down to the fact that the setup had not been working for very long (<<1hr) so was still stabilizing. I've posted some more output below after the system had been running a while and it looks much better.

I'd love to open a TAC case, but I'm an independent Wireless/Security consultant (working to assess ISE 2.0 and train myself) and don't have the formal relationship with Cisco that I believe I need to open such a case. Is there any way that I can do so?

I've done this build numberless times on 1.3 and never had this kind of issue, but I'm prepared to believe that it is my ignorance of 2.0 that is the issue....which is why I'm doing this work before I try to recommend it to any of my customers :)

Thanks

Jim

ISE-100-30/admin# show ntp
Configured NTP Servers:
192.168.255.255
192.168.100.40

synchronised to NTP server (192.168.255.255) at stratum 3
   time correct to within 217 ms
   polling server every 256 s

     remote           refid      st t when poll reach   delay   offset jitter
==============================================================================
127.127.1.0     .LOCL.          10 l 78m   64    0    0.000    0.000   0.000
*192.168.255.255 128.138.141.172 2 u 140 256 377    0.794   -1.866   0.194
+192.168.100.40 192.168.255.255 3 u 45m 256    0    0.282   -2.455   0.000

* Current time source, + Candidate , x False ticker

Warning: Output results may conflict during periods of changing synchronization.

ISE-100-40/admin# show ntp
Configured NTP Servers:
192.168.255.255
192.168.100.30

synchronised to NTP server (192.168.255.255) at stratum 3
   time correct to within 205 ms
   polling server every 128 s

     remote           refid      st t when poll reach   delay   offset jitter
==============================================================================
127.127.1.0     .LOCL.          10 l 79m   64    0    0.000    0.000   0.000
*192.168.255.255 128.138.141.172 2 u 104 128 377    0.729   -0.601   0.070
192.168.100.30 .INIT.          16 u    - 1024    0    0.000    0.000   0.000

* Current time source, + Candidate , x False ticker

Warning: Output results may conflict during periods of changing synchronization.

holger.moersfelder@global.ntt · ‎03-13-2016

Hi Jim,

any update on this topic ?

I'm got the some issue with a new 3.0 deployment.

Running two nodes on 1.4 P3 without any ntp warnings. Now after migration to 3.0 the two PAN/MNT nodes bingup the NTP warning.

But on policy node of the deployment is fine with the same ntp clocks which are consumed by the failing nodes.

Regards,

Holger

Jim Blake · ‎03-18-2016

Hi Holger,

Sorry, no new info...I've been sidetracked from my lab research by a large and complex wireless design....if I get anything more, I'll post, but water-cooler discussions with others who work with the ISE haven't turned up anything

Jim

holger.moersfelder@global.ntt · ‎03-18-2016

Hi Jim,

here is the Cisco TAC feedback we are looking for:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCux82480

It is a new bug for ISE 2.0, it is classified as low severity and is cosmetic in nature, not impacting ISE functionality.

Till now there is no committed patch release for the fix.

Regards Holger

ffischer · ‎06-15-2016

Hi,

have this issue as well @one of our clients.

bug search tool for CSCux82480 now shows

Last Modified:

Jun 10,2016

Status:

Fixed

but

Known Fixed Releases: 0

Somehow confusing...

Any news what patch or release will contain the fix ?

Frank

MohammadHamad · ‎10-23-2016

Hi Frank,

Checking that Bug tracking page, I see that the page updated just a few days ago (21st October) and the issue is now marked as fixed. However, Known Fixed Releases still doesn't show any version.

Regards,

NTP failures with ISE 2.0