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 routeur réseau en fonction d’un graphique réseau et en appliquant des contraintes informatiques. Un client de calcul de chemin (PCC) est toute application client demandant un calcul de chemin à effectuer par un PCE. Le protocole PCEP (Path Computation Element Protocol) permet de communication entre un PCC et un PCE, ou entre deux PCE (définis dans le RFC 5440).

Le PCEP est un protocole basé sur TCP défini par le groupe de travail IETF PCE. Il définit un ensemble de messages et d’objets utilisés pour gérer les sessions PCEP et pour demander et envoyer des chemins pour des LSP (TE LSP) de trafic multidomaine. Il fournit un mécanisme permettant à un PCE d’effectuer un calcul de chemin pour les LSP externes d’un PCC. Les interactions PCEP incluent des rapports d’état LSP envoyés par le PCC 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 à états dans MPLS RSVP-TE réseau.

Figure 1 : PCEP SessionPCEP Session

Une session PCEP basée sur TCP connecte un PCC à un PCE externe. Le PCC initie la session PCEP et reste connecté à l’ordinateur pour la durée de la session PCEP. Lors de la session PCEP, le PCC demande des paramètres LSP depuis le PCE à états. Lors de la réception d’un ou plusieurs paramètres LSP depuis l’ordinateur, le PCC signale de nouveau TE LSP. Lorsque la session PCEP est interrompue, la connexion TCP sous-jacente est fermée immédiatement et le PCC tente de rétablir la session PCEP.

Les fonctions PCEP incluent donc les fonctions suivantes:

  • Synchronisation de l’état de tunnel LSP entre un PCC et un PCE dynamique: lorsqu’une connexion PCE dynamique est détectée, un PCC tente de déléguer tous les LSP à ce PCE dans une procédure appelée synchronisation d’état LSP. PCEP permet la synchronisation de l’état LSP du PCC sur l’ordinateur.

  • Dégation du contrôle des tunnels LSP vers un PCE dynamique: un PCE dynamique actif contrôle un ou plusieurs attributs LSP pour les chemins de calcul, tels que la bande passante, le chemin (ERO) et la priorité (configuration et hold). Le PCEP permet de dégager les LSP pour le calcul de chemin.

  • Contrôle à états de l’heure PCE et de la séquence des calculs de chemin dans et entre les sessions PCEP: un PCE dynamique actif modifie un ou plusieurs attributs LSP, tels que la bande passante, le chemin (ERO) et la priorité (configuration et hold). Le PCEP communique ces nouveaux attributs LSP entre le PCE et le PCC, après quoi le PCC signale de nouveau le LSP dans le chemin spécifié.

Présentation de la prise en charge du protocole de l’élément de calcul de chemin pour RSVP-TE Web

Compréhension MPLS RSVP-TE

Les ingénieries de trafic (TE) s’occupent de l’optimisation des performances des réseaux opérationnels en mayant principalement les flux de trafic sur une topologie physique existante. Les ingénieries de trafic offrent la possibilité de déplacer le flux de trafic du chemin le plus court sélectionné par le protocole de passerelle intérieure (IGP) et sur un chemin physique potentiellement moins congestionné à travers un réseau.

Pour les ingénieries de trafic sur des réseaux denses de grande taille, des fonctionnalités MPLS peuvent être implémentées car elles fournissent potentiellement la plupart des fonctionnalités disponibles depuis un modèle de superposition, de manière intégrée et à un coût moindre que les solutions concurrentes. La principale raison de l’aspects techniques du trafic MPLS consiste à contrôler les chemins le long des flux de trafic à travers un réseau. Le principal avantage de la aspects techniques du trafic MPLS est qu’elle offre un mélange des capacités d’ingénierie du trafic d’ATM et de la différenciation des classes de service (CoS) de l’IP.

Dans un réseau MPLS, les informations du plan de données sont transfertées à l’aide de la commutation d’étiquettes. Un paquet qui arrive sur un routeur PE (Provider Edge) depuis le routeur de périphérie du client (CE) a des étiquettes appliquées sur ce routeur, puis il est transmis au routeur PE de sortie. Les étiquettes sont supprimées au niveau du routeur sortant, puis 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 transmettre le trafic entre et par le biais des LSR. Le protocole RSVP-TE de distribution d’étiquettes permet à un pair d’LSR d’en savoir plus sur les mappages d’étiquettes d’autres pairs.

Lorsque les MPLS et RSVP sont activés sur un routeur, MPLS devient 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, comme pour les flux unicast et multicast IP, et demande des paramètres de qualité de service (QoS) pour les applications. Le protocole est étendu en aspects techniques du trafic MPLS pour permettre à RSVP de configurer des LSP qui peuvent être utilisés pour les ingénieries de trafic MPLS réseaux.

Lorsque MPLS et RSVP sont combinés, les étiquettes sont associées aux flux RSVP. Une fois le LSP établi, le trafic à travers le chemin est défini par le label appliqué au nœud d’entrée du LSP. La mise en correspondance de l’étiquette au trafic est réalisée selon différents critères. L’ensemble de paquets qui sont assignés à la même valeur d’étiquette par un nœud spécifique appartient à la même classe d’équivalence de transfert (FEC) et définissent efficacement le flux RSVP. Lorsque le trafic est mapé sur un LSP de cette manière, le LSP s’appelle un tunnel LSP.

