27
Protocole d'Heure Réseau : Livre blanc sur les pratiques recommandées Contenu Introduction Informations générales Terminologie Aperçu Présentation des périphériques Présentation NTP Critères de conception NTP Modes d'association Architecture NTP Technologie d'horloge et serveurs de temps public Exemples de déploiements NTP Réseau de distribution de temps WAN Réseau de distribution de temps de campus à haute strate Réseau de distribution du temps de campus à basse strate Définitions de processus Propriétaire du processus Objectifs du processus Indicateurs de performance du processus Entrées de processus Sorties de processus Définitions des tâches Tâches d'initialisation Tâches itératives Identification des données Caractéristiques générales des données Identification des données SNMP Collecte de données Collecte de données SNMP Présentation des données Rapport NTP Critical Node Rapport de noeud NTP intéressant Rapport de configuration NTP Informations connexes Introduction

Protocole d'Heure Réseau : Livre blanc sur les pratiques

  • Upload
    others

  • View
    3

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Protocole d'Heure Réseau : Livre blanc sur les pratiques

Protocole d'Heure Réseau : Livre blanc sur lespratiques recommandées

Contenu

IntroductionInformations généralesTerminologieAperçuPrésentation des périphériquesPrésentation NTPCritères de conception NTPModes d'associationArchitecture NTPTechnologie d'horloge et serveurs de temps publicExemples de déploiements NTPRéseau de distribution de temps WANRéseau de distribution de temps de campus à haute strateRéseau de distribution du temps de campus à basse strateDéfinitions de processusPropriétaire du processusObjectifs du processusIndicateurs de performance du processusEntrées de processusSorties de processusDéfinitions des tâchesTâches d'initialisationTâches itérativesIdentification des donnéesCaractéristiques générales des donnéesIdentification des données SNMPCollecte de donnéesCollecte de données SNMPPrésentation des donnéesRapport NTP Critical NodeRapport de noeud NTP intéressantRapport de configuration NTPInformations connexes

Introduction

Page 2: Protocole d'Heure Réseau : Livre blanc sur les pratiques

Les réseaux basés sur Internet Protocol (IP) évoluent rapidement du modèle de prestationtraditionnel à un modèle où le besoin de performances et la fiabilité ont besoin d'être mesurées etdans de nombreux cas garanties, avec les accords de niveau de service (SLA). Le besoin de plusgrand aperçu des caractéristiques du réseau a mené aux efforts de recherche significatifs étantdestinés à définir des mesures et des capacités de mesure pour caractériser le comportement duréseau. La base de beaucoup de méthodologies métriques est la mesure du temps.

Informations générales

La synchronisation de l'heure du réseau, dans la mesure requise pour l'analyse des performancesmodernes, est un exercice essentiel. Selon les modèles commerciaux et les services fournis, lacaractérisation des performances réseau peut être considérée comme un important facteur dedifférenciation des services concurrents. Dans ces cas, le déploiement de systèmes de gestion deréseau et l'affectation de ressources d'ingénierie à l'analyse des données de performancescollectées peuvent entraîner des dépenses importantes. Toutefois, si l'on ne prête passuffisamment attention au principe souvent négligé de la synchronisation du temps, ces effortsrisquent de devenir inutiles.

Ce document décrit une définition de processus hypothétique pour l'exécution de fonctions degestion de réseau pour le protocole NTP (Network Time Protocol). Il est prévu que cetteprocédure hypothétique soit utilisée comme exemple d'information et personnalisée par uneorganisation pour aider à atteindre les objectifs internes.

Les renseignements fournis dans le présent document sont présentés dans plusieurs grandessections, qui sont décrites ci-après.

La section Terminologie fournit des définitions générales des termes relatifs à la synchronisationtemporelle.

La section Vue d'ensemble fournit des informations générales sur le matériel d'élément réseau liéà l'heure système, une présentation technologique du protocole NTP et les principaux aspects deconception de l'architecture NTP.

La section Exemple de déploiement NTP fournit des exemples de déploiement NTP avec desexemples de configurations pour les réseaux WAN, campus à haute strate et réseaux dedistribution de temps de campus à basse strate.

La section Définitions de processus donne un aperçu des définitions de processus utilisées pourréaliser la gestion des NTP. Les détails du processus sont décrits en termes d'objectifs,d'indicateurs de performance, d'entrées, de sorties et de tâches individuelles.

La section Définitions des tâches fournit des définitions détaillées des tâches de processus.Chaque tâche est décrite en termes d'objectifs, d'entrées de tâches, de sorties de tâches, deressources nécessaires à l'exécution de la tâche et de compétences professionnelles requisespour l'implémenteur de la tâche.

La section Identification des données décrit l'identification des données pour NTP. L'identificationdes données tient compte de la source de l'information. Par exemple, les informations peuventêtre contenues dans la base MIB (Management Information Base) SNMP (Simple NetworkManagement Protocol), dans les fichiers journaux générés par Syslog ou par des structures dedonnées internes accessibles uniquement par l'interface de ligne de commande (CLI).

Page 3: Protocole d'Heure Réseau : Livre blanc sur les pratiques

La section Collecte de données décrit la collecte des données NTP. La collecte des données estétroitement liée à l'emplacement des données. Par exemple, les données MIB SNMP sontcollectées par plusieurs mécanismes tels que les déroutements, les alarmes et événementsRMON (Remote Monitoring) ou les interrogations. Les données gérées par des structures dedonnées internes sont collectées par des scripts automatiques ou par un utilisateur se connectantmanuellement au système pour émettre la commande CLI et enregistrer le résultat.

La section Présentation des données fournit des exemples de présentation des données.

Terminologie

Précision : proximité de la valeur absolue de l'horloge au décalage de zéro.●

Précis : lorsque le décalage d'une horloge est égal à zéro à un moment donné dans le temps.●

Dérive : mesure de la variation de l'inclinaison, ou deuxième dérivation du décalage del'horloge par rapport au temps.

Résolution commune : lorsque vous comparez des horloges, il s'agit de la somme desrésolutions de C1 et C2. La résolution commune indique alors une limite inférieure prudentequant à la précision des intervalles de temps calculés en soustrayant les horloges généréespar une horloge de celles générées par l'autre.

Noeud : désigne une instanciation du protocole NTP sur un processeur local. Un noeud peutégalement être appelé périphérique.

Décalage : différence entre l'heure signalée par une horloge et l'heure réelle définie parl'heure UTC (Coordinated Universal Time). Si l'horloge signale une heure Tc et que l'heureréelle est Tt, le décalage de l'horloge est Tc - Tt.

Peer : désigne une instanciation du protocole NTP sur un processeur distant connecté par unchemin réseau à partir du noeud local.

Décalage relatif - La notion d'heure réelle est remplacée par l'heure telle qu'elle est signaléepar l'horloge C1, lors de la comparaison entre deux horloges, C1 et C2. Par exemple, ledécalage de l'horloge C2 par rapport à C1 à un moment donné est Tc2 - Tc1, la différenceinstantanée de temps signalée par C2 et C1.

Résolution : la plus petite unité par laquelle l'heure d'une horloge est mise à jour. La résolutionest définie en secondes. Cependant, la résolution est relative à l'heure rapportée par l'horlogeet non à l'heure réelle. Par exemple, une résolution de 10 millisecondes signifie que l'horlogemet à jour sa notion de temps par incréments de 0,01 seconde et ne signifie pas qu'il s'agit dela durée réelle entre les mises à jour.Note : Les horloges peuvent avoir de très bellesrésolutions et être toujours inexactes.

