RSVP Configuration

Pour activer RSVP sur une seule interface, incluez l’instruction et spécifiez l’interface à l’aide de l’instruction rsvpinterface . Il s’agit de la configuration minimale de RSVP. 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é les propriétés de l’interface sur un groupe d’interfaces et que vous souhaitez désactiver RSVP sur l’une des interfaces, incluez l’instruction disable suivante :

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 ]

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 à la fois 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 au niveau de label-switched-path la [edit protocols mpls] hiérarchie. Chaque LSP se traduit par une demande de RSVP pour initier une session RSVP. Cette demande est transmise via l’interface interne entre la commutation d’étiquettes et RSVP. Après avoir examiné les informations de la demande, vérifié les états de RSVP et vérifié les tables de routage locales, 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. En cas d’échec de la session RSVP, celui-ci informe MPLS de son état. C’est à MPLS d’initier des chemins de sauvegarde ou de continuer à réessayer le chemin initial.

Pour transmettre les informations de signalisation de commutation d’étiquettes, RSVP prend en charge quatre objets supplémentaires : Objet Label Request, Label object, Explicit Route et Record Route object. Pour qu’un LSP puisse être correctement configuré, tous les routeurs le long du chemin doivent prendre en charge MPLS, RSVP et les quatre objets. Des quatre objets, l’objet Record Route n’est pas obligatoire.

Pour configurer MPLS et en faire un client de RSVP, procédez comme suit :

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

• Activez 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 les chemins de commutation d’étiquettes (LSP) RSVP afin d’utiliser une métrique de délai pour calculer le chemin. Pour configurer, utilisez les options CLI que nous avons introduites sous la [edit protocols mpls label-switched-path name] hiérarchie.

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

• Configuration de la réduction de l’actualisation RSVP
• Configuration de l’intervalle RSVP Hello
• Configuration de l’authentification RSVP
• Configuration de l’abonnement de bande passante pour les types de cours
• Configuration du seuil de mise à jour RSVP sur une interface
• Configuration de RSVP pour les interfaces non numérotées

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

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 protocoles BGP et VPN MPLS, tous les routeurs PE existants doivent être configurés pour être appairés avec le nouveau routeur PE pour BGP et MPLS. Chaque nouveau routeur PE étant ajouté au réseau du fournisseur de services, la charge de configuration devient vite trop lourde.

Les exigences de configuration pour l’appairage BGP peuvent être réduites à l’aide de réflecteurs de route. Dans les réseaux MPLS avec signal RSVP, le maillage automatique RSVP peut minimiser 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 lorsqu’un nouveau routeur PE est ajouté.

Par défaut, lorsque vous avez configuré plusieurs LSP RSVP sur le même routeur de sortie, le LSP avec la métrique la plus basse est sélectionné et transporte tout le trafic. Si tous les LSP ont la même métrique, l’un d’eux est sélectionné au hasard et tout le trafic est transféré via celui-ci.

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

Pour activer l’équilibrage de charge par paquet sur un LSP entrant, 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 réparti équitablement entre les LSP (par défaut).

Vous devez configurer l’équilibrage de charge par paquet si vous souhaitez activer le reroutage rapide PFE. Pour activer le reroutage rapide PFE, incluez l’instruction d’équilibrage policy-statement de charge par paquet indiquée dans cette section dans la configuration de chacun des routeurs sur lesquels un reroutage peut avoir lieu. Reportez-vous également à la section Configuration du routage rapide.

Vous pouvez également équilibrer la charge du trafic entre les LSP proportionnellement à la quantité de bande passante configurée pour chaque LSP. Cette fonctionnalité permet de mieux répartir le trafic sur les réseaux dotés de capacités de bande passante asymétrique sur les liens 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 RSVP LSP, incluez l’instruction avec l’option load-balancebandwidth :

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

• [edit protocols rsvp]

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

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

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

• L’instruction load-balance s’applique uniquement aux LSP entrants pour lesquels l’équilibrage de charge par paquet est activé.

• Pour les LSP orientés services différenciés, la bande passante d’un LSP est calculée en additionnant la bande passante de tous les types de classes.

RSVP utilise deux paramètres de minutage associés :

• refresh-time: la durée 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 l’instruction refresh-time de 30, multipliée par une valeur fixe de 1,5. Ce calcul diffère de la RFC 2205, qui stipule 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 les messages Path et Resv. Les messages d’actualisation sont envoyés périodiquement afin que les états de réservation dans les nœuds voisins n’expirent pas. Chaque chemin d’accès et message Resv porte la valeur du minuteur d’actualisation, et le nœud récepteur extrait cette valeur des messages.

