Disponibilité : Haute disponibilité

Gestion de la configuration OSPF avec SNMP

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Le protocole de routage de Protocole OSPF (Open Shortest Path First) est défini par la version 2 OSPF RFC 2328.leavingcisco.com Le but de ce document est de proposer un cadre de processus qui permet à des organisations de mettre en place des procédures de gestion des configurations afin de comparer les déploiements d'OSPF aux plans de conception OSPF et d'effectuer des vérifications périodiques du déploiement d'OSPF afin d'assurer la conformité à long terme du processus par rapport au plan initial.

Ce document se concentre sur les fonctions de gestion de la configuration du modèle FCAPS défini par ITU-T (défaut, configuration, comptabilité/inventaire, représentation, Sécurité). La gestion de la configuration est définie par ITU-T M.3400 pendant que la fourniture fonctionne pour exercer le contrôle plus de, identifier, collecter des données de, et fournir des données à NEs (éléments de réseau).

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

La section de fond OSPF fournit un aperçu technologique d'OSPF comprenant l'information générale sur d'importants aspects d'un déploiement OSPF.

La section de définitions de processus fournit un aperçu des définitions de processus utilisées pour accomplir la Gestion de configuration OSPF. 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âches, 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 l'OSPF. L'identification de données considère la source d'informations ou où elle se trouve. Par exemple, les informations sont contenues par le système en Management Information Base de Protocole SNMP (Simple Network Management Protocol) (MIB), fichiers journal générés par Syslog, ou 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 de ce document décrit la collecte des données OSPF. 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 alors la sortie.

La section Présentation des données fournit des exemples de la façon dont les données sont présentées dans des formats d'état. Après que les données soient identifiées et collectées, elles sont analysées. Ce document fournit les exemples d'état qui peuvent être utilisés pour enregistrer et comparer des données de configuration OSPF.

Le message publicitaire et les outils de supervision d'Internet disponible au public, des sections de données de sondage SNMP, et d'algorithmes de collecte d'exemples de données fournissent des informations sur le développement des outils pour implémenter la procédure de gestion de configuration OSPF.

Fond OSPF

L'OSPF est un protocole de passerelle interne conçu pour être utilisé dans un Autonomous System simple. L'OSPF utilise l'état de lien ou la technologie basée sur Shortest-Path premier (SPF), par rapport au vecteur de distance ou à la technologie de Bellman-Ford trouvée dans les protocoles de routage tels que le Protocole RIP (Routing Information Protocol). Les différentes annonces d'état de lien (LSAs) décrivent des parties du routing domain OSPF, par exemple, l'Autonomous System entier. Ces LSAs sont inondés dans tout un routing domain, formant la base de données d'état de lien. Chaque routeur dans un domaine a une base de données identique d'état de lien. La synchronisation des bases de données d'état de lien est mise à jour avec un algorithme d'engorgement fiable. De la base de données d'état de lien, chaque routeur construit une table de routage en calculant un arbre au chemin le plus court, avec la racine de l'arborescence étant le routeur calculateur elle-même. Ce calcul désigné généralement sous le nom de l'algorithme de Dijkstra.

LSAs sont petit et chaque LSA décrit un petit morceau de routing domain OSPF, spécifiquement, le voisinage d'un routeur unique, le voisinage d'un transit network simple, une route inter-zone simple, ou une artère externe simple.

Cette table définit des fonctionnalités principales d'OSPF :

Caractéristique Description
Contiguïté Quand les paires de Routeurs OSPF deviennent adjacentes, les deux Routeurs synchronisent leurs bases de données d'état de lien en permutant des résumés de base de données sous forme de paquets d'échange de base de données OSPF. Les routeurs contigus mettent à jour alors la synchronisation de leurs bases de données d'état de lien par l'algorithme d'engorgement fiable. Les Routeurs reliés par des lignes série deviennent toujours adjacents. Sur des réseaux multi-accès (Ethernet), tous les Routeurs reliés au réseau deviennent à côté du routeur indiqué (DR) et du routeur de secours désigné (BDR).
Routeur indiqué Quand un DR est élu sur tous les réseaux multi-accès, il lance le LSA de réseau décrivant l'environnement local du réseau. Il joue également un rôle spécial dans l'algorithme d'engorgement, puisque tous les Routeurs sur le réseau synchronisent leurs bases de données d'état de lien en envoyant et en recevant LSAs à et du DR pendant le processus d'engorgement.
Routeur de secours désigné Quand le courant DR disparaît, un BDR est choisi sur des réseaux multi-accès pour expédier la transition du jeu rouleau-tambour. Quand le BDR succède, il n'a pas besoin de passer par le processus de contiguïté sur le réseau local (RÉSEAU LOCAL). Le BDR permet également à l'algorithme d'engorgement fiable de poursuivre en l'absence du DR avant que la disparition du DR soit notée.
support de réseau multi-accès de Non-émission L'OSPF traite des réseaux, tels que des réseaux publics de transmission de données de Relais de trames (PDNs), comme si ils étaient des réseaux locaux. Cependant, les informations de configuration supplémentaire sont nécessaires pour des Routeurs reliés à ces réseaux pour se trouver au commencement.
Secteurs de Gestion de configuration OSPF L'OSPF permet les Autonomous System à diviser en zones. Ceci fournit un niveau supplémentaire de la protection de routage de sorte que l'acheminement dans une zone soit protégé contre toutes les informations externes à la zone. En outre, en séparant un Autonomous System dans des zones, le coût de la procédure de Dijkstra, en termes de cycles CPU, est réduit.
Liaisons virtuelles En permettant la configuration des liaisons virtuelles, l'OSPF retire des restrictions topologiques sur des affichages de zone dans un Autonomous System.
Authentification des échanges de protocole de routage Chaque fois qu'un routeur OSPF reçoit un paquet de protocole de routage, il peut sur option authentifier le paquet avant de le traiter plus loin.
Mesure flexible de routage Dans l'OSPF, des mesures sont assignées aux interfaces de routeur sortantes. Le coût d'un chemin est la somme des interfaces composantes du chemin. La mesure de routage, par défaut, est dérivée de la bande passante du lien. Il peut être assigné par l'administrateur système pour indiquer n'importe quelle combinaison des caractéristiques du réseau telles que le retard, la bande passante, et le coût.
Coût égal par trajets multiples Quand les plusieurs artères de meilleur-coût à une destination existent, l'OSPF les trouve et emploie pour charger le trafic de partage à la destination.
Prise en charge de sous-réseaux de longueur variable Masques de sous-réseau de longueur variable de supports en portant un masque de réseau avec chaque destination annoncée.
Support de zone d'extrémité Pour prendre en charge des Routeurs ayant la mémoire insuffisante, des zones peuvent être configurées comme stubs. LSAs externe ne sont pas inondés dans et dans toutes des zones d'extrémité. Le routage aux destinations externes dans les zones d'extrémité est basé seulement sur le par défaut.

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 la figure ci-dessous.

