Disponibilité : Haute disponibilité

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

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

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

Informations générales

La synchronisation horaire de réseau, au degré exigé pour l'évaluation de performances moderne, est un exercice essentiel. Selon les modèles professionnels, et les services étant fournis, la caractérisation des performances du réseau peut être considérée un important différentiateur de service concurrentiel. Dans des ces cas, de grandes dépenses peuvent être supportées déployant des systèmes d'administration de réseaux et dirigeant des ressources en ingénierie vers analyser les données de performance collectées. Cependant, si une attention appropriée n'est pas donnée au principe souvent-donné sur de la synchronisation horaire, ces efforts peuvent être rendus inutiles.

Ce document décrit une définition de processus hypothétique pour des fonctions de Gestion de réseau de conduite pour le Protocole NTP (Network Time Protocol). On le destine que cette procédure hypothétique soit utilisée comme exemple informationnel et personnalisée par une organisation pour aider à répondre à des objectifs internes.

Les informations fournies par ce document sont présentées dans plusieurs sections importantes, qui sont décrites ci-dessous.

La section terminologique fournit des définitions générales des termes au sujet de la synchronisation horaire.

La vue d'ensemble fournit l'information générale sur le matériel d'élément de réseau lié à l'heure système, à un aperçu technologique de NTP, et aux aspects principaux de conception pour l'architecture de NTP.

La section de déploiement de NTP d'exemple fournit à des exemples de déploiement de NTP des configurations d'échantillon pour le WAN, le campus élevé de strate, et les bas réseaux de la distribution horaire de campus de strate.

La section de définitions de processus fournit un aperçu des définitions de processus utilisées pour accomplir la Gestion de NTP. Les détails du processus sont décrits en termes de buts, indicateurs de performances, entrées, sorties, et tâches de personne.

La section de définitions de tâche fournit des définitions de tâche de processus détaillées. Chaque tâche est décrite en termes d'objectifs, des entrées de tâche, des sorties de tâche, des ressources exigées pour accomplir la tâche, et des qualifications de travail requises pour un responsable de l'implémentation de tâche.

La section Identification des données décrit l'identification de données pour le NTP. L'identification de données considère la source d'informations. Par exemple, les informations peuvent être contenues dans le Management Information Base de Protocole SNMP (Simple Network Management Protocol) (MIB), dans des fichiers journal générés par Syslog, ou par les structures de données internes qui peuvent seulement être accédées à par l'interface de ligne de commande (CLI).

La section de collecte des informations décrit la collecte des données de NTP. La collecte des données est étroitement liée à l'emplacement des données. Par exemple, des données MIB SNMP sont collectées par plusieurs mécanismes tels que des déroutements, des alarmes et des événements de Surveillance à distance (RMON), ou interrogation. Des données mises à jour par des structures de données internes sont collectées par les scripts automatiques ou par un utilisateur se connectant manuellement dans le système pour émettre la commande CLI et enregistrant la sortie.

La section Présentation des données fournit des exemples de format d'état de la façon dont les données peuvent être présentées.

Terminologie

  • Précision — La proximité de la valeur absolue de l'horloge au décalage de zéro.

  • Précis — Quand le décalage d'une horloge est zéro à un instant particulier.

  • Dérive — La mesure dans la variation de la distorsion, ou la deuxième dérivation du décalage de l'horloge en ce qui concerne le temps.

  • Résolution commune — En comparant des horloges, c'est la somme des résolutions de C1 et de C2. La résolution commune indique alors une limite inférieure conservatrice sur la précision de quand les intervalles ont calculé en soustrayant des groupes date/heure générés par une horloge de ceux générés par l'autre.

  • Noeud — Se rapporte à une instanciation du protocole de NTP relatif à un processeur local. Un noeud peut également désigné sous le nom d'un périphérique.

  • Décalage — La différence entre le moment a signalé par une horloge et l'en temps réel comme défini par le temps universel coordonné (UTC). Si l'horloge signale un comité technique de temps et l'en temps réel est TTT, alors le décalage de l'horloge est comité technique - TTT.

  • Pair — Se rapporte à une instanciation du protocole de NTP relatif à un processeur distant relié par un chemin réseau du noeud local.

  • Décalage relatif — La notion d'en temps réel est remplacée avant que comme signalé par l'horloge C1, quand comparant comment deux horloges, C1 et C2, comparent. Par exemple, le décalage de l'horloge C2 à C1 relatif à un moment particulier est Tc2 - Tc1, la différence instantanée à temps signalé par C2 et C1.

  • Résolution — La plus petite unité par laquelle un temps d'horloge est mis à jour. La résolution est définie en termes de secondes. Cependant, la résolution est relativement à l'horloge signalée temps et pas à en temps réel. Par exemple, une résolution de 10 millisecondes signifie que l'horloge met à jour sa notion de temps dans le 0.01 seconde incrément et ne signifie pas que c'est la durée vraie entre les mises à jour.

    Remarque: Les horloges peuvent avoir des résolutions très correctes et encore être inexactes.

  • Distorsion — Une différence de la fréquence de base, ou première dérivée de son décalage en ce qui concerne le temps.

  • Synchronisez — Quand deux horloges sont précises en ce qui concerne une une autre (le décalage relatif est zéro), elles sont synchronisées. Des horloges peuvent être synchronisées et encore inexact en termes d'à quel point elles indiquent en temps réel.

Aperçu

Aperçu de périphérique

Le coeur du service horaire est l'horloge système. L'horloge système exécute du moment les débuts de système et maintient la date et heure actuelles. L'horloge système peut être réglée d'un certain nombre de sources et, consécutivement, peut être utilisée pour distribuer le temps en cours par de divers mécanismes à d'autres systèmes. Quelques Routeurs contiennent un système à piles de calendrier qui dépiste la date et l'heure à travers des redémarrages du système et des pannes de courant. Ce système de calendrier est toujours utilisé pour initialiser l'horloge système quand le système est redémarré. Il peut également être considéré comme source bien fondée de temps et être redistribué par le NTP si aucune autre source n'est disponible. En outre, si le NTP s'exécute, le calendrier peut être périodiquement mis à jour du NTP, compensant la dérive inhérente dans le temps de calendrier. Quand un routeur avec un calendrier de système est initialisé, l'horloge système est réglée basée sur le temps dans son calendrier à piles interne. Sur des modèles sans calendrier, l'horloge système est réglée à une constante de temps prédéterminée. L'horloge système peut être réglée des sources répertoriées ci-dessous.

  • NTP

  • Protocole de diffusion du temps en réseau (SNTP) (SNTP)

  • Service horaire virtuel de service de réseau intégré (VIGNES)

  • Configuration manuelle

