Network Time Protocol (NTP)

1. Introduction

Tout comme les appareils de votre maison, les équipements réseau doivent partager la même heure sur l’ensemble du réseau. Bien que les routeurs et les commutateurs possèdent des horloges internes, celles-ci dérivent : après plusieurs jours ou semaines, différents équipements peuvent finir par afficher des heures différentes.

Figure 1 – Horloges non synchronisées avant l’utilisation du Network Time Protocol

Le Network Time Protocol (NTP) résout ce problème en maintenant tous les équipements synchronisés avec une source de temps commune et précise. Grâce à NTP, l’ensemble du réseau reste aligné.

Figure 2 – Horloges synchronisées avec le Network Time Protocol

NTP est normalisé par l’IETF dans la RFC 5905 (version actuelle NTPv4) et il est largement utilisé dans les réseaux d’entreprise modernes pour maintenir une heure cohérente sur tous les équipements.

Pourquoi avons-nous besoin d’une heure synchronisée ?

• Corrélation des journaux (Syslog) : aligner les horodatages entre les équipements pour reconstituer précisément les événements lors d’un dépannage ou d’incidents de sécurité.
  

• Sécurité et certificats : de nombreux mécanismes dépendent d’une heure correcte (par exemple la validité des certificats et les échanges sensibles au temps dans IPsec/TLS).
  

• Politiques et tâches basées sur le temps : appliquer des ACL basées sur l’heure, exécuter des sauvegardes/scripts/automatisations au bon moment et répondre aux exigences d’audit et de conformité.

En résumé, des horloges synchronisées rendent le réseau plus simple à dépanner, plus sûr et plus fiable.

2. Comment fonctionne le Network Time Protocol ?

NTP utilise un modèle simple Client–Serveur. Dans ce modèle, un serveur NTP est connecté à une source de temps fiable et envoie régulièrement des horodatages à ses clients. Ces horodatages sont des valeurs numériques qui représentent l’heure courante.

Quand les clients reçoivent ces informations, ils les comparent avec leur propre horloge locale et ajustent ensuite leur temps par petites étapes.

Tous les échanges sont légers et utilisent le port UDP 123 pour la communication.

Horloge de référence

Un serveur NTP n’invente pas l’heure. Il s’appuie sur une horloge de référence, c’est-à-dire une source très précise comme un récepteur GPS relié à des horloges atomiques, ou encore une horloge atomique/radio au sol.

Figure 3 – Source de temps autoritative utilisant une horloge atomique embarquée

Traditionnellement, les satellites GPS embarquent des horloges atomiques qui fournissent une heure extrêmement précise. Une antenne au sol reçoit ce signal, le serveur NTP lit les horodatages, puis les distribue au reste du réseau.

Stratums NTP

Les réseaux NTP sont organisés en niveaux appelés stratums (du latin stratum = couche). Dans NTP, le stratum d’un équipement indique sa distance par rapport à la source de temps la plus précise, l’horloge de référence aussi appelé Reference Clock.

Dans l’exemple ci-dessous, le Stratum 0 correspond au système GPS qui agit comme horloge de référence.

Figure 4 – Hiérarchie des stratums dans le Network Time Protocol

Plus on descend dans les couches, plus le numéro de stratum augmente. Les niveaux utilisables vont de 1 à 15. Stratum 16 signifie que l’équipement n’est pas synchronisé.

Dans un réseau NTP typique, un serveur Stratum 1 est directement connecté à l’horloge de référence.

Figure 5 – Communication NTP Client-Serveur par stratum

Ensuite, un équipement Stratum 2 se synchronise sur le Stratum 1 (en tant que client) et peut fournir l’heure aux niveaux inférieurs. Un équipement Stratum 3 est souvent uniquement client, apprenant l’heure d’un Stratum 2.

C’est une hiérarchie : plus le stratum augmente, plus la précision diminue légèrement à cause du délai ajouté. Les clients privilégient donc toujours le serveur atteignable avec le stratum le plus bas.

3. Configuration de NTP

Avant d’utiliser le Network Time Protocol, il est important de savoir régler et vérifier l’horloge locale sur les équipements Cisco. Nous allons ensuite pointer les équipements vers un serveur NTP et interpréter les sorties de vérification.

Pour l’examen CCNA, vous n’avez pas besoin de connaître toutes les commandes, uniquement les essentielles.

Horloge locale

Vous pouvez configurer manuellement le fuseau horaire et l’horloge locale d’un équipement réseau.

Figure 6 – Configuration de l’heure locale sur un routeur Cisco

Pour vérifier la mise à jour, utilisez la commande show clock detail

R1# show clock detail
10:52:5.540 UTC Wed Aug 13 2025
Time source is user configuration

On voit l’heure configurée, avec un léger décalage dû au temps d’exécution de la commande. La ligne Time source is user configuration confirme que l’horloge a été réglée manuellement.

