Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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.

Figure 1 : Séance du PCEPSéance du PCEP

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

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.

Figure 2 : Exemple d’ingénierie de trafic MPLSExemple d’ingénierie de trafic MPLS

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.

Figure 3 : PCC et RSVP-TEPCC et 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.

REMARQUE :

À 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 :

  1. 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.

  2. 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 timerdelegation 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 le delegation 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 le lsp 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-timerdelegation-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.

  3. 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.

Figure 4 : Exemple PCE pour MPLS RSVP-TEExemple PCE pour MPLS RSVP-TE

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.

Tableau 1 : Applicabilité des configurations MPLS et LSP existantes à 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.

  • admin-group

  • Bande passante automatique

  • limite de saut

  • moins de remplissage

  • remplissage le plus

  • Aléatoire

  • admin-group

  • groupes d’administrateurs

  • admin-group-étendu

  • limite de saut

  • Pas de CSPF

  • minuterie d’optimisation intelligente

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.

  • Largeur de bande

  • principal

  • Priorité

  • Priorité

Ces instructions de configuration ne peuvent pas être configurées en même temps que la configuration PCE.

  • P2MP (en anglais)

  • Modèle

  • p2mp-lsp-next-hop

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 cspfchemin 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 le local 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 inclus no-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 inclus no-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 timerdelegation 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

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 :

  • Utilisation du trousseau d’authentification prédéfini :

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.

REMARQUE :
  • 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 et show 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.

REMARQUE :

Le package complémentaire JSDN doit être installé avec le package d’installation principal de Junos OS.

Avant de commencer :

  1. Configurez les interfaces de l’appareil.

  2. Configurez MPLS et RSVP-TE.

  3. 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.

REMARQUE :

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] .

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.

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

Figure 5 : Configuration de PCEP pour MPLS RSVP-TEConfiguration de PCEP pour MPLS RSVP-TE

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 :

  1. 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 est PCC-to-R2 PCC-R0-R1-R2. La bande passante est de 10 m et les valeurs de priorité de configuration et de PCC-to-R2 maintien sont 4.

  2. 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.

  3. 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.

  4. À 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 de PCC-to-R2 maintien sont 3.

  5. 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

R0

R1

R2

R3

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 :

REMARQUE :

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.

  1. 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.

  2. Activez RSVP sur toutes les interfaces du routeur PCC, à l’exception de l’interface de gestion.

  3. Configurez le chemin de commutation d’étiquettes (LSP) du routeur PCC au routeur R2 et activez le contrôle externe des LSP par le PCE.

  4. 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.

  5. Activez MPLS sur toutes les interfaces du routeur PCC, à l’exception de l’interface de gestion.

  6. Configurez IS-IS sur toutes les interfaces du routeur PCC, à l’exception de l’interface de gestion.

  7. Définissez le PCE auquel le routeur PCC se connecte, puis configurez l’adresse IP du PCE.

  8. Configurez le port de destination pour le PCC du routeur qui se connecte à un PCE à l’aide du PCEP basé sur TCP.

  9. Configurez le type PCE.

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.

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

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.

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.

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.

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.

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

Figure 6 : Exemple de LSP point à point initié par PCE pour MPLS RSVP-TEExemple de LSP point à point initié par PCE pour MPLS RSVP-TE

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 :

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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

R1

R2

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 :

