Sur cette page
Présentation de la prise en charge du protocole Path Computation Element pour RSVP-TE
Exemple : Configuration du protocole Path Computation Element pour MPLS RSVP-TE
Activer Segment Routing pour le protocole Path Computation Element
Chemin de commutation d’étiquette de segment routing statique
Activation du CSPF distribué pour les LSP de routage de segments
Activation de chemins multiples pour les LSP SR-TE dans PCEP
Activation de la sécurité de la couche transport pour les sessions PCEP
Optimisation du chemin de création de rapports et mesures calculées dans PCEP
PCEP Configuration
Vue d’ensemble du PCEP
Un élément de calcul de chemin (PCE) est une entité (composant, application ou nœud de réseau) capable de calculer un chemin ou un itinéraire réseau en fonction d’un graphe de réseau et d’appliquer des contraintes de calcul. Un client de calcul de chemin (PCC) est une application cliente qui demande qu’un calcul de chemin soit effectué par un PCE. Le protocole PCEP (Path Computation Element Protocol) permet les communications entre un PCC et un PCE, ou entre deux PCE (défini dans la RFC 5440).
PCEP est un protocole basé sur TCP défini par le groupe de travail IETF PCE et définit un ensemble de messages et d’objets utilisés pour gérer les sessions PCEP et pour demander et envoyer des chemins pour les LSP d’ingénierie de trafic multidomaine (LSP TE). Il fournit un mécanisme permettant à un PCE d’effectuer un calcul de chemin pour les LSP externes d’un PCC. Les interactions PCEP incluent les rapports d’état LSP envoyés par le PCC au PCE et les mises à jour PCE pour les LSP externes.
Figure 1 illustre le rôle de PCEP dans la mise en œuvre côté client d’une architecture PCE dynamique dans un réseau compatible MPLS RSVP-TE.
Une session PCEP basée sur TCP connecte un PCC à un PCE externe. Le PCC initie la session PCEP et reste connecté au PCE pendant toute la durée de la session PCEP. Au cours de la session PCEP, le PCC demande les paramètres LSP au PCE dynamique. À la réception d’un ou de plusieurs paramètres LSP du PCE, le PCC resignale le LSP TE. Lorsque la session PCEP est terminée, la connexion TCP sous-jacente est immédiatement fermée et le PCC tente de rétablir la session PCEP.
Ainsi, les fonctions du PCEP comprennent :
Synchronisation de l’état du tunnel LSP entre un PCC et un PCE avec état : lorsqu’une connexion PCE dynamique active est détectée, un PCC tente de déléguer tous les LSP à ce PCE dans le cadre d’une procédure appelée synchronisation de l’état LSP. PCEP permet de synchroniser l’état du LSP PCC avec le PCE.
Délégation du contrôle sur les tunnels LSP à un PCE dynamique : un PCE dynamique actif contrôle un ou plusieurs attributs LSP pour les chemins de calcul, tels que la bande passante, le chemin (ERO) et la priorité (configuration et attente). PCEP permet une telle délégation des LSP pour le calcul des chemins.
Contrôle PCE dynamique de la synchronisation et de la séquence des calculs de chemin dans et entre les sessions PCEP : un PCE dynamique actif modifie un ou plusieurs attributs LSP, tels que la bande passante, le chemin (ERO) et la priorité (configuration et maintien). Le PCEP communique ces nouveaux attributs LSP du PCE au PCC, après quoi le PCC resignale le LSP selon le chemin spécifié.
Présentation de la prise en charge du protocole Path Computation Element pour RSVP-TE
- Comprendre MPLS RSVP-TE
- Limites actuelles du MPLS RSVP-TE
- Utilisation d’une entité de calcul de chemin externe
- Composants de l’External Path Computing
- Interaction entre un PCE et un PCC à l’aide de PCEP
- Comportement des LSP avec le calcul externe
- Instructions de configuration prises en charge pour le calcul externe
- Protection LSP contrôlée par PCE
- LSP contrôlé par PCE ERO
- LSP RSVP-TE point-à-multipoint contrôlés par PCE
- LSP point à point initiés par PCE
- LSP de contournement initié par le PCE
- LSP point-à-multipoint initiés par PCE
- LSP SRv6 dans PCEP
- Avantages des LSP SRv6 dans PCEP
- LSP à bande passante automatique et contrôle PCE
- Authentification TCP-MD5 pour les sessions PCEP
- Impact de l’implémentation PCE côté client sur les performances du réseau
Comprendre MPLS RSVP-TE
Les aspects techniques du trafic (TE) portent sur l’optimisation des performances des réseaux opérationnels, principalement en cartographiant les flux de trafic sur une topologie physique existante. Les aspects techniques du trafic permettent de déplacer le flux de trafic du chemin le plus court sélectionné par l’IGP (Interior Gateway Protocol) vers un chemin physique potentiellement moins encombré à travers un réseau.
Pour les aspects techniques du trafic sur les réseaux denses et de grande taille, il est possible de mettre en uvre des fonctionnalités MPLS, car elles offrent potentiellement la plupart des fonctionnalités disponibles à partir d’un modèle de superposition, de manière intégrée et à un coût inférieur à celui des alternatives concurrentes actuelles. La principale raison d’implémenter les aspects techniques du trafic MPLS est de contrôler les chemins le long desquels le trafic circule à travers un réseau. Le principal avantage de la mise en uvre des aspects techniques du trafic MPLS est qu’elle combine les capacités d’ingénierie du trafic d’ATM avec la différenciation IP en fonction de la classe de service (CoS).
Dans un réseau MPLS, les informations du plan de données sont transmises à l’aide de la commutation d’étiquettes. Des étiquettes sont appliquées à un paquet arrivant sur un routeur PE (Provider Edge) en provenance du routeur CE (CustomerEdge), puis sont transférés au routeur PE de sortie. Les étiquettes sont supprimées au niveau du routeur de sortie et elles sont ensuite transmises à la destination appropriée en tant que paquet IP. Les routeurs de commutation d’étiquettes (LSR) du domaine MPLS utilisent des protocoles de distribution d’étiquettes pour communiquer la signification des étiquettes utilisées pour transférer le trafic entre et à travers les LSR. RSVP-TE est l’un de ces protocoles de distribution d’étiquettes qui permet à un pair LSR d’en apprendre davantage sur les mappages d’étiquettes d’autres pairs.
Lorsque MPLS et RSVP sont tous deux activés sur un routeur, MPLS devient un client de RSVP. L’objectif principal du logiciel RSVP de Junos OS est de prendre en charge la signalisation dynamique dans les chemins de commutation d’étiquettes (LSP). RSVP réserve des ressources, par exemple pour les flux IP unicast et multicast, et demande des paramètres de qualité de service (QoS) pour les applications. Le protocole est étendu dans les aspects techniques du trafic MPLS pour permettre à RSVP de configurer des LSP pouvant être utilisés pour l’ingénierie du trafic dans les réseaux MPLS.
Lorsque MPLS et RSVP sont combinés, les étiquettes sont associées aux flux RSVP. Une fois qu’un LSP est établi, le trafic qui transite par le chemin est défini par l’étiquette appliquée au niveau du nœud d’entrée du LSP. Le mappage de l’étiquette au trafic est réalisé à l’aide de différents critères. L’ensemble des paquets auxquels un nœud spécifique attribue la même valeur d’étiquette appartient à la même classe d’équivalence de transfert (FEC) et définit effectivement le flux RSVP. Lorsque le trafic est ainsi mappé sur un LSP, celui-ci est appelé tunnel LSP.
Les tunnels LSP permettent d’établir des chemins unidirectionnels de commutation d’étiquettes. RSVP-TE s’appuie sur le protocole de base RSVP en définissant de nouveaux objets et en modifiant les objets existants utilisés dans les objets PATH et RESV pour l’établissement LSP. Les nouveaux objets (objet LABEL-REQUEST (LRO), RECORD-ROUTE (RRO), objet LABEL et objet EXPLICIT-ROUTE (ERO) sont facultatifs par rapport au protocole RSVP, à l’exception des objets LRO et LABEL, qui sont tous deux obligatoires pour l’établissement de tunnels LSP.
En général, RSVP-TE établit un chemin de commutation d’étiquettes qui assure la livraison des trames du routeur d’entrée au routeur de sortie. Toutefois, avec les nouvelles fonctionnalités d’ingénierie du trafic, les fonctions suivantes sont prises en charge dans un domaine MPLS :
-
Possibilité d’établir un chemin de commutation d’étiquettes en utilisant une route explicite complète ou partielle (RFC 3209).
-
Établissement d’un LSP basé sur des contraintes sur des liens qui répondent à des exigences, telles que la bande passante et les propriétés de lien.
-
Le contrôle des points de terminaison, associé à l’établissement et à la gestion de tunnels LSP au niveau des routeurs d’entrée et de sortie.
-
Gestion des liens, qui gère les ressources de liens pour effectuer un routage en fonction des ressources des LSP d’ingénierie du trafic et pour programmer les étiquettes MPLS.
-
Le reroutage rapide MPLS (FRR), qui gère les LSP à protéger et leur attribue des informations de tunnel de secours.
Limites actuelles du MPLS RSVP-TE
Bien que les extensions RSVP pour l’ingénierie du trafic permettent une meilleure utilisation du réseau et répondent aux exigences des classes de trafic, la suite de protocoles MPLS RSVP-TE d’aujourd’hui présente plusieurs problèmes inhérents à sa nature distribuée. Cela entraîne un certain nombre de problèmes lors de la dispute pour la capacité de bisection, en particulier au sein d’une classe de priorité LSP où un sous-ensemble de LSP partagent une configuration commune et détiennent des valeurs de priorité. Les limites de RSVP-TE sont les suivantes :
-
Manque de visibilité sur les demandes de bande passante individuelles par LSP et par appareil : les routeurs entrants d’un réseau MPLS RSVP-TE établissent des LSP sans avoir une vue globale de la demande de bande passante sur le réseau. Les informations sur l’utilisation des ressources réseau sont uniquement disponibles sous forme de capacité totale réservée par classe de trafic et par interface. L’état LSP individuel est disponible localement sur chaque routeur de périphérie d’étiquettes (LER) pour ses propres LSP uniquement. En conséquence, un certain nombre de problèmes liés au modèle de demande se posent, en particulier au sein d’une configuration commune et sont prioritaires.
-
Nature asynchrone et indépendante de la signalisation RSVP : dans RSVP-TE, les contraintes d’établissement du chemin sont contrôlées par un administrateur. Ainsi, la bande passante réservée à un tunnel LSP est définie par l’administrateur et n’implique pas automatiquement de limite sur le trafic envoyé sur le tunnel. Par conséquent, la bande passante disponible sur une liaison d’ingénierie du trafic correspond à la bande passante configurée pour la liaison, à l’exclusion de la somme de toutes les réservations effectuées sur la liaison. Par conséquent, les demandes non signalées sur un tunnel LSP entraînent une dégradation du service du LSP qui nécessite une bande passante excessive, ainsi que des autres LSP qui satisfont aux exigences de bande passante de la liaison d’ingénierie du trafic.
-
Fournisseurs de services linguistiques établis sur la base d’options dynamiques ou chemin explicite dans l’ordre de préférence : les routeurs entrants d’un réseau MPLS RSVP-TE établissent des fournisseurs de services linguistiques pour les demandes en fonction de l’ordre d’arrivée. Étant donné que les routeurs entrants ne disposent pas d’une vue globale de la demande de bande passante sur le réseau, l’utilisation de l’ordre de préférence pour établir des LSP peut entraîner une perte de trafic ou l’échec de l’établissement de LSP lorsqu’il y a un excès de demande de bande passante.
Par exemple, est configuré avec MPLS RSVP-TE, Figure 2 dans lequel A et G sont les routeurs de périphérie d’étiquettes (LER). Ces routeurs entrants établissent des LSP indépendamment en fonction de l’ordre des demandes et n’ont aucune connaissance ni aucun contrôle sur les LSP des autres. Les routeurs B, C et D sont des routeurs intermédiaires ou de transit qui se connectent aux routeurs de sortie E et F.
Les routeurs entrants établissent des LSP en fonction de l’ordre dans lequel les demandes arrivent. Si le routeur G reçoit deux demandes de capacité 5 chacune pour G-F, alors G signale deux LSP (LSP1 et LSP2) via G-B-D-F. De la même manière, lorsque le routeur A reçoit la troisième demande de capacité 10 pour A-E, il signale un LSP, LSP3, via A-B-C-E. Toutefois, si la demande sur le LSP A-E passe de 10 à 15, le routeur A ne peut pas signaler le LSP3 en utilisant le même chemin (A-B-C-E), car la liaison B-C a une capacité inférieure.
Le routeur A aurait dû signaler l’augmentation de la demande sur LSP3 en utilisant le chemin A-B-D-C-E. Étant donné que LSP1 et LSP2 ont utilisé la liaison B-D en fonction de l’ordre des demandes reçues, LSP3 n’est pas signalé.
Ainsi, bien qu’une bande passante de débit maximal adéquate soit disponible pour tous les LSP, le LSP3 est sujet à une dégradation du service potentiellement prolongée. Cela est dû au manque de visibilité de la demande globale du routeur A et au manque de coordination systémique dans le placement de la demande par les routeurs entrants A et G.
Utilisation d’une entité de calcul de chemin externe
Pour remédier aux limitations actuelles du calcul des chemins MPLS RSVP-TE, il est nécessaire de faire appel à une entité externe de calcul de chemin disposant d’une vue globale de la demande par LSP et par appareil dans le réseau, indépendamment de la capacité disponible.
Actuellement, seul le calcul de chemin de routage basé sur les contraintes en ligne et en temps réel est fourni dans un réseau MPLS RSVP-TE. Chaque routeur effectue des calculs de routage basés sur des contraintes, indépendamment des autres routeurs du réseau. Ces calculs sont basés sur les informations topologiques actuellement disponibles, informations généralement récentes, mais pas tout à fait exactes. Les emplacements LSP sont optimisés localement, en fonction de l’état actuel du réseau. Les tunnels MPLS RSVP-TE sont configurés à l’aide de l’interface de ligne de commande. Un opérateur configure le TE LSP, qui est ensuite signalé par le routeur entrant.
En plus des fonctionnalités existantes d’ingénierie du trafic, la fonctionnalité MPLS RSVP-TE a été étendue pour inclure une entité externe de calcul de chemin, appelée Path Computation Element (PCE). Le PCE calcule le chemin pour les LSP TE des routeurs entrants qui ont été configurés pour le contrôle externe. Le routeur entrant qui se connecte à un PCE est appelé Path Computation Client (PCC). Le PCC est configuré avec le protocole PCEP (Path Computation Client Protocol) pour faciliter le calcul de chemin externe par un PCE.
Pour plus d’informations, reportez-vous à la section Composants de l’External Path Computing.
Pour activer le calcul de chemin externe pour les LSP TE d’un PCC, incluez l’instruction lsp-external-controller pccd
aux niveaux de la [edit mpls]
hiérarchie et [edit mpls lsp lsp-name]
.
Composants de l’External Path Computing
Les composants qui composent un système de calcul de chemin externe sont les suivants :
Élément de calcul de chemin
Un élément de calcul de chemin (PCE) peut être une entité (composant, application ou nœud de réseau) capable de calculer un chemin ou un itinéraire réseau en fonction d’un graphe de réseau et d’appliquer des contraintes de calcul. Toutefois, un PCE ne peut calculer le chemin que pour les LSP TE d’un PCC qui ont été configurés pour un contrôle externe.
Un PCE peut être avec ou sans état.
-
PCE avec états : un PCE avec états maintient une synchronisation stricte entre le PCE et les états du réseau (en termes de topologie et d’informations sur les ressources), ainsi que l’ensemble des chemins calculés et des ressources réservées utilisés dans le réseau. En d’autres termes, un PCE dynamique utilise les informations de la base de données d’ingénierie du trafic ainsi que les informations sur les chemins existants (par exemple, les LSP TE) dans le réseau pour traiter les nouvelles demandes du PCC.
Il existe deux types de PCE dynamiques :
-
PCE passif avec états : maintient la synchronisation avec le PCC et apprend les états du LSP PCC pour mieux optimiser les calculs de chemin, mais n’a aucun contrôle sur ceux-ci.
-
PCE dynamique actif : modifie activement les LSP PCC, en plus d’en apprendre davantage sur les états LSP PCC.
REMARQUE :Dans une configuration redondante avec des PCE dynamiques actifs principaux et de secours, le PCE dynamique actif de sauvegarde ne peut pas modifier les attributs des LSP délégués tant qu’il ne devient pas le PCE principal au moment d’un basculement. Il n’y a pas de préemption des PCE dans le cas d’un basculement. Le PCE principal est soutenu par un PCE de secours, et lorsque le PCE principal tombe en panne, le PCE de secours assume le rôle du PCE principal et reste le PCE principal même après que le PCE qui était auparavant le PCE principal soit à nouveau opérationnel.
Un PCE dynamique fournit les fonctions suivantes :
-
Offre un calcul de chemin LSP hors ligne.
-
Déclenche un réacheminement LSP lorsqu’il est nécessaire de réoptimiser le réseau.
-
Modifie la bande passante LSP en cas d’augmentation de la demande de bande passante d’une application.
-
Modifie d’autres attributs LSP sur le routeur, tels que ERO, la priorité de configuration et la priorité de maintien.
Un PCE a une vue globale de la demande de bande passante dans le réseau et gère une base de données d’ingénierie du trafic pour effectuer les calculs de chemin. Il collecte des statistiques à partir de tous les routeurs du domaine MPLS à l’aide de SNMP et NETCONF. Il s’agit d’un mécanisme de contrôle hors ligne des LSP TE du PCC. Bien qu’un système de calcul de chemin LSP hors ligne puisse être intégré dans un contrôleur de réseau, le PCE agit comme un contrôleur de réseau à part entière qui permet de contrôler les LSP TE du PCC, en plus de calculer les chemins.
Bien qu’un PCE dynamique permette un calcul de chemin optimal et une réussite accrue du calcul de chemin, il nécessite des mécanismes de synchronisation d’état fiables, avec une surcharge potentiellement importante du plan de contrôle et la maintenance d’une grande quantité de données en termes d’états, comme dans le cas d’un maillage complet de LSP TE.
-
-
PCE sans état : un PCE sans état ne mémorise aucun chemin calculé et chaque ensemble de demandes est traité indépendamment les uns des autres (RFC 5440).
Client de calcul de chemin
Un client de calcul de chemin (PCC) est une application cliente qui demande qu’un calcul de chemin soit effectué par un PCE.
Un PCC peut se connecter à un maximum de 10 PCE à la fois. La connexion PCC-PCE peut prendre la forme d’une route statique configurée ou d’une connexion TCP qui établit l’accessibilité. Le PCC attribue un numéro de priorité à chaque PCE connecté. Il envoie un message à tous les PCE connectés avec des informations sur ses LSP actuels, dans le cadre d’un processus appelé synchronisation d’état LSP. Pour les LSP TE pour lesquels le contrôle externe est activé, le PCC délègue ces LSP au PCE principal. Le PCC choisit, en tant que PCE principal, un PCE avec le numéro de priorité le plus bas, ou le PCE auquel il se connecte en premier en l’absence d’un numéro de priorité.
Le PCC resignale un LSP en fonction du chemin calculé qu’il reçoit d’un PCE. Lorsque la session PCEP avec le PCE principal est terminée, le PCC élit un nouveau PCE principal, et tous les LSP délégués au PCE principal précédent sont délégués au PCE principal nouvellement disponible.
Protocole d’élément de calcul de chemin
Le protocole PCEP (Path Computation Element Protocol) est utilisé pour la communication entre PCC et PCE (ainsi qu’entre deux PCE) (RFC 5440). PCEP est un protocole basé sur TCP défini par le groupe de travail PCE de l’IETF et définit un ensemble de messages et d’objets utilisés pour gérer les sessions PCEP et pour demander et envoyer des chemins pour les LSP TE multidomaines. Les interactions PCEP comprennent des messages PCC, ainsi que des notifications d’états spécifiques liés à l’utilisation d’un PCE dans le contexte de MPLS RSVP-TE. Lorsque PCEP est utilisé pour la communication PCE à PCE, le PCE demandeur assume le rôle de PCC.
Ainsi, les fonctions du PCEP comprennent :
-
Synchronisation de l’état du tunnel LSP entre un PCC et un PCE à états.
-
Délégation du contrôle des tunnels LSP à un PCE dynamique.
Interaction entre un PCE et un PCC à l’aide de PCEP
Figure 3 illustre la relation entre un PCE, un PCC et le rôle du PCEP dans le contexte du MPLS RSVP-TE.
La communication PCE vers PCC est activée par le PCEP basé sur TCP. Le PCC lance la session PCEP et reste connecté à un PCE pendant toute la durée de la session PCEP.
À partir de Junos OS version 16.1, vous pouvez sécuriser une session PCEP à l’aide de l’authentification TCP-MD5 conformément à la RFC 5440. Pour activer le mécanisme de sécurité MD5 pour une session PCEP, il est recommandé de définir et de lier la clé d’authentification MD5 au niveau hiérarchique [edit protocols pcep pce pce-id]
d’une session PCEP. Cependant, vous pouvez également utiliser un trousseau prédéfini au niveau de la [edit security authentication-key-chains key-chain]
hiérarchie pour sécuriser une session PCEP. Dans ce cas, vous devez lier le trousseau prédéfini à la session PCEP au niveau de la [edit protocols pcep pce pce-id]
hiérarchie.
Le PCE et le PCC utilisent la même clé pour vérifier l’authenticité de chaque segment envoyé sur la connexion TCP de la session PCEP, sécurisant ainsi la communication PCEP entre les appareils, qui peuvent faire l’objet d’attaques et perturber les services sur le réseau.
Pour plus d’informations sur la sécurisation des sessions PCEP à l’aide de l’authentification MD5, reportez-vous à la section Authentification TCP-MD5 pour les sessions PCEP.
Une fois la session PCEP établie, le PCC effectue les tâches suivantes :
-
Synchronisation de l’état LSP : le PCC envoie des informations sur tous les LSP (locaux et externes) à tous les PCE connectés. Pour les LSP externes, le PCC envoie au PCE des informations sur tout changement de configuration, de RRO, d’état, etc.
Pour les LSP initiés par PCE, il n’y a pas de configuration LSP présente sur le PCC. Le PCE qui initie le LSP envoie les paramètres du LSP au PCC qui a indiqué sa capacité à prendre en charge les LSP initiés par le PCE.
REMARQUE :La prise en charge des LSP initiés par PCE est fournie dans Junos OS version 13.3 et versions ultérieures.
-
Délégation LSP : une fois les informations d’état du LSP synchronisées, le PCC délègue les LSP externes à un PCE, qui est le principal PCE actif avec état. Seul le PCE principal peut définir des paramètres pour le LSP externe. Les paramètres modifiés par le PCE principal sont la bande passante, le chemin d’accès (ERO) et la priorité (configuration et maintien). Les paramètres spécifiés dans la configuration locale sont remplacés par les paramètres définis par le PCE principal.
REMARQUE :Lorsque la session PCEP avec le PCE principal est terminée, le PCC élit un nouveau PCE principal, et tous les LSP délégués au PCE principal précédent sont délégués au PCE principal nouvellement disponible.
Dans le cas des LSP initiés par PCE, le PCC crée le LSP à l’aide des paramètres reçus du PCE. Le PCC attribue au LSP initié par le PCE un LSP-ID unique et délègue automatiquement le LSP au PCE. Un PCC ne peut pas révoquer la délégation pour les LSP initiés par le PCE pour une session PCEP active.
Lorsqu’une session PCEP se termine, le PCC démarre deux minuteries sans supprimer immédiatement les LSP initiés par PCE – et
lsp cleanup timer
–delegation cleanup timeout
pour éviter toute interruption des services. Pendant ce temps, un PCE dynamique actif peut prendre le contrôle des LSP provisionnés par le PCE défaillant, en envoyant une demande de création pour le LSP.Le contrôle des LSP initiés par PCE revient au PCC à l’expiration du
delegation cleanup timeout
. Lorsque le expire et qu’aucun autre PCE n’a acquis le contrôle sur le LSP à partir du PCE défaillant, le PCC prend le contrôle local du LSP initié par ledelegation cleanup timeout
PCE non délégué. Par la suite, lorsque le PCE dynamique d’origine ou un nouveau PCE actif souhaite prendre le contrôle des LSP initiés par PCE contrôlés localement, le PCC délègue ces LSP au PCE et lelsp cleanup timer
minuteur est arrêté.Un PCE peut renvoyer la délégation du LSP initié par le PCE au PCC pour permettre le transfert du LSP entre les PCE. Cela déclenche le pour le LSP initié par PCE
lsp cleanup timer
. Le PCC attend l’expiration du minuteur de nettoyage du LSP avant de supprimer les LSP initiés par le PCE non délégués du PCE ayant échoué.Lorsque le expire et qu’aucun autre PCE n’a acquis le contrôle sur les LSP à partir du PCE défaillant, le PCC supprime tous les LSP provisionnés par le
lsp cleanup timer
PCE défaillant.REMARQUE :Conformément à draft-ietf-pce-stateful-pce-09, la révocation des délégations de LSP initiées par PCE par un PCC se fait de manière pré-dématérialisée avant que les LSP ne soient redélégués à un autre PCE. À partir de la version 18.1R1 de Junos OS, la valeur doit être supérieure ou égale à la
lsp-cleanup-timer
delegation-cleanup-timeout
pour que le PCC puisse révoquer les délégations LSP. Si ce n’est pas le cas, l’intervalle de délai d’expiration de la redélégation pour le PCC peut être défini sur l’infini, où les délégations LSP à ce PCE restent intactes jusqu’à ce qu’une action spécifique soit entreprise par le PCC pour modifier les paramètres définis par le PCE. -
Signalisation LSP : à la réception d’un ou de plusieurs paramètres LSP du PCE dynamique actif principal, le PCC resignale le LSP TE en fonction du chemin fourni par PCE. Si le PCC ne parvient pas à configurer le LSP, il informe le PCE de l’échec de l’installation et attend que le PCE principal fournisse de nouveaux paramètres pour ce LSP, puis le resignale.
Lorsque PCE spécifie un chemin incomplet ou comporte des sauts lâches où seuls les points de terminaison du chemin sont spécifiés, le PCC n’effectue pas de routage basé sur les contraintes locales pour déterminer l’ensemble complet des sauts. Au lieu de cela, le PCC fournit à RSVP le chemin fourni par PCE, tel quel, pour la signalisation, et le chemin est configuré à l’aide du routage IGP saut par saut.
La topologie utilisée dans illustre Figure 4 l’implémentation partielle de PCE côté client dans Figure 2le réseau compatible MPLS RSVP-TE. Les routeurs entrants A et G sont les PCC configurés pour se connecter au PCE dynamique externe via une connexion TCP.
Le PCE dispose d’une vue globale de la demande de bande passante dans le réseau et effectue des calculs de chemin externes après avoir consulté la base de données des aspects techniques du trafic. Le PCE dynamique actif modifie ensuite un ou plusieurs attributs LSP et envoie une mise à jour au PCC. Le PCC utilise les paramètres qu’il reçoit du PCE pour re-signaler le LSP.
De cette façon, le PCE dynamique fournit une opération coopérative de fonctionnalités distribuées utilisées pour relever les défis spécifiques d’un calcul de chemin contraint interdomaine le plus court. Elle élimine les scénarios d’encombrement dans lesquels les flux de trafic sont mappés de manière inefficace sur les ressources disponibles, ce qui entraîne une surutilisation de certains sous-ensembles de ressources réseau, tandis que d’autres restent sous-utilisées.
Comportement des LSP avec le calcul externe
LSP Types
Dans une implémentation PCE côté client, il existe trois types de LSP TE :
-
LSP contrôlés par CLI : les LSP pour lesquels l’instruction n’est pas configurée sont appelés LSP contrôlés par CLI
lsp-external-controller pccd
. Bien que ces LSP soient sous contrôle local, le PCC met à jour les PCE connectés avec des informations sur les LSP contrôlés par l’interface de ligne de commande au cours du processus de synchronisation initial du LSP. Après la synchronisation initiale des LSP, le PCC informe également le PCE de tout LSP nouveau et supprimé. -
LSP contrôlés par PCE : les LSP pour lesquels l’instruction est configurée sont appelés LSP contrôlés par PCE
lsp-external-controller pccd
. Le PCC délègue les LSP initiés par le PCC au PCE principal pour le calcul du chemin externe.Le PCC informe le PCE des paramètres configurés d’un LSP contrôlé par PCE, tels que la bande passante, l’ERO et les priorités. Il informe également le PCE sur les valeurs réelles utilisées pour ces paramètres afin de configurer le LSP, y compris le RRO, lorsqu’ils sont disponibles.
Le PCC envoie de tels rapports d’état des LSP au PCE uniquement lorsqu’une reconfiguration a eu lieu ou lorsqu’il y a un changement dans l’ERO, le RRO ou l’état des LSP contrôlés par PCE sous contrôle externe.
Il existe deux types de paramètres qui proviennent de la configuration CLI d’un LSP pour un PCE :
-
Paramètres qui ne sont pas remplacés par un PCE et qui sont appliqués immédiatement.
-
Paramètres remplacés par un PCE. Ces paramètres incluent la bande passante, le chemin d’accès et la priorité (valeurs de configuration et de conservation). Lorsque le mode de contrôle passe de l’externe au local, les valeurs configurées par l’interface de ligne de commande pour ces paramètres sont appliquées à la prochaine occasion de re-signal du LSP. Les valeurs ne sont pas appliquées immédiatement.
-
-
LSP provisionnés en externe (ou LSP initiés par PCE) : les LSP pour lesquels l’instruction est configurée sont appelés LSP initiés par PCE
lsp-provisioning
. Un LSP initié par une PCE est créé dynamiquement par une PCE externe. par conséquent, il n’y a pas de configuration LSP présente sur le PCC. Le PCC crée le LSP initié par le PCE à l’aide des paramètres fournis par le PCE et délègue automatiquement le LSP au PCE.REMARQUE :La prise en charge des LSP initiés par PCE est fournie dans Junos OS version 13.3 et versions ultérieures.
Les LSP contrôlés par CLI, les LSP contrôlés par PCE et les LSP initiés par PCE peuvent coexister sur un PCC.
Les LSP contrôlés par CLI et les LSP contrôlés par PCE peuvent coexister sur un PCC.
Mode de contrôle LSP
Dans une implémentation PCE côté client, il existe deux types de modes de contrôle pour un LSP contrôlé par PCC :
-
External (Externe) : par défaut, tous les LSP contrôlés par PCE sont sous contrôle externe. Lorsqu’un LSP est sous contrôle externe, le PCC utilise les paramètres fournis par le PCE pour configurer le LSP.
-
Local (Local) : un LSP contrôlé par PCE peut passer sous contrôle local. Lorsque le LSP passe d’un contrôle externe à un contrôle local, le calcul du chemin est effectué à l’aide des paramètres configurés par l’interface de ligne de commande et du routage basé sur les contraintes. Un tel basculement ne se produit que lorsqu’il y a un déclencheur pour re-signaler le LSP. Jusque-là, le PCC utilise les paramètres fournis par le PCE pour signaler le LSP contrôlé par le PCE, bien que le LSP reste sous contrôle local.
Un LSP contrôlé par PCE passe au contrôle local à partir de son mode de contrôle externe par défaut dans les cas où il n’y a pas de connectivité à un PCE ou lorsqu’un PCE renvoie la délégation de LSP au PCC.
Pour plus d’informations sur les LSP contrôlés par CLI et par PCE, reportez-vous à la section LSP Types.
Instructions de configuration prises en charge pour le calcul externe
Tableau 1 répertorie les instructions de configuration MPLS et LSP existantes qui s’appliquent à un LSP contrôlé par PCE.
Prise en charge des LSP contrôlés par PCE |
Instructions de configuration LSP applicables |
Instructions de configuration MPLS applicables |
---|---|---|
Ces instructions de configuration peuvent être configurées en même temps que la configuration PCE. Cependant, ils ne prennent effet que lorsque la configuration locale est utilisée. Pendant le contrôle PCE, ces instructions de configuration restent inactives. |
|
|
Ces instructions de configuration peuvent être configurées en même temps que la configuration PCE, mais sont remplacées par les attributs LSP contrôlés par PCE. Toutefois, lorsque la configuration locale est en cours d’utilisation, les valeurs configurées de ces instructions de configuration sont appliquées. REMARQUE :
Les modifications apportées à la configuration locale à l’aide de la CLI alors que le LSP est sous le contrôle d’un PCE dynamique n’ont aucun effet sur le LSP. Ces modifications n’entrent en vigueur que lorsque la configuration locale est appliquée. |
|
|
Ces instructions de configuration ne peuvent pas être configurées en même temps que la configuration PCE. |
|
|
Les autres instructions de configuration LSP s’appliquent de la même manière que pour les LSP existants. Lors de la configuration de l’une des instructions de configuration ci-dessus pour un LSP contrôlé par PCE, un message de journal MPLS est généré pour indiquer quand les paramètres configurés prennent effet.
Protection LSP contrôlée par PCE
Les chemins de protection, y compris les LSP de reroutage rapide et de contournement, sont calculés localement par le PCC à l’aide d’un routage basé sur des contraintes. Un PCE dynamique spécifie uniquement le chemin principal (ERO). Un PCE peut également déclencher un chemin secondaire non passif, même si la configuration locale ne dispose pas d’un chemin secondaire non secondaire pour la protection LSP.
LSP contrôlé par PCE ERO
Pour les LSP contrôlés par PCE (LSP délégués par PCC et LSP initiés par PCE), seul un objet Explicit Route Object (ERO) complet doit être envoyé du PCE au PCC ; sinon, le PCC rejette le message PCUpdate ou PCCreate pour cette session PCEP.
À partir de Junos OS version 17.2, en plus de , deux nouveaux types de calcul de external cspf
chemin sont introduits pour les LSP contrôlés par PCE : local cspf
et no cspf
.
-
local cspf
—Un PCC utilise le type de calcul uniquement lorsque lelocal cspf
PCE envoie une TLV fournisseur Juniper (numéro d’entreprise : 0x0a4c) de type 5. -
no cspf
—Ni le PCE ni le PCC n’effectuent de calcul de chemin contraint. Les points de terminaison et les contraintes sont donnés au module RSVP pour la mise en place du LSP avec le chemin IGP.Un PCC utilise
no cspf
le type de calcul dans les cas suivants :-
Lorsque le PCE envoie
local cspf
TLV, et lorsque la configuration Junos OS ou le modèle correspondant pour ce LSP inclusno-cspf
dans le LSP délégué PCC. -
Lorsque le PCE envoie
local cspf
TLV et lorsque le modèle de configuration Junos OS pour ce LSP est inclusno-cspf
dans le LSP initié par PCE. -
Lorsque le PCE n’envoie
local cspf
pas de TLV avec un ERO vide ou un ERO lâche (avec bit libre défini dans l’objet ERO).
-
Avec ces nouveaux types de calcul, un PCC peut accepter un objet ERO soit en tant qu’ERO lâche, soit en tant qu’ERO vide. Une entité externe de calcul de chemin qui n’est pas capable de calculer un chemin peut modifier des paramètres tels que la bande passante et la couleur, en fonction de l’analyse. Dans de tels cas, un objet ERO vide ou un ERO lâche est utilisé et le chemin à emprunter est décidé par le PCC.
LSP RSVP-TE point-à-multipoint contrôlés par PCE
Une fois qu’une session PCEP est établie entre un PCE et un PCC, le PCC signale tous les LSP du système au PCE pour la synchronisation de l’état LSP. Cela inclut les LSP point à point contrôlés, délégués par PCE et initiés par PCE. À partir de Junos OS versions 15.1F6 et 16.1R1, cette fonctionnalité est étendue aux rapports LSP point à multipoint. Pour un PCE, le LSP point à multipoint est similaire à celui du LSP point à multipoint RSVP, où le LSP point à multipoint est traité comme un ensemble de LSP point à point regroupés sous un identificateur point à multipoint.
Par défaut, le contrôle PCE des LSP point à multipoint n’est pas pris en charge sur un PCC. Pour ajouter cette fonctionnalité, incluez l’instruction p2mp-lsp-report-capability
au niveau de la [edit protocols pcep pce pce-name]
hiérarchie ou [edit protocols pcep pce-group group-id]
. Une fois que la fonctionnalité de rapport point à multipoint est configurée sur un PCC, le PCC annonce cette fonctionnalité au PCE. Si le PCE annonce la même capacité de rapport point à multipoint en retour, le PCC signale l’arborescence LSP point à multipoint complète au PCE pour la synchronisation de l’état LSP.
Un PCC avec la fonctionnalité LSP TE point-à-multipoint prend en charge la création de rapports de LSP TE point-à-multipoint pour les PCE dynamiques, la mise à jour point à multipoint et la base de données LSP prenant en charge le nom LSP point à multipoint comme clé. Toutefois, les fonctionnalités et fonctions suivantes ne sont pas prises en charge pour Junos OS versions 15.1F6 et 16.1 :
-
LSP statiques point-à-multipoint
-
LSP point à multipoint délégués et initiés par PCE
-
Bande passante automatique
-
TE++
-
Demande PCE et message de réponse
-
Création de LSP point-à-multipoint à l’aide de modèles
-
Configuration de la saisie directe sur les LSP point à multipoint initiés par PCE
-
Configuration de l’entrée directe sur le routeur pointant vers un LSP provisionné.
LSP point à point initiés par PCE
À partir de Junos OS version 16.1, la fonctionnalité PCEP est étendue pour permettre à un PCE dynamique de lancer et de provisionner des LSP d’ingénierie du trafic via un PCC. Auparavant, les LSP étaient configurés sur le PCC et le PCC déléguait le contrôle des LSP externes à un PCE. La propriété de l’État LSP était maintenue par le PCC. Avec l’introduction des LSP initiés par PCE, un PCE peut initier et provisionner un LSP point à point d’ingénierie du trafic de manière dynamique sans avoir besoin d’un LSP configuré localement sur le PCC. À la réception d’un message PCCreate d’un PCE, le PCC crée le LSP initié par le PCE et délègue automatiquement le LSP au PCE.
Par défaut, un PCC rejette la demande de provisionnement des LSP point à point initiés par PCE à partir d’un PCE. Pour activer la prise en charge des LSP initiés par PCE sur le PCC, incluez l’instruction lsp-provisioning aux niveaux de la [edit protocols pcep pce pce-id]
hiérarchie ou [edit protocols pcep pce-group group-id]
.
Un PCC indique sa capacité à prendre en charge les LSP point à point initiés par PCE lors de l’établissement de la session PCEP (Path Computation Element Protocol) avec le PCE. Un PCE sélectionne un PCC avec cette capacité pour initier un LSP. Le PCE fournit au PCC les paramètres LSP initiés par le PCE. À la réception des paramètres LSP point à point initiés par PCE, le PCC configure le LSP, attribue un ID LSP et délègue automatiquement le LSP au PCE.
Lorsque le PCE initiant le LSP ne fournit pas les paramètres LSP point à point initiés par PCE, le PCC utilise les paramètres par défaut. Un modèle LSP facultatif peut également être configuré pour spécifier des valeurs pour le LSP point à point initié par PCE lorsque les paramètres LSP ne sont pas fournis par le PCE. Pour configurer un modèle LSP pour les LSP point à point initiés par PCE sur le PCC, incluez l’instruction label-switched-path-template au niveau de la [edit protocols mpls lsp-external-controller lsp-external-controller]
hiérarchie.
À la fin d’une session PCEP, le PCC démarre deux minuteries sans supprimer immédiatement les LSP initiés par le PCE — et lsp cleanup timer
—delegation cleanup timeout
, afin d’éviter toute interruption des services. Pendant ce temps, un PCE dynamique actif peut prendre le contrôle des LSP provisionnés par le PCE défaillant.
Un PCE peut renvoyer la délégation du LSP point à point initié par le PCE au PCC pour permettre le transfert du LSP entre les PCE. Le contrôle sur les LSP initiés par PCE revient au PCC à l’expiration du délai de nettoyage de la délégation. Lorsque le délai de nettoyage de la délégation expire et qu’aucun autre PCE n’a acquis le contrôle du LSP à partir du PCE défaillant, le PCC prend le contrôle local du LSP initié par le PCE non délégué. Par la suite, lorsque le PCE dynamique d’origine ou un nouveau PCE actif souhaite acquérir le contrôle des LSP point à point initiés par PCE contrôlés localement, le PCC délègue ces LSP au PCE et le minuteur de nettoyage du LSP est arrêté.
Le PCC attend l’expiration du minuteur de nettoyage du LSP avant de supprimer les LSP point à point initiés par le PCE non délégué du PCE ayant échoué. Lorsque le minuteur de nettoyage du LSP expire et qu’aucun autre PCE n’a acquis le contrôle sur les LSP à partir du PCE défaillant, le PCC supprime tous les LSP provisionnés par le PCE défaillant.
À partir de Junos OS version 21.1R1, nous prenons en charge le routage actif non-stop (NSR) pour les LSP point à point et point à multipoint RSVP initiés par PCE. Seul le moteur de routage principal gère la session PCEP avec le contrôleur. Il synchronise tous les LSP RSVP initiés par les PCE, y compris les spécifications de flux multicast pour tous les LSP P2MP initiés par PCE, avec le moteur de routage de secours. Lors d’un basculement, la session PCEP tombe en panne et se rétablit lorsque le moteur de routage de secours devient le moteur de routage principal. Cela réduit la perte de trafic pour le trafic transporté sur les LSP RSVP initiés par PCE pendant les basculements du moteur de routage. Cette fonctionnalité est activée lorsque NSR est configuré.
LSP de contournement initié par le PCE
- Comprendre les LSP de contournement initiés par PCE
- Avantages du LSP de contournement initié par le PCE
- Comportement des LSP de dérivation initiés par PCE en cas d’échec de session PCEP
Comprendre les LSP de contournement initiés par PCE
Des pannes de trafic peuvent survenir au moment de la défaillance d’une liaison ou d’un nud, car les chemins de protection de secours dans le réseau ne disposent pas d’une bande passante suffisante pour gérer le trafic. Dans de tels réseaux, bien qu’un PCE puisse être utilisé pour calculer tous les chemins, pour optimiser les performances du réseau, les chemins de protection locaux doivent également être contrôlés via le PCE.
Junos OS version 19.2R1 et ultérieures fournissent une prise en charge partielle du brouillon Internet draft-cbrt-pce-stateful-local-protection-01 (expire en décembre 2018), Extensions PCEP pour RSVP-TE Local-Protection avec PCE-Stateful, où la fonctionnalité PCEP est étendue pour permettre à un PCE dynamique d’initier, de provisionner et de gérer des LSP de contournement pour une interface protégée. Le PCE peut initier plusieurs LSP de contournement avec réservation de bande passante pour protéger un lien ou un nud. On s’attend à ce que la bande passante sur le LSP de dérivation soit inférieure à la bande passante totale des LSP principaux qu’il pourrait protéger.
Le mécanisme de sélection de dérivation existant, qui préfère les LSP de dérivation manuelle (si disponible) aux LSP de dérivation dynamique, est étendu pour préférer les LSP de dérivation provisionnés par PCE (le cas échéant) aux LSP de dérivation dynamique. Les LSP de dérivation provisionnés par PCE ont une préférence plus élevée que les LSP de dérivation dynamique, mais sont moins préférés aux LSP de dérivation manuelle.
L’ensemble des opérations qui sont utilisées pour être effectuées sur les LSP de dérivation opérationnels, tels que clear rsvp session
, peut également être effectuée sur les LSP de dérivation initiés par PCE. Vous pouvez utiliser des commandes, telles que show path-computation-client status extensive
et show path-computation-client lsp
pour afficher les statistiques LSP de contournement initiées par PCE.
Avec la prise en charge du LSP de contournement initié par PCE, vous pouvez :
-
Créez un LSP de contournement RSVP via PCEP à partir d’un contrôleur externe, où le LSP de contournement :
-
peut être pour la protection d’un lien ou d’un nœud.
-
doit avoir une bande passante différente de zéro.
-
doit avoir un ERO strict spécifié.
-
-
Mettez à jour la bande passante et l’ERO d’un LSP de dérivation créé par PCE.
-
Surabonnez la bande passante LSP de dérivation pour le contrôle d’admission des LSP principaux. Il doit s’agir d’un paramètre par bypass et doit permettre la mise à jour de l’abonnement par LSP de bypass.
Avantages du LSP de contournement initié par le PCE
Les LSP de contournement initiés par PCE offrent les avantages suivants :
-
Un meilleur contrôle du trafic après une défaillance et un calcul plus déterministe des chemins de protection.
-
Répondez à des contraintes complexes et à des exigences de diversité, telles que le maintien de chemins diversifiés pour les prestataires de services linguistiques, ainsi que de leurs chemins de protection locaux.
-
Assurez-vous que les liaisons ne sont pas surchargées en cas de défaillance.
Comportement des LSP de dérivation initiés par PCE en cas d’échec de session PCEP
En cas d’échec d’une session PCEP, les LSP de contournement initiés par PCE deviennent orphelins jusqu’à l’expiration du délai d’expiration de l’état. Les LSP de dérivation initiés par PCE sont nettoyés à l’expiration du délai d’expiration de l’état. Pour obtenir le contrôle d’un LSP de contournement initié par PCE (après l’échec de la session PCEP), un PCE (soit le PCE principal, soit tout PCE secondaire) envoie un message PCInitiate avant l’expiration du délai d’expiration de l’état.
LSP point-à-multipoint initiés par PCE
Avec l’introduction des LSP point à multipoint initiés par PCE, un PCE peut initier et provisionner un LSP point à multipoint de manière dynamique sans avoir besoin d’une configuration LSP locale sur le PCC. Cela permet au PCE de contrôler le timing et la séquence des calculs de chemin point à multipoint au sein et entre les sessions PCEP (Path Computation Element Protocol), créant ainsi un réseau dynamique contrôlé et déployé de manière centralisée.
Pour plus d’informations, reportez-vous à la section Présentation du protocole d’élément de calcul de chemin pour MPLS RSVP-TE avec prise en charge des LSP point à multipoint initiés par PCE.
LSP SRv6 dans PCEP
Le routage de segments peut être appliqué aux plans de transfert MPLS et IPv6. L’élément de calcul de chemin (PCE) calcule les chemins SR pour les plans de transfert MPLS et IPv6. Le routage de segments pour PCEP prend en charge les LSP SR tels que les LSP SR initiés, créés localement et délégués par PCE dans le plan de transfert IPv6.
Avantages des LSP SRv6 dans PCEP
- Permet de créer des LSP SRv6 initiés par PCE.
- Déléguez au contrôleur les LSP SRv6 créés sur le routeur.
- Signalez les LSP créés localement sur le routeur au contrôleur.
- La programmation réseau SRv6 permet d’exploiter le routage de segments sans avoir à déployer de MPLS.
PCEP prend en charge la création, la mise à jour et la suppression de LSP SRv6 colorés et non colorés initiés par PCE. Lorsque le LSP SRv6 initié par PCE coexiste avec un LSP SRv6 statique pour la même adresse IP ou IP basée sur la couleur, la route contributive LSP SRv6 TE statique est préférée à la route contributive LSP SRv6 TE initiée par PCE.
Pour configurer une session PCEP afin qu’elle soit compatible SRv6, vous devez activer l’instruction de srv6-capability
configuration au niveau de la hiérarchie [edit protocols pcep pce pce-id] ou [edit protocols pcep pce-group pce-id
]. Si l’instruction de configuration est activée, vous devez également activer l’instruction de configuration srv6 au niveau de la hiérarchie [edit protocols source-packet-routing
], sinon des erreurs s’afficheront lors de srv6-capability
la validation.
Pour configurer SRv6 pour SR-TE, vous devez ajouter l’instruction de configuration srv6 au niveau de la hiérarchie [edit protocols source-packet-routing].
[Pour plus d’informations, reportez-vous à la section Présentation de la stratégie SR-TE pour le tunnel SRv6 .
Pour configurer la profondeur maximale de la liste de segments pour le LSP SRv6, vous devez activer l’instruction de configuration au niveau de maximum-srv6-segment-list-depth
la hiérarchie [edit protocols pcep
].
LSP à bande passante automatique et contrôle PCE
À partir de Junos OS version 14.2R4, la prise en charge de la bande passante automatique est fournie pour les LSP contrôlés par PCE. Dans les versions précédentes, l’option de bande passante automatique ne s’appliquait pas aux LSP contrôlés par PCE, bien que les LSP sous le contrôle de la bande passante automatique et du routage basé sur les contraintes puissent coexister avec les LSP contrôlés par PCE. La collecte de statistiques pour la bande passante automatique ne prenait effet que lorsque le mode de contrôle d’un LSP contrôlé par PCE passait de l’externe au local. Cela se produisait dans des cas tels que l’absence de connectivité à un PCE ou lorsqu’un PCE renvoie la délégation de LSP au PCC.
Authentification TCP-MD5 pour les sessions PCEP
Un serveur PCE dynamique automatise la création de chemins d’ingénierie du trafic sur l’ensemble du réseau, augmentant ainsi l’utilisation du réseau et permettant une expérience de mise en réseau programmable personnalisée grâce à l’utilisation de la communication PCEP avec un PCC. Un PCC envoie des rapports LSP à un serveur PCE, qui met à jour ou provisionne les LSP au PCC. Les données envoyées via une session PCEP sont cruciales pour qu’un serveur PCE puisse effectuer un calcul de chemin externe. Par conséquent, une attaque sur la communication PCEP peut perturber les services réseau. Si des messages PCEP modifiés sont envoyés à un PCC, des LSP inappropriés peuvent être configurés. De même, si des messages PCEP modifiés sont envoyés à un PCE, une vue incorrecte du réseau est apprise par le PCE.
Compte tenu de l’importance de la communication PCEP entre un PCE et un PCC pour l’exécution efficace des fonctionnalités PCE, la version 16.1 de Junos OS introduit la fonctionnalité de sécurisation d’une session PCEP à l’aide de l’authentification TCP-MD5 conformément à la RFC 5440. Cette fonctionnalité protège la communication entre un PCE et un PCC sur une session PCEP, qui peut être victime d’une attaque et peut perturber les services réseau.
Pour activer le mécanisme de sécurité MD5 pour une session PCEP, il est recommandé de définir et de lier la clé d’authentification MD5 au niveau hiérarchique [edit protocols pcep pce pce-id]
d’une session PCEP. Cependant, vous pouvez également utiliser un trousseau prédéfini au niveau de la [edit security authentication-key-chains key-chain]
hiérarchie pour sécuriser une session PCEP. Dans ce cas, vous devez lier le trousseau prédéfini à la session PCEP au niveau de la [edit protocols pcep pce pce-id]
hiérarchie.
La configuration suivante est exécutée sur le PCC pour établir une session PCEP sécurisée avec un PCE :
-
À l’aide de la clé d’authentification MD5 :
[edit protocols pcep pce pce-id] user@PCC# set authentication-key key
-
Utilisation du trousseau d’authentification prédéfini :
[edit protocols pcep pce pce-id] user@PCC# set authentication-key-chain key-chain user@PCC# set authentication-algorithm md5
Pour que les sessions PCEP sécurisées soient établies avec succès, l’authentification MD5 doit être configurée avec la clé d’authentification pré-partagée à la fois sur le serveur PCE et sur le PCC. Le PCE et le PCC utilisent la même clé pour vérifier l’authenticité de chaque segment envoyé sur la connexion TCP de la session PCEP.
-
Junos OS version 16.1 prend uniquement en charge l’authentification TCP-MD5 pour les sessions PCEP, sans étendre la prise en charge de TLS et TCP-AO, par exemple la protection contre l’écoute clandestine, la falsification et la falsification de messages.
-
L’application initiale d’un mécanisme de sécurité à une session PCEP entraîne la réinitialisation de la session.
-
Si MD5 est mal configuré ou n’est pas configuré d’un côté de la session PCEP, la session n’est pas établie. Vérifiez que les configurations du PCC et du PCE correspondent.
-
Cette fonctionnalité ne prend en charge aucun mécanisme d’authentification de session.
-
Pour afficher le trousseau d’authentification utilisé par la session PCEP, utilisez les sorties de
show path-computation-client status
la commande etshow protocols pcep
. -
Utilisez la
show system statistics tcp | match auth
commande pour afficher le nombre de paquets abandonnés par TCP en raison d’erreurs d’authentification. -
Le fonctionnement du trousseau peut être vérifié à l’aide de la sortie de commande
show security keychain detail
.
Impact de l’implémentation PCE côté client sur les performances du réseau
La maintenance d’une base de données dynamique peut s’avérer non triviale. Dans un environnement PCE centralisé unique, un PCE dynamique doit simplement se souvenir de tous les LSP TE que le PCE a calculés, des LSP TE qui ont été réellement configurés (si cela peut être connu) et de la date à laquelle les LSP TE ont été démantelés. Cependant, ces exigences surchargent considérablement le protocole de contrôle en termes d’état, d’utilisation et de traitement du réseau, et d’optimisation globale des liaisons sur le réseau. Ainsi, les préoccupations d’une mise en œuvre dynamique de PCE sont les suivantes :
-
Tout mécanisme de synchronisation fiable engendre une surcharge importante du plan de contrôle. Les PCE peuvent synchroniser l’état en communiquant entre eux, mais lorsque les LSP TE sont configurés à l’aide d’un calcul distribué effectué entre plusieurs PCE, les problèmes de synchronisation et d’évitement des conditions de concurrence deviennent plus importants et plus complexes.
-
La synchronisation de base de données d’ingénierie du trafic hors bande peut s’avérer complexe avec plusieurs PCE configurés dans un modèle de calcul PCE distribué, et peut être sujette à des conditions de concurrence, à des problèmes d’évolutivité, etc.
-
Les calculs de chemins intégrant l’état total du réseau sont extrêmement complexes, même si le PCE dispose d’informations détaillées sur l’ensemble des chemins, priorités et couches.
Malgré les préoccupations ci-dessus, l’implémentation partielle côté client du PCE dynamique est extrêmement efficace dans les grands systèmes d’ingénierie du trafic. Il offre une convergence rapide et des avantages significatifs en termes d’utilisation optimale des ressources, en fournissant la nécessité d’une visibilité globale d’un état LSP TE et d’un contrôle ordonné des réservations de chemins sur les équipements du système contrôlé.
Exemple : Configuration du protocole Path Computation Element pour MPLS RSVP-TE
Cet exemple montre comment activer le calcul de chemin externe par un élément de calcul de chemin (PCE) pour les chemins de commutation d’étiquettes (LSP TE) d’ingénierie de trafic sur un client de calcul de chemin (PCC). Il montre également comment configurer le protocole PCEP (Path Computation Element Protocol) sur le PCC pour permettre la communication PCE à PCC.
Conditions préalables
Cet exemple utilise les composants matériels et logiciels suivants :
Trois routeurs qui peuvent être une combinaison de routeurs ACX Series : M Series routeurs de périphérie multiservice, MX Series Plates-formes de routage universelles 5G, T Series routeurs centraux ou PTX Series routeur de transport, dont l’un est configuré en tant que PCC.
Une connexion TCP à un PCE dynamique externe à partir du PCC.
Junos OS version 12.3 ou ultérieure s’exécute sur le PCC avec le package complémentaire JSDN.
Le package complémentaire JSDN doit être installé avec le package d’installation principal de Junos OS.
Avant de commencer :
Configurez les interfaces de l’appareil.
Configurez MPLS et RSVP-TE.
Configurez IS-IS ou tout autre protocole IGP.
Présentation
À partir de Junos OS version 12.3, la fonctionnalité MPLS RSVP-TE est étendue pour fournir une implémentation partielle côté client de l’architecture PCE dynamique (draft-ietf-pce-stateful-pce) sur un PCC.
L’implémentation partielle côté client de l’architecture PCE à états est basée sur la version 2 d’Internet draft draft-ietf-pce-stateful-pce. À partir de Junos OS version 16.1, cette implémentation est mise à niveau pour prendre en charge la version 7, telle que définie dans Internet draft draft-ietf-pce-stateful-pce-07. Les versions antérieures à la version 16.1 prennent en charge l’ancienne version du brouillon PCE, ce qui entraîne des problèmes d’interopérabilité entre un PCC exécutant une version précédente et un serveur PCE dynamique qui adhère au brouillon Internet draft-ietf-pce-stateful-pce-07.
Pour activer le calcul de chemin externe par un PCE, incluez l’instruction sur le lsp-external-controller
PCC aux niveaux de la [edit mpls]
hiérarchie et [edit mpls lsp lsp-name]
.
lsp-external-controller pccd;
Un LSP configuré avec l’instruction est appelé LSP contrôlé par PCE et est sous le contrôle externe d’un lsp-external-controller
PCE par défaut. Un PCE dynamique actif peut remplacer les paramètres définis à partir de l’interface de ligne de commande, tels que la bande passante, le chemin (ERO) et la priorité, pour ces LSP contrôlés par PCE du PCC.
Pour activer la communication PCE à PCC, configurez PCEP sur le PCC au niveau de la [edit protocols]
hiérarchie.
pcep { ... }
Lors de la configuration de PCEP sur un PCC, tenez compte des considérations suivantes :
Le package complémentaire JSDN doit être installé avec le package d’installation principal de Junos OS.
Junos OS version 12.3 prend uniquement en charge les PCE dynamiques.
Un PCC peut se connecter à un maximum de 10 PCE dynamiques. À un moment donné, il ne peut y avoir qu’un seul PCE principal (le PCE avec la valeur de priorité la plus basse, ou le PCE qui se connecte au PCC en premier en l’absence d’une priorité PCE) auquel le PCC délègue des LSP pour le calcul du chemin.
Pour Junos OS version 12.3, le PCC lance toujours les sessions PCEP. Les sessions PCEP initiées par des PCE distants ne sont pas acceptées par le PCC.
Les fonctionnalités LSP existantes, telles que la protection LSP et le make-before-break, fonctionnent pour les LSP contrôlés par PCE.
L’option de bande passante automatique est désactivée pour les LSP contrôlés par PCE, bien que les LSP sous le contrôle de la bande passante automatique et du routage basé sur les contraintes puissent coexister avec les LSP contrôlés par PCE.
Les LSP contrôlés par PCE peuvent être référencés par d’autres configurations CLI, telles que lsp-nexthop vers des routes, des contiguïtés de transfert, des connexions CCC et des tunnels logiques.
Les LSP contrôlés par PCE ne prennent pas en charge GRES.
Les LSP contrôlés par PCE sous des systèmes logiques ne sont pas pris en charge.
Les LSP contrôlés par PCE ne peuvent pas être des LSP point à multipoint.
Les LSP bidirectionnels ne sont pas pris en charge.
Les LSP contrôlés par PCE ne peuvent pas avoir de chemins secondaires sans chemin principal.
Les LSP contrôlés par PCE dépendent du calcul de chemin externe, ce qui a un impact sur le temps de configuration global, les réacheminements et les fonctionnalités de pré-défaillance.
Le temps de configuration et le temps de convergence (reroutage, MBB) pour les LSP existants sont les mêmes que dans les versions précédentes, en l’absence de LSP contrôlés par PCE. Cependant, un faible impact est observé en présence de LSP contrôlés par PCE.
On s’attend à ce que le temps de calcul de l’ERO soit significativement plus élevé que celui du CSPF local.
Topologie
Dans cet exemple, PCC est le routeur entrant qui se connecte au PCE dynamique actif externe.
Les LSP externes du routeur PCC sont calculés comme suit :
Le PCC du routeur reçoit la configuration du tunnel LSP qui a été configurée à l’aide de l’interface de ligne de commande. En supposant que la configuration reçue est activée avec le calcul de chemin externe, le PCC du routeur se rend compte que certains des attributs LSP (bande passante, chemin et priorité) sont sous le contrôle du PCE dynamique et délègue le LSP au PCE.
Dans cet exemple, le LSP externe est appelé
PCC-to-R2
et il est configuré à partir du routeur PCC vers le routeur R2 . L’ERO configuré par CLI estPCC-to-R2
PCC-R0-R1-R2. La bande passante est de 10 m et les valeurs de priorité de configuration et dePCC-to-R2
maintien sont 4.Le PCC du routeur tente de récupérer les attributs LSP contrôlés par PCE. Pour ce faire, le PCC du routeur envoie un message PCRpt au PCE dynamique indiquant que le LSP a été configuré. Le message PCRpt communique l’état du LSP et contient les paramètres de configuration locaux du LSP.
Le PCE dynamique modifie un ou plusieurs des attributs LSP délégués et envoie les nouveaux paramètres LSP au PCC du routeur via le message PCUpd.
À la réception des nouveaux paramètres LSP, le routeur PCC configure un nouveau LSP et le resignale à l’aide du chemin fourni par le PCE.
Dans cet exemple, l’ERO fourni par l’ECP
PCC-to-R2
est PCC-R3-R2. La bande passante pour est de 8 m, et les valeurs de priorité de configuration et dePCC-to-R2
maintien sont 3.Le PCC du routeur envoie un PCRpt avec le nouveau RRO au PCE dynamique.
Configuration
Configuration rapide de l’interface de ligne de commande
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 à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit]
hiérarchie.
PCC
set interfaces ge-1/0/1 unit 0 family inet address 20.31.4.1/24 set interfaces ge-1/0/1 unit 0 family iso set interfaces ge-1/0/1 unit 0 family mpls set interfaces ge-1/1/1 unit 0 family inet address 20.31.1.1/24 set interfaces ge-1/1/1 unit 0 family iso set interfaces ge-1/1/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.179.95/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls lsp-external-controller pccd set protocols mpls label-switched-path PCC-to-R2 to 10.255.179.98 set protocols mpls label-switched-path PCC-to-R2 bandwidth 10m set protocols mpls label-switched-path PCC-to-R2 priority 4 4 set protocols mpls label-switched-path PCC-to-R2 primary to-R2-path set protocols mpls label-switched-path PCC-to-R2 lsp-external-controller pccd set protocols mpls path to-R2-path 20.31.1.2 strict set protocols mpls path to-R2-path 20.31.2.2 strict set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis level 1 disable set protocols isis interface all set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0 set protocols pcep pce pce1 destination-ipv4-address 10.209.57.166 set protocols pcep pce pce1 destination-port 4189 set protocols pcep pce pce1 pce-type active set protocols pcep pce pce1 pce-type stateful
R0
set interfaces ge-1/0/6 unit 0 family inet address 20.31.1.2/24 set interfaces ge-1/0/6 unit 0 family iso set interfaces ge-1/0/6 unit 0 family mpls set interfaces ge-1/0/7 unit 0 family inet address 20.31.2.1/24 set interfaces ge-1/0/7 unit 0 family iso set interfaces ge-1/0/7 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.179.96/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis level 1 disable set protocols isis interface all set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0
R1
set system ports console log-out-on-disconnect set interfaces ge-2/0/3 unit 0 family inet address 20.31.2.2/24 set interfaces ge-2/0/3 unit 0 family iso set interfaces ge-2/0/3 unit 0 family mpls set interfaces ge-2/0/4 unit 0 family inet address 20.31.8.1/24 set interfaces ge-2/0/4 unit 0 family iso set interfaces ge-2/0/4 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.179.97/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis level 1 disable set protocols isis interface all set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0
R2
set interfaces ge-1/0/2 unit 0 family inet address 20.31.8.2/24 set interfaces ge-1/0/2 unit 0 family iso set interfaces ge-1/0/2 unit 0 family mpls set interfaces ge-1/0/3 unit 0 family inet address 20.31.5.2/24 set interfaces ge-1/0/3 unit 0 family iso set interfaces ge-1/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.179.98/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis level 1 disable set protocols isis interface all set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0
R3
set interfaces ge-2/0/1 unit 0 family inet address 20.31.4.2/24 set interfaces ge-2/0/1 unit 0 family iso set interfaces ge-2/0/1 unit 0 family mpls set interfaces ge-2/0/3 unit 0 family inet address 20.31.5.1/24 set interfaces ge-2/0/3 unit 0 family iso set interfaces ge-2/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.179.99/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis level 1 disable set protocols isis interface all set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0
Procédure
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, consultez Utilisation de l’éditeur CLI en mode Configuration.
Pour configurer le routeur PCC :
Répétez cette procédure pour chaque Juniper Networks routeur entrant du domaine MPLS, après avoir modifié les noms d’interface, les adresses et tous les autres paramètres appropriés pour chaque routeur.
Configurez les interfaces.
Pour activer MPLS, incluez la famille de protocoles sur l’interface afin que celle-ci ne rejette pas le trafic MPLS entrant.
[edit interfaces]
user@PCC# set ge-1/0/1 unit 0 family inet address 20.31.4.1/24 user@PCC# set ge-1/0/1 unit 0 family iso user@PCC# set ge-1/0/1 unit 0 family mpls user@PCC# set ge-1/1/1 unit 0 family inet address 20.31.1.1/24 user@PCC# set ge-1/1/1 unit 0 family iso user@PCC# set ge-1/1/1 unit 0 family mpls user@PCC# set lo0 unit 0 family inet address 10.255.179.95/32Activez RSVP sur toutes les interfaces du routeur PCC, à l’exception de l’interface de gestion.
[edit protocols]
user@PCC# set rsvp interface all user@PCC# set rsvp interface fxp0.0 disableConfigurez le chemin de commutation d’étiquettes (LSP) du routeur PCC au routeur R2 et activez le contrôle externe des LSP par le PCE.
[edit protocols] user@PCC# set mpls lsp-external-controller pccd user@PCC# set mpls label-switched-path PCC-to-R2 to 10.255.179.98/32 user@PCC# set mpls label-switched-path PCC-to-R2 bandwidth 10m user@PCC# set protocols mpls label-switched-path PCC-to-R2 priority 4 4 user@PCC# set protocols mpls label-switched-path PCC-to-R2 primary to-R2-path user@PCC# set protocols mpls label-switched-path PCC-to-R2 lsp-external-controller pccd
Configurez le LSP du routeur PCC au routeur R2, qui dispose d’un contrôle local et est remplacé par les paramètres LSP fournis par PCE.
[edit protocols] user@PCC# set mpls path to-R2-path 20.31.1.2/30 strict user@PCC# set mpls path to-R2-path 20.31.2.2/30 strict
Activez MPLS sur toutes les interfaces du routeur PCC, à l’exception de l’interface de gestion.
[edit protocols] user@PCC# set mpls interface all user@PCC# set mpls interface fxp0.0 disable
Configurez IS-IS sur toutes les interfaces du routeur PCC, à l’exception de l’interface de gestion.
[edit protocols] user@PCC# set isis level 1 disable user@PCC# set isis interface all user@PCC# set isis interface fxp0.0 disable user@PCC# set isis interface lo0.0
Définissez le PCE auquel le routeur PCC se connecte, puis configurez l’adresse IP du PCE.
[edit protocols] user@PCC# set pcep pce pce1 destination-ipv4-address 10.209.57.166
Configurez le port de destination pour le PCC du routeur qui se connecte à un PCE à l’aide du PCEP basé sur TCP.
[edit protocols] user@PCC# set pcep pce pce1 destination-port 4189
Configurez le type PCE.
[edit protocols] user@PCC# set pcep pce pce1 pce-type active user@PCC# set pcep pce pce1 pce-type stateful
Résultats
À partir du mode de configuration, confirmez votre configuration en entrant les commandes show interfaces
et show protocols
. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
user@PCC# show interfaces
ge-1/0/1 {
unit 0 {
family inet {
address 20.31.4.1/24;
}
family iso;
family mpls;
}
}
ge-1/1/1 {
unit 0 {
family inet {
address 20.31.1.1/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.179.95/32;
}
}
}
user@PCC# show protocols
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
lsp-external-controller pccd;
label-switched-path PCC-to-R2 {
to 10.255.179.98;
bandwidth 10m;
priority 4 4;
primary to-R2-path;
lsp-external-controller pccd;
}
path to-R2-path {
20.31.1.2 strict;
20.31.2.2 strict;
}
interface all;
interface fxp0.0 {
disable;
}
}
isis {
level 1 disable;
interface all;
interface fxp0.0 {
disable;
}
interface lo0.0;
}
pcep {
pce pce1 {
destination-ipv4-address 10.209.57.166;
destination-port 4189;
pce-type active stateful;
}
}
Si vous avez terminé de configurer l’appareil, passez commit
en mode de configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification de l’état de la session PCEP
- Vérification de l’état du LSP contrôlé par PCE lorsque le contrôle LSP est externe
- Vérification de l’état du LSP contrôlé par PCE lorsque le contrôle LSP est local
Vérification de l’état de la session PCEP
But
Vérifiez l’état de la session PCEP entre le PCE et le PCC du routeur lorsque l’état PCE est actif.
Action
À partir du mode opérationnel, exécutez la show path-computation-client active-pce
commande.
user@PCC>
show path-computation-client active-pce
PCE pce1
General
IP address : 10.209.57.166
Priority : 0
PCE status : PCE_STATE_UP
Session type : PCE_TYPE_STATEFULACTIVE
PCE-mastership : main
Counters
PCReqs Total: 0 last 5min: 0 last hour: 0
PCReps Total: 0 last 5min: 0 last hour: 0
PCRpts Total: 5 last 5min: 5 last hour: 5
PCUpdates Total: 1 last 5min: 1 last hour: 1
Timers
Local Keepalive timer: 30 [s] Dead timer: 120 [s]
Remote Keepalive timer: 30 [s] Dead timer: 120 [s]
Errors
PCErr-recv
PCErr-sent
PCE-PCC-NTFS
PCC-PCE-NTFS
Sens
La sortie affiche des informations sur le PCE dynamique actif auquel le routeur PCC est connecté. Le PCE status
champ de sortie indique l’état actuel de la session PCEP entre le PCE et le PCC du routeur.
Pour pce1
, l’état de la session PCEP est PCE_STATE_UP
, ce qui indique que la session PCEP a été établie entre les homologues PCEP.
Les statistiques indiquent PCRpts
le nombre de messages envoyés par le PCC du routeur au PCE pour signaler l’état actuel des LSP. Les PCUpdates
statistiques indiquent le nombre de messages reçus par le PCC du routeur à partir du PCE. Les PCUpdates
messages incluent les paramètres PCE modifiés pour les LSP contrôlés par PCE.
Vérification de l’état du LSP contrôlé par PCE lorsque le contrôle LSP est externe
But
Vérifiez l’état du LSP contrôlé par PCE du routeur PCC au routeur R2 lorsque le LSP est sous contrôle externe.
Action
À partir du mode opérationnel, exécutez la show mpls lsp name PCC-to-R2 extensive
commande.
user@PCC>
show mpls lsp name PCC-to-R2 extensive
Ingress LSP: 1 sessions
10.255.179.98
From: 10.255.183.59, State: Up, ActiveRoute: 0, LSPname: PCC-to-R2
ActivePath: to-R2-path (primary)
LSPtype: Externally controlled, Penultimate hop popping
LSP Control Status: Externally controlled
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary to-R2-path State: Up
Priorities: 3 3
Bandwidth: 8Mbps
SmartOptimizeTimer: 180
No computed ERO.
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
20.31.4.2 20.31.5.2
21 Mar 11 05:00:56.736 EXTCTRL LSP: Sent Path computation request and LSP status
20 Mar 11 05:00:56.736 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
19 Mar 11 05:00:56.735 Selected as active path
18 Mar 11 05:00:56.734 EXTCTRL LSP: Sent Path computation request and LSP status
17 Mar 11 05:00:56.734 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
16 Mar 11 05:00:56.734 Record Route: 20.31.4.2 20.31.5.2
15 Mar 11 05:00:56.734 Up
14 Mar 11 05:00:56.713 EXTCTRL LSP: Sent Path computation request and LSP status
13 Mar 11 05:00:56.713 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
12 Mar 11 05:00:56.712 Originate Call
11 Mar 11 05:00:56.712 EXTCTRL_LSP: Received setup parameters : 20.31.4.2 20.31.5.2
10 Mar 11 05:00:49.283 EXTCTRL LSP: Sent Path computation request and LSP status
9 Mar 11 05:00:49.283 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
8 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
7 Mar 11 05:00:20.581 EXTCTRL LSP: Sent Path computation request and LSP status
6 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
5 Mar 11 05:00:20.580 EXTCTRL_LSP: Control status became external
4 Mar 11 05:00:03.716 EXTCTRL_LSP: Control status became local
3 Mar 11 05:00:03.714 EXTCTRL LSP: Sent Path computation request and LSP status
2 Mar 11 05:00:03.714 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
1 Mar 11 05:00:00.279 EXTCTRL LSP: Awaiting external controller connection
Created: Mon Mar 11 05:00:00 2013
Total 1 displayed, Up 1, Down 0
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Sens
Dans la sortie, les LSPtype
champs et LSP Control Status
sortie indiquent que le LSP est contrôlé en externe. La sortie affiche également un journal des messages PCEP envoyés entre le PCC du routeur et le PCE.
La session PCEP entre le PCE et le PCC du routeur est active et le PCC du routeur reçoit les paramètres LSP contrôlés par le PCE suivants :
ERO (chemin) : 20.31.4.2 et 20.31.5.2
Bande passante : 8 Mbit/s
Priorités : 3 3 (valeurs de configuration et de conservation)
Vérification de l’état du LSP contrôlé par PCE lorsque le contrôle LSP est local
But
Vérifiez l’état du LSP contrôlé par PCE du routeur PCC au routeur R2 lorsque le contrôle LSP devient local.
Action
À partir du mode opérationnel, exécutez la show mpls lsp name PCC-to-R2 extensive
commande.
user@PCC>
show mpls lsp name PCC-to-R2 extensive
Ingress LSP: 1 sessions
10.255.179.98
From: 10.255.183.59, State: Up, ActiveRoute: 0, LSPname: PCC-to-R2
ActivePath: to-R2-path (primary)
LSPtype: Externally controlled, Penultimate hop popping
LSP Control Status: Locally controlled
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary to-R2-path State: Up
Priorities: 4 4 (ActualPriorities 3 3)
Bandwidth: 10Mbps (ActualBandwidth: 8Mbps)
SmartOptimizeTimer: 180
No computed ERO.
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
20.31.4.2 20.31.5.2
22 Mar 11 05:02:09.618 EXTCTRL_LSP: Control status became local
21 Mar 11 05:00:56.736 EXTCTRL LSP: Sent Path computation request and LSP status
20 Mar 11 05:00:56.736 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
19 Mar 11 05:00:56.735 Selected as active path
18 Mar 11 05:00:56.734 EXTCTRL LSP: Sent Path computation request and LSP status
17 Mar 11 05:00:56.734 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
16 Mar 11 05:00:56.734 Record Route: 20.31.4.2 20.31.5.2
15 Mar 11 05:00:56.734 Up
14 Mar 11 05:00:56.713 EXTCTRL LSP: Sent Path computation request and LSP status
13 Mar 11 05:00:56.713 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
12 Mar 11 05:00:56.712 Originate Call
11 Mar 11 05:00:56.712 EXTCTRL_LSP: Received setup parameters : 20.31.4.2 20.31.5.2
10 Mar 11 05:00:49.283 EXTCTRL LSP: Sent Path computation request and LSP status
9 Mar 11 05:00:49.283 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
8 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
7 Mar 11 05:00:20.581 EXTCTRL LSP: Sent Path computation request and LSP status
6 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
5 Mar 11 05:00:20.580 EXTCTRL_LSP: Control status became external
4 Mar 11 05:00:03.716 EXTCTRL_LSP: Control status became local
3 Mar 11 05:00:03.714 EXTCTRL LSP: Sent Path computation request and LSP status
2 Mar 11 05:00:03.714 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
1 Mar 11 05:00:00.279 EXTCTRL LSP: Awaiting external controller connection
Created: Mon Mar 11 05:00:00 2013
Total 1 displayed, Up 1, Down 0
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Sens
Dans la sortie, le champ de sortie indique que le LSP Control Status
LSP est sous contrôle local. Bien que le LSP contrôlé par PCE soit sous contrôle local, le PCC du routeur continue d’utiliser les paramètres fournis par le PCE jusqu’à la prochaine occasion de re-signaler le LSP.
La sortie affiche désormais les paramètres LSP qui ont été configurés à l’aide de l’interface de ligne de commande, ainsi que les paramètres fournis par PCE utilisés pour établir le LSP en tant que valeurs réelles utilisées.
Bande passante : 10 Mbit/s (bande passante réelle : 8 Mbit/s)
Priorités : 4 4 (Priorités réelles 3 3)
Lors du déclencheur de resignalisation du LSP, le PCC du routeur utilise les paramètres de configuration locaux pour établir le LSP contrôlé par PCE.
user@PCC>
show mpls lsp name PCC-to-R2 extensive externally-controlled
Ingress LSP: 1 sessions
10.255.179.98
From: 10.255.183.59, State: Up, ActiveRoute: 0, LSPname: PCC-to-R2
ActivePath: to-R2-path (primary)
LSPtype: Externally controlled, Penultimate hop popping
LSP Control Status: Locally controlled
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary to-R2-path State: Up
Priorities: 4 4
Bandwidth: 10Mbps
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30)
20.31.1.2 S 20.31.2.2 S 20.31.8.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
20.31.1.2 20.31.2.2 20.31.8.2
28 Mar 11 05:02:51.787 Record Route: 20.31.1.2 20.31.2.2 20.31.8.2
27 Mar 11 05:02:51.787 Up
26 Mar 11 05:02:51.697 EXTCTRL_LSP: Applying local parameters with this signalling attempt
25 Mar 11 05:02:51.697 Originate Call
24 Mar 11 05:02:51.696 Clear Call
23 Mar 11 05:02:51.696 CSPF: computation result accepted 20.31.1.2 20.31.2.2 20.31.8.2
22 Mar 11 05:02:09.618 EXTCTRL_LSP: Control status became local
21 Mar 11 05:00:56.736 EXTCTRL LSP: Sent Path computation request and LSP status
20 Mar 11 05:00:56.736 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
19 Mar 11 05:00:56.735 Selected as active path
18 Mar 11 05:00:56.734 EXTCTRL LSP: Sent Path computation request and LSP status
17 Mar 11 05:00:56.734 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
16 Mar 11 05:00:56.734 Record Route: 20.31.4.2 20.31.5.2
15 Mar 11 05:00:56.734 Up
14 Mar 11 05:00:56.713 EXTCTRL LSP: Sent Path computation request and LSP status
13 Mar 11 05:00:56.713 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
12 Mar 11 05:00:56.712 Originate Call
11 Mar 11 05:00:56.712 EXTCTRL_LSP: Received setup parameters : 20.31.4.2 20.31.5.2
10 Mar 11 05:00:49.283 EXTCTRL LSP: Sent Path computation request and LSP status
9 Mar 11 05:00:49.283 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
8 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
7 Mar 11 05:00:20.581 EXTCTRL LSP: Sent Path computation request and LSP status
6 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
5 Mar 11 05:00:20.580 EXTCTRL_LSP: Control status became external
4 Mar 11 05:00:03.716 EXTCTRL_LSP: Control status became local
3 Mar 11 05:00:03.714 EXTCTRL LSP: Sent Path computation request and LSP status
2 Mar 11 05:00:03.714 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
1 Mar 11 05:00:00.279 EXTCTRL LSP: Awaiting external controller connection
Created: Mon Mar 11 05:00:00 2013
Total 1 displayed, Up 1, Down 0
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Il s’agit Computed ERO
des versions 20.31.1.2, 20.31.2.2 et 20.31.8.2. Le LSP contrôlé par PCE est établi à l’aide des paramètres de configuration locaux.
Exemple : Configuration du protocole d’élément de calcul de chemin pour MPLS RSVP-TE avec prise en charge des LSP point à point initiés par PCE
Cet exemple montre comment configurer le client de calcul de chemin (PCC) avec la capacité de prendre en charge les chemins de commutation d’étiquettes point à point (LSP) initiés par le trafic PCE (Path Computation Element).
Conditions préalables
Cet exemple utilise les composants matériels et logiciels suivants :
Trois routeurs pouvant être une combinaison de routeurs ACX Series, M Series, MX Series ou T Series.
Une connexion TCP à deux PCE dynamiques externes à partir du routeur entrant (PCC).
Junos OS version 16.1 ou ultérieure s’exécutant sur le PCC.
Avant de commencer :
Configurez les interfaces de l’appareil.
Configurez MPLS et RSVP-TE (RSVP-Traffic Engineering).
Configurez OSPF ou tout autre protocole IGP.
Présentation
À partir de Junos OS version 16.1, la fonctionnalité PCEP est étendue pour permettre à un PCE dynamique de lancer et de provisionner des LSP d’ingénierie du trafic via un PCC. Auparavant, les LSP étaient configurés sur le PCC et le PCC déléguait le contrôle des LSP externes à un PCE. La propriété de l’État LSP était maintenue par le PCC. Avec l’introduction des LSP initiés par PCE, un PCE peut initier et provisionner un LSP point à point d’ingénierie du trafic de manière dynamique sans avoir besoin d’un LSP configuré localement sur le PCC. À la réception d’un message PCCreate d’un PCE, le PCC crée le LSP initié par le PCE et délègue automatiquement le LSP au PCE.
Lors de la configuration de la prise en charge des LSP point à point initiés par PCE pour un PCC, tenez compte des considérations suivantes :
Junos OS version 13.3 prend uniquement en charge les PCE dynamiques.
Pour Junos OS version 13.3, le PCC lance toujours les sessions PCEP. Les sessions PCEP initiées par des PCE distants ne sont pas acceptées par le PCC.
Les fonctionnalités LSP existantes, telles que la protection LSP et le make-before-break, fonctionnent pour les LSP initiés par PCE.
Les LSP initiés par PCE ne prennent pas en charge le basculement GRES (Graceful Moteur de Routage).
Les LSP initiés par PCE dans les systèmes logiques ne sont pas pris en charge.
Les LSP initiés par PCE ne peuvent pas être des LSP point à multipoint.
Les LSP bidirectionnels ne sont pas pris en charge.
RSVP-TE pour les liens non numérotés n’est pas pris en charge. Les LSP initiés par PCE ne prennent en charge que les liaisons numérotées.
Le PCE qui initie un LSP de routage de segments peut utiliser les étiquettes d’ID de segment de liaison (SID) associées aux LSP de routage de segments non colorés pour provisionner les chemins LSP de routage de segments initiés par PCE.
À compter de Junos OS version 18.2R1, les LSP de routage de segments non colorés configurés statiquement sur le périphérique entrant sont signalés à un PCE via une session PCEP. Ces LSP de routage de segments non colorés peuvent être associés à des étiquettes SID de liaison. Grâce à cette fonctionnalité, le PCE peut utiliser cette étiquette SID de liaison dans la pile d’étiquettes pour provisionner des chemins LSP de routage de segments initiés par PCE.
Topologie
Dans cet exemple, PCC est le routeur entrant qui se connecte à deux PCE dynamiques externes : PCE1 et PCE2.
Lorsqu’il y a une nouvelle demande, le PCE dynamique actif lance dynamiquement un LSP pour répondre à l’exigence. Étant donné que PCC est configuré avec la capacité de prendre en charge le LSP initié par PCE, le calcul de chemin sur PCC est effectué comme suit :
Un PCE envoie un message PCCreate au PCC pour initier et provisionner un LSP. Le PCC configure le LSP initié par le PCE à l’aide des paramètres reçus du PCE et délègue automatiquement le LSP initié par le PCE qui l’a initié.
Dans cet exemple, PCE1 est le PCE dynamique actif qui initie et provisionne le LSP initié par PCE sur PCC. À la réception des paramètres LSP initiés par PCE, PCC configure le LSP et délègue automatiquement le LSP initié par PCE à PCE1.
Lorsque la session PCEP entre PCC et PCE1 est terminée, PCC démarre deux temporisateurs pour le LSP initié par PCE1 : delgation cleanup timeout et le minuteur de nettoyage LSP. Pendant ce temps, PCE1 ou PCE2 peut acquérir le contrôle du LSP initié par le PCE.
Si PCE2 prend le contrôle sur le LSP initié par le PCE avant l’expiration du minuteur de nettoyage du LSP, PCC délègue le LSP initié par le PCE à PCE2, et le temporisateur de nettoyage du LSP et le délai d’expiration du nettoyage de la délégation sont arrêtés.
Si le délai de nettoyage de la délégation a expiré et que ni PCE1 ni PCE2 n’ont pris le contrôle du LSP initié par PCE, PCC prend le contrôle local du LSP initié par le PCE non délégué jusqu’à l’expiration du minuteur de nettoyage du LSP.
Après l’expiration du minuteur de nettoyage du LSP, PCC supprime le LSP initié par PCE provisionné par PCE1.
Configuration
Configuration rapide de l’interface de ligne de commande
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 à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit]
hiérarchie.
PCC
set interfaces ge-0/1/1 unit 0 family inet address 10.0.102.9/24 set interfaces ge-0/1/1 unit 0 family iso set interfaces ge-0/1/1 unit 0 family mpls set interfaces ge-0/1/3 unit 0 family inet address 10.0.112.14/24 set interfaces ge-0/1/3 unit 0 family iso set interfaces ge-0/1/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.12.1/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls lsp-external-controller ppcd set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols pcep pce-group PCEGROUP pce-type active set protocols pcep pce-group PCEGROUP pce-type stateful set protocols pcep pce-group PCEGROUP lsp-provisioning set protocols pcep pce-group PCEGROUP lsp-cleanup-timer 30 set protocols pcep pce PCE1 destination-ipv4-address 192.168.69.58 set protocols pcep pce PCE1 destination-port 4189 set protocols pcep pce PCE1 pce-group PCEGROUP set protocols pcep pce PCE2 destination-ipv4-address 192.168.70.65 set protocols pcep pce PCE2 destination-port 4189 set protocols pcep pce PCE2 pce-group PCEGROUP
R1
set interfaces ge-3/1/1 unit 0 family inet address 10.0.102.10/24 set interfaces ge-3/1/1 unit 0 family iso set interfaces ge-3/1/1 unit 0 family mpls set interfaces ge-3/1/2 unit 0 family inet address 10.0.101.9/24 set interfaces ge-3/1/2 unit 0 family iso set interfaces ge-3/1/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.10.1/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable
R2
set interfaces ge-0/1/1 unit 0 family inet address 10.0.101.10/24 set interfaces ge-0/1/1 unit 0 family iso set interfaces ge-0/1/1 unit 0 family mpls set interfaces ge-0/1/3 unit 0 family inet address 10.0.112.13/24 set interfaces ge-0/1/3 unit 0 family iso set interfaces ge-0/1/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.11.1/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable
Procédure
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, consultez Utilisation de l’éditeur CLI en mode Configuration.
Pour configurer le routeur PCC :
Répétez cette procédure pour chaque Juniper Networks routeur entrant du domaine MPLS, après avoir modifié les noms d’interface, les adresses et tous les autres paramètres appropriés pour chaque routeur.
Configurez les interfaces.
Pour activer MPLS, incluez la famille de protocoles sur l’interface afin que celle-ci ne rejette pas le trafic MPLS entrant.
[edit interfaces]
user@PCC# set ge-0/1/1 unit 0 family inet address 10.0.102.9/24 user@PCC# set ge-0/1/1 unit 0 family iso user@PCC# set ge-0/1/1 unit 0 family mpls user@PCC# set ge-0/1/3 unit 0 family inet address 10.0.112.14/24 user@PCC# set ge-0/1/3 unit 0 family iso user@PCC# set ge-0/1/3 unit 0 family mpls user@PCC# set lo0 unit 0 family inet address 192.168.12.1/32Activez RSVP sur toutes les interfaces du PCC, à l’exception de l’interface de gestion.
[edit protocols]
user@PCC# set rsvp interface all user@PCC# set rsvp interface fxp0.0 disableActivez le contrôle externe des LSP par les PCE.
[edit protocols] user@PCC# set mpls lsp-external-controller pccd
Activez MPLS sur toutes les interfaces du PCC, à l’exception de l’interface de gestion.
[edit protocols] user@PCC# set mpls interface all user@PCC# set mpls interface fxp0.0 disable
Configurez OSPF sur toutes les interfaces du PCC, à l’exception de l’interface de gestion.
[edit protocols] user@PCC# set ospf traffic-engineering user@PCC# set ospf area 0.0.0.0 interface all user@PCC# set ospf area 0.0.0.0 interface fxp0.0 disable user@PCC# set ospf interface lo0.0
Définissez le groupe PCE et activez la prise en charge des LSP initiés par PCE pour le groupe PCE.
[edit protocols] user@PCC# set protocols pcep pce-group PCEGROUP pce-type active user@PCC# set protocols pcep pce-group PCEGROUP pce-type stateful user@PCC# set protocols pcep pce-group PCEGROUP lsp-provisioning user@PCC# set protocols pcep pce-group PCEGROUP lsp-cleanup-timer 30
Définissez les PCE qui se connectent au PCC.
[edit protocols] user@PCC# set pcep pce PCE1 destination-ipv4-address 192.168.69.58 user@PCC# set pcep pce PCE1 destination-port 4189 user@PCC# set pcep pce PCE1 pce-group PCEGROUP user@PCC# set pcep pce PCE2 destination-ipv4-address 192.168.70.65 user@PCC# set pcep pce PCE2 destination-port 4189 user@PCC# set pcep pce PCE2 pce-group PCEGROUP
Résultats
À partir du mode de configuration, confirmez votre configuration en entrant les commandes show interfaces
et show protocols
. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
user@PCC# show interfaces
ge-0/1/1 {
unit 0 {
family inet {
address 10.0.102.9/24;
}
family iso;
family mpls;
}
}
ge-0/1/3 {
unit 0 {
family inet {
address 10.0.112.14/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.12.1/32;
}
}
}
user@PCC# show protocols
rsvp {
interface all;
}
interface fxp0.0 {
disable;
}
}
mpls {
lsp-external-controller pccd;
interface all;
interface fxp0.0 {
disable;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
}
}
pce-group PCEGROUP {
pce-type active stateful;
lsp-provisioning;
lsp-cleanup-timer 30;
}
pce PCE1 {
destination-ipv4-address 192.168.69.58;
destination-port 4189;
pce-group PCEGROUP;
}
pce PCE2 {
destination-ipv4-address 192.168.70.65;
destination-port 4189;
pce-group PCEGROUP;
}
Si vous avez terminé de configurer l’appareil, passez commit
en mode de configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification de l’état du PCC
- Vérification de l’état PCE1
- Vérification de l’état du LSP initié par PCE lorsque le LSP est provisionné en externe
Vérification de l’état du PCC
But
Vérifiez l’état de la session PCEP et le résumé LSP entre le PCC et les PCE connectés.
Action
À partir du mode opérationnel, exécutez la show path-computation-client status
commande.
user@PCC# show path-computation-client status Session Type Provisioning Status PCE1 Stateful Active On Up PCE2 Stateful Active On Up LSP Summary Total number of LSPs : 1 Static LSPs : 0 Externally controlled LSPs : 0 Externally provisioned LSPs : 1/16000 (current/limit) Orphaned LSPs : 0 PCE1 (main) Delegated : 1 Externally provisioned : 1 PCE2 Delegated : 0 Externally provisioned : 0
Sens
La sortie affiche l’état de la session PCEP entre les PCE dynamiques actifs et le PCC. Il affiche également des informations sur les différents types de LSP sur le PCC, ainsi que sur le nombre de LSP provisionnés par les PCE connectés et qui leur sont délégués.
Le PCE1 est le principal PCE actif et possède un LSP initié par le PCE qui lui a été automatiquement délégué par le PCC.
Vérification de l’état PCE1
But
Vérifiez l’état du PCE dynamique actif principal.
Action
À partir du mode opérationnel, exécutez la show path-computation-client active-pce detail
commande.
user@PCC# show path-computation-client active-pce PCE PCE1 -------------------------------------------- General IP address : 192.168.69.58 Priority : 0 PCE status : PCE_STATE_UP Session type : PCE_TYPE_STATEFULACTIVE LSP provisioning allowed : On LSP cleanup timer : 30 [s] PCE-mastership : main Max unknown messages : 5 Keepalives received : 0 Keepalives sent : 0 Dead timer : 0 [s] Elapsed as main current : 1 [s] Elapsed as main total : 446380 [s] Unknown msgs/min rate : 0 Session failures : 2198 Corrupted messages : 0 Delegation timeout set : 30 Delegation timeout in : 0 [s] Delegation failures : 0 Connection down : 167092 [s] Counters PCReqs Total: 0 last 5min: 0 last hour: 0 PCReps Total: 0 last 5min: 0 last hour: 0 PCRpts Total: 5 last 5min: 5 last hour: 5 PCUpdates Total: 0 last 5min: 0 last hour: 0 PCCreates Total: 1 last 5min: 1 last hour: 1 Timers Local Keepalive timer: 30 [s] Dead timer: 120 [s] LSP cleanup timer: 30 [s] Remote Keepalive timer: 0 [s] Dead timer: 0 [s] LSP cleanup timer: - [s] Errors PCErr-recv PCErr-sent PCE-PCC-NTFS PCC-PCE-NTFS
Sens
La sortie affiche des informations sur le PCE dynamique actif auquel le PCC est connecté. Le PCE status
champ de sortie indique l’état actuel de la session PCEP entre un PCE et un PCC.
Pour PCE1, l’état de la session PCEP est PCE_STATE_UP
, ce qui indique que la session PCEP a été établie avec le PCC.
Vérification de l’état du LSP initié par PCE lorsque le LSP est provisionné en externe
But
Vérifiez l’état du LSP initié par PCE.
Action
À partir du mode opérationnel, exécutez la show mpls lsp externally-provisioned detail
commande.
user@PCC# show mpls lsp externally-provisioned detail Ingress LSP: 1 sessions 10.0.101.10 From: 10.0.102.9, State: Up, ActiveRoute: 0, LSPname: lsp15 ActivePath: path1 (primary) Link protection desired LSPtype: Externally Provisioned, Penultimate hop popping LSP Control Status: Externally controlled LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary path1 State: Up Priorities: 7 0 Bandwidth: 8Mbps Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3) 10.0.102.10 S 10.0.101.9 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 10.0.102.10 S 10.0.101.9 S
Sens
Dans la sortie, le champ de sortie indique que le LSPtype
LSP est approvisionné en externe.
La session PCEP entre PCC et PCE1 est active et le PCC reçoit les paramètres LSP initiés par PCE suivants :
ERO (chemin) : 10.0.102.10 et 10.0.101.9
Bande passante : 8 Mbit/s
Priorité : 7 0 (valeurs de configuration et de conservation)
Configuration du protocole d’élément de calcul de chemin pour MPLS RSVP-TE avec prise en charge des LSP point à point initiés par PCE
Vous pouvez configurer un client de calcul de chemin (PCC) capable de prendre en charge les chemins de commutation d’étiquettes (LSP) créés dynamiquement à partir d’une entité de calcul de chemin externe centralisée. Un élément de calcul de chemin dynamique (PCE) peut être utilisé pour effectuer un calcul de chemin externe et générer des LSP dynamiques en cas d’augmentation de la demande.
Un PCC crée le LSP point à point initié par le PCE à l’aide des paramètres du LSP fournis par le PCE, ou des paramètres d’un modèle LSP préconfiguré lorsque le PCE ne provisionne pas le LSP, et délègue automatiquement le LSP point à point initié par le PCE au PCE respectif. Par conséquent, pour les LSP initiés par PCE, il n’est pas nécessaire d’avoir un LSP configuré localement sur le PCC.
Un LSP contrôlé par CLI, un LSP contrôlé par PCE et un LSP initié par PCE peuvent coexister ensemble sur un PCC.
Avant de commencer :
Configurez les interfaces de l’appareil.
Configurez MPLS et RSVP-TE.
Configurez OSPF ou tout autre protocole IGP.
Pour configurer PCC afin de prendre en charge les LSP point à point initiés par PCE, effectuez les tâches suivantes :
Exemple de sortie
[edit] user@PCC# edit protocols pcep [edit protocols pcep] user@PCC# set message-rate-limit 50 [edit protocols pcep] user@PCC# set max-provisioned-lsps 16000 [edit protocols pcep] user@PCC# edit pce PCE [edit protocols pcep pce PCE] user@PCC# set delegation-cleanup-timeout 20 [edit protocols pcep pce PCE] user@PCC# set destination-ipv4-address 192.168.69.58 [edit protocols pcep pce PCE] user@PCC# set destination-port 4189 [edit protocols pcep pce PCE] user@PCC# set lsp-cleanup-timer 50 [edit protocols pcep pce PCE] user@PCC# set lsp-provisioning [edit protocols pcep pce PCE] user@PCC# set max-unknown-messages 5 [edit protocols pcep pce PCE] user@PCC# set max-unknown-requests 5 [edit protocols pcep pce PCE] user@PCC# set request-timer 50 [edit protocols pcep pce PCE] user@PCC# up [edit protocols pcep] user@PCC# show message-rate-limit 50; max-provisioned-lsps 16000; pce PCE { destination-ipv4-address 192.168.69.58; destination-port 4189; lsp-provisioning; lsp-cleanup-timer 50; request-timer 50; max-unknown-requests 5; max-unknown-messages 5; delegation-cleanup-timeout 20; } [edit protocols pcep] user@PCC# commit commit complete
Exemple : Configuration du protocole Path Computation Element pour MPLS RSVP-TE avec prise en charge des LSP point-à-multipoint contrôlés par PCE
Cet exemple montre comment configurer le client de calcul de chemin (PCC) avec la capacité de rapporter des chemins de commutation d’étiquettes (LSP TE) d’ingénierie de trafic point à multipoint à un élément de calcul de chemin (PCE).
Conditions préalables
Cet exemple utilise les composants matériels et logiciels suivants :
Trois routeurs pouvant être une combinaison de routeurs ACX Series, M Series, MX Series ou T Series.
Une machine virtuelle configurée avec la fonctionnalité VRR (Virtual Route Reflector).
Une connexion TCP à un PCE dynamique externe à partir du VRR.
Junos OS version 16.1 ou ultérieure s’exécutant sur le PCC.
Avant de commencer :
Configurez les interfaces de l’appareil.
Configurez MPLS et RSVP-TE.
Configurez OSPF ou tout autre protocole IGP.
Présentation
Une fois qu’une session PCEP est établie entre un PCE et un PCC, le PCC signale tous les LSP du système au PCE pour la synchronisation de l’état LSP. Cela inclut les LSP point à point contrôlés, délégués par PCE et initiés par PCE. À partir de Junos OS versions 15.1F6 et 16.1R1, cette fonctionnalité est étendue aux rapports LSP point à multipoint.
Par défaut, le contrôle PCE des LSP point à multipoint n’est pas pris en charge sur un PCC. Pour ajouter cette fonctionnalité, incluez l’instruction p2mp-lsp-report-capability
au niveau de la [edit protocols pcep pce pce-name]
hiérarchie ou [edit protocols pcep pce-group group-id]
.
Topologie
Dans cet exemple, PCC est le routeur entrant, le routeur R1 est le routeur de transit et le routeur R2 est le routeur de sortie. Le PCC est connecté à un réflecteur de route virtuel (VRR) qui est connecté à un PCE. Il existe de nombreuses interfaces point à multipoint entre le PCC, le routeur R1 et le routeur R2.
La création de rapports sur les prestataires de services linguistiques point à multipoint s’exécute comme suit :
Si le PCC du routeur est configuré avec des LSP point à point et point à multipoint sans la prise en charge de la fonctionnalité de création de rapports point à multipoint, seuls les LSP point à point sont signalés au PCE connecté. Par défaut, un PCC ne prend pas en charge la fonctionnalité de création de rapports LSP point à multipoint.
Lorsque le PCC du routeur est configuré avec la fonctionnalité de création de rapports LSP point à multipoint, le PCC annonce d’abord cette capacité à PCE par le biais d’un message de rapport.
Par défaut, un PCE prend en charge la fonctionnalité LSP point à multipoint. À la réception de l’annonce du PCC pour la capacité LSP point à multipoint, le PCE annonce en retour sa capacité au PCC.
À la réception de l’annonce de la capacité point à multipoint par le PCE, le PCC signale toutes les branches des LSP point à multipoint au PCE à l’aide du message de mise à jour.
Une fois que tous les LSP sont signalés au PCE, l’état du LSP est synchronisé entre le PCE et le PCC.
Configuration
Configuration rapide de l’interface de ligne de commande
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 à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit]
hiérarchie.
PCC
set interfaces ge-0/0/0 unit 0 family inet address 1.2.4.1/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 1.2.3.1/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 1.2.2.1/30 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 1.2.5.1/30 set interfaces ge-0/0/3 unit 0 family mpls set interfaces ge-0/0/4 unit 0 family inet address 1.4.0.1/30 set interfaces ge-0/0/4 unit 0 family mpls set interfaces ge-0/0/5 unit 0 family inet address 1.2.1.1/30 set interfaces ge-0/0/5 unit 0 family mpls set interfaces ge-0/0/6 unit 0 family inet address 1.2.0.1/30 set interfaces ge-0/0/6 unit 0 family mpls set routing-options autonomous-system 100 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls lsp-external-controller pccd pce-controlled-lsp pcc_delegated_no_cspf_* label-switched-path-template lsp_template_no_cspf set protocols mpls lsp-external-controller pccd pce-controlled-lsp pce_initiated_no_ero_no_cspf_* label-switched-path-template lsp_template_no_cspf set protocols mpls lsp-external-controller pccd pce-controlled-lsp pce_initiated_loose_ero_no_cspf_* label-switched-path-template lsp_template_no_cspf set protocols mpls traffic-engineering database import policy TE set protocols mpls admin-groups violet 1 set protocols mpls admin-groups indigo 2 set protocols mpls admin-groups blue 3 set protocols mpls admin-groups green 4 set protocols mpls admin-groups yellow 5 set protocols mpls admin-groups orange 6 set protocols mpls label-switched-path lsp_template_no_cspf template set protocols mpls label-switched-path lsp_template_no_cspf no-cspf set protocols mpls label-switched-path lsp1-pcc to 128.102.177.16 set protocols mpls label-switched-path lsp2-pcc to 128.102.177.16 set protocols mpls label-switched-path lsp2-pcc lsp-external-controller pccd set protocols mpls path loose-path 1.2.3.2 loose set protocols mpls path strict-path 1.2.3.2 strict set protocols mpls path strict-path 2.3.3.2 strict set protocols mpls path path-B set protocols mpls path path-C set protocols mpls interface all set protocols mpls interface ge-0/0/6.0 admin-group violet set protocols mpls interface ge-0/0/5.0 admin-group indigo set protocols mpls interface ge-0/0/2.0 admin-group blue set protocols mpls interface ge-0/0/1.0 admin-group green set protocols mpls interface ge-0/0/0.0 admin-group yellow set protocols mpls interface ge-0/0/3.0 admin-group orange set protocols mpls interface fxp0.0 disable set protocols bgp group northstar type internal set protocols bgp group northstar local-address 128.102.180.228 set protocols bgp group northstar family traffic-engineering unicast set protocols bgp group northstar export TE set protocols bgp group northstar neighbor 128.102.180.215 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/6.0 set protocols ospf area 0.0.0.0 interface ge-0/0/5.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/1.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/3.0 set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 interface-type p2p set protocols pcep pce pce1 local-address 10.102.180.228 set protocols pcep pce pce1 destination-ipv4-address 10.102.180.246 set protocols pcep pce pce1 destination-port 4189 set protocols pcep pce pce1 pce-type active set protocols pcep pce pce1 pce-type stateful set protocols pcep pce pce1 lsp-provisioning set protocols pcep pce pce1 lsp-cleanup-timer 0 set protocols pcep pce pce1 delegation-cleanup-timeout 60 set protocols pcep pce pce1 p2mp-lsp-report-capability set policy-options policy-statement TE term 1 from family traffic-engineering set policy-options policy-statement TE term 1 then accept
R1
set interfaces ge-0/0/0 unit 0 family inet address 2.3.4.1/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 1.2.0.2/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 1.2.4.2/30 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 1.2.2.2/30 set interfaces ge-0/0/3 unit 0 family mpls set interfaces ge-0/0/4 unit 0 family inet address 2.3.1.1/30 set interfaces ge-0/0/4 unit 0 family mpls set interfaces ge-0/0/5 unit 0 family inet address 1.2.3.2/30 set interfaces ge-0/0/5 unit 0 family mpls set interfaces ge-0/0/6 unit 0 family inet address 1.2.5.2/30 set interfaces ge-0/0/6 unit 0 family mpls set interfaces ge-0/0/7 unit 0 family inet address 1.2.1.2/30 set interfaces ge-0/0/7 unit 0 family mpls set interfaces ge-0/0/8 unit 0 family inet address 2.3.5.1/30 set interfaces ge-0/0/8 unit 0 family mpls set interfaces ge-0/0/9 unit 0 family inet address 2.3.2.1/30 set interfaces ge-0/0/9 unit 0 family mpls set interfaces ge-0/1/0 unit 0 family inet address 2.3.3.1/30 set interfaces ge-0/1/0 unit 0 family mpls set interfaces ge-0/1/1 unit 0 family inet address 2.3.0.1/30 set interfaces ge-0/1/1 unit 0 family mpls set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls admin-groups violet 1 set protocols mpls admin-groups indigo 2 set protocols mpls admin-groups blue 3 set protocols mpls admin-groups green 4 set protocols mpls admin-groups yellow 5 set protocols mpls admin-groups orange 6 set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols mpls interface ge-0/0/1.0 admin-group violet set protocols mpls interface ge-0/0/7.0 admin-group indigo set protocols mpls interface ge-0/0/3.0 admin-group blue set protocols mpls interface ge-0/0/5.0 admin-group green set protocols mpls interface ge-0/0/2.0 admin-group yellow set protocols mpls interface ge-0/0/6.0 admin-group orange set protocols mpls interface ge-0/1/1.0 admin-group violet set protocols mpls interface ge-0/0/4.0 admin-group indigo set protocols mpls interface ge-0/0/9.0 admin-group blue set protocols mpls interface ge-0/1/0.0 admin-group green set protocols mpls interface ge-0/0/0.0 admin-group yellow set protocols mpls interface ge-0/0/8.0 admin-group orange 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/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/7.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols ospf area 0.0.0.0 interface ge-0/0/5.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/6.0 set protocols ospf area 0.0.0.0 interface ge-0/1/1.0
R2
set interfaces ge-0/0/0 unit 0 family inet address 2.3.0.2/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 2.3.1.2/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 2.3.5.2/30 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 2.3.4.2/30 set interfaces ge-0/0/3 unit 0 family mpls set interfaces ge-0/0/4 unit 0 family inet address 2.3.2.2/30 set interfaces ge-0/0/4 unit 0 family mpls set interfaces ge-0/0/5 unit 0 family inet address 2.3.3.2/30 set interfaces ge-0/0/5 unit 0 family mpls set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls admin-groups violet 1 set protocols mpls admin-groups indigo 2 set protocols mpls admin-groups blue 3 set protocols mpls admin-groups green 4 set protocols mpls admin-groups yellow 5 set protocols mpls admin-groups orange 6 set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols mpls interface ge-0/0/0.0 admin-group violet set protocols mpls interface ge-0/0/1.0 admin-group indigo set protocols mpls interface ge-0/0/4.0 admin-group blue set protocols mpls interface ge-0/0/5.0 admin-group green set protocols mpls interface ge-0/0/3.0 admin-group yellow set protocols mpls interface ge-0/0/2.0 admin-group orange set protocols ospf traffic-engineering 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/4.0 set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive
R3
set interfaces em0 unit 0 family inet address 10.102.180.215/19 set interfaces em1 unit 0 family inet address 4.5.0.1/30 set interfaces em2 unit 0 family inet address 1.4.0.2/30 set interfaces em2 unit 0 family mpls set routing-options router-id 128.102.180.215 set routing-options autonomous-system 100 set protocols topology-export set protocols rsvp interface all set protocols mpls lsp-external-controller pccd set protocols mpls traffic-engineering database import igp-topology set protocols mpls traffic-engineering database import policy TE set protocols mpls interface all set protocols bgp group northstar type internal set protocols bgp group northstar local-address 128.102.180.215 set protocols bgp group northstar family traffic-engineering unicast set protocols bgp group northstar neighbor 128.102.180.228 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface em2.0 interface-type p2p set policy-options policy-statement TE from family traffic-engineering set policy-options policy-statement TE then accept
Procédure
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, consultez Utilisation de l’éditeur CLI en mode Configuration.
Pour configurer le routeur PCC :
Configurez les interfaces du routeur PCC. Pour activer MPLS, incluez la famille de protocoles sur l’interface afin que celle-ci ne rejette pas le trafic MPLS entrant.
[edit interfaces] user@PCC# set ge-0/0/0 unit 0 family inet address 1.2.4.1/30 user@PCC# set ge-0/0/0 unit 0 family mpls user@PCC# set ge-0/0/1 unit 0 family inet address 1.2.3.1/30 user@PCC# set ge-0/0/1 unit 0 family mpls user@PCC# set ge-0/0/2 unit 0 family inet address 1.2.2.1/30 user@PCC# set ge-0/0/2 unit 0 family mpls user@PCC# set ge-0/0/3 unit 0 family inet address 1.2.5.1/30 user@PCC# set ge-0/0/3 unit 0 family mpls user@PCC# set ge-0/0/4 unit 0 family inet address 1.4.0.1/30 user@PCC# set ge-0/0/4 unit 0 family mpls user@PCC# set ge-0/0/5 unit 0 family inet address 1.2.1.1/30 user@PCC# set ge-0/0/5 unit 0 family mpls user@PCC# set ge-0/0/6 unit 0 family inet address 1.2.0.1/30 user@PCC# set ge-0/0/6 unit 0 family mpls
Configurez le numéro du système autonome pour le routeur PCC.
[edit routing-options] user@PCC# set autonomous-system 100
Activez RSVP sur toutes les interfaces du routeur PCC, à l’exception de l’interface de gestion.
[edit protocols] user@PCC# set rsvp interface all user@PCC# set rsvp interface fxp0.0 disable
Activez MPLS sur toutes les interfaces du routeur PCC, à l’exception de l’interface de gestion.
[edit protocols] user@PCC# set mpls interface all user@PCC# set mpls interface fxp0.0 disable
Configurez un LSP dynamique et désactivez le calcul automatique du chemin pour le LSP.
[edit protocols] user@PCC# set mpls label-switched-path lsp_template_no_cspf template user@PCC# set mpls label-switched-path lsp_template_no_cspf no-cspf
Configurez les LSP point à multipoint et définissez l’entité de calcul de chemin externe pour le LSP.
[edit protocols] user@PCC# set mpls label-switched-path lsp1-pcc to 128.102.177.16 user@PCC# set mpls label-switched-path lsp2-pcc to 128.102.177.16 user@PCC# set mpls label-switched-path lsp2-pcc lsp-external-controller pccd
Activez le calcul de chemin externe pour les LSP MPLS et attribuez un modèle pour les LSP provisionnés en externe.
[edit protocols] user@PCC# set mpls lsp-external-controller pccd pce-controlled-lsp pcc_delegated_no_cspf_* label-switched-path-template lsp_template_no_cspf user@PCC# set mpls lsp-external-controller pccd pce-controlled-lsp pce_initiated_no_ero_no_cspf_* label-switched-path-template lsp_template_no_cspf user@PCC# set mpls lsp-external-controller pccd pce-controlled-lsp pce_initiated_loose_ero_no_cspf_* label-switched-path-template lsp_template_no_cspf
Configurez les LSP qui disposent d’un contrôle local et qui sont remplacés par les paramètres LSP fournis par PCE.
[edit protocols] user@PCC# set mpls path loose-path 1.2.3.2 loose user@PCC# set mpls path strict-path 1.2.3.2 strict user@PCC# set mpls path strict-path 2.3.3.2 strict user@PCC# set mpls path path-B user@PCC# set mpls path path-C
Configurez des stratégies de groupe d’administration MPLS pour le calcul LSP à chemin contraint.
[edit protocols] user@PCC# set mpls admin-groups violet 1 user@PCC# set mpls admin-groups indigo 2 user@PCC# set mpls admin-groups blue 3 user@PCC# set mpls admin-groups green 4 user@PCC# set mpls admin-groups yellow 5 user@PCC# set mpls admin-groups orange 6
Attribuez les stratégies de groupe d’administration configurées aux interfaces PCC du routeur.
[edit protocols] user@PCC# set mpls interface ge-0/0/6.0 admin-group violet user@PCC# set mpls interface ge-0/0/5.0 admin-group indigo user@PCC# set mpls interface ge-0/0/2.0 admin-group blue user@PCC# set mpls interface ge-0/0/1.0 admin-group green user@PCC# set mpls interface ge-0/0/0.0 admin-group yellow user@PCC# set mpls interface ge-0/0/3.0 admin-group orange
Configurez une stratégie d’importation de base de données d’ingénierie du trafic (TED).
[edit protocols] user@PCC# set mpls traffic-engineering database import policy TE
Configurez un groupe interne BGP.
[edit protocols] user@PCC# set bgp group northstar type internal user@PCC# set bgp group northstar local-address 128.102.180.228 user@PCC# set bgp group northstar neighbor 128.102.180.215
Configurez l’ingénierie du trafic pour BGP et attribuez la stratégie d’exportation.
[edit protocols] user@PCC# set bgp group northstar family traffic-engineering unicast user@PCC# set bgp group northstar export TE
Configurez la zone OSPF 0 sur toutes les interfaces point à multipoint du routeur PCC.
[edit protocols] user@PCC# set ospf area 0.0.0.0 interface lo0.0 user@PCC# set ospf area 0.0.0.0 interface ge-0/0/6.0 user@PCC# set ospf area 0.0.0.0 interface ge-0/0/5.0 user@PCC# set ospf area 0.0.0.0 interface ge-0/0/2.0 user@PCC# set ospf area 0.0.0.0 interface ge-0/0/1.0 user@PCC# set ospf area 0.0.0.0 interface ge-0/0/0.0 user@PCC# set ospf area 0.0.0.0 interface ge-0/0/3.0
Configurez la zone OSPF 0 sur l’interface point à point du routeur PCC.
[edit protocols] user@PCC# set ospf area 0.0.0.0 interface ge-0/0/4.0 interface-type p2p
Activez l’ingénierie du trafic pour OSPF.
[edit protocols] user@PCC# set ospf traffic-engineering
Définissez le PCE auquel le routeur PCC se connecte, puis configurez les paramètres PCE.
[edit protocols] user@PCC# set pcep pce pce1 local-address 10.102.180.228 user@PCC# set pcep pce pce1 destination-ipv4-address 10.102.180.246 user@PCC# set pcep pce pce1 destination-port 4189 user@PCC# set pcep pce pce1 pce-type active user@PCC# set pcep pce pce1 pce-type stateful user@PCC# set pcep pce pce1 lsp-provisioning user@PCC# set pcep pce pce1 lsp-cleanup-timer 0 user@PCC# set pcep pce pce1 delegation-cleanup-timeout 60
Configurez le PCC du routeur pour activer la fonctionnalité LSP point à multipoint pour le calcul de chemin externe.
[edit protocols] set pcep pce pce1 p2mp-lsp-report-capability
Configurez la stratégie d’ingénierie du trafic.
[edit policy-options] user@PCC# set policy-statement TE term 1 from family traffic-engineering user@PCC# set policy-statement TE term 1 then accept
Résultats
À partir du mode de configuration, confirmez votre configuration en entrant les commandes show interfaces
et show protocols
. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
user@PCC# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 1.2.4.1/30;
}
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 1.2.3.1/30;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 1.2.2.1/30;
}
family mpls;
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 1.2.5.1/30;
}
family mpls;
}
}
ge-0/0/4 {
unit 0 {
family inet {
address 1.4.0.1/30;
}
family mpls;
}
}
ge-0/0/5 {
unit 0 {
family inet {
address 1.2.1.1/30;
}
family mpls;
}
}
ge-0/0/6 {
unit 0 {
family inet {
address 1.2.0.1/30;
}
family mpls;
}
}
user@PCC# show protocols
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
lsp-external-controller pccd {
pce-controlled-lsp pcc_delegated_no_cspf_* {
label-switched-path-template {
lsp_template_no_cspf;
}
}
pce-controlled-lsp pce_initiated_no_ero_no_cspf_* {
label-switched-path-template {
lsp_template_no_cspf;
}
}
pce-controlled-lsp pce_initiated_loose_ero_no_cspf_* {
label-switched-path-template {
lsp_template_no_cspf;
}
}
}
traffic-engineering {
database {
import {
policy TE;
}
}
}
admin-groups {
violet 1;
indigo 2;
blue 3;
green 4;
yellow 5;
orange 6;
}
label-switched-path lsp_template_no_cspf {
template;
no-cspf;
}
label-switched-path lsp1-pcc {
to 128.102.177.16;
}
label-switched-path lsp2-pcc {
to 128.102.177.16;
lsp-external-controller pccd;
}
path loose-path {
1.2.3.2 loose;
}
path strict-path {
1.2.3.2 strict;
2.3.3.2 strict;
}
path path-B;
path path-C;
interface all;
interface ge-0/0/6.0 {
admin-group violet;
}
interface ge-0/0/5.0 {
admin-group indigo;
}
interface ge-0/0/2.0 {
admin-group blue;
}
interface ge-0/0/1.0 {
admin-group green;
}
interface ge-0/0/0.0 {
admin-group yellow;
}
interface ge-0/0/3.0 {
admin-group orange;
}
interface fxp0.0 {
disable;
}
}
bgp {
group northstar {
type internal;
local-address 128.102.180.228;
family traffic-engineering {
unicast;
}
export TE;
neighbor 128.102.180.215;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0;
interface ge-0/0/6.0;
interface ge-0/0/5.0;
interface ge-0/0/2.0;
interface ge-0/0/1.0;
interface ge-0/0/0.0;
interface ge-0/0/3.0;
interface ge-0/0/4.0 {
interface-type p2p;
}
}
}
pcep {
pce pce1 {
local-address 10.102.180.228;
destination-ipv4-address 10.102.180.246;
destination-port 4189;
pce-type active stateful;
lsp-provisioning;
lsp-cleanup-timer 0;
delegation-cleanup-timeout 60;
p2mp-lsp-report-capability;
}
}
Vérification
Vérifiez que la configuration fonctionne correctement.
Vérification de la configuration LSP sur le PCC
But
Vérifiez le type de LSP et l’état d’exécution du LSP point à multipoint.
Action
À partir du mode opérationnel, exécutez la show mpls lsp extensive
commande.
user@PCC> show mpls lsp extensive Ingress LSP: 2 sessions 128.102.177.16 From: 128.102.180.228, State: Up, ActiveRoute: 0, LSPname: lsp1-pcc ActivePath: (primary) LSPtype: Static Configured, Penultimate hop popping LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 2) 1.2.1.2 S 2.3.0.2 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 1.2.1.2 2.3.0.2 6 Jul 12 14:44:10.620 Selected as active path 5 Jul 12 14:44:10.617 Record Route: 1.2.1.2 2.3.0.2 4 Jul 12 14:44:10.615 Up 3 Jul 12 14:44:10.175 Originate Call 2 Jul 12 14:44:10.174 CSPF: computation result accepted 1.2.1.2 2.3.0.2 1 Jul 12 14:43:41.442 CSPF failed: no route toward 128.102.177.16[2 times] Created: Tue Jul 12 14:42:43 2016 128.102.177.16 From: 128.102.180.228, State: Up, ActiveRoute: 0, LSPname: lsp2-pcc ActivePath: (primary) LSPtype: Externally controlled - static configured, Penultimate hop popping LSP Control Status: Externally controlled LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary State: Up Priorities: 7 0 External Path CSPF Status: external SmartOptimizeTimer: 180 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 1.2.4.2 2.3.0.2 50 Jul 12 14:50:14.699 EXTCTRL LSP: Sent Path computation request and LSP status 49 Jul 12 14:50:14.698 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 48 Jul 12 14:49:27.859 EXTCTRL LSP: Sent Path computation request and LSP status 47 Jul 12 14:49:27.859 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 46 Jul 12 14:49:27.858 EXTCTRL LSP: Sent Path computation request and LSP status 45 Jul 12 14:49:27.858 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 44 Jul 12 14:49:27.858 EXTCTRL_LSP: Control status became external 43 Jul 12 14:49:03.746 EXTCTRL_LSP: Control status became local 42 Jul 12 14:46:52.367 EXTCTRL LSP: Sent Path computation request and LSP status 41 Jul 12 14:46:52.367 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 40 Jul 12 14:46:52.367 EXTCTRL LSP: Sent Path computation request and LSP status 39 Jul 12 14:46:52.366 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 38 Jul 12 14:46:52.366 EXTCTRL_LSP: Control status became external 37 Jul 12 14:46:41.584 Selected as active path 36 Jul 12 14:46:41.565 Record Route: 1.2.4.2 2.3.0.2 35 Jul 12 14:46:41.565 Up 34 Jul 12 14:46:41.374 EXTCTRL_LSP: Applying local parameters with this signalling attempt 33 Jul 12 14:46:41.374 Originate Call 32 Jul 12 14:46:41.374 CSPF: computation result accepted 1.2.4.2 2.3.0.2 31 Jul 12 14:46:28.254 EXTCTRL_LSP: Control status became local 30 Jul 12 14:46:12.494 EXTCTRL LSP: Sent Path computation request and LSP status 29 Jul 12 14:46:12.494 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 28 Jul 12 14:45:43.164 EXTCTRL LSP: Sent Path computation request and LSP status 27 Jul 12 14:45:43.164 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 26 Jul 12 14:45:13.424 EXTCTRL LSP: Sent Path computation request and LSP status 25 Jul 12 14:45:13.423 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 24 Jul 12 14:44:44.774 EXTCTRL LSP: Sent Path computation request and LSP status 23 Jul 12 14:44:44.773 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 22 Jul 12 14:44:15.053 EXTCTRL LSP: Sent Path computation request and LSP status 21 Jul 12 14:44:15.053 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 20 Jul 12 14:43:45.705 EXTCTRL LSP: Sent Path computation request and LSP status 19 Jul 12 14:43:45.705 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 18 Jul 12 14:43:45.705 EXTCTRL LSP: Sent Path computation request and LSP status 17 Jul 12 14:43:45.705 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 16 Jul 12 14:43:45.705 EXTCTRL_LSP: Control status became external 15 Jul 12 14:43:42.398 CSPF failed: no route toward 128.102.177.16 14 Jul 12 14:43:13.009 EXTCTRL_LSP: Control status became local 13 Jul 12 14:43:13.009 EXTCTRL LSP: Sent Path computation request and LSP status 12 Jul 12 14:43:13.008 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 11 Jul 12 14:42:43.343 EXTCTRL LSP: Sent Path computation request and LSP status 10 Jul 12 14:42:43.343 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 9 Jul 12 14:42:43.343 EXTCTRL LSP: Sent Path computation request and LSP status 8 Jul 12 14:42:43.343 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 7 Jul 12 14:42:43.342 EXTCTRL LSP: Sent Path computation request and LSP status 6 Jul 12 14:42:43.342 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 5 Jul 12 14:42:43.341 EXTCTRL_LSP: Control status became external 4 Jul 12 14:42:43.337 EXTCTRL_LSP: Control status became local 3 Jul 12 14:42:43.323 EXTCTRL LSP: Sent Path computation request and LSP status 2 Jul 12 14:42:43.323 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0 1 Jul 12 14:42:43.258 EXTCTRL LSP: Awaiting external controller connection Created: Tue Jul 12 14:42:43 2016 Total 2 displayed, Up 2, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
Sens
La sortie affiche le LSP lsp2-pcc en tant que LSP contrôlé par PCE.
Vérification de la configuration PCE sur le PCC
But
Vérifiez la configuration des paramètres PCE et l’état PCE.
Action
À partir du mode opérationnel, exécutez la show path-computation-client active-pce
commande.
user@PCC> show path-computation-client active-pce PCE pce1 -------------------------------------------- General PCE IP address : 10.102.180.246 Local IP address : 10.102.180.228 Priority : 0 PCE status : PCE_STATE_UP Session type : PCE_TYPE_STATEFULACTIVE LSP provisioning allowed : On P2MP LSP report allowed : On P2MP LSP update allowed : Off P2MP LSP init allowed : Off PCE-mastership : main Counters PCReqs Total: 0 last 5min: 0 last hour: 0 PCReps Total: 0 last 5min: 0 last hour: 0 PCRpts Total: 12 last 5min: 0 last hour: 12 PCUpdates Total: 1 last 5min: 0 last hour: 1 PCCreates Total: 0 last 5min: 0 last hour: 0 Timers Local Keepalive timer: 30 [s] Dead timer: 120 [s] LSP cleanup timer: 0 [s] Remote Keepalive timer: 30 [s] Dead timer: 120 [s] LSP cleanup timer: 0 [s] Errors PCErr-recv PCErr-sent Type: 1 Value: 2 Count: 1 PCE-PCC-NTFS PCC-PCE-NTFS
Sens
La sortie affiche le PCE actif auquel le routeur PCC est connecté, ainsi que les paramètres et l’état du PCE pce1.
Comprendre le protocole d’élément de calcul de chemin pour MPLS RSVP-TE avec prise en charge des LSP point-à-multipoint initiés par PCE
Avec l’introduction des LSP point à multipoint initiés par PCE, un PCE peut initier et provisionner un LSP point à multipoint de manière dynamique sans avoir besoin d’une configuration LSP locale sur le PCC. Cela permet au PCE de contrôler le timing et la séquence des calculs de chemin point à multipoint au sein et entre les sessions PCEP (Path Computation Element Protocol), créant ainsi un réseau dynamique contrôlé et déployé de manière centralisée.
- Avantages des LSP point-à-multipoint initiés par PCE
- Signalisation des LSP point à multipoint initiés par PCE
- Comportement des LSP point-à-multipoint initiés par PCE après l’échec d’une session PCEP
- Configuration de la fonctionnalité LSP point-à-multipoint initiée par PCE
- Fonctionnalités prises en charge et non prises en charge pour les LSP point-à-multipoint initiés par PCE
- Mappage des LSP point-à-multipoint initiés par PCE sur MVPN
Avantages des LSP point-à-multipoint initiés par PCE
Répond aux exigences du placement de LSP d’ingénierie du trafic point à multipoint en réponse aux demandes des applications grâce à la création et au démontage dynamiques de LSP point à multipoint, créant ainsi un réseau dynamique contrôlé et déployé de manière centralisée.
Signalisation des LSP point à multipoint initiés par PCE
La signalisation des LSP point à multipoint initiés par PCE est la suivante :
-
When a new branch is added (Grafting)—Seul le nouveau sous-LSP de branche est signalé et n’entraîne pas de resignalisation de l’ensemble de l’arborescence point-multipoint.
Si des modifications de topologie se sont produites avant le provisionnement du nouveau sous-LSP, le serveur de calcul de chemin (PCS) recalcule l’arborescence point à multipoint entière et met à jour le LSP point à multipoint à l’aide d’un message de mise à jour PC.
-
When a branch is deleted (Pruning)—Le sous-LSP de branche supprimé est détruit et n’entraîne pas de resignalisation de l’ensemble de l’arborescence point-multipoint.
-
When a branch sub-LSP parameter is changed: la modification des paramètres sous-LSP, tels que l’objet de route explicite (ERO), la bande passante ou la priorité, peut se produire soit en raison de l’optimisation, soit à la demande de l’utilisateur. S’il y a une demande de re-signalisation pour un sous-LSP, l’ensemble de l’arborescence point-multipoint est re-signalé, puis le basculement vers la nouvelle instance se produit une fois que les nouvelles instances de toutes les branches sont actives.
-
When a branch sub-LSP path fails: une erreur est signalée au PCS pour le sous-LSP de branche défaillant. À la réception du nouvel ERO du PCS, l’ensemble de l’arborescence point-multipoint est re-signalé avec le sous-LSP de branche défaillant, et le basculement vers la nouvelle instance se fait selon un mode MBB (make-before-break).
Comportement des LSP point-à-multipoint initiés par PCE après l’échec d’une session PCEP
Lorsqu’une session PCEP échoue, les LSP point à multipoint initiés par PCE sont orphelins jusqu’à l’expiration state timeout
du minuteur. Une fois le state timeout
minuteur expiré, les LSP initiés par PCE sont nettoyés.
Pour prendre le contrôle d’un LSP point à multipoint initié par PCE après l’échec d’une session PCEP, le PCE principal ou secondaire envoie un message avant l’expiration PCInitiate
du state timeout
minuteur.
Configuration de la fonctionnalité LSP point-à-multipoint initiée par PCE
Par défaut, la création et le provisionnement de LSP point à multipoint par un PCE ne sont pas pris en charge sur un PCC. Pour activer cette fonctionnalité, incluez les p2mp-lsp-init-capability
instructions et p2mp-lsp-update-capability
au niveau de la [edit protocols pcep pce pce-name]
hiérarchie ou [edit protocols pcep pce-group group-id]
.
L’instruction p2mp-lsp-init-capability
permet de provisionner des LSP RSVP-TE point à multipoint par un PCE. L’instruction p2mp-lsp-update-capability
permet de mettre à jour les paramètres RSVP-TE LSP point à multipoint par un PCE.
Fonctionnalités prises en charge et non prises en charge pour les LSP point-à-multipoint initiés par PCE
Les fonctionnalités suivantes sont prises en charge avec les LSP point à multipoint initiés par PCE :
-
Conformité partielle avec le projet Internet draft-ietf-pce-stateful-pce-p2mp (expire en octobre 2018), Path Calculation Element (PCE) Protocol Extensions for Stateful PCE Use for Point-to-Multipoint Traffic Engineering Label Switched Paths.
- À partir de Junos OS version 21.1R1, nous prenons en charge le routage actif non-stop (NSR) pour les LSP point à multipoint basés sur RSVP initiés par PCE. Seul le moteur de routage principal gère la session PCEP avec le contrôleur. Il synchronise tous les LSP RSVP initiés par les PCE, y compris les spécifications de flux multicast pour tous les LSP P2MP initiés par PCE, avec le moteur de routage de secours. Lors d’un basculement, la session PCEP tombe en panne et se rétablit lorsque le moteur de routage de secours devient le moteur de routage principal. Cela réduit la perte de trafic pour le trafic transporté sur les LSP RSVP initiés par PCE pendant les basculements du moteur de routage. Cette fonctionnalité est activée lorsque NSR est configuré.
Les fonctionnalités suivantes ne sont pas prises en charge avec les LSP point à multipoint initiés par PCE :
-
Délégation d’un LSP point à multipoint contrôlé localement.
-
Délégation de contrôle LSP.
-
Extension IGP (Interior Gateway Protocol) pour la découverte PCE au sein d’un domaine de routage IGP.
-
Messages de demande/réponse.
-
Déplacement direct du sous-LSP de branche d’un arbre point à multipoint à un autre.
La même chose peut être obtenue en supprimant un sous-LSP de branche de la première arborescence point-multipoint et en l’ajoutant à nouveau à une autre après que le
PCReport
message indique la suppression de LSP de l’appareil. -
IPv6 n’est pas pris en charge.
-
La signalisation SERO n’est pas prise en charge.
-
La fonction Empty-ERO n’est pas prise en charge.
-
La protection des liens n’est pas prise en charge.
Mappage des LSP point-à-multipoint initiés par PCE sur MVPN
Vous pouvez associer un ou plusieurs flux de multidiffusion MVPN (S,G) à un chemin de commutation d’étiquettes (LSP) point à multipoint initié par PCE créé dynamiquement. Vous ne pouvez spécifier que des types de flux sélectifs pour que cette fonctionnalité fonctionne. Cela inclut :
-
RD (Route Distinguisher) qui est mappé à l’instance de routage MVPN.
-
(S,G) qui est la source d’un paquet multicast et l’adresse du groupe multicast de destination. Il permet de filtrer le trafic entrant pour le mapper au tunnel.
-
LSP point à multipoint utilisé pour envoyer du trafic correspondant à la spécification de flux mentionnée ci-dessus.
Pour plus d’informations, consultez Internet draft -ietf-pce-pcep-flowspec-05 (expire le 16 février 2020) Extension PCEP pour la spécification de flux.
L’implémentation actuelle de cette fonctionnalité n’implémente pas les sections suivantes du projet :
-
Section 3.1.2 — Annonce des capacités PCE dans IGP
-
Section 3.2 — Message PCReq et PCRep
-
Section 7 — La plupart des spécifications de flux, à l’exception de la distinction de routeL’implémentation actuelle de cette fonctionnalité ne prend pas en charge les spécifications de flux de multidiffusion IPv4, ne sont pas prises en charge.
Pour activer le mappage des LSP point à multipoint initiés par PCE vers MVPN :
-
Incluez l’instruction
pce_traffic_steering
au niveau de la hiérarchie pour indiquer la prise en charge de la capacité de spécification de[edit protocols pcep pce pce-id]
flux (également appelée orientation du trafic) par le PCC. -
Incluez l’instruction
external-controller
au niveau de la[edit routing-instances routing-instance-name provider-tunnel]
hiérarchie.La présence de
external-controller
dans la configuration du tunnel fournisseur pour MVPN indique que le LSP point à multipoint et (S,G) pour cette instance MVPN peuvent être fournis par le contrôleur externe. Cela permet au contrôleur externe de configurer dynamiquement (S, G) et le LSP point à multipoint pour MVPN.
Pour mapper des LSP point à multipoint initiés par PCE vers MVPN, tenez compte des éléments suivants :
-
Si vous n’activez pas l’instruction
external-controller pccd
pour une instance MVPN particulière, le processus PCCD ne se configure pas dynamiquement (S,G). -
Si vous désactivez la
external-controller pccd
configuration à partir de l’interface de ligne de commande, les flux de multidiffusion appris dynamiquement (S,G) pour cette instance MVPN particulière sont supprimés et signalés au contrôleur externe. -
Lorsque (S,G) est déjà configuré à partir de l’interface de ligne de commande, le PCC ne peut pas configurer (S,G) dynamiquement car la configuration locale a une priorité plus élevée.
-
Si un particulier (S,G) est appris dynamiquement à partir du contrôleur externe et que vous configurez ensuite le même (S,G) pour la même instance MVPN, alors l’apprentissage dynamique (S,G) est supprimé et signalé au contrôleur externe via le PCC.
-
Si le processus du protocole de routage redémarre, le processus PCCD reconfigure à nouveau tous les (S,G).
-
Si le processus PCCD redémarre, MVPN signale tous les PCCD configurés (S,G) au contrôleur externe.
-
Si l’utilisateur l’active
external-controller pccd
pour une instance MVPN particulière, MVPN demande au processus PCCD de configurer (S,G), le cas échéant. -
S’il y a des changements de configuration majeurs sur une instance MPVN particulière, MVPN demande au processus PCCD de tout reconfigurer (S,G) pour cette instance MVPN particulière.
-
Toutes les spécifications de flux associées à un LSP point à multipoint initié par PCE doivent avoir le même RD. Lors de l’initialisation du PC, si toutes les spécifications de flux n’ont pas le même RD, le message d’initialisation du PC est supprimé avec une erreur.
-
Vous ne pouvez associer un LSP point à multipoint qu’à des spécifications de type de flux sélectif, sinon le message d’initialisation du PC est supprimé avec une erreur.
-
Lors de la mise à jour du PC, si toutes les spécifications de flux n’ont pas le même RD, soit en raison d’un ajout d’une nouvelle spécification de flux, soit en raison d’une mise à jour de spécification de flux existante, le PCC abandonne le message de mise à jour.
-
Lors de la mise à jour du PC, si toutes les spécifications de flux ne répondent pas à la condition sélective, soit en raison de l’ajout d’une nouvelle spécification de flux, soit en raison d’une mise à jour des spécifications de flux existantes, le PCC abandonne le message de mise à jour.
-
Le comportement du mappage du LSP point à multipoint initié par PCE avec l’instance de routage MVPN et du mappage du LSP point à multipoint statique (configuré localement) avec l’instance MVPN est le même au niveau de l’utilisateur.
-
Un ID de spécification de flux ne peut être associé qu’à un seul LSP point à multipoint. Pour associer le même RD et (S,G) à plusieurs LSP point à multipoint, vous pouvez ajouter plusieurs spécifications de flux avec des ID différents et les mêmes RD & (S,G).
-
Pour les dynamiques mappées PCEP (S,G), la valeur seuil est toujours la valeur par défaut de 0.
-
Il n’y a pas de limite au nombre de spécifications de flux mappées à un seul LSP point à multipoint initié par PCE.
-
L’implémentation actuelle de cette fonctionnalité ne prend pas en charge :
-
Création de rapports sur les états de transfert associés au LSP point à multipoint.
-
Configuration dynamique de tunnel fournisseur incluse
-
Mappage pour le tunnel de réplication d’entrée MVPN
-
Processus de protocole de routage programmable (prpd)
-
Création de rapports sur le LSP point à multipoint configuré par l’interface de ligne de commande, qui est mappé aux flux multicast MVPN (S,G).
-
Voir également
Activer Segment Routing pour le protocole Path Computation Element
SUMMARY Vous pouvez activer le routage de segments ou l’ingénierie du trafic SPRING (Source Packet Routing in Networking) (SR-TE) avec le protocole PCEP (Path Computation Element Protocol) pour le pilotage du trafic. Grâce à cette prise en charge, les avantages du routage de segments sont étendus aux chemins de commutation d’étiquettes (LSP) qui sont contrôlés en externe par un élément de calcul de chemin (PCE).
- Présentation du protocole de routage de segments pour l’élément de calcul de chemin
- Exemple : Configurer Segment Routing pour le protocole Path Computation Element
Présentation du protocole de routage de segments pour l’élément de calcul de chemin
- Avantages de Segment Routing pour le PCEP
- Segment Routing pour les aspects techniques du trafic
- Implémentation Junos OS du Segment Routing pour PCEP
- Segment Routing pour les limitations du PCEP et les fonctionnalités non prises en charge
Avantages de Segment Routing pour le PCEP
La configuration des LSP par le biais d’un contrôleur externe fournit une vue globale de la demande de bande passante par LSP et par appareil sur le réseau, ce qui permet de calculer les chemins en ligne et en temps réel en fonction des contraintes.
Les avantages du routage de segments s’étendent aux LSP initiés par un contrôleur externe, également connu sous le nom d’élément de calcul de chemin (PCE), ce qui augmente les avantages du calcul de chemin externe dans un réseau MPLS.
Un client de calcul de chemin (PCC, qui est un routeur MX Series entrant) doté d’une capacité de délégation peut reprendre le contrôle des LSP de routage de segment délégués du PCE lorsque la session PCEP tombe en panne ; dans le cas contraire, les prestataires de services linguistiques seraient supprimés du CCP. Vous pouvez ainsi assurer la protection des données LSP en évitant une situation où des paquets sont silencieusement rejetés ou abandonnés (également connu sous le nom de condition de route nulle).
Segment Routing pour les aspects techniques du trafic
Le routage de segments peut fonctionner sur un plan de données IPv4 ou IPv6 et prend en charge le multichemin à coût égal (ECMP). Grâce aux extensions IGP qui lui sont intégrées, le routage de segments s’intègre aux riches fonctionnalités multiservices de MPLS, notamment le VPN de couche 3, le VPWS (Virtual Private Wire Service), le VPLS (Virtual Private LAN Service) et l’EVPN (Ethernet VPN).
Voici quelques-uns des principaux composants de la solution SR-TE (Segment Routing–Traffic Engineering) :
Utilisation d’un IGP pour les caractéristiques des liens publicitaires. Cette fonctionnalité est similaire à RSVP-TE.
Utilisation du protocole CSPF (Constrained Shortest Path First) sur le périphérique d’entrée ou le PCE.
Utilisation d’un IGP pour les étiquettes publicitaires pour les liens.
Dans le cadre de la fonctionnalité SR-TE :
L’équipement d’entrée construit un LSP en empilant les étiquettes des liens qu’il souhaite traverser.
La publication IGP par liaison est combinée à l’empilement d’étiquettes pour créer des LSP acheminés à la source sur l’appareil entrant, de sorte que les appareils de transit ne connaissent pas les LSP de bout en bout.
Les LSP sont créés entre les nuds périphériques sans imposer d’exigences de mémoire par LSP aux périphériques de transit. (La création de tels LSP est activée car il n’y a pas de signalisation par LSP dans SR-TE.)
Les étiquettes par voisin sont empilées, ce qui entraîne la gestion d’un grand nombre d’étiquettes, conduisant à la mise à l’échelle du plan de contrôle.
Implémentation Junos OS du Segment Routing pour PCEP
Junos OS implémente le routage de segments pour PCEP pour deux types de LSP : les LSP initiés par PCE et les LSP délégués PCE.
LSP Segment Routing initiés par l’ECP
Les LSP de routage de segments initiés par PCE sont les LSP créés par le PCE pour les segments d’adjacence et de nœud
Le PCE remplit les fonctions suivantes :
Calcule le chemin du LSP de routage de segments.
Provisionne le LSP sur le client de calcul de chemin (PCC) à l’aide des extensions de routage de segments PCEP.
Analyse les extensions de routage de segments PCEP.
Crée une route de tunnel sur le PCC qui a sa propre valeur de préférence et est mise à disposition dans la table de routage inet.3 pour résoudre le trafic IP et les services comme n’importe quel autre route de tunnel.
Le PCC remplit les fonctions suivantes :
Sélectionne l’interface sortante en fonction du premier identifiant d’accès réseau (NAI) dans l’objet de route explicite (S-ERO) source.
Junos OS prend en charge les S-ERO qui contiennent le premier saut en tant que saut strict ; Junos OS ne prend pas en charge la sélection de l’interface sortante sur le PCC en fonction d’un ID de segment de nœud (SID) à saut lâche. Cependant, le houblon restant peut être lâche. Aucun traitement spécifique n’est effectué pour les S-ERO qui se trouvent au-delà du premier saut, si ce n’est d’utiliser simplement l’étiquette pour la création du saut suivant.
Rejette le S-ERO si :
Le S-ERO n’a pas d’étiquettes.
Le S-ERO transporte plus de six houblons.
Le PCC crée une route ECMP (Equal-cost multi-path) lorsqu’il existe plusieurs LSP vers la même destination avec la même métrique.
Attend que le PCE traite tout événement qui entraîne une modification du LSP de routage de segments après son provisionnement, par exemple, si l’étiquette est modifiée ou retirée, ou si l’une des interfaces traversées par le LSP tombe en panne.
Lorsque la session PCEP tombe en panne, le LSP de routage de segments initié par PCE :
Reste en place pendant 300 secondes.
Est supprimé du PCC au bout de 300 secondes.
Pour plus d’informations, consultez Brouillons Internet draft-ietf-pce-lsp-setup-type-03.txt (expire le 25 décembre 2015), Type de configuration de chemin de transmission dans les messages PCEP ; et draft-ietf-pce-segment-routing-06.txt (expire le 10 février 2016), les prolongations du PCEP pour Segment Routing.
LSP Segment Routing délégués PCE
Les LSP de routage de segments délégués PCE sont les LSP que le PCC configure localement et délègue ensuite à un contrôleur PCE.
Junos OS version 20.1R1 prend en charge :
Capacité de délégation PCE uniquement pour les LSP de routage de segments non colorés avec des destinations IPv4.
Délégation et reporting du premier segment d’une liste de segments à un contrôleur externe. Les segments multiples ne sont pas pris en charge pour la délégation PCE.
Le PCC peut déléguer un LSP de routage de segments à un contrôleur externe (le PCE) de la manière suivante :
Initial delegation—Les LSP locaux n’ont pas encore été configurés sur le PCC, et la délégation du LSP a lieu au moment où le LSP est configuré.
Delegation of existing LSP: les LSP locaux sont configurés sur le PCC et la délégation du LSP s’effectue après la configuration du chemin de routage source. En d’autres termes, la fonctionnalité de délégation est activée sur les LSP de routage de segments existants.
Après avoir délégué un LSP de routage de segments, le PCE contrôle les LSP délégués et peut modifier les attributs LSP pour le calcul du chemin. Le contrôle LSP revient au PCC lorsque la session PCEP entre le PCC et le PCE est interrompue. Les LSP délégués PCE ont un avantage sur les LSP initiés par PCE en cas d’interruption de la session PCEP. Dans le cas des LSP initiés par PCE, lorsque la session PCEP est inactive, les LSP sont supprimés du PCC. Toutefois, dans le cas des prestataires de services linguistiques délégués par PCE, lorsque la session PCEP est interrompue, le PCC reprend le contrôle des prestataires de services linguistiques délégués du PCE. Par conséquent, avec les LSP délégués par PCE, nous évitons une situation où les paquets sont ignorés silencieusement (également appelée condition de routage null) lorsque la session tombe en panne.
Les types suivants de LSP de routage de segments prennent en charge la capacité de délégation PCE :
Static LSPs: chemins d’acheminement source configurés de manière statique sur lesquels l’ensemble de la pile d’étiquettes est configuré de manière statique.
Auto-translated LSPs: chemins de routage source configurés statiquement qui sont automatiquement traduits.
Computed LSPs: chemins de routage source configurés statiquement qui sont calculés avec CSPF (Constrained Shortest Path First) distribué.
Dynamic LSPs: tunnels créés dynamiquement et déclenchés par le module de tunnel dynamique avec une résolution ERO de dernier saut.
En fonction de la source du LSP de routage de segment, vous pouvez configurer la capacité de délégation sur le PCC. Pour permettre la délégation des LSP de routage de segments, incluez l’instruction lsp-external-controller pccd
au niveau approprié sous la [edit protocols source-packet-routing]
hiérarchie.
Tableau 2 affiche un mappage de la source LSP au niveau hiérarchique de configuration correspondant auquel la fonctionnalité de délégation est activée.
Vous devez inclure l’instruction lsp-external-controller pccd
aux niveaux et [edit protocols source-packet-routing]
[edit protocols mpls]
hiérarchique avant de configurer la capacité de délégation sur le PCC.
Source du LSP de Segment Routing |
Hiérarchie de configuration |
---|---|
|
Liste des segments primaires à l’adresse |
LSP calculés (CSPF distribués) |
Liste des segments primaires du chemin de routage source à l’adresse suivante :
|
LSP dynamiques |
Liste des segments primaires du modèle de chemin de routage source à l’adresse suivante :
|
Vous pouvez afficher l’état de contrôle des LSP SR-TE à partir de la sortie de la commande show spring-traffic-engineering .
Tableau 3 affiche l’interaction PCEP lorsque l’instruction lsp-external-controller
est configurée pour un chemin de routage source.
Hiérarchie de configuration lsp-external-controller |
état de délégation du chemin de routage source |
Interaction PCEP entre PCC et PCE |
---|---|---|
Liste des segments primaires du chemin de routage source |
Délégation initiale |
Le même comportement se produit lorsque le processus de protocole de routage (rpd) redémarre ou qu’un basculement du moteur de routage se produit. |
Liste des segments primaires du chemin de routage source |
Délégation d’un chemin existant |
|
Segment principal du chemin de routage source |
La délégation n’est pas configurée ou a été supprimée. |
La liste des segments du PCE (si disponible) n’est plus utilisée et le résultat du calcul de la configuration locale est utilisé. Lorsque le résultat local de la liste de segments est disponible, la liste de segments correspondante est utilisée pour programmer l’itinéraire de manière à faire avant de rompre. |
Liste des segments du chemin de routage source |
La délégation est activée après la configuration du LSP. |
La fonctionnalité de délégation est déclenchée pour la liste de segments primaire sous le chemin de routage source. |
Liste des segments du chemin de routage source |
La délégation n’est pas configurée ou a été supprimée. |
La fonctionnalité de délégation est supprimée de la liste des segments principaux sous le chemin de routage source. |
Liste des segments primaires du modèle de chemin de routage source |
La délégation est activée après la configuration du LSP. |
|
Liste des segments primaires du modèle de chemin de routage source |
La délégation n’est pas configurée ou a été supprimée. |
La fonctionnalité de délégation est supprimée de tous les chemins de routage source et principaux qui correspondent à la configuration du modèle. |
Segment Routing pour les limitations du PCEP et les fonctionnalités non prises en charge
La prise en charge du routage de segments pour PCEP n’alourdit pas la charge de performances du système. Cependant, il présente les limitations suivantes :
Un LSP SR-TE n’est pas protégé localement sur le PCC. Lorsque le LSP comporte plus de six sauts, aucun service n’est fourni sur le LSP, si ce n’est l’acheminement du trafic IP simple.
GRES (Graceful moteur de routage Switchover) et ISSU unifié (Mise à niveau logicielle en service unifié) ne sont pas pris en charge.
Le NSR (NonStop active Routing) n’est pas pris en charge.
IPv6 n’est pas pris en charge.
Les prestataires de services linguistiques délégués PCE ne prennent pas en charge les éléments suivants :
LSP SR-TE colorés
LSP IPv6
Liste des segments secondaires du chemin de routage source. Un seul chemin de la liste de segments peut être délégué.
Norme multi-segments. Seul le premier segment de la liste de segments est délégué et signalé au contrôleur.
Exemple : Configurer Segment Routing pour le protocole Path Computation Element
Cet exemple montre comment configurer le routage de segments ou l’ingénierie du trafic SPRING (Source Packet Routing in Networking) (SR-TE) pour le protocole PCEP (Path Computation Element Protocol). Pour la configuration, nous combinons les avantages du routage de segments avec les avantages du calcul de chemin externe pour une ingénierie de trafic efficace.
Conditions préalables
Cet exemple utilise les composants matériels et logiciels suivants :
Quatre plates-formes de routage universelles 5G MX Series, où le routeur MX Series entrant est le client de calcul de chemin (PCC).
Une connexion TCP entre le PCC et un élément de calcul de chemin (PCE) dynamique externe.
Junos OS version 17.2 ou ultérieure s’exécutant sur le PCC pour l’implémentation de LSP initiés par PCE.
Pour la fonctionnalité de délégation PCE, vous devez exécuter Junos OS version 20.1R1 ou ultérieure.
Avant de commencer :
Configurez les interfaces de l’appareil.
Configurez MPLS.
Configurez IS-IS.
Présentation
L’implémentation Junos OS du routage de segments pour PCEP inclut les LSP RS-TE initiés et délégués par PCE.
L’implémentation des LSP initiés par PCE est introduite dans Junos OS version 17.2R1, où les capacités d’ingénierie du trafic du routage de segments sont prises en charge dans les sessions PCEP pour les LSP initiés par un PCE. Le PCE crée les LSP pour les segments d’adjacence et de nœud. Les routes de tunnel sont créées dans la table de routage inet.3 du PCC correspondant aux LSP SR-TE initiés par PCE.
L’implémentation des LSP délégués PCE est introduite dans Junos OS version 20.1R1, où les LSP de routage de segments non colorés IPv4 configurés localement sur le PCC peuvent être délégués à un contrôleur PCE. Le PCE contrôle ensuite le LSP et peut modifier les attributs LSP pour le calcul des chemins.
Les prestataires de services linguistiques délégués par PCE ont un avantage sur les prestataires de services linguistiques initiés par le PCE au moment où la session PCEP est interrompue. Dans le cas des LSP initiés par PCE, lorsque la session PCEP est inactive, les LSP sont supprimés du PCC. Toutefois, dans le cas des prestataires de services linguistiques délégués par PCE, lorsque la session PCEP est interrompue, le PCC reprend le contrôle des prestataires de services linguistiques délégués du PCE. Par conséquent, avec les LSP délégués par PCE, nous évitons une situation où les paquets sont ignorés silencieusement (également connu sous le nom de condition de routage null) lorsque la session PCEP tombe en panne.
Pour activer le routage de segments pour PCEP :
Pour les LSP de routage de segments initiés par PCE :
Activez le calcul de chemin externe pour MPLS en incluant l’instruction
lsp-external-controller
au niveau de la[edit protocols mpls]
hiérarchie.Cette configuration est également requise pour PCEP avec extensions RSVP-TE. Vous ne pouvez pas désactiver PCEP avec RSVP-TE lorsque le routage de segments pour PCEP est activé.
Activez le calcul de chemin externe pour SR-TE en incluant l’instruction
lsp-external-controller pccd
au niveau de la[edit protocols spring-traffic-engineering]
hiérarchie.Activez le routage de segments pour le PCE en incluant l’instruction
spring-capability
au niveau de la[edit protocols pcep pce pce-name]
hiérarchie.Vous pouvez également configurer la profondeur SID maximale pour le PCE en incluant l’instruction
max-sid-depth number
au niveau de la[edit protocols pcep pce pce-name]
hiérarchie.La profondeur SID maximale est le nombre de SID pris en charge par un noeud ou un lien sur un noeud. Lorsqu’elle n’est pas configurée, une valeur SID maximale par défaut de 5 est appliquée.
Vous pouvez également configurer la valeur de préférence pour le routage de segments en incluant le
preference preference-value
au niveau de la[edit protocol spring-te]
hiérarchie.La valeur de préférence indique l’ordre dans lequel un chemin est sélectionné comme forme de chemin active parmi les chemins candidats, où une valeur plus élevée a une préférence plus élevée. Lorsqu’elle n’est pas configurée, une valeur de préférence par défaut de 8 est appliquée.
Vous pouvez également configurer la journalisation du routage de segments à des fins de dépannage en incluant l’instruction
traceoptions
au niveau de la[edit protocols spring-te]
hiérarchie.
Pour la délégation PCE de LSP de routage de segments, en plus des étapes susmentionnées, procédez comme suit :
Définissez une liste de segments avec des paramètres d’étiquette. Cela crée un LSP de routage de segments localement sur le PCC.
Activez la capacité de délégation du LSP configuré localement sur le PCC en incluant l’instruction
lsp-external-controller pccd
à l’une des hiérarchies suivantes, en fonction de la source LSP de routage de segments :Pour les chemins de routage source configurés statiquement qui sont calculés avec des niveaux CSPF
[edit protocols source-packet-routing source-routing-path lsp-name primary path-name compute profile-name]
distribués et[edit protocols source-packet-routing source-routing-path lsp-name primary path-name]
hiérarchiques.Pour les chemins de routage source configurés statiquement qui ont l’ensemble de la pile d’étiquettes configurés de manière statique et les chemins de routage source qui sont automatiquement traduits,
[edit protocols source-packet-routing source-routing-path lsp-name primary path-name]
au niveau de la hiérarchie.Pour les tunnels créés dynamiquement et déclenchés par le module de tunnel dynamique qui ont une résolution
[edit protocols source-packet-routing source-routing-path-template template-name primary primary-segment-list-name]
ERO de dernier saut et[edit protocols source-packet-routing source-routing-path-template template-name]
des niveaux hiérarchiques.
Topologie
Figure 8 illustre un exemple de topologie de réseau dans laquelle une session PCEP s’exécute entre le PCE et le PCC (le routeur MX Series entrant). Les routeurs R1, R2 et R3 sont les autres routeurs MX Series du réseau. Dans cet exemple, nous configurons le routage de segments pour PCEP sur le PCC. Nous configurons également une route statique sur le PCC vers le routeur R3 pour vérifier l’utilisation des routes de tunnel SR-TE lors du routage du trafic pour la route statique.
Configuration
Configuration rapide de l’interface de ligne de commande
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, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit]
hiérarchie, puis passez commit
en mode de configuration.
Bien que nous présentions la configuration de tous les périphériques (PCC et les trois routeurs) dans cette section, la procédure étape par étape ne documente que la configuration du PCC.
PCC
set interfaces ge-0/0/5 unit 0 family inet address 10.100.41.1/24 set interfaces ge-0/0/5 unit 0 family iso set interfaces ge-0/0/5 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.100.4/32 primary set interfaces lo0 unit 0 family iso address 49.0011.0110.0000.0101.00 set interfaces lo0 unit 0 family mpls set routing-options static route 100.1.1.1/32 next-hop 192.168.100.3 set routing-options router-id 192.168.100.4 set routing-options autonomous-system 64496 set protocols rsvp interface fxp0.0 disable set protocols rsvp interface all set protocols mpls lsp-external-controller pccd set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis source-packet-routing srgb start-label 800000 set protocols isis source-packet-routing srgb index-range 4000 set protocols isis source-packet-routing node-segment ipv4-index 101 set protocols isis source-packet-routing node-segment ipv6-index 11 set protocols isis level 1 disable set protocols isis level 2 wide-metrics-only set protocols isis interface all point-to-point set protocols isis interface all level 2 metric 10 set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0 passive set protocols source-packet-routing segment-list static_seg_list_1 hop1 label 800102 set protocols source-packet-routing segment-list static_seg_list_1 hop2 label 800103 set protocols source-packet-routing source-routing-path static_srte_lsp_1 to 192.168.100.3 set protocols source-packet-routing source-routing-path static_srte_lsp_1 primary static_seg_list_1 lsp-external-controller pccd set protocols spring-traffic-engineering lsp-external-controller pccd set protocols source-packet-routing source-routing-path static1 lsp-external-controller pccd set protocols pcep pce pce1 local-address 192.168.100.4 set protocols pcep pce pce1 destination-ipv4-address 10.102.180.232 set protocols pcep pce pce1 destination-port 4189 set protocols pcep pce pce1 pce-type active set protocols pcep pce pce1 pce-type stateful set protocols pcep pce pce1 lsp-provisioning set protocols pcep pce pce1 spring-capability
Routeur R1
set interfaces ge-0/0/5 unit 0 family inet address 10.100.41.2/24 set interfaces ge-0/0/5 unit 0 family iso set interfaces ge-0/0/5 unit 0 family mpls set interfaces ge-0/1/2 unit 0 family inet address 10.100.12.1/24 set interfaces ge-0/1/2 unit 0 family iso set interfaces ge-0/1/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.100.1/32 primary set interfaces lo0 unit 0 family iso address 49.0011.0110.0000.0102.00 set interfaces lo0 unit 0 family mpls set routing-options router-id 192.168.100.1 set routing-options autonomous-system 64496 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis source-packet-routing srgb start-label 800000 set protocols isis source-packet-routing srgb index-range 4000 set protocols isis source-packet-routing node-segment ipv4-index 102 set protocols isis level 1 disable set protocols isis level 2 wide-metrics-only set protocols isis interface all point-to-point set protocols isis interface all level 2 metric 10 set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0 passive
Routeur R2
set interfaces ge-0/1/2 unit 0 family inet address 10.100.12.2/24 set interfaces ge-0/1/2 unit 0 family iso set interfaces ge-0/1/2 unit 0 family mpls set interfaces ge-0/1/8 unit 0 family inet address 10.100.23.1/24 set interfaces ge-0/1/8 unit 0 family iso set interfaces ge-0/1/8 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.100.2/32 set interfaces lo0 unit 0 family iso address 49.0011.0110.0000.0105.00 set interfaces lo0 unit 0 family mpls set routing-options router-id 192.168.100.2 set routing-options autonomous-system 64496 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis source-packet-routing srgb start-label 800000 set protocols isis source-packet-routing srgb index-range 4000 set protocols isis source-packet-routing node-segment ipv4-index 105 set protocols isis level 1 disable set protocols isis level 2 wide-metrics-only set protocols isis interface all point-to-point set protocols isis interface all level 2 metric 10 set protocols isis interface all level 1 disable set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0 passive
Routeur R3
set interfaces ge-0/1/8 unit 0 family inet address 10.100.23.2/24 set interfaces ge-0/1/8 unit 0 family iso set interfaces ge-0/1/8 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.100.3/32 primary set interfaces lo0 unit 0 family iso address 49.0011.0110.0000.0103.00 set interfaces lo0 unit 0 family mpls set routing-options static route 100.1.1.1/32 receive set routing-options router-id 192.168.100.3 set routing-options autonomous-system 64496 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis source-packet-routing srgb start-label 800000 set protocols isis source-packet-routing srgb index-range 4000 set protocols isis source-packet-routing node-segment ipv4-index 103 set protocols isis level 1 disable set protocols isis level 2 wide-metrics-only set protocols isis interface all point-to-point set protocols isis interface all level 2 metric 10 set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0 passive
Procédure
Procédure étape par étape
Dans cet exemple, nous configurons uniquement le PCC.
Les étapes suivantes nécessitent que vous naviguiez à 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 à la section Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.
Pour configurer le PCC :
Configurez les interfaces du PCC.
[edit interfaces] user@PCC# set ge-0/0/5 unit 0 family inet address 10.100.41.1/24 user@PCC# set ge-0/0/5 unit 0 family iso user@PCC# set ge-0/0/5 unit 0 family mpls user@PCC# set lo0 unit 0 family inet address 192.168.100.4/32 primary user@PCC# set lo0 unit 0 family iso address 49.0011.0110.0000.0101.00 user@PCC# set lo0 unit 0 family mpls
Configurez l’ID du routeur et attribuez un numéro de système autonome au PCC.
[edit routing-options] user@PCC# set router-id 192.168.100.4 user@PCC# set autonomous-system 64496
Configurez une route statique entre le PCC et le routeur R3.
L’itinéraire statique est créé à des fins de vérification uniquement et n’affecte pas la fonctionnalité de fonctionnalité.
[edit routing-options] user@PCC# set static route 100.1.1.1/32 next-hop 192.168.100.3
Configurez RSVP sur toutes les interfaces du PCC, à l’exception de l’interface de gestion.
[edit protocols] user@PCC# set rsvp interface fxp0.0 disable user@PCC# set rsvp interface all
Configurez MPLS sur toutes les interfaces du PCC, à l’exception de l’interface de gestion.
[edit protocols] user@PCC# set mpls interface all user@PCC# set mpls interface fxp0.0 disable
Activez la capacité de calcul de chemin externe pour MPLS.
[edit protocols] user@PCC# set mpls lsp-external-controller pccd
Configurez IS-IS niveau 2 sur toutes les interfaces du PCC, à l’exception des interfaces de gestion et de bouclage.
[edit protocols] user@PCC# set isis level 1 disable user@PCC# set isis level 2 wide-metrics-only user@PCC# set isis interface all point-to-point user@PCC# set isis interface all level 2 metric 10 user@PCC# set isis interface fxp0.0 disable user@PCC# set isis interface lo0.0 passive
Configurez les attributs de bloc global de routage de segments (SRGB) pour le routage de segments.
[edit protocols] user@PCC# set isis source-packet-routing srgb start-label 800000 user@PCC# set isis source-packet-routing srgb index-range 4000 user@PCC# set isis source-packet-routing node-segment ipv4-index 101 user@PCC# set isis source-packet-routing node-segment ipv6-index 11
Activez la capacité de calcul de chemin externe pour SR-TE.
[edit protocols] user@PCC# set spring-traffic-engineering lsp-external-controller pccd
Configurez les paramètres PCE et activez le provisionnement du LSP par le PCE et la capacité de routage de segments.
[edit protocols] user@PCC# set pcep pce pce1 local-address 192.168.100.4 user@PCC# set pcep pce pce1 destination-ipv4-address 10.102.180.232 user@PCC# set pcep pce pce1 destination-port 4189 user@PCC# set pcep pce pce1 pce-type active user@PCC# set pcep pce pce1 pce-type stateful
Activez le provisionnement des LSP de routage de segments par le PCE.
[edit protocols] user@PCC# set pcep pce pce1 lsp-provisioning
Activez la fonctionnalité de routage de segments pour le PCE.
[edit protocols] user@PCC# set pcep pce pce1 spring-capability
Définissez les paramètres de la liste
static_seg_list_1
statique des segments.[edit protocols] user@PCC# set source-packet-routing segment-list static_seg_list_1 hop1 label 800102 user@PCC# set source-packet-routing segment-list static_seg_list_1 hop2 label 800103
Configurez un LSP de routage de segment statique du PCC vers le routeur R3 pour la délégation PCE.
[edit protocols] user@PCC# set source-packet-routing source-routing-path static_srte_lsp_1 to 192.168.100.3
Activez la capacité de délégation pour le
static_srte_lsp_1
chemin de routage source.[edit protocols] user@PCC# set source-packet-routing source-routing-path static_srte_lsp_1 primary static_seg_list_1 lsp-external-controller pccd
En effectuant les étapes 13, 14 et 15, vous permettez au PCC de déléguer les LSP de routage de segments au PCE.
Validez la configuration.
Résultats
À partir du mode de configuration, confirmez votre configuration en saisissant les commandes show interfaces
, show routing-options
et show protocols
. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
user@PCC# show interfaces ge-0/0/5 { unit 0 { family inet { address 10.100.41.1/24; } family iso; family mpls; } } lo0 { unit 0 { family inet { address 192.168.100.4/32 { primary; } } family iso { address 49.0011.0110.0000.0101.00; } family mpls; } }
user@PCC# show routing-options static { route 100.1.1.1/32 next-hop 192.168.100.3; } router-id 192.168.100.4; autonomous-system 64496;
user@PCC# show protocols rsvp { interface fxp0.0 { disable; } interface all; } mpls { lsp-external-controller pccd; interface all; interface fxp0.0 { disable; } } isis { source-packet-routing { srgb start-label 800000 index-range 4000; node-segment { ipv4-index 101; ipv6-index 11; } } level 1 disable; level 2 wide-metrics-only; interface all { point-to-point; level 2 metric 10; } interface fxp0.0 { disable; } interface lo0.0 { passive; } } spring-traffic-engineering { lsp-external-controller pccd; } source-packet-routing { segment-list static_seg_list_1 { hop1 label 800102 hop1 label 800102 } source-routing-path static_srte_lsp_1 { to 192.168.100.3; primary { static_seg_list_1 { lsp-external-controller pccd; } } } } pcep { pce pce1 { local-address 192.168.100.4; destination-ipv4-address 10.102.180.232; destination-port 4189; pce-type active stateful; lsp-provisioning; spring-capability; } }
Si vous avez terminé de configurer l’appareil (le PCC), passez commit
en mode de configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérifier la contiguïté et les étiquettes IS-IS
- Vérifier la base de données des aspects techniques du trafic
- Vérifier les LSP SR-TE
- Vérifier la création d’un itinéraire de tunnel
- Vérifier les entrées de la table de transfert
- Vérifier l’utilisation des routes de tunnel pour le transfert de route statique
Vérifier la contiguïté et les étiquettes IS-IS
But
Vérifiez la contiguïté IS-IS sur le PCC. Prenez note de la plage d’étiquettes SRGB, des valeurs d’adjacence et de segment de nœud, ainsi que des champs de sortie de la capacité SPRING.
Action
En mode opérationnel, exécutez les show isis adjacency extensive
commandes , show isis database extensive
, et show isis overview
.
user@PCC> show isis adjacency extensive R1 Interface: ge-0/0/5.0, Level: 2, State: Up, Expires in 25 secs Priority: 0, Up/Down transitions: 1, Last transition: 00:37:15 ago Circuit type: 2, Speaks: IP, IPv6 Topologies: Unicast Restart capable: Yes, Adjacency advertisement: Advertise IP addresses: 10.100.41.2 Level 2 IPv4 Adj-SID: 16 Transition log: When State Event Down reason Wed Apr 5 02:42:48 Up Seenself PCE Interface: gre.0, Level: 2, State: Up, Expires in 25 secs Priority: 0, Up/Down transitions: 1, Last transition: 00:27:00 ago Circuit type: 2, Speaks: IP, IPv6 Topologies: Unicast Restart capable: Yes, Adjacency advertisement: Advertise IP addresses: 11.105.199.2 Level 2 Transition log: When State Event Down reason Wed Apr 5 02:53:03 Up Seenself
user@PCC> show isis database extensive IS-IS level 1 link-state database: IS-IS level 2 link-state database: PCC.00-00 Sequence: 0x2a6, Checksum: 0x1a4f, Lifetime: 1150 secs IPV4 Index: 101 Node Segment Blocks Advertised: Start Index : 0, Size : 4000, Label-Range: [ 800000, 803999 ] IS neighbor: R1.00 Metric: 10 Two-way fragment: R1.00-00, Two-way first fragment: R1.00-00 IS neighbor: PCE.00 Metric: 16777215 IP prefix: 192.168.100.4/32 Metric: 0 Internal Up IP prefix: 11.101.102.0/30 Metric: 10 Internal Up IP prefix: 11.105.199.0/30 Metric: 16777215 Internal Up Header: LSP ID: PCC.00-00, Length: 243 bytes Allocated length: 1492 bytes, Router ID: 192.168.100.4 Remaining lifetime: 1150 secs, Level: 2, Interface: 0 Estimated free bytes: 1084, Actual free bytes: 1249 Aging timer expires in: 1150 secs Protocols: IP, IPv6 Packet: LSP ID: PCC.00-00, Length: 243 bytes, Lifetime : 1198 secs Checksum: 0x1a4f, Sequence: 0x2a6, Attributes: 0x3 L1 L2 NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes Packet type: 20, Packet version: 1, Max area: 0 TLVs: Area address: 49.0011 (3) LSP Buffer Size: 1492 Speaks: IP Speaks: IPV6 IP router id: 192.168.100.4 IP address: 192.168.100.4 Hostname: PCC IS extended neighbor: R1.00, Metric: default 10 IP address: 10.100.41.1 Neighbor's IP address: 10.100.41.2 Local interface index: 334, Remote interface index: 333 Current reservable bandwidth: Priority 0 : 10Mbps Priority 1 : 10Mbps Priority 2 : 10Mbps Priority 3 : 10Mbps Priority 4 : 10Mbps Priority 5 : 10Mbps Priority 6 : 10Mbps Priority 7 : 10Mbps Maximum reservable bandwidth: 10Mbps Maximum bandwidth: 10Mbps Administrative groups: 0 none P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0), Weight:0, Label: 16 IS extended neighbor: PCE.00, Metric: default 16777215 IP address: 11.105.199.1 Neighbor's IP address: 11.105.199.2 Local interface index: 329, Remote interface index: 329 IP extended prefix: 11.101.102.0/30 metric 10 up IP extended prefix: 11.105.199.0/30 metric 16777215 up IP extended prefix: 192.168.100.4/32 metric 0 up 8 bytes of subtlvs Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 101 Router Capability: Router ID 192.168.100.4, Flags: 0x00 SPRING Capability - Flags: 0xc0(I:1,V:1), Range: 4000, SID-Label: 800000 SPRING Algorithm - Algo: 0 No queued transmissions R1.00-00 Sequence: 0x297, Checksum: 0x1615, Lifetime: 839 secs IPV4 Index: 102 Node Segment Blocks Advertised: Start Index : 0, Size : 4000, Label-Range: [ 800000, 803999 ] IS neighbor: PCC.00 Metric: 10 Two-way fragment: PCC.00-00, Two-way first fragment: PCC.00-00 IS neighbor: R2.00 Metric: 10 Two-way fragment: R2.00-00, Two-way first fragment: R2.00-00 IP prefix: 192.168.100.1/32 Metric: 0 Internal Up IP prefix: 11.101.102.0/30 Metric: 10 Internal Up IP prefix: 11.102.105.0/30 Metric: 10 Internal Up Header: LSP ID: R1.00-00, Length: 302 bytes Allocated length: 302 bytes, Router ID: 192.168.100.1 Remaining lifetime: 839 secs, Level: 2, Interface: 334 Estimated free bytes: 0, Actual free bytes: 0 Aging timer expires in: 839 secs Protocols: IP, IPv6 Packet: LSP ID: R1.00-00, Length: 302 bytes, Lifetime : 1196 secs Checksum: 0x1615, Sequence: 0x297, Attributes: 0x3 L1 L2 NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes Packet type: 20, Packet version: 1, Max area: 0 TLVs: Area address: 49.0011 (3) LSP Buffer Size: 1492 Speaks: IP Speaks: IPV6 IP router id: 192.168.100.1 IP address: 192.168.100.1 Hostname: R1 IP extended prefix: 192.168.100.1/32 metric 0 up 8 bytes of subtlvs Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 102 IP extended prefix: 11.101.102.0/30 metric 10 up IP extended prefix: 11.102.105.0/30 metric 10 up Router Capability: Router ID 192.168.100.1, Flags: 0x00 SPRING Capability - Flags: 0xc0(I:1,V:1), Range: 4000, SID-Label: 800000 SPRING Algorithm - Algo: 0 IS extended neighbor: R2.00, Metric: default 10 IP address: 10.100.12.1 Neighbor's IP address: 10.100.12.2 Local interface index: 334, Remote interface index: 333 Current reservable bandwidth: Priority 0 : 10Mbps Priority 1 : 10Mbps Priority 2 : 10Mbps Priority 3 : 10Mbps Priority 4 : 10Mbps Priority 5 : 10Mbps Priority 6 : 10Mbps Priority 7 : 10Mbps Maximum reservable bandwidth: 10Mbps Maximum bandwidth: 10Mbps Administrative groups: 0 none P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0), Weight:0, Label: 17 IS extended neighbor: PCC.00, Metric: default 10 IP address: 10.100.41.2 Neighbor's IP address: 10.100.41.1 Local interface index: 333, Remote interface index: 334 Current reservable bandwidth: Priority 0 : 10Mbps Priority 1 : 10Mbps Priority 2 : 10Mbps Priority 3 : 10Mbps Priority 4 : 10Mbps Priority 5 : 10Mbps Priority 6 : 10Mbps Priority 7 : 10Mbps Maximum reservable bandwidth: 10Mbps Maximum bandwidth: 10Mbps Administrative groups: 0 none P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0), Weight:0, Label: 16 No queued transmissions R3.00-00 Sequence: 0x95, Checksum: 0xd459, Lifetime: 895 secs IPV4 Index: 103 Node Segment Blocks Advertised: Start Index : 0, Size : 4000, Label-Range: [ 800000, 803999 ] IS neighbor: R2.00 Metric: 10 Two-way fragment: R2.00-00, Two-way first fragment: R2.00-00 IP prefix: 192.168.100.3/32 Metric: 0 Internal Up IP prefix: 11.102.1.0/24 Metric: 10 Internal Up IP prefix: 11.103.107.0/30 Metric: 10 Internal Up Header: LSP ID: R3.00-00, Length: 209 bytes Allocated length: 284 bytes, Router ID: 192.168.100.3 Remaining lifetime: 895 secs, Level: 2, Interface: 334 Estimated free bytes: 75, Actual free bytes: 75 Aging timer expires in: 895 secs Protocols: IP, IPv6 Packet: LSP ID: R3.00-00, Length: 209 bytes, Lifetime : 1192 secs Checksum: 0xd459, Sequence: 0x95, Attributes: 0x3 L1 L2 NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes Packet type: 20, Packet version: 1, Max area: 0 TLVs: Area address: 49.0011 (3) LSP Buffer Size: 1492 Speaks: IP Speaks: IPV6 IP router id: 192.168.100.3 IP address: 192.168.100.3 Hostname: R3 IS extended neighbor: R2.00, Metric: default 10 IP address: 10.100.23.2 Neighbor's IP address: 10.100.23.1 Local interface index: 336, Remote interface index: 334 Current reservable bandwidth: Priority 0 : 10Mbps Priority 1 : 10Mbps Priority 2 : 10Mbps Priority 3 : 10Mbps Priority 4 : 10Mbps Priority 5 : 10Mbps Priority 6 : 10Mbps Priority 7 : 10Mbps Maximum reservable bandwidth: 10Mbps Maximum bandwidth: 10Mbps Administrative groups: 0 none P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0), Weight:0, Label: 16 IP extended prefix: 192.168.100.3/32 metric 0 up 8 bytes of subtlvs Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 103 IP extended prefix: 11.103.107.0/30 metric 10 up IP extended prefix: 11.102.1.0/24 metric 10 up Router Capability: Router ID 192.168.100.3, Flags: 0x00 SPRING Capability - Flags: 0xc0(I:1,V:1), Range: 4000, SID-Label: 800000 SPRING Algorithm - Algo: 0 No queued transmissions R2.00-00 Sequence: 0x2aa, Checksum: 0xf8f4, Lifetime: 1067 secs IPV4 Index: 105 Node Segment Blocks Advertised: Start Index : 0, Size : 4000, Label-Range: [ 800000, 803999 ] IS neighbor: R1.00 Metric: 10 Two-way fragment: R1.00-00, Two-way first fragment: R1.00-00 IS neighbor: R3.00 Metric: 10 Two-way fragment: R3.00-00, Two-way first fragment: R3.00-00 IP prefix: 192.168.100.2/32 Metric: 0 Internal Up IP prefix: 11.102.105.0/30 Metric: 10 Internal Up IP prefix: 11.103.107.0/30 Metric: 10 Internal Up Header: LSP ID: R2.00-00, Length: 302 bytes Allocated length: 302 bytes, Router ID: 192.168.100.2 Remaining lifetime: 1067 secs, Level: 2, Interface: 334 Estimated free bytes: 0, Actual free bytes: 0 Aging timer expires in: 1067 secs Protocols: IP, IPv6 Packet: LSP ID: R2.00-00, Length: 302 bytes, Lifetime : 1194 secs Checksum: 0xf8f4, Sequence: 0x2aa, Attributes: 0x3 L1 L2 NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes Packet type: 20, Packet version: 1, Max area: 0 TLVs: Area address: 49.0011 (3) LSP Buffer Size: 1492 Speaks: IP Speaks: IPV6 IP router id: 192.168.100.2 IP address: 192.168.100.2 Hostname: R2 IP extended prefix: 192.168.100.2/32 metric 0 up 8 bytes of subtlvs Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 105 IP extended prefix: 11.102.105.0/30 metric 10 up IP extended prefix: 11.103.107.0/30 metric 10 up Router Capability: Router ID 192.168.100.2, Flags: 0x00 SPRING Capability - Flags: 0xc0(I:1,V:1), Range: 4000, SID-Label: 800000 SPRING Algorithm - Algo: 0 IS extended neighbor: R3.00, Metric: default 10 IP address: 10.100.23.1 Neighbor's IP address: 10.100.23.2 Local interface index: 334, Remote interface index: 336 Current reservable bandwidth: Priority 0 : 10Mbps Priority 1 : 10Mbps Priority 2 : 10Mbps Priority 3 : 10Mbps Priority 4 : 10Mbps Priority 5 : 10Mbps Priority 6 : 10Mbps Priority 7 : 10Mbps Maximum reservable bandwidth: 10Mbps Maximum bandwidth: 10Mbps Administrative groups: 0 none P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0), Weight:0, Label: 16 IS extended neighbor: R1.00, Metric: default 10 IP address: 10.100.12.2 Neighbor's IP address: 10.100.12.1 Local interface index: 333, Remote interface index: 334 Current reservable bandwidth: Priority 0 : 10Mbps Priority 1 : 10Mbps Priority 2 : 10Mbps Priority 3 : 10Mbps Priority 4 : 10Mbps Priority 5 : 10Mbps Priority 6 : 10Mbps Priority 7 : 10Mbps Maximum reservable bandwidth: 10Mbps Maximum bandwidth: 10Mbps Administrative groups: 0 none P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0), Weight:0, Label: 17 No queued transmissions PCE.00-00 Sequence: 0x277, Checksum: 0x64a5, Lifetime: 533 secs IS neighbor: PCC.00 Metric: 16777215 IP prefix: 11.0.0.199/32 Metric: 0 Internal Up IP prefix: 11.105.199.0/30 Metric: 16777215 Internal Up Header: LSP ID: PCE.00-00, Length: 120 bytes Allocated length: 284 bytes, Router ID: 11.0.0.199 Remaining lifetime: 533 secs, Level: 2, Interface: 329 Estimated free bytes: 164, Actual free bytes: 164 Aging timer expires in: 533 secs Protocols: IP, IPv6 Packet: LSP ID: PCE.00-00, Length: 120 bytes, Lifetime : 1196 secs Checksum: 0x64a5, Sequence: 0x277, Attributes: 0x3 L1 L2 NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes Packet type: 20, Packet version: 1, Max area: 0 TLVs: Area address: 11.0007 (3) LSP Buffer Size: 1492 Speaks: IP Speaks: IPV6 IP router id: 11.0.0.199 IP address: 11.0.0.199 Hostname: PCE Router Capability: Router ID 11.0.0.199, Flags: 0x00 IP extended prefix: 11.105.199.0/30 metric 16777215 up IP extended prefix: 11.0.0.199/32 metric 0 up IS extended neighbor: PCC.00, Metric: default 16777215 IP address: 11.105.199.2 Neighbor's IP address: 11.105.199.1 Local interface index: 329, Remote interface index: 329 No queued transmissions
user@PCC> show isis overview Instance: master Router ID: 192.168.100.4 Hostname: PCC Sysid: 0110.0000.0101 Areaid: 49.0011 Adjacency holddown: enabled Maximum Areas: 3 LSP life time: 1200 Attached bit evaluation: enabled SPF delay: 200 msec, SPF holddown: 5000 msec, SPF rapid runs: 3 IPv4 is enabled, IPv6 is enabled, SPRING based MPLS is enabled Traffic engineering: enabled Restart: Disabled Helper mode: Enabled Layer2-map: Disabled Source Packet Routing (SPRING): Enabled SRGB Config Range: SRGB Start-Label : 800000, SRGB Index-Range : 4000 SRGB Block Allocation: Success SRGB Start Index : 800000, SRGB Size : 4000, Label-Range: [ 800000, 803999 ] Node Segments: Enabled Ipv4 Index : 101, Ipv6 Index : 11 Level 1 Internal route preference: 15 External route preference: 160 Prefix export count: 0 Wide metrics are enabled, Narrow metrics are enabled Source Packet Routing is enabled Level 2 Internal route preference: 18 External route preference: 165 Prefix export count: 0 Wide metrics are enabled Source Packet Routing is enabled
Sens
La contiguïté IS-IS entre le PCC et le PCE et celle entre le PCC et le routeur R1 sont actives et opérationnelles. La sortie affiche également les affectations d’étiquettes pour les segments adjacents et de nœud.
Vérifier la base de données des aspects techniques du trafic
But
Vérifiez les entrées de la base de données d’ingénierie du trafic sur le PCC.
Action
À partir du mode opérationnel, exécutez la show ted database extensive
commande.
user@PCC# show ted database extensive TED database: 5 ISIS nodes 5 INET nodes NodeID: PCC.00(192.168.100.4) Type: Rtr, Age: 403 secs, LinkIn: 1, LinkOut: 1 Protocol: IS-IS(2) 192.168.100.4 To: R1.00(192.168.100.1), Local: 10.100.41.1, Remote: 10.100.41.2 Local interface index: 334, Remote interface index: 333 Color: 0 none Metric: 10 IGP metric: 10 Static BW: 10Mbps Reservable BW: 10Mbps Available BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps P2P Adjacency-SID: IPV4, SID: 16, Flags: 0x30, Weight: 0 Prefixes: 192.168.100.4/32 Metric: 0, Flags: 0x00 Prefix-SID: SID: 101, Flags: 0x40, Algo: 0 SPRING-Capabilities: SRGB block [Start: 800000, Range: 4000, Flags: 0xc0] SPRING-Algorithms: Algo: 0 NodeID: R1.00(192.168.100.1) Type: Rtr, Age: 712 secs, LinkIn: 2, LinkOut: 2 Protocol: IS-IS(2) 192.168.100.1 To: PCC.00(192.168.100.4), Local: 10.100.41.2, Remote: 10.100.41.1 Local interface index: 333, Remote interface index: 334 Color: 0 none Metric: 10 IGP metric: 10 Static BW: 10Mbps Reservable BW: 10Mbps Available BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps P2P Adjacency-SID: IPV4, SID: 16, Flags: 0x30, Weight: 0 To: R2.00(192.168.100.2), Local: 10.100.12.1, Remote: 10.100.12.2 Local interface index: 334, Remote interface index: 333 Color: 0 none Metric: 10 IGP metric: 10 Static BW: 10Mbps Reservable BW: 10Mbps Available BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps P2P Adjacency-SID: IPV4, SID: 17, Flags: 0x30, Weight: 0 Prefixes: 192.168.100.1/32 Metric: 0, Flags: 0x00 Prefix-SID: SID: 102, Flags: 0x40, Algo: 0 SPRING-Capabilities: SRGB block [Start: 800000, Range: 4000, Flags: 0xc0] SPRING-Algorithms: Algo: 0 NodeID: R3.00(192.168.100.3) Type: Rtr, Age: 435 secs, LinkIn: 1, LinkOut: 1 Protocol: IS-IS(2) 192.168.100.3 To: R2.00(192.168.100.2), Local: 10.100.23.2, Remote: 10.100.23.1 Local interface index: 336, Remote interface index: 334 Color: 0 none Metric: 10 IGP metric: 10 Static BW: 10Mbps Reservable BW: 10Mbps Available BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps P2P Adjacency-SID: IPV4, SID: 16, Flags: 0x30, Weight: 0 Prefixes: 192.168.100.3/32 Metric: 0, Flags: 0x00 Prefix-SID: SID: 103, Flags: 0x40, Algo: 0 SPRING-Capabilities: SRGB block [Start: 800000, Range: 4000, Flags: 0xc0] SPRING-Algorithms: Algo: 0 NodeID: R2.00(192.168.100.2) Type: Rtr, Age: 456 secs, LinkIn: 2, LinkOut: 2 Protocol: IS-IS(2) 192.168.100.2 To: R1.00(192.168.100.1), Local: 10.100.12.2, Remote: 10.100.12.1 Local interface index: 333, Remote interface index: 334 Color: 0 none Metric: 10 IGP metric: 10 Static BW: 10Mbps Reservable BW: 10Mbps Available BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps P2P Adjacency-SID: IPV4, SID: 17, Flags: 0x30, Weight: 0 To: R3.00(192.168.100.3), Local: 10.100.23.1, Remote: 10.100.23.2 Local interface index: 334, Remote interface index: 336 Color: 0 none Metric: 10 IGP metric: 10 Static BW: 10Mbps Reservable BW: 10Mbps Available BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps [4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps P2P Adjacency-SID: IPV4, SID: 16, Flags: 0x30, Weight: 0 Prefixes: 192.168.100.2/32 Metric: 0, Flags: 0x00 Prefix-SID: SID: 105, Flags: 0x40, Algo: 0 SPRING-Capabilities: SRGB block [Start: 800000, Range: 4000, Flags: 0xc0] SPRING-Algorithms: Algo: 0 NodeID: PCE.00(11.0.0.199) Type: Rtr, Age: 267 secs, LinkIn: 0, LinkOut: 0 Protocol: IS-IS(2) 11.0.0.199
Sens
La base de données des aspects techniques du trafic inclut les entrées annoncées par les routeurs R1, R2 et R3, que le PCE utilise pour le calcul de chemin externe pour le PCC.
Vérifier les LSP SR-TE
But
Vérifiez la création des LSP SR-TE sur le PCC.
Action
En mode opérationnel, exécutez les show path-computation-client lsp
commandes , show spring-traffic-engineering lsp detail
, et show route protocol spring-te
.
user@PCC> show path-computation-client lsp Name Status PLSP-Id LSP-Type Controller Path-Setup-Type Template adj_sid_lsp (Up) 3 ext-provised pce1 spring-te node_sid_lsp (Up) 5 ext-provised pce1 spring-te
user@PCC> show spring-traffic-engineering lsp detail Name: adj_sid_lsp To: 192.168.100.3 State: Up, Outgoing interface: ge-0/0/5.0 Delegation info: Control-status: Externally controlled Routing-status: Externally routed SR-ERO hop count: 3 Hop 1 (Strict): NAI: IPv4 Adjacency ID, 10.100.41.1 -> 10.100.41.2 SID type: 20-bit label, Value: 16 Hop 2 (Strict): NAI: IPv4 Adjacency ID, 10.100.12.1 -> 10.100.12.2 SID type: 20-bit label, Value: 17 Hop 3 (Strict): NAI: IPv4 Adjacency ID, 10.100.23.1 -> 10.100.23.2 SID type: 20-bit label, Value: 16 Name: node_sid_lsp To: 192.168.100.3 State: Up, Outgoing interface: ge-0/0/5.0 Delegation info: Control-status: Externally controlled Routing-status: Externally routed SR-ERO hop count: 3 Hop 1 (Strict): NAI: IPv4 Adjacency ID, 10.100.41.1 -> 10.100.41.2 SID type: 20-bit label, Value: 16 Hop 2 (Strict): NAI: IPv4 Node ID, Node address: 192.168.100.1 SID type: 20-bit label, Value: 800105 Hop 3 (Strict): NAI: IPv4 Node ID, Node address: 192.168.100.2 SID type: 20-bit label, Value: 800103 Name: static_srte_lsp_1 Tunnel-source: Static configuration To: 192.168.100.3 State: Up Path: static_seg_list_1 Outgoing interface: NA Delegation info: Control-status: Externally controlled Routing-status: Externally routed Auto-translate status: Disabled Auto-translate result: N/A BFD status: Up BFD name: V4-srte_bfd_session-4 SR-ERO hop count: 2 Hop 1 (Strict): NAI: IPv4 Adjacency ID, 13.1.1.2 -> 36.12.16.1 SID type: None Hop 2 (Strict): NAI: IPv4 Node ID, Node address: 192.168.100.3 SID type: 20-bit label, Value: 804000 Total displayed LSPs: 3 (Up: 3, Down: 0)
user@PCC> show route protocol spring-te inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden) inet.3: 3 destinations, 4 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.100.3/32 *[SPRING-TE/8] 00:23:32, metric 0 to 10.100.41.2 via ge-0/0/5.0, Push 16, Push 17(top) > to 10.100.41.2 via ge-0/0/5.0, Push 800103, Push 800105(top) iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
Sens
Les résultats montrent que deux LSP SR-TE — et —adj_sid_lsp
ont été créés par le PCE pour les segments d’adjacence et node_sid_lsp
de nœud, respectivement.
Le LSP static_srte_lsp_1
de routage de segments , , est activé avec la capacité de délégation. Le Delegation info
champ indique l’état de contrôle et de routage des LSP délégués par PCE. signifie que le PCE a le contrôle sur les LSP. signifie que le PCE a fourni l’ERO pour le chemin de routage source. Externally controlled
Externally routed
Vérifier la création d’un itinéraire de tunnel
But
Vérifiez les routes de tunnel créées pour les LSP SR-TE qui sont inclus dans la table de routage inet.3 sur le PCC.
Action
À partir du mode de fonctionnement, exécutez la show route table inet.3 extensive
commande.
user@PCC> show route table inet.3 extensive inet.3: 3 destinations, 4 routes (3 active, 0 holddown, 0 hidden) 192.168.100.1/32 (1 entry, 1 announced) *L-ISIS Preference: 14 Level: 2 Next hop type: Router, Next hop index: 581 Address: 0xb7a23b0 Next-hop reference count: 13 Next hop: 10.100.41.2 via ge-0/0/5.0, selected Session Id: 0x172 State: Active Int Local AS: 64496 Age: 45:51 Metric: 10 Validation State: unverified ORR Generation-ID: 0 Task: IS-IS Announcement bits (2): 0-Resolve tree 1 2-Resolve tree 3 AS path: I 192.168.100.3/32 (2 entries, 1 announced) *SPRING-TE Preference: 8 Next hop type: Router, Next hop index: 0 Address: 0xb61c190 Next-hop reference count: 7 Next hop: 10.100.41.2 via ge-0/0/5.0 weight 0x1 Label operation: Push 16, Push 17(top) Label TTL action: prop-ttl, prop-ttl(top) Load balance label: Label 16: None; Label 17: None; Label element ptr: 0xb7a2a60 Label parent element ptr: 0x0 Label element references: 5 Label element child references: 0 Label element lsp id: 0 Session Id: 0x0 Next hop: 10.100.41.2 via ge-0/0/5.0 weight 0x1, selected Label operation: Push 800103, Push 800105(top) Label TTL action: prop-ttl, prop-ttl(top) Load balance label: Label 800103: None; Label 800105: None; Label element ptr: 0xb7a2c40 Label parent element ptr: 0x0 Label element references: 2 Label element child references: 0 Label element lsp id: 0 Session Id: 0x0 State: Active Int Local AS: 64496 Age: 9:44 Metric: 0 Validation State: unverified Task: SPRING-TE Announcement bits (2): 0-Resolve tree 1 2-Resolve tree 3 AS path: I L-ISIS Preference: 14 Level: 2 Next hop type: Router, Next hop index: 0 Address: 0xb7a28f0 Next-hop reference count: 1 Next hop: 10.100.41.2 via ge-0/0/5.0, selected Label operation: Push 800103 Label TTL action: prop-ttl Load balance label: Label 800103: None; Label element ptr: 0xb7a2880 Label parent element ptr: 0x0 Label element references: 1 Label element child references: 0 Label element lsp id: 0 Session Id: 0x0 State: Int Inactive reason: Route Preference Local AS: 64496 Age: 45:40 Metric: 30 Validation State: unverified ORR Generation-ID: 0 Task: IS-IS AS path: I 192.168.100.2/32 (1 entry, 1 announced) *L-ISIS Preference: 14 Level: 2 Next hop type: Router, Next hop index: 0 Address: 0xb7a29b0 Next-hop reference count: 1 Next hop: 10.100.41.2 via ge-0/0/5.0, selected Label operation: Push 800105 Label TTL action: prop-ttl Load balance label: Label 800105: None; Label element ptr: 0xb7a2940 Label parent element ptr: 0x0 Label element references: 1 Label element child references: 0 Label element lsp id: 0 Session Id: 0x0 State: Active Int Local AS: 64496 Age: 45:40 Metric: 20 Validation State: unverified ORR Generation-ID: 0 Task: IS-IS Announcement bits (2): 0-Resolve tree 1 2-Resolve tree 3 AS path: I
Sens
Des routes de tunnel ont été créées pour la destination LSP contrôlée par PCE avec SR-TE comme étiquette de protocole.
Vérifier les entrées de la table de transfert
But
Vérifiez que la destination SR-TE LSP vers le routeur R3 est installée dans la table de transfert du PCC.
Action
À partir du mode de fonctionnement, exécutez la show route forwarding-table destination ip-address extensive
commande.
user@PCC> show route forwarding-table destination 192.168.100.3 extensive Routing table: default.inet [Index 0] Internet: Enabled protocols: Bridging, Destination: 192.168.100.3/32 Route type: user Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0 P2mpidx: 0 Flags: sent to PFE, rt nh decoupled Nexthop: 10.100.41.2 Next-hop type: unicast Index: 581 Reference: 14 Next-hop interface: ge-0/0/5.0 Routing table: __pfe_private__.inet [Index 3] Internet: Enabled protocols: Bridging, Destination: default Route type: permanent Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0 P2mpidx: 0 Flags: sent to PFE Next-hop type: discard Index: 517 Reference: 2 Routing table: __juniper_services__.inet [Index 5] Internet: Enabled protocols: Bridging, Destination: default Route type: permanent Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0 P2mpidx: 0 Flags: sent to PFE Next-hop type: discard Index: 530 Reference: 2 Routing table: __master.anon__.inet [Index 6] Internet: Enabled protocols: Bridging, Dual VLAN, Destination: default Route type: permanent Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0 P2mpidx: 0 Flags: sent to PFE Next-hop type: reject Index: 545 Reference: 1
Sens
L’adresse IP de destination du LSP SR-TE vers le routeur R3 est installée en tant qu’entrée de transfert.
Vérifier l’utilisation des routes de tunnel pour le transfert de route statique
But
Vérifiez que l’itinéraire statique emprunte l’itinéraire tunnel créé pour les LSP SR-TE.
Action
À partir du mode opérationnel, exécutez les show route ip-address
commandes and show route forwarding-table destination ip-address
.
user@PCC> show route 100.1.1.1 inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 100.1.1.1/32 *[Static/5] 00:33:36, metric2 0 > to 10.100.41.2 via ge-0/0/5.0, Push 16, Push 17(top) to 10.100.41.2 via ge-0/0/5.0, Push 800103, Push 800105(top)
user@PCC> show route forwarding-table destination 100.1.1.1 Routing table: default.inet Internet: Enabled protocols: Bridging, Destination Type RtRef Next hop Type Index NhRef Netif 100.1.1.1/32 user 0 indr 1048575 2 10.100.41.2 Push 16, Push 17(top) 590 2 ge-0/0/5.0 Routing table: __pfe_private__.inet Internet: Enabled protocols: Bridging, Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 dscd 517 2 Routing table: __juniper_services__.inet Internet: Enabled protocols: Bridging, Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 dscd 530 2 Routing table: __master.anon__.inet Internet: Enabled protocols: Bridging, Dual VLAN, Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 545 1
Sens
Les sorties montrent que la route statique vers le routeur R3 utilise la route de tunnel créée pour le SR-TE LSP.
Chemin de commutation d’étiquette de segment routing statique
L’architecture de routage de segments permet aux périphériques entrants d’un réseau central d’orienter le trafic via des chemins explicites. Vous pouvez configurer ces chemins à l’aide de listes de segments pour définir les chemins que le trafic entrant doit emprunter. Le trafic entrant peut être étiqueté ou trafic IP, ce qui fait que l’opération de transfert au niveau de l’équipement entrant est soit un échange d’étiquettes, soit une recherche basée sur la destination.
- Comprendre le LSP de segment routing statique dans les réseaux MPLS
- Exemple : configuration du chemin de commutation d’étiquette de segment routing statique
Comprendre le LSP de segment routing statique dans les réseaux MPLS
Le routage de paquets source, ou routage de segments, est une architecture de plan de contrôle qui permet à un routeur entrant de diriger un paquet à travers un ensemble spécifique de nuds et de liaisons dans le réseau sans dépendre des nuds intermédiaires du réseau pour déterminer le chemin qu’il doit emprunter.
- Introduction aux LSP de Segment Routing
- Avantages des LSP de Segment Routing
- LSP de routage de segments statique coloré
- LSP de routage de segments statique non coloré
- Provisionnement LSP de segment routing statique
- Static Segment Routing LSP Limitations
- Création dynamique de LSP de Segment Routing
- Mappage basé sur les couleurs des services VPN
- Modèles de tunnel pour les prestataires de services linguistiques Segment Routing initiés par PCE
Introduction aux LSP de Segment Routing
Le routage de segments s’appuie sur le paradigme du routage source. Un périphérique oriente un paquet à travers une liste ordonnée d’instructions, appelées segments. Un segment peut représenter n’importe quelle instruction, topologique ou basée sur un service. Un segment peut avoir une sémantique locale vers un nœud de routage de segment ou vers un nœud global au sein d’un domaine de routage de segment. Le routage de segments applique un flux à travers n’importe quel chemin topologique et n’importe quelle chaîne de services tout en conservant l’état par flux uniquement au niveau de l’équipement d’entrée dans le domaine de routage de segment. Le routage de segments peut être appliqué directement à l’architecture MPLS sans modification du plan de transfert. Un segment est encodé en tant qu’étiquette MPLS. Une liste ordonnée de segments est encodée sous la forme d’une pile d’étiquettes. Le segment à traiter se trouve en haut de la pile. À la fin d’un segment, l’étiquette associée est extraite de la pile.
Les LSP de routage de segments peuvent être de nature dynamique ou statique.
Dynamic segment routing LSPs—Lorsqu’un LSP de routage de segments est créé par un contrôleur externe et téléchargé sur un périphérique d’entrée via des extensions PCEP (Path Computation Element Protocol), ou à partir d’une stratégie de routage de segment BGP via des extensions de routage de segments BGP, le LSP est provisionné dynamiquement. La liste des segments du LSP de routage de segments dynamique est contenue dans l’objet de route explicite (ERO) PCEP ou dans la stratégie de routage de segments BGP du LSP. |
Static segment routing LSPs: lorsqu’un LSP de routage de segments est créé sur le périphérique d’entrée par le biais d’une configuration locale, le LSP est provisionné de manière statique. Un LSP de routage de segments statique peut en outre être classé en LSP colorés et non colorés en fonction de la configuration de l’instruction Par exemple : [edit protocols] source-packet-routing { source-routing-path lsp_name { to destination_address; color color_value; binding-sid binding-label; primary segment_list_1_name weight weight; ... primary segment_list_n_name weight weight; secondary segment_list_n_name; sr-preference sr_preference_value; } } Ici, chaque instruction primaire et secondaire fait référence à une liste de segments. [edit protocols] source-packet-routing { segment-list segment_list_name { hop_1_name label sid_label; ... hop_n_name label sid_label; } } |
Avantages des LSP de Segment Routing
-
Le routage de segments statique ne dépend pas de l’état de transfert par LSP sur les routeurs de transit. Par conséquent, il n’est plus nécessaire d’approvisionner et de maintenir l’état de transfert par LSP dans le cur.
-
Fournir une plus grande évolutivité aux réseaux MPLS.
LSP de routage de segments statique coloré
Un LSP de routage de segments statique configuré avec l’instruction color
est appelé LSP coloré.
- Comprendre les LSP de routage de segments statiques colorés
- Liste de segments des LSP Segment Routing colorés
Comprendre les LSP de routage de segments statiques colorés
Comme pour une stratégie de routage de segment BGP, la route d’entrée du LSP coloré est installée dans les inetcolor.0
tables de routage ou inet6color.0
, avec destination-ip-address, color
comme clé pour mapper le trafic IP.
Un LSP de routage de segment coloré statique peut avoir un SID de liaison, pour lequel un itinéraire est installé dans la mpls.0
table de routage. Cette étiquette SID de liaison est utilisée pour mapper le trafic étiqueté au LSP de routage de segment. Les passerelles de la route sont dérivées des configurations de liste de segments sous les chemins principal et secondaire.
Liste de segments des LSP Segment Routing colorés
Les LSP de routage de segments statiques colorés prennent déjà en charge le mode d’étiquette de premier saut de résolution d’un LSP. Toutefois, le mode IP de premier saut n’est pas pris en charge pour les LSP de routage de segments colorés. À partir de Junos OS version 19.1R1, une fonctionnalité de vérification de validation est introduite pour garantir que toutes les listes de segments contribuant aux routes colorées ont l’étiquette minimale présente pour tous les sauts. Si cette condition n’est pas remplie, la validation est bloquée.
LSP de routage de segments statique non coloré
Un LSP de routage de segment statique configuré sans l’instruction color
est un LSP non coloré. Comme pour les tunnels de routage de segments PCEP, la route d’entrée est installée dans les tables de inet.3
routage ou inet6.3
.
Junos OS prend en charge les LSP de routage de segments statiques non colorés sur les routeurs entrants. Vous pouvez provisionner un LSP de routage de segments statique non coloré en configurant un chemin d’accès routé source et une ou plusieurs listes de segments. Ces listes de segments peuvent être utilisées par plusieurs LSP de routage de segments non colorés.
- Comprendre les LSP Segment Routing non colorés
- Liste de segments des LSP Segment Routing non colorés
Comprendre les LSP Segment Routing non colorés
Le LSP de routage de segments non coloré possède un nom unique et une adresse IP de destination. Une route entrante vers la destination est installée dans la table de routage inet.3 avec une préférence par défaut de 8 et une métrique de 1. Cette route permet de mapper des services non colorés au LSP de routage de segment correspondant à la destination. Dans le cas où le LSP de routage de segments non coloré ne nécessite pas de route d’entrée, la route d’entrée peut être désactivée. Un LSP de routage de segments non coloré utilise une étiquette SID de liaison pour réaliser l’assemblage LSP de routage de segments. Cette étiquette peut être utilisée pour modéliser le LSP de routage de segments en tant que segment qui peut être utilisé pour construire d’autres LSP de routage de segments de manière hiérarchique. Le transit de l’étiquette SID de liaison, par défaut, a une préférence de 8 et une métrique de 1.
À compter de Junos OS version 18.2R1, les LSP de routage de segments non colorés configurés statiquement sur le périphérique entrant sont signalés à l’élément de calcul de chemin (PCE) par le biais d’une session PCEP (Path Computation Element Protocol). Ces LSP de routage de segments non colorés peuvent être associés à des étiquettes d’identificateur de service de liaison (SID). Grâce à cette fonctionnalité, le PCE peut utiliser cette étiquette SID de liaison dans la pile d’étiquettes pour provisionner des chemins LSP de routage de segments initiés par PCE.
Un LSP de routage de segments non coloré peut avoir un maximum de 8 chemins principaux. S’il existe plusieurs chemins principaux opérationnels, le moteur de transfert de paquets (PFE) répartit le trafic sur les chemins en fonction des facteurs d’équilibrage de charge, tels que le poids configuré sur le chemin. Il s’agit d’un chemin multiple à coût égal (ECMP) si aucun des chemins n’a une pondération configurée ou d’un ECMP pondéré si au moins l’un des chemins a une pondération différente de zéro configurée sur les chemins. Dans les deux cas, lorsqu’un ou plusieurs des chemins tombent en panne, le PFE rééquilibre le trafic sur les chemins restants, ce qui conduit automatiquement à la mise en place d’une protection des chemins. Un LSP de routage de segments non coloré peut avoir un chemin secondaire pour une protection de chemin dédiée. En cas de défaillance d’un chemin principal, le PFE rééquilibre le trafic vers les chemins principaux fonctionnels restants. Dans le cas contraire, le PFE bascule le trafic vers le chemin de secours, assurant ainsi la protection du chemin. Un LSP de routage de segment non coloré peut spécifier une métrique at [edit protocols source-packet-routing source-routing-path lsp-name]
pour ses routes SID d’entrée et de liaison. Plusieurs LSP de routage de segments non colorés ont la même adresse de destination, ce qui contribue au saut suivant de la route d’entrée.
Plusieurs LSP de routage de segments non colorés ont la même adresse de destination, ce qui contribue au saut suivant de la route d’entrée. Chaque chemin, qu’il soit primaire ou secondaire, de chaque LSP de routage de segments est considéré comme un candidat de passerelle, si le chemin est fonctionnel et que le LSP de routage de segments a la meilleure préférence de tous ces LSP de routage de segments. Toutefois, le nombre maximal de passerelles pouvant contenir le tronçon suivant ne peut pas dépasser la limite de chemins multiples du RPD, qui est de 128 par défaut. Les chemins supplémentaires sont élagués, d’abord les chemins secondaires, puis les chemins principaux. Une liste de segments donnée peut être désignée plusieurs fois en tant que chemins principaux ou secondaires par ces LSP de routage de segments. Dans ce cas, il existe plusieurs passerelles, chacune ayant un ID de tunnel LSP de routage de segment unique. Ces passerelles sont distinctes, bien qu’elles aient une pile d’étiquettes sortante et une interface identiques. Un LSP de routage de segments non coloré et un LSP de routage de segments colorés peuvent également avoir la même adresse de destination. Cependant, ils correspondent à des adresses de destination différentes pour les routes entrantes, car l’adresse de destination du LSP de routage de segment coloré est construite avec son adresse de destination et sa couleur.
Dans le cas où un LSP de routage de segments statique non coloré et un LSP de routage de segments créé par PCEP coexistent et ont le même adressage qui contribue à la même route d’entrée, s’ils ont également la même préférence. Dans le cas contraire, le LSP de routage de segments avec la meilleure préférence est installé pour la route.
Liste de segments des LSP Segment Routing non colorés
Une liste de segments est constituée d’une liste de sauts. Ces sauts sont basés sur l’étiquette SID ou une adresse IP. Le nombre d’étiquettes SID dans la liste de segments ne doit pas dépasser la limite maximale de la liste de segments. Le nombre maximal de liaisons de liste de segments à un tunnel LSP passe de 8 à 128, avec un maximum de 1000 tunnels par système. Un maximum de 128 chemins principaux sont pris en charge par LSP de routage de segments statique. Vous pouvez configurer la limite maximale de la liste de segments au niveau de la [edit protocols source-packet-routing]
hiérarchie.
Avant Junos OS version 19.1R1, pour qu’un LSP de routage de segments statique non coloré soit utilisable, le premier saut de la liste de segments devait être l’adresse IP d’une interface sortante et l’avant-dernier ndevait être des étiquettes SID. À partir de Junos OS version 19.1R1, cette exigence ne s’applique plus, car le premier saut des LSP statiques non colorés prend désormais en charge les étiquettes SID, en plus des adresses IP. Avec la prise en charge de la première étiquette de saut, le reroutage rapide MPLS (FRR) et le multichemin multi-coût pondéré sont activés pour résoudre les LSP de routage de segments statiques non colorés, similaires aux LSP statiques statiques.
Pour que le mode d’étiquette du premier saut soit effectif, vous devez inclure l’instruction globalement ou individuellement pour une liste de segments, et le premier saut de la liste de segments doit inclure à la fois l’adresse IP et l’étiquette inherit-label-nexthops
. Si le premier saut inclut uniquement l’adresse IP, l’instruction n’a inherit-label-nexthops
aucun effet.
Vous pouvez configurer inherit-label-nexthops
l’une des hiérarchies suivantes. L’instruction inherit-label-nexthops
ne prend effet que si le premier saut de la liste de segments inclut à la fois l’adresse IP et l’étiquette.
-
Segment list level: au niveau de la
[edit protocols source-packet-routing segment-list segment-list-name]
hiérarchie. -
Globally: au niveau de la
[edit protocols source-packet-routing]
hiérarchie.
Lorsque l’instruction inherit-label-nexthops
est configurée globalement, elle est prioritaire sur la configuration au niveau de la liste de segments et la inherit-label-nexthops
configuration est appliquée à toutes les listes de segments. Lorsque l’instruction n’est pas configurée globalement, seules les listes de segments avec des étiquettes et une adresse IP présentes dans le premier saut et configurées avec inherit-label-nexthops
une instruction sont résolues à l’aide d’étiquettes inherit-label-nexthops
SID.
Pour les LSP statiques dynamiques non colorés, c’est-à-dire les LSP de routage de segments pilotés par PCEP, l’instruction doit être activée globalement, car la configuration au niveau du segment n’est inherit-label-nexthops
pas appliquée.
Tableau 4 décrit le mode de résolution LSP du routage de segments en fonction de la spécification du premier saut.
Spécification du premier saut |
Mode de résolution LSP |
---|---|
Adresse IP uniquement Par exemple : segment-list path-1 { hop-1 ip-address 172.16.12.2; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } |
La liste des segments est résolue à l’aide de l’adresse IP. |
SID uniquement Par exemple : segment-list path-2 { hop-1 label 1000011; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } |
La liste des segments est résolue à l’aide d’étiquettes SID. |
Adresse IP et SID (sans la Par exemple : segment-list path-3 { hop1 { label 801006; ip-address 172.16.1.2; } hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } |
Par défaut, la liste des segments est résolue à l’aide de l’adresse IP. |
Adresse IP et SID (avec la Par exemple : segment-list path-3 { inherit-label-nexthops; hop1 { label 801006; ip-address 172.16.1.2; } hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } |
La liste des segments est résolue à l’aide d’étiquettes SID. |
Vous pouvez utiliser la commande pour afficher les LSP d’ingénierie de trafic de routage de segments non colorés ayant plusieurs listes de segments installées dans la show route ip-address protocol spring-te active-path table inet.3
table de routage inet.3.
Par exemple :
user@host> show route 10.7.7.7 protocol spring-te active-path table inet.3 inet.3: 42 destinations, 59 routes (41 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 10.7.7.7/32 *[SPRING-TE/8] 00:01:25, metric 1, metric2 0 > to 10.11.1.2 via et-0/0/0.1, Push 801007 to 10.21.1.2 via et-0/0/2.1, Push 801007 to 10.102.1.2 via et-0/0/0.2, Push 801007, Push 801002(top) to 10.21.1.2 via et-0/0/2.2, Push 801007, Push 801005(top) to 10.103.1.2 via et-0/0/0.3, Push 801007, Push 801003(top) to 10.203.1.2 via et-0/0/2.3, Push 801007, Push 801006(top) to 10.104.1.2 via et-0/0/0.4, Push 801007, Push 801003, Push 801002(top) to 10.204.1.2 via et-0/0/2.4, Push 801007, Push 801006, Push 801005(top)
Le premier type de saut des listes de segments d’un LSP de routage de segments statique peut entraîner l’échec d’une validation, si :
-
Les différentes listes de segments d’un tunnel ont différents types de résolution de premier saut. Cela s’applique aux LSP de routage de segments statiques colorés et non colorés. Toutefois, cela ne s’applique pas aux prestataires de services linguistiques pilotés par le PCEP ; Un message du journal système est généré pour l’incompatibilité dans le type de résolution du premier saut au moment du calcul du chemin.
Par exemple :
segment-list path-1 { hop-1 ip-address 172.16.12.2; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } segment-list path-2 { hop-1 label 1000011; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } source-routing-path lsp1 { to 172.16.10.1; primary { path-1; path-2; } }
La validation du tunnel lsp1 échoue, car le chemin 1 est en mode adresse IP et le chemin 2 est en mode étiquette.
-
Le SID de liaison est activé pour le LSP statique non coloré dont le type de liste de segments est l’étiquette SID.
Par exemple :
segment-list path-3 { hop-1 label 1000011; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } source-routing-path lsp1 { to 172.16.10.1; binding-sid 333; primary { path-3; } }
La configuration de la liaison SID sur la liste des segments d’étiquette n’est prise en charge que pour les LSP statiques colorés et non pour les LSP statiques non colorés.
Provisionnement LSP de segment routing statique
Le provisionnement des segments s’effectue pour chaque routeur. Pour un segment donné sur un routeur, une étiquette d’identifiant de service unique (SID) est allouée à partir d’un pool d’étiquettes souhaité, qui peut provenir du pool d’étiquettes dynamique pour une étiquette SID d’adjacence ou du bloc global de routage de segments (SRGB) pour un SID de préfixe ou un SID de nud. L’étiquette SID d’adjacence peut être allouée dynamiquement, ce qui est le comportement par défaut, ou être allouée à partir d’un pool d’étiquettes statiques local (SRLB). Une route pour l’étiquette SID est ensuite installée dans la table mpls.0.
Junos OS autorise les LSP de routage de segments statiques en configurant l’instruction segment
au niveau de la [edit protocols mpls static-label-switched-path static-label-switched-path]
hiérarchie. Un LSP de segment statique est identifié par une étiquette SID unique qui relève du pool d’étiquettes statiques Junos OS. Vous pouvez configurer le pool d’étiquettes statiques Junos OS en configurant l’instruction static-label-range static-label-range
au niveau de la [edit protocols mpls label-range]
hiérarchie.
Static Segment Routing LSP Limitations
-
Junos OS a actuellement une limitation selon laquelle le saut suivant ne peut pas être construit pour pousser plus que les étiquettes de profondeur de liste de segments maximales. Ainsi, une liste de segments avec plus d’étiquettes SID que le nombre maximal d’étiquettes (à l’exception de l’étiquette SID du premier saut qui est utilisée pour résoudre le transfert du saut suivant) n’est pas utilisable pour les LSP de routage de segments colorés ou non colorés. En outre, le nombre réel autorisé pour un LSP de routage de segment donné peut être même inférieur à la limite maximale, si un service MPLS se trouve sur le LSP de routage de segment ou si le LSP de routage de segment se trouve sur un chemin de protection de liaison ou de nud. Dans tous les cas, le nombre total d’étiquettes de service, d’étiquettes SID et d’étiquettes de protection de lien ou de nœud ne doit pas dépasser la profondeur maximale de la liste de segments. Vous pouvez configurer la limite maximale de la liste de segments au
[edit protocols source-packet-routing]
niveau de la hiérarchie. Plusieurs LSP de routage de segments non colorés avec des étiquettes SID inférieures ou égales au maximum peuvent être assemblés pour construire un LSP de routage de segments plus long. C’est ce qu’on appelle l’assemblage LSP avec routage de segments. Il peut être réalisé à l’aide d’une étiquette Binding-SID. -
L’assemblage LSP de routage de segments s’effectue en fait au niveau du chemin. Si un LSP de routage de segments non coloré comporte plusieurs chemins, c’est-à-dire plusieurs listes de segments, chaque chemin peut être assemblé indépendamment à un autre LSP de routage de segments non coloré à un point d’assemblage. Un LSP de routage de segments non coloré qui est dédié à l’assemblage peut désactiver l’installation de la route d’entrée en configurant
no-ingress
l’instruction au[edit protocols source-packet-routing source-routing-path lsp-name]
niveau de la hiérarchie. -
Un maximum de 128 chemins principaux et 1 chemin secondaire sont pris en charge par LSP de routage de segments statique non coloré. En cas de violation de la configuration, la vérification de validation échoue avec une erreur.
-
Le nombre maximal de liaisons de liste de segments à un tunnel LSP passe de 8 à 128, avec un maximum de 1000 tunnels par système. Un maximum de 128 chemins principaux sont pris en charge par LSP de routage de segments statique. À titre de limitation, la prise en charge maximale du capteur pour le chemin LSP est de 32000 uniquement.
-
Si une liste de segments est configurée avec plus d’étiquettes que la profondeur maximale de la liste de segments, la vérification de validation de la configuration échoue avec une erreur.
Création dynamique de LSP de Segment Routing
Dans les réseaux de routage de segments où chaque périphérique Provider Edge (PE) est connecté à tous les autres périphériques PE, la configuration des chemins de commutation d’étiquettes (LSP) de segment routing nécessite une grande quantité de configuration, bien que seuls quelques chemins SR-TE (Segment Routing Traffic-Engineered Paths) puissent être utilisés. Vous pouvez activer la création dynamique de ces LSP avec BGP pour réduire la quantité de configuration dans de tels déploiements.
- Configuration du modèle LSP de routage de segments dynamique
- Résolution des prestataires de services linguistiques à Segment Routing dynamique
- Considérations relatives à la configuration de la création dynamique de LSP de segment routing
- Services pris en charge sur les LSP de Segment Routing dynamique
- Comportement avec plusieurs sources de tunnel dans le segment routing
- Limites des LSP de Segment Routing dynamique
Configuration du modèle LSP de routage de segments dynamique
Pour configurer le modèle permettant la création dynamique de LSP de routage de segments, vous devez inclure l’instruction spring-te dans la [edit routing-options dynamic-tunnels]
hiérarchie.
-
Voici un exemple de configuration pour le modèle LSP de routage de segments dynamiques couleur :
[edit routing-options] dynamic-tunnels { <dynamic-tunnel-name> { spring-te { source-routing-path-template { <template-name1> color [c1 c2]; <template-name2> color [c3]; <template-name3> color-any; } destination-networks { <dest1>; <dest2>; } } } }
-
Voici un exemple de configuration pour le modèle LSP de routage de segments dynamiques sans couleur :
dynamic-tunnels { <dynamic-tunnel-name> { spring-te { source-routing-path-template { <template-name1>; } destination-networks { <dest1>; <dest2>; } } } }
Résolution des prestataires de services linguistiques à Segment Routing dynamique
Résolution du LSP de routage dynamique de segments coloré
Lorsque les préfixes BGP sont affectés à la communauté de couleurs, ils sont d’abord résolus via la stratégie catch-all-route-for-that-particular-color et, à son tour, le modèle SR-TE sur lequel le préfixe BGP doit être résolu est identifié. Le SID de destination est ensuite dérivé de l’attribut next-hop du préfixe de charge utile BGP. Par exemple, si le tronçon suivant du préfixe de la charge utile BGP est une adresse IP appartenant à l’appareil A, le nœud SID de l’appareil A est pris et une étiquette correspondante est préparée et envoyée au bas de la pile. Le préfixe de la charge utile BGP est résolu en mode couleur uniquement, où le nœud SID de l’appareil A se trouve en bas de la pile d’étiquettes finale et les étiquettes de chemin SR-TE en haut.
Le nom final du modèle LSP est une combinaison de préfixe, de couleur et de nom de tunnel ; Par exemple, <prefix>:<color>:dt-srte-<tunnel-name>
. La couleur du nom LSP est affichée au format hexadécimal et le format du nom du tunnel est similaire à celui des noms LSP de tunnel déclenchés par RSVP.
Pour résoudre correctement un réseau de destination coloré, la couleur doit avoir un mappage de modèle valide, soit vers une couleur spécifique, soit via le color-any
modèle. Sans mappage valide, le tunnel n’est pas créé et la route BGP demandant une résolution reste non résolue.
Résolution des LSP de routage de segments dynamiques non colorés
Les routes fourre-tout pour les LSP non colorés sont ajoutées à la table de routage inet.3. La destination de tunnel non colorée doit être configurée dans une configuration différente spring-te
avec un seul nom de modèle dans la liste de mappage. Ce nom de modèle est utilisé pour tous les itinéraires de tunnel correspondant à l’un des réseaux de destination configurés sous la même spring-te
configuration. Ces tunnels sont similaires aux tunnels RSVP en termes de fonctionnalités.
Le nom final du modèle LSP est une combinaison de préfixe et de nom de tunnel ; Par exemple, <prefix>:dt-srte-<tunnel-name>
.
Exemple de configuration LSP de segment routing dynamique
Le modèle LSP de routage de segments dynamique comporte toujours un chemin partiel. Le SID du dernier nœud de saut est dérivé automatiquement au moment de la création du tunnel, en fonction du SID du nœud PNH (Protocol Next-Hop Address). Un même modèle peut être utilisé par plusieurs tunnels vers des destinations différentes. Dans ce cas, le chemin partiel reste le même, et seul le dernier saut change en fonction de l’HPN. Les modèles LSP de routage de segments dynamiques ne sont pas communs à un seul tunnel, par conséquent, un chemin complet ne peut pas être transporté sur celui-ci. Vous pouvez utiliser une liste de segments si un chemin complet doit être utilisé.
LSP Segment Routing dynamiques colorés
Exemple de configuration pour les LSP de routage de segments dynamiques colorés :
protocols source-packet-routing { source-routing-path-template sr_lsp1 { primary sr_sl1 primary sr_sl2 weight 2 sr-preference 180; } } dynamic-tunnels tunnel1 { spring-te { source-routing-path-template { sr_lsp1 color [101 124]; sr_lsp2 color-any } destination-networks { 10.22.44.0/24; } } }
Pour l’exemple de configuration mentionné ci-dessus, les entrées de route sont les suivantes :
-
inetcolor.0 tunnel route: 10.22.44.0-0/24 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping:
R1(préfixe) -> 10.22.44.55-101(PNH) Nom du tunnel LSP = 10.22.44.55 :65 :dt-srte-tunnel1
-
inetcolor.0 tunnel route:
10.22.44.55-101/64 --> <next-hop>
10.22.44.55-124/64 --> <next-hop>
LSP de routage de segments dynamiques non colorés
Exemple de configuration pour les LSP de routage de segments dynamiques non colorés :
protocols source-packet-routing { source-routing-path-template sr_lsp1 { primary sr_sl1 primary sr_sl2 weight 2 sr-preference 180; } } dynamic-tunnels { tunnel1 { spring-te { source-routing-path-template { sr_lsp1 color; } destination-networks { 10.33.44.0/24; } } } tunnel2 { spring-te { source-routing-path-template { sr_lsp1; } destination-networks { 10.33.44.0/24; } } } }
Pour l’exemple de configuration mentionné ci-dessus, les entrées de route sont les suivantes :
-
inet.3 tunnel route: 10.33.44.0/24 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping:
R1(préfixe) -> 10.33.44.55(PNH) Nom du modèle LSP = LSP1 --- 10.33.44.55 :dt-srte-tunnel2
-
inet.3 tunnel route: 10.33.44.55/32 --> <next-hop>
LSP Segment Routing dynamique non résolu
Exemple de configuration pour les LSP de routage de segments dynamiques non résolus :
protocols source-packet-routing { source-routing-path-template sr_lsp1 { primary sr_sl1 primary sr_sl2 weight 2 sr-preference 180; } } dynamic-tunnels tunnel1 { spring-te { source-routing-path-template { sr_lsp1 color [120 121 122 123]; } destination-networks { 10.33.44.0/24; 10.1.1.0/24; } } }
Pour l’exemple de configuration mentionné ci-dessus, les entrées de route sont les suivantes :
-
inetcolor.0 tunnel route: 10.33.44.0 - 0/24 --> RT_NH_TUNNEL 10.1.1.0 - 0 /24 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping: R1(préfixe) -> Le tunnel 10.33.44.55-124(PNH) ne sera pas créé. (Modèle introuvable pour la couleur).
Considérations relatives à la configuration de la création dynamique de LSP de segment routing
Lors de la configuration de la création dynamique de LSP de routage de segments, tenez compte des éléments suivants :
-
Un modèle peut être associé à un objet de couleur. Lorsque la configuration du tunnel
spring-te
dynamique inclut un modèle avec un objet de couleur, vous devez également configurer tous les autres modèles avec des objets de couleur. Toutes les destinations sont supposées être colorées dans cette configuration. -
Un modèle peut avoir une liste de couleurs définies dessus, ou peut être configuré avec l’option
color-any
. Ces deux options peuvent coexister dans la mêmespring-te
configuration. Dans de tels cas, les modèles attribués avec des couleurs spécifiques ont une préférence plus élevée. -
Dans une
spring-te
configuration, un seul modèle peut être défini avec l’optioncolor-any
. -
Le mappage couleur-modèle est effectué sur une base individuelle. Une couleur ne peut pas être mappée à plusieurs modèles.
-
Le nom du modèle doit être configuré dans l’instruction sous la
[edit protocols]
hiérarchie et l’optionspring-te
primary
doit être activée. -
Les destinations colorées et non colorées ne peuvent pas coexister dans la même
spring-te
configuration. -
Vous ne pouvez pas configurer les mêmes réseaux de destination, avec ou sans couleur, sous des instructions de configuration différentes
spring-te
. -
Dans une configuration non colorée
spring-te
, un seul modèle peut être configuré sans objet de couleur.
Services pris en charge sur les LSP de Segment Routing dynamique
Les services suivants sont pris en charge par les LSP de routage de segments dynamiques colorés :
-
VPN de couche 3
-
BGP EVPN
-
Services de stratégie d’exportation
Les services suivants sont pris en charge sur les LSP de routage de segments dynamiques non colorés :
-
VPN de couche 3
-
VPN de couche 2
-
Configurations à chemins multiples
Comportement avec plusieurs sources de tunnel dans le segment routing
Lorsque deux sources téléchargent des routes vers la même destination à partir du routage de segments (par exemple, des tunnels sources statiques et dynamiques), la préférence de routage de segments est utilisée pour choisir l’entrée de route active. Plus la valeur est élevée, plus la préférence est grande. Si la préférence reste la même, la source du tunnel est utilisée pour déterminer l’entrée de route.
Limites des LSP de Segment Routing dynamique
Les LSP dynamiques SR-TE ne prennent pas en charge les caractéristiques et fonctionnalités suivantes :
-
Tunnels de routage de segments IPv6.
-
Tunnels statiques.
-
6PE n’est pas pris en charge.
-
CSPF distribué.
-
La tunnelisation sBFD et LDP n’est pas prise en charge pour les LSP SR-TE dynamiques et dans un modèle.
-
Installez les routes et les routes B-SID dans un modèle.
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 SR-TE
- 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.
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 dernière couleur attachée 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 vrf-export
de routage , l’exportation de groupe ou l’exportation de voisin de groupe du service VPN au niveau de la [edit protocols bgp]
hiérarchie. 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 routing-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 et faire référence à la stratégie dans l’instance vrf-import
de routage , l’importation de groupe ou l’importation resolution-map
de voisin de groupe d’un 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 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 de couleur IP est prise en charge dans la carte de résolution, où la ou les routes VPN sont résolues à l’aide d’un saut suivant de protocole IP coloré sous la forme .ip-address:color
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 , et résout le prochain saut de protocole dans la table de IP-address:colorroutage 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 SR-TE
À partir de Junos OS version 20.2R1, BGP Labeled Unicast (BGP-LU) peut résoudre les routes IPv4 ou IPv6 via Segment Routing–Traffic Engineering (SR-TE) 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
. BGP utilise inet.3
des tables et inet6.3
pour le mappage non basé sur les couleurs. Cela vous permet de publier des préfixes IPv6 et IPv4 BGP-LU avec une adresse de saut alternatif IPv6 dans les réseaux IPv6 uniquement où aucune adresse IPv4 n’est configurée pour les routeurs. Grâce à cette fonctionnalité, nous prenons actuellement en charge BGP IPv6 LU sur SR-TE avec sous-couche IS-IS.
En Figure 9, le contrôleur configure 4 tunnels colorés dans un réseau central IPv6 configuré avec SR-TE. Chaque tunnel coloré emprunte un chemin différent vers le routeur de destination D en fonction de la carte de résolution définie. Le contrôleur configure un tunnel SR-TE coloré vers l’interface 2001 :db8 ::3701 :2d05 dans le routeur D. BGP importe des stratégies pour affecter une carte de couleurs et de résolution au préfixe reçu 2001 :db8 ::3700 :6/128. En fonction de la couleur de la communauté attribuée, BGP-LU résout le saut suivant coloré pour le préfixe LU IPv6 BGP en fonction de la stratégie de mappage de résolution attribuée.
BGP-LU prend en charge les scénarios suivants :
-
BGP IPv4 LU sur BGP IPv4 SR-TE coloré, avec extensions ISIS/OSPF IPv4 SR.
-
LU IPv4 BGP sur SR-TE IPv4 statique coloré et non coloré, avec extensions ISIS/OSPF IPv4 SR.
-
BGP IPv6 LU sur BGP IPv6 SR-TE coloré, avec extensions ISIS IPv6 SR.
-
LU BGP IPv6 sur SR-TE IPv6 statique coloré et non coloré, avec extensions ISIS IPv6 SR.
-
Services VPN de couche 3 IPv6 avec adresse locale IPv6 et adresse voisine IPv6.
-
Services VPN IPv6 de couche 3 sur BGP IPv6 SR-TE, avec extensions ISIS IPv6 SR.
-
Services VPN IPv6 de couche 3 sur SR-TE IPv6 statique et non coloré, avec extensions ISIS IPv6 SR.
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 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 la table de routage inetcolor.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.
Modèles de tunnel pour les prestataires de services linguistiques Segment Routing initiés par PCE
Vous pouvez configurer un modèle de tunnel pour les LSP de routage de segments initiés par PCE afin de leur transmettre deux paramètres supplémentaires : la détection de transfert bidirectionnel (BFD) et la tunnelisation LDP.
Lorsqu’un LSP de routage de segments initié par PCE est créé, il est vérifié par rapport aux instructions de stratégie (le cas échéant) et, s’il existe une correspondance, la stratégie applique le modèle configuré pour ce LSP. La configuration du modèle n’est héritée que si elle n’est pas fournie par la source LSP (PCEP) ; par exemple, métrique.
Pour configurer un modèle :
-
Incluez l’instruction source-routing-path-template au niveau de la
[edit protocols source-packet-routing]
hiérarchie. Vous pouvez configurer les paramètres de tunnelisation BFD et LDP supplémentaires ici. -
Incluez l’instruction source-routing-path-template-map au niveau de la hiérarchie pour répertorier les instructions de
[edit protocols source-packet-routing]
stratégie par rapport auxquelles le LSP initié par PCE doit être vérifié. -
Définissez une stratégie pour répertorier les prestataires de services linguistiques sur lesquels le modèle doit être appliqué.
L’instruction
from
peut inclure le nom LSP ou l’expression régulière LSP à l’aide des conditions delsp
correspondance etlsp-regex
. Ces options s’excluent mutuellement, de sorte que vous ne pouvez spécifier qu’une seule option à un moment donné.L’instruction
then
doit inclure l’option avec une action d’acceptationsr-te-template
. Le modèle s’applique alors au prestataire de services linguistiques initié par PCE.
Tenez compte des éléments suivants lors de la configuration d’un modèle pour les prestataires de services linguistiques initiés par PCE :
-
La configuration du modèle ne s’applique pas aux LSP de routage de segments configurés de manière statique, ni aux LSP de routage de segments d’un autre client.
-
La configuration fournie par PCEP est prioritaire sur la configuration du modèle.
-
PCEP LSP n’hérite pas de la configuration de liste de segments de modèle.
Exemple : configuration du chemin de commutation d’étiquette de segment routing statique
Cet exemple montre comment configurer les chemins de commutation d’étiquettes de routage de segments statiques (LSP) dans les réseaux MPLS. Cette configuration permet d’apporter une plus grande évolutivité aux réseaux MPLS.
Conditions préalables
Cet exemple utilise les composants matériels et logiciels suivants :
-
Sept plates-formes de routage universelles 5G MX Series
-
Junos OS version 18.1 ou ultérieure s’exécutant sur tous les routeurs
Avant de commencer, assurez-vous de configurer les interfaces de l’appareil.
Présentation
Junos OS, un ensemble de chemins de routage de segments explicites, est configuré sur le routeur entrant d’un tunnel de routage de segments statique non coloré en configurant l’instruction segment-list
au niveau de la [edit protocols source-packet-routing]
hiérarchie. Vous pouvez configurer le tunnel de routage de segments en configurant l’instruction au [edit protocols source-packet-routing]
niveau de la source-routing-path
hiérarchie. Le tunnel de routage de segments dispose d’une adresse de destination et d’un ou plusieurs chemins principaux et, éventuellement, de chemins secondaires qui font référence à la liste des segments. Chaque liste de segments se compose d’une séquence de sauts. Pour les tunnels de routage de segments statiques non colorés, le premier saut de la liste des segments spécifie une adresse IP de saut suivant immédiat et le second jusqu’au Nième saut spécifie les étiquettes d’identification de segment (SID) correspondant au lien ou au nœud traversé par le chemin. La route vers la destination du tunnel de routage de segments est installée dans la table inet.3.
Topologie
Dans cet exemple, configurez le VPN de couche 3 sur les routeurs de périphérie PE1 et PE5. Configurez le protocole MPLS sur tous les routeurs. Le tunnel de routage de segments est configuré du routeur PE1 au routeur PE5 avec un chemin principal configuré sur les routeurs PE1 et PE5 . Le routeur PE1 est également configuré avec un chemin secondaire pour la protection des chemins. Les routeurs de transit PE2 à PE4 sont configurés avec des étiquettes SID d’adjacence avec étiquette pop et une interface sortante.
Configuration
- Configuration rapide de l’interface de ligne de commande
- Configuration de l’équipement PE1
- Configuration de l’équipement PE2
- Résultats
Configuration rapide de l’interface de ligne de commande
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, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit]
hiérarchie, puis passez commit
en mode de configuration.
PE1
set interfaces ge-0/0/0 unit 0 family inet address 10.10.12.1/24 set interfaces ge-0/0/0 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/1 unit 0 family inet address 10.10.13.1/24 set interfaces ge-0/0/1 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/5 unit 0 family inet address 10.10.17.1/24 set routing-options autonomous-system 65000 set routing-options forwarding-table export load-balance-policy set routing-options forwarding-table chained-composite-next-hop ingress l3vpn set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols bgp group pe type internal set protocols bgp group pe local-address 192.168.147.211 set protocols bgp group pe family inet-vpn unicast set protocols bgp group pe neighbor 192.168.146.181 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols source-packet-routing segment-list sl-15-primary hop-1 ip-address 10.10.13.3 set protocols source-packet-routing segment-list sl-15-primary hop-2 label 1000134 set protocols source-packet-routing segment-list sl-15-primary hop-3 label 1000145 set protocols source-packet-routing segment-list sl-15-backup hop-1 ip-address 10.10.12.2 set protocols source-packet-routing segment-list sl-15-backup hop-2 label 1000123 set protocols source-packet-routing segment-list sl-15-backup hop-3 label 1000134 set protocols source-packet-routing segment-list sl-15-backup hop-4 label 1000145 set protocols source-packet-routing source-routing-path lsp-15 to 192.168.146.181 set protocols source-packet-routing source-routing-path lsp-15 binding-sid 1000999 set protocols source-packet-routing source-routing-path lsp-15 primary sl-15-primary set protocols source-packet-routing source-routing-path lsp-15 secondary sl-15-backup set policy-options policy-statement VPN-A-export term a from protocol ospf set policy-options policy-statement VPN-A-export term a from protocol direct set policy-options policy-statement VPN-A-export term a then community add VPN-A set policy-options policy-statement VPN-A-export term a then accept set policy-options policy-statement VPN-A-export term b then reject set policy-options policy-statement VPN-A-import term a from protocol bgp set policy-options policy-statement VPN-A-import term a from community VPN-A set policy-options policy-statement VPN-A-import term a then accept set policy-options policy-statement VPN-A-import term b then reject set policy-options policy-statement bgp-to-ospf from protocol bgp set policy-options policy-statement bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set policy-options policy-statement bgp-to-ospf then accept set policy-options policy-statement load-balance-policy then load-balance per-packet set policy-options community VPN-A members target:65000:1 set routing-instances VRF1 instance-type vrf set routing-instances VRF1 interface ge-0/0/5.0 set routing-instances VRF1 route-distinguisher 192.168.147.211:1 set routing-instances VRF1 vrf-import VPN-A-import set routing-instances VRF1 vrf-export VPN-A-export set routing-instances VRF1 vrf-table-label set routing-instances VRF1 protocols ospf export bgp-to-ospf set routing-instances VRF1 protocols ospf area 0.0.0.0 interface ge-0/0/5.0
PE2
set interfaces ge-0/0/0 unit 0 family inet address 10.10.12.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.10.23.2/24 set interfaces ge-0/0/1 unit 0 family mpls set protocols mpls static-label-switched-path adj-23 segment 1000123 set protocols mpls static-label-switched-path adj-23 segment next-hop 10.10.23.3 set protocols mpls static-label-switched-path adj-23 segment pop set protocols mpls static-label-switched-path adj-21 segment 1000221 set protocols mpls static-label-switched-path adj-21 segment next-hop 10.10.12.1 set protocols mpls static-label-switched-path adj-21 segment pop set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols mpls label-range static-label-range 1000000 1000999 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
PE3
set interfaces ge-0/0/0 unit 0 family inet address 10.10.13.3/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.10.23.3/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 10.10.34.3/24 set interfaces ge-0/0/2 unit 0 family mpls set protocols mpls static-label-switched-path adj-34 segment 1000134 set protocols mpls static-label-switched-path adj-34 segment next-hop 10.10.34.4 set protocols mpls static-label-switched-path adj-34 segment pop set protocols mpls static-label-switched-path adj-32 segment 1000232 set protocols mpls static-label-switched-path adj-32 segment next-hop 10.10.23.2 set protocols mpls static-label-switched-path adj-32 segment pop set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols mpls label-range static-label-range 1000000 1000999 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/0.0
PE4
set interfaces ge-0/0/2 unit 0 family inet address 10.10.34.4/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 10.10.45.4/24 set interfaces ge-0/0/3 unit 0 family mpls set protocols mpls static-label-switched-path adj-45 segment 1000145 set protocols mpls static-label-switched-path adj-45 segment next-hop 10.10.45.5 set protocols mpls static-label-switched-path adj-45 segment pop set protocols mpls static-label-switched-path adj-43 segment 1000243 set protocols mpls static-label-switched-path adj-43 segment next-hop 10.10.34.3 set protocols mpls static-label-switched-path adj-43 segment pop set protocols mpls interface ge-0/0/2.0 set protocols mpls interface ge-0/0/3.0 set protocols mpls label-range static-label-range 1000000 1000999 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
PE5
set interfaces ge-0/0/3 unit 0 family inet address 10.10.45.5/24 set interfaces ge-0/0/3 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/4 unit 0 family inet address 10.10.56.5/24 set routing-options autonomous-system 65000 set protocols mpls interface ge-0/0/3.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols bgp group pe type internal set protocols bgp group pe local-address 192.168.146.181 set protocols bgp group pe family inet-vpn unicast set protocols bgp group pe neighbor 192.168.147.211 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols bfd sbfd local-discriminator 0.0.0.32 minimum-receive-interval 1000 set protocols source-packet-routing segment-list sl-51 hop-1 ip-address 10.10.45.4 set protocols source-packet-routing segment-list sl-51 hop-2 label 1000243 set protocols source-packet-routing segment-list sl-51 hop-3 label 1000232 set protocols source-packet-routing segment-list sl-51 hop-4 label 1000221 set protocols source-packet-routing source-routing-path lsp-51 to 192.168.147.211 set protocols source-packet-routing source-routing-path lsp-51 primary sl-51 set policy-options policy-statement VPN-A-export term a from protocol ospf set policy-options policy-statement VPN-A-export term a from protocol direct set policy-options policy-statement VPN-A-export term a then community add VPN-A set policy-options policy-statement VPN-A-export term a then accept set policy-options policy-statement VPN-A-export term b then reject set policy-options policy-statement VPN-A-import term a from protocol bgp set policy-options policy-statement VPN-A-import term a from community VPN-A set policy-options policy-statement VPN-A-import term a then accept set policy-options policy-statement VPN-A-import term b then reject set policy-options policy-statement bgp-to-ospf from protocol bgp set policy-options policy-statement bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set policy-options policy-statement bgp-to-ospf then accept set policy-options community VPN-A members target:65000:1 set routing-instances VRF1 instance-type vrf set routing-instances VRF1 interface ge-0/0/4.0 set routing-instances VRF1 route-distinguisher 192.168.146.181:1 set routing-instances VRF1 vrf-import VPN-A-import set routing-instances VRF1 vrf-export VPN-A-export set routing-instances VRF1 vrf-table-label set routing-instances VRF1 protocols ospf export bgp-to-ospf set routing-instances VRF1 protocols ospf area 0.0.0.0 interface ge-0/0/4.0
CE1
set interfaces ge-0/0/0 unit 0 family inet address 10.10.17.7/24 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
CE2
set interfaces ge-0/0/4 unit 0 family inet address 10.10.56.6/24 set protocols ospf area 0.0.0.0 interface ge-0/0/4.0
Configuration de l’équipement PE1
Procédure étape par étape
L’exemple suivant nécessite que vous naviguiez à 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 à la section Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.
Pour configurer l’appareil PE1 :
-
Configurez les interfaces.
[edit interfaces] set ge-0/0/0 unit 0 family inet address 10.10.12.1/24 set ge-0/0/0 unit 0 family mpls maximum-labels 5 set ge-0/0/1 unit 0 family inet address 10.10.13.1/24 set ge-0/0/1 unit 0 family mpls maximum-labels 5 set ge-0/0/5 unit 0 family inet address 10.10.17.1/24
-
Configurez le numéro et les options du système autonome pour contrôler les options de routage de transfert de paquets.
[edit routing-options] set autonomous-system 65000 set forwarding-table export load-balance-policy set forwarding-table chained-composite-next-hop ingress l3vpn
-
Configurez les interfaces avec le protocole MPLS et configurez la plage d’étiquettes MPLS.
[edit protocols mpls] set interface ge-0/0/0.0 set interface ge-0/0/1.0 set label-range static-label-range 1000000 1000999
-
Configurez le type de groupe d’homologues, l’adresse locale, la famille de protocoles pour les NLRI dans les mises à jour et l’adresse IP d’un voisin pour le groupe d’homologues.
[edit protocols bgp] set group pe type internal set group pe local-address 192.168.147.211 set group pe family inet-vpn unicast set group pe neighbor 192.168.146.181
-
Configurez les interfaces de la zone de protocole.
[edit protocols ospf] set area 0.0.0.0 interface ge-0/0/0.0 set area 0.0.0.0 interface lo0.0 set area 0.0.0.0 interface ge-0/0/1.0
-
Configurez l’adresse IPv4 et les étiquettes des chemins primaire et secondaire pour les stratégies de routage source et d’ingénierie du trafic TE (Protocol Source Packet Routing).
[edit protocols source-packet-routing segment-list] set sl-15-primary hop-1 ip-address 10.10.13.3 set sl-15-primary hop-2 label 1000134 set sl-15-primary hop-3 label 1000145 set sl-15-backup hop-1 ip-address 10.10.12.2 set sl-15-backup hop-2 label 1000123 set sl-15-backup hop-3 label 1000134 set sl-15-backup hop-4 label 1000145
-
Configurez l’adresse IPv4 de destination, l’étiquette SID de liaison, ainsi que le chemin de routage source primaire et secondaire pour le protocole SPRING.
[edit protocols source-packet-routing source-routing-path] set lsp-15 to 192.168.146.181 set lsp-15 binding-sid 1000999 set lsp-15 primary sl-15-primary set lsp-15 secondary sl-15-backup
-
Configurez les options de stratégie.
[edit policy-options policy-statement] set VPN-A-export term a from protocol ospf set VPN-A-export term a from protocol direct set VPN-A-export term a then community add VPN-A set VPN-A-export term a then accept set VPN-A-export term b then reject set VPN-A-import term a from protocol bgp set VPN-A-import term a from community VPN-A set VPN-A-import term a then accept set VPN-A-import term b then reject set bgp-to-ospf from protocol bgp set bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set bgp-to-ospf then accept set load-balance-policy then load-balance per-packet
-
Configurez les informations de la communauté BGP.
[edit policy-options] set community VPN-A members target:65000:1
-
Configurez l’instance de routage VRF1 avec le type d’instance, l’interface, le distinguateur de routeur, l’importation, l’exportation et l’étiquette de table VRF. Configurez la stratégie d’exportation et l’interface de la zone pour le protocole OSPF.
[edit routing-instances VRF1] set instance-type vrf set interface ge-0/0/5.0 set route-distinguisher 192.168.147.211:1 set vrf-import VPN-A-import set vrf-export VPN-A-export set vrf-table-label set protocols ospf export bgp-to-ospf set protocols ospf area 0.0.0.0 interface ge-0/0/5.0
Résultats
À partir du mode de configuration, confirmez votre configuration en saisissant les commandes show interfaces, show policy-options, show protocols, show routing-options et show routing-instances. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
[edit] user@PE1# show interfaces { ge-0/0/0 { unit 0 { family inet { address 10.10.12.1/24; } family mpls { maximum-labels 5; } } } ge-0/0/1 { unit 0 { family inet { address 10.10.13.1/24; } family mpls { maximum-labels 5; } } } ge-0/0/5 { unit 0 { family inet { address 10.10.17.1/24; } } } } policy-options { policy-statement VPN-A-export { term a { from protocol [ ospf direct ]; then { community add VPN-A; accept; } } term b { then reject; } } policy-statement VPN-A-import { term a { from { protocol bgp; community VPN-A; } then accept; } term b { then reject; } } policy-statement bgp-to-ospf { from { protocol bgp; route-filter 10.10.0.0/16 orlonger; } then accept; } policy-statement load-balance-policy { then { load-balance per-packet; } } community VPN-A members target:65000:1; } routing-instances { VRF1 { instance-type vrf; protocols { ospf { area 0.0.0.0 { interface ge-0/0/5.0; } export bgp-to-ospf; } } interface ge-0/0/5.0; route-distinguisher 192.168.147.211:1; vrf-import VPN-A-import; vrf-export VPN-A-export; vrf-table-label; } } routing-options { autonomous-system 65000; forwarding-table { export load-balance-policy; chained-composite-next-hop { ingress { l3vpn; } } } } protocols { bgp { group pe { type internal; local-address 192.168.147.211; family inet-vpn { unicast; } neighbor 192.168.146.181; } } mpls { label-range { static-label-range 1000000 1000999; } interface ge-0/0/0.0; interface ge-0/0/1.0; } ospf { area 0.0.0.0 { interface ge-0/0/0.0; interface lo0.0; interface ge-0/0/1.0; } } source-packet-routing { segment-list sl-15-primary { hop-1 ip-address 10.10.13.3; hop-2 label 1000134; hop-3 label 1000145; } segment-list sl-15-backup { hop-1 ip-address 10.10.12.2; hop-2 label 1000123; hop-3 label 1000134; hop-4 label 1000145; } source-routing-path lsp-15 { to 192.168.146.181; binding-sid 1000999; primary { sl-15-primary; } secondary { sl-15-backup; } } } }
Configuration de l’équipement PE2
Procédure étape par étape
L’exemple suivant nécessite que vous naviguiez à 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 à la section Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.
-
Configurez les interfaces.
[edit interfaces] set ge-0/0/0 unit 0 family inet address 10.10.12.2/24 set ge-0/0/0 unit 0 family mpls set ge-0/0/1 unit 0 family inet address 10.10.23.2/24 set ge-0/0/1 unit 0 family mpls
-
Configurez le LSP statique pour le protocole MPLS.
[edit protocols mpls static-label-switched-path] set adj-23 segment 1000123 set adj-23 segment next-hop 10.10.23.3 set adj-23 segment pop set adj-21 segment 1000221 set adj-21 segment next-hop 10.10.12.1 set adj-21 segment pop
-
Configurez les interfaces et la plage d’étiquettes statiques pour le protocole MPLS.
[edit protocols mpls] set interface ge-0/0/0.0 set interface ge-0/0/1.0 set label-range static-label-range 1000000 1000999
-
Configurez les interfaces pour le protocole OSPF.
[edit protocols ospf area 0.0.0.0] set interface ge-0/0/0.0 set interface ge-0/0/1.0
Résultats
À partir du mode de configuration sur le routeur PE2, confirmez votre configuration en entrant les show interfaces commandes and show protocols . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
[edit] user@PE2# show interfaces { ge-0/0/0 { unit 0 { family inet { address 10.10.12.2/24; } family mpls; } } ge-0/0/1 { unit 0 { family inet { address 10.10.23.2/24; } family mpls; } } } protocols { mpls { label-range { static-label-range 1000000 1000999; } interface ge-0/0/0.0; interface ge-0/0/1.0; static-label-switched-path adj-23 { segment { 1000123; next-hop 10.10.23.3; pop; } } static-label-switched-path adj-21 { segment { 1000221; next-hop 10.10.12.1; pop; } } } ospf { area 0.0.0.0 { interface ge-0/0/0.0; interface ge-0/0/1.0; } } }
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification de l’entrée de route de la table de routage inet.3 du routeur PE1
- Vérification des entrées de la table de routage de la table de routage mpls.0 du routeur PE1
- Vérification du LSP d’ingénierie de trafic SPRING du routeur PE1
- Vérification des LSP SPRING Traffic Engineered sur le routeur d’entrée du routeur PE1
- Vérification des entrées de la table de routage de la table de routage mpls.0 du routeur PE2
- Vérification de l’état des segments LSP MPLS statiques du routeur PE2
Vérification de l’entrée de route de la table de routage inet.3 du routeur PE1
But
Vérifiez l’entrée de route de la table de routage inet.3 du routeur PE1.
Action
À partir du mode opérationnel, entrez la show route table inet.3
commande.
user@PE1> show route table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.146.181/32 *[SPRING-TE/8] 03:09:26, metric 1
> to 10.10.13.3 via ge-0/0/1.0, Push 1000145, Push 1000134(top)
to 10.10.12.2 via ge-0/0/0.0, Push 1000145, Push 1000134, Push 1000123(top)
Sens
La sortie affiche les routes d’entrée des tunnels de routage de segments.
Vérification des entrées de la table de routage de la table de routage mpls.0 du routeur PE1
But
Vérifiez les entrées de route de la table de routage mpls.0
Action
À partir du mode opérationnel, entrez la show route table mpls.0
commande.
user@PE1> show route table mpls.0
mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 03:25:52, metric 1
Receive
1 *[MPLS/0] 03:25:52, metric 1
Receive
2 *[MPLS/0] 03:25:52, metric 1
Receive
13 *[MPLS/0] 03:25:52, metric 1
Receive
16 *[VPN/0] 03:25:52
> via lsi.0 (VRF1), Pop
1000999 *[SPRING-TE/8] 03:04:03, metric 1
> to 10.10.13.3 via ge-0/0/1.0, Swap 1000145, Push 1000134(top)
to 10.10.12.2 via ge-0/0/0.0, Swap 1000145, Push 1000134, Push 1000123(top)
Sens
La sortie affiche les étiquettes SID des tunnels de routage de segments.
Vérification du LSP d’ingénierie de trafic SPRING du routeur PE1
But
Vérifiez les LSP d’ingénierie de trafic SPRING sur les routeurs entrants.
Action
À partir du mode opérationnel, entrez la show spring-traffic-engineering overview
commande.
user@PE1> show spring-traffic-engineering overview
Overview of SPRING-TE:
Route preference: 8
Number of LSPs: 1 (Up: 1, Down: 0)
External controllers:
< Not configured >
Sens
La sortie affiche la vue d’ensemble des LSP d’ingénierie de trafic SPRING sur le routeur entrant.
Vérification des LSP SPRING Traffic Engineered sur le routeur d’entrée du routeur PE1
But
Vérifiez les LSP d’ingénierie de trafic SPRING sur le routeur entrant.
Action
À partir du mode opérationnel, entrez la show spring-traffic-engineering lsp detail
commande.
user@PE1# show spring-traffic-engineering lsp detail
Name: lsp-15
To: 192.168.146.181
State: Up
Path: sl-15-primary
Outgoing interface: ge-0/0/1.0
BFD status: N/A (Up: 0, Down: 0)
SR-ERO hop count: 3
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.10.13.3
SID type: None
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000134
Hop 3 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000145
Path: sl-15-backup
Outgoing interface: ge-0/0/0.0
BFD status: N/A (Up: 0, Down: 0)
SR-ERO hop count: 4
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.10.12.2
SID type: None
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000123
Hop 3 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000134
Hop 4 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000145
Total displayed LSPs: 1 (Up: 1, Down: 0)
Sens
La sortie affiche les détails des LSP SPRING sur le routeur entrant
Vérification des entrées de la table de routage de la table de routage mpls.0 du routeur PE2
But
Vérifiez les entrées de la table de routage de la table de routage mpls.0 du routeur PE2.
Action
À partir du mode opérationnel, entrez la show route table mpls.0
commande.
user@PE2> show route table mpls.0
mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 03:22:29, metric 1
Receive
1 *[MPLS/0] 03:22:29, metric 1
Receive
2 *[MPLS/0] 03:22:29, metric 1
Receive
13 *[MPLS/0] 03:22:29, metric 1
Receive
1000123 *[MPLS/6] 03:22:29, metric 1
> to 10.10.23.3 via ge-0/0/1.0, Pop
1000123(S=0) *[MPLS/6] 03:22:29, metric 1
> to 10.10.23.3 via ge-0/0/1.0, Pop
1000221 *[MPLS/6] 03:22:29, metric 1
> to 10.10.12.1 via ge-0/0/0.0, Pop
1000221(S=0) *[MPLS/6] 03:22:29, metric 1
> to 10.10.12.1 via ge-0/0/0.0, Pop
Vérification de l’état des segments LSP MPLS statiques du routeur PE2
But
Vérifiez l’état des segments MPLS LSP du routeur PE2.
Action
À partir du mode opérationnel, entrez la show mpls static-lsp
commande.
user@PE2> show mpls static-lsp
Ingress LSPs:
Total 0, displayed 0, Up 0, Down 0
Transit LSPs:
Total 0, displayed 0, Up 0, Down 0
Bypass LSPs:
Total 0, displayed 0, Up 0, Down 0
Segment LSPs:
LSPname SID-label State
adj-21 1000221 Up
adj-23 1000123 Up
Total 2, displayed 2, Up 2, Down 0
Sens
La sortie affiche l’état des segments MPLS LSP statiques du routeur PE2.
Activation du CSPF distribué pour les LSP de routage de segments
Avant Junos OS version 19.2R1S1, pour l’ingénierie du trafic des chemins de routage de segments, vous pouviez soit configurer explicitement des chemins statiques, soit utiliser des chemins calculés à partir d’un contrôleur externe. Avec la fonctionnalité CSPF (Constrained Shortest Path First) distribuée pour le LSP de routage de segments, vous pouvez calculer un LSP de routage de segments localement sur l’équipement entrant en fonction des contraintes que vous avez configurées. Grâce à cette fonctionnalité, les LSP sont optimisés en fonction des contraintes configurées et du type de métrique (traffic-engineering ou IGP). Les LSP sont calculés pour utiliser les chemins ECMP disponibles vers la destination lorsque la compression de pile d’étiquettes de routage de segments est activée ou désactivée.
- Contraintes de calcul CSPF distribuées
- Algorithme de calcul CSPF distribué
- Base de données de calcul CSPF distribuée
- Configuration des contraintes de calcul CSPF distribuées
- Calcul CSPF distribué
- Interaction entre le calcul CSPF distribué et les fonctionnalités SR-TE
- Exemples de configurations de calcul CSPF distribué
Contraintes de calcul CSPF distribuées
Les chemins LSP de routage de segments sont calculés lorsque toutes les contraintes configurées sont satisfaites.
La fonctionnalité de calcul CSPF distribué prend en charge le sous-ensemble de contraintes suivantes spécifié dans le projet Internet, draft-ietf-spring-segment-routing-policy-03.txt, Segment Routing Policy for Traffic Engineering :
-
Inclusion et exclusion de groupes administratifs.
-
Inclusion d’adresses IP de saut lâches ou strictes.
REMARQUE :Vous ne pouvez spécifier que des ID de routeur dans les contraintes de saut lâches ou strictes. Les étiquettes et autres adresses IP ne peuvent pas être spécifiées en tant que contraintes de saut lâches ou strictes dans Junos OS version 19.2R1-S1.
-
Nombre maximal d’ID de segment (SID) dans la liste des segments.
-
Nombre maximal de listes de segments par chemin de routage de segments candidats.
La fonctionnalité de calcul CSPF distribuée pour les LSP de routage de segments ne prend pas en charge les types de contraintes et de scénarios de déploiement suivants :
-
Adresses IPV6.
-
LSP d’ingénierie du trafic de routage de segments interdomaines (SR-TE).
-
Interfaces non numérotées.
-
Plusieurs protocoles de routage (OSPF, ISIS et BGP-LS) sont activés simultanément.
-
Calcul avec des préfixes ou des adresses anycast comme destinations.
-
Inclure et exclure les adresses IP d’interface en tant que contraintes.
Algorithme de calcul CSPF distribué
La fonctionnalité de calcul CSPF distribuée pour les LSP de routage de segments utilise l’algorithme de compression de pile d’étiquettes avec CSPF.
Compression de la pile d’étiquettes activée
Une pile d’étiquettes compressée représente un ensemble de chemins allant d’une source à une destination. Il se compose généralement de SID de nœud et de SID d’adjacence. Lorsque la compression de la pile d’étiquettes est activée, le résultat du calcul est un ensemble de chemins qui maximisent ECMP vers la destination, avec un nombre minimal de SID dans la pile, tout en se conformant aux contraintes.
Compression de la pile d’étiquettes désactivée
Le calcul CSPF multipath lorsque la compression de la pile d’étiquettes est désactivée permet de trouver jusqu’à des listes de segments jusqu’à N la destination, où :
-
Le coût de toutes les listes de segments est égal et identique à la mesure d’ingénierie du trafic la plus courte pour atteindre la destination.
-
Chaque liste de segments est composée de SID de contiguïté.
-
La valeur de est le nombre maximal de listes de N segments autorisées pour le chemin d’accès candidat par configuration.
-
Il n’y a pas deux listes de segments identiques.
-
Chaque liste de segments répond à toutes les contraintes configurées.
Base de données de calcul CSPF distribuée
La base de données utilisée pour le calcul de la SR-TE contient tous les liens, les nœuds, les préfixes et leurs caractéristiques, que l’ingénierie du trafic soit activée ou non dans ces nœuds publicitaires. En d’autres termes, c’est l’union de la base de données d’ingénierie du trafic (TED) et de la base de données d’état des liens IGP de tous les domaines à partir desquels le nœud de calcul a appris. Par conséquent, pour que CSPF fonctionne, vous devez inclure l’instruction igp-topology
au niveau de la [edit protocols isis traffic-engineering]
hiérarchie.
Configuration des contraintes de calcul CSPF distribuées
Vous pouvez utiliser un profil de calcul pour regrouper logiquement les contraintes de calcul. Ces profils de calcul sont référencés par les chemins de routage de segments pour calculer les LSP de routage de segments primaire et secondaire.
Pour configurer un profil de calcul, incluez l’instruction compute-profile au niveau de la [edit protocols source-packet-routing]
hiérarchie.
La configuration des contraintes de calcul prises en charge est la suivante :
-
Administrative groups
Vous pouvez configurer les groupes d’administrateurs au niveau de la
[edit protocols mpls]
hiérarchie. Junos OS applique la configuration du groupe d’administration aux interfaces SR-TE (Segment Routing Traffic-ingénierie).Pour configurer les contraintes de calcul, vous pouvez spécifier trois catégories pour un ensemble de groupes d’administration. La configuration de contrainte de calcul peut être commune à tous les chemins de routage de segments candidats ou se trouver sous des chemins candidats individuels.
-
include-any
: spécifie que tout lien avec au moins un des groupes d’administration configurés dans la liste est acceptable pour le chemin à traverser. -
include-all
: spécifie que tout lien avec tous les groupes d’administration configurés de la liste est acceptable pour le chemin à traverser. -
exclude
: spécifie que tout lien qui n’a aucun des groupes d’administration configurés dans la liste est acceptable pour le chemin à traverser.
-
-
Explicit path
Vous pouvez spécifier une série d’ID de routeur dans le profil de calcul en tant que contrainte pour le calcul des chemins candidats SR-TE . Chaque saut doit être une adresse IPv4 et peut être de type strict ou loose. Si le type d’un saut n’est pas configuré, strict est utilisé. Vous devez inclure l’option sous l’instruction
compute
segment-list lorsque vous spécifiez la contrainte de chemin explicite. -
Maximum number of segment lists (ECMP paths)
Vous pouvez associer un chemin candidat à un certain nombre de listes de segments dynamiques. Les chemins sont des chemins ECMP, où chaque liste de segments se traduit par une passerelle de saut suivant avec une pondération active. Ces chemins sont le résultat d’un calcul de chemin avec ou sans compression.
Vous pouvez configurer cet attribut à l’aide de l’option située sous l’instruction de
maximum-computed-segment-lists maximum-computed-segment-lists
configuration compute-profile . Cette configuration détermine le nombre maximal de ces listes de segments calculées pour un LSP primaire et secondaire donné. -
Maximum segment list depth
Le paramètre de calcul de la profondeur maximale de la liste de segments garantit que, parmi les chemins ECMP qui satisfont à toutes les autres contraintes, telles que le groupe d’administration, seuls les chemins dont les listes de segments sont inférieures ou égales à la profondeur maximale de la liste de segments sont utilisés. Lorsque vous configurez ce paramètre en tant que contrainte sous le profil de calcul, il remplace la configuration sous le
maximum-segment-list-depth
niveau hiérarchique[edit protocols source-packet-routing]
, le cas échéant.Vous pouvez configurer cet attribut à l’aide de l’option située sous l’instruction de
maximum-segment-list-depth maximum-segment-list-depth
configuration compute-profile . -
Protected or unprotected adjacency SIDs
Vous pouvez configurer un SID d’adjacence protégé ou non protégé en tant que contrainte sous le profil de calcul afin d’éviter les liens avec le type de SID spécifié.
-
Metric type
Vous pouvez spécifier le type de métrique sur le lien à utiliser pour le calcul. Par défaut, les LSP SR-TE utilisent les mesures d’ingénierie du trafic des liaisons pour le calcul. La métrique d’ingénierie du trafic pour les liens est annoncée par les extensions d’ingénierie du trafic des protocoles IGP. Toutefois, vous pouvez également choisir d’utiliser la métrique IGP pour le calcul à l’aide de la configuration de type métrique dans le profil de calcul.
Vous pouvez configurer cet attribut à l’aide de l’option située sous l’instruction de
metric-type (igp | te)
configuration compute-profile .
Calcul CSPF distribué
Les chemins candidats SR-TE sont calculés localement de manière à satisfaire les contraintes configurées. Lorsque la compression de la pile d’étiquettes est désactivée, le résultat du calcul CSPF multi-chemin est un ensemble de piles SID d’adjacence. Lorsque la compression de la pile d’étiquettes est activée, le résultat est un ensemble de piles d’étiquettes compressées (composées de SID et de SID de nœud adjacents).
Lorsque les chemins secondaires sont calculés, les liens, les noeuds et les SRLG empruntés par les chemins primaires ne sont pas évités pour le calcul. Pour plus d’informations sur les chemins d’accès principaux et secondaires, consultez Configuration des LSP principaux et secondaires.
Pour tous les LSP dont le résultat de calcul a échoué, le calcul est retenté en tant que modifications de la base de données d’ingénierie du trafic (TED).
Interaction entre le calcul CSPF distribué et les fonctionnalités SR-TE
- Pondérations associées aux chemins d’une politique SR-TE
- Détection de la vivacité BFD
- inherit-label-nexthops
- Fonction de traduction automatique
Pondérations associées aux chemins d’une politique SR-TE
Vous pouvez configurer des pondérations par rapport aux chemins SR-TE calculés et statiques, qui contribuent aux sauts suivants de l’itinéraire. Toutefois, un seul chemin pour lequel le calcul est activé peut générer plusieurs listes de segments. Ces listes de segments calculées sont traitées comme ECMP entre elles. Vous pouvez affecter des pondérations ECMP hiérarchiques à ces segments, en tenant compte des pondérations attribuées à chacun des principaux configurés.
Détection de la vivacité BFD
Vous pouvez configurer la détection de vivacité BFD pour les chemins principaux ou secondaires calculés. Chaque chemin principal ou secondaire calculé peut générer plusieurs listes de segments, par conséquent, les paramètres BFD configurés par rapport aux listes de segments sont appliqués à toutes les listes de segments calculées. Si tous les chemins principaux actifs tombent en panne, le chemin secondaire préprogrammé (s’il est fourni) devient actif.
inherit-label-nexthops
Il n’est pas nécessaire d’activer explicitement la configuration sous la inherit-label-nexthops
[edit protocols source-packet-routing segment-list segment-list-name]
hiérarchie pour les chemins principaux ou secondaires calculés, car il s’agit d’un comportement par défaut.
Fonction de traduction automatique
Vous pouvez configurer la fonctionnalité de traduction automatique dans les listes de segments, et les chemins principaux ou secondaires avec la fonction de traduction automatique font référence à ces listes de segments. D’autre part, le primaire ou le secondaire sur lequel la fonctionnalité de calcul est activée ne peut faire référence à aucune liste de segments. Par conséquent, vous ne pouvez pas activer à la fois la fonctionnalité de calcul et la fonctionnalité de traduction automatique pour un chemin principal ou secondaire donné. Toutefois, vous pouvez avoir un LSP configuré avec un chemin principal avec le type de calcul et un autre avec le type de traduction automatique.
Exemples de configurations de calcul CSPF distribué
Exemple 1
Dans l’exemple 1,
-
Le chemin principal non calculé fait référence à une liste de segments configurée. Dans cet exemple, la liste static_sl1 de segments configurée est référencée et sert également de nom à ce chemin principal.
-
Un nom doit être configuré pour un primaire calculé, et ce nom ne doit pas faire référence à une liste de segments configurée. Dans cet exemple, compute_segment1 il ne s’agit pas d’une liste de segments configurée.
-
Le compute_profile_red profil de calcul est appliqué au chemin d’accès principal portant le nom compute_segment1.
-
Le compute_profile_red profil de calcul inclut une liste de segments de type
compute
, qui est utilisée pour spécifier la contrainte de chemin explicite pour le calcul.
[edit protocols source-packet-routing] segment-list static_sl1{ hop1 label 80000 } segment-list exp_path1 { hop1 ip-address 10.1.1.1 loose hop2 ip-address 10.2.2.2 compute } compute-profile compute_profile_red { include-any red segment-list exp_path1 maximum-segment-list-depth 5 }
Les pondérations pour les sauts suivants de chemin calculés et les sauts suivants statiques sont respectivement de 2 et 3. En supposant que les sauts suivants pour les chemins calculés sont , et comp_nh3, et que le saut suivant pour le chemin statique est static_nh, comp_nh2les pondérations sont comp_nh1appliquées comme suit :
Saut suivant |
Poids |
---|---|
comp_nh1 |
2 |
comp_nh2 |
2 |
comp_nh3 |
2 |
static_nh |
9 |
Exemple 2
Dans l’exemple 2, les chemins primaire et secondaire peuvent être de type calcul et avoir leurs propres profils de calcul.
[edit protocols source-packet-routing] compute-profile compute_profile_green{ include-any green maximum-segment-list-depth 5 } compute-profile compute_profile_red{ include-any red maximum-segment-list-depth 8 }
Exemple 3
Dans l’exemple 3, lorsque le calcul est mentionné sous un chemin principal ou secondaire, il en résulte le calcul local d’un chemin vers la destination sans aucune contrainte ou autre paramètre pour le calcul.
[edit protocols source-packet-routing] source-routing-path srte_colored_policy1 { to 10.5.5.5 color 5 binding-sid 10001 primary { compute_segment1 { compute } } }
Exemple : Configuration du transfert basé sur CoS et du routage basé sur des stratégies pour les LSP SR-TE
SUMMARY Le transfert basé sur CoS (CBF) et le routage basé sur les stratégies (PBR, également appelé transfert basé sur les filtres) peuvent être activés pour les LSP SR-TE (Segment Routing-Traffic Engineer) non colorés afin d’orienter le trafic de manière sélective sur un chemin SR-TE explicite, vous offrant ainsi l’avantage d’une gestion du trafic en fonction de la classe de service ou d’une stratégie.
- Présentation du transfert CoS et du routage basé sur des stratégies pour les LSP SR-TE
- Configurer le transfert CoS et le routage basé sur des stratégies pour les LSP SR-TE
Présentation du transfert CoS et du routage basé sur des stratégies pour les LSP SR-TE
- Avantages du transfert basé sur CoS (CBF) et du routage basé sur des stratégies (PBR) pour les LSP SR-TE
- Sources de chemin de segment routing prenant en charge CBF et PBR
- Considérations relatives à la configuration des modèles CBF et PBR pour les LSP SR-TE
Avantages du transfert basé sur CoS (CBF) et du routage basé sur des stratégies (PBR) pour les LSP SR-TE
Avec CBF et PBR, vous pouvez :
Utilisez des combinaisons de chemins d’ingénierie de trafic de routage de segments (SR-TE) pour orienter le trafic de service dans le réseau central.
Choisissez les services de prise en charge à résoudre sur les chemins SR-TE sélectionnés.
Sources de chemin de segment routing prenant en charge CBF et PBR
Les sources de chemin de routage de segments suivantes prennent en charge le transfert basé sur CoS et le routage basé sur des stratégies :
Static SR–TE paths: chemins d’acheminement source configurés de manière statique sur lesquels l’ensemble de la pile d’étiquettes est configuré de manière statique.
PCEP—Provisionnement dynamique des chemins de routage source créés sur un contrôleur et téléchargés sur un routeur entrant dans un ERO, soit via des extensions de routage de segment PCEP, soit dans une stratégie de routage de segment BGP via des extensions de routage de segment BGP.
Dynamic LSPs: tunnels créés dynamiquement et déclenchés par le module de tunnel dynamique avec une résolution ERO de dernier saut.
Auto-translated paths: chemins de routage source configurés statiquement qui sont automatiquement traduits.
Considérations relatives à la configuration des modèles CBF et PBR pour les LSP SR-TE
Rappelez-vous:
Le CBF et le PBR ne sont activés que sur les LSP SR-TE non colorés configurés de manière statique ou dynamique.
Les configurations CBF et PBR pour les LSP SR-TE peuvent coexister sur un appareil ; L’ordre de configuration détermine le type dans lequel les routes sont transférées.
Pour PBR, si le premier saut du SR-TE LSP est une étiquette, vous devez inclure l’instruction
resolution preserve-nexthop-hiearchy
au niveau de la[edit routing-options]
hiérarchie.Le transfert basé sur la classe des routes pour CBF est visible uniquement dans la table de transfert et non sur les routes.
Le transfert basé sur la stratégie des routes pour PBR s’effectue sur les routes et est visible dans la sortie de la
show route
commande.
Configurer le transfert CoS et le routage basé sur des stratégies pour les LSP SR-TE
SUMMARY Le transfert basé sur CoS (CBF) et le routage basé sur les stratégies (PBR, également connu sous le nom de transfert FBF basé sur les filtres) peuvent être utilisés pour orienter un trafic sélectif à l’aide d’un chemin de basculement d’étiquette (LSP) SR-TE (Explicit Segment Routing-Traffic Engineer). Seuls les LSP de routage de segments non colorés dont le tronçon suivant est configuré comme étiquette de premier saut ou adresse IP prennent en charge les protocoles CBF et PBR.
Avant de commencer
Vous devez exécuter Junos OS version 20.1 et versions ultérieures pour activer CBF et PBR pour les LSP SR-TE non colorés.
Configurez les interfaces des appareils et assurez-vous qu’ils sont connectés au réseau.
Définissez des listes de segments et configurez les LSP SR-TE et leurs paramètres associés.
Pour configurer un LSP SR-TE, procédez comme suit :
Vous pouvez désormais configurer CBF et PBR pour les LSP SR-TE configurés.
Pour configurer CBF, procédez comme suit
Définissez des classificateurs DSCP (Differentiated Services Code Point) pour gérer les paquets IPv4 entrants, les classes de transfert et les valeurs d’option.
[edit class-of-service] user@host# set classifiers dscpclassifier-name forwarding-class forwarding-class-name loss-priority level code-points [ aliases ] [ 6 bit-patterns ]
Par exemple :
[edit class-of-service] user@host# set classifiers dscp mydscp forwarding-class af11 loss-priority low code-points 001010 user@host# set classifiers dscp mydscp forwarding-class af11 loss-priority medium-high code-points 001100 user@host# set classifiers dscp mydscp forwarding-class af11 loss-priority high code-points 001110 user@host# set classifiers dscp mydscp forwarding-class af21 loss-priority low code-points 010010 user@host# set classifiers dscp mydscp forwarding-class af21 loss-priority medium-high code-points 010100 user@host# set classifiers dscp mydscp forwarding-class af21 loss-priority high code-points 010110 user@host# set classifiers dscp mydscp forwarding-class af31 loss-priority low code-points 011010 user@host# set classifiers dscp mydscp forwarding-class af31 loss-priority medium-high code-points 011100 user@host# set classifiers dscp mydscp forwarding-class af31 loss-priority high code-points 011110 user@host# set classifiers dscp mydscp forwarding-class af41 loss-priority low code-points 100010 user@host# set classifiers dscp mydscp forwarding-class af41 loss-priority medium-high code-points 100100 user@host# set classifiers dscp mydscp forwarding-class af41 loss-priority high code-points 100110
Définissez des classes de transfert (FC) pour regrouper les paquets à transmettre et affectez les paquets aux files d’attente de sortie.
[edit class-of-service] user@host# set forwarding-classes queue queue-numner class-name
Par exemple :
[edit class-of-service] user@host# set forwarding-classes queue 0 af11 user@host# set forwarding-classes queue 1 af21 user@host# set forwarding-classes queue 2 af31 user@host# set forwarding-classes queue 3 af41
Affectez les classificateurs configurés aux interfaces de périphériques.
[edit class-of-service] user@host# set interfaces interface-name unit unit classifiers dscp classifier-name
Par exemple :
[edit class-of-service] user@host# set interfaces ge-0/0/8 unit 1 classifiers dscp mydscp user@host# set interfaces ge-0/0/8 unit 2 classifiers dscp mydscp
Définissez des options de stratégie de transfert basées sur CoS avec LSP next-hop comme SR-TE LSP.
[edit class-of-service] user@host# set forwarding-policy next-hop-map map-name forwarding-classes class-name lsp-next-hop source-routing-path-name
Par exemple :
[edit class-of-service] user@host# set forwarding-policy next-hop-map my_cbf forwarding-class af11 lsp-next-hop srtelsp1 user@host# set forwarding-policy next-hop-map my_cbf forwarding-class af21 lsp-next-hop srtelsp2 user@host# set forwarding-policy next-hop-map my_cbf forwarding-class af41 lsp-next-hop srtelsp3 user@host# set forwarding-policy next-hop-map my_cbf forwarding-class af31 lsp-next-hop srtelsp4
Ignorer le trafic qui ne répond à aucune classe de transfert dans la carte de saut suivant.
[edit class-of-service] user@host# set forwarding-policy next-hop-map map-name forwarding-class-default discard
Par exemple :
[edit class-of-service] user@host# set forwarding-policy next-hop-map my_cbf forwarding-class-default discard
Configurez une instruction de stratégie qui spécifie que les routes correspondant au filtre de route sont soumises au mappage de saut suivant CoS spécifié par map-name.
[edit policy-options] user@host# set policy-statement policy-name from route-filter destination-prefix match-type <actions> user@host# set policy-statement policy-name then cos-next-hop-map map-name
Par exemple :
[edit policy-options] user@host# set policy-statement cbf from route-filter 4.0.0.1/16 orlonger user@host# set policy-statement cbf then cos-next-hop-map my_cbf
Appliquez la stratégie aux itinéraires exportés de la table de routage vers la table de transfert. Cela permet d’activer le CBF pour les LSP SR-TE.
[edit routing-options] user@host# set forwarding-table export policy-name
Par exemple :
[edit routing-options] user@host# set forwarding-table export cbf
Validez la configuration.
user@host# commit
Verify CBF Configuration
Vous pouvez vérifier la configuration CBF à l’aide de la show route forwarding-table destination ip-address vpn vpn-name extensive
commande.
user@host> show route forwarding-table destination 4.0.0.1 vpn vpn1 extensive Routing table: vpn1.inet [Index 8] Internet: Destination: 4.0.0.1/32 Route type: user Route reference: 0 Multicast RPF nh index: 0 P2mpidx: 0 Flags: sent to PFE Next-hop type: indirect Next-hop type: indexed Route type: idx:0 Nexthop: 11.1.1.2 Next-hop type: Push 296, Push 801007, Push 801003, Push 801002(top) Index: 807 Reference: 1 Route interface-index: 0 Index: 1048579 Reference: 10001 Index: 837 Reference: 2 Load Balance Label: None Next-hop interface: ge-0/0/1.1 Route type: idx:1 Nexthop: 11.11.1.2 Next-hop type: Push 296, Push 801007, Push 801003, Push 801002(top) Index: 809
Pour CBF, le transfert de routes basé sur les classes est visible uniquement dans la table de transfert, contrairement au PBR, où les routes filtrées sont visibles dans la sortie de la show route
commande.
Pour configurer le PBR, procédez comme suit
Configurez une instruction de stratégie qui spécifie que les routes correspondant au protocole et au filtre de route sont soumises au saut suivant LSP ou sont équilibrées en charge en tant que chemin multi-chemin à coût égal (ECMP) dans la table de transfert.
[edit policy-options] user@host# set policy-statement policy-name from protocol protocol-name user@host# set policy-statement policy-name from route-filter destination-prefix match-type <actions> user@host# set policy-statement policy-name then install-nexthop lsp lsp-name user@host# set policy-statement policy-name then load-balance per-packet
Par exemple :
[edit policy-options] user@host# set policy-statement pbr term 1 from protocol bgp user@host# set policy-statement pbr term 1 from route-filter 4.0.0.1/32 exact user@host# set policy-statement pbr term 1 then install-nexthop lsp srtelsp1 user@host# set policy-statement pbr term 1 then load-balance per-packet user@host# set policy-statement pbr term 1 then reject
Configurez l’appareil pour qu’il effectue une résolution de route personnalisée sur les sauts suivants de protocole.
REMARQUE :L’instruction
resolution preserve-nexthop-hierarchy
est obligatoire pour que le PBR fonctionne lorsque le premier saut du SR-TE LSP est une étiquette.[edit routing-options] user@host# set resolution preserve-nexthop-hierarchy
Appliquez la stratégie aux itinéraires exportés de la table de routage vers la table de transfert. Cela permet le PBR pour les LSP SR-TE.
[edit routing-options] user@host# set forwarding-table export policy-name
Par exemple :
[edit routing-options] user@host# set forwarding-table export pbr
Validez la configuration.
user@host# commit
Verify PBR Configuration
Vous pouvez vérifier la configuration PBR à l’aide de la show route destination-prefix
commande.
user@host> show route 4.0.0.1 vpn1.inet.0: 10003 destinations, 10003 routes (10003 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 4.0.0.1/32 *[BGP/170] 00:24:12, localpref 100, from 7.7.7.7 AS path: 10 I, validation-state: unverified to 11.1.1.2 via ge-0/0/1.1, Push 50983, Push 801007, Push 801003, Push 801002(top) > to 11.11.1.2 via ge-0/0/1.2, Push 50983, Push 801007, Push 801003, Push 801002(top) to 11.12.1.2 via ge-0/0/1.3, Push 50983, Push 801007, Push 801003, Push 801002(top) to 11.13.1.2 via ge-0/0/1.4, Push 50983, Push 801007, Push 801003, Push 801002(top)
user@host> show route 4.0.0.1 expanded-nh extensive vpn1.inet.0: 10003 destinations, 10003 routes (10003 active, 0 holddown, 0 hidden) 4.0.0.1/32 (1 entry, 1 announced) Installed-nexthop: Indr (0xc7aaa54) 7.7.7.7 Push 50983 Session-ID: 0x16f Krt_inh (0xc745a84) Index:1048579 PNH: 7.7.7.7 Chain (0xc7aa798) Index:823 Push 50983 Router (0xc417034) 11.1.1.2 Push 801007, Push 801003, Push 801002(top) via ge-0/0/1.1
La sortie affiche tous les sauts suivants pour le préfixe de destination, 4.0.0.1. Les expanded-nh extensive
options affichent les sauts suivants filtrés sous le champ de Krt_inh
sortie.
user@host> show route 4.0.0.2 vpn1.inet.0: 10003 destinations, 10003 routes (10003 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 4.0.0.2/32 *[BGP/170] 00:30:14, localpref 100, from 7.7.7.7 AS path: 10 I, validation-state: unverified to 11.1.1.2 via ge-0/0/1.1, Push 569, Push 801007, Push 801003, Push 801002(top) > to 11.11.1.2 via ge-0/0/1.2, Push 569, Push 801007, Push 801003, Push 801002(top) to 11.12.1.2 via ge-0/0/1.3, Push 569, Push 801007, Push 801003, Push 801002(top) to 11.17.1.2 via ge-0/0/1.8, Push 569, Push 801007, Push 801003, Push 801002(top)
user@host> show route 7.7.7.7 protocol spring-te inet.0: 10082 destinations, 10119 routes (10082 active, 0 holddown, 0 hidden) inet.3: 25 destinations, 77 routes (25 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 7.7.7.7/32 *[SPRING-TE/1] 00:00:32, metric 1, metric2 4 > to 11.1.1.2 via ge-0/0/1.1, Push 801007, Push 801003, Push 801002(top) to 11.11.1.2 via ge-0/0/1.2, Push 801007, Push 801003, Push 801002(top) to 11.12.1.2 via ge-0/0/1.3, Push 801007, Push 801003, Push 801002(top) to 11.17.1.2 via ge-0/0/1.8, Push 801007, Push 801003, Push 801002(top)
Pour le PBR, la sortie de la show route
commande effectue le filtrage des routes en fonction des stratégies.
Activation de chemins multiples pour les LSP SR-TE dans PCEP
Vous pouvez configurer plusieurs chemins (primaires ou secondaires) pour les LSP PCEP SR-TE (configurés statiquement, délégués et initiés par PCE), comme défini dans draft-ietf-pce-multipath-06. Une seule configuration de chemin secondaire est prise en charge, et uniquement pour les LSP SR-TE à configuration statique. Les extensions PCEP définies dans draft-ietf-pce-multipath-06 permettent à PCEP de propager plusieurs chemins (multipath) pour les LSP entre les points de terminaison PCEP.
Avantages des chemins multiples pour les LSP PCEP SR-TE
-
Les prestataires de services linguistiques peuvent avoir plusieurs ensembles d’ERO vers une destination
-
Fournit des capacités d’équilibrage de charge en configurant des pondérations pour chaque ERO
-
S’aligne sur le projet d’architecture SR-TE pour définir les chemins candidats
Les fonctionnalités de chemins multiples PCEP suivantes sont prises en charge :
-
Lorsque PCEP pour plusieurs chemins est activé (par défaut), vous pouvez configurer plusieurs chemins principaux (ou un chemin secondaire) dans un chemin candidat configuré et contrôlé par PCC.
-
Lorsque PCEP pour plusieurs chemins est désactivé, vous ne pouvez configurer qu’un seul chemin principal dans un chemin candidat. La configuration du chemin secondaire n’est pas autorisée.
Si vous activez les chemins d’accès multiples PCEP, compute-profile
il est désormais possible de configurer un nombre maximal de listes de segments (maximum-computed-segment-lists
) supérieur à 1.
Lorsque PCEP pour plusieurs chemins est activé, PCCD n’envoie pas de contraintes pour les chemins candidats contrôlés par PCC.
Lorsque la fonctionnalité de chemins multiples PCEP est activée, la configuration du chemin secondaire est autorisée pour un chemin candidat PCC non délégué, l’objet EXPLICIT-ROUTE (ERO) spécifique au chemin secondaire est envoyé au PCE avec l’indicateur de secours défini pour l’ERO. Les chemins d’accès principaux n’incluent pas MULTIPATH-BACKUP-TLV dans le message PCRpt. Le chemin secondaire inclut MULTIPATH-BACKUP-TLV avec l’indicateur de sauvegarde défini.
Les fonctionnalités de trajets multiples PCEP suivantes sont prises en charge :
-
Pondération multi-trajets TLV (MULTIPATH-WEIGHT-TLV) dans l’objet attribut de chemin (PATH-ATTRIB)
-
MULTIPATH-BACKUP TLV dans l’objet attribut de chemin (PATH-ATTRIB) uniquement pour les LSP SR-TE contrôlés par PCC
-
MULTIPATH-CAP TLV dans l’objet PCEP LSP
-
Restreint plusieurs chemins primaires et secondaires dans le chemin candidat SR lorsque les chemins multiples PCEP sont désactivés
-
Chemins primaires et secondaires multiples dans le chemin candidat SR lorsque le multichemin PCEP est activé pour les LSP contrôlés par PCC
-
Nombre maximal de segments calculés répertorie (
max-computed-segment-lists
) plus de 1 dans le profil de calcul SR-TE pour les LSP délégués et initiés par des PCE -
Plusieurs ERO pour le chemin candidat initié par l’ECP dans la SR-TE et dans le PCCD
-
LSP SRv6
-
SR MPLS (IPv4)
-
Tunnels dynamiques SR MPLS (IPv4)
-
Prise en charge de plusieurs contrôleurs
-
Plusieurs chemins ERO pour les chemins candidats initiés par PCE, configurés et contrôlés par PCC, et délégués de chemins candidats colorés et non colorés
-
Rétrocompatible avec les versions antérieures de Paragon Pathfinder. Pour la rétrocompatibilité, vous devez configurer
disable-multipath-capability
l’instruction de configuration au niveau de la hiérarchie [edit protocols pcep
]. -
Prise en charge du code d’erreur en cas d’échec de la validation des chemins candidats initiés par PCE
-
Le nombre total de chemins de sous-candidats par chemin candidat est limité à 127. Pour les LSP initiés par PCE, si le nombre de chemins ERO est supérieur à 127, SR-TE lève ERROR vers PCCD (et PCCD envoie un message d’erreur PCEP à PCE) et les chemins ERO correspondants sont rejetés.
-
Les messages d’erreur PCEP suivants sont pris en charge :
Type d’erreur | Valeur d’erreur | Sens | Utilisation |
---|---|---|---|
19 | 20 | Chemin de sauvegarde non pris en charge | Cela se produit lorsque MULTIPATH-BACKUP TLV est reçu par le PCC. |
24 | 1 | Paramètres d’instanciation inacceptables | Cela se produit lorsque PCE tente d’ajouter plus de 127 chemins de sous-candidats par chemin candidat. |
Limitations
Les restrictions suivantes s’appliquent :
-
Les TLV suivantes mentionnées dans le draft-ietf-pce-multipath-06 ne sont pas prises en charge :
-
TLV de sauvegarde à chemins multiples
-
TLV de chemin de direction opposée à trajets multiples
-
Parcours candidat composite
-
-
Lorsque la fonctionnalité de chemins multiples est désactivée dans PCEP, la configuration de plusieurs chemins de sous-candidats n’est pas autorisée. Toutefois, sur les équipements Junos sans fonctionnalité multipath (versions de Junos OS antérieures à 22.4R1), la configuration de plusieurs chemins sous-candidats est autorisée. Lorsque le multi-segment PCEP est activé (par défaut), plusieurs chemins principaux sont autorisés pour les LSP contrôlés par PCC à des fins de reporting. Toutefois, un seul chemin principal est pris en charge pour le chemin candidat délégué lorsque le multisegment PCEP est activé.
-
Les groupes d’administrateurs et toute autre contrainte ne seront pas notifiés à PCE pour les chemins candidats SR-MPLS et SRv6 configurés et contrôlés par PCC (avec une ou plusieurs configurations principales). Il n’y a pas d’impact sur les parcours de candidature délégués et initiés par PCE.
-
Lorsque la fonctionnalité de chemins multiples PCEP est activée, la configuration du chemin secondaire est autorisée pour les chemins candidats non délégués. Lorsque la fonctionnalité de chemins multiples PCEP est désactivée, la configuration du chemin secondaire n’est pas autorisée.
-
Les parcours candidats ne peuvent pas comporter un mélange de prestataires de services linguistiques initiés par PCE et délégués.
-
Plusieurs chemins de sous-candidats pour un chemin candidat coloré initié par PCE ne sont pas pris en charge.
-
Il n’est pas possible de déléguer des entités comportant plusieurs chemins de sous-candidats dans un chemin candidat.
Configuration
Pour permettre à PCCD d’envoyer la TLV de capacité multi-chemin dans l’objet LSP afin de notifier la liste de segments calculée maximale pour un chemin candidat spécifique, incluez l’instruction propagate-max-segmentlist
de configuration au niveau de la hiérarchie [edit protocols pcep
]. Par défaut, le TLV n’est pas envoyé dans l’objet LSP.
user@host# set protocols pcep propagate-max-computed-segmentlist;
Pour désactiver la session à fonctionnalités multiples PCEP pour tous les PCE, incluez l’instruction de disable-multipath-capability
configuration au niveau de la hiérarchie [edit protocols pcep
].
user@host# set protocols pcep disable-multipath-capability;
[edit protocols] pcep { disable-multipath-capability; propagate-max-segmentlist; }
Vous pouvez activer les traceoptions de protocole suivantes pour les diagnostics :
-
user@host# set protocols pcep traceoptions
... -
user@host# set protocols pcep pce pce1 traceoptions
... -
user@host# set protocols source-packet-routing traceoptions
Vous pouvez utiliser les commandes show suivantes pour afficher l’état des LSP dans PCC :
-
user@host> show path-computation-client lsp
: affiche l’état des chemins de commutation d’étiquettes (LSP) connus du client de calcul de chemin (PCC). -
user@host> show path-computation-client lsp extensive
: affiche un niveau de sortie étendu sur chaque LSP connu - LSP point à point et point à multipoint. -
user@host> show path-computation active-pce
: affiche l’état du multipath dans les sessions. -
user@host> show spring-traffic-engineering lsp detail
: affiche les détails d’entrée de l’ingénierie du trafic SPRING.
Activation de la sécurité de la couche transport pour les sessions PCEP
couche transport Sécurité (TLS) prend en charge l’authentification des pairs, le chiffrement et l’intégrité des messages. Vous pouvez activer TLS dans le client de calcul de chemin (PCC) pour établir une connexion TCP avec l’élément de calcul de chemin (PCE) tel que défini dans la RFC 8253. Cela crée une session PCEP sécurisée (PCEPS) pour transporter les messages PCEP.
Ce document décrit comment activer TLS pour les sessions PCEP afin de sécuriser les interactions avec PCE, y compris le lancement des procédures TLS, le mécanisme d’établissement de liaison TLS, les méthodes TLS pour l’authentification des pairs. Le transport sécurisé pour PCEP sur TLS est également connu sous le nom de PCEPS.
- Avantages de l’activation de TLS pour les sessions PCEP
- Activation de TLS dans le client de calcul de chemin (PCC)
- Mise à jour des certificats à l’aide de l’infrastructure à clé publique (PKI)
- Établissement d’une connexion TLS
- Comprendre le mécanisme d’établissement de liaison TLS de base
- Diagnostic et validation du protocole TLS pour les sessions PCEP
- Exemple de sortie
Avantages de l’activation de TLS pour les sessions PCEP
-
Protège les sessions PCEP contre les attaques telles que l’usurpation d’identité (PCC ou PCE), l’espionnage (interception de messages), la falsification et le déni de service.
-
Exploite les avantages de la sécurité TLS.
Activation de TLS dans le client de calcul de chemin (PCC)
Pour activer TLS dans PCC et établir une session PCEPS, définissez l’instruction tls-strict
CLI au niveau de la hiérarchie [edit protocols pcep
].
Après l’activation de l’instruction de configuration tls-strict, les événements suivants se produisent :
-
Volets de session PCEP. Toute connexion TCP existante est interrompue et une reconnexion est effectuée à l’aide de TLS.
-
Le PCC établit une connexion TCP avec le PCE.
-
Les procédures TLS sont initiées par le StartTLS message de PCE à PCC et de PCC à PCE. Le StartTLS message est envoyé par PCC et le StartTLSWait minuteur est démarré. Vous pouvez configurer le StartTLSWait minuteur en configurant l’instruction
start-tls-wait-timer seconds
CLI au niveau de la hiérarchie [edit protocols pcep pce pce-id
].REMARQUE :La valeur recommandée pour la minuterie est de 60 secondes et ne doit pas être inférieure à la StartTLSWaitOpenWait minuterie. La valeur par défaut OpenWait de la minuterie est définie sur 60 secondes.
-
Si le message Ouvert est reçu par PCC au lieu d’un message, PCErr un message dont le type d’erreur est défini sur 1 (échec de l’établissement d’une session PCEP) et la valeur d’erreur sur 1 (réception d’un message ouvert non valide ou d’un StartTLS message non ouvert) et la session TCP est fermée.
-
Si StartTLS le message n’est pas reçu de PCE, après l’expiration du minuteur, PCC envoie un PCErr message avec le type d’erreur défini sur 25 (échec PCEPStartTLS) et la valeur d’erreur définie sur 5 (aucun StartTLS message (ni PCErr/Open) avant StartTLSWait l’expiration du StartTLSWait minuteur), et la session TCP est fermée.
-
-
La négociation et l’établissement de la connexion TLS ont lieu.
-
L’échange de messages PCEP est démarré conformément à RFC5440.
Si vous n’activez pas l’instruction CLI sous le niveau hiérarchique [edit protocols pcep
], lors de l’établissement d’une session PCEP, si le message est reçu par PCC au lieu d’un message, PCErr d’un message dont le StartTLS type d’erreur est défini sur 1 (échec de l’établissement de la session PCEP) et la valeur d’erreur définie sur 1 (réception d’un message ouvert non valide ou d’un tls-strict
Open message non ouvert), la session TCP est fermée.
Pour établir une session PCEPS réussie, TLS doit être activé à la fois sur PCC et PCE.
Mise à jour des certificats à l’aide de l’infrastructure à clé publique (PKI)
La PKI n’informe pas le PCC de l’expiration du certificat. Vous devez mettre à jour manuellement le certificat à l’aide de la commande CLI suivante. Dans cette méthode, vous devez garder une trace de la date d’expiration du certificat.
user@host> request security pki local-certificates re-enroll certificate id
Établissement d’une connexion TLS
Les étapes suivantes décrivent comment une connexion TLS (à l’aide de TLS v1.2) est établie :
-
Générez des certificats pour les nœuds (Junos OS devices/pce-server). Vous pouvez générer les certificats à l’aide de l’une des méthodes suivantes :
-
Method 1: générez une paire de clés et une CSR sur l’appareil et envoyez cette CSR à l’autorité de certification pour obtenir le certificat. Une fois le certificat émis, il est copié dans la boîte et installé.
-
Method 2: générez une paire de clés et le certificat prêt à l’emploi. Le certificat et la clé privée sont copiés sur l’appareil et installés ensemble.
-
-
Chargez l’autorité de certification (CA) sur le PCC afin que le certificat du serveur PCE puisse être validé par rapport à l’autorité de certification chargée.
user@host# set security pki ca-profile pccd-tls ca-identity pccd-tls user@host# commit
user@host> request security pki ca-certificate load ca-profile pccd-tls filename /var/tmp/ca.crt
REMARQUE :Les autorités de certification peuvent être chargées dans une hiérarchie plate en tant qu’autorités de certification indépendantes. Si une autorité de certification est une sous-autorité de certification d’une autre autorité de certification, la chaîne est construite en interne par PKI.
REMARQUE :Le certificat du serveur doit être signé par une autorité de certification. Les certificats autosignés ne sont pas autorisés.
-
Activez TLS sur PCC.
-
La session PCEP est établie via TLS avec un mécanisme d’établissement de liaison TLS.
-
Le serveur PCE écoute le port 4189 pour les demandes de connexion PCC entrantes via TLS.
-
PCC lance la demande de connexion au port de destination 4189.
-
À la fin d’une négociation à trois voies, l’établissement de liaison TLS commence par l’utilisation des certificats et l’authentification unidirectionnelle est effectuée (PCC authentifie le certificat du serveur). Le serveur et le client attendent StartTLSWait le temps de recevoir le StartTLS message. Vous pouvez configurer le StartTLSWait minuteur en configurant l’instruction
start-tls-wait-timer seconds
CLI au niveau de la hiérarchie [edit protocols pcep pce pce-id
].REMARQUE :La valeur recommandée pour la minuterie est de 60 secondes et ne doit pas être inférieure à la StartTLSWaitOpenWait minuterie. La valeur par défaut OpenWait de la minuterie est définie sur 60 secondes.
-
Une fois la session d’établissement de liaison TLS réussie, PCC et PCE initie l’établissement d’une session PCEP sur TLS, au cours de laquelle les paramètres de session sont négociés.
-
Si la validation du certificat échoue, PCC met fin à la connexion TCP.
-
-
Le message PCEP est envoyé via une connexion TLS en tant que données d’application.
-
Le chiffrement et le déchiffrement se produisent à la fois sur PCC et PCE après une négociation TLS réussie.
-
Lorsque la session PCEP est fermée, la session TLS est supprimée.
Si le certificat a expiré, est révoqué ou rechargé au cours d’une session PCEP sur TLS en cours, la session en cours n’est pas affectée.
Comprendre le mécanisme d’établissement de liaison TLS de base
L’établissement de liaison est une série de messages échangés entre un serveur et un client. Les étapes exactes de l’établissement d’une liaison varient en fonction de l’algorithme d’échange de clés, de la suite de chiffrement, etc. Voici les étapes de base du mécanisme d’établissement de liaison TLS :
-
Client Hello: le client initie l’établissement de liaison en envoyant ce message. Ce message contient la version de TLS, la liste des algorithmes cryptographiques ou de la suite de chiffrement pris en charge, ainsi que d’autres détails sur le client.
-
Server Hello: le serveur répond à Client Hello en envoyant un message Sever Hello. Ce message contient le certificat du serveur, l’algorithme cryptographique sélectionné, l’ID de session et la clé publique du serveur.
-
Authentication: le client en arrière-plan vérifie le certificat du serveur à l’aide de l’autorité de certification configurée qui a émis le certificat. Une fois la vérification réussie, le client confirme que le serveur est authentique et continue d’interagir.
-
Optional Client Certificate: si le serveur a demandé un certificat au client dans le message Server Hello, le client envoie le certificat client (uniquement en cas de TLS mutuel).
-
Client Key Exchange: le client envoie une clé secrète chiffrée avec la clé publique du serveur (acquise dans le message Server Hello).
-
Decrypt secret key: le serveur déchiffre la clé secrète à l’aide de la clé privée.
-
Client Finished: le client envoie un message de fin qui est chiffré avec la clé secrète partagée et signale la fin de l’établissement de liaison.
-
Server Finished: le serveur répond par un message de fin chiffré avec la clé secrète partagée et signale que l’établissement de liaison est terminé.
-
Exchange Messages: les messages après la fin de l’établissement de liaison sont chiffrés symétriquement.
Diagnostic et validation du protocole TLS pour les sessions PCEP
Pour les diagnostics, utilisez les instructions CLI traceoptions suivantes :
user@host# set protocols pcep traceoptions … user@host# set protocols pcep pce pce-id traceoptions … user@host# set protocols source-packet-routing traceoptions
Activez les journaux PKI à l’aide de la configuration suivante et capturez le même fichier à partir de /var/log/<filename>
user@host# set security pki traceoptions file <filename> user@host# set security pki traceoptions flag all sss
Vérifiez le certificat d’autorité de certification chargé à l’aide de la commande suivante :
user@host> show security pki ca-certificate detail
Exemple de sortie
Voici un exemple de sortie de show path-computation-client statistics
commande :
user@host> show path-computation-client statistics Warning: License key missing; requires 'PCEP' license PCE ns1 -------------------------------------------- General PCE IP address : 192.168.18.1 Local IP address : 190.168.18.101 Priority : 0 PCE status : PCE_STATE_UP Session type : PCE_TYPE_STATEFULACTIVE LSP provisioning allowed : On P2MP LSP report allowed : On P2MP LSP update allowed : On P2MP LSP init allowed : On Session SRv6 Capable : No PCE-mastership : main PCE Traffic Steering : Off PCC TLS Enabled : Yes PCE TLS Enabled : Yes Session TLS Enabled : Yes Counters PCReqs Total: 0 last 5min: 0 last hour: 0 PCReps Total: 0 last 5min: 0 last hour: 0 PCRpts Total: 0 last 5min: 0 last hour: 0 PCUpdates Total: 0 last 5min: 0 last hour: 0 PCCreates Total: 0 last 5min: 0 last hour: 0 Timers Local Keepalive timer: 0 [s] Dead timer: 0 [s] LSP cleanup timer: - [s] Remote Keepalive timer: 0 [s] Dead timer: 0 [s] LSP cleanup timer: - [s] Errors PCErr-recv PCErr-sent PCE-PCC-NTFS PCC-PCE-NTFS Pcupdate empty ero action counters Send-err : 0 Tear down path : 0 Routing decision : 0 Routing decision failed: 0
Cet exemple de sortie fournit les informations suivantes :
-
TLS est activé au niveau du PCC.
-
Le PCE est compatible TLS.
-
La session TLS est établie. Cela indique également que le certificat du serveur PCE est valide.
-
L’état de la session PCEPS est en cours d’exécution.
Optimisation du chemin de création de rapports et mesures calculées dans PCEP
L’objet métrique dans PCEP est utilisé à plusieurs fins. L’objet Metric indique le type de métrique utilisé pour l’optimisation du chemin. L’objet métrique indique également une limite sur le coût du chemin qui ne doit pas être dépassée pour que le chemin soit considéré comme acceptable. L’objet metric indique également la métrique calculée.
Nous prenons en charge les objets de mesure pour l’optimisation des chemins (protocole de passerelle intérieure, ingénierie du trafic et délai de chemin) et la génération de rapports sur les mesures calculées pour les LSP RSVP et SR-TE.
L’objet Metric pour l’optimisation des chemins et la création de rapports sur la métrique calculée ne s’applique pas aux LSP SRv6-TE.
- Avantages de l’optimisation du chemin de création de rapports et des mesures calculées dans PCEP
- Comprendre les mesures d’optimisation
- Configuration des métriques d’optimisation pour les LSP
- Exemple de sortie
Avantages de l’optimisation du chemin de création de rapports et des mesures calculées dans PCEP
-
La création de rapports sur les mesures d’optimisation de chemin configurées dans PCC aide PCE à connaître les contraintes utilisées pour le calcul de chemin.
-
Reporting des métriques calculées au PCE. Cela permet à PCE d’analyser si le LSP nécessite une optimisation supplémentaire.
Comprendre les mesures d’optimisation
La section suivante décrit les mesures d’optimisation prévues et réelles pour les LSP RSVP et SR-TE (SR MPLS) dans PCEP.
- LSP RSVP créé localement
- RSVP délégué LSP
- LSP RSVP initié par le PCE
- SR-TE LSP DÉLÉGUÉ
- SR-TE LSP initié par PCE
- Envoi d’une métrique d’optimisation dans un message PCRpt
- Envoi d’une métrique calculée dans un message PCRpt
- Incompatibilité descendante pour la métrique de route
LSP RSVP créé localement
Pour optimiser les LSP RSVP créés localement avec des mesures, configurez les mesures d’optimisation (IGP, TE et délai de chemin) afin que la mesure configurée soit signalée via PCEP. La métrique calculée est envoyée en tant que métrique réelle dans PCEP via le message PCRpt.
RSVP délégué LSP
Pour générer des rapports sur les mesures d’optimisation pour les LSP RSVP délégués, configurez les mesures d’optimisation (IGP, TE et délai de chemin).
Intended Metric:
-
Lorsque la métrique d’optimisation est configurée au moment de la délégation du LSP, les informations sont envoyées à PCE par le biais d’un message PCRpt.
-
Lorsque la métrique d’optimisation est configurée après la délégation du LSP, la modification est appliquée sur le LSP/communiquée au PCE lorsque l’état du contrôle LSP devient contrôlé localement.
-
Lorsque le message PCUpd est reçu, si une métrique d’optimisation est présente dans le message, la métrique est utilisée comme métrique prévue dans les messages PCRpt suivants jusqu’à ce que l’état du contrôle LSP soit contrôlé en externe.
-
Lorsque le message PCUpd est reçu, si la métrique d’optimisation n’est pas présente dans le message, les messages PCRpt suivants ne contiennent pas la métrique prévue.
-
Lorsque l’état du contrôle LSP passe à contrôle local, la métrique d’optimisation configurée à partir de l’interface de ligne de commande Junos est la métrique prévue dans le message PCRpt.
Actual Metric:
-
Lors de la délégation du LSP, le message PCRpt ne contient pas de métrique réelle.
-
Lorsque le message PCUpd est reçu, si une métrique calculée est présente dans le message, la métrique est utilisée comme métrique réelle dans les messages PCRpt suivants jusqu’à ce que l’état du contrôle LSP soit contrôlé en externe.
-
Lorsque le message PCUpd est reçu, si la métrique calculée n’est pas présente dans le message, les messages PCRpt suivants ne contiennent pas de métrique réelle.
-
Lorsque l’état du contrôle LSP passe à contrôlé localement, la métrique calculée par PCC est envoyée en tant que métrique réelle dans le message PCRpt.
LSP RSVP initié par le PCE
Pour générer des rapports sur les mesures d’optimisation pour les LSP RSVP initiés par PCE, configurez les mesures d’optimisation (IGP, TE et délai de chemin) dans un modèle. Le modèle est ensuite appliqué au LSP initié par PCE lorsque l’état de contrôle du LSP devient contrôlé localement.
Intended Metric:
-
Lorsqu’un LSP initié par PCE est mappé à un modèle avec une métrique d’optimisation, la configuration est appliquée au LSP et envoyée au PCE lorsque l’état du contrôle LSP passe à contrôlé localement.
-
Lorsque le message PCInit/PCUpd est reçu, si une métrique d’optimisation est présente dans le message, la métrique est utilisée comme métrique prévue dans les messages PCRpt suivants jusqu’à ce que l’état du contrôle LSP soit contrôlé en externe.
-
Lorsque le message PCInit/PCUpd est reçu, si la métrique d’optimisation n’est pas présente dans le message, les messages PCRpt suivants ne contiennent pas la métrique prévue.
-
Lorsque l’état du contrôle LSP devient contrôlé localement, la métrique d’optimisation présente dans le modèle est utilisée comme métrique prévue dans le message PCRpt.
Actual Metric:
-
Lorsque le message PCInit/PCUpd est reçu, si la métrique calculée est présente dans le message, la métrique est utilisée comme métrique réelle dans les messages PCRpt suivants jusqu’à ce que l’état du contrôle LSP soit contrôlé en externe.
-
Lorsque le message PCInit/PCUpd est reçu, si la métrique calculée n’est pas présente dans le message, les messages PCRpt suivants ne contiennent pas de métrique réelle.
-
Lorsque l’état du contrôle LSP passe à contrôlé localement, la métrique calculée par PCC est envoyée en tant que métrique réelle dans le message PCRpt.
SR-TE LSP DÉLÉGUÉ
Pour générer des rapports sur les mesures d’optimisation pour les LSP SR-TE (SR MPLS) délégués, configurez les mesures d’optimisation (IGP, TE et délai de chemin).
Intended Metric:
-
Lorsque la métrique d’optimisation est configurée au moment de la délégation du LSP, les informations sont envoyées au PCE via le message PCRpt.
-
Lorsque la métrique d’optimisation est configurée après la délégation du LSP, la modification est appliquée sur le LSP/communiquée au PCE lorsque l’état du contrôle LSP devient contrôlé localement.
-
Lorsque le message PCUpd est reçu, si une métrique d’optimisation est présente dans le message, la métrique est utilisée comme métrique prévue dans les messages PCRpt suivants jusqu’à ce que l’état du contrôle LSP soit contrôlé en externe.
-
Lorsque le message PCUpd est reçu, si la métrique d’optimisation n’est pas présente dans le message, les messages PCRpt suivants ne contiennent pas la métrique prévue.
-
Lorsque l’état du contrôle LSP passe à contrôle local, la métrique d’optimisation configurée à partir de l’interface de ligne de commande Junos est la métrique prévue dans le message PCRpt.
Actual Metric:
-
Lorsque LSP est délégué après la création, au moment de la délégation LSP si LSP a 1 ERO, les valeurs calculées des métriques IGP, TE et delay sont envoyées en tant que métriques réelles dans le message PCRpt.
-
Lorsque le LSP est délégué après la création, au moment de la délégation du LSP, si le LSP a plusieurs ERO, la métrique calculée/la métrique réelle n’est pas envoyée dans le message PCRpt, car la métrique réelle doit être envoyée par LSP (et non par ERO) dans PCEP.
-
Lorsque le message PCUpd est reçu, si une métrique calculée est présente dans le message, la métrique est utilisée comme métrique réelle dans les messages PCRpt suivants jusqu’à ce que l’état du contrôle LSP soit contrôlé en externe.
-
Lorsque le message PCUpd est reçu, si la métrique calculée n’est pas présente dans le message, les messages PCRpt suivants ne contiennent pas de métrique réelle.
-
Lorsque l’état du contrôle LSP passe à contrôlé localement, les mesures IGP, TE et de retard calculées dans PCC sont envoyées en tant que mesures réelles dans le message PCRpt.
SR-TE LSP initié par PCE
Les métriques prévues ou les métriques réelles envoyées par PCE dans les messages PCInit/PCUpd sont transmises à PCE via un message PCRpt jusqu’à ce que le LSP soit contrôlé en externe.
Intended Metric:
-
Lorsque le message PCInit/PCUpd est reçu, si une métrique d’optimisation est présente dans le message, la métrique est utilisée comme métrique prévue dans les messages PCRpt suivants jusqu’à ce que l’état du contrôle LSP soit contrôlé en externe.
-
Lorsque le message PCInit/PCUpd est reçu, si la métrique d’optimisation n’est pas présente dans le message, les messages PCRpt suivants ne contiennent pas la métrique prévue.
-
Lorsque l’état du contrôle LSP devient contrôlé localement, la métrique prévue n’est pas envoyée.
Actual Metric:
-
Lorsque le message PCInit/PCUpd est reçu, si une métrique calculée est présente dans le message, la métrique est utilisée comme métrique réelle dans les messages PCRpt suivants jusqu’à ce que l’état du contrôle LSP soit contrôlé en externe.
-
Lorsque le message PCInit/PCUpd est reçu, si la métrique calculée n’est pas présente dans le message, les messages PCRpt suivants ne contiennent pas de métrique réelle.
-
Lorsque l’état du contrôle LSP passe à contrôlé localement, les messages PCRpt suivants ne contiennent pas de métrique réelle.
Envoi d’une métrique d’optimisation dans un message PCRpt
La métrique d’optimisation est envoyée au PCE par le biais du intended-attributes-list
message PCRpt. La valeur de la métrique est définie sur 0 et les drapeaux B, C sont définis sur 0. Le type de mesure indique la mesure à optimiser.
Envoi d’une métrique calculée dans un message PCRpt
La métrique calculée est envoyée au PCE par le biais du actual-attributes-list
message PCRpt. La valeur de la métrique est la valeur de la métrique calculée et le type de métrique indique le type de métrique calculé. L’indicateur B est défini sur 0, l’indicateur C est défini sur 1.
Incompatibilité descendante pour la métrique de route
Étant donné que la métrique de route est prise en charge à l’aide du TLV du fournisseur, PCC ne traitera pas la métrique de route envoyée dans l’objet métrique par Juniper PCE prenant en charge Northstar et les versions antérieures de Paragon Pathfinder.
Configuration des métriques d’optimisation pour les LSP
Vous pouvez configurer des mesures d’optimisation (IGP, TE et path delay) pour les LSP RSVP et les LSP SR-TE.
Pour configurer les mesures d’optimisation IGP, TE et de délai de chemin pour les LSP RSVP, incluez l’instruction metric-type <igp|te|delay|delay minimum>
CLI au niveau de la hiérarchie [edit protocols mpls label-switched-path <lsp-name>
].
Pour configurer les mesures d’optimisation IGP, TE et de délai de chemin pour les LSP SR-TE, incluez l’instruction metric-type <igp|te|delay|delay minimum>
CLI au niveau de la hiérarchie [edit protocols source-packet-routing compute-profile <compute-profile-name>
].
Exemple de sortie
Vous pouvez utiliser les show path-computation-client lsp
commandes et show path-computation-client lsp extensive
CLI pour afficher l’état des chemins de commutation d’étiquettes (LSP) connus du client PCC (Path Computation Client).
Voici un exemple de sortie de show path-computation-client lsp extensive
:
user@host> show path-computation-client lsp extensive name sr_lsp
LSP Name : sr_lsp
PathName : -
From : 192.168.1.101
To : 192.168.1.106
Path Setup Type : spring-te
State : Up
Active Path : Yes
Link Protection : none
LSP Type : ext-provised
P2mp tree : NULL
Path cspf status : external_cspf
Controller : ns1
Template : NULL
PLSP-ID : 31
LSP-ID : 0
RSVP Error : 0x0
Requested AutoBw : 0bps
Record Route : (Label=299792)
From PCE ERO (received) : (Label=299792)
From RPD ERO (reported) : (Label=299792)
Configured ERO on PCC : Not Supported
Bandwidth:
Intended : 98.76Kbps
Actual : 0bps
Intended Metric:
Metric type Bound Optimization
IGP 0 TRUE
Actual Metric:
Metric type Computed value
IGP 50
Route Metric : 50
Mapped Flowspec (FS-Ids) : -
LSP Attributes:
Exclude-Any: 0, Include-Any: 0, Include-All: 0
Setup Priority: 0, Hold-Priority: 0
Local Protection Bit: FALSE
Last Rpt/Pcreqest received from RPD at : 22:15:32.000
Last Update sent to PCE at : 16:00:00.000
Last PcUpdate/PcCreate received from PCE at : 22:15:32.000
Last error sent to PCE at : 16:00:00.000
Last 5 reasons to send Report/Pcrequest : , , , ,
La sortie montre que le LSP est optimisé avec le type de métrique IGP. La valeur calculée de la métrique IGP est 50. La métrique Route installée dans la table de routage est 50.
Tableau de l'historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l' Feature Explorer pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.
external cspf
chemin sont introduits pour les LSP contrôlés par PCE : local cspf
et no cspf
.