Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Protection de sortie dans les VPN de couche 3

Cette rubrique présente le concept et les composants de la protection de sortie dans le VPN de couche 3. Il décrit et fournit des exemples sur la configuration des routeurs PLR (protected, protector et point of local repair).

Protection contre les sorties pour les unicasts étiquetés BGP

En cas de défaillance d’un nœud réseau ou d’une liaison, il faut un certain temps pour restaurer le service à l’aide de la convergence traditionnelle des tables de routage. Les procédures de réparation locales peuvent accélérer la restauration en mettant en place une protection locale aussi près d’une défaillance que possible. Une protection rapide des nœuds sortants est disponible pour les services dans lesquels BGP unicast interconnecte les zones, niveaux ou systèmes autonomes IGP. Si un routeur fournisseur détecte qu’un routeur de sortie (AS ou routeur de bordure de zone) est en panne, il transfère immédiatement le trafic destiné à ce routeur vers un routeur de protection qui transfère le trafic en aval vers la destination.

Pour fournir une protection de sortie pour l’unicast étiqueté BGP, le nœud de protection doit créer un état de secours pour les destinations en aval avant que la panne ne se produise. L’idée de base de la solution est que le nœud de protection construit un état de transfert associé au nœud protégé et transmet les étiquettes MPLS attribuées par le nœud protégé plus en aval vers la destination finale.

Cette fonctionnalité prend en charge les applications Inter-AS Option C et Seamless MPLS.

Inter-AS Option C : l’unicast étiqueté BGP fournit des chemins de commutation d’étiquettes de transport (LSP) de bout en bout en raccordant les LSP intra-AS. Les routeurs limites AS exécutent EBGP sur d’autres routeurs limites AS pour échanger des étiquettes contre des routes de bouclage /32 PE. IBGP s’exécute entre le routeur périphérique du fournisseur et les routeurs limites AS au sein de chaque AS. Sur la figure 1, le trafic passe du CE1 au CE2. ASBR1 est le routeur frontière AS protégé, ASBR2 en est le protecteur et l’équipement P1 est le point de réparation local (PLR). Le chemin principal est choisi entre PE1 et PE2 sur ASBR1 et ASBR3. En cas de défaillance de l’ASBR1, le routeur P1 détecte la défaillance de l’ASBR1 et transfère le trafic vers ASBR2, qui fournit un service de sauvegarde et transfère le trafic en aval.

Figure 1 : Inter-AS Option C Inter-AS Option C

MPLS transparent : l’unicast étiqueté BGP fournit des LSP de transport de bout en bout en raccordant les LSP intra-zone/niveau. Les routeurs de périphérie de zone (ACL) exécutent des routeurs BGP étiquetés unicast à d’autres ARL afin d’échanger des étiquettes contre des routes de bouclage /32 PE. Sur la Figure 2, le trafic passe de l’équipement CE1 à l’équipement CE2. ABR1 est l’ABR protégé, ABR2 est le protecteur et T1 est le PLR. Le chemin principal est choisi entre PE1 et PE2 par rapport à ABR1 et ABR3. En cas de défaillance d’ABR1, le routeur T1 détecte la défaillance de l’ABR1 et transfère le trafic vers ABR2, qui fournit un service de sauvegarde et transfère le trafic en aval.

Figure 2 : MPLS transparent Seamless MPLS

Dans chacune de ces applications, le nœud protégé présente une route unicast BGP principale nécessitant une protection. Lorsque la protection rapide est activée, BGP présente les routes d’étiquettes avec une adresse spéciale comme saut suivant. Cette adresse spéciale est un identifiant de contexte configuré par l’intermédiaire de l’interface de ligne de commande. Le nœud protégé présente également l’identificateur de contexte dans IGP et un label NULL dans LDP pour l’identificateur de contexte.

Le nœud de sauvegarde présente des routes unicast BGP de secours pour les routes protégées. Le nœud de protection transfère le trafic vers le nœud de secours à l’aide des étiquettes annoncées par le nœud de secours.

Le nœud de protection fournit le service de secours en connectant les étiquettes provenant du nœud protégé et les étiquettes provenant du nœud de secours. Le nœud de protection transfère le trafic vers le nœud de secours en cas de défaillance du nœud protégé. Le nœud de protection présente le même identifiant contextuel dans IGP avec une métrique élevée. En outre, il présente un label réel dans LDP pour l’identificateur de contexte. Le nœud de protection écoute les routes unicast BGP annoncées par le nœud protégé et le nœud de secours, et remplit la table d’étiquettes contextuelle et la FIB de secours. Lorsque le trafic avec le label LDP en contexte réel arrive, la recherche est effectuée dans le contexte d’un nœud protégé. Le nœud de protection agit souvent comme nœud de secours.

Le PLR détecte la défaillance du nœud protégé et transfère le trafic MPLS vers le nœud de protection. La mesure IGP élevée ainsi que le label LDP annoncé par le nœud de protection garantissent que le PLR utilise le nœud de protection comme LSP de secours LDP.

Il existe deux types de protection pris en charge : protection colocalisée et protection centralisée. Dans le type colocalisé, le nœud de protection est également le nœud de secours. Dans le type centralisé, le nœud de secours est différent du nœud de protection.

Configuration de la protection contre les sorties pour l’unicast étiqueté BGP

Une protection rapide pour les nœuds sortants est disponible pour les services dans lesquels BGP unicast interconnecte les zones, niveaux ou AS IGP. Si un routeur fournisseur détecte qu’un routeur de sortie (AS ou routeur de bordure de zone) est en panne, il transfère immédiatement le trafic destiné à ce routeur vers un routeur de protection qui transfère le trafic en aval vers la destination.

Avant de configurer la protection contre les sorties pour l’unicast étiqueté BGP, assurez-vous que tous les routeurs du système d’exploitation ou de la zone as exécutent Junos OS 14.1 ou une version ultérieure.

Pour configurer la protection de sortie pour l’unicast étiqueté BGP :

  1. Ajoutez la configuration suivante au routeur protégé :
  2. Ajoutez la configuration suivante au routeur de protection :
  3. Ajoutez la configuration suivante au routeur PLR (point de réparation local) :
  4. Exécutez show bgp neighbor sur le routeur protégé pour vérifier que la protection en matière de sortie est activée, par exemple :

