Gestion de la configuration OSPF avec SNMP

Options de téléchargement

  • PDF     (179.6 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (103.1 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
Mis à jour:15 septembre 2008
ID du document:15408

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Introduction

Le protocole de routage OSPF (Open Shortest Path First) est défini par RFC 2328 OSPF Version 2 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 porte sur les fonctions de gestion de la configuration du modèle FCAPS défini par l'UIT-T (panne, configuration, comptabilité/inventaire, performances, sécurité). La gestion de la configuration est définie par l'UIT-T M.3400 comme fournissant des fonctions permettant d'exercer un contrôle, d'identifier, de collecter des données et de fournir des données aux éléments réseau.

Les renseignements fournis dans le présent document sont présentés dans plusieurs grandes sections décrites ci-après.

La section Contexte OSPF fournit une présentation technologique du protocole OSPF, y compris des informations générales sur les aspects importants d'un déploiement OSPF.

La section Définitions de processus fournit une vue d'ensemble des définitions de processus utilisées pour la gestion de la configuration OSPF. Les détails du processus sont décrits en termes d'objectifs, d'indicateurs de performance, d'entrées, de sorties et de tâches individuelles.

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

La section Identification des données décrit l'identification des données pour OSPF. L'identification des données tient compte de la source de l'information ou de son emplacement. Par exemple, les informations sont contenues par le système dans la base MIB (Simple Network Management Information Base) SNMP (Simple Network Management Protocol), les fichiers journaux générés par Syslog ou les structures de données internes accessibles uniquement par l'interface de ligne de commande (CLI).

La section Collecte de données 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, les données MIB SNMP sont collectées par plusieurs mécanismes tels que les déroutements, les alarmes et événements RMON (Remote Monitoring) ou les interrogations. Les données gérées par des structures de données internes sont collectées par des scripts automatiques ou par un utilisateur se connectant manuellement au système pour émettre la commande CLI, puis enregistrer le résultat.

La section Présentation des données fournit des exemples de présentation des données sous forme de rapport. Une fois les données identifiées et collectées, elles sont analysées. Ce document fournit des exemples de rapports qui peuvent être utilisés pour enregistrer et comparer des données de configuration OSPF.

Les sections Outils de surveillance Internet commerciaux et publics, Données d'interrogation SNMP et Exemples d'algorithmes de collecte de données fournissent des informations sur le développement d'outils pour mettre en oeuvre la procédure de gestion de configuration OSPF.

Arrière-plan OSPF

Le protocole OSPF est un protocole de passerelle interne conçu pour être utilisé dans un système autonome unique. Le protocole OSPF utilise une technologie basée sur l’état des liaisons ou le chemin le plus court d’abord (SPF), par rapport à la technologie à vecteur de distance ou Bellman-Ford que l’on trouve dans les protocoles de routage tels que le protocole RIP (Routing Information Protocol). Les LSA (Link-State Advertisement) décrivent des éléments du domaine de routage OSPF, par exemple, l’ensemble du système autonome. Ces LSA sont diffusées dans un domaine de routage, formant la base de données d’état des liaisons. Chaque routeur d’un domaine possède une base de données d’état des liaisons identique. La synchronisation des bases de données à état de liens est gérée à l’aide d’un algorithme d’inondation fiable. À partir de la base de données d’état des liaisons, chaque routeur crée une table de routage en calculant une arborescence du chemin le plus court, la racine de l’arborescence étant le routeur qui calcule lui-même. Ce calcul est communément appelé algorithme Dijkstra.

Les LSA sont petites et chaque LSA décrit une petite partie du domaine de routage OSPF, en particulier le voisinage d’un routeur unique, le voisinage d’un réseau de transit unique, une route interzone unique ou une route externe unique.

Ce tableau définit les principales caractéristiques du protocole OSPF :

Fonctionnalité Description
Contiguïté Lorsque des paires de routeurs OSPF deviennent adjacentes, les deux routeurs synchronisent leurs bases de données d’état des liaisons en échangeant des résumés de base de données sous la forme de paquets d’échange de base de données OSPF. Les routeurs adjacents gèrent ensuite la synchronisation de leurs bases de données d’état des liaisons via l’algorithme de diffusion fiable. Les routeurs connectés par des lignes série deviennent toujours adjacents. Sur les réseaux à accès multiple (Ethernet), tous les routeurs connectés au réseau deviennent adjacents à la fois au routeur désigné (DR) et au routeur désigné de secours (BDR).
Routeur désigné Lorsqu’un routeur désigné est sélectionné sur tous les réseaux à accès multiple, il génère la LSA du réseau décrivant l’environnement local du réseau. Il joue également un rôle spécial dans l’algorithme de diffusion, puisque tous les routeurs du réseau synchronisent leurs bases de données d’état des liaisons en envoyant et en recevant des LSA à destination et en provenance du routeur désigné au cours du processus d’inondation.
Routeur désigné de sauvegarde Lorsque le DR actuel disparaît, un BDR est sélectionné sur les réseaux à accès multiple pour accélérer la transition des DR. Lorsque le routeur désigné de sauvegarde prend le relais, il n'a pas besoin de passer par le processus de contiguïté sur le réseau local (LAN). Le routeur désigné de sauvegarde permet également à l'algorithme d'inondation fiable de continuer en l'absence du routeur désigné avant que la disparition du routeur désigné ne soit détectée.
Prise en charge de réseaux à accès multiple sans diffusion Le protocole OSPF traite les réseaux, tels que les réseaux de données publics (PDN) Frame Relay, comme s’ils étaient des réseaux locaux. Cependant, des informations de configuration supplémentaires sont nécessaires pour que les routeurs connectés à ces réseaux se trouvent mutuellement.
Zones de gestion de configuration OSPF Le protocole OSPF permet de diviser les systèmes autonomes en zones. Cela fournit un niveau supplémentaire de protection du routage de sorte que le routage au sein d'une zone soit protégé de toutes les informations externes à la zone. En outre, en divisant un système autonome en zones, le coût de la procédure Dijkstra, en termes de cycles CPU, est réduit.
Liaisons virtuelles En autorisant la configuration des liaisons virtuelles, OSPF supprime les restrictions topologiques sur les dispositions de zone dans un système autonome.
Authentification des échanges de protocoles de routage Chaque fois qu’un routeur OSPF reçoit un paquet de protocole de routage, il peut éventuellement authentifier le paquet avant de le traiter plus avant.
Métrique de routage flexible Dans OSPF, les métriques sont attribuées aux interfaces de routeur sortantes. Le coût d'un chemin est la somme des interfaces de composants du chemin. La métrique de routage est, par défaut, dérivée de la bande passante de la liaison. Il peut être attribué par l'administrateur système pour indiquer toute combinaison de caractéristiques réseau telles que le délai, la bande passante et le coût.
Chemin multiple à coût égal Lorsque plusieurs routes à meilleur coût vers une destination existent, le protocole OSPF les trouve et les utilise pour charger le trafic de partage vers la destination.
Prise en charge de sous-réseaux de longueur variable Prend en charge les masques de sous-réseau de longueur variable en transportant un masque de réseau avec chaque destination annoncée.
Support de la zone de stub Pour prendre en charge les routeurs dont la mémoire est insuffisante, les zones peuvent être configurées en tant que stubs. Les LSA externes ne sont pas inondées dans et à travers les zones de stub. Le routage vers des destinations externes dans les zones de stub est basé uniquement sur la valeur par défaut.

Définitions de processus

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

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

Sur le plan graphique, ceci est illustré dans la figure ci-dessous.

ospf_a.gif

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

Propriétaire du processus

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

Objectifs du processus

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

L'objectif de ce processus est de fournir un cadre permettant de vérifier la configuration déployée d'une implémentation OSPF par rapport à une conception prévue et de fournir un mécanisme permettant d'auditer périodiquement le déploiement OSPF afin d'assurer la cohérence dans le temps par rapport à la conception prévue.

Indicateurs de performance du processus

Les indicateurs de rendement du processus servent à évaluer l'efficacité de la définition du processus. Les indicateurs de résultats devraient être mesurables et quantifiables. Les indicateurs de performance énumérés ci-dessous sont soit numériques, soit mesurés par le temps. Les indicateurs de performances du processus de gestion de configuration OSPF sont définis comme suit :

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

  • Fréquence d'exécution requise pour détecter de manière proactive les problèmes OSPF avant qu'ils n'affectent les utilisateurs.

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

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

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

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

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

  • L'arriéré des mesures correctives.

  • Temps d'arrêt attribué aux problèmes liés au protocole OSPF.

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

Entrées de processus

Les entrées de processus sont utilisées pour définir les critères et les conditions préalables d'un processus. Souvent, l'identification des entrées de processus fournit des informations sur les dépendances externes. Une liste des entrées relatives à la gestion de la configuration OSPF est fournie ci-dessous.

  • Documentation de conception OSPF

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

  • Informations Syslog

Sortie du processus

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

  • Rapports de configuration OSPF définis dans la section Présentation des données de ce document

  • Recommandations de configuration OSPF pour les actions correctives à effectuer

Définitions des tâches

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

Tâches d'initialisation

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

Vérifier les tâches requises

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

Tâche requise Description
Objectifs et apports des tâches
  1. Vérifiez que des documents de conception OSPF existent et que les informations suivantes sont facilement disponibles dans la documentation de conception du réseau :
    1. Définitions de zone : noms, plages d'adresses et type de zone
    2. Identifications ABR/ASBR
    3. Identifications DR/BDR
    4. Noeuds et interfaces Internet Registry (IR) affectés à des zones
  2. Utilisez un modèle de configuration standard SNMP pour vérifier que SNMP est configuré sur le réseau.

    Remarque : Cette option est utilisée ultérieurement comme entrée pour la création du fichier d'amorçage.

  3. Utilisez un modèle de configuration standard Syslog pour vérifier que Syslog est déployé sur le réseau.
Sortie de la tâche Le résultat de la tâche est un rapport d'état sur l'état des tâches prérequises. Si l'une des tâches d'assistance est jugée inefficace, le propriétaire du processus doit soumettre une demande de mise à jour des processus d'assistance. Si les processus d'appui ne peuvent pas être mis à jour, effectuez une évaluation de l'impact sur ce processus.
Rôle de tâche Ensemble de compétences de l'ingénieur réseau

Créer un fichier de démarrage

Le processus de gestion de la configuration OSPF nécessite l’utilisation d’un fichier d’amorçage pour supprimer la nécessité d’une fonction de détection de réseau. Le fichier d'amorçage enregistre l'ensemble des routeurs qui sont régis par le processus OSPF et est également utilisé comme point focal pour coordonner les processus de gestion des changements dans une organisation. Par exemple, si de nouveaux noeuds sont entrés dans le réseau, ils doivent être ajoutés au fichier de démarrage OSPF. Si des modifications sont apportées aux noms de communauté SNMP en raison de besoins de sécurité, ces modifications doivent être répercutées dans le fichier de démarrage. Le tableau ci-dessous décrit les processus de création d'un fichier d'amorçage.

Process Description
Objectifs de la tâche Créez un fichier de démarrage qui sera utilisé pour initialiser le logiciel de gestion de configuration OSPF. La mise en forme du fichier de démarrage 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 d'amorçage est défini par la conception du logiciel. Si un système de gestion de réseau (NMS) est utilisé, le format du fichier d'amorçage est défini par la documentation NMS.
Entrées de tâche
  1. Formater le fichier de démarrage.
  2. Utilisez la documentation de conception OSPF 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 connexion Telnet et CLI
  3. Planification et/ou noms de contact pour le processus de gestion des modifications du réseau.
Sorties de la tâche Fichier de démarrage pour le processus de gestion de la configuration OSPF.
Ressources de la tâche
  • Système NMS commercial
  • Système logiciel développé sur mesure
  • Processus manuel : connectez-vous à chaque élément du réseau, émettez des lignes de commande et enregistrez le résultat.
Rôle de tâche
  • NMS : ingénieur réseau, administrateur NMS et jeux de compétences de script NMS.
  • Scripts personnalisés : ingénieur réseau et jeux de compétences de script NMS.
  • Processus manuels : ingénieur réseau.

Tâches itératives

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

Tenir à jour le fichier de démarrage

Le fichier de démarrage est essentiel pour la mise en oeuvre efficace du processus de gestion de la configuration OSPF. Par conséquent, l'état actuel du fichier de démarrage doit être géré activement. Les modifications apportées au réseau qui affectent le contenu du fichier de démarrage doivent être suivies par le propriétaire du processus de gestion de la configuration OSPF.

Process Description
Objectifs de la tâche
  1. Tenir à jour le fichier d'amorçage grâce au suivi et aux interactions avec les fonctions organisationnelles qui contrôlent les déplacements, les ajouts, les modifications et/ou les modifications de configuration réseau.
  2. Tenir à jour le contrôle de version et de sauvegarde du fichier de démarrage.
Entrées de tâche
  1. Informations issues de la gestion des changements, telles que les déplacements, les ajouts et les modifications, qui affectent le contenu du fichier de démarrage.
  2. Informations issues de l'ingénierie/conception qui affectent le contenu du fichier de démarrage.
Sorties de la tâche
  1. Rapport hebdomadaire sur l'état de la devise du fichier d'amorçage.
  2. Définition et documentation décrivant l'emplacement et les procédures de restauration des sauvegardes de fichiers de démarrage.
Ressources de la tâche
  • Système NMS commercial
  • Système logiciel développé sur mesure
  • Processus manuel : connectez-vous à chaque élément du réseau, émettez des lignes de commande et enregistrez le résultat.
Rôle de tâche
  • NMS : ingénieur réseau, administrateur NMS et jeux de compétences de script NMS.
  • Scripts personnalisés : ingénieur réseau et jeux de compétences de script NMS.
  • Processus manuels : ingénieur réseau.

Exécuter l'analyse OSPF

Les deux étapes utilisées pour exécuter l'analyse OSPF sont les suivantes :

  1. Collecte des données.

  2. Analyse des données.

En fonction de l'utilisation du processus, la fréquence de ces deux étapes varie. Par exemple, ce processus peut être utilisé pour vérifier les modifications apportées à l'installation. Dans ce cas, la collecte des données s'exécute avant et après la modification, et l'analyse des données est effectuée après la modification pour déterminer la réussite de la modification.

Si ce processus est utilisé pour vérifier les enregistrements de conception de gestion de configuration OSPF, la fréquence de collecte et d'analyse des données dépend du taux de changement dans le réseau. Par exemple, s’il y a un changement important dans le réseau, les vérifications de conception sont effectuées une fois par semaine. Si le réseau est très peu modifié, les vérifications de conception ne sont effectuées qu’une fois par mois.

Examiner les rapports OSPF

Le format des rapports de gestion de configuration OSPF dépend des ressources utilisées pour mettre en oeuvre le processus de gestion de configuration OSPF. Le tableau ci-dessous propose des formats de rapport personnalisés.

Rapport Format
Entrées de tâche Pour les rapports de gestion de configuration OSPF, consultez la section Présentation des données de ce document.
Sorties de la tâche Si des problèmes sont détectés entre les rapports d'analyse et les enregistrements de conception logique, une décision doit être prise quant à l'élément correct et à l'élément incorrect. L'élément incorrect doit être corrigé. Cela peut impliquer une modification des enregistrements de conception ou un ordre de modification du réseau.
Ressources de la tâche
  • Système NMS commercial
  • Système logiciel développé sur mesure
  • Manual : connectez-vous à chaque élément du réseau et émettez des lignes de commande et enregistrez le résultat
Rôle de tâche
  • NMS : ingénieur réseau, administrateur NMS et jeux de compétences de script NMS.
  • Scripts personnalisés : ingénieur réseau et jeux de compétences de script NMS.
  • Processus manuels : ingénieur réseau.

Identification des données

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

Le tableau suivant décrit les données pouvant être appliquées à la gestion de configuration OSPF.

Données Description
Zones OSPF Les informations qui décrivent les zones connectées du routeur sont les suivantes :
  • ID de zone
  • Authentification de zone
  • Exécutions SPF
  • Nombre de routeurs ABR dans une zone
  • Nombre de routeurs ASBR dans une zone
  • Nombre de LSA de zone - Cohérence entre les routeurs d’une zone
  • Somme de contrôle LSA de zone : cohérence entre les routeurs de la zone
  • Fréquence des rejets de paquets en raison d’erreurs d’adressage par zone
  • Fréquence des rejets de paquets de protocole par le processus de routage par zone
  • Fréquence des rejets de paquets routés en raison de la condition no route found par zone
Interfaces OSPF Décrit une interface du point de vue du protocole OSPF, telle que :
  • Adresse IP
  • ID de zone
  • Statut administratif
  • Mesures OSPF attribuées à l’interface
  • Minuteurs OSPF affectés à l’interface
  • État OSPF
État de voisinage OSPF Décrit un voisin OSPF.
  • ID de routeur voisin
  • État voisin
  • Événements de voisinage : nombre de fois où la relation de voisinage a changé d'état ou qu'une erreur s'est produite.
  • Neighbor retransmission queue : longueur actuelle de la file d'attente de retransmission.

Identification des données SNMP

Cisco prend actuellement en charge la MIB leavingcisco.com RFC 1253 OSPF version 2 . Le document RFC 1253 ne contient pas de définitions de déroutement SNMP pour le protocole OSPF. La dernière version de la MIB OSPF est RFC 1850 OSPF Version 2 leavingcisco.com . Les déroutements SNMP sont définis pour OSPF dans RFC 1850. Le RFC 1850 n'est pas pris en charge par Cisco dans la mise en oeuvre de la MIB OSPF.

Pour plus d'informations, reportez-vous à la section SNMP Polling Data de ce document.

Reportez-vous à la page Logiciel de gestion de réseau Cisco pour obtenir une liste définitive des MIB prises en charge sur quelle plate-forme et quelle version de code.

Identification des données RMON

Aucune donnée spécifique RMON n'est requise pour cette procédure.

Identification des données Syslog

En général, Syslog génère des messages spécifiques à un service pour différentes technologies. Bien que les informations Syslog soient plus appropriées pour la gestion des pannes et des performances, les informations fournies ici constituent une référence. Pour obtenir un exemple d'informations Syslog OSPF générées par les périphériques Cisco, consultez Messages d'erreur OSPF.

Pour obtenir une liste complète des messages système par installation, reportez-vous à Messages et procédures de récupération.

Identification des données de la CLI de Cisco IOS

Dans cette version de la procédure de gestion de la configuration OSPF, aucune donnée CLI n'est requise.

Collecte de données

Collecte de données SNMP

Le tableau ci-dessous définit les différents composants de la collecte de données SNMP.

Composant de données SNMP Définition
Configuration générale de SNMP Référez-vous à Configuration de SNMP pour des informations générales sur les meilleures pratiques de configuration SNMP.
Configuration SNMP spécifique au service Aucune configuration SNMP spécifique au service n'est requise pour cette procédure.
Configuration MIB SNMP Voir la section Identification des données ci-dessus.
collection d'interrogation MIB SNMP Les données collectées par SNMP sont collectées par un système commercial tel que hp OpenView leavingcisco.com ou par des scripts personnalisés. Pour plus d'informations sur les algorithmes de collecte, consultez la section Exemple d'algorithmes de collecte de données de ce document.
collection de déroutements MIB SNMP La version actuelle de la MIB OSPF prise en charge sur les périphériques Cisco ne prend pas en charge les déroutements SNMP. Aucune interruption SNMP n'est requise pour cette procédure.

Collecte de données RMON

Cette version de la procédure ne nécessite aucune configuration et donnée RMON.

Collecte de données Syslog

Les directives générales de configuration Syslog ne sont pas incluses dans ce document. Référez-vous à Configuration et dépannage du pare-feu Cisco Secure PIX Firewall avec un seul réseau interne pour plus d'informations.

Les exigences spécifiques au protocole OSPF sont traitées en configurant le routeur OSPF pour enregistrer les modifications de voisinage à l’aide d’un message syslog à l’aide de la commande suivante :

OSPF_ROUTER(config)# ospf log-adj-changes

Collecte de données de l'interface CLI de Cisco IOS

En règle générale, l’interface de ligne de commande de Cisco IOS fournit l’accès le plus direct aux informations brutes contenues dans le NE. Cependant, l'accès CLI est mieux adapté aux procédures de dépannage et aux activités de gestion des modifications qu'à la gestion globale de la configuration telle que définie par cette procédure. L'accès via l'interface de ligne de commande ne s'adapte pas à la gestion d'un grand réseau. Dans ces cas, un accès automatisé à l'information est nécessaire.

Dans cette version de la procédure de gestion de la configuration OSPF, aucune configuration CLI et aucune donnée n'est requise.

Présentation des données

Rapport de zone OSPF

Voici un exemple de format pour le rapport de zone OSPF. Le format du rapport est déterminé par les capacités d'un NMS commercial, si un est utilisé, ou par la sortie conçue des scripts personnalisés.

Zone Champs de données Dernière exécution Cette exécution
ID de zone 1 Authentification    
Exécutions SPF    
Nombre ABR    
Nombre ASBR    
Nombre de LSA    
Somme de contrôle LSA    
Erreurs d'adresse    
Rejets de routage    
Aucune route trouvée    
ID de zone n° Authentification    
Exécutions SPF    
Nombre ABR    
Nombre ASBR    
Nombre de LSA    
Somme de contrôle LSA    
Erreurs d'adresse    
Rejets de routage    
Aucune route trouvée    

Rapport d'interface OSPF

Voici un exemple de format pour le rapport d'interface OSPF. Dans la pratique, le format du rapport est déterminé par les capacités d'un NMS commercial, s'il est utilisé, ou par la sortie conçue des scripts personnalisés.

Zone Périphérique Interface Champs de données Dernière exécution Cette exécution
ID de zone 1 ID de noeud 1 ID d'interface n° 1 Adresse IP    
ID de zone    
État de l'administration    
État OSPF    
Mesures/Coût/Temporisation    
ID d'interface n° Adresse IP    
ID de zone    
État de l'administration    
État OSPF    
Mesures/Coût/Temporisation    
ID de noeud n° ID d'interface n° 1 Adresse IP    
ID de zone    
État de l'administration    
État OSPF    
Mesures/Coût/Temporisation    
ID d'interface n° Adresse IP    
ID de zone    
État de l'administration    
État OSPF    
Mesures/Coût/Temporisation    
ID de zone n° ID de noeud 1 ID d'interface n° 1 Adresse IP    
ID de zone    
État de l'administration    
État OSPF    
Mesures/Coût/Temporisation    
ID d'interface n° Adresse IP    
ID de zone    
État de l'administration    
État OSPF    
Mesures/Coût/Temporisation    
ID de noeud n° ID d'interface n° 1 Adresse IP    
ID de zone    
État de l'administration    
État OSPF    
Mesures/Coût/Temporisation    
ID d'interface n° Adresse IP    
ID de zone    
État de l'administration    
État OSPF    
Mesures/Coût/Temporisation    

Rapport de voisinage OSPF

Voici un exemple de format pour le rapport de voisinage OSPF. Dans la pratique, le format du rapport est déterminé par les capacités d'un NMS commercial, s'il est utilisé, ou par la sortie conçue des scripts personnalisés.

Zone Périphérique Voisins Champs de données Dernière exécution Cette exécution
ID de zone 1 ID de noeud 1 ID de voisin 1 ID de routeur    
Adresse IP du routeur    
Province    
Événements    
Retrans Que    
ID de voisin n° ID de routeur    
Adresse IP du routeur    
Province    
Événements    
Retrans Que    
ID de noeud n° ID de voisin 1 ID de routeur    
Adresse IP du routeur    
Province    
Événements    
Retrans Que    
ID de voisin n° ID de routeur    
Adresse IP du routeur    
Province    
Événements    
Retrans Que    
ID de zone n° ID de noeud 1 ID de voisin 1 ID de routeur    
Adresse IP du routeur    
Province    
Événements    
Retrans Que    
ID de voisin n° ID de routeur    
Adresse IP du routeur    
Province    
Événements    
Retrans Que    
ID de noeud n° ID de voisin 1 ID de routeur    
Adresse IP du routeur    
Province    
Événements    
Retrans Que    
ID de voisin n° ID de routeur    
Adresse IP du routeur    
Province    
Événements    
Retrans Que    

Outils de surveillance de l'Internet public et commercial

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

Aucun outil de surveillance Internet public ou commercial n’est connu pour prendre en charge la gestion de la configuration OSPF telle que définie par cette procédure. Par conséquent, des scripts et des procédures personnalisés locaux sont requis.

Données d'interrogation SNMP

Table de routage RFC 1213 leavingcisco.com

Nom d'objet Description d'objet
ipRouteDest Adresse IP de destination de la route. Une entrée dont la valeur est 0.0.0.0 est considérée comme une route par défaut. Plusieurs routes vers une seule destination peuvent apparaître dans le tableau, mais l’accès à ces entrées multiples dépend des mécanismes d’accès à la table définis par le protocole de gestion de réseau utilisé. ::= { ipRouteEntry 1 } identificateur d'objet = 1.3.6.1.2.1.4.21.1.1
ipRouteMask Indique que le masque est logique avec l'adresse de destination avant d'être comparé à la valeur du champ ipRouteDest. Pour les systèmes qui ne prennent pas en charge des masques de sous-réseau arbitraires, un agent construit la valeur de ipRouteMask en déterminant si la valeur du champ ipRouteDest correspondant appartient à un réseau de classe A, B ou C, en utilisant l'un des réseaux de masque suivants :
  • Classe A = 255.0.0.0
  • Classe B = 255.255.0.0
  • Classe C = 255.255.255.0
Si la valeur de ipRouteDest est 0.0.0.0, la route par défaut, la valeur du masque est également 0.0.0.0.

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

::= { ipRouteEntry 11 } identificateur d'objet = 1.3.6.1.2.1.4.21.1.11
ipRouteNextHop Adresse IP du tronçon suivant de cette route. Dans le cas d'une route liée à une interface réalisée avec un support de diffusion, la valeur de ce champ est l'adresse IP de l'agent sur l'interface. ::= { ipRouteEntry 7 } identificateur d'objet = 1.3.6.1.2.1.4.21.1.7
ipRouteIfIndex Valeur d'index qui identifie de manière unique l'interface locale par laquelle le tronçon suivant de la route est atteint. Cette interface est la même que celle identifiée par la valeur IfIndex. ::= { ipRouteEntry 2 } identificateur d'objet = 1.3.6.1.2.1.4.21.1.2

RFC 1213 Objets divers

Nom d'objet Description d'objet
ipAdEntIfIndex Valeur d'index qui identifie de manière unique l'interface applicable à l'entrée. Cette interface est la même que celle identifiée par la valeur IfIndex. ::= { ipAddrEntry 2 } identificateur d'objet = 1.3.6.1.2.1.4.20.1.2
ipInAddrErrors Nombre de datagrammes d'entrée ignorés, car l'adresse IP dans leur en-tête IP était un champ de destination non valide pour l'entité. Ce nombre inclut les adresses non valides (0.0.0.0) et les adresses de classe non prises en charge (classe E). Pour les entités qui ne sont pas des passerelles IP et ne transmettent pas de datagrammes, le compteur inclut les datagrammes ignorés car l'adresse de destination n'était pas une adresse locale. { ip 5 } identificateur d'objet = 1.3.6.1.2.1.4.5
ipRoutingDiscards Nombre d'entrées de routage valides ignorées. Une raison possible pour rejeter une telle entrée est de libérer de l'espace tampon pour d'autres entrées de routage. { ip 23 } identificateur d'objet = 1.3.6.1.2.1.4.23
ipOutNoRoutes Nombre de datagrammes IP ignorés car aucune route n'a pu être trouvée pour les transmettre à leur destination. { ip 12 } identificateur d'objet = 1.3.6.1.2.1.4.12

Table de zone OSPF RFC 1253 leavingcisco.com

Nom d'objet Description d'objet
ospfAreaID Entier 32 bits identifiant une zone de manière unique. L'ID de zone 0.0.0.0 est utilisé pour le backbone OSPF. ::= { ospfAreaEntry 1 } identificateur d'objet = 1.3.6.1.2.1.14.2.1.1
ospfAuthType Type d'authentification spécifié pour cette zone. D'autres types d'authentification peuvent être attribués localement par zone. La valeur par défaut est 0. ::= { ospfAreaEntry 2 } identificateur d'objet = 1.3.6.1.2.1.14.2.1.2
ExécutionsSpfOspf Nombre de fois où la table de routage intra-zone a été calculée à l'aide de la base de données d'état des liaisons de cette zone. identificateur d'objet = 1.3.6.1.2.1.14.2.1.4
ospfAreaBdrRtrCount Nombre total d'ABR accessibles dans cette zone. Il s'agit initialement de 0, la valeur par défaut, et est calculé dans chaque passe SPF. ::= { ospfAreaEntry 5 } identificateur d'objet = 1.3.6.1.2.1.14.2.1.5
ospfASBdrRtrCount Nombre total d'ABSR accessibles dans cette zone. Il s'agit initialement de 0 (valeur par défaut) et est calculé dans chaque passe SPF. ::= { ospfAreaEntry 6 } identificateur d'objet = 1.3.6.1.2.1.14.2.1.6
ospfAreaLSACount Nombre total de LSA dans la base de données d'état des liaisons d'une zone, à l'exclusion des LSA externes. La valeur par défaut est 0. ::= { ospfAreaEntry 7 } identificateur d'objet = 1.3.6.1.2.1.14.2.1.7
ospfAreaLSACksumSomme Somme non signée de 32 bits des sommes de contrôle LS de la LSA contenues dans la base de données d'état des liaisons de la zone. Cette somme exclut les LSA externes (LS de type 5). La somme peut être utilisée pour déterminer s'il y a eu une modification dans la base de données d'état des liaisons d'un routeur et pour comparer la base de données d'état des liaisons de deux routeurs. La valeur par défaut est 0. ::= { ospfAreaEntry 8 } identificateur d'objet = 1.3.6.1.2.1.14.2.1.8

Table d'interface OSPF RFC 1253

Nom d'objet Description d'objet
OspfIfIpAddress Adresse IP de l'interface OSPF. identificateur d'objet = 1.3.6.1.2.1.14.7.1.1
OspfIfEvents Nombre de fois où l'interface OSPF a changé d'état ou qu'une erreur s'est produite. identificateur d'objet = 1.3.6.1.2.1.14.7.1.15
OspfIfState État de l'interface OSPF. identificateur d'objet = 1.3.6.1.2.1.14.7.1.12

Table de voisinage OSPF RFC 1253

Nom d'objet Description d'objet
AdresseIpNbrOspf Adresse IP de ce voisin. ::= { ospfNbrEntry 1 } identificateur d'objet = 1.3.6.1.2.1.14.10.1.1
ospfNbrAdresseMoinsIndex Valeur correspondante de IfIndex dans la MIB standard Internet sur un index qui ne possède pas d'adresse IP. Lors de la création d'une ligne, cela peut être dérivé de l'instance. ::= { ospfNbrEntry 2 } identificateur d'objet = 1.3.6.1.2.1.14.10.1.2
ospfNbrRtrId Entier de 32 bits, représenté comme adresse IP, identifiant de manière unique le routeur voisin dans le système autonome. La valeur par défaut est 0.0.0.0. ::= { ospfNbrEntry 3 } identificateur d'objet = 1.3.6.1.2.1.14.10.1.3
ospfNbrState État de la relation avec le voisin. Les États sont les suivants :
  • (1)
  • tentative (2)
  • init (3)
  • bidirectionnel (4)
  • exchangeStart (5)
  • échange (6)
  • chargement (7)
  • complet (8)
::= { ospfNbrEntry 6 } identificateur d'objet = 1.3.6.1.2.1.14.10.1.6
ospfNbrEvents Nombre de fois où la relation de voisinage a changé d'état ou qu'une erreur s'est produite. La valeur par défaut est 0. ::= { ospfNbrEntry 7 } identificateur d'objet = 1.3.6.1.2.1.14.10.1.7
ospfNbrLSRetransQLen Longueur actuelle de la file d'attente de retransmission. La valeur par défaut est 0. ::= { ospfNbrEntry 8 } identificateur d'objet = 1.3.6.1.2.1.14.10.1.8

Exemples d'algorithmes de collecte de données

Au cours de l'étude de cet article, un programme prototype de C a été élaboré. Le programme, appelé oscan, a été écrit à l'aide de Microsoft Developer Studio 97 avec Visual C++ version 5.0. Il existe deux bibliothèques spécifiques qui fournissent l'interface de programmation d'application de fonction SNMP (API). Ces bibliothèques sont snmpapi.lib et mgmtapi.lib

Les fonctions fournies par l'API Microsoft sont regroupées en trois grandes catégories et sont répertoriées dans le tableau ci-dessous.

Fonctions de l'agent Fonctions du gestionnaire Fonctions de l'utilitaire
SnmpExtensionInit SnmpExtensionInitEx SnmpExtensionQuery SnmpExtensionTrap SnmpMgrFermer SnmpMgrGetTrap SnmpMgrOidToStrSnmpMgrOuvrir SnmpMgrRequest SnmpMgrStorToOid SnmpMgrTrapListen SnmpUtilMemAlloc SnmpUtilMemFree SnmpUtilMemReAlloc SnmpUtilOidAppend SnmpUtilOidCmp SnmpUtilOidCpy SnmpUtilOidOidFree SnmpUtilOidNCSnmpUPrintAsmp nSnmpUtilVarBindCpy SnmpUtilVarBindListCpy SnmpUtilVarBindFree SnmpUtilVarBindListFree

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

  • snmpWalkStrOid

  • snmpWalkAsnOid

  • snmpWalkVarBind

  • snmpWalkVarBindList

Ces fonctions fournissent une API générique qui permet d'accéder aux différentes tables MIB SNMP utilisées pour gérer les données de configuration OSPF. L'identificateur d'objet (OID) de la table à accéder est transmis à l'API oscan avec une fonction de rappel spécifique à la table. La fonction de rappel a l'intelligence d'agir sur les données retournées par les tables.

Routine principale

La première tâche consiste à établir une liste de noeuds qui seront la cible du programme oscan. Afin d'éviter le problème de « détection de périphérique », un fichier d'amorçage est nécessaire pour identifier les noeuds à analyser. Le fichier d'amorçage fournit des informations telles que l'adresse IP et les chaînes de communauté SNMP en lecture seule.

Le programme oscan doit gérer plusieurs structures de données internes pour stocker les informations SNMP collectées à partir des routeurs. En général, il existe 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 routage IP

Il faut être prudent lors de l'accès à la table de routage IP avec SNMP, car il est simple de surcharger le processeur d'un routeur pendant cette opération. Par conséquent, le programme oscan utilise un paramètre de délai configurable par l'utilisateur. Le paramètre fournit un délai entre chaque requête SNMP. Dans les grands environnements, cela signifie que la durée totale de collecte des informations peut être très importante.

La table de routage contient quatre informations qui intéressent l’analyseur :

  • ipRouteDest

  • ipRouteMask

  • ipRouteNextHop

  • ipRouteIfIndex

La table de routage est indexée par ipRouteDest. Par conséquent, chaque objet retourné à partir de la demande SNMP get-request a l'ipRouteDest ajouté à l'OID.

L'objet ipRouteIfIndex est un entier qui s'indexe dans la table d'adresses IP (ipAddrTable). ipAddrTable est indexé à l'aide de l'objet ipAdEntAddr (adresse IP de l'interface). Pour obtenir l’adresse IP de l’interface, un processus en quatre étapes est requis :

  1. Collectez ipRouteIfIndex dans la table de routage.

  2. Accédez à ipAddrTable à l'aide de ipRouteIfIndex pour la correspondance de modèles.

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

  4. Rangez l’adresse IP de l’interface dans la table de routage IP.

L’algorithme général d’accès à la table de routage IP est présenté ci-dessous. À ce stade, seule la valeur entière de ipRouteIfIndex est stockée. Plus tard dans le processus, lors de la collecte des informations d'interface, ipAddrTable est accessible et les informations restantes sont collectées et placées dans la table de routage 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 aux informations de sortie familières de l’interface de ligne de commande du routeur 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

Table de zones OSPF

La collecte d'informations à partir de la table de zones OSPF s'effectue en analysant la table de zones OSPF (ospfAreaTable) et en traitant les données lors de leur retour. L'index de ospfAreaTable est le osfpAreaId. ospfAreaId est stocké au format décimal à point, identique à une adresse IP. Par conséquent, les sous-routines utilisées pour traiter et rechercher ipRouteTable et ipRouteIfIndex peuvent être réutilisées ici.

Plusieurs éléments de données qui ne figurent pas dans la table de zones OSPF sont inclus dans cette section. Par exemple, les objets ipInAddrErrors, IpRoutingDiscards et ipOutNoRoute se trouvent dans la définition MIB-2, mais ne sont pas associés à une zone OSPF. Ces objets sont associés à un routeur. Par conséquent, ces compteurs sont utilisés comme métrique de zone en ajoutant les valeurs de chaque noeud d'une zone à un compteur de zone. Par exemple, dans le rapport de zone OSPF, le nombre de paquets rejetés en raison de l'absence de route trouvée est en fait la somme des paquets rejetés par tous les routeurs de cette zone. Il s'agit d'une métrique de haut niveau qui fournit une vue générale de l'état du 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 recueillies sont représentées dans le tableau 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 de voisinage OSPF

L'index de la table de voisinage est de deux valeurs :

  • ospfNbrIpAddr : ospfNbrIpAddr est l'adresse IP du voisin.

  • ospfNbrAddressLessIndex—ospfNbrAddressLessIndex peut être l'une des deux valeurs suivantes :

    • Pour une interface à laquelle une adresse IP est attribuée, elle est égale à zéro.

    • Pour une interface qui n'a pas d'adresse IP affectée, elle est interprétée comme IfIndex de la MIB standard Internet.

Comme il existe deux valeurs pour l'index, vous devez ajuster les algorithmes utilisés précédemment pour les informations supplémentaires ajoutées aux OID retournés. Après cet ajustement, les mêmes sous-routines qui ont été utilisées pour traiter et rechercher ipRouteTable et ipRouteIfIndex peuvent être réutilisées 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 recueillies sont représentées dans le tableau 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

Ce document vous est-il utile?

FeedbackCommentaires

Contacter Cisco

Ce document s’applique à ces produits