Segment Routing LSP Configuration
Activation du CSPF distribué pour les LSP de routage de segments
Avant Junos OS version 19.2R1S1, pour l’ingénierie du trafic des chemins de routage de segments, vous pouviez soit configurer explicitement des chemins statiques, soit utiliser des chemins calculés à partir d’un contrôleur externe. Avec la fonctionnalité CSPF (Constrained Shortest Path First) distribuée pour le LSP de routage de segments, vous pouvez calculer un LSP de routage de segments localement sur l’équipement entrant en fonction des contraintes que vous avez configurées. Grâce à cette fonctionnalité, les LSP sont optimisés en fonction des contraintes configurées et du type de métrique (traffic-engineering ou IGP). Les LSP sont calculés pour utiliser les chemins ECMP disponibles vers la destination lorsque la compression de pile d’étiquettes de routage de segments est activée ou désactivée.
- Contraintes de calcul CSPF distribuées
- Algorithme de calcul CSPF distribué
- Base de données de calcul CSPF distribuée
- Configuration des contraintes de calcul CSPF distribuées
- Calcul CSPF distribué
- Interaction entre le calcul CSPF distribué et les fonctionnalités SR-TE
- Exemples de configurations de calcul CSPF distribué
Contraintes de calcul CSPF distribuées
Les chemins LSP de routage de segments sont calculés lorsque toutes les contraintes configurées sont satisfaites.
La fonctionnalité de calcul CSPF distribué prend en charge le sous-ensemble de contraintes suivantes spécifié dans le projet Internet, draft-ietf-spring-segment-routing-policy-03.txt, Segment Routing Policy for Traffic Engineering :
-
Inclusion et exclusion de groupes administratifs.
-
Inclusion d’adresses IP de saut lâches ou strictes.
REMARQUE :Vous ne pouvez spécifier que des ID de routeur dans les contraintes de saut lâches ou strictes. Les étiquettes et autres adresses IP ne peuvent pas être spécifiées en tant que contraintes de saut lâches ou strictes dans Junos OS version 19.2R1-S1.
-
Nombre maximal d’ID de segment (SID) dans la liste des segments.
-
Nombre maximal de listes de segments par chemin de routage de segments candidats.
La fonctionnalité de calcul CSPF distribuée pour les LSP de routage de segments ne prend pas en charge les types de contraintes et de scénarios de déploiement suivants :
-
Adresses IPV6.
-
LSP d’ingénierie du trafic de routage de segments interdomaines (SR-TE).
-
Interfaces non numérotées.
-
Plusieurs protocoles de routage (OSPF, ISIS et BGP-LS) sont activés simultanément.
-
Calcul avec des préfixes ou des adresses anycast comme destinations.
-
Inclure et exclure les adresses IP d’interface en tant que contraintes.
Algorithme de calcul CSPF distribué
La fonctionnalité de calcul CSPF distribuée pour les LSP de routage de segments utilise l’algorithme de compression de pile d’étiquettes avec CSPF.
Compression de la pile d’étiquettes activée
Une pile d’étiquettes compressée représente un ensemble de chemins allant d’une source à une destination. Il se compose généralement de SID de nœud et de SID d’adjacence. Lorsque la compression de la pile d’étiquettes est activée, le résultat du calcul est un ensemble de chemins qui maximisent ECMP vers la destination, avec un nombre minimal de SID dans la pile, tout en se conformant aux contraintes.
Compression de la pile d’étiquettes désactivée
Le calcul CSPF multipath lorsque la compression de la pile d’étiquettes est désactivée permet de trouver jusqu’à des listes de segments jusqu’à N la destination, où :
-
Le coût de toutes les listes de segments est égal et identique à la mesure d’ingénierie du trafic la plus courte pour atteindre la destination.
-
Chaque liste de segments est composée de SID de contiguïté.
-
La valeur de est le nombre maximal de listes de N segments autorisées pour le chemin d’accès candidat par configuration.
-
Il n’y a pas deux listes de segments identiques.
-
Chaque liste de segments répond à toutes les contraintes configurées.
Base de données de calcul CSPF distribuée
La base de données utilisée pour le calcul de la SR-TE contient tous les liens, les nœuds, les préfixes et leurs caractéristiques, que l’ingénierie du trafic soit activée ou non dans ces nœuds publicitaires. En d’autres termes, c’est l’union de la base de données d’ingénierie du trafic (TED) et de la base de données d’état des liens IGP de tous les domaines à partir desquels le nœud de calcul a appris. Par conséquent, pour que CSPF fonctionne, vous devez inclure l’instruction igp-topology au niveau de la [edit protocols isis traffic-engineering] hiérarchie.
Configuration des contraintes de calcul CSPF distribuées
Vous pouvez utiliser un profil de calcul pour regrouper logiquement les contraintes de calcul. Ces profils de calcul sont référencés par les chemins de routage de segments pour calculer les LSP de routage de segments primaire et secondaire.
Pour configurer un profil de calcul, incluez l’instruction compute-profile au niveau de la [edit protocols source-packet-routing] hiérarchie.
La configuration des contraintes de calcul prises en charge est la suivante :
-
Administrative groups
Vous pouvez configurer les groupes d’administrateurs au niveau de la
[edit protocols mpls]hiérarchie. Junos OS applique la configuration du groupe d’administration aux interfaces SR-TE (Segment Routing Traffic-ingénierie).Pour configurer les contraintes de calcul, vous pouvez spécifier trois catégories pour un ensemble de groupes d’administration. La configuration de contrainte de calcul peut être commune à tous les chemins de routage de segments candidats ou se trouver sous des chemins candidats individuels.
-
include-any: spécifie que tout lien avec au moins un des groupes d’administration configurés dans la liste est acceptable pour le chemin à traverser. -
include-all: spécifie que tout lien avec tous les groupes d’administration configurés de la liste est acceptable pour le chemin à traverser. -
exclude: spécifie que tout lien qui n’a aucun des groupes d’administration configurés dans la liste est acceptable pour le chemin à traverser.
-
-
Explicit path
Vous pouvez spécifier une série d’ID de routeur dans le profil de calcul en tant que contrainte pour le calcul des chemins candidats SR-TE . Chaque saut doit être une adresse IPv4 et peut être de type strict ou loose. Si le type d’un saut n’est pas configuré, strict est utilisé. Vous devez inclure l’option sous l’instruction
computesegment-list lorsque vous spécifiez la contrainte de chemin explicite. -
Maximum number of segment lists (ECMP paths)
Vous pouvez associer un chemin candidat à un certain nombre de listes de segments dynamiques. Les chemins sont des chemins ECMP, où chaque liste de segments se traduit par une passerelle de saut suivant avec une pondération active. Ces chemins sont le résultat d’un calcul de chemin avec ou sans compression.
Vous pouvez configurer cet attribut à l’aide de l’option située sous l’instruction de
maximum-computed-segment-lists maximum-computed-segment-listsconfiguration compute-profile . Cette configuration détermine le nombre maximal de ces listes de segments calculées pour un LSP primaire et secondaire donné. -
Maximum segment list depth
Le paramètre de calcul de la profondeur maximale de la liste de segments garantit que, parmi les chemins ECMP qui satisfont à toutes les autres contraintes, telles que le groupe d’administration, seuls les chemins dont les listes de segments sont inférieures ou égales à la profondeur maximale de la liste de segments sont utilisés. Lorsque vous configurez ce paramètre en tant que contrainte sous le profil de calcul, il remplace la configuration sous le
maximum-segment-list-depthniveau hiérarchique[edit protocols source-packet-routing], le cas échéant.Vous pouvez configurer cet attribut à l’aide de l’option située sous l’instruction de
maximum-segment-list-depth maximum-segment-list-depthconfiguration compute-profile . -
Protected or unprotected adjacency SIDs
Vous pouvez configurer un SID d’adjacence protégé ou non protégé en tant que contrainte sous le profil de calcul afin d’éviter les liens avec le type de SID spécifié.
-
Metric type
Vous pouvez spécifier le type de métrique sur le lien à utiliser pour le calcul. Par défaut, les LSP SR-TE utilisent les mesures d’ingénierie du trafic des liaisons pour le calcul. La métrique d’ingénierie du trafic pour les liens est annoncée par les extensions d’ingénierie du trafic des protocoles IGP. Toutefois, vous pouvez également choisir d’utiliser la métrique IGP pour le calcul à l’aide de la configuration de type métrique dans le profil de calcul.
Vous pouvez configurer cet attribut à l’aide de l’option située sous l’instruction de
metric-type (igp | te)configuration compute-profile .
Calcul CSPF distribué
Les chemins candidats SR-TE sont calculés localement de manière à satisfaire les contraintes configurées. Lorsque la compression de la pile d’étiquettes est désactivée, le résultat du calcul CSPF multi-chemin est un ensemble de piles SID d’adjacence. Lorsque la compression de la pile d’étiquettes est activée, le résultat est un ensemble de piles d’étiquettes compressées (composées de SID et de SID de nœud adjacents).
Lorsque les chemins secondaires sont calculés, les liens, les noeuds et les SRLG empruntés par les chemins primaires ne sont pas évités pour le calcul. Pour plus d’informations sur les chemins d’accès principaux et secondaires, consultez Configuration des LSP principaux et secondaires.
Pour tous les LSP dont le résultat de calcul a échoué, le calcul est retenté en tant que modifications de la base de données d’ingénierie du trafic (TED).
Interaction entre le calcul CSPF distribué et les fonctionnalités SR-TE
- Pondérations associées aux chemins d’une politique SR-TE
- Détection de la vivacité BFD
- inherit-label-nexthops
- Fonction de traduction automatique
Pondérations associées aux chemins d’une politique SR-TE
Vous pouvez configurer des pondérations par rapport aux chemins SR-TE calculés et statiques, qui contribuent aux sauts suivants de l’itinéraire. Toutefois, un seul chemin pour lequel le calcul est activé peut générer plusieurs listes de segments. Ces listes de segments calculées sont traitées comme ECMP entre elles. Vous pouvez affecter des pondérations ECMP hiérarchiques à ces segments, en tenant compte des pondérations attribuées à chacun des principaux configurés.
Détection de la vivacité BFD
Vous pouvez configurer la détection de vivacité BFD pour les chemins principaux ou secondaires calculés. Chaque chemin principal ou secondaire calculé peut générer plusieurs listes de segments, par conséquent, les paramètres BFD configurés par rapport aux listes de segments sont appliqués à toutes les listes de segments calculées. Si tous les chemins principaux actifs tombent en panne, le chemin secondaire préprogrammé (s’il est fourni) devient actif.
inherit-label-nexthops
Il n’est pas nécessaire d’activer explicitement la configuration sous la inherit-label-nexthops[edit protocols source-packet-routing segment-list segment-list-name] hiérarchie pour les chemins principaux ou secondaires calculés, car il s’agit d’un comportement par défaut.
Fonction de traduction automatique
Vous pouvez configurer la fonctionnalité de traduction automatique dans les listes de segments, et les chemins principaux ou secondaires avec la fonction de traduction automatique font référence à ces listes de segments. D’autre part, le primaire ou le secondaire sur lequel la fonctionnalité de calcul est activée ne peut faire référence à aucune liste de segments. Par conséquent, vous ne pouvez pas activer à la fois la fonctionnalité de calcul et la fonctionnalité de traduction automatique pour un chemin principal ou secondaire donné. Toutefois, vous pouvez avoir un LSP configuré avec un chemin principal avec le type de calcul et un autre avec le type de traduction automatique.
Exemples de configurations de calcul CSPF distribué
Exemple 1
Dans l’exemple 1,
-
Le chemin principal non calculé fait référence à une liste de segments configurée. Dans cet exemple, la liste static_sl1 de segments configurée est référencée et sert également de nom à ce chemin principal.
-
Un nom doit être configuré pour un primaire calculé, et ce nom ne doit pas faire référence à une liste de segments configurée. Dans cet exemple, compute_segment1 il ne s’agit pas d’une liste de segments configurée.
-
Le compute_profile_red profil de calcul est appliqué au chemin d’accès principal portant le nom compute_segment1.
-
Le compute_profile_red profil de calcul inclut une liste de segments de type
compute, qui est utilisée pour spécifier la contrainte de chemin explicite pour le calcul.
[edit protocols source-packet-routing]
segment-list static_sl1{
hop1 label 80000
}
segment-list exp_path1 {
hop1 ip-address 10.1.1.1 loose
hop2 ip-address 10.2.2.2
compute
}
compute-profile compute_profile_red {
include-any red
segment-list exp_path1
maximum-segment-list-depth 5
}
Les pondérations pour les sauts suivants de chemin calculés et les sauts suivants statiques sont respectivement de 2 et 3. En supposant que les sauts suivants pour les chemins calculés sont , et comp_nh3, et que le saut suivant pour le chemin statique est static_nh, comp_nh2les pondérations sont comp_nh1appliquées comme suit :
|
Saut suivant |
Poids |
|---|---|
|
comp_nh1 |
2 |
|
comp_nh2 |
2 |
|
comp_nh3 |
2 |
|
static_nh |
9 |
Exemple 2
Dans l’exemple 2, les chemins primaire et secondaire peuvent être de type calcul et avoir leurs propres profils de calcul.
[edit protocols source-packet-routing]
compute-profile compute_profile_green{
include-any green
maximum-segment-list-depth 5
}
compute-profile compute_profile_red{
include-any red
maximum-segment-list-depth 8
}
Exemple 3
Dans l’exemple 3, lorsque le calcul est mentionné sous un chemin principal ou secondaire, il en résulte le calcul local d’un chemin vers la destination sans aucune contrainte ou autre paramètre pour le calcul.
[edit protocols source-packet-routing]
source-routing-path srte_colored_policy1 {
to 10.5.5.5
color 5
binding-sid 10001
primary {
compute_segment1 {
compute
}
}
}
Chemin de commutation d’étiquette de segment routing statique
L’architecture de routage de segments permet aux périphériques entrants d’un réseau central d’orienter le trafic via des chemins explicites. Vous pouvez configurer ces chemins à l’aide de listes de segments pour définir les chemins que le trafic entrant doit emprunter. Le trafic entrant peut être étiqueté ou trafic IP, ce qui fait que l’opération de transfert au niveau de l’équipement entrant est soit un échange d’étiquettes, soit une recherche basée sur la destination.
- Comprendre le LSP de segment routing statique dans les réseaux MPLS
- Exemple : configuration du chemin de commutation d’étiquette de segment routing statique
Comprendre le LSP de segment routing statique dans les réseaux MPLS
Le routage de paquets source, ou routage de segments, est une architecture de plan de contrôle qui permet à un routeur entrant de diriger un paquet à travers un ensemble spécifique de nuds et de liaisons dans le réseau sans dépendre des nuds intermédiaires du réseau pour déterminer le chemin qu’il doit emprunter.
- Introduction aux LSP de Segment Routing
- Avantages des LSP de Segment Routing
- LSP de routage de segments statique coloré
- LSP de routage de segments statique non coloré
- Provisionnement LSP de segment routing statique
- Static Segment Routing LSP Limitations
- Création dynamique de LSP de Segment Routing
- Mappage basé sur les couleurs des services VPN
- Modèles de tunnel pour les prestataires de services linguistiques Segment Routing initiés par PCE
Introduction aux LSP de Segment Routing
Le routage de segments s’appuie sur le paradigme du routage source. Un périphérique oriente un paquet à travers une liste ordonnée d’instructions, appelées segments. Un segment peut représenter n’importe quelle instruction, topologique ou basée sur un service. Un segment peut avoir une sémantique locale vers un nœud de routage de segment ou vers un nœud global au sein d’un domaine de routage de segment. Le routage de segments applique un flux à travers n’importe quel chemin topologique et n’importe quelle chaîne de services tout en conservant l’état par flux uniquement au niveau de l’équipement d’entrée dans le domaine de routage de segment. Le routage de segments peut être appliqué directement à l’architecture MPLS sans modification du plan de transfert. Un segment est encodé en tant qu’étiquette MPLS. Une liste ordonnée de segments est encodée sous la forme d’une pile d’étiquettes. Le segment à traiter se trouve en haut de la pile. À la fin d’un segment, l’étiquette associée est extraite de la pile.
Les LSP de routage de segments peuvent être de nature dynamique ou statique.
|
Dynamic segment routing LSPs—Lorsqu’un LSP de routage de segments est créé par un contrôleur externe et téléchargé sur un périphérique d’entrée via des extensions PCEP (Path Computation Element Protocol), ou à partir d’une stratégie de routage de segment BGP via des extensions de routage de segments BGP, le LSP est provisionné dynamiquement. La liste des segments du LSP de routage de segments dynamique est contenue dans l’objet de route explicite (ERO) PCEP ou dans la stratégie de routage de segments BGP du LSP. |
|
Static segment routing LSPs: lorsqu’un LSP de routage de segments est créé sur le périphérique d’entrée par le biais d’une configuration locale, le LSP est provisionné de manière statique. Un LSP de routage de segments statique peut en outre être classé en LSP colorés et non colorés en fonction de la configuration de l’instruction Par exemple : [edit protocols]
source-packet-routing {
source-routing-path lsp_name {
to destination_address;
color color_value;
binding-sid binding-label;
primary segment_list_1_name weight weight;
...
primary segment_list_n_name weight weight;
secondary segment_list_n_name;
sr-preference sr_preference_value;
}
}
Ici, chaque instruction primaire et secondaire fait référence à une liste de segments. [edit protocols]
source-packet-routing {
segment-list segment_list_name {
hop_1_name label sid_label;
...
hop_n_name label sid_label;
}
}
|
Avantages des LSP de Segment Routing
-
Le routage de segments statique ne dépend pas de l’état de transfert par LSP sur les routeurs de transit. Par conséquent, il n’est plus nécessaire d’approvisionner et de maintenir l’état de transfert par LSP dans le cur.
-
Fournir une plus grande évolutivité aux réseaux MPLS.
LSP de routage de segments statique coloré
Un LSP de routage de segments statique configuré avec l’instruction color est appelé LSP coloré.
- Comprendre les LSP de routage de segments statiques colorés
- Liste de segments des LSP Segment Routing colorés
Comprendre les LSP de routage de segments statiques colorés
Comme pour une stratégie de routage de segment BGP, la route d’entrée du LSP coloré est installée dans les inetcolor.0 tables de routage ou inet6color.0 , avec destination-ip-address, color comme clé pour mapper le trafic IP.
Un LSP de routage de segment coloré statique peut avoir un SID de liaison, pour lequel un itinéraire est installé dans la mpls.0 table de routage. Cette étiquette SID de liaison est utilisée pour mapper le trafic étiqueté au LSP de routage de segment. Les passerelles de la route sont dérivées des configurations de liste de segments sous les chemins principal et secondaire.
Liste de segments des LSP Segment Routing colorés
Les LSP de routage de segments statiques colorés prennent déjà en charge le mode d’étiquette de premier saut de résolution d’un LSP. Toutefois, le mode IP de premier saut n’est pas pris en charge pour les LSP de routage de segments colorés. À partir de Junos OS version 19.1R1, une fonctionnalité de vérification de validation est introduite pour garantir que toutes les listes de segments contribuant aux routes colorées ont l’étiquette minimale présente pour tous les sauts. Si cette condition n’est pas remplie, la validation est bloquée.
LSP de routage de segments statique non coloré
Un LSP de routage de segment statique configuré sans l’instruction color est un LSP non coloré. Comme pour les tunnels de routage de segments PCEP, la route d’entrée est installée dans les tables de inet.3 routage ou inet6.3 .
Junos OS prend en charge les LSP de routage de segments statiques non colorés sur les routeurs entrants. Vous pouvez provisionner un LSP de routage de segments statique non coloré en configurant un chemin d’accès routé source et une ou plusieurs listes de segments. Ces listes de segments peuvent être utilisées par plusieurs LSP de routage de segments non colorés.
- Comprendre les LSP Segment Routing non colorés
- Liste de segments des LSP Segment Routing non colorés
Comprendre les LSP Segment Routing non colorés
Le LSP de routage de segments non coloré possède un nom unique et une adresse IP de destination. Une route entrante vers la destination est installée dans la table de routage inet.3 avec une préférence par défaut de 8 et une métrique de 1. Cette route permet de mapper des services non colorés au LSP de routage de segment correspondant à la destination. Dans le cas où le LSP de routage de segments non coloré ne nécessite pas de route d’entrée, la route d’entrée peut être désactivée. Un LSP de routage de segments non coloré utilise une étiquette SID de liaison pour réaliser l’assemblage LSP de routage de segments. Cette étiquette peut être utilisée pour modéliser le LSP de routage de segments en tant que segment qui peut être utilisé pour construire d’autres LSP de routage de segments de manière hiérarchique. Le transit de l’étiquette SID de liaison, par défaut, a une préférence de 8 et une métrique de 1.
À compter de Junos OS version 18.2R1, les LSP de routage de segments non colorés configurés statiquement sur le périphérique entrant sont signalés à l’élément de calcul de chemin (PCE) par le biais d’une session PCEP (Path Computation Element Protocol). Ces LSP de routage de segments non colorés peuvent être associés à des étiquettes d’identificateur de service de liaison (SID). Grâce à cette fonctionnalité, le PCE peut utiliser cette étiquette SID de liaison dans la pile d’étiquettes pour provisionner des chemins LSP de routage de segments initiés par PCE.
Un LSP de routage de segments non coloré peut avoir un maximum de 8 chemins principaux. S’il existe plusieurs chemins principaux opérationnels, le moteur de transfert de paquets (PFE) répartit le trafic sur les chemins en fonction des facteurs d’équilibrage de charge, tels que le poids configuré sur le chemin. Il s’agit d’un chemin multiple à coût égal (ECMP) si aucun des chemins n’a une pondération configurée ou d’un ECMP pondéré si au moins l’un des chemins a une pondération différente de zéro configurée sur les chemins. Dans les deux cas, lorsqu’un ou plusieurs des chemins tombent en panne, le PFE rééquilibre le trafic sur les chemins restants, ce qui conduit automatiquement à la mise en place d’une protection des chemins. Un LSP de routage de segments non coloré peut avoir un chemin secondaire pour une protection de chemin dédiée. En cas de défaillance d’un chemin principal, le PFE rééquilibre le trafic vers les chemins principaux fonctionnels restants. Dans le cas contraire, le PFE bascule le trafic vers le chemin de secours, assurant ainsi la protection du chemin. Un LSP de routage de segment non coloré peut spécifier une métrique at [edit protocols source-packet-routing source-routing-path lsp-name] pour ses routes SID d’entrée et de liaison. Plusieurs LSP de routage de segments non colorés ont la même adresse de destination, ce qui contribue au saut suivant de la route d’entrée.
Plusieurs LSP de routage de segments non colorés ont la même adresse de destination, ce qui contribue au saut suivant de la route d’entrée. Chaque chemin, qu’il soit primaire ou secondaire, de chaque LSP de routage de segments est considéré comme un candidat de passerelle, si le chemin est fonctionnel et que le LSP de routage de segments a la meilleure préférence de tous ces LSP de routage de segments. Toutefois, le nombre maximal de passerelles pouvant contenir le tronçon suivant ne peut pas dépasser la limite de chemins multiples du RPD, qui est de 128 par défaut. Les chemins supplémentaires sont élagués, d’abord les chemins secondaires, puis les chemins principaux. Une liste de segments donnée peut être désignée plusieurs fois en tant que chemins principaux ou secondaires par ces LSP de routage de segments. Dans ce cas, il existe plusieurs passerelles, chacune ayant un ID de tunnel LSP de routage de segment unique. Ces passerelles sont distinctes, bien qu’elles aient une pile d’étiquettes sortante et une interface identiques. Un LSP de routage de segments non coloré et un LSP de routage de segments colorés peuvent également avoir la même adresse de destination. Cependant, ils correspondent à des adresses de destination différentes pour les routes entrantes, car l’adresse de destination du LSP de routage de segment coloré est construite avec son adresse de destination et sa couleur.
Dans le cas où un LSP de routage de segments statique non coloré et un LSP de routage de segments créé par PCEP coexistent et ont le même adressage qui contribue à la même route d’entrée, s’ils ont également la même préférence. Dans le cas contraire, le LSP de routage de segments avec la meilleure préférence est installé pour la route.
Liste de segments des LSP Segment Routing non colorés
Une liste de segments est constituée d’une liste de sauts. Ces sauts sont basés sur l’étiquette SID ou une adresse IP. Le nombre d’étiquettes SID dans la liste de segments ne doit pas dépasser la limite maximale de la liste de segments. Le nombre maximal de liaisons de liste de segments à un tunnel LSP passe de 8 à 128, avec un maximum de 1000 tunnels par système. Un maximum de 128 chemins principaux sont pris en charge par LSP de routage de segments statique. Vous pouvez configurer la limite maximale de la liste de segments au niveau de la [edit protocols source-packet-routing] hiérarchie.
Avant Junos OS version 19.1R1, pour qu’un LSP de routage de segments statique non coloré soit utilisable, le premier saut de la liste de segments devait être l’adresse IP d’une interface sortante et l’avant-dernier ndevait être des étiquettes SID. À partir de Junos OS version 19.1R1, cette exigence ne s’applique plus, car le premier saut des LSP statiques non colorés prend désormais en charge les étiquettes SID, en plus des adresses IP. Avec la prise en charge de la première étiquette de saut, le reroutage rapide MPLS (FRR) et le multichemin multi-coût pondéré sont activés pour résoudre les LSP de routage de segments statiques non colorés, similaires aux LSP statiques statiques.
Pour que le mode d’étiquette du premier saut soit effectif, vous devez inclure l’instruction globalement ou individuellement pour une liste de segments, et le premier saut de la liste de segments doit inclure à la fois l’adresse IP et l’étiquette inherit-label-nexthops . Si le premier saut inclut uniquement l’adresse IP, l’instruction n’a inherit-label-nexthops aucun effet.
Vous pouvez configurer inherit-label-nexthops l’une des hiérarchies suivantes. L’instruction inherit-label-nexthops ne prend effet que si le premier saut de la liste de segments inclut à la fois l’adresse IP et l’étiquette.
-
Segment list level: au niveau de la
[edit protocols source-packet-routing segment-list segment-list-name]hiérarchie. -
Globally: au niveau de la
[edit protocols source-packet-routing]hiérarchie.
Lorsque l’instruction inherit-label-nexthops est configurée globalement, elle est prioritaire sur la configuration au niveau de la liste de segments et la inherit-label-nexthops configuration est appliquée à toutes les listes de segments. Lorsque l’instruction n’est pas configurée globalement, seules les listes de segments avec des étiquettes et une adresse IP présentes dans le premier saut et configurées avec inherit-label-nexthops une instruction sont résolues à l’aide d’étiquettes inherit-label-nexthops SID.
Pour les LSP statiques dynamiques non colorés, c’est-à-dire les LSP de routage de segments pilotés par PCEP, l’instruction doit être activée globalement, car la configuration au niveau du segment n’est inherit-label-nexthops pas appliquée.
Tableau 1 décrit le mode de résolution LSP du routage de segments en fonction de la spécification du premier saut.
|
Spécification du premier saut |
Mode de résolution LSP |
|---|---|
|
Adresse IP uniquement Par exemple : segment-list path-1 {
hop-1 ip-address 172.16.12.2;
hop-2 label 1000012;
hop-3 label 1000013;
hop-4 label 1000014;
}
|
La liste des segments est résolue à l’aide de l’adresse IP. |
|
SID uniquement Par exemple : segment-list path-2 {
hop-1 label 1000011;
hop-2 label 1000012;
hop-3 label 1000013;
hop-4 label 1000014;
}
|
La liste des segments est résolue à l’aide d’étiquettes SID. |
|
Adresse IP et SID (sans la Par exemple : segment-list path-3 {
hop1 {
label 801006;
ip-address 172.16.1.2;
}
hop-2 label 1000012;
hop-3 label 1000013;
hop-4 label 1000014;
}
|
Par défaut, la liste des segments est résolue à l’aide de l’adresse IP. |
|
Adresse IP et SID (avec la Par exemple : segment-list path-3 {
inherit-label-nexthops;
hop1 {
label 801006;
ip-address 172.16.1.2;
}
hop-2 label 1000012;
hop-3 label 1000013;
hop-4 label 1000014;
}
|
La liste des segments est résolue à l’aide d’étiquettes SID. |
Vous pouvez utiliser la commande pour afficher les LSP d’ingénierie de trafic de routage de segments non colorés ayant plusieurs listes de segments installées dans la show route ip-address protocol spring-te active-path table inet.3 table de routage inet.3.
Par exemple :
user@host> show route 10.7.7.7 protocol spring-te active-path table inet.3
inet.3: 42 destinations, 59 routes (41 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
10.7.7.7/32 *[SPRING-TE/8] 00:01:25, metric 1, metric2 0
> to 10.11.1.2 via et-0/0/0.1, Push 801007
to 10.21.1.2 via et-0/0/2.1, Push 801007
to 10.102.1.2 via et-0/0/0.2, Push 801007, Push 801002(top)
to 10.21.1.2 via et-0/0/2.2, Push 801007, Push 801005(top)
to 10.103.1.2 via et-0/0/0.3, Push 801007, Push 801003(top)
to 10.203.1.2 via et-0/0/2.3, Push 801007, Push 801006(top)
to 10.104.1.2 via et-0/0/0.4, Push 801007, Push 801003, Push 801002(top)
to 10.204.1.2 via et-0/0/2.4, Push 801007, Push 801006, Push 801005(top)
Le premier type de saut des listes de segments d’un LSP de routage de segments statique peut entraîner l’échec d’une validation, si :
-
Les différentes listes de segments d’un tunnel ont différents types de résolution de premier saut. Cela s’applique aux LSP de routage de segments statiques colorés et non colorés. Toutefois, cela ne s’applique pas aux prestataires de services linguistiques pilotés par le PCEP ; Un message du journal système est généré pour l’incompatibilité dans le type de résolution du premier saut au moment du calcul du chemin.
Par exemple :
segment-list path-1 { hop-1 ip-address 172.16.12.2; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } segment-list path-2 { hop-1 label 1000011; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } source-routing-path lsp1 { to 172.16.10.1; primary { path-1; path-2; } }La validation du tunnel lsp1 échoue, car le chemin 1 est en mode adresse IP et le chemin 2 est en mode étiquette.
-
Le SID de liaison est activé pour le LSP statique non coloré dont le type de liste de segments est l’étiquette SID.
Par exemple :
segment-list path-3 { hop-1 label 1000011; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } source-routing-path lsp1 { to 172.16.10.1; binding-sid 333; primary { path-3; } }La configuration de la liaison SID sur la liste des segments d’étiquette n’est prise en charge que pour les LSP statiques colorés et non pour les LSP statiques non colorés.
Provisionnement LSP de segment routing statique
Le provisionnement des segments s’effectue pour chaque routeur. Pour un segment donné sur un routeur, une étiquette d’identifiant de service unique (SID) est allouée à partir d’un pool d’étiquettes souhaité, qui peut provenir du pool d’étiquettes dynamique pour une étiquette SID d’adjacence ou du bloc global de routage de segments (SRGB) pour un SID de préfixe ou un SID de nud. L’étiquette SID d’adjacence peut être allouée dynamiquement, ce qui est le comportement par défaut, ou être allouée à partir d’un pool d’étiquettes statiques local (SRLB). Une route pour l’étiquette SID est ensuite installée dans la table mpls.0.
Junos OS autorise les LSP de routage de segments statiques en configurant l’instruction segment au niveau de la [edit protocols mpls static-label-switched-path static-label-switched-path] hiérarchie. Un LSP de segment statique est identifié par une étiquette SID unique qui relève du pool d’étiquettes statiques Junos OS. Vous pouvez configurer le pool d’étiquettes statiques Junos OS en configurant l’instruction static-label-range static-label-range au niveau de la [edit protocols mpls label-range] hiérarchie.
Static Segment Routing LSP Limitations
-
Junos OS a actuellement une limitation selon laquelle le saut suivant ne peut pas être construit pour pousser plus que les étiquettes de profondeur de liste de segments maximales. Ainsi, une liste de segments avec plus d’étiquettes SID que le nombre maximal d’étiquettes (à l’exception de l’étiquette SID du premier saut qui est utilisée pour résoudre le transfert du saut suivant) n’est pas utilisable pour les LSP de routage de segments colorés ou non colorés. En outre, le nombre réel autorisé pour un LSP de routage de segment donné peut être même inférieur à la limite maximale, si un service MPLS se trouve sur le LSP de routage de segment ou si le LSP de routage de segment se trouve sur un chemin de protection de liaison ou de nud. Dans tous les cas, le nombre total d’étiquettes de service, d’étiquettes SID et d’étiquettes de protection de lien ou de nœud ne doit pas dépasser la profondeur maximale de la liste de segments. Vous pouvez configurer la limite maximale de la liste de segments au
[edit protocols source-packet-routing]niveau de la hiérarchie. Plusieurs LSP de routage de segments non colorés avec des étiquettes SID inférieures ou égales au maximum peuvent être assemblés pour construire un LSP de routage de segments plus long. C’est ce qu’on appelle l’assemblage LSP avec routage de segments. Il peut être réalisé à l’aide d’une étiquette Binding-SID. -
L’assemblage LSP de routage de segments s’effectue en fait au niveau du chemin. Si un LSP de routage de segments non coloré comporte plusieurs chemins, c’est-à-dire plusieurs listes de segments, chaque chemin peut être assemblé indépendamment à un autre LSP de routage de segments non coloré à un point d’assemblage. Un LSP de routage de segments non coloré qui est dédié à l’assemblage peut désactiver l’installation de la route d’entrée en configurant
no-ingressl’instruction au[edit protocols source-packet-routing source-routing-path lsp-name]niveau de la hiérarchie. -
Un maximum de 128 chemins principaux et 1 chemin secondaire sont pris en charge par LSP de routage de segments statique non coloré. En cas de violation de la configuration, la vérification de validation échoue avec une erreur.
-
Le nombre maximal de liaisons de liste de segments à un tunnel LSP passe de 8 à 128, avec un maximum de 1000 tunnels par système. Un maximum de 128 chemins principaux sont pris en charge par LSP de routage de segments statique. À titre de limitation, la prise en charge maximale du capteur pour le chemin LSP est de 32000 uniquement.
-
Si une liste de segments est configurée avec plus d’étiquettes que la profondeur maximale de la liste de segments, la vérification de validation de la configuration échoue avec une erreur.
Création dynamique de LSP de Segment Routing
Dans les réseaux de routage de segments où chaque périphérique Provider Edge (PE) est connecté à tous les autres périphériques PE, la configuration des chemins de commutation d’étiquettes (LSP) de segment routing nécessite une grande quantité de configuration, bien que seuls quelques chemins SR-TE (Segment Routing Traffic-Engineered Paths) puissent être utilisés. Vous pouvez activer la création dynamique de ces LSP avec BGP pour réduire la quantité de configuration dans de tels déploiements.
- Configuration du modèle LSP de routage de segments dynamique
- Résolution des prestataires de services linguistiques à Segment Routing dynamique
- Considérations relatives à la configuration de la création dynamique de LSP de segment routing
- Services pris en charge sur les LSP de Segment Routing dynamique
- Comportement avec plusieurs sources de tunnel dans le segment routing
- Limites des LSP de Segment Routing dynamique
Configuration du modèle LSP de routage de segments dynamique
Pour configurer le modèle permettant la création dynamique de LSP de routage de segments, vous devez inclure l’instruction spring-te dans la [edit routing-options dynamic-tunnels] hiérarchie.
-
Voici un exemple de configuration pour le modèle LSP de routage de segments dynamiques couleur :
[edit routing-options] dynamic-tunnels { <dynamic-tunnel-name> { spring-te { source-routing-path-template { <template-name1> color [c1 c2]; <template-name2> color [c3]; <template-name3> color-any; } destination-networks { <dest1>; <dest2>; } } } } -
Voici un exemple de configuration pour le modèle LSP de routage de segments dynamiques sans couleur :
dynamic-tunnels { <dynamic-tunnel-name> { spring-te { source-routing-path-template { <template-name1>; } destination-networks { <dest1>; <dest2>; } } } }
Résolution des prestataires de services linguistiques à Segment Routing dynamique
Résolution du LSP de routage dynamique de segments coloré
Lorsque les préfixes BGP sont affectés à la communauté de couleurs, ils sont d’abord résolus via la stratégie catch-all-route-for-that-particular-color et, à son tour, le modèle SR-TE sur lequel le préfixe BGP doit être résolu est identifié. Le SID de destination est ensuite dérivé de l’attribut next-hop du préfixe de charge utile BGP. Par exemple, si le tronçon suivant du préfixe de la charge utile BGP est une adresse IP appartenant à l’appareil A, le nœud SID de l’appareil A est pris et une étiquette correspondante est préparée et envoyée au bas de la pile. Le préfixe de la charge utile BGP est résolu en mode couleur uniquement, où le nœud SID de l’appareil A se trouve en bas de la pile d’étiquettes finale et les étiquettes de chemin SR-TE en haut.
Le nom final du modèle LSP est une combinaison de préfixe, de couleur et de nom de tunnel ; Par exemple, <prefix>:<color>:dt-srte-<tunnel-name>. La couleur du nom LSP est affichée au format hexadécimal et le format du nom du tunnel est similaire à celui des noms LSP de tunnel déclenchés par RSVP.
Pour résoudre correctement un réseau de destination coloré, la couleur doit avoir un mappage de modèle valide, soit vers une couleur spécifique, soit via le color-any modèle. Sans mappage valide, le tunnel n’est pas créé et la route BGP demandant une résolution reste non résolue.
Résolution des LSP de routage de segments dynamiques non colorés
Les routes fourre-tout pour les LSP non colorés sont ajoutées à la table de routage inet.3. La destination de tunnel non colorée doit être configurée dans une configuration différente spring-te avec un seul nom de modèle dans la liste de mappage. Ce nom de modèle est utilisé pour tous les itinéraires de tunnel correspondant à l’un des réseaux de destination configurés sous la même spring-te configuration. Ces tunnels sont similaires aux tunnels RSVP en termes de fonctionnalités.
Le nom final du modèle LSP est une combinaison de préfixe et de nom de tunnel ; Par exemple, <prefix>:dt-srte-<tunnel-name>.
Exemple de configuration LSP de segment routing dynamique
Le modèle LSP de routage de segments dynamique comporte toujours un chemin partiel. Le SID du dernier nœud de saut est dérivé automatiquement au moment de la création du tunnel, en fonction du SID du nœud PNH (Protocol Next-Hop Address). Un même modèle peut être utilisé par plusieurs tunnels vers des destinations différentes. Dans ce cas, le chemin partiel reste le même, et seul le dernier saut change en fonction de l’HPN. Les modèles LSP de routage de segments dynamiques ne sont pas communs à un seul tunnel, par conséquent, un chemin complet ne peut pas être transporté sur celui-ci. Vous pouvez utiliser une liste de segments si un chemin complet doit être utilisé.
LSP Segment Routing dynamiques colorés
Exemple de configuration pour les LSP de routage de segments dynamiques colorés :
protocols source-packet-routing {
source-routing-path-template sr_lsp1 {
primary sr_sl1
primary sr_sl2 weight 2
sr-preference 180;
}
}
dynamic-tunnels tunnel1 {
spring-te {
source-routing-path-template {
sr_lsp1 color [101 124];
sr_lsp2 color-any
}
destination-networks {
10.22.44.0/24;
}
}
}
Pour l’exemple de configuration mentionné ci-dessus, les entrées de route sont les suivantes :
-
inetcolor.0 tunnel route: 10.22.44.0-0/24 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping:
R1(préfixe) -> 10.22.44.55-101(PNH) Nom du tunnel LSP = 10.22.44.55 :65 :dt-srte-tunnel1
-
inetcolor.0 tunnel route:
10.22.44.55-101/64 --> <next-hop>
10.22.44.55-124/64 --> <next-hop>
LSP de routage de segments dynamiques non colorés
Exemple de configuration pour les LSP de routage de segments dynamiques non colorés :
protocols source-packet-routing {
source-routing-path-template sr_lsp1 {
primary sr_sl1
primary sr_sl2 weight 2
sr-preference 180;
}
}
dynamic-tunnels {
tunnel1 {
spring-te {
source-routing-path-template {
sr_lsp1 color;
}
destination-networks {
10.33.44.0/24;
}
}
}
tunnel2 {
spring-te {
source-routing-path-template {
sr_lsp1;
}
destination-networks {
10.33.44.0/24;
}
}
}
}
Pour l’exemple de configuration mentionné ci-dessus, les entrées de route sont les suivantes :
-
inet.3 tunnel route: 10.33.44.0/24 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping:
R1(préfixe) -> 10.33.44.55(PNH) Nom du modèle LSP = LSP1 --- 10.33.44.55 :dt-srte-tunnel2
-
inet.3 tunnel route: 10.33.44.55/32 --> <next-hop>
LSP Segment Routing dynamique non résolu
Exemple de configuration pour les LSP de routage de segments dynamiques non résolus :
protocols source-packet-routing {
source-routing-path-template sr_lsp1 {
primary sr_sl1
primary sr_sl2 weight 2
sr-preference 180;
}
}
dynamic-tunnels tunnel1 {
spring-te {
source-routing-path-template {
sr_lsp1 color [120 121 122 123];
}
destination-networks {
10.33.44.0/24;
10.1.1.0/24;
}
}
}
Pour l’exemple de configuration mentionné ci-dessus, les entrées de route sont les suivantes :
-
inetcolor.0 tunnel route: 10.33.44.0 - 0/24 --> RT_NH_TUNNEL 10.1.1.0 - 0 /24 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping: R1(préfixe) -> Le tunnel 10.33.44.55-124(PNH) ne sera pas créé. (Modèle introuvable pour la couleur).
Considérations relatives à la configuration de la création dynamique de LSP de segment routing
Lors de la configuration de la création dynamique de LSP de routage de segments, tenez compte des éléments suivants :
-
Un modèle peut être associé à un objet de couleur. Lorsque la configuration du tunnel
spring-tedynamique inclut un modèle avec un objet de couleur, vous devez également configurer tous les autres modèles avec des objets de couleur. Toutes les destinations sont supposées être colorées dans cette configuration. -
Un modèle peut avoir une liste de couleurs définies dessus, ou peut être configuré avec l’option
color-any. Ces deux options peuvent coexister dans la mêmespring-teconfiguration. Dans de tels cas, les modèles attribués avec des couleurs spécifiques ont une préférence plus élevée. -
Dans une
spring-teconfiguration, un seul modèle peut être défini avec l’optioncolor-any. -
Le mappage couleur-modèle est effectué sur une base individuelle. Une couleur ne peut pas être mappée à plusieurs modèles.
-
Le nom du modèle doit être configuré dans l’instruction sous la
[edit protocols]hiérarchie et l’optionspring-teprimarydoit être activée. -
Les destinations colorées et non colorées ne peuvent pas coexister dans la même
spring-teconfiguration. -
Vous ne pouvez pas configurer les mêmes réseaux de destination, avec ou sans couleur, sous des instructions de configuration différentes
spring-te. -
Dans une configuration non colorée
spring-te, un seul modèle peut être configuré sans objet de couleur.
Services pris en charge sur les LSP de Segment Routing dynamique
Les services suivants sont pris en charge par les LSP de routage de segments dynamiques colorés :
-
VPN de couche 3
-
BGP EVPN
-
Services de stratégie d’exportation
Les services suivants sont pris en charge sur les LSP de routage de segments dynamiques non colorés :
-
VPN de couche 3
-
VPN de couche 2
-
Configurations à chemins multiples
Comportement avec plusieurs sources de tunnel dans le segment routing
Lorsque deux sources téléchargent des routes vers la même destination à partir du routage de segments (par exemple, des tunnels sources statiques et dynamiques), la préférence de routage de segments est utilisée pour choisir l’entrée de route active. Plus la valeur est élevée, plus la préférence est grande. Si la préférence reste la même, la source du tunnel est utilisée pour déterminer l’entrée de route.
Limites des LSP de Segment Routing dynamique
Les LSP dynamiques SR-TE ne prennent pas en charge les caractéristiques et fonctionnalités suivantes :
-
Tunnels de routage de segments IPv6.
-
Tunnels statiques.
-
6PE n’est pas pris en charge.
-
CSPF distribué.
-
La tunnelisation sBFD et LDP n’est pas prise en charge pour les LSP SR-TE dynamiques et dans un modèle.
-
Installez les routes et les routes B-SID dans un modèle.
Mappage basé sur les couleurs des services VPN
Vous pouvez spécifier la couleur en tant que contrainte de saut suivant de protocole (en plus de l’adresse IPv4 ou IPv6) pour la résolution des tunnels de transport sur des LSP statiques colorés et SR-TE (BGP Segment Routing-Traffic-Engineer). C’est ce qu’on appelle la résolution de saut suivant du protocole IP-couleur, où vous devez configurer une carte de résolution et l’appliquer aux services VPN. Grâce à cette fonctionnalité, vous pouvez activer l’orientation du trafic basée sur les couleurs des services VPN de couche 2 et de couche 3.
Junos OS prend en charge les LSP SR-TE colorés associés à une seule couleur. La fonctionnalité de mappage coloré des services VPN est prise en charge sur les LSP colorés statiques et les LSP SR-TE BGP.
- Coloration du service VPN
- Spécification du mode de mappage du service VPN
- Résolution du prochain saut du protocole Color-IP
- Repli vers la résolution du prochain saut du protocole IP
- Mappage basé sur les couleurs unicast étiqueté BGP sur SR-TE
- Fonctionnalités prises en charge et non prises en charge pour le mappage basé sur les couleurs des services VPN
Coloration du service VPN
En général, une couleur peut être attribuée à un service VPN sur le routeur de sortie sur lequel le NLRI VPN est annoncé ou sur un routeur entrant sur lequel le NLRI VPN est reçu et traité.
Vous pouvez attribuer une couleur aux services VPN à différents niveaux :
-
Par instance de routage.
-
Par groupe BGP.
-
Par voisin BGP.
-
Par préfixe.
Une fois que vous avez attribué une couleur, celle-ci est attachée à un service VPN sous la forme d’une communauté étendue de couleurs BGP.
Vous pouvez attribuer plusieurs couleurs à un service VPN, appelés services VPN multicolores. Dans ce cas, la dernière couleur attachée est considérée comme la couleur du service VPN et toutes les autres couleurs sont ignorées.
Plusieurs couleurs sont attribuées par les équipements de sortie et/ou d’entrée par le biais de plusieurs stratégies dans l’ordre suivant :
-
Stratégie d’exportation BGP sur l’appareil sortant.
-
Stratégie d’importation BGP sur l’appareil entrant.
-
Stratégie d’importation VRF sur le périphérique d’entrée.
Les deux modes de coloration du service VPN sont les suivants :
Affectation des couleurs de sortie
Dans ce mode, l’appareil sortant (c’est-à-dire l’annonceur du NLRI VPN) est responsable de la coloration du service VPN. Pour activer ce mode, vous pouvez définir une stratégie de routage et l’appliquer dans l’instance vrf-exportde routage , l’exportation de groupe ou l’exportation de voisin de groupe du service VPN au niveau de la [edit protocols bgp] hiérarchie. Le NLRI VPN est annoncé par BGP avec la couleur spécifiée communauté étendue.
Par exemple :
[edit policy-options]
community red-comm {
members color:0:50;
}
[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}
[edit routing-instances]
vpn-X {
...
vrf-export pol-color ...;
}
Ou
Lorsque vous appliquez la stratégie de routage en tant que stratégie d’exportation d’un groupe BGP ou d’un voisin BGP, vous devez inclure l’instruction vpn-apply-export au niveau BGP, groupe BGP ou voisin BGP pour que la stratégie prenne effet sur le NLRI VPN.
[edit protocols bgp]
group PEs {
...
neighbor PE-A {
export pol-color ...;
vpn-apply-export;
}
}
Les stratégies de routage sont appliquées aux NLRI de préfixe VPN de couche 3, aux NRLI VPN de couche 2 et aux NLRI EVPN. La communauté étendue de couleur est héritée par toutes les routes VPN, importées et installées dans les VRF cibles sur un ou plusieurs périphériques entrants.
Affectation des couleurs d’entrée
Dans ce mode, le périphérique entrant (c’est-à-dire le récepteur du NLRI VPN) est responsable de la coloration du service VPN. Pour activer ce mode, vous pouvez définir une stratégie de routage et l’appliquer à l’instance vrf-importde routage , à l’importation de groupe ou à l’importation de voisin de groupe du service VPN au niveau de la [edit protocols bgp] hiérarchie. Toutes les routes VPN correspondant à la stratégie de routage sont attachées avec la communauté étendue de couleur spécifiée.
Par exemple :
[edit routing-options]
community red-comm {
members color:0:50;
}
[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}
[edit routing-instances]
vpn-Y {
...
vrf-import pol-color ...;
}
Ou
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-color ...;
}
}
Spécification du mode de mappage du service VPN
Pour spécifier des modes de mappage de service VPN flexibles, vous devez définir une stratégie à l’aide de l’instruction et faire référence à la stratégie dans l’instance vrf-importde routage , l’importation de groupe ou l’importation resolution-map de voisin de groupe d’un service VPN au niveau de la [edit protocols bgp] hiérarchie. Toutes les routes VPN correspondant à la stratégie de routage sont attachées avec la carte de résolution spécifiée.
Par exemple :
[edit policy-options]
resolution-map map-A {
<mode-1>;
<mode-2>;
...
}
policy-statement pol-resolution {
term t1 {
from {
[any match conditions];
}
then {
resolution-map map-A;
accept;
}
}
}
Vous pouvez appliquer une stratégie d’importation à l’instance de routage du service VPN.
[edit routing-instances]
vpn-Y {
...
vrf-import pol-resolution ...;
}
Vous pouvez également appliquer la stratégie d’importation à un groupe BGP ou à un voisin BGP.
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-resolution ...;
}
}
Chaque mode de mappage de service VPN doit avoir un nom unique défini dans la carte de résolution. Une seule entrée de couleur IP est prise en charge dans la carte de résolution, où la ou les routes VPN sont résolues à l’aide d’un saut suivant de protocole IP coloré sous la forme .ip-address:color
Résolution du prochain saut du protocole Color-IP
Le processus de résolution du prochain saut de protocole a été amélioré pour prendre en charge la résolution du prochain saut du protocole IP coloré. Pour un service VPN coloré, le processus de résolution du prochain saut de protocole prend une couleur et une carte de résolution, crée un saut suivant de protocole IP coloré sous la forme , et résout le prochain saut de protocole dans la table de IP-address:colorroutage inet6color.0.
Vous devez configurer une stratégie pour prendre en charge la résolution par trajets multiples des services VPN de couche 2, VPN de couche 3 ou EVPN colorés sur des LSP colorés. La stratégie doit ensuite être appliquée avec la table RIB appropriée en tant que stratégie d’importation du résolveur.
Par exemple :
[edit policy-options]
policy-statement mpath {
then multipath-resolve;
}
[edit routing-options]
resolution {
rib bgp.l3vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.l3vpn-inet6.0 {
inet6color-import mpath;
}
}
resolution {
rib bgp.l2vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib mpls.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.evpn.0 {
inetcolor-import mpath;
}
}
Repli vers la résolution du prochain saut du protocole IP
Si une carte de résolution n’est pas appliquée à un service VPN coloré, le service VPN ignore sa couleur et revient à la résolution du prochain saut du protocole IP. À l’inverse, si une carte de résolution est appliquée à un service VPN non coloré, la carte de résolution est ignorée et le service VPN utilise la résolution de saut suivant du protocole IP.
La solution de repli est un processus simple, des LSP SR-TE colorés aux LSP LDP, en utilisant un groupe RIB permettant au LDP d’installer les routes dans les tables de routage inet{6}color.0. Une correspondance de préfixe le plus long pour un saut suivant de protocole IP coloré garantit que si une route SR-TE LSP colorée n’existe pas, une route LDP avec une adresse IP correspondante doit être renvoyée.
Mappage basé sur les couleurs unicast étiqueté BGP sur SR-TE
À partir de Junos OS version 20.2R1, BGP Labeled Unicast (BGP-LU) peut résoudre les routes IPv4 ou IPv6 via Segment Routing–Traffic Engineering (SR-TE) pour les familles d’adresses IPv4 et IPv6. BGP-LU prend en charge le mappage d’une couleur de communauté BGP et la définition d’une couleur pour resolution map SR-TE. Un saut suivant de protocole coloré est construit et il est résolu sur un tunnel SR-TE coloré dans la inetcolor.0 table or inet6color.0 . BGP utilise inet.3 des tables et inet6.3 pour le mappage non basé sur les couleurs. Cela vous permet de publier des préfixes IPv6 et IPv4 BGP-LU avec une adresse de saut alternatif IPv6 dans les réseaux IPv6 uniquement où aucune adresse IPv4 n’est configurée pour les routeurs. Grâce à cette fonctionnalité, nous prenons actuellement en charge BGP IPv6 LU sur SR-TE avec sous-couche IS-IS.
En Figure 1, le contrôleur configure 4 tunnels colorés dans un réseau central IPv6 configuré avec SR-TE. Chaque tunnel coloré emprunte un chemin différent vers le routeur de destination D en fonction de la carte de résolution définie. Le contrôleur configure un tunnel SR-TE coloré vers l’interface 2001 :db8 ::3701 :2d05 dans le routeur D. BGP importe des stratégies pour affecter une carte de couleurs et de résolution au préfixe reçu 2001 :db8 ::3700 :6/128. En fonction de la couleur de la communauté attribuée, BGP-LU résout le saut suivant coloré pour le préfixe LU IPv6 BGP en fonction de la stratégie de mappage de résolution attribuée.
BGP-LU prend en charge les scénarios suivants :
-
BGP IPv4 LU sur BGP IPv4 SR-TE coloré, avec extensions ISIS/OSPF IPv4 SR.
-
LU IPv4 BGP sur SR-TE IPv4 statique coloré et non coloré, avec extensions ISIS/OSPF IPv4 SR.
-
BGP IPv6 LU sur BGP IPv6 SR-TE coloré, avec extensions ISIS IPv6 SR.
-
LU BGP IPv6 sur SR-TE IPv6 statique coloré et non coloré, avec extensions ISIS IPv6 SR.
-
Services VPN de couche 3 IPv6 avec adresse locale IPv6 et adresse voisine IPv6.
-
Services VPN IPv6 de couche 3 sur BGP IPv6 SR-TE, avec extensions ISIS IPv6 SR.
-
Services VPN IPv6 de couche 3 sur SR-TE IPv6 statique et non coloré, avec extensions ISIS IPv6 SR.
Fonctionnalités prises en charge et non prises en charge pour le mappage basé sur les couleurs des services VPN
Les caractéristiques et fonctionnalités suivantes sont prises en charge avec le mappage basé sur les couleurs des services VPN :
-
VPN de couche 2 BGP (VPN de couche 2 de Kompella)
-
BGP EVPN
-
Carte de résolution avec une seule option de couleur IP.
-
Résolution de saut suivant des protocoles IPv4 et IPv6 en couleur.
-
Base d’informations de routage (également appelée table de routage) repli basé sur le groupe LDP LSP dans la table de routage inetcolor.0.
-
SR-TE LSP coloré.
-
Plates-formes virtuelles.
-
Junos OS 64 bits.
-
Systèmes logiques.
-
Unicast étiqueté BGP.
Les caractéristiques et fonctionnalités suivantes ne sont pas prises en charge avec le mappage basé sur les couleurs des services VPN :
-
LSP MPLS colorés, tels que RSVP, LDP, BGP-LU, statiques.
-
Circuit de couche 2
-
VPN de couche 2 BGP FEC-129 auto-découvert et signalé par LDP.
-
VPLS
-
MVPN (en anglais)
-
IPv4 et IPv6 à l’aide de resolution-map.
Modèles de tunnel pour les prestataires de services linguistiques Segment Routing initiés par PCE
Vous pouvez configurer un modèle de tunnel pour les LSP de routage de segments initiés par PCE afin de leur transmettre deux paramètres supplémentaires : la détection de transfert bidirectionnel (BFD) et la tunnelisation LDP.
Lorsqu’un LSP de routage de segments initié par PCE est créé, il est vérifié par rapport aux instructions de stratégie (le cas échéant) et, s’il existe une correspondance, la stratégie applique le modèle configuré pour ce LSP. La configuration du modèle n’est héritée que si elle n’est pas fournie par la source LSP (PCEP) ; par exemple, métrique.
Pour configurer un modèle :
-
Incluez l’instruction source-routing-path-template au niveau de la
[edit protocols source-packet-routing]hiérarchie. Vous pouvez configurer les paramètres de tunnelisation BFD et LDP supplémentaires ici. -
Incluez l’instruction source-routing-path-template-map au niveau de la hiérarchie pour répertorier les instructions de
[edit protocols source-packet-routing]stratégie par rapport auxquelles le LSP initié par PCE doit être vérifié. -
Définissez une stratégie pour répertorier les prestataires de services linguistiques sur lesquels le modèle doit être appliqué.
L’instruction
frompeut inclure le nom LSP ou l’expression régulière LSP à l’aide des conditions delspcorrespondance etlsp-regex. Ces options s’excluent mutuellement, de sorte que vous ne pouvez spécifier qu’une seule option à un moment donné.L’instruction
thendoit inclure l’option avec une action d’acceptationsr-te-template. Le modèle s’applique alors au prestataire de services linguistiques initié par PCE.
Tenez compte des éléments suivants lors de la configuration d’un modèle pour les prestataires de services linguistiques initiés par PCE :
-
La configuration du modèle ne s’applique pas aux LSP de routage de segments configurés de manière statique, ni aux LSP de routage de segments d’un autre client.
-
La configuration fournie par PCEP est prioritaire sur la configuration du modèle.
-
PCEP LSP n’hérite pas de la configuration de liste de segments de modèle.
Exemple : configuration du chemin de commutation d’étiquette de segment routing statique
Cet exemple montre comment configurer les chemins de commutation d’étiquettes de routage de segments statiques (LSP) dans les réseaux MPLS. Cette configuration permet d’apporter une plus grande évolutivité aux réseaux MPLS.
Conditions préalables
Cet exemple utilise les composants matériels et logiciels suivants :
-
Sept plates-formes de routage universelles 5G MX Series
-
Junos OS version 18.1 ou ultérieure s’exécutant sur tous les routeurs
Avant de commencer, assurez-vous de configurer les interfaces de l’appareil.
Présentation
Junos OS, un ensemble de chemins de routage de segments explicites, est configuré sur le routeur entrant d’un tunnel de routage de segments statique non coloré en configurant l’instruction segment-list au niveau de la [edit protocols source-packet-routing] hiérarchie. Vous pouvez configurer le tunnel de routage de segments en configurant l’instruction au [edit protocols source-packet-routing] niveau de la source-routing-path hiérarchie. Le tunnel de routage de segments dispose d’une adresse de destination et d’un ou plusieurs chemins principaux et, éventuellement, de chemins secondaires qui font référence à la liste des segments. Chaque liste de segments se compose d’une séquence de sauts. Pour les tunnels de routage de segments statiques non colorés, le premier saut de la liste des segments spécifie une adresse IP de saut suivant immédiat et le second jusqu’au Nième saut spécifie les étiquettes d’identification de segment (SID) correspondant au lien ou au nœud traversé par le chemin. La route vers la destination du tunnel de routage de segments est installée dans la table inet.3.
Topologie
Dans cet exemple, configurez le VPN de couche 3 sur les routeurs de périphérie PE1 et PE5. Configurez le protocole MPLS sur tous les routeurs. Le tunnel de routage de segments est configuré du routeur PE1 au routeur PE5 avec un chemin principal configuré sur les routeurs PE1 et PE5 . Le routeur PE1 est également configuré avec un chemin secondaire pour la protection des chemins. Les routeurs de transit PE2 à PE4 sont configurés avec des étiquettes SID d’adjacence avec étiquette pop et une interface sortante.
Configuration
- Configuration rapide de l’interface de ligne de commande
- Configuration de l’équipement PE1
- Configuration de l’équipement PE2
- Résultats
Configuration rapide de l’interface de ligne de commande
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.
PE1
set interfaces ge-0/0/0 unit 0 family inet address 10.10.12.1/24 set interfaces ge-0/0/0 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/1 unit 0 family inet address 10.10.13.1/24 set interfaces ge-0/0/1 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/5 unit 0 family inet address 10.10.17.1/24 set routing-options autonomous-system 65000 set routing-options forwarding-table export load-balance-policy set routing-options forwarding-table chained-composite-next-hop ingress l3vpn set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols bgp group pe type internal set protocols bgp group pe local-address 192.168.147.211 set protocols bgp group pe family inet-vpn unicast set protocols bgp group pe neighbor 192.168.146.181 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols source-packet-routing segment-list sl-15-primary hop-1 ip-address 10.10.13.3 set protocols source-packet-routing segment-list sl-15-primary hop-2 label 1000134 set protocols source-packet-routing segment-list sl-15-primary hop-3 label 1000145 set protocols source-packet-routing segment-list sl-15-backup hop-1 ip-address 10.10.12.2 set protocols source-packet-routing segment-list sl-15-backup hop-2 label 1000123 set protocols source-packet-routing segment-list sl-15-backup hop-3 label 1000134 set protocols source-packet-routing segment-list sl-15-backup hop-4 label 1000145 set protocols source-packet-routing source-routing-path lsp-15 to 192.168.146.181 set protocols source-packet-routing source-routing-path lsp-15 binding-sid 1000999 set protocols source-packet-routing source-routing-path lsp-15 primary sl-15-primary set protocols source-packet-routing source-routing-path lsp-15 secondary sl-15-backup set policy-options policy-statement VPN-A-export term a from protocol ospf set policy-options policy-statement VPN-A-export term a from protocol direct set policy-options policy-statement VPN-A-export term a then community add VPN-A set policy-options policy-statement VPN-A-export term a then accept set policy-options policy-statement VPN-A-export term b then reject set policy-options policy-statement VPN-A-import term a from protocol bgp set policy-options policy-statement VPN-A-import term a from community VPN-A set policy-options policy-statement VPN-A-import term a then accept set policy-options policy-statement VPN-A-import term b then reject set policy-options policy-statement bgp-to-ospf from protocol bgp set policy-options policy-statement bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set policy-options policy-statement bgp-to-ospf then accept set policy-options policy-statement load-balance-policy then load-balance per-packet set policy-options community VPN-A members target:65000:1 set routing-instances VRF1 instance-type vrf set routing-instances VRF1 interface ge-0/0/5.0 set routing-instances VRF1 route-distinguisher 192.168.147.211:1 set routing-instances VRF1 vrf-import VPN-A-import set routing-instances VRF1 vrf-export VPN-A-export set routing-instances VRF1 vrf-table-label set routing-instances VRF1 protocols ospf export bgp-to-ospf set routing-instances VRF1 protocols ospf area 0.0.0.0 interface ge-0/0/5.0
PE2
set interfaces ge-0/0/0 unit 0 family inet address 10.10.12.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.10.23.2/24 set interfaces ge-0/0/1 unit 0 family mpls set protocols mpls static-label-switched-path adj-23 segment 1000123 set protocols mpls static-label-switched-path adj-23 segment next-hop 10.10.23.3 set protocols mpls static-label-switched-path adj-23 segment pop set protocols mpls static-label-switched-path adj-21 segment 1000221 set protocols mpls static-label-switched-path adj-21 segment next-hop 10.10.12.1 set protocols mpls static-label-switched-path adj-21 segment pop set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
PE3
set interfaces ge-0/0/0 unit 0 family inet address 10.10.13.3/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.10.23.3/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 10.10.34.3/24 set interfaces ge-0/0/2 unit 0 family mpls set protocols mpls static-label-switched-path adj-34 segment 1000134 set protocols mpls static-label-switched-path adj-34 segment next-hop 10.10.34.4 set protocols mpls static-label-switched-path adj-34 segment pop set protocols mpls static-label-switched-path adj-32 segment 1000232 set protocols mpls static-label-switched-path adj-32 segment next-hop 10.10.23.2 set protocols mpls static-label-switched-path adj-32 segment pop set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
PE4
set interfaces ge-0/0/2 unit 0 family inet address 10.10.34.4/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 10.10.45.4/24 set interfaces ge-0/0/3 unit 0 family mpls set protocols mpls static-label-switched-path adj-45 segment 1000145 set protocols mpls static-label-switched-path adj-45 segment next-hop 10.10.45.5 set protocols mpls static-label-switched-path adj-45 segment pop set protocols mpls static-label-switched-path adj-43 segment 1000243 set protocols mpls static-label-switched-path adj-43 segment next-hop 10.10.34.3 set protocols mpls static-label-switched-path adj-43 segment pop set protocols mpls interface ge-0/0/2.0 set protocols mpls interface ge-0/0/3.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0
PE5
set interfaces ge-0/0/3 unit 0 family inet address 10.10.45.5/24 set interfaces ge-0/0/3 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/4 unit 0 family inet address 10.10.56.5/24 set routing-options autonomous-system 65000 set protocols mpls interface ge-0/0/3.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols bgp group pe type internal set protocols bgp group pe local-address 192.168.146.181 set protocols bgp group pe family inet-vpn unicast set protocols bgp group pe neighbor 192.168.147.211 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols bfd sbfd local-discriminator 0.0.0.32 minimum-receive-interval 1000 set protocols source-packet-routing segment-list sl-51 hop-1 ip-address 10.10.45.4 set protocols source-packet-routing segment-list sl-51 hop-2 label 1000243 set protocols source-packet-routing segment-list sl-51 hop-3 label 1000232 set protocols source-packet-routing segment-list sl-51 hop-4 label 1000221 set protocols source-packet-routing source-routing-path lsp-51 to 192.168.147.211 set protocols source-packet-routing source-routing-path lsp-51 primary sl-51 set policy-options policy-statement VPN-A-export term a from protocol ospf set policy-options policy-statement VPN-A-export term a from protocol direct set policy-options policy-statement VPN-A-export term a then community add VPN-A set policy-options policy-statement VPN-A-export term a then accept set policy-options policy-statement VPN-A-export term b then reject set policy-options policy-statement VPN-A-import term a from protocol bgp set policy-options policy-statement VPN-A-import term a from community VPN-A set policy-options policy-statement VPN-A-import term a then accept set policy-options policy-statement VPN-A-import term b then reject set policy-options policy-statement bgp-to-ospf from protocol bgp set policy-options policy-statement bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set policy-options policy-statement bgp-to-ospf then accept set policy-options community VPN-A members target:65000:1 set routing-instances VRF1 instance-type vrf set routing-instances VRF1 interface ge-0/0/4.0 set routing-instances VRF1 route-distinguisher 192.168.146.181:1 set routing-instances VRF1 vrf-import VPN-A-import set routing-instances VRF1 vrf-export VPN-A-export set routing-instances VRF1 vrf-table-label set routing-instances VRF1 protocols ospf export bgp-to-ospf set routing-instances VRF1 protocols ospf area 0.0.0.0 interface ge-0/0/4.0
CE1
set interfaces ge-0/0/0 unit 0 family inet address 10.10.17.7/24 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
CE2
set interfaces ge-0/0/4 unit 0 family inet address 10.10.56.6/24 set protocols ospf area 0.0.0.0 interface ge-0/0/4.0
Configuration de l’équipement PE1
Procédure étape par étape
L’exemple suivant nécessite que vous naviguiez à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.
Pour configurer l’appareil PE1 :
-
Configurez les interfaces.
[edit interfaces] set ge-0/0/0 unit 0 family inet address 10.10.12.1/24 set ge-0/0/0 unit 0 family mpls maximum-labels 5 set ge-0/0/1 unit 0 family inet address 10.10.13.1/24 set ge-0/0/1 unit 0 family mpls maximum-labels 5 set ge-0/0/5 unit 0 family inet address 10.10.17.1/24
-
Configurez le numéro et les options du système autonome pour contrôler les options de routage de transfert de paquets.
[edit routing-options] set autonomous-system 65000 set forwarding-table export load-balance-policy set forwarding-table chained-composite-next-hop ingress l3vpn
-
Configurez les interfaces avec le protocole MPLS et configurez la plage d’étiquettes MPLS.
[edit protocols mpls] set interface ge-0/0/0.0 set interface ge-0/0/1.0 set label-range static-label-range 1000000 1000999
-
Configurez le type de groupe d’homologues, l’adresse locale, la famille de protocoles pour les NLRI dans les mises à jour et l’adresse IP d’un voisin pour le groupe d’homologues.
[edit protocols bgp] set group pe type internal set group pe local-address 192.168.147.211 set group pe family inet-vpn unicast set group pe neighbor 192.168.146.181
-
Configurez les interfaces de la zone de protocole.
[edit protocols ospf] set area 0.0.0.0 interface ge-0/0/0.0 set area 0.0.0.0 interface lo0.0 set area 0.0.0.0 interface ge-0/0/1.0
-
Configurez l’adresse IPv4 et les étiquettes des chemins primaire et secondaire pour les stratégies de routage source et d’ingénierie du trafic TE (Protocol Source Packet Routing).
[edit protocols source-packet-routing segment-list] set sl-15-primary hop-1 ip-address 10.10.13.3 set sl-15-primary hop-2 label 1000134 set sl-15-primary hop-3 label 1000145 set sl-15-backup hop-1 ip-address 10.10.12.2 set sl-15-backup hop-2 label 1000123 set sl-15-backup hop-3 label 1000134 set sl-15-backup hop-4 label 1000145
-
Configurez l’adresse IPv4 de destination, l’étiquette SID de liaison, ainsi que le chemin de routage source primaire et secondaire pour le protocole SPRING.
[edit protocols source-packet-routing source-routing-path] set lsp-15 to 192.168.146.181 set lsp-15 binding-sid 1000999 set lsp-15 primary sl-15-primary set lsp-15 secondary sl-15-backup
-
Configurez les options de stratégie.
[edit policy-options policy-statement] set VPN-A-export term a from protocol ospf set VPN-A-export term a from protocol direct set VPN-A-export term a then community add VPN-A set VPN-A-export term a then accept set VPN-A-export term b then reject set VPN-A-import term a from protocol bgp set VPN-A-import term a from community VPN-A set VPN-A-import term a then accept set VPN-A-import term b then reject set bgp-to-ospf from protocol bgp set bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set bgp-to-ospf then accept set load-balance-policy then load-balance per-packet
-
Configurez les informations de la communauté BGP.
[edit policy-options] set community VPN-A members target:65000:1
-
Configurez l’instance de routage VRF1 avec le type d’instance, l’interface, le distinguateur de routeur, l’importation, l’exportation et l’étiquette de table VRF. Configurez la stratégie d’exportation et l’interface de la zone pour le protocole OSPF.
[edit routing-instances VRF1] set instance-type vrf set interface ge-0/0/5.0 set route-distinguisher 192.168.147.211:1 set vrf-import VPN-A-import set vrf-export VPN-A-export set vrf-table-label set protocols ospf export bgp-to-ospf set protocols ospf area 0.0.0.0 interface ge-0/0/5.0
Résultats
À partir du mode de configuration, confirmez votre configuration en saisissant les commandes show interfaces, show policy-options, show protocols, show routing-options et show routing-instances. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
[edit]
user@PE1# show
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.10.12.1/24;
}
family mpls {
maximum-labels 5;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.10.13.1/24;
}
family mpls {
maximum-labels 5;
}
}
}
ge-0/0/5 {
unit 0 {
family inet {
address 10.10.17.1/24;
}
}
}
}
policy-options {
policy-statement VPN-A-export {
term a {
from protocol [ ospf direct ];
then {
community add VPN-A;
accept;
}
}
term b {
then reject;
}
}
policy-statement VPN-A-import {
term a {
from {
protocol bgp;
community VPN-A;
}
then accept;
}
term b {
then reject;
}
}
policy-statement bgp-to-ospf {
from {
protocol bgp;
route-filter 10.10.0.0/16 orlonger;
}
then accept;
}
policy-statement load-balance-policy {
then {
load-balance per-packet;
}
}
community VPN-A members target:65000:1;
}
routing-instances {
VRF1 {
instance-type vrf;
protocols {
ospf {
area 0.0.0.0 {
interface ge-0/0/5.0;
}
export bgp-to-ospf;
}
}
interface ge-0/0/5.0;
route-distinguisher 192.168.147.211:1;
vrf-import VPN-A-import;
vrf-export VPN-A-export;
vrf-table-label;
}
}
routing-options {
autonomous-system 65000;
forwarding-table {
export load-balance-policy;
chained-composite-next-hop {
ingress {
l3vpn;
}
}
}
}
protocols {
bgp {
group pe {
type internal;
local-address 192.168.147.211;
family inet-vpn {
unicast;
}
neighbor 192.168.146.181;
}
}
mpls {
label-range {
static-label-range 1000000 1000999;
}
interface ge-0/0/0.0;
interface ge-0/0/1.0;
}
ospf {
area 0.0.0.0 {
interface ge-0/0/0.0;
interface lo0.0;
interface ge-0/0/1.0;
}
}
source-packet-routing {
segment-list sl-15-primary {
hop-1 ip-address 10.10.13.3;
hop-2 label 1000134;
hop-3 label 1000145;
}
segment-list sl-15-backup {
hop-1 ip-address 10.10.12.2;
hop-2 label 1000123;
hop-3 label 1000134;
hop-4 label 1000145;
}
source-routing-path lsp-15 {
to 192.168.146.181;
binding-sid 1000999;
primary {
sl-15-primary;
}
secondary {
sl-15-backup;
}
}
}
}
Configuration de l’équipement PE2
Procédure étape par étape
L’exemple suivant nécessite que vous naviguiez à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.
-
Configurez les interfaces.
[edit interfaces] set ge-0/0/0 unit 0 family inet address 10.10.12.2/24 set ge-0/0/0 unit 0 family mpls set ge-0/0/1 unit 0 family inet address 10.10.23.2/24 set ge-0/0/1 unit 0 family mpls
-
Configurez le LSP statique pour le protocole MPLS.
[edit protocols mpls static-label-switched-path] set adj-23 segment 1000123 set adj-23 segment next-hop 10.10.23.3 set adj-23 segment pop set adj-21 segment 1000221 set adj-21 segment next-hop 10.10.12.1 set adj-21 segment pop
-
Configurez les interfaces et la plage d’étiquettes statiques pour le protocole MPLS.
[edit protocols mpls] set interface ge-0/0/0.0 set interface ge-0/0/1.0 set label-range static-label-range 1000000 1000999
-
Configurez les interfaces pour le protocole OSPF.
[edit protocols ospf area 0.0.0.0] set interface ge-0/0/0.0 set interface ge-0/0/1.0
Résultats
À partir du mode de configuration sur le routeur PE2, confirmez votre configuration en entrant les show interfaces commandes and show protocols . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
[edit]
user@PE2# show
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.10.12.2/24;
}
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.10.23.2/24;
}
family mpls;
}
}
}
protocols {
mpls {
label-range {
static-label-range 1000000 1000999;
}
interface ge-0/0/0.0;
interface ge-0/0/1.0;
static-label-switched-path adj-23 {
segment {
1000123;
next-hop 10.10.23.3;
pop;
}
}
static-label-switched-path adj-21 {
segment {
1000221;
next-hop 10.10.12.1;
pop;
}
}
}
ospf {
area 0.0.0.0 {
interface ge-0/0/0.0;
interface ge-0/0/1.0;
}
}
}Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification de l’entrée de route de la table de routage inet.3 du routeur PE1
- Vérification des entrées de la table de routage de la table de routage mpls.0 du routeur PE1
- Vérification du LSP d’ingénierie de trafic SPRING du routeur PE1
- Vérification des LSP SPRING Traffic Engineered sur le routeur d’entrée du routeur PE1
- Vérification des entrées de la table de routage de la table de routage mpls.0 du routeur PE2
- Vérification de l’état des segments LSP MPLS statiques du routeur PE2
Vérification de l’entrée de route de la table de routage inet.3 du routeur PE1
But
Vérifiez l’entrée de route de la table de routage inet.3 du routeur PE1.
Action
À partir du mode opérationnel, entrez la show route table inet.3 commande.
user@PE1> show route table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.146.181/32 *[SPRING-TE/8] 03:09:26, metric 1
> to 10.10.13.3 via ge-0/0/1.0, Push 1000145, Push 1000134(top)
to 10.10.12.2 via ge-0/0/0.0, Push 1000145, Push 1000134, Push 1000123(top)Sens
La sortie affiche les routes d’entrée des tunnels de routage de segments.
Vérification des entrées de la table de routage de la table de routage mpls.0 du routeur PE1
But
Vérifiez les entrées de route de la table de routage mpls.0
Action
À partir du mode opérationnel, entrez la show route table mpls.0 commande.
user@PE1> show route table mpls.0
mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 03:25:52, metric 1
Receive
1 *[MPLS/0] 03:25:52, metric 1
Receive
2 *[MPLS/0] 03:25:52, metric 1
Receive
13 *[MPLS/0] 03:25:52, metric 1
Receive
16 *[VPN/0] 03:25:52
> via lsi.0 (VRF1), Pop
1000999 *[SPRING-TE/8] 03:04:03, metric 1
> to 10.10.13.3 via ge-0/0/1.0, Swap 1000145, Push 1000134(top)
to 10.10.12.2 via ge-0/0/0.0, Swap 1000145, Push 1000134, Push 1000123(top)
Sens
La sortie affiche les étiquettes SID des tunnels de routage de segments.
Vérification du LSP d’ingénierie de trafic SPRING du routeur PE1
But
Vérifiez les LSP d’ingénierie de trafic SPRING sur les routeurs entrants.
Action
À partir du mode opérationnel, entrez la show spring-traffic-engineering overview commande.
user@PE1> show spring-traffic-engineering overview
Overview of SPRING-TE:
Route preference: 8
Number of LSPs: 1 (Up: 1, Down: 0)
External controllers:
< Not configured >
Sens
La sortie affiche la vue d’ensemble des LSP d’ingénierie de trafic SPRING sur le routeur entrant.
Vérification des LSP SPRING Traffic Engineered sur le routeur d’entrée du routeur PE1
But
Vérifiez les LSP d’ingénierie de trafic SPRING sur le routeur entrant.
Action
À partir du mode opérationnel, entrez la show spring-traffic-engineering lsp detail commande.
user@PE1# show spring-traffic-engineering lsp detail
Name: lsp-15
To: 192.168.146.181
State: Up
Path: sl-15-primary
Outgoing interface: ge-0/0/1.0
BFD status: N/A (Up: 0, Down: 0)
SR-ERO hop count: 3
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.10.13.3
SID type: None
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000134
Hop 3 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000145
Path: sl-15-backup
Outgoing interface: ge-0/0/0.0
BFD status: N/A (Up: 0, Down: 0)
SR-ERO hop count: 4
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.10.12.2
SID type: None
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000123
Hop 3 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000134
Hop 4 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000145
Total displayed LSPs: 1 (Up: 1, Down: 0)Sens
La sortie affiche les détails des LSP SPRING sur le routeur entrant
Vérification des entrées de la table de routage de la table de routage mpls.0 du routeur PE2
But
Vérifiez les entrées de la table de routage de la table de routage mpls.0 du routeur PE2.
Action
À partir du mode opérationnel, entrez la show route table mpls.0 commande.
user@PE2> show route table mpls.0
mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 03:22:29, metric 1
Receive
1 *[MPLS/0] 03:22:29, metric 1
Receive
2 *[MPLS/0] 03:22:29, metric 1
Receive
13 *[MPLS/0] 03:22:29, metric 1
Receive
1000123 *[MPLS/6] 03:22:29, metric 1
> to 10.10.23.3 via ge-0/0/1.0, Pop
1000123(S=0) *[MPLS/6] 03:22:29, metric 1
> to 10.10.23.3 via ge-0/0/1.0, Pop
1000221 *[MPLS/6] 03:22:29, metric 1
> to 10.10.12.1 via ge-0/0/0.0, Pop
1000221(S=0) *[MPLS/6] 03:22:29, metric 1
> to 10.10.12.1 via ge-0/0/0.0, PopVérification de l’état des segments LSP MPLS statiques du routeur PE2
But
Vérifiez l’état des segments MPLS LSP du routeur PE2.
Action
À partir du mode opérationnel, entrez la show mpls static-lsp commande.
user@PE2> show mpls static-lsp
Ingress LSPs:
Total 0, displayed 0, Up 0, Down 0
Transit LSPs:
Total 0, displayed 0, Up 0, Down 0
Bypass LSPs:
Total 0, displayed 0, Up 0, Down 0
Segment LSPs:
LSPname SID-label State
adj-21 1000221 Up
adj-23 1000123 Up
Total 2, displayed 2, Up 2, Down 0Sens
La sortie affiche l’état des segments MPLS LSP statiques du routeur PE2.
S-BFD basé sur le moteur de routage pour l’ingénierie du trafic de routage de segments avec résolution d’étiquette par premier saut
Vous pouvez exécuter la détection de transfert bidirectionnel (S-BFD) transparente sur des chemins de commutation d’étiquettes (LSP) colorés et non colorés avec une résolution d’étiquette de 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-based pour l’ingénierie du trafic de routage de segments avec la résolution d’étiquette à premier saut
- Configuration de S-BFD basé sur RE-based pour l’ingénierie du trafic de routage de segments avec résolution d’étiquette de premier saut
- Exemple
- Vérifiez que les LSP sont configurés pour les tunnels de routage de segments statiques et que l’état de la session S-BFD est visible
- Vérifier l’itinéraire du tunnel de routage de segments avec un tronçon suivant principal et un tronçon suivant secondaire
- Vérifier la session S-BFD du chemin d’accès principal
Comprendre le S-BFD basé sur RE-based pour l’ingénierie du trafic de routage de segments avec la résolution d’étiquette à premier saut
- Tunnels de routage de segments statiques S-BFD pour les étiquettes de premier saut
- Limitations
- Dérivation automatique du discriminateur à distance (RD) pour la session SBFD
Tunnels de routage de segments statiques S-BFD pour les étiquettes de premier saut
L’architecture de routage de segments permet aux nuds entrants d’un réseau central d’orienter le trafic via des chemins explicites à travers le réseau. Le tronçon suivant d’ingénierie du trafic de routage de segments (TE) est une ou plusieurs listes d’identificateurs de segment (SID). Ces listes de segments représentent les chemins du réseau que vous souhaitez que le trafic entrant emprunte. Le trafic entrant peut être étiqueté ou trafic IP et l’opération de transfert au niveau du nœud entrant peut être un échange d’étiquettes ou une recherche basée sur la destination pour diriger le trafic sur ces chemins TE de routage de segments dans le chemin de transfert.
Vous pouvez exécuter le BFD TRANSPARENT (S-BFD) sur des LSP de routage de segments statiques colorés et non colorés avec une résolution d’étiquette de premier saut et utiliser le S-BFD comme mécanisme rapide pour détecter les défaillances de chemin et déclencher une convergence globale. S-BFD nécessite moins de changements d’état que BFD, ce qui accélère la génération de rapports sur les défaillances de chemin.
Dans le cas d’un tunnel de routage de segments avec un ou plusieurs LSP principaux et, éventuellement, un LSP secondaire, vous pouvez activer S-BFD sur n’importe lequel de ces LSP. En cas de défaillance d’une session S-BFD, le logiciel met à jour le routage du tunnel de routage de segments en supprimant les sauts suivants des LSP ayant échoué. Si l’étiquette first-hop 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 sous-jacente de l’échec d’accessibilité du saut suivant doit être plus rapide que la durée du temporisateur de détection S-BFD).
Ce modèle est pris en charge pour les LSP dérivés de la traduction automatique.
S-BFD de niveau LSP
Une session S-BFD est créée pour chaque combinaison unique étiquette-pile + famille d’adresses. Vous pouvez configurer des listes de segments identiques et activer S-BFD pour chacune d’entre elles. Les listes de segments qui ont des combinaisons identiques d’étiquettes-pile+famille d’adresses 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) sous l’instance principale.
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 « à » dans le tunnel TE à routage de segments. L’état du LSP avec S-BFD configuré dépend également du fait que BFD est actif ou non : 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 est actif.
Paramètres S-BFD
Les paramètres S-BFD suivants sont pris en charge pour les chemins TE de routage de segments :
-
Discriminateur à distance
-
Intervalle minimum
-
Multiplicateur
-
Pas d’option d’alerte de routeur
Dans S-BFD, chaque répondant peut avoir plusieurs discriminateurs. Les discriminateurs peuvent être annoncés par IGP à d’autres routeurs, ou ils peuvent être configurés de manière statique sur ces routeurs. Sur un initiateur, un discriminateur particulier est choisi comme discriminateur distant pour une session S-BFD par configuration statique, en fonction de la décision ou de la résolution prise par vous ou par un contrôleur central. Lorsque plusieurs LSP sont créés avec la même pile d’étiquettes de 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 discriminateur, 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 n’a pas d’alerte de routeur est configurée, le paramètre S-BFD dérivé n’aura pas d’option d’alerte de routeur.
Limitations
-
Seule la réparation globale est prise en charge.
-
Même si S-BFD détecte les défaillances en fonction des valeurs de temporisation configurées, le temps de convergence dépend du temps de réparation global (seconds).
Dérivation automatique du discriminateur à distance (RD) pour la session SBFD
À partir de Junos OS version 22.4R1, vous pouvez utiliser le discriminateur à distance auto-dérivé pour les sessions SBFD pour les chemins SR-TE. Avec cette fonctionnalité, vous n’avez pas besoin de configurer un dans la configuration SFBD sur le périphérique d’entrée ou de transit et un remote-discriminator discriminateur local correspondant sur son point de terminaison respectif. Au lieu de cela, l’équipement PE de sortie accepte désormais les adresses IP comme discriminateur local. Pour autoriser l’adresse IP en tant que discriminateur local dans BFD, utilisez la set protocols bfd sbfd local-discriminator-ip configuration.
Vous pouvez également utiliser un modèle SBFD commun avec les configurations SBFD sur les stratégies SR-TE provisionnées à plusieurs contrôleurs. Dans ces sessions SBFD, Junos OS dérive automatiquement le discriminateur distant du point de terminaison du tunnel pour faire correspondre les stratégies SR-TE.
-
Nous prenons en charge la dérivation automatique de RD uniquement pour les points de terminaison IPv4, et non pour les points de terminaison IPv6.
-
Nous ne prenons pas en charge la dérivation automatique de RD pour les tunnels de couleur uniquement. Si RD n’est pas configuré (par dérivation automatique de RD) pour les tunnels SR-TE couleur uniquement configurés statiquement, le système affichera une erreur de validation. Si RD n’est pas configuré (par dérivation automatique de RD) pour les tunnels dynamiques de couleur uniquement à l’aide de la configuration de modèle SR-TE, Junos OS ignore la configuration sbfd pour ce tunnel.
Configuration de S-BFD basé sur RE-based pour l’ingénierie du trafic de routage de segments avec résolution d’étiquette de premier saut
Pour activer le S-BFD de niveau LSP pour une liste de segments, vous devez configurer l’instruction bfd-liveness-detection de configuration au niveau de la hiérarchie et de la [edit protocols source-packet-routing source-routing-path lsp-path-name primary segment-list-name] [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, puis le fonctionnement de S-BFD avec une résolution d’étiquette de premier saut :
Les étapes ci-dessous décrivent les grandes lignes de la configuration de base :
Sur un routeur 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 principaux et secondaires.
Sur le routeur 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 suivants dérivés des étiquettes du premier saut des LSP contributeurs.
Sur le routeur entrant, vous activez l’équilibrage de charge par paquet afin que les routes qui se résolvent sur les routes d’entrée et la route de liaison SID (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 un LSP protège toutes les routes qui utilisent ce LSP.
Sur le routeur de sortie du tunnel de routage de segment, vous configurez le mode de réponse S-BFD avec un discriminateur local D, créant ainsi une session d’écoute S-BFD distribuée pour D sur chaque FPC.
Sur le routeur entrant, vous configurez S-BFD pour tout LSP pour lequel vous souhaitez voir la détection de défaillance de chemin. Vous spécifiez un discriminateur distant D pour correspondre au discriminateur S-BFD local 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. Dans le cas d’une session BFD correspondante, les paramètres S-BFD sont réévalués en tenant compte des nouveaux LSP partagés. 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 :
La session d’initiateur S-BFD s’exécute en mode centralisé sur le moteur de routage. Le logiciel suit les états ascendants et descendants de la session S-BFD.
Lorsque l’état S-BFD passe à UP, le LSP est pris en compte pour les routes concernées.
Sur le routeur entrant, si le logiciel détecte une session S-BFD DOWN , une notification d’arrêt de session est envoyée au démon de routage (RPD) et RPD supprime le saut suivant des LSP défaillants de la route du tunnel de routage de segment.
La perte totale de trafic dans la procédure est liée au temps de détection de la défaillance S-BFD et au temps de réparation global. Le temps de détection des défaillances S-BFD est déterminé par les paramètres d’intervalle minimum et de multiplicateur S-BFD. Le temps de réparation global dépend du temps de traitement TE du routage de segments et du retéléchargement des routes vers le transfert.
Les piles d’étiquettes LSP sont modifiées comme suit :
Le LSP particulier est détaché de la session S-BFD existante. Si au moins un LSP fait référence à la session S-BFD existante, l’ancienne session BFD est conservée, mais les paramètres S-BFD sont réévalués afin que les valeurs de paramètre agressives parmi les sessions LSP existantes soient choisies. De plus, le nom de la session S-BFD est mis à jour au moins un s’il y a un changement. Si aucun LSP n’est rattaché à l’ancienne session S-BFD, cette session S-BFD est supprimée.
Le logiciel tente de trouver une session BFD existante qui correspond à la valeur de 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 session, de la même manière que les réévaluations de l’étape 1.
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 minimum et le multiplicateur d’une session S-BFD déterminent le temps de détection des défaillances de la session. Le temps de réparation dépend en outre du temps de réparation global.
La sortie suivante montre les instructions de configuration que vous utiliseriez pour un LSP coloré avec des LSP principaux :
[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;
... {
bfd-liveness-detection {
sbfd {
remote-discriminator value;
}
}
}
}
}
Du côté du répondeur, vous devez configurer le discriminateur correct :
[edit protocols bfd]
sbfd {
local-discriminator value;
}
Par défaut, les alertes de routeur sont configurées pour les paquets S-BFD. Lorsque l’en-tête MPLS est supprimé du côté du répondeur, le paquet est envoyé à l’hôte pour traitement sans recherche d’adresse de destination pour le paquet. Si vous activez l’option no-router-alert sur le routeur entrant, l’option router-alert est supprimée des options IP et donc du côté sortant. Vous devez configurer l’adresse de destination explicitement dans lo0 ; sinon, le paquet est rejeté et S-BFD reste inactif.
[edit interfaces lo0 unit 0 family inet] address 127.0.0.1/32;
Vous pouvez utiliser un nouvel indicateur de trace, , bfdpour tracer les activités BFD :
user@host# set protocols source-packet-routing traceoptions flag bfd
Exemple
La configuration suivante est un exemple de tunnel de routage de segments statique non coloré avec protection LSP.
protocols {
source-packet-routing {
source-routing-path ncsrlsp5 {
to 10.10.10.10;
primary {
ncsrpath12 {
weight 1;
bfd-liveness-detection {
sbfd {
remote-discriminator 100;
}
minimum-interval 100;
}
}
ncsrpath13 {
weight 2;
bfd-liveness-detection {
sbfd {
remote-discriminator 100;
}
minimum-interval 100;
}
}
ncsrpath14 {
weight 3;
bfd-liveness-detection {
sbfd {
remote-discriminator 100;
}
minimum-interval 100;
}
}
ncsrpath15 {
weight 4;
bfd-liveness-detection {
sbfd {
remote-discriminator 100;
}
minimum-interval 100;
}
}
segment-list ncsrpath12 {
hop1 label 50191;
hop2 label 801000;
}
segment-list ncsrpath13 {
hop1 label 50191;
hop2 label 801001;
hop3 label 801000;
}
segment-list ncsrpath14 {
hop1 label 801000;
}
segment-list ncsrpath15 {
hop1 label 801002;
hop2 label 801000;
}
}
}
}
}
Vérifiez que les LSP sont configurés pour les tunnels de routage de segments statiques et que l’état de la 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
user@host> show spring-traffic-engineering lsp detail
Name: abc
To: 77.77.77.77
State: Up
Path: sl1
Outgoing interface: NA
BFD status: Up BFD name: V4-sl1
SR-ERO hop count: 3
Hop 1 (Strict):
NAI: None
SID type: 20-bit label, Value: 801007
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 22222
Hop 3 (Strict):
NAI: None
SID type: 20-bit label, Value: 3333
Path: sl2
Outgoing interface: NA
BFD status: Up BFD name: V4-sl2
SR-ERO hop count: 2
Hop 1 (Strict):
NAI: None
SID type: 20-bit label, Value: 801006
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 121212
Path: sl2
Outgoing interface: NA
BFD status: Up BFD name: V4-sl2
SR-ERO hop count: 2
Hop 1 (Strict):
NAI: None
SID type: 20-bit label, Value: 801006
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 121212
Total displayed LSPs: 1 (Up: 1, Down: 0)
Étant donné que de nombreux LSP peuvent partager la même session BFD, lorsque le premier LSP avec une combinaison unique d’étiquettes-pile+famille d’adresses apparaît, le nom de la session S-BFD utilise adresse-famille+nom-lsp. Si, par la suite, plusieurs LSP partagent la même session, le nom de la session peut changer en address-family+least-lsp-name, sans affecter l’état de la session S-BFD. Le nom de la session S-BFD apparaît également dans la sortie de la show bfd session extensive commande. La sortie de chaque LSP affiche l’état S-BFD ainsi que le nom S-BFD auquel il fait référence, comme indiqué dans l’exemple précédent sous la forme BFD status: Up BFD name: V4-sl2. Étant donné qu’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 l’itinéraire du tunnel de routage de segments avec un tronçon suivant principal et un tronçon suivant secondaire
But
Sur le moteur de routage du routeur entrant, vérifiez l’itinéraire du tunnel de routage de segments avec un tronçon suivant principal et un tronçon suivant secondaire.
Action
user@host> show route table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
128.9.146.157/32 *[SPRING-TE/8] 00:43:16, metric 1
> to 55.1.12.2 via ge-0/0/0.0, Push 1000145, Push 1000134, Push 1000123(top)
to 55.1.12.2 via ge-0/0/1.0, Push 1000934, Push 1000923(top)
Vérifier la session S-BFD du chemin d’accès principal
But
Dans le moteur de routage du routeur entrant, vérifiez la session S-BFD du chemin principal.
Action
user@host> show bfd session extensive
Detect Transmit
Address State Interface Time Interval Multiplier
127.0.0.1 Up 4.000 1.000 4
Client SPRING-TE, TX interval 1.000, RX interval 1.000
Session up time 00:40:53, previous down time 00:02:08
Local diagnostic None, remote diagnostic None
Remote state Up, version 1
Session type: Multi hop BFD (Seamless)
Min async interval 1.000, min slow interval 1.000
Adaptive async TX interval 1.000, RX interval 1.000
Local min TX interval 1.000, minimum RX interval 1.000, multiplier 4
Remote min TX interval 1.000, min RX interval 0.001, multiplier 4
Local discriminator 28, remote discriminator 32
Echo mode disabled/inactive
Remote is control-plane independent
Path-Name V4-sl-1
1 sessions, 1 clients
Cumulative transmit rate 1.0 pps, cumulative receive rate 1.0 pps
Sur le moteur de routage du routeur entrant, vérifiez la session S-BFD du chemin secondaire de la même manière.
Configuration de l’identificateur de segment d’adjacence statique pour les liaisons membres Ethernet agrégées à l’aide d’un LSP statique à saut unique
Dans un réseau où des faisceaux Ethernet agrégés sont utilisés, une liaison agrégée peut être un ensemble d’un nombre quelconque de liaisons physiques. Le trafic envoyé sur ces interfaces de bundle AE est transféré sur l’une des liaisons membres d’une interface AE. Le trafic peut prendre n’importe quel lien physique en fonction du hachage défini pour l’équilibrage de charge du trafic, ce qui rend difficile l’isolement des liens qui ont mal tourné ou qui abandonnent le trafic. Une façon de tester le chemin de transfert disponible dans le réseau consiste à ajouter un chemin de commutation d’étiquettes statiques (LSP) à saut unique, le saut suivant pointant vers un lien membre spécifique de l’interface AE.
L’opération d’étiquetage par défaut pour les LSP statiques doit être pop and forward. Lorsqu’un paquet atteint ces routes étiquetées, il est transféré vers un lien membre spécifique. Une étiquette unique est utilisée pour identifier le lien membre. Ces étiquettes sont appelées identificateurs de segment d’adjacence (SID) et sont provisionnées de manière statique.
Vous pouvez contrôler le flux des paquets dans le réseau en construisant une pile d’étiquettes dans le contrôleur, qui inclut les étiquettes allouées par tous les LSP statiques de transit. Les paquets d’exploitation, d’administration et de maintenance (OAM) sont conçus et injectés dans le réseau avec l’ensemble de la pile d’étiquettes.
Lorsqu’un paquet atteint cette route d’étiquettes, l’étiquette est déclenchée et le trafic est transféré sur la liaison membre spécifiée dans la configuration. Un MAC de destination est choisi lors du transfert du paquet, le Mac de destination est l’adresse MAC de l’interface agrégée (sélectionnée en fonction de l’adresse nexthop configurée).
Lorsque le lien membre tombe en panne et que l’interface d’agrégation est active, la route correspondant à ce lien membre est supprimée. Lorsqu’une interface d’agrégation tombe en panne, toutes les routes correspondant aux liens membres de l’interface d’agrégation sont supprimées. Lorsque l’interface physique enfant est détachée LACP mais que l’interface physique enfant est active, la route étiquetée pour la liaison enfant est supprimée. Dans le cas d’un détachement LACP, si l’état de transfert de la liaison membre est actif et non valide, les paquets OAM sont abandonnés dans le PFE lorsque l’interface physique enfant est détachée.
Utilisez l’exemple suivant pour configurer un LSP statique à saut unique pour une liaison membre AE.
Définissez une plage d’étiquettes statiques.
user@host# set protocols mpls label-range static-label-range 1000000 1048575;REMARQUE :Nous vous recommandons de configurer la plage d’étiquettes statiques par défaut de 1000000-1048575 pour le LSP statique. Si vous souhaitez configurer une plage d’étiquettes autre que la plage d’étiquettes statiques par défaut, configurez plusieurs plages.
Créez un LSP statique pour le lien membre AE à partir du pool de blocs locaux de routage de segments (SRLB) de la plage d’étiquettes statiques.
user@host# set protocols mpls static-label-switched-path statc-lsp transit 100001 pop next-hop 10.1.1.1 member-interface ge-0/0/0
Dans cette configuration, un routeur étiqueté de transit est installé dans mpls.0, affiche l’étiquette et transfère le paquet vers le bas du saut suivant. L’adresse du saut suivant est obligatoire pour les interfaces de diffusion (telles que ge-, xe-, ae-) et le if-name est utilisé pour les interfaces P2P (telles que so-). L’adresse est requise pour les interfaces de diffusion car l’adresse IP du saut suivant est utilisée pour sélectionner l’adresse MAC de destination. L’adresse MAC source du paquet est l’adresse MAC de l’AE.
Les exemples de sorties affichent le nom du lien membre dans la sortie du saut suivant :
show mpls static-lsp extensive
user@host> show mpls static-lsp extensive Ingress LSPs: Total 0, displayed 0, Up 0, Down 0 Transit LSPs: LSPname: static-lsp1, Incoming-label: 1000001 Description: verify-static-lsp-behavior State: Up, Sub State: Traffic via primary but unprotected Nexthop: 10.2.1.1 Via ae0.0 -> ge-0/0/0 LabelOperation: Pop Created: Thu May 25 15:31:26 2017 Bandwidth: 0 bps Statistics: Packets 0, Bytes 0
show route label label-name extensive
user@host> show route label 1000001 extensive
mpls.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
1000001 (1 entry, 1 announced)
TSI:
KRT in-kernel 1000001/52 -> {Pop }
*MPLS Preference: 6
Next hop type: Router, Next hop index: 611
Address: 0xb7a17b0
Next-hop reference count: 2
Next hop: 10.2.1.1 via ae0.0 -> ge-0/0/0 weight 0x1, selected
Label operation: Pop
Load balance label: None;
Label element ptr: 0xb7a1800
Label parent element ptr: 0x0
Label element references: 1
Label element child references: 0
Label element lsp id: 0
Session Id: 0x15d
State: <Active Int>
Age: 3:13:15 Metric: 1
Validation State: unverified
Task: MPLS
Announcement bits (1): 1-KRT
AS path: I
Label 188765184Optimisation des délais de calcul des chemins de segment routing intradomaine et interdomaine
- Présentation des mesures basées sur les retards pour les chemins d’ingénierie du trafic
- Avantages des mesures basées sur le retard pour le calcul de chemin
- Présentation du calcul basé sur DCSPF avec mesures de retard pour le chemin SR
- Vue d’ensemble des mesures de délai pour les cas d’utilisation interdomaines et intradomaines
- Mesure des retards dans les réseaux optiques : cas d’usage
Présentation des mesures basées sur les retards pour les chemins d’ingénierie du trafic
L’utilisation de mesures dynamiques basées sur les retards est de plus en plus souhaitable dans les réseaux modernes. Les métriques basées sur les retards sont essentielles pour qu’un élément de calcul de chemin (PCE) calcule les chemins d’ingénierie du trafic. Vous pouvez utiliser des mesures basées sur le délai pour orienter les paquets sur les chemins les plus lents ou les plus lents. Pour ce faire, vous devez mesurer le délai sur chaque liaison et l’annoncer à l’aide d’un protocole de routage approprié (IGP ou BGP-LS), de sorte que l’entrée ait les propriétés de retard par liaison dans son TED.
Pour comprendre comment annoncer le délai sur chaque liaison ou activer les mesures de liaison, consultez Comment activer la mesure du délai de liaison et la publicité dans ISIS.
La séquence d’événements suivante se produit lorsque vous mesurez, annoncez et calculez la détection des changements dans le réseau et calculez le chemin d’ingénierie du trafic avec la latence la plus courte :
- Détectez les changements dans le réseau en mesurant la latence, avec des sondes synthétiques, routeur à routeur.
- Inondez les résultats vers les nœuds entrants via des extensions métriques TE étendues IGP.
- Annoncez les résultats aux contrôleurs centralisés avec les extensions BGP-LS correspondantes.
- Calculez les chemins de mesure de latence cumulée la plus courte basés sur IGP (Flex-algo).
- Calculez les chemins explicites (de la source à la destination) avec des mesures de latence ou de délai cumulées les plus courtes (SR-TE).
Avantages des mesures basées sur le retard pour le calcul de chemin
- Déployez des services à valeur ajoutée basés sur la latence la plus faible sur l’ensemble du réseau.
- Mesurez la latence par chemin (minimale, maximale, moyenne) à l’aide de mesures basées sur les retards.
- Orientez les services sensibles au retard (tels que les services VPN ou 5G) sur des chemins optimisés pour le SR à très faible latence.
Présentation du calcul basé sur DCSPF avec mesures de retard pour le chemin SR
À l’aide de la fonctionnalité CSPF (Constrained Shortest Path First) distribuée pour le LSP de routage de segments, vous pouvez calculer un LSP de routage de segments localement sur le périphérique 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 métrique (traffic-engineering ou IGP). Les LSP sont calculés pour utiliser les chemins ECMP disponibles vers la destination lorsque la compression de pile d’étiquettes de routage de segments est activée ou désactivée.
Vous pouvez configurer un fichier 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 un profil de calcul sur le chemin source (chemin de routage des paquets source). Si vous avez configuré un profil de calcul optimisé pour la delay-variation-thresholdmoyenne des délais, vous pouvez également appliquer une contrainte appelée . Lorsque vous configurez une valeur pour delay-variation-threshold, tout lien dépassant la valeur seuil est exclu du calcul du chemin.
Pour configurer les mesures de délai pour le calcul basé sur DCSPF pour le chemin SR, vous devez activer l’instruction de configuration au niveau de delay la hiérarchie [edit protocols source-packet-routing compute-profile profile-name metric-type delay]. Vous pouvez configurer les mesures de délai telles que le minimum, le maximum, la moyenne et le seuil de variation de retard pour le calcul du chemin.
minimum: valeur métrique de délai minimum de TED pour le calcul du chemin de latence la plus faible cumulée.average: valeur métrique de retard moyenne de TED pour le calcul du chemin de latence la plus faible cumulée.maximum: valeur métrique de délai maximale de TED pour le calcul du chemin de latence la plus faible cumulée.delay-variation-threshold—Seuil de variation du délai de liaison (1..16777215). Toute liaison dépassant le seuil de variation de retard serait exclue du calcul du trajet. Le seuil de variation du délai est indépendant du fait que vous effectuez une optimisation minimale, maximale ou moyenne. L’instructiondelay-variation-thresholdde configuration s’affiche aux niveaux hiérarchiques suivants :-
[
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 les mesures de délai dans la hiérarchie CLI suivante :
[edit]
protocols {
source-packet-routing {
compute-profile <name> {
metric-type delay {
minimum;
maximum;
average;
delay-variation-threshold <value>;
}
}
}
}
Vue d’ensemble des mesures de délai pour les cas d’utilisation interdomaines et intradomaines
Dans le cas intra-domaine (le chemin réside dans un seul domaine), le délai de liaison est pris en compte lors du calcul du chemin. Les mesures de retard pour le calcul du chemin de routage de segments sont prises en charge sur les SID compressés et non compressés. Si vous avez des SID non compressés, les segments d’adjacence pour les listes de segments sont utilisés pour produire plusieurs listes de segments s’il existe 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 permet d’obtenir un chemin entièrement étendu à l’aide de SID de contiguïté. Pour plus d’informations, consultez compute-profile .
Voici un exemple de configuration pour les mesures de délai :
[edit protocols source-packet-routing]
user@host# show
compute-profile profile1 {
no-label-stack-compression;
metric-type {
delay {
minimum;
delay-variation-threshold 300;
}
}
}
Pour le calcul du chemin optique, il est recommandé d’utiliser les mesures de retard au minimum. Minimum est la configuration par défaut.
Pour les cas d’utilisation interdomaines (multidomaines), où il existe plusieurs systèmes autonomes, vous pouvez utiliser des segments express pour configurer les délais de liaison pour le calcul des chemins. Les segments Express sont des liens qui relient des nœuds de bordure ou ASBR. Pour en savoir plus sur les segments express, reportez-vous à la section Configuration du LSP Express Segment . 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 des délais minimum, maximum et moyen.
Vous pouvez configurer des mesures de délai dans un segment express au niveau de la hiérarchie CLI suivante :
[edit]
protocols {
express-segments {
segment-template <name> {
metric delay [ min <value> | avg <value> | max <value>
}
}
}
Pour le calcul des chemins interdomaines, vous pouvez affecter des mesures de délai sur les liaisons BGP EPE. Vous pouvez configurer une valeur pour delay-metric au 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 :
[edit]
protocols {
bgp {
group <name> {
type external;
}
neighbor <ip_addr> {
egress-te-adj-segment <name> {
egress-te-link-attribute {
delay-metric <value>
}
}
}
}
}
Mesure des retards dans les réseaux optiques : cas d’usage
Les topologies suivantes illustrent un cas d’utilisation optique. Les solutions de protection et de restauration optiques entraînent une modification des attributs physiques sous-jacents, principalement la longueur des trajets, en raison de défaillances de liaison et de l’optimisation du réseau DWDM qui en découle.
Sur la figure, la liaison entre A et C passe par les nœuds optiques O1 et O3 et a une latence de 10 microsecondes. Sur la figure, vous pouvez voir une défaillance de liaison entre les noeuds optiques O1 et O3 et que la connexion optique réelle est réacheminée via le noeud optique O2. Cela augmente la latence de 15 microsecondes. La métrique de la liaison qui relie A et B change dynamiquement entre time=0 et time=1.
Lorsqu’une modification du délai par liaison est détectée par l’entrée, l’entrée déclenche un nouveau calcul du chemin optimisé pour le délai et le routeur en tête de réseau redirige le chemin sur le chemin de latence minimale disponible suivant. La modification du délai de liaison peut amener l’entrée à choisir un autre ensemble de liaisons ayant le chemin de latence le plus faible. Sur la figure B, vous pouvez voir qu’il y a une modification dans la liaison entre les chemins A et C et que le routeur en tête de réseau redirige et sélectionne le chemin A-B-C comme indiqué dans la topologie.
Tableau de l'historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l' Feature Explorer pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.