IP : Protocole OSPF (Open Shortest Path First)

Dépannage complexe de message d'erreur OSPF

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

Introduction

Ce document décrit comment dépanner les messages d'erreur de Protocole OSPF (Open Shortest Path First) qui sont produits dans des exploitations réseau normales et pourraient dégrader la connexion réseau.

Contribué par Mohamed Muddasir Khan, ingénieur TAC Cisco.

Conditions préalables

Conditions requises

Cisco recommande que vous ayez la connaissance des principes fondamentaux OSPF.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Informations générales

Le protocole OSPF est un Protocole IGP (Interior Gateway Protocol) largement déployé dans l'entreprise et les réseaux du fournisseur de service.

Ce protocole était dû développé à un besoin à la communauté Internet d'introduire une à fonctionnalité élevée, IGP non-de propriété industrielle pour la famille de protocole TCP/IP. Des discussions pour la création d'un IGP interopérable commun pour l'Internet commencé en 1988 et n'ont pas été formalisées jusqu'en 1991. À ce moment-là, le groupe de travail OSPF a demandé que l'OSPF soit considéré comme pour que l'avancement dessinant la norme Internet.

Le protocole OSPF est basé sur le technologie basée sur l'état des liaisons, qui est un départ aux algorithmes basés sur vecteur de Bellman-Ford qui sont utilisés dans les protocoles de routage traditionnels d'Internet, tels que le Protocole RIP (Routing Information Protocol).

Problèmes

Cette section décrit trois questions OSPF qui pourraient dégrader la connexion réseau.

Question 1

Vous recevez le message d'erreur OSPF-4-FLOOD_WAR. La guerre d'inondation OSPF se produit quand le routeur reçoit à plusieurs reprises sa propre publicité d'État de lien (LSA) et la vide du réseau ou envoie une nouvelle version de elle. Ceci est censé pour détecter des questions avec le type-2 LSAs quand les adresses IP en double sont présentes dans le réseau, ou avec Type-5 LSAs quand il y a un ID de routeur en double dans différentes zones OSPF.

Dans un scénario typique, il y a un routeur dans le réseau qui lance le LSA et un deuxième routeur qui vide le LSA.

Cette image illustre les événements d'origines et d'annulation entre les premiers et deuxièmes Routeurs (R1 Désigné et R2, respectivement) :

Issue 2

Vous recevez le message d'erreur %OSPF-4-CONFLICTING_LSAID. Ce message d'erreur indique qu'une origine LSA était due empêché à un conflit avec un LSA de courant qui a le même ID d'État de lien mais un masque de sous-réseau différent.

L'algorithme dans RFC 2328, l'annexe E est utilisé afin de résoudre des conflits quand plusieurs LSAs avec le même préfixe et différents masques sont annoncés. Quand cet algorithme est utilisé, et les routes hôte sont annoncées, il y a des situations où la résolution de conflits est impossible et la route hôte ou le préfixe qui est en conflit n'est pas annoncée.

Voici un extrait d'exemple du message d'erreur :

%OSPF-4-CONFLICTING_LSAID: LSA origination prevented by existing LSA with same LSID
but a different mask

Existing Type 5 LSA: LSID 192.168.1.0/31
New Destination: 192.168.1.0/32

Question 3

Vous configurez l'OSPF afin d'utiliser la caractéristique rapide de paquets de bonjour, qui entraîne la CPU de haute. Le soutien OSPF de la caractéristique rapide de paquets de bonjour permet à des configurations tels que bonjour les paquets sont introduits les intervalles moins d'une seconde. Ces types de configurations ont comme conséquence une convergence plus rapide dans un réseau OSPF.

Cette commande est utilisée afin de placer l'intervalle pendant lequel au moins un bonjour paquet doit être reçu, ou le voisin est considéré vers le bas :

ip ospf dead-interval minimal hello-multipliermultiplier

Voici un exemple :

Router(config-if)# ip ospf dead-interval minimal hello-multiplier 5

Dans cet exemple, le soutien OSPF des paquets Fast bonjour est activé avec la spécification du mot clé minimal, du mot clé de hello-multiplier, et de la valeur. Puisque le multiplicateur est placé à 5, cinq bonjour paquets sont envoyés chaque seconde.

Solutions

Cette section décrit quelques solutions possibles aux problèmes qui sont décrits dans la section précédente.

Solution de la question 1

Il est important que vous comprenniez le message d'erreur pendant les tentatives de dépanner des messages de guerre d'inondation. Les messages apparaissent différemment sur les Routeurs d'origines et d'annulation. Pour cette raison, il est crucial de se concentrer sur le type LSA pour lequel le message de guerre d'inondation est signalé, car chaque type LSA est dépanné différemment.

Voici un extrait d'exemple du message de guerre d'inondation OSPF :

%OSPF-4-FLOOD_WAR: Process 1 re-originates LSA ID 172.16.254.25 type-2 adv-rtr
172.16.253.1 in area 0

%OSPF-4-FLOOD_WAR: Process 1 flushes LSA ID 172.16.254.25 type-2 adv-rtr
172.16.253.1 in area 0