Les tunnels LSP sont un moyen d’établir des chemins unidirectionnels de commuté d’étiquettes. 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 la mise en place de LSP. Les nouveaux objets (objet LABEL-REQUEST (LRO), objet DE ROUTE ENREGISTREMENT (RRO), objet LABEL et objet DE ROUTE EXPLICITE (ERO) sont facultatifs en ce qui concerne le protocole RSVP, à l’exception des objets LRO et LABEL, qui sont tous deux obligatoires pour établir des tunnels LSP.

En général, le routeur RSVP-TE établit un chemin de commuté d’étiquettes qui assure la distribution de trames entre le routeur d’entrée et le routeur de sortie. Cependant, grâce aux nouvelles fonctionnalités d’ingénierie du trafic, les fonctions suivantes sont prise en charge dans MPLS domaine:

  • Possibilité d’établir un chemin de commuté d’étiquettes en utilisant un route intégral ou partiel explicite (RFC 3209).

  • Mise en place d’un LSP basé sur des contraintes sur des liaisons qui remplissent des exigences, telles que la bande passante et les propriétés de liaison.

  • Le contrôle des points d’extrémité, associé à l’établissement et à la gestion de tunnels LSP au niveau des routeurs d’entrée et de sortie.

  • La gestion des liaisons, qui gère les ressources de liaison pour mettre en place un routage des LSP des ingénieries de trafic en rapport avec les ressources et pour programmer MPLS étiquettes.

  • MPLS routeur rapide (FRR), qui gère les LSP qui ont besoin d’une protection et affecte des informations de tunnel de secours à ces LSP.

Limites MPLS RSVP-TE actuelles

Bien que les extensions RSVP pour les ingénieries de trafic permettent une meilleure utilisation du réseau et répondent aux exigences des classes de trafic, la suite de protocoles MPLS RSVP-TE présente plusieurs problèmes inhérents à sa nature distribuée. Cela pose un certain nombre de problèmes lors de la conflits pour la capacité de bisection, en particulier au sein d’une classe de priorité LSP où un sous-ensemble de LSP partage des valeurs de configuration et de priorité de priorité communes. Les limites du RSVP-TE sont les suivantes:

  • Manque de visibilité sur les demandes de bande passante individuelle par LSP et par équipement: les routeurs d’entrée dans un réseau MPLS RSVP-TE établissent des LSP sans avoir une vue globale de la demande en bande passante sur le réseau. Les informations sur l’utilisation des ressources réseau sont uniquement disponibles sous la mesure de la capacité totale réservée par classe de trafic par interface. L’état LSP individuel est disponible localement sur chaque routeur de périphérie d’étiquettes (LER) pour ses propres LSP uniquement. C’est pourquoi un certain nombre de problèmes liés aux schémas de demande apparaissent, notamment au sein d’une configuration et d’une priorité de priorité communes.

  • Nature asynchrone et indépendante de la signalisation RSVP: dans RSVP-TE, les contraintes de mise en place du chemin sont contrôlées par l’administrateur. Ainsi, la bande passante réservée à un tunnel LSP est définie par l’administrateur et n’implique pas automatiquement de limite sur le trafic envoyé par le tunnel. La bande passante disponible sur un lien d’ingénierie de trafic est donc la bande passante configurée pour cette liaison, à l’exception de la somme de toutes les réservations faites sur cette liaison. Ainsi, les exigences non alignées qui s’imposent sur un tunnel LSP entraînent une dégradation du service du LSP nécessitant un surcapacité, ainsi que les autres LSP conformes aux exigences de bande passante de la liaison des ingénieries de trafic.

  • Des LSP ont été créés en fonction d’options de chemin dynamiques ou explicites dans l’ordre de préférence: les routeurs d’entrée d’un réseau MPLS RSVP-TE établissent des LSP pour répondre aux demandes en fonction de l’ordre d’arrivée. Étant donné que les routeurs d’entrée n’ont pas de 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 la baisse du trafic ou l’instaurage des LSP lorsqu’une demande de bande passante supplémentaire est établie.

Par exemple, elle est configurée avec MPLS RSVP-TE, dans laquelle les A et G sont les routeurs de périphérie d’étiquettes Figure 2 (LER). Ces routeurs d’entrée établissent des LSP de façon indépendante en fonction de l’ordre des demandes et n’ont aucune connaissance ni aucun contrôle des LSP les uns des autres. Les routeurs B, C et D sont des routeurs intermédiaires ou de transit qui se connectent aux routeurs de sortie E et F.

Figure 2 : Exemple MPLS’ingénierie du trafic Exemple MPLS’ingénierie du trafic

Les routeurs d’entrée établissent des LSP en fonction de l’ordre d’arrivée des demandes. Si le routeur G reçoit deux demandes de capacité 5 chacun pour G-F, G signale deux LSP (LSP1 et LSP2) à G-B-D-F. De la même manière, lorsque le routeur A reçoit la troisième demande de capacité 10 pour A-E, alors il signale un LSP, un LSP3, par le biais d’A-B-C-E. Toutefois, si la demande sur le LSP A-E passe 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 dispose d’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. Puisque 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 max. adéquate soit disponible pour tous les LSP, le LSP3 risque de dégrader les services. Cette situation est due au manque de visibilité globale sur la demande du routeur A et à l’absence de coordination systémique de la position de la demande par les routeurs d’entrée A et G.

Utilisation d’une entité informatique de chemin externe

En tant que solution aux limites actuelles du calcul de chemin MPLS RSVP-TE, une entité externe de calcul de chemin avec une vue globale de la demande par LSP et par équipement sur le réseau, indépendamment de la capacité disponible, est requise.

Actuellement, seul le calcul de chemin de routage en ligne et en temps réel basé sur des MPLS RSVP-TE réseau. Chaque routeur réalise 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, des informations généralement récentes mais qui ne sont pas entièrement exactes. Les placements LSP sont optimisés localement, en fonction de l’état actuel du réseau. Les tunnels MPLS RSVP-TE sont mis en place à l’aide du CLI. Un opérateur configure le TE LSP, qui est ensuite signalé par le routeur d’entrée.

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

Pour plus d’informations, consultez Composants du calcul de chemin externe le site .

Pour activer le calcul de chemin externe pour les TE LSP d’un PCC, inclure l’instruction au niveau des niveaux lsp-external-controller pccd[edit mpls][edit mpls lsp lsp-name] hiérarchiques et.

Composants du calcul de chemin externe

Les composants d’un système informatique de chemin externe sont les éléments ci-après:

É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 routeur réseau en fonction d’un graphique réseau et en appliquant des contraintes de calcul. Toutefois, un PCE peut calculer le chemin pour les TE LSP d’un PCC qui ont été configurés pour un contrôle externe.

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

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

    Un PCE à états est deux types:

    • PCE passif à états: maintient la synchronisation avec le PCC et apprend les états LSP du PCC afin d’optimiser le calcul des chemins, mais sans les contrôler.

    • PCE dynamique actif: modifie activement les LSP du PCC, en plus d’en apprendre davantage sur les états du PCC LSP.

      Remarque :

      Dans une configuration redondante avec PCE dynamiques principales et actives de secours, le PCE dynamique actif de secours ne peut modifier les attributs des LSP déléguer jusqu’à ce qu’ils deviennent le PCE principal au moment du point de panne. Dans le cas d’un basculement, aucun pcE n’est préempté. Le PCE principal est alors supporté par un PCE de secours. En cas de panne du PCE principal, l’PCE de secours endosse le rôle du PCE principal et reste le PCE principal, même après la mise en service de l’PCE principal, qui était auparavant le principal PCE.

    Un PCE à états fournit les fonctions suivantes:

    • Calcul de chemin LSP hors ligne.

    • Déclenche le re-routeur LSP lorsqu’il est nécessaire de ré-optimiser le réseau.

    • Modification de la bande passante LSP en cas d’augmentation de la demande en bande passante d’une application.

    • Modifie les autres attributs LSP du routeur, tels que l’ERO, la priorité de configuration et la priorité de conserver.

    Un PCE dispose d’une vue globale de la demande de bande passante sur le réseau et tient à jour une base de données d’ingénierie du trafic pour effectuer des calculs de chemin. Il collecte des statistiques à partir de tous les routeurs du domaine MPLS à l’aide de SNMP et NETCONF. Ce mécanisme permet de contrôler hors ligne les TE LSP du PCC. Bien qu’un système de calcul de chemin LSP hors ligne puisse être intégré à un contrôleur réseau, l’ORDINATEURE agit comme un contrôleur réseau à part entière, qui permet de contrôler les LSP TE du PCC, en plus des chemins de calcul.

    Bien qu’un PCE à états assure un calcul optimal des chemins et un meilleur succès dans le 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 se souvient d’aucun chemin informatique et chaque ensemble de requêtes est traitée indépendamment les unes des autres (RFC 5440).

Client de calcul de chemin

Un client de calcul de chemin (PCC) est toute application client demandant un calcul de chemin à effectuer par un PCE.

Un PCC peut se connecter à un maximum de 10 PCE en même temps. La connexion PCC vers PCE peut être une route statique configurée ou une connexion TCP établissant une accessibilité. Le PCC attribue à chaque PCE connecté un numéro de priorité. Il envoie un message à tous les PCE connectés avec des informations sur ses LSP actuels, dans le cadre d’un processus appelé synchronisation d’état LSP. Pour les TE LSP avec un contrôle externe activé, le PCC délégue ces LSP au PCE principal. Le PCC choisit le PCE principal, un PCE avec le numéro de priorité le plus faible, ou le PCE à qui il se connecte en premier en l’absence de numéro de priorité.

Le PCC signale de nouveau un LSP en fonction du chemin informatique qu’il reçoit d’un PCE. Lorsque la session PCEP avec le PCE principal est terminée, le PCC choisit un nouveau PCE principal, et tous les LSP déléguer au PCE principal, anciennement principal, sont déléguer au PCE principal nouvellement disponible.

Protocole de l’élément de calcul de chemin

Le protocole PCEP (Path Computation Element Protocol) sert à la communication entre PCC et PCE (ainsi qu’entre deux PCE) (RFC 5440). Le PCEP est un protocole basé sur TCP défini par le groupe de travail IETF PCE. Il définit un ensemble de messages et d’objets utilisés pour gérer les sessions PCEP et pour demander et envoyer des chemins pour des LSP TE multidomaines. Les interactions du PCEP comprennent des messages PCC, ainsi que des notifications d’états spécifiques liés à l’utilisation d’un PCE dans le contexte de MPLS RSVP-TE. Lorsque le PCEP est utilisé pour la communication PCE-PCE, le PCE demandeur endosse le rôle de PCC.

Les fonctions PCEP incluent donc les fonctions suivantes:

  • Synchronisation d’état de tunnel LSP entre le PCC et un PCE à états.

  • D première dégéggée des tunnels LSP vers un PCE à états.

Interaction entre un PCE et un PCC à l’aide du PCEP

Figure 3 illustre la relation entre un PCE, un PCC et le rôle du PCEP dans le cadre du 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 PCC initie la session PCEP et reste connecté à un PCE pour la durée de la session PCEP.

Remarque :

À partir Junos OS version 16.1, vous pouvez sécuriser une session PCEP à l’aide de l’authentification TCP-MD5 au titre du 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 hiérarchie pour une [edit protocols pcep pce pce-id] session PCEP. Vous pouvez toutefois utiliser une clé prédéfinie du niveau hiérarchique pour sécuriser [edit security authentication-key-chains key-chain] une session PCEP. Dans ce cas, vous devez lier la clé prédéfinie à la session PCEP au niveau [edit protocols pcep pce pce-id] de la hiérarchie.

Le PCE et le PCC utilisent la même clé pour vérifier l’authenticité de chaque segment envoyé sur la connexion TCP de la session PCEP, sécurisant ainsi la communication PCEP entre les équipements, qui peut être l’objet d’attaques et qui peut perturber les services sur le réseau.

Pour plus d’informations sur la sécurisation des sessions PCEP à l’aide de l’authentification MD5, Authentification TCP-MD5 pour les sessions PCEP consultez.

Une fois la session PCEP établie, le PCC effectue les tâches suivantes:

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

    Pour les LSP lancés par PCE, il n’y a aucune configuration LSP sur le PCC. L’équipe PCE à l’initiative du LSP envoie au PCC les paramètres LSP qui indiquent sa capacité à prendre en charge les LSP initiés par PCE.

    Remarque :

    La prise en charge des LSP à partir de PCE est Junos OS version 13.3 et ultérieure.

  2. Délégue du LSP: après synchronisation des informations sur l’état du LSP, le PCC délégue ensuite les LSP externes à un PCE (PCE) dynamique principal. Seul le PCE principal peut définir des paramètres pour le LSP externe. Les paramètres que le PCE principal modifie incluent la bande passante, le chemin (ERO) et la priorité (configuration et hold). Les paramètres spécifiés dans la configuration locale sont à l’aune des paramètres paramétrables par le PCE principal.

    Remarque :

    Lorsque la session PCEP avec le PCE principal est terminée, le PCC choisit un nouveau PCE principal, et tous les LSP déléguer au PCE principal, anciennement principal, sont déléguer au PCE principal nouvellement disponible.

    Dans le cas des LSP lancés par PCE, le PCC crée le LSP en utilisant les paramètres reçus du PCE. Le PCC affecte au LSP lancé par PCE un ID LSP unique, puis délégue automatiquement le LSP au PCE. Un PCC ne peut pas révoquer la d entre elles pour une session PCEP active des LSP initiés par PCE.

    Lorsqu’une session PCEP s’termine, le PCC lance deux timeurs sans supprimer immédiatement les LSP initiés par PCE, et – pour éviter toute interruption des delegation cleanup timeoutlsp cleanup timer services. Pendant cette période, un PCE dynamique actif peut acquérir le contrôle des LSP provisionnables par l’ordinateur a échoué, en envoyant une requête créer pour le LSP.

    Le contrôle sur les LSP lancés par PCE revient au PCC à l’expiration du delegation cleanup timeout . Lorsque l’expire et qu’aucun autre PCE n’a pris le contrôle du LSP depuis l’ordinateur échec, le PCC prend le contrôle local du LSP non déléguer au delegation cleanup timeout PCE. Plus tard, lorsque l’original ou le nouveau PCE dynamique actif souhaite prendre le contrôle des LSP contrôlés localement par PCE, le PCC délégue ces LSP au PCE et au timer lsp cleanup timer est arrêté.

    Un PCE peut renvoyer la DSP initiée par PCE au PCC afin d’autoriser le transfert de LSP entre les PCE. Cela déclenche le LSP pour le lsp cleanup timer LSP à l’initiative de PCE. Le PCC attend que le temps de nettoyage LSP expire avant de retirer les LSP non déléguer les LSP non déléguer du PCE défaillon.

    Lorsque l’expire et qu’aucun autre PCE n’a acquis le contrôle des LSP depuis l’ordinateur échec, le PCC supprime tous les LSP provisionés par le lsp cleanup timer PCE défaillon.

    Remarque :

    Conformément au projet-ietf-pce-stateful-pce-09, l’révocation des déléguations LSP lancées par PCE par un PCC se produit de façon pré-break, avant que les LSP soient redélégués à un PCE alternatif. À partir Junos OS du 18.1R1, le PCC doit être supérieur ou égal au PCC pour révoquer les d lsp-cleanup-timerdelegation-cleanup-timeout premières d’entre vous. Si ce n’est pas le cas, l’intervalle d’délai de redéélégation du PCC peut être fixé de façon à ce que les délégations du LSP à ce PCE restent intacts jusqu’à ce que le PCC prend des mesures spécifiques pour modifier les paramètres fixés par le PCE.

  3. Signalisation LSP: lors de la réception d’un ou plusieurs paramètres LSP provenant du PCE dynamique principal, le PCC signale de nouveau le LSP de TE en fonction du chemin fourni par PCE. Si le PCC ne parvient pas à configurer le LSP, il notifie l’pcE de la défaillance de configuration et attend que le PCE principal fournisse de nouveaux paramètres pour ce LSP, puis le signale de nouveau.

    Lorsque le PCE indique un chemin qui est incomplète ou dont les sauts sont lâches et où seuls les points de terminaison du chemin sont spécifiés, le PCC ne réalise pas de routage local basé sur des contraintes pour connaître l’ensemble des sauts. Le PCC fournit alors à RSVP un chemin fourni par PCE, tel qu’il est, pour la signalisation, et le chemin est mis en place à l’aide IGP routage saut par bond.

Au vu de la topologie utilisée dans , illustre l’implémentation partielle d’un PCE côté client dans le MPLS Figure 2Figure 4 RSVP-TE réseau. Les routeurs d’entrée A et G sont des PCC configurés pour se connecter au PCE à états externe par le biais d’une connexion TCP.

Le PCE dispose d’une vue globale de la demande de bande passante sur le réseau et effectue des calculs de chemin externe après avoir pris en compte la base de données des ingénieries de trafic. L’ordinateur PCE dynamique actif modifie un ou plusieurs attributs LSP et envoie une mise à jour au PCC. Le PCC utilise les paramètres qu’il reçoit de l’ordinateur pour signaler de 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 exploitation coopérative de fonctionnalités distribuées, utilisée pour répondre aux défis spécifiques d’un calcul de chemin interdomaine plus court, soumis à des contraintes de chemin. Il élimine les scénarios de congestion dans lesquels les flux de trafic sont mal matés sur les ressources disponibles, ce qui entraîne une surutilisation de certains sous-ensembles de ressources réseau, tandis que d’autres ressources demeurent sous-utilisées.

Comportement LSP avec l’informatique externe

LSP Types

Dans une implémentation PCE côté client, il existe trois types TE LSP:

  • CLI LSP contrôlés par contrôle: les LSP qui ne sont pas configurés sont appelés lsp-external-controller pccd CLI LSP contrôlés par le système. Bien que ces LSP soient sous contrôle local, le PCC met à jour les PCE connectés avec des informations sur les LSP contrôlés par CLI lors du processus de synchronisation LSP initial. Après la synchronisation LSP initiale, le PCC informe l’ordinateur de tout LSP nouveau et supprimé.

  • LSP contrôlés par PCE: les LSP avec l’instruction configurée sont appelés lsp-external-controller pccd LSP contrôlés par PCE. Le PCC délégue les LSP lancés par le PCC au PCE principal pour le calcul de chemin externe.

    Le PCC informe le PCE des paramètres configurés d’un LSP contrôlé par PCE, tels que la bande passante, l’ERO et les priorités. Il informe également le PCE des valeurs réelles utilisées pour ces paramètres pour configurer le LSP, y compris le RRO, lorsqu’il est disponible.

    Le PCC n’envoie ces rapports d’état LSP à l’ordinateur que lorsqu’une reconfiguration s’est produite ou lorsqu’il y a une modification de l’ERO, du RRO ou du statut des LSP contrôlés par PCE sous contrôle externe.

    La configuration d’un LSP pour un PCE CLI deux types de paramètres:

    • Des paramètres qui ne sont pas surchargés par un PCE et qui sont appliqués immédiatement.

    • Paramètres à l’override par un PCE. Ces paramètres incluent la bande passante, le chemin et la priorité (configuration et valeurs de conserver). Lorsque le mode de contrôle passe d’une configuration externe à une configuration locale, les valeurs configurées par CLI pour ces paramètres sont appliquées à la prochaine occasion de signaler à nouveau le LSP. Les valeurs ne sont pas appliquées immédiatement.

  • LSP provisionnables de l’extérieur (ou LSP à l’initiative de PCE): les LSP qui ont configuré l’instruction sont appelés LSP à l’initiative de lsp-provisioning PCE. Un LSP à l’initiative de PCE est créé de façon dynamique par un PCE externe ; il n’y a donc aucune configuration LSP sur le PCC. Le PCC crée le LSP à partir des paramètres fournis par le PCE, puis délégue automatiquement le LSP au PCE.

    Remarque :

    La prise en charge des LSP à partir de PCE est Junos OS version 13.3 et ultérieure.

Les LSP CLI contrôlés par PCE, les LSP contrôlés par PCE et les LSP à partir de PCE peuvent coexister sur un PCC.

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

Mode contrôle LSP

Dans une implémentation PCE côté client, il existe deux types de modes de contrôle pour un LSP contrôlé par PCC:

  • Externe: tous les LSP contrôlés par PCE sont par défaut sous contrôle externe. Lorsqu’un LSP est sous contrôle externe, le PCC utilise les paramètres fournis par PCE pour configurer le LSP.

  • Local: un LSP contrôlé par PCE peut être contrôlé localement. Lorsque les commutateurs LSP passent du contrôle externe au contrôle local, le calcul du chemin est effectué à l’aide CLI paramètres configurés et d’un routage basé sur les contraintes. Un tel basculement n’est se produit que si un déclencheur signale de nouveau le LSP. D’ici là, le PCC utilise les paramètres fournis par PCE pour signaler le LSP contrôlé par PCE, même si le LSP reste sous contrôle local.

Des commutateurs LSP contrôlés par PCE vers un contrôle local depuis son mode de contrôle externe par défaut, par exemple en l’absence de connectivité à un PCE ou lorsqu’un PCE renvoie une dégéggée de LSP au PCC.

Pour en savoir plus sur CLI LSP et LSP contrôlés par PCE, consultez . LSP Types

Déclarations de configuration prise en charge pour l’informatique externe

Tableau 1 répertorie les MPLS de configuration LSP existantes qui s’appliquent à un LSP contrôlé par PCE.

Tableau 1 : Pertinence des MPLS configurations LSP existantes vers un LSP contrôlé par PCE

Prise en charge des LSP contrôlés par PCE

Déclarations de configuration LSP applicables

Déclarations MPLS de configuration applicables

Ces instructions de configuration peuvent être configurées avec la configuration PCE. Toutefois, elles n’entrent en vigueur que lorsque la configuration locale est en cours d’utilisation. Pendant le contrôle PCE, ces instructions de configuration restent inactives.

  • groupe d’administrateurs

  • bande passante automatique

  • limite du saut

  • le moins rempli

  • les plus en charge

  • Aléatoire

  • groupe d’administrateurs

  • groupes d’administrateurs

  • groupe d’administrateurs étendu

  • limite du saut

  • no-cspf

  • smart-optimize-timer

Ces instructions de configuration peuvent être configurées avec la configuration PCE, mais sont adées par les attributs LSP contrôlés par PCE. Cependant, lorsque la configuration locale est en cours d’utilisation, les valeurs configurées pour ces instructions de configuration sont appliquées.

Remarque :

Modifications de la configuration locale à l’aide CLI alors que le LSP est sous le contrôle d’un PCE à états n’a 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’applique de la même manière que pour les LSP existants. Lors de la configuration de l’une des instructions de configuration ci-dessus pour un LSP contrôlé par PCE, un message de journal MPLS est généré pour indiquer quand les paramètres configurés entrent en vigueur.

Protection LSP contrôlée par PCE

Les chemins de protection, notamment le reroutage rapide et la dérivation des LSP, sont calculés localement par le PCC à l’aide d’un routage basé sur les contraintes. Un PCE à états ne spécifie que le chemin principal (ERO). Un PCE peut également déclencher un chemin secondaire non en veille, même si la configuration locale ne propose pas de chemin secondaire non en veille pour la protection LSP.

ERO LSP contrôlé par PCE

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

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

  • local cspf—Un PCC n’utilise le type de calcul que lorsque l’ordinateur envoie un Juniper local cspf fournisseur TLV (numéro d’entreprise: 0x0a4c) du type 5.

  • no cspf—Le PCE et le PCC ne réalisent pas de calcul de chemin soumis à des contraintes. Les points de terminaison et les contraintes sont attribués au module RSVP pour la configuration du LSP avec IGP chemin d’accès.

    Un PCC utilise un no cspf type de calcul dans les cas suivants:

    • Lorsque le PCE envoie des messages TLV et que le modèle de configuration Junos OS ou de modèle correspondant à ce LSP est inclus dans le LSP délègue local cspfno-cspf par le PCC.

    • Lorsque l’ordinateur envoie des messages TLV et que le modèle de configuration Junos OS pour ce LSP est inclus dans le LSP à initiative local cspfno-cspf PCE.

    • Lorsque l’ordinateur PCE n’envoie pas de TLV avec un ERO vide ou un ERO vague (avec des bits lâches placés dans local cspf l’objet ERO).

Avec ces nouveaux types de calcul, un PCC peut accepter un objet ERO comme ERO vague ou comme ERO vide. Une entité externe de calcul de chemin qui n’est pas capable de calcul d’un chemin peut modifier des paramètres tels que la bande passante et la couleur, en fonction de l’analyse. Dans ce cas, un objet ERO vide ou un ERO vague est utilisé et le PCC décide de la voie à suivre.

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

Une fois qu’une session PCEP est établie entre un PCE et un PCC, le PCC signale tous les LSP du système au PCE pour une synchronisation de l’état LSP. Il s’agit notamment de LSP point à point pcE, contrôlés par le PCC, délédés par PCE et pcE. Depuis la Junos OS version 15.1F6 et 16.1R1, cette fonctionnalité est également é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 un ensemble de LSP point à point groupé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 PCC. Pour ajouter cette fonctionnalité, inclure p2mp-lsp-report-capability l’instruction au niveau supérieur ou [edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id] hiérarchique. Une fois la fonctionnalité de rapport point-multipoint configurée sur un PCC, le PCC en fait la publicité sur le PCE. Si le PCE présente la même fonctionnalité de rapport point à multipoint en retour, le PCC signale alors l’arborescence LSP point-multipoint complète au PCE pour la synchronisation de l’état LSP.

Un PCC avec la fonctionnalité LSP TE point à multipoint prend en charge la reporting des LSP TE point à multipoint pour les PCE à états, la mise à jour point à multipoint et la prise en charge du nom LSP point-à-multipoint comme clé. Cependant, les fonctionnalités et fonctions suivantes ne sont pas Junos OS version 15.1F6 et 16.1:

  • LSP statiques point à multipoint

  • LSP point à multipoint, délégue par PCE et PCE

  • Bande passante automatique

  • TE++

  • Requête PCE et message de réponse

  • Création de LSP point à multipoint à l’aide de modèles

  • Configuration de l’entrée de sortie sur les LSP point-multipoint initiés par PCE

  • La configuration d’une entrée de avance sur le pointage du routeur vers un LSP provisionnable.

LSP point à point pcE

Depuis Junos OS version 16.1, la fonctionnalité PCEP est étendue afin de permettre à un PCE à états d’initier et de provisioner des LSP d’ingénierie de trafic via un PCC. Plus tôt, les LSP ont été configurés sur le PCC et le PCC a déléguer le contrôle des LSP externes à un PCE. Le PCC maintenait la propriété de l’état LSP. Avec l’introduction des LSP à l’initiative de PCE, un PCE peut lancer et provisioner un LSP point-à-point d’ingénierie du trafic de manière dynamique, sans avoir à mettre en place un LSP configuré localement sur le PCC. Une fois qu’un PCE reçoit un message PCCreate, le PCC crée le LSP lancé par PCE et délégue automatiquement le LSP au PCE.

Par défaut, le PCC rejette la demande de provisionnement des LSP point à point PCE depuis un PCE. Pour permettre la prise en charge de LSP initated PCE sur le PCC, inclure l’instruction de provisionisation lsp au niveau de la hiérarchie [edit protocols pcep pce pce-id] ou au niveau [edit protocols pcep pce-group group-id] supérieur.

Un PCC indique sa capacité à prendre en charge les LSP point à point pcE lors de l’établissement de la session PCEP (Path Computation Element Protocol) avec le PCE. Un PCE sélectionne un PCC avec cette capacité pour lancer un LSP. Le PCE fournit au PCC les paramètres LSP initiés par PCE. Une fois les paramètres LSP point à point lancés par PCE, le PCC définit le LSP, assigne un ID LSP et délégue automatiquement le LSP au PCE.

Lorsque le PCE à l’initiative du LSP ne fournit pas les paramètres LSP point à point pcE, le PCC utilise les paramètres par défaut. Un modèle LSP facultatif peut également être configuré pour spécifier des valeurs pour le LSP point à point pcE lorsque les paramètres LSP ne sont pas fournis par l’ordinateur. Pour configurer un modèle LSP pour les LSP point-to-point (point-to-point) activés par PCE sur le PCC, inclure l’instruction de modèle de chemin commuté par étiquette au niveau de la label-switched-path-template[edit protocols mpls lsp-external-controller lsp-external-controller] hiérarchie.

Lorsqu’une session PCEP prend fin, le PCC lance deux timeurs sans supprimer immédiatement les SSP initiés par PCE, et ce afin d’éviter toute interruption des delegation cleanup timeoutlsp cleanup timer services. Pendant cette période, un PCE dynamique actif peut acquérir le contrôle des LSP provisionnables par le PCE échec.

Un PCE peut renvoyer la DSP point à point pcE au PCC afin d’autoriser le transfert LSP entre PCE. Le contrôle sur les LSP à l’initiative de PCE revient au PCC à l’expiration du délai d’expiration de la dréption. Lorsque le délai d’expiration de la délégue vient à expiration et qu’aucun autre PCE n’a pris le contrôle du LSP depuis l’échec de l’examen PCE, le PCC prend le contrôle local du LSP non délégueré. Plus tard, lorsque l’original ou le nouveau PCE dynamique actif souhaite prendre le contrôle des LSP point à point contrôlés localement, le PCC délégue ces LSP au PCE et au programme de nettoyage LSP.

Le PCC attend que le temps de nettoyage LSP expire avant de supprimer les LSP point à point non déléguer les LSP point à point non déléguer du PCE défaillon. Lorsque le temps de nettoyage de LSP expire et qu’aucun autre PCE n’a pris le contrôle des LSP depuis l’ordinateur échec, le PCC supprime tous les LSP provisionés par l’ordinateur pcE défaillon.

À partir de Junos OS version 21.1R1, nous pris en charge le routage actif sans arrêt (NSR) pour les LSP point à point et point-à-multipoint basés sur RSVP et PCE. Seule la carte principale moteur de routage conserve la session PCEP avec le contrôleur. Il synchronise tous les LSP RSVP lancés par les PCE, y compris les spécifications de flux multicast pour tous les LSP P2MP à l’initiative de PCE, avec la moteur de routage. Lors d’un basculement, la session PCEP tombe en panne et établit de nouveau lorsque la moteur de routage devient le principal moteur de routage. Cela réduit les pertes de trafic pour le trafic transporté par les LSP RSVP lancés par PCE pendant moteur de routage commutation. Cette fonctionnalité est activée lorsque le NSR est configuré.

Dérivation LSP à l’initiative de PCE

Compréhension des LSP de dérivation lancées par PCE

Il peut y avoir des pannes de trafic en cas de défaillance d’une liaison ou d’un nœud, car les chemins de protection de secours du réseau ne sont pas suffisamment gourmands en bande passante pour gérer le trafic. Dans ces réseaux, même si un PCE peut être utilisé pour calcul de tous les chemins, afin d’optimiser les performances du réseau, les chemins de protection locaux doivent également être contrôlés par l’intermédiaire du PCE.

Junos OS Version 19.2R1 et autres version ultérieures offrent une prise en charge partielle de l’ébauche d’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 afin de permettre à un PCE à états d’initier, de provisionnement et de gérer des LSP de contournement pour une interface protégée. Plusieurs LSP de dérivation avec réservation de bande passante peuvent être lancés par le PCE pour protéger une liaison ou un nœud. On s’attend à ce que la bande passante du LSP de dérivation soit plus faible que celle des LSP principaux qu’elle peut protéger.

Le mécanisme de sélection de dérivation existant, qui préfère la dérivation manuelle des LSP (si possible) au contournement dynamique des LSP, est étendu pour préférer les LSP de dérivation provisionné par PCE (si possible) par rapport aux LSP de dérivation dynamique. Les LSP de dérivation provisionné par PCE ont une préférence plus élevée sur les LSP de dérivation dynamique, mais sont moins privilégiées par rapport aux LSP de dérivation manuelle.

L’ensemble d’opérations utilisées pour effectuer des dérivations opérationnelles des LSP, par exemple, peut également être exécuté sur les LSP de dérivation initiés par clear rsvp session PCE. Vous pouvez utiliser des commandes, telles que des statistiques de contournement LSP initiées par show path-computation-client status extensiveshow path-computation-client lsp PCE.

Avec la prise en charge de la dérivation LSP lancée par PCE, vous pouvez:

  • Créez un DÉRIVATION RSVP LSP via PCEP à partir d’un contrôleur externe, où le dérivation LSP:

    • peut être pour la protection des liaisons ou des nœuds.

    • doit avoir une bande passante non-zéro.

    • doit avoir un ERO strict spécifié.

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

  • Sursinscrire la bande passante LSP de dérivation pour contrôler l’admission des LSP principaux. Il doit s’agit d’un paramètre par dérivation et permettre la mise à jour de l’abonnement par LSP de contournement.

Avantages de la dérivation LSP à l’initiative PCE

Les LSP de dérivation par PCE offrent les avantages suivants:

  • Meilleur contrôle du trafic en cas de panne et calcul de chemin plus déterministe des chemins de protection.

  • Répondez aux contraintes complexes et aux exigences de diversité, telles que le maintien de chemins divers pour les LSP, ainsi que leurs chemins de protection locaux.

  • Assurez-vous que les liaisons ne sont pas trop surchargées en cas d’échec.

Comportement des LSP de dérivation par PCE en cas de défaillance de session PCEP

En cas de défaillance d’une session PCEP, les LSP de dérivation initiés par PCE deviennent insaisiables jusqu’à l’expiration du timeout timer d’état. Les LSP de dérivation lancés par PCE sont nettoyer lors de l’expiration du timeout timer d’état. Pour obtenir le contrôle d’un LSP de dérivation lancé par PCE (après l’échec de la session PCEP), un PCE (PCE principal ou tout PCE secondaire) envoie un message PCInitiate avant l’expiration du timeout d’état.

LSP point à multipoint pcE

Avec l’introduction de LSP point-à-multipoint, un PCE peut lancer et provisioner un LSP point à multipoint de manière dynamique, sans qu’une configuration LSP locale ne soit nécessaire sur le PCC. Cela permet au PCE de contrôler l’heure et la séquence des calculs de chemin point-multipoint dans 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, consultez le protocole Understanding Path Computation Element Protocol for MPLS RSVP-TE with Support for PCE-Initiated Point-to-Multipoint LSP.

Bande passante automatique et LSP contrôlée par PCE

Depuis le Junos OS version 14.2R4, la prise en charge de la bande passante automatique est prise en charge pour les LSP contrôlés par PCE. Dans des version antérieures, l’option de bande passante automatique ne s’était pas appliquée aux LSP contrôlés par PCE, même si les LSP contrôlés par le bandwdith automatique et le routage basé sur des contraintes pouvaient coexister avec des LSP contrôlés par PCE. La collecte de statistiques pour la bande passante automatique n’était en vigueur que lorsque le mode de contrôle d’un LSP contrôlé par PCE change de l’extérieur vers le local. Cela s’est produit dans des cas comme l’absence de connectivité à un PCE ou le retour d’une d’une d’entre elles au PCC.

Authentification TCP-MD5 pour les sessions PCEP

Un serveur PCE à états automatise la création de chemins techniques du trafic sur le réseau, ce qui augmente l’utilisation du réseau et offre une expérience réseau programmable personnalisée avec l’utilisation de la communication PCEP avec un PCC. Un PCC envoie des rapports LSP à un serveur PCE et le PCE met à jour ou met à disposition les LSP vers le PCC. Les données envoyées par une session PCEP sont cruciales pour un serveur PCE qui calcule des chemins externes. En conséquence, une attaque sur la communication PCEP peut perturber les services réseau. Si des messages PCEP modifiés sont envoyés à un PCC, des LSP inappropriés peuvent être mis en place. De même, si des messages PCEP modifiés sont envoyés à un PCE, l’ordinateur apprend une vue incorrecte du réseau.

Compte tenu de l’importance de la communication PCEP entre un PCE et le PCC dans l’exécution efficace des fonctionnalités PCE, Junos OS Version 16.1 présente la fonctionnalité de sécurisation d’une session PCEP à l’aide de l’authentification TCP-MD5 en tant que RFC 5440. Cette fonctionnalité protège la communication entre un PCE et le PCC au cours d’une session PCEP, qui peut être la objet d’une attaque et 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 hiérarchie pour une [edit protocols pcep pce pce-id] session PCEP. Vous pouvez toutefois utiliser une clé prédéfinie du niveau hiérarchique pour sécuriser [edit security authentication-key-chains key-chain] une session PCEP. Dans ce cas, vous devez lier la clé prédéfinie à la session PCEP au niveau [edit protocols pcep pce pce-id] de la hiérarchie.

La configuration suivante s’exécute sur le PCC pour établir une session PCEP sécurisée avec un PCE:

  • Utilisation de la clé d’authentification MD5:

  • Utilisation d’une clé d’authentification prédéfinine:

Pour que les sessions PCEP sécurisées soient établies avec succès, l’authentification MD5 doit être configurée avec la clé d’authentification pré-partagée sur le serveur PCE et le PCC. Le PCE et le PCC utilisent la même clé pour vérifier l’authenticité de chaque segment envoyé sur la connexion TCP de la session PCEP.

Remarque :
  • Junos OS version 16.1 prend en charge l’authentification TCP-MD5 uniquement pour les sessions PCEP, sans extension de la prise en charge des protocoles TLS et TCP-AO, comme la protection contre les écoutes, les inviolations et la contrefaçon de messages.

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

  • Si 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 PCC et du PCE correspondent.

  • Cette fonctionnalité ne prend en charge aucun mécanisme d’authentification de session.

  • Pour afficher la clé d’authentification utilisée par la session PCEP, utilisez show path-computation-client status les sorties et show protocols pcep les commandes.

  • Utilisez la commande pour afficher le nombre de paquets qui ont été abandonnés par TCP à cause d’erreurs show system statistics tcp | match auth d’authentification.

  • L’utilisation de la clé de clés peut être vérifiée à l’aide du résultat show security keychain detail de commande.

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

La maintenance d’une base de données à états peut être négligeable. Dans un environnement PCE centralisé unique, un PCE dynamique doit simplement mémoriser tous les LSP TE que l’ordinateur a calculés, les LSP TE qui ont été en place (si cela peut être connu) et lorsque les LSP de l’TE ont été dérouillés. Toutefois, ces exigences entraînent des frais de protocoles 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. D’où les préoccupations de l’implémentation d’un PCE à états:

  • Tout mécanisme de synchronisation fiable entraîne des frais de plan de contrôle importants. Les PCE peuvent synchroniser l’état en communiquant entre eux. Mais lorsque TE les LSP sont créés à l’aide de calculs distribués exécutés entre plusieurs PCE, les problèmes de synchronisation et de prévention des conditions de course deviennent de plus en plus complexes.

  • La synchronisation hors bande de la base de données des ingénieries de trafic peut être complexe avec plusieurs PCE mis en place dans un modèle de calcul PCE distribué, et peut être sujet à des conditions de course, à des problèmes d’évolutivité, etc.

  • Le calcul de chemin intégrant l’état total du réseau est extrêmement complexe, même si le PCE dispose d’informations détaillées sur tous les chemins, priorités et couches.

Malgré les préoccupations ci-dessus, l’implémentation partielle du PCE à états côté client est extrêmement efficace dans les systèmes d’ingénierie de trafic de grande taille. Elle offre une convergence rapide et des avantages significatifs en termes d’utilisation optimale des ressources, en fournissant une visibilité globale d’un état LSP TE et un contrôle commandé des réservations de chemins sur les équipements du système contrôlé.

Exemple: Configuration du protocole de l’élément de calcul de chemin pour MPLS RSVP-TE

Cet exemple montre comment activer le calcul de chemin externe par un élément de calcul de chemin (PCE) pour les chemins de commutation d’étiquettes (TE LSP) sur un client de calcul de chemin (PCC). Il indique également comment configurer le protocole PCEP (Path Computation Element Protocol) sur le PCC afin de permettre la communication ENTRE PCE et PCC.

Conditions préalables

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

  • Trois routeurs qui peuvent être combinés à des routeurs ACX Series, des routeurs de périphérie multiservices M Series MX Series, des Plates-formes de routage universelles Plates-formes de routage universelles 5G, des routeurs T Series ou des routeurs de transport PTX Series, dont l’un est configuré en tant que PCC.

  • Une connexion TCP à un PCE à états externe à partir du PCC.

  • Junos OS version 12.3 ou ultérieure s’exécutant sur le PCC avec le package jSDN.

Remarque :

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

Avant de commencer:

  1. Configurez les interfaces de l’équipement.

  2. Configurez MPLS et RSVP-TE.

  3. Configurez IS-IS protocole d’IGP de sécurité.

Présentation

Depuis la Junos OS version 12.3, la fonctionnalité RSVP-TE de MPLS est étendue pour fournir une mise en œuvre 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 du projet d’Internet draft-ietf-pce-stateful-pce. Depuis la Junos OS version 16.1, cette implémentation est mise à niveau pour prendre en charge la version 7, telle que définie dans le draft draft-ietf-pce-stateful-pce-07 d’Internet. Les versions antérieures à 16.1 traitent de la version antérieure du projet PCE, ce qui entraîne des problèmes d’interopérabilité entre un PCC exécutant une précédente version et un serveur PCE à états qui adhère à Internet draft-ietf-pce-stateful-pce-07.

Pour activer le calcul de chemin externe par un PCE, inclure l’instruction sur le PCC aux niveaux lsp-external-controller[edit mpls][edit mpls lsp lsp-name] hiérarchiques et suivants.

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

Lors de la configuration du PCEP sur un PCC, prendre conscience des considérations suivantes:

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

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

  • Un PCC peut se connecter à un maximum de 10 PCE à états. À tout moment, un seul PCE principal (l’PCE avec la valeur de priorité la plus faible, ou le PCE qui se connecte au PCC en premier en l’absence de priorité PCE) peut être auquel le PCC délégue les LSP pour le calcul de chemin.

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

  • Les fonctionnalités LSP existantes, telles que la protection LSP et la fonctionnalité 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, même si les LSP contrôlés par le bandwdith automatique et le routage basé sur des contraintes peuvent coexister avec les LSP contrôlés par PCE.

  • Les LSP contrôlés par PCE peuvent être appelés par d’autres configurations CLI, telles que lsp-nexthop to routes, forwarding adjacencies, connexions CCC et tunnels logiques.

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

  • Les LSP contrôlés par PCE ne sont pas pris en charge dans les systèmes logiques.

  • Les LSP contrôlés par PCE ne peuvent pas être des LSP point à multipoint.

  • Les LSP bidirectionnels ne sont pas pris en charge.

  • Les LSP contrôlés par PCE ne peuvent pas avoir de chemins secondaires sans chemin principal.

  • Les LSP contrôlés par PCE dépendent du calcul de chemin externe, ce qui a un impact sur le temps de configuration global, le rerourage et les fonctionnalités de mise en route.

  • Le temps de configuration et le temps de convergence (reroute, MBB) pour l’exisiting LSP sont identiques à ceux des versions précédentes, en l’absence de LSP contrôlés par PCE. Toutefois, la présence de LSP contrôlés par PCE a un faible impact.

  • Les temps de calcul ERO devraient être nettement plus élevés que ceux du CSPF local-CSPF.

Topologie

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

Dans cet exemple, le PCC est le routeur d’entrée qui se connecte au PCE dynamique actif externe.

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

  1. Le PCC du routeur reçoit la configuration de tunnel LSP qui a été mise en place à l’aide du CLI. En supposant que la configuration reçue est activée avec le calcul de chemin externe, 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éguent le LSP au PCE.

    Dans cet exemple, le LSP externe est appelé et il est mis en place depuis le routeur PCC vers le PCC-to-R2 routeur R2 . L CLI ERO configuré pour PCC-to-R2 PCC-R0-R1-R2. La bande passante est de 10 m, et les valeurs de priorité de configuration et PCC-to-R2 de priorité de maintenez sont de 4.

  2. Le PCC du routeur tente de récupérer les attributs LSP contrôlés par PCE. Pour ce faire, le PCC du routeur envoie un message PCRpt au PCE à états indiquant que le LSP a été configuré. Le message PCRpt communique l’état du LSP et contient les paramètres de configuration locale du LSP.

  3. L’pcE à états modifie un ou plusieurs des attributs LSP déléguer et envoie les nouveaux paramètres LSP au PCC du routeur par le biais du message PCUpd.

  4. Une fois les nouveaux paramètres LSP pris en compte, le routeur PCC définit un nouveau LSP et le signale de 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 8 m, et les valeurs de priorité de configuration et PCC-to-R2 de maintenez 3.

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

Configuration

CLI configuration rapide

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

Pcc

R0

R1

R2

R3

Procédure

Procédure étape par étape

L’exemple suivant vous oblige à naviguer dans différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation du CLI, consultez l’utilisationdu CLI en mode de configuration .

Pour configurer le PCC du routeur:

Remarque :

Répétez cette procédure pour chaque routeur d’entrée Juniper Networks dans le domaine MPLS, après avoir modifié les noms, adresses et autres paramètres d’interface appropriés pour chaque routeur.

  1. Configurez les interfaces.

    Pour activer MPLS, inclure la famille de protocoles sur l’interface afin que l’interface n’écarte pas MPLS trafic.

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

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

  4. Configurez le LSP depuis le routeur PCC vers le routeur R2, qui dispose d’un contrôle local et qui est adroute 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 l’adresse PCE à qui le PCC du routeur se connecte et configurez l’adresse IP de ce dernier.

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

  9. Configurez le type de PCE.

Résultats

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

Si vous avez terminé la configuration de l’équipement, commit saisissez-le en mode de configuration.

Vérification

Vérifier que la configuration fonctionne correctement.

Vérification du statut de session PCEP

But

Vérifier l’état de la session PCEP entre le PCE et le PCC du routeur lorsque l’état PCE est en place.

Action

À partir du mode opérationnel, exécutez show path-computation-client active-pce la commande.

Sens

La sortie affiche des informations sur le PCE actif à états à qui le PCC du routeur est connecté. Le champ de sortie indique l’état actuel de la session PCEP entre le PCE et le PCE status PCC routeur.

Par exemple, l’état de la session PCEP est, ce qui indique que la session PCEP a été établie entre les pce1PCE_STATE_UP pairs PCEP.

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

Vérifier l’état du LSP contrôlé par PCE lorsque le contrôle LSP est externe

But

Vérifier l’état du LSP contrôlé par PCE du routeur PCC au routeur R2 lorsque ce dernier est sous contrôle externe.

Action

À partir du mode opérationnel, exécutez show mpls lsp name PCC-to-R2 extensive la commande.

Sens

Les champs de sortie et de sortie indiquent que le LSP est contrôlé LSPtypeLSP Control Status de l’extérieur. La sortie affiche également un journal des messages PCEP envoyés entre le PCC du routeur et l’ordinateur.

La session PCEP entre le PCE et le PCC routeur est en cours de préparation, 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 conserver)