Exemple : Configuration de la protection de sortie pour L’unicast étiqueté BGP

Cet exemple montre comment configurer une protection unicast étiquetée BGP pouvant être utilisée en cas de défaillance de PE dans une topologie Inter-AS Option C.

Exigences

Cet exemple utilise les composants matériels et logiciels suivants :

  • Routeurs de périphérie multiservice M Series, plates-formes de routage universelles 5G MX Series ou routeurs centraux T Series

  • Junos OS version 14.1 ou ultérieure

Aperçu

En cas de défaillance d’un nœud réseau ou d’une liaison, il faut un certain temps pour restaurer le service à l’aide de la convergence traditionnelle des tables de routage. Les procédures de réparation locales peuvent accélérer la restauration en mettant en place une protection locale aussi près d’une défaillance que possible. Une protection rapide des nœuds sortants est disponible pour les services dans lesquels BGP unicast interconnecte les zones, niveaux ou systèmes autonomes IGP. Si un routeur fournisseur détecte qu’un routeur de sortie (AS ou routeur de bordure de zone) est en panne, il transfère immédiatement le trafic destiné à ce routeur vers un routeur de protection qui transfère le trafic en aval vers la destination.

Cet exemple montre comment configurer la protection de sortie unicast étiquetée dans un VPN de couche 3.

Topologie

Dans cet exemple, une topologie Inter-AS Option C est configurée par la configuration de deux équipements de périphérie client (CE) et de six équipements PE (Service Provider Edge) dans quatre systèmes autonomes. Les équipements CE sont configurés dans AS100 et AS101. Les équipements PE sont configurés dans AS200 et AS300.

La figure 3 illustre la topologie utilisée dans cet exemple.

Figure 3 : Protection de sortie dans un VPN Egress Protection in a Layer 3 VPN de couche 3

L’objectif de cet exemple est de protéger le routeur PE R4. La protection de sortie est configurée sur les routeurs R4 et R9 afin que le trafic puisse être acheminé via la liaison de secours (R9 vers R8) lorsque le routeur R4 (ou la liaison entre le nœud R5 et le nœud R4) tombe en panne. Dans cet exemple, le routeur R4 est le routeur protégé, le routeur R9 est le routeur de protection et le routeur R5 est le point de réparation local (PLR).

Configuration

Configuration rapide CLI

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez tous les sauts de ligne, modifiez tous les détails nécessaires pour correspondre à la configuration de votre réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie.

Routeur R0

Routeur R1

Routeur R2

Routeur R3

Routeur R4

Routeur R5

Routeur R6

Routeur R7

Routeur R8

Routeur R9

Configuration de la protection de sortie dans les VPN de couche 3

Procédure étape par étape

L’exemple suivant nécessite de naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à Using the CLI Editor in Configuration Mode dans le CLI User Guide.

Pour configurer la protection de sortie unicast :

  1. Configurez les interfaces de chaque routeur, par exemple :

  2. Configurez l’ID du routeur et le numéro de système autonome (AS) de chaque routeur, par exemple :

    Dans cet exemple, l’ID du routeur est choisi comme étant identique à l’adresse de bouclage configurée sur le routeur.

  3. Configurez les protocoles sur chaque routeur, par exemple :

  4. Configurez les stratégies de routage sur tous les routeurs PE et routeurs de bordure AS (routeurs R1, R3, R4, R6, R8 et R9), par exemple :

  5. Configurez l’instance de routage VPN sur les routeurs R1 et R6.

    Et

  6. Configurez la protection de sortie du routeur R4, en définissant le routeur R4 comme routeur protégé et le routeur R9 comme protecteur.

    Et

Résultats

Depuis le mode configuration, confirmez votre configuration en entrant les show interfacescommandes , show routing-options, show protocolsshow policy-options (le cas échéant) et show routing-instances (le cas échéant).

Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé la configuration du routeur, entrez commit dans le mode de configuration.

Répétez la procédure pour chaque routeur dans cet exemple, en utilisant les noms et adresses d’interface appropriés pour chaque routeur.

Vérification

Vérification de l’activation de la protection de sortie

But

Vérifiez que la protection de sortie est activée sur le routeur protégé, le routeur R4.

Action

Exécutez show bgp neighbor le routeur R4 pour vérifier que la protection pour le sortie est activée.

Vérification de l’état de l’ASBR protégé comme « principal »

But

Vérifiez que l’état du routeur de bordure AS protégé, le routeur R4, est « principal ».

Action

Exécutez show mpls context-identifier sur le routeur R4.

Vérification de l’état du Protector ASBR en tant que « protecteur »

But

Vérifiez que l’état du routeur de bordure AS de protection, le routeur R9, est « protecteur ».

Action

Exécutez show mpls context-identifier sur le routeur R9.

Présentation de la protection sortante pour les VPN de couche 3 en périphérie

En règle générale, la restauration des services VPN de couche 3 pour les routeurs CE (Customer Edge) multi-domiciles dépend du routeur PE (Provider Edge) entrant pour détecter la défaillance de la liaison OU des nœuds PE sortants et du trafic de commutation vers le routeur PE de secours. Pour obtenir une restauration plus rapide, un mécanisme de protection du routeur PE peut être utilisé pour effectuer une restauration locale du service immédiatement en cas de défaillance de nœud PE sortant. Ce mécanisme nécessite que le routeur au point de réparation local (PLR) redirige le trafic VPN vers un routeur PE protecteur pour un reroutage rapide du trafic.

La topologie suivante décrit le concept de protection contre les sorties.

Figure 4 : Topologie d’échantillon pour la protection Sample Topology for Egress Protection contre les sorties

Dans cette topologie :

Le routeur PE3 agit comme protecteur des instances ou sous-réseaux de routage VPN de couche 3 PE2.

Les routeurs CE font partie d’un VPN où le routeur CE1 est multi-domicile avec le routeur PE1 et le routeur PE2. De même, le routeur CE2 est multi-domicile avec routeurs PE2 et PE3.

Le routeur PE1 peut être l’expéditeur de l’identificateur de contexte du routeur CE1, tandis que le routeur PE2 est le protecteur de cet identificateur de contexte. De même, LE2 peut être à l’origine de l’identificateur de contexte du routeur CE2, tandis que le routeur PE3 est le protecteur de cet identificateur de contexte.

