Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Sur cette page
 

RSVP Configuration

Configuration RSVP minimale

Pour activer RSVP sur une interface unique, ajoutez l’instruction rsvp et spécifiez l’interface à l’aide de l’instruction interface . Il s’agit de la configuration RSVP minimale. Toutes les autres instructions de configuration RSVP sont facultatives.

Vous pouvez inclure ces instructions aux niveaux hiérarchiques suivants :

  • [edit protocols]

  • [edit logical-systems logical-system-name protocols]

Pour activer RSVP sur toutes les interfaces, remplacez all la interface-name variable.

Si vous avez configuré des propriétés d’interface sur un groupe d’interfaces et que vous souhaitez désactiver RSVP sur l’une des interfaces, incluez l’instruction disable :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit protocols rsvp interface interface-name ]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name ]

Configuration de RSVP et MPLS

L’objectif principal du logiciel Junos RSVP est de prendre en charge la signalisation dynamique au sein des chemins de commutation d’étiquettes (LSP). Lorsque vous activez MPLS et RSVP sur un routeur, MPLS devient un client de RSVP. Aucune configuration supplémentaire n’est requise pour lier MPLS et RSVP.

Vous pouvez configurer MPLS pour configurer des chemins signalés à l’aide de l’instruction label-switched-path au niveau de la [edit protocols mpls] hiérarchie. Chaque LSP se traduit par une demande de RSVP pour lancer une session RSVP. Cette requête est transmise via l’interface interne entre la commutation d’étiquettes et RSVP. Après avoir examiné les informations de demande, vérifié les états RSVP et vérifié les tables de routage locales, le RSVP lance une session pour chaque LSP. La session provient du routeur local et est destinée à la cible du LSP.

Lorsqu’une session RSVP est créée avec succès, le LSP est configuré le long des chemins créés par la session RSVP. Si la session RSVP a échoué, RSVP notifie MPLS de son statut. Il appartient à MPLS d’initier des chemins de sauvegarde ou de continuer à réessayer le chemin initial.

Pour transmettre des informations sur la signalisation de commutation d’étiquettes, RSVP prend en charge quatre objets supplémentaires : Objet de requête d’étiquette, objet d’étiquette, objet De route explicite et Objet de route d’enregistrement. Pour qu’un LSP soit correctement configuré, tous les routeurs le long du chemin doivent prendre en charge MPLS, RSVP et les quatre objets. Sur les quatre objets, l’objet Route d’enregistrement n’est pas obligatoire.

Pour configurer MPLS et en faire un client de RSVP, effectuez les opérations suivantes :

  • Activez MPLS sur tous les routeurs qui prendront part à la commutation d’étiquettes (c’est-à-dire sur tous les routeurs qui pourraient faire partie d’un chemin de commutation d’étiquettes).

  • Activez le protocole RSVP sur tous les routeurs et sur toutes les interfaces de routeur qui forment le LSP.

  • Configurez les routeurs au début du LSP.

Vous pouvez configurer des chemins de commutation d’étiquettes (LSP) RSVP afin d’utiliser une mesure de retard pour le calcul du chemin. Pour configurer, utilisez les options CLI que nous avons introduites sous la [edit protocols mpls label-switched-path name] hiérarchie.

Exemple : Configuration de RSVP et MPLS

Voici un exemple de configuration d’un routeur au début d’un LSP :

Voici un exemple de configuration pour tous les autres routeurs du LSP :

Configuration des interfaces RSVP

Les sections suivantes décrivent comment configurer les interfaces RSVP :

Configuration de la réduction de la modernisation RSVP

Vous pouvez configurer la réduction de la actualisation RSVP sur chaque interface en incluant les instructions suivantes dans la configuration de l’interface :

  • aggregate et reliable— Activez toutes les fonctionnalités de réduction de la modernisation RSVP : Regroupement de messages RSVP, ID de message RSVP, diffusion fiable de messages et actualisation sommaire.

    Afin d’obtenir une réduction de l’actualisation et une livraison fiable, vous devez inclure les instructions et reliable les aggregate instructions.

  • no-aggregate: désactive la regroupement des messages RSVP et l’actualisation sommaire.

  • no-reliable— Désactivez l’ID de message RSVP, la diffusion fiable des messages et l’actualisation sommaire.

Pour plus d’informations sur la réduction de la modernisation RSVP, voir Réduction de la modernisation RSVP.

Si l’instruction no-reliable est configurée sur le routeur (la diffusion fiable des messages est désactivée), le routeur accepte les messages RSVP qui incluent l’objet ID de message, mais ignore l’objet ID du message et poursuit le traitement standard des messages. Aucune erreur n’est générée dans ce cas, et RSVP fonctionne normalement.

Cependant, toutes les combinaisons entre deux voisins avec différentes capacités de réduction de l’actualisation ne fonctionnent pas correctement. Par exemple, un routeur est configuré avec l’instruction aggregate ou no-reliable les reliableno-aggregate instructions. Si un voisin RSVP envoie un objet Summary Refresh à ce routeur, aucune erreur n’est générée, mais l’objet Summary Refresh ne peut pas être traité. Par conséquent, les états RSVP peuvent utiliser ce routeur si le voisin ne s’appuie que sur l’actualisation des résumés pour actualiser les états RSVP.

À moins qu’il n’y ait des exigences spécifiques, nous vous recommandons de configurer la réduction de l’actualisation RSVP de la même manière sur chaque voisin RSVP.

Pour activer toutes les fonctionnalités de réduction de l’actualisation RSVP sur une interface, incluez l’instruction aggregate :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

Pour désactiver la regroupement des messages RSVP et l’actualisation sommaire, incluez l’instruction no-aggregate :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

Pour activer l’ID de message RSVP et une diffusion fiable des messages sur une interface, incluez l’instruction reliable :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

Pour désactiver l’ID de message RSVP, la diffusion fiable des messages et l’actualisation sommaire, incluez l’instruction no-reliable :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

Définition de la capacité de réduction de l’actualisation des voisins RSVP

Pour déterminer la capacité de réduction de l’actualisation RSVP d’un voisin RSVP, vous avez besoin des informations suivantes :

  • Le bit RR annoncé par le voisin

  • La configuration locale de la réduction de la modernisation RSVP

  • Les vrais messages RSVP reçus du voisin

Pour obtenir ces informations, vous pouvez émettre une show rsvp neighbor detail commande. Exemple de sortie :

Pour plus d’informations sur la show rsvp neighbor detail commande.

Configuration du RSVP Hello Interval

RSVP surveille l’état des voisins IGP (Interior Gateway Protocol) (IS-IS ou OSPF) et s’appuie sur les protocoles IGP pour détecter les défaillances d’un nœud. Si un protocole IGP déclare un voisin en panne (car les paquets hello ne sont plus reçus), le RSVP met également ce voisin en panne. Cependant, les protocoles IGP et RSVP agissent toujours indépendamment lorsqu’un voisin est en place.

Pour les routeurs Juniper Networks, la configuration d’un intervalle RSVP hello plus court ou plus n’a aucun impact sur l’interruption ou non d’une session RSVP. Les sessions RSVP sont conservées même si les paquets RSVP hello ne sont plus reçus. Les sessions RSVP sont maintenues jusqu’à ce que le routeur cesse de recevoir les paquets IGP Hello ou que les messages RSVP Path et Resv ne soient plus disponibles. Toutefois, à partir de la version 16.1 de Junos OS, lorsque les messages RSVP hello sont supprimés, les sessions RSVP sont indisponibles.

L’intervalle hello RSVP peut également être impacté lorsque l’équipement d’un autre fournisseur met en panne une session RSVP. Par exemple, un routeur voisin non Juniper Networks peut être configuré pour surveiller les paquets RSVP hello.

Pour modifier la fréquence à laquelle RSVP envoie des paquets hello, incluez l’instruction hello-interval :

Remarque :

À partir de la version 16.1, Junos envoie des messages RSVP hello via un contournement LSP lorsqu’un commutateur est disponible. Pour no-node-hello-on-bypass savoir comment revenir au comportement historique de l’envoi de bonjours sur le saut suivant IGP.

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, reportez-vous à la section résumé de l’énoncé.

Configuration de l’authentification RSVP

Tous les échanges de protocoles RSVP peuvent être authentifiés afin de garantir que seuls les voisins de confiance participent à la configuration des réservations. Par défaut, l’authentification RSVP est désactivée.

L’authentification RSVP utilise un digesteur basé sur les messages HMAC-MD5. Ce schéma produit un digeste de messages basé sur une clé d’authentification secrète et le contenu du message. (Le contenu du message comprend également un numéro de séquence.) Le digeste informatique est transmis à l’aide de messages RSVP. Une fois l’authentification configurée, tous les messages RSVP reçus et transmis avec tous les voisins sont authentifiés sur cette interface.

L’authentification MD5 offre une protection contre la contrefaçon et la modification des messages. Elle permet également d’éviter les attaques en rejeu. Toutefois, elle n’assure pas la confidentialité, car tous les messages sont envoyés en texte clair.

Par défaut, l’authentification est désactivée. Pour activer l’authentification, configurez une clé sur chaque interface en incluant l’instruction authentication-key :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

Configuration de l’abonnement à la bande passante pour les types de classes

Par défaut, RSVP permet d’utiliser 100 % de la bande passante pour un type de classe pour les réservations RSVP. Lorsque vous surabonnez un type de classe pour un LSP multiclasse, la demande agrégée de toutes les sessions RSVP peut dépasser la capacité réelle du type de classe.

Pour obtenir des instructions détaillées sur la configuration de l’abonnement à la bande passante pour les types de classes, reportez-vous à La configuration du pourcentage d’abonnement à la bande passante pour les LSP.

Configuration du seuil de mise à jour RSVP sur une interface

Les protocoles IGP (Interior Gateway Protocols) conservent la base de données des aspects techniques du trafic, mais la bande passante actuelle disponible sur les liens de la base de données des aspects techniques du trafic provient de RSVP. Lorsque la bande passante d’une liaison change, le RSVP informe les IGP, qui peuvent ensuite mettre à jour la base de données des aspects techniques du trafic et transmettre les nouvelles informations sur la bande passante à tous les nœuds du réseau. Les nœuds du réseau savent alors combien de bande passante est disponible sur la liaison de base de données des aspects techniques du trafic (locale ou distante), et CSPF peut calculer correctement les chemins.