/image/gif/paws/15408/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 un cadre pour vérifier la configuration déployée d'une implémentation OSPF contre une conception destinée et pour fournir un mécanisme pour apurer périodiquement le déploiement OSPF pour assurer la cohérence au fil du temps en ce qui concerne 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. Les indicateurs de performances répertoriés ci-dessous sont numériques ou mesurés par temps. Des indicateurs de performances pour le processus de gestion de configuration OSPF sont définis comme suit :

  • 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 OSPF 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.

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

  • L'arriéré des actions correctives.

  • Le temps d'arrêt attribué aux questions connexes OSPF.

  • 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 fournissent des informations sur des dépendances externes. Une liste d'entrées liées à la Gestion de configuration OSPF est fournie ci-dessous.

  • Documentation de conception OSPF

  • Données MIB OSPF collectées par l'interrogation SNMP

  • Les informations de Syslog

Sortie 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 configuration OSPF.

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 avec chaque itération du processus.

Vérifiez les tâches préalables nécessaires

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 et entrées de tâche
  1. Vérifiez que les documents de conception OSPF existent et que les informations suivantes sont facilement disponibles dans la documentation de conception de réseaux :
    1. Définitions de zone — Noms, plages d'adresses, et type de zone
    2. Identifications de routeur/routeur périphérique de système autonome de cadre de zone (ABR/ASBR)
    3. Identifications DR/BDR
    4. Les Noeuds et les interfaces de l'Internet Registry (IR) ont assigné aux zones
  2. Utilisez un modèle de configuration standard SNMP pour vérifier que le SNMP est configuré dans le réseau.

    Remarque: Ceci est utilisé plus tard comme entrée pour créer le fichier "seed".

  3. Utilisez un modèle de configuration standard de Syslog pour vérifier que le Syslog est déployé dans le réseau.
Sortie de tâche La sortie de tâche est un rapport sur l'état d'avancement des travaux sur la condition des tâches préalables nécessaires. Si des tâches les prenant en charge l'unes des sont considérées en tant qu'inefficace, le propriétaire du processus devrait soumettre une demande pour faire mettre à jour les processus de prise en charge. Si les processus de prise en charge ne peuvent pas être mis à jour, conduisez une estimation sur l'incidence à ce processus.
Rôle de tâche Ensemble de compétences d'ingénieur réseau

Créez un fichier "seed"

Le processus de gestion de configuration OSPF 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 OSPF 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" OSPF. 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".

Processus Description
Objectifs de tâche Créez un fichier "seed" qui sera utilisé pour initialiser le logiciel de gestion de configuration OSPF. Le formatage du fichier "seed" dépend des ressources utilisées pour implémenter le processus de gestion de configuration OSPF. Si des scripts personnalisés sont développés, le format du fichier "seed" est défini par la conception du logiciel. Si un système d'administration de réseaux (NMS) est utilisé, le format du fichier "seed" est défini par la documentation NMS.
Entrées de tâche
  1. Formatez le fichier "seed".
  2. Documentation de conception OSPF d'utilisation pour identifier les données suivantes :
    • Adresses IP de tous les Noeuds
    • Chaînes de caractères de la communauté SNMP
    • Comptes et mots de passe de telnet et de procédure de connexion CLI
  3. Programme et/ou noms du contact pour le processus de gestion du changement de réseau.
Sorties de tâche Un fichier "seed" pour le processus de gestion de configuration OSPF.
Ressources en tâche
  • Système commercial NMS
  • Système logiciel conçu en fonction du client
  • Processus manuel — Connectez-vous dans chaque élément de réseau et lignes de commande de question et enregistrez la sortie.