Décalage : différence de fréquence d'une horloge, ou premier dérivé de son décalage parrapport à l'heure.

Synchroniser : lorsque deux horloges sont exactes l'une par rapport à l'autre (le décalagerelatif est zéro), elles sont synchronisées. Les horloges peuvent être synchronisées et encoreinexactes en termes de leur capacité à dire l'heure exacte.

Aperçu

Présentation des périphériques

Le coeur du service de temps est l'horloge système. L'horloge système s'exécute à partir du

Page 4: Protocole d'Heure Réseau : Livre blanc sur les pratiques

moment où le système démarre et suit la date et l'heure actuelles. L'horloge système peut êtredéfinie à partir de plusieurs sources et, à son tour, peut être utilisée pour distribuer l'heure actuelleà d'autres systèmes via différents mécanismes. Certains routeurs contiennent un système decalendrier alimenté par batterie qui suit la date et l'heure des redémarrages du système et despannes de courant. Ce système de calendrier est toujours utilisé pour initialiser l'horloge systèmelors du redémarrage du système. Elle peut également être considérée comme une source detemps faisant autorité et redistribuée par le biais de NTP si aucune autre source n'est disponible.En outre, si NTP est en cours d'exécution, le calendrier peut être mis à jour périodiquement àpartir de NTP, ce qui compense la dérive inhérente à l'heure du calendrier. Lorsqu'un routeur avecun calendrier système est initialisé, l'horloge système est définie en fonction de l'heure de soncalendrier interne alimenté par batterie. Sur les modèles sans calendrier, l'horloge système estdéfinie sur une constante temporelle prédéfinie. L'horloge système peut être définie à partir dessources répertoriées ci-dessous.

NTP●

SNTP (Simple Network Time Protocol)●

Service VINES (Virtual Integrated Network Service)●

Configuration manuelle●

Certains périphériques Cisco bas de gamme prennent uniquement en charge SNTP. SNTP estune version simplifiée et réservée aux clients de NTP. Le protocole SNTP ne peut recevoir l'heureque des serveurs NTP et ne peut pas être utilisé pour fournir des services temporels à d'autressystèmes. Le protocole SNTP fournit généralement du temps dans les 100 millisecondes del'heure exacte. En outre, SNTP n'authentifie pas le trafic, bien que vous puissiez configurer deslistes d'accès étendues pour fournir une certaine protection. Un client SNTP est plus vulnérableaux erreurs de comportement des serveurs qu'un client NTP et ne doit être utilisé que dans dessituations où une authentification forte n'est pas requise.

L'horloge système fournit du temps aux services répertoriés ci-dessous.

NTP●

Service de temps VINES●

Commandes show utilisateur●

Journalisation et débogage des messages●

L'horloge système suit l'heure en interne en fonction de l'heure UTC, également appelée GMT(Greenwich Mean Time). Vous pouvez configurer des informations sur le fuseau horaire local etl'heure d'été de sorte que l'heure soit affichée correctement par rapport au fuseau horaire local.L'horloge système permet de savoir si l'heure fait autorité ou non. S'il n'est pas autorisé, le tempssera disponible uniquement à des fins d'affichage et ne sera pas redistribué.

Présentation NTP

NTP est conçu pour synchroniser l'heure sur un réseau de machines. Le protocole NTP s'exécutesur le protocole UDP (User Datagram Protocol), en utilisant le port 123 comme source etdestination, qui à son tour s'exécute sur IP. NTP version 3 RFC 1305 est utilisé pour synchroniserla gestion des temps entre un ensemble de serveurs et de clients de temps distribués. Unensemble de noeuds sur un réseau est identifié et configuré avec le protocole NTP et les noeudsforment un sous-réseau de synchronisation, parfois appelé réseau de superposition. Bien queplusieurs maîtres (serveurs principaux) existent, aucun protocole de sélection n'est requis.

Un réseau NTP obtient généralement son heure à partir d’une source temporelle faisant autorité,telle qu’une horloge radio ou une horloge atomique connectée à un serveur temporel. NTP

Page 5: Protocole d'Heure Réseau : Livre blanc sur les pratiques

distribue ensuite cette fois sur le réseau. Un client NTP effectue une transaction avec son serveurau cours de son intervalle d'interrogation (de 64 à 1 024 secondes) qui change dynamiquement aufil du temps en fonction des conditions réseau entre le serveur NTP et le client. L'autre situation seproduit lorsque le routeur communique avec un serveur NTP défectueux (par exemple, un serveurNTP avec une grande dispersion); le routeur augmente également l’intervalle d’interrogation. Iln'est pas nécessaire d'effectuer plus d'une transaction NTP par minute pour synchroniser deuxmachines. Il n'est pas possible de régler l'intervalle d'interrogation NTP sur un routeur.

Le protocole NTP utilise le concept de strate pour décrire le nombre de sauts NTP qui séparentune machine d'une source temporelle faisant autorité. Par exemple, un serveur de temps de strate1 est directement relié à une radio ou à une horloge atomique. Il envoie ensuite son temps à unserveur de temps de strate 2 via NTP, etc. Une machine exécutant NTP choisit automatiquementla machine dont le numéro de strate est le plus bas avec laquelle elle est configurée pourcommuniquer en utilisant NTP comme source temporelle. Cette stratégie construit uneorganisation autonome efficace de haut-parleurs NTP. Le protocole NTP fonctionne bien sur leslongueurs de chemin non déterministes des réseaux à commutation de paquets, car il établit desestimations robustes des trois variables clés suivantes dans la relation entre un client et unserveur de temps.

Délai du réseau●

Dispersion des échanges de paquets temporels : mesure de l'erreur d'horloge maximale entreles deux hôtes.

Décalage d'horloge : correction appliquée à l'horloge d'un client pour la synchroniser.●

La synchronisation des horloges au niveau de 10 millisecondes sur les réseaux étendus longuedistance (WAN) (2 000 km) et au niveau de 1 milliseconde pour les réseaux locaux (LAN) estrégulièrement effectuée.

NTP évite de se synchroniser avec une machine dont l'heure n'est peut-être pas exacte de deuxfaçons. Tout d'abord, NTP ne se synchronise jamais avec une machine qui n'est pas synchroniséeelle-même. Deuxièmement, NTP compare le temps signalé par plusieurs machines et ne sesynchronise pas avec une machine dont le temps est significativement différent des autres, mêmesi sa strate est inférieure.

Les communications entre les machines exécutant NTP (associations) sont généralementconfigurées de manière statique. Chaque machine reçoit l'adresse IP de toutes les machines aveclesquelles elle doit former des associations. Une gestion précise du temps est rendue possible enéchangeant des messages NTP entre chaque paire de machines avec une association.Cependant, dans un environnement LAN, le protocole NTP peut être configuré pour utiliser desmessages de diffusion IP à la place. Cette alternative réduit la complexité de configuration, carchaque machine peut être configurée pour envoyer ou recevoir des messages de diffusion.Cependant, la précision de la gestion du temps est légèrement réduite, car le flux d'informationsn'est qu'à sens unique.

Le temps restant sur une machine est une ressource essentielle et il est fortement recommandéd'utiliser les fonctions de sécurité de NTP pour éviter le paramètre accidentel ou malveillant detemps incorrect. Les deux fonctions de sécurité disponibles sont un schéma de restriction basésur une liste d'accès et un mécanisme d'authentification chiffré.

