SUR CETTE PAGE

Comprendre la mesure du retard de liaison et la publicité dans IS-IS
Exemple : Activation du délai de liaison IS-IS avec SPRING (Source Packet Routing in Networking) dans un réseau privé virtuel (VPN) de couche 3

Activation de la mesure du délai de liaison et de la publicité dans IS-IS

Comprendre la mesure du retard de liaison et la publicité dans IS-IS

Avantages de la mesure du retard de liaison et de la publicité dans IS-IS
Vue d’ensemble de la mesure du retard de liaison et de la publicité dans IS-IS

Avantages de la mesure du retard de liaison et de la publicité dans IS-IS

La mesure du retard de liaison et la publicité dans IS-IS offrent les avantages suivants :

Très avantageux dans certains réseaux tels que les fournisseurs de données boursières, où il est crucial d’avoir accès aux données du marché en temps réel pour effectuer des transactions plus rapidement que la concurrence. C’est là que les critères de performance du réseau, ou la latence, deviennent essentiels pour sélectionner les chemins de données.
Aide à prendre des décisions de sélection de chemin en fonction des données de performance (telles que la latence) d’une manière rentable et évolutive.
C’est une alternative supérieure à l’utilisation de mesures telles que le nombre de sauts ou le coût comme mesures de routage.

Vue d’ensemble de la mesure du retard de liaison et de la publicité dans IS-IS

Les performances du réseau sont mesurées à l’aide de TWAMP -Light. À partir de la version 21.1R1 de Junos OS, vous pouvez obtenir la mesure de diverses mesures de performance dans les réseaux IP, à l’aide de messages de sonde. IS-IS Traffic Engineering Extensions permet de diffuser les informations sur les performances du réseau de manière évolutive. Ces informations peuvent ensuite être utilisées pour sélectionner des chemins en fonction des performances du réseau.

Le BGP-LS (Border Gateway Protocol Link-State) permet au BGP de transporter les informations sur l’état des liens acquises auprès des IGP, ce qui permet ensuite aux fournisseurs d’accès à Internet (FAI) d’exposer ces informations de manière sélective à d’autres FAI, fournisseurs de services, CDN, etc., par le biais d’un appairage BGP normal. De nouvelles TLV d’état de liaison BGP (BGP-LS) sont définies pour porter les extensions de métriques IGP Traffic Engineering.

L’illustration suivante illustre la métrique IGP minimale et la métrique de délai minimum dans les réseaux centraux, métropolitains et d’accès.

Dans ce scénario, le réseau central est moins cher, mais son délai est plus long. Les raccourcis d’accès, avec la latence la plus faible, sont coûteux. Le réseau central étant moins coûteux, la majorité du trafic passe généralement de 1>2>3>4>5> à 6 en utilisant la métrique IGP minimale. Comme illustré dans le scénario a), vous pouvez atteindre l’exigence IGP minimale en exécutant IS-IS avec le coût approprié configuré et l’algorithme IS-IS par défaut défini sur zéro. Dans les entreprises où la latence ultra-faible est cruciale, le nombre de paquets doit passer de 1 à 6. Comme illustré dans le scénario b), vous pouvez obtenir une métrique de délai minimum en définissant un algorithme IS-IS flex avec une latence minimale, ce qui minimise le délai jusqu’au point de terminaison. Cet algorithme flexible se compose uniquement du nœud 1 et du nœud 6.

Exemple : Activation du délai de liaison IS-IS avec SPRING (Source Packet Routing in Networking) dans un réseau privé virtuel (VPN) de couche 3

Cet exemple montre comment configurer le 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
Aperçu
Configuration
Vérification

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écute sur tous les équipements

Topologie

Figure 1 : topologie IS-IS Link Delay Topology

du délai de liaison IS-IS

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

Nous avons configuré la topologie de test pour qu'elle prenne en charge le délai de liaison IS-IS pour IPv4 et IPv6. Nous avons configuré le routeur P2 en tant que réflecteur de route avec les appareils PE comme clients. Pour simplifier la topologie, nous utilisons des routes statiques dans les VRF du routeur PE2. Il n’est donc plus nécessaire d’utiliser des équipements CE et un protocole de routage PE-CE tel que EBGP.

