Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
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.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
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.
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[an error occurred while processing this directive]
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[an error occurred while processing this directive]
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[an error occurred while processing this directive]
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[an error occurred while processing this directive]
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.
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 :
PS C:\Users\Administrator> Stop-Service w32time[an error occurred while processing this directive]
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\LocalClockDispersion[an error occurred while processing this directive]
PS C:\Users\Administrator> Start-Service w32time[an error occurred while processing this directive]
C:\Users\Administrator> w32tm /query /status[an error occurred while processing this directive]
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[an error occurred while processing this directive]
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[an error occurred while processing this directive]
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[an error occurred while processing this directive]
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.
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 :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders[an error occurred while processing this directive]
\NTPServer\Enabled
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type[an error occurred while processing this directive]
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config[an error occurred while processing this directive]
\AnnounceFlags
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 :