Cependant, dans un réseau d’entreprise, régler chaque équipement manuellement serait long, et les horloges finiraient tout de même par dériver. C’est ici que NTP devient essentiel.

Configuration d’un serveur NTP

Maintenant que nous comprenons l’intérêt de NTP, configurons un équipement pour utiliser un serveur NTP et synchroniser l’heure automatiquement.

Figure 7 – Étapes de configuration d’un serveur NTP

La commande de base est ntp server ip address

Étape 1 – Pointer SW1 vers le serveur NTP interne (R1)

Dans notre exemple, SW1 doit obtenir l’heure du serveur NTP 209.165.200.225.
Ce serveur est accessible uniquement via R1 (192.168.1.1), donc SW1 sera configuré pour utiliser R1 :

SW1(config)# ntp server 192.168.1.1

Cela indique à SW1 de demander l’heure à R1.

Étape 2 – Vérifier l’état NTP initial

On peut vérifier si la synchronisation a eu lieu avec la commande show ntp status

SW1# show ntp status
Clock is unsynchronized, stratum 16, no reference clock
nominal freq is 250.0000 Hz, actual freq is 249.9990 Hz, precision is 2**24
reference time is 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1990)
clock offset is 0.00 msec, root delay is 0.00 msec
root dispersion is 0.00 msec, peer dispersion is 0.00 msec.
loopfilter state is 'FSET' (Drift set from file), drift is - 0.000001193 s/s system poll interval is 4, never updated.

À ce stade, l’horloge est unsynchronized et le stratum est 16 (valeur par défaut d’un équipement non synchronisé).

Cela arrive parce que R1 n’a pas encore été configuré pour utiliser un serveur NTP externe.

Étape 3 – Vérifier les associations NTP

Une autre commande utile est show ntp associations

SW1# show ntp associations
address         ref clock  st   when  poll reach  delay  offset  disp
~192.168.1.1  .INIT.    16   -     64    0    0.00   0.00    0.12
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

• ~ configured → SW1 a été configuré pour utiliser 192.168.1.1 (R1) comme serveur NTP.

• .INIT. → R1 n’a pas encore envoyé d’informations valides.

On peut donc voir que l’association est bien créée, mais la reference clock est encore à l’état init.

Étape 4 – Configurer R1 pour utiliser un serveur NTP public

Configurons R1 pour obtenir l’heure depuis le serveur NTP public 209.165.200.225 :

R1(config)# ntp server 209.165.200.225

À partir de maintenant, R1 commencera à recevoir des horodatages depuis ce serveur NTP externe.

Étape 5 – Attendre la synchronisation

• Dans un vrai réseau, la synchronisation peut prendre jusqu’à 30 minutes.

• Dans Packet Tracer, vous pouvez accélérer le processus en utilisant l’option Fast Forward Time.

Une fois R1 synchronisé, SW1 pourra également se synchroniser via R1.

Figure 8 – Le serveur NTP envoie les horodatages aux clients NTP

Étape 6 – Vérifier la synchronisation de R1

Sur R1, vérifions l’état NTP :

R1# show ntp status
Clock is synchronized, stratum 2, reference is 209.165.200.225
nominal freq is 250.0000 Hz, actual freq is 249.9990 Hz, precision is 2**24
reference time is EC1D64C1.00000225 (22:48:33.549 UTC Thu Aug 14 2025)
clock offset is 0.00 msec, root delay is 0.00 msec
root dispersion is 767.34 msec, peer dispersion is 0.48 msec.
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is - 0.000001193 s/s system poll interval is 6, last update was 18 sec ago.

On peut constater :

• Clock is synchronized → R1 est bien synchronisé avec la source externe.

• Stratum 2 → R1 est à deux niveaux de l’horloge de référence.

• Reference = 209.165.200.225 → correspond au serveur configuré.

Étape 7 – Vérifier la synchronisation de SW1

Une fois R1 synchronisé, SW1 peut récupérer l’heure depuis R1 :

SW1# show ntp status
Clock is synchronized, stratum 3, reference is 192.168.1.1
nominal freq is 250.0000 Hz, actual freq is 249.9990 Hz, precision is 2**24
reference time is EC1D642A.0000019F (22:46:2.415 UTC Thu Aug 14 2025)
clock offset is 0.00 msec, root delay is 0.00 msec
root dispersion is 775.07 msec, peer dispersion is 0.48 msec.
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is - 0.000001193 s/s system poll interval is 6, last update was 36 sec ago.

Points importants :

• Reference = 192.168.1.1 → SW1 utilise bien R1 comme serveur NTP.

• Stratum 3 → SW1 est un niveau en dessous de R1.

Step 8 – Check NTP Associations on SW1

SW1# show ntp associations
address         ref clock              st  when  poll reach  delay  offset  disp
*~192.168.1.1 209.165.200.225       2    49    64   377    0.00   0.00   0.48
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

Cela nous indique que :