Vérifier l’état du LSP contrôlé par PCE lorsque le contrôle LSP est local

But

Vérifiez l’état du LSP contrôlé par PCE du routeur PCC au routeur R2 lorsque le contrôle LSP devient local.

Action

À partir du mode opérationnel, exécutez show mpls lsp name PCC-to-R2 extensive la commande.

Sens

En 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 PCC du routeur continue d’utiliser les paramètres fournis par le PCE, jusqu’à la prochaine occasion de signaler de nouveau le LSP.

Le résultat affiche maintenant les paramètres LSP configurés à l’aide de la CLI ainsi que les paramètres fournis par PCE utilisés pour définir le LSP comme valeur réelle utilisée.

  • Bande passante— 10 Mhz (width actualband: 8 M$/s)

  • Priorités: 4 4 (Actualités 3 3 3)

Sur le déclencheur pour signaler de nouveau le LSP, le routeur PCC 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 d’élément de calcul de chemin pour MPLS RSVP-TE avec la prise en charge de LSP point à point pcE

Cet exemple montre comment configurer le client de calcul de chemin (PCC) avec la capacité de prendre en charge les chemins de commutation d’étiquettes (LSP) initiés par PCE (Path Computation Element).

Conditions préalables

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

  • Trois routeurs qui peuvent être combinés à des routeurs ACX Series, M Series, MX Series ou T Series routeurs.

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

  • Junos OS version 16.1 ou ultérieure du PCC.

Avant de commencer:

  • Configurez les interfaces de l’équipement.

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

  • Configurer OSPF protocole de sécurité ou IGP protocole de sécurité.

Présentation

Depuis Junos OS version 16.1, la fonctionnalité PCEP est étendue afin de permettre à un PCE à états d’initier et de provisioner des LSP d’ingénierie de trafic via un PCC. Plus tôt, les LSP ont été configurés sur le PCC et le PCC a déléguer le contrôle des LSP externes à un PCE. Le PCC maintenait la propriété de l’état LSP. Avec l’introduction des LSP à l’initiative de PCE, un PCE peut lancer et provisioner un LSP point-à-point d’ingénierie du trafic de manière dynamique, sans avoir à mettre en place un LSP configuré localement sur le PCC. Une fois qu’un PCE reçoit un message PCCreate, le PCC crée le LSP lancé par PCE et délégue automatiquement le LSP au PCE.

Lors de la configuration de la prise en charge de LSP point-to-point pcE pour un PCC, être conscient des considérations suivantes:

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

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

  • Les fonctionnalités LSP existantes, telles que la protection LSP et make-before-break, fonctionnent pour les LSP à l’initiative de PCE.

  • Les LSP à l’initiative de PCE ne sont pas en charge moteur de routage basculement greS.

  • Les LSP à l’initiative de PCE ne sont pas pris en charge dans les systèmes logiques.

  • Les LSP à l’initiative de PCE ne peuvent pas être des LSP point-à-multipoint.

  • Les LSP bidirectionnels ne sont pas pris en charge.

  • RSVP-TE pour les liaisons non numéroées n’est pas prise en charge. Seules les liaisons sont numérotées pour les LSP à l’initiative de PCE.

  • Le PCE à l’initiative d’un LSP de routage de segments peut utiliser les étiquettes SID (Segment ID) contraignantes associées aux LSP de routage de segments non-segments différentes afin de provisioniser les chemins LSP de routage de segments initiés par PCE.

    À partir de Junos OS version 18.2R1, les LSP de routage de segments configurés de façon statique sur l’équipement d’entrée sont signalés à un PCE par le biais d’une session PCEP. Ces LSP de routage de segments non différentes sont peut-être associés à des labels SID qui les lient. Grâce à cette fonctionnalité, le PCE peut utiliser ce label SID obligatoire dans la pile d’étiquettes pour provisioner des chemins LSP de routage de segments pcE.

Topologie

Figure 6 : Exemple LSP point à point pcE pour RSVP-MPLS RSVP-TEExemple LSP point à point pcE pour RSVP-MPLS RSVP-TE

Dans cet exemple, le PCC est le routeur d’entrée qui se connecte à deux PCE à états externes: PCE1 et PCE2.

En cas de nouvelle demande, le PCE actif dynamique lance un LSP afin de répondre à cette exigence. Puisque le PCC est configuré avec la capacité de soutenir le LSP lancé par PCE, le calcul de chemin sur le PCC est effectué comme suit:

  1. Un PCE envoie un message PCCreate au PCC pour lancer et provisionner un LSP. Le PCC définit le LSP à l’initiative de PCE en utilisant les paramètres reçus du PCE, puis délégue automatiquement le LSP pcE au PCE à l’initiative de son initiative.

    Dans cet exemple, PCE1 est l’ordinateur PCE dynamique actif qui lance et provisions le LSP pcE sur PCC. Une fois les paramètres LSP lancés par PCE, le PCC définit le LSP et délègue automatiquement le LSP pcE à PCE1.

  2. Lorsque la session PCEP entre le PCC et PCE1 est interrompue, le PCC lance deux timeurs pour le LSP lancé par PCE1: d’algation cleanup timeout et le timer de nettoyage LSP. Pendant cette période, PCE1 ou PCE2 peut acquérir le contrôle du LSP à l’initiative de PCE.

  3. Si PCE2 prend le contrôle du LSP à initiative PCE avant l’expiration du minuteur de nettoyage LSP, le PCC délégue le LSP à PCE au PCE2, le minuteur de nettoyage LSP et le délai d’expiration de la délégue, sont arrêtés.

  4. En cas d’expiration du délai d’expiration du programme de nettoyage pour les délégues, et que ni PCE1 ni PCE2 n’ont pris le contrôle du LSP pcE, le PCC prend le contrôle local des LSP non délégues, jusqu’à l’expiration du minuteur de nettoyage LSP.

  5. Après l’expiration du minuteur de nettoyage LSP, le PCC supprime le LSP à initiative PCE provisionnable par PCE1.

