Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuration LSP de routage de segments

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

Avant la version 19.2R1S1 de Junos OS, pour les aspects techniques du trafic des chemins de routage de segments, vous pouviez configurer explicitement des chemins statiques ou utiliser des chemins informatiques à partir d’un contrôleur externe. Grâce à la fonctionnalité CSPF (Constrained Shortest Path First) distribuée pour le routage de segments LSP, vous pouvez calculer localement un LSP de routage de segments sur l’équipement entrant en fonction des contraintes que vous avez configurées. Grâce à cette fonctionnalité, les LSP sont optimisés en fonction des contraintes configurées et du type de métrique (aspects techniques du trafic ou IGP). Les LSP sont calculés pour utiliser les chemins ECMP disponibles vers la destination, avec la compression de la pile de labels de routage de segments activée ou désactivée.

Contraintes de calcul CSPF distribuées

Les chemins LSP de routage de segments sont calculés lorsque toutes les contraintes configurées sont satisfaites.

La fonction de calcul CSPF distribuée prend en charge le sous-ensemble suivant de contraintes spécifiées dans Internet draft, draft-ietf-spring-segment-routing-policy-03.txt, Stratégie de routage de segments pour les aspects techniques du trafic :

  • L’inclusion et l’exclusion des groupes administratifs.

  • L’inclusion d’adresses IP en sauts lâches ou strictes.

    Remarque :

    Vous pouvez spécifier uniquement les ID de routeur dans les contraintes de saut lâches ou strictes. Junos OS Version 19.2R1-S1 ne peut pas spécifier d’étiquettes et d’autres adresses IP comme étant des contraintes de saut lâches ou strictes.

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

  • Nombre maximum de listes de segments par chemin de routage de segments par 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 SR-TE (Inter Domain Segment Routing Traffic Engineering).

  • Interfaces non numérotées.

  • Plusieurs protocoles de routage comme OSPF, ISIS et BGP-LS, activés simultanément.

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

  • Inclure et exclure les adresses IP d’interface comme contraintes.

Algorithme de calcul CSPF distribué

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

Compression de la pile d’étiquettes activée

Une pile de labels comprimées 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 maximisent 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 multipath avec compression de pile d’étiquettes désactivé permet de retrouver les listes de segments jusqu’à N leur destination, où :

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

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

  • La valeur est N le nombre maximum de listes de segments autorisés 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 SR-TE comporte tous les liens, nœuds, préfixes et leurs caractéristiques, que les aspects techniques du trafic soient activés ou non dans ces nœuds publicitaires. En d’autres termes, il s’agit de l’union de la base de données d’ingénierie du trafic (TED) et de la base de données d’état de liaison IGP de tous les domaines que le nœud de calcul a appris. Par conséquent, pour que CSPF fonctionne, vous devez inclure l’instruction igp-topology au niveau de la [edit protocols isis traffic-engineering] hiérarchie.

Configuration des contraintes de calcul CSPF distribuées

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

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

La configuration pour les contraintes de calcul prises en charge comprend les éléments suivants :

  • Administrative groups

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

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

    • include-any— Spécifie que toute liaison avec au moins l’un des groupes administratifs configurés dans la liste est acceptable pour le chemin à parcourir.

    • include-all— Spécifie que toute liaison avec tous les groupes administratifs configurés dans la liste est acceptable pour le chemin à parcourir.

    • exclude— Spécifie que toute liaison ne comprenant aucun des groupes administratifs configurés dans la liste est acceptable pour le chemin à parcourir.

  • Explicit path

    Vous pouvez spécifier une série d’ID de routeur dans le profil de calcul comme contrainte pour le calcul des chemins de candidature SR-TE . Chaque saut doit être une adresse IPv4 et peut être de type strict ou lâche. Si le type de saut n’est pas configuré, il est utilisé de manière stricte. Vous devez inclure l’option compute dans l’instruction de liste de segments lorsque vous spécifiez la contrainte de chemin explicite.

  • Maximum number of segment lists (ECMP paths)

    Vous pouvez associer un chemin de candidature à un certain nombre de listes de segments dynamiques. Les chemins sont des chemins ECMP, où chaque liste de segments se traduit par une passerelle à sauts suivante avec un poids actif. Ces chemins sont le résultat d’un calcul de chemin avec ou sans compression.

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

  • Maximum segment list depth

    Les paramètres de calcul de profondeur maximum de la liste de segments garantissent que parmi les chemins ECMP qui répondent à toutes les autres contraintes telles que les groupes d’administration, seuls les chemins ayant des listes de segments inférieures ou égales à la profondeur maximale de la liste de segments sont utilisés. Lorsque vous configurez ce paramètre comme contrainte dans le profil de calcul, il remplace la maximum-segment-list-depth configuration au [edit protocols source-packet-routing] niveau hiérarchique, le cas échéant.

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

  • Protected or unprotected adjacency SIDs

    Vous pouvez configurer le SID d’adjacence protégé ou non protégé comme contrainte dans le profil de calcul afin d’éviter les liens avec le type SID spécifié.

  • Metric type

    Vous pouvez spécifier le type de mesure sur la liaison à utiliser pour le calcul. Par défaut, les LSP SR-TE utilisent les mesures d’ingénierie du trafic des liaisons pour le calcul. La mesure de l’ingénierie du trafic pour les liaisons est annoncée par les extensions des aspects techniques du trafic des protocoles IGP. Toutefois, vous pouvez également choisir d’utiliser la métrique IGP pour le calcul à l’aide de la configuration de type métrique dans le profil de calcul.

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

Calcul CSPF distribué

Les chemins de candidature au sr-TE 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 de calcul CSPF multi-chemin est un ensemble de piles SID d’adjacence. Lorsque la compression de la pile d’étiquettes est activée, le résultat est un ensemble de piles d’étiquettes comprimées (composées de SID et de SID de nœuds adjacents).

Lorsque les chemins secondaires sont calculés, les liaisons, nœuds et SRLG empruntés par les chemins principaux ne sont pas évités pour le calcul. Pour plus d’informations sur les chemins primaires et secondaires, consultez Configuration des LSP primaires et secondaires.

Pour tous les LSP ayant obtenu un résultat de calcul infructueux, le calcul est retrié sous la forme de modifications de la base de données des aspects techniques du trafic (TED).

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

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

Vous pouvez configurer des poids par rapport aux chemins SR-TE statiques et informatiques, qui contribuent aux sauts suivants de la route. Toutefois, un chemin unique avec l’activation du calcul peut entraîner plusieurs listes de segments. Ces listes de segments informatiques sont traitées en tant qu’ECMP entre elles. Vous pouvez attribuer des pondérations ECMP hiérarchiques à ces segments, compte tenu des poids attribués à chacun des primaires configurées.

Détection de la liaison en direct BFD

Vous pouvez configurer la détection en direct BFD pour les chemins primaires ou secondaires. Chaque chemin principal ou secondaire peut entraîner plusieurs listes de segments. Par conséquent, les paramètres BFD configurés par rapport aux listes de segments sont appliqués à toutes les listes de segments informatiques. Si tous les chemins principaux actifs tombent en panne, le chemin secondaire préprogramé (s’il est fourni) devient actif.