Le chemin emprunté par le routeur PE4 peut passer par PLR>PE2 pour les routeurs CE1 et CE2. Le chemin de secours du routeur CE1 est via PLR>PE1. Le chemin de secours du routeur CE2 est via PLR>PE3. Le trafic transite par le chemin de travail dans des circonstances normales.

Lorsque le routeur PE4 détecte une défaillance de nœud ou de liaison PE2, le trafic est redirigé du chemin de travail vers le chemin protégé. Dans le processus de basculement normal, la détection de la défaillance et de la reprise s’appuie sur le plan de contrôle et est donc relativement lente.

En règle générale, en cas de défaillance d’une liaison ou d’un nœud dans le réseau central, le routeur PE sortant doit s’appuyer sur le routeur PE entrant pour détecter la défaillance et passer au chemin de secours, car aucune option de réparation locale en cas de défaillance de sortie n’est disponible.

Pour fournir une solution locale de réparation de la liaison PE sortante ou de la défaillance de nœud, un mécanisme appelé protection contre les sorties peut être utilisé pour réparer et restaurer rapidement la connexion. Si la protection pour le trafic sortant est configurée, le routeur PLR détecte la défaillance de la liaison ou des nœuds PE2 et redirige le trafic via le routeur de protection PE3 à l’aide du chemin de secours de commutation d’étiquettes (LSP) signalé par LDP. Le routeur PLR utilise des routes alternatives sans boucle par préfixe pour programmer le saut suivant de secours via le routeur PE3, et le trafic est transféré vers les routeurs CE1 et CE2 à l’aide des chemins alternatifs. Cette restauration est effectuée rapidement après que le routeur PLR a détecté le nœud de sortie du routeur PE2 ou une défaillance de liaison.

Le double mécanisme de protection peut également être utilisé pour la protection du trafic sortant, où les deux routeurs PE peuvent simultanément jouer le rôle de routeur PE principal et le routeur PE protecteur pour leurs routes d’ID contextuelles respectives ou les sauts suivant.

Fonctions du routeur

Sur la Figure 4, les routeurs suivants exécutent les fonctions suivantes :

Routeur PE protégé

Le pe2 protégé exécute les fonctions suivantes :

  • Met à jour un identifiant de contexte pour le saut suivant BGP du préfixe VPN de couche 3.

  • Présente l’identificateur de contexte au domaine IS-IS.

Routeur PE de protection

Le routeur PE de protection, PE3, exécute les fonctions suivantes :

  • Présente l’identificateur de contexte au domaine IS-IS à l’aide d’une mesure élevée. La métrique IGP élevée (configurable) et le label LDP garantissent que le routeur PLR utilise le LSP de secours à signalisation LDP en cas de défaillance du routeur PE sortant.

  • Crée une table d’étiquettes contextuelles pour la recherche de route et une table de transfert de secours pour le routeur PE protégé (PE2).

    Note:

    Le routeur PE de protection ne doit pas être dans le chemin de transfert vers le routeur PE principal.

Routeur PLR

Le routeur faisant office de point de réparation local (PLR) remplit les fonctions suivantes :

  • Calculs par routage alternatif sans boucle par préfixe. Pour que ce calcul fonctionne, la configuration de l’instruction node-link-protection et de l’instruction backup-spf-options per-prefix-calculation est nécessaire au niveau de la [edit protocols isis] hiérarchie.

  • Installe des sauts de sauvegarde pour l’identificateur de contexte via le routeur PE3 (protecteur PE).

  • Détecte la défaillance du routeur PE et redirige le trafic LSP de transport vers le protecteur.

Note:

Le routeur PLR doit être directement connecté au routeur de protection (dans ce cas, PE3). Sinon, la route alternative sans boucle ne peut pas trouver le chemin de secours vers le protecteur. Cette limitation est supprimée dans Junos OS version 13.3 et versions ultérieures.

Modèles de protection et de protection

Le protecteur est un nouveau rôle ou fonction pour la restauration de la défaillance de nœud PE sortant. Ce rôle peut être joué par un routeur PE de sortie de secours ou tout autre nœud participant au plan de contrôle VPN pour les préfixes VPN qui nécessitent une protection contre les nœuds de sortie. Il existe deux modèles de protection basés sur l’emplacement et le rôle d’un protecteur :

  • Protection en co-emplacement : dans ce modèle, le routeur PE de protection et les configurations de routeur PE de secours sont effectués sur le même routeur. Le protecteur est colocalisé avec le routeur PE de secours pour le préfixe protégé et dispose d’une connexion directe au site multi-domicile qui est à l’origine du préfixe protégé. En cas de défaillance du PE sortant, le protecteur reçoit le trafic du routeur PLR et le router vers le site multi-domicile.

  • Protection centralisée : dans ce modèle, le routeur PE de protection et le routeur PE de secours sont différents. Le protecteur centralisé peut ne pas avoir de connexion directe au site multi-domicile. En cas de défaillance d’une liaison OU d’un nœud PE sortant, le protecteur centralisé redirige le trafic vers le routeur PE sortant de secours avec le label VPN annoncé pour le routeur PE de sortie de secours qui prend en charge l’envoi du trafic vers le site multi-utilisateur.

Un réseau peut utiliser l’un des modèles de protection ou une combinaison des deux, selon les besoins.

Scénario particulier de protection des nœuds de sortie : si un routeur est à la fois un protecteur et un PLR, il installe des sauts de secours pour protéger le LSP de transport. En particulier, il n’a pas besoin de dérivation LSP pour les réparations locales.

Dans le modèle de protection colocalisé, le PLR ou le protecteur est directement connecté au CE via un ca de secours, tandis que dans le modèle de protection centralisé, le PLR ou le protecteur dispose d’un tunnel MPLS vers le PE de secours. Dans les deux cas, le PLR ou le Protecteur installe un saut suivant avec un label suivi d’une recherche dans une context label table, c’est-à-dire __context__.mpls.0. En cas de défaillance du nœud de sortie, le PLR ou le protecteur bascule le trafic vers ce saut suivant de secours dans le PFE. L’étiquette externe (th etransport LSP label) des paquets est apparaissent, et l’étiquette interne (l’étiquette VPN de couche 3 attribuée par le nœud de sortie) est regardé dans __context__.mpls.0, ce qui entraîne le transfert direct des paquets vers le CE (dans le modèle de protection colocalisé) ou le PE de secours (dans le modèle de protection centralisée).