La mise en oeuvre de NTP par Cisco prend en charge le service de strate 1 dans certainesversions du logiciel Cisco IOS. Si une version prend en charge la commande ntp refclock, il estpossible de connecter une radio ou une horloge atomique. Certaines versions de Cisco IOSprennent en charge le kit de synchronisation NTP Trimble Palisade (routeurs de la gamme Cisco

Page 6: Protocole d'Heure Réseau : Livre blanc sur les pratiques

7200 uniquement) ou le périphérique GPS (Global Positioning System) de Telecom Solutions. Sile réseau utilise les serveurs de temps public sur Internet et que le réseau est isolé d'Internet,l'implémentation de NTP par Cisco permet à une machine d'être configurée de sorte qu'ellefonctionne comme si elle était synchronisée via NTP, alors qu'en fait elle a déterminé le temps enutilisant d'autres moyens. D'autres machines se synchronisent ensuite avec cette machine viaNTP.

Critères de conception NTP

Chaque client du sous-réseau de synchronisation, qui peut également être un serveur pour lesclients de couche supérieure, choisit l'un des serveurs disponibles à synchroniser. Il s'agitgénéralement de l'un des serveurs de couche inférieure auxquels il a accès. Cependant, il nes'agit pas toujours d'une configuration optimale, car NTP fonctionne également en partant duprincipe que l'heure de chaque serveur doit être considérée avec une certaine méfiance. NTPpréfère avoir accès à plusieurs sources de temps de basse strate (au moins trois) car il peut alorsappliquer un algorithme d'accord pour détecter la folie de la part de l'une de ces sources.Normalement, lorsque tous les serveurs sont d'accord, NTP choisit le meilleur serveur en termesde strate la plus basse, la plus proche (en termes de délai réseau) et la précision revendiquée.Cela implique que, bien que l'on doive viser à fournir à chaque client trois sources ou plus detemps de couche inférieure, plusieurs d'entre elles fournissent uniquement un service desauvegarde et peuvent être de moindre qualité en termes de délai et de strate réseau. Parexemple, un homologue de même strate qui reçoit du temps des sources de strate inférieureauxquelles le serveur local n'accède pas directement peut également fournir un bon service desauvegarde.

NTP préfère généralement les serveurs de couche inférieure aux serveurs de couche supérieure,à moins que le temps du serveur de couche inférieure ne soit significativement différent.L'algorithme est capable de détecter quand une source temporelle est susceptible d'êtreextrêmement inexacte, ou folle, et d'empêcher la synchronisation dans ces cas, même si l'horlogeinexacte est à un niveau de strate inférieur. Et il ne synchronisera jamais un périphérique vers unautre serveur qui n'est pas synchronisé lui-même.

Afin de déclarer si le serveur est fiable, il doit passer de nombreux contrôles de bon sens, tels que:

Les mises en oeuvre doivent inclure des délais d'attente sains qui empêchent lestransmissions de déroutements si le programme de surveillance ne renouvelle pas cesinformations après un long intervalle.

Des contrôles d'intégrité supplémentaires sont inclus pour l'authentification, les limites deplage et pour éviter l'utilisation de données très anciennes.

Des vérifications ont été ajoutées pour avertir que l'oscillateur est passé trop longtemps sansmise à jour à partir d'une source de référence.

Les variables peer.valide et sys.hold ont été ajoutées pour éviter les instabilités lorsque lasource de référence change rapidement en raison de retards de dispersion importants dansdes conditions de congestion grave du réseau. Les bits peer.config, peer.authenable etpeer.authentication ont été ajoutés pour contrôler les fonctionnalités spéciales et simplifier laconfiguration.

Si au moins une de ces vérifications échoue, le routeur la déclare folle.

Modes d'association

Page 7: Protocole d'Heure Réseau : Livre blanc sur les pratiques

Les sections suivantes décrivent les modes d'association utilisés par les serveurs NTP pours'associer.

Client/Serveur●

Symétrique actif/passif●

Diffusion●

Mode client/serveur

Les clients et serveurs dépendants fonctionnent normalement en mode client/serveur, dans lequelun client ou un serveur dépendant peut être synchronisé avec un membre de groupe, mais aucunmembre de groupe ne peut se synchroniser avec le client ou le serveur dépendant. Cela fournitune protection contre les dysfonctionnements ou les attaques de protocole.

Le mode client/serveur est la configuration Internet la plus courante. Il fonctionne dans leparadigme classique RPC (Remote-Procedure-Call) avec des serveurs sans état. Dans ce mode,un client envoie une requête au serveur et attend une réponse ultérieurement. Dans certainscontextes, cela serait décrit comme une opération d'interrogation, dans la mesure où le clientinterroge les données d'authentification et d'heure du serveur. Un client est configuré en modeclient à l'aide de la commande server et en spécifiant le nom ou l'adresse du serveur de noms dedomaine (DNS). Le serveur ne nécessite aucune configuration préalable.

Dans un modèle client/serveur commun, un client envoie un message NTP à un ou plusieursserveurs et traite les réponses comme reçues. Le serveur échange les adresses et les ports,remplace certains champs du message, recalcule la somme de contrôle et renvoie le messageimmédiatement. Les informations incluses dans le message NTP permettent au client dedéterminer l'heure du serveur par rapport à l'heure locale et d'ajuster l'horloge locale enconséquence. En outre, le message inclut des informations permettant de calculer la précision etla fiabilité de la gestion du temps, ainsi que de sélectionner le meilleur serveur.

Les serveurs qui fournissent la synchronisation à un nombre important de clients fonctionnentnormalement comme un groupe de trois serveurs redondants réciproquement, chacunfonctionnant avec trois serveurs de strate 1 ou de strate 2 ou plus en mode client/serveur, ainsique tous les autres membres du groupe en mode symétrique. Cela fournit une protection contreles dysfonctionnements dans lesquels un ou plusieurs serveurs ne fonctionnent pas ou fournissentun temps incorrect. Les algorithmes NTP sont conçus pour résister aux attaques lorsqu'unefraction des sources de synchronisation configurées fournissent accidentellement ou délibérémentun temps incorrect. Dans ces cas, une procédure de vote spéciale est utilisée pour identifier lessources fallacieuses et ignorer leurs données. Par souci de fiabilité, certains hôtes peuvent êtreéquipés d’horloges externes et utilisés pour la sauvegarde en cas de défaillance des serveursprincipal et/ou secondaire, ou des chemins de communication entre eux.

La configuration d'une association en mode client, généralement indiquée par une déclaration deserveur dans le fichier de configuration, indique qu'un utilisateur souhaite obtenir du temps duserveur distant, mais qu'il n'est pas disposé à fournir du temps au serveur distant.

Mode actif/passif symétrique

Le mode actif/passif symétrique est conçu pour les configurations dans lesquelles un grouped'homologues de basse strate fonctionne comme des sauvegardes mutuelles les unes pour lesautres. Chaque homologue fonctionne avec une ou plusieurs sources de référence principales,

Page 8: Protocole d'Heure Réseau : Livre blanc sur les pratiques

telles qu'une horloge radio ou un sous-ensemble de serveurs secondaires fiables. Si l'un deshomologues perd toutes les sources de référence ou cesse tout simplement de fonctionner, lesautres homologues reconfigurent automatiquement de sorte que les valeurs de temps puissentcirculer des homologues survivants vers tous les autres membres de la clique. Dans certainscontextes, ceci est décrit comme une opération push-pull, en ce sens que l'homologue tire oupousse le temps et les valeurs selon la configuration particulière.