inherit-label-nexthops

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

Fonctionnalité de traduction automatique

Vous pouvez configurer la fonctionnalité de traduction automatique dans les listes de segments, et les chemins principaux ou secondaires avec la fonction de traduction automatique de ces listes de segments. En revanche, le principal ou le secondaire sur lequel la fonction de calcul est activée ne peut 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 fonction de traduction automatique pour un chemin principal ou secondaire donné. Toutefois, vous pouvez avoir un LSP configuré avec un chemin principal avec type de calcul et un autre avec type de traduction automatique.

Configurations d’exemples de calcul CSPF distribué

Exemple 1

Dans l’exemple 1,

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

  • Un serveur principal doit avoir un nom configuré, et ce nom ne doit pas faire référence à une liste de segments configurée. Dans cet exemple, compute_segment1 il ne s’agit pas d’une liste de segments configurée.

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

  • Le compute_profile_red profil de calcul comprend une liste de segments de type compute, utilisée pour spécifier la contrainte explicite de chemin pour le 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 , et comp_nh3que le saut suivant pour le chemin statique est static_nh, les poids sont appliqués comme suit :

Saut suivant

Poids

comp_nh1

2

comp_nh2

2

comp_nh3

2

static_nh

9

Exemple 2

Dans l’exemple 2, les chemins primaires et secondaires peuvent être de type calcul et peuvent avoir leurs propres profils de calcul.

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 aucune contrainte ni autre paramètre pour le calcul.

Routage de segments statique Chemin de commutation d’étiquettes

L’architecture de routage de segments permet aux équipements entrants d’un réseau central d’orienter le trafic via des chemins explicites. Vous pouvez configurer ces chemins à l’aide de listes de segments pour définir les chemins que le trafic entrant doit emprunter. Le trafic entrant peut être étiqueté ou trafic IP, ce qui fait que le transfert au niveau de l’équipement entrant est soit un échange d’étiquettes, soit une recherche basée sur la destination.

Comprendre le routage de segments statique LSP dans les réseaux MPLS

Le routage de paquets source ou routage de segments est une architecture de plan de contrôle qui permet à un routeur d’entrée d’orienter un paquet à travers un ensemble spécifique de nœuds et de liaisons du réseau, sans compter sur les nœuds intermédiaires du réseau pour déterminer le chemin réel qu’il doit suivre.

Introduction aux LSP de routage de segments

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

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

Dynamic segment routing LSPs— Lorsqu’un LSP de routage de segments est créé par un contrôleur externe et téléchargé vers un équipement entrant via des extensions PCEP (Path Computation Element Protocol), ou à partir d’une stratégie de routage de segmentS BGP via des extensions de routage de segmentS BGP, le LSP est provisionné de manière dynamique. La liste de segments du LSP de routage de segments dynamique est incluse dans l’objet de route explicite (ERO) PCEP ou dans la stratégie de routage de segments BGP du LSP.

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

Un LSP de routage de segments statique peut en outre être classé comme LSP de couleur ou non en fonction de la configuration de l’instruction color au niveau de la [edit protocols source-packet-routing source-routing-path lsp-name] hiérarchie.

Par exemple :

[edit protocols]
    source-packet-routing {
    source-routing-path lsp_name {
        to destination_address;
        color color_value;
        binding-sid binding-label;
        primary segment_list_1_name weight weight;
        ...
        primary segment_list_n_name weight weight;
        secondary segment_list_n_name;
        sr-preference sr_preference_value;
    }
}

Ici, chaque instruction 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 LSP sur les routeurs de transit. Par conséquent, il n’est plus nécessaire de provisionner et de maintenir l’état de transfert LSP dans le cœur.

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

Routage de segments statique de couleur LSP

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

Comprendre les LSP de routage de segments statiques de couleur

À l’instar d’une stratégie de routage de segments BGP, la route d’entrée du LSP de couleur est installée dans les tables de routage, inet6color.0 avec destincation-ip-address, color comme clé de mappage du inetcolor.0 trafic IP.

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

Liste de segments de LSP de routage de segments de couleur

Les LSP de routage statique de segments de couleur prennent déjà en charge le mode d’étiquette du premier saut pour résoudre un LSP. Toutefois, le mode IP du premier saut n’est pas pris en charge pour les LSP de routage de segments de couleur. À partir de Junos OS Version 19.1R1, une fonctionnalité de vérification de validation est mise en place afin de s’assurer que toutes les listes de segments contribuant aux routes colorées ont le label minimum présent pour tous les sauts. Si cette exigence n’est pas satisfaite, la validation est bloquée.

Routage de segments statique non de couleur LSP

Un LSP de routage de segments statique qui est configuré sans l’instruction color est un LSP non coloré. À l’instar des tunnels de routage de segments PCEP, le routage entrant est installé dans les inet.3 tables de routage.inet6.3

Junos OS prend en charge les LSP de routage de segments statiques non colorés sur les routeurs d’entrant. Vous pouvez provisionner un routage de segments statique non coloré en configurant un chemin de routage source et une ou plusieurs listes de segments. Ces listes de segments peuvent être utilisées par plusieurs LSP de routage de segments non colorés.

Comprendre les LSP de routage de segments non colorés

Le LSP de routage de segments non coloré a un nom unique et une adresse IP de destination. Une route entrante vers la destination est installée dans la table de routage inet.3 avec une préférence par défaut de 8 et une métrique de 1. Cette route permet d’mapper les services non colorés au LSP de routage de segments de la destination. Si le routage de segments non de couleur LSP ne nécessite pas de route d’entrant, alors la route d’entrante peut être désactivée. Une LSP de routage de segments non colorée utilise un label SID de liaison 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 ensuite utilisé pour construire d’autres LSP de routage de segments de manière hiérarchique. Le transit du label SID de liaison, par défaut, a une préférence de 8 et une métrique de 1.

À partir de Junos OS Version 18.2R1, les LSP de routage de segments non colorés configurés de manière statique sur l’équipement entrant sont signalés à l’élément de calcul de chemin (PCE) par le biais d’une session PCEP (Path Computation Element Protocol). Ces LSP de routage de segments non colorés peuvent avoir des étiquettes SID (Binding Service Identifier) qui leur sont associées. Grâce à cette fonctionnalité, l’ordinateur peut utiliser ce label SID de liaison dans la pile de labels pour provisionner des chemins LSP de routage de segments initiés par PCE.

