Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

RSVP Configuration

Configuration RSVP minimale

Pour activer RSVP sur une interface unique, inclure l’instruction et rsvp spécifier l’interface à l’aide de interface l’énoncé. Il s’agit de la configuration RSVP minimale. Tous les autres énoncés de configuration RSVP sont facultatifs.

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, remplacer 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, indiquez disable l’instruction:

Vous pouvez inclure cet énoncé aux niveaux hiérarchiques suivants:

  • [edit protocols rsvp interface interface-name ]

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

Configuration des configurations RSVP et MPLS

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

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

Lorsqu’une session RSVP est créée avec succès, le LSP est mis en place le long des chemins créés par la session RSVP. En cas d’échec de la session RSVP, RSVP en MPLS son statut. Il est temps de MPLS lancer des chemins de secours ou de continuer à réessayer le chemin initial.

Pour transmettre des informations de signalisation de commutation d’étiquettes, RSVP prend en charge quatre objets supplémentaires: Objet de demande d’étiquette, objet d’étiquette, objet de route explicite et objet de route d’enregistrement. Pour réussir la mise en place d’un LSP, tous les routeurs 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 client RSVP, faites les opérations suivantes:

  • Activez MPLS sur tous les routeurs qui participeront à la commutation d’étiquettes (c’est-à-dire sur tous les routeurs qui peuvent 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.

Exemple: Configuration des configurations RSVP et MPLS

Les exemples de configuration d’un routeur au début d’un LSP sont illustrés ci-dessous:

Les exemples de configuration de tous les autres routeurs qui forment le LSP sont illustrés ci-dessous:

Configuration des interfaces RSVP

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

Configuration de la réduction de la actualisation 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 —Activer toutes les fonctionnalités de réduction de la actualisation reliable RSVP: Groupage de messages RSVP, ID de message RSVP, diffusion fiable des messages et actualisation de résumé.

    Pour actualiser la formation et assurer une diffusion fiable, vous devez inclure aggregate les reliable déclarations et les énoncés.

  • no-aggregate—Désactivez le groupage de messages RSVP et la actualisation de résumé.

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

Pour plus d’informations sur la réduction de la actualisation RSVP, consultez le site RSVP Refresh Reduction.

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

Toutefois, toutes les combinaisons entre deux voisins avec des capacités de réduction d’actualisation différentes ne fonctionnent pas correctement. Par exemple, un routeur est configuré avec l’énoncé et l’énoncé, aggregateno-reliable ou avec les reliableno-aggregate instructions et les instructions. Si un voisin RSVP envoie un objet Summary Refresh à ce routeur, aucune erreur n’est générée, mais l’objet Actualiser la synthèse ne peut pas être traitée. Par conséquent, les états RSVP peuvent prendre du temps sur ce routeur si le voisin s’appuie uniquement sur Summary Refresh pour actualiser ces états RSVP.

Sauf exigence spécifique, nous vous recommandons de configurer la réduction de la actualisation RSVP de la même manière sur chaque voisin RSVP.

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

Vous pouvez inclure cet énoncé 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 le groupage de messages RSVP et la mise à jour de résumé, inclure no-aggregate l’instruction:

Vous pouvez inclure cet énoncé 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 la diffusion fiable des messages sur une interface, indiquez reliable l’instruction:

Vous pouvez inclure cet énoncé 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, une diffusion fiable des messages et une actualisation de résumé, inclure no-reliable l’instruction:

Vous pouvez inclure cet énoncé 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 la actualisation des voisins RSVP

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

  • Le bit RR annoncé par le voisin

  • La configuration locale de la remise à niveau RSVP

  • Les messages RSVP réels reçus du voisin

Pour obtenir ces informations, vous pouvez émettre une show rsvp neighbor detail commande. L’exemple de sortie suit:

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

Configuration de l’intervalle Hello RSVP

RSVP surveille l’état des voisins IGP IS-IS ou OSPF et s’appuie sur les protocoles IGP pour détecter les pannes d’un nœud. Si un IGP ajoute un voisin en bas (car les paquets hello ne sont plus reçus), RSVP le fait également. Cependant, les protocoles IGP et RSVP agissent toujours de façon indépendante lors de l’amener avec un voisin.

Pour Juniper Networks routeurs, la configuration d’un intervalle RSVP hello plus court ou plus long n’a aucun impact sur la question de savoir si une session RSVP est ou non down. Les sessions RSVP sont maintenues 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 IGP paquets hello ou que les messages RSVP Path and Resv ne soient plus envoyés. Toutefois, à partir Junos OS version 16.1, lorsque RSVP hello messages time-out, les sessions RSVP sont ralenties.

L’intervalle Hello RSVP peut également être impacté lorsque l’équipement d’un autre fournisseur amène une session RSVP. Par exemple, un routeur non-Juniper Networks voisin peut être configuré pour surveiller les paquets RSVP Hello.

Pour modifier la fréquence d’envoi de paquets hello par RSVP, indiquez hello-interval l’instruction suivante:

Pour obtenir la liste des niveaux de hiérarchie à partir des lesquels vous pouvez inclure cette instruction, consultez la section récapitulatif 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 fiables participent à la configuration des réservations. Par défaut, l’authentification RSVP est désactivée.

L’authentification RSVP utilise un digest basé sur les messages de hachage du code d’authentification des messages (HMAC) MD5. Ce schéma produit un digest de message basé sur une clé d’authentification secrète et le contenu du message. (Le contenu du message contient également un numéro de séquence.) Le digeste est transmis avec des 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. Il peut également empêcher les attaques par rejeu. Toutefois, elle ne fournit aucune 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 authentication-key l’instruction:

Vous pouvez inclure cet énoncé 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 d’un type de classe pour les réservations RSVP. Lorsque vous sursinscrisez un type de classe pour un LSP multiclass, la demande agrégée de toutes les sessions RSVP est autorisée à 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 classe, consultez la zone De 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 ingénieries de trafic, mais la bande passante actuelle disponible sur les liens de base de données des techniques du trafic vient de RSVP. En cas de modification de la bande passante d’une liaison, RSVP en informe les IGP, qui peuvent ensuite mettre à jour la base de données des ingénieries de trafic et les présenter à tous les nodes du réseau. Les nodes réseau savent ensuite la quantité de bande passante disponible sur la liaison de base de données des ingénieries de trafic (locale ou distante), et CSPF peut calculer correctement les chemins.

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

Vous pouvez configurer une valeur de 0,001 % à 20 % (le taux par défaut est de 10 %) pour le déclenchement d’IGP de sécurité. 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 à 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 aucune mise à jour IGP update-threshold réseau. Toutefois, si la bande passante réservée sur une liaison change de 20 % de la bande passante des liaisons, RSVP déclenche IGP mise à jour.

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

Si la valeur seuil est configurée pour plus de 20 % de la bande passante sur cette liaison, celle-ci atteint 20 % de la bande passante.

Par exemple, si la bande passante d’une interface est de 1 Gbit/s et que la bande passante est configurée de plus de 200 Mbits/s, le débit est de threshold-valuethreshold-value 200 Mbits/s. Ce seuil s’affiche à 20,000 % et threshold-value à 200 Mps.

Remarque :

Les deux options(seuil-% et threshold-value ) s’exclusivent mutuellement. Vous pouvez configurer une seule option à un moment donné afin de générer une mise à jour IGP pour réduire la bande passante. Ainsi, lorsqu’une option est configurée, l’autre est calculée et affichée sur la CLI.

Par exemple, sur une liaison de 1 Gbit/s, si le seuil de 5 % est configuré jusqu’à 5 %, le montant est calculé et affiché comme threshold-value 50 Mbits/s. De même, si le seuil est configuré à 50 m, le seuil est alors calculé et affiché threshold-value comme 5 %.

Pour ajuster le seuil auquel une modification de la bande passante réservée déclenche une mise à jour IGP, inclure l’énoncé de seuil de mise à jour. En raison du seuil de mise à jour, il est possible pour Constrained Shortest Path First (CSPF) de calcul d’un chemin en utilisant des informations obsolètes sur la bande passante des données d’ingénierie de trafic sur une liaison. Si RSVP tente d’établir un LSP sur ce chemin, il peut se rendre possible que la bande passante est insuffisante sur cette liaison. Dans ce cas, RSVP déclenche une mise à jour IGP de la base de données des ingénieries de trafic, inondant ainsi 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 la liaison encombrée. Notez que cette fonctionnalité est la fonction par défaut et qu’elle n’a pas besoin d’une configuration supplémentaire.

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

Configuration RSVP pour les interfaces en nombre non-numéro

La Junos OS prend en charge les ingénieries de trafic RSVP sur des interfaces non numérotées. Les informations sur les ingénieries de trafic concernant les liaisons sans numéro sont transportés dans les extensions d’ingénierie du trafic IGP pour OSPF et IS-IS telles que décrites dans le RFC 4203, les extensions OSPF à la prise en charge de la commutation d’étiquettes multi-protocoles généralisées (GMPLS)et le RFC 4205, les extensions Intermediate System to Intermediate System (IS-IS) à la prise en charge de la commutation d’étiquettes multi-protocoles généralisées (GMPLS). Les liaisons non numérotations peuvent également être indiquées dans la signalisation aspects techniques du trafic MPLS décrite dans le RFC 3477, « Signalisation n’étant pas en nombre dans le protocole de reserVation des ressources - Ingénierie du trafic (RSVP-TE). Cette fonctionnalité vous évite d’avoir à configurer les adresses IP pour chaque interface participant au réseau signalé par RSVP.

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

Pour configurer la protection des liaisons et le rerouroute rapide sur un routeur avec des interfaces non numérotés activées, vous devez configurer au moins deux adresses. Nous vous recommandons de configurer une interface secondaire sur le loopback en plus de la configuration de l’ID du routeur.

Configuration d’un nœud RSVP ID Hellos

Vous pouvez configurer les hellos RSVP basés sur l’ID de nœud pour vous assurer que les routeurs Juniper Networks peuvent interopérables avec les équipements des autres fournisseurs. Par défaut, Junos OS’utilise les hellos RSVP basés sur l’interface. Les bonjours RSVP basés sur l’ID de nœud sont indiqués dans le RFC 4558, Node-ID Based Resource Reservation Protocol (RSVP) Bonjour: Une déclaration de clarification . Les hellos nœuds-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 interfaces hellos pour ces interfaces. Vous pouvez également utiliser node-ID hellos pour les procédures de redémarrage graceful.

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

Pour activer les hellos nœud-ID RSVP globalement sur le routeur, inclure 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 l’interface RSVP dans le monde. Ce type de configuration peut s’impose dans les réseaux où le routeur Juniper Networks dispose de nombreuses connexions RSVP avec des équipements d’autres fournisseurs. Cependant, 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 l’interface RSVP globalement, mais active l’interface RSVP hellos sur l’interface spécifiée (l’interface RSVP sur qui vous configurez hello-interval l’instruction). Cette configuration peut être nécessaire dans un réseau hétérogène au cours duquel certains équipements sont en mesure de prendre en charge l’ID de nœud RSVP et d’autres prendre en charge l’interface RSVP hellos.

Pour désactiver l’interface RSVP partout dans le monde sur le routeur, indiquez 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 signalés par 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 tel qu’indiqué 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 réseau. Cet exemple montre comment activer MPLS et configurer RSVP sur l’interface de transit ge-0/0/0. En outre, vous devez activer le MPLS sur toutes les interfaces MPLS du réseau.

Cet exemple montre comment définir un LSP entre les R1 et R7 sur le routeur d’entrée (R1) en utilisant l’adresse de bouclure du R7 (10.0.9.7). La configuration réserve 10 Mbits/s de bande passante. En outre, cette configuration désactive l’algorithme CSPF, ce qui garantit que les hôtes C1 et C2 utilisent le LSP à signaux RSVP correspondant au chemin le plus court du réseau IGP.

Configuration

Procédure

CLI configuration rapide

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

Procédure étape par étape

L’exemple suivant vous oblige à naviguer dans différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation du CLI, consultez le guide de l’CLI en mode de configuration dans CLI’utilisateur.

Pour configurer RSVP:

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

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

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

  4. Définir le LSP sur le routeur d’entrée.

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

Résultats

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

Pour plus de concision, ce résultat de commande show inclut uniquement la configuration qui est pertinente dans cet exemple. Toutes les autres configurations du système ont été remplacées par des ellipses (ellipses).

Si vous avez terminé la configuration de l’équipement, commit saisissez-le en mode de configuration.

Vérification

Pour vérifier que la configuration fonctionne correctement, exécutez 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 dans la liste des routeurs R3 et R2 du routeur comme voisins Figure 1 RSVP.

Action

À partir du CLI, saisissez la show rsvp neighbor commande.

Le résultat affiche les adresses IP des routeurs voisins. Vérifiez que chaque adresse de loopback du routeur RSVP voisin 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 la bande passante est active.

Action

À partir du CLI, 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 du saut suivant, pour chaque session RSVP établie. Vérifier les informations suivantes:

  • Chaque adresse de voisin RSVP possède une entrée pour chaque voisin, répertoriée par adresse de boucll.

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

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

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

But

Vérifiez que la table de routage du routeur d’entrée (entrée) dispose d’un LSP configuré vers l’adresse de bouclure de l’autre routeur. Par exemple, vérifiez que la table de routage du routeur d’entrée R1 est configurée d’un LSP vers l’adresse de bouclure du inet.3Figure 1 routeur R7.

Action

À partir du CLI, saisissez la show route table inet.3 commande.

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

Exemple: Configuration du maillage automatique RSVP

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

En cas d’ajout d’un nouveau routeur PE qui participera à BGP et à des VPN MPLS, tous les routeurs PE existants existants doivent être configurés pour être pair avec le nouveau routeur PE pour les BGP et les MPLS. À mesure que chaque nouveau routeur PE est ajouté au réseau du fournisseur de services, la charge de configuration devient bientôt trop lourde à gérer.

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

Conditions préalables

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

  • Un routeur qui s’Junos OS version 10.1 ou ultérieure.

  • Un BGP et un VPN MPLS en utilisant RSVP comme protocole MPLS de signalisation de chemin de commutation d’étiquettes (LSP).

Présentation

Cet exemple montre comment configurer le maillage automatique RSVP sur un routeur PE à l’aide de rsvp-te l’énoncé de configuration. Pour que le maillage automatique RSVP fonctionne correctement, l’instruction doit être configurée sur tous les routeurs PE du configuration entièrement maillée rsvp-te réseau. 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 rsvp-te l’énoncé.

Compte tenu de cette exigence, cet exemple affiche uniquement la configuration du nouveau routeur PE. Il est supposé que le maillage automatique RSVP a déjà été configuré sur les routeurs PE existants.

Topologie

Il Figure 2 existe trois routeurs PE existants, PE1, PE2 et PE3, dans la topologie. Un pe4 a été ajouté et un 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 affichée au centre de la figure.

Figure 2 : Fournisseur de services réseau avec routeurs PEFournisseur de services réseau avec routeurs PE

Configuration

La configuration du maillage automatique RSVP implique l’opération de ces tâches:

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

  • La configuration de l’élément destination-networks requis.

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

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

    Cet élément de configuration prend l’un ou l’autre du nom d’un modèle default-template 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 de l’utilisateur.

CLI configuration rapide

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les interruptions de ligne, modifiez tous les détails nécessaires pour correspondre à votre configuration réseau, puis copiez/collez les commandes dans le CLI 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 dans différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la manière de vous y rendre, consultez le manuel Using the CLI Editor in Configuration Mode dans le CLI User Guide.

Pour activer le maillage automatique RSVP:

  1. rsvp-teConfigurez-les au [edit routing-options dynamic-tunnels] niveau hiérarchique.

  2. destination-networksConfigurez-les au [edit routing-options dynamic-tunnels] niveau hiérarchique.

Résultats

Numéro de show commande du niveau hiérarchique pour voir les résultats de votre [edit routing-options dynamic-tunnels] configuration:

Vérification

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

But

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

Action

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

But

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

Action

Configurer Hello Accusé de réception pour les voisins RSVP de non-sécurité

La déclaration contrôle le comportement d’accusé de réception entre les voisins RSVP, qu’ils se rencontrent ou non hello-acknowledgements dans la même session.

Bonjour messages reçus de voisins RSVP qui ne font pas partie d’une session RSVP courante sont écartés. Si vous configurez l’énoncé au niveau de la hiérarchie, les messages de hello-acknowledgements voisins non-ssion sont reconnus par un message d’accusé [edit protocols rsvp] de réception. Lorsque nous recevons les bonjours de voisins sans présence, une relation de voisinage RSVP est créée et des messages hello périodiques peuvent désormais être reçus de la part des voisins de non-sion. hello-acknowledgementsL’instruction est désactivée par défaut. La configuration de cette instruction permet de découvrir des routeurs capables de RSVP à l’aide de paquets Hello et vérifie que l’interface est capable de recevoir des paquets RSVP avant d’envoyer des messages de configuration LSP de MPLS.

Une fois que vous activez l’accusé de réception des voisins RSVP de non-ession, le routeur continue de reconnaître les messages de tout voisin RSVP de non-assession, sauf si l’interface elle-même est en panne ou que vous modifiez la configuration. Les voisins basés sur les interfaces ne sont pas automatiquement en sortie.

Vous pouvez inclure cet énoncé aux niveaux hiérarchiques suivants:

  • [edit protocols rsvp]

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

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

Vous pouvez configurer le routeur pour que les LSP actifs s’écartent d’un nœud réseau à l’aide d’un LSP de dérivation activé 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 du trafic devant passer autour de l’équipement réseau que vous avez l’intention de désactiver. Pour fonctionner correctement, le LSP de dérivation doit utiliser une interface logique différente de celle du LSP protégé.
  2. Pour préparer le routeur à remplacer le trafic par un nœud du réseau, configurez always-mark-connection-protection-tlv l’énoncé:

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

    Vous pouvez configurer cet énoncé 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 pour basculer le trafic du LSP protégé vers le LSP de dérivation, de manière à contourner l’équipement réseau en aval par switch-away-lsps défaut. Le lien lui-même n’est pas down par cette configuration.

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

    Vous pouvez configurer cet énoncé 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 relatives à la commutation de LSP actifs à un nœud réseau:

  • La fonctionnalité de transfert du commutateur n’est prise MX Series que sur les routeurs.

  • La fonction de commutation n’est pas prise en charge pour le trafic de commutation des LSP point-multipoint principaux afin de contourner les LSP point à multipoint. Si vous configurez l’instruction pour un LSP point-multipoint, le trafic n’est pas commuté vers le switch-away-lsps LSP de dérivation point à multipoint.

  • Si vous configurez la fonction de transfert de commutateur sur une interface le long du chemin d’un LSP dynamique, de nouveaux LSP dynamiques ne peuvent pas être établis sur ce chemin. La fonction d’évitement du commutateur prévient le comportement des LSP signalés par RSVP. Le comportement d’introduction à la panne fait normalement en sorte que le routeur tente d’abord de signaler de nouveau un LSP dynamique avant de détruire l’original.

Configuration de la protection de configuration RSVP

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

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

  2. Un LSP de dérivation protège également la liaison ou le nœud.

  3. Le RSVP signale au LSP qu’il contourne le LSP. Le LSP apparaît comme s’il avait initialement été installé sur son chemin principal, puis a échoué sur le LSP de dérivation à cause de la défaillance de la liaison ou du nœud.

  4. Une fois la liaison ou le nœud récupéré, le LSP peut être automatiquement revenir au chemin principal.

Vous devez configurer l’instruction au niveau de chaque routeur le long du chemin LSP sur lequel vous souhaitez activer une protection de configuration setup-protection[edit protocols rsvp] LSP. Vous devez également configurer les IGP du trafic sur tous les routeurs du chemin LSP. Vous pouvez émettre une commande pour déterminer si le LSP dispose ou non d’une protection de configuration activée sur un routeur qui agit comme point de réparation locale (PLR) ou comme point de show rsvp session fusion.

Pour activer la protection de configuration RSVP, inclure setup-protection l’instruction

Vous pouvez inclure cet énoncé aux niveaux hiérarchiques suivants:

  • [edit protocols rsvp]

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

Configuration de l’équilibrage de charge sur 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 mesure, un des LSP est sélectionné de manière aléatoire et tout le trafic lui est transmis.

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

Pour permettre l’équilibrage de charge par paquet sur un LSP d’entrée, configurez policy-statement l’énoncé comme suit:

Vous devez ensuite appliquer cet énoncé en tant que stratégie d’exportation au tableau de forwarding.

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 la charge par paquet si vous souhaitez activer un reroutage rapide du PFE. Pour activer le reroutage rapide du PFE, ajoutez l’instruction d’équilibrage de la charge par paquet indiquée dans cette section dans la configuration de chacun des routeurs sur lequel un reroutage peut avoir policy-statement lieu. Voir également Configuring Fast Reroute.

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

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

Vous pouvez configurer cet énoncé 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 load-balance l’énoncé:

  • Si vous configurez l’instruction, le comportement des LSP en cours d’exécution load-balance 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 instruction s’applique uniquement aux LSP d’entrée qui ont activé l’équilibrage de la charge par paquet.

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

Configuration du maillage automatique RSVP

Vous pouvez configurer RSVP pour établir automatiquement des chemins de commuté 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 sur tous les rsvp-te routeurs PE du maillage complet.

Remarque :

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

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

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) du réseau de destination. Des tunnels dynamiques peuvent être lancés dans la plage de préfixes IPv4 spécifiées.

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