• keep-multiplier: le multiplicateur keep est un petit entier configuré localement compris entre 1 et 255. La valeur par défaut est 3. Il indique le nombre de messages qui peuvent être perdus avant qu’un état particulier ne soit déclaré obsolète et doive être supprimé. Le multiplicateur 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 d’actualisation successifs doivent être perdus avant qu’un état de réservation ne soit supprimé.

Nous vous déconseillons de configurer un minuteur RSVP hello court. Si la détection rapide d’un voisin défaillant est nécessaire, configurez des temporisateurs Hello IGP courts (OSPF ou IS-IS).

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

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 conservation est de 3. Pour modifier cette valeur, incluez l’instruction keep-multiplier suivante :

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

• [edit protocols rsvp]

• [edit logical-systems logical-system-name protocols 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 n’est préemptée que par une nouvelle session de priorité supérieure.

Pour toujours préempter une session lorsque la bande passante est insuffisante, incluez l’instruction avec l’option preemptionaggressive :

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 avec l’option preemptiondisabled :

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

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

• [edit protocols rsvp]

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

Pour configurer la signalisation MTU (Maximum Transmission Unit) dans RSVP, vous devez configurer MPLS afin d’autoriser 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 suivante :

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
• Activation de la fragmentation des paquets

Vous pouvez contrôler la valeur d’étiquette annoncée sur le routeur de sortie d’un LSP. L’étiquette annoncée par défaut est l’étiquette 3 (étiquette nulle implicite). Si l’étiquette 3 est annoncée, le routeur à l’avant-dernier saut enlève l’étiquette et envoie le paquet au routeur de sortie. Lorsque l’popping ultimate-hop est activé, l’étiquette 0 (étiquette IP version 4 [IPv4] Explicit Null) est publiée. L’popping par saut ultime garantit que tous les paquets qui traversent un réseau MPLS incluent une étiquette.

Pour configurer l’affichage contextuel de saut ultime pour RSVP, incluez l’instruction explicit-null suivante :

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

• [edit protocols mpls]

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

Par défaut, pour les LSP point à point et point à multipoint, l’popping par avant-dernier saut est utilisé pour le trafic MPLS. Les étiquettes MPLS sont supprimées des paquets sur le routeur juste avant le routeur de sortie du LSP. Les paquets IP simples sont ensuite transmis au routeur de sortie. Pour l’éclatement par saut ultime, le routeur de sortie est responsable à la fois de la suppression de l’étiquette MPLS et du traitement du paquet IP brut.

Il peut être avantageux d’activer l’popping par saut ultime sur les LSP point à multipoint, en particulier lorsque le trafic de transit traverse le même périphérique de sortie. Si vous activez l’option popping par saut ultime, une seule copie du trafic peut être envoyée sur la liaison entrante, ce qui permet d’économiser beaucoup de bande passante. Par défaut, l’éclatement du saut ultime est désactivé.

Vous activez l’apparition de sauts ultimes pour les LSP point à multipoint en configurant l’instruction tunnel-services . Lorsque vous activez le popping par saut ultime, Junos OS sélectionne l’une des interfaces VT 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 effectué automatiquement. Le contrôle d’admission de bande passante permet de limiter le nombre de LSP pouvant être utilisés sur une interface VT. Une fois toute la bande passante consommé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 plus de bande passante que ce qui est disponible à partir de l’une des interfaces VT, l’apparition de sauts ultimes ne peut pas être activée et l’apparition de sauts d’avant-dernière est activée à la place.

Pour que l’apparition de sauts ultimes sur les LSP point à multipoint fonctionne correctement, le routeur de sortie doit disposer d’un CIP qui fournit des services de tunnel, tels que le PIC des services de tunnel ou le PIC des services adaptatifs. Des services de tunnel sont nécessaires pour l’affichage de l’étiquette MPLS finale et pour le renvoi des paquets pour les recherches d’adresses IP.

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

Pour activer l’apparition popping par saut ultime pour les LSP point à multipoint de sortie 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 l’apparition de sauts ultimes pour les LSP point à multipoint sortants, vous devez également configurer l’instruction avec l’option interfaceall :

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

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

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 pour spécifier le nom du fichier qui reçoit la sortie de l’opération file de suivi. Tous les fichiers sont placés dans le répertoire /var/log. Nous vous recommandons de placer la sortie de suivi RSVP dans le fichier rsvp-log.

• all—Toutes les opérations de suivi.

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

• event—Événements liés à RSVP (aide à tracer les événements liés au redémarrage progressif de RSVP)

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

• packets—Tous les paquets RSVP

• path—Tous les messages de chemin

• pathtear—Messages PathTear

• resv—Messages 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 descendent.

Pour afficher le fichier journal généré lorsque vous activez les traceoptions RSVP, exécutez la show log file-name commande where file-name is the file you spécifié à l’aide de l’instruction traceoptions .

Pour obtenir des informations générales sur le suivi et les options de suivi global, reportez-vous à la bibliothèque de protocoles de routage de Junos OS pour les périphériques de routage.

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

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

• RSVP Norme de redémarrage progressif

• RSVP Terminologie du redémarrage progressif

• RSVP Opération de redémarrage progressif

• Traitement de l’objet Capuchon de redémarrage

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

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

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

• Le mode d’assistance au redémarrage progressif RSVP doit être activé sur les routeurs voisins, ce qui leur permet d’assister un routeur qui tente de redémarrer RSVP.

Un objet appelé Restart Cap qui est envoyé dans les messages RSVP hello annonce la capacité de redémarrage d’un nœud. Le noeud voisin envoie un objet Recover Label au noeud qui redémarre pour récupérer son état de transfert. Cet objet est essentiellement l’ancienne étiquette annoncée par le noeud de redémarrage avant que le noeud ne tombe en panne.

Voici la liste des 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 sous la configuration de l’instance de routage, le routeur peut redémarrer correctement avec l’aide de ses voisins. RSVP annonce un objet Restart Cap (RSVP RESTART) dans les 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 sous le niveau hiérarchique [protocols rsvp] , l’objet Restart Cap est annoncé avec les temps de redémarrage et de récupération spécifiés sur 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 un redémarrage, RSVP se rend compte qu’aucun état de transfert n’a été conservé, l’objet Restart Cap est annoncé avec les temps de redémarrage et de récupération spécifiés sur 0.

• Si le redémarrage progressif et le mode d’assistance sont désactivés, le redémarrage progressif RSVP est complètement désactivé. Le routeur ne reconnaît ni n’annonce les objets de redémarrage gracieux RSVP.

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

Contrairement à d’autres protocoles, il n’y a aucun moyen pour RSVP de déterminer qu’il a terminé une procédure de redémarrage, autre qu’un délai d’expiration fixe. Toutes les procédures de redémarrage progressif RSVP sont basées sur une minuterie. Une show rsvp version commande peut indiquer que le redémarrage est toujours en cours même si toutes les sessions RSVP sont sauvegardées et que les routes sont restaurées.

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 puisse être distinguée sans ambiguïté d’un redémarrage de nœud) :