Pour plus d’informations sur la protection contre les défaillances PE sortantes, consultez le projet d’internet draft-minto-2547-egress-node-fast-protection-00, 2547 egress PE Fast Failure Protection..

Modèle de publicité IGP

La disponibilité de la protection contre les sorties est annoncée dans le protocole IGP (Interior Gateway Protocol). Les protocoles d’étiquettes et CSPF (Constrained Shortest Path First) utilisent ces informations pour assurer la protection en sortie.

Pour les VPN de couche 3, les publicités IGP peuvent être des types suivants :

  • Identificateur de contexte en tant que lien d’tube (pris en charge dans Junos OS 11.4 R3 et versions ultérieures). Une liaison reliant un nœud de branche à un nœud de transit est une liaison d’tube.

  • Identificateur de contexte en tant que nœud d’alias d’tube (pris en charge dans Junos OS 13.3 et versions ultérieures).

  • Identificateur de contexte en tant que nœud proxy d’talon (pris en charge dans Junos OS 13.3 et versions ultérieures).

Par défaut, la liaison stub est utilisée. Pour activer la fonctionnalité de point de réparation local (PLR), dans laquelle le PLR redirige le trafic de service en cas de panne de sortie, configurez un nœud d’alias de stub ou un nœud proxy d’talon comme suit :

Les deux méthodes offrent des avantages différents, en fonction des besoins de votre déploiement réseau.

Identifiant de contexte en tant que nœud d’alias de stub

Dans la méthode d’alias d’extrémité STUB, l’adresse de point de terminaison LSP comporte un nœud de sortie de sauvegarde explicite qui permet d’apprendre ou de configurer la sauvegarde sur l’avant-dernier nœud de saut d’un LSP protégé. Avec ce modèle, l’avant-dernier nœud de saut d’un LSP protégé configure le tunnel de dérivation LSP pour remonter le nœud de sortie en évitant le nœud de sortie principal. Ce modèle nécessite une mise à niveau de Junos OS dans les nœuds centraux, mais suffisamment flexible pour prendre en charge toutes les contraintes liées aux aspects techniques du trafic.

Le PLR apprend que l’ID de contexte dispose d’une protection. Lorsque l’ID contextuel principal tombe en panne, les paquets sont redirigés vers le protecteur par le biais d’un chemin de secours préprogramé. L’ID de contexte et le mappage de protecteur sont configurés ou appris sur le PLR et signalés dans l’IGP par le protecteur. Une table de routage appelée inet.5 sur le PLR fournit les détails configurés ou appris par IGP.

IS-IS présente les ID contextuels dans le TED via une adresse IP TLV. IS-IS importe ce TLV dans le TED en tant qu’information étendue. IS-IS présente les routes TLV protectrices dans la route inet.5 pour l’ID de contexte, le protocole suivant étant l’ID de routeur du protecteur. Si le TLV de protection dispose d’un label, ce label est ajouté à la route de la table de routage inet.5 pour LDP.

CSPF considère l’adresse IP TLV pour le calcul de point de terminaison de tunnel.

Avec le modèle d’alias d’extrémité, la configuration LSP du protecteur ne nécessite aucune modification dans les nœuds. Toutefois, contourner la configuration LSP pour la protection des nœuds nécessite des modifications dans le PHN et le routeur de protection.

Lorsque le RSVP met en place le dérivation pour la protection des nœuds LSP, le RSVP effectue également une recherche pour le protecteur si le PLR est l’avant-dernier saut du LSP. Si le protecteur est disponible pour la destination LSP, il utilise CSPF pour calculer un chemin avec une contrainte qui exclut le PE sortant et définit une destination LSP de contournement vers l’ID de contexte si une destination n’est pas déjà configurée. Lors de la configuration d’un LSP de dérivation sur l’ID contextuel, le PLR déverve toutes les options de protection.

Le LDP est utile lorsque le réseau prend en charge une couverture LFA à 100 % mais ne prend pas en charge une couverture LFA à 100 % par préfixe. LDP définit un chemin de secours avec le protecteur avec le label de contexte annoncé par le protecteur vers le point de service.

Dans les réseaux où la couverture LFA à 100 % n’est pas disponible, il est utile d’avoir des LFA LSP de secours avec des tunnels basés sur RSVP.

Dans un état stable, le transfert est le même que sur tout autre LSP protégé dans le PLR. Dans le protecteur, le label non nul qui est annoncé et signalé pour l’ID de contexte comporte le point de saut suivant de la table contextuelle MPLS, où les étiquettes des pairs sont programmées.

En cas de défaillance, le PLR remplace le label de transport par le LSP de dérivation par l’ID de contexte ou remplace l’étiquette contextuelle du label (le label annoncé par le protecteur pour l’ID de contexte) et pousse le label de transport sur l’adresse d’interface lo0 du protecteur.

Identificateur de contexte en tant que nœud proxy d’tube

Identificateur de contexte en tant que nœud proxy d’talon (pris en charge dans Junos OS 13.3 et versions ultérieures). Un nœud d’extrémité n’apparaît qu’à la fin d’un chemin AS, ce qui signifie qu’il ne fournit pas de service de transit. Dans ce mode, connu sous le nom de mode virtuel ou proxy, l’adresse du point de terminaison LSP est représentée sous la forme d’un nœud avec des liaisons bidirectionnelles, avec le nœud de sortie principal du LSP et le nœud de sortie de secours. Grâce à cette représentation, l’avant-dernier saut du point de sortie principal LSP peut se comporter comme un PLR en établissant un tunnel de dérivation pour sauvegarder la sortie en évitant le nœud de sortie principal. Ce modèle présente l’avantage que vous n’avez pas besoin de mettre à niveau Junos OS sur les nœuds centraux et aidera ainsi les opérateurs à déployer cette technologie.

