Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

PCEP Configuration

Présentation du PCEP

Un élément de calcul de chemin (PCE) est une entité (composant, application ou nœud réseau) capable de calculer un chemin ou un routage réseau en fonction d’un graphique du réseau et d’appliquer des contraintes de calcul. Un client de calcul de chemin (CCP) est une application cliente demandant un calcul de chemin à effectuer par un PCE. Le protocole PCEP (Path Computation Element Protocol) permet de communiquer entre un CCP et un PCE, ou entre deux PCE (défini dans la RFC 5440).

PCEP est un protocole TCP défini par le groupe de travail PCE de l’IETF, qui définit un ensemble de messages et d’objets utilisés pour gérer les sessions PCEP et demander et envoyer des chemins pour les LSP techniques de trafic multidomaine (TE LSP). Il fournit un mécanisme permettant à un PCE d’effectuer le calcul des chemins pour les LSP externes d’un CCP. Les interactions PCEP comprennent des rapports d’état LSP envoyés par le CCP au PCE, et des mises à jour PCE pour les LSP externes.

Figure 1 illustre le rôle du PCEP dans l’implémentation côté client d’une architecture PCE dynamique dans un réseau MPLS compatible RSVP-TE.

Figure 1 : PCEP SessionPCEP Session

Une session PCEP basée sur TCP connecte un CCP à un PCE externe. Le CCP lance la session PCEP et reste connecté au PCE pendant toute la durée de la session PCEP. Pendant la session PCEP, le CCP demande des paramètres LSP au PCE à états. Dès qu’il reçoit un ou plusieurs paramètres LSP du PCE, le CCP signale à nouveau le LSP TE. Lorsque la session PCEP est terminée, la connexion TCP sous-jacente est immédiatement fermée et le CCP tente de rétablir la session PCEP.

Ainsi, les fonctions PCEP comprennent :

  • Synchronisation de l’état du tunnel LSP entre un CCP et un PCE à états : lorsqu’une connexion PCE active est détectée, un CCP tente de déléguer tous les LSP à ce PCE dans une procédure appelée synchronisation de l’état LSP. LE PCEP permet la synchronisation de l’état LSP de CCP avec le PCE.

  • Délégation de contrôle sur les tunnels LSP à un PCE à états : un PCE à états 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 maintien). Le PCEP permet une telle délégation de LSP pour le calcul des chemins.

  • Contrôle PCE dynamique de la synchronisation et de la séquence des calculs de chemins au sein et entre les sessions PCEP – Un PCE actif à états 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 CCP, après quoi le PCEP signale le LSP dans le chemin spécifié.

Prise en charge du protocole Path Computation Element Protocol pour la présentation de RSVP-TE

Comprendre MPLS RSVP-TE

L’ingénierie du trafic (TE) traite de l’optimisation des performances des réseaux opérationnels, en mappant principalement les flux de trafic sur une topologie physique existante. L’ingénierie du trafic permet de déplacer le flux de trafic du chemin le plus court sélectionné par le protocole IGP (Interior Gateway Protocol) vers un chemin physique potentiellement moins encombré sur un réseau.

Pour l’ingénierie du trafic dans les grands réseaux denses, les fonctionnalités MPLS peuvent être implémentées, car elles fournissent potentiellement la plupart des fonctionnalités disponibles à partir d’un modèle overlay, de manière intégrée et à un coût inférieur aux alternatives concurrentes. La principale raison d’implémenter l’ingénierie du trafic MPLS est de contrôler les chemins sur lesquels le trafic transite par un réseau. Le principal avantage de l’implémentation de l’ingénierie de trafic MPLS est qu’elle offre une combinaison des capacités d’ingénierie de trafic d’ATM, ainsi que de la différenciation de la classe de service (CoS) de l’IP.

Dans un réseau MPLS, les informations du plan de données sont transférés à l’aide de la commutation d’étiquettes. Un paquet arrivant sur un routeur de périphérie du fournisseur (PE) depuis le routeur de périphérie du client (CE) a des étiquettes qui lui sont appliquées, puis il est transféré au routeur PE sortant. Les étiquettes sont retirées au niveau du routeur sortant et elles sont ensuite acheminées vers 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 via les LSR. RSVP-TE est l’un de ces protocoles de distribution d’étiquettes qui permet à un pair LSR d’en savoir plus 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 Junos OS RSVP 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 à l’ingénierie du trafic MPLS pour permettre au RSVP de configurer des LSP pouvant être utilisés pour l’ingénierie de trafic dans les réseaux MPLS.

Lorsque MPLS et RSVP sont combinés, les labels sont associés aux flux RSVP. Une fois qu’un LSP est établi, le trafic à travers le chemin est défini par le label appliqué au nœud d’entrée du LSP. Le mappage des étiquettes au trafic s’effectue à l’aide de différents critères. L’ensemble de paquets auxquels un nœud spécifique attribue la même valeur de label appartiennent à la même classe d’équivalence de transfert (FEC) et définissent efficacement le flux RSVP. Lorsque le trafic est mappé sur un LSP de cette façon, le LSP est appelé tunnel LSP.

Les tunnels LSP sont un moyen d’établir des chemins unidirectionnels à commutation d’étiquettes. La RSVP-TE s’appuie sur le protocole central 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), OBJET RECORD-ROUTE (RRO), OBJET LABEL et OBJET EXPLICIT-ROUTE (ERO) sont facultatifs en ce qui concerne le protocole RSVP, à l’exception des objets LRO et LABEL, qui sont tous deux obligatoires pour l’établissement de tunnels LSP.

En général, le RSVP-TE établit un chemin de commutation d’étiquettes qui assure la distribution des trames de l’entrée au routeur sortant. 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 à commutation d’étiquettes à l’aide d’un routage explicite complet ou partiel (RFC 3209).

  • Établissement LSP basé sur des contraintes sur des liaisons qui répondent à des exigences, telles que la bande passante et les propriétés de liaison.

  • Le contrôle des terminaux, associé à l’établissement et à la gestion des tunnels LSP au niveau des routeurs entrants et sortants.

  • Gestion des liaisons, qui gère les ressources de liaison pour effectuer un routage conscient des ressources des LSP techniques de trafic et pour programmer les labels MPLS.

  • Reroutage rapide MPLS (FRR), qui gère les LSP qui doivent être protégés et attribue des informations de tunnel de secours à ces LSP.

Limites actuelles du RSVP-TE MPLS

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 rencontre plusieurs problèmes inhérents à sa nature distribuée. Cela provoque un certain nombre de problèmes lors de la contestation de 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 du RSVP-TE sont les suivantes :

  • Manque de visibilité sur les besoins individuels de bande passante par LSP et par équipement : 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 ne sont disponibles que sous forme de capacité réservée totale par classe de trafic par interface. 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 des chemins 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 une limitation du trafic envoyé par le tunnel. Par conséquent, la bande passante disponible sur une liaison d’ingénierie du trafic est la bande passante configurée pour la liaison, à l’exclusion de la somme de toutes les réservations effectuées sur la liaison. Ainsi, les demandes non signées sur un tunnel LSP entraînent une dégradation du service du LSP nécessitant une bande passante excédentaire, ainsi que les autres LSP qui répondent aux exigences de bande passante de la liaison d’ingénierie du trafic.

  • LSP établis sur la base d’options de chemin dynamiques ou explicites dans l’ordre de préférence : les routeurs entrants d’un réseau MPLS RSVP-TE établissent des LSP 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 baisse du trafic ou un LSP ne pas être établi du tout en cas d’excès de demande de bande passante.

Par exemple, Figure 2 il est configuré avec MPLS RSVP-TE, 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 ou contrôle sur les LSP les uns des autres. Les routeurs B, C et D sont des routeurs intermédiaires ou de transit qui se connectent aux routeurs sortants E et F.

Figure 2 : Exemple d’ingénierie du trafic MPLS Exemple d’ingénierie du 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) par le biais de G-B-D-F. De même, 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 augmente de 10 à 15, le routeur A ne peut pas signaler 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 à l’aide du 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, le LSP3 n’est pas signalé.

Ainsi, bien que la bande passante de flux maximal soit suffisante pour tous les LSP, le LSP3 est susceptible d’entraîner une dégradation des services potentiellement prolongée. Cela est dû au manque de visibilité du routeur A sur la demande mondiale et au manque de coordination systémique du placement de la demande par les routeurs entrants A et G.

Utilisation d’une entité de path computing externe

Pour répondre aux limites actuelles du calcul des chemins MPLS RSVP-TE, une entité de calcul de chemin externe avec une vue globale par LSP, la demande par équipement sur le réseau, indépendamment de la capacité disponible, est nécessaire.

Actuellement, seul le calcul des chemins de routage en ligne et en temps réel basé sur des contraintes 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 de topologie actuellement disponibles, qui sont généralement récentes, mais pas complètement 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 la CLI. Un opérateur configure le LSP TE, qui est ensuite signalé par le routeur entrant.

Outre les fonctionnalités d’ingénierie du trafic existantes, la fonctionnalité MPLS RSVP-TE est étendue pour inclure une entité de calcul de chemin externe, appelée Path Computing Element (PCE). Le PCE calcule le chemin pour les LSP TE des routeurs entrants qui ont été configurés pour un contrôle externe. Le routeur entrant qui se connecte à un PCE s’appelle un client de calcul de chemin (CCP). Le CCP est configuré avec le protocole PCEP (Path Computation Client Protocol) pour faciliter le calcul de chemins externes par un PCE.

Pour plus d’informations, reportez-vous à la section Composants du path computing externe.

Pour activer le calcul des chemins externes pour les LSP TE d’un PCC, incluez l’instruction lsp-external-controller pccd au niveau et [edit mpls lsp lsp-name] de la [edit mpls] hiérarchie.

Composants du path computing externe

Les composants qui composent un système de calcul des chemins externes sont :

Élément de calcul de chemin

Un élément de calcul de chemin (PCE) peut être n’importe quelle entité (composant, application ou nœud réseau) capable de calculer un chemin ou un routage réseau en fonction d’un graphique du réseau et d’appliquer des contraintes de calcul. Toutefois, un PCE ne peut calculer le chemin que pour les LSP TE d’un CCP qui ont été configurés pour un contrôle externe.

Un PCE peut être à états ou sans état.

  • PCE à états : un PCE à états maintient une synchronisation stricte entre le PCE et les états du réseau (en termes d’informations sur la topologie et les ressources), ainsi que l’ensemble de chemins calculés et de ressources réservées utilisés dans le réseau. En d’autres termes, un PCE à états utilise des informations provenant de la base de données d’ingénierie du trafic ainsi que des informations sur les chemins existants (par exemple, les LSP TE) dans le réseau lors du traitement de nouvelles demandes provenant du CCP.

    Un PCE à états est de deux types :

    • PCE passif à états : maintient la synchronisation avec le CCP et apprend les états LSP du PCC pour mieux optimiser les calculs de chemin, mais n’a pas de contrôle sur eux.

    • PCE actif à états : modifie activement les LSP PCC, en plus d’en apprendre plus sur les états LSP de CCP.

      REMARQUE :

      Dans une configuration redondante avec des PCE principaux et actifs de secours, le PCE actif de sauvegarde à états ne peut pas modifier les attributs des LSP délégués jusqu’à ce qu’il devienne le PCE principal au moment d’un basculement. Il n’y a pas de préempting 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 prend 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 à états fournit les fonctions suivantes :

    • Offre un calcul de chemin LSP hors ligne.

    • Déclenche le reroutoir 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 l’ERO, la priorité de configuration et le maintien de la priorité.

    Un PCE a une vue globale de la demande de bande passante sur le réseau et gère une base de données conçue pour le trafic pour effectuer des calculs de chemins. Il collecte des statistiques auprès de tous les routeurs du domaine MPLS à l’aide de SNMP et NETCONF. Cela fournit un mécanisme pour le contrôle hors ligne des LSP TE de PCC. Bien qu’un système de calcul des chemins LSP hors ligne puisse être intégré à un contrôleur réseau, le PCE agit comme un contrôleur réseau à part entière qui fournit un contrôle sur les LSP TE de PCC, en plus des chemins informatiques.

    Bien qu’un PCE à états permette un calcul de chemin optimal et une meilleure réussite du calcul des chemins, il nécessite des mécanismes de synchronisation d’état fiables, avec des coûts de plan de contrôle potentiellement importants 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 requêtes est traité indépendamment les unes des autres (RFC 5440).

Client de calcul de chemin

Un client de calcul de chemin (CCP) est une application cliente demandant un calcul de chemin à effectuer par un PCE.

Un CCP peut se connecter à un maximum de 10 PCE à la fois. La connexion DE PCC à PCE peut être une route statique configurée ou une connexion TCP qui établit l’accessibilité. Le CCP attribue à chaque PCE connecté un numéro de priorité. Il envoie un message à tous les PCE connectés avec des informations sur leurs LSP actuels, dans le cadre d’un processus appelé synchronisation de l’état LSP. Pour les LSP TE dont le contrôle externe est activé, le CCP délègue ces LSP au PCE principal. Le CCP choisit, en tant que PCE principal, un PCE avec le numéro de priorité le plus bas, ou le PCE à qui il se connecte en premier en l’absence d’un numéro de priorité.

Le CCP signale 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 CCP choisit un nouveau PCE principal, et tous les LSP délégués au PCE principal précédemment sont délégués au PCE principal nouvellement disponible.

Protocole Path Computing Element

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 TCP défini par le groupe de travail PCE de l’IETF, qui définit un ensemble de messages et d’objets utilisés pour gérer les sessions PCEP et demander et envoyer des chemins pour les LSP TE multidomaines. Les interactions PCEP comprennent des messages CCP, ainsi que des notifications d’états spécifiques liés à l’utilisation d’un PCE dans le contexte de MPLS RSVP-TE. Lorsque le PCEP est utilisé pour la communication PCE à PCE, le PCE demandeur assume le rôle d’un CCP.

Ainsi, les fonctions PCEP comprennent :

  • Synchronisation de l’état du tunnel LSP entre CCP et un PCE à états.

  • Délégation de contrôle sur les tunnels LSP à un PCE dynamique.

Interaction entre un PCE et un CCP à l’aide de PCEP

Figure 3 illustre la relation entre un PCE, un CCP et le rôle du PCEP dans le contexte de MPLS RSVP-TE.

Figure 3 : PCC et RSVP-TE PCC et RSVP-TE

La communication PCE-PCC est activée par le PCEP basé sur TCP. Le CCP lance la session PCEP et reste connecté à un PCE pendant toute la durée de la session PCEP.

REMARQUE :