Cependant, les mises à jour IGP peuvent consommer des ressources système excessives. Selon le nombre de nœuds d’un réseau, il peut ne pas être souhaitable d’effectuer une mise à jour IGP pour de petits changements de bande passante. En configurant l’instruction update-threshold au niveau de la [edit protocols rsvp] hiérarchie, vous pouvez ajuster le seuil auquel une modification de la bande passante réservée déclenche une mise à jour IGP.

Vous pouvez configurer une valeur de 0,001 % à 20 % (la valeur par défaut est 10 %) pour le déclenchement d’une mise à jour IGP. Si la modification de la bande passante réservée est supérieure ou égale au pourcentage de seuil configuré de la bande passante statique sur cette interface, une mise à jour IGP se produit. Par exemple, si vous avez configuré l’instruction update-threshold à 15 % et que le routeur découvre que la bande passante réservée sur une liaison a changé de 10 % de la bande passante des liaisons, RSVP ne déclenche pas de mise à jour IGP. Toutefois, si la bande passante réservée sur une liaison change de 20 % de la bande passante du lien, RSVP déclenche une mise à jour IGP.

Vous pouvez également configurer le seuil en tant que valeur absolue à l’aide de l’option threshold-value décrite dans l’instruction update-threshold .

Si la valeur seuil est configurée pour une bande passante supérieure à 20 % sur cette liaison, la valeur seuil est plafonnée à 20 % de la bande passante.

Par exemple, si la bande passante sur une interface est de 1 Gbit/s et que la threshold-value configuration est supérieure à 200 Mbits/s, le threshold-value débit est plafonné à 200 Mbits/s. Le seuil est affiché sous la forme de 20,000 % et de threshold-value 200 Mbit/s.

Remarque :

Les deux options, seuil pour cent et threshold-value, sont mutuellement exclusives. Vous ne pouvez configurer qu’une seule option à un moment donné pour générer une mise à jour IGP pour des réservations de bande passante réduite. Ainsi, lorsqu’une option est configurée, l’autre est calculée et affichée sur l’interface de ligne de commande.

Par exemple, sur une liaison de 1 Gbit/s, si le seuil pour cent est configuré à 5 %, le threshold-value chiffre est calculé et affiché en tant que 50 Mbits/s. De même, si le threshold-value seuil est configuré sur 50 m, le seuil est calculé et affiché sous forme de 5 %.

Pour ajuster le seuil auquel une modification de la bande passante réservée déclenche une mise à jour IGP, incluez l’énoncé du seuil de mise à jour . En raison du seuil de mise à jour, il est possible pour le CSPF (Constrained Shortest Path First) de calculer un chemin à l’aide d’une base de données obsolète d’aspects techniques du trafic et d’informations relatives à la bande passante sur une liaison. Si le RSVP tente d’établir un LSP sur ce chemin, il peut s’avérer qu’il n’y a pas suffisamment de bande passante sur cette liaison. Lorsque cela se produit, RSVP déclenche une mise à jour de la base de données des aspects techniques du trafic IGP, inondant les informations de bande passante mises à jour sur le réseau. CSPF peut ensuite recalculer le chemin en utilisant les informations de bande passante mises à jour, et tenter de trouver un autre chemin, évitant ainsi le lien congestionné. Notez que cette fonctionnalité est par défaut et ne nécessite aucune configuration supplémentaire.

Vous pouvez configurer l’instruction rsvp-error-hold-time au niveau de la [edit protocols mpls] hiérarchie ou de la [edit logical-systems logical-system-name protocols mpls] hiérarchie pour améliorer la précision de la base de données des aspects techniques du trafic (y compris la précision des estimations de bande passante pour les LSP) à l’aide des informations fournies par les messages PathErr. Découvrez comment améliorer la précision de la base de données des aspects techniques du trafic avec les messages RSVP PathErr.

Configuration de RSVP pour les interfaces non numérotées

Junos OS prend en charge les aspects techniques du trafic RSVP sur des interfaces non numérotées. Les informations relatives aux aspects techniques du trafic sur les liaisons non numérotées sont contenues dans les extensions d’ingénierie de trafic IGP pour OSPF et IS-IS, telles que décrites dans RFC 4203, les extensions OSPF pour la prise en charge de la commutation d’étiquettes multiprotocole généralisée (GMPLS) et les extensions RFC 4205, Système intermédiaire à système intermédiaire (IS-IS) pour la prise en charge de la commutation d’étiquettes multiprotocole généralisée (GMPLS). Les liaisons non numérotées peuvent également être spécifiées dans la signalisation des aspects techniques du trafic MPLS telle que décrite dans la directive RFC 3477, « Signaling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE). Cette fonctionnalité vous permet d’éviter d’avoir à configurer des adresses IP pour chaque interface participant au réseau à signalisation RSVP.

Pour configurer RSVP pour les interfaces non numérotées, vous devez configurer le routeur avec un ID de routeur à l’aide de l’instruction router-id spécifiée au niveau de la [edit routing-options] hiérarchie. L’ID du routeur doit être disponible pour le routage (vous pouvez généralement utiliser l’adresse de bouclage). Les messages de contrôle RSVP pour les liaisons non numérotées sont envoyés à l’aide de l’adresse d’ID du routeur (plutôt qu’une adresse sélectionnée de manière aléatoire).

Pour configurer la protection des liaisons et le reroutage rapide sur un routeur avec des interfaces non numérotées activées, vous devez configurer au moins deux adresses. Il est recommandé de configurer une interface secondaire sur le bouclage en plus de configurer l’ID du routeur.

Configuration de Node-ID RSVP Bonjours

Vous pouvez configurer des fonctionnalités RSVP hellos basées sur l’ID de nœud afin de garantir l’interopérabilité des routeurs Juniper Networks avec les équipements d’autres fournisseurs. Par défaut, Junos OS utilise des hellos RSVP basés sur l’interface. RSVP basé sur l’ID de nœud Bonjours sont spécifiés dans RFC 4558, Node-ID Based Resource Reservation Protocol (RSVP) Bonjour : Une déclaration d’explications. Les hellos node-ID RSVP sont utiles si vous avez configuré BFD pour détecter les problèmes sur les interfaces RSVP, ce qui vous permet de désactiver les hellos d’interface pour ces interfaces. Vous pouvez également utiliser des hellos node-ID pour des procédures de redémarrage progressif.

Les hellos Node-ID peuvent être activés globalement pour tous les voisins RSVP. Par défaut, l’ID de nœud hello la prise en charge est désactivée. Si vous n’avez pas activé d’ID de nœud RSVP sur le routeur, junos OS n’accepte aucun ID de nœud hello packets.

Remarque :

À partir de la version 16.1, Junos envoie des messages RSVP hello via un contournement LSP lorsqu’un commutateur est disponible. Pour no-node-hello-on-bypass savoir comment revenir au comportement historique de l’envoi de bonjours sur le saut suivant IGP.

Pour activer l’ID de nœud RSVP au niveau mondial sur le routeur, incluez l’instruction node-hello aux niveaux hiérarchiques suivants :

  • [edit protocols rsvp]

  • [edit logical-systems logical-systems-name protocols rsvp]

Vous pouvez également désactiver explicitement les bonjours de l’interface RSVP dans le monde entier. Ce type de configuration peut être nécessaire dans les réseaux où le routeur Juniper Networks dispose de nombreuses connexions RSVP avec des équipements d’autres fournisseurs. Toutefois, si vous désactivez globalement l’interface RSVP, vous pouvez également configurer un intervalle hello sur une interface RSVP à l’aide de l’instruction hello-interval . Cette configuration désactive globalement l’interface RSVP, mais active les bonjours de l’interface RSVP sur l’interface spécifiée (l’interface RSVP sur qui vous configurez l’instruction hello-interval ). Cette configuration peut être nécessaire dans un réseau hétérogène dans lequel certains équipements prennent en charge les hellos node-ID RSVP et d’autres prennent en charge les bonjours de l’interface RSVP.

Pour désactiver l’interface RSVP hellos globalement sur le routeur, incluez l’instruction no-interface-hello aux niveaux hiérarchiques suivants :

  • [edit protocols rsvp]

  • [edit logical-systems logical-systems-name protocols rsvp]

Exemple : Configuration des LSP à signalisation RSVP

Cet exemple montre comment créer un LSP entre les routeurs d’un réseau IP en utilisant RSVP comme protocole de signalisation.

Conditions préalables

Avant de commencer, supprimez les services de sécurité de l’équipement. Voir l’exemple : Suppression des services de sécurité.

Présentation et topologie

En utilisant RSVP comme protocole de signalisation, vous pouvez créer des LSP entre les routeurs d’un réseau IP. Dans cet exemple, vous configurez un exemple de réseau comme illustré dans Figure 1.

Topologie

Figure 1 : LSP typique à signalisation RSVPLSP typique à signalisation RSVP

Pour établir un LSP entre les routeurs, vous devez activer individuellement la famille MPLS et configurer RSVP sur chacune des interfaces de transit du réseau MPLS. Cet exemple montre comment activer MPLS et configurer RSVP sur l’interface de transit ge-0/0/0. En outre, vous devez activer le processus MPLS sur toutes les interfaces MPLS du réseau.

Cet exemple montre comment définir un LSP de R1 à R7 sur le routeur d’entrant (R1) à l’aide de l’adresse de bouclage (10.0.9.7). La configuration réserve 10 Mbits/s de bande passante. En outre, la configuration désactive l’algorithme CSPF, afin de s’assurer que les hôtes C1 et C2 utilisent le LSP à signalisation RSVP correspondant au chemin le plus court de l’IGP réseau.

Configuration

Procédure

Configuration rapide CLI

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

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à Using the CLI Editor in Configuration Mode dans le CLI User Guide.

Pour configurer RSVP :

  1. Activez la famille MPLS sur toutes les interfaces de transit du réseau MPLS.

  2. Activez RSVP sur chaque interface de transit du réseau MPLS.

  3. Activez le processus MPLS sur l’interface de transit dans le réseau MPLS.

  4. Définissez le LSP sur le routeur d’entrant.

  5. Réservez 10 Mbit/s de bande passante sur le LSP.