Certain support bas de gamme SNTP de périphériques de Cisco seulement. SNTP est une version simplifiée et réservée au client de NTP. SNTP peut seulement recevoir le temps des serveurs de NTP et ne peut pas être utilisé pour fournir des Services horaires à d'autres systèmes. SNTP fournit typiquement le temps dans un délai de 100 millisecondes du temps précis. En outre, SNTP n'authentifie pas le trafic, bien que vous puissiez configurer les Listes d'accès étendues pour assurer une certaine protection. Un client SNTP est plus vulnérable aux serveurs de mauvaise conduite qu'un client de NTP et devrait seulement être utilisé dans les situations où l'authentification poussée n'est pas exigée.

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

  • NTP

  • Service horaire de VIGNES

  • Commandes show d'utilisateur

  • Se connectant et messages de débogage

L'horloge système maintient le temps intérieurement basé sur l'UTC, également connu sous le nom d'heure de Greenwich (GMT). Vous pouvez configurer des informations sur le fuseau horaire et l'heure d'été heure locale de sorte que le temps soit affiché correctement relativement au fuseau horaire heure locale. L'horloge système maintient, que le temps soit bien fondé ou pas. S'il n'est pas bien fondé, le temps sera disponible seulement pour l'affichage et ne sera pas redistribué.

Aperçu de NTP

Le NTP est conçu pour synchroniser le temps sur un réseau des ordinateurs. Le NTP exécute plus de le Protocole UDP (User Datagram Protocol), utilisant le port 123 en tant que la source et destination, qui exécute consécutivement plus de l'IP. RFC 1305 de version 3 de NTPleavingcisco.com est utilisé pour synchroniser le timekeeping parmi un ensemble de Serveurs de synchronisation et de clients distribués. Un ensemble de Noeuds sur un réseau sont identifiés et configuré avec le NTP et les Noeuds formez un sous-réseau de synchronisation, parfois désigné sous le nom d'un réseau de substitution. Tandis que les plusieurs maîtres (serveurs primaires) peuvent exister, il n'y a aucune condition requise pour un protocole d'élection.

Un réseau de NTP obtient habituellement son temps d'une source temporelle bien fondée, telle qu'une horloge radio ou une horloge atomique reliée à un Serveur de synchronisation. Le NTP distribue alors cette fois à travers le réseau. Un client de NTP effectue une transaction avec son serveur pendant son intervalle de sondage (de 64 à 1024 secondes) qui change dynamiquement au fil du temps selon les conditions de réseau entre le serveur de NTP et le client. L'autre situation se produit quand le routeur communique à un mauvais serveur de NTP (par exemple, serveur de NTP avec la grande dispersion) ; le routeur augmente également l'intervalle entre deux invitations à émettre. Pas plus d'une transaction de NTP par minute est nécessaire pour synchroniser deux ordinateurs. Il n'est pas possible d'ajuster l'intervalle entre deux invitations à émettre de NTP sur un routeur.

Le NTP emploie le concept d'une strate pour décrire combien de sauts de NTP loin un ordinateur est d'une source temporelle bien fondée. Par exemple, un Serveur de synchronisation de la strate 1 a une radio ou une horloge atomique directement reliée à elle. Il envoie alors son temps à un Serveur de synchronisation de strate 2 par le NTP, et ainsi de suite. Un NTP courant d'ordinateur choisit automatiquement l'ordinateur avec le plus bas nombre de strate qu'il est configuré pour communiquer avec utiliser le NTP en tant que sa source temporelle. Cette stratégie construit une organisation autonome efficace de haut-parleurs NTP. Le NTP exécute bien plus des longueurs de chemin non déterministes de réseaux de commutation de paquets, parce qu'il fait les évaluations robustes des trois variables principales suivantes dans les relations entre un client et un Serveur de synchronisation.

  • Délai réseau

  • Dispersion des échanges de paquet de temps — Une mesure d'erreur d'horloge maximum entre les deux hôtes.

  • Horloge compensée — La correction a appliqué à l'horloge d'un client pour la synchroniser.

Synchronisez la synchronisation au niveau de 10 millisecondes au-dessus des réseaux de fond d'étendu (WAN) (2000 kilomètres), et au niveau de 1 milliseconde pour des réseaux locaux (réseaux locaux), est par habitude réalisé.

Le NTP évite de synchroniser à un ordinateur dont le temps peut ne pas être précis de deux manières. Tout d'abord, le NTP ne synchronise jamais à un ordinateur qui n'est pas synchronisé. Deuxièmement, le NTP compare le temps signalé par plusieurs ordinateurs, et ne synchronisera pas à un ordinateur dont le temps est sensiblement différent que les autres, même si sa strate est inférieure.

Les transmissions entre les ordinateurs exécutant le NTP (associations) habituellement sont statiquement configurées. Chaque ordinateur est donné l'adresse IP de tous les ordinateurs avec lesquels elle devrait former des associations. La ponctualité précise est rendue possible en permutant des messages de NTP entre chaque paire d'ordinateurs avec une association. Cependant, dans un environnement de RÉSEAU LOCAL, le NTP peut être configuré pour utiliser des messages de diffusion IP à la place. Cette alternative réduit la complexité de configuration parce que chaque ordinateur peut être configuré pour envoyer ou recevoir des messages de diffusion. Cependant, la précision de la mesure du temps est marginalement réduite parce que le flux d'information est à sens unique seulement.

Le temps gardé sur un ordinateur est une ressource essentielle et il est recommandent vivement que vous employiez les fonctionnalités de sécurité du NTP pour éviter la configuration accidentelle ou malveillante du temps incorrect. Les deux fonctionnalités de sécurité disponibles sont un schéma de restriction de liste en fonction d'accès et un mécanisme d'authentification chiffré.

L'implémentation de Cisco du NTP prend en charge le service de la strate 1 dans certaines versions logicielles de Cisco IOS. Si une release prend en charge la commande de ntp refclock, il est possible de connecter une horloge par radio ou atomique. Certaines versions de Cisco IOS prennent en charge le kit de synchronisation de NTP de Palisade de Trimble (Routeurs de la gamme Cisco 7200 seulement) ou le périphérique du système de localisation mondial de solutions de télécommunication (GPS). Si le réseau utilise les Serveurs de synchronisation publics sur l'Internet et le réseau est isolé dans l'Internet, l'implémentation de Cisco du NTP permet un ordinateur à configurer de sorte qu'elle agisse comme s'elle est synchronisée par le NTP, quand en fait elle a déterminé le temps utilisant des autres moyens. D'autres ordinateurs synchronisent alors à cet ordinateur par le NTP.