Rôle de tâche
  • NMS — Ingénieur réseau, administrateur NMS, et ensembles de compétences de script NMS.
  • Scripts personnalisés — Ensembles de compétences d'ingénieur réseau et de script NMS.
  • Processus manuels — Ingénieur réseau.

Tâches répétitives

Des tâches répétitives sont exécutées avec 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 configuration OSPF. 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 configuration OSPF.

Processus Description
Objectifs de tâche
  1. Mettez à jour l'actualité du fichier "seed" par le cheminement et les interactions avec les fonctions organisationnelles qui contrôlent des mouvements de réseau, ajoute, des modifications, et/ou des modifications de configuration réseau.
  2. Mettez à jour le contrôle de version et le contrôle de sauvegarde pour le fichier "seed".
Entrées de tâche
  1. Les informations de la gestion du changement, telle que des mouvements, des ajouts, et des modifications, qui affectent le contenu du fichier "seed".
  2. Les informations de l'ingénierie/de conception qui affectent le contenu du fichier "seed".
Sorties de tâche
  1. Rapport hebdomadaire sur le statut de la devise de fichier "seed".
  2. Définition et documentation décrivant les procédures d'emplacement et de restauration pour des sauvegardes de fichier "seed".
Ressources en tâche
  • Système commercial NMS
  • Système logiciel conçu en fonction du client
  • Processus manuel — Connectez-vous dans chaque élément de réseau et lignes de commande de question et enregistrez la sortie.
Rôle de tâche
  • NMS — Ingénieur réseau, administrateur NMS, et ensembles de compétences de script NMS.
  • Scripts personnalisés — Ensembles de compétences d'ingénieur réseau et de script NMS.
  • Processus manuels — Ingénieur réseau.

Exécutez le balayage OSPF

Les deux étapes utilisées pour exécuter le balayage OSPF sont :

  1. Collecter les données.

  2. Analyse des données.

Selon la façon dont le processus est utilisé, la fréquence de ces deux étapes variera. Par exemple, ce processus peut être utilisé pour vérifier des modifications d'installation. Dans ce cas, la collecte des informations fonctionne avant et après que la modification, et l'analyse de données soit conduite après la modification pour déterminer le succès de la modification.

Si ce processus est utilisé pour vérifier des enregistrements de conception de Gestion de configuration OSPF, la fréquence de collecte des informations et d'analyse dépend du débit de changement du réseau. Par exemple, s'il y a une importante quantité de changement du réseau, les vérifications du projet sont conduites une fois par semaine. S'il y a très peu de changement du réseau, les vérifications du projet sont conduites pas plus qu'une fois par mois.

Passez en revue les états OSPF

Le format des états de Gestion de configuration OSPF dépend des ressources utilisées pour implémenter le processus de gestion de configuration OSPF. Le tableau suivant fournit des formats d'état conçus en fonction du client suggérés.

État Format
Entrées de tâche Pour des états de Gestion de configuration OSPF, voyez la section Présentation des données dans ce document.
Sorties de tâche Si des problèmes sont trouvés entre les états de balayage et les enregistrements de conception logique, on doit prendre une décision quant à laquelle l'élément est correct et à laquelle est incorrect. L'élément incorrect devrait être corrigé. Ceci peut comporter la modification des enregistrements de conception ou d'un ordre de modification de réseau.
Ressources en tâche
  • Système commercial NMS
  • Système logiciel conçu en fonction du client
  • Manuel — Connectez-vous dans chaque élément de réseau et lignes de commande de question et enregistrez la sortie
Rôle de tâche
  • NMS — Ingénieur réseau, administrateur NMS, et ensembles de compétences de script NMS.
  • Scripts personnalisés — Ensembles de compétences d'ingénieur réseau et de script NMS.
  • Processus manuels — 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 peuvent être appliquées à la Gestion de configuration OSPF.

Données Description
Zones OSPF Les informations qui décrivent les zones reliées du routeur incluent :
  • ID de zone
  • Area authentication
  • Passages SPF
  • Nombre d'abr dans une zone
  • Nombre d'ASBR dans une zone
  • Compte de LSA pour la zone — Cohérence à travers des Routeurs dans une zone
  • Somme de contrôle de LSA pour la zone — Cohérence à travers des Routeurs dans la zone
  • Fréquence des rejets de paquet dus aux erreurs d'adressage par zone
  • Fréquence des rejets de paquet de protocole par le processus de routage par zone
  • La fréquence des écarts de paquet routé dus à l'aucune artère fondent la condition par zone
Interfaces OSPF Décrit une interface du point de vue de l'OSPF comme :
  • Adresse IP
  • ID de zone
  • État administratif
  • Mesures OSPF assignées à l'interface
  • Minuteurs OSPF assignés à l'interface
  • État OSPF
État des voisins OSPF Décrit un voisin OSPF.
  • ID de routeur voisin
  • État de voisinage
  • Événements voisins — Le nombre de fois les relations voisines a l'état modifié, ou une erreur s'est produite.
  • File d'attente voisine de retransmission — La longueur en cours de la file d'attente de retransmission.

Identification de données SNMP