Résultats

Confirmez votre configuration en entrant la show commande à partir du mode de configuration. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration fournies dans cet exemple pour la corriger.

Par souci de brièveté, cette show sortie de commande inclut uniquement la configuration pertinente à cet exemple. Toute autre configuration du système a été remplacée par des ellipses (...).

Si vous avez terminé la configuration de l’unité, entrez commit dans le mode de configuration.

Vérification

Pour vérifier que la configuration fonctionne correctement, effectuez les tâches suivantes :

Vérification des voisins RSVP

But

Vérifiez que chaque équipement affiche les voisins RSVP appropriés, par exemple, que le routeur R1 répertorie Figure 1 à la fois les routeurs R3 et R2 comme voisins RSVP.

Action

Dans l’interface de ligne de commande, saisissez la show rsvp neighbor commande.

La sortie affiche les adresses IP des routeurs voisins. Vérifiez que chaque adresse de bouclage de routeur RSVP voisine est répertoriée.

Vérification des sessions RSVP

But

Vérifiez qu’une session RSVP a été établie entre tous les voisins RSVP. Vérifiez également que la valeur de réservation de bande passante est active.

Action

Dans l’interface de ligne de commande, saisissez la show rsvp session detail commande.

Le résultat affiche les informations détaillées, notamment les ID de session, la réservation de bande passante et les adresses de saut suivant, pour chaque session RSVP établie. Vérifiez les informations suivantes :

  • Chaque adresse de voisin RSVP comporte une entrée pour chaque voisin, indiquée par adresse de bouclage.

  • L’état de chaque session LSP est Up.

  • Pour Tspec, la valeur de bande passante appropriée, 10Mbpsapparaît.

Vérification de la présence de LSP à signalisation RSVP

But

Vérifiez que la table de routage du routeur d’entrée (d’entrée) a configuré un LSP en fonction de l’adresse de bouclage de l’autre routeur. Par exemple, vérifiez que la inet.3 table de routage du routeur d’entrée R1 du routeur a Figure 1 configuré LSP comme adresse de bouclage du routeur R7.

Action

Dans l’interface de ligne de commande, saisissez la show route table inet.3 commande.

La sortie affiche les routes RSVP présentes dans la table de inet.3 routage. Vérifiez qu’un LSP à signalisation RSVP est associé à l’adresse de bouclage du routeur de sortie (R7) dans le réseau MPLS.

Exemple : Configuration du maillage automatique RSVP

Les fournisseurs de services utilisent souvent des VPN BGP et MPLS pour faire évoluer efficacement le réseau tout en fournissant des services générateurs de revenus. Dans ces environnements, BGP est utilisé pour distribuer les informations de routage VPN sur le réseau du fournisseur de services, tandis que MPLS est utilisé pour transférer ce trafic VPN d’un site VPN à un autre.

Lors de l’ajout d’un nouveau routeur PE qui participera aux VPN BGP et MPLS, tous les routeurs PE existants précédemment doivent être configurés pour appairer avec le nouveau routeur PE pour BGP et MPLS. À mesure que chaque nouveau routeur PE est ajouté au réseau du fournisseur de services, la charge de configuration devient bientôt trop importante à gérer.

Les exigences de configuration pour l’appairage BGP peuvent être réduites grâce à l’utilisation de réflecteurs de route. Dans les réseaux MPLS à signalisation RSVP, le maillage automatique RSVP peut réduire la charge de configuration pour la partie MPLS du réseau. La configuration rsvp-te sur tous les routeurs PE permet à RSVP de créer automatiquement les LSP nécessaires lors de l’ajout d’un nouveau routeur PE.

Conditions préalables

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

  • Routeur exécutant Junos OS version 10.1 ou ultérieure.

  • Un protocole BGP et VPN MPLS utilisant RSVP comme protocole de signalisation LSP (Label-Switched Path) MPLS.

Présentation

Cet exemple montre comment configurer le maillage automatique RSVP sur un routeur PE à l’aide de l’instruction de rsvp-te configuration. Pour que le maillage automatique RSVP fonctionne correctement, tous les routeurs PE de la configuration de maillage intégral doivent disposer de l’instruction rsvp-te configurée. Cela garantit que tous les nouveaux routeurs PE ajoutés ultérieurement bénéficieront également de la fonctionnalité de maillage automatique, à condition qu’ils soient eux aussi configurés avec l’instruction rsvp-te .

Étant donné cette exigence, cet exemple affiche uniquement la configuration sur le routeur PE nouvellement ajouté. On suppose que le maillage automatique RSVP a déjà été configuré sur les routeurs PE existants.

Topologie

Dans Figure 2, il existe trois routeurs PE existants, PE1, PE2 et PE3, dans la topologie. Le pe4 a été ajouté et le maillage automatique RSVP sera configuré. Le cloud représente le réseau du fournisseur de services, et l’adresse réseau, 192.0.2.0/24, est représentée au centre de la figure.

Figure 2 : Réseau de fournisseur de services avec routeurs PERéseau de fournisseur de services avec routeurs PE

Configuration

La configuration du maillage automatique RSVP implique l’exécution des tâches suivantes :

  • Activation de l’instruction rsvp-te de configuration au niveau de la [edit routing-options dynamic-tunnels dynamic-tunnel-name] hiérarchie.

  • Configuration de l’élément requis destination-networks .

    Cet élément de configuration spécifie la plage de préfixes IPv4 pour le réseau de destination. Seuls des tunnels dans la plage de préfixes spécifiés peuvent être créés.

  • Configuration de l’élément requis label-switched-path-template .

    Cet élément de configuration prend l’un default-template ou l’autre nom d’un modèle LSP préconfiguré comme argument. Il default-template s’agit d’un modèle défini par le système qui ne nécessite aucune configuration utilisateur.

Configuration rapide CLI

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

Routeur PE4

Configuration du maillage automatique RSVP

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur cette méthode, reportez-vous à Using the CLI Editor in Configuration Mode dans le GUIDE DE L’UTILISATEUR CLI.

Pour activer le maillage automatique RSVP :

  1. Configurez rsvp-te au niveau de la [edit routing-options dynamic-tunnels] hiérarchie.

  2. Configurez destination-networks au niveau de la [edit routing-options dynamic-tunnels] hiérarchie.

Résultats

Émettre la show commande à partir du [edit routing-options dynamic-tunnels] niveau hiérarchique pour afficher les résultats de votre configuration :

Vérification

Vérification de l’existence de tunnels de maillage automatique RSVP sur le routeur PE4

But

Pour vérifier le fonctionnement du routeur PE4 nouvellement configuré, émettez la commande depuis le show dynamic-tunnels database mode opérationnel. Cette commande affiche le réseau de destination sur lequel des tunnels dynamiques peuvent être créés.

Action

Vérification de l’existence de LSP MPLS sur le routeur PE4

But

Pour vérifier l’existence de LSP MPLS sur le routeur PE4, émettez la commande depuis le show mpls lsp mode opérationnel. Cette commande affiche l’état des LSP MPLS.

Action

Configuration Hello Accusés de réception pour les voisins RSVP non sessions

L’énoncé hello-acknowledgements contrôle le comportement de reconnaissance hello entre les voisins RSVP, qu’ils soient ou non dans la même session.

Bonjour les messages reçus par les voisins RSVP qui ne font pas partie d’une session RSVP commune sont jetés. Si vous configurez l’instruction hello-acknowledgements au niveau de la [edit protocols rsvp] hiérarchie, les messages d’bonjour des voisins de sessions sont acceptés avec un message de reconnaissance hello. Lorsque des voisins n’ont pas de session, une relation de voisinage RSVP est créée et des messages périodiques de bonjour peuvent désormais être reçus par le voisin qui n’a pas de session. L’instruction hello-acknowledgements est désactivée par défaut. La configuration de cette instruction permet de détecter les routeurs compatibles RSVP à l’aide de paquets Hello et de vérifier que l’interface est capable de recevoir des paquets RSVP avant d’envoyer des messages de configuration LSP MPLS.

Une fois que vous activez les accusés de réception pour les voisins RSVP non sessions, le routeur continue de reconnaître les messages hello de tous les voisins RSVP non sessions, sauf si l’interface elle-même tombe en panne ou que vous modifiez la configuration. Les voisins basés sur l’interface ne sont pas automatiquement vieillis.

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit protocols rsvp]

  • [edit logical-systems logical-system-name protocols rsvp]

Commutation de LSP loin d’un nœud réseau

Vous pouvez configurer le routeur pour qu’il désactive les LSP actifs d’un nœud réseau à l’aide d’une déviation LSP activée pour une interface. Cette fonctionnalité peut être utilisée pour maintenir des réseaux actifs lorsqu’un équipement doit être remplacé sans interrompre le trafic transitant par le réseau. Les LSP peuvent être statiques ou dynamiques.

  1. Vous devez d’abord configurer la protection des liaisons ou des nœuds pour le trafic devant transiter autour de l’équipement réseau que vous souhaitez désactiver. Pour fonctionner correctement, le LSP de contournement doit utiliser une interface logique différente de celle du LSP protégé.
  2. Pour préparer le routeur à commencer à éloigner le trafic d’un nœud réseau, configurez l’instruction always-mark-connection-protection-tlv :

    Le routeur marque ensuite tout le trafic OAM transitant par cette interface en préparation de la commutation du trafic vers un chemin alternatif basé sur la fonctionnalité OAM.

    Vous pouvez configurer cette instruction aux niveaux hiérarchiques suivants :

    • [edit protocols mpls interface interface-name]

    • [edit logical-systems logical-system-name protocols mpls interface interface-name]

  3. Vous devez ensuite configurer l’instruction switch-away-lsps pour basculer le trafic du LSP protégé vers le LSP de contournement, afin de contourner efficacement l’équipement réseau en aval par défaut. La liaison elle-même n’est pas diminuée par cette configuration.

    Pour configurer le routeur pour qu’il désactive le trafic d’un nœud réseau, configurez l’instruction switch-away-lsps :

    Vous pouvez configurer cette instruction aux niveaux hiérarchiques suivants :

    • [edit protocols mpls interface interface-name]

    • [edit logical-systems logical-system-name protocols mpls interface interface-name]