La configuration d'une association en mode symétrique-actif, généralement indiquée par unedéclaration d'homologue dans le fichier de configuration, indique au serveur distant qu'il souhaiteobtenir du temps du serveur distant et qu'il est également disposé à fournir du temps au serveurdistant si nécessaire. Ce mode est approprié dans les configurations impliquant un certain nombrede serveurs de temps redondants interconnectés via différents chemins réseau, ce qui estactuellement le cas pour la plupart des serveurs de strate 1 et de strate 2 sur Internet aujourd'hui.

Les modes symétriques sont le plus souvent utilisés entre deux serveurs ou plus fonctionnant entant que groupe redondant. Dans ces modes, les serveurs des membres du groupe organisent leschemins de synchronisation pour des performances maximales, en fonction de la gigue du réseauet du délai de propagation. Si un ou plusieurs membres du groupe échouent, les autres membresreconfigurent automatiquement selon les besoins.

Un homologue est configuré en mode actif symétrique à l'aide de la commande peer et enspécifiant le nom ou l'adresse DNS de l'autre homologue. L'autre homologue est égalementconfiguré en mode actif symétrique de cette manière.

Remarque : Si l'autre homologue n'est pas configuré de cette manière, une association passivesymétrique est activée à l'arrivée d'un message actif symétrique. Comme un intrus peut imiter unhomologue actif symétrique et injecter des valeurs de temps erronées, le mode symétrique doittoujours être authentifié.

Mode de diffusion et/ou multidiffusion

Lorsque les besoins en précision et en fiabilité sont modestes, les clients peuvent être configuréspour utiliser des modes de diffusion et/ou de multidiffusion. Normalement, ces modes ne sont pasutilisés par les serveurs avec des clients dépendants. L'avantage est que les clients n'ont pasbesoin d'être configurés pour un serveur spécifique, ce qui permet à tous les clients d'exploitationd'utiliser le même fichier de configuration. Le mode de diffusion nécessite un serveur de diffusionsur le même sous-réseau. Puisque les messages de diffusion ne sont pas propagés par lesrouteurs, seuls les serveurs de diffusion du même sous-réseau sont utilisés.

Le mode de diffusion est destiné aux configurations impliquant un ou plusieurs serveurs et unepopulation de clients potentiellement importante. Un serveur de diffusion est configuré à l'aide dela commande broadcast et d'une adresse de sous-réseau locale. Un client de diffusion estconfiguré à l'aide de la commande broadcast client, ce qui permet au client de diffusion derépondre aux messages de diffusion reçus sur n'importe quelle interface. Comme un intrus peutse faire passer pour un serveur de diffusion et injecter des valeurs de temps erronées, ce modedoit toujours être authentifié.

Configuration du saut NTP en deuxième

Vous pouvez utiliser le saut ntp {add | delete} afin d'insérer une seconde de saut. Il existe desoptions pour ajouter et supprimer des secondes bissextiles. Il y a deux contraintes pour cela :

Page 9: Protocole d'Heure Réseau : Livre blanc sur les pratiques

L'horloge doit être synchronisée.●

La commande n'est acceptée que dans le mois précédant le saut. Il ne définit pas le saut sil'heure actuelle est antérieure à 1 mois de l'occurrence du saut.

Une fois que vous l'avez défini, la seconde saut est ajoutée ou supprimée à la dernière seconde,comme indiqué ici :

NTP leap second added :

Show clock given continuously

vl-7500-6#show clock

23:59:58.123 UTC Sun Dec 31 2006

vl-7500-6#show clock

23:59:58.619 UTC Sun Dec 31 2006

vl-7500-6#show clock

23:59:59.123 UTC Sun Dec 31 2006

vl-7500-6#show clock

23:59:59.627 UTC Sun Dec 31 2006

<< 59th second occuring twice

vl-7500-6#show clock

23:59:59.131 UTC Sun Dec 31 2006

vl-7500-6#show clock

23:59:59.627 UTC Sun Dec 31 2006

vl-7500-6#show clock

00:00:00.127 UTC Mon Jan 1 2007

vl-7500-6#show clock

00:00:00.623 UTC Mon Jan 1 2007

Architecture NTP

Les trois structures suivantes sont disponibles pour l'architecture NTP.

Structure d'homologue plate●

Structure hiérarchique●

Structure en étoile●

Dans une structure d’homologue linéaire, tous les routeurs s’homologue, avec quelques routeursgéographiquement distincts configurés pour pointer vers des systèmes externes. La convergencetemporelle devient plus longue avec chaque nouveau membre du maillage NTP.

Dans une structure hiérarchique, la hiérarchie de routage est copiée pour la hiérarchie NTP. Lesrouteurs principaux ont une relation client/serveur avec des sources de temps externes, lesserveurs de temps internes ont une relation client/serveur avec les routeurs principaux, lesrouteurs client interne (serveurs non temps) ont une relation client/serveur avec les serveurs detemps internes, etc. dans l'arborescence. Ces relations sont appelées échelles hiérarchiques. Unestructure hiérarchique est la technique privilégiée car elle assure cohérence, stabilité et évolutivité.

Une architecture NTP évolutive a une structure hiérarchique comme le montre le schéma ci-dessous.

Page 10: Protocole d'Heure Réseau : Livre blanc sur les pratiques

Dans une structure en étoile, tous les routeurs ont une relation client-serveur avec quelquesserveurs temporels dans le coeur. Les serveurs de temps dédiés sont le centre de l'étoile et sontgénéralement des systèmes UNIX synchronisés avec des sources de temps externes, ou leurpropre récepteur GPS.

Technologie d'horloge et serveurs de temps public

Le sous-réseau Internet NTP comprend actuellement plus de 50 serveurs principaux publicssynchronisés directement avec UTC par radio, satellite ou modem. Normalement, les postes detravail client et les serveurs avec un nombre relativement réduit de clients ne sont passynchronisés aux serveurs principaux. Environ 100 serveurs secondaires publics sontsynchronisés avec les serveurs principaux, ce qui permet de synchroniser plus de 100 000 clientset serveurs sur Internet. Les listes des serveurs temporels NTP publics sont fréquemment mises àjour. Il existe également de nombreux serveurs privés principaux et secondaires qui ne sontnormalement pas accessibles au public.

Remarque : PIX et ASA ne peuvent pas être configurés en tant que serveur NTP, mais ils peuventêtre configurés en tant que client NTP.

Dans certains cas, lorsque des services de temps très précis sont requis dans l'entreprise privée,

Page 11: Protocole d'Heure Réseau : Livre blanc sur les pratiques

tels que des mesures unidirectionnelles pour la voix sur IP (VoIP), les concepteurs de réseaupeuvent choisir de déployer des sources de temps externes privées. Le diagramme ci-dessousmontre un graphique comparatif de la précision relative des technologies actuelles.

Jusqu'à récemment, l'utilisation de sources de temps externes n'avait pas été largement déployéedans les réseaux d'entreprise en raison du coût élevé de sources de temps externes de qualité.Cependant, à mesure que les exigences de qualité de service (QoS) augmentent et que le coût dela technologie continue de diminuer, les sources de temps externes pour les réseaux d'entreprisedeviennent une option viable.

Exemples de déploiements NTP

Réseau de distribution de temps WAN

Dans le schéma ci-dessous, un système autonome d'entreprise (AS) obtient des informationstemporelles de trois serveurs de temps publics. Le système autonome d'entreprise est représentépar les serveurs de zone 0 et de zone 1. Dans cet exemple, la hiérarchie NTP suit la hiérarchieOSPF (Open Shortest Path First). Cependant, le protocole OSPF n'est pas une conditionpréalable au protocole NTP. Il n'est utilisé qu'à titre d'exemple. Le protocole NTP peut êtredéployé le long d'autres frontières hiérarchiques logiques, telles qu'une hiérarchie EIGRP(Enhanced Interior Gateway Routing Protocol) ou la hiérarchie Core/Distribution/Access standard.