Votre objectif est de configurer le réseau de manière à ce que les routes annoncées par PE2 pour VPN1 prennent un chemin qui optimise le délai tout en étant limitées à l’utilisation de liens bleus. En revanche, le trafic envoyé vers les routes associées à VPN2 peut prendre un lien bleu ou rouge avec une optimisation de chemin 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 liens de couleur bleue (PE1>P2>P1>PE2) sur un chemin optimisé pour réduire les délais. Pour illustrer la sélection correcte du chemin, vous configurez un délai statique de 20000 microsecondes entre P2 et PE2. Ce délai est significativement plus élevé que le retard dynamique mesuré sur les liaisons restantes. Par conséquent, vous vous attendez à ce que le trafic de l’algorithme flexible 128 évite la liaison P2 vers PE2, préférant plutôt 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), avec un chemin optimisé sur la métrique IGP. Par conséquent, le trafic utilisant l’algorithme flexible 129 a deux chemins de coût égal entre PE1 et PE2, les deux impliquant deux sauts et une métrique résultante de 20.

Aperçu

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

À partir de Junos OS version 21.1R1, vous pouvez activer le délai de liaison IS-IS dans les réseaux IP. Vous pouvez obtenir des chemins de métrique IGP minimums en configurant IS-IS avec le coût de liaison approprié à l’aide de l’algorithme IS-IS par défaut (0). Cela permet d’optimiser les chemins d’accès au point de terminaison, qui sont strictement basés sur la somme des métriques de liaison. L’algorithme IS-IS delay flex vous permet d’optimiser les chemins en fonction de leur délai de bout en bout.

Le délai de liaison peut être mesuré dynamiquement à l’aide de sondes de mesure actives bidirectionnelles (TWAMP). Les routeurs inondent alors leurs paramètres de délai de liaison. Les routeurs de la zone stockent ces paramètres dans la base de données LSDB (Link State Database) partagée. Les nœuds entrants exécutent un algorithme SPF sur la LSDB pour calculer des chemins optimisés en fonction de divers attributs, tels que les couleurs des liens, la métrique IGP, la métrique TE (Traffic-Engineering) ou, comme illustré dans cet exemple, le délai de liaison.

Le routeur de sortie signale l’algorithme de flexion souhaité en associant 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 s'indexer dans une table de couleurs qui résout le prochain saut du protocole distant (l'adresse de bouclage du PE) en un identifiant d'algorithme flexible. 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 dont les prochains sauts doivent être résolus via la table de couleurs.

Le PE local utilise ensuite sa définition d’algorithme Flex (FAD) locale pour mapper l’identifiant de l’algorithme flex dans un ensemble de critères de sélection de chemin, par exemple « utiliser les liens bleus et optimiser sur délai ». Le PE entrant calcule le chemin optimal en fonction des valeurs de la LSDB, pousse la pile d’étiquettes MPLS associée sur le paquet et l’envoie au saut suivant associé. Il en résulte des chemins MPLS d’ingénierie du trafic utilisant IS-IS comme protocole de signalisation.

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, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la hiérarchie [modifier].

Note:

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

PE1

PE2

Procédure étape par étape

Configurez les paramètres de base de l’équipement tels que le nom d’hôte, les adresses IPv4, 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.

Configurez l’ID du routeur, le numéro du système autonome (AS) et appliquez une stratégie d’exportation d’équilibrage de charge à la table de transfert sur tous les routeurs pour activer l’équilibrage de charge du trafic.
Sur PE1 et PE2, configurez le routage ECMP (Equal-cost Multi-Path) pour activer la protection contre le reroutage rapide. Configurez également le saut suivant composite chaîné pour permettre aux routeurs de pointer les routes qui partagent la même destination vers un saut suivant de transfert commun. Cette option améliore la mise à l’échelle de la base d’informations de transfert (FIB).
Activez le traitement du protocole MPLS sur toutes les interfaces de tous les routeurs. Activez également l’ingénierie de trafic.
Activez les sondes TWAMP sur tous les routeurs. Ces sondes prennent en charge la mesure dynamique du délai de liaison entre chaque paire de routeurs.
Configurez le protocole IS-IS pour un fonctionnement point à point (les mesures de retard basées sur TWAMP ne sont pas prises en charge sur les liaisons multipoints) et activez le mode de protection des nœuds pour le fonctionnement TILFA (Topology-Independent Loop-Free Alternate) sur toutes les interfaces. Vous pouvez également activer le mode passif IS-IS sur l’interface de bouclage et désactiver IS-IS niveau 1 pour utiliser uniquement IS-IS niveau 2. Activez l’ingénierie de 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 dans 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 flexibles.

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

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

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