Notez les limites suivantes liées à la commutation de LSP actifs loin d’un nœud réseau :

  • La fonction d’abandon de commutateur est prise en charge uniquement sur les routeurs MX Series.

  • La fonctionnalité d’abandon de commutateur n’est pas prise en charge pour la commutation du trafic des LSP principaux point à multipoint afin de contourner les LSP point à multipoint. Si vous configurez l’instruction switch-away-lsps d’un LSP point à multipoint, le trafic n’est pas transféré vers le LSP de contournement point à multipoint.

  • Si vous configurez la fonctionnalité de commutation sur une interface le long du chemin d’un LSP dynamique, de nouveaux LSP dynamiques ne peuvent pas être établis sur ce chemin. La fonctionnalité d’abandon de commutateur empêche le comportement de pré-marque des LSP à signalisation RSVP. En règle générale, le comportement d’avant-rupture pousse le routeur à signaler de nouveau un LSP dynamique avant de dégrader l’original.

Configuration de la protection de configuration RSVP

Vous pouvez configurer le mécanisme de reroutage rapide de sauvegarde de l’installation afin de fournir une protection de configuration pour les LSP en cours de signalisation. Les LSP point à point et point à multipoint sont pris en charge. Cette fonctionnalité s’applique au scénario suivant :

  1. Une liaison ou un nœud défaillant est présent sur le chemin explicite strict d’un LSP avant que le LSP ne soit signalé.

  2. Il existe également un dérivation LSP protégeant la liaison ou le nœud.

  3. Le protocole RSVP signale le LSP par le biais du LSP de contournement. Le LSP apparaît comme s’il avait été initialement configuré le long de son chemin principal, puis n’a pas réussi à contourner le LSP en raison d’une défaillance de la liaison ou du nœud.

  4. Lorsque la liaison ou le nœud est récupéré, le LSP peut être automatiquement rétabli vers le chemin principal.

Vous devez configurer l’instruction setup-protection au niveau [edit protocols rsvp] de chacun des routeurs le long du chemin LSP sur lequel vous souhaitez activer la protection contre la configuration LSP. Vous devez également configurer les aspects techniques du trafic IGP sur tous les routeurs du chemin LSP. Vous pouvez émettre une show rsvp session commande pour déterminer si la protection de configuration du LSP est activée ou non sur un routeur faisant office de point de réparation local (PLR) ou de point de fusion.

Pour activer la protection contre la configuration RSVP, incluez l’instruction setup-protection

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit protocols rsvp]

  • [edit logical-systems logical-system-name protocols rsvp]

Configuration de l’équilibrage de charge entre les LSP RSVP

Par défaut, lorsque vous avez configuré plusieurs LSP RSVP sur le même routeur de sortie, le LSP avec la mesure la plus faible est sélectionné et transporte tout le trafic. Si tous les LSP ont la même métrique, un des LSP est sélectionné de manière aléatoire et l’ensemble du trafic est transféré vers lui.

Vous pouvez également équilibrer la charge du trafic sur l’ensemble des LSP en activant l’équilibrage de charge par paquet.

Pour activer l’équilibrage de charge par paquet sur une LSP entrante, configurez l’instruction policy-statement comme suit :

Vous devez ensuite appliquer cette instruction en tant que stratégie d’exportation à la table de transfert.

Une fois l’équilibrage de charge par paquet appliqué, le trafic est distribué de la même manière entre les LSP (par défaut).

Vous devez configurer l’équilibrage de charge par paquet pour activer le reroutage rapide du PFE. Pour permettre le reroutage rapide du PFE, incluez l’instruction policy-statement d’équilibrage de charge par paquet indiquée dans cette section dans la configuration de chacun des routeurs où un reroutage peut avoir lieu. Voir également Configuration du reroutage rapide.

Vous pouvez également équilibrer la charge du trafic entre les LSP en fonction de la quantité de bande passante configurée pour chaque LSP. Cette capacité peut mieux distribuer le trafic dans les réseaux avec des capacités de bande passante asymétrique sur les liaisons externes, car la bande passante configurée d’un LSP reflète généralement la capacité de trafic de ce LSP.

Pour configurer l’équilibrage de charge LSP RSVP, incluez l’instruction load-balance avec l’option bandwidth :

Vous pouvez configurer cette instruction aux niveaux hiérarchiques suivants :

  • [edit protocols rsvp]

  • [edit logical-systems logical-system-name protocols rsvp]

Gardez à l’esprit les informations suivantes lorsque vous utilisez l’énoncé load-balance :

  • Si vous configurez l’instruction load-balance , le comportement des LSP en cours d’exécution n’est pas modifié. Pour forcer les LSP en cours d’exécution à utiliser le nouveau comportement, vous pouvez émettre une clear mpls lsp commande.

  • Cette load-balance déclaration ne s’applique qu’aux LSP entrants qui ont activé l’équilibrage de charge par paquet.

  • Pour le trafic LSP (Differentiated Services-Aware Traffic Engineered LSP), la bande passante d’un LSP est calculée en résumant la bande passante de tous les types de classes.

Configuration du maillage automatique RSVP

Vous pouvez configurer RSVP pour établir automatiquement des chemins de commutation d’étiquettes (LSP) point à point pour tout nouveau routeur PE ajouté à un maillage complet de LSP. Pour activer cette fonctionnalité, vous devez configurer l’instruction rsvp-te sur tous les routeurs PE du maillage complet.

Remarque :

Vous ne pouvez pas configurer le maillage automatique RSVP en conjonction avec CCC. La CCC ne peut pas utiliser les LSP générés de façon dynamique.

Pour configurer le maillage automatique RSVP, incluez l’instruction rsvp-te :

Vous pouvez configurer ces instructions aux niveaux hiérarchiques suivants :

  • [edit routing-options dynamic-tunnels tunnel-name]

  • [edit logical-systems logical-system-name routing-options dynamic-tunnels tunnel-name]

Vous devez également configurer les instructions suivantes pour activer le maillage automatique RSVP :

  • destination-networks— Indiquez la plage de préfixes IP version 4 (IPv4) pour le réseau de destination. Des tunnels dynamiques dans la plage de préfixes IPv4 spécifiés peuvent être lancés.

  • label-switched-path-template (Multicast)— Vous pouvez configurer le modèle par défaut explicitement à l’aide de l’option default-template ou configurer votre propre modèle LSP à l’aide de cette template-name option. Le modèle LSP agit comme une configuration de modèle pour les LSP générés dynamiquement.

Configuration des timers pour les messages d’actualisation RSVP

RSVP utilise deux paramètres horaires associés :

  • refresh-time— L’heure d’actualisation contrôle l’intervalle entre la génération de messages d’actualisation successifs. La valeur par défaut du temps d’actualisation est de 45 secondes. Ce nombre est dérivé de la valeur par défaut de 30 de l’instruction refresh-time , multipliée par une valeur fixe de 1,5. Ce calcul diffère de RFC 2205, qui indique que le temps d’actualisation doit être multiplié par une valeur aléatoire comprise entre 0,5 et 1,5.

    Les messages d’actualisation incluent des messages de chemin et de resv. Les messages d’actualisation sont envoyés périodiquement afin que les états de réservation dans les nœuds voisins ne s’timent pas. Chaque chemin et chaque message Resv transporte la valeur du timer de mise à jour, et le nœud destinataire extrait cette valeur des messages.

  • keep-multiplier— Le multiplicateur de keep est un petit entier configuré localement de 1 à 255. La valeur par défaut est 3. Il indique le nombre de messages susceptibles d’être perdus avant qu’un état particulier ne soit déclaré obsolète et doit être supprimé. Le facteur multiplicateur de keep affecte directement la durée de vie d’un état RSVP.

Pour déterminer la durée de vie d’un état de réservation, utilisez la formule suivante :

Dans le pire des cas, (keep-multiplier- 1) les messages de renouvellement successifs doivent être perdus avant de supprimer l’état de réservation.

Nous ne recommandons pas de configurer un court RSVP hello timer. Si vous avez besoin de découvrir rapidement un voisin défaillant, configurez de courts mécanismes IGP (OSPF ou IS-IS) hello timers.

Par défaut, la valeur du minuteur d’actualisation est de 30 secondes. Pour modifier cette valeur, incluez l’instruction refresh-time :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit protocols rsvp]

  • [edit logical-systems logical-system-name protocols rsvp]

La valeur par défaut du multiplicateur de keep est 3. Pour modifier cette valeur, incluez l’instruction keep-multiplier :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit protocols rsvp]

  • [edit logical-systems logical-system-name protocols rsvp]

Préemptage des sessions RSVP

Chaque fois que la bande passante est insuffisante pour gérer toutes les sessions RSVP, vous pouvez contrôler la préemption des sessions RSVP. Par défaut, une session RSVP est préemptée uniquement par une nouvelle session prioritaire.

Pour toujours anticiper une session lorsque la bande passante est insuffisante, incluez l’instruction preemption avec l’option aggressive :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit protocols rsvp]

  • [edit logical-systems logical-system-name protocols rsvp]

Pour désactiver la préemption de session RSVP, incluez l’instruction preemption avec l’option disabled :

Pour revenir à la valeur par défaut (c’est-à-dire, ne préempter une session que pour une nouvelle session de priorité supérieure), incluez l’instruction preemption avec l’option normal :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit protocols rsvp]

  • [edit logical-systems logical-system-name protocols rsvp]

Configuration de la signalisation MTU dans RSVP

Pour configurer la signalisation MTU (Max Transmission Unit) dans RSVP, vous devez configurer MPLS pour permettre la fragmentation des paquets IP avant qu’ils ne soient encapsulés dans MPLS. Vous devez également configurer la signalisation MTU dans RSVP. À des fins de dépannage, vous pouvez configurer la signalisation MTU seule sans activer la fragmentation des paquets.

Pour configurer la signalisation MTU dans RSVP, incluez l’instruction path-mtu :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

Les sections suivantes décrivent comment activer la fragmentation des paquets et la signalisation MTU dans RSVP :

Activation de la signalisation MTU dans RSVP

Pour activer la signalisation MTU dans RSVP, incluez l’instruction rsvp mtu-signaling :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit protocols mpls path-mtu]

  • [edit logical-systems logical-system-name protocols mpls path-mtu]

Une fois la configuration validée, les modifications du comportement de signalisation MTU pour RSVP prennent effet la prochaine fois que le chemin est actualisé.

