Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Exemple : activez le délai de liaison IS-IS avec le routage de paquets source dans le réseau (SPRING) dans un réseau privé virtuel de couche 3 (VPN)

Cet exemple montre comment configurer un délai de liaison IS-IS avec SPRING dans un scénario VPN de couche 3. Dans l’exemple, vous pouvez créer deux VPN entre PE1 et PE2. VPN1 optimise le délai de liaison et VPN2 optimise la métrique IGP. Bien que vous puissiez configurer la fonctionnalité pour activer le trafic bidirectionnel dans la topologie de test, nous nous concentrons sur un scénario de trafic unidirectionnel dans cet exemple. Plus précisément, votre tâche consiste à contrôler le chemin de transfert du trafic VPN de couche 3 envoyé par PE1 vers les destinations annoncées par PE2.

Exigences

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

  • Quatre routeurs MX Series

  • Junos OS Version 21.1R1 ou ultérieure s’exécutant sur tous les équipements

Topologie

Figure 1 : Topologie IS-IS Link Delay Topology de retard de liaison IS-IS

Dans la topologie, la plupart des liaisons ont une métrique IGP (par défaut) de 10, des mesures de retard dynamique et une coloration bleue. Les exceptions sont le chemin de couleur rouge entre PE1 et P1 et la configuration de retard statique sur la liaison P2 vers PE2.

Nous avons configuré la topologie de test pour prendre en charge le délai de liaison IS-IS pour IPv4 et IPv6. Nous avons configuré le routeur P2 comme réflecteur de route avec les équipements PE comme clients. Pour une topologie simple, nous utilisons des routes statiques dans les VRF du routeur PE2. Cela élimine le besoin d’équipements CE et d’un protocole de routage PE-CE comme EBGP.

Votre objectif est de configurer le réseau afin que les routes annoncées par PE2 pour VPN1 empruntent un chemin qui optimise les retards tout en se contentant d’utiliser uniquement des liaisons bleues. En revanche, le trafic envoyé aux routes associées au VPN2 peut prendre un lien bleu ou rouge avec une optimisation des chemins basée sur sa métrique IGP.

  • La définition de l’algorithme Flex (FAD) pour VPN1 utilise l’algorithme 128. Nous l’avons configuré pour utiliser uniquement des liaisons de couleur bleue (PE1>P2>P1>PE2) sur un chemin optimisé pour réduire les délais. Pour vous aider à bien sélectionner les chemins, vous configurez un délai statique de 2 000 microsecondes entre P2 et PE2. Ce délai est nettement plus élevé que le délai dynamique mesuré sur les liaisons restantes. Par conséquent, vous vous attendez à ce que l’algorithme flex 128 évite la liaison P2 vers PE2, préférant des sauts supplémentaires le long du chemin de couleur bleue (PE1>P2>P1>PE2).
  • La définition de l’algorithme Flex (FAD) pour VPN2 utilise l’algorithme 129. Nous l’avons configuré pour prendre des liens bleus ou rouges (PE1>P1>PE2 ou PE1>P2>PE2), le chemin étant optimisé sur la métrique IGP. En conséquence, le trafic utilisant l’algorithme flex 129 a deux chemins à coût égal entre PE1 et PE2, les deux encourant deux sauts et une métrique de 20.

Aperçu

Dans les réseaux IP, la majeure partie du trafic passe souvent par le réseau central, ce qui réduit les coûts, mais peut entraîner une latence accrue. Cependant, le trafic professionnel bénéficie souvent de la possibilité de choisir les chemins en fonction d’autres mesures de performance, telles que la latence des chemins, plutôt que de se relayer sur l’optimisation traditionnelle des chemins basée simplement sur des mesures IGP. L’optimisation d’un chemin pour réduire la latence peut être très bénéfique pour les applications telles que la voix et la vidéo en temps réel. Il peut également permettre un accès hautes performances aux données des marchés financiers où les millisecondes peuvent se traduire par des gains ou des pertes importants.

À partir de la version 21.1R1 de Junos OS, vous pouvez activer le délai de liaison IS-IS dans les réseaux IP. Vous pouvez obtenir des chemins métriques IGP minimum en configurant IS-IS avec le coût de liaison approprié à l’aide de l’algorithme IS-IS par défaut (0). Cela optimise les chemins vers le point de terminaison qui sont strictement basés sur la somme des métriques de liaison. En utilisant l’algorithme IS-IS Delay Flex, vous pouvez optimiser les chemins en fonction de leur retard de bout en bout.