Voici les composants de message décrits :

  • Processus ? C'est le processus OSPF qui signale l'erreur.

  • re-commence ou des annulations ? Ceci indique si ce routeur commence ou vide le LSA.

  • ID LSA ? C'est l'ID LSA pour lequel la guerre d'inondation est détectée.

  • Type ? C'est le type LSA.

    Remarque: La guerre d'inondation pour chaque LSA a une cause principale différente.

  • adv-rtr ? C'est le routeur de la publicité qui lance le LSA.

  • Zone ? C'est la zone à laquelle le LSA appartient.

Type-2 LSAs

Remarque: Référez-vous à RFC 2328 (chapitre 13.4, affaire 3) pour information les informations complémentaires si la guerre d'inondation est imprimée pour un LSA de type-2.

Si un routeur reçoit un LSA de réseau de type-2 dont l'ID LSA est identique que l'adresse IP pour une des interfaces qui sont associées avec ce routeur, alors le routeur devrait vider le LSA. La cause principale dans ce scénario est les adresses IP en double sur les Routeurs d'origines et d'annulation.

Afin de résoudre ce problème, modifiez l'adresse IP sur une des interfaces ou de l'arrêt l'interface qui a l'adresse IP en double.

Remarque: Ceci vérifient les adresses IP en double est exécuté sur les interfaces qui sont en baisse aussi bien. L'interface doit être en mode d'admin-vers le bas afin de sauter le contrôle. Dans des quelques cas faisants le coin, la guerre d'inondation est également signalée pour une interface administrativement arrêtée, ainsi la solution permanente est de retirer les adresses IP en double dans le réseau.

Type-3 LSAs

Il est rare de rencontrer des questions de guerre d'inondation pour un LSA Type-3. Des messages d'erreur de guerre d'inondation pour Type-3 LSAs ont été enregistrés dans les scénarios dans lesquels l'IP de sous-réseau d'un lien fortement de battement est propagé dans le domaine OSPF.

Cisco recommande que vous ouvriez une valise de support avec le centre d'assistance technique Cisco (TAC) si vous rencontrez des questions de guerre d'inondation dues à Type-3 LSAs.

Type-5 LSAs

Les guerres d'inondation dues à Type-5 LSAs se produisent quand il y a des id en double de routeur sur les Routeurs qui se trouvent dans différentes zones. Il est obligatoire de changer l'ID de routeur sur un des Routeurs.

Un autre exemple des guerres de l'inondation Type-5 est quand il y a deux Routeurs qui font redistribuer la même déclaration de réseau de Protocole BGP (Border Gateway Protocol) et aux deux Routeurs ces réseaux BGP dans l'OSPF. Si l'un ou l'autre de ces routeurs BGP accède le réseau par l'OSPF, alors une guerre d'inondation OSPF due à un LSA Type-5 est signalée.

En résumé, assurez-vous que les id de routeur ne sont pas identiques, et la redistribution correcte de LSAs externe devrait empêcher des questions de guerre d'inondation dues à Type-5 LSAs.

Solution d'Issue 2

La mesure initiale que vous devriez prendre avec des tentatives de résoudre le message d'erreur OSPF-CONFLICTING_LSAID est de localiser le préfixe qui n'est pas annoncé aussi bien que le préfixe qui est en conflit.

Afin de localiser ces derniers, sélectionnez le show ip route et les commandes de show ip ospf database dans le CLI. L'administrateur doit dépister l'origine de la nouvelle destination : 192.168.1.0/32, suivant les indications de l'exemple de cas décrit dans la section d'Issue 2, et corrigent le masque de sous-réseau du réseau.

Le cas habituel d'id étés en conflit LSA est enregistré après un changement récent dans l'OSPF et est résolu après que vous corrigiez la configuration de masques de sous-réseau dans les déclarations de réseau OSPF.

Solution de la question 3

Les caisses élevées CPU sont enregistré avec Cisco TAC quand les clients déploient OSPF Hellos rapide sur des Commutateurs de gamme de Cisco Catalyst.

Remarque: Cisco recommande que vous ne configuriez pas OSPF Hellos rapide.

Le Cisco IOS® fonctionne sur un modèle non préemptif, et la caractéristique rapide de paquet de bonjour exige que l'OSPF Hellos soit traité plus fréquemment que l'un-deuxième intervalle mort. Il pourrait y avoir des occasions que l'OSPF n'obtient pas les ressources exigées sur un système avec d'autres processus qui tient l'affiche. La personne à charge sur votre environnement et les autres protocoles et applications qui sont configurés sur le routeur, l'utilisation de cette capacité peut être problématique.

Le remplaçant du sub-second bonjour a été introduit par la détection bidirectionnelle d'expédition (BFD), où le BFD est développé pour la détection rapide de voisin vers le bas. Le BFD fonctionne en mode d'interruption et ne subit pas les problèmes qui sont observés avec OSPF Hellos rapide. Cisco recommande que vous utilisiez le BFD pour une convergence plus rapide.

Voici deux défauts connus dus à OSPF Hellos rapide :

  • ID de bogue Cisco CSCut14044 : Bonjour rapide 333msec WS-C3750X-48/OSPF/baisse de contiguïté/15.0(2)SE6

  • ID de bogue Cisco CSCsd17835 : les contiguïtés rapides de bonjour OSPF/hsrp s'agitent continuellement

Informations connexes



Document ID: 118880