L’ID de contexte est représenté en tant que nœud dans les bases de données TE (Traffic Engineering) et IGP. L’équipement PE principal présente le nœud contextuel dans les bases de données IGP et TE. L’équipement PE principal et l’équipement PE protégé prennent en charge une liaison vers le nœud contextuel avec une bande passante et une mesure TE. Les autres caractéristiques TE des liens TE ne sont pas annoncées par Junos OS.

Dans IS-IS, le routeur PE principal présente le nœud proxy ainsi que des liens vers le routeur principal et le routeur de protection. Les routeurs principaux et protecteurs font la promotion des liens vers le nœud proxy. Le nœud proxy génère les informations suivantes.

  • ID système : décimale à code binaire basée sur l’ID de contexte.

  • Nom d’hôte—Protector-name:ID de contexte

  • LSP-ID — <Système-ID>.00

  • Type de PDU : niveaux 2 et 1, en fonction de la configuration

  • Attributs LSP :

    • Surcharge : 1

    • | IS_TYPE_L1 (0x01) IS_TYPE_L2 (0x02) pour la PDU de niveau 2

    • IS_TYPE_L1 pour le niveau 1

    • Multi-zones : non

    • Tous les autres attributs : 0

Le nœud proxy contient uniquement la zone, le MT, le nom de l’hôte, l’ID du routeur, les protocoles et les TLV d’accessibilité IS. La zone, le MT, l’authentification et les protocoles TLV sont les mêmes que sur le réseau principal. Les TLV d’accessibilité IS contiennent deux liaisons appelées Cnode-primary-link et Cnode-protector-link. Ces deux liaisons incluent des TLV TE. Les TE-link-TLV suivants sont annoncés dans des liens contextuels :

  • Interface IPv4 ou adresse de voisinage

  • Bande passante maximale

  • Métrique TE par défaut

  • Identifiants de liaison (locaux ou distants)

Valeurs sous TLV :

  • Bande passante : zéro

  • Métrique TE : mesure TE maximale

  • Adresse de l’interface — ID de contexte

  • Adresse de voisinage du protecteur : ID de routeur de protection

  • Adresse du voisin principal : ID de routeur protégé

  • Protection des identifiants locaux des liaisons : 0x80fffff1

  • Liaison id local principal : 0x80fffff2

  • Protection des identifiants distants de liaisons : les leçons tirées du protecteur

  • Identifiant distant du lien principal : leçons tirées du principal

Liens PE protégés vers un nœud contextuel (le principal présente le lien avec les détails suivants) :

  • Bande passante : maximum

  • Métrique TE : 1

  • Adresse d’interface — ID de routeur

  • Adresse de voisinage contextuelle : ID de contexte

  • Lier l’ID local au nœud contextuel : généré automatiquement (à l’instar d’une liaison sham)

  • Lier l’ID distant au nœud contextuel : 0x80fffff2

Protection des liens PE vers un nœud contextuel :

  • Le protecteur présente les liaisons de transit non numérotées avec la mesure de liaison routable maximale, la mesure TE maximale et la bande passante zéro vers le nœud contextuel. Les autres caractéristiques TE ne sont pas annoncées.

Les liens non numérotés sont annoncés avec les attributs suivants :

  • bande passante : 0

  • Métrique TE : mesure TE MAX

  • Adresse d’interface — ID de routeur

  • Adresse de voisinage contextuelle : ID de contexte

  • Lier l’ID local au nœud contextuel :généré automatiquement (à l’instar d’une liaison sham)

  • Lier l’ID distant au nœud contextuel : 0x80fffff1

Dans RSVP, les changements de comportement sont uniquement dans le protecteur et les routeurs principaux. RSVP met fin au LSP et au LSP de dérivation vers l’ID contextuel. Si l’ID de contexte est le protecteur, un label non null est signalé. Sinon, il sera basé sur la configuration ou le type d’étiquette demandé. RSVP vérifie l’objet de route explicite (ERO) à partir du chemin lui-même et l’ID de contexte. RSVP envoie le message Resv à l’aide de deux objets RRO (Record Route Object), un pour l’ID de contexte et un pour lui-même. Cette simulation simule l’avant-dernier nœud de saut (PHN) pour assurer la protection de nœud avec le protecteur du principal pour l’ID LSP contextuel. En tant que dérivation du reroutage rapide (FRR), le LSP doit se fondre vers le dérivation de configuration du LSP de protection phN pour passer à l’ID contextuel via le protecteur en évitant le principal.

Le protecteur met également fin au LSP de secours pour l’ID contextuel afin de maintenir le LSP protégé en vie en cas de défaillance, jusqu’à ce que le nœud d’entrée cesse le LSP. Le nouveau LSP est rétabli via le protecteur, mais ce LSP n’est pas utilisé pour le trafic de service, car le protocole de service n’utilise pas l’ID contextuel. Le LSP traverse le protecteur même si le principal arrive. Seule la reoptimisation démissionne du LSP à travers la primaire. En mode proxy stub, le contournement LSP avec contraintes n’est pas pris en charge.

LDP ne peut pas utiliser la méthode proxy stub en raison de la métrique gonflée annoncée dans l’IGP.

En ce qui concerne l’état de transfert, un routeur PE qui protège un ou plusieurs segments connectés à un autre PE est appelé pe protecteur. Un PE protecteur doit connaître l’état de transfert des segments qu’il protège du PE principal protégé.

Pour un segment donné, si le dispositif de protection PE n’est pas directement connecté à l’équipement CE associé au segment, il doit également connaître l’état de transfert à partir d’au moins un pe de secours. Cette situation ne peut survenir que dans le cas d’une protection contre les défaillances PE sortantes.

Un PE protecteur maintient l’état de transfert pour un segment donné dans le contexte du PE principal. Un pe de protection peut conserver l’état pour un sous-ensemble seulement des segments du PE principal ou pour tous les segments du PE principal.

Exemple : Configuration de la protection de sortie MPLS pour les services VPN de couche 3

Cet exemple décrit un mécanisme local de réparation permettant de protéger les services VPN de couche 3 contre la défaillance du routeur PE (Provider Edge) sortant dans un scénario où les routeurs de périphérie du client (CE) sont multi-utilisateurs avec plusieurs routeurs PE.

