IP : Protocole OSPF (Open Shortest Path First)

OSPF comme PE-CE Protocol et techniques de Boucle-prévention dans l'exemple de configuration du VPN MPLS L3

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

Introduction

Ce document décrit les caractéristiques de prévention de boucle et les étapes de configuration minimale quand vous exécutez le protocole de routage de Protocole OSPF (Open Shortest Path First) entre le Provider Edge (PE) et les Routeurs de Customer Edge (CE). Il présente un scénario de réseau qui dépeint l'utilisation du bit de haut en bas (DN), qui est une option dans la balise de la publicité (LSA) et du domaine d'État de lien.

Contribué par Naveen Bansal et Rahul Kukreja, ingénieurs TAC Cisco

Conditions préalables

Conditions requises

Cisco recommande que vous ayez la connaissance d'une couche 3 VPN OSPF et de Commutation multiprotocole par étiquette (MPLS).

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 fournisseur de services (fournisseur de services) et les artères d'échange de routeur CE avec un protocole de routage d'accord sur lequel le fournisseur de services et et le client sont conjointement. La portée de ce document est de décrire le mécanisme de boucle-prévention quand OSPFv2 est utilisé.

Quand OSPFv2 est utilisé sur un lien PE-CE qui appartient à un Virtual Routing and Forwarding particulier (VRF) ou au VPN, le routeur PE :

  • Redistribue les artères reçues par l'intermédiaire de l'OSPF pour ce VPN dans le Multiprotocol Border Gateway Protocol (MP-BGP) et les annonce aux autres Routeurs de PE.
  • Redistribue les routes BGP intalled dans le VPN par l'intermédiaire de MP-BGP dans l'exemple OSPF pour ce VPN et les annonce aux Routeurs de la CE.

Configurez

Diagramme du réseau

Considérez cette topologie du réseau afin de comprendre les techniques de boucle-prévention.

Dans cette installation, il y a une possibilité d'une boucle. Par exemple, si CE1 annonce le type 1 LSA OSPF à PE1, qui redistribue l'artère dans VPNv4 et l'annonce à PE2, puis PE2 annonce consécutivement le LSA de résumé à CE2. Cette artère reçue par CE2 a pu être annoncée de nouveau à PE3. Le troisième routeur PE apprend l'artère OSPF, qui est meilleure que la route BGP, et re-annonce l'artère dans le BGP pendant que les gens du pays au site client 2. PE3 n'apprennent jamais que l'artère qui a été annoncée n'a pas été provenu du site client 2.

Afin de surmonter cette situation, quand les artères sont redistribuées de MP-BGP dans l'OSPF, puis elles sont identifiées par un DN mordu dans le type LSA 3, 5, ou 7 et ont la balise de domaine pour le type 5 et LSA 7.

Configurations

Voici la configuration d'échantillon sur des Routeurs de PE. Cette configuration inclut la configuration de VRF, le processus 2 OSPF qui fonctionne entre les Routeurs PE-CE, le Process 1 OSPF qui fonctionne comme Protocole IGP (Interior Gateway Protocol) dans le noyau MPLS, et la configuration MP-BGP.

Bit de DN

Le bit précédemment inutilisé dans le domaine d'options LSA OSPF désigné sous le nom du bit de DN. Ce bit est placé sur le type 3, LSA 5, et 7 quand les artères MP-BGP sont redistribuées dans l'OSPF. Quand l'autre routeur PE reçoit le LSA d'un type de routeur CE 3, LSA 5, ou 7 avec le positionnement de bit de DN, les informations de ce LSA ne sont pas utilisées dans le calcul d'artère OSPF.

Basé sur la topologie du réseau, PE2 place le bit de DN pour le LSA redistribué et ce LSA n'est jamais considéré pour le calcul d'artère dans le processus 2 OSPF sur PE3. Ainsi PE3 ne redistribue jamais cette artère de nouveau dans MP-BGP.

Voici un exemple de l'en-tête OSPF qui affiche le positionnement de bit de DN, quand l'artère a été annoncée par le routeur PE pour le LSA du type 3 :

Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: LS Update (4)
        Packet Length: 56
        Source OSPF Router: 10.10.23.3 (10.10.23.3)
        Area ID: 0.0.0.0 (0.0.0.0) (Backbone)
        Checksum: 0x4034 [correct]
        Auth Type: Null (0)
        Auth Data (none): 0000000000000000
    LS Update Packet
        Number of LSAs: 1
        Summary-LSA (IP network)
            .000 1110 0001 0000 = LS Age (seconds): 3600
            0... .... .... .... = Do Not Age Flag: 0
            Options: 0xa2 (DN, DC, E)
                1... .... = DN: Set
                .0.. .... = O: Not set
                ..1. .... = DC: Demand Circuits are supported
                ...0 .... = L: The packet does NOT contain LLS data block
                .... 0... = NP: NSSA is NOT supported
                .... .0.. = MC: NOT Multicast Capable
                .... ..1. = E: External Routing Capability
                .... ...0 = MT: NO Multi-Topology Routing