Les retards de liaison peuvent être mesurés dynamiquement à l’aide de sondes de mesure active à deux voies (TWAMP). Les routeurs inondent ensuite leurs paramètres de retard de liaison. Les routeurs de la zone stockent ces paramètres dans la base de données d’état des liaisons (LSDB). Les nœuds entrants exécutent un algorithme SPF par rapport à la LSDB pour calculer des chemins optimisés sur divers attributs, tels que les couleurs de liaison, la métrique IGP, la métrique de l’ingénierie du trafic (TE) ou, comme illustré dans cet exemple, le délai de liaison.

Le routeur sortant signale l’algorithme flex souhaité en attachant une communauté de couleurs associée aux routes annoncées via BGP. À l’extrémité d’envoi (le PE local qui a reçu les routes balisées annoncées par le PE distant), ces communautés de couleurs sont utilisées pour indexer dans une table de couleurs qui résout le saut suivant du protocole distant (l’adresse de bouclage de PE) à un identifiant d’algorithme flex. Dans le contexte des VPN de couche 3, une stratégie de mappage des couleurs est utilisée au niveau du nœud d’entrée pour sélectionner les préfixes à résoudre via la table de couleurs.

Le PE local utilise ensuite sa définition de l’algorithme Flex local (FAD) pour mapper l’identifiant de l’algorithme flex en un ensemble de critères de sélection de chemins, par exemple « utiliser des liaisons bleues et optimiser en cas de retard ». Le PE entrant calcule le chemin optimal en fonction des valeurs de la LSDB, pousse la pile de labels MPLS associée sur le paquet et l’envoie au saut suivant associé. Il en résulte que les chemins MPLS conçus pour le trafic utilisent IS-IS comme protocole de signalisation.

Configuration

Configuration rapide cli

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

Note:

En fonction du type de MPC de vos routeurs MX Series, vous devrez peut-être activer explicitement des services IP améliorés pour prendre en charge la fonctionnalité de retard IS-IS. Lorsque vous validez l’instruction set chassis network-services enhanced-ip de configuration, vous êtes invité à redémarrer le système.

PE1

P1

P2

PE2