Critères de conception de NTP

Chaque client dans le sous-réseau de synchronisation, qui peut également être un serveur pour des clients plus élevés de strate, choisit un des serveurs disponibles pour synchroniser à. C'est habituellement de parmi les plus bas serveurs de strate qu'il a accès à. Cependant, ce n'est pas toujours une configuration optimale, parce que le NTP fonctionne également sous le site que le temps de chaque serveur devrait être visualisé avec une méfiance. Le NTP préfère avoir accès à plusieurs sources de temps de strate inférieure (au moins trois) puisqu'il peut alors appliquer un algorithme d'accord pour détecter la folie de la part de n'importe quel un de ces derniers. Normalement, quand tous les serveurs sont d'accord, le NTP choisit le meilleur serveur en termes de plus basse strate, la plus étroite (en termes de délai réseau), et précision réclamée. L'implication est que, alors qu'on devrait viser à fournir à chaque client trois sources ou plus de temps de strate inférieure, plusieurs de ces derniers fourniront seulement le service de sauvegarde et peuvent être de peu de qualité en termes de délai réseau et strate. Par exemple, un pair de même-strate qui reçoit le temps des sources de strate inférieure le serveur local n'accède à pas directement, peut également fournir le bon service de sauvegarde.

Le NTP préfère généralement des serveurs de strate inférieure à des serveurs plus élevés de strate à moins que le temps du serveur de strate inférieure soit sensiblement différent. L'algorithme peut détecter quand une source temporelle est susceptible d'être extrêmement inexacte, ou aliéné, et empêcher la synchronisation dans des ces cas, même si l'horloge inexacte est à un niveau de strate inférieure. Et il ne synchronisera jamais un périphérique à un autre serveur qui n'est pas synchronisé.

Afin de déclarer si le serveur est digne de confiance, il doit passer à beaucoup le contrôle de validité, comme :

  • Les réalisations devraient inclure les délais d'attente de validité qui empêchent des transmissions de déroutement si le programme de contrôle ne renouvelle pas ces informations après un intervalle prolongé.

  • Des contrôles supplémentaires de validité sont inclus pour l'authentification, des limites de plage, et pour éviter l'utilisation très des données précédentes.

  • Des contrôles ont été ajoutés pour avertir que l'oscillateur a disparu trop long sans mise à jour d'une source de référence.

  • Les variables peer.valid et sys.hold ont été ajoutées pour éviter des instabilités quand la source de référence change rapidement en raison de grands retards dispersifs dans des conditions d'encombrement de réseau grave. Les bits peer.config, peer.authenable, et peer.authentic ont été ajoutés pour contrôler usages spéciaux et pour simplifier la configuration.

Si au moins un de ceux vérifie l'échouer, le routeur le déclare aliéné.

Modes d'association

Les sections suivantes décrivent les modes associants utilisés par des serveurs de NTP pour s'associer les uns avec les autres.

  • Client/serveur

  • Actif symétrique/passif

  • Émission

Mode client/serveur

Les clients et serveurs dépendants fonctionnent normalement dans le mode client/serveur, dans lequel un client ou un serveur dépendant peut être synchronisé à un membre du groupe, mais aucun membre du groupe ne peut synchroniser au client ou au serveur dépendant. Ceci assure la protection contre des défaillances ou des attaques de protocole.

Le mode client/serveur est la configuration d'Internet la plus commune. Il fonctionne dans le paradigme classique du Remote Procedure Call (RPC) avec les serveurs sans état. En ce mode, un client envoie une demande au serveur et s'attend à une réponse à une certaine future heure. Dans quelques contextes, ceci serait décrit comme exécution de balayage, parce que le client vote le temps et les données d'authentification du serveur. Un client est configuré en mode de client à l'aide de la commande et de spécifier de serveur le nom ou l'adresse de serveur de noms de domaines (DN). Le serveur n'a besoin d'aucune configuration antérieure.

Dans un modèle commun de client/serveur, un client envoie un message de NTP à un ou plusieurs serveurs et traite les réponses comme reçu. Le serveur échange des adresses et des ports, remplace certains champs dans le message, recalcule la somme de contrôle, et renvoie le message immédiatement. Les informations incluses dans le message de NTP permettent au client pour déterminer le temps de serveur en ce qui concerne l'heure locale et pour ajuster l'horloge locale en conséquence. En outre, le message inclut les informations pour calculer la précision et la fiabilité prévues de ponctualité, aussi bien que pour sélectionner le meilleur serveur.

Serveurs qui fournissent la synchronisation à une importante population des clients opèrent normalement en tant que groupe de trois serveurs mutuellement redondants ou plus, chaque opération avec trois strates ou plus 1 ou serveurs de strate 2 dans les mode client/serveur, aussi bien que tous autres membres du groupe dans des modes symétriques. Ceci assure la protection contre des défaillances dans lesquels ou plus de serveurs n'actionnent pas ou ne fournissent pas le temps incorrect. Les algorithmes de NTP sont machinés pour résister à des attaques quand une certaine fraction des sources configurées de synchronisation fournissent accidentellement ou exprès le temps incorrect. Dans des ces cas, une procédure de vote spéciale est utilisée pour identifier de fausses sources et pour jeter leurs données. Dans l'intérêt de la fiabilité, des hôtes sélectionnés peuvent être équipés des horloges externes et être utilisés pour la sauvegarde en cas de panne des serveurs primaires et/ou secondaires, ou des artères de communications entre elles.

Configurer une association en mode de client, habituellement indiqué par une déclaration de serveur dans le fichier de configuration, indique qu'on souhaite obtenir le temps du serveur distant, mais qu'on n'est pas disposé à fournir le temps au serveur distant.

Mode actif/passif symétrique

Mode actif/passif symétrique est destiné pour des configurations où un groupe de bas pairs de strate fonctionnent en tant que sauvegardes mutuelles l'un pour l'autre. Chaque pair fonctionne avec un ou plusieurs sources de référence principale, telles qu'une horloge radio, ou un sous-ensemble de serveurs secondaires dignes de confiance. Si un des pairs perd toutes les sources de référence ou cesse simplement l'exécution, les autres pairs modifient automatiquement de sorte que les valeurs temporelles puissent découler des pairs survivants à tous les autres dans la clique. Dans quelques contextes ceci est décrit comme exécution va-et-vient, parce que les tractions de pair ou pousse le temps et les valeurs selon la configuration particulière.