Note:

Notez que les instances de routage à PE2 sont configurées avec des routes statiques IPv4 et IPv6. Ces itinéraires sont configurés avec la possibilité de vous permettre de tester la connectivité à l’aide de receive ping. La fonction 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 périphérique CE connecté. Dans cet exemple, nous utilisons des routes statiques pour garder la topologie simple afin de permettre de se concentrer sur la fonctionnalité d’optimisation du délai IS-IS.

Configurez une stratégie de mappage au niveau PE1 afin d’activer la résolution de route VPN pour les préfixes correspondants à la table de couleurs BGP. Cela vous permet d’évoquer des algorithmes de transfert de chemin flexible pour chaque 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 prochain saut dans la table de couleurs. Le simple fait d’avoir des routes avec des sauts suivants étendus et des communautés de couleurs attachées n’entraîne pas l’utilisation de la table de couleurs, sauf si une stratégie de mappage est utilisée.

Configurez les stratégies d’exportation de route VPN à PE2 pour attacher les communautés de couleurs souhaitées aux routes VPN qu’il annonce à PE1 (via le réflecteur de route). Il est important de noter ici la façon dont les routes de VPN1 ont la communauté de couleurs pour le chemin flexible 128 (délai d’optimisation) attachée, tandis que les routes annoncées à partir de VPN2 ont la communauté de couleurs 129 attachée (métrique IGP d’optimisation).

Configurez l’appairage BGP entre les périphériques PE et le réflecteur de route. Configurez les informations d’accessibilité de la couche réseau (NLRI) unicast pour prendre en charge les sauts suivants de couleur étendus sur les périphériques PE. L’activation de cette option permet aux routes avec des communautés de couleurs de voir leur prochain saut se résoudre via la table de couleurs. Sans l’itinéraire étendu de réglage du saut suivant avec des communautés de couleurs subissant une résolution normale du saut suivant et n’utilisera pas de chemins d’algorithme flexible.

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 des 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 stratégie d’exportation pour attacher la communauté de couleurs souhaitée aux annonces de route VPN envoyées à PE1. L’option vpn-apply-export est nécessaire au niveau de PE2 pour permettre aux stratégies d’exportation d’agir sur les routes VPN annoncées aux PE distants.

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

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

Configurez tous les routeurs pour qu’ils annoncent leur adresse de bouclage en prenant en charge les algorithmes 128 et 129 flex. L prefix-segment index 'option définit l'étiquette 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. Par conséquent, R0 (PE1) utilise 1000 pour IPv4, tandis que R1 (P1) utilise 1001.

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

Configurez les DCP au niveau de l’équipement PE d’entrée (PE1) sous la routing-options hiérarchie. Dans ce cas, vous affectez l’algorithme flex 128 pour optimiser le chemin en fonction de la delay-metric et 129 pour optimiser la 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 DCP à PE1 uniquement, car nous nous concentrons uniquement sur le chemin de transfert de PE1 à PE2.

Pour prendre en charge le transfert de chemin flexible bidirectionnel, vous devez définir les DCP souhaités sur l’appareil PE2. Les routeurs P n'ont pas besoin d'une définition FAD, car celle-ci est uniquement utilisée par le nœud entrant lors du calcul d'un chemin vers le nœud de sortie.
Entrez commit à à partir du 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 proximités IS-IS
Vérifier la base de données IS-IS
Vérifier l’appairage BGP
Vérifier la communauté de couleurs sur les routes VPN
Vérifier la table de routage inetcolor.0
Vérifier le fonctionnement de TWAMP
Vérifier la résolution de l’itinéraire
Vérifier les chemins de transfert