REMARQUE :

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.

  1. 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.

  2. Activez RSVP sur toutes les interfaces du PCC, à l’exception de l’interface de gestion.

  3. Activez le contrôle externe des LSP par les PCE.

  4. Activez MPLS sur toutes les interfaces du PCC, à l’exception de l’interface de gestion.

  5. Configurez OSPF sur toutes les interfaces du PCC, à l’exception de l’interface de gestion.

  6. Définissez le groupe PCE et activez la prise en charge des LSP initiés par PCE pour le groupe PCE.

  7. Définissez les PCE qui se connectent au PCC.

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.

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

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.

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.

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.

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 :

  1. En mode configuration, accédez au niveau hiérarchique suivant :
  2. Spécifiez le nombre maximal de messages par minute que le PCC peut recevoir.
  3. Spécifiez le nombre de chemins de commutation d’étiquettes (LSP) provisionnés en externe sur tous les PCE connectés que le PCC peut accepter au maximum.
  4. Spécifiez l’ID unique défini par l’utilisateur pour le PCE connecté afin de configurer les paramètres PCE.
  5. Spécifiez la durée (en secondes) que le PCC doit attendre avant de rendre le contrôle des LSP au processus de protocole de routage après la déconnexion d’une session PCEP.
  6. Spécifiez l’adresse IPv4 du PCE avec lequel vous souhaitez vous connecter.
  7. Spécifiez le numéro de port TCP utilisé par le PCE

    La valeur peut être comprise entre 1 et 65535 et la valeur par défaut est 4189.

  8. Spécifiez la durée (en secondes) que le PCC doit attendre avant de supprimer tout LSP initié par le PCE non délégué du PCE défaillant après la fin d’une session PCEP.
  9. Configurez le PCC pour qu’il accepte les SP provisionnés en externe par les PCE connectés. Par défaut, le PCC rejette les LSP initiés par PCE.
  10. Spécifiez le nombre de messages inconnus par minute que le PCC peut recevoir au maximum après lequel la session PCEP est fermée.

    La valeur peut être comprise entre 1 et 16384 et la valeur par défaut est 0 (désactivé ou aucune limite).

  11. Spécifiez le nombre maximal de demandes inconnues par minute que le PCC peut recevoir au maximum, après quoi la session PCEP est terminée.

    La valeur peut être comprise entre 0 et 16384 et la valeur par défaut est 5. La valeur 0 désactive cette instruction.

  12. Configurez le type PCE.
  13. Spécifiez le délai (en secondes) pendant lequel le PCC doit attendre une réponse avant de renvoyer une demande.

    La valeur peut être comprise entre 0 et 65535 secondes.

  14. Vérifiez et validez la configuration.

Exemple de sortie

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

Figure 7 : Exemples de LSP point-à-multipoint contrôlés par PCEExemples de LSP point-à-multipoint contrôlés par PCE

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 :

  1. 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.

  2. 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.

  3. 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.

  4. À 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.

  5. 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

R1

R2

R3

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 :

  1. 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.

  2. Configurez le numéro du système autonome pour le routeur PCC.

  3. Activez RSVP sur toutes les interfaces du routeur PCC, à l’exception de l’interface de gestion.

  4. Activez MPLS sur toutes les interfaces du routeur PCC, à l’exception de l’interface de gestion.

  5. Configurez un LSP dynamique et désactivez le calcul automatique du chemin pour le LSP.

  6. Configurez les LSP point à multipoint et définissez l’entité de calcul de chemin externe pour le LSP.

  7. Activez le calcul de chemin externe pour les LSP MPLS et attribuez un modèle pour les LSP provisionnés en externe.

  8. Configurez les LSP qui disposent d’un contrôle local et qui sont remplacés par les paramètres LSP fournis par PCE.

  9. Configurez des stratégies de groupe d’administration MPLS pour le calcul LSP à chemin contraint.

  10. Attribuez les stratégies de groupe d’administration configurées aux interfaces PCC du routeur.

  11. Configurez une stratégie d’importation de base de données d’ingénierie du trafic (TED).

  12. Configurez un groupe interne BGP.

  13. Configurez l’ingénierie du trafic pour BGP et attribuez la stratégie d’exportation.

  14. Configurez la zone OSPF 0 sur toutes les interfaces point à multipoint du routeur PCC.

  15. Configurez la zone OSPF 0 sur l’interface point à point du routeur PCC.

  16. Activez l’ingénierie du trafic pour OSPF.

  17. Définissez le PCE auquel le routeur PCC se connecte, puis configurez les paramètres PCE.

  18. Configurez le PCC du routeur pour activer la fonctionnalité LSP point à multipoint pour le calcul de chemin externe.

  19. Configurez la stratégie d’ingénierie du trafic.

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.

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.

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.

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

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).

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

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 :

    1. L’équipement d’entrée construit un LSP en empilant les étiquettes des liens qu’il souhaite traverser.

    2. 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.

    3. 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.)

    4. 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 :

  1. Calcule le chemin du LSP de routage de segments.

  2. Provisionne le LSP sur le client de calcul de chemin (PCC) à l’aide des extensions de routage de segments PCEP.

  3. Analyse les extensions de routage de segments PCEP.

  4. 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 :

  1. 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.

  2. 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.

  3. 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 :

  1. Reste en place pendant 300 secondes.

  2. 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.

REMARQUE :

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.