Vous pouvez configurer l’instruction mtu-signaling par elle-même au niveau de la [edit protocols mpls path-mtu rsvp] hiérarchie. Cela peut être utile pour le dépannage. Si vous configurez uniquement l’instruction mtu-signaling , vous pouvez utiliser la show rsvp session detail commande pour déterminer quel est le plus petit MTU sur un LSP. La show rsvp session detail commande affiche la valeur MTU reçue et envoyée dans l’objet Adspec.

Favoriser la fragmentation des paquets

Pour permettre la fragmentation des paquets IP avant qu’ils ne soient encapsulés dans MPLS, incluez l’instruction allow-fragmentation :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit protocols mpls path-mtu]

  • [edit logical-systems logical-system-name protocols mpls path-mtu]

    Remarque :

    Ne configurez pas l’instruction allow-fragmentation seule. Configurez-le toujours conjointement avec l’instruction mtu-signaling .

Configuring Ultimate-Hop Popping for LSP (Configuration du popping ultime pour les LSP)

Par défaut, les LSP à signalisation RSVP utilisent php (penultimate-hop popping). Figure 3 illustre un LSP d’avant-dernière saut entre le routeur PE1 et le routeur PE2. Le routeur CE1 transfère un paquet vers son prochain saut (routeur PE1), qui est également l’entrant LSP. Le routeur PE1 pousse l’étiquette 1 sur le paquet et transfère le paquet étiqueté au routeur P1. Le routeur P1 effectue le fonctionnement standard de permutation d’étiquettes MPLS, remplace le label 1 par le label 2 et transfère le paquet au routeur P2. Le routeur P2 étant l’avant-dernier-saut du LSP vers le routeur PE2, il récupère d’abord le label, puis transfère le paquet vers le routeur PE2. Lorsque le routeur PE2 le reçoit, le paquet peut comporter un label de service, un label explicite-null ou simplement un paquet IP ou VPLS clair. Le routeur PE2 transfère le paquet non étiqueté au routeur CE2.

Figure 3 : Avant-dernière hop popping pour un LSPAvant-dernière hop popping pour un LSP

Vous pouvez également configurer l’UHP (Ultimate-Hop Popping) pour Figure 4les LSP à signalisation RSVP. Certaines applications réseau peuvent exiger que les paquets arrivent au routeur de sortie (routeur PE2) avec un label externe non nul. Pour une LSP à sauts ultime, l’avant-dernier routeur (routeur P2 in Figure 4) effectue le fonctionnement standard de permutation d’étiquettes MPLS (dans cet exemple, label 2 pour le label 3 ) avant de transférer le paquet vers le routeur de sortie PE2. Le routeur PE2 récupère l’étiquette externe et effectue une seconde recherche de l’adresse de paquet pour déterminer la destination finale. Il transfère ensuite le paquet vers la destination appropriée (routeur CE2 ou ROUTEUR CE4).

Figure 4 : Le popping ultime pour un LSPLe popping ultime pour un LSP

Les applications réseau suivantes nécessitent de configurer des LSP UHP :

  • MPLS-TP pour la surveillance des performances et l’OAM en bande

  • Circuits virtuels de protection de périphérie

Les fonctionnalités suivantes ne prennent pas en charge le comportement de l’UHP :

  • LSP à signalisation LDP

  • LSP statiques

  • LSP point à multipoint

  • CCC

  • traceroute Commande

Pour plus d’informations sur le comportement de l’UHP, voir Internet draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt, Non PHP behavior and Out-of-Band Mapping for RSVP-TE LSP.

Pour les LSP à signalisation RSVP point à point, le comportement de l’UHP est signalé depuis l’entrant LSP. En fonction de la configuration du routeur d’entrant, RSVP peut signaler l’UHP LSP avec le flag set non PHP. Les messages RSVP PATH portent les deux indicateurs de l’objet LSP-ATTRIBUTES. Lorsque le routeur de sortie reçoit le message PATH, il attribue un label non nul au LSP. RSVP crée et installe également deux routes dans la table de routage mpls.0. S désigne le bit S du label MPLS, qui indique si le bas de la pile de labels a été atteint ou non.

  • Route S=0 : indique qu’il existe d’autres étiquettes dans la pile. Le saut suivant de cette route pointe vers la table de routage mpls.0, déclenchant une recherche d’étiquettes MPLS en chaîne pour découvrir les étiquettes MPLS restantes dans la pile.

  • Route S=1 : indique qu’il n’y a plus de labels. Le saut suivant indique la table de routage inet.0 si la plate-forme prend en charge la recherche multi-famille enchaînée. Le routage d’étiquettes peut également pointer vers une interface VT pour lancer le transfert IP.

Si vous activez les LSP UHP, les applications MPLS telles que les VPN de couche 3, LES VPLS, les VPN de couche 2 et les circuits de couche 2 peuvent utiliser les LSP UHP. Le livre suivant explique comment les LSP affectent les différents types d’applications MPLS :

  • VPN de couche 2 et circuits de couche 2 : un paquet arrive au routeur PE (sortie de l’UHP LSP) avec deux étiquettes. L’étiquette externe (S=0) est l’étiquette UHP, et l’étiquette interne (S=1) est l’étiquette VC . Une recherche basée sur le label de transport donne une poignée de table pour la table de routage mpls.0. Une route supplémentaire est ajoutée dans la table de routage mpls.0 correspondant au label interne. Une recherche basée sur l’étiquette interne donne au routeur CE le saut suivant.

  • VPN de couche 3 : un paquet arrive au routeur PE (sortie de l’UHP LSP) avec deux étiquettes. L’étiquette externe (S=0) est l’étiquette UHP, et l’étiquette interne est l’étiquette VPN (S=1). Une recherche basée sur le label de transport donne un résultat dans la poignée de table pour la table de routage mpls.0. Il y a deux cas dans ce scénario. Par défaut, les VPN de couche 3 affichent le label par saut suivant. Une recherche basée sur l’étiquette interne entraîne le saut suivant vers le routeur CE. Toutefois, si vous avez configuré l’instruction vrf-table-label pour l’instance de routage VPN de couche 3, l’étiquette LSI interne renvoie à la table de routage VRF. Une recherche IP est également effectuée pour la table de routage VRF.

    Remarque :

    L’UHP pour les VPN de couche 3 configurés avec l’instruction vrf-table-label est pris en charge uniquement sur les plates-formes de routage universelles 5G MX Series.

  • VPLS : un paquet arrive au routeur PE (sortie de l’UHP LSP) avec deux étiquettes. L’étiquette externe est l’étiquette de transport (S=0) et l’étiquette interne est l’étiquette VPLS (S=1). Une recherche basée sur le label de transport donne un résultat dans la poignée de table pour la table de routage mpls.0. Une recherche basée sur l’étiquette interne de la table de routage mpls.0 entraîne l’interface de tunnel LSI de l’instance de routage VPLS si les services de tunnel n’sont pas configurés (ou une interface VT non disponible). Les routeurs MX Series 3D prennent en charge la recherche en chaîne et la recherche multi-famille.

    Remarque :

    L’UHP pour VPLS configuré avec l’instruction no-tunnel-service est pris en charge uniquement sur les routeurs MX 3D Series.

  • IPv4 sur MPLS : un paquet arrive au routeur PE (sortie de l’UHP LSP) avec un seul label (S=1). Une recherche basée sur ce label renvoie une interface de tunnel VT. Une autre recherche IP est effectuée sur l’interface VT pour déterminer où transférer le paquet. Si la plate-forme de routage prend en charge les recherches multi-familles et en chaîne (par exemple, les routeurs 3D MX et les routeurs de transport de paquets PTX Series), recherchez en fonction des points de routage d’étiquettes (S=1) vers la table de routage inet.0.

  • IPv6 sur MPLS : pour la tunnelisation IPv6 sur MPLS, les routeurs PE font la promotion des routes IPv6 entre elles avec une valeur d’étiquette de 2. Il s’agit du label explicite NULL pour IPv6. En conséquence, les sauts suivants pour les routes IPv6 qui sont apprises à partir de routeurs PE distants poussent normalement deux étiquettes. L’étiquette intérieure est 2 (il peut être différent si le routeur PE publicitaire provient d’un autre fournisseur) et le label du routeur est le label LSP. Les paquets arrivent au routeur PE (sortie de l’UHP LSP) avec deux étiquettes. L’étiquette externe est le label de transport (S=0) et le label interne est le label IPv6 explicit-null (label 2). Recherche basée sur le label interne dans la table de routage mpls.0 redirige vers la table de routage mpls.0. Sur les routeurs MX 3D Series, l’étiquette interne (label 2) est retirée et une recherche IPv6 est effectuée à l’aide de la table de routage inet6.0.

  • Activation des LSP PHP et UHP : vous pouvez configurer les LSP PHP et UHP sur les mêmes chemins réseau. Vous pouvez séparer le trafic PHP et UHP en sélectionnant le saut suivant LSP à l’aide d’une expression régulière avec l’instruction install-nexthop . Vous pouvez également séparer le trafic en nommant simplement les LSP correctement.

Les instructions suivantes permettent d’activer le saut ultime pour un LSP. Vous pouvez activer cette fonctionnalité sur un LSP spécifique ou pour tous les LSP d’entrant configurés sur le routeur. Configurez ces instructions sur le routeur lors de l’entrant LSP.

  1. Pour permettre l’apparition du saut ultime, incluez la ultimate-hop-popping déclaration :

    Incluez cette déclaration au niveau de la [edit protocols mpls label-switched-path label-switched-path-name] hiérarchie pour activer le saut ultime sur un LSP spécifique. Incluez cette déclaration au niveau de la [edit protocols mpls] hiérarchie pour activer le saut ultime sur tous les LSP entrants configurés sur le routeur. Vous pouvez également configurer l’instruction ultimate-hop-popping sous les niveaux hiérarchiques équivalents [edit logical-routers] .

    Remarque :

    Lorsque vous activez le popping ultime-hop, RSVP tente de quitter les LSP existants en tant que LSP ultime-hop popping de façon à faire-avant de breaker. Si un routeur de sortie ne prend pas en charge le popping ultime, le LSP existant est détruit (le RSVP envoie un message PathTear le long du chemin d’un LSP, supprimant l’état du chemin et l’état de réservation dépendant et libérant les ressources réseau associées).

    Si vous désactivez l’ultimate-hop popping, le RSVP démissionne des LSP existants en tant qu’avant-dernière hop popping LSP de façon à faire-avant-breaker.

  2. Si vous souhaitez activer à la fois le saut ultime et les sauts suivants enchaînés uniquement sur les routeurs MX 3D Series, vous devez également configurer l’option enhanced-ip pour l’instruction network-services :

    Vous configurez cette instruction au niveau de la [edit chassis] hiérarchie. Une fois l’instruction network-services configurée, vous devez redémarrer le routeur pour activer le comportement de l’UHP.