Un LSP de routage de segments non coloré peut avoir au maximum 8 chemins principaux. S’il existe plusieurs chemins principaux opérationnels, le moteur de transfert de paquets (PFE) distribue le trafic sur les chemins en fonction des facteurs d’équilibrage de charge tels que le poids configuré sur le chemin. Il s’agit d’un chemin multi-chemin à coût égal si aucun des chemins n’a de poids configuré sur eux ou ECMP pondéré si au moins un des chemins a un poids non nul configuré sur les chemins. Dans les deux cas, lorsqu’un ou plusieurs chemins tombent en panne, le PFE rééquilibre le trafic sur les autres chemins, ce qui conduit automatiquement à la protection des chemins. Un routage de segments non coloré LSP peut avoir un chemin secondaire pour une protection contre les chemins dédiés. En cas de défaillance d’un chemin principal, le PFE rééquilibre le trafic vers les autres chemins principaux fonctionnels. Dans le cas contraire, le PFE commute le trafic vers le chemin de secours, ce qui permet de protéger le chemin. Une LSP de routage de segments non colorée peut spécifier une mesure au niveau [edit protocols source-packet-routing source-routing-path lsp-name] de ses routes entrantes et SID de liaison. Plusieurs LSP de routage de segments non colorés ont la même adresse de destination qui contribue au saut suivant du routage entrant.

Plusieurs LSP de routage de segments non colorés ont la même adresse de destination qui contribue au saut suivant du routage entrant. 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 a la meilleure préférence de tous ces LSP de routage de segments. Toutefois, le nombre maximum de passerelles que le saut suivant peut contenir ne peut pas dépasser la limite rpd multi-chemin, qui est de 128 par défaut. Des chemins supplémentaires sont élagués, d’abord des chemins secondaires, puis des chemins primaires. Ces LSP de routage de segments peuvent désigner plusieurs fois une liste de segments comme des chemins primaires ou secondaires. Dans ce cas, il existe plusieurs passerelles, chacune ayant un ID de tunnel LSP unique de routage de segments. Ces passerelles sont distinctes, bien qu’elles disposent d’une pile et d’une interface d’étiquettes sortantes identiques. Une LSP de routage de segments non colorée et un LSP de routage de segments de couleur peuvent également avoir la même adresse de destination. Cependant, elles correspondent à différentes adresses de destination pour les routes d’arrivée, car l’adresse de destination du LSP de routage de segments de couleur est construite à la fois avec son adresse de destination et sa couleur.

Remarque :

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

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

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

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

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

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

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

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

Lorsque l’instruction inherit-label-nexthops est configurée globalement, elle a préséance sur la configuration de niveau de la liste de segments et la inherit-label-nexthops configuration est appliquée à toutes les listes de segments. Lorsque l’instruction inherit-label-nexthops n’est pas configurée globalement, seules les listes de segments avec des étiquettes et une adresse IP présentes dans le premier saut, et configurées avec inherit-label-nexthops l’instruction, sont résolues à l’aide de labels SID.

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

Tableau 1 décrit le mode de résolution LSP de routage de segments en fonction de la spécification du premier saut.

Tableau 1 : Résolution LSP statique non colorée basée sur les spécifications du premier saut

Spécification du premier saut

Mode de résolution LSP

Adresse IP uniquement

Par exemple :