Vérifier les proximités IS-IS

But
Action
Signification

Bien que cela ne s’affiche pas, vous pouvez répéter cette commande pour un préfixe dans la table VPN2. Vous vous attendez à trouver ces itinéraires ont le color:0:129 ci-joint.

Vérifier la table de routage inetcolor.0

But
Action
Signification

But

Vérifiez que la inetcolor.0 table de routage est correctement renseignée avec tous les ID de routeur (adresses loopback) montrant la prise en charge des algorithmes 128 et 129 flex.

Note:

Les routes IPv6 sont prises en charge via le inet6color.0 tableau. Vous pouvez vérifier ce tableau en utilisant 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.

Signification

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

En revanche, la route pour 192.168.255.3-129<c> est capable d’équilibrer la charge à la fois sur les ge-0/0/0.0 interfaces vers P1 et vers 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 ou l’autre de ses interfaces lors du transfert vers sa destination associée.

Vérifier le fonctionnement de TWAMP

But
Action
Signification

But

Vérifiez que les sondes TWAMP fonctionnent entre les routeurs sur lesquels le délai de liaison dynamique est configuré.

Action

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

Signification

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 commande du show services rpm twamp client probe-results mode opérationnel pour voir les valeurs de mesure de retard actuelles et historiques.

Vérifier la résolution de l’itinéraire

But
Action
Signification

But

Vérifiez que les routes VPN1 et VPN2 se résolvent sur les chemins d’accès attendus par l’algorithme flexible.

Action

Utilisez la commande du show route mode opérationnel.

Signification

La sortie en surbrillance indique que sur le périphérique PE1, la route 172.16.1.0 pour VPN1 utilise FAD 128 en prenant uniquement le chemin de couleur bleue, ce qui fait de P1 (10.0.2.2) son prochain saut tandis que la route pour VPN2, 172.16.2.0 utilise FAD 129, ce qui signifie qu’elle peut prendre le chemin de 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. C’est également vrai pour les routes IPv6, comme illustré ici pour VPN1 :

La route IPv6 de VPN1 se résout sur le même chemin de transfert que son homologue IPv4, ce qui est logique car ils utilisent tous deux l’algorithme flexible 128 pour forcer l’utilisation de liens bleus avec optimisation de délai. Rappelez-vous que vous avez configuré PE2, la source de ces routes, pour utiliser une base d’étiquettes de 1287 pour les routes IPv4 et 4287 pour les routes IPv6, et que le source-packet-routing srgb start-label à 8000. Par conséquent, la route IPv4 de VPN1 porte l’étiquette 81287, tandis que la route IPv6 de VPN1 utilise 84287.

Vérifier les chemins de transfert

But
Action
Signification

But

Vérifiez que les routes de VPN1 et VPN2 sont transférées via les chemins d’accès attendus de l’algorithme flexible.

Action

Utilisez les ping commandes et trace route 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 à PE2 vous permet d’envoyer un ping aux routes distantes. Toutefois, vous pouvez vous attendre à ce que le dernier saut de la route de trace expire, car le traitement de la route de trace n’est pas pris en charge lors du ciblage d’une route de réception statique IPv4.

Signification

La sortie indique que les chemins de transfert attendus sont utilisés. Par exemple, la trace route pour la route 172.16.1.0/24 dans VPN1 montre que les chemins bleus sont utilisés et que la liaison à fort délai 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 en résulte une réduction de la latence du chemin de bout en bout. Dans ce cas, le lien 10.0.12.0 entre P2 et P1 est utilisé alors que le lien direct entre P2 et PE2 est évité.

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

Bien que cela ne soit pas affiché ici par souci de concision, vous vous attendez à ce que les chemins de transfert soient identiques pour les chemins de suivi vers les routes VPN IPv6 selon qu’ils sont mappés à l’algorithme flexible 128 ou 129, ce qui, dans cet exemple, signifie associé à VPN1 et VPN2, respectivement.