À partir de la version 16.1 de Junos OS, 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 de la [edit protocols pcep pce pce-id] hiérarchie pour 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 CCP 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 équipements, 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 CCP effectue les tâches suivantes :

  1. Synchronisation de l’état LSP : le CCP envoie des informations sur tous les LSP (locaux et externes) à tous les PCE connectés. Pour les LSP externes, le CCP envoie des informations sur toute modification de configuration, de RRO, de changement d’état, etc. au PCE.

    Pour les LSP initiés par PCE, il n’y a pas de configuration LSP présente sur le CCP. Le PCE qui lance le LSP envoie les paramètres LSP au CCP qui a indiqué sa capacité à prendre en charge les LSP initiés par 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 LSP synchronisées, le CCP délègue ensuite les LSP externes à un PCE, qui est le PCE actif principal. Seul le PCE principal peut définir des paramètres pour le LSP externe. Les paramètres que le PCE principal modifie comprennent la bande passante, le chemin (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 CCP choisit un nouveau PCE principal, et tous les LSP délégués au PCE principal précédemment sont délégués au PCE principal nouvellement disponible.

    Dans le cas des LSP initiés par le PCE, le CCP crée le LSP à l’aide des paramètres reçus du PCE. Le CCP attribue au LSP initié par le PCE un LSP-ID unique et délègue automatiquement le LSP au PCE. Un CCP ne peut révoquer la délégation des LSP initiés par le PCE pour une session PCEP active.

    Lorsqu’une session PCEP s’arrête, le CCP lance deux timers sans supprimer immédiatement les LSP initiés par PCE – delegation cleanup timeout et lsp cleanup timer – pour éviter toute perturbation des services. Pendant ce temps, un PCE actif à états peut acquérir 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 sur les LSP initiés par PCE revient au CCP à l’expiration du delegation cleanup timeout. Lorsque le delegation cleanup timeout PCE expire et qu’aucun autre PCE n’a acquis le contrôle sur le LSP du PCE défaillant, le CCP prend le contrôle local du LSP non délégué initié par le PCE. Plus tard, lorsque le PCE original ou un nouveau PCE actif souhaite acquérir le contrôle des LSP pilotés localement par le PCE, le PCC délègue ces LSP au PCE et le lsp cleanup timer timer est arrêté.

    Un PCE peut renvoyer la délégation du LSP initié par le PCE au CCP pour permettre le transfert de LSP entre les PCE. Cela déclenche le lsp cleanup timer LSP initié par le PCE. Le CCP attend l’expiration du timer de nettoyage LSP avant de supprimer les LSP non délégués initiés par le PCE du PCE défaillant.

    Lorsque le lsp cleanup timer PCE expire et qu’aucun autre PCE n’a acquis le contrôle sur les LSP du PCE défaillant, le CCP supprime tous les LSP provisionnés par le PCE défaillant.

    REMARQUE :

    Conformément au projet-ietf-pce-stateful-pce-09, la révocation des délégations LSP à l’initiative du PCE par un CCP se fait de façon « make-before-break » avant que les LSP ne soient relégués à un autre PCE. À partir de junos OS version 18.1R1, le lsp-cleanup-timer doit être supérieur ou égal au delegation-cleanup-timeout pour que le CCP puisse révoquer les délégations LSP. Si ce n’est pas le cas, l’intervalle de délai de relégation pour le CCP peut être défini à l’infini, où les délégations LSP à ce PCE restent intactes jusqu’à ce que le CCP ait pris des mesures spécifiques pour modifier les paramètres définis par le PCE.

  3. Signalisation LSP : après avoir reçu un ou plusieurs paramètres LSP du PCE principal actif, le CCP signale de nouveau le LSP TE en fonction du chemin fourni par le PCE. Si le CCP ne parvient pas à configurer le LSP, il informe le PCE de l’échec de la configuration et attend que le PCE principal fournisse de nouveaux paramètres pour ce LSP, puis le signale à nouveau.

    Lorsque le PCE spécifie un chemin incomplet ou dont les sauts sont libres où seuls les points de terminaison de chemin sont spécifiés, le CCP n’effectue pas de routage local basé sur des contraintes pour connaître l’ensemble complet des sauts. Au lieu de cela, le PCC fournit RSVP avec le chemin fourni par PCE, en l’tant que tel, pour la signalisation, et le chemin est configuré à l’aide du routage IGP hop-by-hop.

Compte tenu de la topologie utilisée dans Figure 2, Figure 4 illustre l’implémentation PCE côté client partiel dans le réseau MPLS RSVP-TE. Les routeurs entrants A et G sont les PCC configurés pour se connecter au PCE externe à états via une connexion TCP.

Le PCE a une vue globale de la demande de bande passante sur le réseau et effectue des calculs de chemins externes après avoir consulté la base de données d’ingénierie du trafic. Le PCE actif à états modifie ensuite un ou plusieurs attributs LSP et envoie une mise à jour au PCC. Le CCP utilise les paramètres qu’il reçoit du PCE pour signaler à nouveau le LSP.

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

De cette façon, le PCE à états fournit une opération coopérative de fonctionnalités distribuées utilisées pour résoudre les problèmes spécifiques d’un calcul de chemin interdomaine restreint le plus court. Il élimine les scénarios de congestion dans lesquels les flux de trafic sont mal mappés aux ressources disponibles, entraînant une surutilisation de certains sous-ensembles de ressources réseau, tandis que d’autres ressources restent sous-utilisées.

Comportement LSP avec l’informatique 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 qui n’ont pas l’instruction lsp-external-controller pccd configurée sont appelés LSP contrôlés par CLI. Bien que ces LSP soient sous contrôle local, le CCP met à jour les PCE connectés avec des informations sur les LSP contrôlés par CLI lors du processus de synchronisation LSP initial. Après la synchronisation LSP initiale, le CCP informe également le PCE des LSP nouveaux et supprimés.

  • LSP contrôlés par PCE : les LSP dont l’instruction lsp-external-controller pccd est configurée sont appelés LSP contrôlés par PCE. Le CCP délègue les LSP initiés par CCP au PCE principal pour le calcul des chemins externes.

    Le CCP 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 des valeurs réelles utilisées pour ces paramètres pour configurer le LSP, y compris le RRO, lorsqu’ils sont disponibles.

    Le CCP envoie ces rapports d’état LSP au PCE uniquement lorsqu’une reconfiguration a eu lieu ou en cas de modification de l’ERO, du RRO ou de 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 comprennent la bande passante, le chemin et la priorité (valeurs de configuration et de maintien). Lorsque le mode contrôle passe de l’extérieur au local, les valeurs configurées par la CLI pour ces paramètres sont appliquées à l’occasion suivante pour signaler à nouveau le LSP. Les valeurs ne sont pas appliquées immédiatement.

  • LSP à provisionnement externe (ou LSP initiés par PCE) : les LSP sur 20000 dont l’instruction lsp-provisioning est configurée sont appelés LSP initiés par PCE. Un LSP initié par PCE est créé dynamiquement par un PCE externe ; par conséquent, il n’y a pas de configuration LSP présente sur le PCC. Le CCP 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 CCP.

Les LSP contrôlés par CLI et les LSP contrôlés par PCE peuvent coexister sur un CCP.

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

  • 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 CCP utilise les paramètres fournis par PCE pour configurer le LSP.

  • Local : un LSP contrôlé par PCE peut être sous contrôle local. Lorsque le LSP passe d’un contrôle externe à un contrôle local, le calcul des chemins est effectué à l’aide des paramètres configurés par la CLI et du routage basé sur les contraintes. Un tel basculement n’a lieu que lorsqu’il y a un déclencheur pour signaler à nouveau le LSP. D’ici là, le CCP 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 commutateur LSP contrôlé par PCE vers un contrôle local à partir de son mode de contrôle externe par défaut dans des cas tels que l’absence 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 les LSP contrôlés par PCE, reportez-vous à la section LSP Types.

Déclarations de configuration prises en charge pour l’informatique 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 du LSP contrôlé par PCE

Déclarations de configuration LSP applicables

Déclarations de configuration MPLS applicables

Ces déclarations de configuration peuvent être configurées en même temps que la configuration PCE. Toutefois, elles ne prennent effet que lorsque la configuration locale est en cours d’utilisation. Pendant le contrôle PCE, ces instructions de configuration restent inactives.

  • admin-group

  • bande passante automatique

  • limite de sauts

  • le moins de remplissage

  • le plus rempli

  • Aléatoire

  • admin-group

  • groupes d’administrateurs

  • admin-group étendu

  • limite de sauts

  • no-cspf

  • timer optimisé intelligent

Ces instructions de configuration peuvent être configurées avec 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 pour 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 à états n’ont aucun effet sur le LSP. Ces modifications n’entrent en vigueur que lorsque la configuration locale est appliquée.

  • Bande passante

  • principal

  • Priorité

  • Priorité

Ces instructions de configuration ne peuvent pas être configurées avec la configuration PCE.

  • p2mp

  • Modèle

  • p2mp-lsp-next-hop

Le reste des 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 déclarations 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 le reroutage rapide et le contournement des LSP, sont calculés localement par le PCC à l’aide d’un routage basé sur des contraintes. Un PCE à états spécifie uniquement le chemin principal (ERO). Un PCE peut également déclencher un chemin secondaire non de réserve, même si la configuration locale n’a pas de chemin secondaire non de réserve pour la protection LSP.

ERO LSP contrôlé par PCE

Pour les LSP contrôlés par PCE (LSP délégués par CCP et LSP initated PCE), seul un objet ERO (Explicit Route Object) complet doit être envoyé du PCE au CCP ; dans le cas contraire, le PCC rejette le message PCUpdate ou PCCreate pour cette session PCEP.

À partir de la version 17.2 de Junos OS, deux external cspfnouveaux types de calcul de chemin sont introduits pour les LSP contrôlés par PCE : local cspf et no cspf.

  • local cspf— Un CCP utilise le type de local cspf calcul uniquement lorsque le PCE envoie un fournisseur Juniper TLV (numéro d’entreprise : 0x0a4c) du type 5.

  • no cspf: ni le PCE ni le CCP n’effectuent de calcul de chemin contraint. Les points de terminaison et les contraintes sont donnés au module RSVP pour configurer le LSP avec le chemin IGP.

    Un CCP utilise un no cspf 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é par PCC.

    • Lorsque le PCE envoie local cspf TLV, et lorsque le modèle de configuration Junos OS pour ce LSP 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 un bit lâche défini dans l’objet ERO).

Avec ces nouveaux types de calcul, un CCP peut accepter un objet ERO soit comme un ERO lâche, soit comme un ERO vide. Une entité de calcul de chemin externe qui n’est pas capable de calculer un chemin peut modifier des paramètres tels que la bande passante et la couleur, en fonction des analyses. Dans de tels cas, un objet ERO vide ou un ERO lâche est utilisé et le chemin à prendre est décidé par le CCP.

LSP RSVP-TE point à multipoint contrôlé par PCE

Une fois qu’une session PCEP est établie entre un PCE et un CCP, le CCP signale tous les LSP du système au PCE pour la synchronisation de l’état LSP. Cela inclut des LSP contrôlés par CCP, délégués par PCE et des LSP point à point initiés par LE PCE. À partir des versions 15.1F6 et 16.1R1 de Junos OS, cette fonctionnalité est étendue pour signaler les 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 une collection de LSP point à point regroupés sous un identifiant point à multipoint.

Par défaut, le contrôle PCE des LSP point à multipoint n’est pas pris en charge sur un CCP. Pour ajouter cette fonctionnalité, incluez l’instruction p2mp-lsp-report-capability au niveau ou [edit protocols pcep pce-group group-id] de la [edit protocols pcep pce pce-name] hiérarchie. Une fois que la fonctionnalité de rapport point à multipoint est configurée sur un CCP, le CCP annonce cette fonctionnalité au PCE. Si le PCE annonce la même fonctionnalité de rapport point à multipoint en retour, alors le CCP signale l’arbre LSP point à multipoint complet au PCE pour la synchronisation de l’état LSP.

Un CCP avec la fonctionnalité TE LSP point à multipoint prend en charge le reporting des TE LSP 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 par LE PCE et initiés par le 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 l’entrée de transfert sur les LSP point à multipoint initiés par PCE

  • Configuration de l’entrée de transfert sur le routeur pointant vers un LSP provisionné.

LSP point à point initiés par PCE

À partir de la version 16.1 de Junos OS, la fonctionnalité PCEP est étendue pour permettre à un PCE à états d’initier et de provisionner des LSP techniques de trafic via un CCP. Auparavant, les LSP étaient configurés sur le PCC et le CCP avait délégué le contrôle sur les LSP externes à un PCE. La propriété de l’état LSP a été maintenue par le PCC. Avec l’introduction des LSP initiés par PCE, un PCE peut lancer et provisionner dynamiquement un LSP d’ingénierie de trafic point à point sans avoir besoin d’un LSP configuré localement sur le PCC. Lors de la réception d’un message PCCreate d’un PCE, le CCP crée le LSP initié par le PCE et délègue automatiquement le LSP au PCE.

Par défaut, un CCP rejette la demande de provisionnement de LSP point à point initiés par PCE à partir d’un PCE. Pour permettre la prise en charge des LSP inités par PCE sur le PCC, incluez l’instruction lsp-provisionnement au niveau ou [edit protocols pcep pce-group group-id] de la [edit protocols pcep pce pce-id] hiérarchie.

Un CCP indique sa capacité à prendre en charge les LSP point à point initiés par PCE tout en établissant la session PCEP (Path Computation Element Protocol) avec le PCE. Un PCE choisit un CCP avec cette capacité pour lancer un LSP. Le PCE fournit au CCP les paramètres LSP initiés par LE PCE. Dès 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 qui lance le LSP ne fournit pas les paramètres LSP point à point initiés par PCE, le CCP utilise les paramètres par défaut. Un modèle LSP optionnel 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 de modèle de chemin de commutation d’étiquettes au niveau de la [edit protocols mpls lsp-external-controller lsp-external-controller] hiérarchie.

Lorsqu’une session PCEP s’arrête, le CCP lance deux timers sans supprimer immédiatement les LSP initiés par PCE etdelegation cleanup timeoutlsp cleanup timerpour éviter toute perturbation des services. Pendant ce temps, un PCE à états actif peut acquérir 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 CCP pour permettre le transfert LSP entre les PCE. Le contrôle sur les LSP initiés par PCE revient au CCP à 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 sur le LSP du PCE défaillant, le CCP prend le contrôle local du LSP non délégué initié par le PCE. Plus tard, lorsque le PCE original ou un nouveau PCE actif souhaite acquérir le contrôle des LSP point à point à l’initiative du PCE contrôlé localement, le PCC délègue ces LSP au PCE et le timer de nettoyage LSP est arrêté.

Le CCP attend l’expiration du timer de nettoyage LSP avant de supprimer les LSP point à point initiés par PCE non délégués du PCE défaillant. Lorsque le délai de nettoyage LSP expire et qu’aucun autre PCE n’a acquis le contrôle sur les LSP du PCE défaillant, le CCP supprime tous les LSP provisionnés par le PCE défaillant.

À partir de la version 21.1R1 de Junos OS, nous prenons en charge le routage actif sans interruption (NSR) pour les LSP point à point et point à multipoint pilotés par le PCE. Seul le moteur de routage principal maintient la session PCEP avec le contrôleur. Il synchronise tous les LSP RSVP initiés par des 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 les pertes 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 le NSR est configuré.

LSP de contournement initié par PCE

Comprendre les LSP de contournement initiés par PCE

Il peut y avoir des pannes de trafic au moment de la défaillance d’une liaison ou d’un nœud, car les chemins de protection de sauvegarde sur le réseau ne disposent pas de suffisamment de bande passante pour gérer le trafic. Dans de tels réseaux, même si un PCE peut être utilisé pour calculer tous les chemins, afin d’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 versions ultérieures fournissent une prise en charge partielle du projet Internet draft-cbrt-pce-stateful-local-protection-01 (expire en décembre 2018), des extensions PCEP pour RSVP-TE Local-Protection avec PCE-Stateful, où la fonctionnalité PCEP est étendue pour permettre à un PCE à états d’initier, de provisionner et de gérer les LSP de contournement pour une interface protégée. Le PCE peut lancer plusieurs LSP de contournement avec réservation de bande passante pour protéger une liaison ou un nœud. La bande passante du LSP de contournement devrait être inférieure à la bande passante totale des LSP primaires qu’il pourrait protéger.

Le mécanisme de sélection de contournement existant, qui préfère les LSP de contournement manuels (si disponibles) aux LSP de contournement dynamique, est étendu pour préférer les LSP de contournement provisionnés par PCE (le cas échéant) aux LSP de contournement dynamiques. Les LSP de contournement provisionnés par PCE ont une préférence plus élevée par rapport aux LSP de contournement dynamique, mais sont moins préférés aux LSP de contournement manuel.

L’ensemble des opérations utilisées pour effectuer tout LSP de contournement opérationnel, par exemple clear rsvp session, peut également être effectué sur les LSP de contournement 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 lancé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 des liaisons ou des nœuds.

    • doit avoir une bande passante non nulle.

    • doit avoir un ERO strict spécifié.

  • Mettez à jour la bande passante et l’ERO pour un LSP de contournement créé par PCE existant.

  • Sursabonnez la bande passante LSP de contournement pour le contrôle d’admission des LSP principaux. Il doit s’agir d’un paramètre par contournement et permettre la mise à jour de l’abonnement par contournement LSP.

Avantages du LSP de contournement piloté par 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 LSP, ainsi que leurs chemins de protection locaux.

  • Assurez-vous que les liaisons ne sont pas surchargées en cas de défaillance.

Comportement des LSP de contournement initiés par PCE lors d’une défaillance de session PCEP