Configurer une association en mode symétrique-actif, habituellement indiqué par une déclaration de pair dans le fichier de configuration, indique au serveur distant qu'on souhaite obtenir le temps du serveur distant et qu'on est prêt également pour assurer le temps au serveur distant s'il y a lieu. Ce mode est approprié dans les configurations faisant participer un certain nombre de Serveurs de synchronisation redondants interconnectés par des chemins réseau divers, qui est actuellement la caisse pour la plupart de strate 1 et serveur sur Internet de strate 2 aujourd'hui.

Les modes symétriques sont les plus employés souvent entre deux serveurs ou plus fonctionnant en tant que groupe mutuellement redondant. En ces modes, les serveurs dans les membres du groupe arrangent les chemins de synchronisation pour des performances maximales, selon le jitter de réseau et le délai de propagation. Si un ou plusieurs des membres du groupe échouent, les membres restants modifient automatiquement au besoin.

Un pair est configuré en mode actif symétrique à l'aide de la commande et de spécifier de pair le nom DNS ou l'adresse de l'autre pair. L'autre pair est également configuré en mode actif symétrique de cette façon.

Remarque: Si l'autre pair n'est pas spécifiquement configuré de cette façon, une association passive symétrique est lancée sur l'arrivée d'un message actif symétrique. Puisqu'un intrus peut personnifier un pair actif symétrique et injecter des valeurs temporelles fausses, le mode symétrique devrait toujours être authentifié.

Mode d'émission et/ou de Multidiffusion

Là où les conditions requises dans la précision et la fiabilité sont modestes, des clients peuvent être configurés pour utiliser des modes d'émission et/ou de Multidiffusion. Normalement, ces modes ne sont pas utilisés par des serveurs avec les clients dépendants. L'avantage est que des clients n'ont pas besoin d'être configurés pour un serveur spécifique, permettant à tous les clients opérants pour utiliser le même fichier de configuration. Le mode d'émission exige un serveur d'émission sur le même sous-réseau. Puisque des messages de diffusion ne sont pas propagés par des Routeurs, seulement des serveurs d'émission sur le même sous-réseau sont utilisés.

Le mode d'émission est destiné pour des configurations faisant participer un ou quelque serveurs et une population potentiellement grande de client. Un serveur d'émission est configuré utilisant la commande d'émission et un subnet address local. Un client d'émission est configuré utilisant la commande broadcastclient, permettant au client d'émission pour répondre aux messages de diffusion reçus sur n'importe quelle interface. Puisqu'un intrus peut personnifier un serveur d'émission et injecter des valeurs temporelles fausses, ce mode devrait toujours être authentifié.

Établissement de la seconde de LEAP de NTP