• SW1 est synchronisé avec 192.168.1.1 (R1).

• R1 utilise comme horloge de référence 209.165.200.225 (le serveur NTP public).

• R1 est Stratum 2, donc SW1 est Stratum 3.

Étape 9 – Confirmer la source de temps

Enfin, vérifions l’horloge sur SW1 :

SW1# show clock detail
22:51:7.176 UTC Thu Aug 14 2025
Time source is NTP

La ligne Time source is NTP confirme que SW1 est bien synchronisé via NTP.

4. NTP Master

Un concept important à comprendre est la fonctionnalité NTP Master.
Elle permet à un équipement d’agir comme un serveur NTP en utilisant sa propre horloge interne si le serveur NTP principal devient indisponible.

Figure 9 – Configuration NTP Master et NTP Server

Sur un équipement Cisco, vous pouvez activer ce mode avec la commande ntp master

Dans notre exemple, R1 est configuré à la fois comme client NTP (tant que le serveur NTP externe est disponible) et comme serveur NTP pour le réseau interne.

Quand le serveur NTP principal tombe en panne

Si le serveur NTP externe devient inaccessible, R1 continue à fournir l’heure au réseau interne, mais en utilisant cette fois son horloge matérielle locale comme référence.

Figure 10 – Scénario de basculement du serveur NTP

Cela garantit que :

• Les équipements internes restent synchronisés entre eux.

• Le réseau évite une dérive importante de l’heure pendant l’incident.

Même si la précision est moindre qu’avec une source externe, ce mode de secours reste une solution fiable jusqu’au rétablissement de la source principale.

5. Déploiement NTP dans un réseau réel

Jusqu’ici, nous avons travaillé avec des exemples simples. Mais dans un grand réseau d’entreprise, il est courant de configurer plusieurs serveurs NTP pour garantir redondance et fiabilité.

Plusieurs serveurs NTP pour la redondance

Figure 11 – Clients et serveurs NTP avec plusieurs pairs

Dans cet exemple, les serveurs NTP publics d’Amazon (1.amazon.pool.ntp.org et 2.amazon.pool.ntp.org) sont utilisés pour synchroniser le réseau interne.

Configuration de NTP Master

Les routeurs de bordure (R1 et R2) sont configurés comme NTP Masters avec un stratum de 6, grâce à la commande : ntp master 6

Par défaut, la commande ntp master attribue un stratum 8.
Ici, on le réduit à 6 pour que les clients considèrent les routeurs comme des sources plus fiables en cas de panne des serveurs externes.

Figure 12 – Configuration NTP avec interface loopback et plusieurs serveurs

Ainsi, même si les serveurs externes deviennent injoignables, ces routeurs peuvent continuer à fournir l’heure aux équipements internes en utilisant leur propre horloge.

Utiliser une interface Loopback comme source NTP

Il est également courant de configurer une interface loopback comme source NTP sur un serveur.
De cette façon, les paquets NTP utilisent l’adresse IP de la loopback, qui reste la même même si une interface physique change d’état.

Vous pouvez le faire avec la commande : ntp source loopback0

L’utilisation d’une interface loopback améliore la stabilité et évite les changements d’adresse IP qui pourraient perturber la synchronisation du temps.

6. Points clés à retenir

La compréhension du Network Time Protocol (NTP) est essentielle pour maintenir une synchronisation précise et fiable de l’heure entre les équipements réseau. Voici les notions principales à retenir :

1) Concepts fondamentaux

• NTPv4 via UDP/123 (RFC 5905) : les équipements échangent des horodatages, pas des dates lisibles.
  

• Stratum :

  • Stratum 0 = référence (GPS/atomique)

  • Stratum 1 = serveurs liés directement à 0

  • Stratum 2+ = niveaux inférieurs
    → Plus le stratum est bas, plus la précision est élevée.

  • Stratum 16 = équipement non synchronisé.

• Les horloges dérivent toujours → préférez NTP à une configuration manuelle.

2) Configuration minimale et vérifications

• Sur un client, configurez :

  ntp server 

  Vérifiez avec trois commandes clés :

  • show ntp status → état de synchronisation, stratum, référence.

  • show ntp associations → * = serveur sélectionné.

  • show clock detail → la source de temps doit être NTP.
    

• Astuce : configurez le fuseau horaire (clock timezone …).
  Si l’heure est totalement fausse, corrigez-la une seule fois avec clock set …, puis laissez NTP l’ajuster.

3) Exploitation et dépannage

• La synchronisation prend du temps → NTP converge lentement (intervalles de sondage en minutes).

• NTP Master :

ntp master [stratum]

• (par défaut stratum 8) → garde les horloges internes cohérentes si le serveur en amont tombe.
  

• Réseaux NTP en entreprise :

  • Prévoir plusieurs sources NTP pour la redondance.

  • Utiliser une loopback comme source NTP (ntp source loopback0).