Des pannes de synchronisation dépannez ISE et de NTP serveur sur Microsoft Windows

Introduction

Ce document décrit un problème qui est produit quand le Logiciel Cisco Identity Services Engine (ISE) et d'autres serveurs de Linux ne synchronisent pas avec un serveur de Protocole NTP (Network Time Protocol) qui est installé sur une Microsoft Windows Server. Une solution au problème est également fournie.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Configuration de Cisco ISE CLI
  
  
• Connaissance de base au sujet de NTP

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Version 2012 de Microsoft Windows Server
  
  
• Versions de logiciel 1.3 de Cisco ISE et plus tard

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Problème

Après que vous configuriez l'ISE CLI afin d'utiliser la Microsoft Windows Server comme NTP, il ne synchronise pas. La configuration par défaut de contrôleur de domaine de la Microsoft Windows Server 2012 est utilisée (configuration par défaut de NTP). Les états ISE que la source locale est encore utilisée :

ise14/admin# show ntp
Configured NTP Servers: 
 10.62.145.72

synchronised to local net at stratum 11 
 time correct to within 11 ms
 polling server every 1024 s

 remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.1.0 .LOCL. 10 l 9 64 377 0.000 0.000 0.000
 10.62.145.72 .LOCL. 1 u 226 1024 377 0.896 -3.998 4.130

* Current time source, + Candidate , x False ticker 

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

Tous les paramètres (accessibilité, retard, décalage, et jitter) ne semblent être corrects, et là sont aucune manière de dépanner la question du CLI (panne de synchronisation de NTP). Pour la confirmation de la question, vous devez aller au niveau de racine et utiliser l'outil NTPQ afin de questionner le démon de ntpd pour plus de détails :

[root@ise14]# ntpq

ntpq> associations

ind assID status conf reach auth condition last_event cnt
===========================================================
 1 53519 9614 yes yes none sys.peer reachable 1
 2 53520 9014 yes yes none reject reachable 1

Comme affiché, il y a deux associations présentées. L'association 53520 est marquée en tant que rejeté. Voici quelques détails supplémentaires pour cette association :

ntpq> mrv 53520 53520
assID=53520 status=9014 reach, conf, 1 event, event_reach,
srcadr=10.62.145.72, srcport=123, dstadr=10.62.145.42, dstport=123,
leap=00, stratum=1, precision=-6, rootdelay=0.000,
rootdispersion=10032.150, refid=LOCL, reach=377, unreach=0, hmode=3,
pmode=4, hpoll=10, ppoll=10, flash=400 peer_dist, keyid=0, ttl=0,
offset=-32.465, delay=0.898, dispersion=30.345, jitter=4.519,
reftime=d96b0358.fe7c815a Tue, Aug 4 2015 11:24:40.994,
org=d96b08ed.829514cf Tue, Aug 4 2015 11:48:29.510,
rec=d96b08ed.8b022d8d Tue, Aug 4 2015 11:48:29.543,
xmt=d96b08ed.8ac74cca Tue, Aug 4 2015 11:48:29.542,
filtdelay= 0.90 1.20 0.95 0.93 0.87 0.89 1.19 0.93,
filtoffset= -32.47 -27.95 -26.50 -34.32 -27.74 -18.14 -22.54 -23.79,
filtdisp= 15.63 30.97 46.32 61.68 77.05 92.44 107.82 115.48

Il est possible de confirmer que c'est le serveur précédemment configuré de NTP (10.62.145.72) pour lequel la synchronisation échoue. En outre, le paramètre de dispersion de racine est grand (au-dessus de 10,000 ms). Employez ces informations afin de confirmer ce paramètre de la Microsoft Windows Server :

C:\Users\Administrator> w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 1 (primary reference - syncd by radio clock)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0000000s
Root Dispersion: 10.0000000s
ReferenceId: 0x4C4F434C (source name: "LOCL")
Last Successful Sync Time: 04/08/2015 11:15:32
Source: Local CMOS Clock
Poll Interval: 6 (64s)

Les captures de paquet présentent la demande qui est envoyée de l'ISE, avec une dispersion acceptable de racine d'une seconde :

Voici la réponse du serveur, qui a une dispersion de racine qui est plus grande que dix secondes :

En conséquence, ceci n'est pas reçu, qui fait relâcher la demande et continuer l'ISE la source heure locale.

La dispersion de racine est un nombre qui indique l'erreur maximum relativement à la source de référence principale à la racine du sous-réseau de synchronisation. Il est augmenté par chaque serveur de NTP. Par défaut, le serveur de Microsoft place la valeur à dix secondes seulement où sa propre source heure locale est utilisée (afin d'indiquer que ce n'est pas une source fiable de temps). Quand le serveur de NTP de Microsoft est configuré avec un NTP externe, cette valeur est dérivée du serveur et le problème n'existe pas.