Configuration

CLI configuration rapide

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

Pcc

R1

R2

Procédure

Procédure étape par étape

L’exemple suivant vous oblige à naviguer dans différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation du CLI, consultez l’utilisationdu CLI en mode de configuration .

Pour configurer le routeur PCC:

Remarque :

Répétez cette procédure pour chaque routeur d’entrée Juniper Networks dans le domaine MPLS, après avoir modifié les noms, adresses et autres paramètres d’interface appropriés pour chaque routeur.

  1. Configurez les interfaces.

    Pour activer MPLS, inclure la famille de protocoles sur l’interface afin que l’interface n’écarte pas MPLS trafic.

  2. Activer 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. Activer 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éfinir le groupe PCE et activer la prise en charge de LSP activés par PCE pour le groupe PCE.

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

Résultats

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

Si vous avez terminé la configuration de l’équipement, commit saisissez-le en mode de configuration.

Vérification

Vérifier que la configuration fonctionne correctement.

Vérification du statut du PCC

But

Vérifier l’état de la session PCEP et le résumé LSP entre le PCC et les PCE connectés.

Action

À partir du mode opérationnel, exécutez show path-computation-client status la commande.

Sens

La sortie affiche l’état de la session PCEP entre les PCE actifs dynamiques et le PCC. Il affiche également des informations sur les différents types de LSP du PCC, ainsi que sur le nombre de LSP provisionés par les PCE connectés et délégués.

PCE1 est le principal PCE actif et possède un LSP à l’initiative de PCE qui a été automatiquement délègue au PCC.

Vérification du statut du PCE1

But

Vérifier le statut du PCE dynamique principal actif.

Action

À partir du mode opérationnel, exécutez show path-computation-client active-pce detail la commande.

Sens

La sortie affiche des informations sur le PCE dynamique actif auquel est connecté le PCC. Le PCE status champ de sortie indique l’état actuel de la session PCEP entre un PCE et le PCC.

Pour le PCE1, l’état de la session PCEP est, ce qui indique que la session PCEP a PCE_STATE_UP été établie avec le PCC.

Vérifier le statut LSP à l’initiative de PCE lorsque le LSP est provisionné de l’extérieur

But

Vérifier l’état du LSP lancé par PCE.

Action

À partir du mode opérationnel, exécutez show mpls lsp externally-provisioned detail la commande.

Sens

Dans la sortie, le champ de sortie indique que LSPtype le LSP est provisionné de l’extérieur.

La session PCEP entre le PCC et PCE1 est ouverte et le PCC reçoit les paramètres LSP pcE suivants:

  • ERO (chemin): 10.0.102.10 et 10.0.101.9

  • Bande passante: 8 Mb/s

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

Configuration du protocole d’élément de calcul de chemin pour MPLS RSVP-TE avec la prise en charge de LSP point à point pcE

Vous pouvez configurer un client de calcul de chemin (PCC) avec la capacité de prendre en charge des chemins de commutation d’étiquettes (LSP) créés de manière dynamique à partir d’une entité de calcul de chemin externe centralisée. Un élément PCE (Stateful Path Computaiton Element) peut être utilisé pour effectuer le calcul de chemin externe et générer des LSP dynamiques en cas de demande croissante.

Un PCC crée le LSP point à point pcE en utilisant les paramètres ou paramètres LSP fournis par PCE à partir d’un modèle LSP pré-configuré lorsque l’ordinateur ne provisionne pas le LSP, et délégue automatiquement le LSP point à point PCE dans le PCE respectif. Ainsi, pour les LSP lancés par PCE, il n’est pas nécessaire d’avoir un LSP configuré localement sur le PCC.

Un LSP contrôlé CLI PCE, un LSP contrôlé par PCE et un LSP à l’initiative de PCE peuvent coexister entre eux sur un PCC.

Avant de commencer:

  • Configurez les interfaces de l’équipement.

  • Configurez MPLS et RSVP-TE.

  • Configurer OSPF protocole de sécurité ou IGP protocole de sécurité.

Pour configurer le PCC afin de prendre en charge les LSP point à point pcE, complétez les tâches suivantes:

  1. En mode configuration, allez au niveau hiérarchique suivant:
  2. Indiquez le nombre de messages par minute que le PCC peut recevoir au maximum.
  3. Indiquez le nombre de chemins commutés d’étiquettes (LSP) provisionés de l’extérieur sur tous les PCE connectés que le PCC peut accepter au maximum.
  4. Indiquez l’ID défini par l’utilisateur unique pour l’ordinateur connecté pour configurer les paramètres PCE.
  5. Indiquez le temps (en secondes) que le PCC 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. Indiquez l’adresse IPv4 de l’ordinateur avec qui vous connecter.
  7. Indiquez le numéro de port TCP utilisé par l’ordinateur

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

  8. Indiquez le temps (en secondes) que le PCC doit attendre avant de supprimer tout LSP non déléguer des LSP non déléguer PCE au PCE défacclé après la fin d’une session PCEP.
  9. Configurez le PCC pour qu’il accepte les fournisseurs de services provisionnables de l’extérieur par des PCE connectés. Par défaut, le PCC rejette les LSP initiés par PCE.
  10. Indiquez le nombre de messages inconnus par minute que le PCC peut recevoir au maximum après la fermeture de la session PCEP.

    La valeur peut varier de 1 à 16384 et la valeur par défaut 0 (désactivée ou non).

  11. Indiquez le nombre de requêtes inconnues par minute que le PCC peut recevoir au maximum, après quoi la session PCEP est interrompue.

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

  12. Configurez le type de PCE.
  13. Indiquez le temps (en secondes) pour que le PCC attende la réponse avant de renvoyer une demande.

    La valeur peut varier de 0 à 6 5535 secondes.

  14. Vérifier et valider la configuration.

Exemple de sortie

Exemple: Configuration du protocole d’élément de calcul de chemin pour MPLS RSVP-TE avec prise en charge de LSP point à multipoint contrôlé par PCE

Cet exemple montre comment configurer le client de calcul de chemin (PCC) avec la capacité de signaler les chemins de commutation d’étiquettes (TE LSP) du 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 qui peuvent être combinés à des routeurs ACX Series, M Series, MX Series ou T Series routeurs.

  • Une machine virtuelle configurée avec une fonctionnalité de réflecteur de route virtuelle (VRR).

  • Une connexion TCP à un PCE à états externe à partir du VRR.

  • Junos OS version 16.1 ou ultérieure du PCC.

Avant de commencer:

  • Configurez les interfaces de l’équipement.

  • Configurez MPLS et RSVP-TE.

  • Configurer OSPF protocole de sécurité ou IGP protocole de sécurité.

Présentation

Une fois qu’une session PCEP est établie entre un PCE et un PCC, le PCC signale tous les LSP du système au PCE pour une synchronisation de l’état LSP. Il s’agit notamment de LSP point à point pcE, contrôlés par le PCC, délédés par PCE et pcE. Depuis la Junos OS version 15.1F6 et 16.1R1, cette fonctionnalité est également é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 PCC. Pour ajouter cette fonctionnalité, inclure p2mp-lsp-report-capability l’instruction au niveau supérieur ou [edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id] hiérarchique.

Topologie

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

Dans cet exemple, le PCC est le routeur d’entrée, le routeur R1 le routeur de transit et le routeur R2 le routeur de sortie. Le PCC est connecté à un réflecteur de route virtuel (VRR) connecté à un PCE. Il existe de nombreuses interfaces point à multipoint entre le PCC, le routeur R1 et le routeur R2.

Le reporting des LSP point à multipoint s’exécute comme suit:

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

  2. Lorsque le PCC du routeur est configuré avec une fonctionnalité de reporting LSP point-multipoint, le PCC fait d’abord la publicité de cette fonctionnalité sur PCE par le biais d’un message de rapport.

  3. Par défaut, un PCE assure la prise en charge de la fonctionnalité LSP point à multipoint. Une fois qu’il a reçu la publicité du PCC pour la fonctionnalité LSP point-à-multipoint, le PCE en échange fait la publicité de sa capacité au PCC.

  4. À la réception de la publicité de la fonctionnalité point-multipoint (point-to-multipoint) du PCE, le PCC signale toutes les filiales de LSP point à multipoint à l’ordinateur à l’aide du message de mise à jour.

  5. Une fois tous les LSP signalés sur le PCE, l’état LSP est synchronisé entre le PCE et le PCC.

Configuration

CLI configuration rapide

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

Pcc

R1

R2

R3

Procédure

Procédure étape par étape

L’exemple suivant vous oblige à naviguer dans différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation du CLI, consultez l’utilisationdu CLI en mode de configuration .

Pour configurer le routeur PCC:

  1. Configurez les interfaces du routeur PCC. Pour activer MPLS, inclure la famille de protocoles sur l’interface afin que l’interface n’écarte pas MPLS trafic.

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

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

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

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

  6. Configurez des LSP point à multipoint et définissez une entité de calcul de chemin externe pour le LSP.

  7. Activez le calcul de chemin externe pour MPLS LSP et attribuez un modèle aux LSP provisionés de l’extérieur.

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

  9. Configurez MPLS des stratégies de groupe administratif pour le calcul LSP à chemin restreint.

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

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

  12. Configurez un BGP interne.

  13. Configurez les ingénieries de trafic pour BGP et attribuez la stratégie d’exportation.

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

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

  16. Activez les ingénieries de trafic pour les OSPF.

  17. Définissez le PCE à qui le PCC du routeur se connecte et configurez les paramètres PCE.

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

  19. Configurez la stratégie des ingénieries de trafic.

Résultats

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

Vérification

Vérifier que la configuration fonctionne correctement.

Vérification de la configuration LSP sur le PCC

But

Vérifier le type LSP et l’état d’exécution du LSP point-à-multipoint.

Action

À partir du mode opérationnel, exécutez show mpls lsp extensive la commande.

Sens

La sortie affiche le LSP lsp2-pcc comme LSP contrôlé par PCE.

Vérification de la configuration PCE sur le PCC

But

Vérifier la configuration et l’état des paramètres PCE.

Action

À partir du mode opérationnel, exécutez show path-computation-client active-pce la commande.

Sens

La sortie affiche l’ordinateur actif à qui le routeur PCC est connecté, ainsi que les paramètres et l’état pce1 PCE.

Understanding Path Computation Element Protocol for MPLS RSVP-TE with Support for PCE-Initiated Point-to-Multipoint LSP (Understanding Path Computation Element Protocol for MPLS RSVP-TE with Support for PCE-Initiated Point-to-Multipoint LSP)

Avec l’introduction de LSP point-à-multipoint, un PCE peut lancer et provisioner un LSP point à multipoint de manière dynamique, sans qu’une configuration LSP locale ne soit nécessaire sur le PCC. Cela permet au PCE de contrôler l’heure et la séquence des calculs de chemin point-multipoint dans 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 pcE

Répond aux exigences des ingénieries de trafic point à multipoint Le positionnement LSP en réponse aux demandes des applications par le biais de la création et de la baisse dynamiques 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 à multipoint pcE

La signalisation des LSP point-multipoint lancés par PCE est la suivante:

  • When a new branch is added (Grafting)—Seule la nouvelle branche sous-LSP est signalée et n’entraîne pas de nouvelle signalisation pour l’ensemble de l’arborescence point à multipoint.

    En cas de changement de topologie avant la mise à disposition du nouveau sous-LSP, le serveur de calcul de chemin (PCS) calcule alors l’ensemble de l’arborescence point à multipoint et met à jour le LSP point-à-multipoint à l’aide d’un message de mise à jour PC.

  • When a branch is deleted (Pruning)—Le sous-LSP supprimé de la filiale est supprimé et n’entraîne pas de signalisation de la totalité de l’arborescence point à multipoint.

  • When a branch sub-LSP parameter is changed—La modification des paramètres sous-LSP, tels que l’objet de route explicite (ERO), la bande passante ou la priorité, peut se produire soit à cause de l’optimisation, soit à la demande de l’utilisateur. En cas de demande de signalisation de nouveau pour un sous-LSP, la signalisation est fait sur l’ensemble de l’arborescence point-multipoint. Le basculement vers la nouvelle instance se produit alors une fois les nouvelles instances toutes les filiales en place.

  • When a branch sub-LSP path fails—Une erreur est signalée dans l’ordinateur pour le sous-LSP de filiale défagée. Lorsque l’ordinateur reçoit le nouvel ERO, l’ensemble de l’arborescence point-multipoint est signalé de nouveau, de même que le sous-LSP (branch sub-LSP) défavert, et le basculement vers la nouvelle instance s’effectuera de façon make-before-break (MBB).

Comportement des LSP point-multipoints lancés par PCE après une défaillance de la session PCEP

En cas d’échec d’une session PCEP, les LSP point-à-multipoint lancés par PCE sont déçus jusqu’à l’expiration state timeout du minuteur. Une fois state timeout le timer expire, les LSP initiés par PCE sont nettoyer.

Pour obtenir le contrôle d’un LSP point-multipoint lancé par PCE en cas de défaillance d’une session PCEP, l’ordinateur PCE principal ou secondaire envoie un message avant l’expiration du PCInitiatestate timeout délai.

Configuration de la fonctionnalité LSP point-multipoint lancée par PCE

Par défaut, la création et la mise à disposition de LSP point à multipoint par un PCE ne sont pas pris en charge sur un PCC. Pour activer cette fonctionnalité, inclure les instructions aux niveaux hiérarchiques ou p2mp-lsp-init-capabilityp2mp-lsp-update-capability[edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id] suivants.

Cet p2mp-lsp-init-capability énoncé permet de provisioner des LSP RSVP-TE point à multipoint par un PCE. Cet énoncé permet de mettre à jour les p2mp-lsp-update-capability paramètres LSP RSVP-TE point à multipoint par un PCE.

Fonctionnalités prise en charge et non prise en charge pour les LSP point à multipoint pcE

Les fonctionnalités suivantes sont prise en charge par les LSP point-à-multipoint pcE:

  • Conformité partielle avec le projet Internet draft-ietf-pce-stateful-pce-p2mp (expire en octobre 2018), les extensions de protocole PCE (Path Computation Element)pour l’utilisation à états de PCE pour les chemins de commutation d’étiquettes de trafic point à multipoint .

  • À partir de Junos OS version 21.1R1, nous pris en charge le routage actif sans arrêt (NSR) pour les LSP point-multipoint basés sur RSVP et PCE. Seule la carte principale moteur de routage conserve la session PCEP avec le contrôleur. Il synchronise tous les LSP RSVP lancés par les PCE, y compris les spécifications de flux multicast pour tous les LSP P2MP à l’initiative de PCE, avec la moteur de routage. Lors d’un basculement, la session PCEP tombe en panne et établit de nouveau lorsque la moteur de routage devient le principal moteur de routage. Cela réduit les pertes de trafic pour le trafic transporté par les LSP RSVP lancés par PCE pendant moteur de routage commutation. Cette fonctionnalité est activée lorsque le NSR est configuré.

Les fonctionnalités suivantes ne sont pas prise en charge par les LSP point-à-multipoint pcE:

  • D’une DSP contrôlée localement par point vers multipoint.

  • DDSP.

  • Extension de protocole de passerelle intérieure (IGP) pour la détection PCE dans IGP domaine de routage.

  • Message de demande/réponse.

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

    Il est possible d’obtenir la même chose en supprimant un sous-LSP de filiale du premier arborescence point-multipoint et en l’ajoutant à un autre après que le message indique que LSP est supprimé de PCReport l’équipement.

  • IPv6 n’est pas pris en charge.

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

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

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

Mappage des LSP point à multipoint (Point-to-Multipoint) et MVPN (Point-to-Multipoint LSP) lancées par PCE

Vous pouvez associer un ou plusieurs flux multicast MVPN (S,G) à un chemin de commuté d’étiquettes (LSP) PCE lancé de manière dynamique. Vous pouvez spécifier les types de flux sélectifs pour que cette fonctionnalité fonctionne. Les thèmes abordés sont les suivants :

  • L’distinguisher de routage (RD), qui est attaché à l’instance de routage MVPN.

  • (S,G), qui est la source d’une adresse de groupe de paquets multicast et de destination. Cette fonction permet de filtrer le trafic entrant pour le matrayer dans le tunnel.

  • LSP point à multipoint utilisé pour envoyer du trafic qui correspond à la spécification de flux ci-dessus.

Pour plus d’informations, consultez le document Internet draft-ietf-pce-pcep-flowspec-05 (qui expire le 16 février 2020) Extension PCEPpour la spécification des 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 dans IGP

  • Section 3.2: message PCReq et PCRep

  • Section 7: la plupart des spécifications de flux, à l’exception de la fonction de route distinguLa mise en œuvre actuelle de cette fonctionnalité ne permet pas de s’appuyer sur des spécifications de flux multicast IPv4 et de suraporer.

Pour permettre la mise en correspondance de LSP point-multipoint lancés par PCE vers le MVPN:

  • Inclure l’instruction au niveau de la hiérarchie pour indiquer la prise en charge de la fonctionnalité de spécification de flux (également appelée orientation du pce_traffic_steering[edit protocols pcep pce pce-id] trafic) par le PCC.

  • Inclure external-controller l’instruction au niveau [edit routing-instances routing-instance-name provider-tunnel] de la hiérarchie.

    La présence de external-controller LSP et (S,G) point-à-multipoint dans la configuration du tunnel fournisseur pour MVPN indique que cette instance MVPN peut être fournie par le contrôleur externe. Le contrôleur externe peut ainsi configurer de manière dynamique (S,G) et LSP point à multipoint pour MVPN.

Prenons les éléments suivants à prendre en compte pour la mise en correspondance des LSP point-multipoint lancés par PCE vers le MVPN:

  • Si l’instruction d’une instance MVPN particulière n’est pas activée, le processus PCCD ne se configure external-controller pccd pas (S,G) de manière dynamique.

  • Si vous désactivez la configuration de la CLI, les flux multicast (S,G) découverts dynamiquement pour cette instance MVPN particulière sont supprimés et signalés au contrôleur external-controller pccd externe.

  • Lorsque (S,G) est déjà configuré à partir du CLI, le PCC ne peut pas configurer (S,G) de manière dynamique car la configuration locale a une priorité supérieure.

  • Si l’on apprend une chose particulière (S,G) du contrôleur externe de façon dynamique et que vous configurez la même instance MVPN (S,G), alors le fichier S,G (Dynamically Learned) est supprimé et signalé au contrôleur externe via le PCC.

  • Si le processus de protocole de routage redémarre, le processus PCCD reconfigure à nouveau tous les S,G.

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

  • Si l’utilisateur active une instance MVPN particulière, alors le MVPN demande au processus PCCD de configurer external-controller pccd (S,G), le cas où il y en a.

  • S’il existe des modifications de configuration majeures sur une instance MPVN spécifique, le MVPN demande au processus PCCD de reconfigurer tous les (S,G) pour cette instance MVPN particulière.

  • Toutes les spécifications de flux associées à tout LSP point-multipoint pcE doivent être identiques. Lors du lancement de l’ordinateur si toutes les spécifications de flux ne sont pas identiques, le message d’introduction de l’ordinateur est abandonné avec une erreur.

  • Vous pouvez associer un LSP point à multipoint uniquement avec un type sélectif de spécifications de flux, faute de quoi l’ordinateur a envoyé un message et a été abandonné à l’occasion d’une erreur.

  • Lors de la mise à jour de l’ordinateur si toutes les spécifications de flux ne sont pas identiques, soit en raison d’un nouvel ajout de spécification de flux, soit en raison de la mise à jour de la spécification de flux existante, le PCC abandonne le message de mise à jour.

  • Lors de la mise à jour de l’ordinateur si toutes les spécifications de flux ne répondent pas à cette condition sélective en raison de l’ajout d’une nouvelle spécification de flux ou en raison de la mise à jour des spécifications de flux existantes, le PCC abandonne le message de mise à jour.

  • Le comportement de mappage de LSP point-à-multipoint lancé par PCE avec l’instance de routage MVPN et la mise en correspondance de LSP statiques (configurés localement) point-à-multipoint avec instance MVPN est le même au niveau de l’utilisateur.

  • Un ID de spécification de flux peut être associé à un seul LSP point-multipoint. Pour associer les mêmes rd et (S,G) à plusieurs LSP point à multipoint, vous pouvez ajouter plusieurs spécifications de flux avec différents ID et même RD et (S,G).

  • Pour les dynamiques pcEP (S,G), la valeur de seuil est toujours la valeur par défaut de 0.

  • Il n’y a pas de limite au nombre de spécifications de flux qu’il faut mettre en place sur un LSP point-multipoint pcE unique.

  • L’implémentation actuelle de cette fonctionnalité ne prend pas en charge:

    • Rapports sur les états de forwarding associés au LSP point-multipoint.

    • Configuration dynamique du tunnel fournisseur inclusive

    • Mappage du tunnel de réplication d’entrée MVPN

    • Processus de protocole de routage programmable (prpd)

    • Rapports sur CLI LSP point-multipoint configuré, qui est mapé dans les flux multicast MVPN (S,G).