Configuration des timers pour la remise à jour des messages RSVP

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

  • refresh-time—Le temps de actualisation contrôle l’intervalle entre la génération de messages de actualisation successifs. La valeur par défaut de la durée de actualisation est de 45 secondes. Ce numéro est dérivée de la valeur par défaut de 30 de l’énoncé, multipliée par une valeur refresh-time fixe de 1,5. Cette puissance de calcul diffère de la RFC 2205, selon laquelle le temps de actualisation doit être multiplié par une valeur aléatoire de l’ordre de 0,5 à 1,5.

    Les messages de actualisation incluent les messages de chemin et de resv. Des messages de actualisation sont envoyés périodiquement afin que les états de réservation des nodes voisins ne s’en sortent pas. Chaque chemin et message resv transporte la valeur du timer de actualisation, et le nœud de réception extrait cette valeur des messages.

  • keep-multiplier—Le multiplicateur de keep est un petit registre configuré localement 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 doit être supprimé. Le multiplicateur de keep a une incidence directe sur 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, ( – 1) les messages de actualisation successifs doivent être perdus avant la suppression keep-multiplier de l’état de réservation.

Il n’est pas recommandé de configurer un court rSVP hello timer. Si vous avez besoin d’une détection rapide d’un voisin défaguré, configurez IGP petits OSPF ou IS-IS) hello timers.

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