Configuration du protocole RSVP pour qu’il affiche l’étiquette sur le routeur Ultimate-Hop

Vous pouvez contrôler la valeur d’étiquette annoncée sur le routeur de sortie d’un LSP. Le label annoncé par défaut est le label 3 (label NULL implicite). Si le label 3 est annoncé, l’avant-dernier saut du routeur retire le label et envoie le paquet au routeur de sortie. Lorsque le popping ultime est activé, le label 0 (ip version 4 [IPv4] Explicit NULL) est annoncé. Le popping ultime garantit que tous les paquets traversant un réseau MPLS comprennent un label.

Remarque :

Les routeurs Juniper Networks font la file d’attente des paquets en fonction du label entrant. Les routeurs d’autres fournisseurs peuvent mettre en file d’attente les paquets différemment. Gardez cela à l’esprit lorsque vous travaillez avec des réseaux contenant des routeurs de différents fournisseurs.

Pour configurer le saut ultime pour RSVP, incluez l’instruction explicit-null :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

Permettre un popping ultime sur les LSP point-à-multipoint

Par défaut, pour les LSP point à point et point à multipoint, l’avant-dernier saut est utilisé pour le trafic MPLS. Les étiquettes MPLS sont retirées des paquets du routeur juste avant le routeur de sortie du LSP. Les paquets IP simples sont ensuite transféré vers le routeur de sortie. Pour le popping ultime, le routeur de sortie est responsable à la fois de supprimer l’étiquette MPLS et de traiter le paquet IP simple.

Il peut être bénéfique d’activer un saut ultime sur les LSP point-à-multipoint, en particulier lorsque le trafic de transit traverse le même équipement de sortie. Si vous activez la création d’un saut ultime, une seule copie du trafic peut être envoyée via la liaison entrante, ce qui permet d’économiser une bande passante importante. Par défaut, le popping ultime du saut est désactivé.

Vous activez l’activation du saut ultime pour les LSP point à multipoint en configurant l’instruction tunnel-services . Lorsque vous activez l’activation du saut ultime, le système d’exploitation Junos OS sélectionne l’une des interfaces VT (Virtual Loopback Tunnel) disponibles pour boucler les paquets vers le PFE pour le transfert IP. Par défaut, le processus de sélection de l’interface VT est exécuté automatiquement. Le contrôle d’admission de bande passante permet de limiter le nombre de LSP pouvant être utilisés sur une seule interface VT. Une fois toute la bande passante utilisée sur une interface, Junos OS sélectionne une autre interface VT avec une bande passante suffisante pour le contrôle d’admission.

Si un LSP nécessite une bande passante supérieure à celle disponible à partir de n’importe quelle interface VT, le popping ultime n’est pas activé et l’avant-dernier saut est activé à la place.

Pour fonctionner correctement sur les LSP point à multipoint, le routeur sortant doit disposer d’un PIC qui fournit des services de tunnel, comme le PIC de services de tunnel ou le PIC de services adaptatifs. Des services de tunnel sont nécessaires pour obtenir le label MPLS final et pour renvoyer des paquets pour rechercher des adresses IP.

Vous pouvez configurer explicitement les interfaces VT qui gèrent le trafic RSVP en incluant l’option devices d’instruction tunnel-services . Cette devices option vous permet de spécifier les interfaces VT à utiliser par RSVP. Si vous ne configurez pas cette option, toutes les interfaces VT disponibles sur le routeur peuvent être utilisées.

Pour activer le saut ultime pour les LSP point-à-multipoint sortants sur un routeur, configurez l’instruction tunnel-services :

Vous pouvez configurer cette instruction aux niveaux hiérarchiques suivants :

  • [edit protocols rsvp]

  • [edit logical-systems logical-system-name protocols rsvp]

Pour activer le saut ultime pour les LSP point-à-multipoint sortants, vous devez également configurer l’instruction interface avec l’option all :

Vous devez configurer cette instruction au niveau de la [edit protocols rsvp] hiérarchie.

Traçage du trafic du protocole RSVP

Pour suivre le trafic du protocole RSVP, incluez l’instruction traceoptions :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit protocols rsvp]

  • [edit logical-systems logical-system-name protocols rsvp]

Vous pouvez spécifier les indicateurs spécifiques RSVP suivants dans l’instruction RSVP traceoptions :

Utilisez l’instruction file pour spécifier le nom du fichier qui reçoit la sortie de l’opération de traçage. Tous les fichiers sont placés dans le répertoire /var/log. Il est recommandé de placer la sortie de traçage RSVP dans le fichier rsvp-log.

  • all— Toutes les opérations de traçage.

  • error— Toutes les conditions d’erreur détectées

  • event— Événements liés au RSVP (permet de suivre les événements liés au redémarrage progressif RSVP)

  • lmp— Interactions RSVP-Link Management Protocol (LMP)

  • packets— Tous les paquets RSVP

  • path— Tous les messages de chemin

  • pathtear— Messages PathTear

  • resv— Messages de resv

  • resvtear— Messages resvTear

  • route— Informations de routage

  • state— Transitions d’état de session, y compris lorsque des LSP signalés par RSVP apparaissent et tombent en panne.

Remarque :

Utilisez l’indicateur all de traçage et le detail modificateur de flag avec précaution, car cela peut entraîner une forte activité du processeur.

Pour afficher le fichier journal généré lorsque vous activez les options de trace RSVP, émettre la show log file-name commande, où file-name est le fichier que vous avez spécifié à l’aide de l’instruction traceoptions .

Pour plus d’informations sur le traçage et les options de traçage global, consultez la bibliothèque junos OS Routing Protocols for Routing Devices.

Exemples: Traçage du trafic du protocole RSVP

Tracez les messages de chemin RSVP en détail :

Tracez tous les messages RSVP :

Tracez toutes les conditions d’erreur RSVP :

Suivi des transitions d’état RSVP :

Sortie du fichier journal RSVP

Voici l’exemple de sortie généré par l’émission de la show log file-name commande sur un routeur sur lequel les options de trace RSVP ont été activées avec l’indicateur state configuré. L’E-D LSP à signalisation RSVP est montrée déchirée le Mar 11 14:04:36.707092. Le Mar 11 14:05:30.101492, il est montré revient.

RSVP Graceful Restart

Le redémarrage progressif RSVP permet à un routeur en cours de redémarrage d’informer ses voisins adjacents de son état. Le routeur de redémarrage demande un délai de grâce au voisin ou à l’pair, qui peut alors coopérer avec le routeur de redémarrage. Le routeur de redémarrage peut toujours transférer le trafic MPLS pendant la période de redémarrage. la convergence dans le réseau n’est pas perturbée. Le redémarrage n’est pas visible par le reste du réseau et le routeur de redémarrage n’est pas retiré de la topologie du réseau. Le redémarrage progressif RSVP peut être activé sur les routeurs de transit et les routeurs d’entrée. Il est disponible à la fois pour les LSP point à point et pour les LSP point à multipoint.

Le redémarrage progressif RSVP est décrit dans les sections suivantes :

Terminologie relative au redémarrage progressif RSVP

Temps de redémarrage (en millisecondes)

La valeur par défaut est 60 000 millisecondes (1 minute). L’heure de redémarrage est annoncée dans le message hello. L’heure indique la durée d’attente d’un voisin pour recevoir un message d’bonjour d’un routeur de redémarrage avant de déclarer que le routeur est mort et les états de purgation.

Junos OS peut remplacer l’heure de redémarrage annoncée d’un voisin si celle-ci est supérieure à un tiers de celle du redémarrage local. Par exemple, étant donné le temps de redémarrage par défaut de 60 secondes, un routeur attendrait au moins 20 secondes pour recevoir un message hello d’un voisin qui redémarrait. Si le temps de redémarrage est nul, le voisin qui le redémarre peut immédiatement être déclaré mort.

Temps de récupération (en millisecondes)

S’applique uniquement lorsque le canal de contrôle est opérationnel (l’échange hello est terminé) avant l’heure de redémarrage. S’applique uniquement aux pannes nodal.

Lorsqu’un redémarrage progressif est en cours, le temps laissé pour effectuer une reprise est annoncé. D’autres fois, cette valeur est zéro. Le temps maximal de récupération annoncé est de 2 minutes (120 000 millisecondes).

Pendant le temps de récupération, un nœud de redémarrage tente de récupérer ses états perdus avec l’aide de ses voisins. Le voisin du nœud de redémarrage doit envoyer les messages de chemin avec les étiquettes de récupération au nœud de redémarrage dans un délai de la moitié du temps de récupération. Le nœud de redémarrage considère que son redémarrage progressif est terminé après son délai de récupération annoncé.

Opération de redémarrage progressif RSVP

Pour que le redémarrage progressif RSVP fonctionne, la fonctionnalité doit être activée sur l’instance de routage globale. Le redémarrage progressif RSVP peut être désactivé au niveau du protocole (pour RSVP uniquement) ou au niveau mondial pour tous les protocoles.

Le redémarrage progressif RSVP nécessite les éléments suivants d’un routeur de redémarrage et des voisins du routeur :

  • Pour le routeur de redémarrage, le redémarrage progressif RSVP tente de maintenir les routes installées par RSVP et les étiquettes attribuées, de sorte que le trafic continue d’être transféré sans perturbation. Le redémarrage progressif RSVP est effectué assez rapidement pour réduire ou éliminer l’impact sur les nœuds voisins.

  • Les routeurs voisins doivent être dotés du mode d’aide au redémarrage progressif RSVP, ce qui leur permet d’aider un routeur à tenter de redémarrer RSVP.