La terminologie suivante est utilisée dans cet exemple :

  • Routeur PE de l’expéditeur : routeur PE doté d’instances ou de sous-réseaux de routage protégés qui distribuent le routeur VPN de couche 3 principal.

  • Routeur PE de secours : routeur PE qui annonce un routage VPN de couche 3 de secours.

  • Routeur PE protecteur : routeur qui relie les étiquettes VPN croisées, distribuées par le routeur PE de l’expéditeur vers les étiquettes provenant du routeur PE de secours. Le routeur PE de protection peut également être un routeur PE de secours.

  • LSP de transport : chemin de commutation d’étiquettes (LSP) à signalisation LDP pour les sauts suivant BGP.

  • PLR : un routeur faisant office de point de réparation local (PLR) capable de rediriger le trafic VPN de couche 3 vers un routeur PE protecteur pour permettre une restauration et un reroutage rapides.

  • Routes alternatives sans boucle : technologie qui ajoute essentiellement une fonction de reroutage rapide IP pour le protocole IGP (Interior Gateway Protocol) en précomputant les routes de secours pour toutes les routes principales de l’IGP. Dans le contexte de ce document, l’IGP est IS-IS.

  • Multihébergement : technologie permettant de connecter un équipement CE à plusieurs routeurs PE. Si une connexion au routeur PE principal tombe en panne, le trafic peut être automatiquement transféré vers le routeur PE de secours.

  • Identifiant de contexte : adresse IPv4 utilisée pour identifier le préfixe VPN nécessitant une protection. L’identificateur est propagé aux routeurs centraux PE et PLR, ce qui permet au routeur PE de sortie protégé de signaler la protection en matière de sortie au routeur PE protecteur.

  • Double protection : mécanisme de protection permettant à deux routeurs PE de jouer simultanément le rôle de routeur PE principal et de routeur PE protecteur pour leurs routes d’ID contextuelles respectives ou les sauts suivant. Par exemple, entre les deux routeurs PE1 et PE2, LE PE1 peut être un routeur PE principal pour l’identificateur de contexte 203.0.113.1 et un protecteur pour l’identificateur de contexte 203.0.113.2 De même, le routeur PE2 peut être un protecteur pour l’identificateur de contexte 203.0.113.1 et un routeur PE principal pour l’identificateur de contexte 203.0.113.2.

Exemple : Configuration de la protection de sortie pour les services VPN de couche 3

Cet exemple montre comment configurer la protection de sortie pour une restauration rapide des services VPN de couche 3.

Exigences

Cet exemple utilise les composants matériels et logiciels suivants

  • Plates-formes de routage universelles 5G MX Series

  • PIC de tunnel ou configuration du mode Services réseau IP améliorés (à l’aide de l’instruction network-services enhanced-ip au niveau de la [edit chassis] hiérarchie).

  • Junos OS version 11.4R3 ou ultérieure s’exécutant sur les équipements

Avant de commencer :

  • Configurez les interfaces de l’équipement. Consultez le Guide de configuration des interfaces réseau Junos OS.

  • Configurez les protocoles de routage suivants sur tous les routeurs PE et PLR.

    • MPLS, LSP et LDP. Consultez le Guide de configuration des applications MPLS de Junos OS.

    • BGP et IS-IS. Consultez le Guide de configuration des protocoles de routage Junos OS.

  • Configurez les VPN de couche 3. Consultez le Guide de configuration des VPN Junos OS.

Aperçu

En général, la restauration des services VPN de couche 3, en cas de défaillance du routeur PE sortant (pour les routeurs de périphérie client multi-domicile [CE] ), dépend du routeur PE entrant pour détecter la défaillance du nœud PE sortant et du trafic de commutation vers le routeur PE de secours pour les sites CE multi-domestiques.

Junos OS version 11.4R3 ou ultérieure vous permet de configurer la protection de sortie pour les services VPN de couche 3 qui protège les services contre la défaillance de nœud PE sortant dans un scénario où le site CE est multi-accueil avec plusieurs routeurs PE. Ce mécanisme permet d’effectuer immédiatement une réparation locale en cas de défaillance de nœud de sortie. Le routeur faisant office de point de réparation local (PLR) redirige le trafic VPN vers un routeur PE protecteur afin de restaurer rapidement le service, obtenant ainsi une protection rapide comparable au reroutage rapide MPLS.

Les instructions utilisées pour configurer la protection contre les sorties sont les suivantes :

  • egress-protection— Lorsqu’elle est configurée au niveau hiérarchique [edit protocols mpls], cette instruction spécifie les informations de protection et l’identificateur de contexte pour le VPN de couche 3 et le circuit virtuel de protection de la périphérie :

    Lorsqu’elle [edit protocols bgp group group-name family inet-vpn unicast]est configurée aux niveaux , [edit protocols bgp group group-name family inet6-vpn unicast]ou [edit protocols bgp group group-name family iso-vpn unicast] hiérarchiques, l’instruction egress-protection spécifie l’identificateur de contexte qui assure la protection de sortie pour les informations d’accessibilité de la couche réseau VPN BGP configurées (NLRI).

    Une fois configurée au niveau de la [edit routing-instances] hiérarchie, l’instruction egress-protection contient l’identificateur de contexte du routeur PE protégé.

    Cette configuration doit être effectuée uniquement sur le routeur PE principal et utilisée pour les mises à jour BGP sortantes pour les sauts suivant.

    La configuration de l’instruction context-identifier au niveau de la [edit routing-instances routing-instance-name] hiérarchie fournit une granularité de l’ID de contexte au niveau VRF de la périphérie du client pour chaque instance VRF.

  • context-identifier— Cette instruction spécifie une adresse IPV4 utilisée pour définir la paire de routeurs PE participant au LSP de protection de sortie. L’identificateur de contexte est utilisé pour attribuer un identifiant au routeur PE de protection. L’identificateur est propagé aux autres routeurs PE participant au réseau, ce qui permet au routeur PE de sortie protégé de signaler le LSP de protection de sortie au routeur PE de protection.

Configuration

Configuration rapide CLI

Note:

Cet exemple montre uniquement l’exemple de configuration pertinent à la configuration de la protection PE sortante pour les services VPN de couche 3 sur le routeur protégé, le PE2, le routeur de protection, le PE3 et le routeur PLR.

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez tous les sauts de ligne, modifiez tous les détails nécessaires pour correspondre à la configuration de votre réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie.