Vous pouvez inclure cet énoncé aux niveaux hiérarchiques suivants:

  • [edit protocols rsvp]

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

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

Vous pouvez inclure cet énoncé aux niveaux hiérarchiques suivants:

  • [edit protocols rsvp]

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

Préempting RSVP Sessions

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 plus prioritaire.

Pour toujours préempter une session lorsque la bande passante est insuffisante, inclure preemption l’énoncé avec aggressive l’option:

Vous pouvez inclure cet énoncé 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, ajoutez preemption l’instruction avec disabled l’option:

Pour revenir au niveau par défaut (c’est-à-dire préempter une session uniquement pour une nouvelle session plus prioritaire), inclure preemption l’instruction avec normal l’option:

Vous pouvez inclure cet énoncé aux niveaux hiérarchiques suivants:

  • [edit protocols rsvp]

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

Configuration MTU signalisation dans RSVP

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

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

Vous pouvez inclure cet énoncé aux niveaux hiérarchiques suivants:

  • [edit protocols mpls]

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

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

Activation MTU signalisation dans RSVP

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

Vous pouvez inclure cet énoncé aux niveaux hiérarchiques suivants:

  • [edit protocols mpls path-mtu]

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

Une fois la configuration engagée, les modifications du comportement MTU de signalisation pour RSVP entreront en vigueur lors de la prochaine actualisation du chemin.

