SUR CETTE PAGE
Segment Routing LSP Configuration
Activation de CSPF distribué pour les LSP de Segment Routing
Avec la fonctionnalité CSPF (Constrained Shortest Path First) distribuée pour le routage de segments LSP, vous pouvez calculer un LSP de routage de segments localement sur le périphérique entrant en fonction des contraintes que vous avez configurées. Cette fonctionnalité permet d’optimiser les LSP en fonction des contraintes configurées et du type de métrique (ingénierie de trafic ou IGP). Les LSP sont calculés pour utiliser les chemins ECMP disponibles vers la destination avec la compression de la pile d’étiquettes de routage de segments activée ou désactivée.
Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de la plate-forme et de la version pour des fonctionnalités spécifiques.
Consultez la section Comportement LSP du Segment Routing spécifique à la plate-forme pour obtenir des notes relatives à votre plate-forme.
- Contraintes de calcul distribuées de CSPF
- Algorithme de calcul distribué CSPF
- Base de données de calcul distribuée CSPF
- Configuration des contraintes de calcul CSPF distribuées
- Calcul CSPF distribué
- Interaction entre le calcul distribué de CSPF et les fonctionnalités SR-TE
- Exemple de configuration de calcul CSPF distribué
Contraintes de calcul distribuées de CSPF
Les chemins LSP de routage de segments sont calculés lorsque toutes les contraintes configurées sont satisfaites.
La fonctionnalité de calcul distribuée de CSPF prend en charge le sous-ensemble de contraintes suivant spécifié dans l’ébauche Internet, draft-ietf-spring-segment-routing-policy-03.txt Segment Routing Policy for Traffic Engineering :
-
Inclusion et exclusion des groupes administratifs.
-
Inclusion d’adresses IP à sauts lâches ou stricts.
Remarque :Vous pouvez spécifier uniquement 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 candidat.
La fonctionnalité de calcul CSPF distribuée pour les LSP de routage de segments ne prend pas en charge les types de contraintes et scénarios de déploiement suivants :
-
Adresses IPV6.
-
Routage de segments inter-domaines, ingénierie de trafic (SR-TE), LSP.
-
Interfaces non numérotées.
-
Plusieurs protocoles de routage protocoles tels que OSPF, IS-IS et BGP-LS, activés simultanément.
-
Calcul avec des préfixes ou des adresses anycast comme destinations.
-
Inclusion et exclusion des adresses IP d’interface en tant que contraintes.
Algorithme de calcul distribué CSPF
La fonctionnalité de calcul distribuée de CSPF 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ées représente un ensemble de chemins d’une source à une destination. Il se compose généralement de SID de nœud et de SID d’adjacence. Lorsque la compression de la pile d’étiquettes est activée, le résultat du calcul est un ensemble de chemins qui maximisent 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 multichemin avec compression de pile d’étiquettes désactivée trouve jusqu’à N des listes de segments vers la destination, où :
-
Le coût de toutes les listes de segments est égal et identique à la mesure d’ingénierie de trafic la plus courte pour atteindre la destination.
-
Chaque liste de segments comprend des SID contigus.
-
La valeur de N est le nombre maximal de listes de segments autorisées pour le chemin candidat par configuration.
-
Il n’y a pas deux listes de segments identiques.
-
Chaque liste de segments satisfait toutes les contraintes configurées.
Base de données de calcul distribuée CSPF
La base de données utilisée pour le calcul du SR-TE contient tous les liens, nœuds, préfixes et leurs caractéristiques, que l’ingénierie de 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 dont le nœud de calcul a appris. Par conséquent, pour que CSPF fonctionne, vous devez inclure l’instruction igp-topology au niveau de la [edit protocols isis traffic-engineering] hiérarchie.
Configuration des contraintes de calcul CSPF distribuées
Vous pouvez utiliser un profil de calcul pour regrouper logiquement les contraintes de calcul. Ces profils de calcul sont référencés par les chemins de routage de segments pour le calcul des LSP de routage de segments primaire et secondaire.
Pour configurer un profil de calcul, incluez l’instruction compute-profile au niveau de la [edit protocols source-packet-routing] hiérarchie.
La configuration 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 de groupe d’administration aux interfaces d’ingénierie du trafic de routage de segments (SR-TE).Pour configurer les contraintes de calcul, vous pouvez spécifier trois catégories pour un ensemble de groupes administratifs. La configuration des contraintes 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 administratifs configurés dans la liste est acceptable pour le chemin à parcourir. -
include-all: spécifie que tout lien avec tous les groupes administratifs configurés dans la liste est acceptable pour le chemin à parcourir. -
exclude: spécifie que tout lien qui n’a aucun des groupes administratifs configurés dans la liste est acceptable pour le chemin à parcourir.
Remarque : Les groupes administratifs ne sont annoncés que si vous :-
Activez RSVP sur les interfaces.
-
Configurez
edit protocols isis traffic-engineering advertisement alwayssi vous ne souhaitez pas activer RSVP.
-
-
Explicit path
Vous pouvez spécifier une série d’ID de routeur dans le profil de calcul comme contrainte pour le calcul des chemins candidats SR-TE. Chaque saut doit être une adresse IPv4 et peut être de type strict ou lâche. Si le type d’un saut n’est pas configuré, strict est utilisé. Vous devez inclure l’option
computesous l’instruction segment-list lorsque vous spécifiez la contrainte de chemin explicite. -
Maximum number of segment lists (ECMP paths)
Vous pouvez associer un chemin 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 un poids actif. Ces chemins sont le résultat d’un calcul de chemin avec ou sans compression.
Vous pouvez configurer cet attribut à l’aide de l’option
maximum-computed-segment-lists maximum-computed-segment-listssituée sous l’instruction de configuration compute-profile . Cette configuration détermine le nombre maximal de ces listes de segments calculées pour un LSP primaire et secondaire donné. -
Maximum segment list depth
Le paramètre de calcul de la profondeur maximale de la liste de segments garantit que, parmi les chemins ECMP qui satisfont à toutes les autres contraintes telles que le groupe administratif, seuls les chemins dont la profondeur de la liste de segments est inférieure ou égale à la profondeur maximale de la liste de segments sont utilisés. Lorsque vous configurez ce paramètre en tant que contrainte sous le profil de calcul, il remplace la
maximum-segment-list-depthconfiguration sous le niveau hiérarchique[edit protocols source-packet-routing], le cas échéant.Vous pouvez configurer cet attribut à l’aide de l’option
maximum-segment-list-depth maximum-segment-list-depthsituée sous l’instruction de configuration compute-profile . -
Protected or unprotected adjacency SIDs
Vous pouvez configurer un SID d’adjacence protégé ou non protégé en tant que contrainte sous le profil de calcul pour éviter les liens avec le type de SID spécifié.
-
Metric type
Vous pouvez spécifier le type de mesure sur le lien à utiliser pour le calcul. Par défaut, les LSP SR-TE utilisent les mesures d’ingénierie du trafic des liens pour le calcul. La mesure 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 en utilisant la configuration de type métrique dans le profil de calcul.
Vous pouvez configurer cet attribut à l’aide de l’option
metric-type (igp | te)située sous l’instruction de configuration compute-profile .
Calcul CSPF distribué
Les chemins candidats SR-TE sont calculés localement de sorte qu’ils satisfassent aux contraintes configurées. Lorsque la compression de la pile d’étiquettes est désactivée, le résultat du calcul CSPF à chemins multiples 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 adjacents et de SID de nœud).
Lorsque les chemins secondaires sont calculés, les liens, nœuds et SRLG empruntés par les chemins principaux ne sont pas évités pour le calcul. Pour plus d’informations sur les chemins principaux et secondaires, consultez Configuration des LSP principaux et secondaires.
Pour tous les LSP dont le résultat de calcul n’a pas abouti, le calcul est retenté au fur et à mesure que la base de données d’ingénierie de trafic (TED) change.
Interaction entre le calcul distribué de CSPF et les fonctionnalités SR-TE
- Pondérations associées aux chemins d’une politique SR-TE
- Détection de la vivacité BFD
- hériter-étiquette-suivantshops
- 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 la route. Toutefois, un seul chemin dont le calcul est activé peut entraîner 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 entraîner plusieurs listes de segments, par conséquent, les paramètres BFD configurés par rapport aux listes de segments sont appliqués à toutes les listes de segments calculées. Si tous les chemins principaux actifs tombent en panne, le chemin secondaire préprogrammé (s’il est fourni) devient actif.
hériter-étiquette-suivantshops
Vous n’êtes pas obligé d’activer explicitement la inherit-label-nexthops configuration sous la [edit protocols source-packet-routing segment-list segment-list-name] hiérarchie pour les chemins 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 sur les listes de segments, et les chemins principaux ou secondaires avec la fonctionnalité de traduction automatique référencent ces listes de segments. D’autre part, le principal 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 fonction de traduction automatique pour un chemin principal ou secondaire donné. Toutefois, vous pouvez avoir un LSP configuré avec un chemin principal avec un type de calcul et un autre avec un type de traduction automatique.
Exemple de configuration 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 principal calculé doit avoir un nom configuré et ce nom ne doit faire référence à aucune liste de segments configurés. Dans cet exemple, compute_segment1 n’est pas une liste de segments configurée.
-
Le compute_profile_red profil de calcul est appliqué au chemin principal avec le nom compute_segment1.
-
Le compute_profile_red profil de calcul inclut une liste de segments de type
compute, qui est utilisée pour spécifier la contrainte 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 prochains sauts de chemin calculés et les prochains sauts statiques sont respectivement de 2 et 3. En supposant que les sauts suivants pour les chemins calculés sont comp_nh1, comp_nh2et comp_nh3, et que le saut suivant pour le chemin statique est static_nh, les pondérations sont appliqué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 principal et secondaire peuvent être de type calcul et peuvent 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 un calcul local d’un chemin vers la destination sans aucune contrainte ni 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
}
}
}
Étiquette de Segment Routing statique Chemin commuté
L’architecture de routage de segments permet aux appareils entrants dans un réseau central de diriger le trafic via des chemins explicites. Vous pouvez configurer ces chemins à l’aide de listes de segments pour définir les chemins que le trafic entrant doit emprunter. Le trafic entrant peut être étiqueté ou IP, ce qui fait que l’opération de transfert au niveau du périphérique entrant est soit un échange d’étiquette, soit une recherche basée sur la destination.
- LSP de Segment Routing statique dans les réseaux MPLS
- Exemple : Configuration d’un chemin commuté d’étiquette de Segment routing statique
LSP de Segment Routing statique dans les réseaux MPLS
Le routage de paquets source, ou routage de segments (segments), est une architecture à plan de contrôle qui permet à un appareil entrant dans un réseau central de diriger le trafic à travers un ensemble spécifique de nœuds et de liaisons du réseau sans dépendre des nœuds intermédiaires du réseau pour déterminer le chemin qu’il doit emprunter. Vous pouvez configurer ces chemins à l’aide de listes de segments pour définir les chemins que le trafic entrant doit emprunter. Le trafic entrant peut être étiqueté ou IP, ce qui fait que l’opération de transfert au niveau du périphérique entrant est soit un échange d’étiquette, soit une recherche basée sur la destination.
- Introduction aux LSP de Segment Routing
- Avantages de l’utilisation des LSP de Segment Routing
- LSP de Segment Routing statique coloré
- LSP de Segment Routing statique non coloré
- Provisionnement LSP de Segment Routing statique
- Limites LSP du Segment Routing statique
- Mappage par couleur des services VPN
- Modèles de tunnel pour les LSP de Segment Routing initiés par PCE
Introduction aux LSP de Segment Routing
Le routage de segments s’appuie sur le paradigme du routage à la source. Un appareil dirige un paquet à travers une liste ordonnée d’instructions, appelée segments. Un segment peut représenter n’importe quelle instruction, topologique ou basée sur des services. Un segment peut avoir une sémantique locale à un nœud de routage de segments ou à un nœud global dans un domaine de routage de segments. Le routage de segments applique un flux à travers n’importe quel chemin topologique et chaîne de services tout en conservant un état par flux uniquement au niveau de l’équipement entrant dans le domaine de routage de segments. Le routage de segments peut être appliqué directement à l’architecture MPLS sans modification du plan de transfert. Un segment est encodé en tant qu’étiquette MPLS. Une liste ordonnée de segments est codée sous la forme d’une pile d’étiquettes. Le segment à traiter se trouve en haut de la pile. Une fois un segment terminé, l’étiquette associée est retirée 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 entrant via des extensions PCEP (Path Computation Element Protocol), ou à partir d’une politique de routage de segments 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 routage explicite PCEP (ERO) ou dans la politique 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 entrant via une configuration locale, le LSP est provisionné de manière statique. Un LSP de routage de segments statiques 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 de l’utilisation des LSP de Segment Routing
-
Le routage de segments statiques ne repose pas sur l’état de transfert de chaque LSP sur les routeurs de transit. Par conséquent, plus besoin de provisionner et de maintenir l’état de transfert LSP dans le cœur.
-
Accroître l’évolutivité des réseaux MPLS.
LSP de Segment Routing statique coloré
Un LSP de routage de segments statiques configuré avec l’instruction color est appelé LSP coloré.
- Comprendre les LSP de Segment Routing statique coloré
- Liste des segments des LSP de Segment Routing colorés
Comprendre les LSP de Segment Routing statique coloré
Semblable à une politique de routage de segments BGP, la route entrante 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 segments colorés statiques peut avoir un SID de liaison, pour lequel une route est installée 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 segments. Les passerelles de la route sont dérivées des configurations de liste de segments sous les chemins principal et secondaire.
Liste des segments des LSP de 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 pour résoudre un LSP. Toutefois, le mode IP de premier saut n’est pas pris en charge pour les LSP de routage de segments colorés. Une fonctionnalité de vérification de validation est introduite pour s’assurer 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 Segment Routing statique non coloré
Un LSP de routage de segments statiques configuré sans l’instruction color est un LSP non coloré. Comme pour les tunnels de routage de segments PCEP, la route entrante est installée dans les tables de inet.3 routage OR 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 du Segment Routing non coloré
- Liste de segments de LSP de Segment Routing non colorés
Comprendre les LSP du Segment Routing non coloré
Le LSP de routage de segments non colorés a un nom unique et une adresse IP de destination. Une route entrante vers la destination est installée dans la table de routage inet.3 avec une préférence par défaut de 8 et une métrique de 1. Cette route permet de mapper des services non colorés au LSP de routage de segments correspondant à la destination. Si le LSP de routage de segments non colorés ne nécessite pas de route entrante, la route entrante peut être désactivée. Un LSP de routage de segments non coloré utilise une étiquette SID de liaison pour réaliser l’assemblage de segments LSP. Étiquette qui 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. Par défaut, le transit de l’étiquette SID de liaison a une préférence de 8 et une métrique de 1.
Les LSP de routage de segments non colorés configurés de manière statique sur le périphérique entrant sont signalés au Path Computation Element (PCE) par le biais d’une session PCEP (Path Computation Element Protocol). Ces LSP de routage de segments non colorés peuvent être associés à des étiquettes SID (Binding Service Identifier). Avec 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) distribue le trafic sur les chemins en fonction des facteurs d’équilibrage de charge tels que le poids configuré sur le chemin. Il s’agit d’ECMP (Equal Cost Multi path) si aucun des chemins n’a de poids configuré ou ECMP pondéré si au moins un des chemins a un poids non nul configuré sur les chemins. Dans les deux cas, lorsqu’un ou plusieurs chemins tombent en panne, le PFE rééquilibre le trafic sur les chemins restants, ce qui permet automatiquement d’obtenir une protection du chemin. Un LSP de routage de segments non colorés peut avoir un chemin secondaire pour la protection du chemin dédié. En cas de défaillance d’un chemin principal, le PFE rééquilibre le trafic vers les chemins principaux fonctionnels restants. Sinon, le PFE bascule le trafic sur le chemin de secours, assurant ainsi la protection du chemin. Un LSP de routage de segments non coloré peut spécifier une métrique at [edit protocols source-packet-routing source-routing-path lsp-name] pour ses routes SID entrantes et de liaison. Plusieurs LSP de routage de segments non colorés ont la même adresse de destination et contribuent au saut suivant de la route entrante.
Plusieurs LSP de routage de segments non colorés ont la même adresse de destination et contribuent au saut suivant de la route entrante. Chaque chemin, principal ou secondaire, de chaque LSP de routage de segments est considéré comme un candidat 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 que le saut suivant peut contenir ne peut pas dépasser la limite de chemins multiples RPD, qui est de 128 par défaut. Les chemins supplémentaires sont élagués, d’abord les chemins secondaires puis les chemins primaires. Une liste de segments donnée peut être désignée plusieurs fois comme chemin principal ou secondaire par ces LSP de routage de segments. Dans ce cas, il existe plusieurs passerelles, chacune ayant un ID de tunnel LSP de routage de segments unique. Ces passerelles sont distinctes, bien qu’elles aient une pile d’étiquettes sortantes et une interface identiques. Un LSP de routage de segments non colorés et un LSP de routage de segments colorés peuvent également avoir la même adresse de destination. Cependant, elles correspondent à des adresses de destination différentes pour les routes entrantes, car l’adresse de destination du LSP de routage de segments colorés est construite avec son adresse de destination et sa couleur.
Dans le cas où un LSP statique de routage de segments non coloré et un LSP de routage de segments créé par PCEP coexistent et ont le même problème à traiter qui contribue à la même route entrante, s’ils ont également la même préférence. Sinon, le LSP de routage de segments avec la meilleure préférence est installé pour la route.
Liste de segments de LSP de Segment Routing non colorés
Une liste de segments se compose 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 1 000 tunnels par système. Un maximum de 128 chemins principaux sont pris en charge par LSP de routage de segments statiques. Vous pouvez configurer la limite maximale de la liste de segments au niveau de la [edit protocols source-packet-routing] hiérarchie.
Le premier saut des LSP statiques non colorés prend 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 pondéré à coût égal sont activés pour résoudre les LSP statiques de routage de segments non colorés, similaires aux LSP statiques colorés.
Pour que le mode d’étiquette de premier saut prenne effet, vous devez inclure l’instruction inherit-label-nexthops globalement ou individuellement pour une liste de segments, et le premier saut de la liste de segments doit inclure à la fois l’adresse IP et l’étiquette. Si le premier saut inclut uniquement l’adresse IP, l’instruction n’a inherit-label-nexthops aucun effet.
Vous pouvez effectuer la configuration inherit-label-nexthops au niveau de l’une des hiérarchies suivantes. L’instruction inherit-label-nexthops prend effet uniquement 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 inherit-label-nexthops listes de segments avec les étiquettes et l’adresse IP présentes dans le premier saut et configurées avec inherit-label-nexthops l’instruction sont résolues à l’aide des étiquettes SID.
Pour les LSP statiques dynamiques non colorés, c’est-à-dire les LSP de routage de segments pilotés par PCEP, l’instruction inherit-label-nexthops doit être activée globalement, car la configuration au niveau du segment n’est pas appliquée.
Le Tableau 1 décrit le mode de résolution LSP de 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 show route ip-address protocol spring-te active-path table inet.3 commande pour afficher les LSP de routage de segments non colorés conçus pour le trafic ayant plusieurs listes de segments installées dans la 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 type de premier 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. Ceci s’applique aux LSP de routage de segments statiques colorés et non colorés. Cependant, cela ne s’applique pas aux LSP pilotés par PCEP ; Un message de journal système est généré pour l’incompatibilité dans le 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; } }
Provisionnement LSP de Segment Routing statique
Le provisionnement des segments est effectué par routeur. Pour un segment donné sur un routeur, une étiquette d’identificateur de service unique (SID) est allouée à partir d’un pool d’étiquettes souhaité qui peut provenir du pool d’étiquettes dynamiques 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 nœud. 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). Un routage pour l’étiquette SID est ensuite installé 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 de Junos OS. Vous pouvez configurer le pool d’étiquettes statiques de Junos OS en configurant l’instruction static-label-range static-label-range au niveau de la [edit protocols mpls label-range] hiérarchie.
Limites LSP du Segment Routing statique
-
Actuellement, Junos OS présente une limitation : le saut suivant ne peut pas être conçu pour envoyer plus d’étiquettes que la profondeur maximale de la liste de segments. Par conséquent, une liste de segments avec plus d’étiquettes SID que le nombre maximal d’étiquettes SID (à l’exclusion de l’étiquette SID du premier saut utilisé 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 segments donné peut être encore inférieur à la limite maximale, si un service MPLS se trouve sur le LSP de routage de segments ou si le LSP de routage de segments se trouve sur un chemin de protection de lien ou de nœud. 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. Vous pouvez assembler plusieurs LSP de routage de segments non colorés dont les étiquettes SID sont inférieures ou égales au nombre maximal de SID afin de créer un LSP de routage de segments plus long. C’est ce qu’on appelle l’assemblage LSP de routage de segments. Cela peut être réalisé en utilisant l’étiquette binding-SID. -
L’assemblage LSP de routage de segments est en fait effectué au niveau du chemin. Si un LSP de routage de segments non colorés 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és à un point d’assemblage. Un LSP de routage de segments non coloré dédié à l’assemblage peut désactiver l’installation de la route entrante en configurant
no-ingressune 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 statiques non colorés. S’il y a une violation dans la configuration, la vérification de la 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 1 000 tunnels par système. Un maximum de 128 chemins principaux sont pris en charge par LSP de routage de segments statiques. Par limitation, la prise en charge maximale des capteurs pour les chemins 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 la validation de la configuration échoue avec une erreur.
Mappage par couleur des services VPN
Vous pouvez spécifier la couleur en tant que contrainte de prochain saut de protocole (en plus de l’adresse IPv4 ou IPv6) pour résoudre les tunnels de transport sur des LSP statiques, colorés et BGP Segment Routing Traffic-Engineered (SR-TE). C’est ce qu’on appelle la résolution de saut suivant du protocole couleur-IP, où vous devez configurer un mappage de résolution et l’appliquer aux services VPN. Cette fonctionnalité vous permet d’activer l’orientation du trafic basée sur la couleur 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 des services VPN basée sur les couleurs est prise en charge sur les LSP de couleur statique et les LSP BGP SR-TE.
- Coloration des services VPN
- Spécification du mode de mappage du service VPN
- Résolution du saut suivant du protocole Color-IP
- Reprise vers la résolution de saut suivant du protocole IP
- Mappage unicast basé sur les couleurs é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 des services VPN
En général, un service VPN peut se voir attribuer une couleur sur le routeur de sortie où le NLRI VPN est annoncé, ou sur un routeur entrant où le NLRI VPN est reçu et traité.
Vous pouvez attribuer une couleur aux services VPN à différents niveaux :
-
Par instance de routage.
-
Par groupe BGP.
-
Par voisin BGP.
-
Par préfixe.
Une fois que vous avez attribué une couleur, la couleur est attachée à un service VPN sous la forme d’une communauté étendue de couleur BGP.
Vous pouvez attribuer plusieurs couleurs à un service VPN, appelé services VPN multicolores. Dans de tels 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 appareils 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’équipement de sortie.
-
Stratégie d’importation BGP sur l’équipement entrant.
-
Stratégie d’importation VRF sur le périphérique entrant.
Les deux modes de coloration des services VPN sont :
Attribution des couleurs de sortie
Dans ce mode, le périphérique de sortie (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 politique de routage et l’appliquer à l’instance de routage, à l’exportation vrf-exportde groupe ou à l’exportation de voisinage 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 politique 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 du voisin BGP, du groupe BGP ou du BGP pour que la stratégie ait un 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 en couleur est héritée par toutes les routes VPN, importée et installée dans les VRF cibles sur un ou plusieurs périphériques entrants.
Attribution des couleurs entrantes
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 politique de routage et l’appliquer à l’instance vrf-importde routage, à l’importation de groupe ou à l’importation de voisins de groupe du service VPN au niveau de la [edit protocols bgp] hiérarchie. Toutes les routes VPN correspondant à la politique de routage sont attachées à 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 resolution-map et faire référence à la stratégie dans l’instance vrf-importde routage, l’importation de groupe ou l’importation de voisins de groupe d’un service VPN au niveau de la [edit protocols bgp] hiérarchie. Toutes les routes VPN correspondant à la politique 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 de ip-address:color.
Résolution du saut suivant du protocole Color-IP
Le processus de résolution du prochain saut du protocole est 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 du protocole prend une couleur et une carte de résolution, crée un saut suivant du protocole IP coloré sous la forme de IP-address:color, et résout le prochain saut du protocole dans la table de routage inet6color.0.
Vous devez configurer une stratégie pour prendre en charge la résolution multichemin des services VPN de couche 2, VPN de couche 3 ou EVPN colorés sur des LSP colorés. La stratégie doit ensuite être appliquée avec la table RIB appropriée comme politique 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;
}
}
Reprise vers la résolution de saut suivant du protocole IP
Si aucun service VPN coloré n’est associé à une carte de résolution, le service VPN ignore sa couleur et revient à la résolution de saut suivant 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 pour passer des LSP colorés SR-TE aux LSP LDP, en utilisant un groupe RIB pour que LDP installe des routes dans les tables de routage inet{6}color.0. Une correspondance de préfixe la plus longue pour un saut suivant de protocole IP coloré garantit que si une route LSP SR-TE colorée n’existe pas, une route LDP avec une adresse IP correspondante doit être renvoyée.
Mappage unicast basé sur les couleurs étiqueté BGP sur SR-TE
BGP Labeled Unicast (BGP-LU) peut résoudre des routes IPv4 ou IPv6 via SR-TE (Segment Routing-Traffic Engineering) pour les familles d’adresses IPv4 et IPv6. BGP-LU prend en charge le mappage d’une couleur communautaire BGP et la définition de a resolution map pour SR-TE. Un saut suivant de protocole coloré est construit et il est résolu sur un tunnel SR-TE coloré dans la inetcolor.0 table ou inet6color.0 . BGP utilise inet.3 des tables pour inet6.3 le mappage non basé sur les couleurs. Cela vous permet d’annoncer les préfixes IPv6 et IPv4 BGP-LU avec une adresse de saut suivant IPv6 dans les réseaux IPv6 uniquement où aucune adresse IPv4 n’est configurée sur les routeurs. Avec cette fonctionnalité, nous prenons actuellement en charge BGP IPv6 LU sur SR-TE avec sous-couche IS-IS.
Sur la 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 du routeur D. BGP importe des stratégies pour affecter une carte de couleur et de résolution au préfixe reçu 2001 :db8 ::3700:6/128. En fonction de la couleur communautaire 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.
IPv6 coloré
BGP-LU prend en charge les scénarios suivants :
-
BGP IPv4 LU sur BGP IPv4 SR-TE coloré, avec extensions IS-IS/OSPF IPv4 SR.
-
BGP IPv4 LU sur IPv4 statique coloré et non coloré SR-TE, avec des extensions IS-IS/OSPF IPv4 SR.
-
BGP IPv6 LU sur BGP IPv6 SR-TE coloré, avec extensions IS-IS IPv6 SR.
-
BGP IPv6 LU sur IPv6 statique coloré et non coloré SR-TE, avec des extensions IS-IS 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 IS-IS IPv6 SR.
-
Services VPN IPv6 de couche 3 sur IPv6 SR-TE de couleur statique et non colorée, avec extensions IS-IS 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 Kompella)
-
BGP EVPN
-
Carte de résolution avec une seule option de couleur IP.
-
Résolution de saut suivant des protocoles IPv4 et IPv6 colorés.
-
Base d’informations de routage (également appelée table de routage) basée sur un groupe de secours vers LDP LSP dans la table de routage inetcolor.0.
-
LSP SR-TE coloré.
-
Plateformes virtuelles.
-
Junos OS 64 bits.
-
Systèmes logiques.
-
Unicast étiqueté BGP.
Les caractéristiques et fonctionnalités suivantes ne sont pas prises en charge par le mappage par couleur des services VPN :
-
LSP MPLS colorés, tels que RSVP, LDP, BGP-LU, statiques.
-
Circuit de couche 2
-
VPN de couche 2 FEC-129 BGP à découverte automatique et signalé par LDP.
-
VPLS
-
MVPN
-
IPv4 et IPv6 à l’aide de resolution-map.
Modèles de tunnel pour les LSP de 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 transmettre deux paramètres supplémentaires pour ces LSP : la détection de transfert bidirectionnelle (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 y a une correspondance, la stratégie applique le modèle configuré pour ce LSP. La configuration du modèle est héritée uniquement 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
[edit protocols source-packet-routing]hiérarchie pour répertorier les instructions de stratégie par rapport auxquelles le LSP initié par PCE doit être vérifié. -
Définissez une stratégie pour répertorier les LSP 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-regexde correspondance. Ces options s’excluent mutuellement, vous ne pouvez donc spécifier qu’une seule option à un moment donné.L’instruction
thendoit inclure l’optionsr-te-templateavec une action d’acceptation. Cela applique le modèle au LSP initié par PCE.
Tenez compte des éléments suivants lors de la configuration d’un modèle pour les LSP initiés par PCE :
-
La configuration de modèle ne s’applique pas aux LSP de routage de segments configurés statiquement, ni aux LSP de routage de segments de tout autre client.
-
La configuration fournie par PCEP a la priorité sur la configuration de modèle.
-
PCEP LSP n’hérite pas de la configuration de la liste de segments des modèles.
Exemple : Configuration d’un chemin commuté d’étiquette de Segment routing statique
Cet exemple montre comment configurer des chemins de commutation d’étiquettes de segment statiques (LSP) dans des réseaux MPLS. Cette configuration contribue à accroître l’évolutivité des réseaux MPLS.
Exigences
Cet exemple utilise les composants matériels et logiciels suivants :
-
Sept plates-formes de routage universelles MX Series 5G
-
Junos OS version 18.1 ou ultérieure s’exécutant sur tous les routeurs
Avant de commencer, assurez-vous de configurer les interfaces des appareils.
Vue d’ensemble
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 a une adresse de destination et un ou plusieurs chemins principaux et éventuellement des chemins secondaires qui font référence à la liste des segments. Chaque liste de segments est constituée 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édiatement et le deuxième saut 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 du fournisseur PE1 et PE5. Configurez le protocole MPLS sur tous les routeurs. Le tunnel de routage de segments est configuré du routeur PE1 au routeur PE5 avec un chemin principal configuré sur le routeur PE1 et le routeur PE5 . Le routeur PE1 est également configuré avec un chemin secondaire pour la protection du chemin. Les routeurs de transit PE2 à PE4 sont configurés avec des étiquettes SID d’adjacence avec des pop d’étiquette et une interface sortante.
d’étiquette de Segment Routing statique
La configuration
- Configuration rapide de la CLI
- Configuration de l’équipement PE1
- Configuration de l’équipement PE2
- Résultats
Configuration rapide de la CLI
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie, puis entrez commit en mode 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 la CLI, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de la CLI.
Pour configurer l’équipement 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 de système autonome et les options 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 politiques de routage à la source et d’ingénierie du trafic (TE) du protocole SPRING (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 du SID de liaison, le chemin de routage de la 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 VRF et l’étiquette de table. 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
En mode configuration, confirmez votre configuration en entrant les show interfacescommandes , , show routing-optionsshow policy-optionsshow protocols, , 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 la CLI, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de la CLI.
-
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
A partir du mode 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 SPRING Traffic Engineered du routeur PE1
- Vérification du trafic SPRING Engineered LSP sur le routeur entrant 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
Objet
Vérifiez l’entrée de route de la table de routage inet.3 du routeur PE1.
Mesures à prendre
À 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)
Signification
La sortie affiche les routes entrantes 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
Objet
Vérifiez les entrées de routage de la table de routage mpls.0
Mesures à prendre
À 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)
Signification
La sortie affiche les étiquettes SID des tunnels de routage de segments.
Vérification du LSP SPRING Traffic Engineered du routeur PE1
Objet
Vérifiez les LSP conçus pour le trafic SPRING sur les routeurs entrants.
Mesures à prendre
À 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 >
Signification
La sortie affiche la vue d’ensemble des LSP conçus pour l’ingénierie du trafic SPRING sur le routeur entrant.
Vérification du trafic SPRING Engineered LSP sur le routeur entrant du routeur PE1
Objet
Vérifiez les LSP conçus pour le trafic SPRING sur le routeur entrant.
Mesures à prendre
À 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)
Signification
La sortie affiche des détails des LSP conçus pour le trafic 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
Objet
Vérifiez les entrées de la table de routage de la table de routage mpls.0 du routeur PE2.
Mesures à prendre
À 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, Pop
Vérification de l’état des segments LSP MPLS statiques du routeur PE2
Objet
Vérifiez l’état des segments LSP MPLS du routeur PE2.
Mesures à prendre
À 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 0
Signification
La sortie affiche l’état des segments LSP statiques MPLS de routeur PE2.
S-BFD basé sur un moteur de routage pour l’ingénierie de trafic de routage de segments avec résolution d’étiquettes de premier saut
Vous pouvez exécuter la détection de transfert bidirectionnelle transparente (S-BFD) sur des chemins de commutation d’étiquettes (LSP) non colorés et 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 les énergies renouvelables pour l’ingénierie de trafic de routage de segments avec la résolution d’étiquettes de premier saut
- S-BFD pour les chemins SRv6 TE
- Configuration du S-BFD basé sur RE pour l’ingénierie de trafic de routage de segments avec résolution d’étiquette de premier saut
- Dérivation automatique du discriminateur à distance (RD) pour session S-BFD
- Exemple : Configuration de la détection de transfert bidirectionnelle transparente (S-BFD) pour SR-TE
Comprendre le S-BFD basé sur les énergies renouvelables pour l’ingénierie de trafic de routage de segments avec la résolution d’étiquettes de premier saut
Tunnels statiques de routage de segments S-BFD pour étiquettes de premier saut
L’architecture de routage de segments permet aux nœuds entrants d’un réseau central de diriger le trafic via des chemins explicites à travers le réseau. Le saut suivant TE (Segment-Routing Traffic Engineering) est une ou plusieurs listes d’identificateurs de segment (SID). Ces listes de segments représentent les chemins du réseau que vous souhaitez emprunter pour le trafic entrant. Le trafic entrant peut être étiqueté ou du trafic IP, et l’opération de transfert au 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 un BFD (S-BFD) transparent sur des LSP de routage de segments statiques non colorés et colorés avec une résolution d’étiquette de premier saut et utiliser S-BFD comme mécanisme rapide pour détecter les défaillances de chemin et déclencher une convergence globale. S-BFD nécessite moins de changements d’état que BFD, ce qui accélère le signalement des défaillances de chemin.
Pour 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. Si une session S-BFD tombe en panne, le logiciel met à jour l’itinéraire du tunnel de routage de segments en supprimant les sauts suivants des LSP ayant échoué. Si l’étiquette de premier saut du LSP pointe vers plusieurs sauts suivants immédiats, le noyau continue d’envoyer des paquets S-BFD si au moins un saut suivant est disponible (la détection des défaillances d’accessibilité du saut suivant sous-jacentes doit être plus rapide que la durée du minuteur 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 étiquettes-pile + famille d’adresses identiques partagent la même session S-BFD. L’adresse source de la session S-BFD est définie sur l’adresse de bouclage la moins configurée (à l’exception des adresses spéciales) 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 « to » dans le tunnel TE de routage de segments. L’état du LSP avec S-BFD configuré dépend également de la disponibilité de BFD : si S-BFD est configuré pour un LSP, la route LSP n’est pas calculée tant que S-BFD n’a pas signalé que le chemin 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
-
Aucune option d’alerte de routeur
Dans le S-BFD, chaque répondant peut avoir plusieurs discriminants. 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 à distance 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é 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 basse est considérée comme la plus agressive. De même pour l’option d’alerte de routeur, si l’une des configurations aucune alerte de routeur n’est configurée, le paramètre S-BFD dérivé n’aura pas d’option d’alerte de routeur.
Limites
-
La réparation globale et locale est prise en charge pour les périphériques MX Series.
-
Même si S-BFD détecte les défaillances en fonction des valeurs de minuterie configurées, le temps de convergence dépend du temps de réparation global (seconds).
S-BFD pour les chemins SRv6 TE
Vous pouvez exécuter S-BFD sur des chemins SRv6 TE pour détecter rapidement les défaillances de chemin. Chaque chemin configuré avec S-BFD dans un tunnel SRv6 TE peut envoyer des sondes à la destination du chemin. Ces sondes suivent les SID du chemin TE et signalent les défaillances de tous les SID se trouvant dans le chemin. Lorsque des défaillances sont détectées, le chemin de tunnel SRv6 TE correspondant est désactivé afin que le trafic puisse être distribué sur des chemins alternatifs.
S-BFD pour SRv6 est pris en charge en mode distribué sur les routeurs entrants et en mode distribué sur les routeurs sortants.
Pour configurer S-BFD pour un chemin SRv6 TE sur un routeur entrant, vous devez configurer un discriminateur local avec l’instruction sbfd local-discriminator number de configuration au niveau de la [edit protocols bfd] hiérarchie. Vous devez également configurer un discriminateur distant avec l’instruction sbfd remote-discriminator number de configuration au niveau de la [edit protocols source-packet-routing source-routing-path name primary name bfd-liveness-detection] hiérarchie.
Pour configurer S-BFD pour les chemins SRv6 TE sur un routeur de sortie, vous devez configurer l’instruction de sbfd local-discriminator number local-ipv6-address address configuration au niveau de la [edit protocols bfd] hiérarchie. Le loca-discriminator répondeur doit correspondre remote-discriminator au chemin configuré sur le chemin TE SRv6 au niveau du routeur entrant
Pour les répondeurs S-BFD qui prennent uniquement en charge l’adresse IPv6 locale, vous pouvez imposer l’utilisation d’une adresse IPv6 locale à l’aide de l’instruction bfd-liveness-detection sbfd destination-ipv6-local-host de configuration au niveau de la [edit protocols source-packet-routing source-routing-path lsp-path-name primary segment-list-name] hiérarchie.
Configuration du S-BFD basé sur RE pour l’ingénierie de trafic de routage de segments avec résolution d’étiquette de premier saut
Pour activer S-BFD au niveau LSP pour une liste de segments, vous configurez l’instruction de bfd-liveness-detection configuration au niveau de la [edit protocols source-packet-routing source-routing-path lsp-path-name primary segment-list-name] hiérarchie et de la [edit protocols source-packet-routing source-routing-path lsp-path-name secondary segment-list-name] hiérarchie.
Les étapes suivantes donnent la configuration de base 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 principal et secondaire.
Sur le routeur entrant, vous configurez le tunnel statique de routage de segments, 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, créant des routes à l’aide des sauts suivants dérivés des étiquettes de premier saut des LSP contributeurs.
Sur le routeur entrant, vous activez l’équilibrage de charge par paquet afin que les routes se résolvant sur les routes entrantes et la route binding-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 segments, vous configurez le mode de réponse S-BFD avec un discriminateur local D, ce qui crée une session d’écouteur 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 étiquette-pile LSP + famille d’adresses 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 et les nouveaux LSP partagés sont pris en compte. 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 de l’initiateur S-BFD s’exécute en mode centralisé sur le moteur de routage. Le logiciel suit les états de connexion S-BFD (Up and Down) de session.
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 de session interrompue 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 segments.
La perte totale de trafic dans la procédure est liée au temps de détection des défaillances S-BFD et au temps de réparation global. Le temps de détection des défaillances S-BFD est déterminé par les paramètres S-BFD minimum-interval et multiplicateur. Le temps de réparation global dépend du temps de traitement du segment routing TE et du nouveau té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 en cas de changement. Si l’ancienne session S-BFD n’a plus de LSP attaché, cette session S-BFD est supprimée.
Le logiciel tente de trouver une session BFD existante qui correspond à la nouvelle valeur de combinaison 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 des 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;
}
}
}
}
}
Côté répondeur, vous devez configurer le bon discriminateur :
[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 d’alerte sans routeur sur le routeur entrant, l’option d’alerte de routeur est supprimée des options IP et donc du côté sortie. Vous devez configurer l’adresse de destination explicitement dans lo0 ; sinon, le paquet est ignoré 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, bfd, pour tracer les activités BFD :
user@host# set protocols source-packet-routing traceoptions flag bfd
Dérivation automatique du discriminateur à distance (RD) pour session S-BFD
Vue d’ensemble
Vous pouvez utiliser le discriminateur à distance dérivé automatiquement pour les sessions S-BFD pour les chemins SR-TE. Avec cette fonctionnalité, vous n’avez pas besoin de configurer une remote-discriminator configuration dans la configuration S-BFD sur l’équipement d’entrée ou de transit et un discriminateur local correspondant sur son point de terminaison respectif. Au lieu de cela, le dispositif PE de sortie acceptera 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 S-BFD commun avec les configurations S-BFD sur plusieurs stratégies SR-TE provisionnées par contrôleur. Dans ces sessions S-BFD, 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, pas 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 des tunnels de couleur SR-TE 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
sbfdconfiguration de ce tunnel.
Exemple : Configuration de la détection de transfert bidirectionnelle transparente (S-BFD) pour SR-TE
Configurez S-BFD pour les chemins de routage de segments afin de détecter rapidement et de manière fiable les défaillances dans le plan de transfert, ce qui permet des mécanismes de reroutage rapide (FRR) dans un réseau de routage de segments. Vous pouvez surveiller les stratégies de routage de segments et les chemins de routage de segments explicitement définis, pour vous assurer que les contraintes d’ingénierie de trafic sont respectées et que les chemins sont opérationnels.
| Score de lisibilité |
|
| Temps de lecture |
Moins de 15 minutes. |
| Temps de configuration |
Moins d’une heure. |
- Exemples de prérequis
- Avant de commencer
- Aperçu fonctionnel
- Présentation de la topologie
- Illustration de la topologie
- Configurer S-BFD sur SR-TE sur R0
- Vérification
- Annexe 1 : Définir des commandes sur tous les appareils
- Annexe 2 : Afficher la sortie de configuration sur R0
Exemples de prérequis
| Exigences matérielles |
Routeurs PTX Series et routeurs MX Series |
| Logiciels exigences |
Junos OS version 23.1R1 ou ultérieure |
Avant de commencer
| Avantages |
Configuration simple : la prise en charge du discriminateur à distance (RD) dérivé automatiquement de l’adresse du point de terminaison du tunnel rend la configuration S-BFD conviviale. Option évolutive : vous pouvez appliquer un modèle S-BFD commun à plusieurs stratégies SR-TE provisionnées par un contrôleur avec RD auto-dérivé. Répartition minimale du trafic : la surveillance des chemins unidirectionnels est idéale pour les chemins de routage séparés asymétriques, ce qui simplifie l’architecture de surveillance pour détecter les défaillances LSP. Moins de surcharge - S-BFD ne crée pas de session BFD distincte pour chaque saut, ce qui réduit la surcharge. |
| En savoir plus |
|
| Expérience pratique |
|
| En savoir plus |
Aperçu fonctionnel
Ce tableau fournit un résumé rapide des composants de configuration déployés dans cet exemple.
| Politiques |
|
| prefix-sid | Définit les ID de segment (SID) pour atteindre l’équipement de sortie, R3. |
| Protocoles |
|
| IS-IS | IS-IS est activé sur tous les appareils. |
| Routage des paquets sources | Il existe deux chemins srpath1 de routage de segments et srpath2, sur lesquels le protocole BFD transparent (S-BFD) est configuré. Il existe un LSP de routage de segments (srlsp1) entre R0 et R3.Le discriminateur local BFD est configuré sur l’appareil R3. |
| MPLS | Le MPLS est activé sur tous les appareils. |
| Tâches de vérification primaire |
|
Présentation de la topologie
Dans cet exemple, l’équipement entrant (R0) initie une session BFD (S-BFD) transparente sur des chemins de routage de segments vers l’équipement de sortie (R3). Le chemin de routage de segments est défini à l’aide de listes de segments (SID) qui spécifient les sauts. L’appareil R3 répond avec un paquet IPv4 simple qui est chiffré avec les informations SID qui sont automatiquement générées en tant que RD automatique.
| Nom d’hôte |
Rôle |
Fonction |
|---|---|---|
| R0 |
Dispositif entrant (initiateur) |
R0 initie la session BFD sur le chemin de routage de segments vers l’équipement R3. |
| R1 |
Équipement de transit | L’un des segments du premier chemin de routage de segments (srpath1) de R0 à R3. |
| R2 |
Équipement de transit | L’un des segments du premier chemin de routage de segments (srpath1) de R0 à R3. |
| R3 |
Dispositif de sortie (répondeur) | Répond avec un paquet IPv4 simple qui est chiffré avec les informations SID qui sont automatiquement générées en tant que RD automatique. |
| R4 |
Équipement de transit | L’un des segments du deuxième chemin de routage de segments (srpath2) de R0 à R3. |
| R5 |
Équipement de transit | L’un des segments du deuxième chemin de routage de segments (srpath2) de R0 à R3. |
Illustration de la topologie
Configurer S-BFD sur SR-TE sur R0
Pour obtenir des exemples complets de configurations sur le DUT, voir :
Vérification
Utilisez la liste des commandes show pour vérifier la fonctionnalité dans cet exemple.
| Commande | Tâche de vérification |
|---|---|
| Afficher la session BFD | Vérifiez que la session BFD est active. |
| show spring-traffic-engineering | Vérifiez le LSP de routage de segments à l’aide de l’option lsp de commande et la valeur RD dérivée automatiquement à l’aide de l’option sbfd de commande. |
| Afficher une session transparente BFD | Vérifiez la session S-BFD sur l’équipement R3. |
- Vérification de session BFD
- Vérification du chemin LSP
- Vérification de session S-BFD sur l’équipement R0
- Vérification de session S-BFD sur l’appareil R3
Vérification de session BFD
Objet
Vérifiez l’état de la session BFD.
Mesures à prendre
En mode opérationnel, entrez la show bfd session extensive commande pour afficher l’état de la session BFD.
user@R0> show bfd session extensive
Detect Transmit
Address State Interface Time Interval Multiplier
127.0.0.1 Up 0.000 2.000 3
Client SPRING-TE, TX interval 1.000, RX interval 1.000
Local diagnostic None, remote diagnostic None
Remote state AdminDown, version 1
Replicated
Session type: Multi hop BFD (Seamless)
Min async interval 1.000, min slow interval 2.000
Adaptive async TX interval 2.000, RX interval 2.000
Local min TX interval 2.000, minimum RX interval 1.000, multiplier 3
Remote min TX interval 0.000, min RX interval 0.000, multiplier 0
Local discriminator 18, remote discriminator 3232235523
Echo TX interval 2.000, echo detection interval 6.000
Echo mode disabled/inactiveno-absorb, no-refresh
Path-Name V4-srte_bfd_session-4
Session ID: 0
Detect Transmit
Address State Interface Time Interval Multiplier
127.0.0.1 Up 3.000 1.000 3
Client SPRING-TE, TX interval 1.000, RX interval 1.000
Session up time 00:18:16
Local diagnostic None, remote diagnostic None
Remote state Up, version 1
Replicated
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 3
Remote min TX interval 1.000, min RX interval 0.000, multiplier 3
Local discriminator 17, remote discriminator 3232235523
Echo TX interval 0.000, echo detection interval 0.000
Echo mode disabled/inactive
Remote is control-plane independent
Path-Name V4-srte_bfd_session-3
Session ID: 0
2 sessions, 2 clients
Cumulative transmit rate 1.5 pps, cumulative receive rate 1.0 pps
Signification
Le statut des sessions BFD est en hausse.
Les sessions sont nommées et V4-srte_bfd_session-4 V4-srte_bfd_session-3. Étant donné que de nombreux LSP peuvent partager la même session BFD, lorsque le premier LSP avec une combinaison unique de label-stack + address-family apparaît, S-BFD utilise la address-family + lsp-name combinaison pour le nom de session. Si plus tard, plusieurs LSP partagent la même session, le nom de la session peut être remplacé par address-family + least-lsp-name, sans affecter l’état de la session S-BFD.
Vérification du chemin LSP
Objet
Vérifiez que le LSP de routage de segments (srlsp1) est configuré et que l’état de la session S-BFD est visible. Vérifiez le chemin parcouru par srlsp1 pour atteindre l’appareil R3.
Mesures à prendre
À partir du mode opérationnel, entrez la commande show spring-traffic-engineering lsp name srlsp1 detail pour comprendre le chemin parcouru par le LSP de routage de segments.
user@R0> show spring-traffic-engineering lsp name srlsp1 detail
E = Entropy-label Capability
Name: srlsp1
Tunnel-source: Static configuration
Tunnel Forward Type: SRMPLS
To: 192.168.0.3
Te-group-id: 0
State: Up
Path: srpath1
Path Status: NA
Outgoing interface: NA
Auto-translate status: Enabled Auto-translate result: Success
Compute Status:Disabled , Compute Result:N/A , Compute-Profile Name:N/A
BFD status: Up BFD name: V4-srte_bfd_session-3
BFD remote-discriminator: 3232235523(auto-derived)
Segment ID : 128
ERO Valid: true
SR-ERO hop count: 3
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.11.2.2
SID type: 20-bit label, Value: 16
Hop 2 (Loose):
NAI: IPv4 Node ID, Node address: 192.168.0.2
SID type: 20-bit label, Value: 801002
Hop 3 (Loose):
NAI: IPv4 Node ID, Node address: 192.168.0.3
SID type: 20-bit label, Value: 801003
Path: srpath2
Path Status: NA
Outgoing interface: NA
Auto-translate status: Enabled Auto-translate result: Success
Compute Status:Disabled , Compute Result:N/A , Compute-Profile Name:N/A
BFD status: Down BFD name: V4-srte_bfd_session-4
BFD remote-discriminator: 3232235523(auto-derived)
Segment ID : 256
ERO Valid: true
SR-ERO hop count: 1
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.14.1.2
SID type: 20-bit label, Value: 17
Total displayed LSPs: 1 (Up: 1, Down: 0, Initializing: 0)
Signification
Vérifiez les sauts parcourus par le LSP pour atteindre le dernier saut, l’équipement R3.
La sortie de chaque LSP affiche le statut S-BFD ainsi que le nom S-BFD auquel il fait référence. Étant donné qu’il n’y a peut-être pas une session S-BFD par LSP, les compteurs S-BFD au niveau LSP ne sont pas affichés.
Vérification de session S-BFD sur l’équipement R0
Objet
Vérifiez l’état des sessions S-BFD sur les deux chemins de routage de segments sur l’équipement R0.
Mesures à prendre
À partir du mode opérationnel, entrez la commande show spring-traffic-engineering sbfd detailpour vérifier l’état de la session S-BFD.
user@R0> show spring-traffic-engineering sbfd detail
BFD name: V4-srte_bfd_session-4
BFD status: Up
BFD remote-discriminator: 3232235523
BFD local-discriminator: 18
Referencing LSPs:
srlsp1:srpath2
SR-ERO hop count: 1
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.14.1.2
SID type: 20-bit label, Value: 17
BFD name: V4-srte_bfd_session-3
BFD status: Up
BFD remote-discriminator: 3232235523
BFD local-discriminator: 17
Referencing LSPs:
srlsp1:srpath1
SR-ERO hop count: 3
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.11.2.2
SID type: 20-bit label, Value: 16
Hop 2 (Loose):
NAI: IPv4 Node ID, Node address: 192.168.0.2
SID type: 20-bit label, Value: 801002
Hop 3 (Loose):
NAI: IPv4 Node ID, Node address: 192.168.0.3
SID type: 20-bit label, Value: 801003
Total displayed BFD sessions: 2 (Up: 2, Down: 0)
Signification
Les sessions S-BFD sont actives et l’appareil R0 peut atteindre l’équipement R3.
Vérification de session S-BFD sur l’appareil R3
Objet
Vérifiez l’état des sessions S-BFD sur le répondeur BFD, Device R3.
Mesures à prendre
En mode opérationnel, entrez la commande show bfd seamless session extensivepour vérifier l’état de la session S-BFD.
user@R3> show bfd seamless session extensive
Receive
Type Descriminator Table Address State Interval
Local 3232235523 (192.168.0.3) default Up 0.050
Logical system id 0, Route table id 0
ISSU State: false
Authentication: false
1 local sessions, 0 remote sessions
Signification
La session S-BFD est active et le discriminateur local BFD configuré correspond à la valeur du discriminateur à distance BFD.
Annexe 1 : Définir des commandes sur tous les appareils
R0 set system host-name R1 set chassis network-services enhanced-ip set interfaces et-0/0/5 unit 0 description "CONNECTED TO R4" set interfaces et-0/0/5 unit 0 family inet address 10.14.1.1/24 set interfaces et-0/0/5 unit 0 family iso set interfaces et-0/0/5 unit 0 family mpls set interfaces et-1/0/3 unit 0 description "CONNECTED TO R1" set interfaces et-1/0/3 unit 0 family inet address 10.11.2.1/24 set interfaces et-1/0/3 unit 0 family iso set interfaces et-1/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.0/32 set interfaces lo0 unit 0 family iso address 49.0001.000a.0a0a.0a00 set policy-options policy-statement prefix-sid term 1 from route-filter 192.168.0.0/32 exact set policy-options policy-statement prefix-sid term 1 then prefix-segment index 100 set policy-options policy-statement prefix-sid term 1 then prefix-segment node-segment set policy-options policy-statement prefix-sid term 1 then accept set routing-options router-id 192.168.0.0 set routing-options autonomous-system 64512 set routing-options rib-groups test import-rib inet.0 set routing-options rib-groups test import-rib inet.3 set protocols isis interface et-0/0/5.0 level 2 metric 20 set protocols isis interface et-0/0/5.0 node-link-protection set protocols isis interface et-0/0/5.0 point-to-point set protocols isis interface et-1/0/3.0 level 2 metric 20 set protocols isis interface et-1/0/3.0 node-link-protection set protocols isis interface et-1/0/3.0 point-to-point set protocols isis interface all ldp-synchronization set protocols isis interface all node-link-protection set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0 disable set protocols isis source-packet-routing adjacency-segment hold-time 240000 set protocols isis source-packet-routing srgb start-label 800000 set protocols isis source-packet-routing srgb index-range 80000 set protocols isis source-packet-routing explicit-null set protocols isis source-packet-routing traffic-statistics statistics-granularity per-interface set protocols isis level 1 disable set protocols isis level 2 wide-metrics-only set protocols isis level 2 preference 180 set protocols isis backup-spf-options remote-backup-calculation set protocols isis backup-spf-options use-source-packet-routing set protocols isis traffic-engineering l3-unicast-topology set protocols isis traffic-engineering family inet shortcuts set protocols isis export prefix-sid set protocols isis ignore-attached-bit set protocols isis rib-group inet test set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols source-packet-routing segment-list srpath1 auto-translate unprotected set protocols source-packet-routing segment-list srpath1 hop1 ip-address 10.11.2.2 set protocols source-packet-routing segment-list srpath1 hop2 ip-address 192.168.0.2 set protocols source-packet-routing segment-list srpath1 hop2 label-type node set protocols source-packet-routing segment-list srpath1 hop3 ip-address 192.168.0.3 set protocols source-packet-routing segment-list srpath1 hop3 label-type node set protocols source-packet-routing segment-list srpath2 auto-translate unprotected set protocols source-packet-routing segment-list srpath2 hop1 ip-address 10.14.1.2 set protocols source-packet-routing source-routing-path srlsp1 to 192.168.0.3 set protocols source-packet-routing source-routing-path srlsp1 primary srpath1 weight 23 set protocols source-packet-routing source-routing-path srlsp1 primary srpath1 bfd-liveness-detection sbfd set protocols source-packet-routing source-routing-path srlsp1 primary srpath1 bfd-liveness-detection minimum-interval 1000 set protocols source-packet-routing source-routing-path srlsp1 primary srpath2 weight 45 set protocols source-packet-routing source-routing-path srlsp1 primary srpath2 bfd-liveness-detection sbfd set protocols source-packet-routing source-routing-path srlsp1 primary srpath2 bfd-liveness-detection minimum-interval 1000 set protocols source-packet-routing inherit-label-nexthops
R1 set system host-name R1 set chassis network-services enhanced-ip set interfaces xe-0/3/0 unit 0 description "CONNECTED TO R0" set interfaces xe-0/3/0 unit 0 family inet address 10.11.2.2/24 set interfaces xe-0/3/0 unit 0 family iso set interfaces xe-0/3/0 unit 0 family mpls set interfaces xe-0/3/1 unit 0 description "CONNECTED TO R2" set interfaces xe-0/3/1 unit 0 family inet address 11.12.1.1/24 set interfaces xe-0/3/1 unit 0 family iso set interfaces xe-0/3/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.1/32 set interfaces lo0 unit 0 family iso address 49.0001.0001.0101.0100 set policy-options policy-statement prefix-sid term 1 from route-filter 192.168.0.1/32 exact set policy-options policy-statement prefix-sid term 1 then prefix-segment index 1001 set policy-options policy-statement prefix-sid term 1 then prefix-segment node-segment set policy-options policy-statement prefix-sid term 1 then accept set routing-options router-id 192.168.0.1 set routing-options autonomous-system 64512 set routing-options rib-groups test import-rib inet.0 set routing-options rib-groups test import-rib inet.3 set protocols isis backup-spf-options remote-backup-calculation set protocols isis backup-spf-options use-source-packet-routing set protocols isis backup-spf-options per-prefix-calculation set protocols isis traffic-engineering family inet shortcuts set protocols isis source-packet-routing adjacency-segment hold-time 240000 set protocols isis source-packet-routing srgb start-label 800000 set protocols isis source-packet-routing srgb index-range 80000 set protocols isis source-packet-routing explicit-null set protocols isis level 1 disable set protocols isis level 1 wide-metrics-only set protocols isis level 2 wide-metrics-only set protocols isis interface xe-0/3/0.0 point-to-point set protocols isis interface xe-0/3/0.0 node-link-protection set protocols isis interface xe-0/3/1.0 point-to-point set protocols isis interface xe-0/3/1.0 node-link-protection set protocols isis interface all node-link-protection set protocols isis interface em0.0 disable set protocols isis interface fxp0.0 disable set protocols isis export prefix-sid set protocols isis ignore-attached-bit set protocols isis rib-group inet test set protocols mpls traffic-engineering set protocols mpls interface all
R2 set system host-name R2 set chassis network-services enhanced-ip set interfaces xe-0/2/1 unit 0 description "CONNECTED TO R1" set interfaces xe-0/2/1 unit 0 family inet address 11.12.1.2/24 set interfaces xe-0/2/1 unit 0 family iso set interfaces xe-0/2/1 unit 0 family mpls set interfaces xe-0/3/0 unit 0 description "CONNECTED TO R3" set interfaces xe-0/3/0 unit 0 family inet address 12.13.1.1/24 set interfaces xe-0/3/0 unit 0 family iso set interfaces xe-0/3/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.2/32 set interfaces lo0 unit 0 family iso address 49.0001.0002.0202.0200 set policy-options policy-statement prefix-sid term 1 from route-filter 192.168.0.2/32 exact set policy-options policy-statement prefix-sid term 1 then prefix-segment index 1002 set policy-options policy-statement prefix-sid term 1 then prefix-segment node-segment set policy-options policy-statement prefix-sid term 1 then accept set routing-options router-id 192.168.0.2 set routing-options autonomous-system 64512 set protocols isis backup-spf-options remote-backup-calculation set protocols isis backup-spf-options use-source-packet-routing set protocols isis traffic-engineering family inet shortcuts set protocols isis source-packet-routing adjacency-segment hold-time 240000 set protocols isis source-packet-routing srgb start-label 800000 set protocols isis source-packet-routing srgb index-range 80000 set protocols isis source-packet-routing explicit-null set protocols isis level 1 disable set protocols isis level 1 wide-metrics-only set protocols isis level 2 wide-metrics-only set protocols isis interface xe-0/2/1.0 point-to-point set protocols isis interface xe-0/2/1.0 node-link-protection set protocols isis interface xe-0/3/0.0 point-to-point set protocols isis interface xe-0/3/0.0 node-link-protection set protocols isis interface all node-link-protection set protocols isis interface em0.0 disable set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0 passive set protocols isis export prefix-sid set protocols isis ignore-attached-bit set protocols mpls interface all
R3 set system host-name R3 set chassis network-services enhanced-mode set interfaces et-0/0/1 unit 0 description "CONNECTED TO R2" set interfaces et-0/0/1 unit 0 family inet address 12.13.1.2/24 set interfaces et-0/0/1 unit 0 family iso set interfaces et-0/0/1 unit 0 family mpls set interfaces et-0/0/3 unit 0 description "CONNECTED TO R5" set interfaces et-0/0/3 unit 0 family inet address 10.15.1.1/24 set interfaces et-0/0/3 unit 0 family iso set interfaces et-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.3/32 set interfaces lo0 unit 0 family iso address 49.0001.0003.0303.0300 set policy-options policy-statement prefix-sid term 1 from route-filter 192.168.0.3/32 exact set policy-options policy-statement prefix-sid term 1 then prefix-segment index 1003 set policy-options policy-statement prefix-sid term 1 then prefix-segment node-segment set policy-options policy-statement prefix-sid term 1 then accept set routing-options router-id 192.168.0.3 set routing-options autonomous-system 64512 set protocols bfd sbfd local-discriminator-ip 192.168.0.3 set protocols isis interface et-0/0/1.0 node-link-protection set protocols isis interface et-0/0/1.0 point-to-point set protocols isis interface et-0/0/3.0 node-link-protection set protocols isis interface et-0/0/3.0 point-to-point set protocols isis interface all ldp-synchronization set protocols isis interface all node-link-protection set protocols isis interface em0.0 disable set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0 passive set protocols isis source-packet-routing adjacency-segment hold-time 240000 set protocols isis source-packet-routing srgb start-label 800000 set protocols isis source-packet-routing srgb index-range 80000 set protocols isis source-packet-routing explicit-null set protocols isis level 1 disable set protocols isis level 1 wide-metrics-only set protocols isis level 2 wide-metrics-only set protocols isis backup-spf-options remote-backup-calculation set protocols isis backup-spf-options use-source-packet-routing set protocols isis export prefix-sid set protocols isis ignore-attached-bit set protocols mpls interface all
R4 set system host-name R4 set chassis network-services enhanced-ip set interfaces xe-0/2/0 description "CONNECTED TO R0" set interfaces xe-0/2/0 unit 0 family inet address 10.14.1.2/24 set interfaces xe-0/2/0 unit 0 family iso set interfaces xe-0/2/0 unit 0 family mpls set interfaces xe-0/3/0 unit 0 description "CONNECTED TO R5" set interfaces xe-0/3/0 unit 0 family inet address 10.15.1.1/24 set interfaces xe-0/3/0 unit 0 family iso set interfaces xe-0/3/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.4/32 set interfaces lo0 unit 0 family iso address 49.0001.0004.0404.0400 set policy-options policy-statement prefix-sid term 1 from route-filter 192.168.0.4/32 exact set policy-options policy-statement prefix-sid term 1 then prefix-segment index 1004 set policy-options policy-statement prefix-sid term 1 then prefix-segment node-segment set policy-options policy-statement prefix-sid term 1 then accept set routing-options router-id 192.168.0.4 set routing-options autonomous-system 64512 set protocols isis backup-spf-options remote-backup-calculation set protocols isis backup-spf-options use-source-packet-routing set protocols isis traffic-engineering family inet-mpls shortcuts set protocols isis traffic-engineering family inet shortcuts set protocols isis source-packet-routing adjacency-segment hold-time 240000 set protocols isis source-packet-routing srgb start-label 800000 set protocols isis source-packet-routing srgb index-range 80000 set protocols isis source-packet-routing explicit-null set protocols isis level 1 disable set protocols isis level 1 wide-metrics-only set protocols isis level 2 wide-metrics-only set protocols isis interface xe-0/2/0.0 point-to-point set protocols isis interface all node-link-protection set protocols isis interface all ldp-synchronization set protocols isis interface em0.0 disable set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0 passive set protocols isis export prefix-sid set protocols isis ignore-attached-bit set protocols isis suppress-attached-bit set protocols mpls interface all
R5 set system host-name R5 set chassis network-services enhanced-ip set interfaces xe-0/2/0 unit 0 description "CONNECTED To R3" set interfaces xe-0/2/0 unit 0 family inet address 10.15.1.2/24 set interfaces xe-0/2/0 unit 0 family iso set interfaces xe-0/2/0 unit 0 family mpls set interfaces xe-0/2/1 unit 0 description "CONNECTED To R4" set interfaces xe-0/2/1 unit 0 family inet address 10.16.1.2/24 set interfaces xe-0/2/1 unit 0 family iso set interfaces xe-0/2/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.5/32 set interfaces lo0 unit 0 family iso address 49.0001.0005.0505.0500 set policy-options policy-statement prefix-sid term 1 from route-filter 192.168.0.5/32 exact set policy-options policy-statement prefix-sid term 1 then prefix-segment index 1005 set policy-options policy-statement prefix-sid term 1 then prefix-segment node-segment set policy-options policy-statement prefix-sid term 1 then accept set routing-options router-id 192.168.0.5 set routing-options autonomous-system 64512 set protocols isis backup-spf-options remote-backup-calculation set protocols isis backup-spf-options use-source-packet-routing set protocols isis traffic-engineering family inet shortcuts set protocols isis source-packet-routing adjacency-segment hold-time 240000 set protocols isis source-packet-routing srgb start-label 800000 set protocols isis source-packet-routing srgb index-range 80000 set protocols isis source-packet-routing explicit-null set protocols isis level 1 disable set protocols isis level 1 wide-metrics-only set protocols isis level 2 wide-metrics-only set protocols isis interface xe-0/2/0.0 point-to-point set protocols isis interface xe-0/2/1.0 point-to-point set protocols isis interface all node-link-protection set protocols isis interface all ldp-synchronization set protocols isis interface em0.0 disable set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0 passive set protocols isis export prefix-sid set protocols isis ignore-attached-bit set protocols mpls interface all
Annexe 2 : Afficher la sortie de configuration sur R0
Afficher la sortie de configuration sur l’appareil R0.
user@R0# show interfaces
et-0/0/5 {
unit 0 {
description "CONNECTED TO R4";
family inet {
address 10.14.1.1/24;
}
family iso;
family mpls;
}
}
et-1/0/3 {
unit 0 {
description "CONNECTED TO R1";
family inet {
address 10.11.2.1/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.0/32;
}
family iso {
address 49.0001.000a.0a0a.0a00;
}
}
}
usre@R0# show policy-options
policy-statement prefix-sid {
term 1 {
from {
route-filter 192.168.0.0/32 exact;
}
then {
prefix-segment {
index 100;
node-segment;
}
accept;
}
}
}
user@R0# show routing-options
router-id 192.168.0.0;
autonomous-system 64512;
rib-groups {
test {
import-rib [ inet.0 inet.3 ];
}
}
user@R0# show protocols
isis {
interface et-0/0/5.0 {
level 2 metric 20;
node-link-protection;
point-to-point;
}
interface et-1/0/3.0 {
level 2 metric 20;
node-link-protection;
point-to-point;
}
interface all {
ldp-synchronization;
node-link-protection;
}
interface fxp0.0 {
disable;
}
interface lo0.0 {
disable;
}
source-packet-routing {
adjacency-segment hold-time 240000;
srgb start-label 800000 index-range 80000;
explicit-null;
traffic-statistics {
statistics-granularity per-interface;
}
}
level 1 disable;
level 2 {
wide-metrics-only;
preference 180;
}
backup-spf-options {
remote-backup-calculation;
use-source-packet-routing;
}
traffic-engineering {
l3-unicast-topology;
family inet {
shortcuts;
}
}
export prefix-sid;
ignore-attached-bit;
rib-group inet test;
}
mpls {
interface all;
interface fxp0.0 {
disable;
}
}
source-packet-routing {
segment-list srpath1 {
auto-translate {
unprotected;
}
hop1 ip-address 10.11.2.2;
hop2 {
ip-address 192.168.0.2;
label-type {
node;
}
}
hop3 {
ip-address 192.168.0.3;
label-type {
node;
}
}
}
segment-list srpath2 {
auto-translate {
unprotected;
}
hop1 ip-address 10.14.1.2;
}
source-routing-path srlsp1 {
to 192.168.0.3;
primary {
srpath1 {
weight 23;
bfd-liveness-detection {
sbfd;
minimum-interval 1000;
}
}
srpath2 {
weight 45;
bfd-liveness-detection {
sbfd;
minimum-interval 1000;
}
}
}
}
inherit-label-nexthops;
}
Configuration de l’identificateur de segment d’adjacence statique pour les liaisons membres Ethernet agrégées à l’aide de LSP statique à saut unique
Dans un réseau où des offres Ethernet agrégées (AE) sont utilisées, une liaison agrégée peut être un ensemble de n’importe quel nombre 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 équilibrer le trafic, ce qui rend difficile d’isoler les liens qui ont mal tourné ou qui abandonnent le trafic. Pour tester le chemin de transfert disponible sur le réseau, vous pouvez 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’étiquette 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 de membre. Ces étiquettes sont appelées identificateurs de segments d’adjacence (SID) et sont provisionnées de manière statique.
Vous pouvez contrôler le flux de paquets sur 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’opération, 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 étiquette, l’étiquette est affichée et le trafic est transféré sur le lien de membre spécifié 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 agrégée est active, la route correspondant à ce lien membre est supprimée. Lorsqu’une interface agrégée tombe en panne, toutes les routes correspondant aux liens membres de l’interface agrégée sont supprimées. Lorsque l’interface physique enfant est détachée de LACP mais que l’interface physique enfant est opérationnelle, la route étiquetée pour la liaison enfant est supprimée. Dans le cas d’un détachement LACP, si la liaison membre est active et que l’état de transfert n’est pas 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 un lien de 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 de 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 saut suivant. L’adresse de saut suivante 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 choisir 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 :
Afficher MPLS statique-LSP extensif
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 188765184
Points de terminaison sans ID de routeur dans l’ingénierie de trafic de Segment Routing
Historiquement, RSVP-TE prenait en charge les points de terminaison sans ID de routeur. L’ajout de points de terminaison autres que des identifiants de routeur dans les politiques de Segment Routing Traffic Engineering (SR-TE) améliore la flexibilité et l’efficacité de votre réseau sur IPv4 et IPv6 dans les frameworks SR-MPLS. Le point de terminaison sans ID de routeur dans SR-TE permet aux routeurs entrants de diriger le trafic vers des destinations logiques (par exemple, l’adresse de service anycast) plutôt que d’être contraints à des ID de routeur de nœud. En activant les spécifications des adresses anycast, de bouclage secondaire (lo0) et des préfixes d’interface comme points de destination, vous obtenez un équilibrage de charge et une redondance robustes.
Traditionnellement, les stratégies SR-TE utilisent des ID de routeur, mais vous pouvez spécifier des adresses anycast pour améliorer la redondance et l’équilibrage de charge dans les réseaux SR-MPLS. Utilisez des adresses anycast IPv4 et IPv6 comme destinations apprises par l’IGP avec ou sans compression de la pile SID. Ces adresses anycast ne sont pas redistribuées (R-bit set). Utilisez-les comme adresse pour les stratégies SR-TE avec les profils de calcul associés.
- Avantages des points de terminaison sans identification de routeur pour SR-TE
- anycast comme adresse de destination
Avantages des points de terminaison sans identification de routeur pour SR-TE
-
Améliore la flexibilité du réseau en ciblant plusieurs nœuds annonçant un préfixe partagé, ce qui facilite l’équilibrage de charge et la redondance.
-
Étend les configurations SR-TE avec des adresses anycast, offrant ainsi davantage d’options pour la conception et l’optimisation du réseau.
-
Améliore le contrôle des paquets entrants sans contraintes supplémentaires liées à l’ingénierie du trafic, ce qui permet une gestion efficace du réseau.
-
Optimise les chemins de routage pour renforcer les performances du réseau, assurer une répartition transparente du trafic et une résilience accrue.
anycast comme adresse de destination
Plusieurs nœuds peuvent annoncer une seule adresse IP anycast (IPv4 ou IPv6) et les SID anycast correspondants sur un domaine IGP.
Un SID anycast est un type de SID de préfixe qui identifie un ensemble de nœuds. L’ensemble de nœuds (groupe anycast) est configuré pour annoncer une adresse de préfixe et un SID de préfixe partagés. Le routage anycast permet d’orienter le trafic vers plusieurs nœuds publicitaires, assurant ainsi l’équilibrage de charge et la redondance. Les paquets adressés à une adresse anycast sont transférés aux nœuds topologiquement les plus proches.
Un routeur entrant est configuré avec une politique SR-TE utilisant l’adresse IP anycast (IPv4 ou IPv6) comme point de terminaison.
Utilisez la commande pour afficher des détails complets sur les points de terminaison sans ID de routeur, en affichant les segments calculés et les show spring-traffic-engineering detail détails des SID anycast. Utilisez ces commandes pour vous assurer que les politiques SR-TE sont correctement implémentées, ce qui permet une distribution transparente du trafic et des chemins de routage optimisés.
Délais de calcul Chemins de Segment Routing intra-domaine et interdomaine optimisés
- Vue d’ensemble des mesures basées sur le retard pour les chemins d’ingénierie du trafic
- Avantages des mesures basées sur le retard pour le calcul des chemins
- Calcul basé sur DCSPF avec mesures de retard pour la présentation des chemins SR
- Mesures de retard pour les cas d’utilisation interdomaine et intradomaine Présentation
- Mesures de retard dans les réseaux optiques
Vue d’ensemble des mesures basées sur le retard pour les chemins d’ingénierie du trafic
L’utilisation de mesures dynamiques basées sur les retards devient un atout souhaitable dans les réseaux modernes. Les métriques basées sur le délai sont essentielles pour qu’un élément PCE (Path Computation Element) puisse calculer les chemins conçus pour le trafic. Vous pouvez utiliser des métriques basées sur le retard pour diriger les paquets sur les chemins les plus latence ou les moins retardés. Pour ce faire, vous devez mesurer le retard sur chaque liaison et l’annoncer à l’aide d’un protocole de routage approprié (IGP ou BGP-LS), afin que l’entrée ait les propriétés de retard par liaison dans son TED.
Pour savoir comment annoncer le délai sur chaque liaison ou activer les mesures de liaison, consultez Comment activer la mesure et la publicité du délai de liaison dans IS-IS.
La séquence d’événements suivante se produit lorsque vous mesurez, annoncez et calculez la détection de changements dans le réseau et calculez le chemin conçu du trafic avec la plus faible latence :
- Détectez les changements dans le réseau en mesurant la latence, avec des sondes synthétiques, de routeur à routeur.
- Inondez les résultats vers les nœuds entrants via des extensions TE-métriques é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 les plus courts basés sur l’IGP (Flex-algo).
- Calculez les chemins explicites conçus pour le trafic (de la source à la destination) avec des mesures de latence ou de retard cumulées les plus courtes (SR-TE).
Avantages des mesures basées sur le retard pour le calcul des chemins
- Déployez des services à valeur ajoutée en fonction de la plus faible latence sur l’ensemble du réseau.
- Mesurez la latence par chemin (minimum, maximum, moyenne) à l’aide de métriques basées sur le retard.
- Dirigez les services sensibles au retard (tels que les services VPN ou 5G) sur des chemins optimisés pour la SR à très faible latence.
Calcul basé sur DCSPF avec mesures de retard pour la présentation des chemins SR
À l’aide de la fonctionnalité distribuée CSPF (Constrained Shortest Path First) pour le routage de segments, vous pouvez calculer un LSP de routage de segments localement sur le périphérique entrant en fonction des contraintes que vous avez configurées. Cette fonctionnalité permet d’optimiser les LSP en fonction des contraintes configurées et du type de métrique (ingénierie de trafic ou IGP). Les LSP sont calculés pour utiliser les chemins ECMP disponibles vers la destination avec la compression de la pile d’étiquettes de routage de segments activée ou désactivée.
Vous pouvez configurer le CSFP distribué pour qu’il s’exécute sur plusieurs têtes de réseau et effectuer des calculs 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 de retard, vous pouvez également appliquer une contrainte appelée . Lorsque vous configurez une valeur pour delay-variation-threshold, toute liaison dépassant la valeur de seuil est exclue du calcul du chemin.
Pour configurer les métriques de retard pour le calcul basé sur DCSPF pour le chemin SR, vous devez activer l’instruction de delay configuration au niveau de la hiérarchie [edit protocols source-packet-routing compute-profile profile-name metric-type delay]. Vous pouvez configurer les mesures de retard telles que le minimum, le maximum, la moyenne et le seuil de variation du délai pour le calcul du chemin.
minimum: valeur de la métrique de retard minimale de TED pour le calcul du chemin de latence cumulé le plus faible.average—Valeur métrique de retard moyenne de TED pour le calcul du chemin de latence cumulé le plus faible.maximum: valeur maximale de la métrique de retard de TED pour le calcul du chemin de latence cumulé le plus faible.delay-variation-threshold—Seuil de variation du retard de liaison (1..16777215). Toute liaison dépassant le seuil de variation de retard serait exclue du calcul du chemin. Le seuil de variation du délai est indépendant selon que vous effectuez une optimisation pour le minimum, le maximum ou la moyenne. L’instructiondelay-variation-thresholdde configuration apparaît 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 retard au niveau de la hiérarchie CLI suivante :
[edit]
protocols {
source-packet-routing {
compute-profile <name> {
metric-type delay {
minimum;
maximum;
average;
delay-variation-threshold <value>;
}
}
}
}
Mesures de retard pour les cas d’utilisation interdomaine et intradomaine Présentation
Pour 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 si les coûts sont égaux. Vous pouvez configurer des SID non compressés à l’aide de l’instruction no-label-stack-compression de configuration au niveau de la hiérarchie [edit protocols source-packet-routing compute-profile profile-name ]. Cela fournit un chemin entièrement étendu à l’aide de SID d’adjacence. Voir compute-profile pour plus d’informations.
Voici un exemple de configuration des mesures de retard :
[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 au minimum les métriques de retard. Minimum est la configuration par défaut.
Pour les cas d’utilisation interdomaines (multidomaines), où il existe plusieurs systèmes autonomes, vous pouvez utiliser Express Segments pour configurer les retards de liaison pour le calcul du chemin. Les segments Express sont des liens qui relient des nœuds de bordure ou des ASBR. Voir Configuration LSP Express Segment pour en savoir plus sur Express Segments. 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 retards minimum, maximum et moyen.
Vous pouvez configurer les mesures de retard dans un segment express selon la hiérarchie CLI suivante :
[edit]
protocols {
express-segments {
segment-template <name> {
metric delay [ min <value> | avg <value> | max <value>
}
}
}
Pour le calcul de chemin interdomaines, vous pouvez attribuer des mesures de retard sur les liaisons EPE BGP. 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>
}
}
}
}
}
Mesures de retard dans les réseaux optiques
Les topologies suivantes représentent un exemple de cas d’utilisation optique. Les solutions de protection et de restauration optiques entraînent une modification des attributs physiques sous-jacents, principalement la longueur du chemin, en raison des défaillances de liaison et de l’optimisation ultérieure du réseau DWDM.
Sur la figure, le lien 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 nœuds optiques O1 et O3 et que la connexion optique réelle est réacheminée via le nœud 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 retard et le routeur principal réachemine le chemin sur le chemin de moindre latence disponible suivant. La modification du délai de liaison peut amener l’entrée à choisir un autre ensemble de liaisons qui présente le chemin de latence le plus faible. Sur la figure B, vous pouvez voir qu’il y a un changement dans la liaison entre le chemin A et C et le routeur principal redirige et sélectionne le chemin A-B-C comme indiqué dans la topologie.
Comprendre le calcul du chemin local d’un tunnel SRv6 TE
Vue d’ensemble
La mise en œuvre de calculs locaux pour les tunnels SRv6 TE, y compris les SID classiques et de microsegmentation (uSID), améliore considérablement les capacités de calcul des chemins au sein de votre réseau. En utilisant les SID SRv6, vous pouvez calculer de manière dynamique et efficace les chemins d’ingénierie de trafic à l’aide des SID SRv6, en fonction de la topologie et des contraintes actuelles du réseau. Les options de configuration vous permettent d’activer le calcul du chemin SRv6 TE, d’attacher des profils de calcul et de définir des contraintes d’instance et de topologie IGP. De plus, les préférences pour les types de SID et la prise en charge de la détection de transfert bidirectionnelle transparente (sBFD) sur les tunnels de calcul SRv6 TE garantissent un routage optimisé et une grande efficacité du réseau, ce qui fait de cette fonctionnalité la partie intégrante de la conception évolutive et adaptative du réseau.
Avantages du calcul local du tunnel SRv6 TE
-
Optimise l’efficacité du réseau en calculant dynamiquement les chemins d’ingénierie du trafic en fonction de la topologie et des contraintes en temps réel, ce qui réduit les frais généraux inutiles et améliore l’utilisation des ressources.
-
Améliore l’évolutivité en prenant en charge les SID SRv6 classiques et les uSID, ce qui permet un routage et une gestion plus efficaces des listes de segments.
-
Facilite le routage adaptatif grâce au calcul local, ce qui permet d’ajuster rapidement les modifications apportées au réseau sans dépendre de sources de calcul externes.
-
Garantit une efficacité et une fiabilité élevées du réseau grâce à la prise en charge de sBFD sur les tunnels SRv6 TE, fournissant des mécanismes robustes de détection et de réponse aux défaillances.
Configuration du calcul du chemin local d’un tunnel SRv6 TE
Pour configurer le calcul du chemin SRv6 TE, utilisez les configurations CLI suivantes :
Comprendre VPN BGP Option C : MPLS sur SRv6
La VPN BGP Option C avec MPLS sur Segment Routing pour IPv6 (SRv6) améliore les architectures réseau multidomaines en facilitant l’interopérabilité transparente entre les domaines SR-MPLS pour IPv4 (SR-MPLS-IPv4) et SRv6. Cette fonctionnalité utilise SRv6 comme couche de transport, ce qui vous permet d’annoncer les identificateurs de segment SRv6 (SID) aux côtés des étiquettes MPLS pour un routage et un transfert optimaux.
- Avantages du VPN BGP Option C avec MPLS par rapport à SRv6
- Vue d’ensemble
- Le LSP BGP-LU est tunnelisé sur le domaine SRv6
- Activer la signalisation SRv6 pour la famille d’adresses BGP-LU
- Comportement des routes de sortie
- Comportement de la route entrante
- Comportement des itinéraires de transit
- Configurer end-dtm-sid
- Configurer advertise-srv6-service pour la famille d’adresses BGP-LU
- Configurer accept-srv6-service pour la famille d’adresses BGP-LU
- Configurer end-dtm-sid avec la stratégie
Avantages du VPN BGP Option C avec MPLS par rapport à SRv6
-
Améliore l’évolutivité du réseau en permettant une intégration transparente des domaines MPLS et SRv6, ce qui facilite un routage efficace dans les environnements multidomaines.
-
Améliore la flexibilité du routage grâce aux identificateurs de segment (SID) SRv6 et aux étiquettes MPLS, ce qui permet des scénarios de transport dynamiques et une livraison optimale des paquets.
-
Permet un contrôle précis des chemins de routage grâce à la prise en charge des configurations des itinéraires d’entrée, de sortie et de transit, ce qui garantit une manipulation précise des étiquettes et un transfert efficace des données.
-
Améliore la robustesse et la fiabilité du réseau grâce à la haute disponibilité des SID dynamiques SRv6, ce qui réduit les interruptions de service.
-
Prend en charge les opérations réseau avancées en permettant la publication et l’acceptation des services SRv6 dans les familles d’adresses BGP-LU, améliorant ainsi l’interopérabilité et la gestion des services dans les configurations réseau complexes.
Vue d’ensemble
Prenons l’exemple d’un réseau multidomaine, où se trouve un domaine central (C) entouré de nombreux domaines leaf. Les flux de service partent d’un PE entrant dans un domaine leaf (LI) entrant, en passant par le domaine central (C) et jusqu’à un PE de sortie du domaine leaf de sortie (LE). Chaque domaine exécute sa propre instance IGP. Les domaines leaf (LI et LE) utilisent le plan de données MPLS (SR-MPLS-IPv4), tandis que le domaine central (C) utilise le plan de données SRv6.
Les équipements de périphérie des fournisseurs sont exécutés MPLS des services basés BGP la couche 3 (par exemple, VPN) via des réflecteurs de route de service. La signalisation des points de terminaison de service à travers les routeurs de bordure et l’état de transfert correspondant assurent l’interopérabilité sur le domaine de transport intermédiaire. Le PE entrant encapsule la charge utile dans une étiquette de service MPLS et l’envoie via le protocole MPLS LSP vers le PE de sortie. Les nœuds de transport transmettent la pile d’étiquettes encapsulées à l’EP de sortie sur le domaine C SRv6.
Le protocole BGP Label Unicast (BGP-LU) indique l’accessibilité du transport pour les loopbacks PE IPv4 sur le réseau multidomaine. Les routeurs Next Hop Self on Border offrent l’indépendance de la technologie de tunnel intra-domaine dans différents domaines. Les services BGP L3 basés sur MPLS sont signalés par un PE de sortie IPv4 via des réflecteurs de route de service (RR) sans communauté étendue de couleur. Besoin PE entrant étiqueté accessibilité à l’adresse de bouclage IPv4 PE distante annoncée comme prochain saut avec les routes de service. BGP-LU annonce les loopbacks PE IPv4. L’auto-saut suivant est effectué sur les routeurs de bordure.
Le LSP BGP-LU est tunnelisé sur le domaine SRv6
-
L’étiquette BGP-LU existante se connecte de manière croisée sur les routeurs de bordure pour chaque adresse de bouclage IPv4 PE.
-
Les recherches au niveau du routeur de bordure d’entrée sont basées sur l’étiquette BGP-LU.
-
L’étiquette IGP SR-MPLS du saut suivant est remplacée par un tunnel IPv6 avec DA = SID SRv6 associé au comportement DTM dans le domaine central SRv6.
-
La bordure entrante routeur le transfert effectuent l’échange d’étiquettes et H.Encaps.M avec DA = SID SRv6 associé au comportement DTM.
Activer la signalisation SRv6 pour la famille d’adresses BGP-LU
Vous pouvez activer la signalisation SRv6 pour la famille d’adresses BGP-LU en :
-
Activation des
advertise-srv6-serviceaccept-srv6-serviceinstructions CLI pour la publicité des TLV du service SRv6 pour la famille d’adresses BGP-LU. -
Prise en charge du tunnel SRv6 pour l’acheminement de l’étiquette de l’attribut BGP prefix-SID pour signaler les SID SRv6 avec l’étiquette MPLS liée au préfixe dans NLRI. Tunnel SRv6 pour route d’étiquettes Le TLV est encodé exactement comme les TLV de service SRv6 dans l’attribut prefix-SID.
-
Publication du SID end-dtm dans la famille d’adresses BGP-LU sans aucune transposition dans les informations du SID SRv6 sous-TLV du tunnel SRv6 pour le TLV de route d’étiquette TLV dans l’attribut prefix-Sid.
Comportement des routes de sortie
Lorsque end-dtm SID est configuré, end-dtm SID route est ajouté à la table inet6.0 pointant vers mpls.0 table nexthop avec la décapsulation des points de terminaison et le comportement de recherche de table MPLS. Pour end-dtm-sid, une route sid stricte est également ajoutée.
Comportement de la route entrante
Le routeur de bordure d’entrée exécute l’envoi d’étiquettes et H.Encaps.M.red avec l’adresse de destination de l’en-tête IPv6 en tant que SID SRv6 reçu dans le tunnel SRv6 pour le TLV de route d’étiquette de l’attribut prefix-Sid.
Comportement des itinéraires de transit
La routeur de bordure de transit effectue l’échange d’étiquettes et H.Encaps.M.red avec l’adresse de destination de l’en-tête IPv6 en tant que SID SRv6 reçu dans SRv6 tunnel pour l’TLV de route d’étiquette de l’attribut prefix-Sid.
Configurer end-dtm-sid
Configurez end-dtm-sid statique ou dynamique. Le localisateur peut être un localisateur d’algo flexible.
user@host# set protocols bgp source-packet-routing srv6 locator locator-name end-dtm-sid [sid-value | non-default]
end-dtm-sid est le point de terminaison avec la décapsulation et le comportement de recherche de table MPLS.
Les sid qui ne sont pas par défaut peuvent être appliqués aux préfixes BGP-LU uniquement par le biais d’une stratégie.
Configurer advertise-srv6-service pour la famille d’adresses BGP-LU
Si l’instruction advertise-srv6-service CLI est configurée, seul le tunnel SRv6 pour le routage d’étiquettes TLV est annoncé dans l’attribut SID du préfixe BGP. La advertise-srv6-service déclaration s’applique à l’origine. L’instruction ne s’applique pas à la propagation.
user@host# set protocols bgp group internal-peers family inet labeled-unicast advertise-srv6-service OR user@host# set protocols bgp family inet labeled-unicast advertise-srv6-service user@host# set protocols bgp group internal-peers family inet6 labeled-unicast advertise-srv6-service OR user@host# set protocols bgp family inet6 labeled-unicast advertise-srv6-service
Configurer accept-srv6-service pour la famille d’adresses BGP-LU
Si l’instruction CLI est configurée, seul le tunnel SRv6 pour le routage d’étiquettes TLV présent dans l’attribut accept-srv6-service SID du préfixe BGP est accepté.
user@host# set protocols bgp group internal-peers family inet labeled-unicast accept-srv6-service OR user@host# set protocols bgp family inet labeled-unicast accept-srv6-service user@host# set protocols bgp group internal-peers family inet6 labeled-unicast accept-srv6-service OR user@host# set protocols bgp family inet6 labeled-unicast accept-srv6-service
Configurer end-dtm-sid avec la stratégie
L’instruction SRv6 CLI est améliorée pour configurer le type de SID SRv6 : end-dtm-sid.
user@host# set policy-options policy-statement policy-name term term-name then srv6 end-dtm-sid
Comportement LSP du Segment Routing spécifique à la plate-forme
Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de la plate-forme et de la version pour des fonctionnalités spécifiques.
Utilisez le tableau suivant pour passer en revue les comportements spécifiques à votre plateforme :
Comportement LSP du Segment Routing spécifique à la plate-forme
| Plate-forme | Différence |
|---|---|
| ACX Series |
|
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’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.