Synchronisation de l’heure NTP sur le cluster de châssis
Le protocole NTP (Network Time Protocol) permet de synchroniser le temps entre le moteur de transfert de paquets et le moteur de routage dans un équipement autonome et entre deux équipements dans un cluster de châssis. Pour plus d’informations, consultez les rubriques suivantes :
Synchronisation de l’heure NTP sur les équipements SRX Series
Dans les modes de cluster autonome et de châssis, le moteur de routage principal exécute le processus NTP pour obtenir l’heure du serveur NTP externe. Bien que le moteur de routage secondaire exécute le processus NTP pour tenter d’obtenir l’heure du serveur NTP externe, cette tentative échoue en raison de problèmes réseau. Pour cette raison, le moteur de routage secondaire utilise NTP pour obtenir l’heure du moteur de routage principal.
Utilisez NTP pour :
-
Envoyez l’heure du moteur de routage principal au moteur de routage secondaire via la liaison de contrôle du cluster de châssis.
-
Obtenez le temps d’un serveur NTP externe vers le moteur de routage principal ou autonome.
-
Obtenez le temps entre le processus NTP du moteur de routage et le moteur de transfert de paquets.
À partir de Junos OS version 15.1X49-D70 et Junos OS version 17.3R1, la configuration du seuil d’ajustement temporel NTP est prise en charge sur les périphériques et instances de Pare-feu virtuel vSRX SRX300, SRX320, SRX340, SRX345, SRX1500, SRX4100, SRX4200, SRX5400, SRX5600 et SRX5800. Cette fonctionnalité vous permet de configurer et d’appliquer le seuil d’ajustement NTP pour le service NTP et d’améliorer la sécurité et la flexibilité du protocole de service NTP.
À partir de Junos OS version 23.4R1 et Junos OS version 24.2R1, la configuration du seuil de réglage de l’heure NTP est prise en charge sur les périphériques SRX1600, SRX2300 et SRX4300.
Voir aussi
Exemple : Simplification de la gestion du réseau en synchronisant les nœuds principal et secondaire avec NTP
Cet exemple montre comment simplifier la gestion en synchronisant le temps entre deux pare-feu SRX Series fonctionnant dans un cluster de châssis. À l’aide d’un serveur NTP (Network Time Protocol), le noeud principal peut synchroniser l’heure avec le noeud secondaire. NTP permet de synchroniser le temps entre le moteur de transfert de paquets et le moteur de routage dans un équipement autonome et entre deux équipements dans un cluster de châssis. Vous devez synchroniser les horloges système sur les deux nœuds des pare-feu SRX Series dans un cluster de châssis afin de gérer les éléments suivants :
Objets temps réel (RTO)
Licences
Mises à jour logicielles
Basculements de nœud
Analyse des journaux système (syslogs)
Exigences
Cet exemple utilise les composants matériels et logiciels suivants :
Pare-feu SRX Series fonctionnant dans un cluster de châssis
Junos OS version 12.1X47-D10 ou ultérieure
Avant de commencer :
Comprendre les principes de base du protocole Network Time Protocol. Reportez-vous à la section Présentation de NTP.
Aperçu
Lorsque les pare-feu SRX Series fonctionnent en mode cluster de châssis, le nœud secondaire ne peut pas accéder au serveur NTP externe via le port payant. Junos OS version 12.1X47 ou ultérieure prend en charge la synchronisation de l’heure du nœud secondaire avec le nœud principal via 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 homologue à l’aide de la liaison de contrôle.
de contrôle
Sur le nœud principal, le serveur NTP est accessible. Le processus NTP sur le noeud primaire peut synchroniser l’heure à partir du serveur NTP, et le noeud secondaire peut synchroniser l’heure avec le noeud primaire à partir de la liaison de contrôle.
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 à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.
set system ntp server 1.1.1.121
Synchronisation de l’heure à partir du serveur NTP
Procédure étape par étape
Dans cet exemple, vous configurez le noeud 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.121Validez 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, passez commit en mode de configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification de la configuration NTP sur le noeud principal
- Vérification de la configuration NTP sur le noeud secondaire
Vérification de la configuration NTP sur le noeud principal
But
Vérifiez que la configuration fonctionne correctement.
Action
À 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 noeuds primaire et secondaire affiche 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 la valeur 0.0.0.0.st— Strate de l’homologue distant.t: type d’homologue : b (diffusion), l (local), m (multidiffusion) ou u (unidiffusion).when: date de 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 primaire 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 qui se sont produits depuis la dernière modification du code. Un événement est souvent la réception d’un message d’interrogation NTP.version: description détaillée de la version de 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 à peu près le nombre de sauts à partir du serveur de strate 1. La strate 1 est une référence primaire, telle qu’une horloge atomique.precision—Précision de l’horloge de l’homologue, avec quelle précision la fréquence et le temps peuvent être maintenus avec ce système particulier de chronométrage.rootdelay: délai total aller-retour jusqu’à la source de référence principale, en secondes.rootdispersion: erreur maximale par rapport à la source de référence principale, en secondes.peer—Numéro d’identification de l’homologue en cours d’utilisation.refid: identificateur de référence de l’homologue distant. Si l’identificateur de référence n’est pas connu, ce champ affiche la valeur 0.0.0.0.reftime: heure locale, au format d’horodatage, date 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 actuel de fonctionnement NTP, où 1 est symétrique actif, 2 symétrique passif, 3 est client, 4 est serveur et 5 est diffusion.offset: décalage estimé actuel de l’homologue, en millisecondes. Indique le décalage horaire 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érification de la configuration NTP sur le noeud secondaire
But
Vérifiez que la configuration fonctionne correctement.
Action
À 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
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.