Vous pouvez configurer mtu-signaling l’énoncé lui-même au niveau [edit protocols mpls path-mtu rsvp] de la hiérarchie. Cela peut être utile pour le dépannage. Si vous configurez uniquement l’instruction, vous pouvez utiliser la commande pour déterminer la plus petite MTU mtu-signaling se trouve sur un show rsvp session detail 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 que les paquets IP soient fragmentés avant qu’ils ne soient encapsulés MPLS, ajoutez allow-fragmentation l’instruction:

Vous pouvez inclure cet énoncé aux niveaux hiérarchiques suivants:

  • [edit protocols mpls path-mtu]

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

    Remarque :

    Ne configurez pas allow-fragmentation l’énoncé seul. Configurez-le toujours en même temps que mtu-signaling l’énoncé.

Configuration d’un saut ultime pour les LSP

Par défaut, les LSP signalés par RSVP utilisent l’avant-dernier saut (PHP).Figure 3 illustre un LSP vers l’avant-dernier saut entre le routeur PE1 et le routeur PE2. Le routeur CE1 fait avancer un paquet vers le saut suivant (Routeur PE1), qui est également le paquet d’entrée LSP. Le routeur PE1 pousse l’étiquette 1 sur le paquet et le pousse vers le routeur P1. Le routeur P1 termine l’opération MPLS de changement d’étiquettes standard, permutant l’étiquette 1 par l’étiquette 2, et route le paquet vers le routeur P2. Routeur P2 étant l’avant-dernier routeur du LSP vers le routeur PE2, il poppe d’abord le label puis le routeur PE2. Lorsque le routeur PE2 le reçoit, le paquet peut être marqué d’un label de service, d’un label explicit-null ou simplement d’un simple paquet IP ou VPLS. Le routeur PE2 route le paquet non-lablé vers le routeur CE2.

Figure 3 : Penultimate-Hop Popping pour un LSPPenultimate-Hop Popping pour un LSP

Vous pouvez également configurer le " ultimate-hop popping "(UHP)(tel qu’indiqué) pour les Figure 4 LSP à signaux RSVP. Certaines applications réseau peuvent exiger que les paquets arrivent au routeur de sortie (Routeur PE2) avec un label extérieur non nul. Pour un LSP à sauts ultimes, l’avant-dernier routeur (routeur P2 in) effectue le fonctionnement standard de permutation d’étiquettes MPLS (dans cet Figure 4 exemple, l’étiquette 2 pour l’étiquette 3) avant de faire avancer le paquet vers le routeur de sortie PE2. Le routeur PE2 pope le label extérieur et effectue une seconde recherche de l’adresse du paquet pour déterminer la destination finale. Il route ensuite le paquet vers la destination appropriée (routeur CE2 ou ROUTEur CE4).