PE2 (routeur PE protégé)

PE3 (routeur PE protecteur)

Routeur PLR

Configuration du routeur PE protégé (PE2)

Procédure étape par étape

Pour configurer le routeur PE protégé, PE2 :

  1. Configurez MPLS sur les interfaces.

  2. Configurez la protection du système de sortie et l’identificateur de contexte.

    Note:

    Le type d’identificateur de contexte doit être défini sur primary.

  3. Configurez la protection de sortie pour le BGP NRLI configuré.

    Note:

    L’identificateur de contexte configuré au niveau de la [edit protocols bgp group group-name family inet-vpn] hiérarchie doit correspondre à celui configuré au niveau de la [edit protocols mpls] hiérarchie.

    Note:

    La configuration de l’identificateur de contexte au niveau de la [edit routing-instances routing-instance-name] hiérarchie fournit une granularité de l’id de contexte de niveau VRF CE pour chaque instance de routage et de transfert virtuels (VRF).

  4. Une fois que vous avez terminé la configuration de l’unité, validez la configuration.

Résultats

Confirmez votre configuration en exécutant la commande Show Protocols. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Configuration du routeur PE de protection (PE3)

Procédure étape par étape

Pour configurer le routeur PE de protection, PE3 :

  1. Configurez MPLS sur les interfaces.

  2. Configurez la protection du système de sortie et l’identificateur de contexte.

  3. Configurez les paramètres NRLI du VPN de couche 3 IPv4.

  4. Configurez les options de stratégie de routage.

  5. Une fois que vous avez terminé la configuration de l’unité, validez la configuration.

Résultats

Confirmez votre configuration en envoyant les show protocols commandes et les show policy-options . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Configuration du routeur PLR

Procédure étape par étape

Pour configurer le routeur agissant comme point de réparation local (PLR) :

  1. Configurez MPLS sur les interfaces.

  2. Configurez le calcul LFA par préfixe avec la protection des liaisons.

  3. Configurez LDP pour utiliser la métrique de route IGP (Interior Gateway Protocol) au lieu de la métrique de route LDP par défaut (la métrique de route LDP par défaut est 1).

Résultats

Confirmez votre configuration en envoyant la show protocols commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification des détails de la protection du sortant

But

Vérifiez la configuration de la protection pour le sortie.

Action
Sens

Instanceindique le nom de l’instance de routage. Type indique le type de VRF. Il peut s’agir de l’une local-vrf RIB ou de l’autre. remote-vrf(base d’informations de routage) : indique la table de routage créée par la protection périphérique. Context-Id indique l’ID de contexte associé à la rib. Route Target indique la cible de route associée à l’instance de routage.

Vérification des instances de routage

But

Vérifier les instances de routage.

Action
Sens

Vrf-edge-protection-id affiche la protection de sortie configurée dans le routeur PE de protection avec l’instance de routage.

Vérification du BGP NRLI

But

Consultez les détails des informations d’accessibilité de la couche réseau VPN BGP.

Action
Sens

NLRI configured with egress-protection affiche la famille BGP configurée avec la protection de sortie. egress-protection NLRI inet-vpn-unicast, keep-import: [remote-vrf] affiche la stratégie de routage de protection pour le groupe BGP.

Exemple : Configuration de la protection de sortie VPN de couche 3 avec RSVP et LDP

Cet exemple montre comment configurer la restauration rapide des services à la sortie d’un VPN de couche 3 lorsque le client est multi-utilisateur vers le fournisseur de services. En outre, cet exemple inclut une fonctionnalité de point de réparation local (PLR), dans laquelle le PLR redirige le trafic de service en cas de défaillance du trafic sortant.

À partir de Junos OS version 13.3, une fonctionnalité PLR améliorée est disponible, dans laquelle le PLR redirige le trafic de service en cas de panne de sortie. Dans le cadre de cette amélioration, le routeur PLR n’a plus besoin d’être directement connecté au routeur de protection. Auparavant, si le PLR n’était pas directement connecté au routeur de protection, la route alternative sans boucle ne pouvait pas trouver le chemin de secours vers le protecteur.

Exigences

Aucune configuration particulière au-delà de l’initialisation de l’équipement n’est requise avant de configurer cet exemple.

Cet exemple requiert Junos OS version 13.3 ou ultérieure.

Aperçu

Dans cet exemple, les équipements de périphérie du client (CE) font partie d’un VPN où l’équipement CE1 est multi-domicile avec les équipements PE2 et PE3.

L’équipement PE3 agit comme protecteur des instances ou sous-réseaux de routage VPN de couche 3.

L’équipement PE1 est l’expéditeur de l’identificateur de contexte de l’équipement CE1, l’équipement PE2 est le routeur principal de cet identificateur de contexte, tandis que l’équipement PE3 est le protecteur de cet identificateur de contexte.

L’unité P1 agit comme point de réparation local (PLR). Ainsi, l’équipement P1 peut rediriger le trafic VPN de couche 3 vers le routeur PE protecteur pour permettre une restauration et un reroutage rapides.

Le chemin de travail passe par P1>PE2. Le chemin de secours passe par P1>PE3. Le trafic transite par le chemin de travail dans des circonstances normales. Lorsqu’un nœud PE2 ou une défaillance de liaison est détecté, le trafic est redirigé du chemin de travail vers le chemin protégé. Dans le processus de basculement normal, la détection de la défaillance et de la reprise s’appuie sur le plan de contrôle et est donc relativement lente. En règle générale, en cas de défaillance d’une liaison ou d’un nœud dans le réseau central, le routeur PE sortant doit s’appuyer sur le routeur PE entrant pour détecter la défaillance et passer au chemin de secours, car aucune option de réparation locale en cas de défaillance de sortie n’est disponible. Pour fournir une solution locale de réparation de la liaison PE sortante ou de la défaillance de nœud, un mécanisme appelé protection de sortie est utilisé dans cet exemple pour réparer et restaurer rapidement la connexion. Étant donné que la protection pour le trafic sortant est configurée, le routeur PLR détecte la défaillance de la liaison ou des nœuds PE2 de l’équipement et redirige le trafic via l’équipement de protection PE3 à l’aide du chemin de commutation d’étiquettes (LSP) de secours signalé par LDP. Le routeur PLR utilise des routes alternatives sans boucle par préfixe pour programmer le saut suivant de secours via l’équipement PE3, et le trafic est transféré vers l’équipement CE2 à l’aide des chemins alternatifs. Cette restauration est effectuée rapidement après que le routeur PLR a détecté le nœud de sortie ou la défaillance de liaison de l’équipement PE2. Le double mécanisme de protection peut également être utilisé pour la protection du trafic sortant, où les deux routeurs PE peuvent simultanément jouer le rôle de routeur PE principal et le routeur PE protecteur pour leurs routes d’ID contextuelles respectives ou les sauts suivant.