Cisco prend en charge actuellement le MIB de version 2 OSPF RFC 1253leavingcisco.com . RFC 1253 ne contient pas des définitions de déroutement SNMP pour l'OSPF. La dernière version du MIB OSPF est des déroutements SNMP de la version 2. OSPFleavingcisco.com RFC 1850 sont définies pour l'OSPF dans RFC 1850. RFC 1850 n'est pas pris en charge sur l'implémentation de Cisco du MIB OSPF.

Veuillez se référer à la section de données de sondage SNMP de ce document pour d'autres détails.

Veuillez se référer à la page de logiciel de Gestion de réseau de Cisco pour une liste définitive dont on prend en charge le MIB sur lequel version de plate-forme et de code.

Identification de données de RMON

Il n'y a aucun spécifique RMON eu besoin pour cette procédure.

Identification de données de Syslog

Généralement le Syslog génère des messages de service-particularité pour différentes Technologies. Bien que les informations de Syslog soient plus appropriées pour le défaut et la Gestion des performances, les informations fournies ici sont une référence. Pour un exemple des informations de Syslog OSPF générées par des périphériques de Cisco, voir les messages d'erreur OSPF.

Pour une liste complète de messages système par l'installation, référez-vous s'il vous plaît aux messages et aux procédures de récupération.

Identification de données CLI de Cisco IOS

Dans cette version de la procédure de gestion de configuration OSPF, il n'y a aucune données CLI eue besoin.

Collecte de données

Collecte des informations SNMP

La table ci-dessous définit les différents composants de la collecte des informations SNMP.

Composant de données SNMP Définition
Configuration de général SNMP Référez-vous à configurer le SNMP pour des informations générales sur des pratiques recommandées de configuration SNMP.
Entretenez la configuration spécifique SNMP Il n'y a aucune configuration SNMP de service-particularité exigée pour cette procédure.
Conditions requises MIB SNMP Voyez la section Identification des données ci-dessus.
Collecte d'interrogation MIB SNMP Des données du sondage SNMP sont collectées par un système commercial tel que des puissances en chevaux OpenViewleavingcisco.com ou par des scripts personnalisés. Pour un autre examen des algorithmes de collecte, voyez la section d'algorithmes de collecte d'exemples de données de ce document.
Collecte de déroutement MIB SNMP La version en cours du MIB OSPF prise en charge sur des périphériques de Cisco ne prend en charge pas des déroutements SNMP. Il n'y a aucun déroutement SNMP exigé pour cette procédure.

Collecte des informations de RMON

Il n'y a aucun configuration et de RMON eues besoin dans cette version de la procédure.

Collecte des informations de Syslog

Les instructions de configuration générales de Syslog sont hors de portée de ce document. Référez-vous à configurer et à dépanner le pare-feu Cisco Secure PIX avec un pour en savoir plus simple de réseau interne.

Des conditions requises spécifiques OSPF sont adressées en configurant le routeur OSPF aux modifications de log neighbor avec un message de Syslog utilisant la commande suivante :

OSPF_ROUTER(config)# ospf log-adj-changes

Collecte de données CLI de Cisco IOS

Généralement le Cisco IOS CLI fournit la plupart d'accès direct aux informations brutes contenues par le Ne. Cependant, l'accès CLI approprié mieux aux procédures de dépannage et aux activités de gestion du changement que pour la Gestion de configuration globale comme défini par cette procédure. Access par le CLI ne mesurera pas pour la Gestion d'un grand réseau. Dans des ces cas, l'accès aux informations automatisé est exigé.

Dans cette version de la procédure de gestion de configuration OSPF, il n'y a aucune configuration et CLI eues besoin.

Présentation des données

État de zone OSPF

Ce qui suit est un format d'exemple pour l'état de zone OSPF. Le format de l'état est déterminé par les capacités des NMS commerciaux, si on est utilisé, ou la sortie conçue des scripts personnalisés.

Zone Zones d'information Dernier passage Ce passage
ID de zone #1 Authentification    
Passages SPF    
Compte ABR    
Nombre de routeurs ASBR    
Compte LSA    
Somme de contrôle LSA    
Erreurs d'adresse    
Acheminement des écarts    
Aucune artère trouvée    
#n d'ID de zone Authentification    
Passages SPF    
Compte ABR    
Nombre de routeurs ASBR    
Compte LSA    
Somme de contrôle LSA    
Erreurs d'adresse    
Acheminement des écarts    
Aucune artère trouvée    

Rapport d'interface OSPF

Ce qui suit est un format d'exemple pour le rapport d'interface OSPF. Dans la pratique, le format de l'état est déterminé par les capacités des NMS commerciaux, si on est utilisé, ou la sortie conçue des scripts personnalisés.

Zone Périphérique Interface Zones d'information Dernier passage Ce passage
ID de zone #1 ID #1 de noeud ID d'interface #1 Adresse IP    
ID de zone    
État d'administration    
État OSPF    
Mesures/coût/temporisateurs    
#n d'ID d'interface Adresse IP    
ID de zone    
État d'administration    
État OSPF    
Mesures/coût/temporisateurs    
#n d'ID de noeud ID d'interface #1 Adresse IP    
ID de zone    
État d'administration    
État OSPF    
Mesures/coût/temporisateurs    
#n d'ID d'interface Adresse IP    
ID de zone    
État d'administration    
État OSPF    
Mesures/coût/temporisateurs    
#n d'ID de zone ID #1 de noeud ID d'interface #1 Adresse IP    
ID de zone    
État d'administration    
État OSPF    
Mesures/coût/temporisateurs    
#n d'ID d'interface Adresse IP    
ID de zone    
État d'administration    
État OSPF    
Mesures/coût/temporisateurs    
#n d'ID de noeud ID d'interface #1 Adresse IP    
ID de zone    
État d'administration    
État OSPF    
Mesures/coût/temporisateurs    
#n d'ID d'interface Adresse IP    
ID de zone    
État d'administration    
État OSPF    
Mesures/coût/temporisateurs    