Page 12: Protocole d'Heure Réseau : Livre blanc sur les pratiques

Voici la configuration de Cisco IOS pour le périphérique A0-R1 dans le schéma ci-dessus.

clock timezone CST -5

clock summer-time CDT recurring

!--- This router has a hardware calendar. !--- To configure a system as an !--- authoritative

time source for a network !--- based on its hardware clock (calendar), !--- use the clock

calendar-valid global !--- configuration command. Notice later that !--- NTP will be allowed to

update the calendar !--- and Cisco IOS will be configured to be an !--- NTP master clock source.

!--- Cisco IOS will then obtain its clock from !--- the hardware calendar. clock calendar-valid

!--- This allows NTP to update the hardware !--- calendar chip. ntp update-calendar !---

Configures the Cisco IOS software as an !--- NTP master clock to which peers synchronize !---

themselves when an external NTP source is !--- not available. Cisco IOS will obtain the !---

clock from the hardware calendar based on !--- the previous line. This line will keep the !---

whole network in Sync even if Router1 loses !--- its signal from the Internet. Assume, for !---

this example, that the Internet time servers !--- are stratum 2. ntp master 3 !--- When the

system sends an NTP packet, the !--- source IP address is normally set to the !--- address of

the interface through which the !--- NTP packet is sent. !--- Change this to use loopback0. ntp

source Loopback0 !--- Enables NTP authentication. ntp authenticate ntp authentication-key 1234

md5 104D000A0618 7 ntp trusted-key 1234 !--- Configures the access control groups for !--- the

public servers and peers for additional !--- security. access-list 5 permit <I-TS-1> access-list

5 permit <I-TS-2> access-list 5 permit <I-TS-3> access-list 5 permit <A0-R2> access-list 5

permit <A0-R3> access-list 5 deny any !--- Configures the access control groups for the !---

clients to this node for additional security. access-list 6 permit <A1-R1> access-list 6 permit

<A1-R2> access-list 6 permit <A1-R3> access-list 6 deny any !--- Restricts the IP addresses for

the peers !--- and clients. ntp access-group peer 5 ntp access-group serve-only 6 !--- Fault

tolerant configuration polling for 3 NTP !--- public servers, peering with 2 local servers. ntp

server <I-TS-1> ntp server <I-TS-2> ntp server <I-TS-3> ntp peer <A0-R2> ntp peer <A0-R3>

Réseau de distribution de temps de campus à haute strate

Page 13: Protocole d'Heure Réseau : Livre blanc sur les pratiques

La section précédente décrit un réseau de distribution de temps WAN. Cette section déplace uneétape vers le bas de la hiérarchie pour discuter de la répartition du temps sur un réseau decampus de haut niveau.

La principale différence lors de la répartition du temps sur un réseau de campus de strate élevéeest l’utilisation potentielle du mode d’association de diffusion. Comme décrit précédemment, lemode d’association de diffusion simplifie les configurations des réseaux locaux, mais réduit laprécision des calculs de temps. Par conséquent, le compromis entre les coûts d'entretien et laprécision des mesures de performance doit être pris en compte.

Le réseau de campus à haute strate, illustré dans le schéma ci-dessus, provient de la conceptionde réseau de campus Cisco standard et comprend trois composants. Le coeur du campus secompose de deux périphériques de couche 3 étiquetés CB-1 et CB-2. Le composant serveur,situé dans la section inférieure de la figure, comporte deux routeurs de couche 3, nommés SD-1et SD-2. Les autres périphériques du bloc serveur sont des périphériques de couche 2. En haut àgauche, il y a un bloc d'accès standard avec deux périphériques de distribution de couche 3étiquetés dl-1 et dl-2. Les autres périphériques sont des commutateurs de couche 2. Dans ce blocd'accès client, l'heure est distribuée à l'aide de l'option de diffusion. En haut à droite, il y a un autrebloc d'accès standard qui utilise une configuration de distribution de temps client/serveur.

Les périphériques de réseau fédérateur de campus sont synchronisés avec les serveurs de zonedans un modèle client/serveur.

La configuration des périphériques de distribution de couche 3 dl-1 est présentée ci-dessous.

Page 14: Protocole d'Heure Réseau : Livre blanc sur les pratiques

!--- In this case, dl-1 will be a broadcast server !--- for the Layer 2 LAN. internet Ethernet0

ntp broadcast clock timezone CST -5 clock summer-time CDT recurring !--- When the system sends

an NTP packet, the !--- source IP address is normally set to the !--- address of the interface

through which the !--- NTP packet is sent. !--- Change this to use loopback0. ntp source

Loopback0 !--- Enables NTP authentication. ntp authenticate ntp authentication-key 1234 md5

104D000A0618 7 ntp trusted-key 1234 !--- Configures the access control groups for !--- the

public servers and peers for !--- additional security. access-list 5 permit <CB-1> access-list 5

permit <CB-2> access-list 5 permit <dl-2> access-list 5 deny any !--- Restricts the IP addresses

for the peers !--- and clients. ntp access-group peer 5 !--- Fault tolerant configuration

polling 2 !--- local time servers and 1 local peer. ntp server <CB-1> ntp server <CB-2> ntp peer

<dl-2>

Réseau de distribution du temps de campus à basse strate

Dans le schéma ci-dessous, une source temporelle GPS ou Cesium est fournie au centre dedonnées central pour le réseau de campus à basse strate. Cela fournit une source temporelle destrate 1 sur le réseau privé. Si plusieurs sources de temps GPS ou Cesium sont situées dans leréseau privé, la distribution de temps dans le réseau privé doit être modifiée pour tirer parti dessources de temps disponibles.

En général, les mêmes principes et configurations s'appliquent que dans les exemplesprécédents. La principale différence dans ce cas est que la racine de l'arborescence desynchronisation est une source temporelle privée plutôt qu'une source temporelle publique à partird'Internet. Cela modifie la conception du réseau de distribution du temps pour tirer parti de lasource privée de temps haute précision. La source de temps privée est distribuée sur l'ensembledu réseau privé en utilisant les principes de hiérarchie et de modularité décrits dans les sectionsprécédentes.

Page 15: Protocole d'Heure Réseau : Livre blanc sur les pratiques

Définitions de processus

Une définition de processus est une série d'actions, d'activités et de changements liés effectuéspar des agents dans le but de répondre à un objectif ou d'atteindre un objectif.

Le contrôle des processus est le processus de planification et de réglementation qui a pourobjectif d'exécuter un processus de façon efficace et efficiente.

Sur le plan graphique, ceci est illustré dans le schéma ci-dessous.

Page 16: Protocole d'Heure Réseau : Livre blanc sur les pratiques

Le résultat du processus doit être conforme aux normes opérationnelles définies par uneorganisation et fondées sur des objectifs commerciaux. Si le processus est conforme à l'ensembledes normes, il est considéré comme efficace puisqu'il peut être répété, mesuré, géré et qu'ilcontribue aux objectifs de l'entreprise. Si les activités sont menées avec un minimum d'effort, leprocessus est également considéré comme efficace.

Propriétaire du processus

