Exemple de configuration d'OSPF en tant que protocole PE-CE et techniques de prévention des boucles dans MPLS L3 VPN

Introduction

Ce document décrit les fonctions de prévention des boucles et les étapes de configuration minimales lorsque vous exécutez le protocole de routage OSPF (Open Shortest Path First) entre les routeurs de périphérie du fournisseur (PE) et de périphérie du client (CE). Il présente un scénario de réseau qui décrit l'utilisation du DN (Downward Bit), qui est une option dans LSA (Link State Advertisement) et Domain Tag.

Conditions préalables

Conditions requises

Cisco vous recommande de connaître le VPN de couche 3 OSPF et MPLS (Multiprotocol Label Switching).

Components Used

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

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Informations générales

Le fournisseur de services (SP) et le routeur CE échangent des routes avec un protocole de routage auquel le fournisseur de services et le client conviennent conjointement. Ce document décrit le mécanisme de prévention des boucles lorsqu'OSPFv2 est utilisé.

Lorsque le protocole OSPFv2 est utilisé sur une liaison PE-CE qui appartient à un VRF ou VPN particulier, le routeur PE :

• Redistribue les routes reçues via OSPF pour ce VPN dans le protocole MP-BGP (Multiprotocol Border Gateway Protocol) et les annonce aux autres routeurs PE.
• Redistribue les routes BGP installées dans le VPN via MP-BGP dans l'instance OSPF pour ce VPN et l'annonce aux routeurs CE.

Configuration

Diagramme du réseau

Considérez cette topologie de réseau afin de comprendre les techniques de prévention des boucles.

Dans cette configuration, il y a une possibilité de boucle. Par exemple, si CE1 annonce la LSA de type 1 OSPF à PE1, qui redistribue la route dans VPNv4 et l'annonce à PE2, PE2 annonce à son tour la LSA récapitulative à CE2. Cette route reçue par CE2 peut être annoncée à nouveau à PE3. Le troisième routeur PE apprend la route OSPF, qui est meilleure que la route BGP, et annonce à nouveau la route dans BGP comme locale au site client 2. PE3 n’apprend jamais que la route annoncée n’est pas issue du site client 2.

Afin de surmonter cette situation, lorsque les routes sont redistribuées de MP-BGP dans OSPF, elles sont marquées avec un bit DN dans LSA de type 3, 5 ou 7 et ont la balise de domaine pour LSA de type 5 et 7.

Configurations

Voici l’exemple de configuration sur les routeurs PE. Cette configuration inclut la configuration VRF, le processus OSPF 2 qui s'exécute entre les routeurs PE-CE, le processus OSPF 1 qui s'exécute en tant que protocole IGP (Interior Gateway Protocol) dans le coeur MPLS et la configuration MP-BGP.

Bit DN

Le bit précédemment inutilisé dans le champ Options LSA OSPF est appelé bit DN. Ce bit est défini sur les LSA de type 3, 5 et 7 lorsque les routes MP-BGP sont redistribuées dans OSPF. Lorsque l’autre routeur PE reçoit la LSA d’un routeur CE de type 3, 5 ou 7 avec le jeu de bits DN, les informations de cette LSA ne sont pas utilisées dans le calcul de la route OSPF.

Sur la base de la topologie du réseau, PE2 définit le bit DN pour la LSA redistribuée et cette LSA n’est jamais prise en compte pour le calcul de route dans le processus OSPF 2 sur PE3. Par conséquent, PE3 ne redistribue jamais cette route dans MP-BGP.

Voici un exemple d'en-tête OSPF qui montre le jeu de bits DN, lorsque la route a été annoncée par le routeur PE pour une LSA de 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 uniquement aux LSA de type 5 et 7 OSPF. Lorsque les routes VPNv4 sont redistribuées de MP-BGP dans OSPF sur le routeur PE, la balise de domaine est définie pour les routes externes OSPF. La balise peut être définie manuellement avec la commande domain-tag sous le processus OSPF ou une valeur de 32 bits peut être générée automatiquement :

En fonction de la topologie du réseau, PE2 définit la balise de domaine pour les LSA de type 5 et 7 lorsqu'il redistribue la route VPNv4 dans OSPF. Cette LSA n’est jamais prise en compte pour le calcul de route, car le bit DN est déjà défini, mais elle a également le jeu de balises de domaine, de sorte que la LSA est ignorée parce que le Tag de domaine correspond à la balise VPN / VRF. Par conséquent, la route n’est jamais redistribuée dans OSPF.

Cet exemple montre le type de LSA 5 ignoré lorsqu'il est reçu avec la balise de domaine définie de la même manière que la balise de domaine VRF locale sur PE3 à partir 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érification

Les commandes permettant de déterminer si le bit DN est défini pour la LSA et la balise de domaine appliquées sont les mêmes que celles utilisées pour vérifier la base de données LSA.

Ce résultat montre l'exemple de LSA de type 3 et 5 OSPF et met en surbrillance le bit DN et le jeu de balises lorsque les routes VPNv4 sont redistribuées dans OSPF sur PE2 :

 Note: MPLS VPN OSPF PE-CE inclut toujours le mécanisme de prévention des boucles afin de gérer les problèmes. Dans l'ancienne version de Cisco IOS^®, les LSA de brouillon de type 3 par IETF d'origine utilisent le bit DN dans les LSA et les LSA de type 5 utilisent une balise. La nouvelle RFC 4576 impose l'utilisation du bit DN pour les LSA de type 3 et de type 5.

Ceci a été validé via l'ID de bogue Cisco CSCtw79182.

Les routeurs PE avec les images Cisco IOS avec la correction de ce défaut émanent de LSA externes de type 5 avec un bit DN et une balise comme mécanismes de prévention des boucles. Les versions précédentes de Cisco IOS annonçaient la seule balise à cette fin pour les routes externes.

Le changement de comportement a été effectué parce qu'une balise peut être réécrite (en changeant l'ID de domaine VPN ou via la route-map) mais le bit DN n'est pas contrôlable par l'utilisateur. Dans certaines conceptions de boîtier d'angle, certains clients ont peut-être délibérément désactivé le mécanisme de prévention des boucles avec une écrasement des étiquettes des LSA externes afin que le routeur PE préfère la route OSPF à la route BGP.

Dans les versions plus récentes de Cisco IOS, cela n'est pas possible. La grande majorité des clients qui utilisent PE-CE OSPF dans une configuration de manuel ne seront pas affectés. Les clients qui remplacent les balises PEUVENT voir un changement de comportement.

Dépannage

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