Outre la protection pour le trafic sortant, cet exemple illustre une fonction PLR améliorée, dans laquelle le PLR redirige le trafic de service en cas de défaillance du trafic sortant. Cette amélioration est prise en charge dans Junos OS version 13.3 et versions ultérieures. Dans cet exemple, l’équipement P1 (le PLR) est directement connecté à l’équipement PE3 (le protecteur). Une nouvelle déclaration de configuration, , advertise-modevous permet de définir la méthode IGP (Interior Gateway Protocol) pour promouvoir la disponibilité de la protection contre les sorties.

Topologie

La figure 5 illustre l’exemple de réseau.

Figure 5 : Protection de sortie VPN de couche 3 avec RSVP et LDP Layer 3 VPN Egress Protection with RSVP and LDP

Configuration

Configuration rapide CLI

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez tous les sauts de ligne, modifiez tous les détails nécessaires pour correspondre à la configuration de votre réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie.

Équipement CE1

Équipement CE2

Équipement P1

Équipement PE1

Équipement PE2

Équipement PE3

Procédure

Procédure étape par étape

L’exemple suivant nécessite de naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à Using the CLI Editor in Configuration Mode dans le CLI User Guide.

Pour configurer l’unité P1 (le PLR) :

  1. Configurez les interfaces de l’équipement.

  2. Configurez IS-IS.

    Configurez le calcul LFA par préfixe avec la protection des liaisons de nœud.

  3. Activer MPLS.

  4. Activez RSVP.

  5. Activez LDP.

Procédure étape par étape

L’exemple suivant nécessite de naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à Using the CLI Editor in Configuration Mode dans le CLI User Guide.

Pour configurer l’équipement PE1 :

  1. Configurez les interfaces de l’équipement.

  2. Activez RSVP.

  3. Configurez MPLS.

  4. Configurez IBGP.

  5. Configurez IS-IS.

  6. Activez LDP.

    [edit protocols ldp]
    user@PE1# set track-igp-metric
    user@PE1# set interface all
    user@PE1# set interface fxp0.0 disable
    

  7. Configurez l’instance de routage.

  8. Configurez le numéro de système autonome (AS).

Procédure étape par étape

L’exemple suivant nécessite de naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à Using the CLI Editor in Configuration Mode dans leCLI User Guide.

Pour configurer l’équipement PE2 :

  1. Configurez les interfaces de l’équipement.

  2. Activez RSVP.

  3. Configurez MPLS.

  4. Configurez IBGP.

  5. Configurez IS-IS.

  6. Activez LDP.

    [edit protocols ldp]
    user@PE2# set track-igp-metric
    user@PE2# set interface all
    user@PE2# set interface fxp0.0 disable
    

  7. Configurez le numéro AS.

Procédure étape par étape

L’exemple suivant nécessite de naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à Using the CLI Editor in Configuration Mode dans le CLI User Guide.

Pour configurer l’équipement PE3 :

  1. Configurez les interfaces de l’équipement.

  2. Activez RSVP.

  3. Configurez MPLS.

  4. Configurez IBGP.

  5. Configurez IS-IS.

  6. Activez LDP.

    [edit protocols ldp]
    user@PE3# set track-igp-metric
    user@PE3# set interface all
    

  7. Configurez la stratégie de routage.

  8. Configurez le numéro AS.

Résultats

Depuis le mode configuration, confirmez votre configuration en entrant les show interfaces show protocols commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Équipement P1

Équipement PE1

Équipement PE2

Équipement PE3

Si vous avez terminé la configuration des équipements, entrez commit dans le mode de configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification du nœud de protection

But

Sur le nœud de protection (équipement PE3), vérifiez les informations relatives aux identifiants de contexte de protection de sortie configurés.

Action
Sens

L’équipement PE3 est le nœud de protection pour deux LSP configurés à partir de l’équipement PE1 (172.16.183.55) et de l’équipement PE2 (172.16.183.56).

Vérification du nœud principal

But

Sur le nœud principal (équipement PE2), vérifiez les informations relatives aux identifiants de contexte de protection de sortie configurés.

Action
Sens

L’équipement PE2 est le nœud principal.

Vérification de la route de l’identificateur de contexte

But

Examinez les informations relatives à l’identificateur de contenxt (192.0.2.6).

Action

Vérification de la protection en sortie

But

Sur l’équipement PE3, vérifiez les routes dans la table de routage.

Action
Sens

Instanceindique le nom de la communauté. Type indique le type de VRF. Il peut s’agir de l’une local-vrf ou de l’autre ou remote-vrfRoute Target de la cible de routage associée à l’instance de routage.

Vérification de l’instance de routage sur l’équipement PE1

But

Sur l’équipement PE1, vérifiez les routes dans la table de routage.

Action

Vérification des LSP

But

Sur tous les équipements, vérifiez les informations LSP.

Action

Vérification du BGP NRLI

But

Consultez les détails des informations d’accessibilité de la couche réseau VPN BGP.

Action
Sens

NLRI configured with egress-protection affiche la famille BGP configurée avec la protection de sortie. egress-protection NLRI inet-vpn-unicast, keep-import: [remote-vrf] affiche la stratégie de routage de protection pour le groupe BGP.

Vérification de la base de données des aspects techniques du trafic

But

Sur tous les équipements, vérifiez le TED.

Action

Vérification de la base de données IS-IS

But

Sur tous les équipements, consultez la base de données IS-IS.

Action