Rapport sur les voisins OSPF

Ce qui suit est un format d'exemple pour le rapport sur les voisins OSPF. Dans la pratique, le format de l'état est déterminé par les capacités des NMS commerciaux, si on est utilisé, ou la sortie conçue des scripts personnalisés.

Zone Périphérique Voisins Zones d'information Dernier passage Ce passage
ID de zone #1 ID #1 de noeud ID de voisin #1 ID de routeur    
Adresse IP du routeur    
État    
Événements    
Retrans Que    
#n d'ID de voisin ID de routeur    
Adresse IP du routeur    
État    
Événements    
Retrans Que    
#n d'ID de noeud ID de voisin #1 ID de routeur    
Adresse IP du routeur    
État    
Événements    
Retrans Que    
#n d'ID de voisin ID de routeur    
Adresse IP du routeur    
État    
Événements    
Retrans Que    
#n d'ID de zone ID #1 de noeud ID de voisin #1 ID de routeur    
Adresse IP du routeur    
État    
Événements    
Retrans Que    
#n d'ID de voisin ID de routeur    
Adresse IP du routeur    
État    
Événements    
Retrans Que    
#n d'ID de noeud ID de voisin #1 ID de routeur    
Adresse IP du routeur    
État    
Événements    
Retrans Que    
#n d'ID de voisin ID de routeur    
Adresse IP du routeur    
État    
Événements    
Retrans Que    

Message publicitaire et outils de supervision d'Internet disponible au public

Les outils commerciaux existent pour faciliter la collecte et le traitement des informations de Syslog et pour l'interrogation de collecte des variables MIB générales SNMP.

Pas commercial ou les outils de supervision d'Internet disponible au public sont connus qui prennent en charge la Gestion de configuration OSPF comme défini par cette procédure. Par conséquent, des scripts personnalisés locaux et les procédures sont exigés.

Données de sondage SNMP

RFC 1213 de table de routageleavingcisco.com

Nom d'objet Description d'objet
ipRouteDest L'adresse IP de destination de l'artère. Une entrée avec une valeur de 0.0.0.0 est considérée un default route. Les plusieurs artères à une destination simple peuvent apparaître dans la table, mais l'accès à de telles plusieurs entrées dépend des mécanismes de table-Access définis par le protocole de gestion de réseau en service. : : = {identifiant d'objet de 1 ipRouteEntry} = 1.3.6.1.2.1.4.21.1.1
ipRouteMask Indique le masque pour être logique avec l'adresse de destination avant d'être comparé à la valeur dans le domaine ipRouteDest. Pour ces systèmes qui ne prennent en charge pas les masques de sous-réseau arbitraires, un agent construit la valeur avec de l'ipRouteMask en déterminant si la valeur du champ ipRouteDest correspondant appartient à une classe A, au réseau B, ou de C, utilisant un des réseaux suivants de masque :
  • Classe A = 255.0.0.0
  • Classe B = 255.255.0.0
  • C de classe = 255.255.255.0
Si la valeur du ipRouteDest est 0.0.0.0, le default route, la valeur de masque est également 0.0.0.0.

Remarque: Tous les sous-systèmes de Routage IP utilisent implicitement ce mécanisme.