Figure 4 : Saut ultime pour un LSPSaut ultime pour un LSP

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

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

  • Protection de périphérie circuits virtuels

Les fonctionnalités suivantes ne sont pas en charge du comportement DEUU:

  • LSP avec signalisation LDP

  • LSP statiques

  • LSP point à multipoint

  • CCC

  • traceroute Commande

Pour plus d’informations sur le comportement d’UHP, consultez le document Internet draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt, Non PHP behavior et Out-of-Band Mapping pour RSVP-TE LSP.

Pour les LSP signalés par RSVP point à point, le comportement DE LSP est signalé à partir du signal d’entrée LSP. En fonction de la configuration du routeur d’entrée, RSVP peut signaler l’UHP LSP avec l’ensemble d’indicateur non PHP. Les messages de CHEMIN RSVP portent les deux indicateurs de l’objet LSP-ATTRIBUTES. Lorsque le routeur de sortie reçoit le message PATH, il attribue un label non-null au LSP. RSVP crée et installe également deux routes dans la table de routage mpls.0. S fait référence au bit S du label MPLS, qui indique si le bas de la pile d’étiquettes a été atteint ou non.

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

  • Route S=1: indique qu’il n’y a plus d’étiquettes. Le saut suivant pointe vers la table de routage inet.0 si la plate-forme prend en charge la recherche multi-familles et chaînées. Le routeur d’étiquettes peut également pointer vers une interface VT pour lancer un forwarding IP.