Solution

Selon la documentation Microsoft, il est possible de configurer la valeur de LocalRootDispersion dans le registre. Terminez-vous ces étapes afin de configurer la valeur de registre :

1. Arrêtez le service de NTP de PowerShell (sur option, sélectionnez la commande nette de l'arrêt w32time) :
   
   

   PS C:\Users\Administrator> Stop-Service w32time

2. Placez la valeur de registre à 0 :
   
   

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\LocalClockDispersion

3. Redémarrez le service (sur option, sélectionnez la commande nette du début w32time) :
   
   

   PS C:\Users\Administrator> Start-Service w32time

4. Vérifiez que la nouvelle valeur (0) est signalée :
   
   

   C:\Users\Administrator> w32tm /query /status
   Leap Indicator: 0(no warning)
   Stratum: 1 (primary reference - syncd by radio clock)
   Precision: -6 (15.625ms per tick)
   Root Delay: 0.0000000s
   Root Dispersion: 0.0000000s
   ReferenceId: 0x4C4F434C (source name: "LOCL")
   Last Successful Sync Time: 04/08/2015 11:15:32
   Source: Local CMOS Clock
   Poll Interval: 6 (64s)

L'outil ISE NTPQ devrait maintenant signaler une valeur basse (de 48 ms) :

ntpq> mrv 53520 53520
assID=8400 status=9614 reach, conf, sel_sys.peer, 1 event, event_reach,
srcadr=10.62.145.72, srcport=123, dstadr=10.62.145.42, dstport=123,
leap=00, stratum=1, precision=-6, rootdelay=0.000,
rootdispersion=48.431, refid=LOCL, reach=377, unreach=0, hmode=3,
pmode=4, hpoll=7, ppoll=7, flash=00 ok, keyid=0, ttl=0, offset=8.206,
delay=0.514, dispersion=21.595, jitter=3.456,
reftime=d96b0c49.2c834d26 Tue, Aug 4 2015 12:02:49.173,
org=d96b175c.d472ead9 Tue, Aug 4 2015 12:50:04.829,
rec=d96b175c.d2bf9803 Tue, Aug 4 2015 12:50:04.823,
xmt=d96b175c.d284b95f Tue, Aug 4 2015 12:50:04.822,
filtdelay= 0.90 0.86 0.51 0.87 0.80 0.82 0.85 0.88,
filtoffset= 7.09 5.23 8.21 6.78 2.73 8.43 1.93 9.67,
filtdisp= 15.63 17.56 19.48 21.39 23.32 25.24 27.18 29.08

Ceci permet à la synchronisation de se produire comme prévue :

ntpq> associations
ind assID status conf reach auth condition last_event cnt
===========================================================
 1 53519 9014 yes yes none reject reachable 1
 2 53520 9614 yes yes none sys.peer reachable 1

Vous pouvez également vérifier ces informations du CLI :

ise14/admin# show ntp
Configured NTP Servers: 
 10.62.145.72

synchronised to NTP server (10.62.145.72) at stratum 2 
 time correct to within 80 ms
 polling server every 128 s

 remote refid st t when poll reach delay offset jitter
==============================================================================
 127.127.1.0 .LOCL. 10 l 15 64 377 0.000 0.000 0.000
*10.62.145.72 .LOCL. 1 u 26 128 377 0.514 8.206 3.456

* Current time source, + Candidate , x False ticker 

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

Questions supplémentaires

Certaines des versions plus anciennes de Microsoft Windows Server pourraient avoir différentes configurations par défaut de NTP. Cisco recommande que vous vérifiiez si ces configurations sont correctes et acceptables par l'ISE. Vérifiez ces paramètres de registre :

• Changez la valeur activée d'indicateur à 1 afin d'activer le serveur de NTP :
  
  

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders
   \NTPServer\Enabled

• Placez l'entrée dans le registre de type au NTP afin de changer le type de serveur :
  
  

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type

• Placez l'entrée dans le registre d'indicateurs d'annonce à 5 afin d'indiquer une source temporelle fiable :
  
  

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config
   \AnnounceFlags

Questions de VMware

Les questions de synchronisation de NTP pourraient sont provoqué par par l'ID 2075424 de bogue de VMware (l'hôte d'ESXi ne synchronise pas le temps avec le serveur de NTP).

La question est résolue dans ces correctifs :

• Mise à jour 1 de VMware ESXi 5.5
  
  
• Correctif 4 d'ESXi 5.1 de VMware
  
  
• Correctif 8 d'ESXi 5.0 de VMware

Informations connexes

• Guide de l'administrateur de Logiciel Cisco Identity Services Engine, version 1.4
  
  
• Support et documentation techniques - Cisco Systems