Configuration d’ingénierie du trafic basée sur les couleurs
SUMMARY
Présentation des plans de transport avec classe BGP
- Avantages des plans de transport de classe BGP
- Terminologie des plans de transport de classe BGP
- Comprendre les plans de transport avec classe BGP
- Implémentation intra-AS des plans de transport avec classe BGP
- Implémentation inter-AS de plans de transport de classe BGP
- Présentation du transport avec classe BGP-CT (BGP-CT) avec tunnels SR-TE colorés sous-jacents
- Avantages de BGP-CT avec les tunnels SR-TE colorés sous-jacents
Avantages des plans de transport de classe BGP
-
Découplage du réseau : les couches de service et de transport sont découplées l’une de l’autre, ce qui constitue les bases du découpage et de la virtualisation du réseau, le découpage de bout en bout sur plusieurs domaines réduisant considérablement les dépenses d’investissement.
- Interopérabilité inter-domaines : étend le déploiement de la classe de transport à tous les domaines de coopération afin que les différents protocoles de signalisation de transport interagissent dans chaque domaine. Réconcilie toutes les différences entre les espaces de noms communautaires étendus qui peuvent être utilisés dans chaque domaine.
-
Résolution colorée avec solution de secours : active la résolution sur des tunnels colorés (RSVP, IS-IS algorithme flexible) avec des options de récupération flexibles sur des tunnels au mieux ou tout autre tunnel de couleur.
- Qualité de service : personnalise et optimise le réseau pour respecter les exigences de niveau de service de bout en bout.
- Exploitation des déploiements existants : prend en charge des protocoles de tunnelisation bien déployés, tels que RSVP, ainsi que de nouveaux protocoles, tels que l’algorithme flexible IS-IS, ce qui permet de préserver le retour sur investissement et de réduire les OPEX.
Terminologie des plans de transport de classe BGP
Cette section fournit un résumé des termes couramment utilisés pour comprendre le plan de transport de classe BGP.
-
Nœud de service : périphériques PE (Ingress Provider Edge) qui envoient et reçoivent des routes de service (Internet et VPN de couche 3).
-
Nœud de bordure : appareil au point de connexion de différents domaines (zones IGP ou AS).
-
Nœud de transport : appareil qui envoie et reçoit des routes de monodiffusion étiquetées BGP (LU).
-
BGP-VPN : VPN construits à l’aide de mécanismes RFC4364.
-
Route Target (RT) : type de communauté étendue utilisé pour définir l’appartenance VPN.
-
Route Distinguisher (RD) : identificateur utilisé pour distinguer le VPN ou le service VPLS (Virtual Private LAN Service) auquel appartient une route. Chaque instance de routage doit être associée à un séparateur de route unique.
- Resolution scheme (Schéma de résolution) : utilisé pour résoudre l’adresse de saut suivant (PNH) de protocole dans les RIB de résolution fournissant une solution de secours.
Ils mappent les itinéraires vers les différents semi-rigides de transport du système en fonction de la communauté de cartographie.
-
Famille de services : famille d’adresses BGP utilisée pour les routes publicitaires pour le trafic de données, par opposition aux tunnels.
-
Famille de transport : famille d’adresses BGP utilisée pour les tunnels publicitaires, qui sont à leur tour utilisés par les routes de service pour la résolution.
-
Tunnel de transport : tunnel sur lequel un service peut placer le trafic, par exemple, GRE, UDP, LDP, RSVP, SR-TE, BGP-LU.
-
Domaine de tunnel : domaine du réseau contenant les nœuds de service et les nœuds de bordure sous un contrôle administratif unique qui est relié par un tunnel. Un tunnel de bout en bout s’étendant sur plusieurs domaines de tunnels adjacents peut être créé en assemblant les nœuds à l’aide d’étiquettes.
-
Classe de transport : groupe de tunnels de transport offrant le même type de service.
Classe de transport RT : nouveau format de cible d’itinéraire utilisé pour identifier une classe de transport spécifique.
Nouveau format de Route Target utilisé pour identifier une classe de transport spécifique.-
Transport RIB : au niveau du nœud de service et du nœud de frontière, une classe de transport a un semi-rigide de transport associé qui contient ses itinéraires de tunnel.
-
RTI de transport : instance de routage ; conteneur du semi-rigide de transport, et la classe de transport associée Route Target et Route Distinguisher.
-
Plan de transport : ensemble de RTI de transport important de la même classe de transport RT. Ceux-ci sont à leur tour assemblés pour s’étendre à travers les limites du domaine de tunnel à l’aide d’un mécanisme similaire à l’option Inter-AS b pour échanger des étiquettes aux nœuds de bordure (nexthop-self), formant un plan de transport de bout en bout.
-
Mappage de la communauté : communauté sur un itinéraire de service qui mappe à résoudre sur une classe de transport.
Comprendre les plans de transport avec classe BGP
Vous pouvez utiliser des plans de transport avec classe BGP pour configurer des classes de transport afin de classer un ensemble de tunnels de transport dans un réseau intra-AS en fonction des caractéristiques d’ingénierie du trafic, et utiliser ces tunnels de transport pour mapper les itinéraires de service avec le SLA souhaité et le plan de secours prévu.
Les plans de transport avec classe BGP peuvent étendre ces tunnels aux réseaux interdomaines qui s’étendent sur plusieurs domaines (AS ou zones IGP) tout en préservant la classe de transport. Pour ce faire, vous devez configurer la famille BGP de la couche de transport transport de classe BGP entre les nœuds de bordure et de service.
Dans les implémentations inter-AS et intra-AS, de nombreux tunnels de transport (LSP MPLS, IS-IS flexible algorithm, SR-TE) peuvent être créés à partir des nœuds de service et de frontière. Les LSP peuvent être signalés à l’aide de différents protocoles de signalisation dans différents domaines et peuvent être configurés avec différentes caractéristiques d’ingénierie du trafic (classe ou couleur). Le point de terminaison du tunnel de transport fait également office de point de terminaison de service et peut être présent dans le même domaine de tunnel que le nœud d’entrée de service, ou dans un domaine adjacent ou non adjacent. Vous pouvez utiliser des plans de transport avec classe BGP pour rechercher des services sur des LSP avec certaines caractéristiques d’ingénierie du trafic à l’intérieur d’un seul domaine ou sur plusieurs domaines.
Les plans de transport de classe BGP réutilisent la technologie BGP-VPN, ce qui permet de coupler et de coordonner les domaines de tunnelisation.
- Les informations d’accessibilité de la couche réseau (NLRI) sont RD :TunnelEndpoint utilisées pour le masquage des chemins d’accès.
- La cible de route indique la classe de transport des LSP et les routes fuient vers le RIB de transport correspondant sur l’équipement de destination.
- Chaque protocole de tunnelisation de transport installe une route entrante dans la table de routage transport-class.inet.3, modélise la classe de transport de tunnel en tant que cible de routage VPN et collecte les LSP de la même classe de transport dans la table de routage transport-rib transport-class.inet.3.
-
Les routes de cette instance de routage sont annoncées dans le plan de transport de classe BGP (TRANSPORT INET) AFI-SAFI en suivant des procédures similaires à celles de la RFC-4364.
-
Lorsque vous franchissez les limites d’une liaison inter-AS, vous devez suivre les procédures de l’option b pour assembler les tunnels de transport dans ces domaines adjacents.
De même, lorsque vous traversez des régions intra-AS, vous devez suivre les procédures de l’option b pour assembler les tunnels de transport dans les différents domaines TE.
-
Vous pouvez définir des schémas de résolution pour spécifier l’intention sur la variété des classes de transport dans un ordre de secours.
- Vous pouvez résoudre les routes de service et les routes de transport de classe BGP sur ces classes de transport, en transportant la communauté de mappage sur celles-ci.
La famille de transport de classe BGP s’exécute parallèlement à la famille de couches de transport BGP-LU. Dans un réseau MPLS homogène utilisant BGP-LU, il est difficile de répondre aux exigences strictes des SLA de la 5G, car les caractéristiques techniques du trafic des tunnels ne sont pas connues ou préservées au-delà des frontières du domaine. Les plans de transport de classe BGP offrent un moyen simple et évolutif sur le plan opérationnel d’annoncer plusieurs chemins pour les bouclages distants, ainsi que les informations sur la classe de transport dans l’architecture MPLS transparente. Dans les itinéraires de la famille de transport avec classe BGP, différents chemins SLA sont représentés à l’aide de la communauté étendue Transport Route-Target, qui porte la couleur de la classe de transport. Cette cible de route de transport est utilisée par les routeurs BGP de réception pour associer la route de transport de classe BGP à la classe de transport appropriée. Lors de la nouvelle publication des routes de transport de classe BGP, MPLS permute les routes et interconnecte les tunnels intra-AS de la même classe de transport, formant ainsi un tunnel de bout en bout qui préserve la classe de transport.
Implémentation intra-AS des plans de transport avec classe BGP
Figure 1 illustre une topologie de réseau avec des scénarios avant/après d’implémentation de plans de transport de classe BGP dans un domaine intra-AS. Les équipements PE11 et PE12 utilisent des LSP RSVP comme tunnel de transport et tous les itinéraires de tunnel de transport sont installés dans le RIB inet.3. L’implémentation de plans de transfert avec classe BGP permet aux tunnels de transport RSVP d’être sensibles aux couleurs, de la même manière que les tunnels de routage de segments.
Pour classer les tunnels de transport en classe de transport BGP dans une configuration intra-AS :
- Définissez la classe de transport au niveau du nœud de service (équipements PE d’entrée), par exemple, or et bronze, et attribuez des valeurs de communauté de couleurs à la classe de transport définie.
Exemple de configuration :
pe11# show routing-options route-distinguisher-id 172.16.1.1; transport-class { name gold { color 100; } name bronze { color 200; - Associez le tunnel de transport à une classe de transport spécifique au niveau du nœud d’entrée des tunnels.
Exemple de configuration :
pe11# show protocols mpls label-switched-path toPE12-bronze { transport-class bronze; } label-switched-path toPE12-gold { transport-class gold; }
Fonctionnalité de plan de transport avec classe BGP intra-AS :
- Le transport avec classe BGP crée des RIB de transport prédéfinis par classe de transport nommée (or et bronze) et dérive automatiquement la communauté de mappage à partir de sa valeur de couleur (100 et 200).
- Les routes de transport intra-AS sont renseignées dans les RIB de transport par le protocole de tunnelisation lorsqu’il est associé à une classe de transport.
Dans cet exemple, les routes RSVP LSP associées à la classe de transport or (couleur 100) et à la classe de transport bronze (couleur 200) sont installées dans les RIB de transport junos-rti-tc-<100>.inet.3 et junos-rti-tc-<200>.inet.3, respectivement.
- Les nœuds de service (PE d’entrée) font correspondre la communauté de couleurs étendue (color :0 :100 et color :0 :200) de la route de service à la communauté de mappage dans des RIB de résolution prédéfinis et résolvent le saut suivant du protocole (PNH) dans les RIB de transport correspondants (soit junos-rti-tc-<100>.inet.3, soit junos-rti-tc-<200>.inet.3).
- Les routes BGP se lient à un schéma de résolution en transportant la communauté de mappage associée.
- Chaque classe de transport crée automatiquement deux schémas de résolution prédéfinis et dérive automatiquement la communauté de mappage.
L’un des schémas de résolution permet de résoudre les routes de service qui utilisent Color :0 :<val> comme communauté de mappage.
L’autre schéma de résolution permet de résoudre les itinéraires de transport qui utilisent Transport-Target :0 :<val> comme communauté de mappage.
- Si le PNH de la route de service ne peut pas être résolu à l’aide des RIB répertoriés dans le schéma de résolution prédéfini, il peut revenir à la table de routage inet.3.
- Vous pouvez également configurer une solution de secours entre des RIB de transport de couleurs différentes à l’aide des schémas de résolution définis par l’utilisateur dans la [edit routing-options resolution scheme] hiérarchie de configuration.
Implémentation inter-AS de plans de transport de classe BGP
Dans un réseau inter-AS, BGP-LU est converti en réseau de transport de classe BGP après avoir configuré au moins deux classes de transport (or et bronze) sur tous les nœuds de service ou équipements PE et nœuds de bordure (ABR et ASBR).
Pour convertir les tunnels de transport en transport de classe BGP :
- Définissez la classe de transport au niveau des nœuds de service (équipements PE entrants) et des nœuds de bordure (ABR et ASBR), par exemple, gold et broze.
Exemple de configuration :
pe11# show routing-options route-distinguisher-id 172.16.1.1; transport-class { name gold { color 100; } name bronze { color 200; - Associez les tunnels de transport à une classe de transport spécifique au niveau du nœud d’entrée des tunnels (PE d’entrée, ABR et ASBR).
Exemple de configuration :
Pour les prestataires de services linguistiques RSVP
abr23# show protocols mpls label-switched-path toASBR21-bronze { transport-class bronze; } label-switched-path toASBR22-gold { transport-class gold;Pour l’algorithme IS-IS flxible
asbr13# show routing-options flex-algorithm 128 { … color 100; use-transport-class; } flex-algorithm 129 { … color 200; use-transport-class; } - Activez une nouvelle famille pour le transport de classe BGP (transport inet) et BGP-LU (inet labeled-unicast) dans le réseau.
Exemple de configuration :
abr23# show protocols bgp group toAs2-RR27 { family inet { labeled-unicast { … } transport { … } cluster 172.16.2.3; neighbor 172.16.2.7; } - Annoncez les itinéraires de service à partir de l’équipement PE de sortie avec la communauté de couleurs étendue appropriée.
Exemple de configuration :
pe11# show policy-options policy-statement red term 1 { from { route-filter 192.168.3.3/32 exact; } then { community add map2gold; next-hop self; accept; } } term 2 { from { route-filter 192.168.33.33/32 exact; } then { community add map2bronze; next-hop self; accept; } } community map2bronze members color:0:200; community map2gold members color:0:100;
Fonctionnalité de plan de transport avec classe BGP inter-AS :
- Les plans de transport avec classe BGP créent des RIB de transport prédéfinis par classe de transport nommée (or et bronze) et dérivent automatiquement la communauté de mappage à partir de sa valeur de couleur.
-
Lorsqu’elles sont associées à une classe de transport, les routes de transport intra-AS sont renseignées dans les RIB de transport par des protocoles de tunnelisation.
Par exemple, les voies de tunnel de transport associées à la classe de transport or et bronze sont installées dans les semi-rigides de transport junos-rti-tc-<100>.inet.3 et junos-rti-tc-<200>.inet.3, respectivement.
- Les plans de transport de classe BGP utilisent un séparateur de route et une cible de route uniques lorsqu’ils copient les itinéraires de tunnel de transport de chaque RIB de transport vers la table de routage bgp.transport.3.
- Les nœuds de bordure annoncent les routes de la table de routage bgp.transport.3 vers ses homologues dans d’autres domaines si le transport family inet est négocié dans la session BGP.
- Le nœud de bordure de réception installe ces routes bgp-ct dans la table de routage bgp.transport.3 et copie ces routes en fonction de la cible de route de transport vers les RIB de transport appropriés.
- Le nœud de service fait correspondre la communauté de couleurs dans l’itinéraire de service à une communauté de mappage dans les schémas de résolution et résout PNH dans le RIB de transport correspondant (soit junos-rti-tc-<100>.inet.3 ou junos-rti-tc-<200>. inet.3).
- Les nœuds de bordure utilisent des schémas de résolution prédéfinis pour la résolution PNH de la route de transport.
- Prédéfinis ou définis par l’utilisateur, les deux schémas de résolution prennent en charge la résolution PNH de la route de service. Le mode prédéfini utilise inet.3 comme solution de secours, et le schéma de résolution défini par l’utilisateur permet d’utiliser la liste des RIB de transport dans l’ordre spécifié lors de la résolution de PNH.
- Si le PNH de la route de service ne peut pas être résolu à l’aide des RIB répertoriés dans le schéma de résolution défini par l’utilisateur, la route est ignorée.
Présentation du transport avec classe BGP-CT (BGP-CT) avec tunnels SR-TE colorés sous-jacents
Avantages de BGP-CT avec les tunnels SR-TE colorés sous-jacents
- Résout les problèmes d’échelle qui peuvent survenir à l’avenir avec la croissance du réseau.
- Assure l’interconnectivité des domaines qui utilisent différentes technologies.
- Découple les services et les couches de transport, ce qui donne un réseau entièrement distribué.
- Fournit une gestion indépendante de la bande passante par le biais d’un contrôleur d’ingénierie du trafic intra-domaine pour SR-TE.
Les grands réseaux en croissance et en constante évolution nécessitent une architecture de routage de segments transparente. À partir de la version 21.2,R1 de Junos OS, nous prenons en charge BGP-CT avec un transport sous-jacent sous forme de tunnels SR-TE colorés. BGP-CT peut résoudre les routes de service à l’aide des RIB de transport et calculer le saut suivant. Les services actuellement pris en charge via BGP-CT peuvent également utiliser les tunnels colorés SR-TE sous-jacents pour la résolution du routage. Les services peuvent désormais utiliser les tunnels colorés SR-TE sous-jacents, tels que les tunnels colorés statiques, BGP SR-TE, RPD programmable et PCEP. BGP-CT utilise l’accessibilité du saut suivant pour résoudre les itinéraires de service sur la classe de transport souhaitée.
Pour activer la résolution de route de service BGP-CT sur des tunnels colorés SR-TE sous-jacents, incluez l’instruction au niveau de la use-transport-class[edit protocols source-packet-routing] hiérarchie.
- Activer l’instruction
use-transport-class
de même que l’instruction[edit protocols source-packet-routing]hiérarchique.auto-createau niveau de la[edit routing-options transport-class]hiérarchie. - Nous ne prenons pas en charge les groupes RIB pour les tunnels SR-TE colorés avec et SR-TE couleur uniquement avec
use-transport-classcette fonctionnalité.
Exemple : Configuration des plans de transport avec classe (intra-domaine)
- Avant de commencer
- Vue d’ensemble fonctionnelle
- Vue d’ensemble de la topologie
- Illustrations de topologie
- Étapes de configuration PE1
- Vérifier les plans de transport de classe
- Annexe 1 : Dépannage
- Annexe 2 : Définir des commandes sur tous les appareils
- Annexe 3 : Afficher la sortie de configuration sur PE1
Avant de commencer
| Exigences matérielles et logicielles |
Junos OS version 21.1R1 ou ultérieure. REMARQUE :
Seuls les routeurs de périphérie du fournisseur (PE1 et PE2) nécessitent la prise en charge de la version de Junos OS pour la fonctionnalité BGP-CT. |
|
Temps de lecture estimé |
Durée : 45 minutes |
|
Temps de configuration estimé |
1 heure |
|
À quoi faut-il s’attendre ? |
Un réseau BGP-CT fonctionnel avec trois niveaux de service qui correspondent à des chemins LSP à différents routages. Configuration Junos qui mappe un trafic spécifique (itinéraires client VPN) à la classe de transport souhaitée à l’aide de communautés étendues d’attributs de couleur BGP. Ingénierie de trafic LSP de base pour forcer les classes de trafic à emprunter différents chemins dans le réseau du fournisseur |
|
Impact sur l’entreprise |
Utilisez cet exemple de configuration pour configurer et vérifier la fonctionnalité de transport avec classe BGP (BGP-CT) au sein d’un seul réseau autonome (intra-domaine). BGP-CT mappe les chemins des clients vers des chemins réseau qui peuvent être conçus pour fournir différents niveaux de performance. Un cas d’utilisation typique du BGP-CT intradomaine est qu’un fournisseur de services déploie BGP-CT pour offrir des niveaux de service VPN hiérarchisés à ses clients. |
|
Ressources utiles : |
|
|
En savoir plus |
Pour mieux comprendre BGP-CT, reportez-vous à la section Présentation des plans de transport avec classe BGP |
|
Juniper vLabs |
Rendez-vous dans les laboratoires virtuels Juniper (vLabs) pour réserver un bac à sable préconfiguré. Utilisez le bac à sable pour interagir avec la fonctionnalité BGP-CT et la comprendre. Vous trouverez la démonstration « Classful Transport Planes (Intra-Domain Scenario) » dans la section routage . |
|
En savoir plus |
Classe de service Junos (JCOS) à la demande |
Vue d’ensemble fonctionnelle
Tableau 1 Fournit un résumé rapide des composants de configuration déployés dans cet exemple.
|
Protocoles de routage et de signalisation |
|
|
OSPF |
Tous les routeurs exécutent OSPF en tant qu’IGP. Tous les routeurs appartiennent à la zone 0 (également appelée zone dorsale). Le domaine de routage OSPF unique assure la connectivité loopback dans le réseau du fournisseur. |
|
BGP interne et externe |
Les équipements CE utilisent l’appairage EBGP pour échanger des routes avec leur équipement de périphérie fournisseur dans le cadre d’un service VPN de couche 3. Les appareils PE utilisent IBGP pour échanger des routes VPN IPv4 de couche 3 avec le PE distant. Ces routes portent également une communauté de couleurs utilisée pour mapper le trafic au tunnel de plan de données approprié. Notre exemple n’utilise pas de réflecteur de route, mais opte pour un appairage PE-PE direct. REMARQUE :
Le routeur fournisseur (routeur P) n’exécute pas BGP. Il fait partie d’un cur sans BGP pour favoriser l’évolutivité. L’équipement P utilise une commutation basée sur l’étiquette MPLS pour transporter le trafic VPN client entre les équipements PE. |
|
RSVP |
Chaque appareil PE signale trois LSP au PE distant. Ces LSP correspondent aux classes de service correspondantes : or, bronze et Best-Effort (BE). RSVP prend en charge les aspects techniques de trafic enrichis pour forcer le trafic à emprunter les chemins souhaités dans le réseau du fournisseur. Ces chemins peuvent à leur tour être conçus pour répondre aux besoins de gestion des classes de service (CoS) variés afin d’appliquer le SLA pour chaque classe de transport. Notre topologie de base prévoit trois chemins entre les dispositifs PE. Nous utilisons un chemin nommé avec un ERO pour assurer un routage diversifié des LSP sur le cur. Junos prend en charge un large éventail de fonctionnalités d’ingénierie du trafic. Pour plus de détails, voir Configuration des aspects techniques du trafic MPLS REMARQUE :
La fonctionnalité de transport avec classe est également prise en charge avec les LSP établis par le biais de tunnels SR-TE (Segment Routing–Traffic Engineering) et de l’algorithme flexible IS-IS. |
|
MPLS |
Le réseau fournisseur utilise un plan de données de commutation d’étiquettes MPLS. L’utilisation de MPLS avec des chemins TE garantit que chaque classe de service peut être acheminée sur des chemins disjoints avec les niveaux de performance souhaités. Comme indiqué ci-dessus, MPLS prend également en charge un cœur sans BGP. |
| Tunnels de transport | |
|
Trois tunnels MPLS (LSP) sont établis entre les appareils PE : |
Chaque tunnel est affecté aux classes de transport suivantes :
|
| Famille de services | |
|
VPN de couche 3 ( |
BGP-CT fonctionne également avec d’autres familles de services, telles que BGP étiqueté Unicast, Flowspec ou VPN de couche 2. |
| Tâches de vérification primaires | |
|
Vérifiez le fonctionnement des protocoles IGP, RSVP, MPLS, BGP et L3VPN. |
|
Modifiez le réseau pour effectuer une orientation du trafic entre les tunnels de classe de transport afin de simuler la défaillance d’un tunnel de service et le basculement ultérieur vers le chemin/la classe BE. |
Vue d’ensemble de la topologie
Cet exemple de configuration est basé sur un simple VPN de couche 3 basé sur MPLS avec deux périphériques CE (customer edge) qui communiquent via le réseau du fournisseur de services. Le cur du réseau comporte trois routeurs fournisseur (P) qui transportent le trafic client VPN à l’aide d’une commutation étiquetée. Les deux appareils Provider Edge (PE) fournissent un service VPN de couche 3 à leurs CE connectés. Les PE utilisent des LSP MPLS signalés RSVP pour transporter le trafic VPN sur le réseau central. Pour plus d’informations sur le fonctionnement et la configuration d’un VPN L3 basé sur MPLS, reportez-vous à la section Example: Configure a Basic MPLS-Based Layer 3 VPN .
Nous nous concentrons sur le flux de trafic de gauche à droite de CE1 vers CE2, et sur la façon dont PE1 utilise une communauté de couleurs BGP attachée aux routes apprises de PE2 pour mapper le trafic envoyé au CE distant sur les sauts suivants de transfert LSP souhaités. Dans notre exemple, PE1 utilise des objets de route explicites (ERO) pour forcer le routage de ces LSP sur des chemins différents. Nous ignorons cette étape à PE2, ce qui permet aux LSP d’être acheminés en fonction de l’équilibrage de charge IGP. Pour que le trafic passe de CE1 à CE2, CE1 doit avoir un itinéraire pour atteindre CE2. Les itinéraires pour CE2 se déplacent dans le sens inverse du trafic qu’ils attirent depuis CE1. C’est-à-dire que l’itinéraire vers le bouclage de CE2 se déplace de droite à gauche.
Dans notre exemple, le LSP de classe de service Gold est contraint au chemin PE1-P1-PE2. La classe de service bronze utilise la voie PE1-P2-PE2. Le LSP le plus efficace est acheminé le long du chemin PE1-P3-PE2. Le diagramme topologique utilise des liens colorés pour représenter les trois chemins.
Dans notre exemple, nous ajoutons l’instruction protocols mpls icmp-tunneling . Cela permet aux appareils CE de tracer le chemin à travers le réseau du fournisseur, même lorsque ce chemin implique une commutation MPLS, comme c’est le cas pour le trafic VPN de couche 3. Cette option vous permet de confirmer que le chemin de transfert attendu en fonction de la classe de transport est utilisé.
Tableau 2 décrit le rôle et les fonctionnalités de chaque équipement dans le contexte de cette topologie. Cliquez sur n’importe quel nom d’appareil pour afficher sa configuration rapide.
| Nom de l'appareil |
Rôle |
Fonction |
| CE1 | Dispositif CE local (R1) . | Peer EBGP au routeur PE1 pour annoncer et apprendre les adresses de bouclage des périphériques CE. Testez la connectivité du service avec des pings vers l’adresse de bouclage de CE2. |
| CE2 | Dispositif CE à distance (R7) | Appairage EBGP sur le routeur PE2 pour annoncer et apprendre les adresses de bouclage des périphériques CE. Configure et attache la communauté de mappage des couleurs. |
| PE1 (DUT) | périphérique PE local (R2). | PE1 mappe les itinéraires de service étiquetés par couleur qui partent de CE2 à une classe de transport (TC) coparrainante. PE1 reçoit les routes des balises de couleur via sa session IBGP vers PE2. Dans cet exemple, PE1 utilise des contraintes basées sur ERO pour forcer un routage diversifié de ses trois LSP sur le cur du fournisseur. |
| PE2 | Dispositif PE à distance (R6). | PE2 annonce à nouveau les routes étiquetées par couleur reçues par CE2 vers PE1 à l’aide d’IBGP. Ces routes utilisent la inet-vpn famille pour prendre en charge des services VPN de couche 3 avec des TC mappés en couleur. |
| P1 P2 P3 P3 | Appareils fournisseur P1, P2 et P3 (R3, R4 et R5). | Les appareils P1-P3 représentent le réseau central du fournisseur de services. Il s’agit de purs périphériques de transit qui effectuent une commutation d’étiquettes MPLS pour transporter le trafic CE envoyé sur le VPN L3. |
Illustrations de topologie
Étapes de configuration PE1
Pour plus d’informations sur la navigation dans l’interface de ligne de commande, consultez Utilisation de l’éditeur CLI en mode configuration
Pour une configuration complète sur tous les appareils, voir :
Dans cet exemple, cette section met en évidence les principales tâches de configuration nécessaires à la configuration de l’appareil PE1. La première étape est commune à la configuration d’un service VPN de couche 3 de base. Les étapes suivantes sont spécifiques à l’ajout de la fonctionnalité BGP-CT à votre VPN de couche 3. Les deux appareils PE ont une configuration similaire, ici nous nous concentrons sur PE1.
-
Tout d’abord, provisionnez le VPN de couche 3 général :
-
Configurez et numérotez les interfaces de bouclage, orientées vers le cur et vers le CE pour IPv4. Assurez-vous d’activer la famille sur les interfaces centrales qui se connectent aux périphériques P pour prendre en charge la
mplscommutation MPLS. -
Configurez un numéro de système autonome.
-
Configurez l’OSPF monozone sur les interfaces de bouclage et de cur.
-
Configurez RSVP sur les interfaces de bouclage et de cur.
-
Configurez la session d’appairage IBGP sur l’équipement PE distant, PE2. Incluez la
inet-vpnfamille d’adresses pour prendre en charge un VPN IPv4 de couche 3. -
Configurez une instance de routage basée sur VRF pour le périphérique CE1. Utilisez EBGP comme protocole de routage PE-CE.
[edit] set interfaces ge-0/0/1 unit 0 family inet address 10.1.23.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 description "Link from PE1 to P2" set interfaces ge-0/0/2 unit 0 family inet address 10.1.24.1/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 description "Link from PE1 to P3" set interfaces ge-0/0/3 unit 0 family inet address 10.1.25.1/24 set interfaces ge-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.1/32
[edit] set routing-instances CE1_L3vpn instance-type vrf set routing-instances CE1_L3vpn protocols bgp group CE1 type external set routing-instances CE1_L3vpn protocols bgp group CE1 peer-as 64510 set routing-instances CE1_L3vpn protocols bgp group CE1 neighbor 172.16.1.1 set routing-instances CE1_L3vpn interface ge-0/0/0.0 set routing-instances CE1_L3vpn route-distinguisher 192.168.0.1:12 set routing-instances CE1_L3vpn vrf-target target:65412:12
[edit] set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.1 set protocols bgp group ibgp family inet unicast set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.2 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/1.0 set protocols rsvp interface ge-0/0/2.0 set protocols rsvp interface ge-0/0/3.0
[edit] set routing-options route-distinguisher-id 192.168.0.1 set routing-options autonomous-system 65412
-
-
Ajoutez des plans de transport avec classe au VPN de couche 3.
Configurez les classes de transport or et bronze.
Il s’agit d’une étape critique dans la configuration de la fonctionnalité de transport avec classe. Ces classes de transport sont mappées à des LSP signalés RSVP (et éventuellement issus de l’ingénierie du trafic) qui traversent le noyau du fournisseur. Les routes distantes apprises à partir de CE2 sont marquées avec des communautés de couleurs qui correspondent à ces classes de transport et, ce faisant, au LSP souhaité entre les périphériques PE.
[edit] set routing-options transport-class name gold color 100 set routing-options transport-class name bronze color 200 set routing-options resolution preserve-nexthop-hierarchy
-
Configurez trois LSP de PE1 à PE2 avec un routage contraint qui les oblige à passer par un routeur P différent. Deux de ces LSP correspondent aux gold classes et bronze transport. Le LSP d’or est acheminé par P1, le bronze par P2 et le meilleur effort par le dispositif P3.
Une fois mappé aux classes de transport, le fournisseur de services est en mesure de placer un trafic client spécifique, comme indiqué par une communauté de couleurs BGP, sur un LSP spécifique. Avec ce mappage couleur-LSP, le fournisseur de services peut offrir un service hiérarchisé avec différents SLA.
Dans notre exemple, nous utilisons un ERO strict pour nous assurer que les trois LSP sont acheminés de manière différente sur les trois chemins disponibles dans la topologie.
[edit] set protocols mpls label-switched-path lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path lsp_to_pe2 primary best-effort set protocols mpls label-switched-path gold_lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path gold_lsp_to_pe2 preference 5 set protocols mpls label-switched-path gold_lsp_to_pe2 primary gold set protocols mpls label-switched-path gold_lsp_to_pe2 transport-class gold set protocols mpls label-switched-path bronze_lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path bronze_lsp_to_pe2 preference 5 set protocols mpls label-switched-path bronze_lsp_to_pe2 primary bronze set protocols mpls label-switched-path bronze_lsp_to_pe2 transport-class bronze set protocols mpls path gold 10.1.23.2 strict set protocols mpls path bronze 10.1.24.2 strict set protocols mpls path best-effort 10.1.25.2 strict set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols mpls interface ge-0/0/3.0
-
Pour faciliter le repli vers le tunnel de classe de service par défaut (best-effort), nous configurons les tunnels de classe de transport Gold et Bronze avec une préférence globale inférieure. Dans cet exemple, la valeur de préférence passe de 7 à 5 par défaut. Cela permet d’utiliser le tunnel au mieux comme solution de repli au cas où les tunnels d’or ou de bronze deviendraient inutilisables. En définissant une préférence plus faible (plus préférable) sur les tunnels or et bronze, vous vous assurez qu’ils sont sélectionnés pour le transfert, même si l’itinéraire de service est en mesure de se résoudre dans le tunnel au mieux.
REMARQUE :Cette section s’est concentrée sur la configuration requise sur l’appareil PE1. Il convient de noter que pour que la fonction de sélection du prochain saut de transport avec classe fonctionne à PE1, les routes de périphérique CE2 distantes doivent être étiquetées avec une communauté de couleurs. Ce balisage peut se produire sur l’équipement PE2 distant ou sur l’équipement CE2 distant. Nous montrons ici cette dernière approche par souci d’exhaustivité :
-
Faites correspondre les balises de communauté de couleurs ajoutées au CE2 distant aux définitions de classe de transport pour les TC bronze et or.
[edit] set policy-options policy-statement adv_direct term 1 from protocol direct set policy-options policy-statement adv_direct term 1 from route-filter 172.16.0.0/16 orlonger set policy-options policy-statement adv_direct term 1 then community add map2bronze set policy-options policy-statement adv_direct term 1 then accept set policy-options community map2bronze members color:0:200 set policy-options community map2gold members color:0:100
Vérifier les plans de transport de classe
Dans cette section, nous nous concentrons sur les commandes qui illustrent une fonctionnalité de transport de classe ouvrière. Voir l’annexe 1 : Dépannage des commandes utilisées pour vérifier la fonctionnalité sous-jacente requise par la fonctionnalité de transport avec classe.
Vous allez utiliser ces commandes pour vérifier que le transport avec classe BGP fonctionne correctement.
| Commande |
Tâche de vérification |
| show routing transport-class | Vérifiez les classes de transport et leurs attributs associés. Cela inclut la communauté de mappage et l’instance de routage. |
| Afficher le schéma de résolution d’itinéraire | Affichez la façon dont les routes de classe de service sont résolues en sauts suivants LSP. Vérifiez les tables de routage de résolution pour un itinéraire spécifique. |
| show route receiving-protocol bgp pe2-loopback-address | Vérifiez qu’une communauté de couleurs BGP est attachée aux routes VPN reçues par PE1. |
| show route et show route forwarding-table vpn https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/ref/command/show-route.htmlvpn | Vérifiez la sélection du tunnel de transport en affichant le protocole nexthop (PNH) pour les routes à PE1. |
| afficher les statistiques mpls lsp et show route forwarding-table | Vérifiez le tunnel de transport utilisé par un itinéraire de classe de transport spécifique. |
- Vérifier les classes de transport et les tunnels de transport
- Vérifier les schémas de résolution du saut suivant
- Vérification du balisage des couleurs et de la sélection du saut suivant pour les routes CE2
- Vérifier la connectivité de bout en bout
- Confirmez le basculement au mieux-effort
Vérifier les classes de transport et les tunnels de transport
But
PE1 et PE2 utilisent des tunnels de transport MPLS signalés RSVP pour prendre en charge un service VPN de couche 3 capable d’offrir des niveaux de service différenciés. Les sauts suivants de ces routes de service sont résolus dans un tunnel MPLS spécifique en fonction de la classe de service correspondante. La classe de service est signalée par l’attachement d’une communauté de couleurs BGP aux routes client VPN.
Dans cette partie, vous confirmez que les trois LSP de PE1 sont opérationnels, qu’ils sont mappés à la classe de transport correcte et qu’ils sont correctement acheminés sur le cœur du fournisseur.
Action
À partir du mode opérationnel, entrez la show route 192.168.0.2 commande.
user@PE1 show route 192.168.0.2
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.2/32 *[OSPF/10] 00:27:20, metric 2
to 10.1.24.2 via ge-0/0/2.0
> to 10.1.25.2 via ge-0/0/3.0
to 10.1.23.2 via ge-0/0/1.0
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.2/32 *[RSVP/7/1] 00:13:09, metric 2
> to 10.1.25.2 via ge-0/0/3.0, label-switched-path lsp_to_pe2
junos-rti-tc-100.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.2/32 *[RSVP/5/1] 00:13:11, metric 2
> to 10.1.23.2 via ge-0/0/1.0, label-switched-path gold_lsp_to_pe2
junos-rti-tc-200.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.2/32 *[RSVP/5/1] 00:13:08, metric 2
> to 10.1.24.2 via ge-0/0/2.0, label-switched-path bronze_lsp_to_pe2Sens
La sortie confirme que PE1 a appris trois chemins vers le bouclage de PE2 via OSPF. Ces itinéraires sont dans le inet.0 tableau. Vous notez également que les trois LSP sont représentés comme des prochains sauts viables pour atteindre PE2. Notez que chacun de ces LSP est hébergé dans une table de routage différente. La partie en surbrillance des sauts IP suivants (et le nom de l’interface correspondant) confirme le routage LSP diversifié souhaité sur le cœur. Le trafic mappé au chemin gold est envoyé à la version 10.1.23.2, tandis que le trafic pour bronze et BE est envoyé à la version 10.1.24.2 et 10.1.25.2, respectivement.
Les RIB de transport et les tunnels de transport suivants sont créés.
-
junos-rti-tc-100.inet.3pour gold_lsp_to_pe2 -
junos-rti-tc-200.inet.3pour bronze_lsp_to_pe2 -
inet.3pour lsp_to_pe2
Vérifier les schémas de résolution du saut suivant
But
Vérifiez les schémas de résolution des routes de service, la communauté de mappage associée et la façon dont le tronçon suivant se résout sur les tables de routage contributives.
Action
À partir du mode opérationnel, entrez la show route resolution scheme all commande.
user@PE1> show route resolution scheme all Resolution scheme: junos-resol-schem-tc-100-v4-service References: 1 Mapping community: color:0:100 Resolution Tree index 1, Nodes: 1 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-100.inet.3 inet.3 Resolution scheme: junos-resol-schem-tc-100-v4-transport References: 1 Mapping community: transport-target:0:100 Resolution Tree index 3, Nodes: 1 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-100.inet.3 Resolution scheme: junos-resol-schem-tc-100-v6-service References: 1 Mapping community: color:0:100 Resolution Tree index 2, Nodes: 0 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-100.inet6.3 inet6.3 Resolution scheme: junos-resol-schem-tc-100-v6-transport References: 1 Mapping community: transport-target:0:100 Resolution Tree index 4, Nodes: 0 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-100.inet6.3 Resolution scheme: junos-resol-schem-tc-200-v4-service References: 1 Mapping community: color:0:200 Resolution Tree index 5, Nodes: 1 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-200.inet.3 inet.3 Resolution scheme: junos-resol-schem-tc-200-v4-transport References: 1 Mapping community: transport-target:0:200 Resolution Tree index 7, Nodes: 1 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-200.inet.3 Resolution scheme: junos-resol-schem-tc-200-v6-service References: 1 Mapping community: color:0:200 Resolution Tree index 6, Nodes: 0 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-200.inet6.3 inet6.3 Resolution scheme: junos-resol-schem-tc-200-v6-transport References: 1 Mapping community: transport-target:0:200 Resolution Tree index 8, Nodes: 0 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-200.inet6.3
Sens
En vous concentrant sur les parties IPv4 de la sortie, vous voyez que la junos-tc-100 (gold) classe de transport a deux schémas de résolution - et - junos-resol-schem-tc-100-v4-service utilisés pour les routes de service et junos-resol-schem-tc-100-v4-transport de transport, respectivement.
Le schéma de résolution pour les routes de service Gold () fournit une résolution à la fois sur les tables de routage et sur les inet.3 tables de routage (junos-resol-schem-tc-100-v4-servicemises en évidence dans l’exemple de junos-rti-tc-100.inet.3 sortie). La liste des tables de résolution de service et de BE est la façon dont la solution de secours se produit lorsque la classe de service est inactive. Rappelez-vous que c’est la raison pour laquelle nous avons modifié la valeur de préférence des LSP de service (en définissant la préférence sur 5 plutôt que sur 7 par défaut), pour s’assurer que la route de service est toujours préférée à la solution de secours BE.
Vérification du balisage des couleurs et de la sélection du saut suivant pour les routes CE2
But
Vérifiez que PE2 annonce la route de bouclage pour CE2 avec une communauté de couleurs qui sélectionne la classe de service bronze (couleur 200).
Dans notre exemple, nous configurons le périphérique CE2 pour attacher la communauté de couleurs. PE2 laisse cette communauté en place lorsqu’elle annonce à nouveau l’itinéraire vers PE1. Cela signifie que le client VPN est en mesure d’effectuer ses propres mappages de classe de service. Lorsqu’il le souhaite, le routeur PE peut blanchir ou dénuder toutes les communautés reçues du CE. Dans ce cas, le périphérique PE doit être configuré pour attacher la communauté de mappage de couleurs souhaitée aux routes CE avant de les annoncer à nouveau à PE1.
Action
À partir du mode opérationnel, entrez la show route receive-protocol bgp 192.168.0.2 172.16.255.2 detail commande.
user@PE1> show route receive-protocol bgp 192.168.0.2 172.16.255.2 detail
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
* 172.16.255.2/32 (1 entry, 1 announced)
Import Accepted
Route Distinguisher: 192.168.0.2:12
VPN Label: 299808
Nexthop: 192.168.0.2
Localpref: 100
AS path: 64520 I
Communities: target:65412:12 color:0:200
Affichez l’entrée de la table de transfert pour le bouclage CE2 dans l’instance de routage VPN à PE1. Vérifiez que le prochain saut de transfert correspond à la classe de transport souhaitée (bronze). Utilisez la show route forwarding-table vpn CE1_L3vpn destination 172.16.255.2 extensive commande.
user@PE1> show route forwarding-table vpn CE1_L3vpn destination 172.16.255.2 extensive
Routing table: CE1_L3vpn.inet [Index 10]
Internet:
Destination: 172.16.255.2/32
Route type: user
Route reference: 0 Route interface-index: 0
Multicast RPF nh index: 0
P2mpidx: 0
Flags: sent to PFE, prefix load balance
Next-hop type: indirect Index: 1048574 Reference: 2
Nexthop:
Next-hop type: composite Index: 662 Reference: 2
Load Balance Label: Push 299808, None
Nexthop: 10.1.24.2
Next-hop type: Push 299872 Index: 653 Reference: 2
Load Balance Label: None
Next-hop interface: ge-0/0/2.0 Sens
Les entrées en surbrillance confirment que le trafic correspondant à l’itinéraire de bouclage CE2 est envoyé à 10.1.24.2 à l’aide de l’interface ge-0/0/2. Rappel des ERO utilisés pour les LSP, cette interface et le saut suivant sont associés au LSP bronze et à la classe de transport. L’étiquette 299808 est utilisée pour identifier le service VRF. L’étiquette de transport RSVP extérieure est 299872.
Vous confirmez rapidement qu’il s’agit de l’étiquette de transport RSVP correcte pour la classe bronze à l’aide d’une show rsvp session detail name bronze_lsp_to_pe2 commande
root@PE1> show rsvp session detail name bronze_lsp_to_pe2 Ingress RSVP: 3 sessions 192.168.0.2 From: 192.168.0.1, LSPstate: Up, ActiveRoute: 0 LSPname: bronze_lsp_to_pe2, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 299872 Resv style: 1 FF, Label in: -, Label out: 299872 Time left: -, Since: Tue Aug 16 12:17:12 2022 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 2 receiver 23256 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 10.1.24.2 (ge-0/0/2.0) 1 pkts RESV rcvfrom: 10.1.24.2 (ge-0/0/2.0) 1 pkts, Entropy label: Yes Explct route: 10.1.24.2 10.1.46.2 Record route: <self> 10.1.24.2 10.1.46.2 Total 1 displayed, Up 1, Down 0
Les parties en surbrillance indiquent que le LSP bronze est acheminé via le périphérique P2 et qu’il est associé à l’étiquette299856 de transport RSVP () que vous avez précédemment confirmée dans le table de transfert VPN pour l’adresse de bouclage CE2.
Vérifier la connectivité de bout en bout
But
Vérifiez la connectivité de bout en bout sur le domaine du fournisseur en effectuant un ping entre CE1 et CE2. Vous examinez les statistiques de trafic MPLS pour confirmer que la classe de transport bronze est utilisée.
Action
À partir du mode opérationnel, entrez la ping commande.
user@CE1> ping 172.16.255.2 source 172.16.255.1 count 100 rapid PING 172.16.255.2 (172.16.255.2): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! --- 172.16.255.2 ping statistics --- 100 packets transmitted, 100 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.647/3.589/30.264/2.695 ms
À partir du mode opérationnel à PE1, entrez la show mpls lsp statistics commande.
user@PE1> show mpls lsp statistics Ingress LSP: 3 sessions To From State Packets Bytes LSPname 192.168.0.2 192.168.0.1 Up 100 8400 bronze_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 0 gold_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 0 lsp_to_pe2 Total 3 displayed, Up 3, Down 0 <output truncated for brevity>
Action
Tracez l’itinéraire de CE1 au bouclage de CE2. Notre configuration inclut l’instruction icmp-tunneling de prise en charge d’une route de trace basée sur ICMP avec des sauts MPLS dans le noyau du fournisseur.
user@CE1> traceroute no-resolve 172.16.255.2
traceroute to 172.16.255.2 (172.16.255.2), 30 hops max, 52 byte packets
1 172.16.1.2 2.174 ms 1.775 ms 1.917 ms
2 10.1.24.2 5.171 ms 5.768 ms 4.900 ms
MPLS Label=299872 CoS=0 TTL=1 S=0
MPLS Label=299808 CoS=0 TTL=1 S=1
3 10.1.46.2 4.707 ms 4.347 ms 4.419 ms
MPLS Label=299808 CoS=0 TTL=1 S=1
4 172.16.255.2 5.640 ms 5.851 ms 44.777 ms
Sens
L’échange ping est réussi et les statistiques confirment l’utilisation du tunnel de transport en bronze. C’est normal étant donné que la route vers CE2 a la communauté de 200 couleurs attachée. Les résultats de l’itinéraire de suivi confirment que le trafic est transféré via un LSP et que ce LSP est transféré via la version 10.1.24.2. Il s’agit de l’adresse IP attribuée à l’appareil P2. Le tronçon suivant de transfert et la valeur de l’étiquette externe confirment que ce trafic est envoyé sur le LSP de classe de service bronze.
Confirmez le basculement au mieux-effort
But
Descendez le LSP de transport Bronze pour vérifier que le trafic envoyé à CE2 bascule vers le chemin BE.
Action
Passez en mode de configuration et spécifiez un tronçon suivant non valide en tant qu’ERO pour le tunnel de transport Bronze. L’incapacité de satisfaire à l’exigence de l’ERO entraîne la chute du PSL connexe.
[edit] user@PE1# set protocols mpls path bronze 10.1.66.6 strict
Une fois le changement validé, le tunnel de bronze est affiché vers le bas :
root@PE1> show mpls lsp ingress Ingress LSP: 3 sessions To From State Rt P ActivePath LSPname 192.168.0.2 0.0.0.0 Dn 0 - bronze_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 * gold gold_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 * best-effort lsp_to_pe2
Répétez les ping commandes et trace route de CE1 vers le bouclage de CE2.
root@CE1> ping 172.16.255.2 source 172.16.255.1 count 100 rapid
PING 172.16.255.2 (172.16.255.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
--- 172.16.255.2 ping statistics ---
100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.164/5.345/12.348/1.240 ms
root@CE1> traceroute no-resolve 172.16.255.2
traceroute to 172.16.255.2 (172.16.255.2), 30 hops max, 52 byte packets
1 172.16.1.2 2.493 ms 1.766 ms 1.913 ms
2 10.1.25.2 5.211 ms 5.016 ms 5.514 ms
MPLS Label=299808 CoS=0 TTL=1 S=0
MPLS Label=299808 CoS=0 TTL=1 S=1
3 10.1.56.2 4.216 ms 4.467 ms 4.551 ms
MPLS Label=299808 CoS=0 TTL=1 S=1
4 172.16.255.2 5.492 ms 5.543 ms 5.112 msAffichez à nouveau les statistiques MPLS sur PE1.
user@PE1> show mpls lsp statistics root@PE1> show mpls lsp statistics Ingress LSP: 3 sessions To From State Packets Bytes LSPname 192.168.0.2 0.0.0.0 Dn NA NA bronze_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 0 gold_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 100 8400 lsp_to_pe2 Total 3 displayed, Up 2, Down 1 . . .
Sens
L’échange de ping réussit toujours, bien qu’il soit maintenant sur la voie du meilleur effort. Sur le PE, les statistiques confirment l’utilisation du tunnel de transport best effort. L’itinéraire de suivi montre que PE1 transfère maintenant vers le saut suivant 10.1.25.2 via PE3. Cela confirme le basculement d’une classe de transport colorée vers la classe de meilleur effort en cas de défaillance du tunnel de transport.
Dans cette section, nous avons effectué le basculement vers la classe BE en abaissant le LSP mappé à la classe de service bronze. Vous pouvez également modifier la stratégie d’exportation EBGP sur l’équipement CE2 afin qu’il soit associé à la communauté de couleurs or (100). Avec cette approche, vous vous attendez à ce que le trafic ping de CE1 à CE2 prenne le LSP d’or plutôt que de basculer vers BE. Ce qui suit fait l’affaire à CE2 si vous préférez cette approche. Assurez-vous de valider les modifications à CE2.
[edit] root@CE2# delete policy-options policy-statement adv_direct term 1 then community add map2bronze root@CE2# set policy-options policy-statement adv_direct term 1 then community add map2gold
Annexe 1 : Dépannage
Notre section de vérification est basée sur l’hypothèse que vous disposez d’un réseau fonctionnel, ce qui permet de mettre l’accent sur la confirmation du fonctionnement de BGP-CT. Dans un contexte VPN de couche 3 basé sur MPLS, la fonctionnalité BGP-CT dépend d’un réseau doté d’interfaces fonctionnelles, IGP, RSVP, MPLS et BGP.
Tableau 4 fournit des conseils sur les éléments à rechercher si votre solution BGP-CT ne fonctionne pas comme prévu. Le tableau est structuré de bas en haut, en commençant par la connectivité de base de l’interface et en terminant par l’échange de routes BGP réussi entre les périphériques PE.
Dans le cadre de cet exemple, vous configurez une adresse de bouclage et un ID de routeur. Si l’appareil avait auparavant un RID différent, il peut s’écouler un certain temps avant que les choses ne se stabilisent. Changer le RID est très perturbant et ce n’est pas quelque chose qui arrive souvent. Dans un environnement de laboratoire, il est suggéré d’exécuter la commande de mode opérationnel sur tous les périphériques juste après la restart routing validation du nouveau RID.
| Couche fonctionnelle |
Approche de vérification |
| Interfaces et adressage IP | Vérifiez que toutes les interfaces de votre topologie sont opérationnelles. Vérifiez que vous pouvez envoyer une requête ping à l’extrémité locale et à l’extrémité distante de chaque lien. Comme la plupart des réseaux, les protocoles et services de cet exemple nécessitent une infrastructure IPv4 fonctionnelle.root@PE1> show interfaces terse | match "(ge-0/0/0|ge-0/0/1|ge-0/0/2|ge-0/0/3)"
ge-0/0/0 up up
ge-0/0/0.0 up up inet 172.16.1.2/30
ge-0/0/1 up up
ge-0/0/1.0 up up inet 10.1.23.1/24
ge-0/0/2 up up
ge-0/0/2.0 up up inet 10.1.24.1/24
ge-0/0/3 up up
ge-0/0/3.0 up up inet 10.1.25.1/24
root@PE1> ping 10.1.23.2 count 1
PING 10.1.23.2 (10.1.23.2): 56 data bytes
64 bytes from 10.1.23.2: icmp_seq=0 ttl=64 time=2.951 ms
--- 10.1.23.2 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.951/2.951/2.951/0.000 ms
root@PE1> ping 172.16.1.1 routing-instance CE1_L3vpn count 1
PING 172.16.1.1 (172.16.1.1): 56 data bytes
64 bytes from 172.16.1.1: icmp_seq=0 ttl=64 time=2.755 ms
--- 172.16.1.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.755/2.755/2.755/0.000 ms
|
| Routage OSPF (IGP) | Vérifiez que tous les appareils du fournisseur disposent de toutes les contiguïtés OSPF attendues. Utilisez les commandes et show ospf interfacesshow ospf neighbors en mode opérationnel. Affichez les routes pour les adresses de bouclage du fournisseur et confirmez les chemins OSPF valides pour toutes les adresses de bouclage distantes (show route protocol ospf | match 192.168.0). Envoyez une requête ping depuis le bouclage local vers les adresses de bouclage à distance de tous les routeurs du fournisseur.Cet exemple utilise des LSP basés sur CSPF. Cela nécessite qu’OSPF soit configuré avec l’instruction root@PE1> show ospf interface Interface State Area DR ID BDR ID Nbrs ge-0/0/1.0 BDR 0.0.0.0 192.168.0.11 192.168.0.1 1 ge-0/0/2.0 BDR 0.0.0.0 192.168.0.12 192.168.0.1 1 ge-0/0/3.0 DR 0.0.0.0 192.168.0.1 192.168.0.13 1 lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0 root@PE1> show ospf neighbor Address Interface State ID Pri Dead 10.1.23.2 ge-0/0/1.0 Full 192.168.0.11 128 34 10.1.24.2 ge-0/0/2.0 Full 192.168.0.12 128 32 10.1.25.2 ge-0/0/3.0 Full 192.168.0.13 128 37 root@PE1> show route protocol ospf| match 192.168.0 192.168.0.2/32 *[OSPF/10] 00:10:15, metric 2 192.168.0.11/32 *[OSPF/10] 00:18:40, metric 1 192.168.0.12/32 *[OSPF/10] 00:18:35, metric 1 192.168.0.13/32 *[OSPF/10] 00:10:15, metric 1 root@PE1> ping 192.168.0.2 source 192.168.0.1 count 1 PING 192.168.0.2 (192.168.0.2): 56 data bytes 64 bytes from 192.168.0.2: icmp_seq=0 ttl=63 time=3.045 ms --- 192.168.0.2 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.045/3.045/3.045/0.000 ms |
| MPLS et RSVP | Vérifiez que toutes les interfaces principales sont activées pour la mpls famille. à l’aide d’une show interfaces terse commande. Vérifiez également que toutes les interfaces fournisseur sont activées dans les protocols mpls hiérarchies et protocols RSVP . Utilisez les show mpls interfaces commandes et show rsvp interfaces . REMARQUE :
Assurez-vous que les numéros d’unité d’interface corrects sont répertoriés pour la famille MPLS et pour chaque protocole. Cet exemple utilise l’unité 0, qui est le numéro d’unité par défaut, sur toutes les interfaces. root@PE1> show rsvp interface
RSVP interface: 4 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
ge-0/0/1.0 Up 1 100% 1000Mbps 1000Mbps 0bps 0bps
ge-0/0/2.0 Up 1 100% 1000Mbps 1000Mbps 0bps 0bps
ge-0/0/3.0 Up 1 100% 1000Mbps 1000Mbps 0bps 0bps
lo0.0 Up 0 100% 0bps 0bps 0bps 0bps
root@PE1> show mpls interface
Interface State Administrative groups (x: extended)
ge-0/0/1.0 Up <none>
ge-0/0/2.0 Up <none>
ge-0/0/3.0 Up <none>Sur les routeurs PE, vérifiez que les LSP sont correctement définis pour sortir à l’adresse de bouclage du périphérique PE distant. Vérifiez que les ERO et toutes les autres contraintes TE sont valides. Utilisez les REMARQUE : Nos exemples utilisent des LSP basés sur CSPF. Pour ce faire, l’IGP doit prendre en charge une base de données TE (TED). Si OSPF est l’IGP, assurez-vous d’inclure l’instruction de
traffic-engieering configuration. Vous pouvez également envisager d’utiliser l’énoncé de la définition LSP pour supprimer CSPF de l’équation no-cspf .root@PE1> show mpls lsp Ingress LSP: 3 sessions To From State Rt P ActivePath LSPname 192.168.0.2 192.168.0.1 Up 0 * bronze bronze_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 * gold gold_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 * best-effort lsp_to_pe2 Total 3 displayed, Up 3, Down 0 Egress LSP: 3 sessions To From State Rt Style Labelin Labelout LSPname 192.168.0.1 192.168.0.2 Up 0 1 FF 3 - bronze_lsp_to_pe1 192.168.0.1 192.168.0.2 Up 0 1 FF 3 - gold_lsp_to_pe1 192.168.0.1 192.168.0.2 Up 0 1 FF 3 - lsp_to_pe1 Total 3 displayed, Up 3, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0 |
| BGP | Utilisez la commande sur les périphériques PE pour confirmer que leur session EBGP vers le CE et la show bgp summarysession IBGP vers le PE distant sont établies. Si BGP est en panne malgré la possibilité d’envoyer un ping, suspectez une mauvaise définition de l’homologue. Rappelez-vous que l’appairage de bouclage (pour IBGP) nécessite l’instruction local-address . Pour EBGP, spécifiez les sauts suivants directement connectés et confirmez que le numéro AS local, sous et le numéro AS distant, sous edit routing-options le groupe de homologues EBGP, sont spécifiés.Vérifiez que la famille est activée pour la root@PE1> show bgp summary
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
0 0 0 0 0 0
bgp.l3vpn.0
2 2 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
172.16.1.1 64510 55 55 0 0 23:13 Establ
CE1_L3vpn.inet.0: 1/2/2/0
192.168.0.2 65412 57 56 0 0 23:11 Establ
inet.0: 0/0/0/0
bgp.l3vpn.0: 2/2/2/0
CE1_L3vpn.inet.0: 2/2/2/0Les commandes show route advertising et receiving protocol sont utiles pour confirmer les routes qu’un interlocuteur BGP donné annonce ou reçoit, respectivement. root@PE1> show route advertising-protocol bgp 192.168.0.2 CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.1.0/30 Self 100 I * 172.16.255.1/32 Self 100 64510 I root@PE1> show route receive-protocol bgp 192.168.0.2 inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden) inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.2.0/30 192.168.0.2 100 I * 172.16.255.2/32 192.168.0.2 100 64520 I junos-rti-tc-100.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) junos-rti-tc-200.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 192.168.0.2:12:172.16.2.0/30 * 192.168.0.2 100 I 192.168.0.2:12:172.16.255.2/32 * 192.168.0.2 100 64520 I |
| VPN de couche 3 | Assurez-vous que la session IBGP prend en charge family inet-vpn les routes. Vérifiez que les routes annoncées par Remote PE sont importées dans l’instance correcte en fonction de la cible de route. Assurez-vous que la stratégie d’importation et d’exportation utilisée dans l’instance de routage de chaque PE correspond aux routes correctes et publiez-les. Certains affichages de la section de vérification BGP confirment la réception de routes CE distantes et l’importation de ces routes dans l’instance VRF. root@PE1> show bgp neighbor 192.168.0.2 | match nlri
NLRI for restart configured on peer: inet-unicast inet-vpn-unicast
NLRI advertised by peer: inet-unicast inet-vpn-unicast
NLRI for this session: inet-unicast inet-vpn-unicast
root@PE1> show route table CE1_L3vpn.inet
root@PE1> show route receive-protocol bgp 192.168.0.2 172.16.255.2 detail
. . .
CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
* 172.16.255.2/32 (1 entry, 1 announced)
Import Accepted
Route Distinguisher: 192.168.0.2:12
VPN Label: 299776
Nexthop: 192.168.0.2
Localpref: 100
AS path: 64520 I
Communities: target:65412:12 color:0:200
root@PE1> show route table CE1_L3vpn.inet
CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.0/30 *[Direct/0] 00:30:11
> via ge-0/0/0.0
[BGP/170] 00:29:57, localpref 100
AS path: 64510 I, validation-state: unverified
> to 172.16.1.1 via ge-0/0/0.0
172.16.1.2/32 *[Local/0] 00:30:11
Local via ge-0/0/0.0
172.16.2.0/30 *[BGP/170] 00:21:26, localpref 100, from 192.168.0.2
AS path: I, validation-state: unverified
> to 10.1.25.2 via ge-0/0/3.0, label-switched-path lsp_to_pe2
172.16.255.1/32 *[BGP/170] 00:29:57, localpref 100
AS path: 64510 I, validation-state: unverified
> to 172.16.1.1 via ge-0/0/0.0
172.16.255.2/32 *[BGP/170] 00:29:40, localpref 100, from 192.168.0.2
AS path: 64520 I, validation-state: unverified
> to 10.1.24.2 via ge-0/0/2.0, label-switched-path bronze_lsp_to_pe2Vérifiez que l’équipement CE reçoit et annonce les routes attendues à l’aide des méthodes décrites pour le dépannage BGP. |
Annexe 2 : Définir des commandes sur tous les appareils
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la hiérarchie [modifier].
CE1
set interfaces ge-0/0/0 unit 0 description "Link from CE1 to PE1 for Layer 3 VPN" set interfaces ge-0/0/0 unit 0 family inet address 172.16.1.1/30 set interfaces lo0 unit 0 family inet address 172.16.255.1/32 set policy-options policy-statement adv_direct term 1 from protocol direct set policy-options policy-statement adv_direct term 1 from route-filter 172.16.0.0/16 orlonger set policy-options policy-statement adv_direct term 1 then accept set protocols bgp group ToPE1 type external set protocols bgp group ToPE1 export adv_direct set protocols bgp group ToPE1 peer-as 65412 set protocols bgp group ToPE1 neighbor 172.16.1.2 set routing-options router-id 172.16.255.1 set routing-options autonomous-system 64510 set system host-name CE1
CE2
set interfaces ge-0/0/0 unit 0 description "Link from CE2 to PE2 for Layer 3 VPN" set interfaces ge-0/0/0 unit 0 family inet address 172.16.2.1/30 set interfaces lo0 unit 0 family inet address 172.16.255.2/32 set policy-options policy-statement adv_direct term 1 from protocol direct set policy-options policy-statement adv_direct term 1 from route-filter 172.16.0.0/16 orlonger set policy-options policy-statement adv_direct term 1 then community add map2bronze set policy-options policy-statement adv_direct term 1 then accept set policy-options community map2bronze members color:0:200 set policy-options community map2gold members color:0:100 set protocols bgp group PE2 type external set protocols bgp group PE2 export adv_direct set protocols bgp group PE2 peer-as 65412 set protocols bgp group PE2 neighbor 172.16.2.2 set routing-options router-id 172.16.255.2 set routing-options autonomous-system 64520 set system host-name CE2
PE1 (DUT)
set interfaces ge-0/0/0 unit 0 description "Link from PE1 to CE1" set interfaces ge-0/0/0 unit 0 family inet address 172.16.1.2/30 set interfaces ge-0/0/1 unit 0 description "Link from PE1 to P1" set interfaces ge-0/0/1 unit 0 family inet address 10.1.23.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 description "Link from PE1 to P2" set interfaces ge-0/0/2 unit 0 family inet address 10.1.24.1/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 description "Link from PE1 to P3" set interfaces ge-0/0/3 unit 0 family inet address 10.1.25.1/24 set interfaces ge-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.1/32 set routing-instances CE1_L3vpn instance-type vrf set routing-instances CE1_L3vpn protocols bgp group CE1 type external set routing-instances CE1_L3vpn protocols bgp group CE1 peer-as 64510 set routing-instances CE1_L3vpn protocols bgp group CE1 neighbor 172.16.1.1 set routing-instances CE1_L3vpn interface ge-0/0/0.0 set routing-instances CE1_L3vpn route-distinguisher 192.168.0.1:12 set routing-instances CE1_L3vpn vrf-target target:65412:12 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.1 set protocols bgp group ibgp family inet unicast set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.2 set protocols mpls icmp-tunneling set protocols mpls label-switched-path lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path lsp_to_pe2 primary best-effort set protocols mpls label-switched-path gold_lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path gold_lsp_to_pe2 preference 5 set protocols mpls label-switched-path gold_lsp_to_pe2 primary gold set protocols mpls label-switched-path gold_lsp_to_pe2 transport-class gold set protocols mpls label-switched-path bronze_lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path bronze_lsp_to_pe2 preference 5 set protocols mpls label-switched-path bronze_lsp_to_pe2 primary bronze set protocols mpls label-switched-path bronze_lsp_to_pe2 transport-class bronze set protocols mpls path gold 10.1.23.2 strict set protocols mpls path bronze 10.1.24.2 strict set protocols mpls path best-effort 10.1.25.2 strict set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols mpls interface ge-0/0/3.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/1.0 set protocols rsvp interface ge-0/0/2.0 set protocols rsvp interface ge-0/0/3.0 set routing-options route-distinguisher-id 192.168.0.1 set routing-options resolution preserve-nexthop-hierarchy set routing-options router-id 192.168.0.1 set routing-options autonomous-system 65412 set routing-options transport-class name gold color 100 set routing-options transport-class name bronze color 200 set system host-name PE1
PE2
set interfaces ge-0/0/0 unit 0 description "Link from PE2 to P1" set interfaces ge-0/0/0 unit 0 family inet address 10.1.36.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 description "Link from PE2 to P2" set interfaces ge-0/0/1 unit 0 family inet address 10.1.46.2/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 description "Link from PE2 to P3" set interfaces ge-0/0/2 unit 0 family inet address 10.1.56.2/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 description "Link from PE2 to CE2" set interfaces ge-0/0/3 unit 0 family inet address 172.16.2.2/30 set interfaces lo0 unit 0 family inet address 192.168.0.2/32 set routing-instances CE2_L3vpn instance-type vrf set routing-instances CE2_L3vpn protocols bgp group CE2 type external set routing-instances CE2_L3vpn protocols bgp group CE2 peer-as 64520 set routing-instances CE2_L3vpn protocols bgp group CE2 neighbor 172.16.2.1 set routing-instances CE2_L3vpn interface ge-0/0/3.0 set routing-instances CE2_L3vpn route-distinguisher 192.168.0.2:12 set routing-instances CE2_L3vpn vrf-target target:65412:12 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.2 set protocols bgp group ibgp family inet unicast set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.1 set protocols mpls icmp-tunneling set protocols mpls label-switched-path lsp_to_pe1 to 192.168.0.1 set protocols mpls label-switched-path gold_lsp_to_pe1 to 192.168.0.1 set protocols mpls label-switched-path gold_lsp_to_pe1 transport-class gold set protocols mpls label-switched-path gold_lsp_to_pe1 preference 5 set protocols mpls label-switched-path bronze_lsp_to_pe1 to 192.168.0.1 set protocols mpls label-switched-path bronze_lsp_to_pe1 transport-class bronze set protocols mpls label-switched-path bronze_lsp_to_pe1 preference 5 set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set protocols rsvp interface ge-0/0/2.0 set routing-options route-distinguisher-id 192.168.0.2 set routing-options router-id 192.168.0.2 set routing-options autonomous-system 65412 set routing-options transport-class name gold color 100 set routing-options transport-class name bronze color 200 set system host-name PE2
P1
set interfaces ge-0/0/0 unit 0 description "Link from P1 to PE1" set interfaces ge-0/0/0 unit 0 family inet address 10.1.23.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 description "Link from P1 to PE2" set interfaces ge-0/0/1 unit 0 family inet address 10.1.36.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.11/32 set protocols mpls icmp-tunneling set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set routing-options router-id 192.168.0.11 set system host-name P1
P2
set interfaces ge-0/0/0 unit 0 description "Link from P2 to PE1" set interfaces ge-0/0/0 unit 0 family inet address 10.1.24.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 description "Link from P2 to PE2" set interfaces ge-0/0/1 unit 0 family inet address 10.1.46.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.12/32 set protocols mpls icmp-tunneling set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set routing-options router-id 192.168.0.12 set system host-name P2
P3
set interfaces ge-0/0/0 unit 0 description "Link from P3 to PE1" set interfaces ge-0/0/0 unit 0 family inet address 10.1.25.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 description "Link from P3 to PE2" set interfaces ge-0/0/1 unit 0 family inet address 10.1.56.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.13/32 set protocols mpls icmp-tunneling set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set routing-options router-id 192.168.0.13 set system host-name P3
Annexe 3 : Afficher la sortie de configuration sur PE1
La configuration complète du PE1 au format Curly Brace
user@PE1# show | no-more
system {
host-name PE1;
}
interfaces {
ge-0/0/0 {
unit 0 {
description "Link from PE1 to CE1";
family inet {
address 172.16.1.2/30;
}
}
}
ge-0/0/1 {
unit 0 {
description "Link from PE1 to P1";
family inet {
address 10.1.23.1/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
description "Link from PE1 to P2";
family inet {
address 10.1.24.1/24;
}
family mpls;
}
}
ge-0/0/3 {
unit 0 {
description "Link from PE1 to P3";
family inet {
address 10.1.25.1/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.1/32;
}
}
}
}
routing-instances {
CE1_L3vpn {
instance-type vrf;
protocols {
bgp {
group CE1 {
type external;
peer-as 64510;
neighbor 172.16.1.1;
}
}
}
interface ge-0/0/0.0;
route-distinguisher 192.168.0.1:12;
vrf-target target:65412:12;
}
}
routing-options {
route-distinguisher-id 192.168.0.1;
resolution {
preserve-nexthop-hierarchy;
}
router-id 192.168.0.1;
autonomous-system 65412;
transport-class {
name gold {
color 100;
}
name bronze {
color 200;
}
}
}
protocols {
bgp {
group ibgp {
type internal;
local-address 192.168.0.1;
family inet {
unicast;
}
family inet-vpn {
unicast;
}
neighbor 192.168.0.2;
}
}
mpls {
label-switched-path lsp_to_pe2 {
to 192.168.0.2;
primary best-effort;
}
label-switched-path gold_lsp_to_pe2 {
to 192.168.0.2;
preference 5;
primary gold;
transport-class gold;
}
label-switched-path bronze_lsp_to_pe2 {
to 192.168.0.2;
preference 5;
primary bronze;
transport-class bronze;
}
path gold {
10.1.23.2 strict;
}
path bronze {
10.1.24.2 strict;
10.1.66.6 strict;
}
path best-effort {
10.1.25.2 strict;
}
icmp-tunneling;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
}
}
rsvp {
interface lo0.0;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
}
}Présentation du transport avec classe BGP-CT (BGP-CT) avec tunnels SR-TE colorés sous-jacents
Avantages de BGP-CT avec les tunnels SR-TE colorés sous-jacents
- Résout les problèmes d’échelle qui peuvent survenir à l’avenir avec la croissance du réseau.
- Assure l’interconnectivité des domaines qui utilisent différentes technologies.
- Découple les services et les couches de transport, ce qui donne un réseau entièrement distribué.
- Fournit une gestion indépendante de la bande passante par le biais d’un contrôleur d’ingénierie du trafic intra-domaine pour SR-TE.
Les grands réseaux en croissance et en constante évolution nécessitent une architecture de routage de segments transparente. À partir de la version 21.2,R1 de Junos OS, nous prenons en charge BGP-CT avec un transport sous-jacent sous forme de tunnels SR-TE colorés. BGP-CT peut résoudre les routes de service à l’aide des RIB de transport et calculer le saut suivant. Les services actuellement pris en charge via BGP-CT peuvent également utiliser les tunnels colorés SR-TE sous-jacents pour la résolution du routage. Les services peuvent désormais utiliser les tunnels colorés SR-TE sous-jacents, tels que les tunnels colorés statiques, BGP SR-TE, RPD programmable et PCEP. BGP-CT utilise l’accessibilité du saut suivant pour résoudre les itinéraires de service sur la classe de transport souhaitée.
Pour activer la résolution de route de service BGP-CT sur des tunnels colorés SR-TE sous-jacents, incluez l’instruction au niveau de la use-transport-class[edit protocols source-packet-routing] hiérarchie.
- Activer l’instruction
use-transport-class
de même que l’instruction[edit protocols source-packet-routing]hiérarchique.auto-createau niveau de la[edit routing-options transport-class]hiérarchie. - Nous ne prenons pas en charge les groupes RIB pour les tunnels SR-TE colorés avec et SR-TE couleur uniquement avec
use-transport-classcette fonctionnalité.
Voir également
Présentation du mappage basé sur les couleurs des services VPN
Vous pouvez spécifier la couleur en tant que contrainte de saut suivant de protocole (en plus de l’adresse IPv4 ou IPv6) pour la résolution des tunnels de transport sur des LSP statiques colorés et SR-TE (BGP Segment Routing-Traffic-Engineer). C’est ce qu’on appelle la résolution de saut suivant du protocole IP-couleur, où vous devez configurer une carte de résolution et l’appliquer aux services VPN. Grâce à cette fonctionnalité, vous pouvez activer l’orientation du trafic basée sur les couleurs des services VPN de couche 2 et de couche 3.
Junos OS prend en charge les LSP SR-TE colorés associés à une seule couleur. La fonctionnalité de mappage coloré des services VPN est prise en charge sur les LSP colorés statiques et les LSP SR-TE BGP.
- Coloration du service VPN
- Spécification du mode de mappage du service VPN
- Résolution du prochain saut du protocole Color-IP
- Repli vers la résolution du prochain saut du protocole IP
- Mappage basé sur les couleurs unicast étiqueté BGP sur sous-couche SR-TE et IS-IS
- Fonctionnalités prises en charge et non prises en charge pour le mappage basé sur les couleurs des services VPN
Coloration du service VPN
En général, une couleur peut être attribuée à un service VPN sur le routeur de sortie sur lequel le NLRI VPN est annoncé ou sur un routeur entrant sur lequel le NLRI VPN est reçu et traité.
Vous pouvez attribuer une couleur aux services VPN à différents niveaux :
-
Par instance de routage.
-
Par groupe BGP.
-
Par voisin BGP.
-
Par préfixe.
-
Ensemble de préfixes.
Une fois que vous avez attribué une couleur, celle-ci est attachée à un service VPN sous la forme d’une communauté étendue de couleurs BGP.
Vous pouvez attribuer plusieurs couleurs à un service VPN, appelés services VPN multicolores. Dans ce cas, la plus petite valeur de couleur est considérée comme la couleur du service VPN et toutes les autres couleurs sont ignorées.
Plusieurs couleurs sont attribuées par les équipements de sortie et/ou d’entrée par le biais de plusieurs stratégies dans l’ordre suivant :
-
Stratégie d’exportation BGP sur l’appareil sortant.
-
Stratégie d’importation BGP sur l’appareil entrant.
-
Stratégie d’importation VRF sur le périphérique d’entrée.
Les deux modes de coloration du service VPN sont les suivants :
Affectation des couleurs de sortie
Dans ce mode, l’appareil sortant (c’est-à-dire l’annonceur du NLRI VPN) est responsable de la coloration du service VPN. Pour activer ce mode, vous pouvez définir une stratégie de routage et l’appliquer dans l’instance de routage vrf-export, l’exportation de groupe ou l’exportation de voisin de groupe du service VPN au niveau hiérarchique [modifier les protocoles bgp]. Le NLRI VPN est annoncé par BGP avec la couleur spécifiée communauté étendue.
Par exemple :
[edit policy-options]
community red-comm {
members color:0:50;
}[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}[edit routing-instances]
vpn-X {
...
vrf-export pol-color ...;
}OU
Lorsque vous appliquez la stratégie de routage en tant que stratégie d’exportation d’un groupe BGP ou d’un voisin BGP, vous devez inclure l’instruction vpn-apply-export au niveau BGP, groupe BGP ou voisin BGP pour que la stratégie prenne effet sur le NLRI VPN.
[edit protocols bgp]
group PEs {
...
neighbor PE-A {
export pol-color ...;
vpn-apply-export;
}
}Les stratégies de routage sont appliquées aux NLRI de préfixe VPN de couche 3, aux NRLI VPN de couche 2 et aux NLRI EVPN. La communauté étendue de couleur est héritée par toutes les routes VPN, importées et installées dans les VRF cibles sur un ou plusieurs périphériques entrants.
Affectation des couleurs d’entrée
Dans ce mode, le périphérique entrant (c’est-à-dire le récepteur du NLRI VPN) est responsable de la coloration du service VPN. Pour activer ce mode, vous pouvez définir une stratégie de routage et l’appliquer à l’instance vrf-import de routage, à l’importation de groupe ou à l’importation de voisin de groupe du service VPN au niveau de la [edit protocols bgp] hiérarchie. Toutes les routes VPN correspondant à la stratégie de routage sont attachées avec la communauté étendue de couleur spécifiée.
Par exemple :
[edit policy-options]
community red-comm {
members color:0:50;
}[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}[edit routing-instances]
vpn-Y {
...
vrf-import pol-color ...;
}OU
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-color ...;
}
}Spécification du mode de mappage du service VPN
Pour spécifier des modes de mappage de service VPN flexibles, vous devez définir une stratégie à l’aide de l’instruction resolution-map et faire référence à la stratégie dans l’instance de routage vrf-import, group import ou group neighbor import d’un service VPN au niveau hiérarchique [edit protocols bgp]. Toutes les routes VPN correspondant à la stratégie de routage sont attachées avec la carte de résolution spécifiée.
Par exemple :
[edit policy-options]
resolution-map map-A {
<mode-1>;
<mode-2>;
...
}
policy-statement pol-resolution {
term t1 {
from {
[any match conditions];
}
then {
resolution-map map-A;
accept;
}
}
}Vous pouvez appliquer une stratégie d’importation à l’instance de routage du service VPN.
[edit routing-instances]
vpn-Y {
...
vrf-import pol-resolution ...;
}Vous pouvez également appliquer la stratégie d’importation à un groupe BGP ou à un voisin BGP.
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-resolution ...;
}
}Chaque mode de mappage de service VPN doit avoir un nom unique défini dans la carte de résolution. Une seule entrée d’IP-color est prise en charge dans la carte de résolution, où la ou les routes VPN sont résolues à l’aide d’un prochain saut de protocole ip-address :color sous la forme de ip-address :color sur les tables de routage inetcolor.0 et inet6color.0.
Résolution du prochain saut du protocole Color-IP
Le processus de résolution du prochain saut de protocole a été amélioré pour prendre en charge la résolution du prochain saut du protocole IP coloré. Pour un service VPN coloré, le processus de résolution du prochain saut de protocole prend une couleur et une carte de résolution, crée un saut suivant de protocole IP coloré sous la forme de , et résout le prochain saut de protocole dans les tables de ip-address:colorroutage inetcolor.0 et inet6color.0.
Vous devez configurer une stratégie pour prendre en charge la résolution par trajets multiples des services VPN de couche 2, VPN de couche 3 ou EVPN colorés sur des LSP colorés. La stratégie doit ensuite être appliquée avec la table RIB appropriée en tant que stratégie d’importation du résolveur.
Par exemple :
[edit policy-options]
policy-statement mpath {
then multipath-resolve;
}[edit routing-options]
resolution {
rib bgp.l3vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.l3vpn-inet6.0 {
inet6color-import mpath;
}
}
resolution {
rib bgp.l2vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib mpls.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.evpn.0 {
inetcolor-import mpath;
}
}Repli vers la résolution du prochain saut du protocole IP
Si une carte de résolution n’est pas appliquée à un service VPN coloré, le service VPN ignore sa couleur et revient à la résolution du prochain saut du protocole IP. À l’inverse, si une carte de résolution est appliquée à un service VPN non coloré, la carte de résolution est ignorée et le service VPN utilise la résolution de saut suivant du protocole IP.
La solution de repli est un processus simple, des LSP SR-TE colorés aux LSP LDP, en utilisant un groupe RIB permettant au LDP d’installer les routes dans les tables de routage inet{6}color.0. Une correspondance de préfixe le plus long pour un saut suivant de protocole IP coloré garantit que si une route SR-TE LSP colorée n’existe pas, une route LDP avec une adresse IP correspondante doit être renvoyée.
Mappage basé sur les couleurs unicast étiqueté BGP sur sous-couche SR-TE et IS-IS
À partir de Junos OS version 20.2R1, BGP Labeled Unicast (BGP-LU) peut résoudre les routes IPv4 ou IPv6 sur l’ingénierie du trafic de routage de segments (SR-TE) avec une sous-couche IS-IS pour les familles d’adresses IPv4 et IPv6. BGP-LU prend en charge le mappage d’une couleur de communauté BGP et la définition d’une couleur pour resolution map SR-TE. Un saut suivant de protocole coloré est construit et il est résolu sur un tunnel SR-TE coloré dans la inetcolor.0 table or inet6color.0 . Ainsi, BGP-LU résout le saut suivant du protocole sur les tunnels SR-TE pour le transport de paquets. BGP utilise inet.3 des tables et inet6.3 pour le mappage non basé sur les couleurs.
Fonctionnalités prises en charge et non prises en charge pour le mappage basé sur les couleurs des services VPN
Les caractéristiques et fonctionnalités suivantes sont prises en charge avec le mappage basé sur les couleurs des services VPN :
-
VPN de couche 3 BGP
-
VPN de couche 2 BGP (VPN de couche 2 de Kompella)
-
BGP EVPN
-
Carte de résolution avec une seule option de couleur IP.
-
Résolution de saut suivant des protocoles IPv4 et IPv6 en couleur.
-
Base d’informations de routage (également appelée table de routage) repli basé sur le groupe LDP LSP dans les tables de routage inetcolor.0 ou inet6color.0.
-
SR-TE LSP coloré.
-
Plates-formes virtuelles.
-
Junos OS 64 bits.
-
Systèmes logiques.
-
Unicast étiqueté BGP
Les caractéristiques et fonctionnalités suivantes ne sont pas prises en charge avec le mappage basé sur les couleurs des services VPN :
-
LSP MPLS colorés, tels que RSVP, LDP, BGP-LU, statiques.
-
Circuit de couche 2
-
VPN de couche 2 BGP FEC-129 auto-découvert et signalé par LDP.
-
VPLS
-
MVPN (en anglais)
-
IPv4 et IPv6 à l’aide de resolution-map.