Si vous activez les LSP UHP, les applications MPLS comme les VPN de couche 3, les VPLS, les VPN de couche 2 et les circuits de couche 2 peuvent utiliser les LSP. Les détails ci-après expliquent comment les LSP UHP affectent les différents types d MPLS applications:

  • VPN de couche 2 et circuits de couche 2: un paquet arrive au routeur PE (sortie du LSP UHP) avec deux labels. L’étiquette extérieure (S=0) est l’étiquette UHP, et l’étiquette interne (S=1) est le label VC. Une recherche basée sur le label de transport entraîne une poignée de tableau pour la table de routage mpls.0. Un chemin supplémentaire est également ajouté à la table de routage mpls.0 correspondant au label interne. Une recherche basée sur le label interne entraîne l’CE saut suivant.

  • VPN de couche 3: un paquet arrive au routeur PE (sortie du LSP UHP) avec deux labels. L’étiquette extérieure (S=0) est l’étiquette UHP et l’étiquette interne est le label VPN (S=1). Une recherche basée sur l’étiquette de transport entraîne une poignée de tableau pour la table de routage mpls.0. Dans ce scénario, deux scénarios sont possibles. Par défaut, les VPN de couche 3 font la publicité du label par saut suivant. Une recherche basée sur le label interne entraîne le saut suivant vers CE routeur. Toutefois, si vous avez configuré l’instruction pour l’instance de routage VPN de couche vrf-table-label 3, le label LSI interne indique la table de routage VRF. Une recherche IP a également été effectuée pour la table de routage VRF.

    Remarque :

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

  • VPLS: un paquet arrive au routeur PE (sortie du LSP UHP) avec deux labels. L’étiquette extérieure porte le label de transport (S=0) et le label interne VPLS (S=1). Une recherche basée sur l’étiquette de transport entraîne une poignée de tableau pour la table de routage mpls.0. Une recherche basée sur le label 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 ne sont pas configurés (ou qu’une interface VT n’est pas disponible). Les routeurs 3D MX Series supportent la recherche en chaîne et la recherche multi-familles.

    Remarque :

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

  • IPv4 sur MPLS: un paquet arrive au routeur PE (sortie DU LSP UHP) avec un seul label (S=1). Une recherche basée sur ce label renvoie à une interface de tunnel VT. Une autre recherche SUR IP est effectuée sur l’interface VT afin de déterminer l’objectif du 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 PTX Series Routeurs de transport de paquets), la recherche se base sur les points de routage d’étiquettes (S=1) vers la table de routage inet.0.

  • IPv6 sur MPLS: pour la tunneling IPv6 sur MPLS, les routeurs PE font la publicité des routes IPv6 entre elles avec une valeur de label de 2. Il s’agit du label null explicite pour IPv6. Ainsi, les sauts suivants pour les routes IPv6 tirés des routeurs PE distants poussent normalement deux labels. Le label interne est 2 (il peut être différent si le routeur PE publicitaire vient d’un autre fournisseur) et le label du routeur est le label LSP. Les paquets arrivent au routeur PE (sortie du LSP UHP) avec deux labels. L’étiquette extérieure est le label de transport (S=0), et le label interne est le label explicit-null IPv6 (label 2). La recherche basée sur le label interne de la table de routage mpls.0 redirige vers la table de routage mpls.0. Sur les routeurs MX Series 3D, le label interne (label 2) est dénudé et une enquête IPv6 est réalisée à l’aide de la table de routage inet6.0.

  • Activation des LSP PHP et UHP: Vous pouvez configurer à la fois PHP et LSP sur les mêmes chemins réseau. Vous pouvez séparer le trafic PHP et LSP en sélectionnant le saut suivant par LSP en utilisant une expression régulière à l’aide de install-nexthop l’énoncé. Vous pouvez également séparer le trafic en nommant simplement les LSP de manière appropriée.

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

  1. Pour activer le saut ultime, inclure ultimate-hop-popping l’instruction:

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

    Remarque :

    Lorsque vous activez un saut ultime, le RSVP tente de recaler les LSP existants en tant que LSP d’ultime saut, de façon à pré-breaker. Si un routeur de sortie ne prend pas en charge le saut ultime, le LSP existant est supprimé (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 le saut ultime, les LSP existants relaient les RSVP comme avant-dernier saut en tant qu’avant-dernier saut.

  2. Si vous souhaitez activer le saut ultime et enchaîner les sauts suivants sur les routeurs 3D MX Series uniquement, vous devez également configurer l’option de enhanced-ipnetwork-services l’instruction:

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

Configuration de RSVP pour pop le label 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 routeur du saut retire le label et envoie le paquet au routeur de sortie. Lorsque le saut ultime est activé, l’étiquette 0 (IP version 4 [IPv4] Label Explicit NULL) est annoncée. Un saut au saut ultime garantit que tous les paquets qui traversent un MPLS comprennent une étiquette.

Remarque :

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

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

Vous pouvez inclure cet énoncé aux niveaux hiérarchiques suivants:

  • [edit protocols mpls]

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

Permettre un saut ultime sur les LSP point à multipoint

Par défaut, pour les LSP point à point et point à multipoint, l’avant-dernier saut est utilisé pour l’MPLS trafic. MPLS étiquettes sont retiré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 le saut ultime, le routeur de sortie est chargé à la fois de retirer MPLS étiquette et de traiter le paquet IP clair.

Il peut être bénéfique pour permettre un saut ultime sur des LSP point à multipoint, en particulier lorsque le trafic transite par le même équipement de sortie. Si vous activez le saut ultime, vous pouvez envoyer une seule copie du trafic sur la liaison entrante, ce qui permet d’économiser de la bande passante. Par défaut, le saut ultime est désactivé.

Vous activez le saut ultime pour les LSP point-à-multipoint en configurant tunnel-services l’instruction. Lorsque vous activez un saut ultime, l’Junos OS sélectionne l’une des interfaces VT (Virtual Loopback Tunnel) disponibles pour boucler les paquets vers le PFE pour le forwarding IP. Par défaut, le processus de sélection de l’interface VT s’effectue automatiquement. Le contrôle d’admission de bande passante est utilisé pour limiter le nombre de LSP qui peuvent ê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 suffisamment de bande passante pour le contrôle d’admission.

Si un LSP nécessite une bande passante plus importante que celle disponible depuis n’importe quelle interface VT, il est impossible d’activer le saut ultime et de mettre en place un popping vers l’avant-dernier saut.

Pour qu’un saut ultime sur les LSP point à multipoint fonctionne correctement, le routeur de sortie doit être dirigé par 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 sur-MPLS étiquette finale et pour les paquets de retour pour la recherche d’adresses IP.

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

Pour activer un saut ultime pour les LSP de point de sortie vers multipoint d’un routeur, configurez tunnel-services l’instruction:

Vous pouvez configurer cet énoncé aux niveaux hiérarchiques suivants:

  • [edit protocols rsvp]

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

Pour activer un saut ultime pour les LSP de point de sortie vers multipoint, vous devez également configurer interface l’instruction avec all l’option:

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

Tracing RSVP Protocol Traffic

Pour suivre le trafic du protocole RSVP, inclure traceoptions l’énoncé:

Vous pouvez inclure cet énoncé aux niveaux hiérarchiques suivants:

  • [edit protocols rsvp]

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

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

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

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

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

  • event—Événements liés à RSVP (permettent de suivre les événements liés à la redémarrage graceful de RSVP)

  • lmp—Interactions LMP (Link Management Protocol) RSVP

  • packets—Tous les paquets RSVP

  • path—Tous les messages de chemin

  • pathtear—Messages PathTear

  • resv—Messages resv

  • resvtear—Messages ResvTear

  • route— Informations sur le routage

  • state—Transitions d’état de session, y compris lorsque les LSP signalés par RSVP sont en cours de développement et de panne.

Remarque :

Utilisez l’indicateur de traçabilité et le modifier de l’indicateur avec prudence, car cela peut rendre le alldetail processeur très occupé.

Pour afficher le fichier journal généré lorsque vous activez les opérations de traçage RSVP, ajoutez la commande, où se trouve le fichier que vous avez spécifié à l’aide de show log file-namefile-nametraceoptions l’énoncé.

Pour des informations générales sur le traçage et les options de traçage global, consultez la bibliothèque Junos OS routage des protocoles de routage pour les équipements de routage.

Exemples: Tracing RSVP Protocol Traffic

Suivi détaillé des messages de chemin RSVP:

Tracez tous les messages RSVP:

Suivre toutes les conditions d’erreur RSVP:

Suivi des transitions d’état RSVP:

Sortie des fichiers journaux RSVP

Les exemples suivants sont les exemples de sortie générés par l’émission de la commande sur un routeur sur lequel les traces RSVP ont été activées avec l’indicateur show log file-namestate configuré. L’E-D LSP à signaux RSVP est illustré le 11 mars 14:04:36.707092. Le 11 mars 14:05:30.101492, l’affiche remonte.

Redémarrage graceful du RSVP

Le redémarrage rapide du routeur permet à un routeur de redémarrage d’informer ses voisins adjacents de sa condition. Le routeur de redémarrage demande un délai de grâce au voisin ou à l’pair, qui peut ensuite coopérer avec le routeur de redémarrage. Le routeur de redémarrage peut toujours MPLS trafic pendant la période de redémarrage ; la convergence du réseau n’est pas perturbée. Le redémarrage n’est pas visible sur le reste du réseau et le routeur de redémarrage n’est pas retiré de la topologie réseau. Le redémarrage graceful du RSVP peut être activé à la fois sur les routeurs de transit et les routeurs d’entrée. Il est disponible aussi bien pour les LSP point à point que pour les LSP point à multipoint.

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

Terminologie RSVP graceful restart

Temps de redémarrage (en millisecondes)

La valeur par défaut est de 60 000 millisecondes (1 minute). Le temps de redémarrage est annoncé dans le message Hello. L’heure indique la durée d’attente pour qu’un voisin attende le message d’un routeur de redémarrage avant de déclarer la mort et les états de puring de ce routeur.

La Junos OS peut remplacer le temps de redémarrage annoncé par un voisin si cette durée est supérieure au tiers du temps de redémarrage local. Par exemple, étant donné le temps de redémarrage par défaut de 60 secondes, un routeur attendrait 20 secondes ou moins pour recevoir un message hello de la part d’un voisin de redémarrage. Si le temps de redémarrage est nul, le voisin de redémarrage peut être immédiatement déclaré mort.

Temps de récupération (en millisecondes)

S’applique uniquement lorsque le canal de contrôle est en place (l’échange Hello est terminé) avant la durée de redémarrage. S’applique uniquement aux pannes nodales.

Lorsqu’un redémarrage est en cours, le temps qui reste à la récupération est annoncé. Dans d’autres cas, cette valeur n’est aucune. Le temps de récupération maximum annoncé est de 2 minutes (120 000 millisecondes).

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

Opération de redémarrage graceful du RSVP

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

Le redémarrage graceful du RSVP nécessite les opérations suivantes, à la suite du redémarrage du routeur et aux voisins du routeur:

  • Pour le routeur de redémarrage, le RSVP tente de redémarrage normal en conservant les routes installées par RSVP et les étiquettes allouées, afin que le trafic continue d’être transmis sans interruption. Le redémarrage graceful du RSVP est effectué assez rapidement pour réduire ou éliminer l’impact sur les nodes voisins.

  • Les routeurs voisins doivent activer le mode d’assistance de redémarrage rapide RSVP, ce qui leur permet d’aider un routeur à tenter de redémarrer RSVP.

Un objet appelé Cap de redémarrage est envoyé dans des messages hello RSVP qui font la publicité de la capacité de redémarrage d’un nœud. Le nœud voisin envoie un objet De récupération d’étiquettes au nœud de redémarrage pour retrouver son état de forwarding. Il s’agit essentiellement de l’ancien label dont le nœud de redémarrage était annoncé avant la panne du nœud.

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

  • Si vous désactivez le mode d’aide, le Junos OS n’essaie pas d’aider un voisin à redémarrer RSVP. Toutes les informations qui arrivent avec un objet Cap de redémarrage provenant d’un voisin sont ignorées.

  • Lorsque vous activez le redémarrage de manière normale dans le cadre de la configuration de l’instance de routage, le routeur peut le redémarrage avec l’aide de ses voisins. RSVP fait la publicité d’un objet cap de redémarrage (REDÉMARRAGE RSVP) dans les messages hello dans lesquels les temps de redémarrage et de restauration sont spécifiés (aucune valeur n’est 0).

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

  • Si, après redémarrage, RSVP réalise qu’aucun état de redémarrage n’a été préservé, l’objet Cap de redémarrage est annoncé avec les temps de redémarrage et de restauration spécifiés comme 0.

  • Si le redémarrage graceful et le mode d’aide sont désactivés, le redémarrage graceful RSVP est entièrement désactivé. Le routeur ne reconnaît ni ne fait la publicité des objets de redémarrage graceful RSVP.

Vous ne pouvez pas configurer des valeurs pour les temps de redémarrage et de reprise.

Contrairement à d’autres protocoles, il n’est pas possible pour RSVP de déterminer qu’il a terminé une procédure de redémarrage, autre qu’un délai d’essai fixe. Toutes les procédures de redémarrage graceful RSVP sont basées sur le timer. Une commande peut indiquer que le redémarrage est toujours en cours, même si toutes les show rsvp version sessions RSVP sont rétablies et que les routes sont rétablies.

Traitement de l’objet cap de redémarrage

Les hypothèses suivantes reposent sur un voisin basé sur l’objet Cap de redémarrage (en supposant qu’une défaillance du canal de contrôle peut être clairement distinguée d’un redémarrage de nœud):

  • Un voisin qui ne fait pas la publicité de l’objet Cap de redémarrage dans ses messages hello n’est pas en mesure d’aider un routeur à rétablir l’état ou l’étiquette, et il ne peut pas effectuer de redémarrage graceful RSVP.

  • Après le redémarrage, un voisin affiche un objet Cap de redémarrage avec un temps de redémarrage égal à n’importe quelle valeur et un temps de reprise égal à 0 n’a pas préservé son état de redémarrage. Lorsqu’un temps de restauration est égal à 0, le voisin est considéré comme étant mort et tous les états liés à ce voisin sont resserrés, indépendamment de la valeur du temps de redémarrage.

  • Après le redémarrage, un voisin affiche son temps de récupération avec une valeur autre que 0 et peut conserver ou a maintenu l’état de forwarding. Si le routeur local aide son voisin à mettre en place des procédures de redémarrage ou de restauration, il envoie un objet d’étiquette de récupération à ce voisin.

Configuration du redémarrage graceful RSVP

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

  • Le redémarrage graceful et le mode helper sont tous deux activés (le par défaut).

  • Le redémarrage est activé, mais le mode d’aide est désactivé. Un routeur configuré de cette manière peut redémarrer normalement, mais ne peut pas aider un voisin avec ses procédures de redémarrage et de restauration.

  • Le redémarrage est désactivé, mais le mode d’aide est activé. Un routeur configuré de cette manière ne peut pas redémarrer correctement, mais peut aider un voisin de redémarrage.

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

Remarque :

Pour activer le redémarrage graceful RSVP, vous devez définir le minuteur de redémarrage d’au moins 180 secondes.

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

Permettre un redémarrage graceful pour tous les protocoles de routage

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

Pour permettre le redémarrage graceful du routeur, indiquez graceful-restart l’instruction suivante:

Vous pouvez inclure cet énoncé aux niveaux hiérarchiques suivants:

  • [edit routing-options]

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

Désactivation du redémarrage graceful pour RSVP

Par défaut, le redémarrage graceful RSVP et le mode d’aide RSVP sont activés lorsque vous activez le redémarrage. Cependant, vous pouvez désactiver une ou les deux de ces fonctionnalités.

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

Désactivation du mode d’aide RSVP

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

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

Pour configurer la durée pendant que le routeur conserve l’état de ses voisins RSVP lors d’un redémarrage, inclure l’instruction au niveau maximum-helper-recovery-time[edit protocols rsvp graceful-restart] de la hiérarchie. Cette valeur s’applique à tous les routeurs voisins, de sorte qu’elle doit être basée sur le temps requis par le voisin RSVP le plus lent à récupérer.

Configuration du temps maximal de redémarrage de l’helper

Pour configurer le délai entre la découverte d’une panne d’un routeur voisin et la panne du voisin, inclure l’instruction au niveau de maximum-helper-restart-time[edit protocols rsvp graceful-restart] la hiérarchie. Cette valeur s’applique à tous les routeurs voisins, de sorte qu’elle doit être basée sur la durée de redémarrage requise par le voisin RSVP le plus lent.

Présentation des tunnels LSP RSVP

Un tunnel LSP (Label-Switched Path) RSVP (Resource Reservation Protocol) vous permet d’envoyer des LSP RSVP dans d’autres LSP RSVP. L’administrateur réseau peut ainsi assurer des ingénieries de trafic d’une extrémité du réseau à l’autre. Pour cette fonctionnalité, il est utile de connecter les routeurs de périphérie des clients (CE) aux routeurs de périphérie du fournisseur (PE) en utilisant un LSP RSVP, puis de tunneler ce LSP de périphérie dans une seconde RSVP LSP qui traverse le cœur du réseau.

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

Un tunnel LSP RSVP ajoute le concept d’adjacence de forwarding, similaire à celui utilisé pour les MPLS générales (GMPLS). (Pour plus d’informations sur GMPLS, consultez le Guide de l’utilisateur de Junos GMPLS.

L’adjacence de transmission crée un chemin tunnelé pour l’envoi de données entre équipements pairs dans un réseau LSP RSVP. Une fois qu’un LSP d’adjacence de communication (FA-LSP) a été établi, d’autres LSP peuvent être envoyés sur le FA-LSP en utilisant CSPF (Constrained Shortest Path First), LMP (Link Management Protocol), Open Shortest Path First (OSPF) et RSVP.

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

  • LMP: à l’origine conçu pour GMPLS, LMP établit des relations d’adage de communication entre les pairs de tunnel LSP RSVP, et maintient et alloue les ressources pour les liaisons d’ingénierie de trafic.

  • OSPF extensions: OSPF a été conçue pour router les paquets vers des interfaces physiques et logiques liées à une carte PIC (Physical Interface Card). Ce protocole a été étendu pour router les paquets vers des interfaces pair virtuelles 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 du chemin pour les LSP de paquets qui se déplacent vers des interfaces pair virtuelles définies dans une configuration LMP.

    Remarque :

    Depuis la 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 du routeur virtuel. Un routeur peut créer et participer à plusieurs partitions topologies TE indépendantes, ce qui permet à chaque domaine TE partitionnement d’être resserrez de manière indépendante. Le modèle RSVP-TE multi-instance offre la possibilité de sélectionner à la main les entités de plan de contrôle qui doivent être conscients des instances, par exemple un routeur peut participer à plusieurs instances de TE tout en exécutant une seule instance BGP.

    L’implémentation Junos OS de MPLS RSVP-TE est 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:

    • S’assurer que le plan de données LSP est prêt pendant la libération du LSP avant que le trafic ne traverse le LSP avec le mécanisme de ping autonome RSVP-TE LSP.

      Un LSP ne doit pas commencer à transporter le trafic à moins d’avoir é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’entrée avant de basculer le trafic vers un LSP ou vers son instance MBB. Dans les réseaux de grande taille, ce trafic peut écraser un routeur de sortie LSP, car le LSP de sortie doit répondre aux requêtes de ping LSP. Le mécanisme d’auto-ping LSP permet au LER d’entrée 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 fait passer au centre d’entrée, indiquant ainsi le bien-être du plan de données LSP. Cela garantit que le LSP ne commence pas à transporter le trafic avant la programmation du plan de données.

    • Suppression de la limite dure actuelle de 64 K LSP sur un routeur d’entrée et mise à l’échelle du nombre total de LSP avec LSVP-TE LSP signalés. Il est possible de configurer jusqu’à 64 000 LSP par sortie. Auparavant, cette limite était le nombre agrégé de LSP configurables sur le LER d’entrée.

    • Prévention de la rupture des LSP par le routeur d’entrée en raison d’un 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 Junos OS version 17.4, un minuteur par défaut de 1 800 secondes pour le ping autonome est introduit.

Les limites suivantes existent pour les hiérarchies LSP:

  • Les LSP basés sur circuits basés sur des connexions croisées (CCC) ne sont pas pris en charge.

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

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

  • Les LSP point à multipoint ne sont pas pris en charge par les LSP fa-LSP.

Exemple: Configuration de tunnels LSP RSVP

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

Figure 5indique un LSP RSVP de bout en bout, originaire du routeur 0 et terminé e2e_lsp_r0r5 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 de bout en bout qui voyage e2e_lsp_r5r0 sur le FA-LSP. fa_lsp_r4r1

Sur le routeur 0, configurez le RSVP LSP de bout en bout qui passe au routeur 5. Utilisez un chemin strict qui traverse le routeur 1 et la liaison des ingénieries de trafic LMP qui relie le 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 de trafic LMP et une relation de pair LMP avec le routeur 4. Référez-vous à la FAQ-LSP dans le lien des ingénieries de trafic et ajoutez l’interface de peer dans OSPF et RSVP.

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

Routeur 1

Sur le routeur 2, configurez les 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 les 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 établir une relation de pair LMP avec le routeur 1. Référez-vous à la FAQ-LSP dans le lien des ingénieries de trafic et ajoutez l’interface de peer dans OSPF et RSVP.

Lorsque le LSP de bout en bout initial arrive au routeur 4, la plate-forme de routage effectue une recherche de routage et peut faire avancer 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 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 des ingénieries de trafic LMP qui relie le routeur 4 au routeur 1.

Routeur 5

Vérifier votre travail

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

  • show ted database (extensive)

  • show rsvp session name (extensive)

  • show link-management

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

Pour voir les commandes utilisées avec l’exemple de configuration, consultez les 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 ingénieries de trafic. Dans ce cas, recherchez les chemins du routeur 1 ( ) et du routeur 4 ( ) qui font référence aux adresses des liaisons techniques du trafic LMP de 10.255.41.21610.255.41.217 et 172.16.30.1172.16.30.2 . Vous pouvez également émettre la commande de rechercher le chemin du LSP de bout en bout lors de son passage au show rsvp session extensive routeur 5 sur le FA-LSP.

Routeur 1

Sur le routeur 1, vérifiez que la configuration des liaisons techniques LMP fonctionne bien et que le LSP de bout en bout parcourant la liaison d’ingénierie de trafic en publiant l’ensemble des show link-management commandes. Vous pouvez également émettre la show rsvp session extensive commande pour confirmer que le FA-LSP est opérationnel.

Configuration des interfaces pair dans OSPF et RSVP

Une fois que vous avez établi des pairs LMP, vous devez ajouter des interfaces à OSPF et RSVP. Une interface pair 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 peer peer-name à l’instruction configurée dans LMP au niveau [edit protocols link-management] de la hiérarchie. Étant donné que les paquets de protocole réels sont envoyés et reçus par des interfaces pairs, ces interfaces peuvent être signalées et annoncées aux pairs comme toute autre interface physique configurée pour OSPF et RSVP. Pour configurer le routage OSPF pour les pairs LMP, inclure peer-interface l’instruction au niveau [edit protocols ospf area area-number] de la hiérarchie. Pour configurer la signalisation RSVP pour les pairs LMP, inclure peer-interface l’instruction au niveau [edit protocols rsvp] de la hiérarchie.

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

Définissez ensuite votre FAQ-LSP en incluant label-switched-path l’instruction au niveau de la [edit protocols mpls] hiérarchie. Inclure l’ID de routeur de l’pair dans to l’instruction 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’égal et un deuxième FA-LSP pour revenir de ce pair.

Établissement d’informations sur le chemin de la fa-LSP

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

Remarque :

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

Option: Grâce à la baisse des LSP RSVP,

Vous pouvez détruire un LSP RSVP en deux étapes qui retire la session RSVP utilisée par le LSP. Pour tous les voisins qui supportent une opération de démontage, une demande de démontage est envoyée par la plate-forme de routage au point de terminaison de destination du LSP et de tous les voisins RSVP du chemin. La demande est incluse dans le ADMIN_STATUS champ du paquet RSVP. Lorsque les voisins reçoivent la demande, ils se préparent à ce que la session RSVP ne soit pas officielle. Un deuxième message est envoyé par la plate-forme de routage pour terminer la démontage de la session RSVP. Si un voisin ne prend pas en charge la graceful teardown, la demande est traitée comme une procédure standard de démontage de session plutôt que comme une demande de grâce.

Pour mettre fin à une session RSVP, émettre la clear rsvp session gracefully commande. Vous pouvez spécifier, si possible, 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 qualifications, inclure connection-source les , et les options lorsque vous connection-destinationlsp-idtunnel-id numérotez la clear rsvp session gracefully commande.

Vous pouvez également configurer la durée pendante que la plate-forme de routage attend les voisins pour recevoir la demande de grâce de démontage avant d’initier la procédure de démontage effective en incluant l’instruction au niveau de la graceful-deletion-timeout[edit protocols rsvp] hiérarchie. La valeur d’arrêt de la suppression normale 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 pour un délai d’arrêt de suppression, numérotez la show rsvp version commande du mode opérationnel.

Tableau de l'historique des versions
Version
Description
19.4R1
16.1
Toutefois, à partir Junos OS version 16.1, lorsque RSVP hello messages time-out, les sessions RSVP sont ralenties.