Les processus s'étendent sur différentes frontières organisationnelles. Par conséquent, il estimportant d'avoir un seul propriétaire de processus responsable de la définition du processus. Lepropriétaire est le point central pour déterminer et signaler si le processus est efficace et efficient.Si le processus n'est pas efficace ou efficient, le propriétaire du processus entraîne la modificationdu processus. La modification du processus est régie par des processus de contrôle et d'examendes changements.

Objectifs du processus

Page 17: Protocole d'Heure Réseau : Livre blanc sur les pratiques

Les objectifs du processus sont établis pour définir l'orientation et la portée de la définition duprocessus. Les objectifs sont également utilisés pour définir les indicateurs utilisés pour mesurerl'efficacité d'un processus.

L'objectif de ce processus est de fournir des critères à documenter pendant la phase deconception NTP et de fournir une capacité d'audit pour une architecture NTP déployée assurant laconformité à long terme avec la conception prévue.

Indicateurs de performance du processus

Les indicateurs de rendement du processus servent à évaluer l'efficacité de la définition duprocessus. Les indicateurs de résultats devraient être mesurables et quantifiables. Par exemple,les indicateurs de performance énumérés ci-dessous sont soit numériques, soit mesurés par letemps.

La durée nécessaire au cycle de l'ensemble du processus.●

Fréquence d'exécution requise pour détecter de manière proactive les problèmes NTP avantqu'ils n'affectent les utilisateurs.

Charge réseau associée à l'exécution du processus.●

Nombre de mesures correctives recommandées par le processus.●

Nombre de mesures correctives mises en oeuvre à la suite du processus.●

Durée nécessaire à la mise en oeuvre des mesures correctives.●

L'arriéré des mesures correctives.●

Les erreurs de dépannage ou de diagnostic de problème attribuées aux problèmes liés auprotocole NTP.

Nombre d'éléments ajoutés, supprimés ou modifiés dans le fichier d'amorçage. C'est uneindication de précision et de stabilité.

Entrées de processus

Les entrées de processus sont utilisées pour définir les critères et les conditions préalables d'unprocessus. Souvent, l'identification des entrées de processus fournit des informations sur lesdépendances externes. On trouvera ci-après une liste des intrants liés à la gestion du NTP.

Documentation de conception NTP●

Données MIB NTP collectées par interrogation SNMP●

Sorties de processus

Les résultats du processus sont définis comme suit :

Rapports de configuration NTP définis dans la section Présentation des données de cedocument

Actions correctives NTP●

Définitions des tâches

Les sections suivantes définissent les tâches d'initialisation et d'itération associées à la gestionNTP.

Page 18: Protocole d'Heure Réseau : Livre blanc sur les pratiques

Tâches d'initialisation

Les tâches d'initialisation sont exécutées une fois lors de la mise en oeuvre du processus et nedoivent pas être exécutées pendant chaque itération du processus.

Créer la conception NTP

Lors de la vérification des tâches préalables, s'il est déterminé que l'une des tâches n'est pas miseen oeuvre ou ne fournit pas suffisamment d'informations pour répondre efficacement aux besoinsde cette procédure, ce fait doit être documenté par le propriétaire du processus et soumis à ladirection. Le tableau ci-dessous présente les tâches d'initialisation requises.

Tâcherequise

Description

Objectifsde latâche

Créer un document de conception détaillé pourl'architecture NTP qui répond aux exigences deconception et aux objectifs de coût

Entrées detâche

Concevoir les besoins techniques etéconomiques

Documentation de conception de réseauexistante

Critères définissant les aspects requis àenregistrer dans la conception pour activerles fonctions de gestion

Informations sur le déploiement desapplications informatiques

Exigences en matière de surveillance desperformances

Sortiede latâche

Documentation de conception NTP

Ressources delatâche

Architecte de l'ingénieur réseau Architecte desopérations réseau

Rôlesdestâches

Approbation technique de la conception du réseaupar les examinateurs de l’ingénierie et desopérations Coûts de conception du réseauapprouvés par le responsable du budget

Créer un fichier de démarrage

Le processus de gestion NTP nécessite l’utilisation d’un fichier d’amorçage pour supprimer lanécessité d’une fonction de découverte de réseau. Le fichier d'amorçage enregistre l'ensemble derouteurs régis par le processus NTP et sert également de point focal pour coordonner les

Page 19: Protocole d'Heure Réseau : Livre blanc sur les pratiques

processus de gestion des changements dans une organisation. Par exemple, si de nouveauxnoeuds sont entrés dans le réseau, ils doivent être ajoutés au fichier de démarrage NTP. Si desmodifications sont apportées aux noms de communauté SNMP en raison de besoins de sécurité,ces modifications doivent être répercutées dans le fichier de démarrage. Le tableau ci-dessousdécrit les processus de création d'un fichier d'amorçage.

Tâcherequise Description

Objectifsde latâche

Créer un fichier de démarrage qui identifie troiscatégories de périphériques réseau

Périphériques critiques : interrogésfréquemment pour obtenir desinformations de configuration

1.

Périphériques intéressants : interrogésmoins fréquemment

2.

Tous les périphériques NTP activés : lenombre le plus faible est interrogé.

3.

Entréesde tâche

Documentation de conception NTPDocumentation de la topologie du réseau

Sortie dela tâche Fichier de démarrage

Ressources de latâche

Critères de conception qui seront utilisés pouridentifier et hiérarchiser les noeuds impliquésdans l'architecture NTP

Paramètres de performances NTP de référence

Plusieurs des paramètres disponibles pour la surveillance du réseau NTP présentent desvariations normales attendues. Le processus de sélection de base est utilisé pour caractériser lesvariations normales attendues et pour fixer des seuils qui définissent des conditions inattenduesou anormales. Cette tâche est utilisée pour planifier l'ensemble de paramètres variables pourl'architecture NTP. Pour une analyse plus détaillée des techniques de référence, voir le processusde référence : Livre blanc sur les meilleures pratiques.

Process Description

Objectifsde latâche

Paramètres de la variable de référence

Entrées detâche

Identifier les paramètres de variablecntpSysRootDelay cntpSysRootDispersioncntpPeersRootDelay cntpPeersRootDispersioncntpPeersOffset cntpPeersDelaycntpPeersDispersion

Sorties delatâche

Valeurs et seuils de référence

Page 20: Protocole d'Heure Réseau : Livre blanc sur les pratiques

Ressources delatâche

Outils de collecte des données SNMP et de calculdes lignes de base

Rôledetâche

Ingénieur réseau Ingénieur NMS

Tâches itératives

Des tâches itératives sont exécutées à chaque itération du processus et leur fréquence estdéterminée et modifiée afin d'améliorer les indicateurs de performance.

Tenir à jour le fichier de démarrage

Le fichier d'amorçage est essentiel à la mise en oeuvre efficace du processus de gestion du NTP.Par conséquent, l'état actuel du fichier de démarrage doit être géré activement. Les modificationsapportées au réseau qui affectent le contenu du fichier de démarrage doivent être suivies par lepropriétaire du processus de gestion NTP.

Process DescriptionObjectifs de latâche

Maintenir la précision du fichier dedémarrage

Entrées detâche

Informations sur les modificationsapportées au réseau

Sorties de latâche Fichier de démarrage

Ressources dela tâche

Rapports, notifications, réunionsconcernant les changements

Rôle de tâche Ingénieur réseau Ingénieur NMS

Exécuter l'analyse du noeud NTP

Recueillez des informations sur les analyses critiques, intéressantes et de configuration définiespar cette procédure. Exécutez ces trois analyses à différentes fréquences.