Vous pouvez utiliser le LEAP de ntp {ajoutez | commande d'effacement} afin d'insérer une seconde de LEAP. Il y a des options pour ajouter et supprimer des secondes de LEAP. Il y a deux contraintes pour que ceci se produise :

  • L'horloge devrait être dans l'état de sync.

  • La commande est reçue seulement dans le mois avant que le LEAP soit de se produire. Il ne placera pas le LEAP si le temps en cours a lieu avant 1 mois de l'occurrence du LEAP.

Après que vous le placiez, la seconde de LEAP obtient ajouté ou supprimé au dernier deuxième comme affiché 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 de NTP

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

  • Structure plate de pair

  • Structure hiérarchique

  • Structure d'étoile

Dans une structure plate de pair, tous les Routeurs scrutent les uns avec les autres, avec quelques Routeurs géographiquement distincts configurés pour indiquer les systèmes externes. La convergence du temps devient plus longue avec chaque nouveau membre de la maille de NTP.

Dans une structure hiérarchique, la hiérarchie de routage est copiée pour la hiérarchie de NTP. Les principaux Routeurs ont des relations de client/serveur avec des sources temporelles externes, les Serveurs de synchronisation internes ont des relations de client/serveur avec les principaux Routeurs, le client interne (non Serveurs de synchronisation) que les Routeurs ont des relations de client/serveur avec les Serveurs de synchronisation internes, et ainsi de suite en bas de l'arborescence. Ces relations s'appellent les échelles de hiérarchie. Une structure hiérarchique est la technique préférée parce qu'elle fournit la cohérence, la stabilité, et l'évolutivité.

Une architecture extensible de NTP a une structure hiérarchique comme vu dans le diagramme ci-dessous.

/image/gif/paws/19643/ntpm-1.gif

Dans une structure d'étoile, tous les Routeurs ont des relations de client/serveur avec quelques Serveurs de synchronisation au centre. Les Serveurs de synchronisation dédiés sont le centre de l'étoile et sont habituellement les systèmes Unix Synchronisés avec des sources temporelles externes, ou leur propre récepteur GPS.

Technologie d'horloge et Serveurs de synchronisation de public

Le sous-réseau de NTP d'Internet inclut actuellement plus de 50 serveurs primaires publics synchronisés directement à l'UTC par la radio, le satellite, ou le modem. Normalement, les postes de travail client et les serveurs avec un nombre relativement réduit de clients ne sont pas synchronisés aux serveurs principaux. Approximativement 100 serveurs secondaires publics sont synchronisés aux serveurs primaires, fournissant la synchronisation à un total au-dessus de 100,000 clients et serveurs sur l'Internet. Les listes publiques de Serveurs de synchronisationleavingcisco.com de NTP sont mises à jour fréquemment. Il y a également les serveurs primaires et secondaires privés nombreux pas normalement disponibles au public.

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

Dans certains cas, où des Services horaires fortement précis sont priés sur l'entreprise privée, telle que des mesures à sens unique pour des mesures de la voix sur ip (VoIP), les créateurs de réseau peuvent choisir de déployer des sources temporelles externes privées. Le diagramme ci-dessous affiche un graphique comparatif de la précision relative des Technologies en cours.

/image/gif/paws/19643/ntpm-2.gif

Jusque récemment, l'utilisation des sources temporelles externes n'ont pas été largement déployées dans les réseaux d'entreprise dus au coût élevé de sources temporelles externes de qualité. Cependant, à mesure que les conditions requises de Qualité de service (QoS) augmentent et le coût de la technologie de temps continue à diminuer, les sources temporelles externes pour des réseaux d'entreprise deviennent une alternative viable.

Déploiements de NTP d'exemple

Réseau BLÊME de la distribution horaire

Dans le diagramme ci-dessous, un système autonome (AS) entreprise obtient les informations horaires de trois Serveurs de synchronisation publics. L'entreprise COMME est affiché comme Serveurs de synchronisation de la zone 0 et de la zone 1. Dans cet exemple, la hiérarchie de NTP suivent la hiérarchie de Protocole OSPF (Open Shortest Path First). Cependant, l'OSPF n'est pas un préalable au NTP. Il est seulement utilisé comme exemple illustratif. Le NTP peut être déployé le long d'autres bornes hiérarchiques logiques telles qu'une hiérarchie de Protocole EIGPR (Enhanced Interior Gateway Routing Protocol) ou la hiérarchie standard de noyau/distribution/Access.

/image/gif/paws/19643/ntpm-4.gif

Ce qui suit est la configuration Cisco IOS pour le périphérique A0-R1 dans le diagramme 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 élevé de la distribution horaire de campus de strate

La section précédente a décrit un réseau BLÊME de la distribution horaire. Cette section déplace un dévolteur dans la hiérarchie pour discuter la distribution horaire sur un réseau campus élevé de strate.

La différence principale en considérant la distribution horaire sur un réseau campus élevé de strate est l'utilisation potentielle du mode d'association d'émission. Comme décrit plus tôt, le mode d'association d'émission simplifie les configurations pour les réseaux locaux, mais réduit la précision des calculs de temps. Par conséquent, le compromis dans les coûts de maintenance doit être considéré contre la précision dans les mesures des performances.

ntpm-5.gif

Le réseau campus élevé de strate, affiché dans le diagramme ci-dessus, est pris de la conception de réseau campus standard de Cisco et contient trois composants. Le Campus Core se compose de deux périphériques de la couche 3 étiquetés CB-1 et CB-2. Le composant de serveur, situé dans la section inférieure de la figure, a deux Routeurs de la couche 3 étiquetés SD-1 et SD-2. Les autres périphériques dans le bloc de serveur sont des périphériques de la couche 2. Dans le gauche supérieur, il y a un bloc d'accès standard avec deux périphériques de distribution de la couche 3 étiquetés dl-1 et dl-2. Les autres périphériques sont des Commutateurs de la couche 2. Dans ce bloc d'accès client, le temps est distribué utilisant l'option d'émission. Dans la droite supérieure, il y a un autre bloc d'accès standard qui utilise une configuration de la distribution horaire de client/serveur.

Les périphériques de fédérateur de campus sont synchronisés aux Serveurs de synchronisation de zone dans un modèle de client/serveur.

La configuration pour dl-1 les périphériques de distribution de la couche 3 est affichée ci-dessous.


!--- 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>

Bas réseau de la distribution horaire de campus de strate

Dans le diagramme ci-dessous, GPS ou une source temporelle de césium est donné au centre de traitement des données central pour le bas réseau campus de strate. Ceci provisions une source temporelle de la strate 1 sur le réseau privé. S'il y a plusieurs GPS ou des sources temporelles de césium situées dans le réseau privé, alors la distribution horaire dans le réseau privé devrait être modifiée pour tirer profit des sources temporelles disponibles.

Généralement les mêmes principes et configurations s'appliquent comme avec les exemples précédents. La différence principale est dans ce cas que la racine de l'arborescence de synchronisation est une source temporelle privée plutôt qu'une source temporelle publique de l'Internet. Ceci change la conception du réseau de la distribution horaire pour tirer profit de la source temporelle privée de grande précision. La source temporelle privée est distribuée dans tout le réseau privé utilisant les principes de la hiérarchie et de la modularité qui ont été décrits dans les sections précédentes.

/image/gif/paws/19643/ntpm-6.gif

Définitions de processus

Une définition de processus est une gamme connectée d'actions, d'activités, et de modifications exécutées par des agents avec l'intention de satisfaire un but ou d'atteindre un but.

Le contrôle du processus est le processus de la planification et de la réglementation, en vue d'exécuter un processus d'un efficace et d'une façon efficace.

Graphiquement, ceci est affiché dans le diagramme ci-dessous.

/image/gif/paws/19643/ospf_a.gif

La sortie du processus doit se conformer aux normes opérationnelles qui sont définies par une organisation et sont basées sur des objectifs professionnels. Si le processus se conforme à l'ensemble de normes, le processus est considéré efficace puisqu'il peut être répété, mesuré, géré, et il contribue aux objectifs professionnels. Si les activités sont effectuées avec un effort minimum, le processus est également considéré efficace.

Propriétaire du processus

Les processus répartissent de diverses bornes organisationnelles. Par conséquent, il est important d'avoir un propriétaire du processus simple qui est responsable de la définition du processus. Le propriétaire est le centre des préoccupations pour déterminer et signaler si le processus est efficace et décisif. Si le processus n'est pas efficace ou décisif, le propriétaire du processus conduit la modification du processus. La modification du processus est régie par des procédés de contrôle et d'examen de modification.

Buts de processus

Des buts de processus sont établis pour placer la direction et la place pour la définition de processus. Des buts sont également utilisés pour définir les mesures qui sont utilisées pour mesurer l'efficacité d'un processus.

Le but de ce processus est de fournir des critères à documenter pendant la phase de conception de NTP, et de fournir à une capacité d'audit pour une architecture déployée de NTP assurant la conformité à long terme la conception destinée.

Indicateurs de performances de traitement

Des indicateurs de performances de traitement sont utilisés pour mesurer l'efficacité de la définition de processus. Les indicateurs de performances devraient être mesurables et quantifiables. Par exemple, les indicateurs de performances répertoriés ci-dessous sont numériques ou mesurés par temps.

  • La durée requise pour faire un cycle par le processus complet.

  • La fréquence de l'exécution requise afin de détecter proactivement des questions de NTP avant qu'elles affectent des utilisateurs.

  • La charge du réseau a associé avec l'exécution du processus.

  • Le nombre d'actions correctives recommandées par le processus.

  • Le nombre d'actions correctives mises en application en raison du processus.

  • La durée requise implémenter des actions correctives.

  • L'arriéré des actions correctives.

  • Les erreurs dans le diagnostic de dépannage ou de problème ont attribué au NTP des questions connexes.

  • Le nombre d'éléments ajoutés, retirés, ou modifiés dans le fichier "seed". C'est une indication de précision et de stabilité.

Entrées de traitement

Des entrées de traitement sont utilisées pour définir des critères et des préalables à un processus. Beaucoup de fois, l'identification des entrées de traitement fournit des informations sur des dépendances externes. Une liste d'entrées liées à la Gestion de NTP est fournie ci-dessous.

  • Documentation de conception de NTP

  • Données MIB de NTP collectées par l'interrogation SNMP

Sorties de processus

Les sorties de processus sont définies comme suit :

Définitions de tâche

Les sections suivantes définissent l'initialisation et les tâches répétitives associées avec la Gestion de NTP.

Tâches d'initialisation

Des tâches d'initialisation sont exécutées une fois pendant l'implémentation du processus et ne devraient pas être exécutées pendant chaque itération du processus.

Créez la conception de NTP

En vérifiant des tâches préalables nécessaires, si on le détermine que des aucunes des tâches ne sont mises en application ou ne fournissent pas des informations suffisantes pour servir efficacement les besoins de cette procédure, ce fait devrait être documenté par le propriétaire du processus et être soumis à la Gestion. Les contours ci-dessous de table les tâches d'initialisation nécessaires.

Tâche préalable nécessaire Description
Objectifs de tâche Créez un document de conception détaillée pour l'architecture de NTP qui répond à des conditions requises de conception et à des objectifs de coût
Entrées de tâche
  • Conditions requises techniques et économiques de conception
  • Documentation de conception de réseau existant
  • Critères définissant des aspects requis à enregistrer dans la conception pour activer des fonctions de gestion
  • Les informations informatiques de déploiement d'applications
  • Exigences de supervision des performances
Sortie de tâche Documentation de conception de NTP
Ressources en tâche Architecte d'exploitations réseau d'architecte d'ingénieur réseau
Rôles de tâche L'approbation technique de conception de réseaux des coûts de conception de réseaux de construction et d'exécutions de critiques a approuvé par le gestionnaire responsable de budget

Créez un fichier "seed"

Le processus de gestion de NTP exige l'utilisation d'un fichier "seed" d'enlever le besoin de fonction de découverte du réseau. Le fichier "seed" enregistre l'ensemble de routeurs qui sont régis par le processus de NTP et sont également utilisés comme centre des préoccupations pour coordonner avec les processus de gestion du changement dans une organisation. Par exemple, si de nouveaux Noeuds sont écrits dans le réseau, ils doivent être ajoutés au fichier "seed" de NTP. Si des modifications sont apportées aux noms de communauté SNMP en raison des exigences de sécurité, ces modifications doivent être reflétées dans le fichier "seed". Les contours ci-dessous de table les procédés pour créer un fichier "seed".

Tâche préalable nécessaire Description
Objectifs de tâche Créez le fichier "seed" qui identifie trois catégories de périphériques de réseau
  1. Périphériques essentiels — Voté sur une base fréquente pour information les informations de configuration
  2. Périphériques intéressants — Voté moins fréquemment
  3. Tout le NTP a activé des périphériques — A voté la moins quantité
Entrées de tâche Documentation de la topologie du réseau de documentation de conception de NTP
Sortie de tâche Fichier "seed"
Ressources en tâche Les critères de conception qui seront utilisés pour identifier et donner la priorité aux Noeuds ont impliqué en architecture de NTP

Paramètres d'optimisation du traitement de NTP de spécification de base

Plusieurs des paramètres disponibles pour surveiller la présentation de réseau de NTP une certaine normale ont attendu des variations. Le processus de l'établissement des références est utilisé pour caractériser les variations prévues par normale et pour placer les seuils qui définissent des anomalies inattendues ou. Cette tâche est utilisée à la spécification de base l'ensemble de paramètres variable pour l'architecture de NTP. Pour plus d'analyse détaillée d'établissement des références les techniques voient le processus de référence : Livre Blanc de pratique recommandée.

Processus Description
Objectifs de tâche Paramètres de variable de spécification de base
Entrées de tâche Identifiez le cntpPeersDispersion cntpPeersDelay de paramètres de cntpSysRootDispersion de cntpPeersOffset cntpPeersRootDelay cntpSysRootDelay variable de cntpPeersRootDispersion
Sorties de tâche Valeurs et seuils de spécification de base
Ressources en tâche Outils pour collecter des données SNMP et des spécifications de base calculatrices
Rôle de tâche Ingénieur de l'ingénieur réseau NMS

Tâches répétitives

Des tâches répétitives sont exécutées pendant chaque itération du processus et leur fréquence est déterminée et modifiée afin d'améliorer les indicateurs de performances.

Mettez à jour le fichier "seed"

Le fichier "seed" est essentiel pour l'implémentation efficace du processus de gestion de NTP. Par conséquent, l'état actuel du fichier "seed" doit être activement géré. Change en le réseau qui affectent le contenu de la nécessité de fichier "seed" d'être dépisté par le propriétaire de processus de gestion de NTP.

Processus Description
Objectifs de tâche Mettez à jour la précision du fichier "seed"
Entrées de tâche Les informations sur des modifications de réseau
Sorties de tâche Fichier "seed"
Ressources en tâche États, notifications, téléconférences au sujet des modifications
Rôle de tâche Ingénieur de l'ingénieur réseau NMS

Exécutez le balayage de noeud de NTP

Collectez les informations sur des balayages essentiels, intéressants, et de configuration définis par cette procédure. Exécutez ces trois balayages à différentes fréquences.

Les Noeuds essentiels sont des périphériques qui sont vus comme très importants pour les points d'informations de collecte de représentation. Le balayage essentiel de noeud est exécuté souvent, par exemple, horaire, ou sur une base de demande avant et après des modifications. Les Noeuds intéressants sont des périphériques qui sont considérés importants pour l'intégrité globale de l'architecture de NTP, mais peuvent ne pas être dans l'arborescence de synchronisation horaire pour la collection essentielle de données de performance. Cet état est exécuté périodiquement, par exemple, journal ou mensuel. L'état de configuration est un état intense complet et de ressource qui est utilisé pour caractériser la configuration globale de déploiement de NTP contre des enregistrements de conception. Cet état est exécuté moins fréquemment, par exemple, le mensuel ou la fois par trimestre. Un point important à considérer est que la fréquence que les états sont collectés peut être ajustée a basé sur la stabilité observée des besoins d'architecture et d'affaires de NTP.

Processus Description
Objectif de tâche Surveillez l'architecture de NTP
Entrée de tâche Données de périphérique de réseau
Sortie de tâche États
Ressources en tâche Applications logicielles de collecter des données et des états de produit
Rôle de tâche Ingénieur réseau

Passez en revue les états de noeud de NTP

Cette tâche exige que les états essentiels, intéressants, et de configuration sont passés en revue et analysés. Si des questions sont détectées, alors des actions correctives devraient être initiées.

Processus Description
Entrées de tâche États de balayage
Sorties de tâche Actions correctives d'analyse de stabilité
Ressources en tâche Access aux périphériques de réseau pour des recherches plus approfondies et la vérification
Rôle de tâche Ingénieur réseau

Identification de données

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

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

Données Description
ID de Noeuds Un périphérique qui a le NTP configuré
Pairs Les pairs configurés pour le périphérique
Source de synchronisation Le pair sélectionné pour la synchronisation
Données de configuration de NTP Paramètres utilisés pour juger la cohérence de la conception de NTP
Données de qualité de NTP Paramètres utilisés pour caractériser la qualité des associations de NTP

Identification de données SNMP

Groupe système MIB de NTP de Cisco

Les données SNMP de NTP sont définies par le Cisco-NTP-MIB. Pour des informations à jour sur les releases qui prennent en charge ce MIB, utilisent le navigateur de fonctionnalité CCO et sélectionnent l'option de localisateur MIB. Cet outil est accédé à par les outils TAC pour la Voix, page de technologies de téléphonie et de messagerie.

Le groupe système dans le MIB de NTP de Cisco fournit des informations pour le NTP courant de noeud de destination. Le noeud de destination est la destination des requêtes SNMP.

Nom d'objet Description d'objet
cntpSysStratum La strate de l'horloge locale. Si la valeur est placée à 1, une référence principale, alors la procédure de Primaire-horloge décrites dans la section 3.4.6, dans RFC-1305leavingcisco.com est appelée. : : = {cntpSystem 2} identifiant d'objet = .1.3.6.1.4.1.9.9.168.1.1.2
cntpSysPrecision Entier signé indiquant la précision de l'horloge système, en quelques secondes, à l'unité de deux le plus proche. La valeur doit être arrondie au prochain plus grand unité de deux. Par exemple, (16.67 ms) une horloge de l'alimentation-fréquence 50-Hz (20 ms) ou 60-Hz est assignée la valeur -5 (31.25 ms), alors que (1 ms) une horloge 1000-Hz contrôlée par le cristal est assignée la valeur -9 (1.95 ms). : : = {cntpSystem 3} identifiant d'objet = .1.3.6.1.4.1.9.9.168.1.1.3
cntpSysRootDelay Un nombre à point fixe signé indiquant tout le délai d'aller-retour en quelques secondes, à la source de référence principale à la racine du sous-réseau de synchronisation. : : = {cntpSystem 4} identifiant d'objet = .1.3.6.1.4.1.9.9.168.1.1.4
cntpSysRootDispersion L'erreur maximum en quelques secondes, relativement à la source de référence principale à la racine du sous-réseau de synchronisation. Seulement les valeurs positives plus grandes que zéro sont possibles. : : = {cntpSystem 5} identifiant d'objet = .1.3.6.1.4.1.9.9.168.1.1.4
cntpSysRefTime L'heure locale où l'horloge locale a été pour la dernière fois mise à jour. Si l'horloge locale n'a été jamais synchronisée, la valeur est zéro. : : = {cntpSystem 7} identifiant d'objet = .1.3.6.1.4.1.9.9.168.1.1.7
cntpSysPeer La source en cours de synchronisation contenant le seul cntpPeersAssocId d'identifiant d'association de l'entrée correspondante de pair dans le cntpPeersVarTable du pair agissant en tant que source de synchronisation. S'il n'y a aucun pair, la valeur est zéro. : : = {cntpSystem 9} identifiant d'objet = .1.3.6.1.4.1.9.9.168.1.1.9
cntpSysClock L'heure locale en cours. L'heure locale est dérivée de l'horloge de matériel de l'ordinateur et des incréments particuliers à intervalles selon la conception utilisée. : : = {cntpSystem 10} identifiant d'objet = .1.3.6.1.4.1.9.9.168.1.1.10

Groupe de homologues MIB de NTP de Cisco - Tableau variable de pairs

Le groupe de homologues du MIB de NTP de Cisco fournit des informations sur les pairs du noeud de destination.

Nom d'objet Description d'objet
cntpPeersVarTable Cette table fournit des informations sur les pairs avec lesquels le serveur NTP local a des associations. Les pairs sont également des serveurs de NTP s'exécutant sur des différents hôtes. C'est une table de cntpPeersVarEntry : : = {cntpPeers 1} identifiant d'objet = .1.3.6.1.4.1.9.9.168.1.2.1
cntpPeersVarEntry Chaque entrée des pairs fournit des informations de NTP récupérées d'un serveur de NTP de pair de détail. Chaque pair est identifié par un seul identifiant d'association. Des entrées sont automatiquement créées quand l'utilisateur configure le serveur de NTP à associer avec les pairs distants. De même, des entrées sont supprimées quand l'utilisateur retire l'association de pair du serveur de NTP. Des entrées peuvent également être créées par la station de Gestion par des valeurs de configuration pour des cntpPeersPeerAddress, des cntpPeersHostAddress, le cntpPeersMode et faire le cntpPeersEntryStatus comme active (1). Pour le moins, la station de Gestion doit placer une valeur pour que les cntpPeersPeerAddress fassent l'active de ligne. INDEX {cntpPeersAssocId} : : = {identifiant d'objet de 1 cntpPeersVarTable} = .1.3.6.1.4.1.9.9.168.1.2.1.1
cntpPeersAssocId Une valeur entière plus grande que zéro qui identifie seulement un pair avec lequel le serveur NTP local est associé. : : = {identifiant d'objet de 1 cntpPeersVarEntry} = .1.3.6.1.4.1.9.9.168.1.2.1.1.1
cntpPeersConfigured C'est un bit indiquant que l'association a été créée des informations de configuration et ne devrait pas deassociated même si le pair devient inaccessible. : : = {identifiant d'objet de 2 cntpPeersVarEntry} = .1.3.6.1.4.1.9.9.168.1.2.1.1.2
cntpPeersPeerAddress L'adresse IP du pair. En créant une nouvelle association, une valeur pour cet objet devrait être placée avant que la ligne soit faite à active. : : = {identifiant d'objet de 3 cntpPeersVarEntry} = .1.3.6.1.4.1.9.9.168.1.2.1.1.3
cntpPeersMode (1) non spécifié (0) et symmetricActive d'ENTIER de SYNTAXE {, (2) symmetricPassive, client (3), serveur (4), émission (5), reservedControl (6), reservedPrivate (7)} en créant une nouvelle association de pair, si aucune valeur n'est spécifiée pour cet objet, il se transfère sur (1) symmetricActive. : : = {identifiant d'objet de 8 cntpPeersVarEntry} = .1.3.6.1.4.1.9.9.168.1.2.1.1.8
cntpPeersStratum La strate de l'horloge de pair. : : = {identifiant d'objet de 9 cntpPeersVarEntry} = .1.3.6.1.4.1.9.9.168.1.2.1.1.9
cntpPeersRootDelay Un nombre à point fixe signé indiquant tout le délai d'aller-retour en quelques secondes, du pair à la source de référence principale à la racine du sous-réseau de synchronisation. : : = {identifiant d'objet de 13 cntpPeersVarEntry} = .1.3.6.1.4.1.9.9.168.1.2.1.1.13
cntpPeersRootDispersion L'erreur maximum, en quelques secondes, de l'horloge de pair relativement à la source de référence principale à la racine du sous-réseau de synchronisation. Seulement les valeurs positives plus grandes que zéro sont possibles. : : = {identifiant d'objet de 14 cntpPeersVarEntry} = .1.3.6.1.4.1.9.9.168.1.2.1.1.14
cntpPeersRefTime L'heure locale au pair quand son horloge a été pour la dernière fois mise à jour. Si l'horloge de pair n'a été jamais synchronisée, la valeur est zéro. : : = {identifiant d'objet de 16 cntpPeersVarEntry} = .1.3.6.1.4.1.9.9.168.1.2.1.1.16
cntpPeersReach Un registre à décalage utilisé pour déterminer l'état d'accessibilité du pair, avec des bits entrant de l'extrémité (de droite) moins significative. Un pair est considéré accessible si au moins un bit dans ce registre est placé à un (l'objet est différent de zéro). Les données dans le registre à décalage sont remplies par les procédures de protocole de NTP. : : = {identifiant d'objet de 21 cntpPeersVarEntry} = .1.3.6.1.4.1.9.9.168.1.2.1.1.21
cntpPeersOffset Le décalage prévu de l'horloge de pair relativement à l'horloge locale, en quelques secondes. L'hôte détermine la valeur de cet objet utilisant l'algorithme de horloge-filtre de NTP. : : = {identifiant d'objet de 23 cntpPeersVarEntry} = .1.3.6.1.4.1.9.9.168.1.2.1.1.21
cntpPeersDelay Le délai d'aller-retour prévu de l'horloge de pair relativement à l'horloge locale au-dessus du chemin réseau entre eux, en quelques secondes. L'hôte détermine la valeur de cet objet utilisant l'algorithme de horloge-filtre de NTP. : : = {identifiant d'objet de 24 cntpPeersVarEntry} = .1.3.6.1.4.1.9.9.168.1.2.1.1.24
cntpPeersDispersion L'erreur maximum prévue de l'horloge de pair relativement à l'horloge locale au-dessus du chemin réseau entre eux, en quelques secondes. L'hôte détermine la valeur de cet objet utilisant l'algorithme de horloge-filtre de NTP. : : = {identifiant d'objet de 25 cntpPeersVarEntry} = .1.3.6.1.4.1.9.9.168.1.2.1.1.25

Collecte de données

Collecte des informations SNMP

Toutes les informations requises par cette procédure peuvent être collectées par des requêtes SNMP. Afin d'analyser les données et produire les états, des scripts personnalisés ou les programmes logiciels devront être développés.

Présentation des données

État essentiel de noeud de NTP

Les Noeuds essentiels sont des périphériques qui sont importants dans l'arborescence de synchronisation des points de collecte de données de performance sélectionnés. S'il y a un service VoIP à revenus élevés étant surveillé et des mesures d'un-manière-retard-variation sont collectées, alors les noeuds sources et de destination où les groupes date/heure sont enregistrés sont considérés les Noeuds essentiels.

Dans cet exemple, la conception de NTP a été établie après une hiérarchie OSPF d'exemple. Par conséquent, les états décrits ci-dessous sont formatés pour grouper les périphériques de NTP selon la zone OSPF du périphérique. Dans les cas où un noeud a des interfaces dans de plusieurs zones, une décision doit être prise par le logiciel de génération du rapport quant à quelle zone le noeud sera répertorié pour l'état. Comme cité précédemment, l'OSPF n'est pas un préalable au NTP. Il est seulement utilisé en ce document comme exemple illustratif.

Zone Périphérique Données de périphérique Valeur
#n d'AreaId DeviceId #1 cntpSysStratum  
cntpSysPrecision  
cntpSysRootDelay  
cntpSysRootDispersion  
cntpSysRefTime  
cntpSysPeer  
cntpSysClock  
#n de DeviceId cntpSysStratum  
cntpSysPrecision  
cntpSysRootDelay  
cntpSysRootDispersion  
cntpSysRefTime  
cntpSysPeer  
cntpSysClock  

État intéressant de noeud de NTP

Le format de l'état intéressant de noeud est identique que le format pour l'état essentiel de noeud. Les Noeuds intéressants sont des Noeuds qui sont considérés importants pour l'architecture globale de NTP, mais peuvent directement ne pas contribuer à la synchronisation horaire des points de supervision des performances essentiels.

État de configuration de NTP

L'état de configuration est un état complet qui collecte des informations sur l'architecture globale de NTP. Cet état est utilisé pour enregistrer et vérifier le déploiement de NTP contre des enregistrements de conception.

Zone Périphérique Pair Données de pair Valeur
#n d'AreaId #n de DeviceId PeerId #1 cntpPeersAssocId  
cntpPeersConfigured  
cntpPeersPeerAddress  
cntpPeersMode  
cntpPeersStratum  
cntpPeersRootDelay  
cntpPeersRootDispersion  
cntpPeersRefTime  
cntpPeersReach  
cntpPeersOffset  
cntpPeersDelay  
cntpPeersDispersion  
#n de PeerId cntpPeersAssocId  
cntpPeersConfigured  
cntpPeersPeerAddress  
cntpPeersMode  
cntpPeersStratum  
cntpPeersRootDelay  
cntpPeersRootDispersion  
cntpPeersRefTime  
cntpPeersReach  
cntpPeersOffset  
cntpPeersDelay  
cntpPeersDispersion  

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 19643