: : = {identifiant d'objet de 11 ipRouteEntry} = 1.3.6.1.2.1.4.21.1.11
ipRouteNextHop L'adresse IP du prochain saut de cette artère. Dans le cas d'une artère attachée à une interface qui est réalisée avec des supports de diffusion, la valeur de ce champ est l'adresse IP de l'agent sur l'interface. : : = {identifiant d'objet de 7 ipRouteEntry} = 1.3.6.1.2.1.4.21.1.7
ipRouteIfIndex La valeur de l'indice qui identifie seulement l'interface locale par laquelle le prochain saut de l'artère est accédé. Cette interface est la même interface identifiée par la valeur d'IfIndex. : : = {identifiant d'objet de 2 ipRouteEntry} = 1.3.6.1.2.1.4.21.1.2

Objets du divers RFC 1213

Nom d'objet Description d'objet
ipAdEntIfIndex La valeur de l'indice qui identifie seulement l'interface applicable à l'entrée. Cette interface est la même interface identifiée par la valeur d'IfIndex. : : = {identifiant d'objet de 2 ipAddrEntry} = 1.3.6.1.2.1.4.20.1.2
ipInAddrErrors Le nombre de datagrammes d'entrée jetés parce que l'adresse IP dans leur en-tête IP était une zone réceptrice de destination non valide pour l'entité. Ce compte inclut des adresses non valides (0.0.0.0) et des adresses non vérifiées de classe (classe E). Pour les entités qui ne sont pas des passerelles IP et n'expédient pas des datagrammes, le compteur inclut des datagrammes jetés parce que l'adresse de destination n'était pas une adresse locale. {IP 5} objectez l'identifiant = 1.3.6.1.2.1.4.5
ipRoutingDiscards Le nombre d'entrées valides de routage jetées. Un possible raison pour jeter une telle entrée est de libérer l'espace de mémoire tampon pour d'autres entrées de routage. {IP 23} objectez l'identifiant = 1.3.6.1.2.1.4.23
ipOutNoRoutes Le nombre de datagrammes IP jetés parce qu'aucune artère ne pourrait s'avérer pour les transmettre à leur destination. {IP 12} objectez l'identifiant = 1.3.6.1.2.1.4.12

Tableau de zoneleavingcisco.com OSPF RFC 1253

Nom d'objet Description d'objet
ospfAreaID Un entier de 32 bits identifiant seulement une zone. L'ID de zone 0.0.0.0 est utilisé pour le circuit principal OSPF. : : = {identifiant d'objet de 1 ospfAreaEntry} = 1.3.6.1.2.1.14.2.1.1
ospfAuthType Le type d'authentification spécifié pour cette zone. Des types supplémentaires d'authentification peuvent être assignés localement sur une base de par-zone. La valeur par défaut est 0. : : = {identifiant d'objet de 2 ospfAreaEntry} = 1.3.6.1.2.1.14.2.1.2
OspfSpfRuns Le nombre de fois où la table de routage d'intra-zone a été calculée utilisant la base de données de l'état de lien de cette zone. identifiant d'objet = 1.3.6.1.2.1.14.2.1.4
ospfAreaBdrRtrCount Le nombre total d'abr accessibles dans cette zone. C'est au commencement 0, la valeur par défaut, et est calculée dans chaque passage SPF. : : = {identifiant d'objet de 5 ospfAreaEntry} = 1.3.6.1.2.1.14.2.1.5
ospfASBdrRtrCount Le nombre total d'ABSRs accessible dans cette zone. C'est au commencement 0 (la valeur par défaut), et est calculé dans chaque passage SPF. : : = {identifiant d'objet de 6 ospfAreaEntry} = 1.3.6.1.2.1.14.2.1.6
ospfAreaLSACount Le nombre total de LSAs dans la base de données de l'état de lien d'une zone, à l'exclusion de LSAs externe. La valeur par défaut est 0. : : = {identifiant d'objet de 7 ospfAreaEntry} = 1.3.6.1.2.1.14.2.1.7
ospfAreaLSACksumSum La somme non signée de 32 bits des sommes de contrôle LS du LSA contenues dans la base de données de l'état de lien de la zone. Cette somme exclut externe (type LS 5) LSAs. La somme peut être utilisée pour déterminer s'il y a eu un changement de la base de données de l'état de lien d'un routeur et pour comparer la base de données d'état de lien de deux Routeurs. La valeur par défaut est 0. : : = {identifiant d'objet de 8 ospfAreaEntry} = 1.3.6.1.2.1.14.2.1.8

Tableau d'interface OSPF RFC 1253

Nom d'objet Description d'objet
OspfIfIpAddress L'adresse IP de l'interface OSPF. identifiant d'objet = 1.3.6.1.2.1.14.7.1.1
OspfIfEvents Le nombre de fois l'interface OSPF a changé son état, ou une erreur s'est produite. identifiant d'objet = 1.3.6.1.2.1.14.7.1.15
OspfIfState L'état d'interface OSPF. identifiant d'objet = 1.3.6.1.2.1.14.7.1.12

Table des voisins OSPF RFC 1253

Nom d'objet Description d'objet
OspfNbrIpAddr L'adresse IP de ce voisin. : : = {identifiant d'objet de 1 ospfNbrEntry} = 1.3.6.1.2.1.14.10.1.1
ospfNbrAddressLessIndex La valeur correspondante d'IfIndex dans le MIB de norme Internet sur un index qui n'a pas une adresse IP. Sur la création de ligne, ceci peut être dérivé de l'exemple. : : = {identifiant d'objet de 2 ospfNbrEntry} = 1.3.6.1.2.1.14.10.1.2
ospfNbrRtrId Un entier de 32 bits, représenté comme IP address, identifiant seulement le routeur voisin dans l'Autonomous System. La valeur par défaut est 0.0.0.0. : : = {identifiant d'objet de 3 ospfNbrEntry} = 1.3.6.1.2.1.14.10.1.3
ospfNbrState L'état des relations avec le voisin. Les états sont :
  • en bas de (1)
  • tentative (2)
  • init (3)
  • (4) bi-directionnel
  • exchangeStart (5)
  • échange (6)
  • chargement (7)
  • complètement (8)