REMARQUE :

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.

Tableau 2 : Mappage de la source LSP de segment routing avec la hiérarchie de configuration

Source du LSP de Segment Routing

Hiérarchie de configuration

  • LSP traduits automatiquement

  • LSP statiques

Liste des segments primaires à l’adresse [edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

LSP calculés (CSPF distribués)

Liste des segments primaires du chemin de routage source à l’adresse suivante :

  • [edit protocols source-packet-routing source-routing-path lsp-name primary path-name compute profile-name]

  • [edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

LSP dynamiques

Liste des segments primaires du modèle de chemin de routage source à l’adresse suivante :

  • [edit protocols source-packet-routing source-routing-path-template template-name primary primary-segment-list-name]

  • [edit protocols source-packet-routing source-routing-path-template template-name]

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.

Tableau 3 : Interaction PCEP Délégation LSP

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

  1. Un message PCReport est envoyé au PCE pour délégation. Le PCReport ne contient que des contraintes et des détails de chemin (tels que ERO).

  2. PCE calcule le chemin pour LSP et signale que le chemin est à l’état inactif.

  3. Aucun itinéraire n’est programmé par le LSP local tant que le contrôleur n’a pas calculé l’ERO et n’a pas notifié le résultat au PCC via PCUpdate.

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

  1. Un PCReport est envoyé au PCE pour délégation. Le PCReport ne contient que des contraintes et des détails de chemin (tels que ERO).

  2. Un segment primaire correspondant est délégué au PCE.

  3. PCE calcule le chemin pour le LSP.

  4. Le segment principal continue de contribuer à l’itinéraire, tel que déterminé par la configuration ou le calcul local, jusqu’à ce qu’une PCUpdate soit reçue du PCE.

    • Si Seamless BFD (S-BFD) n’est pas configuré pour le segment principal, il n’y a plus de mise à jour de la route et l’état LSP n’est pas non plus surveillé et signalé au PCE. À cet endroit, l’état LSP est indiqué comme étant actif ou inactif, selon que le calcul du chemin a réussi ou non à ce moment-là.

    • Si S-BFD est configuré pour le segment primaire, l’état du segment primaire est suivi et signalé au PCE. Si BFD détecte que le segment primaire est inactif, le chemin principal correspondant est supprimé de l’itinéraire. Le même itinéraire qui a été calculé précédemment est reprogrammé si ce chemin est maintenant actif.

  5. Si un message PCUpdate est reçu du PCE, SR-TE utilise le paramètre received pour définir le chemin d’accès pour lequel le message PCReport a été envoyé. Le chemin programmé n’inclut alors que la liste de segments reçue du PCE, et toutes les autres listes de segments précédemment programmées sont supprimées. Cette reprogrammation de l’itinéraire se fait de manière à faire avant de rompre.

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.

  • Sous le modèle de chemin de routage source : la fonctionnalité de délégation est déclenchée pour l’ensemble du chemin de routage source.

    Les configurations de modèle ne peuvent être appliquées qu’au module Tunnel dynamique.

  • Sous le chemin principal dans le modèle de chemin de routage source : la fonctionnalité de délégation est déclenchée pour ce chemin principal particulier en fonction de la configuration.

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 :

  1. 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é.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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 :

  1. 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.

  2. 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.

Figure 8 : Segment Routing pour le PCEPSegment Routing pour le PCEP

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

Routeur R1

Routeur R2

Routeur R3

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 :

  1. Configurez les interfaces du PCC.

  2. Configurez l’ID du routeur et attribuez un numéro de système autonome au PCC.

  3. 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é.

  4. Configurez RSVP sur toutes les interfaces du PCC, à l’exception de l’interface de gestion.

  5. Configurez MPLS sur toutes les interfaces du PCC, à l’exception de l’interface de gestion.

  6. Activez la capacité de calcul de chemin externe pour MPLS.

  7. Configurez IS-IS niveau 2 sur toutes les interfaces du PCC, à l’exception des interfaces de gestion et de bouclage.

  8. Configurez les attributs de bloc global de routage de segments (SRGB) pour le routage de segments.

  9. Activez la capacité de calcul de chemin externe pour SR-TE.

  10. Configurez les paramètres PCE et activez le provisionnement du LSP par le PCE et la capacité de routage de segments.

  11. Activez le provisionnement des LSP de routage de segments par le PCE.

  12. Activez la fonctionnalité de routage de segments pour le PCE.

  13. Définissez les paramètres de la liste static_seg_list_1 statique des segments.

  14. Configurez un LSP de routage de segment statique du PCC vers le routeur R3 pour la délégation PCE.

  15. Activez la capacité de délégation pour le static_srte_lsp_1 chemin de routage source.

    En effectuant les étapes 13, 14 et 15, vous permettez au PCC de déléguer les LSP de routage de segments au PCE.

  16. Validez la configuration.

Résultats

À partir du mode de configuration, confirmez votre configuration en saisissant les commandes show interfaces, show routing-optionset show protocols . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé 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
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 extensivecommandes , show isis database extensive, et show isis overview .

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.

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 lspcommandes , show spring-traffic-engineering lsp detail, et show route protocol spring-te .

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_lspde nœud, respectivement.

Le LSP static_srte_lsp_1de 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 controlledExternally 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.

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.

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 .

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

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

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 color au niveau de la [edit protocols source-packet-routing source-routing-path lsp-name] hiérarchie.

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

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

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.

REMARQUE :

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.

Tableau 4 : Résolution LSP statique non colorée basée sur 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 inherit-label-nexthops configuration)

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 inherit-label-nexthops configuration)

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 :