Activer le routage de segments pour le protocole de l’élément de calcul de chemin

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

Présentation du routage de segments pour l’élément de calcul de chemin

Avantages du routage de segments pour PCEP

  • La configuration de 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 du chemin en ligne et en temps réel basé sur les contraintes.

    Les avantages du routage de segments sont étendus aux LSP lancés par un contrôleur externe, également connu sous le nom d’élément de calcul de chemin (PCE), ce qui augmente les avantages du calcul de chemin externe dans un MPLS réseau.

  • Un client de calcul de chemin (PCC, routeur MX Series d’entrée) avec capacité de délégation peut reprendre le contrôle des LSP de routage de segments déléguer du PCE lors de la désinsion de la session PCEP ; les LSP seraient autrement supprimés du PCC. Vous pouvez ainsi garantir la protection des données LSP en écartant ou en abandonant silencieusement les paquets (également appelé null route condition).

Routage de segments pour les ingénieries de trafic

Le routage de segments peut fonctionner sur un plan de données IPv4 ou IPv6 et prend en charge le multipath à coût égal (ECMP). Grâce aux extensions IGP intégrées, le routage de segments s’intègre aux fonctionnalités multiservices enrichies de MPLS, y compris les VPN de couche 3, virtual private wire service (VPWS), VPLS (Virtual Private LAN Service) et Ethernet VPN (EVPN).

Les composants de haut niveau de la solution SR–TE de routage de segments comprennent:

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

  • Utilisation de CSPF (Constrained Shortest Path First) sur l’équipement d’entrée ou l’ordinateur.

  • Utilisation d’une IGP pour les étiquettes publicitaires pour les liens.

    Dans la fonctionnalité SR-TE:

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

    2. La publicité de IGP par liaison est combinée à l’empilage d’étiquettes pour créer des LSP à itinéraire source sur le dispositif d’entrée, de sorte que les équipements de transit n’ont pas connaissance des LSP de bout en bout.

    3. Des LSP sont créés entre les nodes de périphérie sans imposer de besoin de mémoire par LSP aux équipements de transit. (La création de tels LSP est activée car il n’y a aucune signalisation par LSP dans SR-TE.)

    4. Les étiquettes par voisin sont empilées, ce qui permet de gérer un grand nombre d’étiquettes, ce qui conduit à l’évolution du plan de contrôle.

Junos OS du routage de segments pour PCEP

Junos OS le routage de segments pour PCEP pour deux types de LSP: les LSP à l’initiative de PCE et les LSP délégues par PCE.

LSP de routage de segments à l’initiative de PCE

Les LSP de routage de segments pcE sont les LSP créés par le PCE pour les segments d’adjacence et de nœuds

L’ordinateur exécute les fonctions suivantes:

  1. Calcul du chemin du LSP de routage de segments.

  2. Dispositions du LSP sur le client de calcul de chemin (PCC) à l’aide d’extensions de routage de segment PCEP.

  3. Détails des extensions de routage de segments PCEP.

  4. Crée un routeur de tunnel sur le PCC qui présente sa propre valeur de préférence et est mis à disposition dans la table de routage inet.3 pour résoudre le trafic IP et les services comme toute autre route de tunnel.

Le PCC exécute les fonctions suivantes:

  1. Sélectionne l’interface sortante en fonction du premier identifiant d’accès réseau (AUDS) dans l’objet de route explicite source (S-ERO).

    Junos OS prend en charge les S-ERO qui contiennent le premier saut en tant que saut strict ; Junos OS ne prend pas en charge la sélection de l’interface sortante sur le PCC en raison d’un ID de segment de nœud lâche (SID). Cependant, les sauts restants peuvent être lâches. Aucun traitement spécifique n’est effectué pour les S-ERO qui se trouve au-delà du premier saut, si ce n’est pour utiliser le label pour créer le saut suivant.

  2. Rejette le S-ERO si:

    • Le S-ERO ne comprend pas de labels.

    • L’ERO S-ERO transporte plus de six sauts.

    Le PCC crée un route multi-chemin à coût égal (ECMP) lorsqu’il y a plusieurs LSP à la même destination avec la même mesure.

  3. Attend que le PCE traitera tout événement qui entraîne une modification du LSP de routage de segments après son provisionisation, par exemple en cas de modification ou d’inapprovisionnement du label, ou d’une panne de l’une des interfaces traversant le LSP.

Lorsque la session PCEP s’en panne, le LSP de routage de segments lancé par PCE:

  1. Reste en place pendant 300 secondes.

  2. Supprimé du PCC au bout de 300 secondes.

Pour plus d’informations, consultez les projets Internet draft-ietf-pce-lsp-setup-type-03.txt (qui expire le 25 décembre 2015), Transmettre le type de configuration de chemin dans les messages PCEP; et draft-ietf-pce-segment-routing-06.txt (expire le 10 février 2016), extensions PCEPpour le routage de segments .

LSP de routage de segments déléguer PCE

Les LSP de routage de segments déléguer par PCE sont les LSP que le PCC configure localement, puis déléguent à un contrôleur PCE.

Remarque :

Junos OS version 20.1R1 prend en charge:

  • Capacité de douation PCE uniquement pour les LSP noncolores de routage de segments avec les destinations IPv4.

  • D’où l’idée de d’être d’abord d’une liste de segments avec un contrôleur externe. Plusieurs segments ne sont pas pris en charge par la DDSP.

Le PCC peut déléguer un LSP de routage de segments à un contrôleur externe (PCE) des manières suivantes:

  • Initial delegation—Les LSP locaux doivent encore être configurés sur le PCC, et la d première partie du LSP se produit au moment de la configuration du LSP.

  • Delegation of existing LSP—Les LSP locaux sont configurés sur le PCC, et la d première partie du LSP se produit une fois le chemin de routage source configuré. Autrement dit, la fonction de dégation est activée sur les LSP existants de routage de segments.

Après avoir déléguer 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 de chemin. Le contrôle LSP revient au PCC lorsque la session PCEP entre le PCC et le PCE est en panne. Les LSP déléguer par PCE ont un avantage sur les LSP initiés par PCE en cas de panne de la session PCEP. Dans le cas des LSP lancés par PCE, lorsque la session PCEP est coupée, les LSP sont supprimés du PCC. Toutefois, dans le cas des LSP délégues par PCE, lorsque la session du PCEP est en panne, le PCC reprend le contrôle des LSP déléguer au PCE. Ainsi, grâce aux LSP délégues par PCE, nous vertons à une situation où les paquets sont silencieusement écartés (également appelés condition de route nulle) lors de la panne de la session.

Les types de LSP de routage de segments suivants soutiennent la capacité de dégéggée par le PCE:

  • Static LSPs—Chemins de routage source configurés de manière statique qui ont l’ensemble de la pile d’étiquettes configurée de façon statique.

  • Auto-translated LSPs—Chemins de routage source configurés de façon statique qui sont automatiquement traduits.

  • Computed LSPs—Chemins de routage source configurés de manière statique qui sont calculés avec CSPF (Constrained Shortest Path First).

  • Dynamic LSPs—Tunnels créés de manière dynamique via le module dynamic tunnel avec résolution ERO du dernier saut.

En fonction de la source du LSP de routage de segments, vous pouvez configurer la fonction de dégégage sur le PCC. Pour permettre la dégégage des LSP de routage de segments, inclure l’énoncé au lsp-external-controller pccd niveau approprié sous la [edit protocols source-packet-routing] hiérarchie.

Tableau 2 affiche une correspondance de la source LSP avec le niveau hiérarchique de configuration correspondant à lequel la capacité de dégation est activée.

Remarque :

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

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

Source de Segment Routing LSP

Hiérarchie de configuration

  • LSP à traduction automatique

  • LSP statiques

Liste principale des segments à l' [edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

LSP informatiques (CSPF distribué)

