Synchronisation de l’heure NTP sur un cluster de châssis
Ce schéma explique comment un protocole NTP (Network Time Protocol) est utilisé pour synchroniser l’heure entre le moteur de routage et le moteur de transfert de paquets sur un périphérique autonome, ainsi qu’entre les périphériques d’un cluster de châssis.
Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de la plate-forme et de la version pour des fonctionnalités spécifiques.
Synchronisation de l’heure NTP sur les pare-feu
En mode autonome et en mode cluster de châssis, le moteur de routage principal exécute le processus NTP pour obtenir du temps à partir d’un serveur NTP externe. Bien que le moteur de routage secondaire exécute également le processus NTP, il ne peut pas se synchroniser directement avec le serveur NTP externe en raison de contraintes réseau. Au lieu de cela, le moteur de routage secondaire synchronise son heure avec le moteur de routage principal à l’aide de NTP.
NTP est utilisé pour :
-
Synchronisez le temps entre le moteur de routage principal et le moteur de routage secondaire via la liaison de contrôle du cluster de châssis.
-
Obtenez du temps à partir d’un serveur NTP externe pour le moteur de routage principal ou un moteur de routage autonome.
-
Synchronisez le temps entre le processus NTP du moteur de routage et le moteur de transfert de paquets.
Configurez les paramètres de temps NTP pour définir et appliquer le seuil d’ajustement NTP, améliorant ainsi la sécurité et la flexibilité du service NTP.
Voir aussi
Exemple : Simplifier la gestion du réseau en synchronisant les nœuds principal et de sauvegarde avec NTP
Cet exemple montre comment simplifier la gestion en synchronisant le temps entre deux pare-feu fonctionnant dans un cluster de châssis. À l’aide d’un serveur NTP (Network Time Protocol), le nœud principal synchronise l’heure avec le nœud secondaire. NTP est également utilisé pour synchroniser le temps entre le moteur de routage et le moteur de transfert de paquets sur un périphérique autonome et entre les nœuds d’un cluster de châssis. La synchronisation des horloges système sur les deux nœuds du cluster de châssis est nécessaire pour gérer efficacement les éléments suivants :
-
Objets temps réel (RTO)
-
Licences
-
Mises à jour logicielles
-
Basculements de nœuds
-
Analyse des journaux système (syslogs)
Exigences
Cet exemple utilise les composants matériels et logiciels suivants :
-
Pare-feu fonctionnant dans un cluster de châssis
-
Junos OS version 18.1R1 ou ultérieure
Avant de commencer :
-
Comprendre les bases du protocole Network Time Protocol. Voir Présentation de NTP.
Vue d’ensemble
Lorsque les pare-feu fonctionnent en mode cluster de châssis, le nœud secondaire ne peut pas accéder à un serveur NTP externe via le port commercial. Junos OS prend en charge la synchronisation de l’heure du nœud secondaire avec le nœud principal sur la liaison de contrôle en configurant le serveur NTP sur le nœud principal.
Topologie
La figure 1 montre la synchronisation temporelle à partir du nœud pair à l’aide de la liaison de contrôle.
de contrôle
Au nœud principal, le serveur NTP est accessible. Le processus NTP sur le nœud principal peut synchroniser l’heure à partir du serveur NTP, et le nœud secondaire peut synchroniser l’heure avec le nœud principal à partir de la liaison de contrôle.
La configuration
Configuration rapide de la CLI
Pour configurer rapidement cet exemple et synchroniser l’heure à partir du serveur NTP, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie, puis entrez commit en mode configuration.
set system ntp server 1.1.1.121
Synchroniser l’heure à partir du serveur NTP
Procédure étape par étape
Dans cet exemple, vous configurez le nœud principal pour obtenir son heure à partir d’un serveur NTP à l’adresse IP 1.1.1.121. Pour synchroniser l’heure à partir du serveur NTP :
-
Configurez le serveur NTP.
{primary:node0}[edit] [edit system] user@host# set ntp server 1.1.1.121 -
Validez la configuration.
user@host#commit
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show system ntp commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
{primary:node0}[edit]
user@host# show system ntp
server 1.1.1.121
Si vous avez terminé de configurer l’appareil, entrez en commit mode configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérifiez la configuration NTP sur le nœud principal
- Vérifiez la configuration NTP sur le nœud secondaire
Vérifiez la configuration NTP sur le nœud principal
Objet
Vérifiez que la configuration fonctionne correctement.
Mesures à prendre
À partir du mode opérationnel, entrez la show ntp associations commande :
user@host> show ntp associations remote refid st t when poll reach delay offset jitter ============================================================================== *1-1-1-121-dynami 10.208.0.50 4 - 63 64 65 4.909 -12.067 2.014
À partir du mode opérationnel, entrez la show ntp status commande :
user@host> show ntp status status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg, version="ntpd 4.2.0-a Fri Mar 21 00:50:30 PDT 2014 (1)", processor="i386", system="JUNOS12.1I20140320_srx_12q1_x47.1-637245", leap=00, stratum=5, precision=-20, rootdelay=209.819, rootdispersion=513.087, peer=14596, refid=1.1.1.121, reftime=d6dbb2f9.b3f41ff7 Tue, Mar 25 2014 15:47:05.702, poll=6, clock=d6dbb47a.72918b20 Tue, Mar 25 2014 15:53:30.447, state=4, offset=-6.066, frequency=-55.135, jitter=4.343, stability=0.042
Signification
La sortie sur les nœuds principal et secondaire montre l’association NTP comme suit :
-
remote: adresse ou nom de l’homologue NTP distant. -
refid: identificateur de référence de l’homologue distant. Si l’identificateur de référence n’est pas connu, ce champ affiche une valeur de 0.0.0.0. -
st— Stratie du pair à distance. -
t—Type d’homologue : b (diffusion), l (local), m (multicast) ou u (unicast). -
when: à la réception du dernier paquet de l’homologue. -
poll: intervalle d’interrogation, en secondes. -
reach—Registre d’accessibilité, en octal. -
delay: délai estimé actuel de l’homologue, en millisecondes. -
offset: décalage estimé actuel de l’homologue, en millisecondes. -
jitter—Amplitude de la gigue, en millisecondes.
La sortie sur les nœuds principal et secondaire affiche l’état NTP comme suit :
-
status: mot d’état du système, code représentant les éléments d’état répertoriés. -
x events: nombre d’événements survenus depuis la dernière modification de code. Un événement est souvent la réception d’un message d’interrogation NTP. -
version: description détaillée de la version du NTP utilisée. -
processor: plate-forme matérielle actuelle et version du processeur. -
system: description détaillée du nom et de la version du système d’exploitation utilisé. -
leap: nombre de secondes intercalaires utilisées. -
stratum: strate du serveur homologue. Tout ce qui est supérieur à 1 est une source de référence secondaire, et le nombre représente approximativement le nombre de sauts qui s’éloignent du serveur de la strate 1. La strate 1 est une référence primaire, telle qu’une horloge atomique. -
precision- Précision de l’horloge homologue, avec quelle précision la fréquence et l’heure peuvent être maintenues avec ce système de chronométrage particulier. -
rootdelay: délai aller-retour total vers la source de référence principale, en secondes. -
rootdispersion: erreur maximale par rapport à la source de référence primaire, en secondes. -
peer: numéro d’identification de l’homologue utilisé. -
refid: identificateur de référence de l’homologue distant. Si l’identificateur de référence n’est pas connu, ce champ affiche une valeur de 0.0.0.0. -
reftime: heure locale, sous forme d’horodatage, de la dernière mise à jour de l’horloge locale. Si l’horloge locale n’a jamais été synchronisée, la valeur est zéro. -
poll—Intervalle d’interrogation des messages de diffusion NTP, en secondes. -
clock: heure actuelle sur l’horloge du routeur local. -
state: mode de fonctionnement NTP actuel, où 1 est symétriquement actif, 2 symétriquement passif, 3 client, 4 serveur et 5 diffusion. -
offset: décalage estimé actuel de l’homologue, en millisecondes. Indique la différence de temps entre l’horloge de référence et l’horloge locale. -
frequency—Fréquence de l’horloge. -
jitter—Amplitude de la gigue, en millisecondes. -
stability- Mesure de la capacité de cette horloge à maintenir une fréquence constante.
Vérifiez la configuration NTP sur le nœud secondaire
Objet
Vérifiez que la configuration fonctionne correctement.
Mesures à prendre
À partir du mode opérationnel, entrez la show ntp associations commande :
user@host> show ntp associations remote refid st t when poll reach delay offset jitter ============================================================================== 1-1-1-121-dynami .INIT. 16 - - 1024 0 0.000 0.000 4000.00 *129.96.0.1 1.1.1.121 5 u 32 64 377 0.417 0.760 1.204
À partir du mode opérationnel, entrez la show ntp status commande :
user@host> show ntp status status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg, version="ntpd 4.2.0-a Thu Mar 13 01:53:03 PDT 2014 (1)", processor="i386", system="JUNOS12.1I20140312_srx_12q1_x47.2-635305", leap=00, stratum=12, precision=-20, rootdelay=2.408, rootdispersion=892.758, peer=51948, refid=1.1.1.121, reftime=d6d646bb.853d2f42 Fri, Mar 21 2014 13:03:55.520, poll=6, clock=d6d647bc.e8f28b2f Fri, Mar 21 2014 13:08:12.909, state=4, offset=-1.126, frequency=-62.564, jitter=0.617, stability=0.002