Un objet appelé « Restart Cap » (Cap de redémarrage) envoyé dans les messages hello RSVP présente la capacité de redémarrage d’un nœud. Le nœud voisin envoie un objet Recover Label au nœud de redémarrage afin de récupérer son état de transfert. Cet objet est essentiellement l’ancien label que le nœud de redémarrage annonçait avant que le nœud ne tombe en panne.

Les listes suivantes répertorient les comportements de redémarrage progressif RSVP, qui varient en fonction de la configuration et des fonctionnalités activées :

  • Si vous désactivez le mode d’assistance, Junos OS ne tente pas d’aider un voisin à redémarrer RSVP. Toutes les informations qui arrivent avec un objet Restart Cap d’un voisin sont ignorées.

  • Lorsque vous activez le redémarrage progressif dans le cadre de la configuration de l’instance de routage, le routeur peut redémarrer normalement avec l’aide de ses voisins. RSVP présente un objet RSVP RESTART (Restart Cap object) dans des messages hello dans lesquels les temps de redémarrage et de récupération sont spécifiés (aucune valeur n’est 0).

  • Si vous désactivez explicitement le redémarrage progressif RSVP au niveau de la [protocols rsvp] hiérarchie, l’objet Redémarrage du cap est annoncé avec le redémarrage et les temps de récupération spécifiés comme 0. Le redémarrage des routeurs voisins est pris en charge (sauf si le mode d’assistance est désactivé), mais le routeur lui-même ne conserve pas l’état de transfert RSVP et ne peut pas récupérer son état de contrôle.

  • Si, après le redémarrage, RSVP réalise qu’aucun état de transfert n’a été conservé, l’objet Cap redémarrage est annoncé avec des temps de redémarrage et de récupération spécifiés comme 0.

  • Si le redémarrage progressif et le mode d’assistance sont désactivés, le redémarrage progressif RSVP est totalement désactivé. Le routeur ne reconnaît ni ne présente les objets de redémarrage progressif RSVP.

Vous ne pouvez pas configurer explicitement les valeurs pour les temps de redémarrage et de récupération.

Contrairement à d’autres protocoles, il n’existe aucun moyen pour RSVP de déterminer qu’il a terminé une procédure de redémarrage, à l’exception d’un délai d’arrêt fixe. Toutes les procédures de redémarrage progressif RSVP sont basées sur des délais. Une show rsvp version commande peut indiquer que le redémarrage est toujours en cours même si toutes les sessions RSVP sont rétablies et que les routes sont rétablies.

Traitement de l’objet Cap Restart

Les hypothèses suivantes sont formulées à propos d’un voisin en fonction de l’objet Restart Cap (en supposant qu’une défaillance du canal de contrôle peut être distinguée sans ambiguïté d’un redémarrage de nœud) :

  • Un voisin qui ne fait pas la publicité de l’objet Restart Cap dans ses messages hello ne peut pas aider un routeur avec l’état ou la récupération d’étiquettes, et il ne peut pas non plus effectuer un redémarrage progressif RSVP.

  • Après un redémarrage, un voisin faisant la publicité d’un objet Restart Cap avec un temps de redémarrage égal à toute valeur et un temps de récupération égal à 0 n’a pas conservé son état de transfert. Lorsqu’un temps de récupération est égal à 0, le voisin est considéré comme mort et les états liés à ce voisin sont purgés, quelle que soit la valeur du temps de redémarrage.

  • Après un redémarrage, un voisin faisant la publicité de son temps de récupération avec une valeur autre que 0 peut conserver ou a conservé l’état de transfert. Si le routeur local aide son voisin avec des procédures de redémarrage ou de récupération, il envoie un objet Recover Label à ce voisin.

Configuration du redémarrage progressif RSVP

Les configurations de redémarrage progressif RSVP suivantes sont possibles :

  • Le redémarrage progressif et le mode d’assistance sont tous deux activés (par défaut).

  • Le redémarrage progressif est activé, mais le mode d’assistance est désactivé. Un routeur configuré de cette façon peut redémarrer correctement, mais ne peut pas aider un voisin avec ses procédures de redémarrage et de récupération.

  • Le redémarrage progressif est désactivé, mais le mode d’assistance est activé. Un routeur configuré de cette façon ne peut pas redémarrer correctement, mais peut aider un voisin de redémarrage.

  • Le redémarrage progressif et le mode d’assistance sont tous deux désactivés. Cette configuration désactive complètement le redémarrage progressif RSVP (y compris les procédures de redémarrage et de récupération et le mode d’assistance). Le routeur se comporte comme un routeur qui ne prend pas en charge le redémarrage progressif RSVP.

Remarque :

Pour activer le redémarrage progressif RSVP, vous devez définir le délai global de redémarrage progressif sur au moins 180 secondes.

Les sections suivantes décrivent comment configurer le redémarrage progressif RSVP :

Activation du redémarrage progressif pour tous les protocoles de routage

Pour activer le redémarrage progressif pour RSVP, vous devez activer le redémarrage progressif pour tous les protocoles qui prennent en charge le redémarrage progressif sur le routeur. Pour plus d’informations sur le redémarrage progressif, consultez la bibliothèque des protocoles de routage Junos OS pour les équipements de routage.

Pour activer le redémarrage progressif sur le routeur, indiquez :graceful-restart

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit routing-options]

  • [edit logical-systems logical-system-name routing-options]

Désactivation du redémarrage progressif pour RSVP

Par défaut, le redémarrage progressif RSVP et le mode d’assistance RSVP sont activés lorsque vous activez le redémarrage progressif. Vous pouvez toutefois désactiver l’une de ces fonctionnalités ou les deux.

Pour désactiver le redémarrage progressif et la récupération RSVP, incluez l’instruction disable au niveau de la [edit protocols rsvp graceful-restart] hiérarchie :

Désactivation du mode d’assistance RSVP

Pour désactiver le mode d’assistance RSVP, incluez l’instruction helper-disable au niveau de la [edit protocols rsvp graceful-restart] hiérarchie :

Configuration du temps maximal de récupération de l’assistance

Pour configurer le temps que le routeur conserve l’état de ses voisins RSVP pendant qu’ils subissent un redémarrage progressif, incluez l’instruction maximum-helper-recovery-time au niveau de la [edit protocols rsvp graceful-restart] hiérarchie. Cette valeur est appliquée à tous les routeurs voisins. Elle doit donc être basée sur le temps requis par le voisin RSVP le plus lent à récupérer.

Configuration du temps maximal de redémarrage du helper

Pour configurer le délai entre le moment où le routeur découvre qu’un routeur voisin a diminué et quand il déclare le voisin en bas, incluez l’instruction maximum-helper-restart-time au niveau de la [edit protocols rsvp graceful-restart] hiérarchie. Cette valeur est appliquée à tous les routeurs voisins. Elle doit donc être basée sur le temps requis par le voisin RSVP le plus lent à redémarrer.

Présentation des tunnels LSP RSVP

Un tunnel de chemin de commutation d’étiquettes (LSP) RSVP (Resource Reservation Protocol) vous permet d’envoyer des LSP RSVP à l’intérieur d’autres LSP RSVP. Un administrateur réseau peut ainsi fournir les aspects techniques du trafic d’un bout à l’autre du réseau. Une application utile pour cette fonctionnalité consiste à connecter les routeurs de périphérie du client (CE) aux routeurs de périphérie du fournisseur (PE) à l’aide d’un LSP RSVP, puis à tunnelner ce LSP de périphérie au sein d’un deuxième RSVP LSP voyageant à travers le cœur du réseau.

Vous devriez avoir une compréhension générale des concepts MPLS et de commutation d’étiquettes. Pour plus d’informations sur MPLS, consultez le Junos MPLS Applications Configuration Guide.