Procédure étape par étape

  1. Configurez les paramètres de base de l’équipement tels que le nom d’hôte, IPv4, les adresses IPv6, les adresses d’interface de bouclage, enhanced-ip le mode et activez les familles de protocoles ISO et MPLS sur toutes les interfaces des 4 routeurs.

  2. Configurez l’ID de routeur, le numéro du système autonome (AS) et appliquez une stratégie d’exportation d’équilibrage de charge à la table de transfert de tous les routeurs pour permettre l’équilibrage de charge du trafic.

  3. Sur PE1 et PE2, configurez le multichemin à coût égal (ECMP) pour une protection rapide contre le reroutage. Configurez également le saut suivant composite chaîné pour permettre aux routeurs de rediriger les routes qui partagent la même destination vers un saut suivant commun. Cette option améliore l’évolutivité de la base d’informations de transfert (FIB).

  4. Activez le traitement du protocole MPLS sur toutes les interfaces de tous les routeurs. Activez également l’ingénierie du trafic.

  5. Activez les sondes TWAMP sur tous les routeurs. Ces sondes permettent de mesurer dynamiquement le délai de liaison entre chaque paire de routeurs.

  6. Configurez le protocole IS-IS pour un fonctionnement point à point (les mesures deretardsnaire twAMP ne sont pas prises en charge sur les liaisons multi-points) et activez le mode de protection des nœuds pour les opérations TILFA (Topology-Independent Loop-Free Alternate) sur toutes les interfaces. Vous activez également le mode passif IS-IS sur l’interface de bouclage et désactivez is-IS de niveau 1 pour utiliser uniquement IS-IS de niveau 2. Activez l’ingénierie du trafic avec la topologie unicast de couche 3 pour télécharger la topologie IGP dans le TED. Configurez IS-IS pour prendre en charge les chemins routés SPRING. La prefix-sid stratégie d’exportation est définie à une étape ultérieure. Cette stratégie permet au nœud local d’annoncer son adresse de bouclage avec un mappage à un ou plusieurs algorithmes flex.

  7. Configurez la mesure dynamique des retards de liaison IS-IS à l’aide de sondes TWAMP sur toutes les interfaces IS-IS de tous les routeurs (à l’exception de la liaison P2 et PE2, qui utilise une valeur de retard statique dans cet exemple).

  8. Configurez la métrique statique de retard sur la liaison entre P2 et PE2.

  9. Configurez PE1 et PE2 pour prendre en charge deux VPN de couche 3 (VPN1 et VPN2).

    Note:

    Notez que les instances de routage de PE2 sont configurées avec des routes statiques IPv4 et IPv6. Ces routes sont configurées avec la possibilité de tester la receive connectivité à l’aide de ping. La fonctionnalité de retard IS-IS fonctionne de la même manière si le VPN de couche 3 utilise un protocole de routage dynamique entre le PE et un équipement CE connecté. Dans cet exemple, nous utilisons des routes statiques pour assurer la simplicité de la topologie et permettre de se concentrer sur la fonctionnalité d’optimisation des retards IS-IS.

  10. Configurez une stratégie de carte sur PE1 pour permettre la résolution de route VPN pour les préfixes correspondants à la table de couleurs BGP. Cela vous permet d’évoquer les algorithmes flex de transfert de chemin sur une base par préfixe. La map1 stratégie de résolution est définie sur le mode de ip-color résolution.

    Note:

    Dans un contexte VPN de couche 3, une stratégie de mappage est nécessaire pour sélectionner les préfixes autorisés à résoudre leur saut suivant dans la table de couleurs. Le simple fait d’avoir des routes avec des sauts et des communautés de couleurs étendues n’entraîne pas l’utilisation de la table de couleurs, sauf si une stratégie de mappage est utilisée.

  11. Configurez les stratégies d’exportation de routage VPN au niveau de PE2 pour connecter les communautés de couleurs souhaitées aux routes VPN qu’elle annonce sur PE1 (via le réflecteur de route). Il est important de savoir comment les routes de VPN1 ont la communauté de couleurs pour le chemin flex 128 (délai d’optimisation), tandis que les routes annoncées à partir de VPN2 ont la communauté de couleur 129 (métrique IGP optimisée).

  12. Configurez l’appairage BGP entre les équipements PE et le réflecteur de route. Configurez les informations d’accessibilité de la couche réseau unicast (NLRI) pour prendre en charge les sauts suivants couleur étendus sur les équipements PE. L’activation de cette option permet aux routes avec des communautés de couleurs d’avoir leur saut suivant résolu dans la table de couleurs. Sans la route étendue de réglage du saut suivant avec des communautés de couleurs qui subissent une résolution normale du saut suivant et n’utiliseront pas de chemins d’algorithme flex.

  13. Vous activez également la prise en charge des routes unicast VPN de couche 3 IPv4 et IPv6. Sur PE1, vous appliquez les stratégies de mappage de couleurs en tant qu’importation, afin qu’il puisse agir sur les routes reçues de l’équipement PE distant.

    Sur PE 2, vous appliquez une politique d’exportation pour joindre la communauté de couleurs souhaitée aux publicités de routage VPN envoyées à PE1. L’option vpn-apply-export est nécessaire au PE2 pour permettre aux stratégies d’exportation d’agir sur les routes VPN annoncées vers des PE distants.

  14. Définissez la politique d’équilibrage de charge par paquet sur tous les routeurs.

  15. Configurez la prise en charge du routage de segments avec deux algorithmes flex (128 et 129) sur tous les routeurs.

  16. Configurez tous les routeurs pour qu’ils annoncent leur adresse de bouclage avec la prise en charge des algorithmes flex 128 et 129. Cette prefix-segment index option définit le label de base de l’adresse de bouclage de chaque routeur. Dans cet exemple, l’index de base IPv4 et l’index de base IPv6 sont définis pour refléter le numéro de routeur. En conséquence, R0 (PE1) utilise 1000 pour IPv4 tandis que R1 (P1) utilise 1001.

  17. Sur tous les routeurs, définissez les RED groupes d’administration BLUE et MPLS et attribuez la couleur souhaitée à chaque interface. Vous activez également la tunnelisation ICMP pour permettre la prise en charge du routage trace dans le contexte des VPN de couche 3 basés sur MPLS.

  18. Configurez les DFA au niveau de l’équipement PE entrant (PE1) sous la routing-options hiérarchie. Dans ce cas, vous assignez l’algorithme flex 128 pour optimiser le chemin en fonction du delay-metric et 129 à l’optimisation sur le igp-metric. Dans cet exemple, l’algorithme flex 128 doit prendre uniquement des chemins de couleur bleue, tandis que l’algorithme flex 129 peut prendre un chemin de couleur bleu ou rouge. Dans cet exemple, vous définissez les DFA au niveau de PE1 uniquement, car nous nous concentrons uniquement sur la voie de transfert de PE1 à PE2.

    Pour prendre en charge le transfert de chemin flex bidirectionnel, vous devrez définir les DFA souhaités sur l’équipement PE2. Les routeurs P n’ont pas besoin d’une définition DE FAD, car le FAD n’est utilisé que par le nœud d’entrée lors du calcul d’un chemin vers le nœud de sortie.

  19. Entrez commit dans le mode de configuration.