Balise de domaine

La balise de domaine s'applique seulement pour le LSA du type 5 et du type 7 OSPF. Quand les artères VPNv4 sont redistribuées de MP-BGP dans l'OSPF sur le routeur PE, la balise de domaine est placée pour les artères externes OSPF. La balise pourrait ou être manuallly placée avec la commande de domain-tag sous le processus OSPF ou une valeur 32 bits peut être automatiquement générée :

Basé sur la topologie du réseau, PE2 place la balise de domaine pour le LSA du type 5 et du type 7 quand il redistribue l'artère VPNv4 dans l'OSPF. Ce LSA n'est jamais considéré pour le calcul d'artère parce que le bit de DN est déjà placé, mais il fait également placer la balise de domaine, ainsi le LSA est ignoré parce que les correspondances de balise de domaine la balise VPN/VRF. Par conséquent l'artère n'est jamais redistribuée dans l'OSPF.

Cet exemple affiche que le type 5 LSA ignoré quand il est reçu avec la balise de domaine placez les mêmes que la balise locale de domaine de VRF sur PE3 de CE3 :

*Jan 31 00:29:23.947: OSPF-2 EXTER:  adv_rtr 10.10.57.5, age 3, seq 0x80000001, 
metric 10, metric-type 2, fw-addr 0.0.0.0
*Jan 31 00:29:23.947: OSPF-2 EXTER: Tag equals to VPN Tag, ignoring the LSA
*Jan 31 00:29:23.947: OSPF-2 EXTER: Process partial nssa spf queue

PE3#show ip ospf database external 192.168.5.5

            OSPF Router with ID (10.3.3.3) (Process ID 1)

            OSPF Router with ID (10.10.68.6) (Process ID 2)

                Type-5 AS External Link States

  LS age: 38
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 192.168.5.5 (External Network Number )
  Advertising Router: 10.10.57.5
  LS Seq Number: 80000001
  Checksum: 0x89A3
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 10
        Forward Address: 0.0.0.0
        External Route Tag: 3489725928

Vérifiez

Les commandes de découvrir si le bit de DN est placé pour le LSA et la balise de domaine appliqués sont identiques qui sont utilisées afin de vérifier la base de données LSA.

Cette sortie affiche l'exemple pour le LSA du type 3 et du type 5 OSPF et met en valeur le bit de DN et la balise a placé quand les artères VPNv4 sont redistribuées dans l'OSPF sur PE2 :

 Remarque: OSPF PE-CE MPLS VPN inclut toujours le mécanisme de boucle-prévention afin de traiter des questions. Dans le Cisco IOS® plus ancien, par utilisation d'origine de LSAs du type 3 de projet soumis à l'IETF le bit de DN dans le LSA et l'utilisation de LSAs du type 5 une balise. L'utilisation plus nouvelle de mandats RFC 4576 du DN a mordu pour le type 3 et le type 5 LSAs.

Ceci a été commis par l'intermédiaire de l'ID de bogue Cisco CSCtw79182.

Les Routeurs de PE avec des images de Cisco IOS avec la difficulté de ce défaut lanceront le type 5 LSAs externe avec le bit de DN et une balise comme mécanismes de boucle-prévention. Les versions précédentes de Cisco IOS ont annoncé la seule balise à cet effet pour les artères externes.

Le changement du comportement a été fait parce qu'une balise est possible pour réécrire (en changeant l'ID de domaine VPN ou par l'intermédiaire du route-map) mais le bit de DN n'est pas utilisateur-contrôlable. Dans quelques conceptions de coin-dossier, quelques clients pourraient avoir délibérément désactivé le mécanisme de boucle-prévention avec un écraser des balises de LSAs externe pour que le routeur PE préfère l'artère OSPF au-dessus de la route BGP.

Dans de plus nouvelles versions de Cisco IOS, ce n'est pas possible. L'immense majorité de clients qui utilisent l'OSPF PE-CE dans une configuration de manuel ne sera pas affectée. Les clients qui ignorent des balises POURRAIENT voir un changement du comportement.

Dépannez

Il n'existe actuellement aucune information de dépannage spécifique pour cette configuration.


Conversations connexes de la communauté de soutien de Cisco

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


Document ID: 118800