Un tunnel LSP RSVP ajoute le concept d’adjacence de transfert, semblable à celui utilisé pour la commutation d’étiquettes multiprotocole généralisée (GMPLS). (Pour plus d’informations sur GMPLS, consultez junos GMPLS User Guide.

L’adjacence de transfert crée un chemin tunnelisé pour envoyer des données entre les équipements pairs dans un réseau LSP RSVP. Une fois qu’un LSP d’adjacence de transfert (FA-LSP) a été établi, d’autres LSP peuvent être envoyés par l’intermédiaire de FA-LSP à l’aide de CSPF (Constrained Shortest Path First), de LMP (Link Management Protocol), d’Open Shortest Path First (OSPF) et de RSVP.

Pour activer un tunnel LSP RSVP, junos OS utilise les mécanismes suivants :

  • LMP : initialement conçu pour GMPLS, LMP établit des proximités de transfert entre les pairs de tunnels LSP RSVP, et gère et alloue les ressources pour les liaisons d’ingénierie de trafic.

  • Extensions OSPF : OSPF a été conçu pour acheminer les paquets vers des interfaces physiques et logiques liées à une carte d’interface physique (PIC). Ce protocole a été étendu pour acheminer les paquets vers des interfaces virtuelles homologues définies dans une configuration LMP.

  • Extensions RSVP-TE — RSVP-TE a été conçu pour signaler la configuration des LSP de paquets aux interfaces physiques. Le protocole a été étendu pour demander la configuration de chemin pour les LSP de paquets voyageant vers des interfaces virtuelles homologues définies dans une configuration LMP.

    Remarque :

    À partir de Junos OS Version 15.1, la prise en charge multi-instances est étendue à MPLS RSVP-TE. Cette prise en charge est disponible uniquement pour le type d’instance du routeur virtuel. Un routeur peut créer et participer à plusieurs partitions de topologie TE indépendantes, ce qui permet à chaque domaine TE partitionné d’évoluer indépendamment. Le RSVP-TE multi-instance offre la flexibilité nécessaire pour sélectionner manuellement les entités du plan de contrôle qui doivent être orientées instance. Par exemple, un routeur peut participer à plusieurs instances TE tout en exécutant une seule instance BGP.

    L’implémentation junos OS de MPLS RSVP-TE est mise à l’échelle afin d’améliorer la convivialité, la visibilité, la configuration et le dépannage des LSP dans Junos OS version 16.1.

    Ces améliorations facilitent la configuration RSVP-TE à grande échelle en :

    • Assurez-vous que le plan de données LSP est bien prêt lors de l’abandon du LSP avant que le trafic ne passe par le LSP avec le mécanisme d’auto-ping RSVP-TE LSP.

      Une LSP ne doit pas commencer à transporter le trafic à moins qu’il n’ait été programmé dans le plan de données. L’échange de données dans le plan de données LSP, comme les requêtes ping LSP, se produit au niveau du routeur d’entrant avant de basculer le trafic vers un LSP ou vers son instance MBB. Dans les grands réseaux, ce trafic peut submerger un routeur de sortie LSP, car le LSP de sortie doit répondre aux requêtes ping LSP. Le mécanisme d’auto-ping LSP permet au LER entrant de créer des messages de réponse ping LSP et de les envoyer via le plan de données LSP. À la réception de ces messages, le LER sortant les transmet à l’entrée, indiquant la ligne de liaison du plan de données LSP. Cela garantit que le LSP ne commence pas à transporter le trafic avant que le plan de données ait été programmé.

    • Suppression de la limite de 64 K LSP actuelle sur un routeur d’entrée et évolutivité du nombre total de LSP avec LSP à signalisation RSVP-TE. Il peut y avoir jusqu’à 64 K LSP configurés par sortie. Auparavant, cette limite correspondait au nombre agrégé de LSP pouvant être configurés sur le LER entrant.

    • Prévention de la suppression abrupte des LSP par le routeur d’entrée en raison du retard dans la signalisation du LSP au niveau des routeurs de transit.

    • Permettre une vue flexible des ensembles de données LSP pour faciliter la visualisation des données caractéristiques de LSP.

    Remarque :

    À partir de Junos OS Version 17.4, un minuteur par défaut de 1 800 secondes pour l’auto-ping est introduit.

Les limites suivantes existent pour les hiérarchies LSP :

  • Les LSP basés sur circuits trans-connect (CCC) ne sont pas pris en charge.

  • Le redémarrage progressif n’est pas pris en charge.

  • La protection des liaisons n’est pas disponible pour les FA-LSP ou au point de sortie de l’adjacence de transfert.

  • Les LSP point à multipoint ne sont pas pris en charge dans les FA-LSP.

Exemple : RSVP LSP Tunnel Configuration

Figure 5 : Schéma de la topologie du tunnel LSP RSVPSchéma de la topologie du tunnel LSP RSVP

Figure 5 affiche une LSP RSVP de bout en bout, appelée e2e_lsp_r0r5 « source » du routeur 0 et qui se termine sur le routeur 5. En transit, ce LSP traverse le FA-LSP fa_lsp_r1r4. Le chemin de retour est représenté par le RSVP LSP e2e_lsp_r5r0 de bout en bout qui passe par le FA-LSP fa_lsp_r4r1.

Sur le routeur 0, configurez le RSVP LSP de bout en bout qui se déplace vers le routeur 5. Utilisez un chemin strict qui traverse le routeur 1 et la liaison technique de trafic LMP qui se déplace du routeur 1 au routeur 4.

Routeur 0

Sur le routeur 1, configurez un FA-LSP pour atteindre le routeur 4. Établissez une liaison d’ingénierie de trafic LMP et une relation d’appairage LMP avec le routeur 4. Référencez la FA-LSP dans la liaison d’ingénierie de trafic et ajoutez l’interface d’appairage à OSPF et RSVP.

Lorsque le chemin de retour de bout en bout LSP arrive au routeur 1, la plate-forme de routage effectue une recherche de routage et peut transférer le trafic vers le routeur 0. Assurez-vous de configurer OSPF correctement entre les routeurs 0 et 1.

Routeur 1

Sur le routeur 2, configurez OSPF, MPLS et RSVP sur toutes les interfaces qui transportent les FA-LSP sur le réseau central.

Routeur 2

Sur le routeur 3, configurez OSPF, MPLS et RSVP sur toutes les interfaces qui transportent les FA-LSP sur le réseau central.

Routeur 3

Sur le routeur 4, configurez un chemin de retour FA-LSP pour atteindre le routeur 1. Établissez une liaison d’ingénierie de trafic LMP et une relation d’appairage LMP avec le routeur 1. Référencez la FA-LSP dans la liaison d’ingénierie de trafic et ajoutez l’interface d’appairage à OSPF et RSVP.

Lorsque le LSP initial de bout en bout arrive au routeur 4, la plate-forme de routage effectue une recherche de routage et peut transférer le trafic vers le routeur 5. Assurez-vous de configurer OSPF correctement entre le routeur 4 et le routeur 5.

Routeur 4

Sur le routeur 5, configurez le chemin de retour de bout en bout RSVP LSP qui se déplace vers le routeur 0. Utilisez un chemin strict qui traverse le routeur 4 et la liaison d’ingénierie de trafic LMP qui se déplace du routeur 4 au routeur 1.

Routeur 5

Vérifier votre travail

Pour vérifier que votre tunnel LSP RSVP fonctionne correctement, émettez les commandes suivantes :

  • show ted database (extensive)

  • show rsvp session name (extensive)

  • show link-management

  • show link-management te-link name (detail)

Pour voir ces commandes utilisées avec l’exemple de configuration, reportez-vous aux sections suivantes :

Routeur 0

Sur le routeur 0, vous pouvez vérifier que les FA-LSP apparaissent comme des chemins valides dans la base de données des aspects techniques du trafic. Dans ce cas, recherchez les chemins du routeur 1 (10.255.41.216) et du routeur 4 (10.255.41.217) qui renvoient aux adresses de liens LMP relatives aux aspects techniques du trafic de 172.16.30.1 et 172.16.30.2. Vous pouvez également émettre la commande pour rechercher le chemin du LSP de bout en bout à mesure qu’il se déplace vers le show rsvp session extensive routeur 5 via le FA-LSP.

Routeur 1

Sur le routeur 1, vérifiez que votre configuration de liaison LMP traffic engineering fonctionne et que le LSP de bout en bout traverse le lien aspects techniques du trafic en émettant l’ensemble show link-management de commandes. Vous pouvez également émettre la show rsvp session extensive commande pour confirmer que le FA-LSP est opérationnel.

Configuration des interfaces pairs dans OSPF et RSVP

Une fois que vous avez établi des pairs LMP, vous devez ajouter des interfaces homologues à OSPF et RSVP. Une interface d’appairage est une interface virtuelle utilisée pour prendre en charge l’adjacence de contrôle entre deux pairs.

Le nom de l’interface pair doit correspondre à l’instruction peer peer-name configurée dans LMP au niveau de la [edit protocols link-management] hiérarchie. Étant donné que les paquets de protocole réels sont envoyés et reçus par les interfaces pairs, ces interfaces peuvent être signalés et annoncés à des pairs, comme n’importe quelle autre interface physique configurée pour OSPF et RSVP. Pour configurer le routage OSPF pour les pairs LMP, incluez l’instruction peer-interface au niveau de la [edit protocols ospf area area-number] hiérarchie. Pour configurer la signalisation RSVP pour les pairs LMP, incluez l’instruction peer-interface au niveau de l’architecture [edit protocols rsvp] de base.

Définir des chemins de commutation d’étiquettes pour le FA-LSP

Ensuite, définissez votre FA-LSP en incluant l’instruction label-switched-path au niveau de la [edit protocols mpls] hiérarchie. Incluez l’ID de routeur de l’pair dans l’énoncé to au niveau de la [edit protocols mpls label-switched-path] hiérarchie. Étant donné que les LSP de paquets sont unidirectionnels, vous devez créer un FA-LSP pour atteindre l’pair et un deuxième FA-LSP pour revenir de l’pair.

Définition des informations de chemin FA-LSP

Lorsque vous configurez des chemins LSP explicites pour un FA-LSP, vous devez utiliser l’adresse distante du lien d’ingénierie de trafic comme adresse du prochain saut. Lorsque CSPF est pris en charge, vous pouvez utiliser n’importe quelle option de chemin que vous souhaitez. Toutefois, lorsque CSPF est désactivé avec l’instruction no-cspf au niveau de la [edit protocols mpls label-switched-path lsp-name] hiérarchie, vous devez utiliser des chemins stricts.

Remarque :

Si le LSP de bout en bout est originaire de la même plate-forme de routage que fa-LSP, vous devez désactiver CSPF et utiliser des chemins stricts.

Option: Déchirer les LSP RSVP avec élégance

Vous pouvez retirer un LSP RSVP en deux étapes qui retire normalement la session RSVP utilisée par le LSP. Pour tous les voisins qui prennent en charge le démontage gratieux, une demande de démontage est envoyée par la plate-forme de routage au point de terminaison de destination pour le LSP et tous les voisins RSVP du chemin. La requête est incluse dans le ADMIN_STATUS champ du paquet RSVP. Lorsque les voisins reçoivent la demande, ils se préparent pour que la session RSVP soit retirée. Un deuxième message est envoyé par la plate-forme de routage pour terminer le démontage de la session RSVP. Si un voisin ne prend pas en charge le démontage gratieux, la requête est traitée comme un démontage de session standard plutôt que comme un déchirure gracieuse.

Pour effectuer un démontage gratieux d’une session RSVP, exécutez la clear rsvp session gracefully commande. Vous pouvez éventuellement spécifier l’adresse source et de destination de la session RSVP, l’identifiant LSP de l’expéditeur RSVP et l’identifiant de tunnel de la session RSVP. Pour utiliser ces qualificatifs, incluez les connection-source, lsp-idconnection-destinationet tunnel-id les options lorsque vous délivrez la clear rsvp session gracefully commande.

Vous pouvez également configurer la durée pendant laquelle la plate-forme de routage attend que les voisins reçoivent la demande de déchirure avant d’initier le démontage réel en incluant l’instruction graceful-deletion-timeout au niveau de la [edit protocols rsvp] hiérarchie. La valeur de délai d’expiration de suppression par défaut est de 30 secondes, avec une valeur minimale de 1 seconde et une valeur maximale de 300 secondes. Pour afficher la valeur actuelle configurée en vue d’un délai d’expiration de suppression rapide, émettre la commande mode show rsvp version opérationnel.

Tableau de l'historique des versions
Version
Description
19.4R1
16.1
Toutefois, à partir de la version 16.1 de Junos OS, lorsque les messages RSVP hello sont supprimés, les sessions RSVP sont indisponibles.