Résultats

Vérifiez les résultats de la configuration :

user@PE1# show interfaces

user@PE1# show policy-options

user@PE1# show protocols

user@PE1# show routing-options

user@PE1# show routing-instances

user@PE1# show services rpm

Vérification

Vérifier les adjacenités IS-IS

But

Vérifiez les adjacenances IS-IS attendues sur les équipements de routage.

Action

Depuis le mode opérationnel, saisissez la show isis adjacency commande.

Sens

Cette sortie indique que PE1 a formé avec succès des adjacencies IS-IS sur ses ge-0/0/0.0 interfaces, ge-0/0/1.0 qui se connectent à leurs routeurs P1 et P2, respectivement.

Vérifier la base de données IS-IS

But

Vérifiez que les paramètres de retard de liaison sont présents dans la base de données IS-IS.

Action

Utilisez la show isis database extensive | match delay commande opérationnelle.

Sens

La sortie affiche le délai dynamique associé aux différentes interfaces de la topologie. La partie en surbrillance de la sortie spécifie le délai statique de 2 000 microsecondes configuré sur la liaison P2 vers PE2. La valeur de retard configurée statiquement est nettement supérieure à n’importe quelle mesure de retard dynamique. Ce retard important est configuré pour permettre de prédire facilement le chemin bleu optimisé pour les retards à travers le réseau.

Vérifier l’appairage BGP

But

Vérifiez que les deux PE ont bien établi des sessions d’appairage IPv4 et IPv6 sur le réflecteur de route.

Action

Utilisez la show bgp summary commande opérationnelle. Dans ce cas, nous exécutons la commande sur P2, le réflecteur de route, car il fournit un emplacement pratique pour confirmer les deux sessions d’appairage des deux PE à l’aide d’une seule commande.

Sens

La sortie confirme que toutes les sessions d’appairage BGP sont correctement établies. L’affichage confirme également que les routes VPN de couche 3 sont annoncées/apprises lors de ces sessions d’appairage.

Vérifier la communauté de couleurs sur les routes VPN

But

Vérifiez que les routes VPN annoncées par PE2 sont correctement étiquetées avec une communauté de couleurs.

Action

Utilisez la show route detail <prefix> table <table-name> commande opérationnelle de PE1 pour afficher les détails d’un routage VPN de couche 3 appris par PE2.

Sens

La sortie confirme qu’un préfixe VPN dans l’instance de routage VPN1 est associé à une communauté color:0:128 de couleurs. En outre, vous pouvez confirmer que le saut suivant du protocole pour ce routage est l’adresse de bouclage du routeur PE2 avec un saut suivant étendu qui indexe une entrée correspondante dans la table de couleurs.

Bien qu’elle ne soit pas montrée, vous pouvez répéter cette commande pour un préfixe dans la table VPN2. Vous vous attendez à trouver ces routes en color:0:129 annexe.

Vérifier la table de routage inetcolor.0

But

Vérifiez que la inetcolor.0 table de routage est correctement remplie avec tous les ADRESSES de routeur (bouclage) indiquant la prise en charge des algorithmes flex 128 et 129.

Note:

Les routes IPv6 sont prises en charge via la inet6color.0 table. Vous pouvez vérifier ce tableau à l’aide de la même approche que celle indiquée dans cette section pour la table de couleurs IPv4.

Action

Utilisez la show route table inetcolor.0 commande opérationnelle.

Sens

La sortie affiche les routes dans la table de inetcolor.0 routage. La partie en surbrillance indique que les deux routes proviennent de PE2. Le 192.168.255.3-128<c> chemin n’a qu’un seul chemin possible et prend l’interface ge-0/0/1.0 vers P2 comme saut suivant. Rappelons que l’algorithme 128 flex doit utiliser des liaisons bleues ge-0/0/1 , et du point de vue du PE1, qui ne laisse que l’interface de couleur bleue comme chemin viable.