Les noeuds critiques sont des périphériques considérés comme très importants pour les points dedonnées de collecte de performances. L'analyse de noeud critique est exécutée souvent, parexemple, toutes les heures ou à la demande avant et après les modifications. Les noeudsintéressants sont des périphériques jugés importants pour l'intégrité globale de l'architecture NTP,mais qui ne figurent peut-être pas dans l'arborescence de synchronisation temporelle pour lacollecte de données de performances critiques. Ce rapport est exécuté périodiquement, parexemple, tous les jours ou tous les mois. Le rapport de configuration est un rapport complet etriche en ressources qui est utilisé pour caractériser la configuration globale du déploiement NTPpar rapport aux enregistrements de conception. Ce rapport est exécuté moins fréquemment, parexemple, mensuellement ou trimestriellement. Il est important de tenir compte du fait que lafréquence de collecte des rapports peut être ajustée en fonction de la stabilité observée del'architecture NTP et des besoins commerciaux.

Page 21: Protocole d'Heure Réseau : Livre blanc sur les pratiques

Process DescriptionObjectif de latâche Contrôler l'architecture NTP

Entrée de latâche Données des périphériques réseau

Sortie de latâche Rapports

Ressourcesde la tâche

Applications logicielles pour collecter desdonnées et produire des rapports

Rôle detâche Ingénieur réseau

Examiner les rapports de noeud NTP

Cette tâche nécessite que les rapports critiques, intéressants et de configuration soient examinéset analysés. Si des problèmes sont détectés, des mesures correctives doivent être prises.

Process DescriptionEntrées detâche Rapports d'analyse

Sorties dela tâche Analyse de la stabilité Mesures correctives

Ressources de latâche

Accès aux périphériques réseau pour uneanalyse et une vérification plus approfondies

Rôle detâche Ingénieur réseau

Identification des données

Caractéristiques générales des données

Le tableau suivant décrit les données qui sont considérées comme intéressantes pour l'analyse del'architecture NTP.

Données Description

ID de noeud Périphérique dont le protocole NTP estconfiguré

Homologues Les homologues configurés pour lepériphérique

Source desynchronisation

L'homologue sélectionné pour lasynchronisation

Données deconfigurationNTP

Paramètres utilisés pour juger de lacohérence de la conception NTP

Données dequalité NTP

Paramètres utilisés pour caractériserla qualité des associations NTP

Page 22: Protocole d'Heure Réseau : Livre blanc sur les pratiques

Identification des données SNMP

Groupe système MIB NTP Cisco

Les données SNMP NTP sont définies par Cisco-NTP-MIB. Pour obtenir des informations à joursur les versions qui prennent en charge cette base MIB, utilisez l'outil Navigateur de fonctionsCCO et sélectionnez l'option Localisateur MIB. Cet outil est accessible via la page Outils du TACpour les technologies de la voix, de la téléphonie et de la messagerie.

Le groupe système de la base MIB NTP de Cisco fournit des informations pour le noeud cibleexécutant NTP. Le noeud cible est la destination des requêtes SNMP.

Nom d'objet Description d'objet

cntpSysStratum

La strate de l'horloge locale. Si la valeurest définie sur 1, une référence primaire, laprocédure d'horloge primaire décrite à lasection 3.4.6, dans RFC-1305 est appelée.::= { cntpSystem 2 } identificateur d'objet =.1.3.6.1.4.1.9.9.168.1.1.2

cntpSysPrecision

Entier signé indiquant la précision del'horloge système, en secondes, à lapuissance la plus proche de deux. Lavaleur doit être arrondie à la puissancesupérieure suivante de deux. Par exemple,une horloge de fréquence d'alimentation de50 Hz (20 ms) ou 60 Hz (16,67 ms) estaffectée à la valeur -5 (31,25 ms), tandisqu'une horloge à commande cristalline de1 000 Hz (1 ms) est affectée à la valeur -9(1,95 ms). ::= { cntpSystem 3 }identificateur d'objet =.1.3.6.1.4.1.9.9.168.1.1.3

cntpSysRootDelay

Numéro de point fixe signé indiquant ledélai total aller-retour en secondes, à lasource de référence principale à la racinedu sous-réseau de synchronisation. ::= {cntpSystem 4 } identificateur d'objet =.1.3.6.1.4.1.9.9.168.1.1.4

cntpSysDispersionRacine

Erreur maximale en secondes, par rapportà la source de référence principale à laracine du sous-réseau de synchronisation.Seules les valeurs positives supérieures àzéro sont possibles. ::= { cntpSystem 5 }identificateur d'objet =.1.3.6.1.4.1.9.9.168.1.1.4

cntpSysRefTime

Heure locale de la dernière mise à jour del'horloge locale. Si l'horloge locale n'ajamais été synchronisée, la valeur est zéro.::= { cntpSystem 7 } identificateur d'objet =.1.3.6.1.4.1.9.9.168.1.1.7

cntpSysPeer Source de synchronisation actuelle

Page 23: Protocole d'Heure Réseau : Livre blanc sur les pratiques

contenant l'identificateur d'associationunique cntpPeersAssocId de l'entréehomologue correspondante danscntpPeersVarTable de l'homologueagissant comme source desynchronisation. S'il n'y a pasd'homologue, la valeur est zéro. ::= {cntpSystem 9 } identificateur d'objet =.1.3.6.1.4.1.9.9.168.1.1.9

cntpSysClock

Heure locale actuelle. L'heure locale estdérivée de l'horloge matérielle de lamachine particulière et s'incrémente àintervalles selon la conception utilisée. ::= {cntpSystem 10 } identificateur d'objet =.1.3.6.1.4.1.9.9.168.1.1.10

Groupe d'homologues MIB NTP Cisco - Table des variables d'homologues

Le groupe homologue de la MIB NTP de Cisco fournit des informations sur les homologues dunoeud cible.

Nom d'objet Description d'objet

cntpPeersVarTable

Ce tableau fournit des informations surles homologues avec lesquels le serveurNTP local a des associations. Leshomologues sont également des serveursNTP exécutés sur différents hôtes. Il s'agitd'une table de cntpPeersVarEntry ::= {cntpPeers 1 } identificateur d'objet =.1.3.6.1.4.1.9.9.168.1.2.1

cntpHomologuesEntréeVar

L'entrée de chaque homologue fournit desinformations NTP récupérées à partir d'unserveur NTP homologue particulier.Chaque homologue est identifié par unidentificateur d'association unique. Lesentrées sont automatiquement crééeslorsque l'utilisateur configure le serveurNTP pour être associé à des homologuesdistants. De même, les entrées sontsupprimées lorsque l'utilisateur supprimel'association homologue du serveur NTP.Les entrées peuvent également êtrecréées par la station de gestion endéfinissant des valeurs pourcntpPeersPeerAddress,cntpPeersHostAddress, cntpPeersModeet en rendant cntpPeersEntryStatus actif(1). Au minimum, la station de gestion doitdéfinir une valeur pourcntpPeersPeerAddress pour rendre laligne active. INDEX { cntpPeersAssocId }

Page 24: Protocole d'Heure Réseau : Livre blanc sur les pratiques

::= { cntpPeersVarTable 1 } identificateurd'objet = .1.3.6.1.4.1.9.9.168.1.2.1.1

cntpPeersAssocId

Valeur entière supérieure à zéro quiidentifie de manière unique un homologueauquel le serveur NTP local est associé.::= { cntpPeersVarEntry 1 } identificateurd'objet = .1.3.6.1.4.1.9.9.168.1.2.1.1.1

cntpPeersConfiguré