REMARQUE :

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 :

    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 :

    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

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 :

  • Voici un exemple de configuration pour le modèle LSP de routage de segments dynamiques sans couleur :

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 :

Pour l’exemple de configuration mentionné ci-dessus, les entrées de route sont les suivantes :

  1. inetcolor.0 tunnel route: 10.22.44.0-0/24 --> RT_NH_TUNNEL

  2. 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

  3. inetcolor.0 tunnel route:

    10.22.44.55-101/64 --> &lt;next-hop>

    10.22.44.55-124/64 --> &lt;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 :

Pour l’exemple de configuration mentionné ci-dessus, les entrées de route sont les suivantes :

  1. inet.3 tunnel route: 10.33.44.0/24 --> RT_NH_TUNNEL

  2. 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

  3. inet.3 tunnel route: 10.33.44.55/32 --> &lt;next-hop>

LSP Segment Routing dynamique non résolu

Exemple de configuration pour les LSP de routage de segments dynamiques non résolus :

Pour l’exemple de configuration mentionné ci-dessus, les entrées de route sont les suivantes :

  1. inetcolor.0 tunnel route: 10.33.44.0 - 0/24 --> RT_NH_TUNNEL 10.1.1.0 - 0 /24 --> RT_NH_TUNNEL

  2. 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ême spring-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’option color-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’option spring-teprimary 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

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-exportde 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 :

Ou

REMARQUE :

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.

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-importde 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 :

Ou

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-importde 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 :

Vous pouvez appliquer une stratégie d’importation à l’instance de routage du service VPN.

Vous pouvez également appliquer la stratégie d’importation à un groupe BGP ou à un voisin BGP.

REMARQUE :

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 :

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.

Figure 9 : BGP IPv6 LU sur IPv6 SR-TE coloréBGP IPv6 LU sur IPv6 SR-TE coloré

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 :

  1. 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.

  2. 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é.

  3. 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 de lsp correspondance et lsp-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’acceptation sr-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.

Figure 10 : Chemin de commutation d’étiquette de segment routing statiqueChemin de commutation d’étiquette de segment routing 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.

PE1

PE2

PE3

PE4

PE5

CE1

CE2

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 :

  1. Configurez les interfaces.

  2. Configurez le numéro et les options du système autonome pour contrôler les options de routage de transfert de paquets.

  3. Configurez les interfaces avec le protocole MPLS et configurez la plage d’étiquettes MPLS.

  4. 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.

  5. Configurez les interfaces de la zone de protocole.

  6. 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).

  7. 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.

  8. Configurez les options de stratégie.

  9. Configurez les informations de la communauté BGP.

  10. 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.

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.

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.

  1. Configurez les interfaces.

  2. Configurez le LSP statique pour le protocole MPLS.

  3. Configurez les interfaces et la plage d’étiquettes statiques pour le protocole MPLS.

  4. Configurez les interfaces pour le protocole OSPF.

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.

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
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.

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.

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.

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.

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.

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.

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

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 computesegment-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

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.

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.

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.

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

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 :

  1. Définissez la liste des segments avec les paramètres d’étiquette.

    Par exemple :

  2. Configurez le chemin de routage source pour les LSP SR-TE et spécifiez la valeur de préférence et le segment principal du chemin.

    Par exemple :