En revanche, le routage est 192.168.255.3-129<c> capable d’équilibrer la charge sur les ge-0/0/0.0 interfaces P1 et ge-0/0/1.0 P2. Rappelez-vous que ce chemin pour l’algorithme flex peut prendre n’importe quel chemin bleu ou rouge, et peut donc utiliser l’une de ses interfaces lors du transfert vers sa destination associée.

Vérifier le fonctionnement de TWAMP

But

Vérifiez que les sondes TWAMP fonctionnent entre les routeurs avec un délai de liaison dynamique configuré.

Action

Utilisez la commande du show services rpm twamp client mode opérationnel.

Sens

La partie en surbrillance de la sortie indique que PE1 a deux voisins TWAMP : P2 (10.0.1.2) et P1 (10.0.1.1).

Si vous le souhaitez, utilisez la show services rpm twamp client probe-results commande du mode opérationnel pour voir les valeurs de mesure des retards actuels et historiques.

Vérifier la résolution des routes

But

Vérifiez que les routes pour les VPN1 et VPN2 sont résolus sur les chemins attendus de l’algorithme flex.

Action

Utilisez la commande du show route mode opérationnel.

Sens

La sortie en surbrillance indique que sur l’équipement PE1, la route 172.16.1.0 pour VPN1 utilise FAD 128 en prenant uniquement le chemin de couleur bleue, ce qui rend P1 (10.0.2.2) son saut suivant tandis que le routage pour VPN2, 172.16.2.0 utilise FAD 129, ce qui signifie qu’il peut prendre le chemin de la couleur rouge soit via l’interface ge-0/0/0.0 vers P1>PE2, soit via l’interface ge-0/0/1.0 vers P2> PE2. Cela est également vrai pour les routes IPv6, comme illustré ici pour VPN1 :

Le routage IPv6 de VPN1 se résout au même chemin de transfert que son homologue IPv4, ce qui est logique car ils utilisent tous les deux l’algorithme flex 128 pour forcer l’utilisation de liaisons bleues avec une optimisation des retards. Rappelez-vous que vous avez configuré PE2, la source de ces routes, pour utiliser une base de labels de 1287 pour les routes IPv4 et 4287 pour les routes IPv6, et que le source-packet-routing srgb start-label vers 8000. En conséquence, le routage IPv4 de VPN1 a un label 81287 tandis que le routage IPv6 de VPN1 utilise 84287.

Vérifier les chemins de transfert

But

Vérifiez que les routes vpn1 et VPN2 sont transférés sur les chemins attendus de l’algorithme Flex.

Action

Utilisez les commandes et trace route le ping mode opérationnel pour vérifier l’accessibilité et confirmer le chemin de transfert IPv4 utilisé par PE1 lors de l’envoi de trafic vers des destinations VPN en tant que PE2.

Note:

L’utilisation de routes statiques avec un saut suivant de réception au pe2 vous permet de ping sur les routes distantes. Vous pouvez toutefois vous attendre à ce que le dernier saut de la route trace vers le délai d’expiration, car le traitement de routage de trace n’est pas pris en charge lorsque vous ciblez un routage de réception statique IPv4.

Sens

Le résultat indique que les chemins de transfert attendus sont utilisés. Par exemple, le tracé de la route 172.16.1.0/24 dans VPN1 montre que des chemins bleus sont utilisés et que la liaison à retard élevé entre P2 et PE2 est évitée. Cela confirme que l’algorithme flex préfère un chemin avec un saut supplémentaire s’il se traduit par une réduction de la latence du chemin de bout en bout. Dans ce cas, la liaison 10.0.12.0 entre P2 et P1 est utilisée, tandis que la liaison directe entre P2 et PE2 est évitée.

En revanche, le chemin emprunté pour la route 172.16.2.0/24, associé à VPN2 et à l’algorithme flex 129, est capable de prendre l’un ou l’autre des chemins directs entre PE1 et PE2. Dans ce cas, le chemin de transfert est de PE1 à P1, puis à la destination (PE2), où comme indiqué les derniers sauts. Ce délai sur le dernier saut ne se produit pas pour les routes qui pointent vers un équipement CE (par opposition aux routes de réception statiques utilisées dans cet exemple).

Bien qu’ils ne soient pas présentés ici pour la brièveté, vous attendez les mêmes chemins de transfert pour les routes de traçage vers les routes VPN IPv6, selon qu’elles sont mappées à l’algorithme flex 128 ou 129, ce qui signifie dans cet exemple associé à VPN1 et VPN2, respectivement.