Ce bit indique que l’association a étécréée à partir des informations deconfiguration et ne doit pas être dissociéemême si l’homologue devientinaccessible. ::= { cntpPeersVarEntry 2 }identificateur d'objet =.1.3.6.1.4.1.9.9.168.1.2.1.1.2

cntpPeersPeerAddress

Adresse IP de l'homologue. Lors de lacréation d'une association, une valeurpour cet objet doit être définie avant quela ligne ne soit activée. ::= {cntpPeersVarEntry 3 } identificateurd'objet = .1.3.6.1.4.1.9.9.168.1.2.1.1.3

cntpPeersMode

SYNTAX INTEGER { non spécifié (0),symetricActive (1), symmetricPassive (2),client (3), serveur (4), broadcast (5),resermetricControl (6),ResermetricPrivate (7) } Lors de lacréation d'une nouvelle associationhomologue, si aucune valeur n'estspécifiée pour cet objet, elle prend pardéfaut la valeur symmetricActive (1). ::= {cntpPeersVarEntry 8 } identificateurd'objet = .1.3.6.1.4.1.9.9.168.1.2.1.1.8

cntpPeersStratum

La strate de l'horloge homologue. ::= {cntpPeersVarEntry 9 } identificateurd'objet = .1.3.6.1.4.1.9.9.168.1.2.1.1.9

cntpPeersRootDelay

Numéro de point fixe signé indiquant ledélai total aller-retour en secondes, del'homologue à la source de référenceprincipale à la racine du sous-réseau desynchronisation. ::= { cntpPeersVarEntry13 } identificateur d'objet =.1.3.6.1.4.1.9.9.168.1.2.1.1.13

cntpPeersDispersionRacine

Erreur maximale, en secondes, del'horloge homologue par rapport à lasource de référence principale à la racinedu sous-réseau de synchronisation.Seules les valeurs positives supérieures àzéro sont possibles. ::= {cntpPeersVarEntry 14 } identificateurd'objet = .1.3.6.1.4.1.9.9.168.1.2.1.1.14

cntpPeersRefTime

Heure locale de l'homologue lors de ladernière mise à jour de son horloge. Si

Page 25: Protocole d'Heure Réseau : Livre blanc sur les pratiques

l'horloge homologue n'a jamais étésynchronisée, la valeur est zéro. ::= {cntpPeersVarEntry 16 } identificateurd'objet = .1.3.6.1.4.1.9.9.168.1.2.1.1.16

cntpPeersReach

Registre de décalage utilisé pourdéterminer l'état d'accessibilité del'homologue, avec des bits entrant à partirde l'extrémité la moins importante (la plusà droite). Un homologue est considérécomme accessible si au moins un bit dece registre est défini sur un (l'objet estdifférent de zéro). Les données duregistre de quart de travail sontrenseignées par les procédures duprotocole NTP. ::= { cntpPeersVarEntry21 } identificateur d'objet =.1.3.6.1.4.1.9.9.168.1.2.1.1.21

cntpPeersOffset

Décalage estimé de l'horloge homologuepar rapport à l'horloge locale, ensecondes. L'hôte détermine la valeur decet objet à l'aide de l'algorithme de filtred'horloge NTP. ::= { cntpPeersVarEntry 23} identificateur d'objet =.1.3.6.1.4.1.9.9.168.1.2.1.1.21

cntpPeersDelay

Délai estimé de l'horloge homologue parrapport à l'horloge locale sur le chemin duréseau entre elles, en secondes. L'hôtedétermine la valeur de cet objet à l'aidede l'algorithme de filtre d'horloge NTP. ::={ cntpPeersVarEntry 24 } identificateurd'objet = .1.3.6.1.4.1.9.9.168.1.2.1.1.24

cntpPeersDispersion

Erreur maximale estimée de l'horlogehomologue par rapport à l'horloge localesur le chemin réseau entre elles, ensecondes. L'hôte détermine la valeur decet objet à l'aide de l'algorithme de filtred'horloge NTP. ::= { cntpPeersVarEntry 25} identificateur d'objet =.1.3.6.1.4.1.9.9.168.1.2.1.1.25

Collecte de données

Collecte de données SNMP

Toutes les informations requises par cette procédure peuvent être collectées via des requêtesSNMP. Afin d'analyser les données et de produire les rapports, des scripts personnalisés ou deslogiciels devront être développés.

Présentation des données

Page 26: Protocole d'Heure Réseau : Livre blanc sur les pratiques

Rapport NTP Critical Node

Les noeuds critiques sont des périphériques importants dans l'arborescence de synchronisationdes points de collecte de données de performances sélectionnés. Si un service VoIP à revenuélevé est surveillé et que des mesures de variation de délai unidirectionnel sont collectées, lesnoeuds source et de destination où les horodatages sont enregistrés sont considérés comme desnoeuds critiques.

Dans cet exemple, la conception NTP a été établie à la suite d'un exemple de hiérarchie OSPF.Par conséquent, les rapports décrits ci-dessous sont formatés pour regrouper les périphériquesNTP en fonction de la zone OSPF du périphérique. Dans les cas où un noeud a des interfacesdans plusieurs zones, le logiciel de génération de rapports doit décider de la zone dans laquelle lenoeud sera répertorié à des fins de rapport. Comme mentionné précédemment, le protocoleOSPF n'est pas une condition préalable au protocole NTP. Il n'est utilisé que dans le présentdocument à titre d'exemple.

Zone Périphérique Données du périphérique Valeur

ID dezonen°

ID depériphériquen° 1

cntpSysStratum  cntpSysPrecision  cntpSysRootDelay  cntpSysDispersionRacine  cntpSysRefTime  cntpSysPeer  cntpSysClock  

ID depériphériquen°

cntpSysStratum  cntpSysPrecision  cntpSysRootDelay  cntpSysDispersionRacine  cntpSysRefTime  cntpSysPeer  cntpSysClock  

Rapport de noeud NTP intéressant

Le format du rapport de noeud intéressant est le même que celui du rapport de noeud critique.Les noeuds intéressants sont considérés comme importants pour l’architecture NTP globale, maisils ne contribuent pas directement à la synchronisation temporelle des points critiques desurveillance des performances.

Rapport de configuration NTP

Le rapport de configuration est un rapport complet qui collecte des informations sur l'architectureNTP globale. Ce rapport est utilisé pour enregistrer et vérifier le déploiement NTP par rapport auxenregistrements de conception.

Zone

Périphérique

Homologue Données homologues Vale

ur

Page 27: Protocole d'Heure Réseau : Livre blanc sur les pratiques

IDdezone n°

ID depériphérique n°

PeerId#1

cntpPeersAssocId  cntpPeersConfiguré  cntpPeersPeerAddress  

cntpPeersMode  cntpPeersStratum  cntpPeersRootDelay  cntpPeersDispersionRacine  

cntpPeersRefTime  cntpPeersReach  cntpPeersOffset  cntpPeersDelay  cntpPeersDispersion  

PeerId#n

cntpPeersAssocId  cntpPeersConfiguré  cntpPeersPeerAddress  

cntpPeersMode  cntpPeersStratum  cntpPeersRootDelay  cntpPeersDispersionRacine  

cntpPeersRefTime  cntpPeersReach  cntpPeersOffset  cntpPeersDelay  cntpPeersDispersion  

Informations connexes

RFC 1305 Network Time Protocol●

Cadre RFC 2330 pour les indicateurs de performances IP●

Fonctionnalités IOS essentielles que chaque FAI doit prendre en compte v2.84●

Support technique - Cisco Systems●