: : = {identifiant d'objet de 6 ospfNbrEntry} = 1.3.6.1.2.1.14.10.1.6
ospfNbrEvents Le nombre de fois les relations voisines a l'état modifié, ou une erreur s'est produite. La valeur par défaut est 0. : : = {identifiant d'objet de 7 ospfNbrEntry} = 1.3.6.1.2.1.14.10.1.7
ospfNbrLSRetransQLen La longueur en cours de la file d'attente de retransmission. La valeur par défaut est 0. : : = {identifiant d'objet de 8 ospfNbrEntry} = 1.3.6.1.2.1.14.10.1.8

Algorithmes de collecte d'exemples de données

Pendant l'enquête sur ce document, un programme de « C » de prototype a été développé. Le programme, appelé oscan, a été écrit utilisant Microsoft Developer Studio 97 avec la version 5.0 de Visual C++. Il y a deux bibliothèques spécifiques qui fournissent l'interface de programmation de fonction SNMP (API). Ces bibliothèques sont snmpapi.lib et mgmtapi.lib

Les fonctions fournies par Microsoft API sont groupées dans trois catégories importantes et répertoriées dans la table ci-dessous.

Fonctions d'agent Fonctions de gestionnaire Fonctions de service
SnmpExtensionInit SnmpExtensionInitEx SnmpExtensionQuery SnmpExtensionTrap SnmpMgrClose SnmpMgrGetTrap SnmpMgrOidToStr SnmpMgrOpen SnmpMgrRequest SnmpMgrStrToOid SnmpMgrTrapListen SnmpUtilMemAlloc SnmpUtilMemFree SnmpUtilMemReAlloc SnmpUtilOidAppend SnmpUtilOidCmp SnmpUtilOidCpy SnmpUtilOidFree SnmpUtilOidNCmp SnmpUtilPrintAsnAny SnmpUtilVarBindCpy SnmpUtilVarBindListCpy SnmpUtilVarBindFree SnmpUtilVarBindListFree

Le code oscan de prototype a encapsulé Microsoft API avec un ensemble de fonctions supplémentaires répertoriées ci-dessous.

  • snmpWalkStrOid

  • snmpWalkAsnOid

  • snmpWalkVarBind

  • snmpWalkVarBindList

Ces fonctions fournissent un API générique qui permettent l'accès aux diverses tables MIB SNMP utilisées pour mettre à jour les données de configuration OSPF. L'identifiant d'objet (OID) pour que la table soit accédée à est passé à l'API oscan avec une table l'appel que spécifique de retour fonctionnent. L'appel de retour fonctionnent a l'intelligence de traiter les données renvoyées des tables.

Routine principale

La première tâche établit une liste de Noeuds qui seront la cible du programme oscan. Afin d'éviter le problème de « découverte des périphériques », un fichier "seed" est exigé pour identifier les Noeuds à balayer. Le fichier "seed" fournit des informations telles que l'adresse IP et les chaînes de caractères de la communauté en lecture seule SNMP.

Le programme oscan doit mettre à jour plusieurs structures de données internes pour stocker les informations SNMP qui sont collectées des Routeurs. Il y a généralement une structure de données interne pour chaque table MIB SNMP qui est collectée.

Main
	load node array based on information in the seed file.
	while more entries in the node array
		start SNMP session for this node
		collect IP route table for this node
		collect OSPF area table for this node
		collect OSPF Neighbor table for this node
		collect  sysName for this node
		collect OSPF Interface table for this node
		end SNMP session for this node
	end while

Table de route IP

Le soin doit être pris tout en accédant à la table de route IP avec le SNMP puisqu'il est simple de surcharger la CPU d'un routeur pendant cette exécution. Par conséquent, le programme oscan utilise un paramètre de délai configurable d'utilisateur. Le paramètre fournit un retard entre chaque demande SNMP. Pour de grands environnements, ceci signifie que le temps total de collecter les informations peut être très significatif.

La table de routage contient quatre informations par lesquelles oscan est intéressé :

  • ipRouteDest

  • ipRouteMask

  • ipRouteNextHop

  • ipRouteIfIndex

La table de routage est indexée par ipRouteDest. Par conséquent, chaque objet qui est retourné de l'obtenir-demande SNMP a le ipRouteDest ajouté à l'OID.

L'ipRouteIfIndex d'objet est un entier que les index dans l'adresse IP ajournent (ipAddrTable). L'ipAddrTable est indexé utilisant l'objet d'ipAdEntAddr (l'adresse IP de l'interface). Afin d'obtenir l'adresse IP de l'interface, un processus à quatre phases est exigé :

  1. Collectez l'ipRouteIfIndex de la table de routage.

  2. Accédez à l'ipAddrTable utilisant l'ipRouteIfIndex pour le filtrage.

  3. Quand un modèle est trouvé, convertissez l'OID en chaîne et collectez les quatre derniers pointillés - les champs décimaux qui seront l'adresse IP de l'interface.

  4. Enregistrez l'adresse IP de l'interface de nouveau dans la table de route IP.

L'algorithme général pour accéder à la table de route IP est affiché ci-dessous. En ce moment, seulement la valeur entière de l'ipRouteIfIndex est enregistrée. Plus tard dans le processus, en collectant les informations d'interface, l'ipAddrTable est accédé à et les autres informations est collecté et placé dans la table de route IP interne.

OID List =
	ipRouteDestOID,
	ipRouteMaskOID,
	ipRouteNextHopOID,
	ipRouteIfIndexOID;

For each object returned by  SNMP route table walk
	Sleep // user configurable polling delay.
	check varbind oid against OID list
	if OID is ipRouteDestOID
		add new entry in the internal route table array
	if OID is one of the others
		search internal route array for matching index value
		store information in array

Les informations collectées sont représentées dans une table qui ressemble à la sortie familière du routeur CLI ci-dessous.

ROUTE TABLE
**********************************************************
Destination     Mask                GW              Interface       
10.10.10.4      255.255.255.252     10.10.10.5      10.10.10.5      
10.10.10.16     255.255.255.252     10.10.10.6      10.10.10.5      
10.10.10.24     255.255.255.252     10.10.10.25     10.10.10.25     
10.10.10.28     255.255.255.252     10.10.11.2      10.10.11.1      
10.10.10.36     255.255.255.252     10.10.10.6      10.10.10.5      
10.10.11.0      255.255.255.0       10.10.11.1      10.10.11.1      
10.10.13.0      255.255.255.0       10.10.11.2      10.10.11.1 

Tableau de zone OSPF

La collecte d'informations de la table de zone OSPF est faite en analysant la table de zone OSPF (ospfAreaTable) et en traitant les données pendant qu'elle est retournée. L'index à l'ospfAreaTable est l'osfpAreaId. L'ospfAreaId est enregistré dans le format décimal séparé par des points qui est identique à une adresse IP. Par conséquent, les mêmes sous-programmes qui ont été utilisés pour traiter et rechercher l'ipRouteTable et l'ipRouteIfIndex peuvent être réutilisés ici.

Il y a plusieurs éléments de donnée qui ne sont pas réellement dans la table de zone OSPF qui sont inclus dans cette section. Par exemple, les ipInAddrErrors, IpRoutingDiscards, et les objets d'ipOutNoRoute sont dans la définition MIB-2, mais ne sont pas associés avec une zone OSPF. Ces objets sont associés avec un routeur. Par conséquent, ces compteurs sont utilisés comme mesure de zone en ajoutant les valeurs pour chaque noeud dans une zone à un compteur de zone. Par exemple, dans l'état de zone OSPF, le nombre d'en raison jeté par paquets d'aucune artère trouvée est réellement la somme des paquets jetés par tous les Routeurs dans cette zone. C'est une mesure de haut niveau qui fournit une vue générale des santés de routage de la zone.

OID List =
	ipInAddrErrorsOID,
	ipRoutingDiscardsOID,
	ipOutNoRouteOID,
	areaIdOID,
	authTypeOID,
	spfRunsOID,
	abrCountOID,
	asbrCountOID,
	lsaCountOID,
	lsaCksumSumOID;

	For object returned from the SNMP walk of  the Area Table
		Sleep // user configurable polling delay.
		check varbind oid against OID list.
		if OID is ospfAreaId
			add new entry in the internal route table array
		if OID one of the others
			search internal array for matching index value
			store information in array
	end of for loop
	get ipInAddrErrors, ipRoutingDiscards, ipOutNoRoute
	add values to overall Area counters

Les informations collectées sont représentées dans la table ASCII ci-dessous.

AREAS
**********************************************************
AREA = 0.0.0.0			AREA = 0.0.0.2
authType = 0			authType = 0
spfRuns = 38			spfRuns = 18
abrCount = 2			abrCount = 1
asbrCount = 0			asbrCount = 0
lsaCount = 11			lsaCount = 7
lsaCksumSum = 340985		lsaCksumSum = 319204
ipInAddrErrors = 0		   ipInAddrErrors = 0
ipRoutingDiscards = 0		ipRoutingDiscards = 0
ipOutNoRoutes = 0		ipOutNoRoutes = 0

Table des voisins OSPF

L'index pour la table voisine est deux valeurs :

  • ospfNbrIpAddr — L'ospfNbrIpAddr est l'adresse IP du voisin.

  • ospfNbrAddressLessIndex — L'ospfNbrAddressLessIndex peut être l'une de deux valeurs :

    • Pour une interface qui a une adresse IP assignée, il est zéro.

    • Pour une interface qui n'a pas une adresse IP assignée, il est interprété comme IfIndex du MIB de norme Internet.

Puisqu'il y a deux valeurs pour l'index, vous devez ajuster les algorithmes utilisés plus tôt pour les informations supplémentaires ajoutées aux OID retournés. Après fabrication de ce réglage, les mêmes sous-programmes qui ont été utilisés pour traiter et rechercher l'ipRouteTable et l'ipRouteIfIndex peuvent être réutilisés ici.

OID List =
	ospfNbrIpAddrOID,
	ospfNbrAddressLessIndexOID,
	ospfNbrRtrIdOID,
	ospfNbrStateOID,
	ospfNbrEventsOID,
	ospfNbrLSRetransQLenOID,

	For object returned from the SNMP walk of the Neighbor Table
		Sleep // user configurable polling delay.
		check varbind OID against OID list.
		if OID matches ospfNbrIpAddr
			add new entry in the internal neighbor table array
		if OID matches one of the others
			search array for matching index value
			store information in array

Les informations collectées sont représentées dans la table ASCII ci-dessous.

NEIGHBORS
************************************************************
NEIGHBOR #0				NEIGHBOR #1
Nbr Ip Addr = 10.10.10.6		Nbr Ip Addr = 10.10.11.2
Nbr Rtr Id = 10.10.10.17		Nbr Rtr Id = 10.10.10.29
Nbr State = 8				Nbr State = 8
Nbr Events = 6				Nbr Events = 30
Nbr Retrans = 0				Nbr Retrans = 0

Informations connexes


Document ID: 15408