segment-list path-1 {
    hop-1 ip-address 172.16.12.2;
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

La liste de segments est résolue à l’aide de l’adresse IP.

SID uniquement

Par exemple :

segment-list path-2 {
    hop-1 label 1000011;
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

La liste de segments est résolue à l’aide des étiquettes SID.

Adresse IP et SID (sans la inherit-label-nexthops configuration)

Par exemple :

segment-list path-3 {
    hop1 {
        label 801006;
        ip-address 172.16.1.2;
    }
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

Par défaut, la liste de segments est résolue à l’aide d’une adresse IP.

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

Par exemple :

segment-list path-3 {
    inherit-label-nexthops;
    hop1 {
        label 801006;
        ip-address 172.16.1.2;
    }
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

La liste de segments est résolue à l’aide des étiquettes SID.

Vous pouvez utiliser cette show route ip-address protocol spring-te active-path table inet.3 commande pour afficher les LSP non colorées de routage de segments conçues pour le trafic et disposant de plusieurs listes de segments dans la table de routage inet.3.

Par exemple :

Remarque :

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

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

    Par exemple :

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

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

    Par exemple :

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

Provisionnement LSP de routage de segments statique

Le provisionnement de segments est effectué par routeur. Pour un segment donné sur un routeur, un label SID (Unique Service Identifier) est attribué à partir d’un pool d’étiquettes souhaité qui peut provenir du pool d’étiquettes dynamique pour un label SID d’adjacence ou du bloc global de routage de segments (SRGB) pour un PRÉFIXE SID ou SID de nœud. Le label SID d’adjacence peut être alloué de manière dynamique, c’est-à-dire le comportement par défaut, ou être attribué à partir d’un pool d’étiquettes statique local (SRLB). Un routage pour le label SID est ensuite installé dans la table mpls.0.

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

Limites LSP de routage de segments statique

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

  • Le assemblage LSP de routage de segments est en fait effectué au niveau du chemin. Si une LSP de routage de segments non colorée comporte plusieurs chemins qui se trouvent dans plusieurs listes de segments, chaque chemin peut être raccordé indépendamment à un autre LSP de routage de segments non coloré au niveau d’un point de assemblage. Une LSP de routage de segments non colorée dédiée au assemblage peut désactiver l’installation du routage entrant en configurant l’instruction no-ingress au [edit protocols source-packet-routing source-routing-path lsp-name] niveau de la hiérarchie.

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

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

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

Création dynamique de LSP de routage de segments

Dans les réseaux de routage de segments où chaque équipement PE (périphérie du fournisseur) est connecté à tous les autres équipements PE, une grande quantité de configuration est nécessaire pour configurer les chemins de commutation d’étiquettes (LSP) de routage de segments, bien que seuls quelques chemins SR-TE (Routage de segments) puissent être utilisés. Vous pouvez activer la création dynamique BGP-trigerred 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 permettant la création dynamique de LSP de routage de segments, vous devez inclure l’instruction spring-te dans la [edit routing-options dynamic-tunnels] hiérarchie.

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

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

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

Lorsque les préfixes BGP sont affectés à la communauté de couleurs, ils sont initialement résolus via la stratégie catch-all-route-for-that-particular-color, et à son tour, le modèle SR-TE sur lequel le préfixe BGP doit être résolu est identifié. Le SID de destination est ensuite dérivé de l’attribut du saut suivant du préfixe de la charge utile BGP. Par exemple, si le saut suivant du préfixe de la charge utile BGP est une adresse IP qui appartient à l’équipement A, alors le SID de nœud de l’équipement A est pris et un label correspondant est préparé et transféré vers le bas de la pile. Le préfixe de la charge utile BGP est résolu en mode couleur uniquement, où le SID de nœud de l’équipement A se trouve au bas de la pile d’étiquettes finale, et les étiquettes de chemin SR-TE sont superposées.

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

Pour résoudre un réseau de destination de couleur, la couleur doit comporter un mappage de modèle valide, soit vers une couleur spécifique, soit via le color-any modèle. Sans mappage valide, le tunnel n’est pas créé et la demande de route BGP de résolution n’est pas résolue.

Résolution des LSP de routage de segments dynamiques sans couleur

Les routes catch-all pour les LSP non colorées sont ajoutées à la table de routage inet.3. La destination du tunnel non colorée doit être configurée dans une autre spring-te configuration avec un seul nom de modèle dans la liste de mappage. Ce nom de modèle est utilisé pour toutes les routes de tunnel correspondant à n’importe quel réseau de destination configuré dans la même spring-te configuration. Ces tunnels sont semblables aux tunnels RSVP dans leur fonctionnalité.

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

Configuration d’exemple LSP de routage de segments dynamique

Le modèle LSP de routage de segments dynamique transporte toujours un chemin partiel. Le dernier nœud de saut EST dérivé automatiquement au moment de la création du tunnel en fonction du SID de nœud d’adresse de saut suivant du protocole (PNH). 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 en fonction du PNH. Les modèles LSP de routage de segments dynamiques ne sont pas communs à un tunnel unique, de sorte qu’un chemin complet ne peut pas être transporté sur celui-ci. Vous pouvez utiliser une liste de segments si un chemin complet doit être utilisé.

LSP de routage de segments dynamique de couleur

Exemple de configuration pour les LSP de routage dynamique de segments de couleur :

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

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

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

  3. BGP prefix to tunnel mapping:

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

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

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

  4. inetcolor.0 tunnel route:

    10. 22.44.55-101/64 --> <next-hop>

    10. 22.44.55-124/64 --> <next-hop>

  5. inetcolor6.0 tunnel route:

    ffff::10. 22.44.55-101/160 --> <next-hop>

    ffff::10. 22.44.55-124/160 --> <next-hop>

LSP de routage de segments dynamique non coloré

Exemple de configuration pour les LSP de routage de segments dynamiques non colorés :

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

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

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

  3. BGP prefix to tunnel mapping:

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

    R1(prefix) -> ffff::10.33.44.55(PNH) Nom du modèle LSP = LSP1 --- 10.33.44.55:dt-srte-tunnel2

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

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

LSP de routage de segments dynamique non résolu

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

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

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

  2. inetcolor6.0 tunnel route: ffff::10.33.44.0 - 0/120 --> RT_NH_TUNNEL ffff::10.1.1.0 - 0 /24 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping: R1 (préfixe) : > tunnel 10.33.44.55-124(PNH) ne sera pas créé. (Modèle introuvable pour la couleur).

Considérations relatives à la configuration de la création dynamique des LSP de routage de segments

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

  • Un modèle peut être affecté avec un objet couleur. Lorsque la configuration de tunnel spring-te dynamique inclut un modèle avec un objet couleur, vous devez également configurer tous les autres modèles avec des objets de couleur. Toutes les destinations sont supposées être colorées dans cette configuration.

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

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

  • Le mappage couleur vers modèle est effectué sur une base unique. Une seule couleur ne peut pas être mappée à plusieurs modèles.

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

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

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

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

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

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

  • VPN de couche 3

  • BGP EVPN

  • Services de stratégie d’exportation

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

  • VPN de couche 3

  • VPN de couche 2

  • Configurations multipath

Comportement avec plusieurs sources de tunnel dans le routage de segments

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

Limites des LSP de routage de segments dynamiques

Les LSP SR-TE dynamiques ne prennent pas en charge les fonctionnalités et fonctionnalités suivantes :

  • Tunnels de routage de segments IPv6.

  • Tunnels statiques.

  • 6PE n’est pas pris en charge.

  • CSPF distribué.

  • la tunnelisation SBFD et LDP n’est pas prise en charge pour les LSP SR-TE dynamiques et dans un modèle.

  • Installez et les routes B-SID dans un modèle.

Mappage basé sur les couleurs des services VPN

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

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

Coloration des services VPN

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

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

  • Par instance de routage.

  • Par groupe BGP.

  • Par voisin BGP.

  • Par préfixe.

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

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

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

  • Stratégie d’importation BGP sur l’équipement entrant.

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

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

Attribution des couleurs sortantes

Dans ce mode, l’équipement sortant (c’est-à-dire l’annonceur du NLRI VPN) est responsable de la coloration du service VPN. Pour activer ce mode, vous pouvez définir une stratégie de routage et l’appliquer à l’instance vrf-exportde routage, à l’exportation de groupe ou aux voisins de groupe du service VPN au niveau de la [edit protocols bgp] hiérarchie. L’NLRI VPN est annoncé par BGP avec la communauté étendue de couleur spécifiée.

Par exemple :

Ou

Remarque :

Lorsque vous appliquez la stratégie de routage en tant que stratégie d’exportation d’un groupe BGP ou d’un voisin BGP, vous devez inclure l’instruction vpn-apply-export au niveau de voisinage BGP, BGP ou BGP pour que la stratégie prenne effet sur le NLRI VPN.

Les stratégies de routage sont appliquées aux NLRIs de préfixe VPN de couche 3, aux NRLIs VPN de couche 2 et aux NLRIs EVPN. La communauté étendue de couleur est héritée de tous les routes VPN, importées et installées dans les VNF cibles sur un ou plusieurs équipements entrants.

Attribution des couleurs entrantes

Dans ce mode, l’équipement entrant (c’est-à-dire le récepteur du NLRI VPN) est responsable de la coloration du service VPN. Pour activer ce mode, vous pouvez définir une stratégie de routage et l’appliquer à l’instance vrf-importde routage, l’importation de groupe ou l’importation de voisins de groupe au niveau de la hiérarchie du [edit protocols bgp] service VPN. Toutes les routes VPN correspondant à la stratégie de routage sont jointes à la communauté étendue de couleur spécifiée.

Par exemple :

Ou

Spécification du mode de mappage de service VPN

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

Par exemple :

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

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

Remarque :

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

Résolution du saut suivant du protocole Color-IP

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

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

Par exemple :

Retour à la résolution du saut suivant du protocole IP

Si un service VPN de couleur ne dispose pas d’une carte de résolution, le service VPN ignore sa couleur et revient à la résolution du protocole IP du saut suivant. Inversement, si un service VPN non coloré dispose d’une carte de résolution qui lui est appliquée, la carte de résolution est ignorée et le service VPN utilise le protocole IP de résolution du saut suivant.

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

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

À partir de Junos OS version 20.2R1, BGP Labeled Unicast (BGP-LU) peut résoudre les routes IPv4 ou IPv6 sur les aspects techniques du routage de segments et du trafic (SR-TE) pour les familles d’adresses IPv4 et IPv6. BGP-LU prend en charge le mappage d’une couleur de communauté BGP et la définition d’un resolution map pour SR-TE. Un protocole de couleur du saut suivant est construit et il est résolu sur un tunnel SR-TE de couleur dans le ou inet6color.0 la inetcolor.0 table. BGP utilise inet.3 et inet6.3 tables pour le mappage non basé sur les couleurs. Cela vous permet de promouvoir les préfixes BGP-LU IPv6 et IPv4 avec une adresse de saut suivant IPv6 dans les réseaux IPv6 uniquement où les routeurs ne disposent pas d’adresses IPv4 configurées. Grâce à cette fonctionnalité, nous prenons actuellement en charge BGP IPv6 LU sur SR-TE avec l’underlay IS-IS.

Dans Figure 1, le contrôleur configure 4 tunnels de couleur dans un réseau central IPv6 configuré avec SR-TE. Chaque tunnel de couleur emprunte un chemin différent vers le routeur de destination D en fonction de la carte de résolution définie. Le contrôleur configure un tunnel SR-TE de couleur vers 2001:db8::3701:2d05 interface dans le routeur D . BGP importe les stratégies pour attribuer une carte de couleur et de résolution au préfixe reçu 2001:db8::3700:6/128. En fonction de la couleur de communauté attribuée, BGP-LU résout le saut suivant de couleur pour le préfixe LU BGP IPv6 en fonction de la stratégie de carte de résolution attribuée.

Figure 1 : BGP IPv6 LU sur IPv6 SR-TE de couleur BGP IPv6 LU sur IPv6 SR-TE de couleur

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

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

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

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

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

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

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

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

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

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

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

  • BGP EVPN

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

  • Résolution du prochain saut du protocole IPv4 et IPv6 de couleur.

  • Base d’informations de routage (également appelée table de routage) repli sur la table de routage LDP LSP dans la table de routage inetcolor.0.

  • SR-TE LSP de couleur.

  • Plates-formes virtuelles.

  • Junos OS 64 bits.

  • Systèmes logiques.

  • BGP : unicast.

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

  • LSP MPLS de couleur, tels que RSVP, LDP, BGP-LU, statique.

  • Circuit de couche 2

  • FEC-129 VPN de couche 2 à signalisation LDP et découverte automatique BGP.

  • VPLS

  • MVPN

  • IPv4 et IPv6 à l’aide d’une résolution-map.

Modèles de tunnel pour les LSP de routage de segments initiés par PCE

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

Lorsqu’un LSP de routage de segments initié par PCE est créé, le LSP est vérifié par rapport aux instructions de stratégie (le cas échéant). 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) ; par exemple, la métrique.

Pour configurer un modèle :

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

  2. Incluez l’instruction source-routing-path-template-map au niveau de la [edit protocols source-packet-routing] hiérarchie pour répertorier les instructions de stratégie avec lesquelles le LSP initié par PCE doit être vérifié.

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

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

    L’instruction then doit inclure l’option sr-te-template avec une action d’acceptation. Cela applique le modèle au LSP initié par 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 du modèle ne s’applique pas aux LSP de routage de segments configurés statiquement, ni aux LSP de routage de segments d’un autre client.

  • La configuration fournie par PCEP a préséance sur la configuration de modèle.

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

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

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

Conditions préalables

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

  • Sept plates-formes de routage universelles 5G MX Series

  • Junos OS version 18.1 ou ultérieure s’exécutant sur tous les routeurs

Avant de commencer, assurez-vous de configurer les interfaces de l’équipement.

Présentation

Junos OS est un ensemble de chemins de routage de segments explicites configurés sur le routeur d’entrant d’un tunnel de routage de segments statique non coloré en configurant l’instruction segment-list au niveau de la [edit protocols source-packet-routing] hiérarchie. Vous pouvez configurer le tunnel de routage de segments en configurant l’instruction source-routing-path au [edit protocols source-packet-routing] niveau de la hiérarchie. Le tunnel de routage de segments comporte une adresse de destination et un ou plusieurs chemins principaux, ainsi que des chemins secondaires facultatifs faisant 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 coloré, le premier saut de la liste de segments spécifie une adresse IP immédiate du saut suivant et le deuxième saut Nth spécifie les étiquettes d’identification de segment (SID) correspondant à la liaison ou au nœud que le chemin traverse. Le routage vers la destination du tunnel de routage de segments est installé dans la table 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é entre le routeur PE1 et le routeur PE5 avec un chemin principal configuré sur le routeur PE1 et le routeur PE5 . Le routeur PE1 est également configuré avec le chemin secondaire pour la protection des chemins. Les routeurs de transit PE2 vers PE4 sont configurés avec des étiquettes SID d’adjacence avec le label pop et une interface sortante.

Figure 2 : Routage de segments statique Chemin de commutation d’étiquettes Routage de segments statique Chemin de commutation d’étiquettes

Configuration

Configuration rapide CLI

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez tous les sauts de ligne, modifiez tous les détails nécessaires pour correspondre à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis entrez commit du 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 à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à Using the CLI Editor in Configuration Mode dans le CLI User Guide.

Pour configurer l’équipement PE1 :

  1. Configurez les interfaces.

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

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

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

  5. Configurez les interfaces de la zone de protocole.

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

  7. Configurez l’adresse IPv4 de destination, le label SID de liaison, le chemin de routage source principal et secondaire pour le protocole SPRING.

  8. Configurez les options de stratégie.

  9. Configurez les informations de la communauté BGP.

  10. Configurez l’instance de routage VRF1 avec le type d’instance, l’interface, le routeur distingué, l’importation VRF, l’exportation et l’étiquette de table. Configurez la stratégie d’exportation et l’interface de la zone pour le protocole OSPF.

Résultats

Depuis le mode configuration, confirmez votre configuration en entrant les show interfacescommandes , show policy-options, show protocolsshow routing-optionset 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 à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à Using the CLI Editor in Configuration Mode dans le CLI User Guide.

  1. Configurez les interfaces.

  2. Configurez le LSP statique pour mpls de protocole.

  3. Configurez les interfaces et la plage d’étiquettes statiques pour mpls de protocole.

  4. Configurez les interfaces pour le protocole OSPF.

Résultats

Depuis le mode configuration sur le routeur PE2, confirmez votre configuration en entrant les show interfaces commandes.show protocols Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification de l’entrée de route de la table de routage inet.3 du routeur PE1
But

Vérifiez l’entrée de route de la table de routage danset.3 du routeur PE1.

Action

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

Sens

La sortie affiche les routes d’entrant des tunnels de routage de segments.

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

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

Action

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

Sens

La sortie affiche les étiquettes SID des tunnels de routage de segments.

Vérification du trafic SPRING LSP du routeur PE1
But

Vérifiez que le trafic SPRING a été conçu pour les LSP sur les routeurs d’entrant.

Action

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

Sens

La sortie affiche la présentation du trafic SPRING des LSP ingénieurs sur le routeur d’entrant.

Vérification de l’ingénierie de trafic SPRING LSP sur le routeur d’entrant PE1
But

Vérifiez que le trafic SPRING a été conçu pour les LSP sur le routeur d’entrant.

Action

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

Sens

La sortie affiche les détails du trafic SPRING des LSP ingénieurs sur le routeur d’entrant

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

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

Action

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

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

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

Action

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

Sens

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

S-BFD basé sur le moteur de routage pour les aspects techniques du trafic de routage de segments avec résolution d’étiquettes du premier saut

Vous pouvez exécuter la détection de transfert bidirectionnel (S-BFD) transparente sur des chemins de commutation d’étiquettes (LSP) non colorés et de couleur avec résolution d’étiquettes du premier saut, en utilisant S-BFD comme mécanisme rapide pour détecter les défaillances de chemin.

Comprendre le S-BFD basé sur RE pour les aspects techniques du trafic de routage de segments avec résolution d’étiquettes du premier saut

S-BFD Tunnels statiques de routage de segments pour les étiquettes du premier saut

L’architecture de routage de segments permet aux nœuds entrants d’un réseau central d’orienter le trafic via des chemins explicites à travers le réseau. Le saut suivant TE (Segment Routing Traffic Engineering) est une liste ou des listes d’identificateurs de segments (SID). Ces listes de segments représentent les chemins du réseau que vous souhaitez emprunter pour le trafic entrant. Le trafic entrant peut être étiqueté ou trafic IP et le transfert au niveau du nœud d’entrée peut être un échange d’étiquettes ou une recherche basée sur la destination pour orienter le trafic vers ces chemins TE de routage de segments dans le chemin de transfert.

Vous pouvez exécuter un BFD transparent (S-BFD) sur des LSP de routage de segments statiques non colorés et de couleur avec résolution d’étiquettes de premier saut et utiliser S-BFD comme mécanisme rapide pour détecter les défaillances de chemin et déclencher une convergence globale. Le S-BFD nécessite moins de changements d’état que ne le requiert BFD, ce qui accélère la génération de rapports sur les défaillances de chemin.

Si vous disposez d’un tunnel de routage de segments avec un ou plusieurs LSP principaux et, éventuellement, d’un LSP secondaire, vous pouvez activer le S-BFD sur n’importe lequel de ces LSP. Si une session S-BFD tombe en panne, le logiciel met à jour le routage du tunnel de routage de segments en supprimant les sauts suivant des LSP défaillants. Si le label du premier saut du LSP pointe vers plus d’un saut suivant immédiat, le noyau continue d’envoyer des paquets S-BFD si au moins un saut suivant est disponible (la détection des défaillances d’accessibilité du saut suivant sous-jacent doit être plus rapide que la durée du timer de détection S-BFD).

Remarque :

Ce modèle est pris en charge pour les LSP dérivés de traduction automatique.

S-BFD de niveau LSP

Une session S-BFD est créée pour chaque combinaison unique de la famille d’adresses et de la pile d’adresses. Vous pouvez configurer des listes de segments identiques et activer S-BFD pour toutes ces listes. Les listes de segments ayant des combinaisons label-stack+adresse-family identiques partagent la même session S-BFD. L’adresse source de la session S-BFD est définie sur l’adresse de bouclage la moins configurée (à l’exception des adresses spéciales) dans l’instance principale.

Remarque :

Assurez-vous que l’adresse source choisie est routable.

La famille d’adresses d’un LSP est dérivée de la famille d’adresses de l’adresse « to » dans le tunnel TE de routage de segments. L’état du LSP avec S-BFD configuré dépend également de la disponibilité de BFD: si S-BFD est configuré pour un LSP, la route LSP n’est pas calculée tant que S-BFD n’a pas signalé que le chemin était opérationnel.

Paramètres S-BFD

Les paramètres S-BFD suivants sont pris en charge pour les chemins TE de routage de segments :

  • Discrimination à distance

  • Intervalle minimum

  • Multiplicateur

  • Aucune option d’alerte de routeur

Dans le S-BFD, chaque répondant peut avoir plusieurs discriminations. Les discriminations peuvent être annoncées par IGP à d’autres routeurs, ou elles peuvent être configurées de manière statique sur ces routeurs. Sur un initiateur, une discrimination particulière est choisie comme discrimination à distance pour une session S-BFD par configuration statique, en fonction de la décision ou de la résolution que vous avez prise ou par un contrôleur central. Lorsque plusieurs LSP sont créés avec la même pile de labels clés et que S-BFD est activé sur chacun d’eux avec des paramètres différents, la valeur agressive de chaque paramètre est utilisée dans la session S-BFD partagée. Pour le paramètre discriminatoire, la valeur la plus faible est considérée comme la plus agressive. De même pour l’option d’alerte de routeur, si l’une des configurations ne dispose d’aucune alerte de routeur est configurée, le paramètre S-BFD dérivé n’aura pas d’option d’alerte de routeur.

Limitations

  • Seule une réparation globale est prise en charge.

  • Même si le S-BFD détecte les défaillances en fonction des valeurs du timer configuré, le temps de convergence dépend du temps de réparation global (seconds).

Configuration du S-BFD basé sur RE pour les aspects techniques du trafic de routage de segments avec résolution d’étiquettes du premier saut

Pour activer un S-BFD de niveau LSP pour une liste de segments, vous configurez l’instruction bfd-liveness-detection de configuration au niveau de la [edit protocols source-packet-routing source-routing-path lsp-path-name primary segment-list-name] hiérarchie et de la [edit protocols source-packet-routing source-routing-path lsp-path-name secondary segment-list-name] hiérarchie.

Les étapes suivantes donnent la configuration de base et le fonctionnement du S-BFD avec résolution d’étiquettes au premier saut :

  • Les étapes ci-dessous décrivent les grandes lignes de la configuration de base :

    1. Sur un routeur d’entrant, vous configurez une ou plusieurs listes de segments avec des étiquettes de premier saut pour un tunnel de routage de segments statique à utiliser comme chemins primaires et secondaires.

    2. Sur le routeur d’entrant, vous configurez le tunnel de routage de segments statique, avec plusieurs chemins principaux (pour l’équilibrage de charge) ou un chemin principal et un chemin secondaire (pour la protection des chemins). Chaque chemin principal ou secondaire (LSP) fait référence à l’une des listes de segments que vous avez déjà configurées, en créant des routes à l’aide des sauts suivant dérivés des étiquettes du premier saut de LSP contributifs.

    3. Sur le routeur d’entrant, vous activez l’équilibrage de charge par paquet de sorte que les routes résolvant les routes entrantes et la route SID de liaison (qui ont toutes des étiquettes de premier saut) installent tous les chemins actifs dans le moteur de transfert de paquets. Une session S-BFD sous LSP protège toutes les routes qui utilisent ce LSP.

    4. Sur le routeur sortant du tunnel de routage de segments, vous configurez le mode de réponse S-BFD avec un D discriminatoire local, créant ainsi une session D-BFD distribuée pour D sur chaque FPC.

    5. Sur le routeur d’entrant, vous configurez S-BFD pour n’importe quel LSP pour lequel vous souhaitez voir la détection des défaillances de chemin. Vous spécifiez un D discriminatoire à distance pour correspondre aux S-BFD locaux discriminatoires à l’adresse du routeur de sortie. Une session d’initiateur S-BFD est créée avec la combinaison label-stack+address-family LSP comme clé, si une session d’initiateur n’existe pas déjà pour la clé LSP actuelle. Les paramètres S-BFD dans le cas d’une session BFD équivalente sont réévalués avec les nouveaux LSP partagés pris en considération. Lorsque les paramètres S-BFD sont dérivés, la valeur agressive de chaque paramètre est choisie.

    Les étapes ci-dessous décrivent le fonctionnement de base :

    1. La session d’initiateur S-BFD s’exécute en mode centralisé sur le moteur de routage. Le logiciel suit les états de la session S-BFD.

    2. Lorsque l’état S-BFD passe à UP, le LSP est pris en compte pour les routes pertinentes.

    3. Sur le routeur d’entrant, si le logiciel détecte une session S-BFD VERS LE BAS, une notification de session est envoyée au démon de routage (RPD), et le RPD supprime le saut suivant des LSP défaillants du tunnel de routage de segments.

    4. La perte totale de trafic dans la procédure est liée au temps de détection des défaillances S-BFD et au temps global de réparation. Le temps de détection de défaillance S-BFD est déterminé par l’intervalle minimum S-BFD et les paramètres multiplicateurs. Le temps de réparation global dépend du temps de processus TE de routage de segments et du téléchargement à nouveau des routes vers le transfert.

    Les piles de labels LSP sont modifiées comme suit :

    1. Le LSP particulier est détaché de la session S-BFD existante. Si la session S-BFD existante comporte au moins un LSP qui la renvoie, l’ancienne session BFD est conservée, mais les paramètres S-BFD sont réévalués de manière à choisir les valeurs de paramètres agressives entre les sessions LSP existantes. En outre, le nom de la session S-BFD est mis à jour pour le moins un en cas de changement. Si l’ancienne session S-BFD ne comporte plus de LSP, cette session S-BFD est supprimée.

    2. Le logiciel tente de trouver une session BFD existante qui correspond à la valeur de la combinaison new-label-stack+address-family ; si une telle correspondance existe, le LSP fait référence à cette session S-BFD existante. La session S-BFD est réévaluée pour toute modification des paramètres ou du nom de la session, de la même manière que les évaluations de l’étape 1.

    3. S’il n’y a pas de session BFD correspondante dans le système, une nouvelle session BFD est créée et les paramètres S-BFD sont dérivés de ce LSP.

    Remarque :

    L’intervalle minimal et le facteur multiplicateur d’une session S-BFD déterminent le temps de détection des défaillances pour la session. Le temps de réparation dépend en outre du temps de réparation global.

Le résultat suivant affiche les instructions de configuration que vous utiliseriez pour un LSP de couleur avec des LSP principaux :

Du côté des répondants, vous devez configurer la discrimination correcte :

Par défaut, les alertes des routeurs sont configurées pour les paquets S-BFD. Lorsque l’en-tête MPLS est retiré à la fin du répondeur, le paquet est envoyé à l’hôte pour traitement sans qu’une adresse de destination ne recherche le paquet. Si vous activez l’option d’alerte sans routeur sur le routeur d’entrée, l’option d’alerte de routeur est retirée des options IP et, par conséquent, du côté sortant. Vous devez configurer l’adresse de destination explicitement dans le lo0 ; sinon le paquet est jeté et S-BFD reste en panne.

Vous pouvez utiliser un nouveau trace flag, , bfdpour suivre les activités BFD :

Exemple

La configuration suivante est un exemple de tunnel de routage de segments statique non coloré avec protection LSP.

Vérifiez que les LSP sont configurés pour les tunnels de routage de segments statiques et que l’état de session S-BFD est visible

But

Utilisez la commande show spring-traffic-engineering lsp detail pour afficher les LSP pour les tunnels de routage de segments statiques, avec l’état de session S-BFD.

Action

Comme de nombreux LSP peuvent partager la même session BFD, lorsque le premier LSP avec une combinaison unique de la famille d’adresses+pile d’adresses apparaît, le nom de la session S-BFD utilise address-family+lsp-name. Si d’autres LSP partagent ultérieurement la même session, le nom de la session peut changer pour address-family+least-lsp-name, sans affecter l’état de la session S-BFD. Le nom de la session S-BFD apparaît également en sortie de la show bfd session extensive commande. La sortie de chaque LSP affiche l’état S-BFD ainsi que le nom S-BFD à lequel il se réfère comme indiqué dans l’exemple précédent sous BFD status: Up BFD name: V4-sl2la forme . Comme il n’y a peut-être pas une session S-BFD par LSP, les compteurs S-BFD de niveau LSP ne sont pas affichés.

Vérifier le routage du tunnel de routage de segments avec un saut suivant principal et un saut suivant secondaire

But

Sur le moteur de routage du routeur d’entrant, vérifiez la route du tunnel de routage de segments avec un saut suivant principal et un saut suivant secondaire.

Action

Vérifier la session S-BFD du chemin principal

But

Sur le moteur de routage du routeur d’entrant, vérifiez la session S-BFD du chemin principal.

Action

Remarque :

Sur le moteur de routage du routeur d’entrant, vérifiez également la session S-BFD du chemin secondaire.

Délai de calcul Optimisation des chemins de routage de segments intradomaines et interdomaines

Présentation des mesures basées sur les délais pour les chemins d’ingénierie du trafic

Dans les réseaux modernes, l’utilisation de mesures dynamiques basées sur les délais devient un attribut souhaitable. Les mesures basées sur les délais sont essentielles pour qu’un élément de calcul de chemin (PCE) calcule le trafic des chemins ingénieurs. Vous pouvez utiliser des mesures basées sur les délais pour orienter les paquets sur les chemins à moins de latence, ou sur le chemin le moins long. Pour ce faire, vous devez mesurer le retard sur chaque lien et le promouvoir à l’aide d’un protocole de routage approprié (IGP ou BGP-LS), de sorte que l’entrant dispose des propriétés de délai par liaison dans son TED.

Pour comprendre comment annoncer le délai sur chaque lien, ou activer les mesures de liaison, consultez Comment activer la mesure de retard de liaison et la publicité dans ISIS.

La séquence d’événements suivante se produit lorsque vous mesurez, faites de la publicité et calculez la détection des modifications dans le réseau et calculez le chemin d’ingénierie de trafic avec la latence la plus courte :

  • Détectez les changements dans le réseau en mesurant la latence grâce à des sondes synthétiques, routeur à routeur.
  • Inondez les nœuds entrants des extensions TE étendues IGP.
  • Faites connaître les résultats aux contrôleurs centralisés avec les extensions BGP-LS correspondantes.
  • Chemins métriques de latence cumulés les plus courts basés sur IGP (Flex-algo).
  • Chemins explicites du trafic informatique (source à destination) avec des mesures de latence cumulative ou de délai (SR-TE) les plus courtes.

Avantages des mesures basées sur les délais pour le calcul de chemin

  • Déployez des services à valeur ajoutée en fonction de la latence la plus faible sur l’ensemble du réseau.
  • Mesurez la latence par chemin (minimum, maximum, moyenne) à l’aide de mesures basées sur les délais.
  • Orientez les services sensibles aux délais (tels que les services VPN ou 5G) sur les chemins optimisés pour le SR à très faible latence.

Calcul basé sur DCSPF avec mesures de retard pour la présentation du chemin SR

Grâce à la fonctionnalité CSPF (Constrained Shortest Path First) distribuée pour le routage de segments LSP, vous pouvez calculer localement un LSP de routage de segments sur l’équipement entrant en fonction des contraintes que vous avez configurées. Grâce à cette fonctionnalité, les LSP sont optimisés en fonction des contraintes configurées et du type de métrique (aspects techniques du trafic ou IGP). Les LSP sont calculés pour utiliser les chemins ECMP disponibles vers la destination, avec la compression de la pile de labels de routage de segments activée ou désactivée.

Vous pouvez configurer le CSFP distribué pour qu’il s’exécute sur plusieurs têtes de réseau et effectuer le calcul de chemin indépendamment sur chaque tête de réseau. Vous pouvez appliquer le profil de calcul au chemin source (chemin de routage de paquets source). Si vous avez configuré le profil de calcul optimisé pour la moyenne des délais, vous pouvez également appliquer une contrainte appelée delay-variation-threshold. Lorsque vous configurez une valeur pour delay-variation-threshold, toute liaison dépassant la valeur de seuil serait exclue du calcul du chemin.

Pour configurer des mesures de retard pour le calcul basé sur DCSPF pour le chemin SR, vous devez activer l’instruction delay de configuration au niveau [edit protocols source-packet-routing compute-profile profile-name metric-type delay] de la hiérarchie. Vous pouvez configurer les mesures de retard telles que le seuil de variation minimale, maximale, moyenne et différé pour le calcul du chemin.

  • minimum— Valeur minimale de l’indicateur de délai de TED pour le calcul du chemin de latence le plus faible cumulé.
  • average— Valeur métrique moyenne de délai de TED pour le calcul du chemin de latence le plus faible cumulé.
  • maximum— Valeur métrique maximale de délai de TED pour le calcul du chemin de latence le plus faible cumulé.
  • delay-variation-threshold— Seuil de variation des délais de liaison (1,16777215). Toute liaison dépassant le seuil de variation de retard serait exclue du calcul du chemin. Le seuil de variation de délai est indépendant de l’optimisation que vous effectuez pour le minimum, le maximum ou la moyenne. L’instruction delay-variation-threshold de configuration s’affiche à ces niveaux hiérarchiques :
    • [edit protocols source-packet-routing compute-profile profile-name metric-type delay]

    • [edit protocols source-packet-routing compute-profile profile-name metric-type delay minimum]

    • [edit protocols source-packet-routing compute-profile profile-name metric-type delay maximum]

    • [edit protocols source-packet-routing compute-profile profile-name metric-type delay average]

Vous pouvez configurer des mesures de retard au niveau de la hiérarchie CLI suivante :

Vue d’ensemble des cas d’utilisation interdomaines et intradomaines

Pour le cas intra-domaine (le chemin réside dans un domaine unique), le délai de liaison est pris en compte lors du calcul du chemin. Les mesures de délai pour le calcul de chemin de routage de segments sont prises en charge à la fois sur les SID comprimés et les SID non compressés. Si vous avez des SID non compressés, des segments d’adjacence pour les listes de segments sont utilisés pour produire plusieurs listes de segments s’il y a des coûts égaux. Vous pouvez configurer des SID non compressés à l’aide de l’instruction no-label-stack-compression de configuration au niveau de la hiérarchie [edit protocols source-packet-routing compute-profile profile-name]. Cela fournit un chemin entièrement étendu à l’aide de SID d’adjacence. Pour plus d’informations, consultez le profil de calcul .

Voici un exemple de configuration pour les mesures de retard :

Remarque :

Pour le calcul de chemin optique, il est recommandé d’utiliser les mesures de retard au minimum. La configuration par défaut est minimale.

Dans le cas d’utilisation interdomaine (multidomaine), où il existe plusieurs systèmes autonomes, vous pouvez utiliser des segments express pour configurer les retards de liaison pour le calcul de chemin. Les segments express sont des liaisons qui connectent des nœuds de bordure ou des ASR. Consultez la configuration Express Segment LSP pour en savoir plus sur les segments express. Vous pouvez configurer le délai ou hériter du délai du LSP sous-jacent dans le segment express. Vous pouvez configurer delay au niveau de la hiérarchie [edit protocols express-segments segment-template template-name metric] et définir les valeurs pour les retards minimum, maximum et moyen.

Vous pouvez configurer des mesures de retard dans un segment express au niveau de la hiérarchie CLI suivante :

Pour le calcul de chemin interdomaine, vous pouvez attribuer des métriques de retard sur les liaisons EPE BGP. Vous pouvez configurer une valeur au delay-metric niveau de la hiérarchie [edit protocols bgp group group-name neighbor ip address egress-te-adj-segment segment-name egress-te-link attribute] comme indiqué ci-dessous :

Cas d’utilisation des mesures de retard dans les réseaux optiques

Les topologies suivantes illustrent un cas d’utilisation optique. Les solutions de protection et de restauration optiques se traduisent par des attributs physiques sous-jacents, principalement la longueur du chemin, qui évoluent en raison de défaillances de liaison et de l’optimisation du réseau DWDM.

En figure, la liaison entre A et C passe par les nœuds optiques O1 et O3 et présente une latence de 10 microsecondes. En figure, vous pouvez voir une défaillance de liaison entre les nœuds optiques O1 et O3 et que la connexion optique réelle est acheminée via le nœud optique O2. Cela augmente la latence de 15 microsecondes. La mesure de la liaison qui relie A et B change dynamiquement entre temps=0 et temps=1.

Lorsqu’une modification du délai par liaison est détectée par l’entrée, l’entrée déclenche la recomputation du chemin optimisé pour les délais et le routeur d’entrée redirige le chemin vers le chemin le plus faible disponible suivant. La modification du délai de liaison peut entraîner le choix d’un autre ensemble de liaisons ayant le chemin le moins de latence. Sur la figure B, la liaison entre le chemin A et C est modifiée et le routeur principal rerouve et sélectionne le chemin A-B-C comme illustré dans la topologie.

Tableau de l'historique des versions
Version
Description
20.2R1
À partir de Junos OS version 20.2R1, BGP Labeled Unicast (BGP-LU) peut résoudre les routes IPv4 ou IPv6 sur les aspects techniques du routage de segments et du trafic (SR-TE) pour les familles d’adresses IPv4 et IPv6.
19.4R1
Vous pouvez configurer un modèle de tunnel pour les LSP de routage de segments initiés par PCE afin de transmettre deux paramètres supplémentaires pour ces LSP : la détection de transfert bidirectionnel (BFD) et la tunnelisation LDP.
19.1R1
À partir de Junos OS Version 19.1R1, une fonctionnalité de vérification de validation est mise en place afin de s’assurer que toutes les listes de segments contribuant aux routes colorées ont le label minimum présent pour tous les sauts.
19.1R1
À partir de Junos OS version 19.1R1, cette exigence ne s’applique pas, car le premier saut des LSP statiques non colorées prend désormais en charge les étiquettes SID, en plus des adresses IP. Avec la prise en charge du premier saut, le reroutage rapide MPLS (FRR) et le multipath pondéré à coût égal sont activés pour résoudre les LSP statiques non colorées de routage de segments, semblables aux LSP statiques de couleur.
18.2R1
À partir de Junos OS Version 18.2R1, les LSP de routage de segments non colorés configurés de manière statique sur l’équipement entrant sont signalés à l’élément de calcul de chemin (PCE) par le biais d’une session PCEP (Path Computation Element Protocol).