• Un voisin qui n’annonce pas l’objet Restart Cap dans ses messages hello ne peut pas aider un routeur à récupérer l’état ou l’étiquette, ni effectuer un redémarrage progressif RSVP.

• Après un redémarrage, un voisin publiant un objet Restart Cap avec une heure de redémarrage égale à n’importe quelle 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 tous les états associés à ce voisin sont purgés, quelle que soit la valeur de l’heure de redémarrage.

• Après un redémarrage, un voisin annonçant 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 les procédures de redémarrage ou de récupération, il envoie un objet Recover Label à ce voisin.

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

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

• Le redémarrage progressif est activé, mais le mode d’assistance est désactivé. Un routeur configuré de cette manière peut redémarrer correctement, mais ne peut pas aider un voisin dans 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 manière ne peut pas redémarrer correctement, mais peut aider un voisin qui redémarre.

• 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 normal RSVP.

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

• Activation du redémarrage progressif pour tous les protocoles de routage
• Désactivation du redémarrage progressif pour RSVP
• Désactivation du mode d’assistance RSVP
• Configuration du temps maximal de récupération de l’assistant
• Configuration du temps maximal de redémarrage de l’assistant

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. Cela permet à un administrateur réseau de fournir des fonctions techniques de trafic d’un bout à l’autre du réseau. Une application utile de cette fonctionnalité consiste à connecter des routeurs CE (Customer Edge) à des routeurs PE (Provider Edge) à l’aide d’un LSP RSVP, puis à tunneliser ce LSP Edge à l’intérieur d’un deuxième LSP RSVP traversant le cur du réseau.