Au moment d’une défaillance de session PCEP, les LSP de contournement initiés par PCE deviennent orphelins jusqu’à l’expiration du délai d’expiration d’état. Les LSP de contournement initiés par PCE sont nettoyés à l’expiration du timer d’état. Pour obtenir le contrôle d’un LSP de contournement initié par PCE (après l’échec de la session PCEP), un PCE (le PCE principal ou 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 à multipoints initiés par PCE, un PCE peut lancer et provisionner dynamiquement un LSP point à multipoint sans avoir besoin d’une configuration LSP locale sur le PCC. Cela permet au PCE de contrôler la synchronisation et la séquence des calculs de chemins 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, voir Understanding Path Computation Element Protocol pour MPLS RSVP-TE avec prise en charge des LSP point à multipoint initiés par PCE.

SRv6 LSP 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 par PCE, créés localement et délégués 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 SRv6 LSP créés sur le routeur.
  • Signalez au contrôleur les LSP créés localement sur le routeur.
  • La programmation réseau SRv6 offre la flexibilité nécessaire pour exploiter le routage de segments sans déployer MPLS.

LE PCEP prend en charge la création, l’updation et la suppression des SRv6 LSP colorés et non colorés initiés par PCE. Lorsque le SRv6 LSP initié par PCE coexiste avec un SRv6 LSP statique pour la même ADRESSE IP ou ip basée sur les couleurs, alors le routage contributif statique SRv6 TE LSP est préféré au routage contributif LSP SRv6 TE initié par PCE.

Pour configurer une session PCEP pour qu’elle soit compatible SRv6, vous devez activer l’instruction srv6-capability de configuration au niveau de [modifier les protocoles pcep pce pce-id] ou [] au niveau de la hiérarchie [edit protocols pcep pce-group pce-id]. Si l’instruction de srv6-capability 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 pendant la validation et l’erreur s’afficheront.

Pour configurer SRv6 pour SR-TE, vous devez ajouter l’instruction de configuration srv6 au niveau de la hiérarchie [modifier les protocoles source-packet-routing].

[Voir Comprendre la stratégie SR-TE pour le tunnel SRv6 pour plus d’informations.

Pour configurer la profondeur maximale de la liste de segments pour le SRv6 LSP, vous devez activer l’instruction de maximum-srv6-segment-list-depth configuration au niveau de la hiérarchie [edit protocols pcep].

Bande passante automatique et LSP contrôlé par PCE

À partir de la version 14.2R4 de Junos OS, la bande passante automatique est prise en charge pour les LSP contrôlés par PCE. Dans les versions précédentes, l’option 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 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 prenait effet uniquement 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 comme 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 à états automatise la création de chemins techniques de trafic sur l’ensemble du réseau, ce qui augmente l’utilisation du réseau et permet une expérience de mise en réseau programmable personnalisée grâce à la communication PCEP avec un PCC. Un CCP envoie des rapports LSP à un serveur PCE, et le PCE met à jour ou provisionne les LSP au CCP. Les données envoyées sur une session PCEP sont cruciales pour qu’un serveur PCE effectue des calculs de chemins externes. En conséquence, une attaque sur les communications PCEP peut perturber les services réseau. Si des messages PCEP modifiés sont envoyés à un CCP, 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 CCP dans l’exécution efficace des fonctionnalités PCE, Junos OS Version 16.1 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 PCC sur une session PCEP, qui peut faire l’objet 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 de la [edit protocols pcep pce pce-id] hiérarchie pour 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 CCP pour établir une session PCEP sécurisée avec un PCE :

  • Utilisation de la clé d’authentification MD5 :

  • À l’aide d’un keychain d’authentification prédéfini :

Pour que des 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 sur le serveur PCE et sur le PCC. Le PCE et le CCP utilisent la même clé pour vérifier l’authenticité de chaque segment envoyé sur la connexion TCP de la session PCEP.

REMARQUE :
  • La version 16.1 de Junos OS ne prend en charge que l’authentification TCP-MD5 pour les sessions PCEP, sans étendre la prise en charge de TLS et TCP-AO, comme la protection contre les écoutes clandestines, les altérations et la falsification de messages.

  • L’application initiale du mécanisme de sécurité à une session PCEP entraîne la réinitialisation de la session.

  • Si le MD5 est mal configuré ou non configuré d’un côté de la session PCEP, la session n’est pas établie. Vérifiez que les configurations du CCP 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 et show protocols pcep de show path-computation-client status commande.

  • Utilisez la show system statistics tcp | match auth commande pour afficher le nombre de paquets qui sont supprimés par TCP en raison d’erreurs d’authentification.

  • Le fonctionnement du trousseau peut être vérifié à l’aide de la sortie de show security keychain detail commande.

Impact de l’implémentation du PCE côté client sur les performances du réseau

La maintenance d’une base de données dynamique peut être non négligeable. Dans un seul environnement PCE centralisé, un PCE à états doit simplement se souvenir de tous les LSP TE calculés par le PCE, des LSP TE réellement configurés (si cela peut être connu) et de la date à laquelle les LSP TE ont été détruits. Toutefois, ces exigences entraînent des coûts de protocole de contrôle importants en termes d’état, d’utilisation et de traitement du réseau, et d’optimisation des liaisons à l’échelle mondiale sur le réseau. Ainsi, les préoccupations d’une implémentation PCE à états comprennent :

  • Tout mécanisme de synchronisation fiable entraîne des surcharges importantes 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 course deviennent plus importants et plus complexes.

  • La synchronisation de la base de données d’ingénierie du trafic hors bande peut être complexe avec plusieurs PCE configurés dans un modèle de calcul PCE distribué, et peut être sujette aux conditions de course, aux 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 tous les chemins, priorités et couches.

En dépit des préoccupations ci-dessus, l’implémentation partielle côté client du PCE à états est extrêmement efficace dans les systèmes d’ingénierie de trafic de grande taille. Il offre une convergence rapide et des avantages importants en termes d’utilisation optimale des ressources, en fournissant la nécessité d’une visibilité globale de l’état de 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 Protocol pour MPLS RSVP-TE

Cet exemple montre comment activer le calcul de chemins externes par un élément PCE (Path Computation Element) pour le trafic des chemins de commutation d’étiquettes (TESP) 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 vers PCC.

Conditions préalables

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

  • Trois routeurs pouvant être une combinaison de routeurs ACX Series, de routeurs de périphérie multiservice M Series, de plates-formes de routage universelles 5G MX Series, de routeurs centraux T Series ou de routeurs de transport PTX Series, dont l’un est configuré en tant que PCC.

  • Connexion TCP à un PCE à états externes à partir du PCC.

  • Junos OS Version 12.3 ou ultérieure s’exécutant sur le PCC avec le package complémentaire JSDN.

REMARQUE :

Le package complémentaire JSDN doit être installé en même temps que le package d’installation central Junos OS.

Avant de commencer :

  1. Configurez les interfaces de l’équipement.

  2. Configurez MPLS et RSVP-TE.

  3. Configurez IS-IS ou tout autre protocole IGP.

Présentation

À partir de la version 12.3 de Junos OS, la fonctionnalité MPLS RSVP-TE est étendue pour fournir une implémentation partielle côté client de l’architecture PCE à états (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-ietf-pce-stateful-pce. À partir de la version 16.1 de Junos OS, cette implémentation est mise à niveau pour prendre en charge la version 7, telle que définie dans le projet Internet draft-ietf-pce-stateful-pce-07. Les versions antérieures à la version 16.1 prennent en charge l’ancienne version du projet 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 à états qui adhère à Internet draft-ietf-pce-stateful-pce-07.

Pour activer le calcul des chemins externes par un PCE, incluez l’énoncé lsp-external-controller sur le CCP au niveau et [edit mpls lsp lsp-name] de la [edit mpls] hiérarchie.

Un LSP configuré avec l’instruction lsp-external-controller est appelé LSP contrôlé par PCE et est sous le contrôle externe d’un PCE par défaut. Un PCE actif à états peut remplacer les paramètres définis à partir de la CLI, 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 vers PCC, configurez PCEP sur le CCP au niveau hiérarchique [edit protocols] .

Lors de la configuration de PCEP sur un CCP, soyez conscient des considérations suivantes :

  • Le package complémentaire JSDN doit être installé en même temps que le package d’installation central Junos OS.

  • La version 12.3 de Junos OS ne prend en charge que les PCE à états.

  • Un CCP peut se connecter à un maximum de 10 PCE à états. À un moment donné, il ne peut y avoir qu’un seul PCE principal (le PCE avec la valeur de priorité la plus faible, ou le PCE qui se connecte d’abord au CCP en l’absence de priorité PCE) auquel le CCP délègue des LSP pour le calcul des chemins.

  • Pour Junos OS version 12.3, le CCP lance toujours les sessions PCEP. Les sessions PCEP initiées par des PCE distants ne sont pas acceptées par le CCP.

  • 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 l’auto-bandwdith 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 désignés par d’autres configurations CLI, telles que lsp-nexthop vers les routes, les adjacenances de transfert, les connexions CCC et les tunnels logiques.

  • Les LSP contrôlés par PCE ne prennent pas en charge GRES.

  • Les LSP contrôlés par PCE sous 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 des chemins externes, ce qui a un impact sur le temps de configuration global, les reroutages et les fonctionnalités make-before-break.

  • Le temps d’installation et le temps de convergence (reroutage, MBB) pour les LSP en cours d’expiration sont les mêmes que dans les versions précédentes, en l’absence de LSP contrôlés par PCE. Cependant, un petit impact est observé en présence de LSP contrôlés par PCE.

  • Le temps de calcul de l’ERO devrait être considérablement plus élevé que le CSPF local.

topologie

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

Dans cet exemple, LE PCC est le routeur entrant qui se connecte au PCE externe à états actifs.

Les LSP externes du routeur PCC sont calculés comme suit :

  1. Le routeur PCC reçoit la configuration de tunnel LSP configurée à l’aide de la CLI. En supposant que la configuration reçue est activée avec le calcul des chemins externes, le routeur PCC prend conscience que certains des attributs LSP (bande passante, chemin et priorité) sont sous le contrôle du PCE à états et délègue le LSP au PCE.

    Dans cet exemple, le LSP externe est appelé PCC-to-R2 et il est en cours de configuration du routeur PCC au routeur R2 . L’ERO configuré par CLI pour PCC-to-R2 est PCC-R0-R1-R2. La bande passante est de PCC-to-R2 10 m, et la configuration et les valeurs de priorité sont 4.

  2. Le routeur PCC essaie de récupérer les attributs LSP contrôlés par PCE. Pour ce faire, le routeur PCC envoie un message PCRpt au PCE à états 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 à états modifie un ou plusieurs attributs LSP délégués et envoie les nouveaux paramètres LSP au routeur PCC via le message PCUpd.

  4. Dès réception des nouveaux paramètres LSP, le routeur CCP configure un nouveau LSP et le signale à nouveau à l’aide du chemin fourni par PCE.

    Dans cet exemple, l’ERO fourni par PCE est PCC-to-R2 PCC-R3-R2. La bande passante est de PCC-to-R2 8 m, et les valeurs de priorité de configuration et de maintien sont 3.

  5. Le routeur PCC envoie un PCRpt avec le nouveau RRO au PCE à états.

Configuration

Configuration rapide cli

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

PCC

R0

R1

R2

R3

Procédure

Procédure étape par étape

Dans l’exemple suivant, vous devez parcourir différents niveaux de la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, voir Utilisation de l’éditeur CLI en mode de configuration.

Pour configurer le routeur PCC :

REMARQUE :

Répétez cette procédure pour chaque routeur entrant Juniper Networks 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 l’interface 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 CCP au routeur R2 et activez le contrôle externe des LSP par le PCE.

  4. Configurez le LSP du routeur PCC vers le 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 à lequel le routeur CCP se connecte et configurez l’adresse IP du PCE.

  8. Configurez le port de destination pour le routeur CCP 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 show interfaces commandes 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 fini de configurer l’équipement, saisissez commit à partir du 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 ROUTEUR PCC lorsque le statut PCE est opérationnel.

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 actif à états auxquels le routeur PCC est connecté. Le PCE status champ de sortie indique l’état actuel de la session PCEP entre le PCE et le routeur PCC.

Pour pce1, l’état de la session PCEP est PCE_STATE_UP, ce qui indique que la session PCEP a été établie entre les pairs PCEP.

Les statistiques indiquent PCRpts le nombre de messages envoyés par le routeur PCC au PCE pour signaler l’état actuel des LSP. Les PCUpdates statistiques indiquent le nombre de messages reçus par le routeur PCC de la part du PCE. Les PCUpdates messages incluent les paramètres modifiés du PCE pour les LSP contrôlés par PCE.

Vérification du statut 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 les champs de sortie indiquent que le LSP est contrôlé par l’extérieur. La sortie affiche également un journal des messages PCEP envoyés entre le routeur PCC et le PCE.

La session PCEP entre le PCE et le routeur CCP est allumée, et le routeur PCC reçoit les paramètres LSP contrôlés par PCE suivants :

  • ERO (chemin) — 20.31.4.2 et 20.31.5.2

  • Bandwidth—8Mbps

  • Priorités : 3 3 (valeurs de configuration et de maintien)

Vérification du statut 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 LSP Control Status champ de sortie indique que le LSP est sous contrôle local. Bien que le LSP contrôlé par PCE soit sous contrôle local, le routeur CCP continue d’utiliser les paramètres fournis par le PCE, jusqu’à la prochaine opportunité de signaler le LSP.

La sortie affiche désormais les paramètres LSP qui ont été configurés à l’aide de la CLI ainsi que les paramètres fournis par PCE utilisés pour établir le LSP comme valeurs réelles en utilisation.

  • Bande passante : 10 Mbit/s (largeur de bande réelle : 8 Mbit/s)

  • Priorités — 4 4 (priorités réelles 3 3)

Sur la gâchette pour signaler à nouveau le LSP, le routeur CCP utilise les paramètres de configuration locaux pour établir le LSP contrôlé par PCE.

Il Computed ERO s’agit de 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 Path Computation Element Protocol 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 PCE (Path Computation Element) initiés par le trafic et conçus par des LSP (Point-to-Point Label Switched Path).

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.

  • Connexion TCP à deux PCE à états externes du routeur d’entrée (PCC).

  • Junos OS Version 16.1 ou ultérieure s’exécutant sur le PCC.

Avant de commencer :

  • Configurez les interfaces de l’équipement.

  • Configurez MPLS et RSVP-TE (RSVP-Traffic Engineering).

  • Configurez OSPF ou tout autre protocole IGP.

Présentation

À partir de la version 16.1 de Junos OS, la fonctionnalité PCEP est étendue pour permettre à un PCE à états d’initier et de provisionner des LSP techniques de trafic via un CCP. Auparavant, les LSP étaient configurés sur le PCC et le CCP avait délégué le contrôle sur les LSP externes à un PCE. La propriété de l’état LSP a été maintenue par le PCC. Avec l’introduction des LSP initiés par PCE, un PCE peut lancer et provisionner dynamiquement un LSP d’ingénierie de trafic point à point sans avoir besoin d’un LSP configuré localement sur le PCC. Lors de la réception d’un message PCCreate d’un PCE, le CCP 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 CCP, prenez en compte les considérations suivantes :

  • La version 13.3 de Junos OS ne prend en charge que les PCE à états.

  • Pour la version 13.3 de Junos OS, le CCP lance toujours les sessions PCEP. Les sessions PCEP initiées par des PCE distants ne sont pas acceptées par le CCP.

  • 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 Routing Engine Switchover).

  • Les LSP initiés par PCE sous 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.

  • Le RSVP-TE pour les liaisons non numérotées 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 lance un LSP de routage de segments peut utiliser les labels SID (Binding Segment ID) associés aux LSP de routage de segments non colorés pour provisionner les chemins LSP de routage de segments initiés par PCE.

    À partir de la version 18.2R1 de Junos OS, les LSP de routage de segments non colorés configurés statiquement sur l’équipement entrant sont signalés à un PCE via une session PCEP. Ces LSP de routage de segments non colorés peuvent être associés à des labels SID liés. Grâce à cette fonctionnalité, le PCE peut utiliser ce label SID de liaison dans la pile de labels pour provisionner des chemins LSP de routage de segments initiés par PCE.

topologie

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

Dans cet exemple, LE PCC est le routeur entrant qui se connecte à deux PCE externes à états : PCE1 et PCE2.

En cas de nouvelle demande, le PCE actif à états lance dynamiquement un LSP pour répondre aux exigences. Étant donné que LE CCP est configuré avec la capacité de prendre en charge le LSP initié par PCE, le calcul des chemins sur CCP s’effectue comme suit :

  1. Un PCE envoie un message PCCreate au CCP pour lancer et provisionner un LSP. Le CCP 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 au PCE qui l’a initié.

    Dans cet exemple, PCE1 est le PCE actif à états qui lance et provisionne le LSP initié par PCE sur PCC. Lors de la réception des paramètres LSP initiés par le PCE, CCP configure le LSP et délègue automatiquement le LSP initié par le PCE à PCE1.

  2. Lorsque la session PCEP entre CCP et PCE1 est terminée, CCP lance deux timers pour le LSP initié par PCE1 : delgation nettoyage timeout et le timer de nettoyage LSP. Pendant ce temps, PCE1 ou PCE2 peut acquérir le contrôle du LSP initié par PCE.

  3. Si PCE2 acquiert le contrôle sur le LSP initié par le PCE avant l’expiration du timer de nettoyage LSP, CCP délègue le LSP initié par le PCE2, et le timer de nettoyage LSP et le délai de 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 acquis le contrôle sur le LSP initié par LE PCE, CCP prend le contrôle local du LSP non délégué initié par PCE jusqu’à l’expiration du timer de nettoyage LSP.

  5. Après l’expiration du timer de nettoyage LSP, CCP supprime le LSP initié par PCE provisionné par PCE1.

Configuration

Configuration rapide cli

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

PCC

R1

R2

Procédure

Procédure étape par étape

Dans l’exemple suivant, vous devez parcourir différents niveaux de la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, voir Utilisation de l’éditeur CLI en mode de configuration.

Pour configurer le routeur PCC :

REMARQUE :

Répétez cette procédure pour chaque routeur entrant Juniper Networks 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 l’interface 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 show interfaces commandes 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 fini de configurer l’équipement, saisissez commit à partir du mode de configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification de l’état du CCP

But

Vérifiez l’état de la session PCEP et le résumé LSP entre le CCP 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 à états actifs et le PCC. Il affiche également des informations sur les différents types de LSP sur le CCP, ainsi que le nombre de LSP provisionnés par les PCE connectés et délégués.

Le PCE1 est le principal PCE actif et dispose d’un LSP initié par le PCE qui lui a été automatiquement délégué par le PCC.

Vérification de l’état du PCE1

But

Vérifiez l’état du PCE principal actif.

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 actif à états auquel le PCC est connecté. Le PCE status champ de sortie indique l’état actuel de la session PCEP entre un PCE et 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 CCP.

Vérification du statut 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 LSPtype champ de sortie indique que le LSP est provisionné en externe.

La session PCEP entre CCP et PCE1 est en cours, et le CCP 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 Mbits/s

  • Priorité : 7 0 (valeurs de configuration et de maintien)

Configuration du protocole Path Computation Element Protocol 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 (CCP) avec la possibilité de prendre en charge les chemins de commutation d’étiquettes (LSP) créés dynamiquement à partir d’une entité de calcul de chemins externe centralisée. Un élément de computaiton de chemin à états (PCE) peut être utilisé pour effectuer des calculs de chemins externes et générer des LSP dynamiques en cas d’augmentation de la demande.

Un CCP crée le LSP point à point initié par PCE à l’aide des paramètres LSP fournis par le PCE, ou des paramètres à partir 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 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 CCP.

Un LSP contrôlé par CLI, un LSP contrôlé par PCE et un LSP initié par LE PCE peuvent coexister sur un CCP.

Avant de commencer :

  • Configurez les interfaces de l’équipement.

  • Configurez MPLS et RSVP-TE.

  • Configurez OSPF ou tout autre protocole IGP.

Pour configurer le PCC pour prendre en charge les LSP point à point initiés par PCE, effectuez les tâches suivantes :

  1. En mode configuration, passez au niveau hiérarchique suivant :
  2. Spécifiez le nombre de messages par minute que le CCP peut recevoir au maximum.
  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 le temps (en secondes) que le CCP doit attendre avant de renvoyer 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 qui se connecter.
  7. Spécifiez le numéro de port TCP que le PCE utilise

    La valeur peut varier de 1 à 65535 et la valeur par défaut est 4189.

  8. Spécifiez le temps (en secondes) que le CCP doit attendre avant de supprimer tout LSP non délégué initié par PCE du PCE défaillant après la fin d’une session PCEP.
  9. Configurez le PCC pour accepter les fournisseurs de services provisionnés en externe par des PCE connectés. Par défaut, le CCP 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 quoi la session PCEP est fermée.

    La valeur peut aller de 1 à 16384, et la valeur par défaut est 0 (désactivée ou sans limite).

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

    La valeur peut varier de 0 à 16384, et la valeur par défaut est 5. Une valeur de 0 désactive cette déclaration.

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

    La valeur peut varier de 0 à 6 5535 secondes.

  14. Vérifiez et validez la configuration.

Exemple de sortie

Exemple : Configuration du protocole Path Computation Element Protocol 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 chemins (PCC) avec la possibilité de créer des rapports sur des chemins te switched labelisés (TE LSP) de trafic point à multipoint vers 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é de réflecteur de route virtuel (VRR).

  • Connexion TCP à un PCE à états externes à 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’équipement.

  • 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 CCP, le CCP signale tous les LSP du système au PCE pour la synchronisation de l’état LSP. Cela inclut des LSP contrôlés par CCP, délégués par PCE et des LSP point à point initiés par LE PCE. À partir des versions 15.1F6 et 16.1R1 de Junos OS, cette fonctionnalité est étendue pour signaler les LSP point à multipoint.

Par défaut, le contrôle PCE des LSP point à multipoint n’est pas pris en charge sur un CCP. Pour ajouter cette fonctionnalité, incluez l’instruction p2mp-lsp-report-capability au niveau ou [edit protocols pcep pce-group group-id] de la [edit protocols pcep pce pce-name] hiérarchie.

topologie

Figure 7 : Exemple de LSP point à multipoint contrôlés par PCEExemple de LSP point à multipoint contrôlés par PCE

Dans cet exemple, CCP est le routeur entrant, le routeur R1 est le routeur de transit et le routeur R2 est le routeur sortant. LE CCP est connecté à un réflecteur de route virtuel (VRR) connecté à un PCE. Il existe de nombreuses interfaces point à multipoint entre PCC, routeur R1 et routeur R2.

Les rapports des LSP point à multipoints sont exécutés comme suit :

  1. Si le routeur PCC est configuré avec des LSP point à point et point à multipoint sans la prise en charge de la fonctionnalité de reporting point à multipoint, seuls les LSP point à point sont signalés au PCE connecté. Par défaut, un CCP ne prend pas en charge la fonctionnalité de reporting LSP point à multipoint.

  2. Lorsque le routeur PCC est configuré avec la fonctionnalité de création de rapports LSP point à multipoints, CCP en fait d’abord la promotion auprès du PCE par le biais d’un message de rapport.

  3. Par défaut, un PCE prend en charge la fonctionnalité LSP point à multipoint. Après avoir reçu la publicité du CCP pour la fonctionnalité LSP point à multipoint, le PCE en retour annonce sa capacité au CCP.

  4. Après avoir reçu la publicité du PCE sur la fonctionnalité point à multipoint, CCP signale toutes les filiales de 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 LSP est synchronisé entre le PCE et le CCP.

Configuration

Configuration rapide cli

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

PCC

R1

R2

R3

Procédure

Procédure étape par étape

Dans l’exemple suivant, vous devez parcourir différents niveaux de la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, voir Utilisation de l’éditeur CLI en mode de 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 l’interface 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 des chemins pour le LSP.

  6. Configurez les LSP point à multipoint et définissez une entité de calcul de chemins externes pour le LSP.

  7. Activez le calcul des chemins externes pour les LSP MPLS et attribuez un modèle pour les LSP provisionnés en externe.

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

  9. Configurez les 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 CCP du routeur.

  11. Configurez une stratégie d’importation TED (Traffic Engineering Database).

  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 à lequel le routeur PCC se connecte et configurez les paramètres PCE.

  18. Configurez le routeur PCC pour activer la fonctionnalité LSP point à multipoint pour le calcul des chemins externes.

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

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant les show interfaces commandes 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 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 CCP

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 à lequel le routeur PCC est connecté, ainsi que les paramètres et l’état pce1 PCE.

Understanding Path Computation Element Protocol pour MPLS RSVP-TE avec prise en charge des LSP point à multipoint initiés par PCE

Avec l’introduction des LSP point à multipoints initiés par PCE, un PCE peut lancer et provisionner dynamiquement un LSP point à multipoint sans avoir besoin d’une configuration LSP locale sur le PCC. Cela permet au PCE de contrôler la synchronisation et la séquence des calculs de chemins 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 LSP de l’ingénierie du trafic point à multipoint en réponse aux demandes des applications grâce à la création dynamique et à la démontisation des LSP point à multipoint, créant ainsi un réseau dynamique contrôlé et déployé de manière centralisée.

Signalisation des LSP point à multipoints initiés par PCE

La signalisation des LSP point à multipoints initiés par PCE est la suivante :

  • When a new branch is added (Grafting)— Seul le nouveau sous-LSP des filiales est signalé et n’entraîne pas de re-signalisation de l’ensemble de l’arbre point à multipoint.

    Si des changements de topologie ont eu lieu avant le provisionnement du nouveau sous-LSP, le serveur PCS (Path Computation Server) calcule l’ensemble de l’arbre de point en multipoint et met à jour le LSP point à multipoint à l’aide d’un message de mise à jour du PC.

  • When a branch is deleted (Pruning)— Le sous-LSP de filiale supprimé est détruit et n’entraîne pas de re-signalisation de l’ensemble de l’arbre point vers multipoint.

  • When a branch sub-LSP parameter is changed: les modifications des paramètres de sous-LSP, tels que l’objet de routage explicite (ERO), la bande passante ou la priorité, peuvent être effectuées 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’arbre point à multipoint est re-signalé, puis le basculement vers la nouvelle instance a lieu une fois que les nouvelles instances de toutes les filiales sont en place.

  • When a branch sub-LSP path fails— Une erreur est signalée au PCS pour le sous-LSP de filiale défaillant. À la réception du nouvel ERO du PCS, l’ensemble de l’arbre point à multipoint est re-signalé avec le sous-LSP de la filiale défaillante, et le basculement vers la nouvelle instance se fait de manière make-before-break (MBB).

Comportement des LSP point à multipoints initiés par PCE après une défaillance de session PCEP

Lorsqu’une session PCEP échoue, les LSP point à multipoint initiés par PCE sont orphelins jusqu’à l’expiration du state timeout timer. Après l’expiration du state timeout délai, les LSP initiés par PCE sont nettoyés.

Pour obtenir le contrôle d’un LSP point à multipoint initié par PCE après une défaillance de session PCEP, le PCE principal ou secondaire envoie un PCInitiate message avant l’expiration du state timeout délai.

Configuration de la fonctionnalité LSP point à multipoint piloté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 CCP. Pour activer cette fonctionnalité, incluez les p2mp-lsp-init-capability déclarations et p2mp-lsp-update-capability au niveau de [edit protocols pcep pce-group group-id] la [edit protocols pcep pce pce-name] hiérarchie.

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 LSP RSVP-TE 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 octobre 2018), Extensions du protocole PCE (Path Computation Element) pour l’utilisation à états de PCE pour les chemins de commutation d’étiquettes d’étiquettes point à multipoint du trafic.

  • À partir de la version 21.1R1 de Junos OS, nous prenons en charge le routage actif sans interruption (NSR) pour les LSP point à multipoint pilotés par RSVP basés sur PCE. Seul le moteur de routage principal maintient la session PCEP avec le contrôleur. Il synchronise tous les LSP RSVP initiés par des 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 les pertes 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 le 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 de LSP de point à multipoint contrôlé localement.

  • Délégation de contrôle LSP.

  • Extension IGP (Interior Gateway Protocol) pour la découverte de PCE dans un domaine de routage IGP.

  • Messages de demande/réponse.

  • Déplacement direct du sous-LSP de filiale d’un point à un autre.

    La même chose peut être obtenue en supprimant un sous-LSP de filiale du premier arbre de point à multipoint et en l’ajoutant à un autre après que le message indique la PCReport suppression de LSP de l’équipement.

  • IPv6 n’est pas pris en charge.

  • La signalisation basée sur SERO n’est pas prise en charge.

  • La fonctionnalité ERO vide n’est pas prise en charge.

  • La protection des liaisons n’est pas prise en charge.

Mappage des LSP point à multipoints initiés par PCE vers MVPN

Vous pouvez associer un seul ou plusieurs flux multicast MVPN (S,G) à un chemin de commutation d’étiquettes (LSP) initié par PCE dynamiquement. Vous pouvez spécifier uniquement des types sélectifs de flux pour que cette fonctionnalité fonctionne. Les thèmes abordés sont les suivants :

  • Routage distingueur (RD) qui est mappé à l’instance de routage MVPN.

  • (S,G) qui est la source d’une adresse de groupe multicast de paquet et de destination multicast. Il est utilisé pour filtrer le trafic entrant afin de le mapper au tunnel.

  • LSP point à multipoint utilisé pour envoyer un trafic correspondant aux spécifications de flux mentionnées ci-dessus.

Pour plus de détails, voir le projet Internet draft-ietf-pce-pcep-flowspec-05 (expire le 16 février 2020) Extension PCEP pour les spécifications de flux.

L’implémentation actuelle de cette fonctionnalité n’implémente pas les sections suivantes du projet :

  • Section 3.1.2 — Capabilités PCE publicitaires en IGP

  • Section 3.2 — Message PCReq et PCRep

  • Section 7 — La plupart des spécifications de flux, à l’exception des routes distinguéesL’implémentation actuelle de cette fonctionnalité n’est pas supporisher et les spécifications de flux multicast IPv4 ne sont pas prises en charge.

Pour permettre le mappage des LSP point à multipoints initiés par PCE vers MVPN :

  • Incluez l’énoncé pce_traffic_steering au niveau de la [edit protocols pcep pce pce-id] hiérarchie pour indiquer la prise en charge de la fonctionnalité de spécification de 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 dans external-controller la configuration de tunnel fournisseur pour MVPN indique que le LSP point à multipoint et (S,G) de cette instance MVPN peut être fourni par le contrôleur externe. Le contrôleur externe peut ainsi configurer dynamiquement (S,G) et LSP point à multipoint pour MVPN.

Prenez en compte les éléments suivants pour le mappage des LSP point à multipoints initiés par PCE vers MVPN :

  • 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 de la CLI, les flux multicast (S,G) appris dynamiquement 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 cli, le CCP ne peut pas configurer (S,G) dynamiquement car la configuration locale a une priorité plus élevée.

  • Si un (S,G) particulier est appris du contrôleur externe de manière dynamique et que vous configurez le même (S,G) pour la même instance MVPN, alors le S,G est supprimé et signalé au contrôleur externe via le CCP.

  • Si le processus de protocole de routage redémarre, le processus PCCD reconfigure à nouveau tout le (S, G).

  • Si le processus PCCD redémarre, le MVPN signale tous les CCPD configurés (S,G) au contrôleur externe.

  • Si l’utilisateur active external-controller pccd une instance MVPN particulière, MVPN demande au processus PCCD de configurer (S,G), le cas échéant.

  • S’il y a des modifications majeures de configuration à une instance MPVN particulière, alors MVPN demande au processus PCCD de reconfigurer tout (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. Au démarrage du PC, si toutes les spécifications de flux n’ont pas le même RD, le message de lancement du PC est supprimé avec une erreur.

  • Vous ne pouvez associer un LSP point à multipoint qu’à des spécifications de flux sélectifs, sinon le message de lancement du PC est abandonné 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’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.

  • 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 de la mise à jour des spécifications de flux existantes, alors le PCC abandonne le message de mise à jour.

  • Le comportement du mappage du LSP point à multipoint initié par PCE avec une instance de routage MVPN et du mappage de LSP 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 différents ID et le même RD &(S,G).

  • Pour la carte PCEP dynamique (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 :

    • Reporting des états de transfert associés au LSP point à multipoint.

    • Configuration dynamique de tunnel fournisseur inclusive

    • Mappage pour le tunnel de réplication entrant MVPN

    • Processus de protocole de routage programmable (prpd)

    • Reporting des LSP configurés point à multipoint par CLI, qui sont mappés aux flux multicast MVPN (S,G).

Activer le routage de segments pour le protocole Path Computation Element Protocol

SUMMARY Vous pouvez activer le routage de segments ou le routage de paquets source dans la mise en réseau (SR-TE) avec le protocole PCEP (Path Computation Element Protocol) pour l’orientation du trafic. Avec cette prise en charge, les avantages du routage de segments sont étendus aux chemins de commutation d’étiquettes (LSP) qui sont contrôlés par un élément de calcul de chemin (PCE).

Présentation du routage de segments pour le protocole Path Computation Element Protocol

Avantages du routage de segments pour PCEP

  • La configuration des LSP via un contrôleur externe fournit une vue d’ensemble de la demande de bande passante par LSP et par équipement sur le réseau, ce qui permet un calcul des chemins en ligne et en temps réel basé sur les contraintes.

    Les avantages du routage de segments sont étendus 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 chemins externes dans un réseau MPLS.

  • Un client de calcul de chemin (PCC, qui est un routeur MX Series entrant) avec une capacité de délégation peut reprendre le contrôle des LSP de routage de segments délégués à partir du PCE lorsque la session PCEP tombe en panne ; les LSP seraient sinon supprimés du CCP. Vous pouvez ainsi assurer la protection des données LSP en empêchant une situation où les paquets sont rejetés ou abandonnés en silence (également appelé condition de routage nul).

Routage de segments pour l’ingénierie 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 intégrées, le routage de segments s’intègre aux riches fonctionnalités multiservice de MPLS, notamment vpn de couche 3, VPWS (Virtual Private Wire Service), virtual private LAN service (VPLS) et Ethernet VPN (EVPN).

Parmi les composants de haut niveau de la solution SR-TE (Segment Routing-Traffic Engineering), citons :

  • Utilisation d’un IGP pour les caractéristiques des liens publicitaires. Cette fonctionnalité est similaire à RSVP-TE.

  • Utilisation du CSPF (Constrained Shortest Path First) sur l’équipement entrant ou le PCE.

  • Utilisation d’un IGP pour la publicité d’étiquettes pour les liens.

    Dans la fonctionnalité SR-TE :

    1. L’équipement entrant construit un LSP en empilant les étiquettes des liaisons qu’il souhaite traverser.

    2. L’annonce IGP par liaison est combinée à l’empilage d’étiquettes pour créer des LSP routés à la source sur l’équipement entrant, de sorte que les équipements de transit ne sont pas conscients des LSP de bout en bout.

    3. Les LSP sont créés entre les nœuds de périphérie sans placer de mémoire par LSP sur les équipements 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 permet de gérer un grand nombre de labels, ce qui conduit à l’évolutivité du plan de contrôle.

Implémentation junos OS du routage de segments 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 par PCE.

LSP de routage de segments initiés par PCE

Les LSP de routage de segments initiés par PCE sont les LSP que le PCE crée 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 (CCP) à l’aide des extensions de routage de segments PCEP.

  3. Analyse les extensions de routage de segments PCEP.

  4. Crée un routage de tunnel sur le CCP qui a sa propre valeur de préférence et est disponible dans la table de routage inet.3 pour résoudre le trafic et les services IP comme tout autre routage de tunnel.

Le CCP remplit les fonctions suivantes :

  1. Sélectionne l’interface sortante en fonction du premier identifiant d’accès réseau (NAI) dans l’objet S-ERO (Explicit Route Object) source.

    Junos OS prend en charge les S-ERO qui contiennent le premier saut comme un saut strict ; Junos OS ne prend pas en charge la sélection de l’interface sortante sur le PCC basé sur un ID de segment de nœud (SID) à saut libre. Cependant, les sauts restants peuvent être desserrés. Aucun traitement spécifique n’est effectué pour les S-ERO qui sont au-delà du premier saut, si ce n’est simplement utiliser le label pour la création du saut suivant.

  2. Rejette le S-ERO si :

    • Le S-ERO ne comporte pas d’étiquettes.

    • Le S-ERO transporte plus de six sauts.

    Le CCP crée un routage ecMP (Equal-Cost Multipath) lorsque plusieurs LSP sont acheminés vers la même destination avec la même métrique.

  3. Attend que le PCE traite tout événement qui conduit à un changement dans le LSP de routage de segments après son provisionnement, par exemple, si le label est modifié ou retiré, 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 opérationnel pendant 300 secondes.

  2. Est supprimé du CCP après 300 secondes.

Pour plus de détails, voir les ébauches d’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), extensions PCEP pour le routage de segments.

LSP de routage de segments délégués par PCE

Les LSP de routage de segments délégués par PCE sont les LSP que le PCC configure localement et délègue ensuite à un contrôleur PCE.

REMARQUE :

La version 20.1R1 de Junos OS 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 uniquement à un contrôleur externe. Plusieurs segments ne sont pas pris en charge pour la délégation PCE.

Le CCP peut déléguer un LSP de routage de segments à un contrôleur externe (le PCE) des façons suivantes :

  • Initial delegation— Les LSP locaux n’ont pas encore été configurés sur le CCP, 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 se produit une fois le chemin de routage source configuré. Autrement dit, la capacité 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 des chemins. Le contrôle LSP revient au CCP lorsque la session PCEP entre le CCP et le PCE tombe en panne. Les LSP délégués par PCE ont un avantage par rapport aux LSP initiés par le PCE en cas de panne de la session PCEP. Dans le cas des LSP initiés par PCE, lorsque la session PCEP est en panne, les LSP sont supprimés du PCC. Toutefois, dans le cas des LSP délégués par PCE, lorsque la session PCEP tombe en panne, le CCP reprend le contrôle des LSP délégués du PCE. En conséquence, avec les LSP délégués par PCE, nous éviterons une situation où les paquets sont rejetés en silence (également appelé condition de routage nul) lorsque la session tombe en panne.

Les types de LSP de routage de segments suivants prennent en charge la capacité de délégation PCE :

  • Static LSPs— Chemins de routage à la source configurés de manière statique dont l’ensemble de la pile de labels est statiquement configuré.

  • Auto-translated LSPs— Chemins de routage à la source configurés statiquement et traduits automatiquement.

  • Computed LSPs— Chemins de routage source à configuration statique calculés à l’aide de CSPF (Constrained Shortest Path First) distribué.

  • Dynamic LSPs: les tunnels créés dynamiquement sont déclenchés via le module de tunnel dynamique qui ont une résolution ERO du dernier saut.

En fonction de la source du LSP de routage de segments, 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é dans la [edit protocols source-packet-routing] hiérarchie.

Tableau 2 affiche un mappage de la source LSP au niveau de hiérarchie de configuration correspondant auquel la capacité de délégation est activée.

REMARQUE :

Vous devez inclure l’instruction lsp-external-controller pccd au niveau et [edit protocols mpls] de la [edit protocols source-packet-routing] hiérarchie avant de configurer la capacité de délégation sur le PCC.

Tableau 2 : Mappage de la source LSP de routage de segments avec la hiérarchie de configuration

Source du routage de segments LSP

Hiérarchie de configuration

  • LSP traduits automatiquement

  • LSP statiques

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

LSP calculés (CSPF distribué)

Liste de segments principaux du chemin de routage source à l’adresse :

  • [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 de segments principaux du modèle de chemin de routage source à l’adresse :

  • [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 consulter l’état des contrôles des LSP SR-TE à partir de la sortie de 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 : Délégation LSP d’interaction PCEP

Hiérarchie de configuration lsp-externe-contrôleur

état de délégation du routage source-chemin

Interaction PCEP entre CCP et PCE

Liste de segments principaux du chemin de routage source

Délégation initiale

  1. Un message PCReport est envoyé au PCE pour délégation. Le rapport PC Ne contient que des contraintes et des détails sur les chemins (par exemple ERO).

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

  3. Aucun routage n’est programmé par le LSP local jusqu’à ce que le contrôleur calcule l’ERO et notifie le résultat au CCP via PCUpdate.

Le même comportement est observé lorsque le processus de protocole de routage (rpd) redémarre ou qu’un basculement du moteur de routage se produit.

Liste de segments principaux du chemin de routage source

Délégation du chemin existant

  1. Un rapport PC est envoyé au PCE pour délégation. Le rapport PC Ne contient que des contraintes et des détails sur les chemins (par exemple ERO).

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

  3. PCE calcule le chemin du LSP.

  4. Le segment principal continue de contribuer au routage, tel que déterminé par la configuration ou le calcul local, jusqu’à ce qu’un PCUpdate soit reçu du PCE.

    • Si le BFD transparent (S-BFD) n’est pas configuré pour le segment principal, il n’y a pas d’autre mise à jour du routage et l’état LSP n’est pas non plus surveillé et signalé au PCE. À ce stade, l’état LSP est signalé comme étant à la hausse ou à la baisse, selon que le calcul du chemin a réussi à cet endroit.

    • Si le S-BFD est configuré pour le segment principal, l’état du segment principal est suivi et signalé au PCE. Si BFD détecte que le segment principal est en panne, le chemin principal correspondant est supprimé du routage. Le même chemin précédemment calculé est reprogrammé si ce chemin est déjà en place.

  5. Si un message PCUpdate est reçu du PCE, SR-TE utilise le paramètre reçu pour définir le chemin pour lequel le message PCReport a été envoyé. Le chemin programmé inclut alors uniquement 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 la route s’effectue de manière à faire avant-break.

Segment principal du chemin de routage source

La délégation n’est pas configurée ou a été supprimée.

La liste de segments du PCE (si disponible) n’est plus utilisée et le résultat de 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 la route de manière make-before-break.

Liste de segments du chemin de routage source

La délégation est activée une fois le LSP configuré.

La fonction de délégation est déclenchée pour la liste de segments principaux sous le chemin source-routage.

Liste de 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 de segments principaux sous le chemin source-routage.

Liste de segments principaux du modèle de chemin de routage source

La délégation est activée une fois le LSP configuré.

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

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

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

Liste de segments principaux 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 correspondant à la configuration du modèle.

Routage de segments pour les limitations PCEP et les fonctionnalités non prises en charge

La prise en charge du routage de segments pour PCEP n’alourdit pas les performances du système. Cependant, il présente les limites suivantes :

  • Un LSP SR-TE n’est pas protégé localement sur le CCP. Lorsque le LSP est plus de six sauts, aucun service n’est fourni sur le LSP autre que pour transporter un trafic IP simple.

  • Le basculement GRES (Graceful Routing Engine Switchover) et la mise à niveau logicielle en cours d’utilisation unifiée (UNIFIED ISSU) ne sont pas pris en charge.

  • Le routage actif sans interruption (NSR) n’est pas pris en charge.

  • IPv6 n’est pas pris en charge.

  • Les LSP délégués par PCE ne prennent pas en charge les éléments suivants :

    • LSP SR-TE colorés

    • LSP IPv6

    • Liste de segments secondaires du chemin de routage source. Un seul chemin de la liste de segments peut être délégué.

    • Norme multisegment. Seul le premier segment de la liste de segments est délégué et signalé au contrôleur.

Exemple : Configurer le routage de segments pour le protocole Path Computation Element Protocol

Cet exemple montre comment configurer le routage de segments ou le routage de paquets source dans le réseau (SPRING) l’ingénierie du trafic (SR-TE) pour le protocole PCEP (Path Computation Element Protocol). Dans la configuration, nous exploitons les avantages du routage de segments avec les avantages du path computing 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 (CCP).

  • Connexion TCP du PCC à un élément PCE (Path Computation Element) externe à états.

  • 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 une version ultérieure.

Avant de commencer :

  • Configurez les interfaces de l’équipement.

  • Configurez MPLS.

  • Configurez IS-IS.

Présentation

L’implémentation junos OS du routage de segments pour PCEP inclut des LSP SR-TE délégués et des LSP pilotés par PCE.

  • L’implémentation des LSP initiés par PCE est introduite dans la version 17.2R1 de Junos OS, 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 CCP correspondant aux LSP SR-TE initiés par PCE.

  • L’implémentation des LSP délégués par PCE est introduite dans la version 20.1R1 de Junos OS, où les LSP de routage de segments non colorés 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 LSP délégués par PCE ont un avantage par rapport aux LSP initiés par le PCE au moment où la session PCEP tombe en panne. Dans le cas des LSP initiés par PCE, lorsque la session PCEP est en panne, les LSP sont supprimés du PCC. Toutefois, dans le cas des LSP délégués par PCE, lorsque la session PCEP tombe en panne, le CCP reprend le contrôle des LSP délégués du PCE. En conséquence, avec les LSP délégués par PCE, nous éviterons une situation où des paquets sont rejetés silencieusement (également appelé condition de routage nul) 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 des chemins externes 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 des 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 des chemins externes 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. Si vous le pouvez, configurez 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 nœud ou une liaison sur un nœud. Lorsqu’elle n’est pas configurée, une valeur SID maximale de 5 est appliquée par défaut.

  5. Vous pouvez éventuellement 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 formulaire de chemin actif parmi les chemins candidats, où une valeur supérieure a une préférence plus élevée. Lorsqu’il n’est pas configuré, une valeur de préférence par défaut est 8.

  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 des LSP de routage de segments, en plus des étapes ci-dessus, procédez comme suit :

  1. Définissez une liste de segments avec les 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 du routage de segments :

    • Pour les chemins de routage à la source configurés statiquement et calculés avec des niveaux CSPF[edit protocols source-packet-routing source-routing-path lsp-name primary path-name compute profile-name] et [edit protocols source-packet-routing source-routing-path lsp-name primary path-name] hiérarchiques distribués.

    • Pour les chemins de routage à la source configurés statiquement qui ont toute la pile de labels configurée statiquement et les chemins de routage source qui sont automatiquement traduits, au[edit protocols source-packet-routing source-routing-path lsp-name primary path-name] niveau de la hiérarchie.

    • Pour les tunnels créés dynamiquement 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 du 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 sur lequel une session PCEP s’exécute entre le PCE et le PCC (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 un routage statique sur le PCC vers le routeur R3 pour vérifier l’utilisation de routes de tunnel SR-TE lors du routage du trafic pour le routage statique.

Figure 8 : Routage de segments pour PCEPRoutage de segments pour PCEP

Configuration

Configuration rapide cli

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

Bien que nous présentions la configuration de tous les équipements (PCC et les trois routeurs) dans cette section, la procédure étape par étape documente uniquement la configuration du CCP.

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 exigent que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation sur l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le guide de l’utilisateur CLI.

Pour configurer le PCC :

  1. Configurez les interfaces du PCC.

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

  3. Configurez un routage statique du PCC vers le routeur R3.

    Le routage statique est créé à des fins de vérification uniquement et n’affecte pas les fonctionnalités.

  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 fonctionnalité de calcul des chemins externes pour MPLS.

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

  8. Configurez les attributs SRGB (Segment Routing Global Block) pour le routage de segments.

  9. Activez la fonctionnalité de calcul des chemins externes 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 de static_seg_list_1 segments statiques.

  14. Configurez un LSP de routage de segments statique du PCC au routeur R3 pour la délégation PCE.

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

    En effectuant les étapes 13, 14 et 15, vous autorisez le PCC à 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 entrant le show interfaces, show routing-optionset show protocols les commandes. 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 fini de configurer l’équipement (le PCC), saisissez le commit mode de configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérifier l’adjacence IS-IS et les étiquettes
But

Vérifiez l’adjacence IS-IS sur le CCP. Notez la plage de labels SRGB, les valeurs d’adjacence et de segment de nœud, ainsi que les champs de sortie de la capacité SPRING.

Action

À partir du mode opérationnel, exécutez le show isis adjacency extensive, show isis database extensiveet show isis overview les commandes.

Sens

L’adjacence IS-IS entre le CCP et le PCE, ainsi qu’entre le CCP et le routeur R1, est opérationnelle et opérationnelle. La sortie affiche également les attributions de labels pour les segments adjacents et les segments de nœud.

Vérifier la base de données d’ingénierie du trafic
But

Vérifiez les entrées de la base de données d’ingénierie du trafic sur le CCP.

Action

À partir du mode opérationnel, exécutez la show ted database extensive commande.

Sens

La base de données d’ingénierie du trafic comprend des entrées annoncées par les routeurs R1, R2 et R3, que le PCE utilise pour le calcul des chemins externes pour le PCC.

Vérifier les LSP SR-TE
But

Vérifiez la création de LSP SR-TE sur le CCP.

Action

À partir du mode opérationnel, exécutez le show path-computation-client lsp, show spring-traffic-engineering lsp detailet show route protocol spring-te les commandes.

Sens

Les résultats montrent que deux LSP SR-TE (adj_sid_lsp et node_sid_lsp) ont été créés par le PCE pour les segments d’adjacence et de nœud, respectivement.

Le routage de segments LSP, static_srte_lsp_1, est activé avec la capacité de délégation. Le Delegation info champ affiche l’état du contrôle et du routage des LSP délégués par PCE. Externally controlled Signifie que le PCE contrôle les LSP. Externally routed Signifie que le PCE a fourni l’ERO pour le chemin de routage source.

Vérifier la création de routes de tunnel
But

Vérifiez les routes de tunnel créées pour les LSP SR-TE incluses dans la table de routage inet.3 du PCC.

Action

À partir du mode opérationnel, 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 label de protocole.

Vérifier les entrées de table de transfert
But

Vérifiez que la destination LSP SR-TE vers le routeur R3 est installée dans la table de transfert du CCP.

Action

À partir du mode opérationnel, exécutez la show route forwarding-table destination ip-address extensive commande.

Sens

L’adresse IP de destination 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 le routage statique emprunte le tunnel créé pour les LSP SR-TE.

Action

À partir du mode opérationnel, exécutez les show route ip-address commandes et 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 LSP SR-TE.

Chemin de commutation d’étiquettes de segment routing statique

L’architecture de routage de segments permet aux équipements 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 ip, ce qui entraîne l’opération de transfert au niveau de l’équipement entrant comme un échange d’étiquettes ou une recherche basée sur la destination.

Comprendre le routage de segments statique LSP 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 nœuds et de liaisons dans le réseau sans dépendre des nœuds intermédiaires du réseau pour déterminer le chemin réel qu’il doit prendre.

Introduction aux LSP de routage de segments

Le routage de segments exploite le paradigme du routage source. Un équipement oriente un paquet à travers une liste d’instructions ordonnée, appelée segments. Un segment peut représenter n’importe quelle instruction, topologique ou basée sur les services. Un segment peut avoir une sémantique locale vers un nœud de routage de segments ou vers un nœud global dans un domaine de routage de segments. Le routage de segments applique un flux à travers n’importe quel chemin topologique et chaîne de services tout en maintenant l’état par flux uniquement au niveau de l’équipement entrant vers le domaine de routage de segments. Le routage de segments peut être appliqué directement à l’architecture MPLS sans modification du plan de transfert. Un segment est encodé sous la forme d’un label MPLS. Une liste ordonnée de segments est encodée sous la forme d’une pile de labels. Le segment à traiter se trouve en haut de la pile. Une fois le segment terminé, le label associé est retiré de la pile.

Les LSP de routage de segments peuvent être dynamiques ou statiques par nature.

Dynamic segment routing LSPs— Lorsqu’un LSP de routage de segments est créé soit par un contrôleur externe et téléchargé sur un équipement entrant via les extensions PCEP (Path Computation Element Protocol), soit à partir d’une stratégie de routage de segments BGP via des extensions de routage de segments BGP, le LSP est provisionné dynamiquement. La liste de segments du LSP de routage de segments dynamique est contenue dans l’ERO (Pcep Explicit Route Object) ou la stratégie de routage de segments BGP du LSP.

Static segment routing LSPs— Lorsqu’un LSP de routage de segments est créé sur l’équipement entrant via une configuration locale, le LSP est provisionné statiquement.

Un LSP de routage de segments statique peut en outre être classé dans les 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 routage de segments

  • Le routage de segments statique ne repose pas sur l’état de transfert par LSP sur les routeurs de transit. Par conséquent, il n’est plus nécessaire de provisionner et de maintenir l’état de transfert par LSP dans le cœur.

  • Améliorez l’évolutivité des réseaux MPLS.

LSP statique de routage de segments coloré

Un LSP de routage de segments statique configuré avec l’instruction color s’appelle un LSP coloré.

Comprendre les LSP statiques de routage de segments colorés

Semblable à une stratégie de routage de segments BGP, la route entrante du LSP coloré est installée dans les inetcolor.0inet6color.0 ou tables de routage, avec destination-ip-address, color comme clé de mappage du trafic IP.

Un LSP statique de routage de segments coloré peut avoir un SID de liaison, pour lequel un routage est installé dans la table de mpls.0 routage. Ce label SID de liaison permet de mapper le trafic étiqueté au LSP de routage de segments. Les passerelles de la route sont dérivées des configurations de liste de segments sous les chemins primaires et secondaires.

Liste de segments des LSP de routage de segments colorés

Les LSP statiques de routage de segments 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 la version 19.1R1 de Junos OS, une fonctionnalité de vérification de validation est introduite pour s’assurer que toutes les listes de segments contribuant aux routes colorées ont le label minimum présent pour tous les sauts. Si cette exigence n’est pas satisfaite, la validation est bloquée.

LSP statique de routage de segments non coloré

Un LSP de routage de segments statique configuré sans l’instruction color est un LSP non coloré. À l’instar des tunnels de routage de segments PCEP, la route entrante est installée dans les ou inet6.3 tables de inet.3 routage.

Junos OS prend en charge les LSP statiques de routage de segments non colorés sur les routeurs entrants. Vous pouvez provisionner un LSP statique de routage de segments non coloré en configurant un chemin 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 de routage de segments non colorés

Le LSP de routage de segments non coloré a 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. Ce routage permet de mapper les services non colorés au LSP de routage de segments correspondant à la destination. Dans le cas où le LSP de routage de segments non coloré n’a pas besoin d’un routage entrant, alors la route entrante peut être désactivée. Un LSP de routage de segments non coloré utilise un label SID de liaison pour obtenir un assemblage LSP de routage de segments. Ce label peut être utilisé pour modéliser le routage de segments LSP comme un segment pouvant être utilisé pour construire d’autres LSP de routage de segments de manière hiérarchique. Le transit du label SID de liaison, par défaut, a une préférence de 8 et une métrique de 1.

À partir de la version 18.2R1 de Junos OS, les LSP de routage de segments non colorés configurés statiquement sur l’équipement entrant sont signalés au Path Computation Element Element Element (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 labels SID (Binding Service Identifier). Grâce à cette fonctionnalité, le PCE peut utiliser ce label SID de liaison dans la pile de labels 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 opérationnels primaires, le moteur de transfert de paquets (PFE) distribue 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 multi-chemin à coût égal (ECMP) si aucun des chemins n’a de poids configuré sur eux ou ecMP pondéré si au moins l’un des chemins a un poids non nul configuré sur les chemins. Dans les deux cas, lorsqu’un ou plusieurs chemins tombent en panne, le PFE rééquilibre le trafic sur les chemins restants, ce qui conduit automatiquement à la protection des chemins. Un LSP de routage de segments non coloré peut avoir un chemin secondaire pour la protection des chemins dédiés. En cas de défaillance d’un chemin principal, le PFE rééquilibre le trafic vers les chemins primaires fonctionnels restants. Dans le cas contraire, le PFE bascule le trafic vers le chemin de secours, ce qui permet d’assurer la protection des chemins. Un LSP de routage de segments non coloré peut spécifier une métrique à [edit protocols source-packet-routing source-routing-path lsp-name] pour ses routes d’entrée et de liaison SID. Plusieurs LSP de routage de segments non colorés ont la même adresse de destination qui contribuent au saut suivant de la route entrante.

Plusieurs LSP de routage de segments non colorés ont la même adresse de destination qui contribuent au saut suivant de la route entrante. Chaque chemin, principal ou secondaire, de chaque LSP de routage de segments est considéré comme un candidat de passerelle, si le chemin est fonctionnel et si le LSP de routage de segments a la meilleure préférence pour tous ces LSP de routage de segments. Toutefois, le nombre maximal de passerelles que le saut suivant peut contenir ne peut pas dépasser la limite RPD multi-chemin, qui est de 128 par défaut. Les chemins supplémentaires sont taillés, d’abord les chemins secondaires, puis les chemins primaires. Ces LSP de routage de segments peuvent faire référence plusieurs fois à une liste de segments en tant que chemins primaires ou secondaires. Dans ce cas, il existe plusieurs passerelles, chacune ayant un ID de tunnel LSP de routage de segments unique. Ces passerelles sont distinctes, bien qu’elles aient une pile et une interface de labels sortantes 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, elles correspondent à différentes adresses de destination pour les routes entrantes, car l’adresse de destination du LSP de routage de segments coloré est construite avec son adresse de destination et sa couleur.

REMARQUE :

Dans le cas où un LSP statique de routage de segments non coloré et un LSP de routage de segments créé par PCEP coexistent et ont le même à traiter qui contribue au même routage entrant, s’ils ont également la même préférence. Sinon, le LSP de routage de segments avec la meilleure préférence est installé pour le routage.

Liste de segments des LSP de routage de segments non colorés

Une liste de segments se compose d’une liste de sauts. Ces sauts sont basés sur le label SID ou une adresse IP. Le nombre de labels SID dans la liste de segments ne doit pas dépasser la limite maximale de la liste de segments. La liaison maximale de la liste de segments à un tunnel LSP passe de 8 à 128, avec un maximum de 1 000 tunnels par système. Un maximum de 128 chemins principaux sont pris en charge par routage de segments statique LSP. Vous pouvez configurer la limite maximale de liste de segments au niveau de la [edit protocols source-packet-routing] hiérarchie.

Avant la version 19.1R1 de Junos OS, pour qu’un LSP statique non coloré soit utilisable, le premier saut de la liste de segments devait être une adresse IP d’une interface sortante et le deuxième saut npouvait être des labels SID. À partir de la version 19.1R1 de Junos OS, cette exigence ne s’applique pas, car le premier saut des LSP statiques non colorés prend désormais en charge les étiquettes SID, en plus des adresses IP. Grâce à la prise en charge du premier saut, le reroutage rapide MPLS (FRR) et le multichemin pondéré à coût égal sont activés pour résoudre les LSP statiques de routage de segments non colorés, semblables aux LSP statiques colorés.

Pour que le mode label de premier saut prenne effet, vous devez inclure l’instruction inherit-label-nexthops 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 le label. Si le premier saut ne comprend que l’adresse IP, l’instruction inherit-label-nexthops n’a aucun effet.

Vous pouvez configurer inherit-label-nexthops n’importe quelle des hiérarchies suivantes. L’instruction inherit-label-nexthops prend effet uniquement si le premier saut de la liste de segments comprend à la fois l’adresse IP et le label.

  • 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 est configurée à l’échelle inherit-label-nexthops mondiale, elle prend la priorité 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 inherit-label-nexthops n’est pas configurée globalement, seules les listes de segments avec les étiquettes et l’adresse IP présentes dans le premier saut, et configurées avec inherit-label-nexthops l’instruction sont résolues à l’aide de labels SID.

Pour les LSP statiques dynamiques non colorés, c’est-à-dire les LSP de routage de segments pilotés par PCEP, l’instruction inherit-label-nexthops doit être activée globalement, car la configuration au niveau du segment n’est pas appliquée.

Tableau 4 décrit le mode de résolution LSP de 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 de 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 de segments est résolue à l’aide de labels SID.

Adresse IP et SID (sans 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 de segments est résolue à l’aide de l’adresse IP.

Adresse IP et SID (avec configuration inherit-label-nexthops )

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 de segments est résolue à l’aide de labels SID.

Vous pouvez utiliser la show route ip-address protocol spring-te active-path table inet.3 commande pour afficher les LSP de routage de segments non colorés dont plusieurs listes de segments sont installées dans la table de routage inet.3.

Par exemple :

REMARQUE :

Le premier type de listes de segments d’un LSP de routage de segments statique peut entraîner l’échec d’une validation, si :

  • Différentes listes de segments d’un tunnel ont différents types de résolution de premier saut. Cela s’applique aux LSP statiques de routage de segments colorés et non colorés. Toutefois, cela ne s’applique pas aux LSP pilotés par PCEP ; un message du journal système est généré pour l’incompatibilité du premier type de résolution de saut au moment du calcul du chemin.

    Par exemple :

    La validation du tunnel lsp1 échoue, car le chemin 1 est en mode d’adresse IP et le chemin 2 est en mode label.

  • Le SID de liaison est activé pour le LSP statique non coloré dont le type de liste de segments est le label SID.

    Par exemple :

    La configuration de la liaison SID sur une liste de segments d’étiquettes est prise en charge uniquement pour les LSP statiques colorés et non pour les LSP statiques sans couleur.

Provisionnement LSP de routage de segments statique

Le provisionnement de segments est effectué par routeur. Pour un segment donné sur un routeur, un label d’identifiant de service unique (SID) est alloué à partir d’un pool de labels souhaité, qui peut provenir du pool de labels dynamique pour un label SID d’adjacence ou du segment routing global block (SRGB) pour un préfixe SID ou nœud SID. Le label SID d’adjacence peut être alloué dynamiquement, c’est-à-dire le comportement par défaut, ou être alloué à partir d’un pool d’étiquettes statiques locaux (SRLB). Un routage pour le label SID est ensuite installé dans la table mpls.0.

Junos OS permet le routage de segments statique LSP 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 un label SID unique qui relève du pool de labels statiques Junos OS. Vous pouvez configurer le pool de labels statiques Junos OS en configurant l’instruction static-label-range static-label-range au niveau de la [edit protocols mpls label-range] hiérarchie.

Limitations LSP du routage de segments statiques

  • Pour le moment, Junos OS ne peut pas construire le saut suivant pour pousser plus que les étiquettes de profondeur de liste de segments maximales. Ainsi, une liste de segments avec plus que les étiquettes SID maximales (à l’exception du label SID du premier saut utilisé pour résoudre le prochain saut de transfert) n’est pas utilisable pour les LSP de routage de segments colorés ou non. En outre, le nombre réel autorisé pour un LSP de routage de segments donné peut être encore inférieur à la limite maximale, si un service MPLS est sur le LSP de routage de segments ou si le routage de segments LSP est sur une liaison ou un chemin de protection de nœud. Dans tous les cas, le nombre total de labels de service, de labels SID et de labels de protection des liaisons ou des nœuds ne doit pas dépasser la profondeur maximale de la liste de segments. Vous pouvez configurer la limite maximale de liste de segments au niveau de la [edit protocols source-packet-routing] hiérarchie. Plusieurs LSP de routage de segments non colorés avec des labels SID inférieurs ou égaux au maximum peuvent être réunis pour construire un LSP de routage de segments plus long. C’est ce qu’on appelle l’assemblage LSP de routage de segments. Il peut être réalisé à l’aide d’un label SID de liaison.

  • L’assemblage LSP du routage de segments est en fait effectué 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 rattaché indépendamment à un autre LSP de routage de segments non coloré à un point d’assemblage. Un LSP de routage de segments non coloré dédié à l’assemblage peut désactiver l’installation de route entrante en configurant no-ingress l’instruction au niveau de la [edit protocols source-packet-routing source-routing-path lsp-name] hiérarchie.

  • Un maximum de 12chemins 8 principaux et 1 chemin secondaire sont pris en charge par routage de segments statique non coloré. En cas de violation dans la configuration, la vérification de validation échoue avec une erreur.

  • La liaison maximale de la liste de segments à un tunnel LSP passe de 8 à 128, avec un maximum de 1 000 tunnels par système. Un maximum de 128 chemins principaux sont pris en charge par routage de segments statique LSP. En limite, la prise en charge maximale des capteurs pour le chemin LSP est 32000 uniquement.

  • Si une liste de segments est configurée avec plus de labels que la profondeur maximale de la liste de segments, la vérification de la validation de la configuration échoue avec une erreur.

Création dynamique des LSP de routage de segments

Dans les réseaux de routage de segments dont chaque équipement de périphérie fournisseur (PE) est connecté à tous les autres équipements PE, une grande quantité de configuration est nécessaire pour configurer les chemins de commutation d’étiquettes de segments (LSP), bien que seuls quelques chemins SR-TE (Segment Routing Traffic Engineered) peuvent être utilisés. Vous pouvez activer la création dynamique BGP-trigerred de ces LSP 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 pour permettre 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 dynamique de couleurs :

  • Voici un exemple de configuration pour un modèle LSP de routage de segments dynamique non couleur :

Résolution des LSP de routage de segments dynamiques
Résolution des LSP de routage de segments dynamiques colorés

Lorsque les préfixes BGP sont assignés à une communauté de couleurs, ils sont d’abord résolus par la stratégie catch-all-route-for-that-particular-color, puis 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 saut suivant du préfixe de charge utile BGP est une adresse IP appartenant à l’équipement A, alors le nœud-SID de l’équipement A est prélevé et une étiquette correspondante est préparée et poussée au bas de la pile. Le préfixe de charge utile BGP est résolu dans un mode couleur uniquement, où le nœud-SID de l’équipement A se trouve au bas de la pile de labels finale et les étiquettes de chemin SR-TE sont 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 avec succès 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 le routage BGP demandant une résolution reste en suspens.

Résolution des LSP de routage dynamique de segments non colorés

Les routes catch-all 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 autre spring-te configuration avec un seul nom de modèle dans la liste de mappage. Ce nom de modèle est utilisé pour tous les routes de tunnel correspondant à l’un des réseaux de destination configurés dans la même spring-te configuration. Ces tunnels sont similaires aux tunnels RSVP en termes de fonctionnalité.

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 routage de segments dynamique

Le modèle LSP de routage de segments dynamique comporte toujours un chemin partiel. Le SID du dernier saut est dérivé automatiquement au moment de la création du tunnel en fonction du SID de nœud PNH (Protocol Next-Hop Address). Le même modèle peut être utilisé par plusieurs tunnels vers différentes destinations. Dans de tels cas, le chemin partiel reste le même, et seul le dernier saut change en fonction de la PNH. Les modèles LSP de routage de segments dynamiques ne sont pas communs à un seul tunnel, de sorte qu’il ne peut pas y avoir de chemin complet. Vous pouvez utiliser une liste de segments si vous souhaitez utiliser un chemin complet.

LSP de routage de segments 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. inetcolor6.0 tunnel route: ffff::10. 22.44.0-0/120 --> RT_NH_TUNNEL

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

    R1(préfixe) -> ffff::10. 22.44.55-101(PNH) Nom du tunnel LSP = 10. 22.44.55:65:dt-srte-tunnel1

    R1(préfixe) -> ffff::10. 22.44.55-124(PNH) Nom du tunnel LSP = 10. 22.44.55:7c:dt-srte-tunnel1

  4. inetcolor.0 tunnel route:

    10. 22.44.55-101/64 --> < prochain saut>

    10. 22.44.55-124/64 --> < prochain saut>

  5. inetcolor6.0 tunnel route:

    ffff::10. 22.44.55-101/160 --> < prochain saut>

    ffff::10. 22.44.55-124/160 --> < prochain saut>

LSP de routage dynamique de segments non colorés

Exemple de configuration pour les LSP de routage dynamique de segments 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. inet6.3 tunnel route: ffff::10.33.44.0/120 --> RT_NH_TUNNEL

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

    R1(préfixe) -> ffff::10.33.44.55(PNH) nom du modèle LSP = LSP1 --- 10.33.44.55:dt-srte-tunnel2

  4. inet.3 tunnel route: 10.33.44.55/32 --> < prochain saut>

  5. inet6.3 tunnel route: ffff::10.33.44.55/128 --> < prochain saut>

Routage de segments dynamique non résolu

Exemple de configuration pour les LSP de routage dynamique 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. inetcolor6.0 tunnel route: ffff::10.33.44.0 - 0/120 --> RT_NH_TUNNEL ffff:::10.1.1.0 - 0 /24 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping: Le tunnel R1(préfixe) -> 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 des LSP de routage de segments

Lors de la configuration de la création dynamique de LSP de routage de segments, prenez en compte les éléments suivants :

  • Un modèle peut être assigné avec un objet de couleur. Lorsque la configuration de tunnel spring-te dynamique comprend 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 censées être colorées dans cette configuration.

  • Un modèle peut avoir une liste de couleurs définie 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 assigné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 de la couleur au modèle est effectué sur une base un à un. Une seule couleur ne peut pas être mapée à plusieurs modèles.

  • Le nom du modèle doit être configuré dans l’instruction spring-te sous la [edit protocols] hiérarchie et l’option primary doit être activée.

  • Les destinations colorées et non colorées ne peuvent pas coexister dans la même spring-te configuration.

  • Vous ne pouvez pas configurer les mêmes réseaux de destination, avec ou sans couleur, sous différentes spring-te instructions de configuration.

  • Dans une configuration non colorée spring-te , un seul modèle peut être configuré sans objet de couleur.

Services pris en charge sur des LSP de routage de segments dynamiques

Les services suivants sont pris en charge sur des LSP de routage de segments dynamiques colorés :

  • VPN de couche 3

  • BGP EVPN

  • Exporter des services de stratégie

Les services suivants sont pris en charge sur des LSP de routage dynamique de segments non colorés :

  • VPN de couche 3

  • VPN de couche 2

  • Configurations multi-chemins

Comportement avec plusieurs sources de tunnel dans le routage de segments

Lorsque deux sources téléchargent des routes vers la même destination à partir du routage de segments (par exemple des tunnels statiques et dynamiques sourceux), la préférence de routage de segments est utilisée pour choisir l’entrée de route active. Une valeur plus élevée a plus de préférence. Si la préférence reste la même, alors la source du tunnel est utilisée pour déterminer l’entrée de route.

Limites des LSP de routage de segments dynamiques

Les LSP SR-TE dynamiques ne prennent pas en charge les fonctionnalités 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 et des routes B-SID dans un modèle.

Mappage des services VPN basé sur les couleurs

Vous pouvez spécifier la couleur comme contrainte de saut suivant du protocole (en plus de l’adresse IPv4 ou IPv6) pour résoudre les tunnels de transport sur des LSP statiques colorés et BGP de routage de segments (SR-TE). C’est ce qu’on appelle la résolution du saut suivant du protocole Color-IP, où vous devez configurer une carte de résolution et appliquer aux services VPN. Cette fonctionnalité vous permet d’orienter le trafic en fonction des couleurs des services VPN de couche 2 et 3.

Junos OS prend en charge les LSP SR-TE colorés associés à une seule couleur. La fonctionnalité de mappage des services VPN basée sur les couleurs est prise en charge sur les LSP statiques colorés et les LSP SR-TE BGP.

Coloration des services VPN

En général, un service VPN peut se voir attribuer une couleur sur le routeur sortant où le NLRI VPN est annoncé, ou sur un routeur entrant où le VPN NLRI 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 assigné une couleur, la couleur est rattachée à un service VPN sous la forme d’une communauté étendue de couleur BGP.

Vous pouvez attribuer plusieurs couleurs à un service VPN, appelé services VPN multi-couleurs. Dans de tels cas, la dernière couleur jointe 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 sortants et/ou entrants via plusieurs stratégies dans l’ordre suivant :

  • Politique d’exportation BGP sur l’équipement sortant.

  • Politique d’importation BGP sur l’équipement entrant.

  • Politique d’importation VRF sur l’équipement entrant.

Les deux modes de coloration des services VPN sont les suivants :

Attribution des couleurs sortantes

Dans ce mode, l’équipement sortant (c’est-à-dire l’annonceur du VPN NLRI) 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 du service VPN, l’exportation de groupe ou l’exportation de voisins de groupe au niveau de la [edit protocols bgp] hiérarchie. Le VPN NLRI est annoncé par BGP avec la communauté étendue de couleurs spécifiée.

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 NLRIs de préfixe VPN de couche 3, aux RLAN VPN de couche 2 et aux NLRIs EVPN. La communauté étendue de couleurs est héritée de tous les routes VPN, importées et installées dans les VRF cibles sur un ou plusieurs équipements entrants.

Attribution des couleurs entrantes

Dans ce mode, l’équipement entrant (c’est-à-dire le récepteur du VPN NLRI) 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 voisins de groupe du service VPN au niveau de la [edit protocols bgp] hiérarchie. Tous les routes VPN correspondant à la stratégie de routage sont rattachées à la communauté étendue de couleurs spécifiée.

Par exemple :

Ou

Spécification du mode de mappage des services VPN

Pour spécifier des modes de mappage de services VPN flexibles, vous devez définir une stratégie à l’aide de l’instruction resolution-map et renvoyer la stratégie dans l’instance vrf-importde routage d’un service VPN, l’importation de groupe ou l’importation de voisins de groupe d’un service VPN au niveau de la [edit protocols bgp] hiérarchie. Tous les routes VPN correspondant à la stratégie de routage sont jointes à 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ù le(s) routage(s) VPN sont résolus à l’aide d’un saut suivant de protocole IP coloré sous la forme de ip-address:color.

Résolution du saut suivant du protocole Color-IP

Le processus de résolution du saut suivant du protocole est amélioré pour prendre en charge la résolution du saut suivant du protocole IP couleur. Pour un service VPN coloré, le processus de résolution du protocole prochain saut prend une couleur et une carte de résolution, construit un saut suivant de protocole IP coloré sous la forme de IP-address:color, et résout le saut suivant du protocole dans la table de routage inet6color.0.

Vous devez configurer une stratégie pour prendre en charge la résolution multichemin des services VPN de couche 2, VPN de couche 3 ou EVPN sur des LSP colorés. La stratégie doit ensuite être appliquée avec la table RIB concernée en tant que stratégie d’importation du résolveur.

Par exemple :

Résolution du saut suivant vers le protocole IP

Si un service VPN coloré n’a pas de carte de résolution qui lui est appliquée, le service VPN ignore sa couleur et revient à la résolution du saut suivant du protocole IP. Inversement, 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 du saut suivant du protocole IP.

Le resecours est un processus simple, des LSP SR-TE colorés aux LDP LDP, en utilisant un groupe RIB pour LDP pour installer des routes dans des tables de routage inet{6}color.0. Une correspondance de préfixe la plus longue pour un protocole IP coloré saut suivant garantit que si une route LSP SR-TE colorée n’existe pas, une route LDP avec une adresse IP correspondante doit être renvoyée.

Mappage unicast basé sur les couleurs avec étiquette BGP sur SR-TE

À partir de la version 20.2R1 de Junos OS, BGP Labeled Unicast (BGP-LU) peut résoudre les routes IPv4 ou IPv6 sur sr-TE (Segment Routing-Traffic Engineering) 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’un resolution map pour SR-TE. Un saut suivant de protocole coloré est construit et il est résolu sur un tunnel SR-TE coloré dans la ou inet6color.0 la inetcolor.0 table. BGP utilise inet.3 et inet6.3 tables pour le mappage non basé sur les couleurs. Cela vous permet de faire la publicité des préfixes IPv6 et IPv4 BGP-LU avec une adresse de saut suivant IPv6 dans des réseaux IPv6 uniquement où les routeurs n’ont pas d’adresse IPv4 configurée. Avec cette fonctionnalité, nous prenons actuellement en charge BGP IPv6 LU sur SR-TE avec l’underlay IS-IS.

Dans 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é sur l’interface 2001:db8::3701:2d05 dans le routeur D . BGP importe des stratégies pour attribuer 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 de couleur pour le préfixe LU BGP IPv6 en fonction de la stratégie de carte de résolution attribuée.

Figure 9 : BGP IPv6 LU sur couleur IPv6 SR-TE BGP IPv6 LU sur couleur IPv6 SR-TE

BGP-LU prend en charge les scénarios suivants :

  • BGP IPv4 LU sur couleur BGP IPv4 SR-TE, avec extensions ISIS/OSPF IPv4 SR.

  • BGP IPv4 LU sur sr-TE IPv4 statique et non coloré, avec extensions ISIS/OSPF IPv4 SR.

  • BGP IPv6 LU sur couleur BGP IPv6 SR-TE, avec extensions ISIS IPv6 SR.

  • BGP IPv6 LU sur sr-TE IPv6 statique et non coloré, avec extensions ISIS IPv6 SR.

  • Services VPN de couche 3 IPv6 avec adresse locale IPv6 et adresse voisine IPv6.

  • Services VPN de couche 3 IPv6 sur BGP IPv6 SR-TE, avec extensions ISIS IPv6 SR.

  • Services VPN de couche 3 IPv6 sur IPv6 SR-TE de couleur statique et non colorée, avec extensions ISIS IPv6 SR.

Fonctionnalités prises en charge et non prises en charge pour le mappage des services VPN basé sur la couleur

Les fonctionnalités et fonctionnalités suivantes sont prises en charge avec le mappage des services VPN basé sur les couleurs :

  • VPN de couche 2 BGP (VPN de couche 2 Kompella)

  • BGP EVPN

  • Carte de résolution avec une seule option IP couleur.

  • Résolution du saut suivant des protocoles IPv4 et IPv6 colorés.

  • Base d’informations de routage (également connue sous le nom de table de routage) de secours basée sur le groupe LSP LDP dans la table de routage inetcolor.0.

  • LSP SR-TE coloré.

  • Plateformes virtuelles.

  • Junos OS 64 bits.

  • Systèmes logiques.

  • Unicast étiquetée BGP.

Les fonctionnalités et fonctionnalités suivantes ne sont pas prises en charge avec le mappage des services VPN basé sur les couleurs :

  • LSP MPLS colorés, tels que RSVP, LDP, BGP-LU, statique.

  • Circuit de couche 2

  • FEC-129 BGP découverte automatique et vpn de couche 2 signalé par LDP.

  • VPLS

  • MVPN

  • IPv4 et IPv6 à l’aide de la carte de résolution.

Modèles de tunnel pour les LSP de routage de segments 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 transmettre deux paramètres supplémentaires pour ces LSP : la détection de transfert bidirectionnel (BFD) et la tunnelisation LDP.

Lorsqu’un LSP de routage de segments initié par PCE est créé, le LSP est vérifié par rapport aux déclarations de stratégie (le cas échéant) et s’il y a 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, la 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 supplémentaires de tunnelisation BFD et LDP ici.

  2. Incluez l’instruction source-routing-path-template-map au niveau de la [edit protocols source-packet-routing] hiérarchie pour lister les déclarations de stratégie en fonction desquelles le LSP initié par PCE doit être vérifié.

  3. Définissez une stratégie pour lister les LSP 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 lsp conditions et lsp-regex de correspondance. Ces options s’excluent mutuellement, vous ne pouvez donc spécifier qu’une seule option à un moment donné.

    L’énoncé then doit inclure l’option sr-te-template avec une action d’acceptation. Cela applique le modèle au LSP initié par PCE.

Lors de la configuration d’un modèle pour les LSP initiés par PCE, prenez en compte les éléments suivants :

  • La configuration du modèle n’est pas applicable aux LSP de routage de segments configurés statiquement ou au LSP de routage de segments d’un autre client.

  • La configuration fournie par PCEP a priorité sur la configuration du modèle.

  • PCEP LSP n’hérite pas de configuration de liste de segments de modèles.

Exemple : Configuration du chemin de commutation d’étiquettes de segments statiques

Cet exemple montre comment configurer des chemins de commutation d’étiquettes (LSP) statiques de routage de segments dans les réseaux MPLS. Cette configuration permet d’augmenter l’évolutivité des 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’équipement.

Présentation

Junos OS un ensemble de chemins de routage de segments explicites sont configurés 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 source-routing-path au [edit protocols source-packet-routing] niveau de la hiérarchie. Le tunnel de routage de segments a une adresse de destination et un ou plusieurs chemins primaires et, éventuellement, des chemins secondaires qui se réfèrent à la liste de segments. Chaque liste de segments se compose d’une séquence de sauts. Pour un tunnel de routage de segments statiques non colorés, le premier saut de la liste de segments spécifie une adresse IP de saut suivant immédiat et le deuxième saut vers nth spécifie les étiquettes SID correspondant à la liaison ou au nœud que traverse le chemin. Le routage vers la destination du tunnel de routage de segments est installé dans la table inet.3.

topologie

Dans cet exemple, configurez un VPN de couche 3 sur les routeurs de périphérie PE1 et PE5 du fournisseur. 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 le routeur PE1 et le routeur 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 labels SID d’adjacence avec des étiquettes pop et une interface sortante.

Figure 10 : Chemin de commutation d’étiquettes de segment routing statique Chemin de commutation d’étiquettes de segment routing statique

Configuration

Configuration rapide cli

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

PE1

PE2

PE3

PE4

PE5

CE1

CE2

Configuration du PE1 de l’équipement
Procédure étape par étape

L’exemple suivant exige que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation sur l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le guide de l’utilisateur CLI.

Pour configurer l’équipement PE1 :

  1. Configurez les interfaces.

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

  3. Configurez les interfaces avec le protocole MPLS et configurez la plage de labels MPLS.

  4. Configurez le type de groupe d’homologues, l’adresse locale, la famille de protocoles pour les NLRIs 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 labels des chemins primaires et secondaires pour les stratégies TE (Source Routing-Traffic Engineering) du protocole SPRING (Source Packet Routing).

  7. Configurez l’adresse IPv4 de destination, le label SID de liaison, le chemin de routage source principal 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 routeur distingueur, l’importation, l’exportation VRF et le label de la table. Configurez la stratégie d’exportation et l’interface de zone pour le protocole OSPF.

Résultats

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

Configuration du PE2 de l’équipement
Procédure étape par étape

L’exemple suivant exige que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation sur l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le guide de l’utilisateur CLI.

  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 des interfaces pour le protocole OSPF.

Résultats

À partir du mode de configuration du routeur PE2, confirmez votre configuration en entrant les show interfaces commandes 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 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

Depuis le mode opérationnel, saisissez la show route table inet.3 commande.

Sens

La sortie affiche les routes entrantes des tunnels de routage de segments.

Vérification des entrées de table de routage de la table de routage mpls.0 du routeur PE1
But

Vérifier les entrées de route de la table de routage mpls.0

Action

Depuis le mode opérationnel, saisissez la show route table mpls.0 commande.

Sens

La sortie affiche les labels SID des tunnels de routage de segments.

Vérification du LSP du routeur PE1 pour le trafic SPRING
But

Vérifiez les LSP conçus pour le trafic SPRING sur les routeurs entrants.

Action

Depuis le mode opérationnel, saisissez la show spring-traffic-engineering overview commande.

Sens

Le résultat affiche la présentation des LSP conçus pour le trafic SPRING sur le routeur entrant.

Vérification des LSP conçus pour le trafic SPRING sur le routeur entrant du routeur PE1
But

Vérifiez les LSP conçus pour le trafic SPRING sur le routeur entrant.

Action

Depuis le mode opérationnel, saisissez la show spring-traffic-engineering lsp detail commande.

Sens

La sortie affiche les détails des LSP conçus pour le trafic SPRING sur le routeur entrant

Vérification des entrées de table de routage de la table de routage mpls.0 du routeur PE2
But

Vérifiez les entrées de table de routage de la table de routage mpls.0 du routeur PE2.

Action

Depuis le mode opérationnel, saisissez la show route table mpls.0 commande.

Vérification de l’état des segments LSP statiques MPLS du routeur PE2
But

Vérifiez l’état des segments LSP MPLS du routeur PE2.

Action

Depuis le mode opérationnel, saisissez la show mpls static-lsp commande.

Sens

La sortie affiche l’état des segments LSP MPLS statiques du routeur PE2.

Activation du CSPF distribué pour les LSP de routage de segments

Avant la version 19.2R1S1 de Junos OS, 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. Grâce à la fonctionnalité CSPF (Constrained Shortest Path First) distribuée pour le routage de segments LSP, 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 mesure (ingénierie du trafic ou IGP). Les LSP sont calculés pour utiliser les chemins ECMP disponibles vers la destination avec la compression de la pile d’étiquettes de segment routing 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ée prend en charge le sous-ensemble de contraintes suivantes spécifiées dans le projet Internet, draft-ietf-spring-segment-routing-policy-03.txt, Segment Routing Policy for Traffic Engineering :

  • Inclusion et exclusion des groupes administratifs.

  • Inclusion d’adresses IP à sauts lâches ou stricts.

    REMARQUE :

    Vous ne pouvez spécifier que les IDs de routeur dans les contraintes de sauts lâches ou strictes. Dans junos OS version 19.2R1-S1, il est impossible de spécifier les étiquettes et autres adresses IP comme des contraintes de saut strictes ou lâches.

  • Nombre maximal d’IDs de segments (SID) dans la liste de 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 sr-TE (Segment Routing Traffic Engineering Engineering) de routage interdomaine.

  • Interfaces non numérotées.

  • Plusieurs protocoles de routage tels que OSPF, ISIS et BGP-LS, activés en même temps.

  • Calcul avec des préfixes ou des adresses decast comme destinations.

  • Inclure et exclure les adresses IP d’interface comme 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 la pile de labels avec CSPF.

Compression de la pile d’étiquettes activée

Une pile d’étiquettes compressée représente un ensemble de chemins d’une source à une destination. Il se compose généralement de SIDs de nœud et de SIDs 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 l’ECMP jusqu’à la destination, avec un nombre minimal de SID dans la pile, tout en respectant les contraintes.

Compression de la pile d’étiquettes désactivée

Le calcul CSPF multi-chemin avec compression de la pile d’étiquettes désactivé trouve jusqu’à N des listes de segments jusqu’à la destination, où :

  • Le coût de toutes les listes de segments est égal et identique à la mesure technique de trafic la plus courte pour atteindre la destination.

  • Chaque liste de segments est composée de SID d’adjacence.

  • La valeur de N est le nombre maximal de listes de segments autorisées pour le chemin candidat par configuration.

  • Aucune liste de segments n’est identique.

  • 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 SR-TE contient toutes les liaisons, nœuds, préfixes et leurs caractéristiques, que l’ingénierie du trafic soit ou non activée 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 liaisons IGP de tous les domaines que 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és

Vous pouvez utiliser un profil informatique pour regrouper logiquement les contraintes de calcul. Ces profils de calcul sont référencés par les chemins de routage de segments pour le calcul des LSP de routage de segments primaires et secondaires.

Pour configurer un profil informatique, incluez l’instruction de profil de calcul au niveau de la [edit protocols source-packet-routing] hiérarchie.

Les contraintes de calcul prises en charge sont les suivantes :

  • Administrative groups

    Vous pouvez configurer des groupes d’administrateurs au niveau hiérarchique [edit protocols mpls] . Junos OS applique la configuration de groupe d’administration aux interfaces SR-TE (Segment Routing Traffic Engineering).

    Pour configurer les contraintes de calcul, vous pouvez spécifier trois catégories pour un ensemble de groupes administratifs. La configuration de contrainte de calcul peut être commune à tous les chemins de routage de segments candidats, ou sous des chemins candidats individuels.

    • include-any: spécifie que toute liaison avec au moins un des groupes d’administration configurés dans la liste est acceptable pour le chemin à parcourir.

    • include-all: spécifie que n’importe quelle liaison avec tous les groupes d’administration configurés de la liste est acceptable pour le chemin à traverser.

    • exclude: spécifie que toute liaison 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’IDs de routeur dans le profil de calcul comme contrainte pour le calcul des chemins candidats SR-TE . Chaque saut doit être une adresse IPv4 et peut être de type strict ou lâche. Si le type de saut n’est pas configuré, le protocole strict est utilisé. Vous devez inclure l’option compute dans l’instruction segment-list lorsque vous spécifiez la contrainte de chemin explicite.

  • Maximum number of segment lists (ECMP paths)

    Vous pouvez associer un chemin de candidature à un certain nombre de listes de segments dynamiques. Les chemins sont des chemins ECMP, où chaque liste de segments se traduit en une passerelle de saut suivant avec un poids actif. 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 maximum-computed-segment-lists maximum-computed-segment-lists sous l’instruction de configuration du profil de calcul . Cette configuration détermine le nombre maximal de listes de segments calculées pour un LSP principal 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 répondent à 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 dans le profil de calcul, il remplace la maximum-segment-list-depth configuration au niveau hiérarchique, le [edit protocols source-packet-routing] cas échéant.

    Vous pouvez configurer cet attribut à l’aide de l’option maximum-segment-list-depth maximum-segment-list-depth sous l’instruction de configuration du profil de calcul .

  • Protected or unprotected adjacency SIDs

    Vous pouvez configurer un SID d’adjacence protégé ou non protégé comme une contrainte dans le profil de calcul pour éviter les liaisons avec le type DED 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 des métriques d’ingénierie du trafic des liaisons pour le calcul. La métrique d’ingénierie du trafic pour les liaisons 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 en utilisant la configuration de type métrique dans le profil de calcul.

    Vous pouvez configurer cet attribut à l’aide de l’option metric-type (igp | te) sous l’instruction de configuration du profil de calcul .

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 de 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 des chemins secondaires sont calculés, les liaisons, les nœuds et les SRLG empruntés par les chemins primaires ne sont pas évités pour le calcul. Pour plus d’informations sur les chemins primaires et secondaires, voir Configuration des LSP primaires et secondaires.

Pour tous les LSP dont le résultat de calcul a échoué, le calcul est rejugé au fur et à mesure que la base de données d’ingénierie du trafic (TED) change.

Interaction entre le calcul CSPF distribué et les fonctionnalités SR-TE

Poids associés aux chemins d’une stratégie SR-TE

Vous pouvez configurer des poids par rapport aux chemins SR-TE calculés et statiques, qui contribuent aux sauts suivants du routage. Cependant, un seul chemin avec le calcul peut entraîner plusieurs listes de segments. Ces listes de segments calculés sont traitées entre elles comme ECMP. Vous pouvez attribuer des poids ECMP hiérarchiques à ces segments, en tenant compte des poids assignés à chacun des primaires configurés.

Détection de la BFD Liveliness

Vous pouvez configurer la détection BFD liveliness pour les chemins primaires ou secondaires calculés. Chaque chemin primaire ou secondaire calculé peut donner lieu à plusieurs listes de segments. 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 primaires actifs tombent en panne, le chemin secondaire préprogrammé (si fourni) devient actif.

inherit-label-nexthops

Vous n’avez pas besoin d’activer explicitement la inherit-label-nexthops configuration sous la [edit protocols source-packet-routing segment-list segment-list-name] hiérarchie pour les chemins primaires ou secondaires calculés, car il s’agit d’un comportement par défaut.

Fonctionnalité de traduction automatique

Vous pouvez configurer la fonctionnalité de traduction automatique sur les listes de segments, et les chemins primaires ou secondaires avec la fonctionnalité de traduction automatique référence à ces listes de segments. D’autre part, la fonction principale ou secondaire sur laquelle la fonctionnalité de calcul est activée ne peut pas faire référence à une 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 un type de calcul et un autre avec un type de traduction automatique.

Configurations de calcul CSPF distribuées

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 elle sert également de nom pour ce chemin principal.

  • Un nom principal calculé doit avoir un nom configuré, et ce nom ne doit pas faire référence à une liste de segments configurée. Dans cet exemple, compute_segment1 n’est pas une liste de segments configurée.

  • Le compute_profile_red profil de calcul est appliqué au chemin principal avec le nom compute_segment1.

  • Le compute_profile_red profil de calcul comprend une liste de segments de type compute, qui est utilisée pour spécifier la contrainte de chemin explicite pour le calcul.

Les poids 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 comp_nh1, comp_nh2et , et comp_nh3que le saut suivant pour le chemin statique est static_nh, les poids sont appliqués 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 primaires et secondaires peuvent être de type informatique et avoir leurs propres profils de calcul.

Exemple 3

Dans l’exemple 3, lorsque le calcul est mentionné sous un chemin primaire ou secondaire, il en résulte un calcul local d’un chemin vers la destination, sans aucune contrainte ou autre paramètre pour le calcul.

Exemple : Configuration du transfert coS et du routage basé sur des stratégies pour les LSP SR-TE

SUMMARY Le transfert coS (CBF) et le routage basé sur des stratégies (PBR, également connu sous le nom de transfert basé sur des filtres) peuvent être activés pour les LSP SR-TE (Segment Routing-Traffic Engineered) non colorés pour orienter le trafic sélectif sur un chemin SR-TE explicite, ce qui vous offre l’avantage de gérer le 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 coS (CBF) et du routage basé sur les stratégies (PBR) pour les LSP SR-TE

Avec CBF et PBR, vous pouvez :

  • Utilisez des combinaisons de chemins SR-TE (Segment Routing-Traffic Engineering) pour orienter le trafic de service dans le cœur.

  • Choisissez les services d’appui à résoudre sur les chemins SR-TE sélectionnés.

Sources de chemins de routage de segments 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 les stratégies :

  • Static SR–TE paths— Chemins de routage à la source configurés de manière statique dont l’ensemble de la pile de labels est statiquement configuré.

  • PCEP— Provisionnement dynamique des chemins de routage source-routage créés sur un contrôleur et téléchargés sur un routeur entrant dans une ERO, soit via des extensions de routage de segments PCEP, soit dans une stratégie de routage de segments BGP via des extensions de routage de segments BGP.

  • Dynamic LSPs: les tunnels créés dynamiquement sont déclenchés via le module de tunnel dynamique qui ont une résolution ERO du dernier saut.

  • Auto-translated paths— Chemins de routage à la source configurés statiquement et traduits automatiquement.

Considérations relatives à la configuration du CBF et du PBR pour les LSP SR-TE

Rappelez-vous:

  • CBF et 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 équipement ; l’ordre de configuration détermine le type dans lequel les routes sont transférés.

  • Pour le PBR, si le premier saut du LSP SR-TE est un label, vous devez inclure l’instruction resolution preserve-nexthop-hiearchy au niveau de la [edit routing-options] hiérarchie.

  • Le transfert par classe des routes pour CBF n’est visible que dans la table de transfert et non sur les routes.

  • Le transfert basé sur des stratégies des routes pour le PBR est effectué sur les routes et est visible dans la sortie de show route commande.

Configurer le transfert coS et le routage basé sur des stratégies pour les LSP SR-TE

SUMMARY Le transfert coS (CBF) et le routage basé sur les stratégies (PBR, également appelé FBF de transfert basé sur des filtres) peuvent être utilisés pour orienter le trafic sélectif à l’aide d’un chemin sr-TE (Label Swtiched Path) (LSP). Seuls les LSP de routage de segments non colorés qui ont le saut suivant configuré comme label ou adresse IP premier saut prennent en charge 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 équipements 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, effectuez les opérations suivantes :

  1. Définissez la liste de 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, effectuez les opérations suivantes

  1. Définissez des classificateurs de points de code de services différenciés (DSCP) 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 attribuez des paquets aux files d’attente de sortie.

    Par exemple :

  3. Assignez les classificateurs configurés aux interfaces des équipements.

    Par exemple :

  4. Définissez des options de stratégie de transfert coS avec le prochain saut LSP LSP sr-TE.

    Par exemple :

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

    Par exemple :

  6. Configurez une déclaration de stratégie qui spécifie que les routes correspondant au filtre de routage sont soumises au mappage du saut suivant CoS spécifié par map-name.

    Par exemple :

  7. Appliquez la stratégie aux routes exportées de la table de routage vers la table de transfert. CBF est ainsi compatible avec 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 par classe des routes n’est visible que dans la table de transfert, contrairement au PBR, où les routes filtrées sont visibles dans la sortie de show route commande.

Pour configurer le PBR, effectuez les opérations suivantes

  1. Configurez une déclaration de stratégie qui spécifie que les routes correspondant au protocole et au filtre de routage sont soumises au saut suivant LSP, ou qu’elles sont équilibrées en charge en tant que chemins multiples à coût égal (ECMP) dans la table de transfert.

    Par exemple :

  2. Configurez l’équipement pour qu’il effectue une résolution de route personnalisée sur les sauts suivants du protocole.

    REMARQUE :

    L’énoncé resolution preserve-nexthop-hierarchy est obligatoire pour que le PBR fonctionne lorsque le premier saut du LSP SR-TE est un label.

  3. Appliquez la stratégie aux routes exportées 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 du 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 show route sortie de commande effectue le filtrage des routes basé sur des stratégies.

Activation de plusieurs chemins pour les LSP SR-TE dans PCEP

Vous pouvez configurer plusieurs chemins (primaires ou secondaires) pour les LSP SR-TE PCEP (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 configurés statiquement. 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 de plusieurs chemins pour les LSP SR-TE PCEP

  • Les LSP peuvent avoir plusieurs ensembles d’ERO vers une destination

  • Fournit des capacités d’équilibrage de charge en configurant les poids pour les EROs individuels

  • S’aligne sur le projet d’architecture SR-TE pour définir des chemins candidats

Les fonctionnalités PCEP suivantes sont prises en charge :

  • Lorsque PCEP pour plusieurs chemins est activé (par défaut), vous pouvez configurer plusieurs chemins primaires (ou secondaires) dans un chemin candidat configuré et contrôlé par CCP.

  • Lorsque le PCEP pour plusieurs chemins est désactivé, vous ne pouvez configurer qu’un seul chemin principal dans un chemin candidat. La configuration de chemin secondaire n’est pas autorisée.

Si vous activez les chemins multi-chemins PCEP, compute-profile vous pouvez désormais configurer un nombre maximal de listes de segments (maximum-computed-segment-lists) supérieur à 1.

REMARQUE :

Lorsque le PCEP pour plusieurs chemins est activé, CCPD n’envoie pas de contraintes pour les chemins candidats contrôlés par CCP.

Lorsque la fonctionnalité multi-chemin PCEP est activée, la configuration de 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 un indicateur de sauvegarde défini pour l’ERO. Les chemins principaux n’incluent pas le TLV MULTIPATH-BACKUP dans le message PCRpt. Le chemin secondaire inclut MULTIPATH-BACKUP-TLV avec ensemble d’indicateurs de sauvegarde.

Les fonctionnalités pcep suivantes sont prises en charge :

  • Multipath weight TLV (MULTIPATH-WEIGHT-TLV) dans l’objet path attribute (PATH-ATTRIB)

  • OBJET MULTIPATH-BACKUP TLV dans l’attribut de chemin (PATH-ATTRIB) uniquement pour les LSP SR-TE contrôlés par PCC

  • TLV MULTIPATH-CAP dans un objet LSP PCEP

  • Restreint plusieurs chemins primaires et secondaires dans le chemin de candidature SR lorsque le multi-chemin PCEP est désactivé

  • Plusieurs chemins primaires et chemins secondaires dans le chemin candidat SR lorsque le multichemin PCEP est activé pour les LSP contrôlés par PCC

  • Listes de segments calculés (max-computed-segment-lists) maximum de 1 dans le profil de calcul SR-TE pour les LSP délégués et initiés par le PCE

  • Plusieurs ERO pour le chemin candidat initié par PCE dans SR-TE et dans PCCD

  • LSP SRv6

  • SR MPLS (IPv4)

  • Tunnels dynamiques SR MPLS (IPv4)

  • Prise en charge multi-contrôleurs

  • Chemins ERO multiples pour les chemins candidats initiés par PCE, configurés et contrôlés par PCC, et délégués de couleurs et de candidats non colorés

  • Rétrocompatible avec les versions antérieures de Paragon Pathfinder. Pour une rétrocompatibilité, vous devez configurer disable-multipath-capability l’énoncé de configuration au niveau de la hiérarchie [edit protocols pcep]

  • Prise en charge du code d’erreur en cas d’échec de validation des chemins candidats initiés par PCE

    • Le nombre total de chemins de sous-candidats par parcours de candidature est limité à 127. Pour les LSP initiés par PCE, si le nombre de chemins ERO croise 127, LE SR-TE envoie ERROR à PCCD (et PCCD envoie un message d’erreur PCEP au 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 de l’erreur Sens Utilisation
19 20 Chemin de sauvegarde non pris en charge Cela se produit lorsque le TLV MULTIPATH-BACKUP 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 de candidature.

Limitations

Les limitations PCEP suivantes s’appliquent :

  • Les TLV suivants mentionnés dans le draft-ietf-pce-multipath-06 ne sont pas pris en charge :

    • TLV de sauvegarde multichemin

    • TLV de chemin de chemin opposé

    • Chemin de candidature composite

  • Lorsque la fonctionnalité multichemin 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 capacité multichemin (versions de Junos OS antérieures à 22.4R1), la configuration de plusieurs chemins sous-candidats est autorisée. Lorsque le pcep multi-segment est activé (par défaut), plusieurs chemins principaux sont autorisés pour les LSP contrôlés par CCP à des fins de création de rapports. Toutefois, un seul chemin principal est pris en charge pour le chemin candidat délégué lorsque le multi-segment PCEP est activé.

  • Les groupes d’administrateurs et toute autre contrainte ne seront pas notifiés au PCE pour les chemins candidats SR-MPLS et SRv6 configurés et contrôlés par CCP (avec une ou plusieurs configurations principales). Il n’y a pas d’impact sur les parcours candidats délégués et initiés par le PCE.

  • Lorsque la fonctionnalité multichemin PCEP est activée, la configuration de chemin secondaire est autorisée pour les chemins candidats non délégués. Lorsque la fonctionnalité multichemin PCEP est désactivée, la configuration de chemin secondaire n’est pas autorisée.

  • Les chemins candidats ne peuvent pas avoir de LSP pilotés par PCE et délégués.

  • Les chemins multiples de sous-candidats pour un chemin de candidature coloré initié par PCE ne sont pas pris en charge.

  • Les fonctionnalités de délégation avec plusieurs chemins de sous-candidats dans un chemin de candidature ne sont pas prises en charge.

Configuration

Pour permettre à PCCD d’envoyer une fonctionnalité multichemin TLV dans l’objet LSP afin de notifier la liste maximale de segments calculés pour un chemin candidat spécifique, incluez l’énoncé 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 multi-capacité PCEP pour tous les PCE, incluez l’instruction disable-multipath-capability de configuration au niveau de la hiérarchie [edit protocols pcep].

Vous pouvez activer les options de trace 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 d’affichage 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 (CCP).

  • user@host> show path-computation-client lsp extensive: affichez un niveau de sortie étendu sur chaque LSP connu , point à point et point à multipoint.

  • user@host> show path-computation active-pce: affiche l’état du multi-chemin dans les sessions.

  • user@host> show spring-traffic-engineering lsp detail: affichez les détails de l’ingénierie du trafic SPRING entrant.

Sécurité de la couche de transport pour les sessions PCEP

La sécurité de la couche de transport (TLS) prend en charge l’authentification par les pairs, le chiffrement et l’intégrité des messages. Vous pouvez activer TLS dans Path Computation Client (PCC) pour établir une connexion TCP avec l’élément PCE (Path Computation Element) 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 explique comment activer tls pour les sessions PCEP pour sécuriser les interactions avec PCE, y compris l’initiation des procédures TLS, le mécanisme de négociation TLS et les méthodes TLS pour l’authentification par les pairs. Le transport sécurisé de 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é (CCP ou PCE), la surveillance (interception de messages), la falsification et le déni de service.

  • Tire parti des 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 avoir activé l’instruction de configuration stricte tls, les événements suivants se produisent :

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

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

  3. Les procédures TLS sont lancées par le StartTLS message de PCE à PCC et de CCP à PCE. Le StartTLS message est envoyé par CCP et le StartTLSWait timer est lancé. Vous pouvez configurer le StartTLSWait timer 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 StartTLSWait minuteur est de 60 secondes et ne doit pas être inférieure à la OpenWait minuteur. La valeur du timer par défaut OpenWait est définie comme 60 secondes.

    • Si un message ouvert est reçu par PCC au lieu du StartTLS message, PCErr message avec type d’erreur défini sur 1 (échec de l’établissement de session PCEP) et valeur d’erreur définie sur 1 (réception d’un message ouvert non valide ou non ouvert), et la session TCP est fermée.

    • Si StartTLS le message n’est pas reçu de PCE, alors après l’expiration du StartTLSWait timer, PCC envoie un PCErr message avec type d’erreur défini sur 25 (échec PCEP StartTLS ) et valeur d’erreur définie sur 5 (aucun StartTLS message (ni PCErr/Open) avant StartTLSWait expiration du timer), et la session TCP est fermée.

  4. La négociation et l’établissement d’une connexion TLS ont lieu.

  5. L’échange de messages PCEP est démarré selon la RFC5440.

REMARQUE :

Si vous n’activez pas l’instruction tls-strict CLI au niveau [edit protocols pcep] hiérarchique, alors lors de l’établissement d’une session PCEP, si le StartTLS message est reçu par PCC au lieu du Open message, PCErr message avec Error-Type défini sur 1 (échec de l’établissement de session PCEP) et valeur d’erreur définie sur 1 (réception d’un message ouvert non valide ou non ouvert), alors 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 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 suivre la date d’expiration du certificat.

Établir 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 (équipements Junos OS/pce-serveur). 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 un CSR sur l’équipement et envoyez-le à 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. Le certificat et la clé privée sont copiés sur l’équipement et installés ensemble.

  2. Chargez l’autorité de certification (CA) sur le CCP afin que le certificat du serveur PCE puisse être validé par rapport à l’autorité de certification chargée.

    REMARQUE :

    Les CA peuvent être chargés dans une hiérarchie plate en tant qu’autorité de certification indépendante. Si une CA est une sous-CA 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 auto-signés ne sont pas autorisés.

  3. Activez TLS sur CCP.

  4. La session PCEP est établie sur TLS avec le mécanisme de négociation TLS.

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

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

  7. À l’issue d’une négociation à trois voies, la négociation TLS commence par utiliser les certificats et l’authentification à sens unique est effectuée (CCP authentifie le certificat du serveur). Le serveur et le client attendent le temps de StartTLSWait recevoir le StartTLS message. Vous pouvez configurer le StartTLSWait timer 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 StartTLSWait minuteur est de 60 secondes et ne doit pas être inférieure à la OpenWait minuteur. La valeur du timer par défaut OpenWait est définie comme 60 secondes.

  8. Une fois la session tls de négociation réussie, CCP et PCE lancent l’établissement des sessions 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 la 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 est expiré, révoqué ou rechargé pendant une session PCEP sur TLS en cours, la session en cours n’est pas affectée.

Comprendre le mécanisme de liaison TLS de base

La poignée de main est une série de messages échangés entre un serveur et un client. Les étapes exactes de la négociation 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 de négociation TLS :

  1. Client Hello— Le client lance la poignée de main en envoyant ce message. Ce message contient la version TLS, la liste des algorithmes cryptographiques ou de la suite de chiffrement pris en charge et d’autres détails sur le client.

  2. Server Hello— Le serveur répond au 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 auprès de l’autorité de certification configurée qui avait é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 Serveur Bonjour, 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 à l’aide de la clé publique du serveur (acquise dans le message Bonjour du serveur).

  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 d’arrivée chiffré avec la clé secrète partagée et des signaux de négociation terminés.

  8. Server Finished— Le serveur répond par le message de fin chiffré avec la clé secrète partagée et les signaux de négociation terminés.

  9. Exchange Messages— Les messages une fois la négociation terminée sont chiffrés symétriquement.

Diagnostic et validation 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 /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 :

  • LE TLS est activé sur LE CCP.

  • PCE est compatible TLS.

  • Une session TLS est établie. Cela indique également que le certificat de serveur PCE est valide.

  • L’état de la session PCEPS est opérationnel.

Optimisation des chemins de reporting et métriques calculées dans PCEP

L’objet métrique dans PCEP est utilisé à plusieurs fins. L’objet métrique indique le type de mesure utilisé pour l’optimisation des chemins. 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 métrique indique également la métrique calculée.

Nous prenons en charge l’objet métrique pour l’optimisation des chemins (protocole de passerelle intérieure, ingénierie du trafic et retard de chemin) et le reporting de métriques calculées pour les LSP RSVP et SR-TE.

REMARQUE :

L’objet métrique pour l’optimisation des chemins et la génération de rapports de métriques calculées ne s’applique pas aux LSP SRv6-TE.

Avantages de l’optimisation des chemins de reporting et des métriques calculées dans PCEP

  • Le reporting des métriques d’optimisation des chemins configurés dans CCP permet au PCE d’être conscient des contraintes utilisées pour le calcul des chemins.

  • Reporting des métriques calculées au PCE. Cela permet au PCE d’analyser si le LSP nécessite une optimisation supplémentaire.

Comprendre les métriques 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.

RSVP LSP créé localement

Pour optimiser les LSP RSVP créés localement avec des métriques, configurez les métriques d’optimisation (IGP, TE et retard de chemin) afin que la mesure configurée soit signalée via PCEP. La mesure calculée est envoyée sous forme de mesure réelle dans PCEP via le message PCRpt.

RSVP LSP délégué

Pour signaler les mesures d’optimisation pour les LSP RSVP délégués, configurez les métriques d’optimisation (IGP, TE et retard de chemin).

Intended Metric:

  • Lorsque la mesure d’optimisation est configurée au moment de la délégation du LSP, les informations sont envoyées au PCE via un message PCRpt.

  • Lorsque la métrique d’optimisation est configurée après la délégation de LSP, la modification est appliquée sur le LSP/communiqué 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 mesure prévue dans les messages PCRpt suivants jusqu’à ce que l’état du contrôle LSP soit contrôlé de l’extérieur.

  • Lorsque le message PCUpd est reçu, si la mesure d’optimisation n’est pas présente dans le message, les messages PCRpt suivants ne contiennent pas de mesure prévue.

  • Lorsque l’état du contrôle LSP passe à un contrôle local, la métrique d’optimisation configurée à partir de Junos CLI sera la mesure prévue dans le message PCRpt.

Actual Metric:

  • Tout en déléguant le LSP, le message PCRpt ne contient pas de mesure réelle.

  • Lorsque le message PCUpd est reçu, si une métrique est présente dans le message, la métrique est utilisée comme mesure réelle dans les messages PCRpt suivants jusqu’à ce que l’état du contrôle LSP soit contrôlé de l’extérieur.

  • Lorsque le message PCUpd est reçu, si la mesure calculée n’est pas présente dans le message, les messages PCRpt suivants ne contiennent pas de mesure réelle.

  • Lorsque l’état du contrôle LSP passe à un contrôle local, les mesures calculées par PCC sont envoyées en tant que mesure réelle dans le message PCRpt.

RSVP LSP initié par PCE

Pour signaler les mesures d’optimisation pour les LSP RSVP initiés par PCE, configurez les métriques d’optimisation (IGP, TE et retard de chemin) dans un modèle. Le modèle est ensuite appliqué au LSP intégré par PCE lorsque l’état du contrôle 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 le statut du contrôle LSP passe à un contrôle local.

  • Lorsque le message PCInit/PCUpd est reçu, si la mesure d’optimisation est présente dans le message, elle est utilisée comme mesure prévue dans les messages PCRpt suivants jusqu’à ce que l’état du contrôle LSP soit contrôlé de l’extérieur.

  • Lorsque le message PCInit/PCUpd est reçu, si la mesure d’optimisation n’est pas présente dans le message, les messages PCRpt suivants ne contiennent pas de mesure 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 mesure prévue dans le message PCRpt.

Actual Metric:

  • Lorsque le message PCInit/PCUpd est reçu, si la mesure calculée est présente dans le message, elle est utilisée comme mesure réelle dans les messages PCRpt suivants jusqu’à ce que l’état du contrôle LSP soit contrôlé de l’extérieur.

  • Lorsque le message PCInit/PCUpd est reçu, si la mesure calculée n’est pas présente dans le message, les messages PCRpt suivants ne contiennent pas de mesure réelle.

  • Lorsque l’état du contrôle LSP passe à un contrôle local, les mesures calculées par PCC sont envoyées en tant que mesure réelle dans le message PCRpt.

LSP SR-TE délégué

Pour signaler les mesures d’optimisation pour les LSP SR-TE (SR MPLS) délégués, configurez les mesures d’optimisation (IGP, TE et retard de chemin).

Intended Metric:

  • Lorsque la mesure 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 de LSP, la modification est appliquée sur le LSP/communiqué 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 mesure prévue dans les messages PCRpt suivants jusqu’à ce que l’état du contrôle LSP soit contrôlé de l’extérieur.

  • Lorsque le message PCUpd est reçu, si la mesure d’optimisation n’est pas présente dans le message, les messages PCRpt suivants ne contiennent pas de mesure prévue.

  • Lorsque l’état du contrôle LSP passe à un contrôle local, la métrique d’optimisation configurée à partir de Junos CLI sera la mesure prévue dans le message PCRpt.

Actual Metric:

  • Lorsque le LSP est délégué après la création, au moment de la délégation LSP si le LSP a 1 ERO, les valeurs calculées des mesures IGP, TE et retard sont envoyées en tant que mesures 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 LSP si le LSP a plusieurs ERO, la mesure réelle/métrique calculée n’est pas envoyée dans le message PCRpt, car la mesure 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 est présente dans le message, la métrique est utilisée comme mesure réelle dans les messages PCRpt suivants jusqu’à ce que l’état du contrôle LSP soit contrôlé de l’extérieur.

  • Lorsque le message PCUpd est reçu, si la mesure calculée n’est pas présente dans le message, les messages PCRpt suivants ne contiennent pas de mesure réelle.

  • Lorsque l’état du contrôle LSP passe à un contrôle local, les métriques IGP, TE et retards calculées dans CCP sont envoyées sous forme de mesures réelles dans le message PCRpt.

LSP SR-TE initié par PCE

Les métriques prévues ou les mesures réelles envoyées par PCE dans les messages PCInit/PCUpd sont renvoyées au PCE via un message PCRpt jusqu’à ce que le LSP soit contrôlé par l’extérieur.

Intended Metric:

  • Lorsque le message PCInit/PCUpd est reçu, si la mesure d’optimisation est présente dans le message, elle est utilisée comme mesure prévue dans les messages PCRpt suivants jusqu’à ce que l’état du contrôle LSP soit contrôlé de l’extérieur.

  • Lorsque le message PCInit/PCUpd est reçu, si la mesure d’optimisation n’est pas présente dans le message, les messages PCRpt suivants ne contiennent pas de mesure prévue.

  • Lorsque l’état du contrôle LSP devient contrôlé localement, la mesure prévue ne sera pas envoyée.

Actual Metric:

  • Lorsque le message PCInit/PCUpd est reçu, si une métrique est présente dans le message, elle est utilisée comme mesure réelle dans les messages PCRpt suivants jusqu’à ce que l’état du contrôle LSP soit contrôlé de l’extérieur.

  • Lorsque le message PCInit/PCUpd est reçu, si la mesure calculée n’est pas présente dans le message, les messages PCRpt suivants ne contiennent pas de mesure réelle.

  • Lorsque l’état du contrôle LSP passe à un contrôle local, les messages PCRpt suivants ne contiennent pas de mesure réelle.

Envoi d’une mesure d’optimisation dans un message PCRpt

La mesure d’optimisation est envoyée au PCE via le intended-attributes-list message pcrpt. La valeur métrique est définie sur 0 et B, les indicateurs C sur 0. Le type de mesure indique la mesure à optimiser.

Envoi d’un message métrique informatique dans PCRpt

Les métriques sont envoyées au PCE via le actual-attributes-list message pcrpt. La valeur métrique est la valeur métrique calculée et le type de mesure indique le type de mesure calculé. Le drapeau B est défini sur 0, le drapeau C sur 1.

Incompatibilité en arrière pour les mesures de route

Comme la métrique de route est prise en charge à l’aide des TLV du fournisseur, CCP ne traitera pas les métriques de route envoyées 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 retard de chemin) pour les LSP RSVP et SR-TE LSP.

Pour configurer les métriques d’optimisation IGP, TE et d’optimisation des retards 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 métriques d’optimisation IGP, TE et d’optimisation du retard 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 de calcul de chemin (PCC).

Voici un exemple de sortie de show path-computation-client lsp extensive:

Le résultat montre que le LSP est optimisé avec la métrique de type IGP. La valeur calculée de la métrique IGP est de 50. La métrique route installée dans la table de routage est 50.

Tableau de l'historique des versions
Version
Description
21.R1
À partir de la version 21.1R1 de Junos OS, Junos OS prend en charge le routage actif sans interruption (NSR) pour les LSP point à point et point à multipoint pilotés par RSVP basés sur PCE.
21.R1
À partir de la version 21.1R1 de Junos OS, Junos OS prend en charge le routage actif sans interruption (NSR) pour les LSP point à multipoint basés sur RSVP initiés par PCE.
20.2R1
À partir de la version 20.2R1 de Junos OS, BGP Labeled Unicast (BGP-LU) peut résoudre les routes IPv4 ou IPv6 sur sr-TE (Segment Routing-Traffic Engineering) pour les familles d’adresses IPv4 et IPv6.
19.4R1
Vous pouvez associer un seul ou plusieurs flux multicast MVPN (S,G) à un chemin de commutation d’étiquettes (LSP) initié par PCE dynamiquement.
19.4R1
Vous pouvez configurer un modèle de tunnel pour les LSP de routage de segments initiés par PCE afin de transmettre deux paramètres supplémentaires pour ces LSP : la détection de transfert bidirectionnel (BFD) et la tunnelisation LDP.
19.1R1
À partir de la version 19.1R1 de Junos OS, une fonctionnalité de vérification de validation est introduite pour s’assurer que toutes les listes de segments contribuant aux routes colorées ont le label minimum présent pour tous les sauts.
19.1R1
À partir de la version 19.1R1 de Junos OS, cette exigence ne s’applique pas, car le premier saut des LSP statiques non colorés prend désormais en charge les étiquettes SID, en plus des adresses IP. Grâce à la prise en charge du premier saut, le reroutage rapide MPLS (FRR) et le multichemin pondéré à coût égal sont activés pour résoudre les LSP statiques de routage de segments non colorés, semblables aux LSP statiques colorés.
18.2R1
À partir de la version 18.2R1 de Junos OS, les LSP de routage de segments non colorés configurés statiquement sur l’équipement entrant sont signalés au Path Computation Element Element Element (PCE) par le biais d’une session PCEP (Path Computation Element Protocol).
17.2R1
À partir de la version 17.2 de Junos OS, deux external cspfnouveaux types de calcul de chemin sont introduits pour les LSP contrôlés par PCE : local cspf et no cspf.
16.1
À partir de la version 16.1 de Junos OS, vous pouvez sécuriser une session PCEP à l’aide de l’authentification TCP-MD5 conformément à la RFC 5440.
16.1
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.
14.2R4
À partir de la version 14.2R4 de Junos OS, la bande passante automatique est prise en charge pour les LSP contrôlés par PCE.