Vous pouvez désormais configurer CBF et PBR pour les LSP SR-TE configurés.

Pour configurer CBF, procédez comme suit

  1. 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.

    Par exemple :

  2. Définissez des classes de transfert (FC) pour regrouper les paquets à transmettre et affectez les paquets aux files d’attente de sortie.

    Par exemple :

  3. Affectez les classificateurs configurés aux interfaces de périphériques.

    Par exemple :

  4. Définissez des options de stratégie de transfert basées sur CoS avec LSP next-hop comme SR-TE LSP.

    Par exemple :

  5. Ignorer le trafic qui ne répond à aucune classe de transfert dans la carte de saut suivant.

    Par exemple :

  6. 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.

    Par exemple :

  7. 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.

    Par exemple :

  8. Validez la configuration.

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.

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

  1. 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.

    Par exemple :

  2. 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.

  3. 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.

    Par exemple :

  4. Validez la configuration.

Verify PBR Configuration

Vous pouvez vérifier la configuration PBR à l’aide de la show route destination-prefix commande.

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.

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.

REMARQUE :

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 :

Tableau 5 : Messages d’erreur PCEP
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.

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].

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

  • 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 :

  1. Volets de session PCEP. Toute connexion TCP existante est interrompue et une reconnexion est effectuée à l’aide de TLS.

  2. Le PCC établit une connexion TCP avec le PCE.

  3. 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.

  4. La négociation et l’établissement de la connexion TLS ont lieu.

  5. L’échange de messages PCEP est démarré conformément à RFC5440.

REMARQUE :

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-strictOpen message non ouvert), la session TCP est fermée.

REMARQUE :

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.

Établissement d’une connexion TLS

Les étapes suivantes décrivent comment une connexion TLS (à l’aide de TLS v1.2) est établie :

  1. 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.

  2. 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.

    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.

  3. Activez TLS sur PCC.

  4. La session PCEP est établie via TLS avec un mécanisme d’établissement de liaison TLS.

  5. Le serveur PCE écoute le port 4189 pour les demandes de connexion PCC entrantes via TLS.

  6. PCC lance la demande de connexion au port de destination 4189.

  7. À 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.

  8. 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.

  9. Le message PCEP est envoyé via une connexion TLS en tant que données d’application.

  10. Le chiffrement et le déchiffrement se produisent à la fois sur PCC et PCE après une négociation TLS réussie.

  11. Lorsque la session PCEP est fermée, la session TLS est supprimée.

REMARQUE :

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 :

  1. 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.

  2. 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.

  3. 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.

  4. 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).

  5. Client Key Exchange: le client envoie une clé secrète chiffrée avec la clé publique du serveur (acquise dans le message Server Hello).

  6. Decrypt secret key: le serveur déchiffre la clé secrète à l’aide de la clé privée.

  7. 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.

  8. 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é.

  9. 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 :

Activez les journaux PKI à l’aide de la configuration suivante et capturez le même fichier à partir de /var/log/<filename>

Vérifiez le certificat d’autorité de certification chargé à l’aide de la commande suivante :

Exemple de sortie

Voici un exemple de sortie de show path-computation-client statistics commande :

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.

REMARQUE :

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

  • 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

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:

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.

Version
Description
21.R1
À partir de Junos OS version 21.1R1, Junos OS prend en charge le routage actif continu (NSR) pour les LSP point à point et point à multipoint RSVP initiés par PCE.
21.R1
À partir de Junos OS version 21.1R1, Junos OS prend en charge le routage actif ininterrompu (NSR) pour les LSP point à multipoint RSVP initiés par PCE.
20.2R1
À 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.
19.4R1
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.
19.4R1
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.
19.1R1
À 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.
19.1R1
À 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.
18.2R1
À 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).
17.2R1
À partir de Junos OS version 17.2, en plus de , deux nouveaux types de calcul de external cspfchemin sont introduits pour les LSP contrôlés par PCE : local cspf et no cspf.
16.1
À 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.
16.1
Junos OS version 16.1 introduit la fonctionnalité de sécurisation d’une session PCEP à l’aide de l’authentification TCP-MD5 conformément à RFC 5440.
14.2R4
À 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.