Le protocole de routage OSPF (Open Shortest Path First) est défini par RFC 2328 OSPF Version 2 . 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.
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. |
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.
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.
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.
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.
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é.
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
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
Les sections suivantes définissent les tâches d'initialisation et d'itération associées à la gestion de la configuration OSPF.
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.
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 |
|
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 |
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 |
|
Sorties de la tâche | Fichier de démarrage pour le processus de gestion de la configuration OSPF. |
Ressources de la tâche |
|
Rôle de tâche |
|
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.
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 |
|
Entrées de tâche |
|
Sorties de la tâche |
|
Ressources de la tâche |
|
Rôle de tâche |
|
Les deux étapes utilisées pour exécuter l'analyse OSPF sont les suivantes :
Collecte des données.
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.
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 |
|
Rôle de tâche |
|
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 :
|
Interfaces OSPF | Décrit une interface du point de vue du protocole OSPF, telle que :
|
État de voisinage OSPF | Décrit un voisin OSPF.
|
Cisco prend actuellement en charge la MIB 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 . 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.
Aucune donnée spécifique RMON n'est requise pour cette procédure.
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.
Dans cette version de la procédure de gestion de la configuration OSPF, aucune donnée CLI n'est requise.
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 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. |
Cette version de la procédure ne nécessite aucune configuration et donnée RMON.
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
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.
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 |
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 |
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 |
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.
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 :
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 |
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 |
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 |
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 |
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 :
|
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 |
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.
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
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 :
Collectez ipRouteIfIndex dans la table de routage.
Accédez à ipAddrTable à l'aide de ipRouteIfIndex pour la correspondance de modèles.
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.
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
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
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