Liste principale des segments du chemin source-routage à:

  • [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 principale des segments du modèle de chemin source-routage:

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

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

Vous pouvez afficher l’état du contrôle des LSP SR-TE à partir de la commande show spring-traffic-engineering.

Tableau 3 affiche l’interaction PCEP lorsque lsp-external-controller l’instruction est configurée pour un chemin de routage source.

Tableau 3 : Interaction PCEP DSP - DDSP

Hiérarchie de configuration lsp-external-controller

source-routage-chemin D’État de d’origine

Interaction PCEP entre le PCC et PCE

Liste principale des segments des chemins source-routage

Première dYS

  1. Un message PCReport est envoyé au PCE en tant que d’équipe. PCReport contient uniquement des contraintes et des détails de chemin (tels que l’ERO).

  2. PCE calcule le chemin pour LSP et indique que le chemin est en état down.

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

Le même comportement est observé lors du redémarrage du processus de protocole de routage (rpd) ou d’moteur de routage basculement.

Liste principale des segments des chemins source-routage

D’autres membres se voient d’inger le chemin existant

  1. Un PCReport est envoyé au PCE pour une d bien- PCReport contient uniquement des contraintes et des détails de chemin (tels que l’ERO).

  2. Un segment principal correspondant est déléguer au PCE.

  3. PCE calcule le chemin du LSP.

  4. Le segment principal continue de contribuer au route tel qu’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 aucune mise à jour du routeur et l’état LSP n’est pas non plus surveillé et signalé à l’ordinateur. À ce stade, l’état LSP est signalé comme étant en hausse ou en baisse, en fonction de la réussite du calcul de chemin à ce stade.

    • Si le S-BFD est configuré pour le segment principal, l’état du segment principal est suivi et signalé à l’ordinateur. Si BFD détecte le segment principal en panne, le chemin principal correspondant est supprimé du chemin. Le 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, le SR-TE utilise les paramètres de réception pour configurer 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 du route s’effectuera de façon pré-break.

Segment principal du chemin source-routage

La d première partie n’a pas été configurée ou supprimée.

La liste de segments du PCE (si possible) n’est plus utilisée et le calcul issu de la configuration locale est utilisé. Lorsque le résultat local est disponible pour la liste de segments, la liste de segments correspondante est utilisée pour programmer le routeur de façon à se pré-rompre.

Liste de segments des chemins source-routage

Une fois le LSP configuré, la DSP est en place.

Dans le cadre du chemin source-routage, la fonction de d première liste de segments est déclenchée.

Liste de segments des chemins source-routage

La d première partie n’a pas été configurée ou supprimée.

Le chemin source-routage est supprimé de la liste de segments principal.

Liste principale des chemins de routage source

Une fois le LSP configuré, la DSP est en place.

  • Dans le modèle de chemin de routage source-source: la fonctionnalité de d’auto-d première partie est déclenchée pour l’ensemble du chemin de routage source.

    Seules les configurations de modèles peuvent être appliquées au module Dynamic Tunnel.

  • Dans le cadre du chemin principal du modèle de chemin de routage source- La fonctionnalité de dédation est déclenchée pour ce chemin principal en fonction de la configuration.

Liste principale des chemins de routage source

La d première partie n’a pas été configurée ou supprimée.

La fonctionnalité de dation est supprimée de tous les chemins de routage source et des chemins principaux qui correspondent à la configuration du modèle.

Routage de segments pour les limites PCEP et les fonctionnalités non pris en compte

La prise en charge du routage de segments pour PCEP n’alourdit pas la charge de performance sur le système. Toutefois, il présente les limites suivantes:

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

  • Les moteur de routage GRES (Graceful Switchover) et les mises à niveau logicielles unifiées en cours d’utilisation (ISSU unifiées) ne sont pas pris en charge.

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

  • IPv6 n’est pas pris en charge.

  • Les LSP déléguer par PCE n’ont pas la charge des questions suivantes:

    • SR-TE SSP s' ainsi fait la main

    • LSP IPv6

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

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

Exemple: Configuration du routage de segments pour le protocole de l’élément de calcul de chemin

Cet exemple montre comment configurer le routage de segments ou l’ingénierie du trafic TE SPRING (Source Packet Routing in Networking) pour le protocole PCEP (Path Computation Element Protocol). Dans cette configuration, nous profitons des avantages du routage de segments et des avantages du Path Computing externe pour des ingénieries de trafic efficaces.

Conditions préalables

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

  • Quatre MX Series de Plates-formes de routage universelles 5G, où le routeur d’entrée MX Series le client de calcul de chemin (PCC).

  • Une connexion TCP du PCC à un élément de calcul de chemin à états externe (PCE).

  • Junos OS version 17.2 ou ultérieure s’exécutant sur le PCC pour l’implémentation de LSP à l’initiative de PCE.

    Pour la fonctionnalité de DDSP, vous devez exécuter Junos OS version 20.1R1 version ultérieure.

Avant de commencer:

  • Configurez les interfaces de l’équipement.

  • Configurez MPLS.

  • Configurez IS-IS.

Présentation

La Junos OS du routage de segments pour PCEP inclut les LSP SR-TE PCE et déléguer PCE.

  • La mise en œuvre de LSP à l’initiative de PCE a été mise en œuvre dans Junos OS Release 17.2R1, où les fonctions techniques du trafic du routage de segments sont prise en charge dans les sessions PCEP pour LSP lancées par un PCE. Le PCE crée les LSP pour les segments d’adjacence et de nœuds. Des routes de tunnel sont créées dans la table de routage inet.3 du PCC correspondant aux LSP SR-TE PCE.

  • La mise en œuvre de LSP délègues PCE est mise en œuvre dans Junos OS Release 20.1R1, où les LSP de routage de segments noncolorés IPv4 configurés localement sur le PCC peuvent être déléguer à un contrôleur PCE. L’ordinateur contrôle ensuite le LSP et peut modifier les attributs LSP pour le calcul de chemin.

Les LSP déléguer par PCE ont un avantage sur les LSP initiés par PCE au moment de la panne de la session PCEP. Dans le cas des LSP lancés par PCE, lorsque la session PCEP est coupée, les LSP sont supprimés du PCC. Toutefois, dans le cas des LSP délégues par PCE, lorsque la session du PCEP est en panne, le PCC reprend le contrôle des LSP déléguer au PCE. Ainsi, avec les LSP délégues par PCE, nous vertons à une situation où les paquets sont silencieusement écartés (également appelés condition de route nulle) lorsque la session PCEP s’en trouve en panne.

Pour activer le routage de segments pour PCEP:

Pour les LSP de routage de segments (LSP) à l’initiative de PCE:

  1. Activer le calcul de chemin externe pour les MPLS en incluant lsp-external-controller l’instruction au niveau de la [edit protocols mpls] hiérarchie.

    Cette configuration est également requise pour les extensions PCEP TE RSVP-TE pcEP. Vous ne pouvez pas désactiver PCEP avec RSVP-TE lorsque le routage de segments pour PCEP est activé.

  2. Activez le calcul de chemin externe pour SR-TE en incluant lsp-external-controller pccd l’instruction au niveau de la [edit protocols spring-traffic-engineering] hiérarchie.

  3. Activez le routage de segments pour l’ordinateur (PCE) en incluant spring-capability l’instruction au niveau de la [edit protocols pcep pce pce-name] hiérarchie.

  4. Configurez la profondeur SID maximale pour l’ordinateur en incluant l’instruction au niveau max-sid-depth number[edit protocols pcep pce pce-name] de la 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. Si elle n’est pas configurée, une valeur SID maximale de 5 est appliquée par défaut.

  5. Configurez éventuellement la valeur de préférence pour le routage de segments en incluant le preference preference-value niveau [edit protocol spring-te] hiérarchique.

    La valeur de préférence indique l’ordre dans lequel un chemin est sélectionné comme chemin actif parmi les chemins de candidature pour lesquels une valeur plus élevée a une préférence plus élevée. Si elle n’est pas configurée, une valeur de préférence par défaut de 8 est appliquée.

  6. Configurez éventuellement la journalisation du routage de segments à des fins de dépannage en incluant traceoptions l’instruction au niveau de la [edit protocols spring-te] hiérarchie.

Pour la DSP (DSP) de routage de segments d’un côté, et d’autre part, pour les étapes ci-dessus, faites les actions suivantes:

  1. Définissez une liste de segments avec les paramètres d’étiquette. Ceci crée un LSP de routage de segments au niveau local sur le PCC.

  2. Possibilité de déggée du LSP configuré localement sur le PCC en incluant l’énoncé dans l’une des hiérarchies suivantes en fonction de la source LSP de routage de lsp-external-controller pccd segments:

    • Pour les chemins de routage source configurés de façon statique qui sont calculés avec CSPF distribués et des niveaux [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] hiérarchiques.

    • Pour les chemins de routage source configurés de façon statique qui ont l’ensemble de la pile de label configurées de manière statique et les chemins de routage source qui sont automatiquement traduits: niveau [edit protocols source-packet-routing source-routing-path lsp-name primary path-name] hiérarchique.

    • Pour les tunnels créés dynamiquement par le biais du module dynamic tunnel avec résolution ERO du dernier saut, ainsi que des niveaux [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] hiérarchiques.

Topologie

Figure 8 illustre un exemple de topologie réseau avec une session PCEP s’exécutant entre le PCE et le PCC (le routeur d’entrée MX Series). Les routeurs R1, R2 et R3 sont les MX Series du réseau. Dans cet exemple, nous configurons le routage de segments pour PCEP sur le PCC. Nous configurons également un routeur statique sur le PCC vers le routeur R3 pour vérifier l’utilisation des routes de tunnel SR-TE lors du routage du trafic pour la route statique.

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

Configuration

CLI configuration rapide

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les interruptions de ligne, modifiez tous les détails nécessaires pour correspondre à votre configuration réseau, copiez et collez les commandes dans le CLI au niveau de la hiérarchie, puis entrez dans le [edit]commit 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 ne documente que la configuration du PCC.

Pcc

Routeur R1

Routeur R2

Routeur R3

Procédure
Procédure étape par étape

Dans cet exemple, nous configurons uniquement le PCC.

Les étapes suivantes vous obligent à naviguer dans différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation du CLI, consultez le guide de l’CLI en mode de configuration dans CLI’utilisateur.

Pour configurer le PCC:

  1. Configurez les interfaces du PCC.

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

  3. Configurez un routeur statique du PCC au routeur R3.

    La route statique est créée à des fins de vérification uniquement et n’affecte pas la fonctionnalité.

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

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

  6. Activer une fonction de calcul de chemin externe pour les MPLS.

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

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

  9. Activer une fonction de calcul de chemin externe pour SR-TE.

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

  11. Activer le provisiontage de LSP de routage de segments par le PCE.

  12. Activez la fonctionnalité de routage de segments pour l’ordinateur.

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

  14. Configurez un LSP de routage de segments statique du PCC au routeur R3 pour une dégéggée PCE.

  15. Permettre la possibilité de d première d première voie static_srte_lsp_1 pour le chemin de routage source.

    En complétant les étapes 13, 14 et 15, vous autorisez le PCC à déléguer les LSP de routage de segments au PCE.

  16. Valider la configuration.

Résultats

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

Si vous avez terminé la configuration de l’équipement (le PCC), saisissez commit le mode de configuration.

Vérification

Vérifier que la configuration fonctionne correctement.

Vérifier IS-IS adjacence et les labels
But

Vérifiez l IS-IS jacence sur le PCC. Notez la plage d’étiquettes SRGB, les valeurs d’adjacence et de segments de nœuds, ainsi que les champs de sortie des capacités SPRING.

Action

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

Sens

L IS-IS adjacence entre le PCC et LE PCE et celle entre le PCC et le routeur R1 sont opérationnelles. Le résultat affiche également l’affectation d’étiquettes pour les segments adjacents et de nœuds.

Vérifier la base de données des ingénieries de trafic
But

Vérifier les entrées de la base de données des ingénieries de trafic sur le PCC.

Action

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

Sens

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

Vérifier les LSP SR-TE
But

Vérifier la création de LSP SR-TE sur le PCC.

Action

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

Sens

Les sorties indiquent que deux LSP SR-TE (et) ont été créés par le PCE respectivement pour les segments d’adjacence et les segments de adj_sid_lspnode_sid_lsp nœuds.

Le LSP (Segment Routing LSP) est activé avec la capacité static_srte_lsp_1 de dégégage. Le champ affiche le statut de contrôle et de routage des LSP délègues à PCE. signifie que le PCE a le contrôle sur les LSP. signifie que PCE a fourni l’ERO pour le chemin Delegation infoExternally controlled de Externally routed routage source.

Vérifier la création d’un chemin de tunnel
But

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

Action

À partir du mode fonctionnement, exécutez show route table inet.3 extensive la commande.

Sens

Des routes de tunnel ont été créées pour la destination LSP contrôlée par PCE avec le protocole SR-TE étiquette de protocole.

Vérifier les entrées du tableau de forwarding
But

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

Action

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

Sens

L’adresse IP de TE de destination SR-TE au routeur R3 est installée en tant qu’entrée de routeur.

Vérifier l’utilisation des routes de tunnel pour le transport de routes statiques
But

Vérifiez que la route statique prend le chemin tunnel créé pour les LSP TE SR-TE.

Action

À partir du mode opérationnel, exécutez show route ip-address les show route forwarding-table destination ip-address commandes.

Sens

Les sorties indiquent que la route statique vers le routeur R3 utilise la route de tunnel créée pour le SR-TE LSP.

Chemin de commutage d’étiquettes de routage de segments statique

L’architecture de routage de segments permet aux équipements d’entrée d’un réseau central d’orienter le trafic par des chemins explicites. Vous pouvez configurer ces chemins à l’aide de listes de segments pour définir les chemins que le trafic entrant doit prendre. Le trafic entrant peut être marqué ou trafic IP, ce qui permet au dispositif d’entrée de permuter des étiquettes ou de rechercher la destination.

Understanding Static Segment Routing LSP in MPLS Networks

Le routage des paquets source ou le routage de segments est une architecture de plan de contrôle qui permet à un routeur d’entrée d’orienter un paquet par le biais d’un ensemble spécifique de liens et de nodes du réseau, sans pour autant se reposer sur les nodes 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 par le biais d’une liste d’instructions, appelées segments. Un segment peut représenter n’importe quelle instruction, topologique ou basée sur des services. Un segment peut avoir une sémantique locale vers un nœud de routage de segment ou vers un nœud global dans un domaine de routage de segments. Le routage de segments assure le passage d’un flux à n’importe quel chemin topologique et chaîne de services, tout en conservant son état par flux uniquement au niveau de l’équipement d’entrée vers le domaine de routage de segments. Le routage de segments peut être directement appliqué à l’architecture MPLS sans modification du plan de routage. Un segment est encodé sous la MPLS étiquette. Une liste ordreée de segments est encodée sous la marque d’une pile de labels. Le segment à traiter est au-dessus de la pile. À l’issue d’un segment, le label associé est sur la pile.

Les LSP de routage de segments peuvent être de nature dynamique ou statique.

Dynamic segment routing LSPs—Lorsqu’un LSP de routage de segments est créé par un contrôleur externe et téléchargé sur un équipement d’entrée via des extensions PCEP (Path Computation Element Protocol), ou via une stratégie de routage de segments BGP via des extensions de routage de segments BGP, le LSP est provisionnable dynamiquement. La liste de segments du LSP de routage de segments dynamique est contenue dans l’objet de routage explicite PCEP (ERO) ou dans la stratégie de routage de segments BGP du LSP.

Static segment routing LSPs—Lorsqu’un LSP de routage de segments est créé sur l’équipement d’entrée par le biais d’une configuration locale, le LSP est provisioné de façon statique.

Un LSP de routage de segments statique peut être classifié plus en tant que LSP inférable ou non en fonction de la configuration de l’énoncé au niveau color[edit protocols source-packet-routing source-routing-path lsp-name] de la hiérarchie.

Quelques chiffres clés :

[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 principale 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 de l’utilisation des LSP de routage de segments

  • Le routage de segments statique ne s’appuie pas sur l’état de transfert par LSP sur les routeurs de transit. D’où la suppression du besoin de provisionnation et de maintien de l’état de forwarding par LSP dans le cœur du site.

  • Fournissent une plus grande évolutivité aux MPLS réseaux.

LSP statiques de routage de segments

Un LSP de routage de segments statique configuré avec l’instruction est appelé color LSP infertant.

Compréhension de la dynamique statique des LSP de routage de segments

À l’manière d’BGP routage de segments, le routage d’entrée de l’IXP s’installe dans les tables de routage ou les tables de routage, avec comme clé pour mappage du trafic inetcolor.0inet6color.0destincation-ip-address, color IP.

Un LSP statique statique de routage de segments peut avoir un SID obligatoire pour lequel un routage est installé dans la mpls.0 table de routage. Ce label SID obligatoire permet d’associer le trafic étiqueté au LSP de routage de segments. Les passerelles du route sont dérivées des configurations de listes de segments des chemins principaux et secondaires.

Liste segments des LSP de routage de segments inséchers

Les LSP statiques statiques et statiques qui vantent déjà la charge du premier saut en mode de résolution d’un LSP. Toutefois, le mode IP du premier saut n’est pas pris en charge pour les LSP de routage de segments insaisirstifs. À partir de Junos OS version 19.1R1, une fonction de vérification de validation est mise en place pour s’assurer que toutes les listes de segments contribuant aux routes de validation disposent du label minimum pour tous les sauts. Si cette exigence n’est pas satisfaite, la validation est bloquée.

LSP de routage de segments statique non statique non statique

Un LSP de routage de segments statique configuré sans l’énoncé est un color LSP non-égégante. À l’identique des tunnels de routage de segments PCEP, la route d’entrée est installée dans les inet.3 tables de inet6.3 routage ou.

Junos OS prend en charge les LSP de routage de segments statiques non-différentes sur les routeurs d’entrée. Vous pouvez provisioner un chemin routage source et une ou plusieurs listes de segments en mesure de fournir un LSP de routage de segments statique non-statique. Ces listes de segments peuvent être utilisées par de multiples LSP de routage de segments non-différentes.

Comprendre les LSP de routage de segments non-segments non-segments

Le LSP de routage de segments non-différentes possède un nom unique et une adresse IP de destination. Un chemin d’entrée vers la destination est installé dans la table de routage inet.3 avec une préférence par défaut de 8 et une mesure de 1. Cette route permet d’associer les services non-différentes au LSP de routage de segments de leur destination. Si le LSP de routage de segments non désinstant ne nécessite pas de route d’entrée, alors celui-ci peut être désactivé. Un LSP de routage de segments non-différentes utilise un label SID qui lient pour obtenir un assemblage LSP de routage de segments. Ce label peut être utilisé pour modéliser le LSP de routage de segments en tant que segment qui peut être davantage utilisé pour construire d’autres LSP de routage de segments de manière hiérarchique. Par défaut, le transit du label SID obligatoire a une préférence de 8 et une mesure de 1.

À partir de Junos OS Version 18.2R1, les LSP de routage de segments configurés de façon statique sur l’équipement d’entrée sont signalés à l’élément de calcul de chemin (PCE) par le biais d’une session PCEP (Path Computation Element Protocol). Ces LSP de routage de segments non différentes sont peut-être associés par des labels SID (Service Identifier). Grâce à cette fonctionnalité, le PCE peut utiliser ce label SID obligatoire dans la pile d’étiquettes pour provisioner des chemins LSP de routage de segments pcE.

Un LSP de routage de segments non différentes peut avoir un maximum de 8 chemins principaux. S’il existe plusieurs chemins principaux opérationnels, le moteur de forwarding 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 coût égal pour plusieurs chemins (ECMP) si aucun des chemins n’a un poids configuré sur eux ou pondéré ECMP si au moins un des chemins a un poids non-nul configuré sur les chemins. Dans les deux cas, en cas de panne d’un ou de certains chemins, le PFE équilibre le trafic sur les chemins restants pour assurer automatiquement la protection des chemins. Un LSP de routage de segments non-différentes peut avoir un chemin secondaire pour une protection dédiée des chemins. En cas de défaillance d’un chemin principal, le PFE équilibre le trafic vers les chemins principaux fonctionnels restants. Sinon, le PFE bascule le trafic vers le chemin de secours, d’où une protection des chemins. Un LSP de routage de segments non différentes peut spécifier une mesure à son entrée et ses [edit protocols source-packet-routing source-routing-path lsp-name] routes SID contraignantes. Plusieurs LSP de routage de segments non différentes ont la même adresse de destination qui contribue au saut suivant de la route d’entrée.

Plusieurs LSP de routage de segments non différentes ont la même adresse de destination qui contribue au saut suivant de la route d’entrée. Chaque chemin (principal ou secondaire) de chaque LSP de routage de segments est considéré comme un candidat à la passerelle si le chemin est fonctionnel et que le LSP de routage de segments possède la meilleure préférence de tous ces LSP de routage de segments. Toutefois, le nombre maximal de passerelles que le saut suivant peut conserver ne peut pas dépasser la limite de multi-chemins du RPD, qui est de 128 par défaut. Les chemins supplémentaires sont ensuite chemins secondaires, puis principaux. Une liste de segments donnée peut être appelée à plusieurs reprises comme chemins principaux ou secondaires par ces LSP de routage de segments. Dans ce cas, il existe plusieurs passerelles 100 % segment routage et tunnel LSP. Ces passerelles sont distinctes, même si leur pile et interface sortantes sont identiques. Un LSP de routage de segments non-différentes et un LSP de routage de segments non-différentes peuvent également avoir la même adresse de destination. Toutefois, elles correspondent à différentes adresses de destination pour les routes d’entrée, car l’adresse de destination du LSP de segments est construite à la fois avec son adresse de destination et sa couleur.

Remarque :

Dans le cas où un LSP de routage de segments statique et un LSP créé par PCEP co-existent et ont la même adresse qui contribue à la même route d’entrée, 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 la route.

Liste de segments des LSP de routage de segments non-segmenté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 d’étiquettes SID répertoriées dans la liste de segments ne doit pas dépasser la limite maximale de la liste de segments. La liste de segments maximale qui lie un tunnel LSP est augmentée de 8 à 128, avec 1 000 tunnels maximum par système. Un maximum de 128 chemins principaux est pris en charge par LSP de routage de segments statique. Vous pouvez configurer la limite maximale de liste de segments au niveau [edit protocols source-packet-routing] de la hiérarchie.

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

Pour que le mode de label du premier saut prenne effet, vous devez inclure l’instruction globalement ou individuellement pour une liste de segments, et le premier saut de la liste de segments doit inclure à la fois l’adresse IP et le inherit-label-nexthops label. Si le premier saut inclut uniquement une adresse IP, inherit-label-nexthops l’instruction n’a aucun effet.

Vous pouvez vous configurer inherit-label-nexthops dans l’une des hiérarchies suivantes. L’instruction n’entre en vigueur que si le premier saut de la liste de segments inclut à la fois inherit-label-nexthops l’adresse IP et l’étiquette.

  • Segment list level— Au niveau [edit protocols source-packet-routing segment-list segment-list-name] hiérarchique.

  • Globally— Au niveau [edit protocols source-packet-routing] hiérarchique.

Lorsque l’énoncé est configuré globalement, il prend la priorité sur la configuration au niveau de la liste de segments et la configuration est appliquée à toutes les inherit-label-nexthopsinherit-label-nexthops listes de segments. Lorsque l’instruction n’est pas configurée globalement, seules les listes de segments avec des labels et des adresses IP présentes dans le premier saut, et configurées avec une instruction sont résolues à l’aide des inherit-label-nexthopsinherit-label-nexthops labels SID.

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

Tableau 4 décrit le mode de résolution LSP de routage de segments basé sur la spécification du premier saut.

Tableau 4 : Résolution LSP statique non-statique statique basée sur la spécification du premier saut

Spécification du premier saut

Mode de résolution LSP

Adresse IP uniquement

Quelques chiffres clés :

segment-list path-1 {
    hop-1 ip-address 172.0.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

Quelques chiffres clés :

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 la configuration)

Quelques chiffres clés :

segment-list path-3 {
    hop1 {
        label 801006;
        ip-address 172.24.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 la inherit-label-nexthops configuration)

Quelques chiffres clés :

segment-list path-3 {
    inherit-label-nexthops;
    hop1 {
        label 801006;
        ip-address 172.24.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 commande pour afficher les LSP de routage de segments non-différentes qui sont conçues pour le trafic et qui ont plusieurs listes de segments installées dans la table de show route ip-address protocol spring-te active-path table inet.3 routage inet.3.

Quelques chiffres clés :

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:

  • Les différentes listes de segments d’un tunnel ont différents types de résolution du premier saut. Cette norme s’applique aux LSP de routage de segments statiques à la fois insértables et non-différentes. Toutefois, cela ne s’applique pas aux LSP pilotés par PCEP; un message de journal système est généré en cas d’inconnection du type de résolution du premier saut au moment du calcul du chemin.

    Quelques chiffres clés :

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

  • Le SID obligatoire est activé pour les LSP statiques non-invités dont le type de liste de segments est un label SID.

    Quelques chiffres clés :

    La configuration d’une SID contraignante sur une liste de segments d’étiquettes n’est prise en charge que pour les LSP statiques et non pour les LSP statiques non-statiques.

Provisionation LSP de routage de segments statique

Le provisionment de segments est exécuté sur chaque routeur. Pour un segment donné sur un routeur, un label SID (Service Identifier) unique est alloué à partir d’un pool de label souhaité, qui peut se trouve dans le pool de label dynamique d’un label SID d’adjacence ou du bloc global de routage de segments (SRGB) pour un SID de préfixe ou siD de nœud. Le label SID d’adjacence peut être attribué de façon dynamique, c’est-à-dire le comportement par défaut, ou à partir d’un pool de label statique local (SRLB). Un chemin pour le label SID est ensuite installé dans la table mpls.0.

Junos OS LSP de routage de segments statique en configurant segment l’énoncé au niveau de la [edit protocols mpls static-label-switched-path static-label-switched-path] hiérarchie. Un segment LSP statique est identifié par un label SID unique qui ne passe Junos OS de label statique. Vous pouvez configurer le pool Junos OS d’étiquettes statiques en configurant static-label-range static-label-range l’instruction au niveau de la [edit protocols mpls label-range] hiérarchie.

Limitations LSP de routage de segments statique

  • Junos OS est limitée par le fait que le saut suivant ne peut pas être créé pour pousser plus que les étiquettes de profondeur de liste de segments maximales. Ainsi, une liste de segments avec plus que le nombre maximal d’étiquettes SID (à l’exception du label SID du premier saut utilisé pour résoudre le problème du saut suivant) n’est pas utilisable à des raisons comme des LSP de routage de segments insévables ou non. Par ailleurs, le nombre réel autorisé pour un LSP de routage de segments donné peut être même inférieur à la limite maximale, si un service MPLS se trouve sur le LSP de routage de segments ou que le LSP est sur une liaison ou un chemin de protection de nœud. Dans tous les cas, le nombre total de labels de services, labels SID et 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 [edit protocols source-packet-routing] niveau hiérarchique. Il est possible d’assembler plusieurs LSP de routage de segments non différentes avec un nombre d’étiquettes SID inférieur ou égal au maximum pour construire un LSP de routage de segments plus long. C’est ce que l’on appelle le assemblage LSP de routage de segments. Il est possible de le faire à l’aide d’une étiquette SID contraignante.

  • Le assemblage LSP de routage de segments s’effectue en fait au niveau du chemin. Si un LSP de routage de segments non-différentes possède plusieurs chemins (listes de segments multiples), chaque chemin peut être assemblage indépendamment à un autre LSP de routage de segments non-différentes au point de assemblage. Un LSP de routage de segments non insaisirable, dédié au assemblage, peut désactiver l’installation du routage d’entrée en configurant l’énoncé au niveau no-ingress[edit protocols source-packet-routing source-routing-path lsp-name] hiérarchique.

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

  • La liste de segments maximale qui lie un tunnel LSP est augmentée de 8 à 128, avec 1 000 tunnels maximum par système. Un maximum de 128 chemins principaux est pris en charge par LSP de routage de segments statique. En limitation, la prise en charge maximale du chemin LSP par le capteur est de 3 2000 uniquement.

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

Création dynamique de LSP de routage de segments

Dans les réseaux de routage de segments dont chaque équipement de périphérie fournisseur (PE) est connecté à chaque autre équipement PE, une grande configuration est requise pour mettre en place les chemins de commutation d’étiquettes (LSP) de routage de segments, même si seuls quelques chemins de routage de segments conçus par (SR-TE) peuvent être utilisés. Vous pouvez activer BGP de création dynamique tritrée de ces LSP afin de réduire le nombre de configurations 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’énoncé « spring-te » au niveau de la [edit routing-options dynamic-tunnels] hiérarchie.

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

  • Il s’agit d’un exemple de configuration pour le modèle LSP de routage de segments dynamique non couleur:

Résolution des LSP de routage de segments dynamique
Résolution de LSP dynamique dynamique de routage de segments

Lorsque les préfixes BGP sont assignés à la communauté couleur, ils sont d’abord résolus par la stratégie catch-all-route-for-that-particular-color, et à leur tour, le modèle SR-TE sur lequel le préfixe BGP doit être résolu est identifié. La siD de destinations est ensuite dérivée de l’attribut BGP préfixe de saut suivant. 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 pris et un label correspondant est préparé et mis en place au bas de la pile. Le préfixe de charge utile de BGP est résolu en mode color-only, où le nœud-SID de l’équipement A se trouve en bas de la pile de labels final et les étiquettes de chemin SR-TE sont au-dessus.

Le nom final du modèle LSP est une combinaison de préfixe, de couleur et de nom de tunnel ; par <prefix>:<color>:dt-srte-<tunnel-name> exemple. La couleur du nom LSP s’affiche au format hexadécimaux, et le format du nom du tunnel est similaire à celui des noms LSP de tunnel déclenchés par O RSVP.

Pour résoudre un réseau de destination différentes, la couleur doit être mappage de modèle valide, soit via une couleur spécifique, soit via le color-any modèle. Sans mappage valide, le tunnel n’est pas créé et le BGP pour résolution reste en suspens.

Résolution des LSP de routage de segments dynamiques noncolores

Les routes « catch-all » pour les LSP non-égégants sont ajoutées à la table de routage inet.3. La destination du tunnel sans insélation doit être configurée dans une configuration différente avec un seul spring-te nom de modèle dans la liste de mappage. Ce nom de modèle est utilisé pour tous les chemins 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 fonctionnalité.

Le nom final du modèle LSP est une combinaison de préfixe et de nom de tunnel. par <prefix>:dt-srte-<tunnel-name> exemple.

Configuration d’exemples de LSP de routage de segments dynamique

Le modèle LSP de routage de segments dynamique transporte toujours un chemin partiel. Le siD de nœud du dernier saut est dérivée automatiquement au moment de la création du tunnel en fonction de l’adresse PNH (Protocol Next-Hop Address) SID. Le même modèle peut être utilisé par plusieurs tunnels vers différentes destinations. Dans ce cas, le chemin partiel reste le même, et seul le dernier saut change selon le PNH. Les modèles LSP de routage de segments dynamiques ne sont pas courants au niveau d’un tunnel unique, par conséquent, un chemin complet ne peut pas être effectué. Vous pouvez utiliser une liste de segments si vous devez utiliser un chemin complet.

RSP dynamiques et dynamiques de routage de segments

Exemple de configuration pour les LSP dynamiques et dynamiques du routage:

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

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

  2. inetcolor6.0 tunnel route: ffff:::22.33.44.0-0/120 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping:

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

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

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

  4. inetcolor.0 tunnel route:

    22.33.44.55-101/64 --><next-hop>

    22.33.44.55-124/64 --><next-hop>

  5. inetcolor6.0 tunnel route:

    ffff:::22.33.44.55-101/160 --><next-hop>

    ffff::22.33.44.55-124/160 --><next-hop>

LSP de routage de segments dynamique non dynamique et non dynamique

Exemple de configuration des LSP dynamiques de routage de segments non-dynamiques:

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

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

  2. inet6.3 tunnel route: ffff:::22.33.44.0/120 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping:

    R1(préfixe) -> 22.33.44.55 (PNH) Nom de modèle LSP = LSP1 --- 22.33.44.55:dt-srte-tunnel2

    R1(préfixe) ->ffff:::22.33.44.55 (PNH) Nom de modèle LSP = LSP1 --- 22.33.44.55:dt-srte-tunnel2

  4. inet.3 tunnel route: 22.33.44.55/32 --><next-hop>

  5. inet6.3 tunnel route: ffff::22.33.44.55/128 --><next-hop>

LSP de routage de segments dynamique non résolu

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

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

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

  2. inetcolor6.0 tunnel route: ffff:::22.33.44.0 - 0/120 --> RT_NH_TUNNEL ffff:::1.1.1.0 - 0 /24 -> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping: R1 (préfixe) -> 22.33.44.55-124 (PNH) ne sera pas créé. (Modèle in found for the color).

Considérations pour la configuration de la création dynamique de LSP de routage de segments

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

  • Un modèle peut être attribué avec un objet en couleur. Lorsque la configuration de tunnel dynamique inclut un modèle avec un objet couleur, vous devez configurer tous les autres modèles avec des spring-te objets couleurs. Toutes les destinations sont différentes au sein de cette configuration.

  • Un modèle peut avoir une liste de couleurs définies ou peut être configuré avec color-any l’option. Ces deux options peuvent coexister dans la même spring-te configuration. Dans ce cas, les modèles attribués avec des couleurs spécifiques ont une préférence plus élevée.

  • Dans une configuration, un seul modèle peut spring-te être défini avec color-any l’option.

  • Le mappage color-to-template s’effectué individuellement. Une couleur ne peut pas se baser sur plusieurs modèles.

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

  • Les destinations insélations et autres ne peuvent pas exister dans une spring-te même 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-configuration, un seul modèle peut être spring-te configuré sans objet couleur.

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

Les services suivants sont pris en charge par des LSP dynamiques et dynamiques de routage de segments:

  • VPN de couche 3

  • BGP EVPN

  • Services de stratégies d’exportation

Les services suivants sont pris en charge par les LSP dynamiques de routage de segments non-égégants:

  • 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 de segments routage (par exemple, tunnels statiques et dynamiques), la préférence de routage de segment est utilisée pour choisir l’entrée de routage active. Une valeur plus élevée a une préférence plus grande. Si la préférence reste la même, la source du tunnel est utilisée pour déterminer l’entrée du routeur.

Limitations des LSP de routage de segments dynamique

Les LSP dynamiques TE SR-TE ne disposent pas des fonctionnalités et fonctionnalités suivantes:

  • Tunnels de routage de segments IPv6.

  • Tunnels statiques.

  • Le 6PE n’est pas pris en charge.

  • CSPF distribué.

  • La tunnellité sBFD et LDP n’est pas prise en charge pour les TE SR-TE dynamiques ni dans un modèle.

  • Installer des routes B-SID dans un modèle.

Mappage basé sur la couleur des services VPN

Vous pouvez spécifier la couleur en tant que contrainte de saut suivant du protocole (en complément de l’adresse IPv4 ou IPv6) pour résoudre les tunnels de transport en cas de déchargement statique et LSP (SRTE) de routage de segments de BGP. C’est ce que l’on appelle la résolution du saut suivant du protocole color-IP, où vous devez configurer une carte de résolution et l’appliquer aux services VPN. Grâce à cette fonctionnalité, vous pouvez activer l’orientation du trafic selon la couleur des services VPN de couche 2 et 3.

Junos OS prend en charge les LSP SRTE associés à une seule couleur. La mise en correspondance par couleur des services VPN est prise en charge sur les LSP statiques et BGP LSP SRTE.

Coloration des services VPN

En général, un service VPN peut se faire attribuer une couleur sur le routeur de sortie où l’offre NLRI VPN est annoncée, ou sur un routeur d’entrée où le NLRI VPN est reçu et traiter.

Vous pouvez attribuer une couleur aux services VPN à différents niveaux:

  • Par instance de routage.

  • Par BGP groupe.

  • Par BGP voisin.

  • Par préfixe.

Une fois que vous attribuez une couleur, la couleur est rattachée à un service VPN sous la forme d’BGP communauté étendue de couleurs.

Vous pouvez attribuer plusieurs couleurs à un service VPN, appelé services VPN multicolores. Dans ce 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 affectées par les équipements de sortie et/ou d’entrée par le biais de plusieurs stratégies de l’ordre suivant:

  • BGP d’exportation sur l’équipement de sortie.

  • BGP d’importation sur l’équipement d’entrée.

  • Stratégie d’importation VRF sur l’équipement d’entrée.

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

Attribution de la couleur du sortie

Dans ce mode, c’est l’équipement de sortie (c’est-à-dire l’annonceur de l’application VPN NLRI) qui est chargé de colorer le service VPN. Pour activer ce mode, vous pouvez définir une stratégie de routage et l’appliquer dans l’instance de routage, l’exportation de groupe ou l’exportation de voisin de groupe au niveau hiérarchique du service vrf-export[edit protocols bgp] VPN. L’offre NLRI VPN est annoncée BGP avec la communauté étendue de couleur spécifiée.

Quelques chiffres clés :

Ou

Remarque :

Lorsque vous appliquez la stratégie de routage comme stratégie d’exportation d’un groupe de BGP ou d’un voisin BGP, vous devez inclure l’instruction au niveau des BGP, du groupe BGP ou du niveau de voisin BGP afin que la stratégie prenne effet sur vpn-apply-export l’ILRI VPN.

Les stratégies de routage sont appliquées aux NLRI de préfixe VPN de couche 3, aux NRLIS VPN de couche 2 et aux NRE EVPN. La communauté étendue de couleurs est héritée par toutes les routes VPN, importé et installé dans les VRF cibles sur un ou plusieurs équipements d’entrée.

Attribution de la couleur d’entrée

Dans ce mode, c’est l’équipement d’entrée (c’est-à-dire le récepteur de l’ILRI VPN) qui est chargé de colorer le service VPN. Pour activer ce mode, vous pouvez définir une stratégie de routage et l’appliquer à l’instance de routage, à l’importation de groupe ou à l’importation de voisin de groupe au niveau hiérarchique du service vrf-import[edit protocols bgp] VPN. Toutes les routes VPN correspondant à la stratégie de routage sont rattachées à la communauté étendue de couleur spécifiée.

Quelques chiffres clés :

Ou

Spécifiant le mode de mappage de services VPN

Pour spécifier des modes de mappage de services VPN flexibles, vous devez définir une stratégie à l’aide de l’énoncé et la référer dans l’instance de routage, l’importation de groupe ou l’importation de voisin de groupe au niveau de la hiérarchie resolution-map d’un service vrf-import[edit protocols bgp] VPN. Toutes les routes VPN correspondant à la stratégie de routage sont rattachées à la carte de résolution spécifiée.

Quelques chiffres clés :

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 BGP ou à BGP voisin.

Remarque :

Chaque mode de mappage de services VPN doit avoir un nom unique défini dans la carte résolution. Seule une seule entrée de couleur IP est prise en charge dans la carte de résolution, où les routeurs VPN sont résolus à l’aide d’un protocole IP de type 1er saut suivant sous la forme de ip-address:color .

Résolution du saut suivant par le protocole Color-IP

Le processus de résolution du saut suivant du protocole est amélioré pour prendre en charge la résolution du protocole 102/IP du prochain saut. Pour un service VPN inserant, le processus de résolution du protocole suivant prend une couleur et une carte de résolution, développe un protocole IP à saut suivant sous la forme d’adresse IP:couleur,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 multi-chemin d’une vpn de couche 2, d’un VPN de couche 3 ou de services EVPN sur les LSP insaisints. La politique doit ensuite être appliquée au tableau RIB pertinent en tant que politique d’importation de solution.

Quelques chiffres clés :

Résolution du saut suivant du protocole IP

Si un service VPN inserant une carte de résolution ne s’applique pas à celui-ci, le service VPN ignore sa couleur et revient à la résolution du prochain saut du protocole IP. À l’inverse, si un service VPN non- présévique dispose d’une carte de résolution appliquée, la carte de résolution est ignorée, et le service VPN utilise la résolution du saut suivant du protocole IP.

Il s’agit d’un processus simple qui va des LSP SRTE à ceux des LSP 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 plus longue en raison d’un saut suivant d’un protocole IP d’adéquation garantit que si une route LSP SRTE de plus en plus rapide n’existe pas, une route LDP avec une adresse IP équivalente doit être renvoyée.

BGP mappage unicast basé sur les couleurs sur SR-TE

À partir de Junos OS Version 20.2R1, BGP labelé Unicast (BGP-LU) peut résoudre les routes IPv4 ou IPv6 sur les ingénieries de trafic de routage de segments (SR-TE) pour les gammes d’adresses IPv4 et IPv6. BGP-LU prend en charge la mise en correspondance BGP couleur de la communauté et la définition d’un resolution map pour le SR-TE. Un protocole de va-et-passe est créé et il est résolu par un tunnel SR-TE qui se trouve dans inetcolor.0 la inet6color.0 ou la table. BGP et inet.3inet6.3 tableaux pour une mise en correspondance basée sur les couleurs. Vous pouvez ainsi mettre en avant les préfixes IPv6 et IPv4 BGP-LU avec une adresse IPv6 de saut suivant dans les réseaux IPv6 uniquement où les routeurs ne comptent pas d’adresses IPv4 configurées. Grâce à cette fonctionnalité, nous traitons actuellement BGP lu IPv6 sur SR-TE avec IS-IS underlay.

Dans , le contrôleur configure 4 tunnels inséables dans un réseau central Figure 9 IPv6 configuré avec le SR-TE. Chaque tunnel de l’insélité prend 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 sur abcd:3701:2d05 interface dans le routeur D . BGP importation de stratégies pour attribuer une couleur et une carte de résolution au préfixe reçu: 3700:6/128. En fonction de la couleur de la communauté affectée, BGP-LU résout le saut suivant inséparable pour BGP préfixe LU IPv6 conformément à la stratégie de carte de résolution affectée.

Figure 9 : BGP’IPv6 LU sur IPv6 SR-TEBGP’IPv6 LU sur IPv6 SR-TE

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

  • BGP les BGP IPv4 SR-TE, avec extensions ISIS/OSPF SR IPv4.

  • BGP L’IPv4 LU est à la fois statique et statique et non-statique IPv4 SR-TE, avec des extensions ISIS/OSPF SR IPv4.

  • BGP lu IPv6 sur les BGP SR-TE IPv6, avec extensions ISIS IPv6 SR.

  • BGP de l’IPv6 LU en cas de statique statique ou non IPv6 SR-TE, avec extensions SR ISIS IPv6.

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

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

  • Services VPN IPv6 de couche 3 sur une période IPv6 SR-TE statique et non-insaisissable, avec extensions SR ISIS IPv6.

Fonctionnalités prise en charge et non prise en charge pour la mise en correspondance basée sur la couleur des services VPN

Les fonctionnalités et fonctionnalités suivantes sont prise en charge par la mise en correspondance par couleur des services VPN:

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

  • BGP EVPN

  • Résolution avec une seule option de couleur IP.

  • Suivre la résolution des sauts entre les protocoles IPv4 et IPv6.

  • Base d’informations de routage (également connue sous le nom de table de routage) retour en arrière vers la table de routage LDP LSP inetcolor.0.

  • SRTE s’erte lSP s’erd.

  • plates-formes virtuelles.

  • 64 bits Junos OS.

  • Systèmes logiques.

  • BGP unicast.

Les fonctionnalités et fonctionnalités suivantes ne sont pas prise en charge par la mise en correspondance par couleur des services VPN:

  • S’MPLS LSP comme RSVP, LDP, BGP-LU, statique.

  • Circuit de couche 2

  • La technologie FEC-129 BGP vpn de couche 2 à auto-découverte et avec signalisation LDP.

  • VPLS

  • MVPN (MVPN)

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

Modèles de tunnel pour les LSP de routage de segments à l’initiative de PCE

Vous pouvez configurer un modèle de tunnel pour les LSP de routage de segments lancés par PCE afin de transmettre deux paramètres supplémentaires pour ces LSP: la détection de routage bidirectionnelle (BFD) et la tunnelisation LDP.

Lors de la création d’un LSP de routage de segments pcE, le LSP est vérifié par rapport aux instructions de stratégie (le cas caser) et en cas de 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) ; mesure, par exemple.

Pour configurer un modèle:

  1. Inclure l’instruction de modèle de chemin-routage source au niveau [edit protocols source-packet-routing] de la hiérarchie. Vous pouvez configurer ici les paramètres de tunneling BFD et LDP supplémentaires.

  2. Inclure l’instruction source-routage-chemin-modèle-map au niveau de la hiérarchie pour énumérer les instructions de stratégie à partir des lesquelles il est nécessaire de contrôler le LSP lancé par [edit protocols source-packet-routing] PCE.

  3. Définissez une stratégie pour énumérer les LSP sur lesquels le modèle doit être appliqué.

    L’énoncé peut inclure le nom LSP ou l’expression régulière LSP à l’aide from des lsp conditions de lsp-regex correspondance. Ces options sont mutuellement exclusives, de sorte que vous pouvez spécifier une seule option à un moment donné.

    La then déclaration doit inclure l’option avec une action sr-te-template acceptée. Ce modèle s’applique au LSP à l’initiative de PCE.

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

  • La configuration de modèle ne s’applique pas aux LSP de routage de segments configurés de façon statique ou aux LSP de routage de segments de tout autre client.

  • La configuration fournie par PCEP a priorité sur la configuration des modèles.

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

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

Cet exemple montre comment configurer des chemins de commuté d’étiquettes (LSP) de routage de segments statiques dans MPLS réseaux. Cette configuration permet d’augmenter l’évolutivité des MPLS réseaux.

Conditions préalables

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

  • Sept MX Series de Plates-formes de routage universelles

  • 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 d’entrée d’un tunnel de routage de segments statique non-statique, en configurant l’énoncé au niveau de segment-list [edit protocols source-packet-routing] la hiérarchie. Vous pouvez configurer le tunnel de routage de segments en configurant source-routing-path l’énoncé au [edit protocols source-packet-routing] niveau hiérarchique. Le tunnel de routage de segments possède une adresse de destination, un ou plusieurs chemins principaux et, éventuellement, des chemins secondaires qui font référence à la liste de segments. Chaque liste de segments se compose d’une séquence de sauts. Dans le cas d’un tunnel de routage de segments statique non statique, le premier saut de la liste de segments spécifie une adresse IP immédiate à côté du saut suivant, et le deuxième saut au saut Nth spécifie les étiquettes SID correspondant à la liaison ou au nœud traverse le chemin. La route jusqu’à la destination du tunnel de routage de segments est installée dans un tableau inet.3.

Topologie

Dans cet exemple, configurez le VPN de couche 3 sur les routeurs de périphérie du fournisseur PE1 et PE5. Configurez le protocole MPLS sur tous les routeurs. Le tunnel de routage de segments est configuré du routeur PE1 au routeur PE5 avec un chemin principal configuré sur le routeur PE1 et le routeur PE5. Le routeur PE1 est également configuré avec un chemin secondaire pour protéger les chemins. Les routeurs de transit PE2 à PE4 sont configurés avec des labels SID d’adjacence avec pop et interface sortante.

Figure 10 : Chemin de commutage d’étiquettes de routage de segments statiqueChemin de commutage d’étiquettes de routage de segments statique

Configuration

CLI configuration rapide

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

PE1

PE2

PE3

PE4

PE5

CE1

CE2

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

L’exemple suivant nécessite de naviguer dans différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation du CLI, consultez le guide de l’CLI en mode de configuration dans CLI’utilisateur.

Pour configurer l’équipement PE1:

  1. Configurez les interfaces.

  2. Configurez le nombre et les options du système autonomes pour contrôler les options de routage de routage de paquets.

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

  4. Configurez le type de groupe de pairs, l’adresse locale, la famille de protocoles pour NLRIS dans les mises à jour et l’adresse IP d’un voisin pour le groupe de pairs.

  5. Configurez les interfaces de zone de protocole.

  6. Configurez l’adresse IPv4 et les étiquettes des chemins principaux et secondaires pour les stratégies de routage des paquets source (TE) du routage des paquets source de protocole (SPRING).

  7. Configurer l’adresse IPv4 de destination, l’étiquette SID contraignante, le chemin de routage principal et secondaire pour le protocole SPRING.

  8. Configurer les options de stratégie.

  9. Configurez BGP les informations de la communauté.

  10. Configurer l’instance de routage VRF1 avec le type, l’interface, l’ident rapportateur de routeur, l’importation, l’exportation et l’étiquette de tableau VRF. Configurer la stratégie d’exportation et l’interface de zone pour les protocoles OSPF.

Résultats

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

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

L’exemple suivant nécessite de naviguer dans différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation du CLI, consultez le guide de l’CLI en mode de configuration dans CLI’utilisateur.

  1. Configurez les interfaces.

  2. Configurez le LSP statique pour les protocoles MPLS.

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

  4. Configurez des interfaces pour les protocoles OSPF.

Résultats

Depuis le mode de configuration sur le routeur PE2, confirmez votre configuration en entrant les show interfaces commandes show protocols et les commandes. 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érifier 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érifier l’entrée par route de la table de routage inet.3 du routeur PE1.

Action

À partir du mode opérationnel, saisissez la show route table inet.3 commande.

Sens

Le résultat affiche les routes d’entrée des tunnels de routage de segments.

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

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

Action

À partir du mode opérationnel, saisissez la show route table mpls.0 commande.

Sens

Le résultat affiche les labels SID des tunnels de routage de segments.

Vérification du trafic SPRING LSP de routeur PE1
But

Vérifier le trafic SPRING conçu pour les LSP sur les routeurs d’entrée.

Action

À partir du mode opérationnel, saisissez la show spring-traffic-engineering overview commande.

Sens

La sortie affiche la présentation des LSP conçus pour le trafic SPRING sur le routeur d’entrée.

Vérification du trafic SPRING LSP ingénieur sur le routeur d’entrée du routeur PE1
But

Vérifier le trafic SPRING conçu pour les LSP sur le routeur d’entrée.

Action

À partir du mode opérationnel, saisissez la show spring-traffic-engineering lsp detail commande.

Sens

La sortie affiche les détails du trafic SPRING conçu pour les LSP sur le routeur d’entrée

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

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

Action

À partir du mode opérationnel, saisissez la show route table mpls.0 commande.

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

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

Action

À partir du mode opérationnel, saisissez la show mpls static-lsp commande.

Sens

La sortie affiche l’état de la MPLS les segments LSP du routeur PE2.

Activer CSPF distribué pour les LSP de routage de segments

Avant Junos OS version 19.2R1S1, pour les ingénieries de trafic des chemins de routage de segments, vous pouviez soit configurer des chemins statiques, soit utiliser des chemins informatiques à partir d’un contrôleur externe. Avec 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 d’entrée 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 mesures (ingénierie du trafic ou IGP). Les LSP sont utilisés pour utiliser les chemins ECMP disponibles vers la destination, la compression de la pile de label de routage de segments activée ou désactivée.

Contraintes de calcul CSPF distribuées

Lorsque toutes les contraintes configurées sont satisfaites, les chemins LSP de routage de segments sont atteints.

La fonctionnalité de calcul CSPF distribuée prend en charge le sous-ensemble suivant des contraintes spécifiées dans le projet Internet, draft-ietf-spring-segment-routing-policy-03.txt, Stratégie de routage de segmentspour les ingénieries de trafic:

  • Inclusion et exclusion des groupes administratifs.

  • Inclusion d’adresses IP de sauts lâches ou strictes.

    Remarque :

    Vous pouvez spécifier uniquement les ID de routeur en cas de contraintes de saut lâches ou strictes. Les labels et autres adresses IP ne peuvent pas être spécifiés comme des contraintes de saut lâches ou strictes dans Junos OS version 19.2R1-S1.

  • Nombre maximal d’ID de segments (SID) dans la liste de segments.

  • Nombre maximum de listes de segments par chemin de routage de segments candidat.

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 (Inter Domain Segment Routing Traffic Engineering, SRTE).

  • Interfaces en nombre non-numéro.

  • Protocoles de routage multiples activés en même OSPF, ISIS et BGP-LS.

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

  • Inclure et exclure les adresses IP d’interface en tant que contraintes.

Algorithme de calcul CSPF distribué

La fonction de calcul CSPF distribuée pour les LSP de routage de segments utilise l’algorithme de compression de la pile d’étiquettes avec CSPF.

Compression de la pile d’étiquettes activée

Une pile de label compressée représente un ensemble de chemins d’une source à une destination. Il se compose généralement de SID de nœud et de SID d’adjacence. Lorsque la compression de la pile d’étiquettes est activée, le résultat du calcul est un ensemble de chemins qui optimisent l’ECMP vers 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-chemins avec compression de la pile d’étiquettes désactivé trouve des listes de segments N jusqu’à leur destination, où:

  • Le coût de toutes les listes de segments est égal à celui de la mesure d’ingénierie de trafic la plus courte pour atteindre sa destination.

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

  • La valeur de N est le nombre maximal de listes de segments autorisées pour le chemin de candidature 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 SRTE contient tous les liens, nodes, préfixes et caractéristiques, indépendamment du fait que les techniques de trafic sont activées dans ces nodes 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 IGP d’état de liaison de tous les domaines dont le nœud informatique a pu tirer des enseignements.

Configuration des contraintes de calcul CSPF distribuées

Vous pouvez utiliser un profil informatique pour grouper 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 primaires et secondaires.

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

La configuration des contraintes de calcul pris en charge est la suivante:

  • Administrative groups

    Vous pouvez configurer des groupes d’administrateurs sous [edit protocols mpls] le niveau hiérarchique. Junos OS applique la configuration de groupe administratif aux interfaces SRTE (Segment Routing Traffic Engineering).

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

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

    • include-all— Indique que toute liaison avec tous les groupes d’administration configurés dans la liste est acceptable pour le chemin à traverser.

    • exclude— Indique que toute liaison qui ne comprend aucun des groupes d’administration configurés dans la liste est acceptable pour le chemin à traverser.

  • Explicit path

    Vous pouvez spécifier une série d’ID de routeur dans le profil de calcul comme contrainte pour l’informatique des chemins de candidature SRTE. Chaque saut doit être une adresse IPv4 et peut être d’un type strict ou lâche. Si le type de saut n’est pas configuré, une procédure stricte est utilisée. Vous devez inclure compute l’option dans l’énoncé de la liste de segments lors de la spécification de 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 passerelle de sauts suivants avec un poids actif. Ces chemins sont le fruit d’un calcul de chemin avec ou sans compression.

    Vous pouvez configurer cet attribut en utilisant l’option sous l’instruction maximum-computed-segment-lists maximum-computed-segment-lists de configuration de profil de calcul. Cette configuration détermine le nombre maximum de listes de segments de ce type calculées pour un LSP principal et secondaire donné.

  • Maximum segment list depth

    Le paramètre de calcul de détail maximal de la liste de segments garantit que parmi les chemins ECMP qui répondent à toutes les autres contraintes, telles que les groupes administratifs, seuls les chemins pertoriant des listes de segments de moins ou d’égale à la profondeur maximale de la liste de segments sont utilisés. Lorsque vous configurez ce paramètre en tant que contrainte sous le profil informatique, il remplace la configuration sous le niveau hiérarchique, le maximum-segment-list-depth[edit protocols source-packet-routing] cas contraire.

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

  • Protected or unprotected adjacency SIDs

    Vous pouvez configurer un SID d’adjacence protégé ou compute-profile non protégé en tant que contrainte sous le profil informatique afin d’éviter les liens avec le type de SID spécifié.

  • Metric type

    Vous pouvez spécifier le type de mesure du lien à utiliser pour le calcul. Par défaut, les LSP TE SR-TE utiliser les indicateurs techniques du trafic des liaisons pour le calcul. La métrique d’ingénierie du trafic pour les liaisons est annoncée par les extensions des ingénieries de trafic IGP protocoles spécifiques. Cependant, vous pouvez également choisir d’utiliser la IGP de calcul en utilisant la configuration de type métrique dans le profil de calcul.

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

Calcul CSPF distribué

Les chemins de candidature au SRTE sont calculés localement afin de répondre aux contraintes configurées. Lorsque la compression de la pile d’étiquettes est désactivée, le résultat du calcul CSPF multi-chemin est un ensemble de piles SID d’adjacence. Lorsque la compression de la pile d’étiquettes est activée, il en résulte un ensemble de piles de label compressées (composées de SID et de SID de nœuds adjacents).

Lorsque les chemins secondaires sont calculés, les liaisons, les nodes et les SRLG pris par les chemins principaux ne sont pas évités pour le calcul. Pour plus d’informations sur les chemins primaires et secondaires, consultez configuring Primary and Secondary LSP.

Pour tous les LSP ayant échoué dans le calcul, le calcul est retérigé à mesure que la base de données des techniques du trafic (TED) change.

Interaction entre le calcul CSPF distribué et les fonctionnalités SRTE

Poids associés aux chemins d’une stratégie SRTE

Vous pouvez configurer des poids par rapport aux chemins SRTE statiques et informatiques, ce qui contribue aux sauts suivants de la route. Toutefois, un chemin unique activé par calcul peut entraîner plusieurs listes de segments. Ces listes de segments informatiques sont entre elles traitées comme ECMP. Vous pouvez attribuer des poids ECMP hiérarchiques à ces segments, compte tenu des poids attribués à chacun des configurables.

BFD - Détection de la convivialité

Vous pouvez configurer la détection de la liveliness BFD pour les chemins informatiques principaux ou secondaires. Chaque chemin informatique principal ou secondaire peut entraîner plusieurs listes de segments: les paramètres BFD configurés en fonction des listes de segments sont appliqués à toutes les listes de segments informatiques. Si tous les chemins principaux actifs s’en baissent, le chemin secondaire pré-programmé (si fourni) devient actif.

inherit-label-nexthops

Il n’est pas nécessaire d’activer la configuration sous la hiérarchie pour les chemins informatiques principaux ou secondaires, car il s’agit inherit-label-nexthops[edit protocols source-packet-routing segment-list segment-list-name] d’un comportement par défaut.

Fonctionnalité d’auto-traduction

Vous pouvez configurer la fonctionnalité d’auto-traduction sur les listes de segments, et les chemins primaires ou secondaires avec la référence de fonctionnalités de traduction automatique de ces listes de segments. D’autre part, les fonctionnalités primaires ou secondaires sur lesquelles la fonctionnalité de calcul est activée ne peuvent pas faire référence à une liste de segments. En conséquence, vous ne pouvez pas activer à la fois la fonctionnalité de calcul et la fonctionnalité d’auto-traduction pour un chemin principal ou secondaire donné. Toutefois, un LSP peut être configuré avec un chemin principal avec un type de calcul et un autre avec un type de traduction automatique.

Configurations d’exemples de calcul CSPF distribués

Exemple 1

Exemple 1:

  • Le chemin principal non informatique fait référence à une liste de segments configurée. Dans cet exemple, la liste de segments configurée static_sl1 référence, qui sert également de nom à ce chemin principal.

  • Un primaire informatique doit avoir un nom configuré, et ce nom ne doit pas référencer une liste de segments configurée. Dans cet exemple, compute_segment1 n’est pas une liste de segments configurée.

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

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

Les poids des sauts suivants du chemin informatique et des sauts suivants statiques sont respectivement de 2 et 3. En supposant que les sauts suivants pour les chemins informatiques sont comp_nh1,comp_nh2et comp_nh3, et que 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 principal et secondaire peuvent être du type informatique et possèdent leurs propres profils informatiques.

Exemple 3

Dans l’exemple 3, lorsque le calcul est mentionné dans un chemin principal ou secondaire, il en résulte un calcul local d’un chemin vers la destination sans contraintes ni autres paramètres pour le calcul.

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

SUMMARY Le CoS CBF (forwarding) et le routage basé sur des stratégies (PBR, également appelés forwarding à base de filtres) peuvent être activés pour les LSP non-segmentés (SR–TE) de routage de segments non-segmentés, afin d’orienter le trafic sélectif vers un chemin SR-TE explicite, afin de mettre en service le trafic en fonction de classes de service ou d’une politique.

CoS de routage basé sur les stratégies et le routage basé sur les stratégies pour la présentation TE SR-TE LSP

Avantages du CoS de routage basé sur les stratégies (CBF) et du routage basé sur les stratégies (PBR) pour les TE SR-TE SR

Avec les CBF et PBR, vous pouvez:

  • Utilisez les combinaisons de chemins SR-TE (SR-TE) pour diriger le trafic des services au cœur du réseau.

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

Sources de chemins de routage de segments qui soutiennent le CBF et le PBR

Les sources de chemin de routage de segments suivantes CoS de routage basée sur des stratégies et le routage basé sur des stratégies:

  • Static SR–TE paths—Chemins de routage source configurés de manière statique qui ont l’ensemble de la pile d’étiquettes configurée de façon statique.

  • PCEP— Provisionation dynamique des chemins de routage source créés sur un contrôleur et téléchargés sur un routeur d’entrée dans un 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—Tunnels créés de manière dynamique via le module dynamic tunnel avec résolution ERO du dernier saut.

  • Auto-translated paths—Chemins de routage source configurés de façon statique qui sont automatiquement traduits.

Considérations pour la configuration des CBF et PBR pour les LSP SR-TE

Rappelez-vous:

  • Le CBF et le PBR sont uniquement activés sur les LSP SR-TE non-sur-s statiques ou dynamiquement configurés.

  • Les configurations CBF et PBR pour les LSP SR-TE peuvent co-exister sur un équipement . l’ordre de configuration détermine le type de routes dans lesquelles ils sont transmis.

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

  • Le forwarding de routes pour CBF basé sur les classes n’est visible que dans le tableau de forwarding et non sur les routes.

  • Le forwarding des routes PBR, basé sur des stratégies, est effectué sur les routes et se voit dans le résultat show route de commande.

Configuration du CoS basé sur le routage basé sur les stratégies et le TE SR-TE LSP

SUMMARY Le CoS CBF (forwarding) et le PBR (policy-based routing), également appelés FBF (forwarding basé sur des filtres), peuvent être utilisés pour orienter le trafic sélectif à l’aide d’un chemin « label-swtiched path » (SR-TE) de routage de segments explicite. Seuls les LSP de routage de segments non insaisirables dont le saut suivant est configuré en tant que label du premier saut ou prise en charge des adresses IP CBF et PBR .

Avant de commencer

  • Vous devez être en Junos OS version 20.1 et ultérieures pour activer les CBF et PBR pour les LSP SR-TE non-différentes.

  • Configurez les interfaces de l’équipement et assurez-vous que ces derniers 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, faites les choses suivantes:

  1. Définissez la liste de segments avec les paramètres d’étiquettes.

    Quelques chiffres clés :

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

    Quelques chiffres clés :

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

Pour configurer le CBF, faites les choses suivantes

  1. Définissez des classificateurs DSCP (Differentiated Services Code Point) pour gérer les paquets IPv4 entrants, les classes de transfert et les valeurs d’option.

    Quelques chiffres clés :

  2. Définir des classes de transfert (CFC) pour le regroupement des paquets pour la transmission et attribuer des paquets aux files d’attente de sortie.

    Quelques chiffres clés :

  3. Attribuez les classificateurs configurés aux interfaces de l’équipement.

    Quelques chiffres clés :

  4. Définissez CoS options de stratégie de forwarding basées sur le saut suivant avec LSP en tant que SR-TE LSP.

    Quelques chiffres clés :

  5. Discard traffic that does not meet any forwarding class in the next-hop map.

    Quelques chiffres clés :

  6. Configurez une déclaration de stratégie qui spécifie que les routes correspondant au filtre de route sont soumises au mappage du saut suivant CoS par le nom de la carte.

    Quelques chiffres clés :

  7. Appliquez la stratégie aux routes en cours d’exportation depuis la table de routage vers la table de routage. Cela permet d’obtenir une CBF pour les TE SR-TE.

    Quelques chiffres clés :

  8. Valider 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 le CBF, le forwarding des routes basé sur la classe n’est visible que dans la table de forwarding, contrairement au PBR, où les routes filtrées sont visibles dans le résultat show route de commande.

Pour configurer le PBR, faites ce qui suit

  1. Configurer une déclaration de stratégie qui spécifie que les routes correspondant au protocole et au filtre de route sont soumises au saut suivant du LSP ou que la charge est équilibrer en tant qu’ECMP (Equal-Cost Multipath) dans la table de forwarding.

    Quelques chiffres clés :

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

    Remarque :

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

  3. Appliquez la stratégie aux routes en cours d’exportation depuis la table de routage vers la table de routage. Cela permet d’activer le PBR pour les LSP SR-TE.

    Quelques chiffres clés :

  4. Valider la configuration.

Verify PBR Configuration

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

La sortie affiche tous les sauts suivants pour le préfixe de destination, 4.0.0.1. Les expanded-nh extensive options s’affichent avec les sauts suivants filtrés dans le Krt_inh champ de sortie.

Pour le PBR, la commande de sortie s’appuie sur un filtrage des routes basé sur show route des stratégies.

Tableau de l'historique des versions
Version
Description
21.R1
À partir de Junos OS version 21.1R1, Junos OS prend en charge le routage actif sans arrêt (NSR) pour les LSP point à point et point à multipoint basés sur RSVP et PCE.
21.R1
À partir de Junos OS version 21.1R1, Junos OS prend en charge le routage actif sans arrêt (NSR) pour les LSP point à multipoint basés sur RSVP et PCE.
20.2R1
À partir de Junos OS Version 20.2R1, BGP labelé Unicast (BGP-LU) peut résoudre les routes IPv4 ou IPv6 sur les ingénieries de trafic de routage de segments (SR-TE) pour les gammes d’adresses IPv4 et IPv6.
19.4R1
Vous pouvez associer un ou plusieurs flux multicast MVPN (S,G) à un chemin de commuté d’étiquettes (LSP) PCE lancé de manière dynamique.
19.4R1
Vous pouvez configurer un modèle de tunnel pour les LSP de routage de segments lancés par PCE afin de transmettre deux paramètres supplémentaires pour ces LSP: la détection de routage bidirectionnelle (BFD) et la tunnelisation LDP.
19.1R1
À partir de Junos OS version 19.1R1, une fonction de vérification de validation est mise en place pour s’assurer que toutes les listes de segments contribuant aux routes de validation disposent du label minimum pour tous les sauts.
19.1R1
À partir de Junos OS Version 19.1R1, cette exigence ne s’applique pas, car le premier saut des LSP statiques non-pré-statiques prend désormais en charge les labels SID, en plus des adresses IP. Grâce au premier label de saut, MPLS reroutage rapide (FRR) et multi-chemin à coût égal pondéré sont activés pour résoudre les LSP de routage de segments statiques non-insaisirables, semblables aux LSP statiques statiques.
18.2R1
À partir de Junos OS Version 18.2R1, les LSP de routage de segments configurés de façon statique sur l’équipement d’entrée sont signalés à l’élément de calcul de chemin (PCE) par le biais d’une session PCEP (Path Computation Element Protocol).
17.2R1
À partir Junos OS version 17.2, deux nouveaux types de calcul de chemin sont introduits pour les LSP contrôlés par external cspf PCE: local cspf et no cspf .
16.1
À partir Junos OS version 16.1, vous pouvez sécuriser une session PCEP à l’aide de l’authentification TCP-MD5 au titre du RFC 5440.
16.1
Junos OS version 16.1 présente la fonctionnalité de sécurisation d’une session PCEP à l’aide de l’authentification TCP-MD5 au titre du RFC 5440.
14.2R4
Depuis le Junos OS version 14.2R4, la prise en charge de la bande passante automatique est prise en charge pour les LSP contrôlés par PCE.