Vous devez avoir une compréhension générale des concepts MPLS et commutation d'étiquettes. Pour plus d’informations sur MPLS, reportez-vous au Guide de configuration des applications MPLS Junos.

Un tunnel LSP RSVP ajoute le concept d’adjacence de transfert, similaire à celui utilisé pour la commutation d’étiquette multiprotocole généralisée (GMPLS). (Pour plus d’informations sur GMPLS, reportez-vous au Guide de l’utilisateur Junos GMPLS.

La contiguïté de transfert crée un chemin tunnelisé pour l’envoi de données entre les appareils homologues d’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 via le FA-LSP en utilisant Constrained Shortest Path First (CSPF), Link Management Protocol (LMP), Open Shortest Path First (OSPF) et RSVP.

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

• LMP : conçu à l’origine pour GMPLS, le LMP établit des contiguïtés de transfert entre les homologues de tunnel LSP RSVP, et gère et alloue les ressources pour les liaisons d’ingénierie du trafic.

• Extensions OSPF : l’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 homologues virtuelles définies dans une configuration LMP.

• Extensions RSVP-TE : RSVP-TE a été conçu pour signaler la configuration de LSP de paquets aux interfaces physiques. Le protocole a été étendu pour permettre l’établissement d’un chemin de requête pour les LSP de paquets voyageant vers des interfaces homologues virtuelles définies dans une configuration LMP.

  REMARQUE :

  À partir de Junos OS version 15.1, la prise en charge multi-instance est étendue à MPLS RSVP-TE. Cette prise en charge est disponible uniquement pour le type d’instance de routeur virtuel. Un routeur peut créer et participer à plusieurs partitions de topologie TE indépendantes, ce qui permet à chaque domaine TE partitionné de se développer indépendamment. RSVP-TE multi-instance offre la flexibilité nécessaire pour sélectionner manuellement les entités de plan de contrôle qui doivent être sensibles aux instances. 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 a été mise à l’échelle pour 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 :

  • Garantir la disponibilité du plan de données du LSP lors de la resignalisation du LSP avant que le trafic ne traverse le LSP grâce au mécanisme d’auto-ping RSVP-TE LSP.

    Un LSP ne doit pas commencer à transporter du trafic à moins que l’on sache qu’il a été programmé dans le plan de données. L’échange de données dans le plan de données LSP, comme les demandes ping LSP, se produit au niveau du routeur 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 sortant doit répondre aux demandes 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 sur le plan de données LSP. À la réception de ces messages, le LER de sortie les transmet à l’entrée, ce qui indique la vivacité du plan de données LSP. Cela permet de s’assurer que le LSP ne commence pas à transporter le trafic avant que le plan de données n’ait été programmé.

  • Suppression de la limite stricte actuelle de 64K LSP sur un routeur entrant et mise à l’échelle du nombre total de LSP avec LSP signalés RSVP-TE. Jusqu’à 64 000 LSP peuvent être configurés par sortie. Auparavant, cette limite correspondait au nombre total de LSP pouvant être configurés sur le LER entrant.

  • Empêcher le démantèlement brutal des LSP par le routeur entrant en raison d’un retard dans la signalisation du LSP sur les routeurs de transit.

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

  REMARQUE :

  À partir de la version 17.4 de Junos OS, un minuteur par défaut de 1800 secondes pour l’auto-ping est introduit.

Les hiérarchies LSP sont soumises aux limitations suivantes :

• Les LSP basés sur la connexion croisée de circuit (CCC) ne sont pas pris en charge.

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

• La protection de liaison n’est pas disponible pour les FA-LSP ou au point de sortie de la contiguïté de transfert.

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

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

Figure 5 affiche un LSP RSVP appelé de e2e_lsp_r0r5 bout en bout qui commence sur le routeur 0 et 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 LSP RSVP de bout en bout qui se déplace sur le FA-LSP e2e_lsp_r5r0fa_lsp_r4r1.

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

Routeur 0

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

Lorsque le LSP de bout en bout du chemin de retour 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 correctement OSPF 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. Établir un lien d’ingénierie de trafic LMP et une relation d’homologue LMP avec le routeur 1. Référencez le FA-LSP dans le lien d’ingénierie du trafic et ajoutez l’interface homologue dans 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 correctement OSPF entre le routeur 4 et le routeur 5.

Routeur 4

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

Routeur 5