Network Time Protocol (« protocole d'heure réseau ») ou NTP est un protocole qui permet de synchroniser, via un réseau informatique, l'horloge locale d'ordinateurs sur une référence d'heure.

La première version v. 0 de NTP, formalisée dans la RFC 958, date de septembre 1985. Dès le début, ce protocole fut conçu pour offrir une précision de synchronisation meilleure que la seconde. Par rapport au service « Time Protocol » qui offre un service d'heure sans proposer une infrastructure, le projet NTP propose une solution globale et universelle de synchronisation qui est utilisable dans le monde entier.

La version 3 de NTP est la plus répandue à ce jour. Elle est formalisée par la RFC 1305 et a le statut « Draft Standard (en) » c'est-à-dire « spécification finale », elle spécifie plusieurs aspects :

• la description du protocole réseau ;
• les modes de fonctionnement ;
• les algorithmes à mettre en place dans les machines.

La mise au point de ce protocole et des algorithmes a été menée de pair avec le développement d'un logiciel conforme à ces spécifications. De ce fait, cette réalisation fait office de référence dans le domaine et est appelée « logiciel NTP2 » même si d'autres solutions existent. Ces travaux ont été réalisés en grande partie à l'Université du Delaware grâce au professeur David L. Mills et à une importante équipe de bénévoles.

La version 4 de NTP est une révision importante publiée dans la RFC 5905 en juin 2010.

Aussitôt après la parution de la version 3 de NTP, une version simplifiée est apparue, appelée « Simple Network Time Protocol » (SNTP) qui a également fait l'objet de plusieurs RFC. Par rapport à NTP, cette version est simplifiée dans le sens qu'elle ne spécifie pas les algorithmes à mettre en place dans les machines.

Le NTP est un protocole permettant de synchroniser l'horloge d'un ordinateur avec celle d'un serveur de référence. NTP est un protocole basé sur UDP et utilise le port 123.

Le protocole NTP comprend :

• une partie architecture,
• une partie messagerie,
• et une partie algorithmique.

L'architecture NTP prévoit :

• la diffusion verticale arborescente de proche en proche d'une heure de référence à partir d'une ou plusieurs machines racines garantes d'une grande précision. Dans cette arborescence, chaque nœud choisit parmi ses nœuds parents, celui qui présente les meilleures garanties de qualité et hérite au passage d'un attribut nommé stratum qu'il transmet à ses descendants. Les machines de stratum 1 sont les machines racines et à chaque traversée d'un nœud ce nombre augmente d'une unité. Ce stratum est une mesure de la distance d'un nœud aux machines racines, il est considéré comme un indicateur de la qualité de synchronisation qu'une machine donnée peut offrir à ses descendants.
• la diffusion latérale à des machines paires d'une heure commune. Cette diffusion vient en complément de la précédente ; elle permet à ces machines de partager une référence de temps qui leur est commune. Cette diffusion améliore la résilience de cette architecture NTP dans le sens où elle permet de suppléer une déficience locale/temporaire de connectivité vers les machines racines, voire de permettre à un groupe de machines de conserver entre elles une même référence relative en l'absence de machines racines.

Dans la terminologie NTP, les serveurs de 'stratum 1' sont appelés serveurs primaires, et les autres sont appelés serveurs secondaires.

Chaque nœud de cette architecture doit être configuré en lui indiquant au minimum quels sont ses serveurs parents et/ou collatéraux. C'est à la charge de chaque utilisateur de réaliser localement cette configuration. C'est cette agrégation de configurations qui, de proche en proche, crée le réseau NTP, il n'est pas préexistant ni même configuré de façon centralisée. Cette architecture est flexible, extensible et robuste, mais c’est à la charge des utilisateurs d’y contribuer.

La diffusion de l'heure est basée :

• sur un modèle du type « client/serveur » pour la diffusion verticale :
  • un nœud « serveur » répond aux demandes d'heure émises par un nœud « client » ;
  • les parents sont les serveurs, les enfants sont les clients ;
  • en opérant dans le mode « serveur », un nœud annonce son désir de synchroniser ;
  • en opérant dans le mode « client », un nœud annonce son désir d’être synchronisé ;
  • le mode d'adressage « unicast » est utilisé pour transférer les messages de demande et de réponse ;
• sur un modèle du type « symétrique actif/passif » pour la diffusion latérale :
  • un nœud « symétrique passif » répond aux demandes d'heure émises par un nœud « symétrique actif » ;
  • ce paradigme est proche du précédent avec la différence suivante : une fois la demande initiale émise, « serveur » et « client » échangent leur rôle tour à tour, la réponse de l'un devient une demande pour l'autre ;
  • en opérant dans le mode « symétrique », aussi bien passif qu’actif, un nœud annonce son désir de synchroniser et d’être synchronisé ;
  • comme précédemment le mode d'adressage « unicast » est utilisé pour transférer les messages de demande et de réponse ;
• sur un modèle du type « broadcast » pour la diffusion locale :
  • un nœud émet spontanément et périodiquement des messages de l'heure courante à destination de voisins d'opportunité proches, un peu à la manière d’une horloge parlante sans se préoccuper de savoir si son information d'heure sera utilisée ;
  • en opérant dans ce mode, un nœud annonce son désir de synchroniser ses voisins ;
  • le mode d'adressage « broadcast » est utilisé pour transférer ces messages horaires ; de par ce fait, et également parce que par défaut les routeurs ne routent pas les messages « broadcast », cette méthode de diffusion de l'heure ne concerne que les machines d'un même réseau local.

La messagerie NTP prévoit :

• des messages pour qu'un client interroge un serveur et que celui-ci lui retourne l'heure courante ;
• des messages de service pour interroger un client donné sur son état interne.

Lors de la parution de nouvelles versions de NTP, la structure des nouveaux messages est formée en agrégeant les informations nouvelles à la suite de celle des messages de version précédente. Cette façon de procéder permet l'interopérabilité des différentes versions ce qui facilite la migration globale du parc de machines d'une version ancienne vers une nouvelle.

Le protocole NTP prévoit pour chaque client des algorithmes :

1. pour calculer la période d'interrogation du ou des serveurs ;
2. pour calculer l'écart de son heure locale avec celle d'un serveur donné ;
3. pour calculer la durée de transit des messages sur le réseau ;
4. pour choisir le serveur qui présente les meilleures garanties de qualité, et calculer ainsi son stratum local ;
5. pour filtrer les écarts et calculer les corrections temps/fréquence à appliquer sur son horloge locale ;
6. pour gérer les secondes intercalaires.

Installation du package ntp

[root@srv ~]# yum -y install ntp

Déclarer les pool suivants en se basant sur le site pool.ntp.org : https://www.pool.ntp.org/zone/fr

[root@srv ~]# nano /etc/ntp.conf
#server 0.centos.pool.ntp.org iburst
#server 1.centos.pool.ntp.org iburst
#server 2.centos.pool.ntp.org iburst
#server 3.centos.pool.ntp.org iburst
server 0.fr.pool.ntp.org
server 1.fr.pool.ntp.org
server 2.fr.pool.ntp.org
server 3.fr.pool.ntp.org

Autoriser votre réseau à se synchroniser au serveur de temps

[root@srv ~]# nano /etc/ntp.conf
# Allow NTP client access from local network.
restrict 192.168.0.0 mask 255.255.0.0 nomodify notrap

Démarrage et activation du daemon automatique

• Pour RHEL 6 / CentOS 6 / OEL 6

[root@srv ~]# service ntpd start
[root@srv ~]# chkconfig --level 235 ntpd on

• Pour RHEL 7 / CentOS 7 / OEL 7

[root@srv ~]# systemctl start ntpd
[root@srv ~]# systemctl enable ntpd

Vérification de la synchro.

[root@srv ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+163-172-10-212. 138.96.64.10     2 u   44   64  377   20.028   16.901   5.735
*ntp-3.arkena.ne 138.96.64.10     2 u   48   64  377   20.941   17.624  10.273
+eva.aplu.fr     145.238.203.14   2 u   51   64  377   38.333   19.782  10.606
+cdg1.m-d.net    193.190.230.65   2 u   36   64  377   17.730   17.137   6.615

On peut ainsi connaître pour chaque serveur distant, dit pair de la machine hôte :

• remote : son adresse (nom de domaine, tronqué à 15 caractères) ;
• refid : l'adresse IP du serveur qui lui sert de référence (les serveurs de strate 1 indiqueront par exemple « .GPS. ») ;
• st : son stratum (soit 1 - par exemple pour une source GPS -, 2 pour les clients des strates 1, etc. jusqu'à 5 - rarement plus, au maximum 15 - pour les plus éloignés d'une source fiable) ;
• t : son type (u = unicast, m = multicast, l = local, - = inconnu) ;
• when : le temps écoulé, en secondes, depuis la dernière réponse reçue ;
• poll : l'intervalle de temps en secondes entre deux requêtes (intervalle adapté suivant un algorithme interne) ;
• reach : son accessibilité (état du registre en octal) ;
• delay : la durée en millisecondes, due aux délais réseau, d'une requête complète (similaire au ping) ;
• offset : le décalage temporel apparent, en millisecondes, entre son horloge et celle de l'hôte ;
• jitter : la moyenne quadratique du décalage temporel apparent.

Note : Au-delà de 211 (2048) secondes, les durées when et poll sont exprimées en minutes (34m, 68m, 137m, etc.)

Installation du package chrony

[root@srv ~]# yum -y install chrony

Déclarer les pool suivants en se basant sur le site pool.ntp.org : https://www.pool.ntp.org/zone/fr

[root@srv ~]# nano /etc/chrony.conf
#server 0.centos.pool.ntp.org iburst
#server 1.centos.pool.ntp.org iburst
#server 2.centos.pool.ntp.org iburst
#server 3.centos.pool.ntp.org iburst
server 0.fr.pool.ntp.org
server 1.fr.pool.ntp.org
server 2.fr.pool.ntp.org
server 3.fr.pool.ntp.org

Autoriser votre réseau à se synchroniser au serveur de temps

[root@srv ~]# nano /etc/chrony.conf
# Allow NTP client access from local network.
allow 192.168.0.0/16

Démarrage et activation du daemon automatique

[root@srv ~]# systemctl start chronyd
[root@srv ~]# systemctl enable chronyd

Vérification de la synchro.

# chronyc sources
210 Number of sources = 4
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^- ntp.tuxfamily.net             2   6    17    49  -8471us[-8471us] +/-   67ms
^+ ovh.sqlserver.express         2   6     7    49    +12ms[  +12ms] +/-   43ms
^- cdg1.m-d.net                  2   6    17    48  +5270us[+5270us] +/-   59ms
^* cp01.webhd.nl                 3   6    17    50  +1597us[-2807us] +/-   62ms

Les colonnes sont comme suit :

• M : Ceci indique le mode de la source.
  • ^ signifie un serveur
  • = signifie un pair
  • # indique une horloge de référence connectée localement.
• S : Cette colonne indique l'état des sources.
  • * indique la source avec laquelle chronyd est actuellement synchronisé.
  • + indique les sources acceptables qui sont combinées avec la source sélectionnée.
  • - indique les sources acceptables qui sont exclues de l'algorithme de combinaison.
  • ? indique les sources dont la connectivité a été perdue ou dont les paquets n'ont pas passé tous les tests.
  • x indique une horloge que chronyd croit être de type falseticker (son heure est incohérente avec la majorité des autres sources).
  • ~ indique une source dont la variabilité de l'heure semble trop importante.
  • La condition « ? » est également affichée lors du démarrage, jusqu'à ce qu'au moins 3 échantillons en soient prélevés.
• Name/IP address : Affiche le nom ou l'adresse IP de la source, ou l'ID de référence pour les horloges de référence.
• Stratum : Affiche le stratum de la source noté dans l'échantillon reçu le plus récemment. Stratum 1 indique un serveur avec une horloge de référence attachée localement. Un serveur synchronisé avec un serveur stratum 1 se trouve au stratum 2. Un serveur synchronisé avec un serveur stratum 2 se trouve au stratum 3, et ainsi de suite.
• Poll : Affiche la vitesse à laquelle la source est sondée, en tant que logarithme de base 2 de l'intervalle en secondes. Ainsi, une valeur de 6 indiquerait qu'une mesure est prise toutes les 64 secondes. chronyd fait varier automatiquement la vitesse de sondage en réponse aux conditions actuelles.
• Reach : Affiche l'enregistrement de la portée de la source imprimé en tant que nombre octal. L'enregistrement compte 8 bits et est mis à jour chaque fois qu'un paquet est reçu ou n'a pas été reçu de la source. Une valeur de 377 indique qu'une réponse valide a été reçue pour chacune des huit dernières transmissions.
• LastRx : Cette colonne affiche le temps écoulé depuis que le dernier échantillon a été reçu de la source. Cette valeur est généralement exprimée en secondes. Les lettres m, h, d ou y indiquent les minutes, heures, jours ou années. Une valeur de 10 ans indique qu'aucun échantillon n'a encore été reçu de cette source.
• Last sample : Cette colonne affiche le décalage entre l'horloge locale et la source lors de la dernière mesure. Le chiffre entre les crochets montre le décalage mesuré réel. Celui-ci peut être suivi du suffixe ns (indiquant des nanosecondes), us (indiquant des microsecondes), ms (indiquant des millisecondes), ou s (indiquant des secondes). Le nombre à gauche des crochets affiche la mesure d'origine ajustée pour permettre tout changement appliqué à l'horloge locale. Le nombre suivant qui se trouve après le marqueur +/- affiche la marge d'erreur de la mesure. Des décalages positifs indiquent que l'horloge locale est en avance comparé à la source.

Pour la configuration des clients, nous allons faire la même configuration à une exception prêt. Nous allons déclarer comme serveur de temps référence notre nouveau serveur déclaré plus haut.

Exemple pour un serveur utilisant le service 'chrony' :

Installation du package chrony

[root@srv ~]# yum -y install chrony

Déclarer notre serveur de temps

[root@srv ~]# nano /etc/chrony.conf
#server 0.centos.pool.ntp.org iburst
#server 1.centos.pool.ntp.org iburst
#server 2.centos.pool.ntp.org iburst
#server 3.centos.pool.ntp.org iburst
server 192.168.1.100 # L'ip de notre serveur de temps !

Démarrage et activation du daemon automatique

[root@srv ~]# systemctl start chronyd
[root@srv ~]# systemctl enable chronyd

Vérification de la synchro.

# chronyc sources
210 Number of sources = 1
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^* 10.75.168.28                  3   6   377    53    +39us[+2466us] +/-   71ms

https://www.ntppool.org/fr/